2.3.20 Network Time Protocol (ntp)
NOTE: This charter is a snapshot of the 63rd IETF Meeting in Paris, France. It may now be out-of-date.
Last Modified: 2005-06-29
Karen O'Donoghue <email@example.com>
Brian Haberman <firstname.lastname@example.org>
Internet Area Director(s):
Mark Townsley <email@example.com>
Margaret Wasserman <firstname.lastname@example.org>
Internet Area Advisor:
Mark Townsley <email@example.com>
General Discussion: firstname.lastname@example.org
To Subscribe: https://lists.ntp.isc.org/mailman/listinfo/ntpwg
Description of Working Group:
The Network Time Protocol (NTP) is widely deployed and used
in the Internet. However, the standardization status of this
protocol has lagged in the IETF. RFC 1305 (NTP version 3) was
published in March 1992 and remains unchanged and at Draft
Standard status. RFC 1305 represents the majority of full NTP
implementations deployed today. RFC 2030 (SNTP version 4)
was published as an Informational RFC in October 1996 as a
lightweight version of NTP for deployments not requiring the full
functionality of NTP. SNTP now represents the majority of both
NTP traffic and NTP implementation issues on the Internet. A
good deal of work has been produced in the NTP community
updating both NTPv3 and SNTPv4. This work is ongoing and
available through the collaborative development effort in the NTP
community, but it has not been reflected back into the NTP
The goal of this working group is to document NTPv4 based on
the extensive work of the NTP community and to advance the
standardization status of NTP. It is an explicit goal of this effort to
have NTPv4 interoperate with the deployed base avoiding any
A number of topics have been raised as potential work items for
an update to NTP including support for IPv6, security
considerations including authentication, automatic configuration
including possible requirements for DHCP, and algorithm
improvements. This working group will focus first on delivering
NTPv4 and will defer additional development efforts until after
the delivery of NTPv4. Support for IPv6 and defining
mechanisms for securing NTP transactions is considered part of
the core NTPv4 functionality. Potential further modifications and
additions to the NTP protocol will be documented for possible
further work beyond the initial NTPv4 effort.
The working group will initially focus on the following
1. NTPv4 Scope and Requirements Document
(documenting the scope of the NTPv4 update and
identifying issues deferred for future work).
2. NTPv4 Protocol Specification (documenting the protocol
on the wire)
3. NTPv4 Architecture and Algorithms Specification
(documenting the architecture, mathematical algorithms,
and behavior of NTP servers and clients)
4. NTPv4 MIB (provision for management and monitoring
of NTP via SNMP)
Goals and Milestones:
|Done|| ||NTP BOF at IETF 61 |
|Done|| ||NTP WG Charter Approved |
|Mar 05|| ||Draft of Scope and Requirements Document |
|Mar 05|| ||Draft of NTP Protocol Specification |
|May 05|| ||Draft of MIB Specification |
|Jul 05|| ||Draft of NTP Algorithms Specification |
|Sep 05|| ||WG Last Call Scope and Requirements Document |
|Nov 05|| ||WG Last Call NTP Protocol Specification |
|Mar 06|| ||WG Last Call NTP MIB Specification |
|May 06|| ||WG Last Call NTP Algorithms Specification |
No Request For Comments
Current Meeting Report
Network Time Protocol WG Meeting Minutes
Tuesday, August 2 at 1630-1800
CHAIRS: Brian Haberman, email@example.com
Karen O'Donoghue, firstname.lastname@example.org
o Administrivia (Chairs)
Mailing list, blue sheets, scribes, agenda bashing
There was no jabber scribe available.
o SNTP Draft Status (Karen)
The SNTP draft is now final; it is to be an Informational RFC that is
now pending in the RFC Editor's Queue. While this work pre-dates this
WG, it will be under WG once it is released. The new documents, that this
Working Group is developing, will supersede this RFC.
o NTPv4 Requirements
draft-ietf-ntp-reqs-00 (Dave Plonka)
This effort is developing a requirements document for a protocol that is
already in use. This document is also to be a collection place for
future requirements. Dave provided an overview of the current draft.
Areas that he is soliciting information are marked with a "FIXME".
Dave asked for help in the Algorithm Requirements in particular.
A number of issues were discussed:
*(Dave P.) How can we best address SNTP? Currently it has its own section but
it is interleaved throughout as well.
*(Dave P.) Should operational requirements be included? Usually only a BCP
covers operational issues but NTP's public server infrastructure is a special
case. Brian said that Operational considerations should be in a BCP, not
in a Requirements document. Karen asked that we collect the operational
considerations here for now and break them out later.
*(Peter L.) Should the working group be concerned only with UTC or with any
time source? Direction was to work with any time source but NTP's public
server infrastructure is a special case that needs emphasis.
*(Peter L.) Need to explain the algorithm so that someone can build from
scratch, this will affect many documents.
*(Dave P.) How should we handle autokey? Brian indicated that he talked to
an AD who indicated that we may need a way to distribute keys using IETF IPSEC
key distribution protocols. The requirement is to distribute keys, not
to describe a particular protocol.
*(Bill) Manual key configuration will result in replay attacks related to
restarting the sequence number at the same value and thus an automated
key management capability is needed.
*(Sharon C.) Need to provide useful reporting of management information (e.g.
via the MIB), do not make it an operational issue. For example, continue
requiring that stratum 1 servers have an outside source of time versus
making this an operational issue.
*(Peter L.) - Need to document a requirement to identify the type of time
that is being transferred. For example any of the eighty UTC clocks is
identified by a four-character name, this could be placed into the protocol
header sent by a stratum 1 server. Currently, the protocol has a means
identifying the dissemination method versus identifying the source of the
time information. Someway of authenticating such information would also
be needed. This topic is to be put into the bin of future requirements.
draft-frost-pwe3-timing-pw-reqs-00 (Tim Frost)
Tim provided an overview of his draft, explaining pseudo wire's need
for time synchronization. There was a lot of discussion trying to align
the time needs of pseudo wire (Used in carrier packet nets) with NTP (usually
used in LAN or Internet environments) capabilities. Tim was interested in
seeing whether NTP might be a protocol suitable for conveying timing and
synchronization for a pseudo wire infrastructure. NTP is concerned with wall
clock or absolute time while carrier packet nets are concerned with frequency
and phase as well as absolute time. Performance aspirations may differ.
The basic question discussed was whether NTP could be used for timing pseudo
wires. Pseudo wire time capabilities are needed for the infrastructure and
not providing time info directly to users.
A number of issues were discussed:
(From the floor) Why could not NTP be used as is since pseudo wire is
is used where you don't have IP ( e.g. an L2 link like ATM)?
(From the floor) Can we use NTP to distribute clock within a Telco? There
were a number of people who thought it could. Use NTP packets to pass
phase and frequency.
(Stewart B.) Wants to understand the requirement and come up with a viable
solution. Recommended that the discussion be moved to the list.
(Karen) Asked that the focus be the articulation of the problem so that
all can agree on the problem and the associated performance numbers.
o NTPv4 Protocol Specification
draft-ietf-ntp-ntpv4-proto-00 (Jack Burbank)
Jack provided an overview of the draft which Jim Martin, Dave Mills and he
are writing. This draft is to document the protocol on the wire. The goal is to
have a draft ready for Working Group last call by the next meeting. As with the
NTP Requirements draft, he felt that SNTP probably deserves its own section in
the protocol draft.
The three step process for developing this draft is (currently in step 2):
1. Compile material "as-is" from existing NTP material putting it into the proper format.
2. Add any additional material that is required. Here the comments from the
IESG on the informational SNTP draft can be addressed.
3. Clean up.
Issues that were discussed:
(From the floor) Anycast terminology needs to be cleaned up. There was consensus
that this is a goal for this draft.
(Jack) The advancement of the Protocol document requires multiple independent
implementations. Most current implementations come from the reference
o IEEE 1588 Update (Karen)
IEEE1588-2002 is a standard for a Precision Clock Synchronization Protocol for
Networked Measurement and Control Systems. The IEEE 1588 community is interested
in using the NTP security approach. Karen wants to keep the two communities
Issues that were discussed:
(Sharon C.) Asked whether IEEE 1588 and NTP could be merged. Karen indicated that
there are quite a bit of difference since IEEE 1588 can require dedicated hardware
and only uses Ethernet transfer. Stewart said that we can perhaps a common upper
layer for both 1588 and NTP.
(From the floor) Is the NTP security solution in need of fixing? If there
are known problems these need to be communicated to the IEEE 1588 group. The
discussion that followed indicates that there are no known problems with the
NTP security solution but at this point it is not known whether the NTP
security solution would be good for IEEE 1588.
NTP Agenda and Administrivia
PWE3 Timing Requirements
IEEE 1588 Status