-
Notifications
You must be signed in to change notification settings - Fork 6
/
ntp-ntpv5.xml
1465 lines (1230 loc) · 71.9 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-ietf-ntp-ntpv5-02" ipr="trust200902">
<front>
<title>Network Time Protocol Version 5</title>
<author fullname="Miroslav Lichvar" initials="M." surname="Lichvar">
<organization>Red Hat</organization>
<address>
<email>[email protected]</email>
</address>
</author>
<date year="2024" month="Jun" day="19"/>
<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>Synchronized server clock is indicated in a separate flag instead
of the leap indicator.</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 interleaved 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. Reference IDs have 120 bits instead of
32 bits.</t>
<t>Resolution of the root delay and root dispersion fields is
improved from about 15 microseconds to about 4 nanoseconds.</t>
<t>Clients do not 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 enable detection and
prevention of 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 signed 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 or value that is
too large to be represented by this type.</t>
<t hangText="time32"><vspace/>
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.</t>
<t hangText="timestamp64"><vspace/>
A 64-bit unsigned fixed-point type containing a timestamp describes
in seconds. It has 32 signed
integer bits and 32 fractional bits. It spans an interval of about
136 years and has a resolution of about 0.23 nanoseconds. It can be
used in different timescales. In the UTC timescale it is the number
of SI seconds since 1 Jan 1972 plus 2272060800 (number of seconds
since 1 Jan 1900 assuming 86400-second days), excluding leap
seconds. Timestamps in the TAI timescale are the same except they
include leap seconds and extra 10 seconds for the original
difference between TAI and UTC in 1972, when leap seconds were
introduced. A value of 0 indicates an unknown or invalid timestamp.
One interval covered by the type is called an NTP era. The era
starting at the epoch is era number 0, the following era is number
1, and so on.</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^4 (2 to the power of 4, 16) seconds, or a log2 value of -2
is 2^-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 | Stratum | Poll | Precision |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timescale | Era | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Root Delay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Root Dispersion |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Server Cookie (64) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Client Cookie (64) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Receive Timestamp (64) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Transmit Timestamp (64) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Extension Field 1 (variable) .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Extension Field N (variable) .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></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 indicating upcoming leap seconds. In requests it is
always 0. In responses it has one of the following values:
<list style="hanging">
<t hangText="0: Normal"><vspace/>
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).</t>
<t hangText="1: Insert leap second"><vspace/>
A leap second will be inserted in the next 14 days at the end
of the current month.</t>
<t hangText="2: Delete leap second"><vspace/>
A leap second will be deleted in the next 14 days at the end of
the current month.</t>
<t hangText="3: Unknown"><vspace/>
The server does not have a time source or other source
providing information about leap seconds.</t>
</list>
</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="Stratum"><vspace/>
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.</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. 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.</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 do not contain any timestamps, it is always 0.</t>
<t hangText="Timescale"><vspace/>
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:
<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="Era"><vspace/>
An 8-bit unsigned NTP era number corresponding to the receive
timestamp. In requests it is always 0.</t>
<t hangText="Flags"><vspace/>
A 16-bit integer that can contain the following flags:
<list style="hanging">
<t hangText="0x1: Synchronized"><vspace/>
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.</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>
<t hangText="0x4: Authentication NAK"><vspace/>
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.</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 related 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 by
the server. 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 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 <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 optional extension fields (zero or more).
The maximum length is not specified, but the length MUST be 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 zeros 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 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.</t>
<section title="Draft Identification Extension Field">
<t>Note to the editors: this section must be removed before final publication.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
</section>
<section title="Padding Extension Field">
<t>This field, with type [[TBD]] (draft: 0xF501), is used by servers to pad the response to the same length
as the request if the response does not contain all requested
extension fields, or some have a variable length. It can have any
length. The data field of the extension field SHOULD contain zeros
and it MUST be ignored by the receiver.</t>
<t>This field MUST be supported on servers.</t>
</section>
<section title="MAC Extension Field">
<t>This field, with type [[TBD]] (draft: 0xF502), 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
(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.</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 <xref target="Bloom">Bloom filter</xref>
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 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.</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 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.</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 = [[TBD]] (draft 0xF503) | 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 = [[TBD]] (draft 0xF504) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. Bloom filter chunk (variable) .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>These fields MUST be supported on servers which can be synchronized
to other NTP servers (i.e. they can be in a synchronization loop).</t>
</section>
<section title="Server Information Extension Field">
<t>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.</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 = [[TBD]] (draft 0xF505) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Supported NTP versions | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>This field MUST be supported on servers.</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 and network delay.</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 = [[TBD]] (draft 0xF506) | 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 Path 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>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.</t>
<t>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:
<list style="numbers">
<t>It is an IPv4 or IPv6 packet (e.g. EtherType of 0x0800 or
0x86DD)</t>
<t>The IP protocol number is 17 (UDP)</t>
<t>The UDP source port or destination port is 123 (NTP)</t>
<t>The NTP version is 5</t>
<t>The NTP message contains the Correction Extension Field</t>
</list>
</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>The Correction Extension Field is required to be the last extension
field in the message to provide an indicator at a fixed offset from
the ending of the message reception (which might simplify hardware
implementation of the correction) and to avoid being covered by the
MAC Extension Field, or other authenticator extension fields (e.g.
Network Time Security). It is the exception in the requirement
specified for the MAC Extension Field. If the corrections were
covered by the authenticator fields, the network devices would need
to have access to the keys and have a significant additional
complexity in order to update the authenticator fields when they
modify the Correction Extension Field.</t>
<t>As the Correction Extension Field is not protected, NTP clients
MUST validate the corrections before their application as specified
in <xref target="measurement-modes">Measurement Modes</xref>. Clients
MUST ignore an unexpected Correction Extension Field in the response,
i.e. if it was not included in the request.</t>
</section>
<section title="Reference Timestamp Extension Field">
<t>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.</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 = [[TBD]] (draft 0xF507) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Reference Timestamp (64) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
</section>
<section title="Monotonic Receive 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 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.</t>
<t>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.</t>
<figure align="center" anchor="monotonic-timestamp-ext-field"
title="Format of Monotonic Receive 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 = [[TBD]] (draft 0xF508) | 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 title="Secondary Receive Timestamp Extension Field">
<t>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.</t>
<t>In requests, the Timescale field selects the requested timescale.
The other data fields in the extension field MUST be set to 0.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<figure align="center" anchor="secondary-receive-timestamp-ext-field"
title="Format of Secondary Receive 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 = [[TBD]] (draft 0xF509) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timescale | Era | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Secondary Receive Timestamp (64) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
</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)) / 2</t>
<t>delay = |(T4 - T1) - (T3 - T2)|</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>DR is the client's dispersion rate</t>
</list>
</t>
<t>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:
<list style="symbols">
<t>offset_c = offset + (Cd - Co) / 2</t>
<t>delay_c = delay - (Cd + Co - Drx - Dtx) * (1 - FC)|</t>
</list>
where
<list style="symbols">
<t>Co is the Origin Correction from the response to the request
corresponding to timestamps T1 and T2</t>
<t>Cd is the Delay Correction from the response corresponding to
timestamps T3 and T4</t>
<t>FC is the maximum expected frequency error of devices providing
the delay corrections (e.g. 100 ppm)</t>
<t>Drx is the time it took to receive the frame containing the
response corresponding to T3 and T4</t>
<t>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.</t>
</list>
</t>
<t>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.</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>.