Manage Learn to apply best practices and optimize your operations.

How to avoid IPv6 neighbor discovery threats

If you're ready to deploy IPv6, get ready to understand neighbor discovery and its vulnerabilities.

Editor's note: IPv6 neighbor discovery is a core part of the IPv6 protocol suite. It is employed, among other things,...

for IPv6 address resolution and IPv6 stateless address autoconfiguration. This article, the first in a series of tips about IPv6 networks, explores a number of ND-based attacks and illustrates how an open source IPv6 toolkit can enable an IT administrator to assess the effectiveness of any security device meant to mitigate these issues.

IPv6 neighbor discovery (ND), a critical component of the IPv6 protocol suite, is employed by IPv6 nodes for a number of functions:

  • IPv6 address resolution
  • Stateless address autoconfiguration
  • Duplicate address detection
  • Neighbor unreachability detection
IPv6 address resolution consists of mapping the IPv6 address of a neighboring node to the corresponding link-layer address.

IPv6 address resolution consists of mapping the IPv6 address of a neighboring node to the corresponding link-layer address. This is the same function carried out by the Address Resolution Protocol (ARP) in the IPv4 world. Stateless address autoconfiguration (SLAAC) involves finding neighboring routers and obtaining network configuration information to enable IPv6 connectivity. Duplicate address detection (DAD) is a function meant to detect IPv6 address duplication before employing an IPv6 address for network communication. Finally, neighbor unreachability detection (NUD) is employed to assess the reachability of a path to a neighboring node. In the event that node is failing, an alternative path can be employed.

Neighbor Discovery employs Internet Control Message Protocol v6 messages for all of its functions; this differs from ARP, which operates directly on top of the underlying link-layer protocol. While this could be seen as a "cleaner" design choice (ND is thus not tied to any specific link-layer technology), it also has nontrivial implications. For example, any device or technology meant to monitor ND traffic or to mitigate ND-based attacks will have to deal with the flexibility (and associated complexity) of IPv6 packets. For example, IPv6 fragmentation and IPv6 extension headers can prove to be challenging for any ND security or monitoring device or technology.

IPv6 address resolution and how it works

Whenever an IPv6 packet is to be sent on the local link, the IPv6 address of a neighboring node (whether the final destination or an intermediate router) needs to be mapped into the corresponding link-layer address.

The simplest way to play with the address resolution function is to employ the (open source) ndisc6 tool from nDisc6 IPv6 diagnostic tools. The ndisc6 tool simply meshes two functions: the IPv6 address to be resolved and the network interface to be employed to perform the address resolution. For example, one could resolve the IPv6 address fc00:1::1 into the corresponding link-layer address as follows:

Resolving an IPv6 address
Figure 1. Resolving an IPv6 address.

An IPv6 implementation maintains the mappings from IPv6 addresses to link-layer addresses (along with other related information) in a data structure called neighbor discovery cache (which corresponds to the ARP cache from the IPv4 world). Inspecting the neighbor cache can be useful in manually assessing whether a node has incorrect address mappings (possibly as a result of an attack). All IPv6 implementations offer some mechanism or tool to inspect the contents of the neighbor cache. For example, on GNU/Linux systems, the neighbor cache can be inspected with the "ip" command, as follows:

Inspecting the neighbor discovery cache
Figure 2. Inspecting the neighbor discovery cache.

Each line contains an IPv6 address; the network interface on which it's a neighbor; the corresponding link-layer address; a keyword (router) that indicates whether the address corresponds to a router; and a state for this entry (e.g., whether this neighbor is considered reachable or the mapping information is considered stale, etc.).

In BSD-derived operating systems, the contents of the neighbor cache can be inspected with the ndp –a command, as follows:

Inspecting a neighbor cache in a BSD system
Figure 3. Inspecting a neighbor cache in a BSD system.

It should be noted that while the output is slightly different from the Linux case, the information being displayed is essentially the same.

If an attacker were able to introduce illegitimate mappings in the neighbor cache, he would be able to direct local packets to any local node at will and perform man in the middle (MITM) or denial of service (DDoS) attacks. Whether the resulting attack leads to a MITM or DDoS attack depends on the link-layer address to which the victim address is mapped: If the attacker were to map the victim's IPv6 address to his own link-layer address, he would become a MITM. If he were to map the victim's IPv6 address into a nonexistent link-layer address, this would introduce a DDoS situation.

Another diagnostic tool, SI6 Networks' IPv6 Toolkit is a comprehensive, open source IPv6 security assessment and troubleshooting utility that's available for a variety of operating systems (including GNU/Linux, BSD and Mac OS). Among the myriad of tools it includes is the na6 tool, which can be employed to send forged neighbor advertisement (NA) messages.

Na6 can be employed to perform the aforementioned MITM or DDoS attacks. For example, in order to direct all traffic sent to the IPv6 address fc00:1::1 to the link-layer address 11:22:33:44:55:66, an attacker could execute the na6 tool as follows:

na6 -i eth0 -W fc00:1::1 -E 11:22:33:44:55:66 -L -v -o

The effectiveness of the tool in poisoning the victim's ND cache could be assessed by manually inspecting its neighbor cache, as previously illustrated.

As noted above, the use of IPv6 extension headers and/or fragmentation could possibly be leveraged by an attacker to circumvent security controls. Thus, an attacker meaning to evade security devices that fail to process the entire IPv6 header chain could send his malicious NA messages with, for example, one destination options header, as follows:

na6 -i eth0 -W fc00:1::1 -E 11:22:33:44:55:66 -L -v -o

-u 64

It should be obvious that this command simply adds the "-u 64" option to the previous attack command, which inserts a destination options header of 64 bytes right after the mandatory IPv6 header.

Finally, ND messages (including NAs) could, in theory, employ fragmentation. While the use of fragmentation with ND has been prohibited by RFC 6980, outdated implementations might still honor these packets. When assessing an IPv6 network or implementation, one should check whether the use of IPv6 fragmentation with ND can be leveraged to circumvent security controls. Two different test cases are probably warranted: an NA message sent as an IPv6 atomic fragment, and an NA message sent with an oversized IPv6 header chain.

IPv6 atomic fragments, described in RFC 6946, essentially are IPv6 packets that contain an IPv6 fragment header with an offset of 0 and the MF (more fragments) bit set to 0 -- that is, a packet that contains a fragment header but is composed of a single fragment. The na6 tool can be instructed to send the packets as atomic fragments, as follows:

na6 -i eth0 -W fc00:1::1 -E 11:22:33:44:55:66 -L -v -o

-y 500

where the "-y 500" option indicates that the tool should fragment the neighbor advertisement messages in fragments of 500 bytes -- but since the whole NA message is much smaller than 500 bytes, the resulting message will be sent as an atomic fragment.

The second test case is that of an oversized IPv6 header chain. A packet is said to have an oversized IPv6 header chain if the packet is fragmented and the first fragment does not contain all of the protocol headers starting from the mandatory IPv6 header up to (and including) the upper-layer protocol (e.g., a transport protocol header). The following figure illustrates oversized IPv6 header chains.

An oversized IPv6 header chain
Figure 4. An oversized IPv6 header chain.

RFC 7112 describes oversized IPv6 header chains, deprecates them and explicitly allows nodes to drop the corresponding packets, if found. However, outdated IPv6 implementations might still honor these packets, and hence it is not possible to assume that they will be dropped by the victim node. The na6 tool could be employed to send NA messages with an oversized IPv6 header chain as follows:

na6 -i eth0 -W fc00:1::1 -E 11:22:33:44:55:66 -L -v -o

-u 500 -u 100 -y 400

This is essentially the original attack command employed earlier above, with the addition of two destination options headers (one of 500 bytes, and a subsequent header of 100 bytes), and a request to fragment the NA messages into fragments of at most 400 bytes ("-y 400" option). As a result, the first fragment will not be large enough to carry the entire IPv6 header chain, and hence the IPv6 header chain will be split into two fragments.

As part of a security assessment of an IPv6 network, one could perform each of these test cases and assess whether the security controls in place are effective against each of these attack vectors.

Next: SLAAC, duplicate address vulnerabilities and how to guard against them.

About the author:
Fernando Gont currently works for SI6 Networks as an Internet security and engineering consultant. He is an active participant at the IETF (Internet Engineering Task Force), where he contributes to several working groups, and has authored a number of requests for comments and Internet drafts. Gont is a regular speaker at conferences, trade shows and technical meetings, discussing information security, operating systems and Internet engineering. More information is available at his website.

Next Steps

Understanding IPv6 security

Auto-configured addresses raise concerns

Corralling DDoS attacks in IPv6

This was last published in January 2015

Dig Deeper on IP Networking



Find more PRO+ content and other member only offers, here.

Start the conversation

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.