Summary

  • A host may send through its router before that router has the neighbour-cache information needed for the return packet.
  • GRAND moves address information earlier, but its implementation makes queueing, timing and burst control part of the engineering problem.

The most revealing network failures are often not failures of steady-state reachability. They occur in the interval before the network has learned enough to complete the first exchange. The technical account by Seyed Pouria Mousavizadeh Tehrani focuses on this IPv6 first-return-packet asymmetry: a host can transmit through a router while the router still lacks the neighbour mapping required to deliver the response back to that host.

That distinction changes the question an operator should ask. “Can the address be reached?” is not sufficient. The better question is whether neighbour state exists at the moment the first response needs it. A cache transition can therefore become an application-visible delay or loss mechanism without implying that the route itself is absent.

Seyed Pouria Mousavizadeh Tehrani is identified by RIPE Labs and FreeBSD as a FreeBSD source committer working on Internet and network protocols. RIPE Labs describes work across datacentres, ISPs and network-development teams, as well as IRNOG steering and presentation work. FreeBSD’s public review and committer records provide a separate account of source participation and network-focused review activity. Those records establish a technical role; they do not establish institutional authority, broad deployment or an operational result for every change associated with his name.

The approach described as GRAND moves address information earlier by sending an unsolicited Neighbour Advertisement. Under the conditions specified by RFC 9131, a receiving router can create a STALE neighbour-cache entry. STALE is not a promise of permanent correctness. It is a qualified form of state: the receiver has an address-to-link-layer association available, while the protocol retains a path for confirmation or replacement when traffic requires it.

The FreeBSD implementation account also makes clear why “send information earlier” is not a complete design. Proactive advertisements can become an uncontrolled burst when many addresses are involved, or when anycast and proxy addresses broaden the set of possible recipients. Queueing, delayed transmission and randomisation constrain that work. Timing is therefore not an implementation afterthought. It is part of the safety boundary.

The available evidence does not establish that the subject invented GRAND or RFC 9131. Nor does it establish measured latency reduction, fewer packet drops, broad adoption or production deployment. Its value is more precise. It shows a person working where protocol semantics, kernel state and operational timing meet, and it makes the implementation problem legible without turning a technical account into an outcome claim.

Those choices are easiest to understand by following the first packet through the stack. An IPv6 host wants to communicate with a destination outside its local link. It selects a default router and sends the outgoing packet toward that router. The router can receive the packet and may know how to forward it toward the destination. The return path, however, may require the router to place a packet on the host’s local link. To do that, the router needs a link-layer mapping for the host’s IPv6 address. If that neighbour-cache information is absent, the router must discover it before it can deliver the response.

The resulting asymmetry is easy to miss because the original request has already crossed the first apparent boundary. A test that records only whether the host can transmit may report success. A test that begins after the cache has been populated may also report success. The failure is located between those observations: after the host’s request has been accepted, but before the router is ready to forward the corresponding return packet at the link layer.

This is why first-packet behaviour deserves separate treatment from ordinary reachability. A route table answers a question about where traffic should go. A neighbour cache answers a more immediate question about how a packet reaches the next device on a local link. Both are forms of state, but their lifecycles and failure modes differ. A route can remain valid while the next-hop mapping is missing, stale, delayed or being refreshed. The application experiences only the delay or loss, not the distinction between those internal causes.

The distinction also matters for interpreting measurements. A warm-path probe may show stable response time while a cold-path connection experiences a pause. Repeating a test too quickly can hide the problem because the first attempt has populated state for the next one. Conversely, a test that treats every first response as a routing failure may misdiagnose a neighbour-discovery transition. The correct interpretation requires observing the cache state and its transitions alongside packet timing.

GRAND addresses the timing of that knowledge. Rather than waiting for a router to discover a host only after it needs to send a packet back, an unsolicited Neighbour Advertisement can communicate address information earlier. RFC 9131 defines Gratuitous Neighbour Discovery and the conditions under which an unsolicited advertisement can create a STALE neighbour-cache entry. The purpose is not to establish a permanent assertion that never needs checking. It is to place usable, explicitly non-fresh state in the receiving system before the first return packet creates an urgent demand for it.

