Please Whitelist This Site?

I know everyone hates ads. But please understand that I am providing premium content for free that takes hundreds of hours of time to research and write. I don't want to go to a pay-only model like some sites, but when more and more people block ads, I end up working for free. And I have a family to support, just like you. :)

If you like The TCP/IP Guide, please consider the download version. It's priced very economically and you can read all of it in a convenient format without ads.

If you want to use this site for free, I'd be grateful if you could add the site to the whitelist for Adblock. To do so, just open the Adblock menu and select "Disable on". Or go to the Tools menu and select "Adblock Plus Preferences...". Then click "Add Filter..." at the bottom, and add this string: "@@||^$document". Then just click OK.

Thanks for your understanding!

Sincerely, Charles Kozierok
Author and Publisher, The TCP/IP Guide

NOTE: Using software to mass-download the site degrades the server and is prohibited.
If you want to read The TCP/IP Guide offline, please consider licensing it. Thank you.

The Book is Here... and Now On Sale!

Read offline with no ads or diagram watermarks!
The TCP/IP Guide

Custom Search

Table Of Contents  The TCP/IP Guide
 9  TCP/IP Application Layer Protocols, Services and Applications (OSI Layers 5, 6 and 7)
      9  TCP/IP Network Configuration and Management Protocols (BOOTP, DHCP, SNMP and RMON)
           9  Host Configuration and TCP/IP Host Configuration Protocols (BOOTP and DHCP)
                9  TCP/IP Dynamic Host Configuration Protocol (DHCP)
                     9  DHCP Configuration and Operation

Previous Topic/Section
DHCP Lease Allocation Process
Previous Page
Pages in Current Topic/Section
Next Page
DHCP Lease Renewal and Rebinding Processes
Next Topic/Section

DHCP Lease Reallocation Process
(Page 2 of 2)

Lease Reallocation Process Steps

The reallocation process is essentially an abbreviated version of the allocation process described in the previous topic. There is no need for the client to go through the whole “yoohoo, any servers out there want to give me a lease” routine. Instead, the client attempts to find the server that gave it the lease in the first place, seeking a confirmation that the lease is still valid and that it may resume using its previously-allocated IP address. It also receives confirmation of the parameters it should use.

Figure 264: DHCP Lease Reallocation Process

The lease reallocation process consists of seven steps that correspond approximately to steps 8 through 14 of the full lease allocation process shown in Figure 263. In this example, the server that originally granted the lease to the client is Server #2, so it is normally the only one that responds.


The following steps summarize the reallocation process, which is also shown in Figure 264. (Note that the same notes about addressing fields, relay agents and such that I mentioned in the discussion of lease allocation apply here as well):

1. Client Creates DHCPREQUEST Message

The client begins in the INIT-REBOOT state instead of the INIT state. It creates a DHCPREQUEST message to attempt to find a server with information about its current lease. Note that this may or may not be the server that originally granted the lease; the server responsible for a lease could, theoretically, have changed in the time since the client obtained the lease. Thus, unlike the DHCPREQUEST message in step #8 in the allocation process, the client does not include a DHCP Server Identifier option. It does includes the following information:

  • Its own hardware address in the CHAddr field of the message, to identify itself.

  • The IP address of its existing lease, in the Requested IP Address DHCP option. Note that this address is not put into the CIAddr field.

  • A random transaction identifier, put into the XID field. This is used to identify later messages as being part of the same transaction.

  • Any additional configuration parameters it wants, in a Parameter Request List option in the message.
2. Client Sends DHCPREQUEST Message

The client broadcasts the DHCPREQUEST message. It then transitions to the REBOOTING state, where it waits for a reply from a server.

3. Servers Receive and Process DHCPREQUEST Message and Generate Replies

Each server on the network receives and processes the client's request. The server looks up the client in its database, attempting to find information about the lease. Each server then decides how to reply to the client:

  • Server Has Valid Client Lease Information: The server has information about the client's lease. It sends a DHCPACK message to confirm the lease. It will also reiterate any parameters the client should be using.

  • Server Determines Client Lease Is Invalid: The server determines that the client's lease is no longer valid. Common reasons for this happening are the client trying to confirm a lease after it has moved to a different network, or after the least has in fact already expired. In such a case the server sends a DHCPNAK message to negate the lease request.

  • Server Has No Definitive Information About Client Lease: A server that has no information about the lease does not respond. A server is also required not to respond unless its information is guaranteed to be accurate. So, for example, if a server has knowledge of an old expired lease, it cannot assume that the lease is no longer valid and send a DHCPNAK, unless it also has certain knowledge that no other server has a newer, valid lease for that client.
4. Servers Send Replies

Servers that are going to respond to the client’s DHCPREQUEST send their DHCPACK or DHCPNAK messages.

5. Client Receives and Processes DHCPACK or DHCPNAK Message

The client waits for a period of time to get a reply to its request. Again, there are three possibilities that match the three in the previous step:

  • Positive Acknowledgment: The client receives a DHCPACK message; this confirms the validity of the lease. The client will prepare to begin using the lease again, and continue with the next step below.

  • Negative Acknowledgment: The message is a DHCPNAK, which tells the client that its lease is no longer valid. The client transitions back to the INIT state to get a new lease—step #1 in the allocation process.

  • No Reply: If the client receives no reply at all, it may retransmit the DHCPREQUEST message. If no reply is received after a period of time, it will conclude that no server has information about its lease and will return to the INIT state to try to get a new lease.
6. Client Checks That Address Is Not In Use

Before resuming use of its lease, the client device should perform a final check to ensure that the new address isn't already in use. Even though this should not be the case when a lease already exists, it's done anyway, as a “safety measure” of sorts. The check is the same as described in step #13 of the allocation process: an ARP request is issued on the local network, to see if any other device thinks it already has the IP address this client was just leased. If another device responds, the client sends a DHCPDECLINE message back to the server, which tells it that the lease is no good because some other device is using the address. The client then goes back to the INIT state to get a new lease.

7. Client Finalizes Lease Allocation

Assuming that the address is not already in use, the client finalizes the lease and transitions to the BOUND state. It is now ready for normal operation.

Key Concept: If a client starts up and already has a lease, it need not go through the full lease allocation process; instead, it can use the shorter reallocation process. The client broadcasts a request to find the server that has the current information on its lease; that server responds back to confirm that the client’s lease is still valid.

Previous Topic/Section
DHCP Lease Allocation Process
Previous Page
Pages in Current Topic/Section
Next Page
DHCP Lease Renewal and Rebinding Processes
Next Topic/Section

If you find The TCP/IP Guide useful, please consider making a small Paypal donation to help the site, using one of the buttons below. You can also donate a custom amount using the far right button (not less than $1 please, or PayPal gets most/all of your money!) In lieu of a larger donation, you may wish to consider purchasing a download license of The TCP/IP Guide. Thanks for your support!
Donate $2
Donate $5
Donate $10
Donate $20
Donate $30
Donate: $

Home - Table Of Contents - Contact Us

The TCP/IP Guide (
Version 3.0 - Version Date: September 20, 2005

Copyright 2001-2005 Charles M. Kozierok. All Rights Reserved.
Not responsible for any loss resulting from the use of this site.