rfc1541-dhcp.txt

串口配置工具 ·作车牌识别的人一定要看

   the server sends any return messages to the 'DHCP server' port on the
   DHCP relaying agent whose address appears in 'giaddr'.  If the
   'giaddr' field is zero, the client is on the same subnet, and the
   server sends any return messages to either the client's network
   address, if that address was supplied in the 'ciaddr' field, or to
   the client's hardware address or to the local subnet broadcast
   address.

   If the options in a DHCP message extend into the 'sname' and 'file'
   fields, the 'option overload' option MUST appear in the 'options'
   field, with value 1, 2 or 3, as specified in the DHCP options
   document [2].  If the 'option overload' option is present in the
   'options' field, the options in the 'options' field MUST be
   terminated by an 'end' option, and MAY contain one or more 'pad'
   options to fill the options field.  The options in the 'sname' and
   'file' fields (if in use as indicated by the 'options overload'
   option) MUST begin with the first octet of the field, MUST be
   terminated by an 'end' option, and MUST be followed by 'pad' options



Droms                                                          [Page 21]

RFC 1541          Dynamic Host Configuration Protocol       October 1993


   to fill the remainder of the field.  Any individual option in the
   'options', 'sname' and 'file' fields MUST be entirely contained in
   that field.  The options in the 'options' field MUST be interpreted
   first, so that any 'option overload' options may be interpreted.  The
   'file' field MUST be interpreted next (if the 'option overload'
   option indicates that the 'file' field contains DHCP options),
   followed by the 'sname' field.

   DHCP clients are responsible for all message retransmission.  The
   client MUST adopt a retransmission strategy that incorporates a
   randomized exponential backoff algorithm to determine the delay
   between retransmissions.  The delay before the first retransmission
   MUST be 4 seconds randomized by the value of a uniform random number
   chosen from the range -1 to +1.  Clients with clocks that provide
   resolution granularity of less than one second may choose a non-
   integer randomization value.  The delay before the next
   retransmission MUST be 8 seconds randomized by the value of a uniform
   number chosen from the range -1 to +1.  The retransmission delay MUST
   be doubled with subsequent retransmissions up to a maximum of 64
   seconds.  The client MAY provide an indication of retransmission
   attempts to the user as an indication of the progress of the
   configuration process.  The protocol specification in the remainder
   of this section will describe, for each DHCP message, when it is
   appropriate for the client to retransmit that message forever, and
   when it is appropriate for a client to abandon that message and
   attempt to use a different DHCP message.

   Normally, DHCP servers and BOOTP relay agents attempt to deliver
   DHCPOFFER, DHCPACK and DHCPNAK messages directly to the client using
   unicast delivery.  The IP destination address (in the IP header) is
   set to the DHCP 'yiaddr' address and the link-layer destination
   address is set to the DHCP 'chaddr' address.  Unfortunately, some
   client implementations are unable to receive such unicast IP
   datagrams until the implementation has been configured with a valid
   IP address (leading to a deadlock in which the client's IP address
   cannot be delivered until the client has been configured with an IP
   address).

   A client that cannot receive unicast IP datagrams until its protocol
   software has been configured with an IP address SHOULD set the
   BROADCAST bit in the 'flags' field to 1 in any DHCPDISCOVER or
   DHCPREQUEST messages that client sends.  The BROADCAST bit will
   provide a hint to the DHCP server and BOOTP relay agent to broadcast
   any messages to the client on the client's subnet.  A client that can
   receive unicast IP datagrams before its protocol software has been
   configured SHOULD clear the BROADCAST bit to 0.  The BOOTP
   clarifications document discusses the ramifications of the use of the
   BROADCAST bit [21].



Droms                                                          [Page 22]

RFC 1541          Dynamic Host Configuration Protocol       October 1993


   A server or relay agent sending or relaying a DHCP message directly
   to a DHCP client (i.e., not to a relay agent specified in the
   'giaddr' field) SHOULD examine the BROADCAST bit in the 'flags'
   field.  If this bit is set to 1, the DHCP message SHOULD be sent as
   an IP broadcast using an IP broadcast address (preferably
   255.255.255.255) as the IP destination address and the link-layer
   broadcast address as the link-layer destination address.  If the
   BROADCAST bit is cleared to 0, the message SHOULD be sent as an IP
   unicast to the IP address specified in the 'yiaddr' field and the
   link-layer address specified in the 'chaddr' field.  If unicasting is
   not possible, the message MAY be sent as an IP broadcast using an IP
   broadcast address (preferably 255.255.255.255) as the IP destination
   address and the link-layer broadcast address as the link-layer
   destination address.

4.2 DHCP server administrative controls

   DHCP servers are not required to respond to every DHCPDISCOVER and
   DHCPREQUEST message they receive.  For example, a network
   administrator, to retain stringent control over the hosts attached to
   the network, may choose to configure DHCP servers to respond only to
   hosts that have been previously registered through some external
   mechanism.  The DHCP specification describes only the interactions
   between clients and servers when the clients and servers choose to
   interact; it is beyond the scope of the DHCP specification to
   describe all of the administrative controls that system
   administrators might want to use.  Specific DHCP server
   implementations may incorporate any controls or policies desired by a
   network administrator.

   In some environments, a DHCP server will have to consider the values
   of the 'chaddr' field and/or the 'class-identifier' option included
   in the DHCPDISCOVER or DHCPREQUEST messages when determining the
   correct parameters for a particular client.  For example, an
   organization might have a separate bootstrap server for each type of
   client it uses, requiring the DHCP server to examine the 'class-
   identifier' to determine which bootstrap server address to return in
   the 'siaddr' field of a DHCPOFFER or DHCPACK message.

   A DHCP server must use some unique identifier to associate a client
   with its lease.  The client may choose to explicitly provide the
   identifier through the 'client identifier' option.  If the client
   does not provide a 'client identifier' option, the server MUST use
   the contents of the 'chaddr' field to identify the client.

   DHCP clients are free to use any strategy in selecting a DHCP server
   among those from which the client receives a DHCPOFFER message.  The
   client implementation of DHCP should provide a mechanism for the user



