Unicast Unsolicited Router Advertisements for Propagating Network Configuration Updates

IPv6 Neighbor Discovery (ND) relies heavily on multicast Router Advertisements (RAs) to convey configuration changes, prefix information, and routing updates to connected hosts. However, on IEEE 802.11 (Wi-Fi) networks, multicast frames are known to be unreliable, especially for battery-powered devices such as mobile phones. Such devices often drop incoming multicast packets due to power-saving mechanisms. As a result, critical network state updates transmitted via Router Advertisements (RAs), such as on-link prefix modifications, are not propagated to hosts in a timely manner. Operating with stale network configurations leads to degraded connectivity and poor user experience. Mechanisms like attempt to improve renumbering and configuration update reliability by retransmitting RAs, selecting optimal timer values and transmission counts that suit all network environments remains challenging. This document updates by allowing routers to send unicast RAs to active and known hosts upon detecting critical configuration updates, significantly improving delivery reliability on lossy multicast media like Wi-Fi.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

As described in , network configuration changes (such as flash renumbering, DNS server updates, or lifetime reductions) require fast and dependable delivery to hosts. On wireless media, multicast packet loss can cause subset of hosts to miss multicast RAs, leading to stale configuration, broken connectivity, or security vulnerabilities. Increasing the frequency or count of unsolicited multicast RAs increases multicast traffic overhead and battery consumption on mobile endpoints. Furthermore, no single set of timers or RA repeat counts works reliably across all wireless network conditions and scales.

This document modifies the behavior specified in Section 6.2.4 ("Sending Unsolicited Router Advertisements") of .

When an IPv6 router detects a configuration change that needs to be propagated to connected hosts on an interface, it SHOULD send unicast Router Advertisements to every IPv6 link-local address recorded in its Neighbor Cache for that interface that is currently in either the REACHABLE or STALE state. Those unicast RAs are sent in addition to any multicast unsolicited RAs sent in accordance with . Examples of configuration changes that trigger this mechanism include, but are not limited to: An interface becomes an advertising interface (see , Section 6.2.1, "Becoming an Advertising Interface"). The link-local address of the router changes. Any timer in the Router Advertisement header or RA options changes increased or changed from a non-zero value to zero value An RA option is added (e.g., Prefix Information Option, Recursive DNS Server Option, Route Information Option).

To prevent bursty packet transmission and avoid network congestion when a large number of neighbors exist in the Neighbor Cache, the triggered unicast RAs MUST NOT all be transmitted simultaneously. Instead, the router MUST spread the transmission of unicast RAs evenly over a period of MAX_RA_DELAY_TIME seconds (as defined in Section 10).

Routers SHOULD provide a configuration option allowing network administrators to enable or disable this unicast update propagation behavior on a per-interface basis.

A potential concern with sending unicast RAs to all hosts is router CPU and network queue overhead. However, the total number of unicast RA packets sent during a configuration update is at most equal to the number of active host entries in the neighbor cache (specifically those in REACHABLE or STALE state). Because these packets are unicast (and thus transmitted at higher unicast Wi-Fi data rates with L2 retry mechanisms) and spread across MAX_RA_DELAY_TIME seconds, the resulting packet rate and bandwidth usage are negligible compared to standard data traffic and normal Neighbor Discovery protocol exchanges (such as NS/NA exchanges).

This document has no IANA actions.

This document introduces no new security vulnerabilities beyond those already discussed in . Using unicast RAs improves network stability by ensuring hosts promptly receive security-critical updates (e.g., deprecation of invalidated prefixes or updated DNS servers).

The author would like to thank Lorenzo Colitti for valuable discussions, feedback, and input on this optimization proposal.