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

[Brian Utterback]

Danny Mayer wrote:
> Brian Utterback wrote:
>> Benoit Lourdelet (blourdel) wrote:
>>> Considering a central DHCP server, the use of remote-id [RFC4649] or
>>> just link-id may tell the server from where the request is coming then
>>> giving it the knowledge of the delay to
>>> apply.
>>> In the case of a DHCP server hosted by the first hop, the DHCP server is
>>> well positioned to know the delay.   
>> Oh, agreed, it is possible for the delay to be known. 
> 
> I consider that it is most unlikely for the DHCP server to know the
> delay. Consider DHCP server D, client C and NTP server N. Each are in
> different locations on the physical wire (wireless and other medium are
>   similar). D may know its own delay to N but C is elsewhere on the
> wire. You might be able to figure out the delay between D and C but how
> does it relate to the delay between C and N? They are in different
> locations on the wire. Is C closer to N, further away, on another
> segment of the network?

Also, agreed. One can imagine a setup where the DHCP server has been
configured with the correct broadcast delay for every subnet that it
serves. However, I consider that this is a very rare occurrence and
very error prone. Why bother? Just let the client do the volley and
have done with it. So I agree with you in general, Danny. Having
a broadcast delay served from the DHCP server is usually going to
be a bad idea.


-- 
blu

"You've added a new disk. Do you want to replace your current
drive, protect your data from a drive failure or expand your
storage capacity?" - Disk management as it should be.
----------------------------------------------------------------------
Brian Utterback - Solaris RPE, Sun Microsystems, Inc.
Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom