RE: [dhcwg] AD Review: draft-ietf-dhc-dhcpv6-opt-timeconfig-02.txt

Hi Margaret

Thanks for your very quick reply. My reply inline

~ Vijay

> 
> Hi Vijay,
> 
> Thanks for your response.
> 
> > > General question on this document:  We recently deprecated the 
> > > option code allocation for the IPv4 version of this 
> option.  Why do 
> > > we think that there is a greater need for this in IPv4 
> than in IPv6?  
> > > Has anyone implemented these options?
> >  
> > NTP version 4.0 available in www.ntp.org supports IPv6. Most of the 
> > vendors provide this version and support NTP on IPv6. So, 
> it is really 
> > needed.
> 
> Your response answers my concern about whether or not NTP is 
> available for IPv6, but it doesn't answer my larger concern.
> 
> We just deprecated the corresponding configuration options 
> for IPv4, because they weren't implemented.  Do we have some 
> reason to believe that people will implement this option for 
> DHCPv6 when no one implemented the same option for IPv4?  If so, why? 

One of the two options specified in the draft has been already
standardized for IPv4. Refer RFC 2132, option code : 42, Network Time
Protocol Servers Option. 

There is an option called "Time offset" (option code: 2) defined in RFC
2132. But, it could not convey enough information like day light
savings. Only to provide more information about the timezone, the  draft
for "POSIX time zone option for DHCPv4" was written. Meanwhile, There
were few implementations providing this support in the vendor specific
options. One such example is Solaris's "SUNW.posix-timezone-string"
option. Hence, certainly there are few users. Unfortunately, this draft
was not advanced and got expired. As most of the platforms provided this
option in the form of vendor specific options, nobody really bothered to
restart the work and advance it to the standard. Moreover, I could see
alteast 2 implementation of DHCPv6, which have the support for POSIX
time zone option. (1) HPUX (2) KAME FreeBSD. What I am trying to say is,
Certainly keeping this as an vendor specific option may cause issues
while switching between the servers. Since, this option is used as
vendor specific option in few implementations of DHCPv4 and there are
implementations of DHCPv6 which support this option, its better to
standardize it.

> 
> > > It is also my understand that we haven't (yet) specified how NTP 
> > > would run over IPv6, so this option may be premature.
> > 
> > Since, there is actually no protocol changes are needed in
> > existing RFC for NTP, there is no specification for NTP on 
> IPv6. Its 
> > just like another application migration to IPv6. But, IPv6 
> version of 
> > NTP are available in various platforms. I don't think this 
> option is 
> > a premature one.
> 
> Actually, there are several IPv4 dependencies in the NTP 
> specification, as document in:  
> 
> http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4surve
> y-apps-02.txt
> 
> The folks who have implemented NTP for IPv6 must have worked 
> around those dependencies, but I don't believe that their 
> changes have been document in an IETF specification (yet).

The RFC it refers is version 3 of the SNTP protocol. The next version
deals with IPv6 also. 

        D. Mills.  Simple Network Time Protocol (SNTP) Version 4 for
        IPv4, IPv6 and OSI.  Request for Comments (Informational) 2030,
        Internet Engineering Task Force, October 1996.

> 
> > > What is the reason for specifying a timezone format in this 
> > > document, instead of relying completely on another establish 
> > > standard for timezone representation?
> > 
> > This flexibility is provided to help the vendors to use some other 
> > vendor specific database for timezone information. This is 
> needed, if 
> > they feel that their databases can convey more information 
> than POSIX 
> > time string.
> [...]
> > > What is a "timezone database"?  Is this a standard concept, or 
> > > something you are assuming will be specific to each host?
> > > If the latter, why do we need this flexibility?
> > 
> > Its not a standard concept. Its something specific to the 
> OS. For the 
> > last question, you refer the prev answer.
> 
> How do you maintain interoperability between the DHCP server 
> and clients from multiple vendors, if the server may return 
> the timezone in an OS-proprietary format?  

Its basically through vendor-options/class ids. Based on the class-ids
the server can provide different information for the same entity to the
different clients. This is the conventional methodology done from DHCPv4
onwards.

> You mentioned 
> earlier that this timezone information is set on a per-subnet 
> basis, with the assumption that all clients on the same 
> subnet are in the same timezone.  Do you also 
> assume that all clients on the same subnet are running the same OS?

No, certainly not. There can be clients running different OS. But, they
will be differentiated by the server.

> 
> > > > To avoid attacks through these options, the DHCP client 
> SHOULD use 
> > > > authenticated DHCP (see section "Authentication of DHCP 
> messages" 
> > > > in the DHCPv6 specification [1]).
> > > 
> > > Why only a "SHOULD"?  Given the critical nature of time 
> information 
> > > to some security protocols, I would prefer a statement that this 
> > > option MUST only be used when the DHCP messages are 
> authenticated.  
> > > Is there a reason not to say that?
> > 
> > As such authentication is not mandatory in the DHCPv6
> > specification (RFC 3315) except for reconfiguration. That's the 
> > reason why "MUST" is not used here.
> 
> True, although we could require that DHCP security be 
> implemented and used whenever certain sensitive options are 
> in use...  I'm not sure what sort of policy has been used for 
> deciding this in the 
> past, though.
> 
> > > > [2]  D. Mills.  Simple Network Time Protocol (SNTP)
> > > > Version 4 for IPv4, IPv6 and OSI.  Request for Comments
> > > > (Informational) 2030, Internet Engineering Task Force, 
> > > > October 1996.
> > > 
> > > This should be a reference to NTP, not to SNTP.
> > 
> > Basically, the NTP servers I am referring are SNTP servers. I
> > believe, I could change the "NTP server option" to "SNTP server 
> > option".
> 
> If that is more accurate, then I think it would make sense to 
> make that change. 
>  
> 
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www1.ietf.org/mailman/listinfo/dhcwg
> 

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg