2.3.19 Network Time Protocol (ntp)

NOTE: This charter is a snapshot of the 64th IETF Meeting in Vancouver, British Columbia Canada. It may now be out-of-date.

Last Modified: 2005-09-27


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 2005  Draft of Scope and Requirements Document
Mar 2005  Draft of NTP Protocol Specification
May 2005  Draft of MIB Specification
Jul 2005  Draft of NTP Algorithms Specification
Sep 2005  WG Last Call Scope and Requirements Document
Nov 2005  WG Last Call NTP Protocol Specification
Mar 2006  WG Last Call NTP MIB Specification
May 2006  WG Last Call NTP Algorithms Specification


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

    No Request For Comments

    Current Meeting Report

    Dave Plonka - Requirements Draft
    Differences between -00 and -01:
        Extended broadcast term to mean IPv6 multicast too.
        Added jitter and wander defs.
        Remove reference to master/slave.
    Algorithm Requirements:
        Removed MAXSTRAT, MAXSKEW, etc. due to them being only implementation details
        Introduced MAXPOLL which has clear requirements
        Mentioned that SNTP clients are divorced from many of the algorithm requirements for "full" implementations.
        noted that ntp is best effort, but noted service expectations.
        4 servers should be configurable
        New "Leap Seconds" Section
        Implementations should signal pending leap-seconds
        Added test re:reconfiguration when servers are unreachable.
    New "Management Information Requirements" Section
        removed references to th autokey protocol in favor of "IETF standard method" 
        for server verfification and key distribution.  Identity verification of 
        servers and the like is included in that.  
        AutoKey is NTP-specific, and perhaps this should be replaced with some other protocol.
    Previous Open issues: 
        draft has a dedicated sntp sectioni:  There has been discussion in splitting
        the sntp protocol out into a separate draft.
        operational requiremetns section remains temporarily to collect these items.
    Leap Seconds:
        Is this issue sufficiently addressed in the new Leap Seconds sub-section?
        Is distribution of the leap-seconds table important?  This was apparently a
        function of the non-standard AutoKey protocol.
        There is a ntp community terms doc somewhere
        Other NTP WG drafts/rfcs become the authorative source fo defs of these terms,
        at least the terms used in the protocol spec.
    What is iburst?
        used in ntpd initialization.
        how does this affect poolling interval requirements?
    There are still holes that need to be filled, planned for the next draft, 
    please contribute!!
    Yakov Stein:
        defs of time, jitter and wander, ref to ITU-T G.810.
        Editorial comments.
            section 8, specially crafted ntp public key crypto method should be crafted. --
            is there a good reason we cannot use an existing pki method??
    Brian Haberman: 
        Originally said had to use AutoKey, this new text is trying to get away from
        specifying autokey in the requirements doc.
        We should try to use a standard method, should change the text to make it
        I agree, makes sense, send text.
    Other point: Pat Cain did an assesssment of the autokey method itself.  Should
    put this assessment out on the mailing list, since that will give us a 
    Operational guidelines should be in other specs and not in requirements doc.
    Jim Martin:
        As we go through the protocol, we may discover that there are things defined
        in the current spec, that if we document is precisely, may not make it 
        through the rfc process (see existing issue on autokey).  Do we rev the 
        version?  What do we do if the spec diverges from the application?
        If we assume that we're just doing an implementation documentation, why are
        we doing a requirements doc?
        We are trying to do both, the requirements doc is an attempt to look at the
        delta between the existing implementation and things that we may need for
    James Rafferty:
        Former chair of FAX, similar problems in that wg.  Different communities
        differ in how they opearte, we need to keep lines of communication open
        so we don't break things.
    Jack Burbank:
        If this doc is attempting to address requirements for both v4 and v5, we 
        might want to reconsider the title.
    Tony Hain:
        Perhaps we should split this into 2 docs, v4 and v5. Also put things that are
        likely to change into an v5 requirements doc.  So the v4 doc says that 
        this is a minimum set that is not likely to change.
        Easy to say, but the existing problem is that the current implemenation
        as done cannot pass ietf (e.g. autokey).
        Working on getting more closely hooked into the ntp community.
        NTPv4 is in flux, we need to try to coordinate this.
        One thing that was missing from the open issues, are tim frost's requirements
        from the pseudowire group.
    Mark Townsley:
        If ntpv4 is not done, then this is fine, and does the group plan to do some
        work on v4, then break and do v5.
        How do we split that?
        In working with the community, the changes that are immedietely pending in
        the developer community will go into v4, others will go to v5.
        If you go to IESG with a doc that exists vs. saying that this is the doc, and
        that this is what we merge to.  These are different things.
        Inclined to the latter.
        Still unclear as to what we're targeting for what docs and processes.
        We're trying to write ietf-standard specs, that document what exists.
        It is possible that by the time we publish, things will be in sync.  Worried
        that the developer community and the ietf community will diverge with regard
        to ntpv4.  If developers and ietf are all on board, we converge to what ntpv4
        should be.  If that doesn't happen, maybe we need to do ntpv5.
        Now we get into the normal developer<>protocol designer conflicts.  We need
        to get the developer community onboard.  To reiterate: would be nice to 
        have a clear def as to where the "should be" stops and when work on v5 
        Affinity with the v4 label.  Maybe we should be less concerned with the v4
    Jim Martin Presenting on NTPv4 Protocol draft -01.
        Work in progress, drawn on sntp draft.
        reorged the sections.
        clarified "manycast" mechanism.
        pulled in the control protocol that existed in the v3 spec.
        defined the modes of operation for ntp vs sntp.
        broke ptocol ops into client, server, and symmetric peer (to be done).
        removed all refs to anycast
        added a setion clearly definding the dynamic discovery mechanism.
        manycast is a dynamic discovery mechanism using an expanding-ring
        ttl/hop-count based multicast discovery mechanism.  The expanding-ring
        expands until it gets max hop count or you reach the required server
        count.  Pulled into a separate mechanism, removed refs to anycast.
    Control protocol:
        imported out of ntpv3
        minor updates for v4, still need to go through the source and see if there
        are any changes.
    To do:
        document v4 options
        document symmetric peer ops
        document existing autokey so we can make a decision.
        determine what elements shoul dbe iana managed
        vet docs for sntp specific refs.
        copyedit (rev -03+).
    Once -02 and/or -03 are out, plan to circulate through the community to
    fix errors and the like.
    Targeting at least one rev, and preferably both before the next meeting (65,
    Bill Kasch presenting on -00 rev on algorithm draft.
        created to capture the algorithm info.
        based entirely on david mills draft book.
        6 algorithms
        clock filter, clock selection, clustering, clock combining, polling, clock 
        incomplete polling info
        state machine shortcomings
    Need to get input from implementors.
    Karen O'Donoghue presenting on Leap Second discussion
        IETF position on leap seconds, there is an ITU effort
        ITU-R 236/7.  Dates back to 1999 to look at the future of UTC timescales.
        The ITU would like data on how leap seconds impact applicaitons and 
        protocols.  Karen posted ITU questions on slides.  Ronald Beard is the ITU
    IETF is responsible for a leap seconds position to send to ITU.
    No consensus yet:
        two positions
             - IETF shouldn't care
             - Don't do away with them (but need data on this).
    Peter Lothberg:
        Since we live on a planet that is slowing down, the clocks run consistently,
        but the earth does not.  Need to sync up clocks with earth time. 
        Committee for earth rotation speed sees we've slowed down more than 0.9
        seconds we'll add or delete a second to sync up.  A letter goes to vimp
        which gets published.  You can add a leap second at the end of every
        Earlier we said that we were going to ignore this, but if we delete leap
        seconds then we cannot keep up with the time.  We should factor this in so
        that regardless the internet can keep up.
    Tim Shepard:
        Worked for astronomers for 2 months years ago.  And what I find astonishing
        is that the ITU has authority to decide what UTC means.  Hesitant to 
        suggest that the IETF should make any statement that agrees with ITU 
        having authority to define this.  Since this is well defined in the 
        astronomy community, that I still keep up with.  There is a volume of 
        information on what UTC means that go backs to the 1970's and goes forward
        for a long time as well, so that in the 30th century they have a consistent
        time reference.  TAI and UTC and leap seconds relationship is not something
        that the ITU should play with.
        ITU specifies UTC, full stop.  UT-1 is specified by the astronomical 
        Not having an opinion on this is fine, if that is the consensus.  The issue
        with talking to the ITU folks, is what is the impact of UTC with leap
        seconds.  Having leap seconds is something that causes problems, so ITU
        wants to know if the impact of removing it will be worse.
    Dave Plonka:
        Should leave it in.  But a difference between the time distribution protocol
        and what the applicaiton does with it.
        Dave Mills agrees with that.
        If we are the time experts in the IETF, then our stand should be that our
        protocols should be able to correctly implement leap seconds, but if the
        user doesn't want to use them, that is fine.
        A profileration of timescales (UTC, GPS, etc.) are out there, one of the
        ITU concerns are that this causes confustion.
        Would have been nice is when ntp was deployed, you could also distrubute TAI
        which is a timescale that does not use leap seconds.  Dave Mills 15 years
        ago, said he did not have an accurate timesource for TAI time.  The only
        atomic-grade time source was UTC.  Pehaps we should add a UTC-TAI offset 
        information to NTPv5.
        The GPS navigation timescale is a snapshot of UTC when it was launched in
        the mid 1980's.  Suggestion that Gallieo should be launched with TAI.
        Glonaz runs with UTC including leap seconds.
    Greg Dowd:
        As a manufactuer of time gear, this is just time shifting.  NTP is just
        a dist protocol, the bits are not going away, leave 'em alone, unless
        you want to get into the os specs business.  I believe the apps don't have
        any more trouble dealing with this than with daylight savings time.
        What we do owe the ITU is a document that at least states how leap seconds
        relates to the ntp protocol.  Implementors: PLEASE HELP, so we can get
        the doc done.
        We have more time, we don't have to make a decision this week.
        Can we try to get this doc done by the end of the year.
        Perhaps we don't need a full doc, unless we need to give details.
        ITU is not asking us for an opinion, they are asking for data on how 
        ntp deals with leap seconds.
        So long as something gets done, it doesn't have to be a doc.
        I have lots of ITU experience, ITU loves docs.  ITU will want a doc, and
        ideally, send a person at the same meeting, to explain the doc, that is what
        will open communication lines.
    Mark Andrews:
        Disagee that this is the only group that deals with time.  DNS deals with time
        as well.  We had to make a decision, although I don't remember the decision.
        We should also look at these protocols.
        Good point, glad you made it, we shoud look at these, can you provide more 
        How to talk to ITU - need a liason statement, ITU processing is at least
        3 weeks.
    Steve Cassner:
        Datapoint on RTP's use of NTP-format time.  In RTP we pretend that leap
        seconds don't exist, since we're interested in keeping track of time
        intervals, not absolute time.  So if you have 2 implementations one which
        include leap-seconds and one that does not, this could cause a problem.
        Doesn't happen very often.  So this is not a strong datapoint to say that
        this has to be removed.
        We'll need to add complexity to the protocols to specify the timescales, 
        because in 50 years, they'll be 30 seconds off.
        Yes, however today people are using GPS-feeds for ntp clock source.  Which
        does not do leap seconds.
        What for ntpv4
        We'll be UTC for ntpv4.
        Perhaps add something to ntpv5 that indicates timescale in the packet.
        NTP extensions format is open, but it is not defined that you can extend the
        format to include what you want.  Has that been considered?
        Good to have values which can be registered an extended.  That way you can
        have time-related data be distributed.  You could, for example, transmit
        the offset between two timescales.
        ICMP has a timestamp.  If some people are doing leap seconds and some are not,
        we'll have return times off.  To circuit-em applications it might cause
        a failure.
    Karen speaking on IEEE 1588 update.
    Work is progressing in the 1588 committees.  There is a fair amount of 
    overlap, and we have an ongoing discussion to coordinate the work between
    the two groups.


    None received.