[arin-ppml] IPv6 Transition Policy (aka Soft Landing)

[Owen DeLong]

On Oct 10, 2010, at 9:53 AM, Joe Maimon wrote:

> 
> 
> Owen DeLong wrote:
>>   That ship really has sailed. SLAAC is deployed, people are using it. Breaking SLAAC would
>> be a bad thing.
>> 
>>   
> Fixing slaac would be a good thing. Its absurd to allow something barely a decade old control the next several. If it is still a good idea, keep it, if it is a better idea to modify it, do it.

It is still a good idea. It's not broken. I'm not in favor of "fixing" it.

>>   I'm not sure what you mean by apipa, but, no, 16 bits isn't sufficient for a stateless scheme.
>>   
> 
> It works now. It can work better with more but it does not necessarily require 64.

OK... I did a little bit of research. APIPA which you are holding out as a shining example
of address allocation is actually an almost completely useless technology. First, it is
only deployed today as a backstop for DHCP server failure, and, even then, it doesn't
work to provide useful network services in the vast majority of cases. Second, it has
serious scaling limitations and depends on all hosts having not only the same host
identifier, but, also the same prefix. It provides no mechanism for learning default
router and has no facility to support dynamic renumbering, prefix assignment, or
multiple addresses per host. All of these things are supported in SLAAC and without
the scaling limitations of APIPA.

For those that, like me, were unfamiliar with the term APIPA prior to this discussion,
APIPA is the formal name (Automatic Private IP Addressiing) for what happens on
a DHCP managed interface when it fails to get an address and assigns some
random number from 169.254/16 and validates uniqueness through ARP.

>> It doesn't get much more flexible than SLAAC except for the requirement for EUI-64 based
>> end system identifiers.
>>   
> Does this requirement bear out in anything other than slaac?

To my knowledge, noone has proposed an alternative stateless address allocation scheme.
If you have one, I'd need to see the details in order to judge the merits.

>>   
>>> In other words, pdv6 would have to ripple up the chain and cause subnet shortening on the fly all the way up in order to be fully robust.
>>> 
>>>     
>> Now you're throwing random technologies in a blender and postulating what comes out.
>> 
>> DHCPv6 PD does actually allow for shortening on the fly as you describe, but, most implementations
>> don't. However, the problem is that if the shortened result is the CPE->ISP router requesting a
>> prefix larger than the ISP can or will give, it doesn't matter how much dynamic shortening occurred
>> or not.
>> 
>> Owen
>> 
>> 
>>   
> If shortening smaller than 64 was available, it would be much more robust, regardless of what was available >64 from the ISP. It would work at least as well as apipa for another 48 bits, which is quite deep hierarchically.
> 
APIPA doesn't work for meaningful regular internet communications. You can't deploy an
enterprise numbered with APIPA. Suggesting it as an alternative for SLAAC is like
suggesting RIP as an alternative for BGP in the network core.

Owen