Bootstrap Protocol (RFC0951)
Original Publication Date: 1985-Sep-01
Included in the Prior Art Database: 2001-Jul-12
Internet Society Requests For Comment (RFCs)
W.J. Croft: AUTHOR [+2]
1. Status of this Memo
Network Working Group Bill Croft (Stanford University) Request for Comments: 951 John Gilmore (Sun Microsystems)
BOOTSTRAP PROTOCOL (BOOTP)
1. Status of this Memo
This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
This RFC describes an IP/UDP bootstrap protocol (BOOTP) which allows a diskless client machine to discover its own IP address, the address of a server host, and the name of a file to be loaded into memory and executed. The bootstrap operation can be thought of as consisting of TWO PHASES. This RFC describes the first phase, which could be labeled 'address determination and bootfile selection'. After this address and filename information is obtained, control passes to the second phase of the bootstrap where a file transfer occurs. The file transfer will typically use the TFTP protocol , since it is intended that both phases reside in PROM on the client. However BOOTP could also work with other protocols such as SFTP  or FTP .
We suggest that the client's PROM software provide a way to do a complete bootstrap without 'user' interaction. This is the type of boot that would occur during an unattended power-up. A mechanism should be provided for the user to manually supply the necessary address and filename information to bypass the BOOTP protocol and enter the file transfer phase directly. If non-volatile storage is available, we suggest keeping default settings there and bypassing the BOOTP protocol unless these settings cause the file transfer phase to fail. If the cached information fails, the bootstrap should fall back to phase 1 and use BOOTP.
Here is a brief outline of the protocol:
1. A single packet exchange is performed. Timeouts are used to retransmit until a reply is received. The same packet field layout is used in both directions. Fixed length fields of maximum reasonable length are used to simplify structure definition and parsing.
2. An 'opcode' field exists with two values. The client broadcasts a 'bootrequest' packet. The server then answers with a 'bootreply' packet. The bootrequest contains the client's hardware address and its IP address, if known.
Croft Gilmore [Page 1]
RFC 951 September 1985 Bootstrap Protocol
3. The request can optionally contain the name of the server the client wishes to respond. This is so the client can force the boot to occur from a specific host (e.g. if multiple versions of the same bootfile exist or if the server is in a far distant net/domain). The client does not have to deal with name domain services; instead this function is pushed off to the BOOTP server.
4. The request can optionally contain the 'generic' filename to be booted. For example 'unix' or 'ethertip'. When the server sends the bootreply, it replaces this ...