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

[Owen DeLong]

On Oct 10, 2010, at 1:29 AM, Joe Maimon wrote:

> 
> 
> Owen DeLong wrote:
>> 
>> On Oct 9, 2010, at 10:46 PM, Christopher Morrow wrote:
>> 
>>> On Sun, Oct 10, 2010 at 12:00 AM, Owen DeLong<owen at delong.com>  wrote:
>>> 
>>>> We will cause harm by being stingy with address space beyond these points.
>>> 
>>> you've mentioned (at least 2x in the last 3 days) that /48's for
>>> consumer end sites permit heirarchical dhcpv6-PD, can you explain how
>>> the you see this working? and more importantly why you can't do PD on
>>> ... just about any other boundary? Why can't I do PD of a /64 or /60
>>> inside an already PD'd /56 to my home gateway? (or is this just
>>> inconvenient?)
>>> 
>> For better or worse, /64 as the end subnet size is pretty well codified
>> and required for SLAAC. So, PD of /64 is a non-starter.
> 
> Its only as codified as we all allow it to be by continuing to give SLAAC veto power over the rightmost 64 bits.
> 
That ship really has sailed. SLAAC is deployed, people are using it. Breaking SLAAC would
be a bad thing.

> Its early days yet. In comparable v4 history, it was the leftmost bits that were well codified.
> 
Not early enough.

> There are alternatives to slaac, and apipa has already shown that 16 bits is sufficient in todays world.
> 
I'm not sure what you mean by apipa, but, no, 16 bits isn't sufficient for a stateless scheme.
It's especially insufficient if you want to allow for things like privacy addressing.

> Toss in privacy concerns and slaac is starting to look stodgy.
> 
Actually SLAAC with privacy addressing looks pretty good. Much better than almost any other
addressing scheme today for privacy concerns.

> Automatic numbering and subnetting schemes in v6 are going to have to be a bit more bit flexible if they are to withstand the test of time.
> 
It doesn't get much more flexible than SLAAC except for the requirement for EUI-64 based
end system identifiers.

> 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