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

[Brian Utterback]

I think we are all arguing at cross purposes. We have people reasoning 
about what will be,
some about what is, some about what could be and some about what should be.

The question on the floor is very simple. Is it sufficient for the DHCP 
option to follow convention
and serve an IP address or is it necessary to instead serve a string 
that represents a FQDN that should
be used for a DNS lookup and periodically re-resolved.

It has been suggested that if you are going to serve up a string, a URL 
that points to a configuration
file to be used would offer the most general mechanism for 
configuration, but this is highly problematic
since there is no implementation agnostic configuration language it it 
is way, way out of scope to think
about making one. This this idea is rejected.

So, the advantage of serving a FQDN is that the client is forced to 
resolve the host and get the IP
addresses from DNS and removal of an IP from the DNS name system will 
cause all the traffic
to that IP to eventually disappear.

The disadvantage is that it forces client to run and configure a 
resolver and potentially adds a lot
of overhead to the DHCP protocol.

Ted maintains that as a practical matter, the same effect is achieved 
with the IP address.
We can specify in the DHCP protocol that when the DHCP lease is renewed, 
that the
NTP client must accept a new IP address and if different from the old 
one, cease using
the old one.  We can specify that the DHCP client may only serve site 
local addresses
unless the IP addresses served are themselves the result of periodic DNS 
lookup if
FQDN's. We can specify that the FQDN used may not be hard coded and must be
configurable.

Not all of these "can"s and "must"s may be necessary or perhaps they are not
sufficient. If we decide on using the IP address, then we must also 
decide on the
musts and shoulds and mays.

Ted Lemon wrote:
> On Nov 25, 2007, at 6:09 PM, Mark Andrews wrote:
>> I would think that this should be a push operation from the dhcp
>> client rather than a pull operation.
>
> Sure, but it amounts to the same thing.   This is trivial to do with 
> the ISC DHCP client (which I presume is the one you use).   It's also 
> trivial to do on Linux with dbus.   Mac OS X and Windows handle it 
> differently still, but they already have mechanisms in place for doing 
> this.   So the point is that if the will exists to make it happen, 
> it's trivial to make it happen.
>