Gratuitous Neighbor Discovery: Creating Neighbor Cache Entries on First-Hop Routers
updates
- rfc-4861 — Neighbor Discovery for IP version 6 (IPv6)
Extracted elements (24)
Gleaning from DAD NS messages was discarded as the sole solution because it requires routers to listen to all solicited-node multicast groups (CPU impact), and the address resolution triggered during DAD may complete before the host finishes DAD, causing the host to silently ignore the router's NS per RFC 4862 Section 5.4.3.
Gratuitous NAs are sent to ff02::2 (all-routers) rather than ff02::1 (all-nodes) to reduce multicast noise. With MLD snooping enabled, these NAs are only delivered to routers on the segment rather than flooded to all nodes.
Increasing router buffer sizes was discarded because it would exacerbate the Neighbor Cache exhaustion DoS attack surface described in RFC 6583, making routers more vulnerable.
Registration-based ND (RFC 8505) was considered but discarded due to the significant implementation changes required across existing IPv6 stacks and an unclear adoption timeline, making the gratuitous NA approach preferable.
RFC 4861 Section 7.2.5 directed routers to silently discard unsolicited NAs with no existing NC entry because 'the recipient has apparently not initiated any communication with the target.' This reasoning is valid for host-to-host on-link traffic but not for host-to-router scenarios where the router needs a cache entry to forward return traffic.
The Override flag MUST NOT be set for Optimistic Addresses to comply with RFC 4429 Section 2.2, ensuring that gratuitous NAs from an Optimistic Address cannot override an existing NC entry for the rightful address owner, preventing traffic disruption.
In dual-stack networks, the packet loss problem described in this document may be hidden by Happy Eyeballs (RFC 8305), but it manifests clearly in IPv6-only environments, especially wireless environments.
Some wireless link-layer devices intercept or perform ND proxy actions on ND packets, which may prevent gratuitous NAs from reaching routers. Alternative approaches relying on NS or RS messages have the same limitation.
The solution requires cache updates on ALL first-hop routers in topologies with first-hop redundancy, since traffic may be asymmetric. Sending gratuitous NAs to ff02::2 addresses this by reaching all routers on the segment simultaneously.
A node SHOULD send up to MAX_NEIGHBOR_ADVERTISEMENT Neighbor Advertisement messages when configuring a new global IPv6 address to notify first-hop routers. These advertisements MUST be separated by at least RetransTimer seconds.
Hosts SHOULD silently discard unsolicited Neighbor Advertisements for which no Neighbor Cache entry exists, preserving RFC 4861 host behavior.
If a received unsolicited Neighbor Advertisement does not contain the Target Link-Layer Address Option and no NC entry exists, the router SHOULD silently discard the advertisement.
If Optimistic DAD is used, a gratuitous NA SHOULD be sent as soon as a new Optimistic Address is assigned to the node interface. If not using Optimistic DAD, the NA SHOULD be sent when an address transitions from tentative to preferred.
Routers SHOULD create a new Neighbor Cache entry for the target address with the link-layer address set to the Target Link-Layer Address Option (if supplied) when receiving an unsolicited NA with no existing NC entry. The entry's reachability state MUST be set to STALE.
The destination address for gratuitous Neighbor Advertisements SHOULD be set to the all-routers multicast address (ff02::2) to limit recipients to routers only.
When sending gratuitous NAs for a preferred address, the Override flag SHOULD NOT be set. If the address is in the Optimistic state, the Override flag MUST NOT be set.
Gratuitous Neighbor Advertisement (unsolicited NA) is an NA sent by a node upon configuring a new IPv6 address, targeting all-routers multicast (ff02::2), to proactively populate router Neighbor Cache entries with a STALE entry.
The Neighbor Cache entry created by a router upon receiving an unsolicited NA MUST be in STALE state and includes the link-layer address from the Target Link-Layer Address Option. This entry is used when return traffic arrives, avoiding the address resolution delay.
A malicious host could exhaust the router's Neighbor Cache by creating large numbers of STALE entries via unsolicited NAs. However, this attack vector is not new — the attacker could equivalently use NS or RS with SLLAO. All RFC 6583 recommendations still apply.
Cache spoofing attack: an attacker could attempt to install a NC entry for a victim's IPv6 address with the attacker's link-layer address. However, this document only modifies router behavior when no existing NC entry exists; existing entries are not overridden, so no new vectors are introduced for overriding existing cache entries.
In the worst-case duplicate address scenario (Section 5.3.2), an Optimistic Address duplicate can cause traffic disruption for the rightful owner for up to DELAY_FIRST_PROBE_TIME + (MAX_UNICAST_SOLICIT-1)*RetransTimer = 7 seconds. This risk is deemed acceptable due to low probability and the fact that the rightful owner can prevent it by implementing this document's mechanism.
Sending gratuitous NAs to ff02::2 may reveal a host's IPv6 addresses to on-link attackers. However, DAD already discloses this information to all nodes (when MLD snooping is absent). MLD snooping on link-layer devices can mitigate this exposure.
Existing NC entry handling upon receipt of an unsolicited NA with Override flag cleared: if entry is in REACHABLE state, transition to STALE but do not update the link-layer address; all other non-INCOMPLETE states are similarly unaffected by Override=0.
When a router receives an unsolicited NA with no existing NC entry: create STALE entry. When the STALE entry is used to forward return traffic, transition to DELAY. After DELAY_FIRST_PROBE_TIME (5 seconds), transition to PROBE and send up to MAX_UNICAST_SOLICIT unicast NSes. If no response, delete the entry.