On Thu, Mar 10, 2011 at 1:52 PM, George Bonser <gbonser@seven.com> 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@inconcepts.biz> Sr Network Operator / Innovative Network Concepts