Network Working Group                                           W. Wimer
Request for Comments: 1542                    Carnegie Mellon University
Updates: 951                                                October 1993
Obsoletes: 1532
Category: Standards Track


        Clarifications and Extensions for the Bootstrap Protocol

Status of this Memo

   This RFC specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" for the standardization state and status
   of this protocol.  Distribution of this memo is unlimited.

Abstract

   Some aspects of the BOOTP protocol were rather loosely defined in its
   original specification.  In particular, only a general description
   was provided for the behavior of "BOOTP relay agents" (originally
   called BOOTP forwarding agents").  The client behavior description
   also suffered in certain ways.  This memo attempts to clarify and
   strengthen the specification in these areas.  Due to some errors
   introduced into RFC 1532 in the editorial process, this memo is
   reissued as RFC 1542.

   In addition, new issues have arisen since the original specification
   was written.  This memo also attempts to address some of these.

Table of Contents

   1. Introduction.................................................  2
   1.1 Requirements................................................  3
   1.2 Terminology.................................................  3
   1.3 Data Transmission Order.....................................  4
   2. General Issues...............................................  5
   2.1 General BOOTP Processing....................................  5
   2.2 Definition of the 'flags' Field.............................  5
   2.3 Bit Ordering of Hardware Addresses..........................  7
   2.4 BOOTP Over IEEE 802.5 Token Ring Networks...................  8
   3. BOOTP Client Behavior........................................  9
   3.1 Client use of the 'flags' field.............................  9
   3.1.1 The BROADCAST flag........................................  9
   3.1.2 The remainder of the 'flags' field........................  9
   3.2 Definition of the 'secs' field.............................. 10
   3.3 Use of the 'ciaddr' and 'yiaddr' fields..................... 10



Wimer                                                           [Page 1]


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                                                           [Page 2]


RFC 1542        Clarifications and Extensions for BOOTP     October 1993


1.1 Requirements

   In this memo, the words that are used to define the significance of
   particular requirements are capitalized.  These words are:

      o "MUST"

        This word or the adjective "REQUIRED" means that the item
        is an absolute requirement of the specification.

      o "MUST NOT"

        This phrase means that the item is an absolute prohibition
        of the specification.

      o "SHOULD"

        This word or the adjective "RECOMMENDED" means that there
        may exist valid reasons in particular circumstances to
        ignore this item, but the full implications should be
        understood and the case carefully weighed before choosing a
        different course.

      o "SHOULD NOT"

        This phrase means that there may exist valid reasons in
        particular circumstances when the listed behavior is
        acceptable or even useful, but the full implications should
        be understood and the case carefully weighed before
        implementing any behavior described with this label.

      o "MAY"

        This word or the adjective "OPTIONAL" means that this item
        is truly optional.  One vendor may choose to include the
        item because a particular marketplace requires it or
        because it enhances the product, for example; another
        vendor may omit the same item.

1.2 Terminology

   This memo uses the following terms:

      BOOTREQUEST

         A BOOTREQUEST message is a BOOTP message sent from a BOOTP
         client to a BOOTP server, requesting configuration information.




Wimer                                                           [Page 3]


RFC 1542        Clarifications and Extensions for BOOTP     October 1993


      BOOTREPLY

         A BOOTREPLY message is a BOOTP message sent from a BOOTP server
         to a BOOTP client, providing configuration information.

      Silently discard

         This memo specifies several cases where a BOOTP entity is to
         "silently discard" a received BOOTP message.  This means that
         the entity is to discard the message without further
         processing, and that the entity will not send any ICMP error
         message as a result.  However, for diagnosis of problems, the
         entity SHOULD provide the capability of logging the error,
         including the contents of the silently-discarded message, and
         SHOULD record the event in a statistics counter.

1.3 Data Transmission Order

   The order of transmission of the header and data described in this
   document is resolved to the octet level.  Whenever a diagram shows a
   group of octets, the order of transmission of those octets is the
   normal order in which they are read in English.  For example, in the
   following diagram, the octets are transmitted in the order they are
   numbered.

                     0                   1
                     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                     |       1       |       2       |
                     +-------------------------------+
                     |       3       |       4       |
                     +-------------------------------+
                     |       5       |       6       |
                     +-------------------------------+

   Whenever an octet represents a numeric quantity, the leftmost bit in
   the diagram is the high order or most significant bit.  That is, the
   bit labeled 0 is the most significant bit.  For example, the
   following diagram represents the value 170 (decimal).

                               0 1 2 3 4 5 6 7
                              +-+-+-+-+-+-+-+-+
                              |1 0 1 0 1 0 1 0|
                              +---------------+

   Similarly, whenever a multi-octet field represents a numeric quantity
   the leftmost bit of the whole field is the most significant bit.
   When a multi-octet quantity is transmitted the most significant octet



Wimer                                                           [Page 4]


RFC 1542        Clarifications and Extensions for BOOTP     October 1993


   is transmitted first.

2. General Issues

   This section covers issues of general relevance to all BOOTP entities
   (clients, servers, and relay agents).

2.1 General BOOTP Processing

   The following consistency checks SHOULD be performed on BOOTP
   messages:

      o The IP Total Length and UDP Length must be large enough to
        contain the minimal BOOTP header of 300 octets (in the UDP
        data field) specified in [1].

   NOTE: Future extensions to the BOOTP protocol may increase the size
   of BOOTP messages.  Therefore, BOOTP messages which, according to the
   IP Total Length and UDP Length fields, are larger than the minimum
   size specified by [1] MUST also be accepted.

      o The 'op' (opcode) field of the message must contain either the
        code for a BOOTREQUEST (1) or the code for a BOOTREPLY (2).

   BOOTP messages not meeting these consistency checks MUST be silently
   discarded.

2.2 Definition of the 'flags' Field

   The standard BOOTP message format defined in [1] includes a two-octet
   field located between the 'secs' field and the 'ciaddr' field.  This
   field is merely designated as "unused" and its contents left
   unspecified, although Section 7.1 of [1] does offer the following
   suggestion:

      "Before setting up the packet for the first time, it is a good
      idea to clear the entire packet buffer to all zeros; this will
      place all fields in their default state."

      This memo hereby designates this two-octet field as the 'flags'
      field.

      This memo hereby defines the most significant bit of the 'flags'
      field as the BROADCAST (B) flag.  The semantics of this flag are
      discussed in Sections 3.1.1 and 4.1.2 of this memo.

      The remaining bits of the 'flags' field are reserved for future
      use.  They MUST be set to zero by clients and ignored by servers



Wimer                                                           [Page 5]


RFC 1542        Clarifications and Extensions for BOOTP     October 1993


      and relay agents.

      The 'flags' field, then, appears as follows:

                     0                   1
                     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                     |B|             MBZ             |
                     +-+-----------------------------+

   where:

      B    BROADCAST flag (discussed in Sections 3.1.1 and 4.1.2)

      MBZ  MUST BE ZERO (reserved for future use)

   The format of a BOOTP message is shown below.  The numbers in
   parentheses indicate the size of each field in octets.

































Wimer                                                           [Page 6]


RFC 1542        Clarifications and Extensions for BOOTP     October 1993


   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     op (1)    |   htype (1)   |   hlen (1)    |   hops (1)    |
   +---------------+---------------+---------------+---------------+
   |                            xid (4)                            |
   +-------------------------------+-------------------------------+
   |           secs (2)            |           flags (2)           |
   +-------------------------------+-------------------------------+
   |                           ciaddr (4)                          |
   +---------------------------------------------------------------+
   |                           yiaddr (4)                          |
   +---------------------------------------------------------------+
   |                           siaddr (4)                          |
   +---------------------------------------------------------------+
   |                           giaddr (4)                          |
   +---------------------------------------------------------------+
   |                                                               |
   |                           chaddr (16)                         |
   |                                                               |
   |                                                               |
   +---------------------------------------------------------------+
   |                                                               |
   |                           sname  (64)                         |
   +---------------------------------------------------------------+
   |                                                               |
   |                           file   (128)                        |
   +---------------------------------------------------------------+
   |                                                               |
   |                           vend   (64)                         |
   +---------------------------------------------------------------+

2.3 Bit Ordering of Hardware Addresses

   The bit ordering used for link-level hardware addresses in the
   'chaddr' field SHOULD be the same as the ordering used for the ARP
   protocol [4] on the client's link-level network (assuming ARP is
   defined for that network).

   The 'chaddr' field MUST be preserved as it was specified by the BOOTP
   client.  A relay agent MUST NOT reverse the bit ordering of the
   'chaddr' field even if it happens to be relaying a BOOTREQUEST
   between two networks which use different bit orderings.

      DISCUSSION:

         One of the primary reasons the 'chaddr' field exists is to
         enable BOOTP servers and relay agents to communicate directly



