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

[Ralph Droms <[e-mail]>]

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

At 12:59 AM 10/7/2003 +0530, Vijayabhaskar A K wrote:
>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
> > [e-mail]
> > https://www1.ietf.org/mailman/listinfo/dhcwg
> >


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