Subject: Re: DHCP server/Client behavior when options change while

From: Rob Stevens <[email-masked]>
Date: Fri, 19 Nov 1999 03:23:42 -0500 (EST)

At 07:55 PM 11/18/99 -0500, Peter Memishian wrote:

>
>  > 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?
>
>for portability, i'd say so.
>
>--

I think that is too sweeping, and that it is entirely
a matter for the client device. For dumb client
devices, which only know how to do "one thing"
it might well make sense to check parameters
which may have changed....but

.at the other end of the scale, unix workstations
are unlikely to be able to make use of much
of the information. reconfiguring DNS is not
going to change application which have already
initialised. Changing IP masks is going to
breka existing connections.. And how does
the DHCP client know which apps are interested
in which parameters..

basically, I think it is useless for desk top
computers to bother with changes to parameters
unless they reboot.

I guess that means that I wouldn't agree with Ted's
comment either.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 19 Nov 1999 09:53:35 -0500 (EST)

I don't want to create needless controversy, but I'd like to point out
a couple of things:

> reconfiguring DNS is not going to change application which have
> already initialised.

This depends on the application, and the resolver.   The BIND 8
resolver does indeed appear cache the contents of the resolv.conf
file, but this is only a problem for long-running applications -
anything that runs for short periods of time isn't going to have a
problem with that.   And I'd argue that it would probably be better if
the resolver statted the file once in a while to see if it's changed.
I'm not sure what the BIND 9 resolver does.   Personally, the idea
that you have to restart applications to see a new resolv.conf file
seems like a bug to me.

> Changing IP masks is going to breka existing connections..

I can't speak for all unix implementations here, but certainly
implementations that are based on the 4.4BSD stack do not have this
problem - if your IP address stays the same and your netmask changes,
connections will continue.  In fact, you can completely lose your IP
address, and as long as you get the same one back before the next time
a particular TCB is used, the connection will not be broken.

The real problem with the 4.4BSD stack is route caching - TCBs have
cached routes, so if the routing changes in a way that matters to a
particular connection, the connection doesn't switch to the new
route.   IMHO, though, this is also a bug.

> And how does the DHCP client know which apps are interested in which
> parameters..

It shouldn't matter to the DHCP client - the client should just do
what the server tells it, and let the applications decide whether or
not they care.

Basically, what I'm saying here is that the DHCP client should *try*
to do the right thing, and if applications do the wrong thing, that's
a problem the authors of the applications should solve.   In the
NetBSD community, we certainly have the intention of getting to the
point where the kernel and applications are maximally responsive to 
changes like this.

That's not to say your take on things is wrong for all situations, but
I think that in the cases where what you have said is correct, the
host is probably not using DHCP anyway.  For those sites where it is
considered preferable to have even Unix servers use DHCP to get their
IP addresses, I think what you've said is probably true, and a good
Unix DHCP client should probably have a switch that lets you control
what it does when parameters change.

The ISC DHCP client actually lets you completely override what the
server sends if you want, and also lets you override what the server
has sent in a conditional way, based on what the server sent (e.g.,
you can say "use 127.0.0.1 for the name server unless the domain-name
option is "firewalled.com", because I happen to know that
firewalled.com has a firewall that blocks DNS, so my local name server
won't work - only when I'm at firewalled.com, use the name server list
the DHCP server supplies).

			       _MelloN_

---

From: "Eric A. Hall" <[email-masked]>
Date: Fri, 19 Nov 1999 15:39:17 -0500 (EST)

> reconfiguring DNS is not going to change application which have

Do the apps do their own DNS lookups or do they call the system
resolver? If the resolver is able to recognize the changes then the apps
that call it won't care.

> Changing IP masks is going to breka existing connections..

How so? IP only cares about the mask for delivery purposes. TCP and UDP
don't care about the mask, and neither should any of the applications.
Changing the IP address would break the connections, but changing the
mask certainly shouldn't have any more of an effect on those layers than
changing the default route (ie, it should have no effect at all).

> And how does the DHCP client know which apps are interested
> in which parameters..

What parameters should application-layer protocols be interested in? I
can see why there'd be some interest in changing "default home page" or
"default mail server" but I don't know of many applications that use
those paramters.

> basically, I think it is useless for desk top computers to bother
> with changes to parameters unless they reboot.

I'd have to disagree with you 100% on this.

-- 
Eric A. Hall                                            [email-masked]
+1-650-685-0557                                    http://www.ehsco.com

---

From: Nathan Lane <[email-masked]>
Date: Fri, 19 Nov 1999 16:30:55 -0500 (EST)

