[134386] in North American Network Operators' Group
Re: NIST IPv6 document
daemon@ATHENA.MIT.EDU (Richard Barnes)
Wed Jan 5 12:37:19 2011
In-Reply-To: <AANLkTi=MWLXPJQHQ3oLwFLkFYiZMZZ6rfB+GczrkvR2A@mail.gmail.com>
Date: Wed, 5 Jan 2011 12:36:40 -0500
From: Richard Barnes <richard.barnes@gmail.com>
To: Jeff Wheeler <jsw@inconcepts.biz>
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
> IPv6) I can scan your v6 /64 subnet, and your router will have to send
> out NDP NS for every host I scan. =A0If it requires "incomplete" entries
> in its table, I will use them all up, and NDP learning will be broken.
> =A0Typically, this breaks not just on that interface, but on the entire
> router. =A0This is much worse than the v4/ARP sitation.
I'm guessing you're referring to this paragraph of RFC 4861:
"
When a node has a unicast packet to send to a neighbor, but does not
know the neighbor's link-layer address, it performs address
resolution. For multicast-capable interfaces, this entails creating
a Neighbor Cache entry in the INCOMPLETE state and transmitting a
Neighbor Solicitation message targeted at the neighbor. The
solicitation is sent to the solicited-node multicast address
corresponding to the target address.
"
<http://tools.ietf.org/html/rfc4861#section-7.2.2>
It's worth noting that nothing in this paragraph is normative (there's
no RFC 2119 language), so implementations are free to ignore it. I
haven't read the NIST document, but it wouldn't conflict with the RFC
if they recommended ignoring this paragraph and just relying on the ND
cache they already have when a packet arrives.
--Richard
