rfc2131.txt

DHCP服务器源码

                  v               v               v
     Figure 3: Timeline diagram of messages exchanged between DHCP
               client and servers when allocating a new network address







Droms                       Standards Track                    [Page 15]

RFC 2131          Dynamic Host Configuration Protocol         March 1997


  3. The client receives one or more DHCPOFFER messages from one or more
     servers.  The client may choose to wait for multiple responses.
     The client chooses one server from which to request configuration
     parameters, based on the configuration parameters offered in the
     DHCPOFFER messages.  The client broadcasts a DHCPREQUEST message
     that MUST include the 'server identifier' option to indicate which
     server it has selected, and that MAY include other options
     specifying desired configuration values.  The 'requested IP
     address' option MUST be set to the value of 'yiaddr' in the
     DHCPOFFER message from the server.  This DHCPREQUEST message is
     broadcast and relayed through DHCP/BOOTP relay agents.  To help
     ensure that any BOOTP relay agents forward the DHCPREQUEST message
     to the same set of DHCP servers that received the original
     DHCPDISCOVER message, the DHCPREQUEST message MUST use the same
     value in the DHCP message header's 'secs' field and be sent to the
     same IP broadcast address as the original DHCPDISCOVER message.
     The client times out and retransmits the DHCPDISCOVER message if
     the client receives no DHCPOFFER messages.

  4. The servers receive the DHCPREQUEST broadcast from the client.
     Those servers not selected by the DHCPREQUEST message use the
     message as notification that the client has declined that server's
     offer.  The server selected in the DHCPREQUEST message commits the
     binding for the client to persistent storage and responds with a
     DHCPACK message containing the configuration parameters for the
     requesting client.  The combination of 'client identifier' or
     'chaddr' and assigned network address constitute a unique
     identifier for the client's lease and are used by both the client
     and server to identify a lease referred to in any DHCP messages.
     Any configuration parameters in the DHCPACK message SHOULD NOT
     conflict with those in the earlier DHCPOFFER message to which the
     client is responding.  The server SHOULD NOT check the offered
     network address at this point. The 'yiaddr' field in the DHCPACK
     messages is filled in with the selected network address.

     If the selected server is unable to satisfy the DHCPREQUEST message
     (e.g., the requested network address has been allocated), the
     server SHOULD respond with a DHCPNAK message.

     A server MAY choose to mark addresses offered to clients in
     DHCPOFFER messages as unavailable.  The server SHOULD mark an
     address offered to a client in a DHCPOFFER message as available if
     the server receives no DHCPREQUEST message from that client.

  5. The client receives the DHCPACK message with configuration
     parameters.  The client SHOULD perform a final check on the
     parameters (e.g., ARP for allocated network address), and notes the
     duration of the lease specified in the DHCPACK message.  At this



Droms                       Standards Track                    [Page 16]

RFC 2131          Dynamic Host Configuration Protocol         March 1997


     point, the client is configured.  If the client detects that the
     address is already in use (e.g., through the use of ARP), the
     client MUST send 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.  The client should choose to retransmit
     the DHCPREQUEST enough times to give adequate probability of
     contacting the server without causing the client (and the user of
     that client) to wait overly long before giving up; e.g., a client
     retransmitting as described in section 4.1 might retransmit the
     DHCPREQUEST message four times, for a total delay of 60 seconds,
     before restarting the initialization procedure.  If the client
     receives neither a DHCPACK or a DHCPNAK message after employing the
     retransmission algorithm, the client reverts to INIT state and
     restarts the initialization process.  The client SHOULD notify the
     user that the 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 with its 'client identifier',
     or 'chaddr' and network address in the DHCPRELEASE message. If the
     client used a 'client identifier' when it obtained the lease, it
     MUST use the same 'client identifier' in the DHCPRELEASE message.

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

   If a client remembers and wishes to reuse a previously allocated
   network address, 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.











Droms                       Standards Track                    [Page 17]

RFC 2131          Dynamic Host Configuration Protocol         March 1997


   1. The client broadcasts a DHCPREQUEST message on its local subnet.
      The message includes the client's network address in the
      'requested IP address' option. As the client has not received its
      network address, it MUST NOT fill in the 'ciaddr' field. BOOTP
      relay agents pass the message on to DHCP servers not on the same
      subnet.  If the client used a 'client identifier' to obtain its
      address, the client MUST use the same 'client identifier' in the
      DHCPREQUEST message.

   2. Servers with knowledge of the client's configuration parameters
      respond with a DHCPACK message to the client.  Servers SHOULD NOT
      check that the client's network address is already in use; the
      client may respond to ICMP Echo Request messages at this point.

                Server          Client          Server

                  v               v               v
                  |                |               |
                  |              Begins            |
                  |          initialization        |
                  |                |               |
                  |                /|\             |
                  |   _________ __/ | \__________  |
                  | /DHCPREQU EST  |  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



Droms                       Standards Track                    [Page 18]

RFC 2131          Dynamic Host Configuration Protocol         March 1997


      If the client's request is invalid (e.g., the client has moved
      to a new subnet), servers SHOULD respond with a DHCPNAK message to
      the client. Servers SHOULD NOT respond if their information is not
      guaranteed to be accurate.  For example, a server that identifies a
      request for an expired binding that is owned by another server SHOULD
      NOT respond with a DHCPNAK unless the servers are using an explicit
      mechanism to maintain coherency among the servers.

      If 'giaddr' is 0x0 in the DHCPREQUEST message, the client is on
      the same subnet as the server.  The server MUST
      broadcast the DHCPNAK message to the 0xffffffff broadcast address
      because the client may not have a correct network address or subnet
      mask, and the client may not be answering ARP requests.
      Otherwise, the server MUST send the DHCPNAK message to the IP
      address of the BOOTP relay agent, as recorded in 'giaddr'.  The
      relay agent will, in turn, forward the message directly to the
      client's hardware address, so that the DHCPNAK can be delivered even
      if the client has moved to a new network.

   3. The client receives the DHCPACK message with configuration
      parameters.  The client performs a final check on the parameters
      (as in section 3.1), and notes the duration of the lease specified
      in the DHCPACK message.  The specific lease is implicitly identified
      by the 'client identifier' or 'chaddr' and the network address.  At
      this point, the client is configured.

      If the client detects that the IP address in the DHCPACK message
      is already in use, the client MUST send 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.

      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
      client retransmits the DHCPREQUEST according to the retransmission
      algorithm in section 4.1.  The client should choose to retransmit
      the DHCPREQUEST enough times to give adequate probability of
      contacting the server without causing the client (and the user of
      that client) to wait overly long before giving up; e.g., a client
      retransmitting as described in section 4.1 might retransmit the



Droms                       Standards Track                    [Page 19]

RFC 2131          Dynamic Host Configuration Protocol         March 1997


      DHCPREQUEST message four times, for a total delay of 60 seconds,
      before restarting the initialization procedure.  If the client
      receives neither a DHCPACK or a DHCPNAK message after employing
      the retransmission algorithm, the client MAY choose to use the
      previously allocated network address and 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 its
      'client identifier', or 'chaddr' and network address in the
      DHCPRELEASE message.

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

   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