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

[Benoit Lourdelet (blourdel)]

About those 50 options ... For DHCPv6, listing already defined options
specifying an IP service,
I find option : 22,27,28,31,34, 40 that have hardcoded IPv6 addresses.

So far, I cant find any IP service defined by an FQDN for DHCPv6.

Benoit 

> -----Original Message-----
> From: Danny Mayer [mailto:mayer at ntp.org] 
> Sent: Monday, November 19, 2007 7:05 PM
> To: Ted Lemon
> Cc: Brian Utterback; Benoit Lourdelet (blourdel); 
> ntpwg at lists.ntp.org; dhcwg at ietf.org; Richard Gayraud (rgayraud)
> Subject: Re: [dhcwg] Re: [ntpwg] Network Time Protocol (NTP) 
> Options for DHCPv6
> 
> Ted Lemon wrote:
> > On Mon, 2007-11-19 at 09:07 -0500, Brian Utterback wrote:
> >   
> >> 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."
> >>     
> >
> > An option in a protocol that produces no different behavior 
> is just an 
> > opportunity for interoperability problems.
> >
> > This is actually an old discussion.   Danny's position 
> isn't unheard of,
> > but the fact is that there's really no way in which this option is 
> > different from the other fifty options that tell DHCP 
> clients how to 
> > contact servers.
> >
> > There's no reason why this option should use FQDNs while the other 
> > fifty use IP addresses, and there are a number of good 
> reasons not to 
> > send FQDNs, the first and most obvious of which is that 
> they take up 
> > more space in the packet, and space in the packet is very limited.
> >
> >   
> There is no way of answering that claim without knowing more 
> about a) those other 50 options; and
> b) how those options are obtained.
> 
> So let's step back here for a moment and have someone from 
> the DHCP community explain exactly how and when these options 
> are sent to the client. Remember that those of us 
> concentrating on NTP have only some idea how DHCP is sending 
> these options. Does DHCP:
> a) Send these options unsolicited when it is requested to 
> send an IP address to be used by the client?;
> b) Only send these options when requested by the client?;
> c) something else?
> 
> When does the client send/receive the request?
> a) Upon boot
> b) upon lease renew
> c) some other time?
> 
> Except for a) the NTP server is not going to be taking any 
> options from the DHCP server unless some other mechanism 
> (which NTP has not designed) tells it to. That means that the 
> NTP can be up for months never updating it's list of NTP 
> server addresses. In the meantime, Server 1 has stopped 
> running, Server 2 has moved to a different address, Server 3 
> was always suspect. DCHP has no say in what to do about this, 
> at least so far. DNS at least provides a way of getting a 
> fresh set of addresses.
> 
> Danny
>