rfc1541-dhcp.txt

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

   DHCPRELEASE  -  Client to server relinquishing network address and
                   cancelling remaining lease.

                          Table 2:  DHCP messages

   5. The client receives the DHCPACK message with configuration
      parameters.  The client performs a final check on the parameters
      (e.g., ARP for allocated network address), and notes the duration
      of the lease and the lease identification cookie specified in the
      DHCPACK message.  At this point, the client is configured.  If the
      client detects a problem with the parameters in the DHCPACK
      message, the client sends a DHCPDECLINE message to the server and
      restarts the configuration process.  The client should wait a
      minimum of ten seconds before restarting the configuration process
      to avoid excessive network traffic in case of looping.

      If the client receives a DHCPNAK message, the client restarts the
      configuration process.

      The client times out and retransmits the DHCPREQUEST message if the
      client receives neither a DHCPACK or a DHCPNAK message.  The client
      retransmits the DHCPREQUEST according to the retransmission
      algorithm in section 4.1.  If the client receives neither a DHCPACK
      or a DHCPNAK message after ten retransmissions of the DHCPREQUEST
      message, the client reverts to INIT state and restarts the
      initialization process.  The client SHOULD notify the user that the



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


      initialization process has failed and is restarting.

   6. The client may choose to relinquish its lease on a network address
      by sending a DHCPRELEASE message to the server.  The client
      identifies the lease to be released by including its network
      address in the 'ciaddr' field and its hardware address in the
      'chaddr' field.

3.2 Client-server interaction - reusing a previously allocated network
    address

   If a client remembers and wishes to reuse a previously allocated
   network address (allocated either by DHCP or some means outside the
   protocol), a client may choose to omit some of the steps described in
   the previous section.  The timeline diagram in figure 4 shows the
   timing relationships in a typical client-server interaction for a
   client reusing a previously allocated network address.

      1. The client broadcasts a DHCPREQUEST message on its local subnet.
         The DHCPREQUEST message includes the client's network address in
         the 'ciaddr' field.  DHCP/BOOTP relay agents pass the message on
         to DHCP servers not on the same subnet.

      2. Servers with knowledge of the client's configuration parameters
         respond with a DHCPACK message to the client.

         If the client's request is invalid (e.g., the client has moved
         to a new subnet), servers may respond with a DHCPNAK message to
         the client.

      3. The client receives the DHCPACK message with configuration
         prameters.  The client performs a final check on the parameters
         (as in section 3.1), and notes the duration of the lease and
         the lease identification cookie specified in the DHCPACK
         message.  At this point, the client is configured.

         If the client detects a problem with the parameters in the
         DHCPACK message, the client sends a DHCPDECLINE message to the
         server and restarts the configuration process by requesting a
         new network address.  This action corresponds to the client
         moving to the INIT state in the DHCP state diagram, which is
         described in section 4.4.









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


                Server          Client          Server

                  v               v               v
                  |               |               |
                  |             Begins            |
                  |         initialization        |
                  |               |               |
                  |              /|\              |
                  |  ___________/ | \___________  |
                  | /DHCPREQUEST  |  DHCPREQUEST\ |
                  |/              |              \|
                  |               |               |
               Locates            |            Locates
            configuration         |         configuration
                  |               |               |
                  |\              |              /|
                  | \             |  ___________/ |
                  |  \            | /  DHCPACK    |
                  |   \_______    |/              |
                  |    DHCPACK\   |               |
                  |         Initialization        |
                  |            complete           |
                  |              \|               |
                  |               |               |
                  |          (Subsequent          |
                  |            DHCPACKS           |
                  |            ignored)           |
                  |               |               |
                  |               |               |
                  v               v               v

     Figure 4: Timeline diagram of messages exchanged between DHCP
               client and servers when reusing a previously allocated
               network address

         If the client receives a DHCPNAK message, it cannot reuse its
         remembered network address.  It must instead request a new
         address by restarting the configuration process, this time
         using the (non-abbreviated) procedure described in section
         3.1.  This action also corresponds to the client moving to
         the INIT state in the DHCP state diagram.

         The client times out and retransmits the DHCPREQUEST message if
         the client receives neither a DHCPACK nor a DHCPNAK message.
         The   time between retransmission MUST be chosen according to
         the algorithm given in section 4.1.  If the client receives no
         answer after transmitting 4 DHCPREQUEST messages, the client
         MAY choose to use the previously allocated network address and



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


         configuration parameters for the remainder of the unexpired
         lease.  This corresponds to moving to BOUND state in the client
         state transition diagram shown in figure 5.

      4. The client may choose to relinquish its lease on a network
         address by sending a DHCPRELEASE message to the server.  The
         client identifies the lease to be released with the lease
         identification cookie.

         Note that in this case, where the client retains its network
         address locally, the client will not normally relinquish its
         lease during a graceful shutdown.  Only in the case where the
         client explicitly needs to relinquish its lease, e.g., the client
         is about to be moved to a different subnet, will the client send
         a DHCPRELEASE message.

