Subject: DHCP Lease Time Option continued

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

[Continued from "DHCP Lease Time Option woes". You don't need to read 
this unless you are really interested in just how much grief I went 
through trying to get the Mac DHCP client to work with all servers.]

I even tried some more subtle workarounds, without success. What if I 
omit the lease time option in the DISCOVER packet, wait and see what 
lease time the server offers, and then remember that lease time and 
include it in every subsequent DHCPREQUEST?

This makes the Japanese ISDN modems happy, but it doesn't work for other 
reasons:

1. It removes the ability for the server admin to change the lease time. 
Suppose the DHCP server is set to a 30-minute lease. The server admin 
later realizes that this was a mistake, and changes it to 24 hours. 
Unfortunately, all the Macs will have remembered the initial 30-minute 
offer and will continue to request 30-minute leases forever. Even 
rebooting them would not fix the lease lifetime because INIT-REBOOT 
processing would recover the old lease parameters and skip the 
DHCDISCOVER packet that might have allowed them to learn the new lease 
time.

2. Even more subtle, consider this case:

The server admin has configured a 24-hour lease duration.

On Monday, Joe comes to work at 9:00am, plugs in his laptop computer and 
turns it on. It gets a 24-hour lease on an address. By 5:00pm the first 
renew hasn't happened yet. Joe takes his laptop computer home, and plugs 
it in to his home Ethernet. His REQUEST generated in INIT-REBOOT state is 
NAKed because he's on a new subnet now, so his laptop discards the old 
lease information, and gets a new lease from the cable modem, with a 
one-hour duration. At 10:00pm Joe shuts the laptop down and goes to bed.

On Tuesday, Joe comes to work a minute late at 9:01am. His laptop's 
remembered lease information from the cable modem last night has expired, 
so in the morning it begins back in INIT state. It sends a DISCOVER; the 
server has no record of an active lease for this client ID, so it issues 
a new lease, duration 24-hours, expiring tomorrow at 9:01am. So far, so 
good. Joe takes his laptop computer home at 5:00pm, and plugs it in to 
his home Ethernet again, like Monday night.

On Wednesday, Joe gets to work on time. He arrives at 9:00am, and his 
laptop sends a DISCOVER. As explained, the DISCOVER has no lease time 
option. The server DOES have a record of an active lease for this client 
ID, expiring in one minute's time at 9:01am. The RFC 2131 paragraph 
quoted above is very clear about this: "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." That means that the remaining time 
on this lease is 60 seconds, which the server puts in its OFFER packet, 
which means that the Mac remembers it and then proceeds to renew its 
lease every 30 seconds for the rest of the day.

So, my workaround of "learn the lease time and remember it" doesn't work 
either.

What are we to do?

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

---

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

> include it in every subsequent DHCPREQUEST?

This is actually forbidden - the client is supposed to send the same
options in the DHCPREQUEST as in the DHCPDISCOVER.

			       _MelloN_