File: rfc2030.txt

package info (click to toggle)
doc-rfc 20181229-2
  • links: PTS, VCS
  • area: non-free
  • in suites: buster
  • size: 570,944 kB
  • sloc: xml: 285,646; sh: 107; python: 90; perl: 42; makefile: 14
file content (1011 lines) | stat: -rw-r--r-- 48,620 bytes parent folder | download | duplicates (5)
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
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011






Network Working Group                                           D. Mills
Request for Comments: 2030                        University of Delaware
Obsoletes: 1769                                             October 1996
Category: Informational


             Simple Network Time Protocol (SNTP) Version 4
                         for IPv4, IPv6 and OSI

Status of this Memo

   This memo provides information for the Internet community.  This memo
   does not specify an Internet standard of any kind.  Distribution of
   this memo is unlimited.

Abstract

   This memorandum describes the Simple Network Time Protocol (SNTP)
   Version 4, which is an adaptation of the Network Time Protocol (NTP)
   used to synchronize computer clocks in the Internet. SNTP can be used
   when the ultimate performance of the full NTP implementation
   described in RFC-1305 is not needed or justified. When operating with
   current and previous NTP and SNTP versions, SNTP Version 4 involves
   no changes to the NTP specification or known implementations, but
   rather a clarification of certain design features of NTP which allow
   operation in a simple, stateless remote-procedure call (RPC) mode
   with accuracy and reliability expectations similar to the UDP/TIME
   protocol described in RFC-868.

   The only significant protocol change in SNTP Version 4 over previous
   versions of NTP and SNTP is a modified header interpretation to
   accommodate Internet Protocol Version 6 (IPv6) [DEE96] and OSI
   [COL94] addressing. However, SNTP Version 4 includes certain optional
   extensions to the basic Version 3 model, including an anycast mode
   and an authentication scheme designed specifically for multicast and
   anycast modes. While the anycast mode extension is described in this
   document, the authentication scheme extension will be described in
   another document to be published later. Until such time that a
   definitive specification is published, these extensions should be
   considered provisional.

   This memorandum obsoletes RFC-1769, which describes SNTP Version 3.
   Its purpose is to correct certain inconsistencies in the previous
   document and to clarify header formats and protocol operations for
   current NTP Version 3 (IPv4) and proposed NTP Version 4 (IPv6 and
   OSI), which are also used for SNTP. A working knowledge of the NTP
   Version 3 specification RFC-1305 is not required for an
   implementation of SNTP.



Mills                        Informational                      [Page 1]

RFC 2030             SNTPv4 for IPv4, IPv6 and OSI          October 1996


