Section 3. The Client-Server Protocol

DHCP uses the BOOTP message format defined in RFC 951 and given in
   table 1 and figure 1.  The 'op' field of each DHCP message sent from
   a client to a server contains BOOTREQUEST. BOOTREPLY is used in the
   'op' field of each DHCP message sent from a server to a client.
   The first four octets of the 'options' field of the DHCP message
   contain the (decimal) values 99, 130, 83 and 99, respectively (this
   is the same magic cookie as is defined in RFC 1497 [17]).  The
   remainder of the 'options' field consists of a list of tagged
   parameters that are called "options".  All of the "vendor extensions"
   listed in RFC 1497 are also DHCP options.  RFC 1533 gives the
   complete set of options defined for use with DHCP.
   Several options have been defined so far.  One particular option -
   the "DHCP message type" option - must be included in every DHCP
   message.  This option defines the "type" of the DHCP message.
   Additional options may be allowed, required, or not allowed,
   depending on the DHCP message type.
   Throughout this document, DHCP messages that include a 'DHCP message
   type' option will be referred to by the type of the message; e.g., a
   DHCP message with 'DHCP message type' option type 1 will be referred
   to as a "DHCPDISCOVER" message.
3.1 Client-server interaction - allocating a network address
   The following summary of the protocol exchanges between clients and
   servers refers to the DHCP messages described in table 2.  The
   timeline diagram in figure 3 shows the timing relationships in a
   typical client-server interaction.  If the client already knows its
   address, some steps may be omitted; this abbreviated interaction is
   described in section 3.2.
   1. The client broadcasts a DHCPDISCOVER message on its local physical
      subnet.  The DHCPDISCOVER message MAY include options that suggest
      values for the network address and lease duration.  BOOTP relay
      agents may pass the message on to DHCP servers not on the same
      physical subnet.
   2. Each server may respond with a DHCPOFFER message that includes an
      available network address in the 'yiaddr' field (and other
      configuration parameters in DHCP options).  Servers need not
      reserve the offered network address, although the protocol will
      work more efficiently if the server avoids allocating the offered
      network address to another client.  When allocating a new address,
      servers SHOULD check that the offered network address is not
      already in use; e.g., the server may probe the offered address
      with an ICMP Echo Request.  Servers SHOULD be implemented so that
      network administrators MAY choose to disable probes of newly
      allocated addresses.  The server transmits the DHCPOFFER message
      to the client, using the BOOTP relay agent if necessary.
   Message         Use
   -------         ---
   DHCPDISCOVER -  Client broadcast to locate available servers.
   DHCPOFFER    -  Server to client in response to DHCPDISCOVER with
                   offer of configuration parameters.
   DHCPREQUEST  -  Client message to servers either (a) requesting
                   offered parameters from one server and implicitly
                   declining offers from all others, (b) confirming
                   correctness of previously allocated address after,
                   e.g., system reboot, or (c) extending the lease on a
                   particular network address.
   DHCPACK      -  Server to client with configuration parameters,
                   including committed network address.
   DHCPNAK      -  Server to client indicating client's notion of network
                   address is incorrect (e.g., client has moved to new
                   subnet) or client's lease as expired
   DHCPDECLINE  -  Client to server indicating network address is already
                   in use.
   DHCPRELEASE  -  Client to server relinquishing network address and
                   cancelling remaining lease.
   DHCPINFORM   -  Client to server, asking only for local configuration
                   parameters; client already has externally configured
                   network address.
                          Table 2:  DHCP messages
                Server          Client          Server
            (not selected)                    (selected)
                  v               v               v
                  |               |               |
                  |     Begins initialization     |
                  |               |               |
                  | _____________/|\____________  |
                  |/DHCPDISCOVER | DHCPDISCOVER  \|
                  |               |               |
              Determines          |          Determines
             configuration        |         configuration
                  |               |               |
                  |\             |  ____________/ |
                  | \________    | /DHCPOFFER     |
                  | DHCPOFFER\   |/               |
                  |           \  |                |
                  |       Collects replies        |
                  |             \|                |
                  |     Selects configuration     |
                  |               |               |
                  | _____________/|\____________  |
                  |/ DHCPREQUEST  |  DHCPREQUEST\ |
                  |               |               |
                  |               |     Commits configuration
                  |               |               |
                  |               | _____________/|
                  |               |/ DHCPACK      |
                  |               |               |
                  |    Initialization complete    |
                  |               |               |
                  .               .               .
                  .               .               .
                  |               |               |
                  |      Graceful shutdown        |
                  |               |               |
                  |               |\ ____________ |
                  |               | DHCPRELEASE  \|
                  |               |               |
                  |               |        Discards lease
                  |               |               |
                  v               v               v
     Figure 3: Timeline diagram of messages exchanged between DHCP
               client and servers when allocating a new network address
  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
     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.
   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
      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
      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
   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 Obtaining parameters with externally configured network address
   If a client has obtained a network address through some other means
   (e.g., manual configuration), it may use a DHCPINFORM request message
   to obtain other local configuration parameters.  Servers receiving a
   DHCPINFORM message construct a DHCPACK message with any local
   configuration parameters appropriate for the client without:
   allocating a new address, checking for an existing binding, filling
   in 'yiaddr' or including lease time parameters.  The servers SHOULD
   unicast the DHCPACK reply to the address given in the 'ciaddr' field
   of the DHCPINFORM message.
   The server SHOULD check the network address in a DHCPINFORM message
   for consistency, but MUST NOT check for an existing lease.  The
   server forms a DHCPACK message containing the configuration
   parameters for the requesting client and sends the DHCPACK message
   directly to the client.
3.5 Client 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
   server with a list of specific parameters the client is interested
   in.  If the client includes a list of parameters in a DHCPDISCOVER
   message, it MUST include that list in any subsequent DHCPREQUEST
   messages.
   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.  Other options
   representing "hints" at configuration parameters are allowed in a
   DHCPDISCOVER or DHCPREQUEST message.  However, additional options may
   be ignored by servers, and multiple servers may, therefore, not
   return identical values for some options.  The 'requested IP address'
   option is to be filled in only in a DHCPREQUEST message when the
   client is verifying network parameters obtained previously. The
   client fills in the 'ciaddr' field only when correctly configured
   with an IP address in BOUND, RENEWING or REBINDING state.
   If a server receives a DHCPREQUEST message with an invalid 'requested
   IP address', 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.6 Use of DHCP in clients with multiple interfaces
   A client with multiple network interfaces must use DHCP through each
   interface independently to obtain configuration information
   parameters for those separate interfaces.
3.7 When clients should use DHCP
   A client 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 client's or user's knowledge.
   If a client has knowledge of a previous network address and is unable
   to contact a local DHCP server, the client may continue to use the
   previous network address until the lease for that address expires.
   If the lease expires before the client can contact a DHCP server, the
   client must immediately discontinue use of the previous network
   address and may inform local users of the problem.