NIST IPv6 document

TJ trejrco at
Fri Jan 7 08:30:50 CST 2011

On Thu, Jan 6, 2011 at 21:13, Jeff Wheeler <jsw at> wrote:

> On Thu, Jan 6, 2011 at 8:47 PM, Owen DeLong <owen at> wrote:
> > 1.      Block packets destined for your point-to-point links at your
> >        borders. There's no legitimate reason someone should be
> Most networks do not do this today.  Whether or not that is wise is
> questionable, but I don't think those networks want NDP to be the
> reason they choose to make this change.

Today (IPv4) they may not, but many recommendations for tomorrow (IPv6) are
to use discrete network allocations for your infrastructure (loopbacks and
PtP links, specifically) and to filter traffic destined to those at your
edges ...

> > 3.      Police the ND issue rate on the router. Yes, it means that
> >        an ND attack could prevent some legitimate ND requests
> >        from getting through, but, at least it prevents ND overflow and
> >        the working hosts with existing ND entries continue to function.
> >        In most cases, this will be virtually all of the active hosts on
> >        the network.
> You must understand that policing will not stop the NDCache from
> becoming full almost instantly under an attack.  Since the largest
> existing routers have about 100k entries at most, an attack can fill
> that up in *one second.*
> On some platforms, existing entries must be periodically refreshed by
> actual ARP/NDP exchange.  If they are not refreshed, the entries go
> away, and traffic stops flowing.  This is extremely bad because it can
> break even hosts with constant traffic flows, such as a server or
> infrastructure link to a neighboring router.  Depending on the attack
> PPS and policer configuration, such hosts may remain broken for the
> duration of the attack.
> Implementations differ greatly in this regard.  All of them break
> under an attack.  Every single current implementation breaks in some
> fashion.  It's just a question of how bad.

And I am not saying there isn't a concern here that we should get vendors to
allow us to mitigate, I think we just disagree on the severity of the issue
at hand and the complexity of the solution.


More information about the NANOG mailing list