I suppose router operating as proxy ND (similarly to local proxy ARP in IPv4) can mitigate the threat as well. it is mentioned in 'DOCSIS 3.0 Requirements for IPv6 support' (http://tools.ietf.org/html/draft-mule-cablelabs-docsis3-ipv6-00).
Dmitry Cherkasov 2011/11/29 Jonathan Lassoff <[email protected]>: > On Mon, Nov 28, 2011 at 10:43 PM, <[email protected]> wrote: > >> On Tue, 29 Nov 2011 00:15:02 EST, Jeff Wheeler said: >> >> > Owen and I have discussed this in great detail off-list. Nearly every >> > time this topic comes up, he posts in public that neighbor table >> > exhaustion is a non-issue. I thought I'd mention that his plan for >> > handling neighbor table attacks against his networks is whack-a-mole. >> > That's right, wait for customer services to break, then have NOC guys >> > attempt to clear tables, filter traffic, or disable services; and >> > repeat that if the attacker is determined or going after his network >> > rather than one of his downstream customers. >> >> It's worked for us since 1997. We've had bigger problems with IPv4 worms >> that >> decided to probe in multicast address space for their next target, causing >> CPU >> exhaustion on routers as they try to set up zillions of multicast groups. >> >> Sure, it's a consideration. But how many sites are *actually* getting hit >> with this, compared to all the *other* DDOS stuff that's going on? I'm >> willing >> to bet a large pizza with everything but anchovies that out in the *real* >> world, 50-75 times as many (if not more) sites are getting hit with IPv4 >> DDoS attacks that they weren't prepared for than are seeing this one >> particular neighbor table exhaustion attack. >> >> Any of the guys with actual DDoS numbers want to weigh in? >> > > Agreed. While I don't have any good numbers that I can publicly offer up, > it also intuitively makes sense that there's a greater proportion of IPv4 > DDOS and resource exhaustion attacks vs IPv6 ones. > Especially on the "distributed" part; there's a heck of lot more v4-only > hosts to be 0wned and botnet'ed than dual-stacked ones. > > That said, I think the risk of putting a /64 on a point-to-point link is > much greater than compared to a (incredibly wasteful) v4 /24 on a > point-to-point. Instead of ~254 IPs one can destinate traffic towards (to > cause a ARP neighbor discovery process), there's now ~18446744073709551614 > addresses one can cause a router to start sending ICMPv6 messages for. > > For links that will only ever be point-to-point, there's no good reason > (that I know of) to not use a /127. For peering LANs or places that have a > handful of routers, /112's are cute, but I would think the risk is then > comparable to a /64 (which has the added benefit of SLAAC). > > I imagine the mitigation strategies are similar for both cases though: just > rate-limit how often your router will attempt neighbor discovery. Are there > other methods? > > Cheers, > jof
