RA Guard (Router Advertisement Guard) is a Layer 2 security mechanism designed to protect IPv6 networks from rogue Router Advertisement (RA) messages. Standardized in RFC 6105 and updated by RFC 7113, RA Guard acts as the first line of defense against malicious or misconfigured devices that attempt to inject false routing information into IPv6 networks. By filtering RA messages at the switch level, this technology prevents attackers from redirecting traffic, launching man-in-the-middle attacks, or disrupting network connectivity.
IPv6 networks rely on Router Advertisement messages as part of the Neighbor Discovery Protocol (NDP) to automatically configure network settings on hosts. When a device connects to an IPv6 network, it listens for RA messages to learn critical information including:
This automatic configuration mechanism, while convenient, creates a significant security vulnerability. Any device on the network can potentially send RA messages, whether authorized or not.
Man-in-the-Middle (MITM) Attacks: An attacker sends rogue RA messages advertising themselves as the default gateway. Victim hosts then route their traffic through the attacker's system, allowing interception and modification of all network communications. This attack is particularly dangerous because it requires no special privileges - any device connected to the network segment can attempt it.
Denial of Service: A malicious actor can send RA messages with a router lifetime of zero, causing legitimate routers to be removed from hosts' routing tables. Alternatively, an attacker might advertise invalid prefixes or parameters that prevent proper network configuration, effectively disconnecting hosts from the network.
Dual-Stack Exploitation: In networks running both IPv4 and IPv6, attackers can exploit IPv6 vulnerabilities even when administrators believe they're operating a "dual-stack networking" network. Modern operating systems and applications prefer IPv6 when available, so a rogue RA can hijack traffic that would otherwise use IPv4. This is especially problematic in container environments and Kubernetes clusters, as documented in CVE-2020-10749.
Unintentional Misconfiguration: Not all rogue RAs come from malicious actors. Windows Internet Connection Sharing, virtual machine bridges, misconfigured home routers, and unauthorized wireless access points frequently generate unintended RA messages that disrupt enterprise networks. RFC 6104 notes that unintended RAs represent the most common problem observed in production networks.
RA Guard operates at the Layer 2 network fabric, typically implemented in Ethernet switches. The mechanism examines ICMPv6 packets to identify Router Advertisement messages (ICMPv6 Type 134) and Router Redirect messages (ICMPv6 Type 137), then applies policy-based filtering before forwarding.
The validation process follows these steps:
RA Guard policies fundamentally distinguish between two device roles:
Host Mode (Default): All Router Advertisement and Router Redirect messages are blocked on the port. This configuration is appropriate for access layer ports where end-user devices, servers, and other hosts connect. No RA messages should originate from these devices under normal circumstances.
Router Mode: RA and Router Redirect messages are permitted but still validated against policy criteria. This mode is used for uplink ports connecting to legitimate routers or Layer 3 switches. The policy can specify additional validation rules such as allowed prefix lists, hop count limits, and router preference values.
Stateless Mode: Each RA message is independently evaluated against the static policy configuration. The switch maintains no state about previous messages or learning from network behavior. This mode offers predictable, deterministic filtering but cannot adapt to network changes.
Stateful Mode: The switch operates through distinct phases:
Stateful mode provides more sophisticated protection by detecting deviations from established baselines, but requires careful tuning to avoid false positives during network topology changes.
Basic Host-Mode Policy (Access Ports):
! Create a host-mode RA Guard policy
Switch(config)# ipv6 nd raguard policy HOST-POLICY
Switch(config-nd-raguard)# device-role host
Switch(config-nd-raguard)# exit
! Apply to access interfaces
Switch(config)# interface range GigabitEthernet1/0/1-48
Switch(config-if-range)# ipv6 nd raguard attach-policy HOST-POLICY
Switch(config-if-range)# exit
Router-Mode Policy with Validation (Uplink Ports):
! Create router-mode policy with prefix validation
Switch(config)# ipv6 nd raguard policy ROUTER-POLICY
Switch(config-nd-raguard)# device-role router
Switch(config-nd-raguard)# match ipv6 access-list ALLOWED-PREFIXES
Switch(config-nd-raguard)# hop-limit maximum 64
Switch(config-nd-raguard)# managed-config-flag on
Switch(config-nd-raguard)# exit
! Define allowed prefixes
Switch(config)# ipv6 access-list ALLOWED-PREFIXES
Switch(config-ipv6-acl)# permit ipv6 host fe80::1 any
Switch(config-ipv6-acl)# permit ipv6 2001:db8::/32 any
Switch(config-ipv6-acl)# exit
! Apply to uplink interface
Switch(config)# interface TenGigabitEthernet1/0/1
Switch(config-if)# ipv6 nd raguard attach-policy ROUTER-POLICY
Switch(config-if)# exit
Verification Commands:
Switch# show ipv6 nd raguard policy
Switch# show ipv6 nd raguard interface gigabitethernet1/0/1
Switch# show ipv6 nd raguard counters
Stateless Configuration:
[edit forwarding-options access-security]
# Define RA Guard policy
user@switch# set router-advertisement-guard policy BLOCK-ALL discard
# Apply to access interfaces
user@switch# set router-advertisement-guard interface ge-0/0/1 policy BLOCK-ALL stateless
user@switch# commit
Stateful Configuration with MAC Filtering:
[edit forwarding-options access-security]
# Create MAC address list for allowed routers
user@switch# set mac-list AUTHORIZED-ROUTERS mac-address 00:11:22:33:44:55
# Define policy allowing specific routers
user@switch# set router-advertisement-guard policy ALLOW-ROUTERS permit source-mac-address-list AUTHORIZED-ROUTERS
# Apply stateful mode to VLAN
user@switch# set router-advertisement-guard vlans VLAN100 policy ALLOW-ROUTERS stateful
user@switch# commit
Verification:
user@switch> show access-security router-advertisement-guard interface ge-0/0/1
user@switch> show access-security router-advertisement-guard statistics
Beyond simple device-role filtering, RA Guard policies can validate multiple RA message parameters:
RA Guard is typically deployed alongside complementary IPv6 security mechanisms:
Together, these features form a comprehensive first-hop security solution protecting against various IPv6 threats.
The most significant RA Guard vulnerability involves IPv6 packet fragmentation. RFC 6105's original specification did not adequately address fragmented packets, allowing attackers to bypass protection by fragmenting rogue RA messages.
Attack Method: An attacker constructs an RA message with multiple IPv6 Extension Headers and fragments the packet so that the ICMPv6 Router Advertisement header doesn't appear in the first fragment. Many RA Guard implementations only inspect the first fragment, allowing subsequent fragments containing the malicious RA to pass through undetected.
Example: Research has demonstrated that both Cisco and H3C RA Guard implementations can be bypassed using this technique. The attack succeeds because reassembly occurs at the destination host, after the switch has already forwarded all fragments.
RFC 7113 Mitigation: Updated implementation guidance recommends:
However, deployment remains challenging because dropping all fragmented ND packets may affect legitimate but unusual traffic patterns.
Related to fragmentation, attackers can insert multiple IPv6 Extension Headers to confuse RA Guard inspection. Testing shows that inserting seven empty Destination Options Extension Headers bypasses Cisco implementations, while H3C devices fail after just three Extension Headers.
This occurs because RA Guard must parse through the entire Extension Header chain to locate the ICMPv6 header, but implementations often have parsing depth limits or performance constraints that prevent complete inspection.
RA Guard operates at Layer 2 and cannot inspect traffic within tunnels. Attackers can encapsulate rogue RAs in:
If not properly configured on trunk ports, RA Guard policies might not apply to all VLANs, allowing attackers to send tagged frames that bypass protection.
Deep packet inspection for RA Guard consumes switch processing resources. On high-traffic ports or lower-end hardware, the feature may be selectively disabled or configured with less stringent policies, creating security gaps.
RA Guard should never be the sole security control. Implement multiple layers:
Complement network-level RA Guard with host-based protections:
/proc/sys/net/ipv6/conf/*/accept_raAfter deploying RA Guard, verify effectiveness:
RFC 3971 defines SEND, which uses cryptographic signatures to authenticate RA messages. While theoretically superior to RA Guard, SEND suffers from:
RA Guard remains the pragmatic solution for most deployments.
SDN controllers can implement more sophisticated RA filtering logic:
Counterintuitively, IPv6-only networks can simplify security. Without dual-stack complexity, administrators can focus protection efforts solely on IPv6 mechanisms, eliminating the subtle attack vectors that arise from protocol interaction.
After implementing RA Guard, it's crucial to verify that your IPv6 connectivity remains functional while rogue advertisements are blocked. Use comprehensive testing platforms like test-ipv6.run to:
The platform provides real-time testing of IPv6-only, IPv4-only, and dual-stack configurations, helping you ensure that security measures haven't inadvertently disrupted legitimate traffic.
RA Guard represents a critical security control for IPv6 networks, providing essential protection against rogue Router Advertisement attacks. While not perfect—particularly regarding fragmentation-based bypass techniques—it offers practical, widely-supported defense when properly configured and deployed as part of a comprehensive security strategy.
Key takeaways:
As IPv6 adoption accelerates, RA Guard has evolved from an optional enhancement to a mandatory security baseline. Network administrators must understand both its capabilities and limitations to build robust IPv6 infrastructures that balance connectivity with security.
References:
Related Reading: