IPv6 First-Hop Security Concerns


There are a growing number of large-scale IPv6 deployments occurring within enterprise, university, and government networks. For these networks to succeed, it is important that the IPv6 deployments are secure and the quality of service (QoS) must rival the existing IPv4 infrastructure. An important security aspect to consider is the local links (Layer 2). Traditional Layer 2 security differs between IPv4 and IPv6 because of the functionality in Layer 2 operations. This paper identifies the threats to IPv6 first-hop security (FHS). Mitigations are outside the scope of this document.


Network users expect functional parity between IPv4 and IPv6 networks including security and quality of service (QoS). Network administrators maintain similar expectations and assume that both environments are secure with a high degree of traceability and quality assurance. However, those assumptions do not hold true for link operations. Link operations are contained within the link boundaries. It is necessary for a node to communicate with its neighbors, including the link exit points. Link operations encompass address configuration parameters, address initialization/allocation resolution, default gateway discovery, local network configuration, and neighbor reachability tracking.

IPv6 introduces a new set of technology link operations paradigms that differ significantly from IPv4. For example, IPv6 introduces changes to the network topology infrastructure because threats often align with topology. The changes include more end nodes permitted on the link (up to 264) and increased neighbor cache size on end nodes and the default router, which creates more opportunities for denial of service (DoS) attacks.

In addition to the topology changes, there are additional threats to consider in IPv6 including threats with the protocols in use:

  • Neighbor Discovery Protocol (NDP) integrates all link operations that determine address assignment, router discovery, and associated tasks.
  • Dynamic Host Configuration Protocol (DHCP) can have a lesser role in address assignment compared to IPv4.

Finally, non-centralized address assignment in IPv6 creates challenges for controlling address misuse by malicious hosts.

Because of the increase in IPv6 technology and the intrinsic differences between IPv4 and IPv6 outlined previously, it is important to have secure environments in both IPv4 and IPv6. This paper will help identify first-hop security (FHS) concerns for the IPv6 infrastructure when connecting systems to a network link. A subsequent white paper will provide mitigations for the threats identified in this paper.


This section indentifies the IPv6 FHS concerns associated with Router Discovery, Neighbor Discovery, and DHCPv6. Each concern has a dedicated section that summarizes the threat and provides figures to help illustrate the steps involved in an attack.

Router Discovery-Related Concerns

Router Discovery, new to IPv6 and defined in RFC 4861 Neighbor Discovery for IPv6, is a means for hosts to locate routers that reside on an attached link; however, it has some FHS concerns. RFC 4861 resolves other link-local specific problems including Router Discovery, Prefix Discovery, stateless address autoconfiguration (SLAAC), IPv6 address resolution (replaces IPv4 ARP), Neighbor Unreachability Detection (NUD), Duplicate Address Detection (DAD), and redirection.

Router Discovery

IPv6 Neighbor Discovery uses ICMPv6 messages and relies heavily on multicast (including Layer 2 multicast). In this scenario, host A is attempting to discover routers in its link via Router Discovery. It sends an ICMPv6 router solicitation message requesting information for the routers in its local link. A legitimate router, shown as RTR, responds with an ICMPv6 router advertisement for a lifetime x that lets host A know that it is the router in the link. In turn, host A installs a default route to its routing table that points to RTR for x time.

If an intruder, shown as host T, manages to install itself in the link, host T could attempt to insert itself as a default router in the routing table of host A. To do that, host T can spoof a new router advertisement to host A from RTR and set the lifetime to 2 hours. According to RFC 4862, "If RemainingLifetime is less than or equal to 2 hours, ignore the Prefix Information option with regard to the valid lifetime, unless the Router Advertisement from which this option was obtained has been authenticated." Host A will remove the installed default route that points to RTR after 2 hours. Host T is then free to send another router advertisement inserting itself as the default route for host A. If host T succeeds in becoming the default route, it can see all traffic from host A that is using its default route, and may gain additional information or deploy other types of attacks (for example, a man-in-the-middle attack). Figure 1 illustrates the steps involved in deploying a Router Discovery attack.

Figure 1. Attack against IPv6 Router Discovery

Stateless Address Autoconfiguration

IPv6 stateless address autoconfiguration (SLAAC), defined in IETF RFC 4862, is a mechanism that enables an IPv6 endpoint to get an IPv6 address from the link it is coming up on without requiring DHCPv6 address allocation.

