BOOTP: Bootstrap Protocol

In the early days of computer networking, configuring a new machine to join a network was a painstaking manual process. System administrators had to physically visit each machine, manually enter IP addresses, subnet masks, gateway addresses, and DNS server information. For networks with hundreds or thousands of machines, this was not just tedious—it was fundamentally unscalable.

The Bootstrap Protocol (BOOTP) emerged in 1985 as a revolutionary solution to this problem. Defined in RFC 951, BOOTP introduced the concept of automated network configuration—the ability for a machine with no pre-configured network settings to discover and obtain all the information it needed to become a functional network participant.

The implications were profound. For the first time, a computer could boot from the network itself, without local storage or pre-configured settings. This capability enabled diskless workstations, centralized system management, and laid the conceptual groundwork for the modern internet's plug-and-play networking.

To appreciate BOOTP's significance, we must understand the network configuration landscape before its introduction.

The Manual Configuration Burden

In early TCP/IP networks, every host required manual configuration of at least four critical parameters:

1. IP Address — A unique 32-bit identifier within the network
2. Subnet Mask — Defining the boundary between network and host portions
3. Default Gateway — The router through which to reach non-local destinations
4. DNS Server(s) — For hostname-to-IP resolution

For a modest corporate network of 500 machines, this meant 2,000 individual configuration entries—each susceptible to typos, duplicates, and documentation lag. Network administrators maintained spreadsheets, walked between buildings with floppy disks, and dreaded the day when subnet reorganization would require touching every machine.

The RARP Partial Solution

Before BOOTP, the Reverse Address Resolution Protocol (RARP) offered a primitive automated solution. RARP allowed a machine knowing only its hardware (MAC) address to discover its IP address by broadcasting a query.

However, RARP had severe limitations:

• Link-layer dependency — RARP operated at Layer 2, meaning it couldn't cross routers. Each subnet required its own RARP server.
• IP address only — RARP provided just the IP address, not the gateway, subnet mask, or DNS servers.
• No boot image location — Diskless workstations still needed a separate mechanism to find their operating system images.
• Fixed table updates — RARP servers required manual table updates for each new MAC address.

The networking community needed something more capable.

BOOTP was designed with specific architectural principles that addressed RARP's shortcomings while enabling future extensibility.

Core Design Principles

1. Transport Layer Operation — By using UDP over IP, BOOTP messages are routable. A single BOOTP server can serve multiple subnets via relay agents.

2. Fixed Message Size — BOOTP uses a fixed 300-byte message format, simplifying implementation and ensuring predictable behavior across all implementations.

3. Stateless Server Design — The BOOTP server maintains no memory of previous transactions. Each request is self-contained, with the MAC address serving as the client identifier.

4. Static Mapping Model — Unlike later DHCP, BOOTP maps MAC addresses to IP addresses statically. The administrator pre-configures all assignments; BOOTP merely distributes them.

5. Boot Image Support — BOOTP natively supports providing the filename and location of a boot image, enabling diskless workstations to bootstrap from the network.

The Client-Server Model

BOOTP employs a straightforward client-server architecture:

• BOOTP Client (bootpc) — The machine seeking configuration, typically a device during power-on with no network parameters configured. Listens on UDP port 68.

• BOOTP Server (bootps) — The configuration authority maintaining MAC-to-configuration mappings. Listens on UDP port 67.

• BOOTP Relay Agent — An optional intermediary (typically a router) that forwards BOOTP messages between subnets, enabling centralized server deployment.

The port numbers (67 and 68) were deliberately chosen below the privileged port threshold (1024), requiring server processes to run with elevated privileges—an early security consideration.

The BOOTP message format is a masterpiece of protocol design for its era—balancing simplicity, efficiency, and extensibility within a fixed 300-byte structure. Understanding each field illuminates both BOOTP's capabilities and its constraints.

The 300-Byte Message Structure

