Subject: DHCP Lease Time Option woes

From: Stuart Cheshire <[email-masked]>
Date: Fri, 17 Dec 1999 19:30:46 -0500 (EST)

At the DC meeting, Ted Lemon volunteered to collect comments for 
revisions to RFC 2131 as it moves to full standard. Here is one thing I 
think could benefit from some clarification:

The use of the Requested Lease Time Option (51) in DHCP client packets is 
not as obvious as it might seem. There is the question of which packets 
it should appear in, and with what value in each case.

(Remember that I'm coming at this from an Apple perspective -- saying 
that your sysadmin configures it for you is not an acceptable answer for 
us. We want to ship PowerBooks that you can take anywhere in the world, 
and be able to plug them in and have them "just work". If you need a 
sysadmin to come and configure your Lease Time Option then he might as 
well manually configure your IP address too while he's there.)

Here are the five relevant packet types:

DISCOVER
REQUEST (responding to a DHCPOFFER)
REQUEST (when renewing)
REQUEST (when rebinding)
REQUEST (when rebooting)

For each one, I need to work out whether it should include a Lease Time 
Option, and if so, with what value.

Before you assume that it is obvious, and I must be an idiot, bear with 
me. It is more tricky that it seems...

In Open Transport 2.0.x (Mac OS 8.6) OT never put a Lease Time Option in 
any packet. This caused problems with certain DHCP servers, which would 
treat each renewal request as merely being an enquiry of how much time 
remains on the current lease, not a request to actually extend said 
lease. As a result, if you have a one-hour lease, then you renew after 30 
minutes, then after 15 minutes, then after 7.5 minutes, and so on, 
successively halving until the lease expires. The author of the server in 
question quoted RFC 2131 to us:

>   o IF the client has not requested a specific lease in the
>     DHCPDISCOVER message and the client already has an assigned network
>     address, the server returns the lease expiration time previously
>     assigned to that address (note that the client must explicitly
>     request a specific lease to extend the expiration time on a
>     previously assigned address), ELSE

The server author was implementing this very literally. If the client 
already has an assigned network address, and is not explicitly requesting 
a specific lease to extend the expiration time, then the expiration time 
stays at it was.

Suitably chagrined, we modified our DHCP client in OT 2.5.x (Mac OS 9.0) 
to include a specific lease request in all packets. Since we don't 
actually care what the lease duration is, and the whole point of DHCP for 
us is that the parameters are controlled by the server administrator, we 
requested a lease time of "very large" (0x3FFFFFFF) in the assumption 
that the server would cap that large request to the locally configured 
maximum. I deliberately didn't use 0xFFFFFFFF because that is the 
"infinite" lease. I deliberately didn't use 0xFFFFFFFE because I didn't 
want to tickle signed/unsigned bugs in badly written servers. That made 
0x7FFFFFFF the sensible choice, which I halved once more to be extra 
extra cautious. So far, so good.

We went through alpha testing, beta testing, and final candidate testing, 
manufactured lots of Mac OS 9.0 CDs, and started selling them on the 
store shelves.

Then, our Japanese testing office reports that it doesn¹t work with 
Japanese ISDN modems. It turns out that Japanese ISDN modems NAK all 
REQUEST packets with lease request outside their allowed range. This put 
the Mac into an endless DISCOVER/OFFER/REQUEST/NAK deadlock with the 
server.

So, now what are we to do?

If you don¹t request a lease time, RFC 2131 says you don¹t get a lease 
extension.

If you request a very long lease time, then some DHCP servers (claiming 
to follow RFC 1541) NAK you.

If you request a short lease time, then you get a short lease time, 
effectively destroying the ability of a DHCP server administrator to make 
their own decision about what lease duration they wish to hand out to 
clients.

There is no clear answer. I even tried some more subtle workarounds, 
without success. (This is mail is starting to get long, so I'll continue 
with "Stuart's subtle workaround which doesn't work" in a subsequent 
email...)

Stuart Cheshire <[email-masked]>
 * <A HREF="http://ResComp.Stanford.EDU/~cheshire/">Web Page</A>
 * Wizard Without Portfolio, Apple Computer

---

From: "HIBBS, BARR (PB)" <[email-masked]>
Date: Fri, 17 Dec 1999 20:46:09 -0500 (EST)

> If you don¹t request a lease time, RFC 2131 says you don¹t get a lease 
..I'm sorry to seem contrary, but your interpretation is just not correct!
If your client already possesses a valid lease, why would you NOT send that
as the requested address in subsequent discover messages?  The solution to
your problem is that simple!

> This caused problems with certain DHCP servers, which would 
> successively halving until the lease expires.
> 
..and some servers continuously extend the lease on subsequent DHCPREQUEST
messages.  Why does the distinction matter to you?  Are you concerned about
processing time-critical data like streaming video?  I can see how a server
which does not extend a lease without receiving a DHCPDISCOVER message might
provoke a brief window when the client cannot receive and process data while
lease re-negotiation is occurring, but DHCPv4 will probably not address that
problem anytime soon.  Maybe you should advise users of time-critical
applications not to use dynamically assigned addresses if the duration of
such streams is likely to exceed any time remaining on a lease.

On the other hand, if you want to press for a fundamental change in the
protocol, that also is okay, just remember how long it may take for that to
occur.

> the Mac into an endless DISCOVER/OFFER/REQUEST/NAK deadlock with the
..the ISDN modem/DHCP server is broken:  as a manufacturer, you're in a
pickle!  This is an unsolvable problem -- for ANY value of lease time that
you pick, I assert that somewhere is a broken server implementation that
thinks it is (1) too long, or (2) too short, or (3) worst of all, if you do
find a value that works with 99.999999999% of all servers, the one for which
it does not work is certain to be the one chosen by your next corporate
purchaser of 100,000 Mac's.  Is a disclaimer acceptable? For example,
"...this version does not operate with the following vendors' DHCP
servers...."

However, I still say that the solution to your problem is simply to specify
the requested IP address when an existing lease is or has been valid....

--Barr

---

From: Ted Lemon <[email-masked]>
Date: Fri, 17 Dec 1999 22:22:27 -0500 (EST)

This is a good comment - thanks!

It also explains the message I got on the ISC DHCP mailing list about
OT clients with MacOS 9 not working with some DHCP servers - thanks
for that, too!

> to follow RFC 1541) NAK you.

A DHCP server that follows RFC1541 is not a DHCP server.   The fact
that your client doesn't work with it isn't terribly surprising.
Knowing your story, I think it would be good to phrase RFC2131ng in
such a way that a conforming implementation will not tickle this
interoperability problem, but OTOH what you were trying to do seems
sensible, so I'd say the right thing to do is actually to just respond
to the "bug" report about the ISDN modem with "that's a bug in the
ISDN modem."   Sigh.

> their own decision about what lease duration they wish to hand out to 

Here, I would follow what the Microsoft client does: the DHCP server
can return to you a lease longer than the one you requested, and the
Microsoft client will take whatever time comes back in the offer.
The ISC DHCP server can be configured with a min-lease-time parameter
that forces the client to take a longer lease.   This is useful
because the Microsoft client in fact requests a 24-hour lease.

In any case, may I take this opportunity to suggest that you pick up a
copy of the DHCP Handbook, which, while no substitute for the
standard, does actually talk about strategies for dealing with the
very conundrum of which you speak (it just suggests using the
min-lease-time, and completely misses the other points you raised, of
course, since apparently none of us had stumbled over this particular
permutation before).

			       _MelloN_