idnits 2.17.1 draft-mlichvar-ntp-ntpv5-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 659 has weird spacing: '... Server t2 ...' == Line 701 has weird spacing: '... Server t2 ...' == Line 857 has weird spacing: '...wn leap is se...' == Line 861 has weird spacing: '...ed mode is se...' -- The document date (Feb 17, 2021) is 1161 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-07) exists of draft-ietf-ntp-interleaved-modes-04 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force M. Lichvar 3 Internet-Draft Red Hat 4 Intended status: Standards Track Feb 17, 2021 5 Expires: August 21, 2021 7 Network Time Protocol Version 5 8 draft-mlichvar-ntp-ntpv5-02 10 Abstract 12 This document describes the version 5 of the Network Time Protocol 13 (NTP). 15 Status of This Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at https://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on August 21, 2021. 32 Copyright Notice 34 Copyright (c) 2021 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (https://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 50 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 51 2. Basic Concepts . . . . . . . . . . . . . . . . . . . . . . . 3 52 3. Data Types . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 4. Message Format . . . . . . . . . . . . . . . . . . . . . . . 5 54 5. Extension Fields . . . . . . . . . . . . . . . . . . . . . . 9 55 5.1. Padding Extension Field . . . . . . . . . . . . . . . . . 10 56 5.2. MAC Extension Field . . . . . . . . . . . . . . . . . . . 10 57 5.3. Reference IDs Extension Field . . . . . . . . . . . . . . 10 58 5.4. Server Information Extension Field . . . . . . . . . . . 10 59 5.5. Correction Extension Field . . . . . . . . . . . . . . . 11 60 5.6. Reference Timestamp Extension Field . . . . . . . . . . . 13 61 5.7. Monotonic Timestamp Extension Field . . . . . . . . . . . 13 62 6. Measurement Modes . . . . . . . . . . . . . . . . . . . . . . 14 63 7. Client Operation . . . . . . . . . . . . . . . . . . . . . . 17 64 8. Server Operation . . . . . . . . . . . . . . . . . . . . . . 18 65 9. NTPv5 Negotiation in NTPv4 . . . . . . . . . . . . . . . . . 20 66 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 67 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 68 12. Security Considerations . . . . . . . . . . . . . . . . . . . 21 69 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 70 13.1. Normative References . . . . . . . . . . . . . . . . . . 21 71 13.2. Informative References . . . . . . . . . . . . . . . . . 21 72 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 22 74 1. Introduction 76 Network Time Protocol (NTP) is a protocol which enables computers to 77 synchronize their clocks over network. Time is distributed from 78 primary time servers to clients, which can be servers for other 79 clients, and so on. Clients can use multiple servers simultaneously. 81 NTPv5 is similar to NTPv4 [RFC5905]. The main differences are: 83 1. The protocol specification (this document) describes only the 84 on-wire protocol. Filtering of measurements, security 85 mechanisms, source selection, clock control, and other 86 algorithms, are out of scope. 88 2. For security reasons, NTPv5 drops support for the symmetric 89 active, symmetric passive, broadcast, control, and private 90 modes. The symmetric and broadcast modes are vulnerable to 91 replay attacks. The control and private modes can be exploited 92 for denial-of-service traffic amplification attacks. Only the 93 client and server modes remain in NTPv5. 95 3. Timestamps are clearly separated from values used as cookies. 97 4. NTPv5 messages can be extended only with extension fields. The 98 MAC field is wrapped in an extension field. 100 5. Extension fields can be of any length, even indivisible by 4, 101 but are padded to a multiple of 4 octets. Extension fields 102 specified for NTPv4 are compatible with NTPv5. 104 6. NTPv5 adds support for other timescales than UTC. 106 7. The NTP era number is exchanged in the protocol, which extends 107 the unambiguous interval of the client from 136 years to about 108 35000 years. 110 8. NTPv5 adds a new measurement mode to provide clients with more 111 accurate transmit timestamps. 113 9. NTPv5 works with sets of reference IDs to prevent 114 synchronization loops over multiple hosts. 116 10. Resolution of the root delay and root dispersion fields is 117 improved. 119 11. Clients don't leak information about their clock (e.g. 120 timestamps). 122 1.1. Requirements Language 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 126 "OPTIONAL" in this document are to be interpreted as described in BCP 127 14 [RFC2119] [RFC8174] when, and only when, they appear in all 128 capitals, as shown here. 130 2. Basic Concepts 132 The distance to the reference time sources in the hierarchy of 133 servers is called stratum. Primary time servers, which are 134 synchronized to the reference clocks, are stratum 1, their clients 135 are stratum 2, and so on. 137 Root delay measures the total delay on the path to the reference time 138 source used by the primary time server. Each client on the path adds 139 to the root delay the NTP delay measured to the server it considers 140 best for synchronization. The delay includes network delays and any 141 delays between timestamping of NTP messages and their actual 142 reception and transmission. Half of the root delay estimates the 143 maximum error of the clock due to asymmetries in the delay. 145 Root dispersion estimates the maximum error of the clock due to the 146 instability of the clocks on the path and instability of NTP 147 measurements. Each server on the path adds its own dispersion to the 148 root dispersion. Different clock models can be used. In a simple 149 model, the clock can have a constant dispersion rate, e.g. 15 ppm as 150 used in NTPv4. 152 The sum of the root dispersion and half of the root delay is called 153 root distance. It is the estimated maximum error of the clock, 154 taking into account asymmetry in delay and stability of clocks and 155 measurements. 157 Servers have randomly generated reference IDs to prevent 158 synchronization loops. 160 3. Data Types 162 NTPv5 uses few different data types. They are all in the network 163 order. Beside signed and unsigned integers, it has also the 164 following fixed-point types: 166 time16 167 A 16-bit fixed-point type containing values in seconds. It has 1 168 signed integer bit (i.e. it is just the sign) and 15 fractional 169 bits. The minimum value is -1.0, the maximum value is 170 32767/32768, and the resolution is about 30 microseconds. 172 time32 173 A 32-bit fixed-point type containing values in seconds. It has 4 174 unsigned integer bits and 28 fractional bits. The maximum value 175 is 16 seconds and the resolution is about 3.7 nanoseconds. 177 timestamp64 178 A 64-bit fixed-point type containing timestamps. It has 32 signed 179 integer bits and 32 fractional bits. It spans an interval of 180 about 136 years and has a resolution of about 0.23 nanoseconds. 181 It can be used in different timescales. In the UTC timescale it 182 is the number of SI seconds since 1 Jan 1972 plus 2272060800, 183 excluding leap seconds. Timestamps in the TAI timescale are the 184 same except they include leap seconds and extra 10 seconds for the 185 original difference between TAI and UTC in 1972, when leap seconds 186 were introduced. One interval covered by the type is called an 187 NTP era. The era starting at the epoch is era number 0, the 188 following era is number 1, and so on. 190 4. Message Format 192 NTPv5 servers and clients exchange messages as UDP datagrams. 193 Clients send requests to servers and servers send them back 194 responses. The format of the UDP payload is shown in Figure 1. 196 0 1 2 3 197 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 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 |LI | VN |Mode | Scale |Stratum| Poll | Precision | 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 | Flags | Era | Timescale Offset | 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 | Root Delay | 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 | Root Dispersion | 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | | 208 + Server Cookie (64) + 209 | | 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 | | 212 + Client Cookie (64) + 213 | | 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 | | 216 + Receive Timestamp (64) + 217 | | 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 | | 220 + Transmit Timestamp (64) + 221 | | 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 | | 224 . . 225 . Extension Field 1 (variable) . 226 . . 227 | | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 . . 230 . . 231 . . 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | | 234 . . 235 . Extension Field N (variable) . 236 . . 237 | | 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 Figure 1: Format of NTPv5 messages 242 Each NTPv5 message has a header containing the following fields: 244 Leap indicator (LI) 245 A 2-bit field which can have the following values: 0 (normal), 1 246 (leap second inserted at the end of the month), 2 (leap second 247 deleted at the end of the month), 3 (not synchronized). The 248 values 1 and 2 are set at most 14 days in advance before the leap 249 second. In requests it is always 0. 251 Version Number (VN) 252 A 3-bit field containing the value 5. 254 Mode 255 A 3-bit field containing the value 3 (request) or 4 (response). 257 Scale 258 A 4-bit identifier of the timescale. In requests it is the 259 requested timescale. In responses it is the timescale of the 260 receive and transmit timestamps. Defined values are: 262 0: UTC 264 1: TAI 266 2: UT1 268 3: Leap-smeared UTC 270 Stratum 271 A 4-bit field containing the stratum of host. Primary time 272 servers have a stratum of 1, their clients have a stratum of 2, 273 and so on. The value of 0 indicates an unknown or infinite 274 stratum. In requests it is always 0. 276 Poll 277 An 8-bit signed integer containing the polling interval as a 278 rounded log2 value in seconds. In requests it is the current 279 polling interval. In responses it is the minimum allowed polling 280 interval. 282 Precision 283 An 8-bit signed integer containing the precision of the timestamps 284 included in the message as a rounded log2 value in seconds. In 285 requests, which don't contain any timestamps, it is always 0. 287 Flags 288 An 8-bit integer that can contain the following flags: 290 0x1: Unknown leap 291 In requests it is zero. In responses it indicates the server 292 does not have a time source which provides information about 293 leap seconds and the client should interpret the Leap Indicator 294 as having only two values: synchronized (0) and not 295 synchronized (3). 297 0x4: Interleaved mode 298 In requests it is a request for a response in the interleaved 299 mode. In responses it indicates the response is in the 300 interleaved mode. 302 Era 303 An 8-bit unsigned NTP era number corresponding to the receive 304 timestamp. In requests it is always 0. 306 Timescale Offset 307 A 16-bit value specific to the selected timescale, which is 308 referenced to the receive timestamp. In requests it is always 0. 310 * In the UTC (0) and TAI (1) timescales it is the TAI-UTC offset 311 as a signed integer, or 0x8000 if unknown. 313 * In the UT1 timescale (2) it is the UT1-UTC offset using the 314 time16 type, or 0x8000 (-1.0) if unknown. 316 * In the leap-smeared UTC, it is the current offset between the 317 leap smeared time and UTC using the time16 type, or 0x8000 318 (-1.0) if unknown. 320 Root Delay 321 A field using the time32 type. In responses it is the server's 322 root delay. In requests it is always 0. 324 Root Dispersion 325 A field using the time32 type. In responses it is the server's 326 root dispersion. In requests it is always 0. 328 Server Cookie 329 A 64-bit field containing a number generated by the server which 330 enables the interleaved mode. In requests it is 0, or a copy of 331 the server cookie from the last response. 333 Client Cookie 334 A 64-bit field containing a random number generated by the client. 335 Responses contain a copy of the field from the corresponding 336 request, which allows the client to verify that the responses are 337 valid responses to the requests. 339 Receive Timestamp 340 A field using the timestamp64 type. In requests it is always 0. 341 In responses it is the time when the request was received. The 342 timestamp corresponds to the end of the reception. 344 Transmit Timestamp 345 A field using the timestamp64 type. In requests it is always 0. 346 In responses it is the time when a response to the client was 347 transmitted. The specific response depends on the selected mode 348 (basic or interleaved). The timestamp corresponds to the 349 beginning of the transmission. 351 The header has 48 octets, which is the minimum length of a valid 352 NTPv5 message. A message can contain zero, one, or multiple 353 extension fields. The maximum length is not specified, but the 354 length is always divisible by 4. 356 5. Extension Fields 358 The format of NTPv5 extension fields is shown in Figure 2. 360 0 1 2 3 361 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 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 | Type | Length | 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 . . 366 . Data (variable) . 367 . . 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 Figure 2: Format of NTPv5 extension fields 372 Each extension field has a header which contains a 16-bit type and 373 16-bit length. The length is in octets and it includes the header. 374 The minimum length is 4, i.e. an extension field doesn't have to 375 contain any data. If the length is not divisible by 4, the extension 376 field is padded with zeroes to the smallest multiple of 4 octets. 378 Generally, if a request contains an extension field, the client is 379 asking the server to include the same extension field in the 380 response. Exceptions to this rule are allowed. 382 Extension fields specified for NTPv4 can be included in NTPv5 383 messages as specified for NTPv4. 385 The rest of this section describes new extension fields specified for 386 NTPv5. Clients are not required to use or support any of these 387 extension fields, but servers are required to support some extension 388 fields. 390 5.1. Padding Extension Field 392 This field is used by servers to pad the response to the same length 393 as the request if the response doesn't contain all requested 394 extension fields, or some have a variable length. It can have any 395 length. 397 This field MUST be supported on server. 399 5.2. MAC Extension Field 401 This field authenticates the NTPv5 message with a symmetric key. 402 Implementations SHOULD use the MAC specified in RFC8573 [RFC8573]. 403 The extension field MUST be the last extension field in the message 404 unless an extension field is specifically allowed to be placed after 405 a MAC or another authenticator field. 407 5.3. Reference IDs Extension Field 409 This field allows servers to prevent synchronization loops, i.e. 410 synchronizing to one of its direct or indirect clients. It contains 411 a set (bloom filter) of reference IDs. 413 TODO 415 This field MUST be supported on server. 417 5.4. Server Information Extension Field 419 This field provides clients with information about which NTP versions 420 are supported by the server, as a minimum and maximum version. The 421 extension field has a fixed length of 8 octets. In requests, all 422 data fields of the extension are 0. 424 0 1 2 3 425 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 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 | Type | Length | 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 | Min. Version | Max. Version | Reserved | 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 Figure 3: Format of Server Information Extension Field 434 This field MUST be supported on server. 436 5.5. Correction Extension Field 438 Processing and queueing delays in network switches and routers may be 439 a significant source of jitter and asymmetry in network delay, which 440 has a negative impact on accuracy and stability of clocks 441 synchronized by NTP. A solution to this problem is defined in the 442 Precision Time Protocol (PTP) [IEEE1588], which is a different 443 protocol for synchronization of clocks in networks. In PTP a special 444 type of switch or router, called a Transparent Clock (TC), updates a 445 correction field in PTP messages to account for the time messages 446 spend in the TC. This is accomplished by timestamping the message at 447 the ingress and egress ports, taking the difference to determine time 448 in the TC and adding this to the Delay Correction. Clients can 449 acccount for the accumated Delay Correction to determine a more 450 accurate clock offset. 452 The NTPv5 Delay Correction has the same format as the PTP 453 correctionField to make it easier for manfacturers of switches and 454 routers to implement NTP corrections. The format of the Correction 455 Extension Field is shown in Figure 4. 457 0 1 2 3 458 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 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 | Type | Length | 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 | | 463 + Origin Correction + 464 | | 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 | Origin path ID | Reserved | 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 | | 469 + Delay Correction + 470 | | 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 | Delay Path ID | Checksum complement | 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 Figure 4: Format of Correction Extension Field 477 Field Type 478 The type which identifies the Correction extension field (value 479 TBD). 481 Length 482 The length of the extension field, which is 28 octets. 484 Origin Correction 485 A field which contains a copy of the accumulated delay correction 486 from the request packet in the NTP exchange. 488 Origin ID 489 A field which contains a copy of the final path ID from the 490 request packet in the NTP exchange. 492 Reserved 493 16 bit reserved for future specification by the IETF. Transmit 494 with all zeros. 496 Delay Correction 497 A signed fixed-point number of nanoseconds with 48 integer bits 498 and 16 binary fractional bits, which represents the current 499 correction of the network delay that has accumulated for this 500 packet on the path from the source to the destination. The format 501 of this field is identical to the PTP correctionField. 503 Path ID 504 A 16-bit identification number of the path where the delay 505 correction was updated. 507 Checksum Complement 508 A field which can be modified in order to keep the UDP checksum of 509 the packet valid. This allows the UDP checksum to be transmitted 510 before the Correction Field is received and modified. The same 511 field is described in RFC 7821 [RFC7821]. 513 A correction capable client SHALL transmit the request with the 514 Origin Correction, Origin ID, Delay Correction and Path ID fields 515 filled with all zeros. 517 Network nodes, such as switches and routers, that are NTP corrections 518 capable SHALL add the difference between the beginning of an NTP 519 message retransmission and the end of the message reception to the 520 received Delay Correction value, and update this field. Note that 521 this time difference might be negative, for example in a cut-through 522 switch. If the packet is transmitted at the same speed as it was 523 received and the length of the packet does not change (e.g. due to 524 adding or removing a VLAN tag), the beginning and end of the interval 525 may correspond to any point of the reception and transmission as long 526 as it is consistent for all forwarded packets of the same length. If 527 the transmission speed or length of the packet is different, the 528 beginning and end of the interval SHOULD correspond to the end of the 529 reception and beginning of the transmission respectively. Both 530 timestamps MUST be based on the same clock. This clock does not need 531 to be synchronized as long as the frequency is accurate enough such 532 that resulting time difference estimation errors are acceptable to 533 the precision required by the application. 535 If a network node updates the delay correction, it SHOULD also add 536 the identification numbers of the incoming and outgoing port to the 537 path ID. Path ID values can be used by clients to determine if the 538 ntp request and response messages are likely to have traversed the 539 same network path. 541 If a network node modified any field of the extension field, it MUST 542 update the checksum complement field in order to keep the current UDP 543 checksum valid, or update the UDP checksum itself. 545 The server SHALL write the received Delay Correction value in the 546 origin correction field of the response message, and the recieved 547 path ID value in the origin ID field. The server SHALL set the Delay 548 Correction field and Path ID fields to all zeros 550 5.6. Reference Timestamp Extension Field 552 This fields contains the time of the last update of the clock. It 553 has a fixed length of 12 octets. In requests, the timestamp is 554 always 0. 556 (Is this really needed? It was mostly unused in NTPv4.) 558 0 1 2 3 559 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 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 | Type | Length | 562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 563 | | 564 | Reference Timestamp (64) | 565 | | 566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 568 Figure 5: Format of Reference Timestamp Extension Field 570 5.7. Monotonic Timestamp Extension Field 572 When a clock is synchronized to a time source, there is a compromise 573 between time (phase) accuracy and frequency accuracy, because the 574 frequency of the clock has to be adjusted to correct time errors that 575 accumulate due to the frequency error (e.g. caused by changes in the 576 temperature of the crystal). Faster corrections of time can minimize 577 the time error, but increase the frequency error, which transfers to 578 clients using that clock as a time source and increases their 579 frequency and time errors. This issue can be avoided by transfering 580 time and frequency separately using different clocks. 582 The Monotonic Timestamp Extension Field contains an extra receive 583 timestamp with a 32-bit epoch identifier captured by a clock which 584 doesn't have corrected phase and can better transfer frequency than 585 the clock which captures the receive and transmit timestamps in the 586 header. The extension field has a constant length of 16 octets. In 587 requests, the counter and timestamp are always 0. 589 The epoch identifier is a random number which is changed when 590 frequency transfer needs to be restarted, e.g. due to a step of the 591 clock. 593 0 1 2 3 594 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 595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 596 | Type | Length | 597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 598 | Epoch ID | 599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 600 | | 601 | Monotonic Receive Timestamp (64) | 602 | | 603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 605 Figure 6: Format of Monotonic Timestamp Extension Field 607 The client can determine the frequency-transfer offset from the time- 608 transfer offset and difference between the two receive timestamps in 609 the response. It can use the frequency-transfer offset to better 610 control the frequency of its clock, avoiding the frequency error in 611 the server's time-transfer clock. 613 6. Measurement Modes 615 An NTPv5 client needs four timestamps to measure the offset and delay 616 of its clock relative to the server's clock: 618 1. T1 - client's transmit timestamp of a request 620 2. T2 - server's receive timestamp of the request 622 3. T3 - server's transmit timestamp of a response 624 4. T4 - client's receive timestamp of the response 626 The offset, delay and dispersion are calculated as: 628 o offset = ((T2 + T3) - (T4 + T1) + (Cd - Co)) / 2 630 o delay = |(T4 - T1) - (T3 - T2) - (Cd + Co)| 632 o dispersion = |T4 - T1| * DR 634 where 636 o T1, T2, T3, T4 are the receive and transmit timestamps of a 637 request and response 639 o Co is the Origin Correction from the Correction Extension Field if 640 present in the response and has acceptable values, zero otherwise 642 o Cd is the Delay Correction from the Correction Extension Field if 643 present in the response and has acceptable values, zero otherwise 645 o DR is the client's dispersion rate 647 The client can make measurements in the basic mode, or interleaved 648 mode if supported on the server. In the basic mode, the transmit 649 timestamp in the server response corresponds to the message which 650 contains the timestamp itself. In the interleaved mode it 651 corresponds to a previous response indentified by the server cookie. 652 The interleaved mode enables the server to provide the client with a 653 more accurate transmit timestamp which is available only after the 654 previous response was formed or sent. 656 An example of cookies and timestamps in an NTPv5 exchange using the 657 basic mode is shown in Figure 7. 659 Server t2 t3 t6 t7 t10 t11 660 -----+----+----------------+----+----------------+----+----- 661 / \ / \ / \ 662 Client / \ / \ / \ 663 --+----------+----------+----------+----------+----------+-- 664 t1 t4 t5 t8 t9 t12 666 +----+ +----+ +----+ +----+ +----+ +----+ 667 SC | 0 | | s1 | | 0 | | s2 | | 0 | | s3 | 668 CC | c1 | | c1 | | c2 | | c2 | | c3 | | c3 | 669 Rx | 0 | | t2 | | 0 | | t6 | | 0 | |t10 | 670 Tx | 0 | | t3 | | 0 | | t7 | | 0 | |t11 | 671 +----+ +----+ +----+ +----+ +----+ +----+ 673 Figure 7: Cookies and timestamps in basic mode 675 From the three exchanges in this example, the client would use the 676 the following sets of timestamps: 678 o (t1, t2, t3, t4) 680 o (t5, t6, t7, t8) 682 o (t9, t10, t11, t12) 684 For NTPv4, the interleaved mode is described in NTP Interleaved Modes 685 [I-D.ietf-ntp-interleaved-modes]. The difference between the NTPv5 686 and NTPv4 interleaved modes is that in NTPv5 it is enabled with a 687 flag and the previous transmit timestamp on the server is identified 688 by a random cookie instead of the receive timestamp. 690 An example of an NTPv5 exchange using the interleaved mode is shown 691 in Figure 8. The messages in the basic and interleaved mode are 692 indicated with B and I respectively. The timestamps t3' and t11' 693 correspond to the same transmissions as t3 and t11, but they may be 694 less accurate. The first exchange is in the basic mode followed by a 695 second exchange in the interleaved mode. For the third exchange, the 696 client request is in the interleaved mode, but the server response is 697 in the basic mode, because the server no longer had the timestamp t7 698 (e.g. it was dropped to save timestamps for other clients using the 699 interleaved mode). 701 Server t2 t3 t6 t7 t10 t11 702 -----+----+----------------+----+----------------+----+----- 703 / \ / \ / \ 704 Client / \ / \ / \ 705 --+----------+----------+----------+----------+----------+-- 706 t1 t4 t5 t8 t9 t12 708 Mode: B B I I I B 709 +----+ +----+ +----+ +----+ +----+ +----+ 710 SC | 0 | | s1 | | s1 | | s2 | | s2 | | s3 | 711 CC | c1 | | c1 | | c2 | | c2 | | c3 | | c3 | 712 Rx | 0 | | t2 | | 0 | | t6 | | 0 | |t10 | 713 Tx | 0 | | t3'| | 0 | | t3 | | 0 | |t11'| 714 +----+ +----+ +----+ +----+ +----+ +----+ 716 Figure 8: Cookies and timestamps in interleaved mode 718 From the three exchanges in this example, the client would use the 719 following sets of timestamps: 721 o (t1, t2, t3', t4) 722 o (t1, t2, t3, t4) or (t5, t6, t3, t4) 724 o (t9, t10, t11', t12) 726 7. Client Operation 728 An NTPv5 client can use one or multiple servers. It has a separate 729 association with each server. It makes periodic measurements of its 730 offset and delay to the server. It can filter the measurements and 731 compare measurements from different servers to select and combine the 732 best servers for synchronization. It can adjust its clock in order 733 to minimize its offset and keep the clock synchronized. These 734 algorithms are not specified in this document. 736 The polling interval can be adjusted for the network conditions and 737 stability of the clock. When polling a public server on Internet, 738 the client SHOULD use at least a polling interval of 64 seconds, 739 increasing up to at least 1024 seconds. 741 Each successful measurement provides the client with an offset, delay 742 and dispersion. When combined with the server's root delay and 743 dispersion, it gives the client an estimate of the maximum error. 745 On each poll, the client: 747 1. Generates a new random cookie. 749 2. Formats a request with necessary extension fields and the fields 750 in the header all zero except: 752 * Version is set to 5. 754 * Mode is set to 3. 756 * Scale is set to the timescale in which the client wants to 757 operate. 759 * Poll is set to the rounded log2 value of the current client's 760 polling interval in seconds. 762 * Flags are set according to the requested mode. The 763 interleaved mode flag requests a response in the interleaved 764 mode. 766 * Server cookie is set only in the interleaved mode. If a valid 767 response from the server was received previously, it is set to 768 the server cookie from the previous response. 770 * Client cookie is set to the newly generated cookie. 772 3. Sends the request to the server to the UDP port 123 and captures 773 a transmit timestamp. 775 4. Waits for a valid response from the server and captures a receive 776 timestamp. A valid response has version 5, mode 4, client cookie 777 equal to the cookie from the request, and passes authentication 778 if enabled. The client MUST ignore all invalid responses and 779 accept at most one valid response. 781 5. Checks whether the response is usable for synchronization of the 782 clock. Such a response has a leap indicator not equal to 3, 783 stratum between 0 and 16, root delay and dispersion both smaller 784 than a specific value, e.g. 16 seconds, and timescale equal to 785 the requested timescale. If the response is in a different 786 timescale, the client can switch to the provided timescale, 787 convert the timestamps if the offset between the timescales is 788 provided or known, or drop the response. 790 6. Saves the server's receive and transmit timestamps. If the 791 client internally counts seconds using a type wider than 32 bits, 792 it SHOULD expand the timestamps with the provided NTP era. 794 7. Calculates the offset, delay, and dispersion. 796 8. Server Operation 798 A server receives requests on the UDP port 123. The server MUST 799 support measurements in the basic mode. It MAY support the 800 interleaved mode. 802 For the basic mode the server doesn't need to keep any client- 803 specific state. For the interleaved mode it needs to save transmit 804 timestamps and be able to identify them by a cookie. 806 The server maintains its leap indicator, stratum, root delay, and 807 root dispersion: 809 o Leap indicator MUST be 3 if the clock is not synchronized or its 810 maximum error cannot be estimated with the root delay and 811 dispersion. Otherwise, it MUST be 0, 1, 2, depending on whether a 812 leap second is pending in the next 14 day and, if it is, whether 813 it will be inserted or deleted. 815 o Stratum SHOULD be one larger than stratum of the best server it 816 uses for its own synchronization. 818 o Root delay SHOULD be the best server's root delay in addition to 819 the measured delay to the server. 821 o Root dispersion SHOULD be the best server's root dispersion in 822 addition to an estimate of the maximum drift of its own clock 823 since the last update of the clock. 825 The server has a randomly generated reference ID and it MUST track 826 reference IDs of its servers using the Reference IDs Extension Field. 828 For each received request, the server: 830 1. Captures a receive timestamp. 832 2. Checks the version in the request. If it is not equal to 5, it 833 MUST either drop the request, or handle it according to the 834 specification corresponding to the protocol version. The server 835 MAY respond with an NTPv5 message if and only if the request has 836 version 5. 838 3. Drops the request if the format is not valid, mode is not 3, or 839 authentication fails if the MAC Extension Field or another 840 authenticator field is present. The server MUST ignore unknown 841 extension fields. 843 4. Server forms a response with requested extension fields and sets 844 the fields in the header as follows: 846 * Leap Indicator, Stratum, Root delay, and Root dispersion, are 847 set to the current server's values. 849 * Version is set to 5. 851 * Scale is set to the client's requested timescale if it is 852 supported by the server. If not, the server SHOULD respond in 853 any timescale it supports. 855 * The flags are set as follows: 857 Unknown leap is set if the server does not know if a leap 858 second is pending in the next 14 days, i.e. it has no 859 source providing information about leap seconds. 861 Interleaved mode is set if the interleaved mode was requested 862 and a response in the interleaved mode is possible (i.e. a 863 transmit timestamp is associated with the server cookie). 865 * Era is set to the NTP era of the receive timestamp. 867 * Timescale Offset is set to the timescale-specific offset, or 868 0x8000 if unknown. 870 * Server Cookie is set when the interleaved mode is requested 871 and it is supported by the server, even if the response cannot 872 be in the requested mode yet due to the request having an 873 invalid server cookie. The cookie identifies a more accurate 874 transmit timestamp, which can be retrieved by the client later 875 with another request. 877 * Client Cookie is set to the Client Cookie from the request. 879 * Receive Timestamp is set to the server's receive timestamp of 880 the request. 882 * Transmit Timestamp is set to a value which depends on the 883 measurement mode. In the basic mode it is the server's 884 current time when the message if formed. In the interleaved 885 mode it is the transmit timestamp of the previous response 886 identified by the server cookie in the request, captured at 887 some point after the message was formed. 889 5. Adds the Padding Extension field if necessary to make the length 890 of the response equal to the length of the request. 892 6. Drops the response if it is longer than the request to prevent 893 traffic amplification. 895 7. Sends the response. 897 8. Saves the transmit timestamp and server cookie, if the 898 interleaved mode was requested and is supported by the server. 900 9. NTPv5 Negotiation in NTPv4 902 NTPv5 messages are not compatible with NTPv4, even if they do not 903 contain any extension fields. Some widely used NTPv4 implementations 904 are known to ignore the version and interpret all requests as NTPv4. 905 Their responses to NTPv5 requests have a zero client cookie, which 906 means they fail the client's validation and are ignored. 908 The implementations are also known to not respond to requests with an 909 unknown extension field, which prevents an NTPv4 extension field to 910 be specified for NTPv5 negotiation. Instead, the reference timestamp 911 field in the NTPv4 header is reused for this purpose. 913 An NTP server which supports both NTPv4 and NTPv5 SHOULD check the 914 reference timestamp in all NTPv4 client requests. If the reference 915 timestamp contains the value 0x4E5450354E545035 ("NTP5NTP5" in 916 ASCII), it SHOULD respond with the same reference timestamp to 917 indicate it supports NTPv5. 919 An NTP client which supports both NTPv4 and NTPv5, and is not 920 configured to use a particular version, SHOULD start with NTPv4 921 requests having the reference timestamp set to 0x4e5450354e545035. 922 If the server responds with the same reference timestamp, the client 923 SHOULD switch to NTPv5. 925 10. Acknowledgements 927 Some ideas were taken from a different NTPv5 design proposed by 928 Daniel Franke. 930 The author would like to thank Doug Arnold for his contributions and 931 Watson Ladd, Hal Murray, Kurt Roeckx, and Ulrich Windl for their 932 useful comments. 934 11. IANA Considerations 936 This memo includes no request to IANA. 938 12. Security Considerations 940 13. References 942 13.1. Normative References 944 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 945 Requirement Levels", BCP 14, RFC 2119, 946 DOI 10.17487/RFC2119, March 1997, 947 . 949 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 950 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 951 May 2017, . 953 [RFC8573] Malhotra, A. and S. Goldberg, "Message Authentication Code 954 for the Network Time Protocol", RFC 8573, 955 DOI 10.17487/RFC8573, June 2019, 956 . 958 13.2. Informative References 960 [I-D.ietf-ntp-interleaved-modes] 961 Lichvar, M. and A. Malhotra, "NTP Interleaved Modes", 962 draft-ietf-ntp-interleaved-modes-04 (work in progress), 963 September 2020. 965 [IEEE1588] 966 Institute of Electrical and Electronics Engineers, "IEEE 967 std. 1588-2019, "IEEE Standard for a Precision Clock 968 Synchronization for Networked Measurement and Control 969 Systems."", 11 2019, . 971 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 972 "Network Time Protocol Version 4: Protocol and Algorithms 973 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 974 . 976 [RFC7821] Mizrahi, T., "UDP Checksum Complement in the Network Time 977 Protocol (NTP)", RFC 7821, DOI 10.17487/RFC7821, March 978 2016, . 980 Author's Address 982 Miroslav Lichvar 983 Red Hat 984 Purkynova 115 985 Brno 612 00 986 Czech Republic 988 Email: mlichvar@redhat.com