BOOTP messages use a fixed 300-byte format, split into well-defined fields. Both requests and replies use identical structures, with different fields populated depending on message direction.

Field-by-Field Analysis

Operation Code (op) — The single byte distinguishing requests from replies. A client always sends op=1; a server always sends op=2. This simplicity means parsers can determine message direction immediately.

Hardware Address Fields (htype, hlen, chaddr) — These fields support various network hardware types. For Ethernet, htype=1 and hlen=6. The chaddr field holds the 6-byte MAC address, padded to 16 bytes for future hardware types with longer addresses.

Transaction ID (xid) — A 32-bit random number generated by the client and echoed by the server. This allows clients to match incoming replies to their outstanding requests, crucial when multiple transactions may be in flight.

Seconds Elapsed (secs) — Indicates how long the client has been trying to boot. Servers may use this field to prioritize long-waiting clients or to trigger backup server activation.

Address Fields (ciaddr, yiaddr, siaddr, giaddr) — These four IP address fields form the configuration payload:

• ciaddr — Set by clients that already know their IP (renewal scenarios)
• yiaddr — The IP address assigned to the client by the server
• siaddr — Points to the server hosting the boot image (may differ from BOOTP server)
• giaddr — Set by relay agents to indicate which subnet the client is on

BOOTP employs a simple two-message exchange: the client broadcasts a BOOTREQUEST, and the server sends back a BOOTREPLY. This simplicity reflects BOOTP's stateless design philosophy.

Phase 1: Client Broadcast (BOOTREQUEST)

When a BOOTP client boots:

1. Generate Transaction ID — The client creates a random 32-bit xid value to identify this configuration attempt.

2. Construct BOOTREQUEST — The client populates:

   • op = 1 (request)
   • htype = 1 (Ethernet)
   • hlen = 6 (MAC length)
   • xid = generated random value
   • chaddr = client's MAC address
   • All IP fields = 0.0.0.0 (unknown)

3. Broadcast Message — The client sends the UDP datagram to:

   • Source IP: 0.0.0.0 (client has no IP yet)
   • Destination IP: 255.255.255.255 (limited broadcast)
   • Source Port: 68 (bootpc)
   • Destination Port: 67 (bootps)

Phase 2: Server Response (BOOTREPLY)

When a BOOTP server receives a BOOTREQUEST:

1. MAC Address Lookup — The server searches its configuration database for an entry matching the chaddr field.

2. If Match Found — The server constructs a reply with:

   • op = 2 (reply)
   • xid = same as request (for matching)
   • yiaddr = assigned IP address for this client
   • siaddr = boot server address
   • file = boot filename (if configured)
   • vend = any vendor-specific options

3. Reply Delivery — Here's where BOOTP faces an interesting challenge. The client doesn't have an IP address yet, so how should the reply be addressed?

Reply Addressing Options:

• Unicast to yiaddr — The server sends directly to the IP it's assigning. This requires the server to insert an ARP entry temporarily, or the client to accept packets before its IP is configured.

• Broadcast — If the client set the broadcast flag, or the server cannot unicast, the reply goes to 255.255.255.255. All clients must examine the xid to determine ownership.

• Hardware Unicast — Some implementations send to the client's MAC address directly at Layer 2, regardless of IP destination.

One of BOOTP's most important architectural innovations is the relay agent mechanism, which allows a single centralized BOOTP server to serve clients across multiple subnets. This was a direct solution to RARP's fundamental limitation of being non-routable.

The Problem: Broadcasts Don't Cross Routers

When a client broadcasts a BOOTREQUEST to 255.255.255.255, that broadcast is confined to the local subnet by design. Routers do not forward limited broadcasts. Without relay agents, every subnet would require its own BOOTP server—negating much of the protocol's administrative benefit.

The Solution: The BOOTP Relay Agent

A BOOTP relay agent (also called a BOOTP forwarder or helper) is a network device—typically a router—that:

1. Listens for BOOTP broadcasts on local interfaces
2. Forwards requests as unicast to configured BOOTP server(s)
3. Stamps the giaddr field with the relay agent's IP address on the client's subnet
4. Receives unicast replies from the server
5. Forwards replies to the client (broadcast or unicast, depending on flags)

Relay Agent Configuration (Cisco Example)

On Cisco routers, BOOTP/DHCP relay is configured using the ip helper-address command on each client-facing interface:

The 64-byte vendor-specific (vend) field was BOOTP's forward-looking provision for extensibility. This field became the seed from which DHCP's rich options framework grew.

Original Vendor Extensions (RFC 1048)

RFC 1048 defined the first structured format for the vend field, introducing the concept of BOOTP Vendor Extensions. The field begins with a 4-byte "magic cookie" (99.130.83.99 or 0x63825363) indicating that structured options follow.

Option Format:

[Tag: 1 byte][Length: 1 byte][Data: Length bytes]

This Tag-Length-Value (TLV) encoding remains the foundation for DHCP options today.

The 64-Byte Limitation

The 64-byte vend field size proved constraining as needs grew. Consider that just specifying three gateway addresses consumes 14 bytes (tag + length + 12 address bytes). Add a subnet mask (6 bytes), DNS servers (10 bytes for two), and you've exhausted most of the space.

Solutions to Space Constraints:

1. Option Overloading — RFC 1533 defined options 52 (overload) allowing the 'sname' and 'file' fields to carry additional options if not needed for their primary purpose.

2. Long Message Extension — Some implementations allowed messages longer than 300 bytes, though this risked interoperability issues.

3. DHCP — The eventual solution was DHCP, which expanded options to 312 bytes minimum and defined mechanisms for larger options.

The vendor extensions mechanism demonstrated both BOOTP's architectural foresight and its practical limitations, directly motivating DHCP's development.

Implementing a BOOTP server requires careful consideration of database design, message processing, and error handling. While modern networks use DHCP, understanding BOOTP server operation illuminates the configuration management problem space.

The bootpd Configuration File

The traditional Unix BOOTP daemon (bootpd) uses a simple text configuration file mapping MAC addresses to configuration sets:

Server Processing Logic

A BOOTP server follows this processing sequence for each incoming request:

1. Validate Message — Check op=1 (request), verify message length and format.

2. Extract Client Identifier — Pull the chaddr (MAC address) as the lookup key.

3. Check giaddr — If non-zero, the request came via relay agent. Use giaddr to select the correct IP pool.

4. Database Lookup — Search for a configuration entry matching the client's MAC address.

5. If No Match — Either ignore silently or log the unknown MAC. BOOTP has no NAK mechanism.

6. Build Reply — Populate yiaddr, siaddr, file, and vendor options from the configuration.

7. Determine Reply Address — Check if broadcast flag is set or if unicast is feasible.

8. Send Reply — Transmit the BOOTREPLY.

Server Implementation Considerations

• Concurrency — Multiple clients may request simultaneously. The server must be thread-safe or use non-blocking I/O.

• Logging — Every transaction should be logged with timestamp, MAC, and assigned IP for troubleshooting.

• Failover — With static mappings, multiple servers can run with identical configurations for redundancy.

• Cache Insertion — Before unicasting to yiaddr, the server may need to insert a temporary ARP entry so the client can receive the reply.

• Security — Anyone who can broadcast on the network can request configuration. BOOTP has no authentication mechanism.

BOOTP represents a pivotal advancement in network configuration management. Its concepts and mechanisms remain foundational to modern networking infrastructure.

Looking Ahead

While BOOTP solved immediate configuration challenges, its static nature created new limitations as networks grew and became more dynamic. Mobile users, temporary devices, and address conservation requirements demanded something more flexible.

In the next page, we'll compare BOOTP with its evolutionary successor, DHCP, examining how dynamic allocation and lease management extended BOOTP's foundation to meet modern networking demands.