Summary
- RFC 4861 used a short Neighbor Unreachability Detection sequence to expose failed next hops quickly, but its conceptual state machine deleted the cache entry after the configured unanswered probes.
- RFC 7048 introduced UNREACHABLE: alternatives could be preferred while the last link-layer mapping remained available under multicast probing and exponential backoff.
The third unanswered probe
A working IPv6 host does not continuously interrogate every neighbor it has learned. RFC 4861 gave each active Neighbor Cache Entry a small state machine. Fresh positive evidence made an entry REACHABLE. Time without confirmation made it STALE, but did not trigger traffic on its own. Only when a packet needed that stale neighbor did the entry enter DELAY, giving an upper-layer protocol a brief chance to demonstrate forward progress. If no such evidence arrived, the node entered PROBE and sent unicast Neighbor Solicitations to the link-layer address already in the cache.
That economy mattered. Reachability was tested when an entry was used, and a TCP acknowledgment or another trustworthy upper-layer signal could spare the link an unnecessary probe. But the conceptual ending was blunt. After the configured number of unanswered probes, the entry was discarded.
RFC 7048 described the common default as three transmissions one second apart. That was deliberately fast when a host had another default router or when a Redirect-created entry could be abandoned in favor of ordinary next-hop selection. In those cases the timeout was a useful switch signal. It prevented traffic from remaining pinned to a failed choice.
The same ending behaved differently when there was no alternative. Deleting the entry did not conjure another router or another destination. As new packets arrived, the host had to perform address resolution again. The unicast probes aimed at a known link-layer address could give way to repeated multicast solicitations, adding work precisely while a transient layer-2 fault was already disrupting the link.
Unreachable without being erased
RFC 7048 changed the state machine at that boundary. Where RFC 4861 said that PROBE should discard an entry after the probe limit, the update said to increase the timeout, send a multicast Neighbor Solicitation and enter a new UNREACHABLE state.
The name is intentionally not reassuring. UNREACHABLE does not certify a functioning path. A default router in that state is no longer “known to be reachable,” so next-hop selection can prefer another router. A cache entry created by a Redirect may be deleted instead, and an implementation should not keep using such an unreachable redirect as its forwarding choice.
Yet the ordinary UNREACHABLE entry retains the recorded link-layer address, and packets may continue to be sent to it. This preserves a residual path when there is no better one. The standard therefore stopped using one observation—several unanswered probes—to answer two different questions. The observation could revoke preference without necessarily destroying the last forwarding evidence.
That distinction also leaves garbage collection intact. RFC 7048 permits an implementation to discard cache entries at any time under RFC 4861's rules and even to prefer UNREACHABLE entries for collection. Retention is a protocol option under continued use, not permanent ownership of memory.
A wider probe with a slower rhythm
Keeping the link-layer address alone would be dangerous if the neighbor had moved to a different address on the link. RFC 7048 therefore changed both the audience and tempo of later probes. An implementation may send some initial solicitations by unicast, but it must switch to multicast within 60 seconds of the initial retransmission. The wider question lets a target with a changed link-layer address answer.
At the same time, implementations that transmit beyond the earlier solicitation limits should apply exponential backoff. RFC 7048 suggests clamping the interval at a reasonable maximum such as 60 seconds. If no IPv6 packet is using the entry, retransmissions should stop until use resumes or the entry is collected. Continued uncertainty is allowed, but it does not justify a fixed-rate background storm.
The document's example algorithm makes the policy visible without making its exact timer schedule universal. It marks the entry UNREACHABLE after the early probes, tries alternatives at that point, and spaces later attempts farther apart. Those sample constants illustrate compliance; they are not performance measurements or a mandate that every implementation choose identical numbers.
Why the old constants became policy
RFC 7048 also records an institutional detail. RFC 4861's MAX_MULTICAST_SOLICIT, MAX_UNICAST_SOLICIT and RETRANS_TIMER values appeared to have become part of IPv6 conformance testing. Implementers could not safely treat them as loose suggestions even when operations showed that longer recovery was useful. Changing deployed behavior therefore required an explicit standards update.
RFC 6583 supplies the broader operational setting. On a large IPv6 subnet, traffic toward huge numbers of unassigned addresses can fill Neighbor Discovery queues and caches, disrupt established flows and prevent new devices from joining. That document does not define the UNREACHABLE transition, but it explains why retransmission, multicast and cache behavior cannot be treated as harmless local details.
The history is not simply that IPv6 learned to wait longer. RFC 7048 made failure context-sensitive. When alternatives existed, the early threshold could still move traffic away. When none existed, the implementation could preserve the last mapping, probe more broadly, and spend less control-plane effort as uncertainty continued. “Unreachable” became a routing judgment rather than an automatic command to forget.
Sources
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
