NIST IPv6 document

Wed Jan 5 14:39:04 UTC 2011

On 5 jan 2011, at 13:21, Jeff Wheeler wrote:

> customers may be driven to expect a /64, or
> even believe it is necessary for proper functioning.

RFC 3513 says:

   For all unicast addresses, except those that start with binary value
   000, Interface IDs are required to be 64 bits long and to be
   constructed in Modified EUI-64 format.

Nobody has been able or willing to tell why that's in there, though.

All the same, beware of the anycast addresses if you want to use a smaller block for point-to-point and for LANs, you break stateless autoconfig and very likely terminally confuse DHCPv6 if your prefix length isn't /64.

> This is one
> that a lot of smart people agree is a serious design flaw in any IPv6
> network where /64 LANs are used

It's not a design flaw, it's an implementation flaw. The same one that's in ARP (or maybe RFC 894 wasn't published on april first by accident after all). And the internet managed to survive.

A (relatively) easy way to avoid this problem is to either use a stateful firewall that only allows internally initiated sessions, or a filter that lists only addresses that are known to be in use.

> and yet, vendors are not doing anything about it.

Then don't give them your business.

And maybe a nice demonstration on stage at a NANOG meeting will help a bit?

> In addition, if you design your network around /64 LANs, and
> especially if you take misguided security-by-obscurity advice and
> randomize your host addresses so they can't be found in a practical
> time by scanning, you may have a very difficult time if the ultimate
> solution to this must be to change the typical subnet size from /64 to
> something that can fit within a practical NDP/ARP table.

Sparse subnets in IPv6 are a feature, not a bug. They're not going to go away.