The IPv6 neighbor discovery asymmetry

When a device joins an IPv6 network, it receives a Router Advertisement, configures a new address, and immediately begins sending packets. From the host's perspective, communication is ready to begin—it knows the link-layer address of its default router. The router, however, may not yet have learned how to reach the host's newly configured global IPv6 address. This creates an asymmetry: the host can reach the router, but the router may need to perform neighbor discovery before it can forward traffic back to the host.

Why the first packet experiences latency

When a host sends a packet to an off-link destination, the first-hop router forwards it normally. When the remote destination responds, however, the return packet arrives at the router with the host as its destination. If the router lacks a Neighbor Cache entry for that IPv6 address, it must resolve the host's link-layer address before forwarding the packet. This places neighbor discovery directly in the critical path of the first return packet, potentially causing additional latency or packet loss while address resolution occurs.

The problem is particularly notable because the host already possesses all the information the router needs. The host knows it owns the IPv6 address and knows the corresponding link-layer address, yet the router has not learned it.

How GRAND changes the information flow

Gratuitous Neighbor Discovery, defined in RFC 9131, inverts the direction of information flow. Rather than waiting for the router to discover the host when the first packet arrives, the host proactively announces its IPv6 address and link-layer address using an unsolicited Neighbor Advertisement. The router can then learn this information before it needs to forward traffic towards the host.

Implementing GRAND is not simply a matter of sending an unsolicited Neighbor Advertisement whenever an address appears. GRAND interacts with several existing Neighbor Discovery rules, including the handling of multiple addresses, anycast and proxy addresses, timing, and Duplicate Address Detection.

Building on existing RFC 4861 mechanisms

Unsolicited Neighbor Advertisements already have a defined role in Neighbor Discovery. RFC 4861 rule 7.2.6 specifies behavior for unsolicited Neighbor Advertisements, including cases such as changes to a node's link-layer address. It also limits how many advertisements a node can send for multiple addresses and recommends spacing those advertisements to avoid unnecessary congestion.

RFC 4861 rules 7.2.7 and 7.2.8 cover the special case of anycast and proxy Neighbor Advertisements. In these situations, multiple nodes may potentially respond to the same Neighbor Solicitation. If they all transmitted immediately, their purpose becomes ineffective. To address this, RFC 4861 specifies a random delay before sending an anycast or proxy Neighbor Advertisement, giving multiple potential responders a chance to avoid transmitting simultaneously.

Scheduling and queueing neighbor advertisements

One of the less obvious parts of GRAND is the scheduling of Neighbor Advertisements. The existing implementation did not previously provide the queueing and delayed-transmission machinery needed for these behaviors. Implementing GRAND required adding that infrastructure and then using it to schedule unsolicited Neighbor Advertisements.

In GRAND, a newly configured address may result in an unsolicited Neighbor Advertisement, but the implementation must consider how many addresses are being advertised and when each advertisement should be transmitted. In IPv6, an interface might have hundreds of addresses at the same time. Sending all advertisements immediately could create an unnecessary burst. For example, consider a data center after power is restored, causing many servers to start at once. The implementation therefore adds the delayed advertisement behavior described by RFC 4861 7.2.6 and the randomized response behavior described in 7.2.7 and 7.2.8.

The goal is not simply to minimize the time before an advertisement is sent. It is to balance fast neighbor discovery with the amount of multicast traffic generated by that discovery.

What RFC 9131 changes in router behavior

RFC 9131 builds on these Neighbor Discovery mechanisms to address the first-packet problem. A host sends an unsolicited Neighbor Advertisement when a new IPv6 address becomes usable. The advertisement contains the information that a first-hop router needs to construct a neighbor entry.

Under the original RFC 4861 behavior, receiving an unsolicited Neighbor Advertisement does not necessarily mean that a router with no existing Neighbor Cache entry will create one. RFC 9131 changes this behavior. A router receiving a valid unsolicited Neighbor Advertisement for an address for which it has no existing Neighbor Cache entry can create one using the information supplied in the advertisement. The entry is created in the STALE state, a detail that makes GRAND useful for the first-packet problem.

Why STALE state is critical

Putting a newly learned neighbor into STALE may seem counterintuitive, but the distinction is important. GRAND tells the router that the host is claiming the IPv6 address and provides a link-layer address. It does not necessarily prove that the neighbor is currently reachable in the sense used by Neighbor Unreachability Detection.

