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

[Joe Maimon]

Owen DeLong wrote:
>
> On Oct 11, 2010, at 5:48 AM, Leo Bicknell wrote:

>
>> Back to the current day, IPv6 designers seemed to feel we were
>> moving to EUI-64's, and that fit nicely with the 64 bit boundary.
>> There are technologies that use EUI-64, but Ethernet is not one of
>> them yet.  It seems to me a lot of the 6rd problem could be solved
>> if we could use a /80 boundary for the local LAN.  Rather than use
>> EUI-64 on the LAN, EUI-48 (the MAC address directly) could be used.
>> Everything would work exactly the same as it does today (DAD, RA's,
>> DHCPv6, etc) only on the smallar address space.  Only some minor
>> changes need to be made so the host can detect if it is on a /64
>> or /80 boundary.
>>
> While we have not yet moved to 64 bit EUIs in ethernet, I do think
> that is only a matter of time. There are not that many OUIs left in
> the 48 bit EUI numbering space and the IEEE will have to do something
> at that point. Much like IPv6 is the alternative for solving the addressing
> problem in IPv4, EUI-64 is the IEEEs stated plan for addressing
> the shortage of EUI-48 identifiers, and, xx:xx:xx:FF:FE:xx:xx:xx is the
> reserved EUI-64 numbering space for EUI-48 compatibility addresses.

I remain unconvinced that aligning the L3 network addressing (local 
scope) with the L2 addressing (global scope) has enough to recommend it 
(other than how cute it looks) so that it is deserving of a lifetime 
guarantee of 64 bits. Quite a long lifetime.

In fact, it is a layering violation. Those always look cute initially.

>
> You're talking about updating an awful lot of hosts to facilitate this
> small change and I doubt it could be reliably accomplished in a
> sufficiently timely manner to be meaningful.


That argument is only valid when there is a deadline that when exceeded 
the investment of effort is lost, and there is only a limited amount of 
effort to invest. When that is the case, a careful evaluation of where 
to invest effort is required.

I dont believe that to be the case here. Even if such an effort would 
have been better made years earlier, that does not preclude it from 
being made now, or even years from now. Benefit can still be realized.


> And, as you noted, for the changes you are suggesting, the IETF
> lists are that away.. ---->
>
>
> Owen
>

There is an intersection. The bits the IETF decides how they are to be 
used are expected to come out of the bits we have to operate with and 
that the registry uses to allocate from.

Joe