[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 3177-bis

Thus spake "Leo Vegoda" <leo.vegoda@icann.org>

On 18/03/2008 15:41, "Tony Hain" <alh-ietf@tndh.net> wrote:

Since we know the RIR policy will continue to be as stingy as
possible, there will be fragmentation over time, so more bits just
means a bigger scaling problem.


I have seen a number of RIRs make very large allocations.


Cases in point:

inet6num:        2003::/19
netname:         DE-TELEKOM-20050113
descr:           Deutsche Telekom AG

inet6num:        2a01:c000::/19
netname:         FR-TELECOM-20051230
descr:           France Telecom
I don't get the claims that RIRs will be "as stingy as possible", given they're already handing out IPv6 /19s to LIRs that can show a need. That's 536,870,912 customers without having to resort to per-site assignments longer than /48; given those two ISPs have a maximum of 82M and 64M customers, respectively, how are RIRs being "stingy"?
All this whining about needing longer prefixes for customer assignments just means the LIR isn't asking for a big enough allocation in the first place. There is plenty of space to go around on the left side, and all evidence to date is the RIRs will give it out if they're asked for it; we don't need to steal bits from customers on the right side.
(For instance, one cable operator in the US is said to need ~16M assignments, one for each home they pass, and that means they'll need to use /56s to fit into their /32. However, they could just as easily get a /24 and hand out /48s to each customer...) 


I am not aware of anyone complaining that their request for a big chunk
of IPv6 has been denied by a stingy RIR. If you are aware of a problem
with the RIRs' current IPv6 policies then you should draft a policy
proposal for a different policy.
If someone brings me an example of a reasonable request for v6 space being denied in the ARIN region, I'll be first in line to draft a proposal to fix the problem; I'm sure other folks will step up in the others. Frankly, though, the bar is already set so low that it requires little more than a pulse to get a v6 allocation (or assignment, in regions with PI) today... 


I've seen them liberalise their policies. You just need a convincing
argument.
Indeed. While I've only watched ARIN's policy process, the trend has been for gradually more liberal policies over time -- even for IPv4 in the face of imminent exhaustion, when all logic tells us we should be making them stricter. The IPv6 policies have been liberalised significantly, and not just in the adoption of PI assignments (which was certainly the most controversial).
All of that said, though, I fail to see the need for the IETF to revise RFC 3177. The RIRs started there and diverged, just like they started with RFC 2050 and diverged. This is nothing new; the RIRs view the IETF's input as advisory only, and have for a long time. The reality is that the IETF has no enforcement power over the RIRs once the address space has been delegated, and if one wants to change how the RIRs operate, one should show up at their meetings or on their mailing lists and use _their_ processes, not spend years publishing another RFC that will eventually be ignored just like 3177 and 2050 are now. Unless there's an overriding technical reason that /48s are too short -- and none has been identified so far, only the contrary -- this is a purely _policy_ matter, which is the RIRs' domain, not a _technical_ matter, which is the IETF's domain. 

S

Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking