A relay agent is distinct from an IP router: it receives BOOTP messages as a final destination and generates new ones, rather than forwarding packets transparently. This distinction justifies placing relay-agent logic in routers but also allowing it in directly-connected hosts.

ip

The BROADCAST flag is explicitly described as a workaround for client implementations that cannot receive unicast IP datagrams before learning their IP address. Its use is discouraged; such client implementations SHOULD be modified to accept unicast replies instead.

ip

The 'giaddr' field name ('gateway' address) is acknowledged as 'poorly named.' It exists solely to route BOOTP exchanges between relay agents and servers, not as a general first-hop IP router for the client. Its misinterpretation as a router address (suggested in RFC 951 Section 7.5) is explicitly prohibited here.

ip

The 'secs' field was left vague in RFC 951, leading to implementations that used a constant value or incorrect byte-ordering. This memo clarifies it as elapsed time since the first BOOTREQUEST, enabling servers and relay agents to implement threshold-based policies for handling long-waiting clients.

ip

For BOOTP over IEEE 802.5 Token Ring networks, the client SHOULD send its broadcast BOOTREQUEST with an All Routes Explorer RIF; servers/relay agents that cannot cache the return route SHOULD reply using a Spanning Tree Rooted RIF. This avoids communication failures on bridged rings where the server is on a different segment.

ip

Unless otherwise specified, the requirements in this document also apply to extensions to BOOTP such as DHCP (RFC 1531). In particular, the prohibition on round-robin relay-agent load-balancing is explicitly motivated by DHCP's dependence on multiple sequential BOOTREQUEST/BOOTREPLY exchanges with the same server.

ip

A BOOTP client MUST set the 'giaddr' field to 0.0.0.0 in all BOOTREQUEST messages it generates. A client MUST NOT interpret the 'giaddr' field in a BOOTREPLY as an IP router address and SHOULD completely ignore it.

ip

A BOOTP server SHOULD preserve the 'ciaddr' field contents in BOOTREPLY messages, so that the reply's 'ciaddr' exactly matches what was sent in the corresponding BOOTREQUEST.

ip

A client that cannot receive unicast IP datagrams before knowing its IP address SHOULD set the BROADCAST flag to 1; a client capable of receiving unicast BOOTREPLY messages SHOULD NOT set it. This use of broadcast is explicitly discouraged as a workaround for old implementations.

ip

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 value exceeds a configurable threshold (default SHOULD be 4).

ip

A relay agent MUST silently discard any received UDP message whose UDP destination port number is BOOTPC (68); there is no need for relay agents to process client-bound BOOTPC messages.

ip

A relay agent MUST use the same destination (or set of destinations) for all BOOTREQUEST messages it relays from a given client. Round-robin load-balancing across servers is prohibited because it breaks multi-exchange protocols like DHCP.

ip

A relay agent relaying a BOOTREPLY SHOULD examine the BROADCAST flag: if set, the reply SHOULD be sent to IP 255.255.255.255 with link-layer broadcast; if cleared, the reply SHOULD be unicast to 'yiaddr' at the 'chaddr' link-layer address. The UDP destination port MUST be BOOTPC (68).

ip

BOOTP messages that fail consistency checks (IP/UDP length too small for 300-octet minimum payload, or 'op' not 1 or 2) MUST be silently discarded. Messages larger than the minimum MUST be accepted to allow future protocol extensions.

ip

Clients MUST set the reserved (MBZ) bits of the 'flags' field to zero in all BOOTREQUEST messages; servers and relay agents MUST ignore those bits. A client MUST also ignore these bits in received BOOTREPLY messages.

ip

Hosts or routers supporting a BOOTP relay agent MUST accept for local delivery BOOTREQUEST messages whose IP source address is 0.0.0.0, overriding the normal 'Martian address filtering' rule. Legal IP source addresses MUST also be accepted.

ip

Hosts or routers supporting a BOOTP server MUST accept BOOTREQUEST messages with IP source 0.0.0.0 (overriding Martian filtering) and MUST silently discard any UDP message with destination port BOOTPC (68).

ip

If a BOOTP client does not know its IP address it SHOULD set 'ciaddr' to 0.0.0.0; it MAY fill 'ciaddr' with a previously-assigned or preconfigured address, but it MUST then be prepared to receive datagrams at that address and answer ARP requests. The client SHOULD adopt the 'yiaddr' address assigned by the server as soon as possible.

ip

It is RECOMMENDED that a BOOTP client always fill the first four octets of the 'vend' field with a magic cookie; if no special vendor-specific cookie is used, the standard value 99.130.83.99 SHOULD be placed there, followed by an 'End' tag (255) and zeros if the client has no additional vendor information.

ip

When a relay agent receives a BOOTREPLY whose 'giaddr' does not match any of its own directly-connected logical interfaces, the message MUST be silently discarded. All BOOTP fields MUST be preserved when relaying a BOOTREPLY; the relay MUST NOT modify any field.

ip

When relaying a BOOTREQUEST, if 'giaddr' is zero the relay agent MUST fill it with the IP address of the receiving interface; if 'giaddr' is already non-zero it MUST NOT be modified. The relay agent MUST NEVER fill 'giaddr' with a broadcast address.

ip

When relaying a BOOTREQUEST, the relay agent MUST increment the 'hops' field and MUST preserve all other BOOTP fields intact. The relay MUST NOT rebroadcast the BOOTREQUEST on the physical interface from which it was received if it arrived as a broadcast.

ip

BOOTREPLY delivery follows a priority-ordered algorithm: (1) if 'ciaddr' is non-zero, unicast to 'ciaddr':BOOTPC; (2) else if 'giaddr' is non-zero, unicast to 'giaddr':BOOTPS; (3) else if BROADCAST flag is set, broadcast to 255.255.255.255:BOOTPC; (4) else unicast to 'yiaddr'/'chaddr':BOOTPC. This is summarized in a decision table in Section 5.4.

ip

The 'chaddr' field MUST be preserved exactly as supplied by the BOOTP client, using the bit ordering native to the client's link-layer network as defined by ARP. A relay agent MUST NOT reverse the bit ordering when bridging between networks that use different orderings.

ip

The 'flags' field (2 octets) has its most significant bit defined as the BROADCAST (B) flag; the remaining 15 bits are designated MBZ (MUST BE ZERO) and reserved for future use. The BROADCAST flag signals to servers and relay agents that the client requires broadcast delivery of BOOTREPLY messages.

ip

The 'secs' field SHOULD contain the elapsed time in seconds since the client sent its first BOOTREQUEST; the first BOOTREQUEST SHOULD set 'secs' to zero. Clients SHOULD NOT use a constant value, as this undermines its utility as a policy control mechanism for servers and relay agents.

ip

BOOTP has no authentication mechanism, making it trivial for unauthorized servers to supply false IP addresses, spoofed default routers, or false DNS server addresses to clients. Unauthorized relay agents can present the same threats. Malicious clients can masquerade as legitimate clients or claim all dynamically-allocated resources, denying service to others.

security, ip

The BOOTP message format is a fixed-layout UDP payload of at minimum 300 octets, with fields: 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). The 'flags' field replaces the previously 'unused' two-octet field between 'secs' and 'ciaddr'.

ip