Some systems label IPv4 ARP entries INCOMPLETE, REACHABLE, STALE, DELAY or PROBE: where do these states come from, and what does each mean?
answer
- not from any ARP RFC
- borrowed from IPv6 Neighbor Discovery
- STALE is still used
- wait for upper-layer proof, then probe
- unicast probes before deletion
basics
~20 sThey are the Neighbor Cache states of IPv6 Neighbor Discovery (RFC 4861), reused for ARP by some implementations: INCOMPLETE while resolving, REACHABLE after recent confirmation, STALE once that lapses, then DELAY and PROBE to re-verify an entry in use.
solid answer
~50 sNo ARP specification defines entry states; RFC 4861 §7.3.2 defines them for IPv6, and some implementations, Linux for example, run the same machine for IPv4 ARP. **INCOMPLETE**: a request is out and no answer has arrived. **REACHABLE**: the forward path was confirmed within `ReachableTime`, a random 0.5 to 1.5 times a 30,000 ms base, so 15 to 45 s by default. **STALE**: that confirmation has lapsed, but the entry is still used to send. The first packet sent from STALE moves it to **DELAY**, which waits `DELAY_FIRST_PROBE_TIME` (5 s) for upper-layer proof, such as a TCP acknowledgement of new data. Without it the entry enters **PROBE**: unicast solicitations to the cached address every `RetransTimer` (1,000 ms), and after `MAX_UNICAST_SOLICIT` (3) go unanswered the entry SHOULD be deleted. For ARP, those probes are unicast ARP requests.
go deeper
Recall that these names come from IPv6 Neighbor Discovery, and that a STALE entry still carries traffic.
Walk the transitions: INCOMPLETE to REACHABLE on a solicited answer, REACHABLE to STALE after ReachableTime, STALE to DELAY on send, DELAY to PROBE without confirmation, deletion after unanswered unicast probes.
Use the machine to diagnose: an entry cycling through PROBE and deletion means the cached MAC stopped answering, while a STALE entry on an idle neighbour is normal. Keep RFC 4861 constants apart from a platform's own.
Judge where confirmation-based ageing beats fixed timeouts, such as large links where broadcast load matters, and what it costs in probe traffic for UDP-heavy or forwarding-heavy workloads.
## Where the names come from ARP's own documents define no states. RFC 826 describes a translation table and leaves ageing open; RFC 1122 requires that out-of-date entries be flushed and lists four ways to do it. The five state names come from **IPv6 Neighbor Discovery**, RFC 4861 §7.3.2, which defines a **Neighbor Cache** and a procedure called **Neighbor Unreachability Detection (NUD)**. Some operating systems implement one neighbour table for both IPv4 and IPv6 and run the RFC 4861 machine over ARP as well; Linux is the common example. When you see these names on an IPv4 entry, you are looking at that implementation choice, not at an ARP rule. ## The five states | State | Meaning (RFC 4861) | What the sender does | |---|---|---| | `INCOMPLETE` | resolution is in progress; a request has gone out, no answer yet | holds packets in a small queue | | `REACHABLE` | positive confirmation within the last `ReachableTime` | sends normally, no extra action | | `STALE` | more than `ReachableTime` since the last confirmation | still sends with the cached address; nothing happens until a packet is sent | | `DELAY` | stale, and a packet was sent within the last `DELAY_FIRST_PROBE_TIME` | waits for upper-layer confirmation | | `PROBE` | confirmation is actively sought | sends unicast solicitations every `RetransTimer` | RFC 4861's default constants, all from its protocol-constants section: - `REACHABLE_TIME` 30,000 ms is the base; the actual `ReachableTime` is a uniformly random value between `MIN_RANDOM_FACTOR` 0.5 and `MAX_RANDOM_FACTOR` 1.5 times it, so **15 to 45 seconds**; - `DELAY_FIRST_PROBE_TIME` 5 seconds; - `RETRANS_TIMER` 1,000 ms; - `MAX_UNICAST_SOLICIT` 3 and `MAX_MULTICAST_SOLICIT` 3 transmissions. An implementation that reuses the machine for ARP chooses its own values; these are IPv6's. ## How an entry moves 1. A packet needs a neighbour with no entry: create it as **INCOMPLETE** and start resolution. If no answer comes after the allowed solicitations, the entry is discarded. 2. A solicited answer arrives: record the link-layer address, enter **REACHABLE**. 3. `ReachableTime` passes with no new confirmation: **STALE**. RFC 4861 notes an implementation may defer this change until a packet is actually sent. 4. A packet is sent while STALE: it goes out using the cached address and the entry enters **DELAY**. 5. Confirmation arrives during DELAY: back to **REACHABLE**, with no probe sent at all. 6. DELAY expires without it: **PROBE**, with a unicast solicitation to the cached address; repeat every `RetransTimer`. 7. After `MAX_UNICAST_SOLICIT` probes go unanswered, the entry SHOULD be deleted; the next packet re-creates it and resolves from scratch. ## What counts as confirmation - **Upper-layer advice**: evidence that a connection is making forward progress. In TCP, a new acknowledgement shows earlier data reached the peer, so it must have reached the next-hop neighbour too. - **A solicited answer** to this node's own solicitation. - **Not** an unsolicited message. A received packet that carries the neighbour's link-layer address creates or updates the entry as **STALE**, because it proves nothing about the forward path. Mapped onto ARP, an overheard request from the neighbour typically lands the entry in STALE rather than REACHABLE. The DELAY state exists for an everyday case: a TCP connection opened after a lull would otherwise trigger probes, although its own handshake will confirm the path within moments. ## Mapping it onto ARP | RFC 4861 element | ARP equivalent in implementations that reuse it | |---|---| | multicast solicitation for resolution | broadcast ARP request | | unicast solicitation in PROBE | unicast ARP request to the cached MAC, RFC 1122's unicast poll | | solicited advertisement | ARP reply to this host's request | | unsolicited message with a link-layer address | overheard ARP request or unrequested reply | ## Misreadings to avoid - STALE is not an error and not a deleted entry; stale entries carry traffic. RFC 4861 §5.3 notes there is no correctness need to purge them periodically, because NUD purges a bad one quickly once it is used. - REACHABLE does not mean "replied to an ARP request recently" only; upper-layer progress keeps an entry there with no ARP traffic. - A STALE entry that carries no traffic is never probed; probing starts only after a packet is sent from STALE.
- Why does RFC 4861 put a newly overheard link-layer address into STALE rather than REACHABLE?Receiving a packet from a neighbour proves the path from it to you, not from you to it, and it may even carry a wrong address. STALE means the address is used, but the first real traffic triggers DELAY and, without upper-layer confirmation, a unicast probe, so a wrong or one-way entry is caught within seconds of being used.
- Why can an entry stay REACHABLE for hours without a single ARP packet?Upper-layer advice counts as confirmation. A TCP flow whose acknowledgements keep advancing proves the forward path works, so the implementation keeps refreshing REACHABLE from that evidence and never needs to solicit the neighbour.
Like a phone contact: REACHABLE means you spoke this week; STALE means you have not, but you still dial the number; DELAY is waiting a moment to hear a voice; PROBE is ringing again directly, and deleting the contact only after repeated silence.
saying these in an interview costs you the question
- RFC 826 defines the REACHABLE, STALE and PROBE states for ARP.
- A STALE entry is broken and no longer used for sending.
- Any ARP packet received from a neighbour makes its entry REACHABLE.
- Idle STALE entries are probed continuously until they answer.
- ReachableTime is a fixed 30 seconds for every entry.