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 all active hosts on that interface. The router identifies these hosts by extracting all unique link-layer addresses from REACHABLE or STALE Neighbor Cache entries on that interface, provided those entries are not associated with routers (i.e., the IsRouter flag is FALSE and corresponding NAs do not have the R flag set). 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).

When sending unicast RAs to active hosts, the router MAY use either of the following approaches: IP-layer unicast: The router uses the link-local IPv6 address of each host as the IPv6 destination address. In this case, when identifying active hosts, the router MUST only search for link-local addresses in the REACHABLE or STALE state within its Neighbor Cache. L3 multicast with L2 unicast mapping: The router sends an IPv6 multicast packet addressed to the all-nodes multicast group (ff02::1), but maps it to the Ethernet link-layer unicast address of the targeted host, as described in . The latter approach (L3 multicast over L2 unicast) offers several practical benefits: Avoids unnecessary ND probingr. Transmitting L3 unicast traffic to a host whose Neighbor Cache entry is in the STALE state causes the entry to transition to DELAY. After 5 seconds (DELAY_FIRST_PROBE_TIME), the router will initiate unicast NS probes to re-confirm reachability. Using L3 multicast avoids triggering these state transitions and eliminates the associated unicast ND overhead. Consistency with existing practices in enterprise Wi-Fi APs, where multicast-to-unicast conversion is often enabled. Simplified implementation via POSIX APIs, as it can be achieved using ICMPv6 sockets rather than packet sockets.

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).

To prevent excessive RA transmissions during periods of network instability and to avoid configuration oscillation on host interfaces, a router MUST implement a dampening mechanism for unicast unsolicited RAs. If a router detects more than ND_UURA_MAX_FLAP configuration change events within an interval defined by ND_UURA_MAX_FLAP_INTERVAL, it MUST suspend the transmission of unicast unsolicited RAs for a duration of ND_UURA_DELAY. The default protocol parameters for dampening are defined as follows: ND_UURA_MAX_FLAP: 3 events ND_UURA_MAX_FLAP_INTERVAL: 10 seconds ND_UURA_DELAY: min(30 seconds, MinRtrAdvInterval)

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

Enterprise Wi-Fi networks often convert IP-layer multicast traffic into link-layer unicast frames . Networks with this functionality enabled do not benefit from the optimizations proposed in this document. Thetefore the administrators of such networks do not need to enable the suggested mechanism.

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 Brian Carpenter, Lorenzo Colitti, David 'equinox' Lamparter, Ole Troan for their feedback, comments, and guidance.