forked from ietf-wg-ntp/draft-ietf-ntp-ntpv5
-
Notifications
You must be signed in to change notification settings - Fork 0
/
ntp-ntpv5.xml
1182 lines (985 loc) · 56.7 KB
/
ntp-ntpv5.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC1321 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.1321.xml">
<!ENTITY RFC2119 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC5905 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5905.xml">
<!ENTITY RFC7384 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7384.xml">
<!ENTITY RFC7821 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7821.xml">
<!ENTITY RFC8174 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
<!ENTITY RFC8573 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8573.xml">
<!ENTITY RFC8915 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8915.xml">
<!ENTITY XLEAVE SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-ntp-interleaved-modes.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes"?>
<?rfc toc="yes"?>
<?rfc tocdepth="3"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-mlichvar-ntp-ntpv5-05" ipr="trust200902">
<front>
<title>Network Time Protocol Version 5</title>
<author fullname="Miroslav Lichvar" initials="M." surname="Lichvar">
<organization>Red Hat</organization>
<address>
<postal>
<street>Purkynova 115</street>
<city>Brno</city>
<region></region>
<code>612 00</code>
<country>Czech Republic</country>
</postal>
<email>mlichvar@redhat.com</email>
</address>
</author>
<date year="2022" month="Aug" day="25"/>
<area>General</area>
<workgroup>Internet Engineering Task Force</workgroup>
<keyword>NTP</keyword>
<abstract>
<t>This document describes the version 5 of the Network Time Protocol (NTP).</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>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.</t>
<t>NTPv5 is similar to <xref target="RFC5905">NTPv4</xref>. The main
differences are:
<list style="numbers">
<t>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.</t>
<t>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.</t>
<t>Timestamps are clearly separated from values used as cookies.</t>
<t>NTPv5 messages can be extended only with extension fields. The MAC
field is wrapped in an extension field.</t>
<t>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.</t>
<t>NTPv5 adds support for other timescales than UTC.</t>
<t>The NTP era number is exchanged in the protocol, which extends the
unambiguous interval of the client from 136 years to about 35000
years.</t>
<t>NTPv5 adds a new measurement mode to provide clients with more
accurate transmit timestamps.</t>
<t>NTPv5 works with sets of reference IDs to prevent synchronization
loops over multiple hosts.</t>
<t>Resolution of the root delay and root dispersion fields is
improved.</t>
<t>Clients don't leak information about their clock (e.g.
timestamps).</t>
</list>
</t>
<section title="Requirements Language">
<t>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 <xref target="RFC2119"/>
<xref target="RFC8174"/> when, and only when, they appear in all
capitals, as shown here.</t>
</section>
</section>
<section title="Basic Concepts">
<t>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.</t>
<t>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.</t>
<t>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 used in
NTPv4.</t>
<t>The sum of the root dispersion and half of the root delay is called
root distance. It is the estimated maximum error of the clock, taking
into account asymmetry in delay and stability of clocks and
measurements.</t>
<t>Servers have randomly generated reference IDs to prevent
synchronization loops.</t>
</section>
<section title="Data Types">
<t>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:
<list style="hanging">
<t hangText="time16"><vspace/>
A 16-bit fixed-point type containing values in seconds. It has 1
signed integer bit (i.e. it is just the sign) and 15 fractional
bits. The minimum value is the fraction -32767/32768 (almost -1
second), the maximum value is 32767/32768 (almost 1 second), and
the resolution is about 30 microseconds. The type has a special
value of 0x8000, which indicates an unknown value.</t>
<t hangText="time32"><vspace/>
A 32-bit fixed-point type containing values in seconds. It has 4
unsigned integer bits and 28 fractional bits. The maximum value is
16 seconds and the resolution is about 3.7 nanoseconds. Note that
this is different than the 32-bit time format in NTPv4.</t>
<t hangText="timestamp64"><vspace/>
A 64-bit fixed-point type containing timestamps. 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, 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. 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.</t>
</list>
</t>
<t>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 to the power of 4 (16 seconds), or a log2 value of -2 is 2 to
the power of -2 (0.25 seconds).</t>
</section>
<section title="Message Format">
<t>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 <xref format="counter"
target="message-format"/>.</t>
<figure align="center" anchor="message-format"
title="Format of NTPv5 messages">
<artwork><![CDATA[
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 | Scale |Stratum| Poll | Precision |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Era | Timescale Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Root Delay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Root Dispersion |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Server Cookie (64) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Client Cookie (64) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Receive Timestamp (64) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Transmit Timestamp (64) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Extension Field 1 (variable) .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Extension Field N (variable) .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>Each NTPv5 message has a header containing the following fields:
<list style="hanging">
<t hangText="Leap indicator (LI)"><vspace/>
A 2-bit field which can have the following values: 0 (normal), 1
(leap second inserted at the end of the month), 2 (leap second
deleted at the end of the month), 3 (not synchronized). The values
1 and 2 are set at most 14 days in advance before the leap second.
In requests it is always 0.</t>
<t hangText="Version Number (VN)"><vspace/>
A 3-bit field containing the value 5.</t>
<t hangText="Mode"><vspace/>
A 3-bit field containing the value 3 (request) or 4 (response).</t>
<t hangText="Scale"><vspace/>
A 4-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:
<list style="hanging">
<t>0: UTC</t>
<t>1: TAI</t>
<t>2: UT1</t>
<t>3: Leap-smeared UTC</t>
</list>
</t>
<t hangText="Stratum"><vspace/>
A 4-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.</t>
<t hangText="Poll"><vspace/>
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.</t>
<t hangText="Precision"><vspace/>
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 don't contain any timestamps, it is always 0.</t>
<t hangText="Flags"><vspace/>
An 8-bit integer that can contain the following flags:
<list style="hanging">
<t hangText="0x1: Unknown leap"><vspace/>
In requests it is 0. In responses a value of 1 indicates the
server does not have a time source which provides information
about leap seconds and the client should interpret the Leap
Indicator as having only two possible values: synchronized (0)
and not synchronized (3).</t>
<t hangText="0x2: Interleaved mode"><vspace/>
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.</t>
</list>
</t>
<t hangText="Era"><vspace/>
An 8-bit unsigned NTP era number corresponding to the receive
timestamp. In requests it is always 0.</t>
<t hangText="Timescale Offset"><vspace/>
A 16-bit value specific to the selected timescale, which is
referenced to the receive timestamp. In requests it is always
0.
<list style="symbols">
<t>In the UTC (0) and TAI (1) timescales it is the TAI-UTC offset
(TAI minus UTC) as a signed integer, or 0x8000 if unknown.</t>
<t>In the UT1 timescale (2) it is the UT1-UTC offset (UT1 minus
UTC) using the time16 type (0x8000 if unknown).</t>
<t>In the leap-smeared UTC (3), it is the current offset between
the leap smeared time and UTC (former minus latter) using the
time16 type (0x8000 if unknown).</t>
</list>
</t>
<t hangText="Root Delay"><vspace/>
A field using the time32 type. In responses it is the server's root
delay. In requests it is always 0.</t>
<t hangText="Root Dispersion"><vspace/>
A field using the time32 type. In responses it is the server's root
dispersion. In requests it is always 0.</t>
<t hangText="Server Cookie"><vspace/>
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.</t>
<t hangText="Client Cookie"><vspace/>
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 valid responses to the requests.</t>
<t hangText="Receive Timestamp"><vspace/>
A field using the timestamp64 type. In requests it is always
0. In responses it is the time when the request was received. The
timestamp corresponds to the end of the reception.</t>
<t hangText="Transmit Timestamp"><vspace/>
A field using the timestamp64 type. In requests it is always
0. In responses it is 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 <xref
target="measurement-modes">Measurement Modes</xref> for detail.</t>
</list>
</t>
<t>The header has 48 octets, which is the minimum length of a valid NTPv5
message. A message can contain zero, one, or multiple extension fields.
The maximum length is not specified, but the length is always divisible
by 4.</t>
</section>
<section title="Extension Fields">
<t>The format of NTPv5 extension fields is shown in Figure <xref
format="counter" target="extension-field"/>.</t>
<figure align="center" anchor="extension-field"
title="Format of NTPv5 extension fields">
<artwork><![CDATA[
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) .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>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 zeroes to the smallest multiple of 4 octets.</t>
<t>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.</t>
<t>Extension fields specified for NTPv4 can be included in NTPv5 messages
as specified for NTPv4.</t>
<t>The rest of this section describes new extension fields specified for
NTPv5. Clients are not required to use or support any of these
extension fields, but servers are required to support some extension
fields.</t>
<section title="Padding Extension Field">
<t>This field 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.</t>
<t>This field MUST be supported on server.</t>
</section>
<section title="MAC Extension Field">
<t>This field authenticates the NTPv5 message with a symmetric key.
Implementations SHOULD use the MAC specified in <xref
target="RFC8573">RFC8573</xref>. 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.</t>
</section>
<section title="Reference IDs Request and Response Extension Fields">
<t>Each NTPv5 server has a randomly generated 120-bit reference ID. 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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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
<xref target="RFC1321">MD5</xref> sum of the address.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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 the extension field. The response
extension field MUST have the same length as the request extension
field. If the request contains an invalid offset, the extension field
MUST be ignored.</t>
<t>The client SHOULD use requests of a constant length for the
association to avoid adding a variation to the measured NTP
delay.</t>
<t>The format of the Reference IDs Request is shown in Figure <xref
format="counter" target="reference-ids-req-ext-field"/>.</t>
<figure align="center" anchor="reference-ids-req-ext-field"
title="Format of Reference IDs Request Extension Field">
<artwork><![CDATA[
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Offset | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
. .
. Padding (variable) .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>The format of the Reference IDs Response is shown in Figure <xref
format="counter" target="reference-ids-res-ext-field"/>.</t>
<figure align="center" anchor="reference-ids-res-ext-field"
title="Format of Reference IDs Response Extension Field">
<artwork><![CDATA[
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. Bloom filter chunk (variable) .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>These fields MUST be supported on server.</t>
</section>
<section title="Server Information Extension Field">
<t>This field provides clients with information about which NTP
versions are supported by the server, as a minimum and maximum
version. The extension field has a fixed length of 8 octets. In
requests, all data fields of the extension are 0. </t>
<figure align="center" anchor="server-information-ext-field"
title="Format of Server Information Extension Field">
<artwork><![CDATA[
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Min. Version | Max. Version | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>This field MUST be supported on server.</t>
</section>
<section title="Correction Extension Field">
<t>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
<xref target="IEEE1588">Precision Time Protocol (PTP)</xref>, 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.</t>
<t>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 <xref format="counter"
target="correction-ext-field"/>.</t>
<figure align="center" anchor="correction-ext-field"
title="Format of Correction Extension Field">
<artwork><![CDATA[
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Origin Correction +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Origin path ID | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Delay Correction +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Delay Path ID | Checksum complement |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>
<list style="hanging">
<t hangText="Field Type"><vspace/>
The type which identifies the Correction extension field (value
TBD).</t>
<t hangText="Length"><vspace/>
The length of the extension field, which is 28 octets.</t>
<t hangText="Origin Correction"><vspace/>
A field which contains a copy of the accumulated delay
correction from the request packet in the NTP exchange.</t>
<t hangText="Origin ID"><vspace/>
A field which contains a copy of the final path ID from the
request packet in the NTP exchange.</t>
<t hangText="Reserved"><vspace/>
16 bit reserved for future specification by the IETF.
Transmit with all zeros.</t>
<t hangText="Delay Correction"><vspace/>
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.</t>
<t hangText="Path ID"><vspace/>
A 16-bit identification number of the path where the delay
correction was updated.</t>
<t hangText="Checksum Complement"><vspace/>
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 <xref
target="RFC7821">RFC 7821</xref>.</t>
</list>
</t>
<t>A correction capable client SHALL transmit the request with the
Origin Correction, Origin ID, Delay Correction and Path ID fields
filled with all zeros.</t>
<t>Network nodes, such as switches and routers, that are NTP
corrections capable SHALL add the difference between the beginning of
an NTP message retransmission and the end of the message reception to
the received Delay Correction value, and update this field. Note that
this time difference might be negative, for example 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. Both
timestamps MUST be based on the same clock. This clock does not need
to be synchronized as long as the frequency is accurate enough such
that resulting time difference estimation errors are acceptable to
the precision required by the application.</t>
<t>If a network node updates the delay correction, it SHOULD also add
the identification numbers of the incoming and outgoing port to the
path ID. Path ID values can be used by clients to determine if the
ntp request and response messages are likely to have traversed the
same network path.</t>
<t>If a network node modified any field of the extension field, it MUST
update the checksum complement field in order to keep the current UDP
checksum valid, or update the UDP checksum itself.</t>
<t>The server SHALL write the received Delay Correction value in the
origin correction field of the response message, and the received
path ID value in the origin ID field. The server SHALL set the Delay
Correction field and Path ID fields to all zeros</t>
</section>
<section title="Reference Timestamp Extension Field">
<t>This fields contains the time of the last update of the clock. It
has a fixed length of 12 octets. In requests, the timestamp is always
0.</t>
<t>(Is this really needed? It was mostly unused in NTPv4.)</t>
<figure align="center" anchor="reference-timestamp-ext-field"
title="Format of Reference Timestamp Extension Field">
<artwork><![CDATA[
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Reference Timestamp (64) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
</section>
<section title="Monotonic Timestamp Extension Field">
<t>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.</t>
<t>The Monotonic Timestamp Extension Field contains an extra receive
timestamp with a 32-bit epoch identifier 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.</t>
<t>The epoch identifier is a random number which is changed when
frequency transfer needs to be restarted, e.g. due to a step of the
clock.</t>
<figure align="center" anchor="monotonic-timestamp-ext-field"
title="Format of Monotonic Timestamp Extension Field">
<artwork><![CDATA[
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Epoch ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Monotonic Receive Timestamp (64) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>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.</t>
</section>
</section>
<section title="Measurement Modes" anchor="measurement-modes">
<t>An NTPv5 client needs four timestamps to measure the offset and delay
of its clock relative to the server's clock:
<list style="numbers">
<t>T1 - client's transmit timestamp of a request</t>
<t>T2 - server's receive timestamp of the request</t>
<t>T3 - server's transmit timestamp of a response</t>
<t>T4 - client's receive timestamp of the response</t>
</list>
</t>
<t>The offset, delay and dispersion are calculated as:
<list style="symbols">
<t>offset = ((T2 + T3) - (T4 + T1) + (Cd - Co)) / 2</t>
<t>delay = |(T4 - T1) - (T3 - T2) - (Cd + Co)|</t>
<t>dispersion = |T4 - T1| * DR</t>
</list>
where
<list style="symbols">
<t>T1, T2, T3, T4 are the receive and transmit timestamps of a
request and response</t>
<t>Co is the Origin Correction from the Correction Extension Field if
present in the response and has acceptable values, zero otherwise</t>
<t>Cd is the Delay Correction from the Correction Extension Field if
present in the response and has acceptable values, zero otherwise</t>
<t>DR is the client's dispersion rate</t>
</list>
</t>
<t>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.</t>
<t>An example of cookies and timestamps in an NTPv5 exchange using the
basic mode is shown in Figure <xref format="counter"
target="basic-exchange"></xref>.</t>
<figure align="center" anchor="basic-exchange"
title="Cookies and timestamps in basic mode">
<artwork><![CDATA[
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 |
+----+ +----+ +----+ +----+ +----+ +----+
]]></artwork>
</figure>
<t>From the three exchanges in this example, the client would use the
the following sets of timestamps:
<list style="symbols">
<t>(t1, t2, t3, t4)</t>
<t>(t5, t6, t7, t8)</t>
<t>(t9, t10, t11, t12)</t>
</list>
</t>
<t>For NTPv4, the interleaved mode is described in <xref
target="I-D.ietf-ntp-interleaved-modes">NTP Interleaved Modes</xref>.
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.</t>
<t>An example of an NTPv5 exchange using the interleaved mode is shown in
Figure <xref format="counter" target="interleaved-exchange"></xref>.
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. 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).</t>
<figure align="center" anchor="interleaved-exchange"
title="Cookies and timestamps in interleaved mode">
<artwork><![CDATA[
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'|
+----+ +----+ +----+ +----+ +----+ +----+
]]></artwork>
</figure>
<t>From the three exchanges in this example, the client would use the
following sets of timestamps:
<list style="symbols">
<t>(t1, t2, t3', t4)</t>
<t>(t1, t2, t3, t4) or (t5, t6, t3, t4)</t>
<t>(t9, t10, t11', t12)</t>
</list>
</t>
</section>
<section title="Client Operation">
<t>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.</t>
<t>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 at least a polling interval of 64 seconds, increasing
up to at least 1024 seconds.</t>
<t>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.</t>
<t>On each poll, the client:
<list style="numbers">
<t>Generates a new random cookie.</t>
<t>Formats a request with necessary extension fields and the fields
in the header all zero except:
<list style="symbols">
<t>Version is set to 5.</t>
<t>Mode is set to 3.</t>
<t>Scale is set to the timescale in which the client wants to
operate.</t>
<t>Poll is set to the rounded log2 value of the current client's
polling interval in seconds.</t>
<t>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).</t>
<t>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).</t>
<t>Client cookie is set to the newly generated cookie.</t>
</list>
</t>
<t>Sends the request to the server to the UDP port 123 and captures a
transmit timestamp.</t>
<t>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.</t>
<t>Checks whether the response is usable for synchronization of the
clock. Such a response has a leap indicator not equal to 3, 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 provided or
known, or drop the response.</t>
<t>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.</t>
<t>Calculates the offset, delay, and dispersion.</t>
</list>
</t>
<t>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.</t>
</section>
<section title="Server Operation">
<t>A server receives requests on the UDP port 123. The server
MUST support measurements in the basic mode. It MAY support the
interleaved mode.</t>
<t>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.</t>
<t>The server maintains its leap indicator, stratum, root delay, and root
dispersion:
<list style="symbols">
<t>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 day and, if it is, whether it
will be inserted or deleted.</t>
<t>Stratum SHOULD be one larger than stratum of the best
server it uses for its own synchronization.</t>
<t>Root delay SHOULD be the best server's root delay in addition to
the measured delay to the server.</t>
<t>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.</t>
</list>
</t>
<t>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.</t>
<t>For each received request, the server:
<list style="numbers">
<t>Captures a receive timestamp.</t>
<t>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.</t>
<t>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