Internet Edge Router replacement - IPv6 route tablesizeconsiderations

George Bonser gbonser at seven.com
Fri Mar 11 03:51:17 UTC 2011


> 
> 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.

And I say making them /127s may not really make any difference.  Say you
make all of those /127s, at some point you *are* going to have a network
someplace that is a /64 that has hosts on it and that one is just as
subject to such an attack.  If you are a content provider, it doesn't
make any difference if they take down the links between your routers or
if they take down the link that your content farm is on.  The end result
is the same.  You have managed to re-arrange the deck chairs.  Have
another squeeze at that water balloon.  

If you are a service provider where practically all of your links are
point to points, sure.

> 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.

Where that is done is primarily on a backbone section of the network and
where I connect to public peering points.  I add static entries for the
specific peers I communicate with.  Yes, it does take a little
maintenance when a peer changes out some gear or moves to a different
port on their gear but that doesn't happen all that often and is a
compromise I am willing to make in exchange for some added protection.
It also protects against someone who I am not peering with on that same
switch fat-fingering an IP address during some maintenance and
accidently configuring their gear with the same IP as someone I *am*
peering with.  I won't even see it if I have a static neighbor (the same
thing is also done with v4 on public peering switches with static ARP
entries, too).

> 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.

Right, if I had dozens of point-to-points with gear that is constantly
changing at the other end, yeah.  I agree.  I might then consider that
approach.  But in this case I can only speak about my own stuff and what
is the best solution for one specific application might not be the best
solution for someone else.  I am not trying to say that this solution is
best for everyone, I am simply pointing out a solution that others might
find useful depending on their application. 

 
> 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.)

Yeah, it's a tough nut to crack.  I do agree that 64-bit host addressing
is just too big.  The reason is that it even allows you to configure
more IPs on a single subnet legitimately than the network gear can
handle.  The notion of "we are going to give you a subnet with 8
bazillion possible addresses, but don't try to use more than half a
million of them or you will melt your network gear" seems quite idiotic,
actually.

So you have a huge address space that you actually can't use much of
(relative to the size of the space) and it creates a stability risk.

We didn't need much more host addressing, we needed more subnet
addressing.  I would have settled for 16 bits of host addressing and 112
bits of subnet addressing and I suppose nothing prevents me from doing
that except none of the standard IPv6 automatic stuff would work
anymore.
 
> 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.

And again, are you talking about all the way down to the host subnet
level?  I suppose I could configure server farms in /112 or even /96
(/96 has some appeal for other reasons mostly having to do with
multicast) but then I would wonder how many bugs that would flush out of
OS v6 stacks.

Something will have to evolve to handle this problem because I agree
with you, it is going to be a major issue at some point.

It might just be as simple as a host doing what amounts to a gratuitous
announcement when an IP is assigned to an interface (and some kind of
withdrawal announcement when the address is removed).  If a packet
arrived from an interface off the host's subnet for an IP address that
is not in the neighbor table at all (even stale ones), then maybe the
router simply drops the packet.  Leave it up to the hosts themselves to
keep their information current on the network even when they aren't
passing traffic. That doesn't protect against rogue hosts but there
might be ways around that, too, or at least limiting the damage a rogue
host can cause.

So any packet arriving on a router for a local subnet, if that address
isn't already in the neighbor table, drop it on the floor or return an
"unreachable" or whatever.

Something will have to be done at some point ... soon.





More information about the NANOG mailing list