RFC 951 (rfc951) - Page 1 of 12

Bootstrap Protocol

Network Working Group                   Bill Croft (Stanford University)
Request for Comments: 951                John Gilmore (Sun Microsystems)
                                                          September 1985

                       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.

2. Overview

   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 [9], since it is
   intended that both phases reside in PROM on the client.  However
   BOOTP could also work with other protocols such as SFTP [3] or
   FTP [6].

   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