1. Introduction

   The Network Time Protocol (NTP) Version 3 specified in RFC-1305
   [MIL92] is widely used to synchronize computer clocks in the global
   Internet. It provides comprehensive mechanisms to access national
   time and frequency dissemination services, organize the time-
   synchronization subnet and adjust the local clock in each
   participating subnet peer. In most places of the Internet of today,
   NTP provides accuracies of 1-50 ms, depending on the characteristics
   of the synchronization source and network paths.

   RFC-1305 specifies the NTP Version 3 protocol machine in terms of
   events, states, transition functions and actions and, in addition,
   engineered algorithms to improve the timekeeping quality and mitigate
   among several synchronization sources, some of which may be faulty.
   To achieve accuracies in the low milliseconds over paths spanning
   major portions of the Internet of today, these intricate algorithms,
   or their functional equivalents, are necessary. However, in many
   cases accuracies in the order of significant fractions of a second
   are acceptable. In such cases, simpler protocols such as the Time
   Protocol [POS83], have been used for this purpose. These protocols
   usually involve an RPC exchange where the client requests the time of
   day and the server returns it in seconds past some known reference
   epoch.

   NTP is designed for use by clients and servers with a wide range of
   capabilities and over a wide range of network delays and jitter
   characteristics. Most users of the Internet NTP synchronization
   subnet of today use a software package including the full suite of
   NTP options and algorithms, which are relatively complex, real-time
   applications (see http://www.eecis.udel.edu/~ntp). While the software
   has been ported to a wide variety of hardware platforms ranging from
   personal computers to supercomputers, its sheer size and complexity
   is not appropriate for many applications. Accordingly, it is useful
   to explore alternative access strategies using simpler software
   appropriate for less stringent accuracy expectations.

   This document describes the Simple Network Time Protocol (SNTP)
   Version 4, which is a simplified access strategy for servers and
   clients using NTP Version 3 as now specified and deployed in the
   Internet, as well as NTP Version 4 now under development. The access
   paradigm is identical to the UDP/TIME Protocol and, in fact, it
   should be easily possible to adapt a UDP/TIME client implementation,
   say for a personal computer, to operate using SNTP. Moreover, SNTP is
   also designed to operate in a dedicated server configuration
   including an integrated radio clock. With careful design and control
   of the various latencies in the system, which is practical in a
   dedicated design, it is possible to deliver time accurate to the



Mills                        Informational                      [Page 2]

RFC 2030             SNTPv4 for IPv4, IPv6 and OSI          October 1996


   order of microseconds.

   SNTP Version 4 is designed to coexist with existing NTP and SNTP
   Version 3 clients and servers, as well as proposed Version 4 clients
   and servers. When operating with current and previous versions of NTP
   and SNTP, SNTP Version 4 requires no changes to the protocol or
   implementations now running or likely to be implemented specifically
   for NTP ir SNTP Version 4. To a NTP or SNTP server, NTP and SNTP
   clients are undistinguishable; to a NTP or SNTP client, NTP and SNTP
   servers are undistinguishable. Like NTP servers operating in non-
   symmetric modes, SNTP servers are stateless and can support large
   numbers of clients; however, unlike most NTP clients, SNTP clients
   normally operate with only a single server. NTP and SNTP Version 3
   servers can operate in unicast and multicast modes. In addition, SNTP
   Version 4 clients and servers can implement extensions to operate in
   anycast mode.

   It is strongly recommended that SNTP be used only at the extremities
   of the synchronization subnet. SNTP clients should operate only at
   the leaves (highest stratum) of the subnet and in configurations
   where no NTP or SNTP client is dependent on another SNTP client for
   synchronization. SNTP servers should operate only at the root
   (stratum 1) of the subnet and then only in configurations where no
   other source of synchronization other than a reliable radio or modem
   time service is available. The full degree of reliability ordinarily
   expected of primary servers is possible only using the redundant
   sources, diverse subnet paths and crafted algorithms of a full NTP
   implementation. This extends to the primary source of synchronization
   itself in the form of multiple radio or modem sources and backup
   paths to other primary servers should all sources fail or the
   majority deliver incorrect time. Therefore, the use of SNTP rather
   than NTP in primary servers should be carefully considered.

   An important provision in this document is the reinterpretation of
   certain NTP Versino 4 header fields which provide for IPv6 and OSI
   addressing and optional anycast extensions designed specifically for
   multicast service. These additions are in conjunction with the
   proposed NTP Version 4 specification, which will appear as a separate
   document. The only difference between the current NTP Version 3 and
   proposed NTP Version 4 header formats is the interpretation of the
   four-octet Reference Identifier field, which is used primarily to
   detect and avoid synchronization loops. In Version 3 and Version 4
   primary (stratum-1) servers, this field contains the four-character
   ASCII reference identifier defined later in this document. In Version
   3 secondary servers and clients, it contains the 32-bit IPv4 address
   of the synchronization source. In Version 4 secondary servers and
   clients, it contains the low order 32 bits of the last transmit
   timestamp received from the synchronization source.



Mills                        Informational                      [Page 3]

RFC 2030             SNTPv4 for IPv4, IPv6 and OSI          October 1996


   In the case of OSI, the Connectionless Transport Service (CLTS) is
   used [ISO86]. Each SNTP packet is transmitted as tht TS-Userdata
   parameter of a T-UNITDATA Request primitive. Alternately, the header
   can be encapsulated in a TPDU which itself is transported using UDP
   [DOB91]. It is not advised that NTP be operated at the upper layers
   of the OSI stack, such as might be inferred from [FUR94], as this
   could seriously degrade accuracy. With the header formats defined in
   this document, it is in principle possible to interwork between
   servers and clients of one protocol family and another, although the
   practical difficulties may make this inadvisable.

      In the following, indented paragraphs such as this one contain
      information not required by the formal protocol specification, but
      considered good practice in protocol implementations.

2. Operating Modes and Addressing

   SNTP Version 4 can operate in either unicast (point to point),
   multicast (point to multipoint) or anycast (multipoint to point)
   modes. A unicast client sends a request to a designated server at its
   unicast address and expects a reply from which it can determine the
   time and, optionally, the roundtrip delay and local clock offset
   relative to the server. A multicast server periodically sends a
   unsolicited message to a designated IPv4 or IPv6 local broadcast
   address or multicast group address and ordinarily expects no requests
   from clients. A multicast client listens on this address and
   ordinarily sends no requests. An anycast client sends a request to a
   designated IPv4 or IPv6 local broadcast address or multicast group
   address. One or more anycast servers reply with their individual
   unicast addresses. The client binds to the first one received, then
   continues operation in unicast mode.

      Multicast servers should respond to client unicast requests, as
      well as send unsolicited multicast messages. Multicast clients may
      send unicast requests in order to determine the network
      propagation delay between the server and client and then continue
      operation in multicast mode.

   In unicast mode, the client and server end-system addresses are
   assigned following the usual IPv4, IPv6 or OSI conventions. In
   multicast mode, the server uses a designated local broadcast address
   or multicast group address. An IP local broadcast address has scope
   limited to a single IP subnet, since routers do not propagate IP
   broadcast datagrams. On the other hand, an IP multicast group address
   has scope extending to potentially the entire Internet. The scoping,
   routing and group membership procedures are determined by
   considerations beyond the scope of this document. For IPv4, the IANA
   has assigned the multicast group address 224.0.1.1 for NTP, which is



Mills                        Informational                      [Page 4]

RFC 2030             SNTPv4 for IPv4, IPv6 and OSI          October 1996


   used both by multicast servers and anycast clients. NTP multicast
   addresses for IPv6 and OSI have yet to be determined.

   Multicast clients listen on the designated local broadcast address or
   multicast group address. In the case of local broadcast addresses, no
   further provisions are necessary. In the case of IP multicast
   addresses, the multicast client and anycast server must implement the
   Internet Group Management Protocol (IGMP) [DEE89], in order that the
   local router joins the multicast group and relays messages to the
   IPv4 or IPv6 multicast group addresses assigned by the IANA. Other
   than the IP addressing conventions and IGMP, there is no difference
   in server or client operations with either the local broadcast
   address or multicast group address.

      It is important to adjust the time-to-live (TTL) field in the IP
      header of multicast messages to a reasonable value, in order to
      limit the network resources used by this (and any other) multicast
      service. Only multicast clients in scope will receive multicast
      server messages. Only cooperating anycast servers in scope will
      reply to a client request. The engineering principles which
      determine the proper value to be used are beyond the scope of this
      document.

   Anycast mode is designed for use with a set of cooperating servers
   whose addresses are not known beforehand by the client. An anycast
   client sends a request to the designated local broadcast or multicast
   group address as described below. For this purpose, the NTP multicast
   group address assigned by the IANA is used. One or more anycast
   servers listen on the designated local broadcast address or multicast
   group address. Each anycast server, upon receiving a request, sends a
   unicast reply message to the originating client. The client then
   binds to the first such message received and continues operation in
   unicast mode. Subsequent replies from other anycast servers are
   ignored.

      In the case of SNTP as specified herein, there is a very real
      vulnerability that SNTP multicast clients can be disrupted by
      misbehaving or hostile SNTP or NTP multicast servers elsewhere in
      the Internet, since at present all such servers use the same IPv4
      multicast group address assigned by the IANA. Where necessary,
      access control based on the server source address can be used to
      select only the designated server known to and trusted by the
      client. The use of cryptographic authentication scheme defined in
      RFC-1305 is optional; however, implementors should be advised that
      extensions to this scheme are planned specifically for NTP
      multicast and anycast modes.





Mills                        Informational                      [Page 5]

RFC 2030             SNTPv4 for IPv4, IPv6 and OSI          October 1996


      While not integral to the SNTP specification, it is intended that
      IP broadcast addresses will be used primarily in IP subnets and
      LAN segments including a fully functional NTP server with a number
      of dependent SNTP multicast clients on the same subnet, while IP
      multicast group addresses will be used only in cases where the TTL
      is engineered specifically for each service domain.

      In NTP Version 3, the reference identifier was often used to
      walk-back the synchronization subnet to the root (primary server)
      for management purposes. In NTP Version 4, this feature is not
      available, since the addresses are longer than 32 bits. However,
      the intent in the protocol design was to provide a way to detect
      and avoid loops. A peer could determine that a loop was possible
      by comparing the contents of this field with the IPv4 destination
      address in the same packet. A NTP Version 4 server can accomplish
      the same thing by comparing the contents of this field with the
      low order 32 bits of the originate timestamp in the same packet.
      There is a small possibility of false alarm in this scheme, but
      the false alarm rate can be minimized by randomizing the low order
      unused bits of the transmit timestamp.

3. NTP Timestamp Format

   SNTP uses the standard NTP timestamp format described in RFC-1305 and
   previous versions of that document. In conformance with standard
   Internet practice, NTP data are specified as integer or fixed-point
   quantities, with bits numbered in big-endian fashion from 0 starting
   at the left, or high-order, position. Unless specified otherwise, all
   quantities are unsigned and may occupy the full field width with an
   implied 0 preceding bit 0.

   Since NTP timestamps are cherished data and, in fact, represent the
   main product of the protocol, a special timestamp format has been
   established. NTP timestamps are represented as a 64-bit unsigned
   fixed-point number, in seconds relative to 0h on 1 January 1900. The
   integer part is in the first 32 bits and the fraction part in the
   last 32 bits. In the fraction part, the non-significant low order can
   be set to 0.

      It is advisable to fill the non-significant low order bits of the
      timestamp with a random, unbiased bitstring, both to avoid
      systematic roundoff errors and as a means of loop detection and
      replay detection (see below). One way of doing this is to generate
      a random bitstring in a 64-bit word, then perform an arithmetic
      right shift a number of bits equal to the number of significant
      bits of the timestamp, then add the result to the original
      timestamp.




Mills                        Informational                      [Page 6]

RFC 2030             SNTPv4 for IPv4, IPv6 and OSI          October 1996


   This format allows convenient multiple-precision arithmetic and
   conversion to UDP/TIME representation (seconds), but does complicate
   the conversion to ICMP Timestamp message representation, which is in
   milliseconds. The maximum number that can be represented is
   4,294,967,295 seconds with a precision of about 200 picoseconds,
   which should be adequate for even the most exotic requirements.

                        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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Seconds                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Seconds Fraction (0-padded)                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Note that, since some time in 1968 (second 2,147,483,648) the most
   significant bit (bit 0 of the integer part) has been set and that the
   64-bit field will overflow some time in 2036 (second 4,294,967,296).
   Should NTP or SNTP be in use in 2036, some external means will be
   necessary to qualify time relative to 1900 and time relative to 2036
   (and other multiples of 136 years). There will exist a 200-picosecond
   interval, henceforth ignored, every 136 years when the 64-bit field
   will be 0, which by convention is interpreted as an invalid or
   unavailable timestamp.

      As the NTP timestamp format has been in use for the last 17 years,
      it remains a possibility that it will be in use 40 years from now
      when the seconds field overflows. As it is probably inappropriate
      to archive NTP timestamps before bit 0 was set in 1968, a
      convenient way to extend the useful life of NTP timestamps is the
      following convention: If bit 0 is set, the UTC time is in the
      range 1968-2036 and UTC time is reckoned from 0h 0m 0s UTC on 1
      January 1900. If bit 0 is not set, the time is in the range 2036-
      2104 and UTC time is reckoned from 6h 28m 16s UTC on 7 February
      2036. Note that when calculating the correspondence, 2000 is not a
      leap year. Note also that leap seconds are not counted in the
      reckoning.

4. NTP Message Format

   Both NTP and SNTP are clients of the User Datagram Protocol (UDP)
   [POS80], which itself is a client of the Internet Protocol (IP)
   [DAR81]. The structure of the IP and UDP headers is described in the
   cited specification documents and will not be detailed further here.
   The UDP port number assigned to NTP is 123, which should be used in
   both the Source Port and Destination Port fields in the UDP header.
   The remaining UDP header fields should be set as described in the
   specification.



Mills                        Informational                      [Page 7]

RFC 2030             SNTPv4 for IPv4, IPv6 and OSI          October 1996


   Below is a description of the NTP/SNTP Version 4 message format,
   which follows the IP and UDP headers. This format is identical to
   that described in RFC-1305, with the exception of the contents of the
   reference identifier field. The header fields are defined as follows:

                           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   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          Root Delay                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Root Dispersion                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Reference Identifier                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |                   Reference Timestamp (64)                    |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |                   Originate Timestamp (64)                    |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |                    Receive Timestamp (64)                     |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |                    Transmit Timestamp (64)                    |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 Key Identifier (optional) (32)                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |                                                               |
      |                 Message Digest (optional) (128)               |
      |                                                               |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   As described in the next section, in SNTP most of these fields are
   initialized with pre-specified data. For completeness, the function
   of each field is briefly summarized below.







Mills                        Informational                      [Page 8]

RFC 2030             SNTPv4 for IPv4, IPv6 and OSI          October 1996


   Leap Indicator (LI): This is a two-bit code warning of an impending
   leap second to be inserted/deleted in the last minute of the current
   day, with bit 0 and bit 1, respectively, coded as follows:

      LI       Value     Meaning
      -------------------------------------------------------
      00       0         no warning
      01       1         last minute has 61 seconds
      10       2         last minute has 59 seconds)
      11       3         alarm condition (clock not synchronized)

   Version Number (VN): This is a three-bit integer indicating the
   NTP/SNTP version number. The version number is 3 for Version 3 (IPv4
   only) and 4 for Version 4 (IPv4, IPv6 and OSI). If necessary to
   distinguish between IPv4, IPv6 and OSI, the encapsulating context
   must be inspected.

   Mode: This is a three-bit integer indicating the mode, with values
   defined as follows:

      Mode     Meaning
      ------------------------------------
      0        reserved
      1        symmetric active
      2        symmetric passive
      3        client
      4        server
      5        broadcast
      6        reserved for NTP control message
      7        reserved for private use

   In unicast and anycast modes, the client sets this field to 3
   (client) in the request and the server sets it to 4 (server) in the
   reply. In multicast mode, the server sets this field to 5
   (broadcast).

   Stratum: This is a eight-bit unsigned integer indicating the stratum
   level of the local clock, with values defined as follows:

      Stratum  Meaning
      ----------------------------------------------
      0        unspecified or unavailable
      1        primary reference (e.g., radio clock)
      2-15     secondary reference (via NTP or SNTP)
      16-255   reserved






