Bootstrap Protocol
RFC 951

Document Type RFC - Draft Standard (September 1985; Errata)
Last updated 2013-03-02
Stream Legacy
Formats plain text pdf htmlized with errata bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 951 (Draft Standard)
Telechat date
Responsible AD (None)
Send notices to (None)
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                                                 [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 field with the fully qualified
      path name of the appropriate boot file.  In determining this name,
      the server may consult his own database correlating the client's
      address and filename request, with a particular boot file
      customized for that client.  If the bootrequest filename is a null
      string, then the server returns a filename field indicating the
      'default' file to be loaded for that client.

      5. In the case of clients who do not know their IP addresses, the
      server must also have a database relating hardware address to IP
      address.  This client IP address is then placed into a field in
      the bootreply.

      6. Certain network topologies (such as Stanford's) may be such
      that a given physical cable does not have a TFTP server directly
      attached to it (e.g. all the gateways and hosts on a certain cable
      may be diskless).  With the cooperation of neighboring gateways,
      BOOTP can allow clients to boot off of servers several hops away,
      through these gateways.  See the section 'Booting Through
      Gateways' below.  This part of the protocol requires no special
      action on the part of the client.  Implementation is optional and
      requires a small amount of additional code in gateways and
      servers.

3. Packet Format

   All numbers shown are decimal, unless indicated otherwise.  The BOOTP
   packet is enclosed in a standard IP [8] UDP [7] datagram.  For
   simplicity it is assumed that the BOOTP packet is never fragmented.
   Any numeric fields shown are packed in 'standard network byte order',
   i.e. high order bits are sent first.

   In the IP header of a bootrequest, the client fills in its own IP
Show full document text