We help IT Professionals succeed at work.

Check out our new AWS podcast with Certified Expert, Phil Phillips! Listen to "How to Execute a Seamless AWS Migration" on EE or on your favorite podcast platform. Listen Now


What is the maximum supported value for the DHCP lease time field?

Mike Rolfs
Mike Rolfs asked
Medium Priority
Last Modified: 2012-06-21
I won't go into the back story, but the immediate question is what's the max supported value for DHCP lease time field?  It seems to take something around 9700 days or so (in seconds) but someone's set it to 10,000 days and it's causing problems.  We need a very very long lease time, and static IP's are out of the question.

For part 2 extra credit, anybody knows what happens if a server supports a larger max value than a client and hands the client a lease time value that goes over its supported range?

Server is default dhcpd on SuSE enterprise linux 11 GA, client is a firmware embedded stack.
Watch Question

Mike RolfsCommercial Systems Architect


Further information:

The DHCP server is truncating the value of 10,000 days down to a value of 9763 days, 17 hours, 7 minutes, and 12 seconds.  This comes out to be:
BIN  110010010010000001010101000000
DEC  843584832
HEX  32481540

which makes no sense, as it's not anywhere near a bit/byte/word rollover.
Unlock this solution and get a sample of our free trial.
(No credit card required)
Mike RolfsCommercial Systems Architect


Not a worry there, no DHCP server is serving more than 7-12 clients at a time.  

That's interesting that you note it's 1000 days -1 second, because on a wireshark capture of the dhcp process it shows dhcpd sending the following with the DHCPOFFER:

     Option: (t=51,l=4) IP Address Lease Time = 9763 days, 17 hours, 7 minutes, 12 seconds

which is where I got the truncated value I noted above from.
Unlock this solution and get a sample of our free trial.
(No credit card required)
Mike RolfsCommercial Systems Architect


Interesting what you get when people decide to ignore established standards...
Mike RolfsCommercial Systems Architect


I'm going to experiment around with this but I'm willing to bet you're right on the money.  Probably dhcpd accepts a higher number, but the embedded dhcp client in the firmware is still back to the 1000 days -1 second standard and that's likely causing the problem.  Thanks much!

130+ years = 2^32 secs
The RFC does not mention a limit... it seems to me its upon the DHCP server capabilies dealing with longer or shorter values when it comes to healthy mantain the IP pool...

"RFC 2132        DHCP Options and BOOTP Vendor Extensions      March 1997"

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.

   The code for this option is 51, and its length is 4.
My original info came from configuring many disparate routers and not being able to add more than 999 days. The hardware may actually have supported it but the software never allowed up further than that so I thought it was just a standard (since so many vendors stick to that, not the actual standard). Good to know what the actual standard is though.

10k days should actually work if it lets you set it that high. @MRolfs: Give some lower values a test and draw your conclusions from that. It may just be one or two clients that don't like it. It's possible that the hardware supports seconds up to 32-bit unsigned values but the software doesn't, as you mentioned though it truncates well outside of any 8/16/32 value range??

you where talking about "1000 days minus 1 sec" as the limit and now you say " I thought it was just a standard"  
now you fearlessly say that the software "doesn't support it"...

when we talk about RFC is good to read them....
evilrixSenior Software Engineer (Avast)

>> when we talk about RFC is good to read them....
An RFC is not a standard, it is a proposal for a standard. A standard has to be ratified for it to be a standard.

When it comes to Internet, we have not ISO, not ANSI, not IEEE; the IETF adopts some of the RFCs as official Internet Standards.The whole community and vendors take them as the reference for developing hardware and software.

The RFC 2132  is an IETF accepted RFC as you can se here  http://www.ietf.org/rfc/rfc2132.txt
then I can say The RFC 2132 it a standard and "when we talk about RFC is good to read them"

"Our own standard says..."
if it is your "own" it is not a standard...
1. You are reading into this too much because you are going on about the RFC standard that I never once referred to. When you say "when we talk about RFC is good to read them" it's all well and good except I wasn't talking about the RFC, I was talking about software limitations in terms of setting the value for lease time which I've come across many times.

2. I already corrected myself saying that my information was incorrect and is based on my own experience when dealing with long lease times. When I refer to "our standard" it's just something that's been established within the company or by myself that hasn't presented any issues so I stick to it. None-the-less, it's still a standard to someone.

3. I answered this question not because I know what the standard is, which is irrelevant to resolving the issue, but rather that it stuck out because I've never had an issue like this using much lower values and was concerned about MRolfs ability to set the number so high.

4. Standard or not, some hardware and software vendors do not comply with them. Internet Explorer is good example, you can't assume everyone is using a written standard as they may just have stuck to something that works for them, probably their "own" standard.

5. From my experience setting the value to no more than 999 days means you don't run into trouble, I was just trying to help MRolfs out with some suggestions and never fearlessly claimed to know anything. I even double checked what other people were saying because which is why I corrected myself but still stuck to my suggestion.

The comments that have followed have added no value to the discussion other than to point out that people can be misinterpreted and so can the RFC. MRolfs never asked for the "standard", he asked for "supported" which could mean anything. From my decade of dabbling with networks, 999 days for a lease seems to be widely supported albeit in no way a limitation or standard across the board. If this helped MRolfs solve his problem then it served it's purpose. If hardware/software developers limit the input of certain settings maybe they know something we don't...

1) the asked value derives from a standard even if you never quoted/read it.
2) your personal experience cannot ever been called "your own standard" as you did.

I don't know, probably you have something to learn out of this thread and next time you'll get the standard figures before posting your personal experience as the ultimate Internet law.
Once again, no value added to the discussion. MRolfs never asked for the standard, merely what's supported. Standards are often not followed so experience counts for more in my opinion. You're misinterpreting "our standard" as some kind of international law but in fact it's just a rule of thumb. That's why I never said "the standard" or something similar where in fact would give you credit.

I never said my experience was my own standard either, this is something that hardware vendors seem to stick to and even if software or routers supported higher, keeping to the lowest common denominator can keep you out of trouble. This is my "own standard" that I've documented and stuck to when setting up.

I did learn something from this thread, what the real RFC standard is as you quoted, which still doesn't help explain or resolve the issue at hand. You should learn from this that not even a standard is a hard and fast rule. I posted my experience to try and assist someone with a problem they were experiencing while you are in fact "fearlessly" stating your claims on the subject and the reasons for my answer. We are all participating to help each other and learn a few things ourselves not make bold claims or establish anything as "law", if you have a different agenda please take it elsewhere.
Unlock the solution to this question.
Thanks for using Experts Exchange.

Please provide your email to receive a sample view!

*This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.


Please enter a first name

Please enter a last name

8+ characters (letters, numbers, and a symbol)

By clicking, you agree to the Terms of Use and Privacy Policy.