Subject: RE: DHCP server/Client behavior when options change while lease i

From: "HIBBS, BARR (PB)" <[email-masked]>
Date: Thu, 18 Nov 1999 19:54:50 -0500 (EST)

> From: 	Edward Mascarenhas[SMTP:[email-masked]]
> Sent: 	Thursday, November 18, 1999 4:08 PM
> 
> If a client has a valid lease of an IP address but some of 
> the options change (the subnet mask, for example), what 
> should the server do when the client attempts to renew the 
> lease. Should the server renew the lease returning 
> the options requested (some of which may have changed) or 
> cause the client to reinitialize.
> 
--using DHCPv4, the server has no way to force a client to reinitialize, the
server must wait until the client initiates a protocol exchange.  At that
time, the server's behavior should be a local policy decision, it is not
specified in the RFC.  It is quite common for a server to supply the most
current configuration data for all subsequent requests, but there is nothing
to prevent an implementation from caching the data supplied previously, and
simply replaying it.

> Should the client check the set of options received 
> each time a lease is renewed and take appropriate action if 
> the some of the options have changed? 
> 
Again, that is an implementation decision.  Consider the things most likely
to change in practice:  router addresses, DNS server addresses, and subnet
masks are changed by an administrator from time to time.  Since it is
possible for option values to change, a competent client implementation
probably anticipate this and recognize changes, taking an appropriate
action.  On the other hand, a client could choose not to request options
after receiving an IP address lease, deferring changes until the next
discover/offer cycle begins.

--Barr

---

From: Ted Lemon <[email-masked]>
Date: Thu, 18 Nov 1999 21:11:14 -0500 (EST)

> On the other hand, a client could choose not to request options

Of course, such a client would probably find itself on the network
administration's Do Not Buy In the Future list very quickly.

			       _MelloN_