Connected: An Internet Encyclopedia
RFC 1122 - 2.3.2.1 ARP Cache Validation

Top: Connected: An Internet Encyclopedia
Up: Requests For Comments
Up: RFC 1122
Up: 2. LINK LAYER
Up: 2.3 SPECIFIC ISSUES
Up: 2.3.2 Address Resolution Protocol -- ARP
Prev: 2.3.2 Address Resolution Protocol -- ARP
Next: 2.3.2.2 ARP Packet Queue

### 2.3.2.1 ARP Cache Validation

An implementation of the Address Resolution Protocol (ARP) [LINK:2] MUST provide a mechanism to flush out-of-date cache entries. If this mechanism involves a timeout, it SHOULD be possible to configure the timeout value.

A mechanism to prevent ARP flooding (repeatedly sending an ARP Request for the same IP address, at a high rate) MUST be included. The recommended maximum rate is 1 per second per destination.

DISCUSSION:

  The ARP specification [LINK:2] suggests but does not require a timeout mechanism to invalidate cache entries when hosts change their Ethernet addresses. The prevalence of proxy ARP (see Section 2.4 of [INTRO:2]) has significantly increased the likelihood that cache entries in hosts will become invalid, and therefore some ARP-cache invalidation mechanism is now required for hosts. Even in the absence of proxy ARP, a long- period cache timeout is useful in order to automatically correct any bad ARP data that might have been cached.

IMPLEMENTATION:

  Four mechanisms have been used, sometimes in combination, to flush out-of-date cache entries.

  1. Timeout -- Periodically time out cache entries, even if they are in use. Note that this timeout should be restarted when the cache entry is "refreshed" (by observing the source fields, regardless of target address, of an ARP broadcast from the system in question). For proxy ARP situations, the timeout needs to be on the order of a minute.

  2. Unicast Poll -- Actively poll the remote host by periodically sending a point-to-point ARP Request to it, and delete the entry if no ARP Reply is received from N successive polls. Again, the timeout should be on the order of a minute, and typically N is 2.

  3. Link-Layer Advice -- If the link-layer driver detects a delivery problem, flush the corresponding ARP cache entry.

  4. Higher-layer Advice -- Provide a call from the Internet layer to the link layer to indicate a delivery problem. The effect of this call would be to invalidate the corresponding cache entry. This call would be analogous to the "ADVISE_DELIVPROB()" call from the transport layer to the Internet layer (see Section 3.4), and in fact the ADVISE_DELIVPROB routine might in turn call the link-layer advice routine to invalidate the ARP cache entry.

  Approaches (1) and (2) involve ARP cache timeouts on the order of a minute or less. In the absence of proxy ARP, a timeout this short could create noticeable overhead traffic on a very large Ethernet. Therefore, it may be necessary to configure a host to lengthen the ARP cache timeout.

Next: 2.3.2.2 ARP Packet Queue

Connected: An Internet Encyclopedia
RFC 1122 - 2.3.2.1 ARP Cache Validation