| Internet-Draft | Unicast Unsolicited RAs | July 2026 |
| Linkova | Expires 23 January 2027 | [Page] |
Multicast transmissions on Wi-Fi links are known to be unreliable, making the propagation of critical network configuration changes via multicast Router Advertisements (RAs) prone to failure or severe delay. Existing approaches to improve reliability, such as sending multiple unsolicited multicast RAs, require fine-tuning timers and packet counts that may not fit all deployment scenarios.¶
This document updates RFC 4861 by introducing an optimization: when a router detects a configuration change that must be propagated to hosts, it sends unicast Router Advertisements to every client recently observed on that interface.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 23 January 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
IPv6 Neighbor Discovery (ND) [RFC4861] 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 [I-D.ietf-6man-slaac-renum] 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 [RFC4861] 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
As described in [I-D.ietf-6man-slaac-renum], 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 [RFC4861].¶
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.¶
Examples of configuration changes that trigger this mechanism include, but are not limited to:¶
An interface becomes an advertising interface (see [RFC4861], 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 [RFC4861] 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 [RFC4861]. 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.¶