IPv6 Security Guide: Router Advertisements and DHCPv6

Most networks that believe they are IPv4-only are running IPv6 anyway, because every modern operating system enables it by default and will trust the first router advertisement or DHCPv6 reply it hears. That gap lets anyone on a local segment become a default router or DNS server for nearby hosts, often without touching IPv4 at all. This guide covers Neighbor Discovery, SLAAC and DHCPv6, rogue router advertisement and DHCPv6 attacks, IPv6 first hop security (RA Guard, DHCPv6 Guard, SAVI), extension headers and ICMPv6 filtering, tunnelling, address scanning, dual-stack monitoring and a rollout plan. It is for network engineers, Windows and Active Directory administrators, and SOC teams, whether IPv6 is a deliberate deployment or something they have never switched off.

Key takeaways

• Dual stack is the default, not a project. RFC 9099 notes "all host operating systems have IPv6 enabled by default", so IPv4-only networks can still be attacked over IPv6 through rogue router advertisements or DHCPv6.
• First hop security is the core control. RA Guard (RFC 6105) and DHCPv6 Guard or Shield (RFC 7610) on access switches and wireless controllers stop most local IPv6 attacks, provided they drop fragmented packets that hide the header chain (RFC 7113).
• Do not unbind IPv6 on Windows. Microsoft says unbinding "can result in an unsupported Windows configuration" and recommends "Prefer IPv4 over IPv6" instead of disabling; if you must disable, use the DisabledComponents registry value.
• Parity with IPv4 is the policy test. NSA guidance says every IPv4 security mechanism needs an IPv6 counterpart: firewall rules, ACLs, logging, IDS and DNS filtering all have to see both protocols.
• ICMPv6 cannot be blocked wholesale. Neighbor Discovery and Packet Too Big are required for IPv6 to work, so filter ICMPv6 by type following RFC 4890.

Why IPv6 is already on your network

IPv6 adoption is no longer optional for many organisations. US OMB memorandum M-21-07 (19 November 2020) set targets for federal agencies of at least 20% of IP-enabled assets IPv6-only by the end of FY2023, 50% by FY2024 and 80% by FY2025, and requires agencies to "Identify and justify Federal information systems that cannot be converted to use IPv6." Mobile carriers and cloud providers already run large IPv6 estates, so IPv6 transition and IPv6 migration work reaches most enterprises through suppliers even when nobody plans it.

The security problem is that IPv6 readiness usually lags IPv6 presence. Hosts form link-local addresses (fe80::/10) on every interface, listen for router advertisements and send DHCPv6 requests whether or not the network offers IPv6. NSA's IPv6 Security Guidance (January 2023) puts it plainly: "Dual stacked networks (that run both IPv4 and IPv6 simultaneously) have additional security concerns", because controls built for IPv4 do not automatically cover the second protocol. Dual stack security means running both protocols to the same standard. NIST SP 800-119 made the same point in 2010: "Organizations should begin now to understand the risks of deploying IPv6."

Neighbor Discovery, SLAAC and DHCPv6

IPv6 replaces ARP and much of DHCP with IPv6 Neighbor Discovery (the Neighbor Discovery Protocol, NDP, RFC 4861), carried in ICMPv6. Every NDP message is sent with Hop Limit 255, which makes it "immune to off-link senders", but there is no authentication of who on the link sent it. Secure Neighbor Discovery (SEND, RFC 3971) adds signatures, but host support is so limited that practical defence happens in the network.

SLAAC: with stateless address autoconfiguration (RFC 4862), a host takes the prefix from a Prefix Information option with the A flag set, adds its own interface identifier and runs duplicate address detection. RFC 4862 notes that SLAAC "allows a host to connect to a network" without registering or authenticating with the site. DHCPv6: the RA's M flag (Managed) tells hosts to get addresses from DHCPv6 and the O flag (Other) to get DNS and other options there. DHCPv6 clients use UDP 546 and servers and relays UDP 547. NSA recommends "assigning addresses to hosts via a Dynamic Host Configuration Protocol version 6 (DHCPv6) server" so addresses are logged and not derived from hardware identifiers.

Rogue router advertisement and DHCPv6 attacks

Because hosts trust the link, an attacker or a misconfigured device on the same VLAN or Wi-Fi network can answer first. ATT&CK tracks the DHCP case as T1557.003 DHCP Spoofing, a sub-technique of T1557 Adversary-in-the-Middle, and its mitigation M1037 explicitly includes blocking DHCPv6 and incoming router advertisements, especially where IPv6 is not commonly used.

• Router advertisement spoofing: a rogue RA makes the sender the default router for every host that accepts it, putting it in the path of IPv6 traffic. Accidental rogue RAs, from a laptop sharing its connection or a consumer router plugged into a desk port, are more common than attacks and cause outages the same way.
• DHCPv6 spoofing and IPv6 DNS takeover: on dual-stack Windows networks, hosts send DHCPv6 requests even when no DHCPv6 service exists. A rogue DHCPv6 server that answers can assign itself as the host's DNS server, and Windows will generally prefer it over the IPv4 DNS server. From there the attacker can answer name lookups, including web proxy auto-discovery (WPAD), and steer hosts to authenticate to it, which enables NTLM credential relay against Active Directory services such as LDAP and certificate enrolment endpoints.
• NDP spoofing: forged Neighbor Advertisements redirect traffic for a specific neighbour, as ARP spoofing does in IPv4.
• Denial of service: answering every duplicate address detection probe stops hosts getting addresses; floods of RAs with many prefixes exhaust host resources; scanning large subnets fills router neighbour caches.

Mitigating DNS takeover on Windows networks

1. Block it at the switch and access point: enable DHCPv6 Guard and RA Guard on every access port and wireless SSID so only infrastructure ports may send DHCPv6 server messages or RAs.
2. Use host firewall policy as a second layer: where the network does not run DHCPv6, add Windows Defender Firewall inbound block rules for DHCPv6 replies (UDP 546) and router advertisements (ICMPv6 type 134), deployed by Group Policy or Intune after testing.
3. If IPv6 is genuinely unused, follow Microsoft's method: set DisabledComponents under HKLM\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters rather than clearing the adapter binding. Microsoft recommends 0x20 (Prefer IPv4 over IPv6) instead of disabling; 0xFF disables IPv6 on all non-loopback interfaces (not 0xFFFFFFFF, which delays start-up). A restart is needed, and Microsoft warns "some Windows components might not function" when IPv6 is disabled. Prefer IPv4 changes address selection only, so keep first hop security in place.
4. Remove what makes the takeover useful: disable WPAD automatic proxy detection where it is not used, require SMB signing, enforce LDAP signing and channel binding, and enable Extended Protection for Authentication on certificate enrolment web services. See the Active Directory and Entra ID Hardening Guide.
5. Detect: alert on any DHCPv6 server or RA source that is not on the infrastructure list, on hosts whose DNS server is a link-local or unexpected IPv6 address, and on NTLM authentications from workstations to other workstations.

IPv6 first hop security

RFC 9099 calls RA Guard and SAVI a "first line of defense" and recommends enabling RA Guard by default on managed Wi-Fi and campus networks. The features below are implemented in switches and wireless controllers under similar names.

RFC 7113 records that hiding an RA behind a fragmented extension header chain "has been found to be effective against all existing implementations of RA-Guard" at the time, and requires that "RA-Guard must parse the entire IPv6 header chain present in the packet" and drop first fragments that do not contain it, logging the drop. Confirm your platform does this before relying on it, and remember RFC 6105's caveat that RA Guard only works where "all messages between IPv6 end-devices traverse the controlled L2 networking devices", so peer-to-peer wireless and unmanaged switches are gaps. Port-based access control helps reduce who can plug in at all; see the Network Access Control (NAC) Guide and the Wi-Fi Security Guide.

Extension headers, ICMPv6 and IPv6 firewall rules