The word STALE carries much of the design’s meaning. A STALE entry is not equivalent to a recently confirmed, permanently trusted mapping. It tells the stack that an address-to-link-layer association is available, while preserving a protocol path through which the association can be confirmed or replaced when traffic requires it. In operational terms, the mechanism trades an entirely empty cache for a piece of state whose freshness is deliberately qualified.

That trade can be valuable because a cold-start problem is not always solved by adding more capacity to the steady-state path. The obstacle may be the order in which events occur. If a response arrives before the router has a mapping, the router has to initiate discovery at exactly the moment an application is waiting. If the mapping is already present in STALE form, the forwarding decision can proceed while the stack handles confirmation according to the neighbour-discovery rules. The mechanism therefore shifts work from a reactive moment to an earlier, more controlled phase.

But moving work earlier also creates a new responsibility. A host or service may have many addresses. Some addresses may be anycast, so more than one system can represent the same service address. Others may be proxy addresses, where a device answers or forwards on behalf of another endpoint. In those cases, a proactive advertisement is not simply one harmless message sent once to one obvious neighbour. The implementation must consider the number of addresses, the number of possible recipients and the possibility that several events occur together.

The reported FreeBSD implementation uses queueing, delayed transmissions and randomisation to keep proactive work bounded. Each measure addresses a different risk. Queueing gives the system a place to hold work rather than forcing every advertisement into the immediate transmission path. Delayed transmission prevents a large address set from becoming an instantaneous burst. Randomisation reduces synchronised behaviour in which many advertisements that were logically independent become physically simultaneous.

These mechanisms do not prove a deployment-level improvement, and the available evidence does not establish measured latency reduction, fewer packet drops or broad adoption. Their importance is architectural. They show that an apparently small protocol action has resource consequences. A design that improves readiness by emitting unlimited control traffic could exchange one cold-start problem for congestion, queue pressure or contention with ordinary traffic. The implementation must therefore define not only what information is sent, but when it may be sent and how much unfinished work the system may retain.

Queueing also makes policy visible. A queue has a capacity, an admission rule and a service rate, whether those properties are documented or merely emerge from code. If advertisements accumulate faster than they can be transmitted, the queue becomes a second state machine. Items may wait, be coalesced, be discarded or be reordered. Each choice affects which address information is available first and how an operator should interpret a delayed result.

A bounded queue can protect the rest of the stack, but it can also create a limit that users discover only under scale. A service with a small address set may remain within the intended operating envelope. A host using many addresses may encounter deferred or discarded proactive work. Anycast and proxy configurations may make the effective workload less obvious than a simple address count suggests. Testing must therefore vary not only packet rate but also address cardinality and address role.

Delay is similarly double-edged. A delay can flatten a burst and allow other work to proceed. It can also mean that the advertisement arrives too late to help the first return packet it was intended to prepare for. The right question is not whether delay exists, but whether the delay, queue service and application timing form a predictable relationship. If they do not, an operator may see intermittent first-packet behaviour that looks like random network unreliability.

Randomisation introduces another operational consideration. It can prevent synchronisation, but it makes individual event timing less deterministic. Aggregate behaviour may improve while a single transaction sees a different preparation interval from the next. That is not necessarily a defect; it is a consequence of trading synchronised bursts for distributed work. It does mean that a test based on one request or one fixed timeout is unlikely to characterise the whole behaviour.

The implementation problem is therefore a problem of bounded proactive state. The state should exist early enough to help, but not so aggressively that it overwhelms the system. It should be explicit enough to inspect, but not mistaken for proof that the mapping is permanently current. It should accommodate many, anycast and proxy addresses without allowing those cases to erase the safeguards designed for ordinary hosts.

