Clarifications and Extensions for the Bootstrap Protocol
obsoletes
- rfc-1532 — Clarifications and Extensions for the Bootstrap Protocol
updates
- rfc-951 — Bootstrap Protocol
Extracted elements (31)
All BOOTREQUEST messages from a given client MUST go to the same relay destination to maintain session coherence with DHCP and other protocols that depend on multiple request/reply exchanges. Round-robin load balancing breaks this invariant and caused known interoperability failures.
The BROADCAST flag was added as a workaround for client implementations that cannot receive unicast datagrams before knowing their IP address. The workaround is discouraged and such implementations SHOULD be fixed to accept unicast BOOTREPLY messages.
The 'giaddr' field is poorly named; it does not represent a general IP router for the client to use post-boot. RFC 951 Section 7.5 implied it could be used as a first-hop for TFTP, which is incorrect because relay agents may not be IP routers and may hold broadcast addresses.
The term 'BOOTP relay agent' replaces 'BOOTP forwarding agent' to avoid confusion with IP router forwarding. A relay agent receives BOOTP messages as a final destination and generates new messages; it must not simply forward packets transparently like a router.
On IEEE 802.5 Token Ring networks, BOOTP clients SHOULD send BOOTREQUEST with an All Routes Explorer RIF to enable servers/relay agents to cache the return route. BOOTREPLY messages SHOULD be sent to the client's hardware address using a Spanning Tree Rooted RIF when the return route cannot be cached.
The bit ordering of hardware addresses in 'chaddr' SHOULD follow the ARP convention for the client's link-layer network. As a consequence, an IEEE 802.5 client's 'chaddr' bit ordering is the opposite of a DIX Ethernet client's, and relay agents must not alter it.
The 'ciaddr' field has been subject to multiple conflicting interpretations. Placing a non-zero value in 'ciaddr' can prevent the BOOTREPLY from reaching the client if the client is not yet listening on or is on the wrong subnet for that address; placing 0.0.0.0 is the safest and most interoperable behavior.
A BOOTP client MUST set the 'giaddr' field to zero (0.0.0.0) in all BOOTREQUEST messages it generates. A client MUST NOT interpret the 'giaddr' field of a BOOTREPLY as the IP address of an IP router, and SHOULD completely ignore it.
A configuration mechanism MUST exist to enable or disable relaying of BOOTREQUEST messages, and relaying MUST be disabled by default. The relay agent MUST silently discard BOOTREQUEST messages whose 'hops' field exceeds 16; a configurable threshold SHOULD default to 4.
A relay agent MUST silently discard any received UDP messages whose UDP destination port is BOOTPC (68). Only messages to BOOTPS (67) are considered for relay agent processing.
A relay agent MUST use the same relay destination (or set of destinations) for all BOOTREQUEST messages from a given client. Round-robin load balancing across servers is prohibited because it breaks DHCP's multi-exchange protocol flow.
BOOTP messages MUST be at least 300 octets (the minimum BOOTP header size). Messages larger than this minimum MUST also be accepted. Messages with an 'op' field other than BOOTREQUEST (1) or BOOTREPLY (2) MUST be silently discarded.
BOOTP servers MUST accept BOOTREQUEST messages with IP source 0.0.0.0 despite Martian address filtering. Servers MUST silently discard messages addressed to BOOTPC (68).
BOOTP servers SHOULD preserve the 'ciaddr' field contents in BOOTREPLY messages, exactly matching what was in the corresponding BOOTREQUEST. The 'ciaddr' field alone SHOULD NOT be trusted as the sole key in identifying a client.
Hosts or routers supporting a BOOTP relay agent MUST accept BOOTREQUEST messages with IP source address 0.0.0.0 for local delivery to the relay agent, bypassing normal Martian address filtering. BOOTREQUEST messages from legal IP source addresses MUST also be accepted.
If a client cannot receive unicast IP datagrams before knowing its IP address, it SHOULD set the BROADCAST flag to 1 in BOOTREQUEST messages. Clients able to receive unicast replies SHOULD NOT set the BROADCAST flag (SHOULD clear it to 0).
Server BOOTREPLY delivery algorithm: if 'ciaddr' is non-zero, unicast to 'ciaddr' on BOOTPC (68); else if 'giaddr' is non-zero, unicast to 'giaddr' on BOOTPS (67); else if BROADCAST flag=1, broadcast to 255.255.255.255 on BOOTPC (68); else unicast to 'yiaddr'/'chaddr' on BOOTPC (68).
The 'chaddr' field MUST be preserved exactly as specified by the BOOTP client. A relay agent MUST NOT reverse the bit ordering of 'chaddr' even when relaying between networks that use different bit orderings.
The relay agent MUST increment the 'hops' field and MUST preserve all other BOOTP fields intact when relaying a BOOTREQUEST. The relay destination MUST be configurable and SHOULD be independent of destinations for other broadcast forwarders.
The reserved bits (bits 1–15) of the 'flags' field MUST be set to zero by clients in all BOOTREQUEST messages. Servers and relay agents MUST ignore these reserved bits.
The 'secs' field SHOULD represent the elapsed time in seconds since the client sent its first BOOTREQUEST message; the first message SHOULD set 'secs' to zero. Clients SHOULD NOT use a constant value for this field.
When delivering a BOOTREPLY to a client, the relay agent SHOULD check the BROADCAST flag: if set to 1, the reply SHOULD be broadcast using 255.255.255.255 and the link-layer broadcast; if cleared, the reply SHOULD be unicast to 'yiaddr'/'chaddr'. The UDP destination port MUST be BOOTPC (68).
When relaying a BOOTREPLY, if the 'giaddr' field does not match one of the relay agent's directly-connected logical interfaces, the BOOTREPLY MUST be silently discarded. All BOOTP fields MUST be preserved intact; the relay agent MUST NOT modify any field.
When relaying a BOOTREQUEST, the relay agent MUST fill 'giaddr' with the receiving interface's IP address if 'giaddr' is zero; if 'giaddr' is non-zero, it MUST NOT be modified. The relay agent MUST NOT under any circumstances place a broadcast address in 'giaddr'.
The BROADCAST (B) flag is the most significant bit of the 'flags' field. When set to 1 by a client, it signals that servers and relay agents should broadcast the BOOTREPLY rather than attempt unicast delivery to a client that may not yet be able to receive unicast datagrams.
The 'giaddr' (gateway IP address) field facilitates relay of BOOTREQUEST messages from clients through relay agents to servers on different networks. It is set by the relay agent to its receiving interface address, not by the client, and must never contain a broadcast address.
The 'secs' field is a 2-octet field representing elapsed seconds since the client sent its first BOOTREQUEST. Servers and relay agents MAY use it as a policy control mechanism, e.g., for load shedding or prioritizing long-waiting clients.
The 'vend' field's first four octets SHOULD contain a magic cookie (99.130.83.99 in dotted decimal for the standard format) to identify the vendor information format. If no information follows, the byte after the cookie SHOULD be the 'End' tag (255) and remaining bytes zeroed.
BOOTP provides no authentication between servers and clients, making it vulnerable to rogue servers that can supply false IP addresses, incorrect routing information, and spoofed DNS server addresses. Unauthorized relay agents present similar risks. Malicious clients can masquerade as legitimate ones or exhaust dynamically allocated resources.
The BOOTP message format consists of: op (1), htype (1), hlen (1), hops (1), xid (4), secs (2), flags (2), ciaddr (4), yiaddr (4), siaddr (4), giaddr (4), chaddr (16), sname (64), file (128), vend (64) — totaling a minimum of 300 octets in the UDP data field.
The 'flags' field is a 2-octet field located between 'secs' and 'ciaddr'. The most significant bit is the BROADCAST (B) flag; the remaining 15 bits are reserved (MBZ). Previously this field was designated 'unused' in RFC 951.