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

[Owen DeLong]

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

> In a message written on Sun, Oct 10, 2010 at 04:55:29PM -0700, Owen DeLong wrote:
>> SLAAC is useful in a routed managed environment. APIPA is _NOT_ anywhere near suitable
>> as a  replacement.
> 
> History begs to differ.
> 
> Back in the day there was this protocol called Appletalk.  It used
> a 2 byte network number, and a one byte node number.  The network
> number was learned from the routers in a procedure not unlike IPv6's
> to learn the network number.  The node number though was chosen
> entirely at random.  If there was a collision, the system chose
> again, repeating until it had a free number.
> 
Yes... However...

> I won't hold Appletalk up as a shining example of anything, but
> there were some large deployments using a APIPA style random
> assignment, using a very small number space, which worked just fine.
> 
Did you ever maintain one of these large deployments? The statement
"worked just fine" is only true for a definition of "worked just fine" that
is acceptable to the average user of Windows 3.1.1. History begs
to differ with a more common definition of the term "works just fine".

> 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.

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.

> The result is that even giving 16 bits of subnet to the home 6rd
> now fits in a /32 (128 - 48 - 16 - 32).  More importantly, an ISP
> will only have in its routing table the portions of that /32
> corresponding to their IPv4 infrastructure; all of the rest of it
> can be used normally as native IPv6.  While this may mean a few of
> the larger ISP's need more IPv6 space, for a lot of the smaller
> guys they will have more than they need.
> 
No, actually, due to the limitations of how the routing/autotunneling
works in a stateless manner, those addresses can't easily be
re-used for native IPv6. It's sad, but, true.

ANY IPv6 address containing the ISPs defined 6rd prefix will
be automatically encapsulated by the CPE into an IPv4 packet
with the destination address corresponding to the embedded
IPv4 address contained in the IPv6 packet.

> I realize this isn't the IETF list, but we keep trying to "fix"
> problems with the 64 bits on the left side of the address, and that
> still rubs me the wrong way.  Already ISP's have found why using a
> /64 on your P2P interfaces is a bad idea and are using /126's and
> /127's.  I find it hard to believe that advertising the prefix
> length with the prefix would be that much harder, and could allow
> flexability to solve most of these issues.
> 
I know of at least one ISP that I think is undeniably a major ISP,
especially in IPv6 that is not having any problem whatsoever with
our /64 PTP links.

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


Owen