Cabling
Why IPv6 Can Still Send Using a STALE Neighbor Entry
An IPv6 STALE neighbor entry retains a link-layer address but lacks recent positive reachability confirmation. On first use, the sender can transmit using that address and move the entry to DELAY while confirmation is sought. INCOMPLETE means address resolution is still in progress: the sender has not yet determined the neighbor's link-layer address. The distinction explains why STALE can coexist with packet sending.
Separate address resolution from reachability confirmation
An IPv6 neighbor observation makes sense only from the observing node and interface. RFC 4861's Neighbor Cache associates an on-link unicast IPv6 address with information including its link-layer address and reachability state. On Ethernet, that link-layer address is a MAC address. The neighbor can be the destination itself or a router selected as the next hop toward an off-link destination.
INCOMPLETE means the link-layer address is still being resolved. STALE retains an address while recent positive confirmation is absent. STALE can follow the aging of a previously REACHABLE entry, but it can also follow learning or updating an address from unsolicited Neighbor Discovery information. A STALE row therefore does not establish that this neighbor was previously confirmed reachable.
The explanation below follows the conceptual behavior in RFC 4861, September 2007. RFC 7048, January 2014, updates retransmission rules and later handling after unanswered probes. These references explain the initial sending and confirmation sequence; they do not prescribe a particular operating system's display vocabulary or its eventual failure handling.
First use can send before reconfirmation finishes
When a packet is sent using a STALE entry, the sender uses the cached link-layer address and changes the entry to DELAY. DELAY gives upper-layer protocols an opportunity to supply reachability confirmation before Neighbor Unreachability Detection, or NUD, begins explicit probing.
If confirmation has not arrived when that delay expires, the entry moves to PROBE and the node sends unicast Neighbor Solicitations using the cached address. Data transmission can continue alongside this verification. An already-started PROBE sequence can also continue without additional data packets.
The useful distinction is between an address available for an attempted transmission and evidence that the forward path recently worked. A pending reachability check does not itself impose the address-resolution wait associated with INCOMPLETE.
References: [R1]
Two entries expose two different missing inputs
Consider an invented snapshot from one host's outgoing Ethernet interface. Next-hop selection has already chosen neighbor A for destination X and neighbor B for destination Y. The choices are stipulated inputs, not competing routes or a failover arrangement. A's entry contains the symbolic address MAC-A and is STALE. B's entry is INCOMPLETE and has no resolved link-layer address.
A new packet for X can be sent to MAC-A as A's entry moves from STALE to DELAY. The host has enough cached addressing information to attempt that local transmission. It is seeking renewed confirmation rather than starting from an unknown Ethernet destination.
A packet for Y faces a different gap: B's Ethernet address is unresolved. RFC 4861 describes a small per-neighbor queue for packets awaiting address resolution; queued packets can be transmitted when resolution completes. This is a bounded waiting mechanism, not a promise to retain every packet indefinitely.
References: [R1]
Recognize evidence of progress in the forward direction
NUD seeks confirmation that recently sent packets reached the neighbor's IP layer. The direction matters: receiving something from a neighbor does not by itself establish that the observing node's transmissions reach it.
One source of confirmation is upper-layer forward progress. RFC 4861 gives a new TCP acknowledgment as an example: it indicates that previously sent data reached the peer. When applicable upper-layer advice is available to the node, that progress can also confirm the next-hop path used to reach the peer.
A solicited Neighbor Advertisement can provide confirmation when it is valid and accepted for the entry under the advertisement-processing rules. The Solicited flag alone does not override those rules. For example, an advertisement carrying a conflicting link-layer address with the Override flag clear does not promote a STALE entry to REACHABLE.
Router Advertisements and unsolicited Neighbor Advertisements do not supply NUD reachability confirmation. Unsolicited information may update address knowledge without proving the sender's forward path. Upper-layer advice also has no effect on an INCOMPLETE entry: it cannot fill in the missing link-layer address.
In the two-entry example, accepted confirmation for A can make A REACHABLE. It does not resolve B. Even A's REACHABLE label is scoped evidence about recent next-hop reachability; the label itself supplies neither an authenticated neighbor identity nor a completed remote application result.
References: [R1]
Read the supplied state in its network context
For a supplied handoff observation, retain the observing node, outgoing interface, neighbor IPv6 address, cached link-layer address if present, state and snapshot time. Identify whether the selected neighbor is the endpoint or a router toward it. Those details keep a local adjacency observation from becoming an unsupported statement about an entire destination path.
Keep three questions separate when interpreting the record: which next hop was selected, whether its link-layer address is resolved, and what recent confirmation exists. A state label cannot substitute for the route-selection context that identifies the neighbor in the first place.
The related IPv4 forwarding article explains route and next-hop selection with ARP; this article concerns IPv6 Neighbor Discovery and NUD. The LLDP article instead explains received advertisements, their lifetime and the separate physical-path record. An LLDP lifetime and an IPv6 STALE state describe different mechanisms.
References: [R1]
Connect a separate physical requirement to the installation scope
If the project separately requires installing or changing physical Ethernet connections, use the structured cabling service and project-inquiry links below. Share the approved endpoints and patching, specified assemblies, routes, material responsibilities and required connection records.
Leviathan can discuss that defined physical installation and handoff scope. The appointed network owner remains responsible for IPv6 interpretation and network configuration. A STALE observation alone does not define a cabling project.
References: [L1]
Primary sources
- [R1] RFC 4861: Neighbor Discovery for IP version 6 (IPv6)Checked 2026-10-20. September 2007. Sections 5.1–5.2, 7.2.2, 7.2.5, 7.3.1–7.3.3, 11.1 and Appendix C support the conceptual distinction between address resolution and forward-path confirmation. The two-entry example stipulates its addresses, selected next hops and initial states.
- [R2] RFC 7048: Neighbor Unreachability Detection Is Too ImpatientChecked 2026-10-20. January 2014, section 3. Updates later behavior after unanswered probes, including a conceptual UNREACHABLE state. The initial STALE-to-DELAY-to-PROBE explanation does not imply an exhaustive state list or a guaranteed failure deadline.
- [L1] Leviathan Systems: Structured Cabling & Fiber InstallationChecked 2026-10-20. Physical routing, connection, labeling and agreed checks and handoff records for a defined installation package. Material responsibilities and exact verification coverage depend on the project scope.