Seyed Pouria Mousavizadeh Tehrani’s wider FreeBSD record helps explain why this kind of work is best understood through reviewable control surfaces. FreeBSD identifies him as a source committer working on Internet and network protocols, and its public review system binds the relevant account to network and transport project memberships and review activity. A January 2026 FreeBSD record adds him as a source committer with Gleb Smirnoff as mentor. These records establish role and participation; they do not establish sole authorship of every related network-stack change or prove production effects.

The same boundary applies to the other technical examples associated with his 2026 work. A FreeBSD status report describes routing-metric support reaching CURRENT and lists kernel and userland surfaces including rtsock, netlink, route and netstat. A source commit attributes a route-metric implementation change to him and shows the nexthop-selection and control-plane files changed. Separately, a project report describes GENEVE work across kernel, netlink, ifconfig, manual, tests and ECN-related review units.

Routing metrics and GENEVE are not parts of the GRAND mechanism in this account. They should not be presented as evidence that GRAND has been deployed widely or improved measured outcomes. They are bounded examples of a broader implementation practice: network behaviour is made visible across interfaces, control paths, documentation and tests rather than being treated as an isolated packet-processing trick. The value of that evidence is about how work is decomposed and reviewed, not about the operational reach of any one feature.

That distinction matters in a profile. Public technical work can easily be flattened into a claim that one person “solved IPv6”. The evidence supports something narrower and more credible. It shows a person working in the source, review and protocol spaces where hidden state becomes a design concern. His technical account makes the causal chain legible: first-return asymmetry, neighbour state, unsolicited advertisement, STALE handling, queueing, delay and randomisation. His other records show related attention to explicit network-control surfaces.

None of that permits claims about traffic scale, customer count, uptime, commercial success or institutional authority.

A public association with AS214145 adds another piece of identity context. PeeringDB associates the full name and SPMZT label with that autonomous system and the spmzt.net website, while bgp.tools independently shows AS214145 as an active personal network originating IPv4 and IPv6 space. This is useful as a public network identity chain. It is not evidence of traffic volume, customer base, reachability quality, uptime or commercial scale. A personal network identity should not be turned into an institutional credential.

The operational lesson is to test the cold path as a first-class path. An operator should begin with a state table, not merely a success-rate table. At minimum, the test should record whether the relevant neighbour entry is absent, INCOMPLETE, STALE or otherwise changing; when the first request is sent; when the first response is expected; when the mapping becomes usable; and when confirmation traffic occurs. The exact state names and transitions should be interpreted according to the implementation under test, but the principle is general: packet outcome without state context is incomplete evidence.

A useful test sequence separates cold and warm conditions. The cold condition begins after the relevant neighbour state has expired or been removed, subject to the test environment’s controls. The warm condition repeats the same exchange after a successful interaction has populated or refreshed state. Comparing only the two outcomes can identify a cold-start effect; inspecting the transitions can show whether the effect is caused by discovery, proactive advertisement, queueing or timer behaviour.

The test should also distinguish the direction of the first packet. The host-to-router leg may succeed while the router-to-host return leg waits. A measurement taken at the host alone can therefore understate the internal sequence. Captures or counters at the host, router and relevant interface can show whether the request was forwarded, whether a response reached the router, whether the router attempted neighbour discovery and when the response was finally emitted on the local link.

Timing should be treated as a distribution rather than a single threshold. Delayed and randomised advertisements mean that repeated trials may not have identical preparation intervals. Report at least the cold-start distribution, warm-path distribution, queue occupancy and advertisement count. A single average can hide a small but consequential tail. A failure budget should also distinguish a dropped advertisement from a dropped application packet; they are related events, but they are not interchangeable measurements.

Address scale is a required dimension. Begin with one ordinary address, then increase the number of addresses while holding the application workload stable. Repeat the exercise with anycast and proxy configurations where they are legitimately part of the design. Observe whether queue depth, delay, advertisement rate or cache transitions change. The purpose is not to assume that scale causes failure, but to reveal whether the safeguards remain within their intended envelope.

