Differences from Previous Versions
The original NTP, later called NTP Version 0, was described in RFC-958 [MIL85c]. Subsequently, Version 0 was superseded by Version 1
(RFC-1059 [MIL88a]), and Version 2 (RFC-1119 [MIL89]. The Version-2 description was split into two documents, RFC-1119 defining the
architecture and specifying the protocol and algorithms, and another [MIL90b] describing the service model, algorithmic analysis and
operating experience. In previous versions these two objectives were combined in one document. While the architecture assumed in
Version 3 is identical to Version 2, the protocols and algorithms differ in minor ways. Differences between NTP Version 3 and previous
versions are described in this Appendix. Due to known bugs in very old implementations, continued support for Version-0
implementations is not recommended. It is recommended that new implementations follow the guidelines below when interoperating with
Version 3 neither changes the protocol in any significant way nor obsoletes previous versions or existing implementations. The main
motivation for the new version is to refine the analysis and implementation models for new applications at much higher network speeds
to the gigabit-per-second regime and to provide for the enhanced stability, accuracy and precision required at such speeds. In
particular, the sources of time and frequency errors have been rigorously examined and error bounds established in order to improve
performance, provide a model for correctness assertions and indicate timekeeping quality to the user. Version 3 also incorporates two
new optional features, (1) an algorithm to combine the offsets of a number of peer time servers in order to enhance accuracy and (2)
improved local-clock algorithms which allow the poll intervals on all synchronization paths to be substantially increased in order to
reduce network overhead. Following is a summary of previous versions of the protocol together with details of the Version 3
||1. Version 1 supports no modes other than
symmetric-active and symmetric-passive, which are determined by inspecting the port-number fields of the UDP packet header. The peer
mode can be determined explicitly from the packet-mode variable (pkt.mode) if it is nonzero and implicitly from the source port
(pkt.peerport) and destination port (pkt.hostport) variables if it is zero. For the case where pkt.mode is zero the mode is determined
Note that it is not possible in this case to distinguish between symmetric active and symmetric passive modes. Use of the pkt.mode and
NTP.PORT variables in this way is not recommended and may not be supported in future versions of the protocol. The low-order three
bits of the first octet, specified as zero in Version 1, are used for the mode field in Version 2. Version-2 and Version-3
implementations interoperating with Version-1 implementations should operate in a passive mode only and use the value one in the
version number (pkt.version) field and zero in the mode (pkt.mode) field in transmitted messages.
||2. Version 1 does not support the NTP control
message described in Appendix B. Certain old versions of the Unix NTP daemon ntpd use the high-order bits of the stratum field
(pkt.stratum) for control and monitoring purposes. While these bits are never set during normal Version-1, Version-2 or Version-3
operations, new implementations may use the NTP reserved mode 6 described in Appendix B and/or private reserved mode 7 for special
purposes, such as remote control and monitoring, and in such cases the format of the packet following the first octet can be
arbitrary. While there is no guarantee that different implementations can interoperate using private reserved mode 7, it is
recommended that vanilla ASCII format be used whenever possible.
||3. Version 1 does not support authentication. The
key identifiers, cryptographic keys and procedures described in Appendix C are new to Version 2 and continued in Version 3, along with
the corresponding variables, procedures and authenticator fields. In the NTP message described in Appendix A and NTP control message
described in Appendix B the format and contents of the header fields are independent of the authentication mechanism and the
authenticator itself follows the header fields, so that previous versions will ignore the authenticator.
||4. In Version 1 the total dispersion
(pkt.rootdispersion) field of the NTP header was called the estimated drift rate, but not used in the protocol or timekeeping
procedures. Implementations of the Version-1 protocol typically set this field to the current value of the skew-compensation register,
which is a signed quantity. In a Version 2 implementation apparent large values in this field may affect the order considered in the
clock-selection procedure. Version-2 and Version-3 implementations interoperating with older implementations should assume this field
is zero, regardless of its actual contents.
||5. Version 2 and Version 3 incorporate several
sanity checks designed to avoid disruptions due to unsynchronized, duplicate or bogus timestamp information. The checks in Version 3
are specifically designed to detect lost or duplicate packets and resist invalid timestamps. The leap-indicator bits are set to show
the unsynchronized state if updates are not received from a reference source for a considerable time or if the reference source has
not received updates for a considerable time. Some Version-1 implementations could claim valid synchronization indefinitely following
loss of the reference source.
||6. The clock-selection procedure of Version 2 was
considerably refined as the result of accumulated experience with the Version-1 implementation. Additional sanity checks are included
for authentication, range bounds and to avoid use of very old data. The candidate list is sorted twice, once to select a relatively
few robust candidates from a potentially large population of unruly peers and again to order the resulting list by measurement
quality. As in Version 1, The final selection procedure repeatedly casts out outlyers on the basis of weighted dispersion.
||7. The local-clock procedure of Version 2 were
considerably improved over Version 1 as the result of analysis, simulation and experience. Checks have been added to warn that the
oscillator has gone too long without update from a reference source. The compliance register has been added to improve frequency
stability to the order of a millisecond per day. The various parameters were retuned for optimum loop stability using measured data
over typical Internet paths and with typical local-clock hardware. In version 3 the phase-lock loop model was further refined to
provide an adaptive-bandwidth feature that automatically adjusts for the inherent stabilities of the reference clock and local clock
while providing optimum loop stability in each case.
||8. Problems in the timekeeping calculations of
Version 1 with high-speed LANs were found and corrected in Version 2. These were caused by jitter due to small differences in clock
rates and different precisions between the peers. Subtle bugs in the Version-1 reachability and polling-rate control were found and
corrected. The peer.valid and sys.hold variables were added to avoid instabilities when the reference source changes rapidly due to
large dispersive delays under conditions of severe network congestion. The peer.config, peer.authenable and peer.authentic bits were
added to control special features and simplify configuration.
||9. In Version 3 The local-clock algorithm has been
overhauled to improve stability and accuracy. Appendix G presents a detailed mathematical model and design example which has been
refined with the aid of feedback-control analysis and extensive simulation using data collected over ordinary Internet paths. Section
5 of RFC-1119 on the NTP local clock has been completely rewritten to describe the new algorithm. Since the new algorithm can result
in message rates far below the old ones, it is highly recommended that they be used in new implementations. Note that this algorithm
is not integral to the NTP protocol specification itself and its use does not affect interoperability with previous versions or
existing implementations; however, in order to insure overall NTP subnet stability in the Internet, it is essential that the
local-clock characteristics of all NTP time servers conform to the analytical models presented previously and in this document.
||10. In Version 3 a new algorithm to combine the
offsets of a number of peer time servers is presented in Appendix F. This algorithm is modelled on those used by national standards
laboratories to combine the weighted offsets from a number of standard clocks to construct a synthetic laboratory time scale more
accurate than that of any clock separately. It can be used in an NTP implementation to improve accuracy and stability and reduce
errors due to asymmetric paths in the Internet. The new algorithm has been simulated using data collected over ordinary Internet paths
and, along with the new local-clock algorithm, implemented and tested in the Fuzzball time servers now running in the Internet. Note
that this algorithm is not integral to the NTP protocol specification itself and its use does not affect interoperability with
previous versions or existing implementations.
||11. Several inconsistencies and minor errors in
previous versions have been corrected in Version 3. The description of the procedures has been rewritten in pseudo-code augmented by
English commentary for clarity and to avoid ambiguity. Appendix I has been added to illustrate C-language implementations of the
various filtering and selection algorithms suggested for NTP. Additional information is included in Section 5 and in Appendix E, which
includes the tutorial material formerly included in Section 2 of RFC-1119, as well as much new material clarifying the interpretation
of timescales and leap seconds.
||12. Minor changes have been made in the Version-3
local-clock algorithms to avoid problems observed when leap seconds are introduced in the UTC time scale and also to support an
auxiliary precision oscillator, such as a cesium clock or timing receiver, as a precision time base. In addition, changes were made to
some procedures described in Section 3 and in the clock-filter and clock-selection procedures described in Section 4. While these
changes were made to correct minor bugs found as the result of experience and are recommended for new implementations, they do not
affect interoperability with previous versions or existing implementations in other than minor ways (at least until the next leap
||13. In Version 3 changes were made to the way
delay, offset and dispersion are defined, calculated and processed in order to reliably bound the errors inherent in the time-transfer
procedures. In particular, the error accumulations were moved from the delay computation to the dispersion computation and both
included in the clock filter and selection procedures. The clock-selection procedure was modified to remove the first of the two
sorting/discarding steps and replace with an algorithm first proposed by Marzullo and later incorporated in the Digital Time Service.
These changes do not significantly affect the ordinary operation of or compatibility with various versions of NTP, but they do provide
the basis for formal statements of correctness as described in Appendix H.