+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Identifier (optional) (32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
| Message Digest (optional) (128) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1. NTP Packet Header
Leap Indicator (LI): This is a two-bit code warning of an impending
leap second to be inserted/deleted in the last minute of the current
day. This field is significant only in server messages, where the
values are defined as follows:
LI Meaning
---------------------------------------------
0 no warning
1 last minute has 61 seconds
2 last minute has 59 seconds
3 alarm condition (clock not synchronized)
On startup, servers set this field to 3 (clock not synchronized), and
set this field to some other value when synchronized to the primary
reference clock. Once set to a value other than 3, the field is
never set to that value again, even if all synchronization sources
become unreachable or defective.
Version Number (VN): This is a three-bit integer indicating the
NTP/SNTP version number, currently 4. If necessary to distinguish
between IPv4, IPv6, and OSI, the encapsulating context must be
inspected.
Mode: This is a three-bit number indicating the protocol mode. The
values are defined as follows:
Mode Meaning
------------------------------------
0 reserved
1 symmetric active
2 symmetric passive
3 client
4 server
5 broadcast
6 reserved for NTP control message
7 reserved for private use
In unicast and manycast modes, the client sets this field to 3
(client) in the request, and the server sets it to 4 (server) in the
reply. In broadcast mode, the server sets this field to 5
(broadcast). The other modes are not used by SNTP servers and
clients.
Stratum: This is an eight-bit unsigned integer indicating the
stratum. This field is significant only in SNTP server messages,
where the values are defined as follows:
Stratum Meaning
----------------------------------------------
0 kiss-o’-death message (see below)
1 primary reference (e.g., synchronized by radio clock)
2-15 secondary reference (synchronized by NTP or SNTP)
16-255 reserved
Poll Interval: This is an eight-bit unsigned integer used as an
exponent of two, where the resulting value is the maximum interval
between successive messages in seconds. This field is significant
only in SNTP server messages, where the values range from 4 (16 s) to
17 (131,072 s -- about 36 h).
Precision: This is an eight-bit signed integer used as an exponent of
two, where the resulting value is the precision of the system clock
in seconds. This field is significant only in server messages, where
the values range from -6 for mains-frequency clocks to -20 for
microsecond clocks found in some workstations.
Root Delay: This is a 32-bit signed fixed-point number indicating the
total roundtrip delay to the primary reference source, in seconds
with the fraction point between bits 15 and 16. Note that this
variable can take on both positive and negative values, depending on
the relative time and frequency offsets. This field is significant
only in server messages, where the values range from negative values
of a few milliseconds to positive values of several hundred
milliseconds.
Code External Reference Source
------------------------------------------------------------------
LOCL uncalibrated local clock
CESM calibrated Cesium clock
RBDM calibrated Rubidium clock
PPS calibrated quartz clock or other pulse-per-second
source
IRIG Inter-Range Instrumentation Group
ACTS NIST telephone modem service
USNO USNO telephone modem service
PTB PTB (Germany) telephone modem service
TDF Allouis (France) Radio 164 kHz
DCF Mainflingen (Germany) Radio 77.5 kHz
MSF Rugby (UK) Radio 60 kHz
WWV Ft. Collins (US) Radio 2.5, 5, 10, 15, 20 MHz
WWVB Boulder (US) Radio 60 kHz
WWVH Kauai Hawaii (US) Radio 2.5, 5, 10, 15 MHz
CHU Ottawa (Canada) Radio 3330, 7335, 14670 kHz
LORC LORAN-C radionavigation system
OMEG OMEGA radionavigation system
GPS Global Positioning Service
Figure 2. Reference Identifier Codes
Root Dispersion: This is a 32-bit unsigned fixed-point number
indicating the maximum error due to the clock frequency tolerance, in
seconds with the fraction point between bits 15 and 16. This field
is significant only in server messages, where the values range from
zero to several hundred milliseconds.
Reference Identifier: This is a 32-bit bitstring identifying the
particular reference source. This field is significant only in
server messages, where for stratum 0 (kiss-o’-death message) and 1
(primary server), the value is a four-character ASCII string, left
justified and zero padded to 32 bits. For IPv4 secondary servers,
the value is the 32-bit IPv4 address of the synchronization source.
For IPv6 and OSI secondary servers, the value is the first 32 bits of
the MD5 hash of the IPv6 or NSAP address of the synchronization
source.
Primary (stratum 1) servers set this field to a code identifying the
external reference source according to Figure 2. If the external
reference is one of those listed, the associated code should be used.
Codes for sources not listed can be contrived, as appropriate.
In previous NTP and SNTP secondary servers and clients, this field
was often used to walk-back the synchronization subnet to the root
(primary server) for management purposes. In SNTPv4 with IPv6 or
OSI, this feature is not available, because the addresses are
longer than 32 bits, and only a hash is available. However, a
walk-back can be accomplished using the NTP control message and
the reference identifier field described in RFC 1305.
Reference Timestamp: This field is the time the system clock was last
set or corrected, in 64-bit timestamp format.
Originate Timestamp: This is the time at which the request departed
the client for the server, in 64-bit timestamp format.
Receive Timestamp: This is the time at which the request arrived at
the server or the reply arrived at the client, in 64-bit timestamp
format.
Transmit Timestamp: This is the time at which the request departed
the client or the reply departed the server, in 64-bit timestamp
format.
Authenticator (optional): When the NTP authentication scheme is
implemented, the Key Identifier and Message Digest fields contain the
message authentication code (MAC) information defined in Appendix C
of RFC 1305.
5. SNTP Client Operations
An SNTP client can operate in unicast, broadcast, or manycast modes.
In unicast mode, the client sends a request (NTP mode 3) to a
designated unicast server and expects a reply (NTP mode 4) from that
server. In broadcast client mode, it sends no request and waits for
a broadcast (NTP mode 5) from one or more broadcast servers. In
manycast mode, the client sends a request (NTP mode 3) to a
designated broadcast address and expects a reply (NTP mode 4) from
one or more manycast servers. The client uses the first reply
received to establish the particular server for subsequent unicast
operations. Later replies from this server (duplicates) or any other
server are ignored. Other than the selection of address in the
request, the operations of manycast and unicast clients are
identical.
Client requests are normally sent at intervals depending on the
frequency tolerance of the client clock and the required accuracy.
However, under no conditions should requests be sent at less than
one minute intervals. Further discussion on this point is in
Section 9.
A unicast or manycast client initializes the NTP message header,
sends the request to the server, and strips the time of day from the
Transmit Timestamp field of the reply. For this purpose, all the NTP
header fields shown above are set to 0, except the Mode, VN, and
optional Transmit Timestamp fields.
NTP and SNTP clients set the mode field to 3 (client) for unicast and
manycast requests. They set the VN field to any version number that
is supported by the server, selected by configuration or discovery,
and that can interoperate with all previous version NTP and SNTP
servers. Servers reply with the same version as the request, so the
VN field of the request also specifies the VN field of the reply. A
prudent SNTP client can specify the earliest acceptable version on
the expectation that any server of that or a later version will
respond. NTP Version 3 (RFC 1305) and Version 2 (RFC 1119) servers
accept all previous versions, including Version 1 (RFC 1059). Note
that Version 0 (RFC 959) is no longer supported by current and future
NTP and SNTP servers.
Although setting the Transmit Timestamp field in the request to the
time of day according to the client clock in NTP timestamp format is
not necessary in a conforming client implementation, it is highly
recommended in unicast and manycast modes. This allows a simple
calculation to determine the propagation delay between the server and
client and to align the system clock generally within a few tens of
milliseconds relative to the server. In addition, this provides a
simple method for verifying that the server reply is in fact a
legitimate response to the specific client request and thereby for
avoiding replays. In broadcast mode, the client has no information
to calculate the propagation delay or to determine the validity of
the server, unless one of the NTP authentication schemes is used.
To calculate the roundtrip delay d and system clock offset t relative
to the server, the client sets the Transmit Timestamp field in the
request to the time of day according to the client clock in NTP
timestamp format. For this purpose, the clock need not be
synchronized. The server copies this field to the Originate
Timestamp in the reply and sets the Receive Timestamp and Transmit
Timestamp fields to the time of day according to the server clock in
NTP timestamp format.
When the server reply is received, the client determines a
Destination Timestamp variable as the time of arrival according to
its clock in NTP timestamp format. The following table summarizes
the four timestamps.
Timestamp Name ID When Generated
------------------------------------------------------------
Originate Timestamp T1 time request sent by client
Receive Timestamp T2 time request received by server
Transmit Timestamp T3 time reply sent by server
Destination Timestamp T4 time reply received by client
The roundtrip delay d and system clock offset t are defined as:
d = (T4 - T1) - (T3 - T2) t = ((T2 - T1) + (T3 - T4)) / 2.
Note that in general both delay and offset are signed quantities and
can be less than zero; however, a delay less than zero is possible
only in symmetric modes, which SNTP clients are forbidden to use.
The following table summarizes the required SNTP client operations in
unicast, manycast, and broadcast modes. The recommended error checks
are shown in the Reply and Broadcast columns in the table. The
message should be considered valid only if all the fields shown
contain values in the respective ranges. Whether to believe the
message if one or more of the fields marked "ignore" contain invalid
values is at the discretion of the implementation.
Field Name Unicast/Manycast Broadcast
Request Reply
---------------------------------------------------------------
LI 0 0-3 0-3
VN 1-4 copied from 1-4
request
Mode 3 4 5
Stratum 0 0-15 0-15
Poll 0 ignore ignore
Precision 0 ignore ignore
Root Delay 0 ignore ignore
Root Dispersion 0 ignore ignore
Reference Identifier 0 ignore ignore
Reference Timestamp 0 ignore ignore
Originate Timestamp 0 (see text) ignore
Receive Timestamp 0 (see text) ignore
Transmit Timestamp (see text) nonzero nonzero
Authenticator optional optional optional
Although not required in a conforming SNTP client implementation, it
is wise to consider a suite of sanity checks designed to avoid
various kinds of abuse that might happen as the result of server
implementation errors or malicious attack. Following is a list of
suggested checks.
1. When the IP source and destination addresses are available for
the client request, they should match the interchanged addresses
in the server reply.
2. When the UDP source and destination ports are available for the
client request, they should match the interchanged ports in the
server reply.
3. The Originate Timestamp in the server reply should match the
Transmit Timestamp used in the client request.
4. The server reply should be discarded if any of the LI, Stratum,
or Transmit Timestamp fields is 0 or the Mode field is not 4
(unicast) or 5 (broadcast).
5. A truly paranoid client can check that the Root Delay and Root
Dispersion fields are each greater than or equal to 0 and less
than infinity, where infinity is currently a cozy number like one
second. This check avoids using a server whose synchronization
source has expired for a very long time.
6. SNTP Server Operations
A SNTP server operating with either an NTP or SNTP client of the same
or previous versions retains no persistent state. Because an SNTP
server ordinarily does not implement the full suite of grooming and
mitigation algorithms intended to support redundant servers and
diverse network paths, it should be operated only in conjunction with
a source of external synchronization, such as a reliable radio clock
or telephone modem. In this case it operates as a primary (stratum
1) server.
A SNTP server can operate with any unicast, manycast, or broadcast
address or any combination of these addresses. A unicast or manycast
server receives a request (NTP mode 3), modifies certain fields in
the NTP header, and sends a reply (NTP mode 4), possibly using the
same message buffer as the request. A manycast server listens on the
designated broadcast address, but uses its own unicast IP address in
the source address field of the reply. Other than the selection of
address in the reply, the operations of manycast and unicast servers
are identical. Broadcast messages are normally sent at intervals
from 64 s to 1024 s, depending on the expected frequency tolerance of
the client clocks and the required accuracy.
Unicast and manycast servers copy the VN and Poll fields of the
request intact to the reply and set the Stratum field to 1.
Note that SNTP servers normally operate as primary (stratum 1)
servers. Although operating at higher strata (up to 15) while
synchronizing to an external source such as a GPS receiver is not
forbidden, this is strongly discouraged.
If the Mode field of the request is 3 (client), the reply is set to 4
(server). If this field is set to 1 (symmetric active), the reply is
set to 2 (symmetric passive). This allows clients configured in
either client (NTP mode 3) or symmetric active (NTP mode 1) to
interoperate successfully, even if configured in possibly suboptimal
ways. For any other value in the Mode field, the request is
discarded. In broadcast (unsolicited) mode, the VN field is set to
4, the Mode field is set to 5 (broadcast), and the Poll field set to
the nearest integer base-2 logarithm of the poll interval.
Note that it is highly desirable that a broadcast server also
supports unicast clients. This is so a potential broadcast client
can calculate the propagation delay using a client/server exchange
prior to switching to broadcast client (listen-only) mode. By
design, a manycast server is also a unicast server. There does
not seem to be a great advantage for a server to operate as both
broadcast and manycast at the same time, although the protocol
specification does not forbid it.
A broadcast or manycast server does not send packets if not
synchronized to a correctly operating reference source. It may or
may not respond to a client request if it is not synchronized, but
the preferred option is to respond because this allows reachability
to be determined regardless of synchronization state. If the server
has never synchronized to a reference source, the LI field is set to
3 (unsynchronized). Once synchronized to a reference source, the LI
field is set to one of the other three values and remains at the last
value set even if the reference source becomes unreachable or turns
faulty.
If the server is synchronized to a reference source, the Stratum
field is set to 1, and the Reference Identifier field is set to the
ASCII source identifier shown in Figure 2. If the server is not
synchronized, the Stratum field is set to zero, and the Reference
Identifier field is set to an ASCII error identifier described below.
The Precision field is set to reflect the maximum reading error of
the system clock. For all practical cases it is computed as the
negative base-2 logarithm of the number of significant bits to the
right of the decimal point in the NTP timestamp format. The Root
Delay and Root Dispersion fields are set to 0 for a primary server.
The timestamp fields in the server message are set as follows. If
the server is unsynchronized or first coming up, all timestamp fields
are set to zero, with one exception. If the message is a reply to a
previously received client request, the Transmit Timestamp field of
the request is copied unchanged to the Originate Timestamp field of
the reply. It is important that this field be copied intact, as an
NTP or SNTP client uses it to avoid bogus messages.
If the server is synchronized, the Reference Timestamp is set to the
time the last update was received from the reference source. The
Originate Timestamp field is set as in the unsynchronized case above.
The Transmit Timestamp field is set to the time of day when the
message is sent. In broadcast messages the Receive Timestamp field
is set to zero and copied from the Transmit Timestamp field in other
messages. The following table summarizes these actions.
Field Name Unicast/Manycast Broadcast
Request Reply
----------------------------------------------------------------
LI ignore as needed as needed
VN 1-4 copied from 4
request
Mode 3 4 5
Stratum ignore 1 1
Poll ignore copied from log2 poll
request interval
Precision ignore -log2 server -log2 server
significant significant
bits bits
Root Delay ignore 0 0
Root Dispersion ignore 0 0
Reference Identifier ignore source ident source ident