router advertisement
termThe ICMPv6 message, type 134, in which an IPv6 router announces itself, its prefixes and how hosts should configure.
Router advertisements are how an IPv6 host learns its default router, its on-link prefixes and whether SLAAC or DHCPv6 is on offer; DHCPv6 has no way to supply the default route. Without one a host keeps only its link-local address; a rogue one takes over its default router.
Routers send them unsolicited, by default at intervals of up to 600 seconds, and immediately in answer to a Router Solicitation, which a host sends up to three times, four seconds apart, when an interface comes up. The source must be the router's link-local address and the hop limit 255. The header holds the M and O flags, which only signal that addresses or other configuration are available from DHCPv6, and a Router Lifetime, where zero means the router must not be used as a default.
The options do the configuring. Each Prefix Information option has an L flag for on-link use, an A flag that permits SLAAC, and valid and preferred lifetimes, by default 30 and 7 days; other options carry the link MTU, DNS servers (RDNSS, type 25) and the NAT64 prefix (PREF64, type 38).
The failures follow from trust and lifetimes. Any node can send one, and accidental rogue RAs are common; RA-Guard on switch ports is the usual remedy. An unauthenticated RA cannot cut a valid lifetime below two hours, so after a renumbering hosts can keep a stale prefix for days; RFC 9096 asks customer edge routers to cap lifetimes at 45 and 90 minutes. rdisc6 solicits and prints them, and Wireshark shows them as icmpv6.type == 134.
Also known as: ra, ipv6 ra, router solicitation, rs, icmpv6 type 134
Sources
- RFC 4861, Neighbor Discovery for IP version 6 (IPv6), September 2007: sections 4.1, 4.2, 4.6.2, 6.2.1, 6.3.7 and 10 (read 2026-10-18)
- RFC 4862, IPv6 Stateless Address Autoconfiguration, September 2007: sections 5.5.2 and 5.5.3 (read 2026-10-18)
- RFC 6104, Rogue IPv6 Router Advertisement Problem Statement, February 2011: sections 1, 2 and 6 (read 2026-10-18)
- RFC 9096, Improving the Reaction of Customer Edge Routers to IPv6 Renumbering Events, August 2021: sections 3 and 4 (read 2026-10-18)