An IPv6 host can learn a default router and network prefix from Router Advertisement messages. This Stateless Address Autoconfiguration model reduces manual configuration, but it also means an unauthorized device on the local segment can influence where hosts send traffic. The issue is not a theoretical implementation bug. It is a property of a discovery protocol that assumes control over who can advertise.
RFC 6105 describes Router Advertisement Guard as a protection for shared Layer 2 segments where SEND is not fully deployed. The guard filters RAs at the network fabric and permits them only from ports or devices associated with an authorized router. RFC 7113 provides implementation advice because early filtering approaches had evasion considerations. RFC 9099 notes that a rogue RA can lead a host to select an incorrect router or prefix, enabling an on-path attack or disrupting connectivity.
What a rogue advertisement can change
An RA can affect the default route, prefix information, address configuration, and other parameters. A host that accepts the message may send traffic through the wrong next hop, configure an address in an unintended prefix, or lose access to legitimate services. The impact may look like a routing incident until packet captures and neighbor discovery state are reviewed.
The relevant boundary is local. A remote Internet scanner cannot send a valid link-local RA into a segment without a foothold, a misconfigured bridge, or an exposed control plane. Review virtual switches, hypervisor bridges, Wi-Fi client isolation, conference networks, and container host bridges. A lab device or an employee laptop with router advertisements enabled can be enough to disturb a shared segment.
Review the host and the fabric
On hosts, record the effective IPv6 forwarding, accept_ra, router preference, and address configuration settings. A router does not use its own advertisements in the same way as an end host, so the policy should match the host's role. Servers with static routing may be able to ignore RAs entirely. A server that accepts RAs should have a clear reason and a monitored upstream segment.
On switches, verify RA Guard policy on access ports. Include wireless controllers, virtual switching, and lab ports. Check that an uplink to an authorized router is allowed and that a downstream port cannot carry an RA unless explicitly configured. Review VLAN and bridge boundaries; a guard that protects one segment does not protect another.
The guard must not become a false sense of security. Fragmentation and encapsulation behavior should be understood for the deployed equipment. Keep the network operating system patched and test the policy with the actual encapsulation used on the segment. Where a switch cannot enforce RA Guard, isolate the segment or use SEND where it is operationally feasible.
Detection and response
Capture ICMPv6 Router Advertisement traffic at the access layer and correlate it with the expected router link-local address and MAC. Alert on a new router, a changed prefix, or a preference change. On hosts, collect neighbor and route tables before and after the event. A single unexpected RA can disappear quickly, so packet capture retention matters.
When an unauthorized RA is suspected, isolate the port or virtual interface, identify the source, and remove the device or configuration. Check for traffic that was redirected during the exposure window. Restore addressing and routing only after the segment is clean.
Defensive baseline
Treat Router Advertisement authority as a network control. Permit RAs only from approved ports, document static versus automatic host behavior, segment untrusted devices, and monitor for changes in default routers and prefixes. The protocol is designed to be automatic; security depends on deciding who is allowed to make the announcement.