BOOTP was designed as an IP/UDP protocol rather than a hardware link-level protocol (unlike RARP) so it can be implemented without kernel or driver modifications. RARP required such modifications because it operated below the IP layer, making it impractical across diverse network kernel implementations.

ip, udp

Fixed-length fields of maximum reasonable length are used throughout the BOOTP packet to simplify structure definition and parsing. This is a deliberate tradeoff for PROM implementations where code size and parsing complexity are tightly constrained.

ip

The 'secs' field (seconds elapsed since the client started booting) serves as an implicit priority signal: as the value grows, servers that do not normally service a client 'may feel more sympathetic', allowing fallback server behavior without explicit protocol negotiation.

ip

The 'vend' field is recommended to begin with a 4-byte magic number so servers can identify what kind of vendor-specific information is present. Different magic numbers may be used for bootrequest versus bootreply to allow clients to take special action with reply data.

ip

Two reserved UDP ports (67 and 68) are used rather than one to avoid waking up BOOTP server daemons when a bootreply must be broadcast. Hosts not running the server will not listen on port 68, so incoming broadcasts on that port are filtered at the kernel level. A randomly chosen source port would risk confusing other hosts listening on that port.

udp, ip

BOOTP is designed to work with TFTP as the primary second-phase file transfer protocol, but may also work with SFTP or FTP. The 'file' field in the bootreply contains the fully qualified path name to be used in a TFTP 'read request'.

ip

Cross-gateway booting is an optional extension requiring cooperating gateways and servers. The forwarding agent (which may or may not be co-located with the gateway) fills in 'giaddr' and increments 'hops'. A non-gateway forwarding agent may use the broadcast address of the receiving interface as 'giaddr', allowing normal gateways to forward the reply without involving the agent.

ip

The BOOTP client may skip an ARP request for the server/gateway during the TFTP phase by using the hardware source address from the BOOTP reply's link-layer encapsulation. This should be treated as an optimization only, since second-phase-only boots (TFTP with pre-known addresses) must still be supported independently.

ip

A gateway forwarding a BOOTP request should plug its own IP address (on the receiving cable) into 'giaddr' if the field is zero, and should increment the 'hops' field on each forwarding. Packets with hops exceeding approximately 3 should be discarded to prevent broadcast loops.

ip

Before each retransmission, the client should update the 'secs' (elapsed seconds since boot start) field in the packet.

ip

The client should discard incoming packets that are not IP/UDP addressed to the boot port, are not BOOTREPLYs, do not match the client's IP address (if known) or hardware address, or do not match the client's transaction ID (xid).

ip, udp

The client should use exponential backoff for retransmission to avoid flooding the network, particularly during power-failure recovery when many machines boot simultaneously. After the average backoff reaches approximately 60 seconds it should not increase further, but randomization should continue.

udp, ip

The server should discard a bootrequest if ciaddr is zero and the client's hardware address (chaddr/hlen/htype) cannot be found in the server's database. If the requested boot filename is non-null but no matching file exists, the packet should also be discarded.

ip

The server should not depend on the 'vend' field existing or having a recognized format; its presence is optional. When recognized vendor data is provided, the server should take client-specific actions and place a response in the 'vend' field of the reply.

ip

The UDP checksum field may be set to zero by the client or server to avoid extra overhead in a PROM implementation, making checksum computation optional for BOOTP.

udp

BOOTP is a two-phase bootstrap protocol: phase 1 uses a single UDP packet exchange to determine the client's IP address, server address, and boot filename; phase 2 uses TFTP (or SFTP/FTP) to transfer the boot file. Both phases are intended to reside in PROM on the client.

ip, udp

BOOTP uses two reserved UDP ports: port 67 ('BOOTP server') and port 68 ('BOOTP client'). Clients send bootrequest packets to destination port 67 (usually broadcast); servers send bootreply packets to destination port 68 on the client.

udp, ip

The BOOTP server is expected to maintain two databases: one mapping generic boot file names (e.g., 'unix', 'gateway') to directory pathnames, and one mapping hardware address type/value pairs to IP addresses with optional per-client boot filename overrides and path suffixes.

ip

The 'xid' (transaction ID) is a 4-byte random number chosen by the client in the bootrequest and echoed in the bootreply. It is used to match requests with their corresponding responses, which is critical because replies may be broadcast to multiple clients.

ip

When ciaddr is zero (client does not know its IP), the server delivering a bootreply has two options: (a) manually inject an ARP cache entry mapping chaddr to yiaddr and unicast the reply, or (b) broadcast the reply on the appropriate interface.

ip

RFC 951 contains no dedicated Security Considerations section. The vend field is suggested as an optional authentication mechanism — 'a workstation client could provide an authentication key and receive from the server a capability for remote file access' — but no cryptographic mechanism is specified. The protocol relies entirely on network-level trust and offers no protection against spoofed bootreply packets.

security, ip

Address fields in the BOOTP packet: ciaddr (4 bytes, client IP if known, else zero), yiaddr (4 bytes, 'your' IP assigned by server), siaddr (4 bytes, server IP), giaddr (4 bytes, gateway IP for cross-gateway booting). All numeric fields are in network byte order (high order bits first).

ip, udp

Remaining BOOTP fields: chaddr (16 bytes, client hardware address), sname (64 bytes, optional null-terminated server hostname), file (128 bytes, null-terminated boot filename — generic name or null in request, fully qualified path in reply), vend (64 bytes, optional vendor-specific data).

ip, udp

The BOOTP packet is carried in an IP/UDP datagram and uses fixed-length fields in network byte order. Control fields: op (1 byte, 1=BOOTREQUEST/2=BOOTREPLY), htype (1 byte, ARP hardware type), hlen (1 byte, hardware address length), hops (1 byte, gateway hop count), xid (4 bytes, random transaction ID), secs (2 bytes, elapsed boot seconds), unused (2 bytes).

ip, udp