Summary

  • RFC 1931 described multiple coordinated Dynamic RARP servers as an availability measure, while requiring every server on a segment to communicate with the same logical address authority.
  • The authority’s records were not treated as reality itself: before allocation, the implementation could probe with ARP or ICMP because an address marked available might already be in use.
  • Published in April 1996 as Informational and now recorded as Legacy, the memo documented a system used on certain Sun platforms from 1988; it did not define an Internet standard or establish a causal path to later DHCP.

A silent boot request had too many meanings

The original Reverse Address Resolution Protocol served a machine that knew its hardware address but not its protocol address. It broadcast a request and relied on one or more servers holding hardware-to-IP mappings. RARP deliberately had no negative reply: one server might know a binding that another did not. Silence therefore preserved openness, but it was poor diagnosis. A lost packet, an unavailable server, an unknown machine, the wrong cable segment and the absence of any server could all sound identical.

That ambiguity mattered during hands-off installation. A new machine could retransmit with exponential backoff without learning whether patience would help. Nor could a cable teach it everything. The site still needed an administratively prepared IP network and naming system; obtaining an address was only the first move before name registration, boot resources, keys or initial passwords could be provisioned.

RFC 1931 recorded Dynamic RARP, or DRARP, as one answer to this narrow operational problem. Certain Sun Microsystems platforms had used it beginning in 1988. By the memo’s April 1996 publication, those platforms were no longer sold, and the document observed that DHCP had addressed the role to some extent. This was preservation of a historical design, not a claim that DRARP should displace the newer protocol.

The status boundary is explicit. The RFC Editor’s current record classifies the memo as Informational in the Legacy stream and says it defines no Internet standard. Its date is chronology, not evidence of an April Fools’ joke.

Dynamic meant an answer, not an autonomous server

Every DRARP server was also a RARP server and reused the familiar packet format and link-layer encapsulation. Three additional opcodes changed the conversation. A DRARP_REQUEST used opcode 5. If the authority already held a persistent binding, the server returned the ordinary REVARP_REPLY. If not, it normally created a temporary binding and returned DRARP_REPLY, opcode 6. Failure became explicit through DRARP_ERROR, opcode 7.

The errors separated conditions that silence had collapsed. RESTRICTED meant current policy prohibited dynamic service on that segment. NOADDRESSES meant the pool was exhausted. SERVERDOWN covered a temporarily unavailable or slow allocator. MOVED recognized a known machine on the wrong segment. FAILURE admitted that the remaining cause was unknown. A classification improved client behavior, but the name of an error did not authenticate the responder or prove its explanation.

DRARP also required a response to every request. That promise made the service observable. Operators could distinguish refusal from delay and pool exhaustion from topological mismatch. Yet the server answering on the wire was not free to invent the allocation. The implementation described by the memo used NIS and a centralized RPC service called IPalloc as its address authority. Administrators and DRARP servers could be authorized to change that database. The memo documented this arrangement; it did not standardize the authority protocol or its security choices.

Many mouths, one account of truth

The decisive rule appears when several servers hear the same broadcast. Their replies must not differ except in the fields that identify the sending server. Disagreement is a protocol error. That turns a collection of processes into one DRARP service exposed through multiple responders.

Putting a server on each cable segment could reduce the cost of a partition. Running more than one could survive a dead machine or a failed segment. But all of them had to communicate with the same address authority. The redundancy belonged to the response plane. Allocation authority remained singular in the logical sense: persistent bindings, temporary bindings and the available pool had to form one coherent account.

“One” need not mean one physical computer. RFC 1931 allowed that the authority could be partitioned, while warning of substantial implementation and administrative complexity. The invariant was not a box count. It was that concurrent requests could not legitimately produce conflicting bindings. Replication that makes a wrong shared decision faster is highly available, but it is not correct.

