Using IPv6 with prefixes shorter than a /64 on a LAN

Douglas Otis dotis at mail-abuse.org
Wed Jan 26 20:36:28 CST 2011


On 1/25/11 6:00 PM, Fernando Gont wrote:
> On 24/01/2011 08:42 p.m., Douglas Otis wrote:
>> It seems efforts related to IP address specific policies are likely
>> doomed by the sheer size of the address space, and to be pedantic, ARP
>> has been replaced with multicast neighbor discovery which dramatically
>> reduces the overall traffic involved.
> This has nothing to do with the number of entries required in the
> Neighbor Cache.
>> Secondly, doesn't Secure Neighbor
>> Discovery implemented at layer 2 fully mitigate these issues?  I too
>> would be interested in hearing from Radia and Fred.
> It need not. Also, think about actual deployment of SEND: for instance,
> last time I checked Windows Vista didn't support it.
First, it should be noted ND over ARP offers ~16M to 2 reduction in 
traffic.  Secondly, services offered within a facility can implement 
Secure Neighbor Discovery, since a local network's data link layer, by 
definition, is isolated from the rest of the Internet. While ICMPv6 
supports ND and SeND using standard IPv6 headers, only stateful ICMPv6 
Packets Too Big messages should be permitted.  Nor is Vista, ISATAP, or 
Teredo wise choices for offering Internet services.  At least there are 
Java implementations of Secure Neighbor Discovery.

When one considers what is needed to defend a facility's resources, 
Secure Neighbor Discovery seems desirable since it offers hardware 
supported defenses from a wide range of threats.  While it is easy to 
understand a desire to keep specific IP addresses organized into small 
segments, such an approach seems at greater risk and more fragile in the 
face of frequent renumbering.  In other words, it seems best to use IPv6 
secure automation whenever possible.

The make before break feature of IPv6 should also remove most 
impediments related to renumbering.  In other words, fears expressed 
about poorly considered address block assignments also seem misplaced.

-Doug






More information about the NANOG mailing list