Wimer                                                           [Page 7]


RFC 1542        Clarifications and Extensions for BOOTP     October 1993


         with clients without the use of broadcasts.  In practice, the
         contents of the 'chaddr' field is often used to create an ARP-
         cache entry in exactly the same way the normal ARP protocol
         would have.  Clearly, interoperability can only be achieved if
         a consistent interpretation of the 'chaddr' field is used.

         As a practical example, this means that the bit ordering used
         for the 'chaddr' field by a BOOTP client on an IEEE 802.5 Token
         Ring network is the opposite of the bit ordering used by a
         BOOTP client on a DIX ethernet network.

2.4 BOOTP Over IEEE 802.5 Token Ring Networks

   Special consideration of the client/server and client/relay agent
   interactions must be given to IEEE 802.5 networks because of non-
   transparent bridging.

   The client SHOULD send its broadcast BOOTREQUEST with an All Routes
   Explorer RIF.  This will enable servers/relay agents to cache the
   return route if they choose to do so.  For those server/relay agents
   which cannot cache the return route (because they are stateless, for
   example), the BOOTREPLY message SHOULD be sent to the client's
   hardware address, as taken from the BOOTP message, with a Spanning
   Tree Rooted RIF.  The actual bridge route will be recorded by the
   client and server/relay agent by normal ARP processing code.

      DISCUSSION:

         In the simplest case, an unbridged, single ring network, the
         broadcast behavior of the BOOTP protocol is identical to that
         of Ethernet networks.  However, a BOOTP client cannot know, a
         priori, that an 802.5 network is not bridged.  In fact, the
         likelihood is that the server, or relay agent, will not know
         either.

         Of the four possible scenerios, only two are interesting: where
         the assumption is that the 802.5 network is not bridged and it
         is, and the assumption that the network is bridged and it is
         not.  In the former case, the Routing Information Field (RIF)
         will not be used; therefore, if the server/relay agent are on
         another segment of the ring, the client cannot reach it.  In
         the latter case, the RIF field will be used, resulting in a few
         extraneous bytes on the ring.  It is obvious that an almost
         immeasurable inefficiency is to be preferred over a complete
         failure to communicate.