IPv6 extension headers (RFC 8200) sit between the fixed header and the upper-layer protocol: Hop-by-Hop Options, Destination Options, Routing, Fragment, Authentication and ESP. RFC 8200 says "Each extension header should occur at most once, except for the Destination Options header", and "If the first fragment does not include all headers through an Upper-Layer header, then that fragment should be discarded". Overlapping fragments are prohibited and Routing Header type 0 is deprecated (RFC 5095). For IPv6 firewall rules, RFC 9099 advises enforcing the recommended header order and dropping first fragments without the full header chain, and dropping Routing Header type 0 at the edge.

ICMPv6 filtering is where IPv4 habits break IPv6. RFC 4890 lists transit messages that must not be dropped:

NSA adds that "Specific ICMPv6 messages, such as neighbor discovery and router advertisement, may need to be permitted" even where IPv4 ICMP is blocked, and that because interfaces carry several addresses, you should "carefully review ACLs to ensure they deny all traffic by default". Every TCP and UDP rule needs an IPv6 equivalent. See the Firewall Management Guide.

IPv6 tunnelling and transition mechanisms

Automatic IPv6 tunnelling (IPv6 tunneling in most product documentation) can carry IPv6 through an IPv4 network and past IPv4-only inspection. NSA recommends that you "disable tunneling protocols (6to4, ISATAP, Teredo, etc.) on all devices where possible" and block them at the perimeter. RFC 9099 lists what to block when not required: IP protocol 41 (6to4, 6rd, ISATAP, 6in4), IP protocol 47 (GRE) and UDP 3544 (Teredo's default port), and notes "Client usage of 6to4 by default is now discouraged". Teredo deserves particular attention because it runs over UDP and can traverse NAT. Where a tunnel or translation service is genuinely needed, such as NAT64/DNS64 or 464XLAT in IPv6-only networks, terminate it on managed gateways with the same inspection as native traffic.

IPv6 address scanning and addressing plans

A /64 subnet holds 2⁶⁴ addresses, but RFC 9099 warns that scanning is "more feasible than expected", because real addresses cluster around low numbers, MAC-derived identifiers, embedded IPv4 addresses and DNS records (RFC 7707). Do not rely on obscurity. Use randomised DHCPv6 assignments or stable privacy identifiers for clients, keep servers in AAAA records behind the same rules as IPv4, run split DNS so internal AAAA records are not published externally (NSA), apply ingress ACLs and ND rate limits so scans of unused space cannot exhaust router neighbour caches, and use /127 on point-to-point links (RFC 6164). See the DNS Security Guide.

Choosing a strategy: block, prefer IPv4, dual stack or IPv6-only

Small organisations without managed switches should prioritise blocking IPv6 tunnels at the edge, host firewall rules for RAs and DHCPv6, and the Active Directory hardening that removes the payoff of DNS takeover. Large organisations should treat IPv6 as a first-class protocol: one addressing plan, first hop security as a switch template, and IPv6 in every security assessment, as M-21-07 requires for federal systems.

Rolling out IPv6 security

1. Discover: capture traffic on representative VLANs and SSIDs for RAs, DHCPv6 and tunnel protocols; list link-local and global addresses seen. Assume IPv6 is present until shown otherwise.
2. Decide per segment: block, prefer IPv4, dual stack or IPv6-only, using the table above, and record the decision.
3. Pilot first hop security: enable RA Guard and DHCPv6 Guard in log or monitor mode on one access switch stack and one SSID, mark router and DHCP server ports as trusted, then move to blocking after a week without false positives.
4. Roll out by ring: access layer and wireless first, then data centre access where hypervisors and containers may emit RAs. Keep the previous switch template so a port can be reverted quickly.
5. Bring firewalls to parity: IPv6 equivalents for every IPv4 rule, ICMPv6 by type, tunnel protocols blocked, extension header and fragment handling configured.
6. Harden hosts: firewall block rules where DHCPv6 and RAs are unused, DisabledComponents only where justified, WPAD off, signing and channel binding enforced. Test line-of-business applications in a pilot group before broad deployment.
7. Prove it: from a test port, confirm that a rogue RA and DHCPv6 reply are dropped and logged, and that hosts keep their legitimate gateway and DNS server.

IPv6 monitoring and detection

Dual-stack monitoring fails most often because logs and tools only understand IPv4. RFC 9099 recommends logging in the canonical address format (RFC 5952) so one address is not stored several ways, polling router neighbour caches about every 30 seconds to map IPv6 addresses to MAC addresses, and keeping history because privacy extensions (RFC 8981) give one host many addresses over a day. Feed RA Guard and DHCPv6 Guard drop events, DHCPv6 server leases and neighbour cache data into the SIEM (see the SIEM Guide), and make sure NDR and IDS sensors decode IPv6 and common tunnels. On Windows, the Microsoft-Windows-DHCPv6-Client operational log and changes in a host's DNS server list are useful signals.

Metrics:

• First hop coverage: share of access ports and SSIDs with RA Guard and DHCPv6 Guard in blocking mode.
• Rogue sources: unauthorised RA or DHCPv6 sources detected per month, and time to locate the port.
• Rule parity: share of IPv4 firewall rules with a reviewed IPv6 equivalent.
• Tunnel exposure: hosts emitting Teredo, 6to4 or ISATAP traffic.
• Attribution: share of IPv6 flows in the SIEM that can be mapped to a device and user.

Framework mapping

Common failure patterns

• "We do not run IPv6": no RA Guard, no DHCPv6 Guard, no IPv6 rules, and every Windows host waiting to accept a DHCPv6 reply from whoever answers first.
• Unbinding IPv6 by script: the adapter checkbox is cleared across the estate, producing an unsupported configuration and odd failures, while switches still forward rogue RAs to devices that were missed.
• RA Guard that can be bypassed: the feature is on but does not drop fragmented packets with incomplete header chains, as RFC 7113 requires.
• ICMPv6 blocked like ICMP: Packet Too Big is dropped, so large transfers hang over IPv6 and teams disable IPv6 to fix it rather than correcting the filter.
• Tunnels left open: Teredo or protocol 41 allowed outbound gives hosts an uninspected IPv6 path to the internet.
• IPv4-only logging: SIEM parsers, asset inventories and threat intelligence lists ignore IPv6 addresses, so an intrusion over IPv6 leaves no usable trail.

Practitioner checklist

• Capture RAs, DHCPv6 and tunnel traffic on every segment to confirm where IPv6 is active.
• Enable RA Guard and DHCPv6 Guard on all access ports and SSIDs, trusting only router and server ports.
• Confirm first hop features drop first fragments without a full header chain.
• Never unbind IPv6 on Windows; use DisabledComponents 0x20, or 0xFF only where justified and tested.
• Block inbound RAs and DHCPv6 replies on hosts where the network does not use them.
• Disable WPAD where unused and enforce SMB signing, LDAP signing and channel binding.
• Give every IPv4 firewall rule an IPv6 equivalent and filter ICMPv6 by type per RFC 4890.
• Block Teredo, 6to4, ISATAP and other unneeded tunnels at hosts and the perimeter.
• Log IPv6 in canonical form, map addresses to MACs and users, and confirm sensors decode IPv6.

Standards and references

• IETF: RFC 9099 Operational Security Considerations for IPv6 Networks
• IETF: RFC 6105 IPv6 Router Advertisement Guard
• IETF: RFC 7113 Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)
• IETF: RFC 7610 DHCPv6-Shield: Protecting against Rogue DHCPv6 Servers
• IETF: RFC 4890 Recommendations for Filtering ICMPv6 Messages in Firewalls
• NIST: SP 800-119 Guidelines for the Secure Deployment of IPv6
• NSA: IPv6 Security Guidance
• Microsoft: Guidance for configuring IPv6 in Windows for advanced users

Related NHI Mgmt Group resources: Network Segmentation Guide · Network Access Control (NAC) Guide · Firewall Management Guide · Lateral Movement Guide · Active Directory and Entra ID Hardening Guide