rfc1532.txt

RFC 的详细文档！

Network Working Group                                           W. Wimer
Request for Comments: 1532                    Carnegie Mellon University
Updates: 951                                                October 1993
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.

   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................................................  2
   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..............................  9
   3.3 Use of the 'ciaddr' and 'yiaddr' fields..................... 10
   3.4 Interpretation of the 'giaddr' field........................ 11
   3.5 Vendor information "magic cookie"........................... 12
   4. BOOTP Relay Agents........................................... 13



Wimer                                                           [Page 1]

RFC 1532        Clarifications and Extensions for BOOTP     October 1993


   4.1 General BOOTP Processing for Relay Agents................... 13
   4.1.1 BOOTREQUEST Messages...................................... 14
   4.1.2 BOOTREPLY Messages........................................ 16
   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................. 19
   Acknowledgements................................................ 21
   References...................................................... 21
   Security Considerations......................................... 22
   Author's Address................................................ 22

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].

1.1 Requirements

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




Wimer                                                           [Page 2]

RFC 1532        Clarifications and Extensions for BOOTP     October 1993


      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.

      BOOTREPLY

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




Wimer                                                           [Page 3]

RFC 1532        Clarifications and Extensions for BOOTP     October 1993


      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
   is transmitted first.







Wimer                                                           [Page 4]

RFC 1532        Clarifications and Extensions for BOOTP     October 1993


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
      and relay agents.




Wimer                                                           [Page 5]

RFC 1532        Clarifications and Extensions for BOOTP     October 1993


      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.