Mills                        Informational                      [Page 9]

RFC 2030             SNTPv4 for IPv4, IPv6 and OSI          October 1996


   Poll Interval: This is an eight-bit signed integer indicating the
   maximum interval between successive messages, in seconds to the
   nearest power of two. The values that can appear in this field
   presently range from 4 (16 s) to 14 (16284 s); however, most
   applications use only the sub-range 6 (64 s) to 10 (1024 s).

   Precision: This is an eight-bit signed integer indicating the
   precision of the local clock, in seconds to the nearest power of two.
   The values that normally appear in this field range from -6 for
   mains-frequency clocks to -20 for microsecond clocks found in some
   workstations.

   Root Delay: This is a 32-bit signed fixed-point number indicating the
   total roundtrip delay to the primary reference source, in seconds
   with fraction point between bits 15 and 16. Note that this variable
   can take on both positive and negative values, depending on the
   relative time and frequency offsets. The values that normally appear
   in this field range from negative values of a few milliseconds to
   positive values of several hundred milliseconds.

   Root Dispersion: This is a 32-bit unsigned fixed-point number
   indicating the nominal error relative to the primary reference
   source, in seconds with fraction point between bits 15 and 16. The
   values that normally appear in this field range from 0 to several
   hundred milliseconds.

   Reference Identifier: This is a 32-bit bitstring identifying the
   particular reference source. In the case of NTP Version 3 or Version
   4 stratum-0 (unspecified) or stratum-1 (primary) servers, this is a
   four-character ASCII string, left justified and zero padded to 32
   bits. In NTP Version 3 secondary servers, this is the 32-bit IPv4
   address of the reference source. In NTP Version 4 secondary servers,
   this is the low order 32 bits of the latest transmit timestamp of the
   reference source. NTP primary (stratum 1) servers should set this
   field to a code identifying the external reference source according
   to the following list. If the external reference is one of those
   listed, the associated code should be used. Codes for sources not
   listed can be contrived as appropriate.













