Internet Edge Router replacement - IPv6 route table sizeconsiderations

Jeff Wheeler jsw at
Thu Mar 10 19:28:11 CST 2011

On Thu, Mar 10, 2011 at 1:52 PM, George Bonser <gbonser at> wrote:
> What I have done on point to points and small subnets between routers is
> to simply make static neighbor entries.  That eliminates any neighbor
> table exhaustion causing the desired neighbors to become unreachable.  I
> also do the same with neighbors at public peering points.  Yes, that
> comes at the cost of having to reconfigure the entry if a MAC address
> changes, but that doesn't happen often.

I wouldn't bet on the router evicting a maliciously-learned dynamic
NDP entry to install a static NDP entry when an interface flaps up,
and if it doesn't, I wouldn't bet on that static NDP entry ever being
installed until the interface flaps again.  Remember, there are
several possible attack methods here, one of which is a compromised or
badly broken box on a connected LAN.

As Richard points out, there is *no* reason to configure /64s on
point-to-point links, and there are obvious disadvantages.  The "RFC
wavers" are downright stupid to suggest otherwise.

As for IXP LANs, I predict that one of two things will happen: either
one or more major IXPs will be subject to NDP DoS and will decide to
shrink their subnet size, allowing others to follow suit; or vendors
will make NDP inspection work and be configurable enough to prevent
most problems.  Again, Cisco has already added a knob to some
platforms which allows you to steer the failure mode.  Interfaces will
fail regardless of what you do; the Cisco knob just lets you decide to
break NDP on only the interface(s) subject to attack instead of on the
entire box.  In any case, I don't judge static NDP entries on IXP LANs
to be a practical long-term solution.  There are obvious disadvantages
to that.

If your network is entirely made up of backbone routers with fairly
static neighbors, your strategy can certainly work with a bit of extra
effort and a vendor box that doesn't do entirely crazy things.

If you have customers (those pesky customers!) they may not be so
comfortable having to open a ticket and feel like they are
troubleshooting a problem you've caused them because you have
configured a static NDP entry facing them.  If you have hosting
customers with servers attached to VLANs, especially in a VPS
environment where IP/MAC associations may routinely change ... good
luck with those static NDP entries.

Obviously, some folks will continue to cite "standards" for something
which was developed in 1997 and still isn't really working, or claim
their own "fix" works, until they get actual IPv6 customers.  Those
folks are probably choosing to redesign their access layer in the
future, *AFTER* they already have customers.

I have been talking to smart people about this problem for nearly ten
years, and I have never heard a practical solution that doesn't
involve some kind of persistent "sticky NDP" which refuses to make
discovery requests to the LAN for addresses which have never been seen
from the LAN.  I've also never seen a practical idea for preventing
malicious hosts on the LAN from filling the table that doesn't involve
NDP inspection at the access port, some kind of database (e.g.
RADIUS/etc) or additional configuration in the router, or proposals
that would simply change the failure mode (e.g. rate-limit knobs.)

You'll notice that there have been several discussions about this on
NANOG and other mailing lists, most of which include some "RFC
wavers," some people saying "the sky is falling," and some guys
in-between who think their vendor's box will fail gracefully or that
NDP learning not functioning for some or all interfaces is not bad as
long as the box doesn't evict busy entries.  I suggest all the folks
in the middle ask themselves why Cisco added a knob *just to control
the failure mode.*  This is a real problem, and the current, practical
fix is simply to not configure /64.

Jeff S Wheeler <jsw at>
Sr Network Operator  /  Innovative Network Concepts

More information about the NANOG mailing list