Dhclient makes system unresponsive with very short leases

Ted Lemon Ted.Lemon at nominum.com
Tue May 12 16:02:00 UTC 2009

On May 12, 2009, at 8:49 AM, David W. Hankins wrote:
> The patch appears to enforce a 60 second minimum lease time, which is
> not described in any IETF RFC.  I suspect imposing one would be met
> with some resistance.

Generally our experience has been that lease times shorter than about  
30 seconds work really badly.   Your point about /var filling up is  
correct, but that's not the whole problem.   DHCP was never intended  
to support leases this short, and none of the infrastructure it  
depends on or that depends on it really works in this context.   E.g.,  
TCP and DNS timeouts tend to be in the 90 second range, so when you go  
shorter than that on a lease, does that even make sense?

I think the 60 second minimum lease time is not unreasonable.    
However, the way I would address it is for the client to discard any  
DHCPOFFER or DHCPACK it receives that offers a lease that's shorter  
than 60 seconds.   You can't simply unilaterally decide to keep the  
lease for longer than the server offered.

By the way, when you get a two-second lease, it's very likely the  
client will compute a renewal time of zero, because it's using integer  
math.   We "fixed" this in DHCPv6 by specifying intervals in  
milliseconds, but DHCPv4 just uses seconds.   So you could probably  
make the client behave more correctly on two-second leases by tweaking  
the way it does the math to compute the renewal time.

More information about the dhcp-users mailing list