Re: [dhcwg] Re: [ntpwg] Network Time Protocol (NTP) Options for DHCPv6

On Mon, Nov 19, 2007 at 01:05:11PM -0500, Danny Mayer wrote:
> a) Send these options unsolicited when it is requested to send an IP
> address to be used by the client?;
> b) Only send these options when requested by the client?;
> c) something else?

In general, and in context of this discussion, it is most important to
understand that DHCP servers (both v4 and v6) provide exactly those
options the DHCP clients request (via the DHCPv4 Parameter Request
List option, or the DHCPv6 Option Request Option).

A server might be configured to send additional options explicitly,
but doing so is no guarantee that the client will use the options.

The request lists are essentially an advertisement of what options
the client is willing to digest, and the order of priority it places
in them (in the event of packet space exhaustion, earlier options
will preclude later).

In DHCPv4, there are approximately 312 bytes available for DHCP
options, considering realistic operational deployment.  Less if you
don't want to bear support costs.  Some of those must be textual
(domain name, search path), but the majority have been and continue
to be carried in binary IP address forms.

In DHCPv6, there are potentially 64k bytes available for DHCP options,
with some handwaving for the (extremely brief) headers, recursive
headers due to DHCPv6 relay paths, and the various options that are
'mandatory' for normal operation...you are still left with a "large"
potential for options payload.  This is much more than four times the
available packet space, considering IPv6 addresses are "only" four
times larger than IPv4 addresses.

> When does the client send/receive the request?

It depends, and in either protocol is at the discretion of the client.

> a) Upon boot

Obviously the client will obtain an address upon booting.  Upon
rebooting...

In DHCPv4, we have the INIT-REBOOT state, so the client sends a
request that effectively extends its lease, and new configuration
state is loaded along with that.

In DHCPv6, we have the Confirm message, which allows a client to
continue to use its previous binding (or not, sending it back to
the beginning), and no new configuration state is loaded.

Any change in configuration (such as its absence) is detected, and
new values (or lack thereof) are adopted.

> b) upon lease renew

Yes.  New values from the network always supplant older ones.  How
to integrate this onto e.g. a Unix-like system is unclear, and
realistically many configuration values are "sticky" with running
applications (such as /etc/resolv.conf contents that are loaded
once when firefox starts and never again).

So all of this is academic if your ntpd runs once at startup on
a laptop that "sleeps" rather than being shutdown, and never
reloads its configuratoin file with fresh values from the DHCP
client.

Ostensibly you would want to have some closer integration with the
DHCP client to receive these configuration events in near real time.

> c) some other time?

Both DHCP protocols include a mechanism to reconfigure/force the
renewal of configuration information causing a client to enter into
the renewal event at any time, but the DHCPv4 method is not well
deployed, and the DHCPv6 method is not clearly well used (to me, maybe
someone else will comment).

I don't know if you will find this document helpful;

http://www.ietf.org/internet-drafts/draft-ietf-dhc-option-guidelines-00.txt

But I (rather egotistically) think it is a good read for background
information for any authors looking to write new DHCP options.

It expires Jan. 2 2008.  I should probably rev it soon, but doubt I
will have the time available until approx Jan 15...

-- 
Ash bugud-gul durbatuluk agh burzum-ishi krimpatul.
Why settle for the lesser evil?	 https://secure.isc.org/store/t-shirt/
-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		     you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins