Summary
- IPv6 Neighbor Unreachability Detection records a narrow, time-bounded claim: recent evidence showed that the one-way path delivered packets to a neighbor's IP layer. When that evidence ages,
REACHABLEbecomesSTALE; use then moves the entry throughDELAYandPROBEunless fresh confirmation arrives. - RFC 7048 can retain a cached link-layer address and probe more patiently when no alternate neighbor exists. That continuity choice does not authenticate the neighbor, prove address ownership, authorize an action or certify an application outcome.
An incident console shows a host with a neighbor-cache entry marked STALE. Someone writes, “the neighbor went stale at 14:07.” The phrase quietly turns a state of knowledge into a state of the world. It sounds as though a router, server or appliance deteriorated at a known moment.
Nothing in the label supports that story.
What became stale was the positive evidence. IPv6 Neighbor Unreachability Detection, or NUD, keeps a bounded record of whether a forward path was recently shown to work. A timer can expire without a packet failing. A cached link-layer address can remain useful without being freshly confirmed. A later packet can trigger a pause and a probe. The protocol is not indecisive; it is unusually careful about the difference between remembered location and current reachability.
Erik Nordmark is part of the documented standards history behind that care. He is one of four authors of RFC 4861, the Standards Track specification for IPv6 Neighbor Discovery. He is first-listed among the two authors of RFC 7048, which updates NUD when the original failure clock is too impatient. He also co-authored RFC 3756, an Informational analysis of Neighbor Discovery trust models and threats. These are collective IETF products. They establish participation in the design and its security analysis, not sole invention or authority over a deployment.
Read together, the documents offer a useful operational grammar: a cache entry is a claim with a source, a scope and an expiry. It is not a person, a credential or an outcome.
Reachability is a one-way claim
RFC 4861 defines a neighbor as reachable when there is positive evidence that the one-way forward path is functioning: packets sent to the neighbor reach its IP layer and are properly processed there. For a neighboring router, the claim also includes evidence that it is forwarding packets as a router.
That definition is narrower than “the service is healthy.” It does not say the return path is symmetrical, that every transit element is healthy, that an application accepted a transaction or that a physical operation completed. It does not even make a universal claim about the neighbor. It says something about a particular next-hop relationship from the observing node, using evidence recent enough for the configured reachability interval.
NUD recognizes two broad forms of positive confirmation. One is a solicited Neighbor Advertisement received in response to a Neighbor Solicitation. The other is a suitable indication from an upper-layer protocol that it is making forward progress.
The upper-layer inference is precise. A fresh TCP acknowledgement can show that recently sent data reached the remote peer. If the route to that peer uses the cached neighbor as the first hop, the acknowledgement supports the inference that the forward path through that neighbor worked. Receiving new, non-duplicate data can likewise imply that earlier acknowledgements traveled forward. The implementation may use that signal to refresh neighbor reachability.
It must not spend the evidence twice. A TCP acknowledgement does not authenticate the link-layer neighbor. It does not prove that the current return path matches the forward path. It does not certify the application payload, authorization decision or business result. It is an upper-layer observation borrowed for one lower-layer inference: recent first-hop forward progress.
The state machine is a sequence of questions
The familiar RFC 4861 states are easiest to understand as questions rather than verdicts.
INCOMPLETE means address resolution is still in progress: the node does not yet have the link-layer address it needs. REACHABLE means a recent positive confirmation exists. Once the reachability timer expires, the entry becomes STALE. The link-layer address is not discarded. The label says only that the old confirmation is no longer recent enough to support the stronger state.
STALE does not generate probe traffic merely because time passed. An unused cache entry can remain quiet. The first packet that needs it changes the state to DELAY and is sent using the cached link-layer address. The delay gives upper layers a brief chance to supply fresh confirmation. If they do, the entry returns to REACHABLE without an extra Neighbor Solicitation.
If no such evidence arrives, the state becomes PROBE. The node sends unicast Neighbor Solicitations to test the cached path directly. A valid solicited Neighbor Advertisement can restore REACHABLE. Under the base algorithm, exhaustion of the probe count causes the entry to be deleted; next-hop determination or address resolution can begin again.
The sequence separates four things that dashboards often collapse:
- the stored link-layer address;
- the freshness of positive reachability evidence;
- current demand to use the neighbor;
- the active attempt to obtain a new confirmation.
A green or red dot cannot preserve those distinctions. Nor can a single timestamp named last_seen. An operator needs to know what was seen, by which mechanism, at which observation point and when its inference expires.
Unsolicited news is not positive confirmation
Neighbor Discovery carries information that can be valuable without proving the forward path. An unsolicited Neighbor Advertisement might announce a changed link-layer address. A Router Advertisement might show that a message traveled from the neighbor toward the receiver. Neither establishes that packets sent in the other direction are reaching and being processed by that neighbor.
RFC 4861 therefore says that Router Advertisements and Neighbor Advertisements with the Solicited flag clear must not be treated as reachability confirmation. The asymmetry matters. Hearing someone speak does not prove that they can hear you. Learning a location does not prove that the route to it currently works.
This is where an apparently innocent observability shortcut becomes dangerous. If every Neighbor Advertisement updates a generic last_reachable_at, an unsolicited message can keep the display green without answering the forward-path question. The log then loses whether confirmation was solicited, whether it corresponded to an active probe and which cached entry it was allowed to refresh.
The safer receipt keeps message direction, Solicited flag, target address, source and destination context, link-layer option changes and the exact state transition. “Neighbor information received” and “forward reachability confirmed” are separate events, even when they occur close together.
Three probes can be reasonable and still be wrong for the situation
The base NUD constants create a quick failure path. RFC 7048 describes the default as three transmissions about one second apart. That is useful when a host has an alternative default router or next hop. Declaring the current neighbor unusable can move traffic to a path with a real chance of succeeding.
But the same clock behaves differently when no alternative exists. A brief wireless fade, sleeping link, transient congestion or slow recovery can outlast the probe budget. Deleting the cache entry then triggers address resolution, often with multicast, while the original cached link-layer address may still be the only plausible route. Fast failure has discovered no substitute; it has merely discarded useful state and added load.
RFC 7048 introduces a conditional, conceptual UNREACHABLE state for that case. When there is no alternative neighbor, the implementation may retain the cache entry and its link-layer address. Packets can continue to be sent there. Probing continues, eventually using multicast Neighbor Solicitations with exponential backoff. The switch from unicast to multicast is important because the neighbor's link-layer address may have changed; endlessly probing only the old address would never rediscover it.
The name UNREACHABLE is intentionally uncomfortable. It means the node has failed to obtain confirmation under the active probing process. It does not mean that the implementation must stop transmitting. It does not mean that every packet is failing, or that a service is permanently down. And it must not prevent selection of a genuinely alternate next hop when one becomes available.
Patient probing is not a universal improvement. If an alternate router exists, continuing to feed an unconfirmed neighbor can delay useful failover. If no alternate exists, deleting the only mapping can make a transient failure worse. The decisive fact is not the state label. It is the current alternative set and the operator's continuity policy.
A cache state cannot authenticate its subject
RFC 3756 explains why the boundary is also a security boundary. Neighbor Discovery commonly operates inside a trust model in which nodes on the link can send messages that influence caches. A forged solicited Neighbor Advertisement can create false reachability confirmation. An attacker can steer packets toward a malicious or nonexistent link-layer address, or sustain denial of service by manipulating the state the victim trusts.
That possibility does not make NUD useless. It tells the operator what kind of evidence it is. A state transition can be correct under the protocol's input rules while the input itself was produced by an adversary. REACHABLE is not shorthand for authenticated, authorized or owned. Cryptographic or link-access controls, when present, are separate evidence with separate failure modes.
Likewise, an address is not an institution. A Neighbor Cache entry binds an IPv6 next-hop address to link-layer information for forwarding. It does not establish the human responsible for the device, the organisation entitled to use the address, the software revision in control or the policy under which a packet was admitted. Those facts require their own records and custodians.
The minimum incident ledger therefore keeps the cache state beside, not instead of, the evidence that produced it: solicited response or upper-layer hint, timestamps, interface, next hop, stored link-layer address, probe sequence, alternative-router set, security context and relevant software/configuration version. Application authorization and outcome receipts remain separate.
Erik Nordmark's role is strongest when stated narrowly
The current IETF profile reviewed for this article lists 25 RFCs and an active role as a reviewer in the Internet of Things Directorate. That is time-sensitive profile metadata, not a permanent title. More durable attribution comes from the documents themselves.
RFC 4861 names Nordmark with Thomas Narten, William Simpson and Hesham Soliman. RFC 7048 names Nordmark with Igor Gashinsky. RFC 3756 names Pekka Nikander, as editor, with James Kempf and Nordmark. The first two are Standards Track documents; RFC 3756 is Informational. The distinctions matter because authorship, document status, IETF consensus and deployed behaviour are not interchangeable claims.
Running code still has to show which transitions an implementation performs, which upper-layer hints it accepts, how it discovers alternatives, how it backs off and what it logs. An RFC provides a public coordination point and a specification against which those observations can be compared. It does not make its authors operators of the reader's network.
This restraint reflects the deeper design virtue. The state machine does not try to settle more than it can observe. It preserves a usable mapping while downgrading confidence. It asks for new evidence when traffic makes the question relevant. It changes failure policy when alternatives change. And it stops before a forwarding hint is mistaken for identity or authority.
The neighbor did not become stale. The evidence did. The difference is the beginning of an accountable network record.
Sources
- https://www.rfc-editor.org/rfc/rfc4861.html
- https://www.rfc-editor.org/rfc/rfc7048.html
- https://www.rfc-editor.org/rfc/rfc3756.html
- https://datatracker.ietf.org/person/Erik%20Nordmark
- https://www.ietf.org/lib/dt/media/photo/erik-nordmark-PAKeJ.jpg
- https://heng.lu/running-code-primary-the-patch-needed-to-preserve-the-internet-original-design/
- https://heng.lu/minimum-initial-specification-localized-future-decision-voluntary-adoption-internet-coordination-system/
Member Briefing
Deeper Profile Context
Sign in with the right membership level to unlock the full briefing and source notes.
Only for Strategic Circle
Strategic Circle
Open to all readers. Unlock profile briefings after joining and signing in.
Join Strategic CircleOnly for Leadership Alliance
Leadership Alliance
For qualified IP-asset owners and management; sign in to unlock alliance briefings.
Join Leadership Alliance
