NIST IPv6 document

Mark Smith nanog at
Fri Jan 7 15:28:20 CST 2011

On Fri, 7 Jan 2011 09:38:32 +0000
"Dobbins, Roland" <rdobbins at> wrote:

> On Jan 7, 2011, at 4:14 PM, Mark Smith wrote:
> > Doesn't this risk already exist in IPv4? 
> There are various vendor knobs/features to ameliorate ARP-level issues in switching gear.  Those same knobs aren't viable in IPv6 due to the way ND/NS work, 

I was commenting on the mentality the OP seemed to be
expressing, about *both* onlink and off link sources triggering address
resolution for lots of non-existent destinations, and that this was a
new and unacceptable threat. I think the offlink risk is a
far more significant one. I think the onlink risk pretty much no worse
than any of the other things that LAN attached devices can do if they
choose to.

> and as you mention, the ND stuff is layer-3-routable.

The issue isn't that ND is layer 3 routable - it isn't unless a router
implementation is broken. The problem is that somebody on the Internet
could send 1000s of UDP packets (i.e. an offlink traffic source)
towards destinations that don't exist on the target subnet. The
upstream router will then perform address resolution, sending ND NSes
for those unknown destinations, and while waiting to see if ND NAs are
returned, will maintain state for each outstanding ND NS. This state is
what is exploitable remotely, unless the state table size is large
enough to hold all possible outstanding ND NA entries for all possible
addresses on the target subnet.

I think this problem can be avoided by getting rid of this offlink
traffic triggered address resolution state. The purpose of the state
(from the Neighbor Discovery RFC) is two fold -

- to allow the ND NS to be resent up to two times if no ND NA response
  is received to ND NSes. A number of triggering packets (e.g. UDP
  ones or TCP SYNs) are queued as well so that they can be resent if and
  when ND NS/NA completes.

- to allow ICMP destination unreachables to be generated if the ND
  NS/NA transaction fails, even after resending.

I think it is acceptable to compromise on these requirements.

ND NS/NA transactions are going to be successful most of the time, so
the ND NS/NA retransmit mechanism is going to be rarely used. Original
traffic sources have to be prepared for it to fail anyway - the
Internet is a best effort network, so if a source node wants to be sure
a packet gets to the original destination it needs to be prepared to
retransmit it. This has actually proved not to be a problem in IPv4 as
Cisco routers have for many years dumped the data packet that triggers
ARP, which I'm pretty sure is the reason why the ARP timeout is 4
hours, rather than the more common 5 minutes. Time outs are pretty much
moot anyway, because active Neighbor Unreachability Detection is
usually performed these days instead of using simple timeouts for
existing ARP entries and is required to be performed by IPv6.

If you don't maintain state for outstanding ND NS transactions, then
that means that the ND NS issuing device will have to just blindly
accept any ND NAs it receives at any time, and put them in the neighbor
cache, assuming they are correct. That is an vulnerability, as a
local node could fill up the neighbor cache with bogus entries, but one
that is far less of a risk than the Internet sourced one we're talking
about, as it is only onlink devices that can exploit it. As a LAN is
already a trusted environment for basic protocol operations, and
devices have a vested interest not disabling other devices that provide
them with services e.g. default routers, I think it is a reasonable and
acceptable risk given those we already accept in LANs, such as the IPv4
ones I mentioned. If it isn't, implement static address
resolution entries, PPPoE, per-device VLANs, SEND etc.

I doubt I need to go into much detail about whether ICMP destination
unreachables need to be reliably received, the reality is that they
aren't in IPv4 and I doubt that will change much in IPv6. I think
they're a "nice to have" not a "need to have".


More information about the NANOG mailing list