Network Time Protocol Version 5

Network Time Protocol (NTP) is a protocol which enables hosts to synchronize their clocks over a 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. The main differences are: 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. 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 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. Timestamps are clearly separated from values used as cookies. Synchronized server clock is indicated in a separate flag instead of the leap indicator. 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. 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 can be included in NTPv5 messages as specified for NTPv4. NTPv5 adds support for other timescales than UTC. The NTP era number is exchanged in the protocol, which extends the unambiguous time interval from 136 years to about 35000 years. NTPv5 adds a flag to clearly identify the use of interleaved mode instead of comparing timestamps or cookies. 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. Resolution of the root delay and root dispersion fields is improved from about 15 microseconds to about 4 nanoseconds. Clients do not leak information about their clock (e.g. timestamps, estimated accuracy). Servers that support multiple versions of NTP MUST send a response in the same version as the request, to support backwards compatibility. This does not preclude servers from acting as a client in one version of NTP and a server in another.

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 when, and only when, they appear in all capitals, as shown here.

An NTP client exchanges messages with one or more NTP servers; the client sends a request and the server sends a response. Both the client and server measure the time of transmission and reception of every message they send and receive. The servers provide their timestamps to the client. From the timestamps the client captures and receives 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. An NTP response message includes two fields that provide an estimate of the server's time error, the root delay and the root dispertion. 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.

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: 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. A 64-bit unsigned fixed-point type containing a timestamp specified 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 second adjustments. 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).

NTPv5 servers and clients exchange messages as UDP datagrams. Clients send requests to servers and servers send them back responses. The server's UDP port in NTP messages is 123, as assigned by IANA. The client's UDP port can be any number consistent with the local policy. The format of the UDP payload is shown in Figure .

Each NTPv5 message has a header containing the following fields: A 2-bit field indicating upcoming leap seconds. In requests it is always 0. In responses it has one of the following values: 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). A leap second will be inserted in the next 14 days at the end of the current month. A leap second will be deleted in the next 14 days at the end of the current month. The server does not have a time source or other source providing information about leap seconds. A 3-bit field containing the value 5. A 3-bit field containing the value 3 (request) or 4 (response). 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. 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. 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. 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 An 8-bit unsigned NTP era number corresponding to the receive timestamp. In requests it is always 0. A 16-bit integer that can contain the following flags: 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. 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. 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. A field using the time32 type. In responses it is the server's root delay. In requests it is always 0. A field using the time32 type. In responses it is the server's root dispersion. In requests it is always 0. 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. 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. 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. 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 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 octets.

The format of NTPv5 extension fields is shown in Figure .

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. If the server excludes one or more extension fields in the response, it MUST include a Padding extension field that compensates for the excluded fields, making the request and response symmetric in length. 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.

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. 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.

This field, with type [[TBD]] (draft: 0xF501), can have any length. The data field within this extension field SHOULD contain zeros and it MUST be ignored by the receiver. Servers can use this extension field to pad the response to match the length of the request if the response does not contain all requested extension fields, or some have a variable length. If the request message includes a padding extension, the server can increase its length if necessary. If the request message does not include a padding extension, the server can add it to the response. Clients can include the padding extension in the request message, allowing the extension to be used for internal purposes. For instance, an NTP client receiving a response message can use this extension field to transfer the reception time from a hardware module to a software module. This field MUST be supported on servers.

This field, with type [[TBD]] (draft: 0xF502), authenticates the NTPv5 message with a symmetric key. Implementations SHOULD use the Message Authentication Code (MAC) specified in RFC8573. The MAC MUST be computed over the NTP header and all the extension fields, if present, located prior to the Message Authentication Extension Field. 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, such as the Correction Extension Field.

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 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. A server maintains a copy of the filter for each server it acquires time from. 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 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. If a recurring loop is detected, it is recommended to increase the random delay in order to avoid livelock scenarios. 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. Bloom filters are free from false negatives. However, there is a transient period between the addition of a reference ID to a server's Bloom filter and the propagation of this information through a chain of clients. During this period, the new reference ID may not be detected, potentially causing a temporary synchronization loop. For instance, if two servers inquire each other about the list of reference IDs roughly at the same time, neither will detect its reference ID in the other's Bloom filter, resulting in a temporary loop. Generally, when a server updates the Bloom filter it distributes to clients, temporary synchronization loops might occur before converging to an acyclic distribution tree. 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. When a filter is sent to a client in multiple chunks, the server might update the Bloom filter to a new value after some chunks have been sent. This can cause the subsequent chunks to be inconsistent with the previously sent ones. The partially updated Bloom filter might cause false negative or false positive detections. This transient issue is resolved once the server completes sending the updated Bloom filter. 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 .

The format of the Reference IDs Response is shown in Figure .

These fields MUST be supported on servers which can be synchronized to other NTP servers (i.e. they can be in a synchronization loop).

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.

This field MUST be supported on servers.

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), 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 .

The type which identifies the Correction extension field (value TBD). The length of the extension field, which is 28 octets. A field which contains a copy of the accumulated delay correction from the request packet in the NTP exchange. A field which contains a copy of the final path ID from the request packet in the NTP exchange. 16 bit reserved for future specification by the IETF. Transmit with all zeros. 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. A value of one in all bits, except the most significant, of the field indicates that the correction is too big to be represented. The format of this field is identical to the PTP correctionField. A 16-bit identification number of the path where the delay correction was updated. 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. 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: It is an IPv4 or IPv6 packet The IP protocol number is 17 (UDP) The UDP source port or destination port is 123 (NTP) The NTP version is 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 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 Message Authentication Code Extension Field, or other authenticator extension fields (e.g. Network Time Security). It is the exception in the requirement specified for the Message Authentication Code 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. Clients MUST ignore an unexpected Correction Extension Field in the response, i.e. if it was not included in the request.

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. (Is this really needed? It was mostly unused in NTPv4.)

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.

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.

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.

