On 4 feb 2011, at 22:02, Dave Cardwell wrote: > Without wanting to get into whether NAT provides security to hosts > that exist on the inside. I am curious if the potential to overflow > ND caches with incomplete* entries exists on currently shipping CPE > hardware and if NAT helps prevent this?
> e.g. > In v4 with a /24 on the inside an attacker can send a single packet to > each consecutive address causing at most 254 arp requests to be sent > on the lan segment and upto 253 incomplete entries, until they > timeout. > In v6 with a /64 on the inside it seems like the same tactic would > lead to more outstanding ND requests than any realistically sized > cache would support. Ok, I had a hard time making up my mind whether a sarcastic or a factual response was in order... This is of course a very big problem, and one of the reasons why everyone who's tried IPv6 immediately turns it off again: script kiddies are continuously scanning the entire IPv6 address space so this happens to regular IPv6 users all the time. Since this is a problem that is inherent to the ND protocol that is impossible to fix without modifying the IPv6 standards significantly, the easiest way to solve this with the least amount of impact to applications, the ability to host services and the end-to-end model in particular is to use a single public IPv6 address and NAT all local stuff behind it. (BTW, there have been some discussions on NAT66 in the IETF, but that wouldn't be a port overloading 1-to-many NAT, but rather a 1-to-1 NAT, because with IPv6, there obviously isn't any reason to use address sharing. The thinking is that such a 1-to-1 NAT is less harmful than a port overloading 1-to-many NAT so it would be beneficial to specify the former to avoid the latter. But many people within the IETF don't support that strategy.)