Wimer                                                           [Page 8]


RFC 1542        Clarifications and Extensions for BOOTP     October 1993


         Given that the assumption is that RIF fields will be needed, it
         is necesary to determine the optimum method for the client to
         reach the server/relay agent, and the optimum method for the
         response to be returned.

3. BOOTP Client Behavior

   This section clarifies various issues regarding BOOTP client
   behavior.

3.1 Client use of the 'flags' field

3.1.1 The BROADCAST flag

   Normally, BOOTP servers and relay agents attempt to deliver BOOTREPLY
   messages directly to a client using unicast delivery.  The IP
   destination address (in the IP header) is set to the BOOTP 'yiaddr'
   address and the link-layer destination address is set to the BOOTP
   'chaddr' address.  Unfortunately, some client implementations are
   unable to receive such unicast IP datagrams until they know their own
   IP address (thus we have a "chicken and egg" issue).  Often, however,
   they can receive broadcast IP datagrams (those with a valid IP
   broadcast address as the IP destination and the link-layer broadcast
   address as the link-layer destination).

   If a client falls into this category, it SHOULD set (to 1) the
   newly-defined BROADCAST flag in the 'flags' field of BOOTREPLY
   messages it generates.  This will provide a hint to BOOTP servers and
   relay agents that they should attempt to broadcast their BOOTREPLY
   messages to the client.

   If a client does not have this limitation (i.e., it is perfectly able
   to receive unicast BOOTREPLY messages), it SHOULD NOT set the
   BROADCAST flag (i.e., it SHOULD clear the BROADCAST flag to 0).

      DISCUSSION:

         This addition to the protocol is a workaround for old host
         implementations.  Such implementations SHOULD be modified so
         that they may receive unicast BOOTREPLY messages, thus making
         use of this workaround unnecessary.  In general, the use of
         this mechanism is discouraged.

3.1.2 The remainder of the 'flags' field

   The remaining bits of the 'flags' field are reserved for future use.
   A client MUST set these bits to zero in all BOOTREQUEST messages it
   generates.  A client MUST ignore these bits in all BOOTREPLY messages



Wimer                                                           [Page 9]


RFC 1542        Clarifications and Extensions for BOOTP     October 1993


   it receives.

3.2 Definition of the 'secs' field

   The 'secs' field of a BOOTREQUEST message SHOULD represent the
   elapsed time, in seconds, since the client sent its first BOOTREQUEST
   message.  Note that this implies that the 'secs' field of the first
   BOOTREQUEST message SHOULD be set to zero.

   Clients SHOULD NOT set the 'secs' field to a value which is constant
   for all BOOTREQUEST messages.

      DISCUSSION:

         The original definition of the 'secs' field was vague.  It was
         not clear whether it represented the time since the first
         BOOTREQUEST message was sent or some other time period such as
         the time since the client machine was powered-up.  This has
         limited its usefulness as a policy control mechanism for BOOTP
         servers and relay agents.  Furthermore, certain client
         implementations have been known to simply set this field to a
         constant value or use incorrect byte-ordering.  Incorrect
         byte-ordering usually makes it appear as if a client has been
         waiting much longer than it really has, so a relay agent will
         relay the BOOTREQUEST sooner than desired (usually
         immediately).  These implementation errors have further
         undermined the usefulness of the 'secs' field.  These incorrect
         implementations SHOULD be corrected.

3.3 Use of the 'ciaddr' and 'yiaddr' fields

   If a BOOTP client does not know what IP address it should be using,
   the client SHOULD set the 'ciaddr' field to 0.0.0.0.  If the client
   has the ability to remember the last IP address it was assigned, or
   it has been preconfigured with an IP address via some alternate
   mechanism, the client MAY fill the 'ciaddr' field with that IP
   address.  If the client does place a non-zero IP address in the
   'ciaddr' field, the client MUST be prepared to accept incoming
   unicast datagrams addressed to that IP address and also answer ARP
   requests for that IP address (if ARP is used on that network).

   The BOOTP server is free to assign a different IP address (in the
   'yiaddr' field) than the client expressed in 'ciaddr'.  The client
   SHOULD adopt the IP address specified in 'yiaddr' and begin using it
   as soon as possible.






Wimer                                                          [Page 10]


RFC 1542        Clarifications and Extensions for BOOTP     October 1993


      DISCUSSION:

         There are various interpretations about the purpose of the
         'ciaddr' field and, unfortunately, no agreement on a single
         correct interpretation.  One interpretation is that if a client
         is willing to accept whatever IP address the BOOTP server
         assigns to it, the client should always place 0.0.0.0 in the
         'ciaddr' field, regardless of whether it knows its previously-
         assigned address.  Conversely, if the client wishes to assert
         that it must have a particular IP address (e.g., the IP address
         was hand-configured by the host administrator and BOOTP is only
         being used to obtain a boot file and/or information from the
         'vend' field), the client will then fill the 'ciaddr' field
         with the desired IP address and ignore the IP address assigned
         by the BOOTP server as indicated in the 'yiaddr' field.  An
         alternate interpretation holds that the client always fills the
         'ciaddr' field with its most recently-assigned IP address (if
         known) even if that address may be incorrect.  Such a client
         will still accept and use the address assigned by the BOOTP
         server as indicated in the 'yiaddr' field.  The motivation for
         this interpretation is to aid the server in identifying the
         client and/or in delivering the BOOTREPLY to the client.  Yet a
         third (mis)interpretation allows the client to use 'ciaddr' to
         express the client's desired IP address, even if the client has
         never used that address before or is not currently using that
         address.

         The last interpretation is incorrect as it may prevent the
         BOOTREPLY from reaching the client.  The server will usually
         unicast the reply to the address given in 'ciaddr' but the
         client may not be listening on that address yet, or the client
         may be connected to an incorrect subnet such that normal IP
         routing (correctly) routes the reply to a different subnet.

         The second interpretation also suffers from the "incorrect
         subnet" problem.

         The first interpretation seems to be the safest and most likely
         to promote interoperability.

