Subject: DHCP Lease Time Option conclusion

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

I think that the successor to RFC 2131 needs to be explicit about how the 
server should interpret the presense or absense of lease time options in 
packets from clients:

Either:

(a) Any DHCPDISCOVER or DHCPREQUEST without a lease time option is 
treated as if it contained a request for the server's default lease. In 
other words, *all* DHCPDISCOVER and DHCPREQUEST packets cause the 
creation or sensible renewal of a lease. The server *never* simply offers 
the dregs of a previous lease. If the server is configured to offer 
24-hour leases, then *all* DISCOVERS and REQUESTS that don't explicitly 
request something different get a lease that lasts for 24-hours beginning 
now.

Or, if the ability to do an "informational query" without actually 
extending the lease is considered to be important, then:

(b) All normal DHCPDISCOVER or DHCPREQUEST packets that are not 
"informational queries" MUST include a lease request option. If the 
client has no particular care what the lease time should be, then the 
client needs a way to communicate that. We can specify that a very large 
lease request should be capped to the server's configured maximum, or 
that a request for a lease of zero means a request for the default lease, 
or that a request for a lease of 0xFFFFFFFE (one less than 'infinity') 
means a request for the default lease.

In either case, a client may still request a specific lease time, which 
the server will treat as a hint of what the client would like to see in 
the OFFER or ACK packet. Macs will probably never do this, but I imagine 
that some special purpose devices may know that they only want an address 
for a few seconds.

Any comments?

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:48:42 -0500 (EST)

Stuart--

I sympathize with your problem after reading your prior note, but I don't
quite agree with your suggested changes.  There are too many existing server
implementations that pick one or the other of the choices you suggest.  I am
of the opinion that RFC editors cannot possibly know all the circumstances
where a protocol will be used, so trying to legislate one choice over the
other is not likely to succeed.

I'm more inclined to wording such as:

"...DHCPDISCOVER or DHCPREQUEST messages MAY be sent by a client without a
requested lease time option.  If, as specified by local configuration, the
server chooses to reply to these messages it MUST select the
locally-configured default lease time as the lease duration.  Requests for a
zero lease time MUST be construed by the server as a request for the
locally-configured minimum lease time, while requests for a "near-infinite"
lease time (0xFFFFFFFE) MUST be construed by the server as a request for the
locally-configured maximum lease time. Further, even if the client does not
include the lease time option in the parameter request list with a
DHCPREQUEST or DHCPDISCOVER message, the server MUST return that option to
the client in the DHCPACK or DHCPOFFER message."

..and...

"...it is a local administrative policy decision as to whether subsequent
DHCPDISCOVER and/or DHCPREQUEST messages from a client with an existing,
valid lease are to be interpreted as (1) a request for an extension equal to
the original duration of the lease, or (2) a notification that the client is
continuing to use that lease."

I know this is not what you want, but I don't want leases to just be
automatically extended forever!  By changing the wording so that the
decision is removed from the server implementor and give to the server
administrator, I think we both can be satisfied.

You still, however, have the problem with leases possibly expiring during
streaming video feeds.  But at least then you can point to the user and say,
"This is under your control."

--Barr