An NTPv5 client needs four timestamps to measure the offset and delay of its clock relative to the server's clock: T1 - client's transmit timestamp of a request T2 - server's receive timestamp of the request T3 - server's transmit timestamp of a response 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 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 .

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. 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 . 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).

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)

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: Generates a new random cookie. 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. Sends the request to the server to the UDP port 123 and captures a transmit timestamp for the packet. 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. 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. 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. Calculates the offset, delay, and dispersion as specified in Measurement Modes. 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.

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 by 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. Stratum SHOULD be 1 if the server is synchronized to a local reference clock, or be one larger than the stratum of the NTP server it selected as best for synchronization. It MUST be greater than the minimum stratum of all servers selected for synchronization, as they provided in their last accepted response, or 0 to indicate infinity. Root delay MUST be an estimate of the double of the maximum error of the server's clock due to asymmetries in the network delay and other delays (e.g. timestamping) on the path to the primary time source. For a server that is synchronized to other NTP servers, one possibility is to set it to the latest measured delay to the server it considers best plus the root delay provided in that response. Root dispersion MUST be an estimate of the maximum error of the server's clock from other causes than those covered by root delay, e.g. instability of the clock and measurements by which it is synchronized. If the server is synchronized to other NTP servers, it MUST include root dispersion from one of the servers' responses. 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: Captures a receive timestamp. 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. Drops the request if the format is not valid, mode is not 3, or authentication fails with the Message Authentication Code Extension Field or another authenticator which does not have a specified response for failed authentication. The server MUST ignore unknown extension fields. 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: 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. is set if the interleaved mode is 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. The length of the response MUST be equal to the length of the request. The server adds the Padding Extension Field or increases its length if necessary to make the length of the response equal to the length of the request. Drops the response if it is longer than the request to prevent traffic amplification. Sends the response. Saves the transmit timestamp and server cookie, if the interleaved mode was requested and is supported by the server.

The Network Time Security 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. 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.

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. 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.

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.

IANA is requested to allocate the following entries in the NTP Extension Field Types Registry: Field Type Meaning Reference [[TBD]] Padding [[this memo]] [[TBD]] Message Authentication Code [[this memo]] [[TBD]] Reference IDs Request [[this memo]] [[TBD]] Reference IDs Response [[this memo]] [[TBD]] Server Information [[this memo]] [[TBD]] Correction [[this memo]] [[TBD]] Reference Timestamp [[this memo]] [[TBD]] Monotonic Receive Timestamp [[this memo]] [[TBD]] Secondary Receive Timestamp [[this memo]] IANA is requested to allocate the following entry in the Network Time Security Next Protocols Registry: Protocol ID Protocol Name Reference [[TBD]], selected by IANA from the IETF Review range Network Time Protocol version 5 (NTPv5) [[this memo]]

The security considerations of time protocols in general are discussed in . A successful attack on the time distribution can result in one of three outcomes: Denial of Service (DoS), reduced accuracy, or obtaining incorrect time. NTP can be compromised through various methods, such as altering or delaying NTP messages during transit, injecting malicious NTP messages or replaying valid ones, or impersonating an NTP server. The Message Authentication Code Extension Field can be used to provide integrity protection, thus mitigating in-transit NTP message modification and malicious packet injection. Using NTS with NTPv5 provides enhanced security properties, including server identity verification, improved replay protection, and secure key establishment. NTPv5 was design to minimize the necessary on-the-wire data that is included in the NTPv5 header in order to limit the amount of information that is exposed to the network and minimize the potential effect of network reconnaissance. For example, the client's transmission timestamp is not included in the NTPv5 header. Extension fields are used for conveying optional information. The protocol operates in a client-server mode. Other modes of operation, which were supported in the previous version of the protocol have known security vulnerabilities. The symmetric and broadcast modes are vulnerable to replay attacks. The control and private modes can be exploited for denial-of-service traffic amplification attacks. These modes are not supported in NTPv5. The NTP response message has the same length as the corresponding request message. This symmetric approach reduces the potential of amplification attacks. The protocol does not inherently mitigate delay attacks. An on-path attacker can delay NTP messages and compromise the accuracy. Delay attacks can be mitigated by limiting the maximum acceptable delay. In each request-response exchange the client computes the delay and can discard the response if the delay exceeds a maximum expected value. A more fine-grained mitigation approach is acquiring time from multiple sources and selecting the sources that are most likely to be accurate. A detailed scheme was defined in and can be used in NTPv5. This scheme defines a selection algorithm, which identifies the most accurate and reliable time sources from a pool of candidates. These sources are then grouped by the clustering algorithm to minimize the impact of outliers. Finally, the combining algorithm averages the time data from these clustered sources to produce a final, stable time estimate. An enhancement to the selection algorithm was proposed in . An alternative approach to using multiple time sources is using multiple diverse paths between the client and server , as it is assumed that only a subset of the paths is compromised by an on-path attacker. The corrections provided by network devices in the Correction Extension Field are not authenticated. Man-in-the-middle attackers can modify the correction values. In order to mitigate such attacks, the client validates the correction values as described in . Thus, only corrections smaller than the measured delay are accepted by clients. The security impact is comparable to the impact of delaying unmodified NTP messages, as described above.