rfc1542.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

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



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


   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.

         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
   'ciaddr' field SHOULD NOT be trusted as a sole key in identifying a
   client; the contents of the 'ciaddr', 'chaddr', 'htype', and 'hlen'
   fields, and probably other information (perhaps in the 'file' and
   'vend' fields) SHOULD all be considered together in deciding how to
   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 'ciaddr' to further verify that a particular
         BOOTREPLY message was indeed intended for it.





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


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

   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 '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.  In any case, the UDP
   destination port MUST be set to BOOTPC (68).







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


      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:

      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.









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


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 1541,
       Bucknell University, October 1993.

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

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




























Wimer                                                          [Page 22]

RFC 1542        Clarifications and Extensions for BOOTP     October 1993


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