The authority therefore needed more than a list. It had to create, look up, delete and purge bindings; distinguish persistent from temporary assignments; serialize concurrent claims; authorize mutation; and retain temporary state through the interval in which installation records propagated. The memo mentions an hour as sufficient in the initial implementation, not as a universal lease law. Expiry reclaimed scarcity. It did not prove the client had finished installing.

The ledger could be coherent and still wrong

RFC 1931’s sharpest design move is its distrust of its own authority. An administrative database might say an address was available while a running machine was already using it. Before granting the address, the allocator was advised to check the network; the implementation used ARP and ICMP echo.

ARP’s original specification distributes protocol-to-hardware mappings on demand. A reply can show that some link-visible participant claims an address. It cannot prove the claimant’s owner, authorization or future presence. The probe is evidence against an unsafe allocation, not a new title registry.

This creates three layers that are easy to merge in a diagram and costly to confuse in production. A hardware identifier says what link-layer value was presented. The address authority says what binding administrators and allocator state currently recognize. A live probe says what responded on this link at this time. None alone proves legitimate ownership, durable identity and conflict-free operation.

Movement exposed the same boundaries. Recognizing a machine that arrived on a different segment required the two authorities to be the same or to communicate. It also assumed hardware identifiers whose scope was wide enough not to collide across those segments. Even then, a MAC-like value named a device interface, not an authenticated person.

The memo also let servers listen for one another’s announcements and report an apparently uncoordinated responder before entering restricted mode. But it defined no protocol by which two servers adjudicated who was spurious. That judgment had to occur elsewhere, typically through the authority or administration. Detection was not governance.

Later protocols made different choices

The contrast with DHCP is architectural, not genealogical. RFC 1541 described a BOOTP extension with multiple offers, explicit client choice, a server identifier and leases. Its successor, RFC 2131, refined that state machine and allowed a client to decline an offered address after local checking found it in use. These documents do not make DRARP their cause; they show another way to separate proposal, selection, commitment, lifetime and conflict evidence.

A later edge case removed centralized allocation from one narrow scope. RFC 3927 lets a host select and probe an IPv4 link-local address, then claim and sometimes defend it. The address is non-routable and local to one link. This is not a substitute for durable, globally meaningful allocation authority.

RFC 5227 generalized IPv4 Address Conflict Detection with ARP Probes and Announcements. Its evidence remains local and time-bounded. Simultaneous isolation, partitions and malicious responders limit what absence of a reply can establish. Running reality can falsify a ledger entry; it cannot always certify the ledger’s opposite.

Running code kept the authority honest

Heng Lu’s Running-Code Primacy provides a useful analytical lens here. The authority database was the site’s symbolic record, but packets on the cable could contradict it. DRARP’s probe did not abolish administration. It forced administrative truth to meet an operational test before becoming executable allocation.

Minimum Initial Specification helps explain why the useful common rule was small: responders must agree, errors must be distinguishable, and temporary state must not be recycled before its dependencies can settle. The particular NIS tables, RPC machinery, cache period and local authorization practice could remain implementation choices.

The separation is also a case of reality layers. A database row can coordinate people and servers; a broadcast reply can configure a host; a live probe can expose conflict. Each has power, but not the same power. RFC 1931 is valuable because it refused to call five responding boxes five authorities—and refused to call one coherent database reality itself.

Sources

  1. RFC 1931 — Dynamic RARP Extensions for Automatic Network Address Acquisition
  2. RFC Editor — RFC 1931 current record
  3. RFC 903 — A Reverse Address Resolution Protocol
  4. RFC 826 — An Ethernet Address Resolution Protocol
  5. RFC 1541 — Dynamic Host Configuration Protocol
  6. RFC 2131 — Dynamic Host Configuration Protocol
  7. RFC 3927 — Dynamic Configuration of IPv4 Link-Local Addresses
  8. RFC 5227 — IPv4 Address Conflict Detection
  9. Heng Lu — Running-Code Primacy
  10. Heng Lu — Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
  11. Heng Lu — On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile