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

[Mark Stapp]

yes, this is another reason why the DHCP folks have generally used 
addresses in options. it just removes a dependency among the various 
clients in the system, and it doesn't usually have any significant drawback.

there seems to be a concern that delivering addresses via DHCP somehow 
makes them difficult to update over time. just to reiterate: it's often 
the case that the information at the DHCP server is updated. the updated 
information flows out to clients as they renew. if the lease timers were 
very long, a client who got NTP addresses and found itself having 
trouble with them all could also use the INFORMATION-REQUEST message to 
check whether the addresses were still valid, outside of the normal 
renewal timers.

-- Mark

David L. Mills wrote:
> Brian,
> 
> Trying to put out fires when the network is burning is a good excercise 
> in fault containment. When the DNS is broken and the repair party 
> arrives, it's good to know the gateway works even if DNS doesn't. I'm 
> not sure this exactly applies to NTP, but I sure would like to see the 
> NTP servers options include hard coded addresses.
> 
> Dave
> 
> Brian Utterback wrote:
> 
>>
>> Danny Mayer wrote:
>>
>>> There is *no* avantage to not sending a FQDN and plenty of disadvantages
>>> to not doing so.
>>> Would you like a list of vendors who have hardcoded IP addresses into
>>> their devices without
>>> permission of the operator of that NTP server causing headaches for not
>>> just the owner of the
>>> NTP Server but also for the users of those devices? The NTP reference
>>> implementation expects
>>> the existence of a resolver so you haven't gained anything.
>>>
>>
>> As already noted, there is an advantage, namely that the client does
>> not have to have a resolver. And even if the reference implementation
>> requires one (Is that really true? Even if no name resolution is
>> required?) DHCP should remain implementation agnostic.
>>
>> As far the "hard coded address" problem goes, I don't see that
>> scenario as very likely. DHCP clients don't tend to remain up
>> for very long periods. And you don't have the same IP addresses
>> being served by thousands of DHCP servers. The thing to be careful
>> of is that the DHCP server not be embedded and replicated with hard
>> coded addresses, not that the clients only get IP addresses.
>>
>> That having been said, I would like to see a way to pass a FQDN
>> as an option, perhaps passing both. Then you could have logic
>> like "Here's both, use the name if you can, and use the address if
>> you must."
>>
> 
> 
> _______________________________________________
> dhcwg mailing list
> dhcwg at ietf.org
> https://www1.ietf.org/mailman/listinfo/dhcwg
>