rfc1532.txt

RFC 的详细文档！

   address.  If the BROADCAST flag is cleared (0), the reply SHOULD be
   sent as an IP unicast to the IP address specified by the 'yiaddr'
   field and the link-layer address specified in the 'chaddr' field.  If
   unicasting is not possible, the reply MAY be sent as a broadcast, in
   which case it SHOULD be sent to the link-layer broadcast address
   using the IP limited broadcast address 255.255.255.255 as the IP
   destination address.

      DISCUSSION:

         The addition of the BROADCAST flag to the protocol is a
         workaround to help promote interoperability with certain client
         implementations.

         Note that since the 'flags' field was previously defined in [1]
         simply as an "unused" field, it is possible that old client or
         server implementations may accidentally and unknowingly set the
         new BROADCAST flag.  It is actually expected that such
         implementations will be rare (most implementations seem to
         zero-out this field), but interactions with such
         implementations must nevertheless be considered.  If an old
         client or server does set the BROADCAST flag to 1 incorrectly,
         conforming relay agents will generate broadcast BOOTREPLY



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


         messages to the corresponding client.  The BOOTREPLY messages
         should still properly reach the client, at the cost of one
         (otherwise unnecessary) additional broadcast.  This, however,
         is no worse than a server or relay agent which always
         broadcasts its BOOTREPLY messages.

         Older client or server implementations which accidentally set
         the BROADCAST flag SHOULD be corrected to properly comply with
         this newer specification.

         All BOOTP fields MUST be preserved intact.  The relay agent
         MUST NOT modify any BOOTP field of the BOOTREPLY message when
         relaying it to the client.

         The reply MUST have its UDP destination port set to BOOTPC
         (68).

         If the BOOTREPLY has a UDP checksum (i.e., the UDP checksum is
         non-zero), the checksum must be recalculated before
         transmitting the reply.

5. BOOTP Server Behavior

   This section provides clarifications on the behavior of BOOTP
   servers.

5.1 Reception of BOOTREQUEST Messages

   All received UDP messages whose UDP destination port number is BOOTPS
   (67) are considered for processing by the BOOTP server.

   Hosts and routers are usually required to silently discard incoming
   datagrams containing illegal IP source addresses.  This is generally
   known as "Martian address filtering."  One of these illegal addresses
   is 0.0.0.0 (or actually anything on network 0).  However, hosts or
   routers which support a BOOTP server MUST accept for local delivery
   to the server BOOTREQUEST messages whose IP source address is
   0.0.0.0.  BOOTREQUEST messages from legal IP source addresses MUST
   also be accepted.

   A BOOTP server MUST silently discard any received UDP messages whose
   UDP destination port number is BOOTPC (68).

      DISCUSSION:

         There should be no need for a BOOTP server to process messages
         addressed to the BOOTPC port.  Careful reading of the original
         BOOTP specification [1] will show this.



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


         The consistency checks specified in Section 2.1 SHOULD be
         performed by the BOOTP server.  BOOTP messages not meeting
         these consistency checks MUST be silently discarded.

5.2 Use of the 'secs' field

   When the BOOTP server receives a BOOTREQUEST message, it MAY use the
   value of the 'secs' (seconds since client began booting) field of the
   request as a factor in deciding whether and/or how to reply to the
   request.

      DISCUSSION:

         To date, this feature of the BOOTP protocol has not necessarily
         been shown to be useful.  See Section 3.2 for a discussion.

