Summary

  • BOOTP let a diskless client ask for its IP address, a server and a boot-file name before it had ordinary IP connectivity; a separate transfer, typically TFTP, fetched the file.
  • The reply exposed a second bootstrap problem: a client without an address could not answer ARP. RFC 951 described either a temporary server-side ARP entry or a broadcast reply, while later BOOTP relay rules carried requests across subnets.

At power-on, a diskless workstation did not yet have an operating system to configure its network. Its PROM could send a request, but it needed the network to tell it which address to use and which file to load. Then it could ask for that file. The sequence began with a dependency that looked circular: how does a machine receive a network-layer answer before it has a network-layer identity?

Bill Croft and John Gilmore described that problem in RFC 951 in September 1985. BOOTP was not a file-transfer protocol. It handled the first phase: address determination and boot-file selection. The client's PROM could request an address, a server and a file name; after a reply, a second phase—typically TFTP—could fetch the file into memory. The paper proposed that the sequence could run without a person at an unattended power-up. It described a design, not a census of how many machines used it. (RFC 951, §§2, 7.5.)

The request did not need an IP address it did not yet know. When the client and server were not already specified, the client could send an IP/UDP packet from source address zero to 255.255.255.255, a broadcast on the local cable. The request also carried the client's hardware type and address and a transaction identifier. The server could match that hardware address to an IP address in its own database, put the result in the reply's yiaddr field, and select a fully qualified boot-file path. A generic request such as unix could resolve to a file customized for that client. BOOTP made that local server record part of the startup path. (RFC 951, §§2–3, 7.1, 7.3, 9.)

The first reply had its own chicken-and-egg problem. A server normally needs ARP to learn the link-layer address for an IP destination. But this client did not yet know its IP address and could not answer the server's ARP request. RFC 951 gave two ways around the gap. A system with suitable kernel or driver support could create a temporary ARP cache entry from the client's hardware address and the proposed IP address, with a timeout. The RFC specifically noted that UNIX 4.2 BSD had this capability. Without those hooks, the server could broadcast the reply on the client's interface. The protocol left the workaround tied to the transmitter's local network facilities. (RFC 951, §4.)

The two UDP port numbers also served that return path. Requests went to the BOOTP server port, 67; replies went to the client port, 68. RFC 951 explained why the ports were separate: a broadcast reply could be filtered by the kernel on hosts that were not listening on the client port, instead of waking and scheduling unrelated BOOTP server daemons. A random client port could also make the broadcast appear relevant to another host's listener. The detail was not decorative protocol bookkeeping; it kept a one-client startup answer from becoming everyone else's application event. (RFC 951, §3.)

The local cable was not always where the boot server lived. RFC 951 made cross-gateway booting optional and cooperative. A gateway or another forwarding agent could receive a broadcast, set giaddr to identify the client-side network, and pass a request toward a server. The authors warned against simply rebroadcasting requests everywhere because loops could follow. In October 1993, RFC 1542 tightened this boundary: a BOOTP relay agent was not merely an IP router transparently forwarding a datagram. It could receive a BOOTP message as a final destination and generate a new BOOTP message. The function could live on a router or on a separate host attached to the client subnet. Relaying was a configured role with its own message-processing rules. (RFC 951, §8; RFC 1542, §§4–4.1.)

This is why BOOTP should not be collapsed into “old DHCP.” RFC 2131 later described DHCP as an extension of the BOOTP mechanism, preserving the message format and relay behavior so existing clients and servers could interoperate. It also named a central change: DHCP could grant a finite lease and reuse an address after a client no longer needed it. BOOTP's 1985 model instead looked up a client's address and boot-file choice in server records. DHCP could still make a manual assignment, so the difference was not that every later address became temporary; it was that dynamic allocation entered the protocol. (RFC 2131, §§1–2.)

BOOTP's historical work was modest but necessary. It did not make a diskless machine self-sufficient, authenticate a user, or move an operating-system image by itself. It defined how a machine with a hardware address but no usable IP identity could ask for the next pieces of its startup, how a server could choose those pieces, and how a response could get back before ARP worked normally. Internet connectivity began, in this case, with a local broadcast, a server's explicit record and a specially handled reply.

Sources and limits

RFC 951 was a proposed protocol and documents intended behavior, not a deployment census. Its description of one 4.2 BSD ARP-cache facility does not prove that every implementation had it. RFC 1542 records later relay rules, not universal compliance. BOOTP selected network parameters and a file name; a separate transfer protocol fetched the file. DHCP added dynamic leases but also retained manual allocation.