3 - 4 - 6 - 8 - 9 - A - B - C - D - E - F - G - H - I - K - L - M - N - O - P - Q - R - S - T - U - V - W
version
Click on the red underlined text to get to the source
... This document constitutes a formal specification of the Network Time
Protocol (NTP) Version 3, which is used to synchronize timekeeping among
a set of distributed time servers and clients ...
... [MIL85c], but
has since evolved in significant ways, culminating in the most recent
NTP Version 2 described in RFC-1119(-> 1305draft) [MIL89]. It is built on the Internet
Protocol ...
... authentication mechanism which can
be used to control access and prevent unauthorized data modification,
while Appendix D contains a listing of differences between Version 3 of
NTP and previous versions. Appendix E expands on issues involved with
...
... while Appendix D contains a listing of differences between Version 3 of
NTP and previous versions. Appendix E expands on issues involved with
precision timescales and calendar dating peculiar to computer networks ...
... with time) between them. Real clocks exhibit some variation in skew
(second derivative of offset with time), which is called drift; however,
in this version of the specification the drift is assumed zero.
...
... represent the contents of the NTP message; and parameters, which
represent fixed configuration constants for all implementations of the
current version. For each class the description of the variable is
followed by its name and the procedure or value which controls it. Note
...
...
Version Number (pkt.version): This is an integer indicating the version
number of the sender ...
... Version Number (pkt.version): This is an integer indicating the version
number of the sender. NTP messages will always be sent with the current
version ...
... version
number of the sender. NTP messages will always be sent with the current
version number NTP.VERSION and will always be accepted if the version
number ...
... NTP messages will always be sent with the current
version number NTP.VERSION and will always be accepted if the version
number matches NTP.VERSION ...
... current
version number NTP.VERSION and will always be accepted if the version
number matches NTP.VERSION. Exceptions may be advised on a case-by-case
...
... VERSION and will always be accepted if the version
number matches NTP.VERSION. Exceptions may be advised on a case-by-case
basis at times when the version number is changed. Specific guidelines
...
... NTP.VERSION. Exceptions may be advised on a case-by-case
basis at times when the version number is changed. Specific guidelines
for interoperation between this version and previous versions ...
... basis at times when the version number is changed. Specific guidelines
for interoperation between this version and previous versions of NTP are
...
... version number is changed. Specific guidelines
for interoperation between this version and previous versions of NTP are
summarized in Appendix D.
...
... <$Eroman pkt.hostport~<<-~roman peer.peerport>;
<$Eroman pkt.leap~<<-~roman sys.leap>;
<$Eroman pkt.version~<<-~roman NTP.VERSION>;
...
... <$Eroman pkt.version~<<-~roman NTP.VERSION>;
<$Eroman pkt.mode~<<-~roman peer.mode>;
<$Eroman pkt.stratum~<<-~roman sys.stratum>;
...
... filter the data and select the synchronization source. If
the version number in the packet does not match the current version, the
message may be discarded; however, exceptions may be advised on a case-
...
... synchronization source. If
the version number in the packet does not match the current version, the
message may be discarded; however, exceptions may be advised on a case-
by-case basis at times when the version ...
... current version, the
message may be discarded; however, exceptions may be advised on a case-
by-case basis at times when the version is changed. If the NTP control
messages described in Appendix B are implemented and the packet mode is
...
...
If the packet mode is nonzero, this becomes the value of mode used in
the following step; otherwise, the peer is an old NTP version and mode
is determined from the port numbers as described in Section 3.3.
...
...
if (pkt.mode = 0) /* for
compatibility with old versions */
<$Emode~<<-~>(see Section 3.3);
else
...
... MIL88b] was written by
the author. Many individuals to numerous to mention meticulously tested
the several beta-test prototype versions and ruthlessly smoked out the
bugs, both in the code and the specification. Especially useful were
comments from Dennis Ferguson and Bill Sommerfeld, as well as
...
... Digital Time Service Functional Specification Version T.1.0.5. DigitalEquipment Corporation, 1989. ...
... Mills, D.L. Network Time Protocol (version 1) - specification andimplementation. DARPA Network Working Group ...
... Mills, D.L. Network Time Protocol (version 2) - specification andimplementation. DARPA Network Working Group ...
... not appear that specific standards and implementations will happen
within the lifetime of this particular version of NTP.
...
... replay attacks and keying errors, as well as
facilitate testing and migration to new versions. The crypto-checksum is
calculated using the 64-bit ...
... Appendix D. Differences from Previous Versions. ...
...
The original NTP, later called NTP Version 0, was described in RFC-958(-> 1305draft | 1119(-> 1305draft) | 1059(-> 1305draft | 1119(-> 1305draft)))
[MIL85c ...
... 958(-> 1305draft | 1119(-> 1305draft) | 1059(-> 1305draft | 1119(-> 1305draft)))
[MIL85c]. Subsequently, Version 0 was superseded by Version 1 (RFC-1059(-> 1305draft | 1119(-> 1305draft))
...
... [MIL85c]. Subsequently, Version 0 was superseded by Version 1 (RFC-1059(-> 1305draft | 1119(-> 1305draft))
[MIL88a ...
... 1059(-> 1305draft | 1119(-> 1305draft))
[MIL88a]), and Version 2 (RFC-1119(-> 1305draft) [MIL89]. The Version ...
... Version 2 (RFC-1119(-> 1305draft) [MIL89]. The Version-2 description
was split into two documents, RFC-1119(-> 1305draft) defining the architecture ...
... 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 ...
... 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 ...
... While the architecture assumed in Version 3 is identical to Version 2,
the protocols and algorithms differ in minor ways. Differences between
...
... ,
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
...
... 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
...
... 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
older implementations.
...
...
Version 3 neither changes the protocol in any significant way nor
obsoletes previous versions or existing implementations. The main
...
...
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
...
... 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
...
... 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 ...
... 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 changes.
...
... overhead. Following is a summary of previous versions of the
protocol together with details of the Version 3 changes.
...
...
Version 1 supports no modes other than symmetric-active and symmetric-
passive, which are determined by inspecting the ...
... 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 ...
... 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 ...
... 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
...
... Version 1, are used for the
mode field in Version 2. Version-2 and Version-3 implementations
interoperating with Version ...
... mode field in Version 2. Version-2 and Version-3 implementations
interoperating with Version-1 implementations should operate in a
...
... 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
...
... 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
...
... 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.
...
... 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
...
... 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 ...
... purposes. While these bits are never set during normal Version-1,
Version-2 or Version-3 operations, new implementations may use the NTP
...
... 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
...
... 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 ...
... 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 ...
... authentication mechanism and the authenticator itself follows the header
fields, so that previous versions will ignore the authenticator.
...
...
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
...
...
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 ...
... -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 ...
... 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
...
... 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.
...
...
Version 2 and Version 3 incorporate several sanity checks designed to
avoid disruptions due to unsynchronized, duplicate or bogus timestamp ...
... 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-
...
... 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
...
...
The clock-selection procedure of Version 2 was considerably refined as
the result of accumulated experience with the Version-1 implementation.
...
... 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 ...
... 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.
...
...
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
...
...
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 ...
... 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
...
...
Problems in the timekeeping calculations of Version 1 with high-speed
LANs were found and corrected in ...
... 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 ...
... 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 ...
...
In Version 3 The local-clock algorithm has been overhauled to improve
stability and accuracy. Appendix G presents a detailed mathematical
...
...
itself and its use does not affect interoperability with previous
versions or existing implementations; however, in order to insure
overall NTP subnet ...
...
itself and its use does not affect interoperability with previous
versions or existing implementations.
...
...
Several inconsistencies and minor errors in previous versions have been
corrected in Version 3. The description of the procedures has been
...
... 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
...
...
Minor changes have been made in the Version-3 local-clock algorithms to
avoid problems observed when leap seconds are introduced in the UTC ...
... 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
second).
...
...
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
...
... 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
...