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 tcpipguide.com". Or go to the Tools menu and select "Adblock Plus Preferences...". Then click "Add Filter..." at the bottom, and add this string: "@@||tcpipguide.com^$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 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

DHCP Lease Allocation Process 1 2 DHCP Lease Renewal and Rebinding Processes

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.

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):

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.

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

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.

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

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.

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.

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.

DHCP Lease Allocation Process 1 2 DHCP Lease Renewal and Rebinding Processes