Summary

  • RFC 3074 let cooperating DHCP servers make the same local decision from a client identifier and a preconfigured 256-bucket assignment, without negotiating on every request.
  • Its hash divided permission to answer, not measured server work: empty buckets could mean silence, delayed service could only wait out that silence, and neither configuration nor standards status proved a client got a lease.

A division of replies, not a live load meter

DHCP broadcasts can reach several servers at once. In 2001, RFC 3074 offered a way to reduce that duplicate work without changing clients: each participating server would calculate the same hash for a service transaction and respond only when the result fell inside its assigned Hash Bucket Assignment, or HBA.

The key was the DHCP Client Identifier when present. Otherwise the server used the hardware-length field and client hardware address, taking no more than the first sixteen bytes. Pearson’s hash returned one of 256 values. A 32-octet bitmap represented which values a server could serve; a relay could instead map bucket ranges to server IDs and forward requests selectively.

That design replaced repeated negotiation with an initial configuration decision. It began as an optimization for a DHCP failover proposal, then widened into a method for cooperating servers and BOOTP relays. Its promise was operational economy: no per-request exchange among servers, and no new behavior required from clients.

But the percentage on the configuration screen was not a measurement of CPU, lease-pool pressure, response time or successful allocations. The RFC says a server’s share may stray from its target over short intervals and approach it as request volume grows. That is a statement about the distribution of client transactions over time, not proof that each transaction costs the same or that the servers finish equal work.

The unowned bucket was a policy choice

The sharpest edge is not the hash function. It is the bitmap. RFC 3074 says a request mapped to an unassigned value may be entirely ignored. The authors note that such a gap can be desirable in some scenarios. The design therefore allowed silence to be configured—not merely caused by packet loss.

An optional Delayed Service interval softened that rule: a server that was not meant to serve a request could answer after the client had waited. This is a timer-based escape hatch, not a live quorum or proof that the designated server failed. The RFC also permits implementations to handle an unavailable selected server or one with no suitable addresses, but leaves the details to the implementation.

The relay variant makes the boundary visible. A relay can direct each bucket to one server, or to a primary-backup pair running a separate failover arrangement. Selection, forwarding, lease state and the client’s eventual use of its address are different steps. RFC 3074 specifies one selection mechanism; it does not turn the bitmap into shared lease state or an end-to-end receipt.

The Datatracker continues to list RFC 3074 as an IETF Proposed Standard. That standing records a standards-track document, not contemporary adoption. RFC 8156, published in 2017, later defines DHCPv6 failover and lease takeover after a server failure or network partition. It is useful contrast, not evidence that RFC 3074 was updated or deployed.

Heng Lu’s later “Reality Layers” note offers an editorial lens rather than DHCP evidence: keep the written rule, the operator’s configuration, the server’s observed behavior and the client’s result separate. Under that lens, RFC 3074’s historical contribution is precise. It made response eligibility computable. It did not make the service outcome self-proving.

Sources