Question about DHCPRELEASE

Darren perl-list at
Fri Jul 28 12:27:48 UTC 2006

As always, you have been very helpful.  For clarity's sake then, 
DHCPRELEASE (when sent - which usually only happens when a user manually 
invokes such a thing) does indeed truncate the lease and immediately 
move the IP Address to a FREE or BACKUP state yes?

David W. Hankins wrote:
> On Thu, Jul 27, 2006 at 08:37:43PM -0400, Darren wrote:
>> 2006-07-27 00:00:00  client does DHCPDISCOVER
>> 2006-07-27 00:00:00  server does DHCPOFFER of an IP Address with 
>> min/default/max lease length of 3600 seconds
> Actually, ISC dhcpd will generally answer somewhere between 0 and 1
> seconds later, in default configuration.  The ping-check does this.
> The timer system literally gates on the edge between seconds, so if
> the client's packet was received late in the second, very close to
> the next second, then the actual amount of time waited is closer to
> zero (but never equal of course).  Likewise the contrary - if the
> client's packet happened to be received very close to the start of
> the second, the time between will be very close to 1 second (but
> again not quite equal).
>> 2006-07-27 00:00:00  client does DHCPREQUEST for that IP Address with a 
>> 3600 second lease.
>> 2006-07-27 00:00:00  server does DHCPACK and creates 3600 secon lease 
>> for client of that IP Address
>> 2006-07-27 00:30:00  client does DHCPREQUEST of that IP Address with a 
>> 3600 second lease
>> 2006-07-27 00:30:00  server does DHCPACK of that IP Address and updates 
>> the lease begin and end.
>> 2006-07-27 00:33:27  client does DHCPRELEASE and removes the IP Address 
>> from its interface. The server subsequently destroys the lease and marks 
>> the IP Address as free upon receipt of this packet.
> DHCPRELEASE is optional.  Very few operating systems do a DHCPRELEASE
> when they "think they are done".  Most choose to keep their old lease
> on the (generally safe) bet that they will need it soon.  It speeds
> up re-acquisition of the network and causes the DHCP server slightly
> less trouble.
> ISC dhclient will send a DHCPRELEASE if it is explicitly invoked to do
> so.
> I know of very few cases where that's actually used, and none of them
> are default operating system installs.
> Windows for example has a DHCP configuration option you can set that
> informs the client that it is expected to release its lease when it
> is done with it (eg on shutdown).
> I'm not sure if Mac OSX has a similar option.
> There is no standard option for this at any rate.
>> How does this behavior change in a failover situation, if at all?
> Well, once a lease is DHCPRELEASEd, it becomes FREE.  That's not
> BACKUP.  It might stay free, it might move to BACKUP to balance the
> pools.  The client in question might LBA to the primary or secondary,
> and this may not match the state of the lease either way.
> So the client might get a different address when it returns.
> And the state change doesn't happen until the server is in partner-down
> for more than MCLT, or if the two servers agree on the state change (so
> it might happen substantially later than when the client indicated).
> But even this is the same as if the lease had expired: it's just an
> advanced schedule.
> I bring it up mostly because 3.1.0 behaviour will be different: if
> the previous client for the lease (the one that just released)
> hashes on LBA to the secondary, the primary will queue a new binding
> update to move it to BACKUP directly after receiving the
> acknowledgement from the peer.
> This should reduce churn in the lease pools, leases should return to
> FREE and BACKUP states more or less in approximate (if random)
> balance, so there should also be less of a need for events to
> rebalance the pools.
> I guess we'll have to wait to find out how it works out there in
> the real world.

More information about the dhcp-users mailing list