IPv6 address autoconfiguration is stateless; therefore, it does not require a mechanism to track the address allocations before it assigns a new address. The allocation occurs based on the IPv6 prefix information provided by ICMPv6 router advertisements. When host A needs to receive an IPv6 address, it sends an ICMPv6 router solicitation requesting the link information. RTR responds with an ICMPv6 router advertisement that provides the IPv6 address prefix (shown as 2001:DB8:600D::/64) on the link and a lifetime x for it. Then host A can pick an address (shown as 2001:DB8:600D::A) on the link and, after it checks its availability (see Duplicate Address Detection ), it can begin using it.

If malicious host T manages to insert itself in the link, it could spoof an ICMPv6 router advertisement from RTR that sets the lifetime for the link to 2 hours. According to RFC 4862, "If RemainingLifetime is less than or equal to 2 hours, ignore the Prefix Information option with regards to the valid lifetime, unless the Router Advertisement from which this option was obtained has been authenticated". That would cause the host A address to expire in 2 hours, and host T could then send a new router advertisement with a new prefix (shown as 2001:DB8:BAD::/64). Upon seeing the new prefix, host A will pick a new address (shown as 2001:DB8:BAD::A). Depending on the network configuration, the RTR ACLs may deny the new address from traversing the network; therefore, host A could be blocked from accessing beyond the next hop router, or even its link-local peers. If IPv6 address autoconfiguration is used and FHS protection is not employed, host T could potentially blackhole hosts in its local link by spoofing two IPv6 router advertisements. Figure 2 illustrates the steps involved in deploying the IPv6 address autoconfiguration attack.

Figure 2. Attack against IPv6 Auto-Configuration

Neighbor Discovery-Related Concerns

Neighbor Discovery is equivalent to Router Discovery but for hosts. It performs operations such as address resolution, Duplicate Address Detection (DAD), Neighbor Unreachability (NUD), and redirection. As with Router Discovery, in IPv6 there are also Neighbor Discovery ICMPv6 messages that are responsible for network discovery. They are ICMPv6 Neighbor Solicitation (NS) and Neighbor Advertisement (NA). This section describes concerns related to Neighbor Discovery.

Address Resolution

Address resolution is the process that an endpoint (shown as host A) follows when it wants to forward a packet to another endpoint (shown as host B) in the local link when it does not know its Layer 2 address. Host A resolves the IP address of host B into a MAC address and then forwards the packet by setting the host B MAC address as the Layer 2 frame's destination MAC.

In IPv4, Address Resolution Protocol (ARP) is responsible for address resolution; however, in IPv6, ICMPv6 is responsible for that service. In figure 3, Host A sends an ICMPv6 NS requesting the link-layer address for host B. When host B sends an ICMPv6 NA response, host A knows the MAC address that it will use to send the frame. At the same time, host A creates a neighbor cache entry for host B that binds the MAC for host B to its IPv6 address (similar to the ARP table in IPv4).

If malicious host T manages to insert itself in the link, it could impersonate host B and, in turn, intercept all packets that were originally destined for host B. Therefore, if proper FHS protections are not employed, host B can perform a man-in-the-middle attack or intercept traffic. Figure 3 illustrates the steps involved in deploying an address resolution attack.

Figure 3. Attack against IPv6 Address Resolution.

Duplicate Address Detection

Duplicate Address Detection (DAD) is a protocol in IPv6 that enables an endpoint to verify the uniqueness of an address. In essence, it is a probe message that the host sends to verify other hosts have not claimed the address. Figure 4 illustrates the steps involved in deploying a duplicate address attack. In IPv6, when host A wants to perform DAD it sends an ICMPv6 NS for the address it wants to claim (for example, 2001:DB8:600D::A). If other hosts do not respond with an ICMP NA stating the address has been taken, then host A is able to use the address.

In this scenario, DAD can be susceptible to attacks by malicious host T, which wants to prevent host A from receiving an IPv6 address. When host A sends its NS for 2001:DB8:600D::A, host T can then send an NA stating that the address is taken. If host A tries to claim another address (for example, 2001:DB8:600D::AA), host T can send an NS and claim it. Essentially, host T can claim every address that host A performs DAD and prevent host A from getting an IPv6 address to communicate with the network. Figure 4 illustrates the steps involved in deploying a duplicate address attack.

