[134365] in North American Network Operators' Group
Re: NIST IPv6 document
daemon@ATHENA.MIT.EDU (Iljitsch van Beijnum)
Wed Jan 5 09:39:13 2011
From: Iljitsch van Beijnum <iljitsch@muada.com>
In-Reply-To: <AANLkTim-yTU59z=ALR154fFhtb5RsAoo0XQvMDOGg7KE@mail.gmail.com>
Date: Wed, 5 Jan 2011 15:39:04 +0100
To: Jeff Wheeler <jsw@inconcepts.biz>
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
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.
