Network Working Group                                     Ross Finlayson
Request for Comments: 906                            Stanford University
                                                               June 1984

                      Bootstrap Loading using TFTP


Status of this Memo

   It is often convenient to be able to bootstrap a computer system from
   a communications network.  This RFC proposes the use of the IP TFTP
   protocol for bootstrap loading in this case.

   This RFC specifies a proposed protocol for the ARPA Internet
   community, and requests discussion and suggestions for improvements.

Introduction

   Many computer systems, such as diskless workstations, are
   bootstrapped by loading one or more code files across a network.
   Unfortunately, the protocol used to load these initial files has not
   been standardized - numerous methods have been employed by different
   computer manufacturers. This can make it difficult, for example, for
   an installation to support several different kinds of systems on a
   local-area network.  Each different booting mechanism that is used
   must be supported, for example by implementing a number of servers on
   one or more host machines.  This is in spite of the fact that these
   heterogeneous systems may be able to communicate freely (all using
   the same protocol) once they have been booted.

   We propose that TFTP (Trivial File Transfer Protocol) [6] be used as
   a standard protocol for bootstrap loading.  This protocol is
   well-suited for our purpose, being based on the standard Internet
   Protocol (IP) [4].  It is easily implemented, both in the machines to
   be booted, and in bootstrap servers elsewhere on the net.  (In
   addition, many popular operating systems already support TFTP
   servers.)  The fact that TFTP is a rather slow protocol is not a
   serious concern, due to the fact that it need be used only for the
   primary bootstrap.  A secondary bootstrap could use a faster
   protocol.

   This RFC describes how system to be booted (called the "booter"
   below) would use TFTP to load a desired code file.  It also describes
   an existing implementation (in ROM) for Ethernet.

   Note that we are specifying only the network protocols that would be
   used by the booting system.  We do not attempt to mandate the method
   by which a user actually boots a system (such as the format of a
   command typed at the console).  In addition, our proposal does not





 


RFC 906                                                        June 1984


   presuppose the use of any particular data-link level network
   architecture (although the example that we describe below uses
   Ethernet).

Network Protocols used by the Booting System

   To load a file, the booter sends a standard TFTP read request (RRQ)
   packet, containing the name of the file to be loaded.  The file name
   should not assume any operating system dependent naming conventions
   (file names containing only alphanumeric characters should suffice).
   Thereafter, the system receives TFTP DATA packets, and sends TFTP ACK
   and/or ERROR packets, in accordance with the TFTP specification [6].

   TFTP is implemented using the User Datagram Protocol (UDP) [5], which
   is in turn implemented using IP.  Thus, the booter must be able to
   receive IP datagrams containing up to 524 octets (excluding the IP
   header), since TFTP DATA packets can be up to 516 octets long, and
   UDP headers are 8 octets long.  The booting machine is not required
   to respond to incoming TFTP read or write requests.

   We allow for the use of two additional protocols.  These are ARP
   (Address Resolution Protocol) [3], and RARP (Reverse Address
   Resolution Protocol) [1]. The possible use of these protocols is
   described below.  The booter could also use other protocols (such as
   for name lookup), but they should be IP-based, and an internet
   standard.

   The IP datagram containing the initial TFTP RRQ (and all other IP
   datagrams sent by the booter) must of course contain both a source
   internet address and a destination internet address in its IP header.
   It is frequently the case, however, that the booter does not
   initially know its own internet address, but only a lower-level (e.g.
   Ethernet) address.  The Reverse Address Resolution Protocol
   (RARP) [1] may be used by the booter to find its internet address
   (prior to sending the TFTP RRQ).  RARP was motivated by Plummer's
   Address Resolution Protocol (ARP) [3].  Unlike ARP, which is used to
   find the 'hardware' address corresponding to a known higher-level
   protocol (e.g. internet) address, RARP is used to determine a
   higher-level protocol address, given a known hardware address.  RARP