5.3 Use of the 'ciaddr' field

   There have been various client interpretations of the 'ciaddr' field
   for which Section 3.3 should be consulted.  A BOOTP server SHOULD be
   prepared to deal with these varying interpretations.  In general, the
   client; the contents of the 'ciaddr', 'chaddr', 'htype', and 'hlen'
   fields, and probably other information (perhaps in the 'file' and
   respond to a given client.

   BOOTP servers SHOULD preserve the contents of the 'ciaddr' field in
   BOOTREPLY messages; the contents of 'ciaddr' in a BOOTREPLY message
   SHOULD exactly match the contents of 'ciaddr' in the corresponding
   BOOTREQUEST message.

      DISCUSSION:

   It has been suggested that a client may wish to use the contents of
   indeed intended for it.

5.4 Strategy for Delivery of BOOTREPLY Messages

   Once the BOOTP server has created an appropriate BOOTREPLY message,
   that BOOTREPLY message must be properly delivered to the client.

   The server SHOULD first check the 'ciaddr' field.  If the 'ciaddr'
   field is non-zero, the BOOTREPLY message SHOULD be sent as an IP
   unicast to the IP address identified in the 'ciaddr' field.  The UDP
   destination port MUST be set to BOOTPC (68).  However, the server
   MUST be aware of the problems identified in Section 3.3.  The server
   MAY choose to ignore the 'ciaddr' field and act as if the 'ciaddr'
   field contains 0.0.0.0 (and thus continue with the rest of the
   delivery algorithm below).



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


   The server SHOULD next check the 'giaddr' field.  If this field is
   non-zero, the server SHOULD send the BOOTREPLY as an IP unicast to
   the IP address identified in the 'giaddr' field.  The UDP destination
   port MUST be set to BOOTPS (67).  This action will deliver the
   BOOTREPLY message directly to the BOOTP relay agent closest to the
   client; the relay agent will then perform the final delivery to the
   client.  If the BOOTP server has prior knowledge that a particular
   client cannot receive unicast BOOTREPLY messages (e.g., the network
   manager has explicitly configured the server with such knowledge),
   the server MAY set the newly-defined BROADCAST flag to indicate that
   relay agents SHOULD broadcast the BOOTREPLY message to the client.
   Otherwise, the server MUST preserve the state of the BROADCAST flag
   so that the relay agent can correctly act upon it.

   If the 'giaddr' field is set to 0.0.0.0, then the client resides on
   one of the same networks as the BOOTP server.  The server SHOULD
   examine the newly-defined BROADCAST flag (see Sections 2.2, 3.1.1 and
   4.1.2 for more information).  If this flag is set to 1 or the server
   has prior knowledge that the client is unable to receive unicast
   BOOTREPLY messages, the reply SHOULD be sent as an IP broadcast using
   the IP limited broadcast address 255.255.255.255 as the IP
   destination address and the link-layer broadcast address as the
   link-layer destination address.  If the BROADCAST flag is cleared
   (0), the reply SHOULD be sent as an IP unicast to the IP address
   specified by the field.  If unicasting is not possible, the reply MAY
   be sent as a broadcast in which case it SHOULD be sent to the link-
   layer broadcast address using the IP limited broadcast address
   255.255.255.255 as the IP destination address.  In any case, the UDP
   destination port MUST be set to BOOTPC (68).

      DISCUSSION:

         The addition of the BROADCAST flag to the protocol is a
         workaround to help promote interoperability with certain client
         implementations.

         The following table summarizes server delivery decisions for
         BOOTREPLY messages based upon information in BOOTREQUEST
         messages:












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


      BOOTREQUEST fields     BOOTREPLY values for UDP, IP, link-layer
   +-----------------------+-----------------------------------------+
   | 'ciaddr'  'giaddr'  B | UDP dest     IP destination   link dest |
   +-----------------------+-----------------------------------------+
   | non-zero     X      X | BOOTPC (68)  'ciaddr'         normal    |
   | 0.0.0.0   non-zero  X | BOOTPS (67)  'giaddr'         normal    |
   | 0.0.0.0   0.0.0.0   0 | BOOTPC (68)  'yiaddr'         'chaddr'  |
   | 0.0.0.0   0.0.0.0   1 | BOOTPC (68)  255.255.255.255  broadcast |
   +-----------------------+-----------------------------------------+

        B = BROADCAST flag

        X = Don't care

   normal = determine from the given IP destination using normal
            IP routing mechanisms and/or ARP as for any other
            normal datagram

Acknowledgements

   The author would like to thank Gary Malkin for his contribution of
   the "BOOTP over IEEE 802.5 Token Ring Networks" section, and Steve
   Deering for his observations on the problems associated with the
   'giaddr' field.

   Ralph Droms and the many members of the IETF Dynamic Host
   Configuration and Router Requirements working groups provided ideas
   for this memo as well as encouragement to write it.

   Philip Almquist and David Piscitello offered many helpful suggestions
   for improving the clarity, accuracy, and organization of this memo.
   These contributions are graciously acknowledged.

References

   [1] Croft, B., and J. Gilmore, "Bootstrap Protocol (BOOTP)", RFC 951,
       Stanford University and Sun Microsystems, September 1985.

   [2] Reynolds, J., "BOOTP Vendor Information Extensions", RFC 1497,
       USC/Information Sciences Institute, August 1993.  This RFC is
       occasionally reissued with a new number.  Please be sure to
       consult the latest version.

   [3] Droms, R., "Dynamic Host Configuration Protocol", RFC 1531,
       Bucknell University, October 1993.

   [4] Plummer, D., "An Ethernet Address Resolution Protocol", STD 37,
       RFC 826, MIT, November 1982.



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


   [5] Deering, S., "ICMP Router Discovery Messages", RFC 1256, Xerox
       PARC, September 1991.

   [6] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340,
       USC/Information Sciences Institute, July, 1992.  This RFC is
       periodically reissued with a new number.  Please be sure to
       consult the latest version.

Security Considerations

   There are many factors which make BOOTP in its current form quite
   insecure.  BOOTP is built directly upon UDP and IP which are as yet
   inherently insecure themselves.  Furthermore, BOOTP is generally
   intended to make maintenance of remote and/or diskless hosts easier.
   While perhaps not impossible, configuring such hosts with passwords or
   keys may be difficult and inconvenient.  This makes it difficult to
   provide any form of reasonable authentication between servers and
   clients.

   Unauthorized BOOTP servers may easily be set up.  Such servers can
   then send false and potentially disruptive information to clients such
   as incorrect or duplicate IP addresses, incorrect routing information
   (including spoof routers, etc.), incorrect domain nameserver addresses
   (such as spoof nameservers), and so on.  Clearly, once this "seed"
   mis-information is planted, an attacker can further compromise the
   affected systems.

   Unauthorized BOOTP relay agents may present some of the same problems
   as unauthorized BOOTP servers.

   Malicious BOOTP clients could masquerade as legitimate clients and
   retrieve information intended for those legitimate clients.  Where
   dynamic allocation of resources is used, a malicious client could
   claim all resources for itself, thereby denying resources to
   legitimate clients.

Author's Address

   Walt Wimer
   Network Development
   Carnegie Mellon University
   5000 Forbes Avenue
   Pittsburgh, PA  15213-3890

   Phone: [phone]
   EMail:  [e-mail]





Wimer                                                          [Page 22]