Figure 4: Attack against IPv6 Duplicate Address Detection (DAD)

Neighbor Cache

When performing address resolution after receiving the ICMPv6 NA, host A creates a neighbor cache entry for the IP address it resolved to the host B MAC address. Given the size of the local link address pool, a host's neighbor cache can significantly increase in relation to the ARP table size in IPv4. In IPv6, the interface identifier of an address is 64-bits long, which means there could be as many as 264 hosts on the link, and thus, potentially 264 neighbor cache entries.

In this scenario, malicious host T can attack the neighbor cache of a host or routing device and attempt to fill it or cause a DoS condition. Let us assume that host T knows that RTR is connected to its link and to a link with hosts in the 2001:DB8:600D::/64 prefix. Host T can start scanning 2001:DB8:600D::/64 by sending a packet to the hosts one by one. Regardless of whether the destination host is present on the link, RTR will attempt to resolve their IPv6 addresses to forward the frame that is destined to them. For example, even if host 2001:DB8:600D::A is not on the link, while resolving it, RTR will create a cache entry that will be incomplete and remain in the RTR neighbor cache for a few seconds until it times out. Thus, if host T was fast enough and able to scan a large portion of the 264 hosts within a few seconds, it could succeed at filling the RTR cache entry and cause a DoS condition. Figure 5 illustrates the steps involved in deploying a neighbor cache attack.

Figure 5. Neighbor Cache attack

Note: The attack on the RTR neighbor cache does not require host T to be local to the RTR. If host T knows the links directly connected to RTR, it could launch the attack remotely.

DHCPv6 Concerns

In 2003, the IETF defined DHCPv6 in its RFC 3315. As in IPv4 DHCP, DHCPv6 describes how a host that comes up can acquire an IPv6 address and other configuration options from a server that is available on its local link. DHCPv6 is described as a stateful protocol that has compatibility with stateless address autoconfiguration as a design requirement. In other words, DHCPv6 can operate in a stateless fashion where it provides configuration information to nodes and does not perform address assignments (RFC 3736). In addition, it can operate in a stateful manner, where it assigns IPv6 addresses and configuration information to hosts that request it.

As in IPv4 DHCP, DHCPv6 is susceptible to rogue server attacks. In other words, if DHCPv6 was used to provide IPv6 addresses to the hosts, an attacker that managed to insert a rogue DHCPv6 server in the link could potentially assign addresses and configuration options to the link hosts as he wished. In turn, the attacker could deploy man-in-the-middle, traffic interception, or blackhole traffic, similar to those in the stateless address autoconfiguration scenario. Thus, it is important to use DHCP protections for both IPv4 and IPv6.


In conclusion, security has become one of the most popular subjects of IPv6 discussions. In particular, IPv6 raises a number of FHS concerns that were not present in IPv4. Those concerns stem from the protocol's unique manner in which it performs router and neighbor discovery, address assignment, and address resolution. These mechanisms could allow an attacker to deploy attacks such as traffic interception, DoS, or man-in-the-middle. Clearly, FHS should not be neglected and appropriate protection mechanisms should be employed when possible. Mitigation mechanisms for FHS concerns will be presented in a subsequent white paper.


Panos Kampanakis (pkampana[at]cisco[dot]com)
Cisco Applied Intelligence Engineer


IPv6 First Hop Security—Protecting Your IPv6 Access Network

Implementing First Hop Security in IPv6

IPv6 First Hop Security—Protecting Your IPv6 Access Network Whitepaper

IETF RFC 4861 Neighbor Discovery for IP version 6 (IPv6)

IETF RFC 5942 IPv6 Subnet Model: The Relationship between Links and Subnet Prefixes

IETF RFC 3315 Dynamic Host Configuration Protocol for IPv6 (DHCPv6)

IETF RFC 6104 Rogue IPv6 Router Advertisement Problem Statement

Book: IPv6 Security by Scott Hogg, Eric Vyncke, Cisco Press (2008)

This document is part of Cisco Security Intelligence Operations.

This document is provided on an "as is" basis and does not imply any kind of guarantee or warranty, including the warranties of merchantability or fitness for a particular use. Your use of the information on the document or materials linked from the document is at your own risk. Cisco reserves the right to change or update this document at any time.

Back to Top

Cisco Security Intelligence Operations