Mills                        Informational                     [Page 10]

RFC 2030             SNTPv4 for IPv4, IPv6 and OSI          October 1996


      Code     External Reference Source
      ----------------------------------------------------------------
      LOCL     uncalibrated local clock used as a primary reference for
               a subnet without external means of synchronization
      PPS      atomic clock or other pulse-per-second source
               individually calibrated to national standards
      ACTS     NIST dialup modem service
      USNO     USNO modem service
      PTB      PTB (Germany) modem service
      TDF      Allouis (France) Radio 164 kHz
      DCF      Mainflingen (Germany) Radio 77.5 kHz
      MSF      Rugby (UK) Radio 60 kHz
      WWV      Ft. Collins (US) Radio 2.5, 5, 10, 15, 20 MHz
      WWVB     Boulder (US) Radio 60 kHz
      WWVH     Kaui Hawaii (US) Radio 2.5, 5, 10, 15 MHz
      CHU      Ottawa (Canada) Radio 3330, 7335, 14670 kHz
      LORC     LORAN-C radionavigation system
      OMEG     OMEGA radionavigation system
      GPS      Global Positioning Service
      GOES     Geostationary Orbit Environment Satellite

   Reference Timestamp: This is the time at which the local clock was
   last set or corrected, in 64-bit timestamp format.

   Originate Timestamp: This is the time at which the request departed
   the client for the server, in 64-bit timestamp format.

   Receive Timestamp: This is the time at which the request arrived at
   the server, in 64-bit timestamp format.

   Transmit Timestamp: This is the time at which the reply departed the
   server for the client, in 64-bit timestamp format.

   Authenticator (optional): When the NTP authentication scheme is
   implemented, the Key Identifier and Message Digest fields contain the
   message authentication code (MAC) information defined in Appendix C
   of RFC-1305.

