Summary

  • RFC 826 solved a narrow but decisive problem: after IP routing selected an immediate protocol address, an Ethernet interface still needed a hardware destination. A host asked the local cable only when its table lacked the answer.
  • The request did more than solicit a reply. Every listener could observe the sender's claim, and the target learned the requester before answering. The cache made that observation executable, while later rules made it expire.
  • Proxy replies and address-conflict detection exposed ARP's authority boundary. A reply may be a forwarding promise rather than identity, and a DHCP lease or manual setting may still be rejected by evidence from the local link.

The missing destination after routing

An IP stack can decide that the next packet belongs to a host on the attached network, or to a router that will carry it farther. That decision still does not tell an Ethernet interface what destination to place in the frame. The Internet address and the 48-bit hardware address are different kinds of name. Neither can be derived reliably from the other.

RFC 826, published in November 1982 by David C. Plummer, began precisely at that seam. Its example protocol had already selected a target on a connected 10-megabit Ethernet. The remaining job was to convert a pair—protocol type and target protocol address—into a hardware address that the local network could use.

The packet format made the mismatch explicit. It carried a hardware type, a protocol type, the length of each address, an operation, and sender and target addresses in both spaces. IPv4 over Ethernet became the familiar use, but the form did not assume that every protocol address was 32 bits or every local medium was Ethernet. Resolution was a relation between namespaces, not a property hidden inside one address.

This matters because the mapping is not routing. Routing chooses the immediate protocol destination and the outgoing interface. ARP acts only after that choice, inside the selected local link. If the IP destination is remote, the hardware address normally belongs to the next-hop router, not the distant server. The frame and the packet can therefore name different destinations without contradiction.

The 1982 proposal avoided a complete central table. The local Address Resolution module first looked in its own translation cache. If the mapping existed, it returned the hardware address and transmission could proceed. If not, it constructed a request and broadcast it on the Ethernet selected by routing. The question was limited in scope and generated on demand.

A question sent to everyone nearby

Broadcast made the unknown address a shared local event. The requester supplied its own hardware and protocol addresses, named the protocol address it wanted, and left the target hardware address unknown. Every station on that cable could receive the frame, but only a station that understood the relevant hardware and protocol spaces and recognised itself as the target needed to reply.

The reply was unicast back to the requester. This asymmetry kept discovery visible while keeping the answer from becoming another required broadcast. It also avoided periodic advertisement of every mapping. RFC 826 explicitly compared on-demand resolution with workstations repeatedly broadcasting tables full of entries they might never use. Ask when needed, remember what matters, and do not make all peers maintain the same world view.

That economy had a cost. A first packet might be discarded while resolution took place, on the assumption that a higher layer would retry. Host requirements later refined the behavior: RFC 1122 said the link layer should save at least the latest packet for an unresolved destination. Queueing one packet avoids losing the opening packet of every exchange, but it remains local execution state. It says nothing about who owns the address.

Broadcast also needs restraint. RFC 1122 required a mechanism to stop repeated requests for the same destination from becoming an ARP flood and recommended a maximum of one request per second per destination. An unanswered question cannot be amplified without limit. Silence may mean absence, loss, a sleeping host, segmentation, or hostile interference; repetition changes the load, not the certainty.

Learning before knowing the opcode

The most revealing part of RFC 826 is the order of its receive algorithm. A station first checked whether it understood the hardware and protocol types. If it already held an entry for the sender's protocol address, it updated that entry with the hardware address observed in the packet. If it was the named target and no sender entry existed, it added one. Only then did it inspect whether the packet was a request that required a reply.

The request was therefore both question and evidence. A asks, in effect, “Who can receive traffic for B?” while simultaneously stating, “Replies to A can reach this hardware address.” B learns how to answer before answering. A passive monitor can likewise collect sender mappings without speaking the higher-level protocols carried on the cable.

RFC 826 allowed a new sender hardware address to supersede an old one. That helped a network recover when a mapping changed, but it also revealed the protocol's trust model: recent observable claims influence the cache. The packet did not carry a cryptographic proof of identity. A receiver had to treat the mapping as useful local information, not as a title deed.

The original memo discussed table aging and timeouts but left them outside the protocol. It recognised the danger that incorrect data or a moved host could leave other machines pointing at an obsolete address. Seven years later, RFC 1122 turned the concern into a requirement: ARP implementations must have a mechanism to flush stale entries, and timeout values should be configurable when time is the chosen mechanism.

RFC 1122 described more than a clock. A host could poll a cached hardware address directly, accept advice from the link layer, or use failure reported by a higher layer. These mechanisms disagree about what counts as contrary evidence, but all reject permanence. A cache accelerates repeated execution by accepting temporary incompleteness. Its safety comes from an exit.

When a gateway answered for somebody else

ARP's reply is often described as if the target itself announces its hardware identity. RFC 1027, published in October 1987, documented why that interpretation was too strong. Networks at the University of Texas needed subnets, while many host operating systems did not implement subnetting. Proxy ARP let gateways hide the new boundary.

Suppose A broadcasts for B. A gateway hears the question and knows from its routing table that B lies across another physical network. It replies using its own hardware address. A caches that mapping and sends packets addressed to B's IP address inside frames addressed to the gateway. On B's side, another proxy answer can arrange the return path.

The endpoint sees no subnet. Compatibility is the benefit: more than half a dozen operating systems did not need to be changed at once. But the answer is now plainly delegated. The hardware that replied is not claiming to be the final IP endpoint; it is promising to accept the local frame and forward the enclosed packet.