3.4 Interpretation of the 'giaddr' field

   The 'giaddr' field is rather poorly named.  It exists to facilitate
   the transfer of BOOTREQUEST messages from a client, through BOOTP
   relay agents, to servers on different networks than the client.
   Similarly, it facilitates the delivery of BOOTREPLY messages from the
   servers, through BOOTP relay agents, back to the client.  In no case
   does it represent a general IP router to be used by the client.  A



Wimer                                                          [Page 11]


RFC 1542        Clarifications and Extensions for BOOTP     October 1993


   BOOTP client MUST set the 'giaddr' field to zero (0.0.0.0) in all
   BOOTREQUEST messages it generates.

   A BOOTP client MUST NOT interpret the 'giaddr' field of a BOOTREPLY
   message to be the IP address of an IP router.  A BOOTP client SHOULD
   completely ignore the contents of the 'giaddr' field in BOOTREPLY
   messages.

      DISCUSSION:

         The semantics of the 'giaddr' field were poorly defined.
         Section 7.5 of [1] states:

           "If 'giaddr' (gateway address) is nonzero, then the packets
           should be forwarded there first, in order to get to the
           server."

   In that sentence, "get to" refers to communication from the client to
   the server subsequent to the BOOTP exchange, such as a TFTP session.
   Unfortunately, the 'giaddr' field may contain the address of a BOOTP
   relay agent that is not itself an IP router (according to [1],
   Section 8, fifth paragraph), in which case, it will be useless as a
   first-hop for TFTP packets sent to the server (since, by definition,
   non-routers don't forward datagrams at the IP layer).

   Although now prohibited by Section 4.1.1 of this memo, the 'giaddr'
   field might contain a broadcast address according to Section 8, sixth
   paragraph of [1].  Not only would such an address be useless as a
   router address, it might also cause the client to ARP for the
   broadcast address (since, if the client didn't receive a subnet mask
   in the BOOTREPLY message, it would be unable to recognize a subnet
   broadcast address).  This is clearly undesirable.

   To reach a non-local server, clients can obtain a first-hop router
   address from the "Gateway" subfield of the "Vendor Information
   Extensions" [2] (if present), or via the ICMP router discovery
   protocol [5] or other similar mechanism.

3.5 Vendor information "magic cookie"

   It is RECOMMENDED that a BOOTP client always fill the first four
   octets of the 'vend' (vendor information) field of a BOOTREQUEST with
   a four-octet identifier called a "magic cookie."  A BOOTP client
   SHOULD do this even if it has no special information to communicate
   to the BOOTP server using the 'vend' field.  This aids the BOOTP
   server in determining what vendor information format it should use in
   its BOOTREPLY messages.




Wimer                                                          [Page 12]


RFC 1542        Clarifications and Extensions for BOOTP     October 1993


   If a special vendor-specific magic cookie is not being used, a BOOTP
   client SHOULD use the dotted decimal value 99.130.83.99 as specified
   in [2].  In this case, if the client has no information to
   communicate to the server, the octet immediately following the magic
   cookie SHOULD be set to the "End" tag (255) and the remaining octets
   of the 'vend' field SHOULD be set to zero.

      DISCUSSION:

         Sometimes different operating systems or networking packages
         are run on the same machine at different times (or even at the
         same time!).  Since the hardware address placed in the 'chaddr'
         field will likely be the same, BOOTREQUESTs from completely
         different BOOTP clients on the same machine will likely be
         difficult for a BOOTP server to differentiate.  If the client
         includes a magic cookie in its BOOTREQUESTs, the server will at
         least know what format the client expects and can understand in
         corresponding BOOTREPLY messages.

4. BOOTP Relay Agents

         In many cases, BOOTP clients and their associated BOOTP
         server(s) do not reside on the same IP network or subnet.  In
         such cases, some kind of third-party agent is required to
         transfer BOOTP messages between clients and servers.  Such an
         agent was originally referred to as a "BOOTP forwarding agent."
         However, in order to avoid confusion with the IP forwarding
         function of an IP router, the name "BOOTP relay agent" is
         hereby adopted instead.

      DISCUSSION:

         A BOOTP relay agent performs a task which is distinct from an
         IP router's normal IP forwarding function.  While a router
         normally switches IP datagrams between networks more-or-less
         transparently, a BOOTP relay agent may more properly be thought
         to receive BOOTP messages as a final destination and then
         generate new BOOTP messages as a result.  It is incorrect for a
         relay a