5. SNTP Client Operations

   A SNTP client can operate in multicast mode, unicast mode or anycast
   mode. In multicast mode, the client sends no request and waits for a
   broadcast (mode 5) from a designated multicast server. In unicast
   mode, the client sends a request (mode 3) to a designated unicast
   server and expects a reply (mode 4) from that server. In anycast
   mode, the client sends a request (mode 3) to a designated local
   broadcast or multicast group address and expects a reply (mode 4)
   from one or more anycast servers. The client uses the first reply



Mills                        Informational                     [Page 11]

RFC 2030             SNTPv4 for IPv4, IPv6 and OSI          October 1996


   received to establish the particular server for subsequent unicast
   operations. Later replies from this server (duplicates) or any other
   server are ignored. Other than the selection of address in the
   request, the operations of anycast and unicast clients are identical.
   Requests are normally sent at intervals from 64 s to 1024 s,
   depending on the frequency tolerance of the client clock and the
   required accuracy.

   A unicast or anycast client initializes the NTP message header, sends
   the request to the server and strips the time of day from the
   Transmit Timestamp field of the reply. For this purpose, all of the
   NTP header fields shown above can be set to 0, except the first octet
   and (optional) Transmit Timestamp fields. In the first octet, the LI
   field is set to 0 (no warning) and the Mode field is set to 3
   (client). The VN field must agree with the version number of the
   NTP/SNTP server; however, Version 4 servers will also accept previous
   versions. Version 3 (RFC-1305) and Version 2 (RFC-1119) servers
   already accept all previous versions, including Version 1 (RFC-1059).
   Note that Version 0 (RFC-959) is no longer supported by any other
   version.

   Since there will probably continue to be NTP and SNTP servers of all
   four versions interoperating in the Internet, careful consideration
   should be given to the version used by SNTP Version 4 clients. It is
   recommended that clients use the latest version known to be supported
   by the selected server in the interest of the highest accuracy and
   reliability. SNTP Version 4 clients can interoperate with all
   previous version NTP and SNTP servers, since the header fields used
   by SNTP clients are unchanged. Version 4 servers are required to
   reply in the same version as the request, so the VN field of the
   request also specifies the version of the reply.

   While not necessary in a conforming client implementation, in unicast
   and anycast modes it highly recommended that the transmit timestamp
   in the request is set to the time of day according to the client
   clock in NTP timestamp format. This allows a simple calculation to
   determine the propagation delay between the server and client and to
   align the local clock generally within a few tens of milliseconds
   relative to the server. In addition, this provides a simple method to
   verify that the server reply is in fact a legitimate response to the
   specific client request and avoid replays. In multicast mode, the
   client has no information to calculate the propagation delay or
   determine the validity of the server, unless the NTP authentication
   scheme is used.

   To calculate the roundtrip delay d and local clock offset t relative
   to the server, the client sets the transmit timestamp in the request
   to the time of day according to the client clock in NTP timestamp



