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

From: [email-masked]
Date: Mon, 6 Oct 2003 13:53:01 -0400

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

---

From: "Vijayabhaskar A K" <[email-masked]>
Date: Tue, 7 Oct 2003 00:59:57 +0530

Hi Margaret

Thanks for your very quick reply. My reply inline

~ Vijay

> > > 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?
> >  
> 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.
> > 
> Actually, there are several IPv4 dependencies in the NTP 
> specification, as document in:  
> 
> 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 a "timezone database"?  Is this a standard concept, or 
> > > something you are assuming will be specific to each host?
> 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 

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

> SHOULD use 
> > > > authenticated DHCP (see section "Authentication of DHCP 
> messages" 
> 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?
> > 
> 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.
>

---

From: Ralph Droms <[email-masked]>
Date: Tue, 21 Oct 2003 12:20:17 -0400

Seems to me we are closer to consensus on publishing the option for (S)NTP 
servers than we are for the timezone configuration option.  Vijay, I 
suggest you split your current draft into two drafts, one for the (S)NTP 
servers option (call it draft-ietf-dhc-dhcpv6-opt-timeconfig-03.txt if you 
can publish it this week) and a new draft for the timezone option.  With 
two documents, we can let each option proceed at its own pace...

- Ralph

---

From: "Vijayabhaskar A K" <[email-masked]>
Date: Tue, 21 Oct 2003 22:01:43 +0530

Ralph,

I have submitted the draft-ietf-dhc-dhcpv6-opt-timeconfig-03.txt last
week. Still, it is not published, though I submitted nisconfig-03 and
timeconfig-03 together. Shall I proceed with the splitting up of the
drafts (or) shall I wait for timeconfig-03 to get published? I am
attaching the draft-ietf-dhc-dhcpv6-opt-timeconfig-03.txt along with
this mail. 

~ Vijay

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Ralph Droms
Sent: Tuesday, October 21, 2003 9:50 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [dhcwg] AD Review:
draft-ietf-dhc-dhcpv6-opt-timeconfig-02.txt

Seems to me we are closer to consensus on publishing the option for
(S)NTP 
servers than we are for the timezone configuration option.  Vijay, I 
suggest you split your current draft into two drafts, one for the (S)NTP

servers option (call it draft-ietf-dhc-dhcpv6-opt-timeconfig-03.txt if
you 
can publish it this week) and a new draft for the timezone option.  With

- Ralph

At 12:59 AM 10/7/2003 +0530, Vijayabhaskar A K wrote:
> > > 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.
> >

> > that people will implement this option for DHCPv6 when no one 
> > implemented the same option for IPv4?  If so, why?
>

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

> > > > something you are assuming will be specific to each host? If the

> > > > latter, why do we need this flexibility?
> > >

> > in an OS-proprietary format?
>

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

> > > > > [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.
> > If that is more accurate, then I think it would make sense to make 
> > that change.
> >
> >