Droms                                                          [Page 23]

RFC 1541          Dynamic Host Configuration Protocol       October 1993


   to select directly the 'class-identifier' value.

4.3 DHCP server behavior

   A DHCP server processes incoming DHCP messages from a client based on
   the current state of the binding for that client.  A DHCP server can
   receive the following messages from a client:

      o DHCPDISCOVER

      o DHCPREQUEST

      o DHCPDECLINE

      o DHCPRELEASE

   Table 3 gives the use of the fields and options in a DHCP message by
   a server.  The remainder of this section describes the action of the
   DHCP server for each possible incoming message.

4.3.1 DHCPDISCOVER message

   When a server receives a DHCPDISCOVER message from a client, the
   server chooses a network address for the requesting client.  If no
   address is available, the server may choose to report the problem to
   the system administrator and may choose to reply to the client with a
   DHCPNAK message.  If the server chooses to respond to the client, it
   may include an error message in the 'message' option.  If an address
   is available, the new address should be chosen as follows:

   o The client's previous address as recorded in the client's binding,
     if that address is in the server's pool of available addresses and
     not already allocated, else

   o The address requested in the 'Requested IP Address' option, if that
     address is valid and not already allocated, else

   o A new address allocated from the server's pool of available
     addresses.












Droms                                                          [Page 24]

RFC 1541          Dynamic Host Configuration Protocol       October 1993


  Field      DHCPOFFER            DHCPACK             DHCPNAK
  -----      ---------            -------             -------

  'op'       BOOTREPLY            BOOTREPLY           BOOTREPLY
  'htype'    (From "Assigned Numbers" RFC)
  'hlen'     (Hardware address length in octets)
  'hops'     0                    0                   0
  'xid'      'xid' from client    'xid' from client   'xid' from client
             DHCPDISCOVER         DHCPREQUEST         DHCPREQUEST
             message              message             message
  'secs'     0                    0                   0
  'ciaddr'   0                    'ciaddr' from       'ciaddr' from
                                  DHCPREQUEST or 0    DHCPREQUEST or 0
  'yiaddr'   IP address offered   IP address          0
             to client            assigned to client
  'siaddr'   IP address of next   IP address of next  0
             bootstrap server     bootstrap server
  'flags'    if 'giaddr' is not 0 then 'flags' from client message else 0
  'giaddr'   0                    0                   0
  'chaddr'   'chaddr' from        'chaddr' from       'chaddr' from
             client               client DHCPREQUEST  client DHCPREQUEST
             DHCPDISCOVER         message             message
             message
  'sname'    Server host name     Server host name    (unused)
             or options           or options
  'file'     Client boot file     Client boot file    (unused)
             name or options      name or options
  'options'  options              options

  Option                   DHCPOFFER        DHCPACK          DHCPNAK
  ------                   ---------        -------          -------

  Requested IP address     MUST NOT         MUST NOT         MUST NOT
  IP address lease time    MUST             MUST             MUST NOT
  Use 'file'/'sname'       MAY              MAY              MUST NOT
  fields
  DHCP message type        DHCPOFFER        DHCPACK          DHCPNAK
  Parameter request list   MUST NOT         MUST NOT         MUST NOT
  Message                  SHOULD           SHOULD           SHOULD
  Client identifier        MUST NOT         MUST NOT         MUST NOT
  Class identifier         MUST NOT         MUST NOT         MUST NOT
  Server identifier        MUST             MAY              MAY
  Maximum message size     MUST NOT         MUST NOT         MUST NOT
  All others               MAY              MAY              MUST NOT

           Table 3:  Fields and options used by DHCP servers





Droms                                                          [Page 25]

RFC 1541          Dynamic Host Configuration Protocol       October 1993


   As described in section 4.2, a server MAY, for administrative
   reasons, assign an address other than the one requested, or may
   refuse to allocate an address to a particular client even though free
   addresses are available.

   While not required for correct operation of DHCP, the server should
   not reuse the selected network address before the client responds to
   the server's DHCPOFFER message.  The server may choose to record the
   address as offered to the client.

   The server must also choose an expiration time for the lease, as
   follows:

   o IF the client has not requested a specific lease in the
     DHCPDISCOVER message and the client already has an assigned network
     address, the server returns the lease expiration time previously
     assigned to that address (note that the client must explicitly
     request a specific lease to extend the expiration time on a
     previously assigned address), ELSE

   o IF the client has not requested a specific lease in the
     DHCPDISCOVER message and the client does not have an assigned
     network address, the server assigns a locally configured default
     lease time, ELSE

   o IF the client has requested a specific lease in the DHCPDISCOVER
     message (regardless of whether the client has an assigned network
     address), the server may choose either to return the requested
     lease (if the lease is acceptable to local policy) or select
     another lease.

   Once the network address and lease have been determined, the server
   constructs a DHCPOFFER message with the offered configuration
   parameters.  It is important for all DHCP servers to return the same
   parameters (with the possible exception of a newly allocated network
   address) to ensure predictable host behavior regardless of the which
   server the client selects.  The configuration parameters MUST be
   selected by applying the following rule