STALE allows the router to use the information it has already learned without requiring a new multicast address-resolution operation. The router can subsequently verify reachability using the normal Neighbor Discovery mechanisms. This means that GRAND removes address resolution from the critical path of the first packet without claiming that the neighbor has been permanently verified as reachable.

FreeBSD implementation details

Implementing GRAND in FreeBSD involved more than adding code to transmit an unsolicited Neighbor Advertisement. The existing IPv6 Neighbor Discovery implementation already provided state machines, address lifecycle handling, Duplicate Address Detection, and Neighbor Cache management. However, it did not previously provide the queueing and delayed-Neighbor-Advertisement machinery required for GRAND and the related RFC 4861 behaviors.

The GRAND implementation added that infrastructure. It also implements the relevant delayed and randomized advertisement behavior from RFC 4861 rule 7.2.7 and 7.2.8. This includes handling the timing of advertisements so that multiple addresses, anycast addresses, and proxy-related advertisements do not unnecessarily produce bursts of Neighbor Discovery traffic.

The implementation combines several pieces of Neighbor Discovery behavior:

  • Proactively advertising newly usable IPv6 addresses
  • Handling link-layer address changes
  • Adding queueing for Neighbor Advertisements
  • Delaying multiple unsolicited advertisements
  • Applying the appropriate randomization for anycast and proxy responses
  • Integrating the new scheduling machinery with the existing ND state and timer handling

The result is not a separate "GRAND subsystem", but rather an extension of the existing Neighbor Discovery implementation with new queueing and transmission-scheduling support.

Link-layer address changes

GRAND also connects naturally to one of the existing uses of unsolicited Neighbor Advertisements. RFC 4861 rule 7.2.6 defines unsolicited advertisements for situations such as a change in the link-layer address. If an interface's link-layer address changes while its IPv6 addresses remain configured, other nodes may still have cached information referring to the previous link-layer address. The implementation can proactively advertise the new mapping rather than waiting for normal Neighbor Discovery to discover the change.

This means that the GRAND implementation covers two closely related situations: an IPv6 address becomes usable, or the link-layer mapping for an existing IPv6 address changes. In both cases, the objective is the same: make the information available to neighbors before they are forced to discover it reactively.

Lessons from kernel integration

The implementation highlighted an important difference between implementing a protocol on paper and integrating it into an existing networking stack. The RFC describes the desired protocol behavior, but the kernel did not previously have all of the mechanisms needed to implement it. In particular, GRAND required new queueing and delayed-transmission support for Neighbor Advertisements.

Adding GRAND therefore meant introducing those mechanisms and making sure that they interacted correctly with the existing address lifecycle, DAD, Neighbor Cache management, and Neighbor Discovery state handling. GRAND-generated advertisements have different semantics from other Neighbor Advertisements, which required changes to the way advertisements are queued, combined, delayed, and eventually transmitted.

The timing requirements also make the implementation more interesting than simply generating packets immediately. The implementation needs to avoid creating unnecessary bursts while still making the information available early enough to solve the first-packet problem. This is where the details in RFC 4861 rules 7.2.6-7.2.8 become important in practice. They are not merely historical protocol details; they provide the rules needed to make proactive Neighbor Discovery behave well on a real network.

Relevance for IPv6 deployments

Neighbor Discovery is often invisible when everything works correctly, and this is exactly what makes issues like this easy to overlook. The protocol is normally fast enough that users never think about it. But Neighbor Discovery can sit directly on the forwarding path, which means that its behavior can affect the first packet of a connection.

This becomes increasingly relevant as IPv6 hosts dynamically configure and remove addresses. Privacy addresses, changing prefixes, mobile devices, virtual machines, containers, and other environments can all result in addresses appearing and disappearing during the lifetime of an interface. GRAND allows the network to learn about a new address at the time the address becomes available rather than waiting until traffic forces that discovery to happen. And at the same time, the timing mechanisms inherited from the Neighbor Discovery design help ensure that proactive advertisements do not themselves become a source of unnecessary multicast traffic.

GRAND is not just an interesting optimization described in an RFC. RFC 9898, Neighbor Discovery Considerations in IPv6 Deployments, explicitly identifies GRAND as a mechanism that addresses the router forwarding delay caused by this form of Neighbor Discovery. This is important because it places the problem in the context of actual IPv6 deployment rather than treating it as a theoretical protocol issue.