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

[Mark Stapp <[e-mail]>]

making it possible to convey NTP servers in dhcpv6 doesn't seem to me to 
be any different than conveying them in dhcpv4 was. that was done 
something like ten years ago, and as far as I know that hasn't been a 
problem.

I do wonder why some folks seem to think that using DNS names would 
somehow be "safer" than using v6 addresses. if someone shipped a server 
with a canned list of DNS names for NTP servers, there would be a 
problem until the owners of the NTP servers named moved them. I don't 
see how that'd be any better than the analogous mistake involving IP 
addresses.

shipping a DHCP server with a canned configuration would not be good, so 
let's hope it doesn't happen. Mark Andrews's email seems to me to 
summarize what happens: 'home' routers have a dhcp client face and a 
dhcp server face, and use the client to populate the server.

aside from the catastrophe hypothetical, is there any really strong 
reason - anything to do with the NTP protocol - that would prevent the 
use of ipv6 addresses?

Thanks,
Mark

Benoit Lourdelet (blourdel) wrote:
> Mark and David,
> 
> If we consider the already defined DHCPv4 and DHCPv6 Options, IP
> services are, in (almost) all cases, passed as an address and not as a
> name.  
> If we come to the conclusion that FQDN is really mandatory for NTP, I
> don't see why we should not retrofit this to all existing IP services
> Options.
> 
> Honestly, I would like the DHCP veterans to come forward and tell us why
> they made so many bad decisions in the past :-;
> 
> Benoit
> 
>> -----Original Message-----
>> From: Mark Stapp (mjs) 
>> Sent: Wednesday, November 21, 2007 5:10 PM
>> To: David L. Mills
>> Cc: [e-mail]; [e-mail]
>> Subject: Re: [ntpwg] [dhcwg] Re: Network Time Protocol (NTP) 
>> Options for DHCPv6
>>
>> 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
>>> [e-mail]
>>> https://www1.ietf.org/mailman/listinfo/dhcwg
>>>
>> _______________________________________________
>> dhcwg mailing list
>> [e-mail]
>> https://www1.ietf.org/mailman/listinfo/dhcwg
>>
> 

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