IPv6 Security Considerations

IPv6 brings fundamental changes to network addressing and routing — and with those changes come a new set of security challenges. While IPv6 was designed with security improvements over IPv4 (IPsec was originally mandatory, for instance), the protocol also introduces attack surfaces that did not exist in IPv4 networks.

Understanding these vulnerabilities is essential for anyone deploying or managing IPv6-capable networks.

The Expanded Attack Surface of IPv6

IPv6 changes more than just address length. It replaces ARP with NDP, introduces autoconfiguration (SLAAC), eliminates broadcast in favor of multicast, and adds extension headers. Each of these changes brings both capabilities and risks.

Why IPv6 Security Is Often Neglected

Many organizations enable IPv6 by default (Windows, Linux, macOS, Android, and iOS all prefer IPv6 when available) but only actively manage their IPv4 security policies. This creates a dangerous gap: the IPv6 traffic that flows across "IPv4 networks" may bypass firewalls and IDS systems that were never configured to inspect it.

Neighbor Discovery Protocol (NDP) Attacks

In IPv4, ARP resolves IP addresses to MAC addresses. In IPv6, NDP (Neighbor Discovery Protocol) serves this function — and more. NDP handles:

• Address resolution (like ARP)
• Router discovery and prefix announcement
• Duplicate Address Detection (DAD)
• Neighbor Unreachability Detection

Because NDP relies on ICMPv6 messages without built-in authentication, it is vulnerable to several spoofing attacks.

NDP Spoofing (Neighbor Cache Poisoning)

An attacker on the local link can send forged Neighbor Advertisement (NA) messages, claiming that a target IPv6 address maps to the attacker's MAC address. This poisons the neighbor caches of other devices, redirecting traffic to the attacker — equivalent to ARP poisoning in IPv4.

Legitimate:
Victim sends NS: "Who has 2001:db8::1?"
Router replies NA: "2001:db8::1 is at 00:11:22:33:44:55"

Attack:
Attacker sends NA: "2001:db8::1 is at aa:bb:cc:dd:ee:ff" (attacker's MAC)
Victim's neighbor cache is poisoned; traffic to 2001:db8::1 goes to attacker

Defenses: - SEND (Secure Neighbor Discovery, RFC 3971) — Cryptographically signs NDP messages using RSA public keys and Crypto Generated Addresses (CGAs). Prevents spoofing but has significant deployment complexity. - Dynamic ARP Inspection equivalent — Some managed switches support "IPv6 ND inspection" or "IPv6 Snooping" to validate NDP messages against a trusted binding table. - RA Guard (see below) for router-specific attacks.

Rogue Router Advertisement (RA) Attacks

Router Advertisement (RA) messages announce routers and prefixes to hosts, enabling SLAAC autoconfiguration. Any host on the link can send an RA message — there is no built-in mechanism to verify that an RA comes from a legitimate router.

An attacker can send a forged RA claiming to be the default router, redirecting all outbound traffic through their machine. This is a powerful man-in-the-middle vector.

Alternatively, an attacker can send RAs with a very short prefix lifetime or a bogus prefix, disrupting connectivity for all hosts on the segment.

Rogue RA tools such as radvd (misconfigured), fake_router6, and tools in the THC-IPv6 toolkit make this attack trivially easy.

Defenses:

RA Guard (RFC 6105) is the primary defense. Implemented on managed switches or routers, RA Guard:

1. Inspects all ICMPv6 Router Advertisement messages
2. Checks whether the sending port is designated as a "router port"
3. Drops RA messages arriving on non-router ports

Switch configuration example (Cisco IOS):
ipv6 nd raguard policy HOST-PORTS
 device-role host
!
interface GigabitEthernet0/1
 ipv6 nd raguard attach-policy HOST-PORTS

Most enterprise-grade managed switches support RA Guard. Consumer-grade switches do not.

Extension Header Attacks

IPv6 supports extension headers — optional headers that appear between the IPv6 header and the upper-layer protocol header. Extension headers enable features like:

• Hop-by-hop options
• Routing (source routing)
• Fragmentation
• Destination options
• Authentication and ESP (for IPsec)

Extension headers are a legitimate and powerful feature, but they are also a significant attack vector.

Extension Header Evasion

Some firewall implementations examine the first few bytes of an IPv6 packet to determine the upper-layer protocol (TCP, UDP, ICMPv6). If extension headers are present, the upper-layer header is not at a fixed offset, potentially causing the firewall to misidentify or fail to inspect the packet.

An attacker can craft packets with multiple chained extension headers, burying the real payload deep enough that some security devices give up parsing and pass the packet without inspection.

Defense: Use IPv6-aware security devices that fully parse extension header chains. Most modern firewalls and IDS systems (Snort 3, Suricata, Palo Alto, Cisco ASA/FTD) handle extension headers correctly, but verify your specific devices.

Type 0 Routing Header (Deprecated)

The Type 0 Routing Header (RH0) allowed a packet to specify a list of intermediate IPv6 nodes it must traverse — similar to IPv4 loose source routing. This could be exploited to:

• Amplify traffic (bounce a packet through many nodes)
• Bypass access controls by routing around firewalls

RFC 5095 (2007) deprecated RH0. All modern implementations discard packets with RH0. Ensure your network equipment does the same.

Fragmentation Attacks

IPv6 fragmentation is handled only by the originating host (unlike IPv4, where routers can fragment). Attackers can use overlapping fragments or tiny fragments to evade security devices that only inspect the first fragment.

Defense: Block or carefully inspect fragmented IPv6 packets at security boundaries. For most enterprise environments, fragmented IPv6 from external sources is unusual and can be dropped.

Privacy Addressing and Tracking

SLAAC and MAC Address Exposure

The original SLAAC mechanism derives the Interface Identifier (IID) from the device's MAC address using EUI-64 encoding. A device with MAC 00:11:22:33:44:55 would get an IID of 0211:22ff:fe33:4455.

This is a privacy problem: the MAC address is globally unique and embedded in the public IPv6 address, allowing any destination to identify and track the device across networks.

Privacy Addresses (RFC 4941)

RFC 4941 introduced temporary privacy addresses — randomly generated IIDs that change periodically. Modern operating systems generate a temporary address for outbound connections and a stable address for inbound connections (services).

Stable address:  2001:db8:1::/64 + EUI-64 derived ID (for servers)
Temporary:       2001:db8:1::/64 + random 64-bit IID (changes every 24h)

On Linux:

# Check privacy address settings
sysctl net.ipv6.conf.eth0.use_tempaddr
# 2 = prefer temporary address, 1 = generate but don't prefer, 0 = disabled

# Enable privacy extensions
sysctl -w net.ipv6.conf.all.use_tempaddr=2

Stable Privacy Addresses (RFC 7217)

An alternative to full randomization, RFC 7217 generates a stable-per-network IID that does not reveal the MAC address. The IID is derived from a hash of the network prefix, interface name, and a secret key. The address is stable on a given network but changes when the device moves to a different network.

Windows uses RFC 7217 by default since Windows 10. Linux uses it via the stable-privacy mode in systemd-networkd.

IPv6 Firewall Considerations

The Implicit Trust Problem

Many IPv4 environments rely on NAT as a de-facto firewall — internal devices have RFC 1918 addresses that are unreachable from the internet. With IPv6, every device typically has a globally routable address. This means explicit stateful firewall rules are not optional — they are mandatory.

A common mistake is deploying IPv6 connectivity without updating perimeter firewall rules, leaving internal IPv6-addressed devices directly reachable from the internet.

Required ICMPv6 Types

Unlike IPv4, where blocking all ICMP is sometimes considered acceptable, ICMPv6 must not be blocked indiscriminately. Many ICMPv6 types are essential for IPv6 to function:

Blocking ICMPv6 Type 2 (Packet Too Big) breaks Path MTU Discovery, causing mysterious connectivity failures for hosts with large MTUs (common in enterprise environments).

Recommended Perimeter Ruleset

# Allow established/related traffic
pass in proto ipv6 from any to any established

# Allow Packet Too Big (required for PMTUD)
pass in proto ipv6-icmp icmpv6-type 2 from any to any

# Allow Destination Unreachable (specific codes)
pass in proto ipv6-icmp icmpv6-type 1 from any to any

# Block NDP from external (should only be link-local)
block in proto ipv6-icmp icmpv6-type {133,134,135,136} from any to any

# Block RH0 routing headers (deprecated, drop)
block in proto ipv6 from any to any ext-header routing-type 0

# Your inbound service rules
pass in proto tcp from any to 2001:db8::/32 port 443

Dual-Stack Hidden Channels

A classic attack in dual-stack networks: if IPv4 traffic is tightly controlled but IPv6 is not, an attacker can establish an IPv6 channel that bypasses IPv4-based security controls entirely.

This can happen inadvertently — an internal host receives an IPv6 prefix via SLAAC from a rogue RA, establishes IPv6 connectivity to the internet (bypassing the IPv4 proxy/firewall), and leaks data over IPv6.

Defense: 1. Apply equivalent security policies to IPv6 and IPv4 traffic 2. Disable IPv6 on network segments where it is not needed 3. Use RA Guard to prevent rogue RAs 4. Monitor for unexpected IPv6 traffic at network boundaries

Scanning and Reconnaissance in IPv6

The astronomical size of IPv6 address space (2^64 hosts per /64 subnet) makes traditional sequential port scanning impractical. Scanning the entire 2001:db8::/64 would take thousands of years at 1 million packets per second.

However, attackers have adapted:

• Known patterns — EUI-64-derived addresses follow a predictable pattern from MAC OUI ranges
• DNS zone transfer / DNSSEC enumeration — Discovering IPv6 addresses via DNS
• Multicast groups — ff02::1 (all nodes on link) reveals active hosts if ICMP echo is permitted
• DHCPv6 logs — If DHCPv6 is used, server logs reveal all assigned addresses

Defense: Use privacy addresses (RFC 4941/7217) and avoid predictable address patterns. Do not rely on address obscurity as a security control.

Summary: IPv6 Security Checklist

IPv6 security is not fundamentally harder than IPv4 security, but it requires deliberate attention. The most dangerous posture is deploying IPv6 connectivity without updating security policies — leaving a wide-open path through an assumed-to-be-controlled perimeter.