3.3 Interpretation and representation of time values

   A client acquires a lease for a network address for a fixed period of
   time (which may be infinite).  Throughout the protocol, times are to
   be represented in units of seconds.  The time value of 0xffffffff is
   reserved to represent "infinity".  The minimum lease duration is one
   hour.

   As clients and servers may not have synchronized clocks, times are
   represented in DHCP messages as relative times, to be interpreted
   with respect to the client's local clock.  Representing relative
   times in units of seconds in an unsigned 32 bit word gives a range of
   relative times from 0 to approximately 100 years, which is sufficient
   for the relative times to be measured using DHCP.

   The algorithm for lease duration interpretation given in the previous
   paragraph assumes that client and server clocks are stable relative
   to each other.  If there is drift between the two clocks, the server
   may consider the lease expired before the client does.  To
   compensate, the server may return a shorter lease duration to the
   client than the server commits to its local database of client
   information.

3.4 Host parameters in DHCP

   Not all clients require initialization of all parameters listed in
   Appendix A.  Two techniques are used to reduce the number of
   parameters transmitted from the server to the client.  First, most of
   the parameters have defaults defined in the Host Requirements RFCs;
   if the client receives no parameters from the server that override
   the defaults, a client uses those default values.  Second, in its
   initial DHCPDISCOVER or DHCPREQUEST message, a client may provide the



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


   server with a list of specific parameters the client is interested
   in.

   The client SHOULD include the 'maximum DHCP message size' option to
   let the server know how large the server may make its DHCP messages.
   The parameters returned to a client may still exceed the space
   allocated to options in a DHCP message.  In this case, two additional
   options flags (which must appear in the 'options' field of the
   message) indicate that the 'file' and 'sname' fields are to be used
   for options.

   The client can inform the server which configuration parameters the
   client is interested in by including the 'parameter request list'
   option.  The data portion of this option explicitly lists the options
   requested by tag number.

   In addition, the client may suggest values for the network address
   and lease time in the DHCPDISCOVER message.  The client may include
   the 'requested IP address' option to suggest that a particular IP
   address be assigned, and may include the 'IP address lease time'
   option to suggest the lease time it would like.  No other options
   representing "hints" at configuration parameters are allowed in a
   DHCPDISCOVER or DHCPREQUEST message.  The 'ciaddr' field is to be
   filled in only in a DHCPREQUEST message when the client is requesting
   use of a previously allocated IP address.

   If a server receives a DHCPREQUEST message with an invalid 'ciaddr',
   the server SHOULD respond to the client with a DHCPNAK message and
   may choose to report the problem to the system administrator.  The
   server may include an error message in the 'message' option.

3.5 Use of DHCP in clients with multiple interfaces

   A host with multiple network interfaces must use DHCP through each
   interface independently to obtain configuration information
   parameters for those separate interfaces.

3.6 When clients should use DHCP

   A host should use DHCP to reacquire or verify its IP address and
   network parameters whenever the local network parameters may have
   changed; e.g., at system boot time or after a disconnection from the
   local network, as the local network configuration may change without
   the host's or user's knowledge.

   If a host has knowledge of a previous network address and is unable
   to contact a local DHCP server, the host may continue to use the
   previous network address until the lease for that address expires.



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


   If the lease expires before the host can contact a DHCP server, the
   host must immediately discontinue use of the previous network address
   and may inform local users of the problem.

4. Specification of the DHCP client-server protocol

   In this section, we assume that a DHCP server has a block of network
   addresses from which it can satisfy requests for new addresses.  Each
   server also maintains a database of allocated addresses and leases in
   local permanent storage.

4.1 Constructing and sending DHCP messages

   DHCP clients and servers both construct DHCP messages by filling in
   fields in the fixed format section of the message and appending
   tagged data items in the variable length option area.  The options
   area includes first a four-octet 'magic cookie' (which was described
   in section 3), followed by the options.  The last option must always
   be the 'end' option.

   DHCP uses UDP as its transport protocol.  DHCP messages from a client
   to a server are sent to the 'DHCP server' port (67), and DHCP
   messages from a server to a client are sent to the 'DHCP client' port
   (68).

   DHCP messages broadcast by a client prior to that client obtaining
   its IP address must have the source address field in the IP header
   set to 0.

   If the 'giaddr' field in a DHCP message from a client is non-zero,