That promise depends on routing knowledge and administrative consistency outside ARP. If several gateways answer, the first reply may shape the cache. If a gateway proxies for a destination it cannot correctly reach, the local mapping looks complete while delivery fails later. Proxy ARP can preserve old hosts and conceal topology at the price of hidden coupling between local resolution and router policy.

The example establishes a useful boundary. Observing a reply proves that somebody answered with a usable candidate. It does not prove physical co-location, endpoint identity, authority to own the IP address, or successful delivery beyond the responder.

A lease that the wire could still reject

Central configuration did not eliminate the local test. RFC 2131, the 1997 Dynamic Host Configuration Protocol specification, lets a server offer and lease an address. Yet it advises the server to probe an address before reallocation and tells the client to perform a final check after receiving DHCPACK.

The client may send an ARP request with its own hardware address, the proposed address as target, and an all-zero sender IP. Zero is important: the host is asking whether it can use the address without first asserting that it already does. Other receivers should not fill their caches with a mapping the client may have to abandon.

If the client discovers that the address is in use, it must send DHCPDECLINE and restart configuration. If the test succeeds, it should announce the mapping so peers can discard stale entries left by a previous user. The server's lease is a valid administrative record, but the local link can still supply evidence that makes immediate use unsafe.

This is not a contest between DHCP and ARP. They answer different questions. The server coordinates a pool and a lease. ARP observes the execution environment into which that decision will be placed. An allocation record can be internally correct while the wire contains an old, duplicated, or malicious claimant.

From one lookup to continuous conflict detection

RFC 3927, published in 2005 for IPv4 link-local addresses, gave the local check a timed procedure. A host waits a random interval, broadcasts probes with a zero sender IP, and treats either an answer or a competing probe as evidence that the candidate is in use. After success it broadcasts announcements whose sender and target IP fields both contain the selected address.

Random timing matters when many hosts start together. Conflict counters and rate limits matter when a broken or hostile device answers every probe. The protocol must not convert uncertainty into an infinite broadcast storm. Announcements matter because another host may still cache the address's previous hardware mapping.

The procedure continues after configuration. Two disconnected Ethernet segments can each contain a host using the same link-local address. If the segments are later joined, a boot-time test from the past cannot prevent the collision. RFC 3927 therefore requires hosts to watch for conflicts throughout the period of use.

RFC 5227, published in 2008, generalized IPv4 Address Conflict Detection. It describes an ARP Probe as both a question—“Is anyone using this address?”—and an implied statement—“This is the address I hope to use.” An announcement makes the stronger statement that the sender is now using it.

After a conflict, a host may withdraw immediately or defend the address once by announcing it. If another conflict arrives within DEFEND_INTERVAL, an ordinary host must stop using the address and report the failure rather than enter an endless contest. Some infrastructure, such as a deliberately configured router or DNS server, may be set never to relinquish its stable address, but even that exception requires controlled announcements and operator visibility.

Conflict detection improves safety without authenticating ownership. An attacker can make a legitimate host believe its address conflicts and cause denial of service. A quiet probe can miss a sleeping or partitioned claimant. The protocol establishes a bounded operational test: enough to change behavior, never enough to settle legal or global identity.

What the registry of ARP numbers did not govern

ARP itself contains number spaces. Implementations need to agree on hardware types and operation codes so that the same bits are parsed the same way. RFC 5494, published in 2009, supplied IANA guidelines for allocating those values and reserved experimental ranges.

This is real coordination, but its scope is easy to overstate. IANA can maintain the code point meaning “this field uses a particular hardware type” without deciding which machine may use 192.0.2.7 on a particular Ethernet. A registry of protocol vocabulary is not a registry of every claim expressed with that vocabulary.

The distinction mirrors the architecture ARP revealed. Shared specifications make messages interoperable. Local observation supplies candidates. A cache turns one candidate into action. Timers, new packets, routing policy, or conflict detection can revise the action. Different authorities operate at each layer, and failure follows when one layer's evidence is mistaken for another layer's mandate.

The local ledger that must forget

ARP succeeded partly because it asked for less than a complete system of truth. It did not require every host to register in advance with one service. It did not require a broadcast of all mappings. It required enough common grammar for one host to ask a nearby question and enough local memory to avoid asking before every packet.

That modesty is also its vulnerability. The common wire is observable by parties the host may not trust. The newest claim may be false. A proxy may hide a dependency. A cache may outlive the topology that produced it. The design remains usable only when operators treat the table as a working hypothesis: bounded in scope, aged in time, compared with routing and switching evidence, and replaceable when reality changes.

ARP did not make the cable an authority. It made the cable a witness. The host still decides whether to cache, send, probe again, defend, or withdraw—and bears the result of confusing a local statement with permanent identity.

Sources and evidence limits

RFC 826 supplies the original packet format, on-demand broadcast, merge-before-opcode algorithm, cache replacement, and unresolved discussion of aging. RFC 1027 documents Proxy ARP as a compatibility mechanism and shows that an answer can be delegated. RFC 1122 makes cache invalidation and request throttling host requirements.

RFC 2131 separates DHCP allocation from the client's local duplicate check. RFC 3927 specifies link-local probing, announcements, continued observation, and storm limits. RFC 5227 generalizes IPv4 conflict detection and bounded defence. RFC 5494 governs ARP code-point allocation.

These documents establish designs and requirements, not Internet-wide adoption statistics. An ARP capture establishes what was observed on one link at one time. It does not by itself establish authenticated identity, global ownership, intent, or successful forwarding after a proxy reply.