> -----Original Message-----
> From:	Eric A. Hall [SMTP:[email-masked]]
> Sent:	Friday, November 19, 1999 2:42 PM
> To:	Multiple recipients of list
> Subject:	Re: DHCP server/Client behavior when options change while
> 
> 
	[Nathan Lane]  Most apps I know of here use gethostbyname() whenever they need to resolve a name, so they will notice changes immediately.  Even IE4 and Netscape call gethostbyname about once every 15 minutes (they cache in the interim).

> I'd have to disagree with you 100% on this.
	[Nathan Lane]  I agree with the disagreement.  There are many times when a parameter would need to change!  We are currently removing many, many WINS servers from our network and workstations need to be told of the change.  Rebooting is not an option.  I also rolled new DNS servers to some 20K clients transparently because the clients picked up the change upon renew (NT SP3 and later).

	We've also designed in a short renew interval (but a relatively longer lease time) specifically so we can roll mass parameter changes under emergency server outage conditions.

	-Nathan Lane
	Wal-Mart Stores, Inc.
	(501) 277-5786

---

From: Rob Stevens <[email-masked]>
Date: Sat, 20 Nov 1999 19:35:45 -0500 (EST)

At 04:31 PM 11/19/99 -0500, Nathan Lane wrote:

>         [Nathan Lane]  Most apps I know of here use gethostbyname() 
> whenever they need to resolve a name, so they will notice changes 
> immediately.  Even IE4 and Netscape call gethostbyname about once every 
> 15 minutes (they cache in the interim).

Calling gethostbyname() is not going to change
the DNS server to which the packet is sent (on most platforms): that
was established implicitly by the first call or
an explicitly via res_init().

>         [Nathan Lane]  I agree with the disagreement.  There are many 
> times when a parameter would need to change!  We are currently removing 
> many, many WINS servers from our network and workstations need to be told 
> of the change.  Rebooting is not an option.  I also rolled new DNS 
> servers to some 20K clients transparently because the clients picked up 
> the change upon renew (NT SP3 and later).
>
>         We've also designed in a short renew interval (but a relatively 
> longer lease time) specifically so we can roll mass parameter changes 
> under emergency server outage conditions.
>

And I disagree with the agreement with the...whoops stack overflow.

I don't doubt that there are may be times when a parameter would need
to change. Nor that Walmart is in the happy position of having all the
clients and their apps in their stores respond (nee, instantaneously)
to the changes which just came down the pike from DHCP.

But other platforms and applications will not.
There is a whole universe of applications out there, and
the vast bulk don't know about the wonderful world
that DHCP made possible, in which any parameter
known to DHCP and used by these apps can change
asynchronously.

Therefore, I think to dismiss all these apps as being,
somehow, broken, is extreme. And  what is more
to the point, that it is misleading to convey the
impression that ISPs, sysadmins, whomever,
can get their all the apps throughout their domain
to respond to option changes in a time predictable
manner by DHCP alone. Some applications are just
going to go on using whatever they started up with,
and nothing DHCP says is going to change that.

I am quite happy for servers to send these parameters
whenever they want; even willing to accept that they
be sent when not requested (hasn't anyone run out of space
yet?). That is not my issue (at least, not now).

Rob

---

From: Ted Lemon <[email-masked]>
Date: Sun, 21 Nov 1999 13:20:15 -0500 (EST)

> somehow, broken, is extreme.

I would say "out of date," not broken.  And what will encourage them
to be brought up to date?  DHCP Clients that are not (and here I think
the word is used correctly) broken, in the sense of ignoring updates
from the servers.

			       _MelloN_

---

From: Rob Stevens <[email-masked]>
Date: Mon, 22 Nov 1999 13:15:45 -0500 (EST)

>the word is used correctly) broken, in the sense of ignoring updates

Fair enough.
I was interested in the comments you made about routing tables.
I am wondering what all the ramifications about changing masks
are on all the diverse platforms out there.

It's true that I can't immediately see that any problems would
occur, but my gut feeling is that there must be some subtleties
with this. Has anyone any deep insights on other platforms?

Rob.

---

From: Peter Memishian <[email-masked]>
Date: Mon, 22 Nov 1999 21:38:14 -0500 (EST)

> with this. Has anyone any deep insights on other platforms?

well, i don't have any deep insights, but it seems to me that changing
the netmask on an interface is going to cause the same sorts of
problems that changing the ip address will; any applications that have
previously used the netmask to figure out the network address or
broadcast address are going to be confused at best.

of course, the real "problem" here is that the network topology has
changed; the fact that the dhcp client is providing the updated
netmask is just a side effect of this topology change.  so having the
client not provide the updated mask is worse; at least by providing
the updated mask, dhcp-aware applications have a chance of recovering.

-- 
meem

---

From: Ted Lemon <[email-masked]>
Date: Mon, 22 Nov 1999 22:52:15 -0500 (EST)

> any applications that have

Other than DHCP servers, I can't think of any applications that would
need to do this...

			       _MelloN_