Mills                        Informational                     [Page 12]

RFC 2030             SNTPv4 for IPv4, IPv6 and OSI          October 1996


   format. The server copies this field to the originate timestamp in
   the reply and sets the receive timestamp and transmit timestamp to
   the time of day according to the server clock in NTP timestamp
   format.

   When the server reply is received, the client determines a
   Destination Timestamp variable as the time of arrival according to
   its clock in NTP timestamp format. The following table summarizes the
   four timestamps.

      Timestamp Name          ID   When Generated
      ------------------------------------------------------------
      Originate Timestamp     T1   time request sent by client
      Receive Timestamp       T2   time request received by server
      Transmit Timestamp      T3   time reply sent by server
      Destination Timestamp   T4   time reply received by client

   The roundtrip delay d and local clock offset t are defined as

      d = (T4 - T1) - (T2 - T3)     t = ((T2 - T1) + (T3 - T4)) / 2.

   The following table summarizes the SNTP client operations in unicast,
   anycast and multicast modes. The recommended error checks are shown
   in the Reply and Multicast columns in the table. The message should
   be considered valid only if all the fields shown contain values in
   the respective ranges. Whether to believe the message if one or more
   of the fields marked "ignore" contain invalid values is at the
   discretion of the implementation.

      Field Name              Unicast/Anycast          Multicast
                              Request    Reply
      ----------------------------------------------------------
      LI                      0          0-2           0-2
      VN                      1-4        copied from   1-4
                                         request
      Mode                    3          4             5
      Stratum                 0          1-14          1-14
      Poll                    0          ignore        ignore
      Precision               0          ignore        ignore
      Root Delay              0          ignore        ignore
      Root Dispersion         0          ignore        ignore
      Reference Identifier    0          ignore        ignore
      Reference Timestamp     0          ignore        ignore
      Originate Timestamp     0          (see text)    ignore
      Receive Timestamp       0          (see text)    ignore
      Transmit Timestamp      (see text) nonzero       nonzero
      Authenticator           optional   optional      optional




Mills                        Informational                     [Page 13]

RFC 2030             SNTPv4 for IPv4, IPv6 and OSI          October 1996


6. SNTP Server Operations

   A SNTP Version 4 server operating with either a NTP or SNTP client of
   the same or previous versions retains no persistent state. Since a
   SNTP server ordinarily does not implement the full set of NTP
   algorithms intended to support redundant peers and diverse network
   paths, a SNTP server should be operated only in conjunction with a
   source of external synchronization, such as a reliable radio clock or
   telephone modem. In this case it always operates as a primary
   (stratum 1) server.

   A SNTP server can operate in unicast mode, anycast mode, multicast
   mode or any combination of these modes. In unicast and anycast modes,
   the server receives a request (mode 3), modifies certain fields in
   the NTP header, and sends a reply (mode 4), possibly using the same
   message buffer as the request. In anycast mode, the server listens on
   the designated local broadcast or multicast group address assigned by
   the IANA, but uses its own unicast address in the source address
   field of the reply. Other than the selection of address in the reply,
   the operations of anycast and unicast servers are identical.
   Multicast messages are normally sent at poll intervals from 64 s to
   1024 s, depending on the expected frequency tolerance of the client
   clocks and the required accuracy.

   In unicast and anycast modes, the VN and Poll fields of the request
   are copied intact to the reply. If the Mode field of the request is 3
   (client), it is set to 4 (server) in the reply; otherwise, this field
   is set to 2 (symmetric passive) in order to conform to the NTP
   specification. This allows clients configured in symmetric active
   (mode 1) to interoperate successfully, even if configured in possibly
   suboptimal ways. In multicast (unsolicited) mode, the VN field is set
   to 4, the Mode field is set to 5 (broadcast), and the Poll field set
   to the nearest integer base-2 logarithm of the poll interval.

      Note that it is highly desirable that, if a server supports
      multicast mode, it also supports unicast mode. This is so a
      potential multicast client can calculate the propagation delay
      using a client/server exchange prior to regular operation using
      only multicast mode. If the server supports anycast mode, then it
      must support unicast mode. There does not seem to be a great
      advantage to operate both multicast and anycast modes at the same
      time, although the protocol specification does not forbid it.

   In unicast and anycast modes, the server may or may not respond if
   not synchronized to a correctly operating radio clock, but the
   preferred option is to respond, since this allows reachability to be
   determined regardless of synchronization state. In multicast mode,
   the server sends broadcasts only if synchronized to a correctly



Mills                        Informational                     [Page 14]

RFC 2030             SNTPv4 for IPv4, IPv6 and OSI          October 1996


   operating reference clock.

   The remaining fields of the NTP header are set in the following way.
   Assuming the server is synchronized to a radio clock or other primary
   reference source and operating correctly, the LI field is set to 0
   and the Stratum field is set to 1 (primary server); if not, the
   Stratum field is set to 0 and the LI field is set to 3. The Precision
   field is set to reflect the maximum reading error of the local clock.
   For all practical cases it is computed as the negative of the number
   of significant bits to the right of the decimal point in the NTP
   timestamp format. The Root Delay and Root Dispersion fields are set
   to 0 for a primary server; optionally, the Root Dispersion field can
   be set to a value corresponding to the maximum expected error of the
   radio clock itself. The Reference Identifier is set to designate the
   primary reference source, as indicated in the table of Section 5 of
   this document.

   The timestamp fields are set as follows. If the server is
   unsynchronized or first coming up, all timestamp fields are set to
   zero. If synchronized, the Reference Timestamp is set to the time the
   last update was received from the radio clock or modem. In unicast
   and anycast modes, the Receive Timestamp and Transmit Timestamp
   fields are set to the time of day when the message is sent and the
   Originate Timestamp field is copied unchanged from the Transmit
   Timestamp field of the request. It is important that this field be
   copied intact, as a NTP client uses it to avoid replays. In multicast
   mode, the Originate Timestamp and Receive Timestamp fields are set to
   0 and the Transmit Timestamp field is set to the time of day when the
   message is sent. The following table summarizes these actions.

      Field Name              Unicast/Anycast          Multicast
                              Request    Reply
      ----------------------------------------------------------
      LI                      ignore     0 or 3        0 or 3
      VN                      1-4        copied from   4
                                         request
      Mode                    3          2 or 4        5
      Stratum                 ignore     1             1
      Poll                    ignore     copied from   log2 poll
                                         request       interval
      Precision               ignore     -log2 server  -log2 server
                                         significant   significant
                                         bits          bits
      Root Delay              ignore     0             0
      Root Dispersion         ignore     0             0
      Reference Identifier    ignore     source ident  source ident
      Reference Timestamp     ignore     time of last  time of last
                                         radio update  radio update



Mills                        Informational                     [Page 15]

RFC 2030             SNTPv4 for IPv4, IPv6 and OSI          October 1996


      Originate Timestamp     ignore     copied from   0
                                         transmit
                                         timestamp
      Receive Timestamp       ignore     time of day   0
      Transmit Timestamp      (see text) time of day   time of day
      Authenticator           optional   optional      optional

   There is some latitude on the part of most clients to forgive invalid
   timestamps, such as might occur when first coming up or during
   periods when the primary reference source is inoperative. The most
   important indicator of an unhealthy server is the LI field, in which
   a value of 3 indicates an unsynchronized condition. When this value
   is displayed, clients should discard the server message, regardless
   of the contents of other fields.

7. Configuration and Management

   Initial setup for SNTP servers and clients can be done using a
   configuration file if a file system is available, or a serial port if
   not. It is intended that in-service management of NTP and SNTP
   Version 4 servers and clients be performed using SNMP and a suitable
   MIB to be published later. Ordinarily, SNTP servers and clients are
   expected to operate with little or no site-specific configuration,
   other than specifying the IP address and subnet mask or OSI NSAP
   address.

   Unicast clients must be provided with the designated server name or
   address. If a server name is used, the address of one of more DNS
   servers must be provided. Multicast servers and anycast clients  must
   be provided with the TTL and local broadcast or multicast group
   address. Anycast servers and multicast clients may be configured with
   a list of address-mask pairs for access control, so that only those
   clients or servers known to be trusted will be used. These servers
   and clients must implement the IGMP protocol and be provided with the
   local broadcast or multicast group address as well. The configuration
   data for cryptographic authentication is beyond the scope of this
   document.

   There are several scenarios which provide automatic server discovery
   and selection for SNTP clients with no pre-specified configuration,
   other than the IP address and subnet mask or OSI NSAP address. For a
   IP subnet or LAN segment including a fully functional NTP server, the
   clients can be configured for multicast mode using the local
   broadcast address. The same approach can be used with other servers
   using the multicast group address. In both cases, provision of an
   access control list is a good way to insure only trusted sources can
   be used to set the local clock.




Mills                        Informational                     [Page 16]

RFC 2030             SNTPv4 for IPv4, IPv6 and OSI          October 1996


   In another scenario suitable for an extended network with significant
   network propagation delays, clients can be configured for anycast
   mode, both upon initial startup and after some period when the
   currently selected unicast source has not been heard. Following the
   defined protocol, the client binds to the first reply heard and
   continues operation in unicast mode. In this mode the local clock can
   be automatically adjusted to compensate for the propagation delay.

   In still another scenario suitable for any network and where
   multicast service is not available, the DNS can be set up with a
   common CNAME, like time.domain.net, and a list of address records for
   NTP servers in the same domain. Upon resolving time.domain.net and
   obtaining the list, the client selects a server at random and begins
   operation in unicast mode with that server. Many variations on this
   theme are possible.

8. Acknowledgements

   Jeff Learman was helpful in developing the OSI model for this
   protocol. Ajit Thyagarajan provided valuable suggestions and
   corrections.

9. References

   [COL94] Colella, R., R. Callon, E. Gardner, Y. Rekhter, "Guidelines
   for OSI NSAP allocation in the Internet", RFC 1629, NIST, May 1994.

   [DAR81] Postel, J., "Internet Protocol", STD 5, RFC 791,
   USC Information Sciences Institute, September 1981.

   [DEE89] Deering, S., "Host extensions for IP multicasting", STD 5,
   RFC 1112, Stanford University, August 1989.

   [DEE96] Deering, S., R. Hinden, "Internet Protocol, Version 6 (IPv6)
   Specification", RFC 1883, Xerox and Ipsilon, January 1996.

   [DOB91] Dobbins, K, W. Haggerty, C. Shue, "OSI connectionless
   transport services on top of UDP - Version: 1", RFC 1240, Open
   Software Foundation, June 1991.

   [EAS95] Eastlake, D., 3rd., and C. Kaufman, "Domain Name System
   Security Extensions", Work in Progress.

   [FUR94] Furniss, P., "Octet sequences for upper-layer OSI to support
   basic communications applications", RFC 1698, Consultant,
   October 1994.





Mills                        Informational                     [Page 17]

RFC 2030             SNTPv4 for IPv4, IPv6 and OSI          October 1996


   [HIN96] Hinden, R., and S. Deering, "IP Version 6 addressing
   Architecture", RFC 1884, Ipsilon and Xerox, January 1996.

   [ISO86] International Standards 8602 - Information Processing Systems
   - OSI: Connectionless Transport Protocol Specification. International
   Standards Organization, December 1986.

   [MIL92] Mills, D., "Network Time Protocol (Version 3) specification,
   implementation and analysis", RFC 1305, University of Delaware,
   March 1992.

   [PAR93] Partridge, C., T. Mendez and W. Milliken, "Host anycasting
   service", RFC 1546, Bolt Beranek Newman, November 1993.

   [POS80] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
   USC Information Sciences Institute, August 1980.

   [POS83] Postel, J., "Time Protocol", STD 26, RFC 868,
   USC Information Sciences Institute, May 1983.

Security Considerations

   Security issues are not discussed in this memo.

Author's Address

   David L. Mills
   Electrical Engineering Department
   University of Delaware
   Newark, DE 19716

   Phone: (302) 831-8247



















Mills                        Informational                     [Page 18]