DHCPINFORM _vs_ INIT-REBOOT

[Don Coolidge <[e-mail]>]

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]