Summary
- An IPv6 Router Advertisement announces a router and configuration parameters. Its Router Lifetime governs default-router usefulness, while option data can have independent lifetimes.
- Default-router selection depends on host capabilities, preferences and reachability state. RFC 4861 deliberately uses Neighbor Unreachability Detection, not missing advertisements, to detect a failed first hop.
- A durable receipt must join the received RA, the route actually selected, Neighbor Cache and NUD state, and representative packet delivery.
The route appeared before reachability was known
Consider a host that receives a valid Router Advertisement, installs the sender as its default router and immediately shows a healthy-looking ::/0. The router is present on the link, the lifetime is non-zero and the preference is acceptable. Yet the forward path is broken: perhaps the link is asymmetric, the router has lost upstream forwarding, or the cached link-layer state no longer reaches the intended interface.
Nothing in the advertisement contradicts that outcome. Router Discovery and Neighbor Unreachability Detection answer different questions. One tells the host which routers and parameters have been announced. The other seeks positive evidence that the neighbor is still receiving and processing packets. Treating the first as the second turns a legitimate discovery event into an invented delivery guarantee.
The practical consequence is a familiar blind interval. A dashboard can show a recent RA and an installed default route before upper-layer progress or NUD probes have confirmed the first hop. Operators who keep only the route-install event lose the state transition that matters most.
What a Router Advertisement actually establishes
RFC 4861 describes Router Advertisements as messages that announce a router's presence and carry link and Internet parameters. They can include prefixes for on-link determination or address configuration, a suggested hop limit, Router Lifetime, Reachable Time, Retrans Timer, link-layer information and MTU.
Those fields do not share one validity clock. Router Lifetime applies only to the router's usefulness as a default router; it does not extend to information in other fields and options. Prefix and route information carry their own lifetime rules. A receipt that records only “RA received” therefore cannot reconstruct which facts were still valid when a packet was sent.
RFC 4861 is equally direct about failure detection. Routers advertise often enough for hosts to learn of their presence, but not often enough for an absence of advertisements to identify router failure. NUD is the separate mechanism. The freshness of the last multicast RA is neither a liveness probe nor confirmation of bidirectional packet progress.
The Default Router List also is not independent of neighbor state. Its entries point to Neighbor Cache entries, and the selection algorithm favors routers known to be reachable over routers whose reachability is suspect. The host's selected next hop is thus a changing result produced from discovery, cached reachability and destination state—not a permanent meaning attached to one RA.
Preference changes selection, not delivery
RFC 4191 adds Default Router Preference in the RA header and the Route Information Option for more-specific prefixes. The preference values are deliberately coarse and are not metrics. If Router Lifetime is zero, the header preference has no selecting force. A Route Information Option carries its own prefix, preference and lifetime.
Host behavior is not uniform. A type A host ignores both router preferences and Route Information Options. A type B host uses default-router preference but ignores RIOs. A type C host builds a routing table from both. A ::/0 RIO can override the header's preference and lifetime for a type C host. Two hosts on the same link can therefore receive the same bytes yet maintain different effective routes because their supported models differ.
Even where preference is used, reachability comes first. A type B host primarily prefers reachable routers and uses preference secondarily. A type C host chooses longest prefix, uses preference to break ties among identical prefix lengths, and passes over a route whose next-hop router is known unreachable. When the host has no reachability information, the conceptual algorithm assumes the router reachable. That assumption lets traffic begin; it is not evidence that traffic succeeded.
NUD supplies a different class of evidence
Neighbor Unreachability Detection looks for positive confirmation that packets sent to a neighbor are reaching it and being processed by its IP layer. Recent upper-layer forward progress can provide that confirmation. When such hints are absent, the node sends unicast Neighbor Solicitations and uses solicited Neighbor Advertisements to test reachability.
The Neighbor Cache records more than an address binding. Its conceptual state includes reachability, unanswered-probe count and the next scheduled NUD event. A default route can remain installed while the neighbor moves through states such as reachable, stale, delay and probe. The route row and the neighbor row must be observed together.
NUD is still first-hop evidence, not end-to-end assurance. A router can answer a neighbor probe while lacking an upstream path to a destination. Conversely, temporary missing upper-layer hints do not prove failure. The operational record must preserve what was tested: advertisement receipt, link-neighbor reachability, route selection, upstream progress or full service delivery.
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

