Summary

  • RFC 903 addressed a specific cold-start problem: a diskless host knew its hardware address but needed a protocol address before it could use IP.
  • RARP put that lookup on the data link. A server answered from a maintained hardware-to-protocol-address map; the reply did not authenticate a machine or prove that booting had finished.
  • The protocol had no explicit “not found” response. A client that heard nothing had to time out, without learning whether the mapping was absent, the request was lost or no server answered.
  • RFC 950 and BOOTP show why one address was only part of boot configuration: hosts might also need a gateway, name server, subnet mask and boot file.

The first question came before IP

Picture a workstation with no local disk. Its boot code can read the hardware address of its Ethernet interface, but it has no stored Internet address. An IP request cannot solve the problem: the machine does not yet know the source address with which to send one.

Ross Finlayson, Timothy Mann, Jeffrey Mogul and Marvin Theimer proposed RARP in RFC 903, published in June 1984. The memo describes the host as asking for its protocol address from an external source, on a broadcast medium such as Ethernet. ARP solved the reverse direction: it found a hardware address when the protocol address was already known. RARP began with the hardware address and asked for the corresponding protocol address.

This was not a general identity service. RARP did not ask who owned the workstation or whether a person was entitled to use an address. It gave an unconfigured host a way to request one specific mapping before normal IP communication was possible.

A local server held the answer

RFC 903 deliberately made RARP a separate data-link protocol. It reused ARP’s packet layout but assigned reverse-request and reverse-reply opcodes. In a request for its own address, the host placed its hardware address in both the sender and target hardware fields. A server that recognized the address could reply with the target protocol address.

That answer depended on server state. The RFC says one or more RARP servers maintain a database of hardware-to-protocol-address mappings. This differs from ordinary ARP, where hosts learn peer mappings into a cache and there is no client/server distinction. RARP therefore introduced an operating dependency: the client could ask, but some local operator had to keep the server’s map useful.

The response was a mapping receipt, not a credential. The RFC specifies no authentication that binds the hardware address to a person, owner or authorized device. Nor does the response prove that the host installed the address correctly, reached a gateway or loaded an operating system. Those are later steps.

Silence was not a negative answer

RFC 903 defines reverse requests and replies, but no “not found” or error packet. The authors explain that many servers may be free to answer a request. Instead of defining a separate refusal, the RFC tells the requester to time out if no reply arrives within a reasonable interval.

That choice kept the exchange small, but left the client with an ambiguous observation. A timeout might mean that no server had the mapping; it might also mean that the request or reply was lost, the link was down, or no server was available. Silence did not identify which condition held. A boot log that reported only “RARP timed out” could not settle the cause.

The distinction matters when reconstructing a failure. A missing response is evidence about what the client received, not proof that an address was unassigned. The original memo is clear on that boundary even though it does not prescribe a diagnostic system for separating every cause.

One address did not configure a host

The wider boot problem quickly became visible. RFC 950 names RARP as one way a newly booted host could discover its Internet address, then lists other facts it might need: a gateway’s hardware address, a name server’s IP address and the subnet mask. It argues that obtaining several parameters in one request would be preferable to issuing multiple broadcasts.

BOOTP, specified the following year, retained the hardware-to-IP lookup while carrying more boot information, including an optional file name. Its design also allowed booting through gateways. RFC 951 explicitly contrasts its IP/UDP approach with RARP’s hardware-link-level packets and the special kernel or driver work needed to access them. RFC 1542 later clarified BOOTP relay behavior; RFC 2131 describes DHCP as building on BOOTP with reusable automatic address allocation and configuration options.

That sequence is not proof that every network abandoned RARP on one date. It shows a shift in the problem statement: learning one preassigned address was useful, while booting across routed networks required a broader exchange and a relay path.

A record is not the machine

Heng Lu’s Note 72 offers a later analytical lens, not evidence about 1984: a registry record describes reality but does not create it. RARP was not a global registry, yet the distinction travels. A server’s table could coordinate a local mapping; it could not make the returned address proof of hardware ownership, user identity or successful operation.

The protocol’s historical contribution was narrower and practical. It let a host ask the link it could already reach for the one address needed to begin IP communication. Its boundary was also its cost: local mappings had to be maintained, silence could not explain itself, and the answer stopped short of full configuration.

Sources

RFC 903 — A Reverse Address Resolution Protocol; RFC 826 — An Ethernet Address Resolution Protocol; RFC 950 — Internet Standard Subnetting Procedure; RFC 951 — Bootstrap Protocol; RFC 1542 — Clarifications and Extensions for the Bootstrap Protocol; RFC 2131 — Dynamic Host Configuration Protocol. Note 72 is a later editorial lens, not a historical source.