A device on an IPv6 LAN starts sending its own Router Advertisements; what happens to the other hosts, and how do RA Guard and SEND each stop it?

## Why a rogue RA works IPv6 hosts learn their default routers, on-link prefixes and often their DNS servers from **Router Advertisements (RAs)**, ICMPv6 type 134 (RFC 4861). A host's validity checks on an RA are structural: the source must be a link-local address, the Hop Limit must be 255, the ICMP checksum must be valid and the code 0. The Hop Limit check proves the sender is **on the link** — it stops a sender across the internet, not one on the same segment. Without a filter in the path, any device that can put frames on the LAN can send an RA that every IPv6-enabled host accepts. ## What one forged advertisement can do | RA content | Effect on hosts | |---|---| | Router Lifetime above 0 | the device's link-local address joins the default router list, and traffic can leave through it | | Default router preference High (RFC 4191) | hosts that implement preferences choose it over a real router left at Medium | | Prefix Information option with A=1 | hosts autoconfigure addresses in the rogue prefix | | RDNSS option (RFC 8106) | hosts send DNS queries to the rogue's resolver | | Router Lifetime 0, sourced from the real router's link-local address | hosts drop the legitimate default router at once — a denial of service | | M or O flag set | hosts look for DHCPv6, where a rogue DHCPv6 server may be waiting | Two details shape the damage: - RFC 4862 will not cut an existing SLAAC address's remaining valid lifetime below **two hours** on an unauthenticated RA, so a forged short lifetime cannot erase addresses at once. - The attack works on a network that **never deployed IPv6**. Hosts with IPv6 enabled configure themselves from the first RA they hear, and dual-stack hosts commonly prefer IPv6 destinations, so an attacker who supplies the whole IPv6 side — prefix, gateway and DNS — can draw traffic from an IPv4-only LAN. ## Accidental rogues Many rogue RAs are mistakes: a workstation sharing its connection, a test router or virtual machine bridged onto the office LAN, a consumer device plugged into a wall port. The symptom is the same: some hosts gain an extra prefix or default router, connections through it fail, and the problem follows whichever hosts heard the bad RA. ## RA Guard (RFC 6105) RA Guard moves the decision from every host to the **layer-2 switch**, which drops RAs that fail its criteria before they reach anyone. RFC 6105 is **Informational**: a framework for switch behaviour, not a wire protocol hosts implement. - **Stateless** RA Guard checks each RA against configuration: the port it arrived on, the sender's MAC, its IP source, the advertised prefixes and the router preference. The simplest form trusts the router's port and blocks RAs on all others. - **Stateful** RA Guard learns legitimate routers — during a manually started learning period, or by validating SEND signatures on the hosts' behalf — and then allows only those. - **Limits**: RFC 6105 says it is effective only when all traffic between IPv6 devices crosses an RA-Guard-capable layer-2 device, so it cannot help hosts that share a hub or a software bridge below the guarded port, and it offers no protection where IPv6 is tunnelled. Simple implementations have also been evaded with RAs hidden behind IPv6 extension headers or fragments, which later IETF guidance addressed. ## SEND (RFC 3971 and RFC 3972) **Secure Neighbor Discovery** (RFC 3971, Standards Track) protects all of Neighbor Discovery, not only RAs: 1. A node's address is a **Cryptographically Generated Address** (CGA, RFC 3972): its interface identifier comes from a hash of the node's public key, so the address itself shows which key may use it. 2. ND messages carry an **RSA Signature** option made with that key, plus **Timestamp** and **Nonce** options against replay. 3. Routers must hold certificates chaining to a **trust anchor** configured on hosts; hosts fetch the chain with Certification Path Solicitation and Advertisement messages. SEND therefore also stops forged Neighbor Advertisements, the IPv6 form of ARP spoofing. In practice it is rarely deployed: every host needs an implementation and provisioned trust anchors, and RFC 6105 itself calls SEND non-trivial to deploy. ## Defence in practice - Enable RA Guard on every access port, trusting only router-facing ports, and pair it with DHCPv6 Guard, since a rogue RA's M and O flags send hosts looking for DHCPv6. - Treat an IPv4-only LAN as exposed: filter RAs there too, or disable IPv6 on hosts deliberately. - Watch for unexpected RAs and new prefixes; a new default router on hosts is the earliest signal. - Expect SEND only in specialised environments that can provision trust anchors.