Summary

  • RFC 1542 required a BOOTP relay to send every request from one client to the same destination or destination set.
  • The rule addressed a specific failure mode: round-robin forwarding could scatter successive requests across servers when DHCP or another BOOTP variant relied on multiple exchanges.
  • The standard left room for load distribution through stable client-based selection, such as hashing a link-layer address.

A broadcast that needed a return path

BOOTP was designed for a machine that might start without knowing its own IP address or the server that could supply its boot information. In 1985, RFC 951 described an initial exchange for address determination and boot-file selection. A client could broadcast on its local network; a BOOTP server on another network would be unreachable through ordinary IP forwarding alone, because routers do not normally forward a subnet’s limited broadcast as a server request.

RFC 951 therefore made cross-gateway booting possible through cooperating gateways. The forwarding function was optional, and the document allowed it to live in a gateway or in another forwarding agent on the client’s network. A relay did more than move an unchanged IP packet: it handled a BOOTREQUEST, filled the BOOTP giaddr field when necessary, and incremented hops. That address gave the server a way to send its reply back toward the client’s network. The original specification sketched this arrangement, but left much of relay behavior open.

By October 1993, RFC 1532 had attempted to clarify BOOTP. RFC 1542 followed in the same month, updating RFC 951 and obsoleting RFC 1532 after editorial errors were introduced into the earlier document. Its abstract names relay-agent behavior as one of the areas needing a stronger specification. The change matters as protocol history: the relay was now treated as a defined participant in a client-server exchange, rather than as a convenient forwarding detail.

The destination rule

RFC 1542 gave network managers a local control surface. A relay had to offer a way to enable or disable BOOTREQUEST forwarding, and relaying had to be disabled by default. If enabled, it had to reject requests whose hops value exceeded 16; a smaller configurable threshold was encouraged. When giaddr was zero, the relay had to set it to an address of the receiving interface, increment hops, and preserve the other BOOTP fields. The destination or destinations were configurable, and the relay could use a unicast, multicast or broadcast arrangement appropriate to the network.

Then came the less obvious invariant: every BOOTREQUEST relayed from a given client had to use the same destination, or the same set of destinations. The document’s discussion explains why. It describes at least one known relay implementation that used round-robin load balancing, sending each new request to the next server in a list. Consecutive requests from one client could therefore land on different servers.

The danger was not load balancing in itself. It was making the routing decision independently for each packet when the protocol exchange could span several requests and replies. RFC 1542 says this arrangement reacts badly with DHCP and perhaps other BOOTP variations that depend on multiple exchanges. If one server sees an early request and another sees the next, the client and server-side state may no longer line up. The RFC identifies a protocol risk; it does not document a named outage or say how common the implementation was.

The suggested alternative is revealing. A relay could hash the client’s link-layer address, or another reliable identifier, and use that result to choose a destination or destination set. The result could still spread different clients across servers while preserving a client’s path. The simplest option was to forward all requests to one fixed destination set. In both cases, the load-balancing unit became the client rather than the individual BOOTREQUEST.

A narrow rule with a clear boundary

The requirement did not promise that a server would be available, that two servers would share state, or that a client would finish booting. It constrained only the relay’s destination choice across requests from the same client. Nor did it require all clients to use one server. A configured set could receive each client’s messages, and a stable mapping could distribute different clients among multiple destinations.

The rule fit the wider design of BOOTP. The relay was configured by the network operator; its destination set was not automatically inferred from ordinary router routes or from unrelated broadcast-forwarding settings. The standard defined the behavior needed for a coherent exchange and left the operator to decide whether and how relaying should be enabled. That is a small example of protocol text setting a common invariant while preserving local deployment choices.

RFC 1534, also published in October 1993, described how DHCP and BOOTP participants could interoperate because DHCP messages used a format based on BOOTP. RFC 2131, published in 1997, later laid out DHCP’s multi-step exchanges: a client can discover servers, receive offers, select one, and send further requests. These later documents make the exchange context legible, but they do not turn RFC 1542’s example into evidence of a particular production failure.

The RFC Editor lists one verified erratum for RFC 1542. It corrects a BOOTREPLY/BOOTREQUEST reference in §3.1.1, a broadcast-flag passage separate from §4.1.1’s relay-destination rule. Because RFCs remain published as issued and errata are listed separately, the correction is useful editorial context; it does not alter the affinity requirement discussed here.

The historical point is unusually concrete: a relay can distribute work and still preserve a client’s conversation, provided selection remains stable for that client. Round robin across packets breaks that property. Hashing a reliable client identifier or forwarding to a fixed destination set preserves it. RFC 1542 made this boundary explicit before DHCP’s later specification gave the multi-message exchange a fuller shape.

Sources