IPv6 Rogue Router Advertisements: NDP Spoofing and Layer 3 VPN Defense

The transition to IPv6 altered client network discovery. Where IPv4 used broadcast ARP inquiries and DHCP servers, IPv6 introduced the Neighbor Discovery Protocol (NDP). Defined in RFC 4861, NDP operates over ICMPv6 to manage address resolution, router discovery, on-link prefix determination, and stateless autoconfiguration (SLAAC).

While NDP streamlined client onboarding, it assumed implicit link trust. Any device on a shared Layer 2 broadcast domain can broadcast unsolicited ICMPv6 Router Advertisement (RA) packets. When an adversary transmits crafted RAs, neighboring endpoints adopt the attacker as default gateway. Without complete routing defenses, unencapsulated IPv6 packets travel across rogue gateways, exposing sensitive sessions.

Stateless Autoconfiguration and the Trust Model of IPv6 Neighbor Discovery

In IPv4 networks, address allocation requires explicit state tracking by DHCP servers. IPv6 replaced centralized lease tables with SLAAC, enabling hosts to configure 128-bit addresses autonomously.

When an IPv6 interface connects to a physical or wireless link, it generates a link-local address in fe80::/10. To find upstream paths, the host transmits an ICMPv6 type 133 Router Solicitation (RS) to multicast address ff02::2. Local routers reply with an ICMPv6 type 134 Router Advertisement to multicast address ff02::1.

RFC 4861 was conceived assuming Layer 2 physical security. The protocol omits cryptographic authentication or pre-shared keys. Any device on a Wi-Fi segment, Ethernet VLAN, or shared hotspot can declare itself an upstream router. Operating systems parse incoming type 134 packets directly in kernel space, updating routing tables and interface addresses without user intervention.

Anatomy of ICMPv6 Router Advertisements: Flags, Prefixes, and Timers

An ICMPv6 Router Advertisement contains an 8-bit Type (134), 8-bit Code (0), 16-bit Checksum, and 8-bit Cur Hop Limit. Base flags dictate client behavior:

• Managed Address Configuration (M flag): Prompts the host to obtain stateful addresses via DHCPv6.
• Other Configuration (O flag): Instructs the client to query DHCPv6 for auxiliary data like NTP servers.
• Default Router Preference (Prf bits): Standardized under RFC 4191, encoding Low (11), Medium (00), or High (01) priority.
• Router Lifetime (16 bits): Dictates how many seconds (from 0 to 9000) the sender serves as default gateway. A value of 0 removes the router from client routing tables.

RA headers package variable Option fields that govern routing:

Manipulating these fields enables adversaries to restructure routing paths and name resolution across local subnets.

Threat Vectors: How Rogue RAs Hijack Operating System Routing Tables

Rogue Router Advertisements arise from misconfigured hypervisors or deliberate interception attacks. Using tools like scapy or radvd, an attacker broadcasts high-priority ICMPv6 RA frames, triggering two attack vectors.

Forced SLAAC Readdressing and Default Gateway Preemption

The attacker broadcasts an RA packet with:

1. Router Preference set to High (Prf = 01).
2. Router Lifetime set to 1800 seconds.
3. A /64 Prefix Information Option with Autonomous (A) and On-link (L) flags enabled.

The victim kernel accepts the attacker link-local address (fe80::dead:beef:cafe) as primary default gateway. The host assigns itself a global unicast address within the rogue prefix.

Because modern systems prioritize IPv6 via RFC 8305 Happy Eyeballs, outbound sessions route through the rogue gateway. With kernel packet forwarding enabled (sysctl -w net.ipv6.conf.all.forwarding=1), the attacker inspects unencrypted flows while logging SNI headers and remote destination endpoints.

Malicious RDNSS Injection: Intercepting DNS Prior to Transport Encapsulation

Under RFC 8106, the RDNSS option injects recursive DNS resolver addresses directly into host network stacks. An attacker specifies an adversary-controlled IPv6 resolver address.

When the endpoint resolves hostnames, the malicious resolver serves forged records. Because autoconfiguration processes this at the kernel interface level, it can override static IPv4 DNS resolvers.

If client machines lack encapsulated Layer 3 tunneling, queries circulate unencrypted over the local link. Readers examining local network hazards can inspect our guide on ARP spoofing and cache poisoning.

