rfc1542.txt

RFC 的详细文档！

   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 agent implementation to simply forward a BOOTP message
         "straight through like a regular packet."

         This relay-agent functionality is most conveniently located in
         the routers which interconnect the clients and servers, but may
         alternatively be located in a host which is directly connected
         to the client subnet.

         Any Internet host or router which provides BOOTP relay-agent
         capability MUST conform to the specifications in this memo.



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


4.1 General BOOTP Processing for Relay Agents

   All locally delivered UDP messages whose UDP destination port number
   is BOOTPS (67) are considered for special processing by the host or
   router's logical BOOTP relay agent.

   In the case of a host, locally delivered datagrams are simply all
   datagrams normally received by that host, i.e., broadcast and
   multicast datagrams as well as unicast datagrams addressed to IP
   addresses of that host.

   In the case of a router, locally delivered datagrams are broadcast
   and multicast datagrams as well as unicast datagrams addressed to IP
   addresses of that router.  These are datagrams for which the router
   should be considered an end destination as opposed to an intermediate
   switching node.  Thus a unicast datagram with an IP destination not
   matching any of the router's IP addresses is not considered for
   processing by the router's logical BOOTP relay agent.

   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 relay agent MUST accept for local
   delivery to the relay agent BOOTREQUEST messages whose IP source
   address is 0.0.0.0.  BOOTREQUEST messages from legal IP source
   addresses MUST also be accepted.

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

      DISCUSSION:

         There should be no need for a relay agent to process messages
         addressed to the BOOTPC port.  Careful reading of the original
         BOOTP specification [1] will show this.  Nevertheless, some
         relay agent implementations incorrectly relay such messages.

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

4.1.1 BOOTREQUEST Messages

   Some configuration mechanism MUST exist to enable or disable the
   relaying of BOOTREQUEST messages.  Relaying MUST be disabled by
   default.




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


   When the BOOTP relay agent 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 to relay the request.  If
   such a policy mechanism is implemented, its threshold SHOULD be
   configurable.

      DISCUSSION:

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

   The relay agent MUST silently discard BOOTREQUEST messages whose
   'hops' field exceeds the value 16.  A configuration option SHOULD be
   provided to set this threshold to a smaller value if desired by the
   network manager.  The default setting for a configurable threshold
   SHOULD be 4.

   If the relay agent does decide to relay the request, it MUST examine
   the 'giaddr' ("gateway" IP address) field.  If this field is zero,
   the relay agent MUST fill this field with the IP address of the
   interface on which the request was received.  If the interface has
   more than one IP address logically associated with it, the relay
   agent SHOULD choose one IP address associated with that interface and
   use it consistently for all BOOTP messages it relays.  If the
   'giaddr' field contains some non-zero value, the 'giaddr' field MUST
   NOT be modified.  The relay agent MUST NOT, under any circumstances,
   fill the 'giaddr' field with a broadcast address as is suggested in
   [1] (Section 8, sixth paragraph).

   The value of the 'hops' field MUST be incremented.

   All other BOOTP fields MUST be preserved intact.

   At this point, the request is relayed to its new destination (or
   destinations).  This destination MUST be configurable.  Further, this
   destination configuration SHOULD be independent of the destination
   configuration for any other so-called "broadcast forwarders" (e.g.,
   for the UDP-based TFTP, DNS, Time, etc.  protocols).

      DISCUSSION:

         The network manager may wish the relaying destination to be an
         IP unicast, multicast, broadcast, or some combination.  A
         configurable list of destination IP addresses provides good
         flexibility.  More flexible configuration schemes are
         encouraged.  For example, it may be desirable to send to the
         limited broadcast address (255.255.255.255) on specific
         physical interfaces.  However, if the BOOTREQUEST message was



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


         received as a broadcast, the relay agent MUST NOT rebroadcast
         the BOOTREQUEST on the physical interface from whence it came.

         A relay agent MUST use the same destination (or set of
         destinations) for all BOOTREQUEST messages it relays from a
         given client.

      DISCUSSION:

         At least one known relay agent implementation uses a round-
         robin scheme to provide load balancing across multiple BOOTP
         servers.  Each time it receives a new BOOTREQUEST message, it
         relays the message to the next BOOTP server in a list of
         servers.  Thus, with this relay agent, multiple consecutive
         BOOTREQUEST messages from a given client will be delivered to
         different servers.

         Unfortunately, this well-intentioned scheme reacts badly with
         DHCP [3] and perhaps other variations of the BOOTP protocol
         which depend on multiple exchanges of BOOTREQUEST and BOOTREPLY
         messages between clients and servers.  Therefore, all
         BOOTREQUEST messages from a given client MUST be relayed to the
         same destination (or set of destinations).

         One way to meet this requirement while providing some load-
         balancing benefit is to hash the client's link-layer address
         (or some other reliable client-identifying information) and use
         the resulting hash value to select the appropriate relay
         destination (or set of destinations).  The simplest solution,
         of course, is to not use a load-balancing scheme and just relay
         ALL received BOOTREQUEST messages to the same destination (or
         set of destinations).

         When transmitting the request to its next destination, the
         relay agent may set the IP Time-To-Live field to either the
         default value for new datagrams originated by the relay agent,
         or to the TTL of the original BOOTREQUEST decremented by (at
         least) one.

      DISCUSSION:

         As an extra precaution against BOOTREQUEST loops, it is
         preferable to use the decremented TTL from the original
         BOOTREQUEST.  Unfortunately, this may be difficult to do in
         some implementations.

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



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


         transmitting the request.

4.1.2 BOOTREPLY Messages

   BOOTP relay agents relay BOOTREPLY messages only to BOOTP clients.
   It is the responsibility of BOOTP servers to send BOOTREPLY messages
   directly to the relay agent identified in the 'giaddr' field.
   Therefore, a relay agent may assume that all BOOTREPLY messages it
   receives are intended for BOOTP clients on its directly-connected
   networks.

   When a relay agent receives a BOOTREPLY message, it should examine
   the BOOTP 'giaddr', 'yiaddr', 'chaddr', 'htype', and 'hlen' fields.
   These fields should provide adequate information for the relay agent
   to deliver the BOOTREPLY message to the client.

   The 'giaddr' field can be used to identify the logical interface from
   which the reply must be sent (i.e., the host or router interface
   connected to the same network as the BOOTP client).  If the content
   of the 'giaddr' field does not match one of the relay agent's
   directly-connected logical interfaces, the BOOTREPLY messsage MUST be
   silently discarded.

   The 'htype', 'hlen', and 'chaddr' fields supply the link-layer
   hardware type, hardware address length, and hardware address of the
   client as defined in the ARP protocol [4] and the Assigned Numbers
   document [6].  The 'yiaddr' field is the IP address of the client, as
   assigned by the BOOTP server.

   The relay agent SHOULD examine the newly-defined BROADCAST flag (see
   Sections 2.2 and 3.1.1 for more information).  If this flag is set to
   1, 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.

      DISCUSSION:

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




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


         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
         messages to the corresponding client.  The BOOTREPLY messages
         should still properly reach the client, at the cost of one