Internet Engineering Task Force M. Lichvar
Internet-Draft Red Hat
Intended status: Standards Track 13 February 2025
Expires: 17 August 2025
Network Time Protocol Version 5
draft-ietf-ntp-ntpv5-03
Abstract
This document describes the version 5 of the Network Time Protocol
(NTP).
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 17 August 2025.
Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Lichvar Expires 17 August 2025 [Page 1]
Internet-Draft Network Time Protocol Version 5 February 2025
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Basic Concepts . . . . . . . . . . . . . . . . . . . . . . . 4
3. Data Types . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Message Format . . . . . . . . . . . . . . . . . . . . . . . 5
5. Extension Fields . . . . . . . . . . . . . . . . . . . . . . 9
5.1. Draft Identification Extension Field . . . . . . . . . . 10
5.2. Padding Extension Field . . . . . . . . . . . . . . . . . 11
5.3. MAC Extension Field . . . . . . . . . . . . . . . . . . . 11
5.4. Reference IDs Request and Response Extension Fields . . . 11
5.5. Server Information Extension Field . . . . . . . . . . . 13
5.6. Correction Extension Field . . . . . . . . . . . . . . . 14
5.7. Reference Timestamp Extension Field . . . . . . . . . . . 17
5.8. Monotonic Receive Timestamp Extension Field . . . . . . . 18
5.9. Secondary Receive Timestamp Extension Field . . . . . . . 19
6. Measurement Modes . . . . . . . . . . . . . . . . . . . . . . 20
7. Client Operation . . . . . . . . . . . . . . . . . . . . . . 23
8. Server Operation . . . . . . . . . . . . . . . . . . . . . . 25
9. Network Time Security with NTPv5 . . . . . . . . . . . . . . 27
10. NTPv5 Negotiation in previous NTP versions . . . . . . . . . 28
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
13. Security Considerations . . . . . . . . . . . . . . . . . . . 31
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
14.1. Normative References . . . . . . . . . . . . . . . . . . 31
14.2. Informative References . . . . . . . . . . . . . . . . . 31
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 32
1. Introduction
Network Time Protocol (NTP) is a protocol which enables computers to
synchronize their clocks over network. Time is distributed from
primary time servers to clients, which can be servers for other
clients, and so on. Clients can use multiple servers simultaneously
to improve reliability, stability, and accuracy of synchronization.
NTPv5 is very similar to NTPv4 [RFC5905]. The main differences are:
1. The protocol specification (this document) describes only the
on-wire protocol. Filtering of measurements, security
mechanisms, source selection, clock control, and other
algorithms, are out of scope.
2. For security reasons, NTPv5 drops support for the symmetric
active, symmetric passive, broadcast, control, and private
modes. The symmetric and broadcast modes are vulnerable to
Lichvar Expires 17 August 2025 [Page 2]
Internet-Draft Network Time Protocol Version 5 February 2025
replay attacks. The control and private modes can be exploited
for denial-of-service traffic amplification attacks. Only the
client and server modes remain in NTPv5.
3. Timestamps are clearly separated from values used as cookies.
4. Synchronized server clock is indicated in a separate flag
instead of the leap indicator.
5. NTPv5 messages can be extended only with extension fields. The
MAC field is wrapped in an extension field to avoid an ambiguity
in parsing of the NTP message, which was later addressed for
NTPv4 in RFC 7822 [RFC7822].
6. Extension fields can be of any length, even indivisible by 4,
but are padded to a multiple of 4 octets. Extension fields
specified for NTPv4 are compatible with NTPv5.
7. NTPv5 adds support for other timescales than UTC.
8. The NTP era number is exchanged in the protocol, which extends
the unambiguous time interval from 136 years to about 35000
years.
9. NTPv5 adds a flag to clearly identify the use of interleaved
mode instead of comparing timestamps or cookies.
10. NTPv5 works with sets of reference IDs to prevent
synchronization loops over multiple hosts, even if they form
over other NTP sources than the system peer. Reference IDs have
120 bits instead of 32 bits to minimize the rate of false
positives.
11. Resolution of the root delay and root dispersion fields is
improved from about 15 microseconds to about 4 nanoseconds.
12. Clients do not leak information about their clock (e.g.
timestamps, estimated accuracy).
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
Lichvar Expires 17 August 2025 [Page 3]
Internet-Draft Network Time Protocol Version 5 February 2025
2. Basic Concepts
An NTP client is exchanging messages with one or more NTP servers,
each timestamping transmission and reception of every message it
sends and receives. The servers provide their timestamps to the
client. From the timestamps the client captured and received from
its servers it can calculate the offset and network delay of its
clock relative to the servers' clocks.
The distance to the reference time sources in the hierarchy of
servers is called stratum. Primary time servers, which are
synchronized to the reference clocks, are stratum 1, their clients
are stratum 2, and so on.
Root delay measures the total delay on the path to the reference time
source used by the primary time server. Each client on the path adds
to the root delay the NTP delay measured to the server it considers
best for synchronization. The delay includes network delays and any
delays between timestamping of NTP messages and their actual
reception and transmission. Half of the root delay estimates the
maximum error of the clock due to asymmetries in the delay.
Root dispersion estimates the maximum error of the clock due to the
instability of the clocks on the path and instability of NTP
measurements. Each server on the path adds its own dispersion to the
root dispersion. Different clock models can be used. In a simple
model, the clock can have a constant dispersion rate, e.g. 15 ppm as
defined for NTPv4.
The sum of the root dispersion and half of the root delay is called
root distance. It is an estimate of the maximum time error of the
clock, assuming the modeled stability of the clock and a worst-case
asymmetry in the network delay.
A loop can form between clients if they try to synchronize to each
other, directly or indirectly over other servers. A synchronization
loop is an undesired state in an NTP network. It creates a positive
feedback loop and can negatively impact stability of synchronization.
To enable detection and prevention of synchronization loops, servers
have randomly generated reference IDs, which are exchanged in NTP
messages.
3. Data Types
NTPv5 uses few different data types. They are all in the network
order. Beside signed and unsigned integers, it has also the
following fixed-point types:
Lichvar Expires 17 August 2025 [Page 4]
Internet-Draft Network Time Protocol Version 5 February 2025
time32
A 32-bit unsigned fixed-point type containing values in seconds.
It has 4 bits describing the unsigned integral part and 28 bits
describing the fractional part. The maximum value is 16 seconds
and the resolution is about 3.7 nanoseconds. Note that this is
different from the 32-bit time format in NTPv4.
timestamp64
A 64-bit unsigned fixed-point type containing a timestamp
describes in seconds. It has 32 signed integer bits and 32
fractional bits. It spans an interval of about 136 years and has
a resolution of about 0.23 nanoseconds. It can be used in
different timescales. In the UTC timescale it is the number of SI
seconds since 1 Jan 1972 plus 2272060800 (number of seconds since
1 Jan 1900 assuming 86400-second days), excluding leap seconds.
Timestamps in the TAI timescale are the same except they include
leap seconds and extra 10 seconds for the original difference
between TAI and UTC in 1972, when leap seconds were introduced. A
value of 0 indicates an unknown or invalid timestamp. One
interval covered by the type is called an NTP era. The era
starting at the epoch is era number 0, the following era is number
1, and so on.
Some fields use a logarithmic scale, where an 8-bit signed integer
represents the rounded log2 value of seconds. For example, a log2
value of 4 is 2^4 (2 to the power of 4, 16) seconds, or a log2 value
of -2 is 2^-2 (0.25 seconds).
4. Message Format
NTPv5 servers and clients exchange messages as UDP datagrams.
Clients send requests to servers and servers send them back
responses. The format of the UDP payload is shown in Figure 1.
Lichvar Expires 17 August 2025 [Page 5]
Internet-Draft Network Time Protocol Version 5 February 2025
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|LI | VN |Mode | Stratum | Poll | Precision |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timescale | Era | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Root Delay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Root Dispersion |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Server Cookie (64) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Client Cookie (64) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Receive Timestamp (64) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Transmit Timestamp (64) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Extension Field 1 (variable) .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Extension Field N (variable) .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Format of NTPv5 messages
Each NTPv5 message has a header containing the following fields:
Lichvar Expires 17 August 2025 [Page 6]
Internet-Draft Network Time Protocol Version 5 February 2025
Leap indicator (LI)
A 2-bit field indicating upcoming leap seconds. In requests it is
always 0. In responses it has one of the following values:
0: Normal
No leap second will be inserted or deleted in the next 14 days,
or the server is responding in a leap-smeared timescale (i.e.
the client is not expected to be handling leap seconds).
1: Insert leap second
A leap second will be inserted in the next 14 days at the end
of the current month.
2: Delete leap second
A leap second will be deleted in the next 14 days at the end of
the current month.
3: Unknown
The server does not have a time source or other source
providing information about leap seconds.
Version Number (VN)
A 3-bit field containing the value 5.
Mode
A 3-bit field containing the value 3 (request) or 4 (response).
Stratum
An 8-bit field containing the stratum of the server. Primary time
servers have a stratum of 1, their clients have a stratum of 2,
and so on. The value of 0 indicates an unknown or infinite
stratum. In requests it is always 0. When 0 in a response, it
indicates the server was unable or unwilling to provide valid time
information. Servers advertising a stratum above 16 should not be
synchronized to except when the client is explicitly configured to
do so by the end-user.
Poll
An 8-bit signed integer containing the polling interval as a
rounded log2 value in seconds. In requests it is the current
polling interval. In responses it is the minimum allowed polling
interval. This field is valid even when stratum is 0. A value of
127 indicates the server does not want to hear from the client
again.
Lichvar Expires 17 August 2025 [Page 7]
Internet-Draft Network Time Protocol Version 5 February 2025
Precision
An 8-bit signed integer containing the precision of the timestamps
included in the message as a rounded log2 value in seconds. In
requests, which do not contain any timestamps, it is always 0.
Timescale
An 8-bit identifier of the timescale. In requests it is the
requested timescale. In responses it is the timescale of the
receive and transmit timestamps. Defined values are:
0: UTC
1: TAI
2: UT1
3: Leap-smeared UTC
Era
An 8-bit unsigned NTP era number corresponding to the receive
timestamp. In requests it is always 0.
Flags
A 16-bit integer that can contain the following flags:
0x1: Synchronized
In requests it is 0. In responses a value of 1 indicates the
server's clock is synchronized and the provided timestamps can
be used by the client for its own synchronization.
0x2: Interleaved mode
In requests a value of 1 is a request for a response in the
interleaved mode. In responses a value of 1 indicates the
response is in the interleaved mode.
0x4: Authentication NAK
In requests it is 0. In responses a value of 1 indicates that
the server failed to authenticate the request. A server
setting this bit SHOULD also set the stratum of the message to
0.
Root Delay
A field using the time32 type. In responses it is the server's
root delay. In requests it is always 0.
Root Dispersion
A field using the time32 type. In responses it is the server's
root dispersion. In requests it is always 0.
Lichvar Expires 17 August 2025 [Page 8]
Internet-Draft Network Time Protocol Version 5 February 2025
Server Cookie
A 64-bit field containing a number generated by the server which
enables the interleaved mode. In requests it is 0, or a copy of
the server cookie from the last response.
Client Cookie
A 64-bit field containing a random number generated by the client.
Responses contain a copy of the field from the corresponding
request, which allows the client to verify that the responses are
related to the requests.
Receive Timestamp
A field using the timestamp64 type. In requests it is always 0.
In responses it is the time when the request was received by the
server. The timestamp corresponds to the end of the reception.
Transmit Timestamp
A field using the timestamp64 type. In requests it is always 0.
In responses it is the server's time denoting the beginning of the
transmission of a response to the client. Which response it
refers to depends on the selected mode (basic or interleaved).
See Measurement Modes (Section 6) for detail.
The header has 48 octets, which is the minimum length of a valid
NTPv5 message. A message can contain optional extension fields (zero
or more). The maximum length is not specified, but the length MUST
be divisible by 4.
5. Extension Fields
The format of NTPv5 extension fields is shown in Figure 2.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. Data (variable) .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Format of NTPv5 extension fields
Lichvar Expires 17 August 2025 [Page 9]
Internet-Draft Network Time Protocol Version 5 February 2025
Each extension field has a header which contains a 16-bit type and
16-bit length. The length is in octets and it includes the header.
The minimum length is 4, i.e. an extension field does not have to
contain any data. If the length is not divisible by 4, the extension
field is padded with zeros to the smallest multiple of 4 octets.
If a request contains an extension field, the server MUST include
this extension field in the response unless the specification of the
extension field states otherwise, or the server does not support the
extension field. A client can interpret the absence of an expected
extension field in a response as an indication that the server does
not support the extension field.
Extension fields specified for NTPv4 can be included in NTPv5
messages as specified for NTPv4.
The rest of this section describes extension fields specified for
NTPv5. Clients are not required to use or support any of these
extension fields, but servers are required to support the following
extension fields: Padding, Server Information, Reference IDs Request,
Reference IDs Response.
5.1. Draft Identification Extension Field
Note to the editors: this section must be removed before final
publication.
This field, with type 0xF5FF, is used to indicate which draft of the
specification an implementation is based upon. It MUST be included
in NTPv5 requests produced by an implementation based on a draft of
this specification, and MUST NOT be included in NTPv5 requests
produced by an implementation based on the final version of this
specification. Server MUST use this field if and only if responding
to a request containing this field and the server is a draft
implementation.
The contents of this field MUST be the full name, including version
number, of the draft upon which the implementation is based, encoded
as an ASCII string. If the server string is longer than the client
string, the server MUST NOT respond in that version to prevent
traffic amplification.
A server MUST NOT respond to requests with a draft identification it
does not recognize, and SHOULD respond with a response according to
the same draft specification as given by the client.
Lichvar Expires 17 August 2025 [Page 10]
Internet-Draft Network Time Protocol Version 5 February 2025
Note: the content of this field MUST NOT be null-terminated (the
extension field in the NTP message may need to be padded with up to 3
octets). When comparing the strings be compared in their full
length, i.e. a longer string containing a shorter string is not
sufficient.
5.2. Padding Extension Field
This field, with type [[TBD]] (draft: 0xF501), is used by servers to
pad the response to the same length as the request if the response
does not contain all requested extension fields, or some have a
variable length. It can have any length. The data field of the
extension field SHOULD contain zeros and it MUST be ignored by the
receiver.
This field MUST be supported on servers.
5.3. MAC Extension Field
This field, with type [[TBD]] (draft: 0xF502), authenticates the
NTPv5 message with a symmetric key. Implementations SHOULD use the
MAC specified in RFC8573 [RFC8573]. The extension field MUST be the
last extension field in the message unless an extension field is
specifically allowed to be placed after a MAC or another
authenticator field.
5.4. Reference IDs Request and Response Extension Fields
Each NTPv5 server has a randomly generated 120-bit reference ID (it
will be split into 10 12-bit values). The extension fields described
in this section are used to exchange sets of reference IDs in order
to detect synchronization loops, i.e. when a client is synchronizing
(directly or indirectly) to one of its own clients, or more generally
detect presence of a specific time source in the synchronization
chain.
As each client can be synchronized to an unlimited number of servers
(and there can be up to 15 strata of servers), the reference IDs are
exchanged as a Bloom filter [Bloom] instead of a list to limit the
amount of data that needs to be exchanged.
The Bloom filter is an array of 4096 bits. When empty, all bits are
zero. To add a reference ID to the filter, the 120-bit value of the
reference ID is split into 10 12-bit values and the bits of the array
at the 10 positions given by the 12-bit values are set to one.
Lichvar Expires 17 August 2025 [Page 11]
Internet-Draft Network Time Protocol Version 5 February 2025
A server maintains a copy of the filter for each server it is using
as an NTP client. The filter provided by the server to clients is
the union of the filters (using the bitwise OR operation) of the
server's sources selected for synchronization and the server's own
reference ID.
If the server uses a previous version of NTP for some of its sources,
the reference IDs added to the filter are generated from their IP
addresses as the first 120 bits of the MD5 [RFC1321] sum of the
address in network order. If the server uses a reference clock, the
reference ID is the first 120 bits of the MD5 sum of the 4-octet
zero-padded ASCII string from the NTP Reference Identifier Codes
registry maintained by IANA, or a string beginning with the uppercase
letter X, which are reserved for private and experimental use.
A client checking whether the server's set of reference IDs contains
the client's own reference ID checks whether the bits at the 10
positions corresponding to the 12-bit values from the reference ID
are all set to one.
When a client which serves time to other clients detects a
synchronization loop with one of its servers, it SHOULD stop using
the server for synchronization. When the client's reference ID is no
longer detected in the server's filter, it SHOULD wait for a random
number of polling intervals (e.g. between 0 and 4) before selecting
the server again. The random delay helps with stabilization of the
selection in longer loops.
False positives are possible. The probability of a collision grows
with the number of reference IDs in the filter. With 26 reference
IDs it is about 1e-12. With 118 IDs it is about 1e-6. The client
MAY avoid selecting a server which has too many bits set in the
filter (e.g. more than half) to reduce the probability of the
collision for its own clients. A client which detected a
synchronization loop MAY change its own reference ID to limit the
duration of the potential collision.
The filter can be exchanged as a single 512-octet array, or it can be
exchanged in smaller chunks over multiple NTP messages, making them
shorter, but delaying the detection of the synchronization loop.
The request extension field specifies the offset of the requested
chunk in the filter as a number of octets. The requested length of
the chunk is given by the length of data in the request extension
field. The response extension field MUST have the same length as the
request extension field. If the request contains an invalid offset
for the length, i.e. it is larger than 512 minus length of data in
the extension field, the extension field MUST be ignored.
Lichvar Expires 17 August 2025 [Page 12]
Internet-Draft Network Time Protocol Version 5 February 2025
The client SHOULD use requests of a constant length for the
association to avoid adding a variation to the measured NTP delay.
The format of the Reference IDs Request is shown in Figure 3.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = [[TBD]] (draft 0xF503) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Offset | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
. .
. Padding (variable) .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Format of Reference IDs Request Extension Field
The format of the Reference IDs Response is shown in Figure 4.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = [[TBD]] (draft 0xF504) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. Bloom filter chunk (variable) .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Format of Reference IDs Response Extension Field
These fields MUST be supported on servers which can be synchronized
to other NTP servers (i.e. they can be in a synchronization loop).
5.5. Server Information Extension Field
This field provides clients with information about which NTP versions
are supported by the server, i.e. whether it can respond to requests
conforming to the specific version. It contains a 16-bit field with
flags indicating support for NTP versions in the range of 1 to 16,
where the least significant bit corresponds to the version 1. The
extension field has a fixed length of 8 octets. In requests, all
data fields of the extension are 0.
Lichvar Expires 17 August 2025 [Page 13]
Internet-Draft Network Time Protocol Version 5 February 2025
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = [[TBD]] (draft 0xF505) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Supported NTP versions | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Format of Server Information Extension Field
This field MUST be supported on servers.
5.6. Correction Extension Field
Processing and queueing delays in network switches and routers may be
a significant source of jitter and asymmetry in network delay, which
has a negative impact on accuracy and stability of clocks
synchronized by NTP. A solution to this problem is defined in the
Precision Time Protocol (PTP) [IEEE1588], which is a different
protocol for synchronization of clocks in networks. In PTP a special
type of switch or router, called a Transparent Clock (TC), updates a
correction field in PTP messages to account for the time messages
spend in the TC. This is accomplished by timestamping the message at
the ingress and egress ports, taking the difference to determine time
in the TC and adding this to the Delay Correction. Clients can
account for the accumulated Delay Correction to determine a more
accurate clock offset and network delay.
The NTPv5 Delay Correction has the same format as the PTP
correctionField to make it easier for manufacturers of switches and
routers to implement NTP corrections. The format of the Correction
Extension Field is shown in Figure 6.
Lichvar Expires 17 August 2025 [Page 14]
Internet-Draft Network Time Protocol Version 5 February 2025
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = [[TBD]] (draft 0xF506) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Origin Correction +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Origin Path ID | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Delay Correction +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Delay Path ID | Checksum Complement |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Format of Correction Extension Field
Field Type
The type which identifies the Correction extension field (value
TBD).
Length
The length of the extension field, which is 28 octets.
Origin Correction
A field which contains a copy of the accumulated delay correction
from the request packet in the NTP exchange.
Origin Path ID
A field which contains a copy of the final path ID from the
request packet in the NTP exchange.
Reserved
16 bit reserved for future specification by the IETF. Transmit
with all zeros.
Delay Correction
A signed fixed-point number of nanoseconds with 48 integer bits
and 16 binary fractional bits, which represents the current
correction of the network delay that has accumulated for this
packet on the path from the source to the destination. The format
of this field is identical to the PTP correctionField.
Lichvar Expires 17 August 2025 [Page 15]
Internet-Draft Network Time Protocol Version 5 February 2025
Path ID
A 16-bit identification number of the path where the delay
correction was updated.
Checksum Complement
A field which can be modified in order to keep the UDP checksum of
the packet valid. This allows the UDP checksum to be transmitted
before the Correction Field is received and modified. The same
field is described in RFC 7821 [RFC7821].
An NTP client with enabled support for network corrections SHOULD add
the Correction Extension Field to its requests, with all fields of
the extension field set to zero. It MUST be the last extension field
in the NTP message.
A network device forwarding packets (e.g. a switch or router) with
enabled support for NTP corrections MUST modify only packets which
meet all of the following requirements:
1. It is an IPv4 or IPv6 packet (e.g. EtherType of 0x0800 or 0x86DD)
2. The IP protocol number is 17 (UDP)
3. The UDP source port or destination port is 123 (NTP)
4. The NTP version is 5
5. The NTP message contains the Correction Extension Field
The network device SHOULD add the difference between the beginning of
the NTP message retransmission and the end of the message reception
to the Delay Correction value in the Correction Extension Field.
Note that this time difference might be negative, e.g. in a cut-
through switch. If the packet is transmitted at the same speed as it
was received and the length of the packet does not change (e.g. due
to adding or removing a VLAN tag), the beginning and end of the
interval may correspond to any point of the reception and
transmission as long as it is consistent for all forwarded packets of
the same length. If the transmission speed or length of the packet
is different, the beginning and end of the interval SHOULD correspond
to the end of the reception and beginning of the transmission
respectively.
The receive timestamp of the ingress port and transmit timestamp of
the egress port MUST be from the same clock, or two clocks that are
synchronized to each other. The clocks do not need to be
synchronized to an external reference if their frequency is accurate
enough for the accuracy of measured NTP delay required by the
Lichvar Expires 17 August 2025 [Page 16]
Internet-Draft Network Time Protocol Version 5 February 2025
application. The correction field is updated before or during the
transmission of the message. It is a one-step end-to-end transparent
clock in the PTP terminology.
The network device SHOULD have a randomly generated 16-bit ID number
assigned to each of its ports. When it modifies the Correction
Extension Field, it SHOULD update the Path ID field of the extension
field by adding to it the values of the incoming and outgoing port
ID. The Path ID values can be used by clients to determine if the
NTP request and response have likely traversed the same network path.
If the network device modified any fields of the Correction Extension
Field, it MUST also update the Checksum Complement field in order to
keep the existing UDP checksum valid, or update the UDP checksum in
the UDP header itself. The network device MUST NOT modify any other
data in the UDP payload.
If an NTP server supports the Correction Extension Field and receives
a request which contains this extension field, it SHOULD include the
extension field in the response. If it is included, it MUST be the
last extension field in the message. It MUST copy the Delay
Correction and Path ID from the request to the Origin Correction and
Origin Path ID fields in the response respectively. It SHOULD set
the Delay Correction and Path ID fields of the response to zero.
The Correction Extension Field is required to be the last extension
field in the message to provide an indicator at a fixed offset from
the ending of the message reception (which might simplify hardware
implementation of the correction) and to avoid being covered by the
MAC Extension Field, or other authenticator extension fields (e.g.
Network Time Security). It is the exception in the requirement
specified for the MAC Extension Field. If the corrections were
covered by the authenticator fields, the network devices would need
to have access to the keys and have a significant additional
complexity in order to update the authenticator fields when they
modify the Correction Extension Field.
As the Correction Extension Field is not protected, NTP clients MUST
validate the corrections before their application as specified in
Measurement Modes (Section 6). Clients MUST ignore an unexpected
Correction Extension Field in the response, i.e. if it was not
included in the request.
5.7. Reference Timestamp Extension Field
This field contains the time of the last update of the clock. It has
a fixed length of 12 octets. In requests, that timestamp is always
0.
Lichvar Expires 17 August 2025 [Page 17]
Internet-Draft Network Time Protocol Version 5 February 2025
(Is this really needed? It was mostly unused in NTPv4.)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = [[TBD]] (draft 0xF507) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Reference Timestamp (64) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Format of Reference Timestamp Extension Field
5.8. Monotonic Receive Timestamp Extension Field
When a clock is synchronized to a time source, there is a compromise
between time (phase) accuracy and frequency accuracy, because the
frequency of the clock has to be adjusted to correct time errors that
accumulate due to the frequency error (e.g. caused by changes in the
temperature of the crystal). Faster corrections of time can minimize
the time error, but increase the frequency error, which transfers to
clients using that clock as a time source and increases their
frequency and time errors. This issue can be avoided by transferring
time and frequency separately using different clocks.
The Monotonic Receive Timestamp Extension Field contains an extra
receive timestamp with a 32-bit epoch ID captured by a clock which
does not have corrected phase and can better transfer frequency than
the clock which captures the receive and transmit timestamps in the
header. The extension field has a constant length of 16 octets. In
requests, the counter and timestamp are always 0.
The epoch ID is a random number which is changed when frequency
transfer needs to be restarted, e.g. due to a step of the clock.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = [[TBD]] (draft 0xF508) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Epoch ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Monotonic Receive Timestamp (64) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Lichvar Expires 17 August 2025 [Page 18]
Internet-Draft Network Time Protocol Version 5 February 2025
Figure 8: Format of Monotonic Receive Timestamp Extension Field
The client can determine the frequency-transfer offset from the time-
transfer offset and difference between the two receive timestamps in
the response. It can use the frequency-transfer offset to better
control the frequency of its clock, avoiding the frequency error in
the server's time-transfer clock.
5.9. Secondary Receive Timestamp Extension Field
This extension field provides an additional receive timestamp of the
client request in a selected timescale. It enables the client to get
the same receive timestamp in different timescales in order to
calculate the current offset between the timescales.
In requests, the Timescale field selects the requested timescale.
The other data fields in the extension field MUST be set to 0.
The Timescale, Era, and Secondary Receive Timestamp fields in a
response have the same meaning as the Timescale, Era, and Receive
Timestamp fields in the header respectively.
If the server does not support the requested timescale, it MUST
ignore the extension field in the request. If the server supports
the timescale, but does not have a reliable timestamp (e.g. due to
being close to a leap second), it SHOULD set the timestamp field to
0.
The server MAY provide in this extension field timestamps in
timescales which it does not provide in the header, e.g. it can
provide UTC in addition to leap-smeared UTC to enable its clients to
measure the current smearing offset.
A request MAY contain multiple instances of this extension field, but
each timescale MUST be requested at most once, not counting the
timescale in the header. The server SHOULD include in its response
timestamps in all timescales it supports.
Lichvar Expires 17 August 2025 [Page 19]
Internet-Draft Network Time Protocol Version 5 February 2025
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = [[TBD]] (draft 0xF509) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timescale | Era | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Secondary Receive Timestamp (64) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Format of Secondary Receive Timestamp Extension Field
6. Measurement Modes
An NTPv5 client needs four timestamps to measure the offset and delay
of its clock relative to the server's clock:
1. T1 - client's transmit timestamp of a request
2. T2 - server's receive timestamp of the request
3. T3 - server's transmit timestamp of a response
4. T4 - client's receive timestamp of the response
The offset, delay and dispersion are calculated as:
* offset = ((T2 + T3) - (T4 + T1)) / 2
* delay = |(T4 - T1) - (T3 - T2)|
* dispersion = |T4 - T1| * DR
where
* T1, T2, T3, T4 are the receive and transmit timestamps of a
request and response
* DR is the client's dispersion rate
If the Correction Extension Field is used and the corrections are
known for both the request and response, a corrected offset and delay
is calculated:
* offset_c = offset + (Cd - Co) / 2
Lichvar Expires 17 August 2025 [Page 20]
Internet-Draft Network Time Protocol Version 5 February 2025
* delay_c = delay - (Cd + Co - Drx - Dtx) * (1 - FC)|
where
* Co is the Origin Correction from the response to the request
corresponding to timestamps T1 and T2
* Cd is the Delay Correction from the response corresponding to
timestamps T3 and T4
* FC is the maximum expected frequency error of devices providing
the delay corrections (e.g. 100 ppm)
* Drx is the time it took to receive the frame containing the
response corresponding to T3 and T4
* Dtx is the time it took to transmit the frame containing the
request corresponding to T1 and T2. If unknown, it SHOULD be set
to Drx.
The corrected offset and delay MUST NOT be accepted if any of
delay_c, Co and Cr is negative. The uncorrected delay MUST always be
used for calculation of root delay.
The client can make measurements in the basic mode, or interleaved
mode if supported on the server. In the basic mode, the transmit
timestamp in the server response corresponds to the message which
contains the timestamp itself. In the interleaved mode it
corresponds to a previous response identified by the server cookie.
The interleaved mode enables the server to provide the client with a
more accurate transmit timestamp which is available only after the
response was formed or sent.
An example of cookies and timestamps in an NTPv5 exchange using the
basic mode is shown in Figure 10.
Lichvar Expires 17 August 2025 [Page 21]
Internet-Draft Network Time Protocol Version 5 February 2025
Server t2 t3 t6 t7 t10 t11
-----+----+----------------+----+----------------+----+-----
/ \ / \ / \
Client / \ / \ / \
--+----------+----------+----------+----------+----------+--
t1 t4 t5 t8 t9 t12
+----+ +----+ +----+ +----+ +----+ +----+
SC | 0 | | s1 | | 0 | | s2 | | 0 | | s3 |
CC | c1 | | c1 | | c2 | | c2 | | c3 | | c3 |
Rx | 0 | | t2 | | 0 | | t6 | | 0 | |t10 |
Tx | 0 | | t3 | | 0 | | t7 | | 0 | |t11 |
+----+ +----+ +----+ +----+ +----+ +----+
Figure 10: Cookies and timestamps in basic mode
From the three exchanges in this example, the client would use the
the following sets of timestamps:
* (t1, t2, t3, t4)
* (t5, t6, t7, t8)
* (t9, t10, t11, t12)
For NTPv4, the interleaved mode is described in NTP Interleaved Modes
[I-D.ietf-ntp-interleaved-modes]. The difference between the NTPv5
and NTPv4 interleaved modes is that in NTPv5 it is enabled with a
flag and the previous transmit timestamp on the server is identified
by the server cookie instead of the receive timestamp.
An example of an NTPv5 exchange using the interleaved mode is shown
in Figure 11. The messages in the basic and interleaved mode are
indicated with B and I respectively. The timestamps t3' and t11'
correspond to the same transmissions as t3 and t11, but they may be
less accurate (e.g. due to being captured in software before the
transmission). The first exchange is in the basic mode followed by a
second exchange in the interleaved mode. For the third exchange, the
client request is in the interleaved mode, but the server response is
in the basic mode, because the server no longer had the timestamp t7
(e.g. it was dropped to save timestamps for other clients using the
interleaved mode).
Lichvar Expires 17 August 2025 [Page 22]
Internet-Draft Network Time Protocol Version 5 February 2025
Server t2 t3 t6 t7 t10 t11
-----+----+----------------+----+----------------+----+-----
/ \ / \ / \
Client / \ / \ / \
--+----------+----------+----------+----------+----------+--
t1 t4 t5 t8 t9 t12
Mode: B B I I I B
+----+ +----+ +----+ +----+ +----+ +----+
SC | 0 | | s1 | | s1 | | s2 | | s2 | | s3 |
CC | c1 | | c1 | | c2 | | c2 | | c3 | | c3 |
Rx | 0 | | t2 | | 0 | | t6 | | 0 | |t10 |
Tx | 0 | | t3'| | 0 | | t3 | | 0 | |t11'|
+----+ +----+ +----+ +----+ +----+ +----+
Figure 11: Cookies and timestamps in interleaved mode
From the three exchanges in this example, the client would use the
following sets of timestamps:
* (t1, t2, t3', t4)
* (t1, t2, t3, t4) or (t5, t6, t3, t4)
* (t9, t10, t11', t12)
7. Client Operation
An NTPv5 client can use one or multiple servers. It has a separate
association with each server. It makes periodic measurements of its
offset and delay to the server. It can filter the measurements and
compare measurements from different servers to select and combine the
best servers for synchronization. It can adjust its clock in order
to minimize its offset and keep the clock synchronized. These
algorithms are not specified in this document.
The polling interval can be adjusted for the network conditions and
stability of the clock. When polling a public server on Internet,
the client SHOULD use a polling interval of at least 64 seconds,
increasing in normal conditions up to at least 1024 seconds to avoid
excessive load on the server in case the implementation is used on a
very large number of systems.
Each successful measurement provides the client with an offset, delay
and dispersion. When combined with the server's root delay and
dispersion, it gives the client an estimate of the maximum error.
On each poll, the client:
Lichvar Expires 17 August 2025 [Page 23]
Internet-Draft Network Time Protocol Version 5 February 2025
1. Generates a new random cookie.
2. Formats a request with necessary extension fields and the fields
in the header all zero except:
* Version is set to 5.
* Mode is set to 3.
* Scale is set to the timescale in which the client wants to
operate.
* Poll is set to the rounded log2 value of the current client's
polling interval in seconds.
* Flags are set according to the requested mode. The
interleaved mode flag requests the server to save the transmit
timestamp of the response and provide the transmit timestamp
of a previous response corresponding to the server cookie (if
not zero).
* Server cookie is set only in the interleaved mode. It is set
to the server cookie from the last valid response, or zero if
no such response was received yet or the transmit timestamp of
that response would no longer be useful to the client (e.g.
after missing too many responses).
* Client cookie is set to the newly generated cookie.
3. Sends the request to the server to the UDP port 123 and captures
a transmit timestamp for the packet.
4. Waits for a valid response from the server and captures a receive
timestamp. A valid response has version 5, mode 4, client cookie
equal to the cookie from the request, and passes authentication
if enabled. The client MUST ignore all invalid responses and
accept at most one valid response.
5. Checks whether the response is usable for synchronization of the
clock. Such a response has the Synchronized flag set, stratum
between 0 and 16, root delay and dispersion both smaller than a
specific value, e.g. 16 seconds, and timescale equal to the
requested timescale. If the response is in a different
timescale, the client can switch to the provided timescale,
convert the timestamps if the offset between the timescales is
known from the Secondary Receive Timestamp Extension Field or
other sources, or ignore the response.
Lichvar Expires 17 August 2025 [Page 24]
Internet-Draft Network Time Protocol Version 5 February 2025
6. Saves the server's receive and transmit timestamps. If the
client internally counts seconds using a type wider than 32 bits,
it SHOULD expand the timestamps with the provided NTP era.
7. Calculates the offset, delay, and dispersion as specified in
Measurement Modes (Section 6).
A client which operates as a server for other clients MUST include
the Reference IDs Request Extension Field in its requests in order to
track reference IDs of its sources. If the server's set of reference
IDs contains the client's own reference ID, it SHOULD not select the
server for synchronization to avoid a synchronization loop. If the
client is requesting the reference IDs in multiple chunks, it SHOULD
NOT select the server for synchronization until it received the whole
set.
A client which uses multiple servers MUST be able to handle servers
providing timestamps in different timescales. It can ignore servers
not using the most common or preferred timescale, or convert them to
a common timescale if it knows the offsets between them.
If the client synchronizes its clock to a leap-smeared timescale, it
MUST NOT apply leap seconds and it SHOULD provide the same timescale
to its own clients if it is a server.
The client SHOULD periodically (e.g. every two weeks) refresh IP
addresses of all servers specified by hostname to limit the amount of
traffic that migrated or decommissioned servers will receive from
long-running clients.
8. Server Operation
A server receives requests on the UDP port 123. The server MUST
support measurements in the basic mode. It MAY support the
interleaved mode.
For the basic mode the server does not need to keep any client-
specific state. For the interleaved mode it needs to save transmit
timestamps and be able to identify them by a cookie.
The server maintains its leap indicator, stratum, root delay, and
root dispersion:
* Leap indicator MUST be 3 if the clock is not synchronized or its
maximum error cannot be estimated with the root delay and
dispersion. Otherwise, it MUST be 0, 1, 2, depending on whether a
leap second is pending in the next 14 days and, if it is, whether
it will be inserted or deleted.
Lichvar Expires 17 August 2025 [Page 25]
Internet-Draft Network Time Protocol Version 5 February 2025
* Stratum SHOULD be one larger than stratum of the best server it
uses for its own synchronization.
* Root delay SHOULD be the best server's root delay in addition to
the measured delay to the server.
* Root dispersion SHOULD be the best server's root dispersion in
addition to an estimate of the maximum drift of its own clock
since the last update of the clock.
The server has a randomly generated 120-bit reference ID. It MUST
track reference IDs of its servers in order to be able to respond
with a Reference IDs Response Extension Field.
For each received request, the server:
1. Captures a receive timestamp.
2. Checks the version in the request. If it is not equal to 5, it
MUST either drop the request, or handle it according to the
specification corresponding to the protocol version.
3. Drops the request if the format is not valid, mode is not 3, or
authentication fails with the MAC Extension Field or another
authenticator which does not have a specified response for failed
authentication. The server MUST ignore unknown extension fields.
4. Server forms a response with requested extension fields and sets
the fields in the header as follows:
* Leap Indicator, Stratum, Root delay, and Root dispersion, are
set to the current server's values.
* Version is set to 5.
* Scale is set to the client's requested timescale if it is
supported by the server. If not, the server SHOULD respond in
any timescale it supports.
* The flags are set as follows:
Synchronized is set if the server's clock is considered to be
synchronized, and the receive and transmit timestamps
provided in the response are usable for synchronization of
the client.
Interleaved mode is set if the interleaved mode is
Lichvar Expires 17 August 2025 [Page 26]
Internet-Draft Network Time Protocol Version 5 February 2025
implemented, was requested, and a response in the
interleaved mode is possible (i.e. a transmit timestamp is
associated with the server cookie).
* Era is set to the NTP era of the receive timestamp.
* Server Cookie is set when the interleaved mode is requested
and it is supported by the server, even if the response cannot
be in the requested mode due to the request having an unknown
or zero server cookie. The cookie identifies a more accurate
transmit timestamp of the response, which can be retrieved by
the client later with another request. The cookie generation
is implementation-specific.
* Client Cookie is set to the Client Cookie from the request.
* Receive Timestamp is set to the server's receive timestamp of
the request.
* Transmit Timestamp is set to a value which depends on the
measurement mode. In the basic mode it is the server's
current time when the message is formed. In the interleaved
mode it is the transmit timestamp of the previous response
identified by the server cookie in the request, captured at
some point after the message was formed.
5. Adds the Padding Extension field if necessary to make the length
of the response equal to the length of the request.
6. Drops the response if it is longer than the request to prevent
traffic amplification.
7. Sends the response.
8. Saves the transmit timestamp and server cookie, if the
interleaved mode was requested and is supported by the server.
9. Network Time Security with NTPv5
The Network Time Security [RFC8915] mechanism uses the NTS-KE
protocol to establish keys and negotiate the next protocol. NTPv5
can be indicated as the next protocol with identifier [[TBD]] (draft
use 0x8001). This can be used by clients and servers to negotiate
NTPv5 for an NTS session.
No new NTS-KE records are specified for NTPv5. The records that were
specified for NTPv4 (i.e. NTPv4 New Cookie, NTPv4 Server Negotiation,
and NTPv4 Port Negotiation) are reused for NTPv5.
Lichvar Expires 17 August 2025 [Page 27]
Internet-Draft Network Time Protocol Version 5 February 2025
The NTS extension fields specified for NTPv4 are compatible with
NTPv5. No new extension fields are specified.
(Note to editor: remove this paragraph before publishing.) Client
implementations of a draft of this specification MUST provide the
identity of the draft implemented as data in an NTS-KE record of type
0x4001, which does not have the critical bit set. The draft identity
MUST be encoded as ascii and MUST not contain any trailing 0 bytes.
Servers that implement a draft MUST not accept NTPv5 as an option
unless they support the specific draft version identified.
10. NTPv5 Negotiation in previous NTP versions
NTPv5 messages are not compatible with NTPv4 and other previous
versions of NTP, even if they do not contain any extension fields.
Some widely used server NTPv4 implementations are known to accept
requests indicating a higher version, interpreting them as NTPv4, and
copying the version number from the request to its NTPv4 response.
Responses to NTPv5 requests have a zero client cookie, which causes
them to fail the NTPv5 validation and be ignored by the client.
The implementations are also known to not respond to requests with an
unknown extension field, which prevents an NTPv4 extension field to
be specified for NTPv5 negotiation. Instead, the negotiation reuses
the reference timestamp field.
An NTP server which supports NTPv5 and also NTPv4, NTPv3, NTPv2, or
NTPv1, SHOULD check the reference timestamp in received client-mode
requests of the previous NTP versions. If the reference timestamp
contains the value 0x4E5450354E545035 ("NTP5NTP5" in ASCII), it
SHOULD respond with the same reference timestamp to indicate it
supports NTPv5.
Note to the editor: Remove this paragraph before publication.
Implementations of a draft of this specification SHOULD use
0x4E54503544524654 ("NTP5DRFT" in ASCII) instead of
0x4E5450354E545035.
When NTPv5 is not expected to be widely supported on servers yet, an
NTP client which supports both NTPv5 and a previous NTP version, is
not configured to use a specific NTP version, and does not use NTS or
other mechanism including negotiation of the NTP version, SHOULD
start with the previous version and set the reference timestamp to
0x4e5450354e545035. If the server responds with the same reference
timestamp, the client SHOULD switch to NTPv5. If no valid response
is received for a number of requests (e.g. 2), the client SHOULD
switch back to the orignal NTP version and stick with it for a larger
number of requests (e.g. 256) before trying NTPv5 again.
Lichvar Expires 17 August 2025 [Page 28]
Internet-Draft Network Time Protocol Version 5 February 2025
The special value of the reference timestamp corresponds to
1941-08-24T01:13:25Z in NTP era 0 and 2077-09-29T07:41:41Z in NTP era
1. The negotiation will probably not be needed at that time anymore.
If NTPv5 servers and NTPv4-or-older-only clients are still in use and
they send a request with the special value by chance, they will get
an acceptable response with no side effects. If an NTPv5 client gets
the special value by chance from an NTPv4-or-older-only server, it
will switch to NTPv5 and back after missing a valid response.
11. Acknowledgements
Some ideas were taken from a different NTPv5 design proposed by
Daniel Franke.
The author would like to thank Doug Arnold and David Venhoek for
their contributions and Dan Drown, Watson Ladd, Hal Murray, Kurt
Roeckx, and Ulrich Windl for their suggestions and comments.
12. IANA Considerations
IANA is requested to create a new registry for NTPv5 Extension Field
Types with initial entries including all entries from the NTPv4
Extension Field Types Registry [RFC5905] and the following
NTPv5-specific entries:
Lichvar Expires 17 August 2025 [Page 29]
Internet-Draft Network Time Protocol Version 5 February 2025
+============================+===================+===========+
| Field Type | Meaning | Reference |
+============================+===================+===========+
| [[TBD]], selected by IANA | Padding | [[this |
| from the IETF Review range | | memo]] |
+----------------------------+-------------------+-----------+
| [[TBD]], selected by IANA | MAC | [[this |
| from the IETF Review range | | memo]] |
+----------------------------+-------------------+-----------+
| [[TBD]], selected by IANA | Reference IDs | [[this |
| from the IETF Review range | Request | memo]] |
+----------------------------+-------------------+-----------+
| [[TBD]], selected by IANA | Reference IDs | [[this |
| from the IETF Review range | Response | memo]] |
+----------------------------+-------------------+-----------+
| [[TBD]], selected by IANA | Server | [[this |
| from the IETF Review range | Information | memo]] |
+----------------------------+-------------------+-----------+
| [[TBD]], selected by IANA | Correction | [[this |
| from the IETF Review range | | memo]] |
+----------------------------+-------------------+-----------+
| [[TBD]], selected by IANA | Reference | [[this |
| from the IETF Review range | Timestamp | memo]] |
+----------------------------+-------------------+-----------+
| [[TBD]], selected by IANA | Monotonic Receive | [[this |
| from the IETF Review range | Timestamp | memo]] |
+----------------------------+-------------------+-----------+
| [[TBD]], selected by IANA | Secondary Receive | [[this |
| from the IETF Review range | Timestamp | memo]] |
+----------------------------+-------------------+-----------+
Table 1
IANA is requested to allocate the following protocol in the Network
Time Security Next Protocols Registry [RFC8915]:
+============================+=======================+===========+
| Protocol ID | Protocol Name | Reference |
+============================+=======================+===========+
| [[TBD]], selected by IANA | Network Time Protocol | [[this |
| from the IETF Review range | version 5 (NTPv5) | memo]] |
+----------------------------+-----------------------+-----------+
Table 2
Lichvar Expires 17 August 2025 [Page 30]
Internet-Draft Network Time Protocol Version 5 February 2025
13. Security Considerations
The corrections provided by network devices in the Correction
Extension Field are not authenticated. Man-in-the-middle attackers
can modify the corrections, but only corrections smaller than the
measured delay are accepted by clients. The security impact is
comparable to the impact of delaying unmodified NTP messages, which
generally cannot be prevented.
14. References
14.1. Normative References
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
DOI 10.17487/RFC1321, April 1992,
<https://www.rfc-editor.org/info/rfc1321>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8573] Malhotra, A. and S. Goldberg, "Message Authentication Code
for the Network Time Protocol", RFC 8573,
DOI 10.17487/RFC8573, June 2019,
<https://www.rfc-editor.org/info/rfc8573>.
14.2. Informative References
[Bloom] Bloom, B. H., "Space/Time Trade-Offs in Hash Coding with
Allowable Errors", June 1970,
<https://doi.org/10.1145/362686.362692>.
[I-D.ietf-ntp-interleaved-modes]
Lichvar, M. and A. Malhotra, "NTP Interleaved Modes", Work
in Progress, Internet-Draft, draft-ietf-ntp-interleaved-
modes-08, 6 November 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-ntp-
interleaved-modes-08>.
[IEEE1588] Institute of Electrical and Electronics Engineers, "IEEE
std. 1588-2019, "IEEE Standard for a Precision Clock
Synchronization for Networked Measurement and Control
Systems."", November 2019, <https://www.ieee.org>.
Lichvar Expires 17 August 2025 [Page 31]
Internet-Draft Network Time Protocol Version 5 February 2025
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
"Network Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
<https://www.rfc-editor.org/info/rfc5905>.
[RFC7821] Mizrahi, T., "UDP Checksum Complement in the Network Time
Protocol (NTP)", RFC 7821, DOI 10.17487/RFC7821, March
2016, <https://www.rfc-editor.org/info/rfc7821>.
[RFC7822] Mizrahi, T. and D. Mayer, "Network Time Protocol Version 4
(NTPv4) Extension Fields", RFC 7822, DOI 10.17487/RFC7822,
March 2016, <https://www.rfc-editor.org/info/rfc7822>.
[RFC8915] Franke, D., Sibold, D., Teichel, K., Dansarie, M., and R.
Sundblad, "Network Time Security for the Network Time
Protocol", RFC 8915, DOI 10.17487/RFC8915, September 2020,
<https://www.rfc-editor.org/info/rfc8915>.
Author's Address
Miroslav Lichvar
Red Hat
Email: mlichvar@redhat.com
Lichvar Expires 17 August 2025 [Page 32]