rfc1532.txt

RFC 的详细文档！

Wimer                                                           [Page 6]

RFC 1532        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
   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 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
         with clients without the use of broadcasts.  In practice, the
         contents of the the same way the normal ARP protocol would



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


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

         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.





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


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



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


   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
   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
   SHOULD adopt the IP address specified in 'yiaddr' and begin using it
   as soon as possible.

      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



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


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







Wimer                                                          [Page 11]