Summary

  • RFC 1868 addressed a Proxy ARP failure in which a dial-in host reattached through a second communications server before a peer's old cache entry expired.
  • UNARP reused an unsolicited ARP Reply with hardware-address length zero to ask supporting peers to delete the old IP mapping. Unaware peers were expected to reject the abbreviated packet, and implementations could disable the extension.
  • Transmission, peer reception, parser acceptance, cache deletion, fresh ARP resolution and successful forwarding were different events. The broadcast acknowledged none of them.

The caller returned through another door

Imagine a remote computer dialing a shared modem pool. Its Internet address looks local to machines on the office LAN, although the computer is physically behind a communications server. When Host A asks for the remote computer's hardware address, the first server answers on its behalf. Host A stores the server's hardware address and sends later traffic through it.

This was the compatibility bargain documented by RFC 1027. Proxy ARP let a gateway answer for a host beyond the local wire. Existing hosts did not need to understand the hidden subnet or install a new route. Their ignorance was useful, but it concentrated truth in a small cache entry: for this IP address, use this local hardware destination.

Now the caller disconnects from the first server and immediately dials back through a second. The remote IP address is unchanged. Host A's cached hardware address is not. Until the entry expires, Host A continues delivering frames to the first server, which no longer owns the path.

RFC 1868 isolated exactly this interval. Published as Experimental in November 1995, it did not redesign routing or the ARP packet. It proposed a negative message: when the server loses the remote host, tell the LAN that the old mapping should cease to exist.

ARP had created a local belief

The original RFC 826 described how a node learns a correspondence between a protocol address and a hardware address. A request asks who owns the target protocol address. A reply supplies a sender mapping that the receiver can merge into its table and use for later transmission.

The table is local. There is no central ARP register and no transaction in which all stations commit the same version. That design kept address resolution close to the machines that needed it. It also meant that movement could leave different peers holding different ages of the truth.

By 1989, RFC 1122 required hosts to have some way to invalidate stale ARP entries. It listed four mechanisms that could be combined: timeout, unicast polling, advice from the link layer and advice from a higher layer after a delivery problem. Proxy ARP made invalidation more urgent because a host might keep using a gateway's answer after the hidden path had changed.

Those mechanisms produced different evidence. A timeout says only that local policy stopped trusting an old entry. A failed poll reports unanswered probes. Link advice reports a local transmission problem. Higher-layer advice carries a failure seen above the link. None says that the remote computer has attached elsewhere.

A Reply without a hardware answer

UNARP used opcode 2, the ordinary ARP Reply value, but set hardware-address length to zero. The source protocol address was the IP address of the detaching host. The target protocol address was the all-ones IPv4 broadcast address. With no source or target hardware-address fields, the packet occupied sixteen bytes before its link-layer header.

A receiver that implemented RFC 1868 was instructed to delete the ARP cache entry associated with the source IP address. The sending server did not even need to remember whether it had previously emitted the Proxy ARP Reply. It could send UNARP whenever the remote host disconnected. A host leaving a LAN gracefully could also send one for itself.

This looseness was deliberate. The cost of an unnecessary delete was a later resolution. The cost of retaining the stale answer was continued transmission to the wrong intermediary. UNARP preferred forgetting to false continuity.

But deletion was not a new fact about location. After accepting UNARP, Host A knew only that it should stop using one cached answer. It still had to ask again, receive a fresh mapping and send data through it. Absence of the old belief was not presence of the new path.

Compatibility meant that silence had several meanings

RFC 1868 expected supporting and nonsupporting nodes to coexist. Hardware-address length zero served as the discriminator. A conventional implementation that did not know UNARP should reject the malformed-looking Reply instead of creating a mapping to an all-zero hardware address.

That was a cautious failure mode, but it made the limits of a broadcast visible. If Host A remained silent after the packet, the server could not tell whether Host A had received and acted, received and rejected, never received, or had no entry to remove. There was no acknowledgement list.

The memo also recommended a configuration switch so operators could disable UNARP if an existing vendor implementation reacted badly to the abbreviated format. The standard therefore preserved local refusal. Publication defined a possible message; it did not make every station run the same interpretation.

The document's expectation that the change would be widely supported was an expectation, not a measurement. Its Experimental status and later appearances in standards inventories show documentary history. They do not supply an implementation census.

A later link repeated the request and narrowed the delete

RFC 2176 carried a related mechanism into IPv4 over MAPOS in 1997. Its UNARP used a dedicated operation code and included hardware addresses. A node coming up sent three copies at thirty-second intervals. A receiver deleted a cached IP mapping only if the hardware address in the packet differed from the one already cached.

Those choices sharpened the meaning. Repetition reduced the chance that one lost frame preserved stale state. The hardware comparison protected a mapping that already matched the announcing node. Yet three transmissions were still not three acknowledgements. The RFC separately required cache aging and immediate clearing on link loss, showing that UNARP was one invalidation signal among several.

RFC 3790 later classified RFC 1868 as an IPv4-dependent extension for deleting ARP cache entries. That description establishes the design's place in the record, not its deployment or success.

Positive assertion did not close the chain either

RFC 5227 later described the two voices already present in an ARP Request. The sender fields assert a mapping; the target fields ask for one. An ARP Probe asks whether an address is in use while implying an intention to claim it. An ARP Announcement says that the sender is now using the address.

UNARP spoke in the opposite direction: stop believing the old mapping. Both kinds of statement are link-local inputs to receivers. A peer can validate syntax, compare them with its own state and decide what to do. Neither statement alone proves that all peers agree, that no conflict exists, that subsequent frames reach their target or that an application completed useful work.

The historical lesson is not that ARP needed a central judge. It is that a decentralized cache needs honest names for its transitions. “Departure broadcast sent,” “frame observed,” “entry deleted,” “new mapping learned” and “packet delivered” are all defensible records. “The network forgot” is not, unless the network has been observed at the places that matter.

Sources and limits

The packet and cache foundations are in RFCs 826, 1027 and 1122; RFC 1868 defines the experimental departure message; RFC 2176 supplies a later link-specific variation; RFC 3790 classifies the IPv4 dependency; and RFC 5227 explains later ARP probe and announcement semantics. These sources define behavior and stated expectations. They do not prove current use, universal support, a named incident, product conformity, malicious exploitation or successful delivery on any real network.