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

[Leo Bicknell]

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.

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.

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.

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.

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.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20101011/a42ac410/attachment.sig>