Re: DHCPINFORM _vs_ INIT-REBOOT

[Charles Ragan <[e-mail]>]

Hello Don,

Actually, I can think of a couple of reasons to at least leave the
automatic DHCPDISCOVER as an option.  Although I'm not  an Apple user ;-( -
it sure would be nice to have the option for mobile users in the win95
stack.  (i.e. I have one dhcp lan connection @ work, and another at my
house....I have no control over the lease periods @ work, so I have to run
winipcfg and release the address, and restart win95 to attain a new one at
home area network (han) ;-)

Just thinking out loud.

Charles

At 06:18 PM 10/17/96 -0400, Don Coolidge wrote:
>I'm responsible for the DHCP client software in Apple's MacOS Open
>Transport (OT) networking architecture. I've been bringing it up to a more
>current state with respect to RFCs and drafts, and I have a few questions
>on which I need advice.
>
>The current OT DHCP client design, while (as far as I can tell) fairly
>compliant with existing RFCs, nevertheless differs in many ways from most
>other DHCP client implementations. For instance, in order to avoid making
>assumptions about network management, it was implemented so as to be
>constantly naive: it comes up each time totally without state, starting
>with a DHCPDISCOVER message; it accepts the first DHCPOFFER it receives,
>regardless of the configuration parameters; and it sends a DHCPRELEASE
>whenever the stack is torn down. This is a bit more complicated than on
>many other vendors' boxes because the networking stack is torn down and
>replumbed not only across reboots; the stack is also torn down if no client
>streams have been open for two minutes' time, and it is re-plumbed when the
>next stream is opened (picture a Mac runing only Eudora, polling for email
>every five minutes).
>
>This is all kosher DHCP client behavior (why, after all, should the Mac
>care about its IP address? -- though a network administrator certainly
>may), and yet since Apple (finally!) began giving me time to participate in
>the IETF, I've found that in each of these aspects it differs from almost
>every other industry implementation of a DHCP client.
>
>So, among the changes I'm working on for the next major release of Open
>Transport (1.5) are the following:
>
>1) Add support for the Client ID option.
>
>2) Don't send a DHCPRELEASE unless the lease times out without being
>renewed or rebound, or the user explicitly releases the lease.
>
>3) Maintain state across reboots and/or protocol stack teardown/replumbing.
>
>4) Provide a programmatic interface that will allow users/applications to
>retrieve all of the parameters and options configured by the DHCP server,
>even those options that are not themselves used by Open Transport (e.g.
>various flavors of server addresses).
>
>The problem comes with number 3). When configuring, should I go into
>INIT-REBOOT state if the previous lease is unexpired, or should I issue a
>DHCPINFORM message? I can see advantages and disadvantages of each.
>
>First, DHCPINFORM is not yet part of an RFC; it's still in draft. Because
>of that, it is probably supported by fewer server implementations.
>Nevertheless, it has the advantage of allowing a client to reconfigure even
>if the server is down.
>
>Second, INIT-REBOOT state is an approved RFC practice for DHCP clients. It
>is undoubtedly supported by many more DHCP servers than support DHCPINFORM.
>However, it provides no way for a client to successfully configure if all
>relevant servers are down and nobody answers.
>
>My incliniation is to support DHCPINFORM rather than INIT-REBOOT - I'd
>rather be ahead of the standards curve than continually behind. In
>addition, given that most clients maintain state across reboots, including
>the time of their lease's expiration, DHCPINFORM seems the more correct
>thing to do. But it's not yet a standard.
>
>So, the questions:
>
>a) How long is it anticipated it will take for DHCPINFORM to make it to RFC
>status?
>
>b) Have any client implementors Out There run into server incompatibility
>situations with either of these choices?
>
>c) Which should I implement? :^)
>
>d) Last, as a philosophical matter, why was DHCPINFORM invented, when
>simply changing the specified behavior of the INIT-REBOOT state could have
>achieved the same end? Just curious...
>
>Thanks in advance for your comments. And if these questions have been
>previously dealt with on this mailing list, could somebody point me at the
>archive?
>
>See you in San Jose...
>
>-- Don Coolidge
>[e-mail]
>
>
>
>
[e-mail]
Sr. Network Systems Consultant
International Network Services
CCIE, CBE, MCSE, MCNE