Subject: DHCPRELEASE policy (specifically WRT OpenTransport)...

From: Ted Lemon <[email-masked]>
Date: Sat, 20 Mar 1999 17:48:51 -0500 (EST)

At the IETF WG meeting on Thursday, somebody from Apple whose name I
have of course spaced got up and talked a bit about the OpenTransport
DHCPRELEASE policy, and said that in the next release of
OpenTransport, the user would be able to configure the policy that the
OT client would use when powering down - whether it would send a
DHCPRELEASE and then power back on into the INIT state, or not send a
DHCPRELEASE and, if possible, power back on into the INIT-REBOOT
state.

It occurs to me that this is something that a site administrator might
want to control as a global policy.   The OpenTransport client also
has a setting to decide whether or not it should get a lease when it
first needs an IP address, or always maintain a lease.   Again, this
is something that some sites might want to administer centrally.

I'd like to suggest that we create an option that controls these two
configuration settings, and possibly others if people can think of
them.  Essentially, when the OT client (and hopefully other clients)
acquires a lease, it sets these two flags based on an option sent in
the DHCPACK packet.  The send-dhcprelease flag would take effect on
the current lease, and the relinquish-address flag would as well.  The
relinquish-address flag would remain in effect until a DHCPACK was
received that had a different setting.

Naturally, it would also be useful to hack the UI to allow the user to
override these settings (maybe with a "allow DHCP server to modify
these settings" toggle), but I think that exposing this functionality
to the DHCP server administrator would be a big win - otherwise,
people who don't know any better are likely to wind up with the wrong
policy configured in their client.

If this seems agreeable, I'd like to whip up a draft and get it
rolling quickly, so that the time during which reconfiguring clients
with respect to these two settings involves having somebody touch the
client machine is minimized.

So what do folks at Apple and Microsoft (as well as other WG
participants) think of this?  If the answer is "sounds good, but don't
have time to push the draft," I still want to hear from you.

Thanks!

			       _MelloN_

---

From: "HIBBS, BARR (PB)" <[email-masked]>
Date: Mon, 22 Mar 1999 15:15:49 -0500 (EST)

Ted, et al.,

while I haven't thought through all of the implications of doing this, my
first reaction is to support the concept.  This, of course, presupposes that
client stack vendors would incorporate support for such an option.

In our recent experience with renumbering and conversion of formerly static
clients to dynamic addressing, we've occasionally been frustrated to find
that on the night of the conversion, despite our most careful planning, we
might be 3-7 addresses short of what we need to convert an entire office,
meaning middle-of-the-night conference calls, database reconfiguration, and
two or three people who don't get to sleep because they must baby-sit the
troubled clients.  This has a cascading effect on the next night's
conversion, so even a small problem of insufficient addresses can be a big
deal for us.

The use of the proposed option won't, of course, completely fix our
conversion problem, but combined with the other things we already do should
actually improve our particular situation.

--Barr

> ----------
> From: 	Ted Lemon[SMTP:[email-masked]]
> Sent: 	Saturday, March 20, 1999 2:51 PM
> To: 	Multiple recipients of list
> Subject: 	DHCPRELEASE policy (specifically WRT OpenTransport)...
> 
> 
[ ... stuff deleted ... ]

> received that had a different setting.
[ ... more stuff deleted ... ]

---

From: "Robert Breen" <[email-masked]>
Date: Mon, 22 Mar 1999 20:16:53 -0500 (EST)

I was at that session.  Ted, I totally agree with your thoughts.  I was the
person who indicated we ran over 120,000 DHCP clients on our network (I
wish I could publish the name of the company, but they lawyers go crazy)
and I had thought about way in which our Windows 95, Windows NT and various
flavors of Unix clients handled this same situation.  For instance, the
pre-winsock 2.0 Windows 95 clients do not perform a release when shutting
down, but the post-winsock 2.0 Windows 95 clients do.  For some subnets
this makes sense.  Our remote subnets were we know we have a lot of mobile
users (read laptops...) could be configured to release their IP address
upon shutdown, but it doesn't make sense on our subnets composed mostly of
desktop machines that seldomly move.  The organization I work for is lucky,
we can say with some certainty which subnets fall in which categories.  

	It might also be nice, for instance, to configure a subnet that was
particularly tight on IP addresses to have clients release their IP address
upon shutdown (in addition to shorter lease times), so that address could
be thrown back in the available pool quicker than waiting for lease times
to expire.  I see lots of uses for this option.

I'm not up on how to write drafts, but I'd be happy to help in any way
possible.

Bob Breen
[email-masked]

----------
> From: Ted Lemon <[email-masked]>
> To: Multiple recipients of list <[email-masked]>
> Date: Saturday, March 20, 1999 4:54 PM
> 
>

---

From: [email-masked]
Date: Tue, 23 Mar 1999 12:38:29 -0500 (EST)

Ted

 This is a good idea. OS/2 Clients have been doing this for a few years via
a client policy that the user or a site administrator( via a common client
config files distribution)  could  choose. It would be great if the DHCP
server served this policy.

The only thing to watch out for is that a server should not expect to have
a perfect cleanup solution since the DHCPRELEASE packet may be dropped or
the client may not be able to send it out in time due to the shutdown
process being initiated.

regards,

Pratik Gupta
[email-masked]

Ted Lemon <[email-masked]> on 03/20/99 05:51:38 PM

Please respond to [email-masked]

To:   Multiple recipients of list <[email-masked]>
cc:    (bcc: Pratik Gupta/Raleigh/IBM)
Subject:  DHCPRELEASE policy (specifically WRT OpenTransport)...

Thanks!

                      _MelloN_

---

From: [email-masked] (by way of Ralph Droms)
Date: Tue, 23 Mar 1999 22:53:19 -0500 (EST)

message sent to [email-masked] by [email-masked] follows.
-----------------------------------------------------------------------
> them.

	Excellent idea.  The first of these (``send-dhcprelease'') is
definitely something that our IR folks could have used.  The fact that
we don't release addresses when shutting down was one of the first things
they complained about (and set out to work around) when converting to
use DHCP for a hotelling system they were deploying.

			Carl