Summary

  • A September implementation account explains how FreeBSD added proactive IPv6 neighbour announcements; the cited code changes date from March, not September.
  • The revealing change separates announcement accounting from delayed replies. A shared queue does not make two messages equally disposable.

A computer can be ready to send before its router is ready to send back. Once an IPv6 host has learned its default router’s link-layer address, it can reach an off-link destination. The returning packet may still find the router without a mapping for the host’s new global address. The ensuing discovery exchange puts waiting—and potentially loss—at the beginning of an otherwise working connection.

On September 4, Seyed Pouria Mousavizadeh Tehrani described the FreeBSD work on Gratuitous Neighbor Discovery, or GRAND. The useful detail is not simply that the host can announce itself earlier. It is how an operating system accommodates that announcement alongside messages it already owes other participants.

This is an implementation explanation, not a new September release or an independently measured improvement. The initial commit dates from March 5. It added support around newly usable global addresses, link-layer changes and queued advertisements. A follow-up committed on March 19 made the distinction between GRAND and delayed solicited replies explicit.

An announcement and an answer are different work

The later commit describes separate treatment for the two classes. Its stated intent includes replacing a pending GRAND notification for the same interface address, reusing its queue storage and freeing non-GRAND reply entries without the announcement’s extra retention interval. Its quota-counting change excludes non-GRAND entries from the GRAND count.

These are implementation rules, not an assertion that normal replies face no other resource limits. Nor does a shared scheduling mechanism imply two physical paths or guaranteed reply priority. The narrower point is that the cost-control rule for one class should not silently become the rule for another.

Why distinguish them? A fresh notification can supersede an older pending announcement about the same local address. A reply may instead be answering a different request. Treating both as interchangeable entries can obscure which obligation a cancellation or limit is meant to affect. That is an analytical reading of the design problem, not a reported production failure or a claim that every possible interleaving in the cited patch has been tested.

Earlier information still needs a willing receiver

RFC 9131, published in 2021, supplies the protocol background. Its optimisation needs both sides: the host sends information about a new global address, and the router creates a previously missing cache entry from a valid advertisement carrying the required link-layer information. The entry is STALE, not a declaration that reachability has been confirmed.

The notification is directed towards first-hop routers, and repeated advertisements must be spaced. Existing-entry processing is not simply replaced. A sender-side implementation therefore cannot establish the whole outcome: the message must arrive, the receiving router must apply compatible behaviour and the mapping must still exist when it is needed.

The older Neighbour Discovery specification already explains why sending immediately is not always the right answer. Multiple addresses can produce bursts; anycast and proxy replies introduce timing considerations. Unsolicited advertisements can be lost. Scheduling work is part of making an optimisation coexist with a shared link, not merely an incidental coding detail.

The important counterexample is a router whose cache is cleared after the host announced its address. Another is an address used again after a long quiet period and cache eviction. RFC 9131 explicitly leaves such gaps. GRAND does not remove the need for ordinary discovery, buffering or subsequent reachability checks.

A meaningful acceptance exercise would therefore mix new-address announcements with delayed replies, remove an address while work is pending, and observe more than the first successful exchange. It would also cover a missed announcement, a cleared cache and, where applicable, multiple first-hop routers. These are proposed operator checks, not experiments performed for this article.

The sources establish the protocol rules, the implementation authors’ intentions and specific historical changes. They do not establish deployment share, inclusion in every supported release, measured latency savings or an outage caused by these queues. The commercial question is whether an optimisation can reduce initial friction without making its own housekeeping a new source of uncertainty.