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

[[e-mail]]

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? 

> > 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-ipv4survey-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).

> > 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?  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?

> > > 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
[e-mail]
https://www1.ietf.org/mailman/listinfo/dhcwg