Subject: [ntpwg] IPv6 Router Advertisement Option for NTP Configuration

From: Danny Mayer <[email-masked]>
Date: Tue, 15 Jun 2010 08:14:29 -0400

I was looking for our NTP drafts when I came across this document:
draft-chen-ntps-ra-opt-00.txt (see
http://www.ietf.org/id/draft-chen-ntps-ra-opt-00.txt)
which talks about adding router advertisement for an NTP server.

Since this is listed as standards track even though it is an individual
submission I think it should have gone to the NTP working group for
review and advice.

My quick look at this document indicates that it hasn't thought through
the NTP requirements for NTP servers and that is crucial.

I won't comment further until the working group has a chance to consider
whether or not we should review this.

Danny
_______________________________________________
ntpwg mailing list
[email-masked]
http://lists.ntp.org/listinfo/ntpwg

---

From: Karen O'Donoghue <[email-masked]>
Date: Tue, 15 Jun 2010 09:25:47 -0400

Danny,

Thanks for reminding me about this document. I identified it prior to 
the March IETF
meeting and contacted the authors about making it an NTP working group 
document. It was one
of the possible work items for the NTP discussed at the March TICTOC 
meeting. We haven't
done anything with it because we had been focused on getting our four 
documents through
the final steps and discussing how to proceed with the NTP working group.

In that light, I'd like to make two requests:

1) Please review and comment on the referenced document. Regardless of 
whether the NTP
working group will determine the final status of this document or not, 
it needs to be involved
in the discussion.

2) Please consider what future time work should be done in the IETF in 
either the NTP or
TICTOC working groups and post any comments or suggestions.

Thanks,
Karen

---

From: Tony Li <[email-masked]>
Date: Tue, 15 Jun 2010 10:04:49 -0700

> 1) Please review and comment on the referenced document. Regardless of whether the NTP
> working group will determine the final status of this document or not, it needs to be involved
> in the discussion.

I've reviewed this draft and have no problems with it, as far as it goes.  It's very unusual in that I think it's the first IETF draft I've ever read where the specific syntax of the proposal has not yet been specified.  Isn't that what we love to argue about?  ;-)

I'd love to know what Danny considers to be the issues with this.

I'd recommend that the authors fully specify the syntax before this is accepted as a WG document.

Regards,
Tony

---

From: Danny Mayer <[email-masked]>
Date: Tue, 15 Jun 2010 22:19:17 -0400

You managed to drop the principal author which I made sure to include in
responses!

On 6/15/2010 1:04 PM, Tony Li wrote:
> I've reviewed this draft and have no problems with it, as far as it
goes. It's very unusual in that I think it's the first IETF draft I've
ever read where the specific syntax of the proposal has not yet been
specified. Isn't that what we love to argue about? ;-)

Certainly it's very vague! I cannot even tell how many of the IPv6
addresses are going to be sent.

> I'd love to know what Danny considers to be the issues with this.

I have not read the document in full details but I am concerned that it
appears that only one IPv6 address will be sent. Since NTP depends on
multiple sources to improve accuracy and reliability sending just one is
not sufficient. If this is likely to be a site-local address it would be
better to have the NTP server set up as a broadcast server and multicast
to FF05::101 for clients to pick up. The only thing that the routers
then need to do is forward those packets on the network.

Even better would be for the admin to set up an ntppool label in their
local domain DNS which would point to a list of AAAA addresses or just
CNAME to the pool.ntp.org domains. The reference implementation uses the
pool option to allow it to set up up to 10 associations from all of
those addresses as servers for it.

Furthermore it is not clear why one would do it at the router in the
first place and who would be maintain the address and where and what
happens when that NTP server is replaced by a different one and who
would notice.

> is accepted as a WG document.
+1

Danny

---

From: Tony Li <[email-masked]>
Date: Wed, 16 Jun 2010 12:13:09 -0700

Hi Danny,

> You managed to drop the principal author which I made sure to include in

Whoops, apologies!

> addresses are going to be sent.

Well, nothing is certain without specifics, but given the references to DHCPv6, I'm assuming that they will mirror what's done in DHCP.  That would allow multiple addresses or names.

You might check out that document: draft-ietf-ntp-dhcpv6-ntp-opt-06.txt

> those addresses as servers for it.

It seems like the approach that is taken for DHCP would suffice for this.

> happens when that NTP server is replaced by a different one and who

There are those who feel that DHCP isn't the architecturally clean way of providing host configuration and that it should instead be done by ND.  While I have no wish to re-open that particular hornet's nest here, I suspect that the author's intention is simply to replicate the DHCP NTP configuration capabilities within ND.

Regards,
Tony

---

From: Danny Mayer <[email-masked]>
Date: Wed, 16 Jun 2010 22:12:07 -0400

On 6/16/2010 3:13 PM, Tony Li wrote:
> Well, nothing is certain without specifics, but given the references
to DHCPv6, I'm assuming that they will mirror what's done in DHCP. That
would allow multiple addresses or names.
> You might check out that document: draft-ietf-ntp-dhcpv6-ntp-opt-06.txt

I held up that draft for a time while we argued over security, possible
DDOS attacks, DNS names etc. so I'm all too familiar with that one.

This draft seems to think that there are no security issues which not a
correct assessment. See the dhcpv6 ntp opt document.

> It seems like the approach that is taken for DHCP would suffice for this.

So why duplicate the effort? What does Router Advertisement have to
offer that DHCP does not?

> There are those who feel that DHCP isn't the architecturally clean
> way
of providing host configuration and that it should instead be done by
ND.

Hmm, DHCP = Dynamic Host Configuration Protocol. Seems to fit the bill
exactly.

> While I have no wish to re-open that particular hornet's nest here,
I suspect that the author's intention is simply to replicate the DHCP
NTP configuration capabilities within ND.

But the question is why? I'm struggling to understand the point of this.
What is the problem that this draft is trying to solve that is not
already solved another way?

Danny

---

From: "Plunkett, Timothy R CIV NSWCDD, W23" <[email-masked]>
Date: Thu, 24 Jun 2010 13:55:44 -0400

In answer to Karen O'Donoghue's second item where she is requesting suggestions for any future work for either the NTP or TICTOC working groups.  I would like to see work in the area of incorporating the time synchronization capabilities of IEEE 1588 into NTP.  A IEEE 1588 type of solution can get time from a time source to a time client while minimizing the effects of network delays.  However IEEE 1588 does not provide for a solution for keeping an operating system clock synchronized to that time that was obtained over the network.  That is where NTP excels.  I think it will be beneficial if the two solutions, which address different parts of the time synchronization problem, could be made to work together.  

***********************************************************
Timothy R. Plunkett
NSWC-DD, Code W23
Building 1500 Room A104
17214 AVENUE B SUITE 126
DAHLGREN, VA 22448-5147

(540) 653 - 1090 (phone at Dahlgren)
(540) 653 - 4270 (fax at Dahlgren)
(540) 846 - 5472 (cell phone)

-----Original Message-----
From: ntpwg-bounces+timothy.plunkett=[email-masked] [mailto:ntpwg-bounces+timothy.plunkett=[email-masked]] On Behalf Of Karen O'Donoghue
Sent: Tuesday, June 15, 2010 9:26
To: [email-masked]
Cc: NTP Working Group; [email-masked]; Ralph Droms
Subject: Re: [ntpwg] IPv6 Router Advertisement Option for NTP Configuration

Danny,

Thanks,
Karen

---

From: todd glassey <[email-masked]>
Date: Thu, 24 Jun 2010 11:36:00 -0700

> In answer to Karen O'Donoghue's second item where she is requesting suggestions for any future work for either the NTP or TICTOC working groups.  I would like to see work in the area of incorporati…

I disagree - the two systems provide different time transfer services 
and since the OS clocks are the issue - something this group seems to 
want to ignore, the adding of another protocol interface will just 
complicate the evidence capture and proof model tremendously.

Todd Glassey