NDP Cache Poisoning: Exploiting Neighbor Advertisements and Router Lifetime

Adversaries also target Neighbor Advertisements (NA) to corrupt local address mappings. NDP relies on Neighbor Solicitation (type 135) and Neighbor Advertisement (type 136) messages to bind IPv6 addresses to Ethernet MAC addresses.

An attacker sends unsolicited NA packets to victims with the Override flag set (O = 1). The receiving kernel updates its Link-Layer Address (LLA) cache, mapping legitimate gateway IP addresses to the attacker MAC address.

[Legitimate Gateway]                [Victim Host]                [Adversary Node]
  2001:db8::1                          fe80::100                   2001:db8::666
       |                                    |                            |
       |                                    |<--- Unsolicited NA (O=1) --|
       |                                    |    Maps 2001:db8::1 to     |
       |                                    |    Adversary MAC           |
       |                                    |                            |
       |<-- Outgoing IPv6 Packets Diverted -|--------------------------->|
       |    (Packets intercepted and logged by adversary proxy)          |

Attackers can also emit RA messages with Router Lifetime set to 0. Operating system kernels immediately purge default route entries, causing disconnections and denial of service.

Why Split-Tunneling and Dual-Stack Applications Leak Under Rogue RA Attacks

Rogue RAs expose critical flaws in VPN clients that lack complete IPv6 routing.

Many VPN clients configure only IPv4 routing over virtual network adapters (tun0 or utun3), inserting split prefixes into the IPv4 table:

# Typical IPv4-only VPN routing insertion
ip route add 0.0.0.0/1 dev tun0
ip route add 128.0.0.0/1 dev tun0

The underlying IPv6 routing table remains tied to the physical adapter (wlan0 or eth0). When a rogue RA arrives, the host installs an IPv6 default route pointing to the local attacker.

When web clients connect to dual-stack endpoints, RFC 8305 Happy Eyeballs prefers IPv6 paths. Because the VPN interface manages no default IPv6 route, traffic departs through the physical adapter toward the rogue gateway. The user assumes the session is secured, while application payloads leak outside encryption. Similar routing failures are discussed in our analysis of DHCP Option 121 route injection attacks.

Layer 2 Infrastructure Defenses: RA-Guard, SEND, and Port Security Limitations

Network administrators deploy Layer 2 defenses to suppress unauthorized advertisements:

IPv6 RA-Guard (RFC 6105)

Switches supporting RA-Guard classify switch ports as trusted or untrusted. Hardware ASICs inspect incoming ICMPv6 type 134 packets and drop unauthorized advertisements arriving on client access ports.

Secure Neighbor Discovery (SEND, RFC 3971)

SEND authenticates NDP frames using Cryptographically Generated Addresses (CGA) and asymmetric digital signatures. Hosts verify address ownership by validating public keys hashed into interface identifiers.

Operational Limitations

These mechanisms fail to protect roaming devices:

• Absence on Public Networks: Commercial cafes, airport Wi-Fi, and residential gateways rarely deploy RA-Guard.
• SEND Incompatibility: Major platforms lack native SEND implementations due to complex PKI prerequisites.
• VLAN Evasion: Attackers encapsulate rogue RAs inside 802.1Q double-tagged frames or fragmented ICMPv6 packets to evade switch filters.

Because Layer 2 defenses are outside client control, devices must enforce protection within the local operating system stack.

Layer 3 VPN Architecture: Dual-Stack Kernel Encapsulation and Route Pinning

Immunity against rogue RAs requires modern Layer 3 VPNs to enforce deterministic kernel routing. Protection relies on dual-stack tunnel encapsulation paired with routing policy database (RPDB) pinning.

+------------------------------------------------------------------------+
|                            User Space Application                      |
+------------------------------------------------------------------------+
                                    |
                                    v (Dual-Stack Sockets: AF_INET / AF_INET6)
+------------------------------------------------------------------------+
|                          Linux Kernel RPDB Rules                       |
|   Rule 100: from all to <VPN-Endpoint-IP> lookup main                  |
|   Rule 200: from all lookup 51820 (VPN routing table)                  |
|   Rule 32766: from all lookup main (Physical interface default)        |
+------------------------------------------------------------------------+
                                    |
                                    v
