| 
 
 
 | 
 
 DHCP Lease Renewal and Rebinding Processes
 (Page 2 of 3)
 Lease Renewal/Rebinding Process Steps The following steps summarize the 
renewal/rebinding process. Obviously, the exact sequence of operations 
taken by a client depends on what happens in its attempts to contact 
a server; for example, if it is successful with renewal, it will never 
need to attempt rebinding. An example renewal and rebinding is illustrated 
in Figure 265. 
Note also that the same notes about addressing fields, relay agents 
and such that I mentioned in the 
allocation process topic apply here as 
well. 
 Figure 265: DHCP Lease Renewal and Rebinding Processes This diagram shows the example of a client that presently holding a lease with Server #2 attempting to contact it to renew the lease. However, in this case, Server #2 is down for maintenance. The server is unable to respond and the client remains stuck at Step #2 in the renewal/rebinding process. It keeps sending DHCPREQUEST messages to Server #2 until its T2 timer expires. It then enters the rebinding state and broadcasts a DHCPREQUEST message, which is heard by Server #1, which in this case agrees to extend its current lease. 
|   
 | 
1. Renewal Timer (T1) Expires
 The renewal timer, T1, is 
set by default to 50% of the length of the lease. When the timer goes 
off, the client transitions from the BOUND state to the RENEWING 
state. Note that a client may 
initiate lease renewal prior to T1 timer expiration if it desires.2. Client Sends DHCPREQUEST Renewal Message The client creates a DHCPREQUEST 
message that identifies itself and its lease. It then transmits the 
message directly to the server that initially granted the lease, unicast. 
Note that this is different from the DHCPREQUEST messages used 
in the allocation/reallocation processes, where the DHCPREQUEST 
is broadcast. The client may request a particular new lease length, 
just as it may request a lease length in its requests during allocation, 
but as always, the server makes the final call on lease length.3. Server Receives and Processes DHCPREQUEST Message and Creates Reply Assuming the server is reachable, 
it will receive and process the client's renewal request. There are 
two possible responses: 
4. Server Sends ReplyServer Agrees To Renew Client Lease: The 
server decides that the client's lease can be renewed. It prepares to 
send to the client a DHCPACK message to confirm the lease's renewal, 
indicating the new lease length and any parameters that may have changed 
since the lease was created or last renewed.
 
Server Refuses To Renew Client Lease: 
The server decides for whatever reason not to renew the client's lease. 
It will create a DHCPNAK message.
 The server sends the DHCPACK 
or DHCPNAK message back to the client.5. Client Receives and Processes Server Reply The client takes the appropriate 
action in response to the server's reply: 
6. Rebinding Timer (T2) ExpiresPositive Acknowledgment: The client receives 
a DHCPACK message, renewing the lease. The client makes note 
of the new lease expiration time and any changed parameters sent by 
the server, resets the T1 and T2 timers, and transitions 
back to the BOUND state. Note that the client does not 
need to do an ARP IP address check when it is renewing.
 
Negative Acknowledgment: The message is 
a DHCPNAK, which tells the client that its lease renewal request 
has been denied. The client will immediately transition to the INIT 
state to get a new leasestep #1 in the allocation process.
 If the client receives no reply from 
the server, it will remain in the RENEWING state, and will regularly 
retransmit the unicast DHCPREQUEST to the server. During this 
period of time, the client is still operating normally, from the perspective 
of its user. If no response from the server is received, eventually 
the rebinding timer (T2) expires. This will cause the client 
to transition to the REBINDING state. Recall 
that by default, the T2 timer is 
set to 87.5% (7/8ths) of the length of the lease.7. Client Sends DHCPREQUEST Rebinding Message Having received no response from 
the server that initially granted the lease, the client gives 
up on that server and tries to contact any server that may be 
able to extend its existing lease. It creates a DHCPREQUEST message 
and puts its IP address in the CIAddr field, indicating clearly 
that it presently owns that address. It then broadcasts the request 
on the local network.8. Servers Receives and Processes DHCPREQUEST Message and Send Reply Each server receives the request, 
and responds according to the information it has for the client (a server 
that has no information about the lease or may have outdated information 
does not respond): 
9. Server Sends ReplyServer Agrees To Rebind Client Lease: 
A server has information about the client's lease and agrees to extend 
it. It prepares for the client a DHCPACK message to confirm the 
lease's renewal, indicating any parameters that may have changed since 
the lease was created or last renewed. 
 
Server Decides Client Cannot Extend Its Current 
Lease: A server determines that for whatever reason, this client's 
lease should not be extended. It gets ready to send back to the client 
a DHCPNAK message.
 Each server that is responding to 
the client sends its DHCPACK or DHCPNAK message.10. Client Receives Server Reply The client takes the appropriate 
action in response to the two possibilities in the preceding step: 
11. Lease ExpiresPositive Acknowledgment: The client receives 
a DHCPACK message, rebinding the lease. The client makes note 
of the server that is now in charge of this lease, the new lease expiration 
time, and any changed parameters sent by the server. It resets the T1 
and T2 timers, and transitions back to the BOUND state. 
(It may also probe the new address as it does during regular lease allocation.)
 
Negative Acknowledgment: The message is 
a DHCPNAK, which 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 leasestep #1 in the allocation 
process.
 If the client receives no response 
to its broadcast rebinding request, it will, as in the RENEWING 
state, retransmit the request regularly. If no response is received 
by the time the lease expires, it transitions to the INIT state 
to get a new lease. 
 
 | 
 | 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! |  
|  | 
 | 
 
 
 Home - 
Table Of Contents - Contact Us
 
 The TCP/IP Guide (http://www.TCPIPGuide.com)
 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.
 |