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

[Brian Utterback]

David L. Mills wrote:
>
> 1. Listen for broadcast/multicast on <address> and do/do not execute a 
> volley. I like the delay field to enable/disable that and have added 
> it to ntpd. In principle, the delay can be determined from the DHCP 
> packets themselves, a feature that might be added.
>
Right, I am fine with having the delay given and novolley specified. You 
can't determine the delay from the DHCP
packets because the DHCP server is likely not the NTP server. The DHCP 
server may be multiple hops away.

> 2. Troll the pool at one of the pool DNS names, us.pool.ntp.org, etc. 
> The client should be smart enough to use/not use iburst and preempt 
> flags.

This argues for having another possible field/format, where a string for 
lookup is given.
>
> 3. Specify a list of <addresses> to send to, each together with the 
> mode and  minpoll. I don't think maxpoll is useful either.

What other mode than active client do you envision?
>
> 4. Specify a manycast server group address, ttl limit and beacon 
> interval.

Okay.
>
> In the broadcast/multicast, pool and manycast schemes, we need the 
> optional tos floor and tos ceiling and tos cohort commands as well. 
> All schemes may need the key ID or Autokey flag.

Interesting. I agree that a key needs to be specified somehow, but it is 
not clear
to me how to do it. We have to assume that the client does not have the 
same NTP
keys. However, we would like a way to specify a server and keys 
securely, so that
the security of the network depends only on the security of DHCP. Again 
I am not
up to date, *is* there a secure DHCP? If so, then how to get keys to the 
clients
becomes an issue.


>
> All this makes me nervous. A possible alternative is simply to send a 
> configuration file like the ntpq program can now. However, this of 
> course is implemention specific. It might be useful to provide the 
> name of a local configuration file only. The most important thing is 
> to make it flexible for use by current ntpd and possibly others.
>
It seems (as you said) that a general purpose configuration mechanism is 
needed. One that
is implementation neutral. We have talked in the past about config over 
LDAP and HTTP.
Maybe we need to revist that. It would not have to be built into ntpd, 
though, it could easily
live as a separate process.

Brian
>