+-----------------------------------+------------------------------------+
|   Table 51820 (WireGuard / RiceGuard)|   Table Main (Physical wlan0)      |
|   default via :: dev rg0          |   default via fe80::dead:beef dev  |
|   default via 0.0.0.0 dev rg0     |   (Rogue RA route isolated here)   |
+-----------------------------------+------------------------------------+

The VPN client establishes an isolated routing table (such as table 51820) containing encompassing prefixes:

• 0.0.0.0/0 routed through interface rg0
• ::/0 routed through interface rg0

The client configures kernel policy rules with strict evaluation priority:

# Pin all IPv6 traffic to the encrypted tunnel table
ip -6 rule add pref 200 lookup 51820
ip -6 rule add pref 201 unreachable

When an adversary broadcasts high-priority rogue RAs on physical interface wlan0, the kernel processes table 51820 at priority 200 before reaching table main. The rogue route remains unreferenced.

RiceGuard Route Table Enforcement: Neutralizing Unsolicited ICMPv6 at the Socket Layer

VPNRice incorporates RiceGuard, an optimized WireGuard transport built to insulate devices against local Layer 2 hazards.

RiceGuard applies a multi-layered defense pipeline:

1. Deterministic Dual-Stack Allocation: RiceGuard provisions internal IPv4 (10.64.0.0/10) and unique local IPv6 (fd00::/8) addresses on every connection, preventing Happy Eyeballs from choosing physical paths.
2. Kernel Packet Filtering Rules: On platforms supporting nftables or pf, RiceGuard injects firewall directives dropping incoming ICMPv6 type 134 packets on physical interfaces:

table inet vpnrice_defense {
    chain prerouting {
        type filter hook prerouting priority -100; policy accept;
        iifname != "rg0" icmpv6 type { nd-router-advert, nd-redirect } counter drop
    }
}

3. DNS Resolver Locking: RiceGuard routes DNS queries to internal stub listeners on 127.0.0.1:53 and [::1]:53. Malicious RDNSS options received on local Wi-Fi links are discarded.

Users can audit external addresses and verify routing security using the What is my IP lookup tool.

Benchmarking Network Resiliency: Metric Priority, Handover Times, and Packet Loss

We evaluated client stability during active rogue RA injection within an isolated Wi-Fi laboratory. A rogue node transmitted ICMPv6 type 134 frames at 2-second intervals using scapy, announcing preference High alongside rogue RDNSS records.

We evaluated three configurations: an unprotected baseline, a standard IPv4 VPN, and an attested RiceGuard dual-stack tunnel.

Under IPv4-only configurations, operating system route stacks oscillated between competing default gateways, causing packet loss and socket resets.

Under RiceGuard, kernel policy routing resolved table 51820 unconditionally. Unsolicited ICMPv6 frames were discarded by packet filters, preserving continuous encryption without packet dropouts.

Practical Implementation: Hardening Endpoints and Auditing Local IPv6 Neighbors

Administrators and users in untrusted networks can implement complementary endpoint hardening measures.

Inspecting Active IPv6 Gateways and Neighbors

On Linux systems, inspect active IPv6 routes and neighbor tables to identify rogue gateways:

# Display default IPv6 routes and metrics
ip -6 route show default

# Inspect discovered neighbor link-layer addresses
ip -6 neighbor show

# Monitor live ICMPv6 advertisements in real time
sudo tcpdump -ni any "icmp6 and (ip6[40] == 134 or ip6[40] == 135)" -v

Disabling Autonomous Router Acceptance on Untrusted Interfaces

On Linux endpoints without automated filtering, administrators can disable ICMPv6 Router Advertisement processing on physical interfaces:

# Disable Router Advertisement processing on physical interface wlan0
sudo sysctl -w net.ipv6.conf.wlan0.accept_ra=0
sudo sysctl -w net.ipv6.conf.wlan0.accept_ra_defrtr=0
sudo sysctl -w net.ipv6.conf.wlan0.accept_ra_pinfo=0
sudo sysctl -w net.ipv6.conf.wlan0.accept_ra_rtr_pref=0

Setting accept_ra=0 instructs the kernel to drop incoming type 134 frames on wlan0. When establishing connections via the official VPNRice client application, these protections deploy automatically alongside WireGuard encapsulation.

By combining strict policy routing with kernel-level packet inspection, modern endpoints maintain transport integrity across hostile local networks.