North American Network Operators Group
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Multi-6 [WAS: OT - Vint Cerf joins Google]

  • From: Joe Abley
  • Date: Sun Sep 11 03:57:32 2005 
On 10-Sep-2005, at 21:42, Patrick W. Gilmore wrote:


On Sep 10, 2005, at 10:17 AM, Joe Abley wrote:
Yes, according to the current RIR policies. [So the determination of "unworthy" above has been made, in effect, by RIR members.]
And this is why v6 has failed and will continue to fail.
It'll only continue to fail (for this reason) as long as the various RIR memberships don't vote for change.

[...]

2. Because there is vastly more v6 space than v4 space, if entitlement to PI space in v6 was opened up the chances are many more people would have v6 PI space than currently have v4 PI space.
This assumption has more holes in it than swiss cheese.
It doesn't need to a foregone conclusion; it just needs to have significantly non-zero probability, since if it turns out to be true then we're all screwed.

Right now there are lots of multi-homed organisations who use NAT, and whose "PI" address space deployed internally comes from RFC1918. If you imagine all those enterprises using a globally-unique, PI v6 block instead, then perhaps the thinking behind the speculation in (2) above becomes clearer.

[ObCheese: most of the 450 or so kinds of cheese made in Switzerland don't have holes.]

Ignoring the problems with #2, what is made of the idea that each AS might only have a single block, since blocks are so much larger? (And lots of other questions I'm sure you guys have already covered which are probably not on-topic for NANOG.)
This is an RIR policy issue, not an IETF protocol issue. If the members of RIRs all pushed for the idea that "I have a globally- unique ASN" is also appropriate justification for a /32 allocation, then I would imagine that the policy might change.

It's possible that the number of PI assignments might not be that high, and the scaling properties in practice might not be so bad. However, you only get to find this out after you've opened the floodgates, and if it turns out that it doesn't scale, it's hard to push the water back into the reservoir.

The goal in shim6 is to find a mechanism which provides all the functional benefits of multi-homing without holding all the state in DFZ routers.
Perhaps the goal ... was chosen poorly?

Perhaps. This will surely become clear with the benefit of hindsight :-)


Joe