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

["David L. Mills" <[e-mail]>]

Danny,

As I understand it, the DHCP client broadcasts a request to the DHCP 
server and receives a response. There is an opportunity for the DHCP 
client to measure the delay, should it be so instrumented. In no way did 
I intend the DHCP server run NTP for any business but itself.

The discussion has left me a little uneasy about the specificy of the 
message formats to the current NTP implementation. Things like minpoll 
and maxpoll could be interpreted in context to protect the NTP servers, 
but in the DHCP environment that probably is not an issue. There is no 
real need to reveal broadcast mode servers. As long as the client knows 
the address mask, it can generate the broadcast address to listen on. It 
doesn't make sense to advertise symmetric modes, as these are usually 
reserved for serious low-stratum campus servers. This leaves only 
client/server mode as useful. However, the key ID is important, as the 
NTP client and server should share the same bag of keys and the client 
might not know the current server key ID.

Some perspective on the issues can be gained from our experience with 
other discovery schemes like broadcast, manycast and the pool. Broadcast 
provides the server address (for delay measurements), stratum and key 
ID. Manycast servers filter the client stratum and respond only if they 
can provide better time. They also provide the key ID. The pool scheme 
merely provides the server addresses. In all three schemes the client 
can filter the responses for acceptable stratum and then cast out the 
survivors from the population leaving only the best quality survivors. 
The DHCP discovery scheme needs only to provide comparable statistics. A 
client can use any combination of these schemes.

Dave

Danny Mayer wrote:

> Dave,
>
> I don't see how. The DHCP server and the NTP server are different nodes
> on the network, unless the DHCP server is going to provide the NTP
> service as well but that's a bad assumption to make even though the DHCP
> server SHOULD be running NTP, if only for itself.
>
> Danny
>
> David L. Mills wrote:
>
>> Brian,
>>
>> We need to think about scenarios for server discovery. Without prejudice
>> on the message formats, a virgin client might be directed to either:
>>
>> 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.
>>


_______________________________________________
dhcwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/dhcwg