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

[David L. Mills]

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."
>