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 <karen.odonoghue@navy.mil>
Brian Haberman <brian@innovationslab.net>

Internet Area Director(s):

Mark Townsley <townsley@cisco.com>
Margaret Wasserman <margaret@thingmagic.com>

Internet Area Advisor:

Mark Townsley <townsley@cisco.com>

Mailing Lists:

General Discussion: ntpwg@lists.ntp.isc.org
To Subscribe: https://lists.ntp.isc.org/mailman/listinfo/ntpwg
Archive: http://lists.ntp.isc.org/pipermail/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
backwards-incompatible changes.

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


  • draft-ietf-ntp-ntpv4-proto-00.txt
  • draft-ietf-ntp-reqs-00.txt

    No Request For Comments

    Current Meeting Report

    Network Time Protocol WG Meeting Minutes
    Tuesday, August 2 at 1630-1800
    CHAIRS: Brian Haberman, brian@innovationslab.net
    	Karen O'Donoghue, karen.odonoghue@navy.mil
    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
    tied together.  
    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
    SNTP Status
    NTP Requirements
    PWE3 Timing Requirements
    NTP Protocol
    IEEE 1588 Status