Timer tests should vary the relationship between advertisement timing, neighbour-state ageing and application timeout. A proactive message that arrives just before a request may produce a different result from one that arrives just after the request has triggered reactive discovery. Repeating the test around those boundaries can reveal a race that a broad average conceals. It can also show whether an apparent improvement depends on a narrow timing coincidence.

Operators should inspect the negative cases as carefully as the successful ones. What happens when the queue is full? What happens when several addresses become eligible together? What happens when a mapping is stale but wrong, or when the expected recipient is not the only possible recipient? What happens when a timer expires during a delay? The answer should be observable in counters, logs, packet traces or documented state transitions. If it is not, the system may still function, but its failure modes will be expensive to distinguish from ordinary routing or application faults.

The same approach applies to change review. A patch that adds proactive signalling should be reviewed for message construction, admission control, queue ownership, timer behaviour, randomisation, address enumeration and interaction with existing neighbour discovery. Tests should cover both the protocol’s intended path and resource-exhaustion boundaries. Documentation should state which behaviour is guaranteed, which is best effort and which depends on deployment configuration.

The review question is not simply “does the advertisement appear?” It is “what state does it create, for how long, at what cost, and under what conditions can the system decline to create it?”

This is where the broader FreeBSD examples are relevant without becoming evidence for GRAND outcomes. Routing-metric work that spans kernel and userland surfaces shows why a network-control feature cannot be evaluated only at the point where a forwarding decision is made. Operators need a way to inspect and configure the behaviour. The GENEVE work, described across kernel, netlink, ifconfig, manuals, tests and ECN-related review units, similarly illustrates decomposition into interfaces and verification surfaces. Those examples do not demonstrate the performance or adoption of GRAND.

They show why explicit boundaries matter when control behaviour crosses layers.

The first-packet problem also has an organisational dimension. Different teams may own the host, the router, the application timeout and the monitoring system. Each team can observe a locally reasonable fact: the host sent the request, the route exists, the application retried or the router eventually delivered traffic. Without a shared model of neighbour state, the incident can move between teams as an apparently intermittent fault. A state-oriented runbook gives the teams a common object of investigation.

Monitoring should consequently include indicators that ordinary availability dashboards omit. Useful signals include cold-versus-warm first-response latency, the proportion of requests encountering an absent or incomplete neighbour entry, STALE-entry creation and confirmation, proactive-advertisement counts, queue depth and drops, timer expiries and the distribution of addresses represented in a burst. These indicators should be interpreted as diagnostics, not as proof that any one mechanism is responsible. Correlation with packet traces and controlled tests remains necessary.

The trigger for escalation can be a difference between cold and warm behaviour, not merely an absolute outage. A service may be reachable in synthetic tests that reuse state while real clients repeatedly encounter cold paths. A response that is delayed only during neighbour-state creation can still breach an application timeout. Conversely, a small timing difference may be harmless for one protocol and material for another. The correct threshold depends on the service, but the measurement must expose the state transition before a threshold can be chosen intelligently.

A staged rollout, where available, should begin with observation. Record the existing cold-path behaviour, then enable or test proactive behaviour for a constrained address set and compare state, timing and resource indicators. Expansion should depend on queue and burst behaviour as well as application outcomes. Because the supplied evidence does not establish broad production deployment or measured improvement, any organisation considering such a change must generate its own evidence rather than treating the technical account as a guarantee.

The central idea is simple but easy to lose: readiness is a resource. A network stack can know a route without knowing the next-hop mapping. It can know a mapping without knowing whether it is fresh. It can have a mechanism for refreshing the mapping without having enough queue capacity or timer budget to use that mechanism under a burst. Each layer of readiness has a lifecycle, and each lifecycle can become visible to the application when events arrive in an unlucky order.

GRAND’s contribution in this framing is not magic preloading. It is a protocol-supported way to move selected information earlier while preserving a qualified cache state. The engineering work lies in making that earlier state safe, bounded and inspectable. The implementation details—queueing, delayed transmission and randomisation—are not secondary polish. They determine whether proactive information remains a controlled aid or becomes another source of contention.

Seyed Pouria Mousavizadeh Tehrani’s public work is therefore best read as a study in network control under incomplete visibility. The visible symptom may be a slow or missing first response. The underlying issue may be that the network has not yet crossed a state boundary that steady-state tests assume away. The remedy is not to declare every such symptom a routing defect, nor to assume that a protocol mechanism guarantees improvement. It is to describe the state transition, constrain its cost, instrument its timing and test the cases in which the system is least prepared.

The measurement contract around a first reply

A credible first-packet test needs a stricter contract than “clear the cache and run ping”. Cache removal is only the opening condition. The test also has to state which node’s cache was cleared, which address became usable, whether Duplicate Address Detection had completed, whether an unsolicited advertisement was eligible to be sent and which packet was designated as the first return packet. Without those facts, two engineers can reproduce different sequences while believing they ran the same experiment.

The observation points should be fixed before the trial. A host trace can establish when the request left and when a response arrived. A router-side trace can establish when the return packet reached the first hop and whether neighbour resolution delayed local delivery. State inspection can show whether an entry was absent, created as STALE, moved through another state or was replaced. Queue and timer instrumentation can then connect packet timing to implementation work. No single observation provides the whole causal chain.

Repeated trials also need an independence rule. If one attempt creates state used by the next, the second attempt is not another cold start. The test harness should either restore the declared initial state or classify the next trial as warm. That discipline matters because a system can look reliable after the first attempt while still imposing a material delay on every genuinely new address. It also prevents a successful retry from erasing evidence about the failed or delayed first exchange.

The result should be reported as linked observations rather than a single verdict. For each trial, record the initial neighbour state, address count and role; the advertisement eligibility and send time; queue admission and delay; return-packet arrival at the router; local-link transmission; application response time; and final cache state. A reader can then see whether the proposed mechanism moved state early enough, whether it stayed within its resource limits and whether the application outcome followed the expected sequence.

This reporting structure sets a boundary around inference. If the router created a STALE entry before the response arrived and the response crossed the local link without reactive resolution, the trace supports a mechanism-level finding for that environment. It still does not prove broad adoption, universal compatibility or a durable reduction in user-visible loss. If the response improved but queue and state evidence are missing, the test has an outcome correlation, not a demonstrated mechanism. Both results can be useful when named accurately.

Why the surrounding FreeBSD work matters

The routing-metric record offers a useful comparison because it exposes the difference between internal behavior and operable behavior. The FreeBSD status report does not stop at a kernel decision rule. It names rtsock and netlink control surfaces and the route and netstat tools through which an operator can configure or inspect metric values. The associated source commit shows that the change reaches nexthop selection and control-plane structures. Those details do not prove an operational benefit, but they make the feature’s location and observable surface more concrete.

The GENEVE report makes a different comparison. It describes a feature divided across a kernel module, netlink and ifconfig integration, documentation, tests and ECN-related reviews. The report explicitly preserves the status of separate review units rather than presenting the entire body of work as one completed fact. That decomposition is important evidence about method: a network feature can cross several interfaces, and progress in one part does not silently certify the others.

Applied to GRAND, the same discipline asks where each obligation lives. Protocol rules define when unsolicited information is valid and what receiving state it may create. Kernel code owns address lifecycle, cache transitions, queues and timers. Configuration determines whether and where behavior is enabled. Tests establish bounded observations. Documentation tells an operator what can be relied upon. Monitoring exposes whether the actual workload stays inside the assumptions. A weakness in any one surface can leave the packet mechanism technically present but operationally hard to trust.

That is the substantive connection among the three episodes. They are not one programme, and routing metrics or GENEVE cannot be used as evidence that GRAND has succeeded in deployment. They show why network-control work becomes credible through explicit interfaces, limited claims and reviewable transitions. The person-centred significance is not a heroic claim about solving IPv6; it is the repeated choice to turn hidden control-plane behavior into something other engineers can inspect, challenge and test.

Sources