How do ARP cache entries age out in IPv4, what do RFC 826 and RFC 1122 each require, and how do static entries differ?

## What the original specification said RFC 826 (1982) defines the ARP packet and the receive algorithm, but it deliberately stops short of cache management: "It may be desirable to have table aging and/or timeouts. The implementation of these is outside the scope of this protocol." Its discussion sketches options (resetting a timer whenever a packet arrives from a host, or a background task that re-asks a host directly before forgetting it) and notes that 48-bit Ethernet addresses "shouldn't change", so the problem seemed minor at the time. ## What host requirements added RFC 1122 (1989), §2.3.2.1 "ARP Cache Validation", turned the suggestion into a rule: - an implementation **MUST** provide a mechanism to flush out-of-date cache entries; - if that mechanism is a timeout, it **SHOULD** be possible to configure the timeout value; - an implementation **MUST** include a mechanism to prevent ARP flooding, with a recommended maximum of **1 request per second per destination**. Its reasoning: hosts do change hardware addresses, proxy ARP had made invalid entries much more likely, and even without it a long timeout corrects bad data that would otherwise persist. ## The four flushing mechanisms RFC 1122 lists four mechanisms that implementations had used, sometimes combined: | Mechanism | How it works | Cost | |---|---|---| | Timeout | entries expire even if in use; the timer restarts when the source fields of an ARP broadcast from that host are seen, whatever its target | re-resolution traffic | | Unicast poll | send a point-to-point ARP request to the cached MAC; delete after N unanswered polls, typically N = 2 | one unicast per entry per period | | Link-layer advice | the driver reports a delivery problem and the entry is flushed | needs a link that can detect failures | | Higher-layer advice | the internet layer tells ARP that delivery to that neighbour is failing | needs the transport layer to notice | For the first two it suggests timeouts "on the order of a minute" where proxy ARP is in use, and warns that such short values create noticeable overhead on a very large Ethernet, so a host may need a longer one. ## Choosing a lifetime is a trade 1. **Short lifetimes** correct a wrong mapping quickly but cost broadcasts every time an active entry expires, and every host on the link processes each broadcast. 2. **Long lifetimes** cut that traffic but leave a wrong mapping in place for as long as the entry lives. 3. **Confirmation-based schemes** avoid the choice: keep using an entry while traffic proves it works, and probe only when nothing does. Some systems apply IPv6 Neighbor Discovery's state machine to ARP for exactly this reason. Whatever an implementation picks is its own default. Lifetimes in use range from about a minute, the scale RFC 1122 suggests where proxy ARP is in use, to several hours on some routers. Neither end is a protocol value. ## Static versus dynamic entries | | Dynamic entry | Static entry | |---|---|---| | Origin | learned from ARP requests and replies | typed in by an administrator | | Lifetime | flushed by the implementation's mechanism | kept until removed | | Updated by received ARP | yes, by RFC 826's merge | not in common implementations | | Follows a MAC change | eventually | never | | Typical use | everything | a few critical neighbours, or devices that answer ARP badly | Static entries are not part of any ARP specification; they are an implementation feature. Their appeal is that a forged reply cannot overwrite them. Their cost is that nothing ever corrects them, and they must be maintained on every host that holds one. ## Flushing by hand RFC 826 already anticipated it: "Perhaps manually resetting (or clearing) the address mapping table will suffice." Clearing one entry, or the whole cache, is the operator's tool when an entry is known to be wrong. The next packet triggers a fresh request, so clearing a dynamic entry is cheap; clearing a static one means it is gone until someone adds it back. ## Misconceptions - "The standard ARP timeout is N minutes" is false for any N; the RFCs fix no lifetime. - "Shorter is always better" ignores the broadcast load RFC 1122 itself warns about. - "A static entry expires, just more slowly" confuses static with a long-lived dynamic entry.