RFC 1542 (rfc1542) - Page 2 of 23
Clarifications and Extensions for the Bootstrap Protocol
Alternative Format: Original Text Document
RFC 1542 Clarifications and Extensions for BOOTP October 1993
3.4 Interpretation of the 'giaddr' field........................ 11
3.5 Vendor information "magic cookie"........................... 12
4. BOOTP Relay Agents........................................... 13
4.1 General BOOTP Processing for Relay Agents................... 14
4.1.1 BOOTREQUEST Messages...................................... 14
4.1.2 BOOTREPLY Messages........................................ 17
5. BOOTP Server Behavior........................................ 18
5.1 Reception of BOOTREQUEST Messages........................... 18
5.2 Use of the 'secs' field..................................... 19
5.3 Use of the 'ciaddr' field................................... 19
5.4 Strategy for Delivery of BOOTREPLY Messages................. 20
Acknowledgements................................................ 21
References...................................................... 22
Security Considerations......................................... 23
Author's Address................................................ 23
1. Introduction
The Bootstrap Protocol (BOOTP) is a UDP/IP-based protocol which
allows a booting host to configure itself dynamically and without
user supervision. BOOTP provides a means to notify a host of its
assigned IP address, the IP address of a boot server host, and the
name of a file to be loaded into memory and executed [1]. Other
configuration information such as the local subnet mask, the local
time offset, the addresses of default routers, and the addresses of
various Internet servers can also be communicated to a host using
BOOTP [2].
Unfortunately, the original BOOTP specification [1] left some issues
of the protocol open to question. The exact behavior of BOOTP relay
agents formerly called "BOOTP forwarding agents") was not clearly
specified. Some parts of the overall protocol specification actually
conflict, while other parts have been subject to misinterpretation,
indicating that clarification is needed. This memo addresses these
problems.
Since the introduction of BOOTP, the IEEE 802.5 Token Ring Network
has been developed which presents a unique problem for BOOTP's
particular message-transfer paradigm. This memo also suggests a
solution for this problem.
NOTE: Unless otherwise specified in this document or a later
document, the information and requirements specified througout this
document also apply to extensions to BOOTP such as the Dynamic Host
Configuration Protocol (DHCP) [3].
Wimer