Yesterday, I was working with a colleague to troubleshoot a problem with a VM IP change, so I just wanted to organize the DHCP lease life cycle and the change process.

DHCP lease lifecycle

  • Allocation: A client starts with no valid lease, and therefore no DHCP-assigned address. It acquires a lease through an allocation process.
  • Reallocation: If a client already has an address from an existing lease, then when it reboots or starts up after shutdown, it contacts the DHCP server that granted it the lease to confirm the lease and obtain operational parameters. This is sometimes referred to as a reassignment; it is similar to the full assignment process, but takes less time.
  • Normal Operation: Once the lease is activated, the client works normally, using its assigned IP address and other parameters for the duration of the lease cycle. The client is said to be bound to the lease and address.
  • Renewal: After a certain portion of the lease time has expired, the client will attempt to contact the server that originally granted the lease to renew it so that it can continue to use its IP address.
  • Rebinding: If renewal with the initial lease server fails (for example, because that server is offline), then the client will attempt to rebind to any active DHCP server, attempting to extend its current lease on any server that allows it to do so.
  • Release: The client can decide at any time that it no longer wishes to use the IP address it was assigned and can terminate the lease and release the IP address.

Allocation Process

  1. Client creates DHCPDISCOVER message The client starts in the INIT (initialization) state. It does not have an IP address and does not even know if or where there is a DHCP server on the network. To find one, it creates a DHCPDISCOVER message that includes the following information.
    • Its own hardware address in the CHAddr field of the message, which is used to identify itself.
    • A random transaction identifier, placed in the XID field, which is used to identify subsequent messages as being part of the same transaction.
    • Alternatively, a client can request a specific IP address using the Requested IP Address DHCP option, request a specific lease length using the IP address Lease Time option, or request specific configuration parameters by including the Parameter Request List option in the message.
  2. Client sends DHCPDISCOVER message The client broadcasts a DHCPDISCOVER message on the local network. The client transitions to the SELECTING state, where it waits for a reply to its message.
  3. Server receives and processes DHCPDISCOVER messages Each DHCP server on the local network receives a DHCPDISCOVER message from a client and checks it. The server looks up the customer’s hardware address in its database and determines whether it can offer the customer a lease and what the terms of the lease are. If a customer makes a request for a specific IP address, lease length, or other parameters, the server will attempt to meet those requests, but does not require it. If a server is not set up to serve a particular customer, it has no IP addresses remaining, or for other reasons, it may decide not to offer a lease to that customer.
  4. Server creates DHCPOFFER message Each server that chooses to respond to a client creates a DHCPOFFER message that includes the following information.
    • The YIAddr field contains the IP address to be assigned to the client, and if the server has previously leased for this client, it will attempt to reuse the last IP address used. If not, it will attempt to use the address requested by the customer, if one exists; otherwise, it will select any available address.
    • The length of the lease provided.
    • Any client-specific configuration parameters requested by the client or returned to the client at the server.
    • Any general configuration parameters to be returned to all clients or within that client class.
    • The server identifier in the DHCP Server Identifier option.
    • The same transaction ID (XID) used in the DHCPDISCOVER message.
  5. Server Probe, Reserved Provided Address (optional) The DHCP standard states that before sending a DHCPOFFER to a client, the server “should” check that the IP address is already in use by sending an ICMP Echo message to that address. If it detects that the address is in use, the server will of course not make it available to the client. This can be disabled by the administrator. It is considered to be a key part of the DHCP server’s conflict detection function. Whether it detects the offered address or not, the server can also reserve the address so that it will be available if the client decides to use it. This is not mandatory because, as we will see below, the protocol handles the case when the offered lease is withdrawn. It would be more efficient if the server reserved the address, but if there is a very shortage of IP addresses, such a reservation may not be practical.
  6. Servers send DHCPOFFER messages Every server sends its DHCPOFFER messages. Of course, they may not all be sent at exactly the same time. As mentioned earlier, these messages can be unicast or broadcast.
  7. The client collects and processes DHCPOFFER messages The client waits for the arrival of DHCPOFFER messages as a response to its DHCPDISCOVER. The exact behavior of the client here is implementation-dependent. For convenience, the client may decide to simply accept the first offer it receives. Or it may choose to compare them by waiting for a period of time. It can then process each DHCPOFFER and select the one with the most favorable conditions - for example, the one with the longest lease period. If no DHCPOFFER message is received, the client enters retransmission mode and tries to send DHCPDISCOVER again within a period of time.
  8. client creates DHCPREQUEST message The client creates a DHCPREQUEST message for the server DHCPOFFER it selected. This message serves two purposes: it tells the server whose offer the client accepted “Yes, I accept your offer, assuming it is still available”, and it also tells the other server “Sorry, your offer is rejected”. In this message, the client includes the following information.
    • The identifier of the selected server in the DHCP Server Identifier option.
    • The IP address assigned to the client by the DHCP server in the DHCPOFFER message, which the client uses as the confirmation address in the Requested IP Address DHCP option
    • Any other configuration parameters it wants in the parameter request list option in the message.
  9. Client sends DHCPREQUEST message The client sends a DHCPREQUEST message. Since it is not just for the selected DHCP server, but for all DHCP servers, it is broadcast. After doing so, the client transitions to the REQUESTING state, where it waits for a reply from the selected server.
  10. Servers receive and process DHCPREQUEST messages Each server receives and processes the client’s request message. Servers that are not selected will treat the message as a rejection. Note, however, that a customer may select an OFFER , attempting to request a lease order that was not successfully completed. The customer may then attempt its “second choice” OFFER by sending a DHCPREQUEST containing a different server identifier. this means that if Server A receives a single DHCPREQUEST with Server B as the server identifier, this does not necessarily mean that Server A has completed. For this reason, the “rejected” server waits a while before offering the previously offered lease to another client.
  11. Server sends DHCPACK or DHCPNAK message The selected server will see that its lease has been selected. If it did not previously reserve the IP address offered to the client, it must check to make sure it is still available. If not, the server will send back a DHCPNAK (negative confirmation) message. Normally, the server still owns the lease. It will create a binding for the client and send back a DHCPACK message confirming the lease and including all relevant configuration parameters for the client.
  12. Client receives and processes DHCPACK or DHCPNAK message The client receives a positive or negative acknowledgement of its request. If the message is a DHCPNAK, the client transitions to the INIT state and starts over: back at the origin (step #1). If it is a DHCPACK, the client reads the IP address from the YIAddr field and records the lease length and other parameters from the various message fields and DHCP options. If the client does not receive any messages, it can retransmit the DHCPREQUEST message one or more times. If it continues to hear nothing, then it must conclude that the server has failed and return to step 1.
  13. Client checks if the address is in use The client device should perform a final check to ensure that the new address is not in use before ending the lease process. This is usually done by generating an ARP request on the local network to see if any other device thinks it already has the IP address that the client just leased. If any other devices respond, the client sends a DHCPDECLINE message to the server, and then the client goes back to step 1 and starts over.
  14. Client Finalizes Lease Assignment Assuming the address is not already in use, the client finalizes the lease and transitions to the BOUND state. It has also set its two lease timers, T1 and T2. It is now ready for normal operation.

Reallocation Process

  1. Client creates DHCPREQUEST message The client starts with the INIT-REBOOT state instead of the INIT state. It creates a DHCPREQUEST message, trying to find a server with its current lease information. Note that this may not be the server that originally granted the lease; in theory, the server responsible for the lease could change after the client has been granted the lease. Therefore, unlike the DHCPREQUEST message in step 8 of the assignment process, the client does not include the DHCP server identifier option. It does include the following information.
    • Include its own hardware address in the CHAddr field of the message to identify itself.
    • The Requested IP Address DHCP option contains the IP address of its existing lease, which is not put into the CIAddr field.
    • A random transaction identifier that is placed in the XID field. This is used to identify subsequent messages as part of the same transaction.
    • Any additional configuration parameters it wants, placed in the parameter request list option in the message.
  2. Client sends DHCPREQUEST message The client broadcasts a DHCPREQUEST message. Then, it transitions to the REBOOTING state and waits for a reply from the server.
  3. The server receives and processes the DHCPREQUEST message and generates a reply Each DHCP server on the network receives and processes requests from clients. The server looks up the client in its database and tries to find information about the lease. Each DHCP server then decides how to reply to the client.
    • The server has information about valid client leases. The server has the client’s lease information. It sends a DHCPACK message to confirm the lease. It also reiterates any parameters that the client should use.
    • The server determines that the client’s lease is invalid. The server determines that the client’s lease is no longer valid. This commonly happens when a client tries to confirm a lease after moving to a different network, or after it has in fact at least expired. In this case, the server sends a DHCPNAK message to negate the lease request.
    • The server has no explicit information about the customer’s lease. Servers that do not have lease information do not respond. A server is also asked not to respond unless its information is guaranteed to be accurate. For example, if a server knows of an expired lease, it cannot assume that the lease is no longer valid and send a DHCPNAK unless it also knows that no other server has a newer, valid lease for that customer.
  4. server sends a reply Servers that will respond to a client’s DHCPREQUEST send their DHCPACK or DHCPNAK message.
  5. the client receives and processes the DHCPACK or DHCPNAK message The client waits for a period of time to get a response to its request. Again, there are three possibilities that match the three possibilities in the previous step.
    • Positive acknowledgement. The client receives a DHCPACK message; this confirms the validity of the lease. The client will be ready to start using the lease again and continue with the following steps.
    • Negative acknowledgement. This message is a DHCPNAK which tells the client that its lease is no longer valid. The client transitions to the INIT state to get a new lease - step 1 in the assignment process.
    • No reply. If the client does not receive a reply at all, it can resend the DHCPREQUEST message. If no reply is received after some time, it will conclude that no server has its lease information and will return to the INIT state to try to obtain a new lease.
  6. Client checks if the address is in use Before resuming use of its lease, the client device should perform a final check to ensure that the new address is not in use. Although this should not be done when a lease already exists, it is important to do so as a security measure. This check is the same as described in step 13 of the assignment process: send an ARP request on the local network to see if any other device thinks it already has the IP address that the client has just leased. If any other device responds, the client sends a DHCPDECLINE message to the server telling it that the lease is invalid because another device is using the address. The client then returns to the INIT state and gets a new lease.
  7. The client finalizes the lease assignment Assuming the address is not yet in use, the client finalizes the lease and transitions to the BOUND state. It is now ready for normal operation.

Renewal & Rebinding Process

  1. Renewal timer (T1) expires The renewal timer, T1, is set to 50% of the lease length by default. When the timer is turned off, the client transitions from the BOUND state to the RENEWING state. The client can initiate a lease renewal before the T1 timer expires. 2.
  2. client sends DHCPREQUEST update message The client creates a DHCPREQUEST message that identifies itself and its lease. It then delivers the message directly to the server that originally granted the lease, unicast. This is different from the DHCPREQUEST message used in the allocation/redistribution process, where the DHCPREQUEST is broadcast. The client can request a specific new lease length, just as it requested the lease length during the allocation process, and the server makes the final decision on the lease length.
  3. the server receives and processes the DHCPREQUEST message and creates a reply Assuming the server is reachable, it will receive and process the client’s update request. There are two possible responses.
    • The server agrees to update the customer’s lease. The server decides that the customer’s lease can be renewed. It prepares to send a DHCPACK message to the customer to confirm the lease renewal, indicating the new lease length and any parameters that may have changed since the lease was created or last renewed.
    • The server refuses to update the client lease. The server decides not to update the customer’s lease for any reason. It will create a DHCPNAK message.
  4. Server sends a reply The server sends a DHCPACK or DHCPNAK message back to the client.
  5. The client receives and processes the server reply The client takes appropriate action on the server reply.
    • Positive acknowledgement. The client receives a DHCPACK message to update the lease. The client notes the new lease expiration time and any changed parameters sent by the server, resets the T1 and T2 timers, and transitions to the BOUND state. Note that the client does not need to do an ARP IP address check at the time of the update.
    • Negate Acknowledgement. This message is a DHCPNAK that tells the client that its renewal request has been denied. The client will immediately transition to the INIT state to obtain a new lease - step 1 in the assignment process.
  6. Rebinding timer (T2) expires If the client does not receive a response from the server, it will remain in the RENEWING state and periodically retransmit a unicast DHCPREQUEST to the server. during this time, the client is still operating normally from the user’s perspective. If no response is received from the server, the final rebinding timer (T2) will expire. This will cause the client to transition to the REBINDING state. Recall that by default, the T2 timer is set to 87.5% (7 out of 8) of the lease length.
  7. client sends DHCPREQUEST rebind message Since no response is received from the server that originally granted the lease, the client abandons that server and attempts to contact any server that might be able to extend its existing lease. It creates a DHCPREQUEST message and places its IP address in the CIAddr field, explicitly indicating that it currently owns the address. It then broadcasts the request on the local network.
  8. The server receives and processes the DHCPREQUEST message and sends a reply Each DHCP server receives the request and responds based on the customer information it has.
    • The server agrees to rebind the customer’s lease. The server has the customer’s lease information and agrees to extend the lease. It prepares a DHCPACK message for the customer to acknowledge the lease renewal and indicate any parameters that may have occurred since the lease was created or last renewed.
    • The server decides that the client cannot extend its current lease. The server decides that for whatever reason, this customer’s lease should not be extended. It prepares to send a DHCPNAK message to the customer.
  9. The server sends a reply Each server that responds to a client sends its DHCPACK or DHCPNAK message.
  10. The client receives the server reply The client takes the appropriate action for the two possibilities in the previous step.
    • Positive acknowledgement. The client receives a DHCPACK message and rebinds the lease. The client notes the server now responsible for this lease, the new lease expiration time, and any changed parameters sent by the server. It resets the T1 and T2 timers and transitions to the BOUND state. (It can also probe for new addresses as it does during regular lease assignments).
    • Negative acknowledgement. This message is a DHCPNAK that tells the client that some server has determined that the lease should not be extended. The client immediately transitions to the INIT state to get a new lease - step 1 in the allocation process.
  11. Lease Expiration If the client does not receive a response to its broadcast rebinding request, it will resend the request periodically, as it would in the RENEWING state. If it does not receive any response when the lease expires, it will transition to the INIT state to obtain a new lease.