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

Sun Sep 11 07:54:56 UTC 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