Summary

  • In 1985 BOOTP let a diskless client ask for an address and boot-file instructions before it could send an ordinary IP request to a server. A relay could carry that exchange across network boundaries.
  • The field called giaddr recorded the BOOTP relay path. RFC 1542 later made explicit that it was not the client’s general-purpose IP router or default route.

A machine needs help before it can ask for help

A freshly powered diskless workstation faced a small but consequential loop. It needed an Internet address before it could use IP, yet it needed the network to learn which address to use. It also needed to know which server and file could continue the startup. If the boot server sat on another network, a local broadcast could not simply travel through ordinary routers to reach it.

This was a practical design problem, not a claim that every workstation booted the same way. RFC 951, published in September 1985, described the first BOOTP phase as address determination and boot-file selection. A client sent a BOOTREQUEST containing its hardware address and, if it knew one, its own IP address. When the client had no address, a server could look up the hardware address in its own database and return the chosen address in yiaddr. Other fields named the server address and boot file. The request and reply used UDP ports 67 and 68.

That exchange did not itself load the operating system. RFC 951 explicitly separated selecting an address and file from the next phase, normally a TFTP transfer. RFC 906 had described network boot loading with TFTP a year earlier. Separating the control message from file transfer mattered: a BOOTP reply could name a server and file without proving that the client reached the server, received every byte, or completed a boot.

A local broadcast, then a service-specific relay

BOOTP did not ask a client with no configuration to discover a remote server through DNS or a preconfigured route. It could broadcast on the local cable. Where a server was not attached to that cable, a gateway or forwarding agent could carry the BOOTP request outward and return the response. RFC 951 made that cross-gateway behavior optional and said it required additional code in gateways and servers, but no special client action.

The packet included giaddr, described in 1985 as a gateway IP address. In the forwarding procedure, the first gateway could fill an empty field with its own address and increment the hops count. A server receiving a request with nonzero giaddr could send its BOOTP reply to that address, using the server port, so the relay could deliver it back on the client’s network. The field therefore helped connect a local booting device to a service located elsewhere.

That path was not the same thing as the route the newly booted host would later use. RFC 951’s early wording left room for confusion: one passage suggested that packets should be forwarded through giaddr “in order to get to the server.” But the server’s boot-file transfer and the client’s ordinary IP routing were separate jobs. A name that included “gateway” was not enough to establish that both jobs used the same address.

The 1993 clarification changed the reading

Eight years later, RFC 1542 addressed the ambiguity directly. It said the earlier specification had not clearly defined forwarding-agent behavior and adopted the term “relay agent” to distinguish the function from normal IP forwarding. A BOOTP relay is an endpoint for the BOOTP message: it receives one message and generates another. It is not simply an IP router passing an ordinary datagram through unchanged. The relay could conveniently run in an interconnecting router, but the specification also allowed a host directly attached to the client network to provide the function.

RFC 1542’s interpretation of giaddr is the crucial distinction. The field exists to move BOOTREQUEST messages through relay agents toward servers on other networks, and BOOTREPLY messages back through those agents. The RFC says it does not represent a general IP router for the client and tells clients not to interpret it as one. A host that needs to reach a nonlocal TFTP server still needs a separate first-hop router address, supplied through another configuration mechanism or discovery process.

This clarification did not erase the 1985 design. It made its boundary easier to see. The relay answered a question about how the boot service could reach a client before ordinary client configuration was complete. It did not answer every question needed for the client’s later traffic.

What central booting bought—and what it left open

A relay let the boot server and its address-to-hardware and boot-file records sit away from the client’s local cable. That could reduce the need to place a separate boot server on every segment, while giving the service operator a central place to maintain mappings and files. This is an architectural implication of the documented exchange, not a measured account of how many networks adopted it or of their costs.

It also concentrated operational dependencies. The client still needed a working local link and relay; the relay needed a configured destination; the server needed a matching record and file; and the client needed a valid route and a successful transfer after the reply. A visible BOOTP answer proves none of those later steps by itself. Nor does the relay’s address identify a human, prove authorization, or declare the client’s default route.

DHCP later reused the relay-agent behavior while adding configuration and address-allocation modes, including finite leases. That lineage should not blur the distinction between BOOTP’s startup exchange, DHCP’s lease lifecycle, the TFTP file transfer, and ordinary IP routing. The same network may involve all four, but each has a different state and a different record to inspect.

The historical lesson sits in a four-letter field. giaddr helped a message cross a boundary while the host was still learning how to participate in IP. Calling it a gateway did not make it the host’s gateway. In Internet infrastructure, a control message’s return path, a client’s next hop, a file server’s address and a successful service are related facts, not interchangeable proofs.

Sources