animind - Fotolia

Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

How to protect your IPv6 address management

Expert Fernando Gont explains how to probe whether your IPv6 address components are vulnerable to attack.

Editor's note: IPv6 neighbor discovery (ND) is a core part of the IPv6 protocol suite. It is employed for IPv6 address resolution and IPv6 stateless address autoconfiguration, among other things. This article, the second in a series of tips about IPv6 network management, explores how some of the various components of IPv6 can be vulnerable to ND-based attacks.

IPv6 nodes are required to implement IPv6 stateless address autoconfiguration (SLAAC). In SLAAC, local routers provide IPv6 network configuration information to local hosts, which employ this information to set up their IPv6 connectivity. This encompasses, among other things, the configuration of an IPv6 address. Unlike Dynamic Host Configuration Protocol version 6, there are no address "leases." Instead, hosts autoconfigure (or "lease") IPv6 addresses themselves. SLAAC employs router solicitation and router advertisement messages to solicit and convey IPv6 network and IPv6 address management configuration information. The address autoconfiguration process works (roughly) as follows:

  1. The host configures a link-local address.
  2. The host checks that the address is unique -- i.e., it performs duplicate address detection (DAD) for that (tentative) address.
  3. The host sends a router solicitation message.
  4. When a router advertisement (RA) is received, the host configures one or more tentative IPv6 addresses for each of the prefixes advertised in the received router advertisement.
  5. The host checks that the address is unique -- i.e., it performs DAD for the tentative address.
  6. If the address is unique, it typically becomes a "preferred" address and can be actively used for network communication.

In essence, this means that a node first configures a link-local IPv6 address, followed by one or more global IPv6 addresses based on the prefix information obtained from RA messages. RA messages may contain other network configuration information that includes IPv6 routes to specific networks, IPv6 addresses of recursive domain name system servers and the maximum transmission unit (i.e., the maximum packet size) to be employed.

Some IPv6 deployments fail to implement validation checks on the information they receive in RA messages, or fail to enforce limits on the size of the corresponding data structures.

For example, some implementations will configure one address per prefix advertised in an RA message, without enforcing any limits on the maximum number of IPv6 addresses they will configure. Thus, an attacker can flood a victim with multiple RA messages that advertise multiple autoconfiguration prefixes, and the victim will autoconfigure so many IPv6 addresses that it will crash or become unresponsive.

To help understand the underpinnings of such an attempt, an IT admin can employ the ra6 tool of the SI6 Networks' IPv6 toolkit to perform this attack, as follows:

ra6 -i eth0 --flood-prefixes 10 -d ff02::1 -l -z 1 -v

This command will send one RA message, containing 10 (randomized) prefixes every second, to all the local nodes. This will cause each node to configure one IPv6 address for each of the randomized prefixes.

In Unix-like systems, the ifconfig command can be employed at any victim node to check the IPv6 addresses that have been autoconfigured.

The ifconfig command can be used to probe autoconfigured addresses
Figure 1. The ifconfig command can be used to probe autoconfigured addresses.

In a real-world attack, of course, the RA messages would be sent at a much higher rate (e.g., at least 100 per second). However, because of the potential of this attack to crash all local nodes, this example has employed a more conservative packet rate for the attack.

All RA messages contain a router lifetime value that indicates for how long the router sending the message can be employed as a default router. Local hosts learn this value from the RA messages and keep track of it by maintaining a local timer. Local routers try to "refresh" the associated timer at the local hosts by sending periodic (unsolicited) RA messages. As a result, in normal scenarios, the router lifetime never expires. An attacker could, however, exploit this timer or parameter for denial of service (DoS) purposes. If an attacker were able to impersonate a local router and send an RA message with a router lifetime of 0 (or some other small value), the victim node(s) would remove the impersonated router from the list of default routers and hence a DoS situation would take place.

Assuming the legitimate local router for a given subnet is fe80::1, an attacker could perform a DoS attack to all the local nodes by employing ra6 as follows:

ra6 -i eth0 -s fe80::1 -d ff02::1 -t 0

Where "-i eth0" specifies the network interface to be employed for launching the attack; "-s fe80::1" specifies the source address of the attack packet (such that the legitimate local router is impersonated); "-d ff02::1" specifies that the attack packet be sent to the "all-nodes link-local multicast address" and "-t 0" sets the "router lifetime" to 0.

The netstat command could then be employed to inspect the routing table at a victim node and confirm that the default route pointing to the node fe80::1 has been removed.

Plugging duplicate address detection leaks

Before an IPv6 address is actively employed for network communication, the address needs to be checked for uniqueness -- this is formally referred to as duplicate address detection. DAD operates roughly as follows:

  • A node willing to use an IPv6 address will send a neighbor solicitation (NS) message for the aforementioned (tentative) address.
  • If a neighbor advertisement (NA) is received in response, the address is considered to be a duplicate, and therefore DAD fails.
  • If no NA message is received for that address (possibly after a number of retransmissions of the NS message), the address is considered unique, and DAD succeeds.

The NS messages corresponding to DAD are sent with the source address set to the unspecified address (::), and hence it's trivial to differentiate them from NS messages meant for address resolution (rather than duplicate address detection).

An attacker can easily perform a DoS attack against local nodes by employing the na6 tool as follows:

na6 -i eth0 -b :: -L -v

This command instructs na6 to listen ("-L") for NS messages that have the source address set to the unspecified address ("-b ::") on the network interface eth0, and respond with an NA when such messages are received. Thus, whenever a node is bootstrapped and tries to autoconfigure an IPv6 address, every address it tries to configure will be considered a duplicate, and thus SLAAC will fail.

The ifconfig command can be employed to inspect the configuration of a victim network interface card, as follows:

Inspecting the configuration of a network interface card
Figure 2. Inspecting the configuration of a network interface card.

There are at least two things to note from the screenshot above. First, the link-local address is marked as "duplicate." Second, there are no global IPv6 addresses configured for this interface -- the reason being that when DAD fails for the tentative link-local address, SLAAC is aborted. As a result, a DoS attack takes place.

Network unreachability detection (NUD), another component of IPv6, consists of testing the path to neighboring nodes to permit an alternative path to be selected if the current one is detected to fail. For the most part, all an attacker can do to compromise NUD is to confuse the protocol to believe that a failing path is working properly.

That vulnerability, compared to the rest of ND-based attacks, isn't that appealing to attackers. As a result, there is little need to be concerned about that tactic.

Next: Mitigating IPv6 neighbor discovery attacks

About the author:
Fernando Gont currently works for SI6 Networks as an Internet security and engineering consultant. He is an active participant at the 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

How to avoid neighbor discovery threats

IPv6: Many addresses, many threats?

This was last published in January 2015

Dig Deeper on Network protocols and standards