DHCPd sending lease expiration of 3600 seconds

Jeff Haran jharan at Brocade.COM
Wed Feb 18 19:03:56 UTC 2009


> -----Original Message-----
> From: dhcp-users-bounces at lists.isc.org 
> [mailto:dhcp-users-bounces at lists.isc.org] On Behalf Of Simon Hobson
> Sent: Wednesday, February 18, 2009 12:08 AM
> To: Users of ISC DHCP
> Subject: RE: DHCPd sending lease expiration of 3600 seconds
> 
...
> 
> There isn't actually a value for 'infinite', the best the server can 
> do is use the end of time, which in unix terms is currently 19th Jan 
> 2038 when the 32bit counter rolls over. Is 28 years not a long enough 
> lease :-)
> 
> -- 
> Simon Hobson
> 

OK. I see my error. I was assuming that the option 51 lease time value
was following the same semantics as IPv6's autoconfiguration preferred
and valid lifetimes, which do define 0xffffffff to mean infinity.

But I now see that RFC 2132 makes no such stipulation for option 51. So
the protocol itself does not allow for the assignment of an infinite
lease. Unfortunate and a bit short sighted.

The weird thing is at least some open source DHCP clients interpret
0xffffffff to mean infinity. The dhcpcd package (at least the version I
have) specifically checks for this. If it receives an offer with a lease
time of 0xffffffff, it configures it's IP stack with the offered
configuration and exits since there is no reason for it to continue to
run if there is no need to renew. It's because of this code that I
thought it was supposed to work this way.

Has this special interpretation of a lease time of 0xffffffff always
been non-standard or was it allowed in prior RFCs that have since been
obsoleted?

It seems like a reasonable extension, even if it isn't called for in the
RFCs. It would be nice if it were possible to configure dhcpd to offer
leases like this. On workstations with lots of resources, keeping a
daemon running that has nothing to do for years may have no downside,
but on embedded systems with limited resources in closed networks where
all that is desired is to assign an address and be done with it, it
would be nice to be able run a standard client that upon receiving an
infinite lease would terminate and free up the resources it consumes.

WRT 32 bit rollovers, I haven't read where the protocol defines the
beginning and end of time to correspond to the Unix Epoch. The RFC says:

9.2. IP Address Lease Time

   This option is used in a client request (DHCPDISCOVER or DHCPREQUEST)
   to allow the client to request a lease time for the IP address.  In a
   server reply (DHCPOFFER), a DHCP server uses this option to specify
   the lease time it is willing to offer.

   The time is in units of seconds, and is specified as a 32-bit
   unsigned integer.

If somebody wants to assign 136 year leases, why should the
implementation prohibit that?

Thanks,

Jeff Haran
Brocade



More information about the dhcp-users mailing list