One of the first problems facing any layer three protocol is address resolution. Given an IP packet, how to deliver that to an Ethernet interface?
IPv6 uses a protocol called the Neighbor Discovery Protocol (NDP) to do address resolution, among other things. Neighbor Discovery (ND) uses multicast to a small set of similar addresses rather than a broadcast to all, but in broad terms is very similar to IPv4's ARP. The router builds a cache of layer three to layer two mappings. For new destination IPv6 addresses the router sets up a new cache entry, sends out an ND solicitation, and waits for the desired host to respond with its layer two address. If the router receives no response within a certain time, it discards the cache entry; otherwise it completes the cache entry and can then use it to deliver packets to that destination IPv6 address.
If someone sends lots of packets for non-existent IPv6 addresses, the router will end up with lots of incomplete cache entries. If enough such packets are received fast enough, all available cache slots may be used up, meaning that no new addresses can be reached. Since completed cache entries time out after a little while, even good entries may be dropped, to be replaced by new never-to-be-completed entries. Unlike most other NDP-related attacks, this one can come from outside your network. It doesn't take much bandwidth either – timing out an incomplete cache entry takes about four seconds; in four seconds a gigabit link can deliver more than enough packets to be a problem.
Sadly there is no real defence yet. Bad packets are indistinguishable from good packets; the router can't tell that an address doesn't exist unless it does neighbor discovery on it. The simple defence of having a big enough cache to handle the load is not feasible with IPv6, where just a single subnet has billions of possible addresses. You can mitigate the problem by doing things like using small subnets, filtering packets at your border, rate limiting and so forth, but the real defence lies in sophisticated cache management in the routers.
Another NDP issue is rogue router advertisements. Setting up an IPv6 “router” is trivial on any modern desktop or laptop. An on-link host sending unwanted router advertisements can cause havoc – deprecating prefixes, redirecting traffic and so on.
There are two solutions in the wings, but neither is complete or robust yet. The first is Secure Neighbor Discovery, or SEND. SEND uses cryptographically generated addresses and signed NDP messages, guaranteeing that the apparent sender of an NDP message is in fact the sender. Combined with a mechanism for distributing certificates (a PKI), SEND is a solution to rogue RAs; without a PKI, it is not. SEND is a moderately heavyweight solution, but a bigger issue is that neither Windows nor OSX currently support SEND.
A second solution is RA-Guard. RA-Guard is (conceptually) a piece of software that sits at a security border such as a switch, and inspects passing RA messages. If they meet certain criteria, RA-Guard lets them pass. If they do not, RA-Guard blocks them. This sounds simple enough, but it turns out that IPv6 throws a few curve balls – current implementations get confused by extension headers, for example. Fixing this means either redefining the NDP protocol to forbid extension headers, or building lots of wire-speed layer three smarts into switches.
Karl Auer is technical manager at IPv6Now, a company specialising in helping organisations get into and get the most out of IPv6. This is the third in a four-part series of articles on IPv6 security issues.