IPv6 Router Advertisement (RA) Guard is a critical Layer 2 security control for any network running IPv6. When misconfigured — or when implemented on unpatched hardware — it can be bypassed using well-documented techniques, leaving enterprise networks vulnerable to rogue router injection, SLAAC attacks, and denial of service. My6 Initiative Berhad has identified this as a recurring gap during IPv6 readiness assessments conducted across Malaysian enterprise and government networks.
IPv6 networks use Router Advertisement (RA) messages — ICMPv6 Type 134 — to inform hosts of available routers, prefixes, and address configuration parameters. In a dual-stack or IPv6-only enterprise network, any device that can send an RA message can effectively become the network's default gateway and redirect or intercept traffic.
RA Guard is a Layer 2 security mechanism, standardised in RFC 6105 (published February 2011), that is implemented directly on managed switches. The switch acts as an authorisation proxy: it inspects each ICMPv6 RA message and forwards only those arriving from ports explicitly configured as router-facing. RA messages arriving on host-facing ports are silently discarded.
RA Guard, when correctly implemented, protects against three distinct attack types: Denial of Service via RA flooding that exhausts host NDP state tables; SLAAC attacks that inject rogue IPv6 prefixes causing hosts to configure attacker-controlled addresses; and Man-in-the-Middle attacks where an attacker issues an RA claiming a lower hop limit or a spoofed gateway MAC, redirecting all host traffic through an attacker-controlled device.
| RFC | Title | Year | Relevance |
|---|---|---|---|
| RFC 4861 | Neighbor Discovery for IPv6 | 2007 | Defines RA/RS messages and NDP protocol |
| RFC 3971 | SEcure Neighbor Discovery (SEND) | 2005 | Cryptographic alternative to RA Guard |
| RFC 6105 | IPv6 Router Advertisement Guard | 2011 | Original RA Guard specification |
| RFC 7113 | Implementation Advice for IPv6 RA Guard | 2014 | Documents bypass techniques and mitigations |
| RFC 6980 | Security Implications of IPv6 Fragmentation with ND | 2013 | Standards Track — forbids Fragment Header in all ND messages |
| RFC 7610 | DHCPv6-Shield | 2015 | Analogous protection for rogue DHCPv6 servers |
RA Guard bypass techniques were first publicly disclosed by security researcher Marc Heuse (THC) in May 2011 via the Full Disclosure mailing list, within months of RFC 6105's publication. These are not theoretical — they are implemented in widely available security tools and confirmed effective against real hardware. RFC 7113, published in February 2014, formally documents these bypass methods and provides implementation guidance to address them.
An attacker prepends a Destination Options header (Next Header = 60) or Hop-by-Hop Options header before the ICMPv6 RA payload. Switches that only inspect the fixed IPv6 header's Next Header field for the value 58 (ICMPv6) will not recognise the packet as an RA and will forward it without inspection. This is described in RFC 7113 as a fundamental implementation failure in early RA Guard deployments.
An attacker constructs a large (~1,400 byte) Destination Options Header and uses it to push the ICMPv6 RA payload into the second fragment of a fragmented IPv6 packet. The switch sees only extension headers in the first fragment and cannot identify it as an RA. RFC 7113 confirmed this technique was "effective against all existing implementations" at the time of writing.
RFC 6980 (a Standards Track document, August 2013) addresses this directly: it formally forbids the use of the IPv6 Fragment Header in all Neighbor Discovery messages, including RAs, and requires implementations to silently drop any fragmented ND message. A switch correctly implementing RFC 6980 drops fragmented RAs entirely, neutralising this bypass. However, switches running pre-RFC 6980 firmware may not enforce this.
A more recently documented bypass class exploits the handling of VLAN 0 (priority tag) and 802.2 LLC/SNAP headers at the L2 processing layer. By prepending these headers, an attacker can cause some switch implementations to skip L2 security feature inspection entirely. These vulnerabilities were publicly disclosed by researcher Etienne Champetier and assigned as CERT/CC VU#855201 in September 2022.
| CVE | Attack Vector | CVSS | Affected Vendors |
|---|---|---|---|
| CVE-2021-27853 | VLAN 0 + LLC/SNAP headers | 4.7 Medium | Cisco, Juniper, Arista |
| CVE-2021-27854 | VLAN 0 + LLC/SNAP + Ethernet↔WiFi conversion | 4.7 Medium | Juniper, Arista |
| CVE-2021-27861 | LLC/SNAP invalid length (optional VLAN0) | 4.7 Medium | Cisco, Arista |
| CVE-2021-27862 | LLC/SNAP invalid length + Ethernet→WiFi | 4.7 Medium | Arista |
Vendor patches for this family are available. Juniper released fixes in Junos OS 21.4R3, 22.1R2+, 22.2R2+, and 22.3R1+. Cisco's workaround involves L2 ACLs restricting ethertypes to 0x86DD (IPv6), 0x0800 (IPv4), and 0x0806 (ARP) on access ports. Arista published Security Advisory 0080.
Beyond the protocol-level bypasses, My6's assessments and industry documentation point to several recurring configuration errors that undermine RA Guard even on patched hardware:
device-role host. Uplinks to legitimate routers must be explicitly configured with device-role router, otherwise Router Solicitation messages from the router will not be forwarded to hosts.Network security engineers and IPv6 auditors can verify RA Guard effectiveness using:
fake_router26 with evasion flags (-E F full evasion, -E H hop-by-hop, -E D large destination header, -E 1 fragmentation). Also flood_router26 for RA flood testing. Available in Kali Linux.ra6 for RA generation and evasion testing.Security testing tools should only be used on networks you own or have explicit written authorisation to test. Unauthorised use may violate the Computer Crimes Act 1997 (Malaysia) and equivalent legislation in other jurisdictions.
For organisations operating dual-stack or IPv6-only enterprise networks, My6 Initiative Berhad recommends the following:
device-role host. Do not rely on VLAN-level application alone.device-role router and define an RA Guard policy that validates RA content (prefix lists, hop limits, flags).My6 Initiative Berhad conducts IPv6 security assessments as part of its IPv6 Readiness Assessment service. RA Guard misconfiguration is among the most consistently identified gaps in enterprise IPv6 deployments assessed since 2010. If your organisation is deploying or auditing an IPv6 network, contact My6 for a formal assessment at [email protected].