IPv6 /64 links (was Re: ipv6 book recommendations?)
Alexandru Petrescu
alexandru.petrescu at gmail.com
Tue Jun 19 15:48:08 UTC 2012
Le 07/06/2012 22:27, Ricky Beam a écrit :
> On Wed, 06 Jun 2012 10:58:05 -0400, Chuck Church
> <chuckchurch at gmail.com> wrote:
>> Does anyone know the reason /64 was proposed as the size for all L2
>> domains?
>
> There is one, and only one, reason for the ::/64 split: SLAAC. IPv6
> is a classless addressing system. You can make your LAN ::/117 if
> you want to; SLAAC will not work there.
SLAAC could work with ::/117 but not on Ethernet and its keen. There
are many other links than Ethernet and IEEE.
Nothing (no RFC) prohibits SLAAC with something longer than 64, provided
a means to form an Interfac Identifier for that particular link is
provided. I.e. a new document that specifies e.g. IPv6-over-LTE
(replace LTE with something non-IEEE).
Alex
>
> The reason the requirement is (currently) 64 is to accomodate EUI-64
> hardware addresses -- firewire, bluetooth, fibre channel, etc.
> Originally, SLAAC was designed for ethernet and its 48bit hardware
> address. (required LAN mask was ::/80.) The purpose wasn't to put
> the whole internet into one LAN. It was to make address selection
> "brainless", esp. for embeded systems with limited memory/cpu/etc...
> they can form an address by simply appending their MAC to the
> prefix, and be 99.99999% sure it won't be in use. (i.e. no DAD
> required.) However, that was optimizing a problem that never existed
> -- existing tiny systems of the day were never destined to have an
> IPv6 stack, "modern" IPv6 hardware can select an address and perform
> DAD efficiently in well under 1K. (which is noise vs. the size of the
> rest of the IPv6 stack.)
>
> SLAAC has been a flawed idea from the first letter... if for no other
> reason than it makes people think "64bit network + 64bit host" --
> and that is absolutely wrong. (one cannot make such assumptions about
> networks they do not control. it's even worse when people design
> hardware thinking that.)
>
> --Ricky
>
>
>
More information about the NANOG
mailing list