Summary

  • RFC 3074 mapped a client identifier or hardware address into one of 256 buckets so cooperating DHCP servers could decide who should respond from shared configuration rather than negotiate every request.
  • The RFC separately anticipated unavailable or address-exhausted assigned servers, unreliable client time fields, uncovered buckets and tampered assignments. A correct hash proved a configured choice, not live readiness or completed service.

When a DHCP client broadcasts a discovery request, several servers may hear it. They may all answer, leaving the client to choose, while a BOOTP relay can reproduce the same fan-out by forwarding the request to every configured destination. RFC 3074, published in February 2001 by B. Volz, S. Gonczi, T. Lemon and R. Stevens, proposed a quieter arrangement. Cooperating servers could reach the same serve/do-not-serve decision without exchanging information after their initial configuration.

The decision began with a Service Transaction ID. If a DHCP Client Identifier was present, servers had to use it. Otherwise they took the length from hlen and hashed chaddr, using no more than the first sixteen bytes. The specified Pearson function returned one value from 0 through 255. Each participant held a Hash Bucket Assignment, represented for a server as a 32-octet bitmap. A set bit meant that the server had to service requests whose transaction identifier landed in the corresponding bucket.

That design created a valuable kind of agreement. With the same input, mandated mixing table and matching HBA state, two implementations could calculate the same result independently. A relay could use Server-ID/bucket pairs to choose a forwarding destination. Continuous arbitration was unnecessary. The common algorithm turned a broadcast population into configured shares while preserving existing DHCP clients.

Yet the result was an assignment, not a health check. Nothing in the Pearson calculation queried whether the selected process was running, whether a network path reached it, whether its lease database agreed with its partner or whether its address pool still contained a suitable offer. The input described a client transaction. The HBA described administrative responsibility. Neither carried live capacity.

RFC 3074 says so in operational terms. It allows an implementation to handle the case where the server supposed to respond is unavailable or out of suitable addresses. The optional Delayed Service parameter lets a server normally excluded by the hash answer after S seconds have elapsed since the client's first attempt. The alternate does not overturn the arithmetic; it changes the service policy after waiting long enough for the first assignment to have had its opportunity.

Even the timer rests on qualified evidence. A server should use the secs field when the client supplies a nonzero value, but the RFC notes that some clients may not implement that field correctly. The server may instead remember the first request it declined and, when another request arrives with the same transaction ID and a zero secs value, calculate elapsed time locally. One method trusts a client-reported duration; the other infers duration by joining retries. They are substitutes for timing an attempt, not receipts proving why the assigned server stayed silent.

If Delayed Service is not configured, the HBA produces a strict serve/do-not-serve policy. Unassigned buckets cause some client service transactions to be ignored entirely, which the RFC says may be desirable in some scenarios. This makes configuration coverage a separate object of inspection. A flawless implementation can compute an uncovered value flawlessly and still produce no responder by design.

The load percentages have another boundary. RFC 3074 calls the method probabilistic because operators cannot predict which client will ask next. Over short periods, the share handled by one server can depart from its configured percentage; with more requests, the observed distribution should approach that allocation. The hash does not weigh current CPU, queue depth, free addresses or response time. It distributes identifiers, and the statistical balance depends on sufficient variety in transaction IDs.

Configuration is therefore part of the execution path. HBAs may come from a file, the Windows NT registry, EEPROM or an agreed algorithm, and may be carried inside another protocol. The RFC provides no security by itself. If HBA data travel over a network, the message must be protected against tampering because altered buckets can deny service to some or all clients. Identical code cannot rescue participants whose maps differ or whose common map has been maliciously changed.

The DHCP foundation reinforces the distinction. RFC 2131 expects a client to tolerate multiple replies and treats DHCP as a mechanism operating under local administrative policy. The service transaction may continue from DISCOVER to OFFER, REQUEST and ACK, after which the client still has to use the supplied configuration. RFC 3074 optimizes the first question—who should be permitted to answer—without collapsing all those later events into the hash result. RFC 1542 likewise provides relay behavior, not evidence that a particular relay adopted this selection scheme correctly.

Later DHCPv6 failover requirements in RFC 7031 make configuration agreement explicit as a recurring operational problem and place load balancing outside the core failover protocol. That later document should not be read backward as a report on any RFC 3074 deployment. It is useful because it preserves the category difference: distributing incoming work, synchronizing service state and surviving failure are related responsibilities, but they are not the same mechanism.

Running-Code Primacy offers a later lens for joining the receipts in the right order. The chain is: extract the intended STID, calculate the mandated bucket, confirm HBA coverage, identify the assigned server, observe reachability, verify suitable address capacity, evaluate any delayed-service takeover, record the offer and client choice, receive the ACK and test the resulting network configuration. Reality Layers asks why the symbolic certainty of a deterministic owner can feel like operational certainty even when the execution chain remains incomplete. These are later analytical tools, not claims made by the RFC's authors or the IETF.

RFC 3074's achievement was real. It reduced negotiation among cooperating servers and made a division of work reproducible with modest computation and no client changes. Its restraint was equally important. The document did not pretend that an assigned server must be alive or supplied, and it designed an optional escape for silence. The lesson is not that hashing failed. It is that the hash answered exactly one question.

A bucket can name the server configured to try first. It cannot report whether that server is present, capable, honest, synchronized or successful. When operators treat those claims as separate receipts, deterministic coordination remains useful without being promoted into evidence it never contained.

Sources