7
Network Working Group D. Mills
8
Request for Comments: 2030 University of Delaware
9
Obsoletes: 1769 October 1996
10
Category: Informational
13
Simple Network Time Protocol (SNTP) Version 4
14
for IPv4, IPv6 and OSI
18
This memo provides information for the Internet community. This memo
19
does not specify an Internet standard of any kind. Distribution of
20
this memo is unlimited.
24
This memorandum describes the Simple Network Time Protocol (SNTP)
25
Version 4, which is an adaptation of the Network Time Protocol (NTP)
26
used to synchronize computer clocks in the Internet. SNTP can be used
27
when the ultimate performance of the full NTP implementation
28
described in RFC-1305 is not needed or justified. When operating with
29
current and previous NTP and SNTP versions, SNTP Version 4 involves
30
no changes to the NTP specification or known implementations, but
31
rather a clarification of certain design features of NTP which allow
32
operation in a simple, stateless remote-procedure call (RPC) mode
33
with accuracy and reliability expectations similar to the UDP/TIME
34
protocol described in RFC-868.
36
The only significant protocol change in SNTP Version 4 over previous
37
versions of NTP and SNTP is a modified header interpretation to
38
accommodate Internet Protocol Version 6 (IPv6) [DEE96] and OSI
39
[COL94] addressing. However, SNTP Version 4 includes certain optional
40
extensions to the basic Version 3 model, including an anycast mode
41
and an authentication scheme designed specifically for multicast and
42
anycast modes. While the anycast mode extension is described in this
43
document, the authentication scheme extension will be described in
44
another document to be published later. Until such time that a
45
definitive specification is published, these extensions should be
46
considered provisional.
48
This memorandum obsoletes RFC-1769, which describes SNTP Version 3.
49
Its purpose is to correct certain inconsistencies in the previous
50
document and to clarify header formats and protocol operations for
51
current NTP Version 3 (IPv4) and proposed NTP Version 4 (IPv6 and
52
OSI), which are also used for SNTP. A working knowledge of the NTP
53
Version 3 specification RFC-1305 is not required for an
54
implementation of SNTP.
58
Mills Informational [Page 1]
60
RFC 2030 SNTPv4 for IPv4, IPv6 and OSI October 1996
65
The Network Time Protocol (NTP) Version 3 specified in RFC-1305
66
[MIL92] is widely used to synchronize computer clocks in the global
67
Internet. It provides comprehensive mechanisms to access national
68
time and frequency dissemination services, organize the time-
69
synchronization subnet and adjust the local clock in each
70
participating subnet peer. In most places of the Internet of today,
71
NTP provides accuracies of 1-50 ms, depending on the characteristics
72
of the synchronization source and network paths.
74
RFC-1305 specifies the NTP Version 3 protocol machine in terms of
75
events, states, transition functions and actions and, in addition,
76
engineered algorithms to improve the timekeeping quality and mitigate
77
among several synchronization sources, some of which may be faulty.
78
To achieve accuracies in the low milliseconds over paths spanning
79
major portions of the Internet of today, these intricate algorithms,
80
or their functional equivalents, are necessary. However, in many
81
cases accuracies in the order of significant fractions of a second
82
are acceptable. In such cases, simpler protocols such as the Time
83
Protocol [POS83], have been used for this purpose. These protocols
84
usually involve an RPC exchange where the client requests the time of
85
day and the server returns it in seconds past some known reference
88
NTP is designed for use by clients and servers with a wide range of
89
capabilities and over a wide range of network delays and jitter
90
characteristics. Most users of the Internet NTP synchronization
91
subnet of today use a software package including the full suite of
92
NTP options and algorithms, which are relatively complex, real-time
93
applications (see http://www.eecis.udel.edu/~ntp). While the software
94
has been ported to a wide variety of hardware platforms ranging from
95
personal computers to supercomputers, its sheer size and complexity
96
is not appropriate for many applications. Accordingly, it is useful
97
to explore alternative access strategies using simpler software
98
appropriate for less stringent accuracy expectations.
100
This document describes the Simple Network Time Protocol (SNTP)
101
Version 4, which is a simplified access strategy for servers and
102
clients using NTP Version 3 as now specified and deployed in the
103
Internet, as well as NTP Version 4 now under development. The access
104
paradigm is identical to the UDP/TIME Protocol and, in fact, it
105
should be easily possible to adapt a UDP/TIME client implementation,
106
say for a personal computer, to operate using SNTP. Moreover, SNTP is
107
also designed to operate in a dedicated server configuration
108
including an integrated radio clock. With careful design and control
109
of the various latencies in the system, which is practical in a
110
dedicated design, it is possible to deliver time accurate to the
114
Mills Informational [Page 2]
116
RFC 2030 SNTPv4 for IPv4, IPv6 and OSI October 1996
119
order of microseconds.
121
SNTP Version 4 is designed to coexist with existing NTP and SNTP
122
Version 3 clients and servers, as well as proposed Version 4 clients
123
and servers. When operating with current and previous versions of NTP
124
and SNTP, SNTP Version 4 requires no changes to the protocol or
125
implementations now running or likely to be implemented specifically
126
for NTP ir SNTP Version 4. To a NTP or SNTP server, NTP and SNTP
127
clients are undistinguishable; to a NTP or SNTP client, NTP and SNTP
128
servers are undistinguishable. Like NTP servers operating in non-
129
symmetric modes, SNTP servers are stateless and can support large
130
numbers of clients; however, unlike most NTP clients, SNTP clients
131
normally operate with only a single server. NTP and SNTP Version 3
132
servers can operate in unicast and multicast modes. In addition, SNTP
133
Version 4 clients and servers can implement extensions to operate in
136
It is strongly recommended that SNTP be used only at the extremities
137
of the synchronization subnet. SNTP clients should operate only at
138
the leaves (highest stratum) of the subnet and in configurations
139
where no NTP or SNTP client is dependent on another SNTP client for
140
synchronization. SNTP servers should operate only at the root
141
(stratum 1) of the subnet and then only in configurations where no
142
other source of synchronization other than a reliable radio or modem
143
time service is available. The full degree of reliability ordinarily
144
expected of primary servers is possible only using the redundant
145
sources, diverse subnet paths and crafted algorithms of a full NTP
146
implementation. This extends to the primary source of synchronization
147
itself in the form of multiple radio or modem sources and backup
148
paths to other primary servers should all sources fail or the
149
majority deliver incorrect time. Therefore, the use of SNTP rather
150
than NTP in primary servers should be carefully considered.
152
An important provision in this document is the reinterpretation of
153
certain NTP Versino 4 header fields which provide for IPv6 and OSI
154
addressing and optional anycast extensions designed specifically for
155
multicast service. These additions are in conjunction with the
156
proposed NTP Version 4 specification, which will appear as a separate
157
document. The only difference between the current NTP Version 3 and
158
proposed NTP Version 4 header formats is the interpretation of the
159
four-octet Reference Identifier field, which is used primarily to
160
detect and avoid synchronization loops. In Version 3 and Version 4
161
primary (stratum-1) servers, this field contains the four-character
162
ASCII reference identifier defined later in this document. In Version
163
3 secondary servers and clients, it contains the 32-bit IPv4 address
164
of the synchronization source. In Version 4 secondary servers and
165
clients, it contains the low order 32 bits of the last transmit
166
timestamp received from the synchronization source.
170
Mills Informational [Page 3]
172
RFC 2030 SNTPv4 for IPv4, IPv6 and OSI October 1996
175
In the case of OSI, the Connectionless Transport Service (CLTS) is
176
used [ISO86]. Each SNTP packet is transmitted as tht TS-Userdata
177
parameter of a T-UNITDATA Request primitive. Alternately, the header
178
can be encapsulated in a TPDU which itself is transported using UDP
179
[DOB91]. It is not advised that NTP be operated at the upper layers
180
of the OSI stack, such as might be inferred from [FUR94], as this
181
could seriously degrade accuracy. With the header formats defined in
182
this document, it is in principle possible to interwork between
183
servers and clients of one protocol family and another, although the
184
practical difficulties may make this inadvisable.
186
In the following, indented paragraphs such as this one contain
187
information not required by the formal protocol specification, but
188
considered good practice in protocol implementations.
190
2. Operating Modes and Addressing
192
SNTP Version 4 can operate in either unicast (point to point),
193
multicast (point to multipoint) or anycast (multipoint to point)
194
modes. A unicast client sends a request to a designated server at its
195
unicast address and expects a reply from which it can determine the
196
time and, optionally, the roundtrip delay and local clock offset
197
relative to the server. A multicast server periodically sends a
198
unsolicited message to a designated IPv4 or IPv6 local broadcast
199
address or multicast group address and ordinarily expects no requests
200
from clients. A multicast client listens on this address and
201
ordinarily sends no requests. An anycast client sends a request to a
202
designated IPv4 or IPv6 local broadcast address or multicast group
203
address. One or more anycast servers reply with their individual
204
unicast addresses. The client binds to the first one received, then
205
continues operation in unicast mode.
207
Multicast servers should respond to client unicast requests, as
208
well as send unsolicited multicast messages. Multicast clients may
209
send unicast requests in order to determine the network
210
propagation delay between the server and client and then continue
211
operation in multicast mode.
213
In unicast mode, the client and server end-system addresses are
214
assigned following the usual IPv4, IPv6 or OSI conventions. In
215
multicast mode, the server uses a designated local broadcast address
216
or multicast group address. An IP local broadcast address has scope
217
limited to a single IP subnet, since routers do not propagate IP
218
broadcast datagrams. On the other hand, an IP multicast group address
219
has scope extending to potentially the entire Internet. The scoping,
220
routing and group membership procedures are determined by
221
considerations beyond the scope of this document. For IPv4, the IANA
222
has assigned the multicast group address 224.0.1.1 for NTP, which is
226
Mills Informational [Page 4]
228
RFC 2030 SNTPv4 for IPv4, IPv6 and OSI October 1996
231
used both by multicast servers and anycast clients. NTP multicast
232
addresses for IPv6 and OSI have yet to be determined.
234
Multicast clients listen on the designated local broadcast address or
235
multicast group address. In the case of local broadcast addresses, no
236
further provisions are necessary. In the case of IP multicast
237
addresses, the multicast client and anycast server must implement the
238
Internet Group Management Protocol (IGMP) [DEE89], in order that the
239
local router joins the multicast group and relays messages to the
240
IPv4 or IPv6 multicast group addresses assigned by the IANA. Other
241
than the IP addressing conventions and IGMP, there is no difference
242
in server or client operations with either the local broadcast
243
address or multicast group address.
245
It is important to adjust the time-to-live (TTL) field in the IP
246
header of multicast messages to a reasonable value, in order to
247
limit the network resources used by this (and any other) multicast
248
service. Only multicast clients in scope will receive multicast
249
server messages. Only cooperating anycast servers in scope will
250
reply to a client request. The engineering principles which
251
determine the proper value to be used are beyond the scope of this
254
Anycast mode is designed for use with a set of cooperating servers
255
whose addresses are not known beforehand by the client. An anycast
256
client sends a request to the designated local broadcast or multicast
257
group address as described below. For this purpose, the NTP multicast
258
group address assigned by the IANA is used. One or more anycast
259
servers listen on the designated local broadcast address or multicast
260
group address. Each anycast server, upon receiving a request, sends a
261
unicast reply message to the originating client. The client then
262
binds to the first such message received and continues operation in
263
unicast mode. Subsequent replies from other anycast servers are
266
In the case of SNTP as specified herein, there is a very real
267
vulnerability that SNTP multicast clients can be disrupted by
268
misbehaving or hostile SNTP or NTP multicast servers elsewhere in
269
the Internet, since at present all such servers use the same IPv4
270
multicast group address assigned by the IANA. Where necessary,
271
access control based on the server source address can be used to
272
select only the designated server known to and trusted by the
273
client. The use of cryptographic authentication scheme defined in
274
RFC-1305 is optional; however, implementors should be advised that
275
extensions to this scheme are planned specifically for NTP
276
multicast and anycast modes.
282
Mills Informational [Page 5]
284
RFC 2030 SNTPv4 for IPv4, IPv6 and OSI October 1996
287
While not integral to the SNTP specification, it is intended that
288
IP broadcast addresses will be used primarily in IP subnets and
289
LAN segments including a fully functional NTP server with a number
290
of dependent SNTP multicast clients on the same subnet, while IP
291
multicast group addresses will be used only in cases where the TTL
292
is engineered specifically for each service domain.
294
In NTP Version 3, the reference identifier was often used to
295
walk-back the synchronization subnet to the root (primary server)
296
for management purposes. In NTP Version 4, this feature is not
297
available, since the addresses are longer than 32 bits. However,
298
the intent in the protocol design was to provide a way to detect
299
and avoid loops. A peer could determine that a loop was possible
300
by comparing the contents of this field with the IPv4 destination
301
address in the same packet. A NTP Version 4 server can accomplish
302
the same thing by comparing the contents of this field with the
303
low order 32 bits of the originate timestamp in the same packet.
304
There is a small possibility of false alarm in this scheme, but
305
the false alarm rate can be minimized by randomizing the low order
306
unused bits of the transmit timestamp.
308
3. NTP Timestamp Format
310
SNTP uses the standard NTP timestamp format described in RFC-1305 and
311
previous versions of that document. In conformance with standard
312
Internet practice, NTP data are specified as integer or fixed-point
313
quantities, with bits numbered in big-endian fashion from 0 starting
314
at the left, or high-order, position. Unless specified otherwise, all
315
quantities are unsigned and may occupy the full field width with an
316
implied 0 preceding bit 0.
318
Since NTP timestamps are cherished data and, in fact, represent the
319
main product of the protocol, a special timestamp format has been
320
established. NTP timestamps are represented as a 64-bit unsigned
321
fixed-point number, in seconds relative to 0h on 1 January 1900. The
322
integer part is in the first 32 bits and the fraction part in the
323
last 32 bits. In the fraction part, the non-significant low order can
326
It is advisable to fill the non-significant low order bits of the
327
timestamp with a random, unbiased bitstring, both to avoid
328
systematic roundoff errors and as a means of loop detection and
329
replay detection (see below). One way of doing this is to generate
330
a random bitstring in a 64-bit word, then perform an arithmetic
331
right shift a number of bits equal to the number of significant
332
bits of the timestamp, then add the result to the original
338
Mills Informational [Page 6]
340
RFC 2030 SNTPv4 for IPv4, IPv6 and OSI October 1996
343
This format allows convenient multiple-precision arithmetic and
344
conversion to UDP/TIME representation (seconds), but does complicate
345
the conversion to ICMP Timestamp message representation, which is in
346
milliseconds. The maximum number that can be represented is
347
4,294,967,295 seconds with a precision of about 200 picoseconds,
348
which should be adequate for even the most exotic requirements.
351
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
352
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
354
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
355
| Seconds Fraction (0-padded) |
356
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
358
Note that, since some time in 1968 (second 2,147,483,648) the most
359
significant bit (bit 0 of the integer part) has been set and that the
360
64-bit field will overflow some time in 2036 (second 4,294,967,296).
361
Should NTP or SNTP be in use in 2036, some external means will be
362
necessary to qualify time relative to 1900 and time relative to 2036
363
(and other multiples of 136 years). There will exist a 200-picosecond
364
interval, henceforth ignored, every 136 years when the 64-bit field
365
will be 0, which by convention is interpreted as an invalid or
366
unavailable timestamp.
368
As the NTP timestamp format has been in use for the last 17 years,
369
it remains a possibility that it will be in use 40 years from now
370
when the seconds field overflows. As it is probably inappropriate
371
to archive NTP timestamps before bit 0 was set in 1968, a
372
convenient way to extend the useful life of NTP timestamps is the
373
following convention: If bit 0 is set, the UTC time is in the
374
range 1968-2036 and UTC time is reckoned from 0h 0m 0s UTC on 1
375
January 1900. If bit 0 is not set, the time is in the range 2036-
376
2104 and UTC time is reckoned from 6h 28m 16s UTC on 7 February
377
2036. Note that when calculating the correspondence, 2000 is not a
378
leap year. Note also that leap seconds are not counted in the
381
4. NTP Message Format
383
Both NTP and SNTP are clients of the User Datagram Protocol (UDP)
384
[POS80], which itself is a client of the Internet Protocol (IP)
385
[DAR81]. The structure of the IP and UDP headers is described in the
386
cited specification documents and will not be detailed further here.
387
The UDP port number assigned to NTP is 123, which should be used in
388
both the Source Port and Destination Port fields in the UDP header.
389
The remaining UDP header fields should be set as described in the
394
Mills Informational [Page 7]
396
RFC 2030 SNTPv4 for IPv4, IPv6 and OSI October 1996
399
Below is a description of the NTP/SNTP Version 4 message format,
400
which follows the IP and UDP headers. This format is identical to
401
that described in RFC-1305, with the exception of the contents of the
402
reference identifier field. The header fields are defined as follows:
405
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
406
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
407
|LI | VN |Mode | Stratum | Poll | Precision |
408
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
410
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
412
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
413
| Reference Identifier |
414
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
416
| Reference Timestamp (64) |
418
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
420
| Originate Timestamp (64) |
422
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
424
| Receive Timestamp (64) |
426
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
428
| Transmit Timestamp (64) |
430
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
431
| Key Identifier (optional) (32) |
432
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
435
| Message Digest (optional) (128) |
438
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
440
As described in the next section, in SNTP most of these fields are
441
initialized with pre-specified data. For completeness, the function
442
of each field is briefly summarized below.
450
Mills Informational [Page 8]
452
RFC 2030 SNTPv4 for IPv4, IPv6 and OSI October 1996
455
Leap Indicator (LI): This is a two-bit code warning of an impending
456
leap second to be inserted/deleted in the last minute of the current
457
day, with bit 0 and bit 1, respectively, coded as follows:
460
-------------------------------------------------------
462
01 1 last minute has 61 seconds
463
10 2 last minute has 59 seconds)
464
11 3 alarm condition (clock not synchronized)
466
Version Number (VN): This is a three-bit integer indicating the
467
NTP/SNTP version number. The version number is 3 for Version 3 (IPv4
468
only) and 4 for Version 4 (IPv4, IPv6 and OSI). If necessary to
469
distinguish between IPv4, IPv6 and OSI, the encapsulating context
472
Mode: This is a three-bit integer indicating the mode, with values
476
------------------------------------
483
6 reserved for NTP control message
484
7 reserved for private use
486
In unicast and anycast modes, the client sets this field to 3
487
(client) in the request and the server sets it to 4 (server) in the
488
reply. In multicast mode, the server sets this field to 5
491
Stratum: This is a eight-bit unsigned integer indicating the stratum
492
level of the local clock, with values defined as follows:
495
----------------------------------------------
496
0 unspecified or unavailable
497
1 primary reference (e.g., radio clock)
498
2-15 secondary reference (via NTP or SNTP)
506
Mills Informational [Page 9]
508
RFC 2030 SNTPv4 for IPv4, IPv6 and OSI October 1996
511
Poll Interval: This is an eight-bit signed integer indicating the
512
maximum interval between successive messages, in seconds to the
513
nearest power of two. The values that can appear in this field
514
presently range from 4 (16 s) to 14 (16284 s); however, most
515
applications use only the sub-range 6 (64 s) to 10 (1024 s).
517
Precision: This is an eight-bit signed integer indicating the
518
precision of the local clock, in seconds to the nearest power of two.
519
The values that normally appear in this field range from -6 for
520
mains-frequency clocks to -20 for microsecond clocks found in some
523
Root Delay: This is a 32-bit signed fixed-point number indicating the
524
total roundtrip delay to the primary reference source, in seconds
525
with fraction point between bits 15 and 16. Note that this variable
526
can take on both positive and negative values, depending on the
527
relative time and frequency offsets. The values that normally appear
528
in this field range from negative values of a few milliseconds to
529
positive values of several hundred milliseconds.
531
Root Dispersion: This is a 32-bit unsigned fixed-point number
532
indicating the nominal error relative to the primary reference
533
source, in seconds with fraction point between bits 15 and 16. The
534
values that normally appear in this field range from 0 to several
535
hundred milliseconds.
537
Reference Identifier: This is a 32-bit bitstring identifying the
538
particular reference source. In the case of NTP Version 3 or Version
539
4 stratum-0 (unspecified) or stratum-1 (primary) servers, this is a
540
four-character ASCII string, left justified and zero padded to 32
541
bits. In NTP Version 3 secondary servers, this is the 32-bit IPv4
542
address of the reference source. In NTP Version 4 secondary servers,
543
this is the low order 32 bits of the latest transmit timestamp of the
544
reference source. NTP primary (stratum 1) servers should set this
545
field to a code identifying the external reference source according
546
to the following list. If the external reference is one of those
547
listed, the associated code should be used. Codes for sources not
548
listed can be contrived as appropriate.
562
Mills Informational [Page 10]
564
RFC 2030 SNTPv4 for IPv4, IPv6 and OSI October 1996
567
Code External Reference Source
568
----------------------------------------------------------------
569
LOCL uncalibrated local clock used as a primary reference for
570
a subnet without external means of synchronization
571
PPS atomic clock or other pulse-per-second source
572
individually calibrated to national standards
573
ACTS NIST dialup modem service
574
USNO USNO modem service
575
PTB PTB (Germany) modem service
576
TDF Allouis (France) Radio 164 kHz
577
DCF Mainflingen (Germany) Radio 77.5 kHz
578
MSF Rugby (UK) Radio 60 kHz
579
WWV Ft. Collins (US) Radio 2.5, 5, 10, 15, 20 MHz
580
WWVB Boulder (US) Radio 60 kHz
581
WWVH Kaui Hawaii (US) Radio 2.5, 5, 10, 15 MHz
582
CHU Ottawa (Canada) Radio 3330, 7335, 14670 kHz
583
LORC LORAN-C radionavigation system
584
OMEG OMEGA radionavigation system
585
GPS Global Positioning Service
586
GOES Geostationary Orbit Environment Satellite
588
Reference Timestamp: This is the time at which the local clock was
589
last set or corrected, in 64-bit timestamp format.
591
Originate Timestamp: This is the time at which the request departed
592
the client for the server, in 64-bit timestamp format.
594
Receive Timestamp: This is the time at which the request arrived at
595
the server, in 64-bit timestamp format.
597
Transmit Timestamp: This is the time at which the reply departed the
598
server for the client, in 64-bit timestamp format.
600
Authenticator (optional): When the NTP authentication scheme is
601
implemented, the Key Identifier and Message Digest fields contain the
602
message authentication code (MAC) information defined in Appendix C
605
5. SNTP Client Operations
607
A SNTP client can operate in multicast mode, unicast mode or anycast
608
mode. In multicast mode, the client sends no request and waits for a
609
broadcast (mode 5) from a designated multicast server. In unicast
610
mode, the client sends a request (mode 3) to a designated unicast
611
server and expects a reply (mode 4) from that server. In anycast
612
mode, the client sends a request (mode 3) to a designated local
613
broadcast or multicast group address and expects a reply (mode 4)
614
from one or more anycast servers. The client uses the first reply
618
Mills Informational [Page 11]
620
RFC 2030 SNTPv4 for IPv4, IPv6 and OSI October 1996
623
received to establish the particular server for subsequent unicast
624
operations. Later replies from this server (duplicates) or any other
625
server are ignored. Other than the selection of address in the
626
request, the operations of anycast and unicast clients are identical.
627
Requests are normally sent at intervals from 64 s to 1024 s,
628
depending on the frequency tolerance of the client clock and the
631
A unicast or anycast client initializes the NTP message header, sends
632
the request to the server and strips the time of day from the
633
Transmit Timestamp field of the reply. For this purpose, all of the
634
NTP header fields shown above can be set to 0, except the first octet
635
and (optional) Transmit Timestamp fields. In the first octet, the LI
636
field is set to 0 (no warning) and the Mode field is set to 3
637
(client). The VN field must agree with the version number of the
638
NTP/SNTP server; however, Version 4 servers will also accept previous
639
versions. Version 3 (RFC-1305) and Version 2 (RFC-1119) servers
640
already accept all previous versions, including Version 1 (RFC-1059).
641
Note that Version 0 (RFC-959) is no longer supported by any other
644
Since there will probably continue to be NTP and SNTP servers of all
645
four versions interoperating in the Internet, careful consideration
646
should be given to the version used by SNTP Version 4 clients. It is
647
recommended that clients use the latest version known to be supported
648
by the selected server in the interest of the highest accuracy and
649
reliability. SNTP Version 4 clients can interoperate with all
650
previous version NTP and SNTP servers, since the header fields used
651
by SNTP clients are unchanged. Version 4 servers are required to
652
reply in the same version as the request, so the VN field of the
653
request also specifies the version of the reply.
655
While not necessary in a conforming client implementation, in unicast
656
and anycast modes it highly recommended that the transmit timestamp
657
in the request is set to the time of day according to the client
658
clock in NTP timestamp format. This allows a simple calculation to
659
determine the propagation delay between the server and client and to
660
align the local clock generally within a few tens of milliseconds
661
relative to the server. In addition, this provides a simple method to
662
verify that the server reply is in fact a legitimate response to the
663
specific client request and avoid replays. In multicast mode, the
664
client has no information to calculate the propagation delay or
665
determine the validity of the server, unless the NTP authentication
668
To calculate the roundtrip delay d and local clock offset t relative
669
to the server, the client sets the transmit timestamp in the request
670
to the time of day according to the client clock in NTP timestamp
674
Mills Informational [Page 12]
676
RFC 2030 SNTPv4 for IPv4, IPv6 and OSI October 1996
679
format. The server copies this field to the originate timestamp in
680
the reply and sets the receive timestamp and transmit timestamp to
681
the time of day according to the server clock in NTP timestamp
684
When the server reply is received, the client determines a
685
Destination Timestamp variable as the time of arrival according to
686
its clock in NTP timestamp format. The following table summarizes the
689
Timestamp Name ID When Generated
690
------------------------------------------------------------
691
Originate Timestamp T1 time request sent by client
692
Receive Timestamp T2 time request received by server
693
Transmit Timestamp T3 time reply sent by server
694
Destination Timestamp T4 time reply received by client
696
The roundtrip delay d and local clock offset t are defined as
698
d = (T4 - T1) - (T2 - T3) t = ((T2 - T1) + (T3 - T4)) / 2.
700
The following table summarizes the SNTP client operations in unicast,
701
anycast and multicast modes. The recommended error checks are shown
702
in the Reply and Multicast columns in the table. The message should
703
be considered valid only if all the fields shown contain values in
704
the respective ranges. Whether to believe the message if one or more
705
of the fields marked "ignore" contain invalid values is at the
706
discretion of the implementation.
708
Field Name Unicast/Anycast Multicast
710
----------------------------------------------------------
712
VN 1-4 copied from 1-4
717
Precision 0 ignore ignore
718
Root Delay 0 ignore ignore
719
Root Dispersion 0 ignore ignore
720
Reference Identifier 0 ignore ignore
721
Reference Timestamp 0 ignore ignore
722
Originate Timestamp 0 (see text) ignore
723
Receive Timestamp 0 (see text) ignore
724
Transmit Timestamp (see text) nonzero nonzero
725
Authenticator optional optional optional
730
Mills Informational [Page 13]
732
RFC 2030 SNTPv4 for IPv4, IPv6 and OSI October 1996
735
6. SNTP Server Operations
737
A SNTP Version 4 server operating with either a NTP or SNTP client of
738
the same or previous versions retains no persistent state. Since a
739
SNTP server ordinarily does not implement the full set of NTP
740
algorithms intended to support redundant peers and diverse network
741
paths, a SNTP server should be operated only in conjunction with a
742
source of external synchronization, such as a reliable radio clock or
743
telephone modem. In this case it always operates as a primary
746
A SNTP server can operate in unicast mode, anycast mode, multicast
747
mode or any combination of these modes. In unicast and anycast modes,
748
the server receives a request (mode 3), modifies certain fields in
749
the NTP header, and sends a reply (mode 4), possibly using the same
750
message buffer as the request. In anycast mode, the server listens on
751
the designated local broadcast or multicast group address assigned by
752
the IANA, but uses its own unicast address in the source address
753
field of the reply. Other than the selection of address in the reply,
754
the operations of anycast and unicast servers are identical.
755
Multicast messages are normally sent at poll intervals from 64 s to
756
1024 s, depending on the expected frequency tolerance of the client
757
clocks and the required accuracy.
759
In unicast and anycast modes, the VN and Poll fields of the request
760
are copied intact to the reply. If the Mode field of the request is 3
761
(client), it is set to 4 (server) in the reply; otherwise, this field
762
is set to 2 (symmetric passive) in order to conform to the NTP
763
specification. This allows clients configured in symmetric active
764
(mode 1) to interoperate successfully, even if configured in possibly
765
suboptimal ways. In multicast (unsolicited) mode, the VN field is set
766
to 4, the Mode field is set to 5 (broadcast), and the Poll field set
767
to the nearest integer base-2 logarithm of the poll interval.
769
Note that it is highly desirable that, if a server supports
770
multicast mode, it also supports unicast mode. This is so a
771
potential multicast client can calculate the propagation delay
772
using a client/server exchange prior to regular operation using
773
only multicast mode. If the server supports anycast mode, then it
774
must support unicast mode. There does not seem to be a great
775
advantage to operate both multicast and anycast modes at the same
776
time, although the protocol specification does not forbid it.
778
In unicast and anycast modes, the server may or may not respond if
779
not synchronized to a correctly operating radio clock, but the
780
preferred option is to respond, since this allows reachability to be
781
determined regardless of synchronization state. In multicast mode,
782
the server sends broadcasts only if synchronized to a correctly
786
Mills Informational [Page 14]
788
RFC 2030 SNTPv4 for IPv4, IPv6 and OSI October 1996
791
operating reference clock.
793
The remaining fields of the NTP header are set in the following way.
794
Assuming the server is synchronized to a radio clock or other primary
795
reference source and operating correctly, the LI field is set to 0
796
and the Stratum field is set to 1 (primary server); if not, the
797
Stratum field is set to 0 and the LI field is set to 3. The Precision
798
field is set to reflect the maximum reading error of the local clock.
799
For all practical cases it is computed as the negative of the number
800
of significant bits to the right of the decimal point in the NTP
801
timestamp format. The Root Delay and Root Dispersion fields are set
802
to 0 for a primary server; optionally, the Root Dispersion field can
803
be set to a value corresponding to the maximum expected error of the
804
radio clock itself. The Reference Identifier is set to designate the
805
primary reference source, as indicated in the table of Section 5 of
808
The timestamp fields are set as follows. If the server is
809
unsynchronized or first coming up, all timestamp fields are set to
810
zero. If synchronized, the Reference Timestamp is set to the time the
811
last update was received from the radio clock or modem. In unicast
812
and anycast modes, the Receive Timestamp and Transmit Timestamp
813
fields are set to the time of day when the message is sent and the
814
Originate Timestamp field is copied unchanged from the Transmit
815
Timestamp field of the request. It is important that this field be
816
copied intact, as a NTP client uses it to avoid replays. In multicast
817
mode, the Originate Timestamp and Receive Timestamp fields are set to
818
0 and the Transmit Timestamp field is set to the time of day when the
819
message is sent. The following table summarizes these actions.
821
Field Name Unicast/Anycast Multicast
823
----------------------------------------------------------
824
LI ignore 0 or 3 0 or 3
829
Poll ignore copied from log2 poll
831
Precision ignore -log2 server -log2 server
832
significant significant
834
Root Delay ignore 0 0
835
Root Dispersion ignore 0 0
836
Reference Identifier ignore source ident source ident
837
Reference Timestamp ignore time of last time of last
838
radio update radio update
842
Mills Informational [Page 15]
844
RFC 2030 SNTPv4 for IPv4, IPv6 and OSI October 1996
847
Originate Timestamp ignore copied from 0
850
Receive Timestamp ignore time of day 0
851
Transmit Timestamp (see text) time of day time of day
852
Authenticator optional optional optional
854
There is some latitude on the part of most clients to forgive invalid
855
timestamps, such as might occur when first coming up or during
856
periods when the primary reference source is inoperative. The most
857
important indicator of an unhealthy server is the LI field, in which
858
a value of 3 indicates an unsynchronized condition. When this value
859
is displayed, clients should discard the server message, regardless
860
of the contents of other fields.
862
7. Configuration and Management
864
Initial setup for SNTP servers and clients can be done using a
865
configuration file if a file system is available, or a serial port if
866
not. It is intended that in-service management of NTP and SNTP
867
Version 4 servers and clients be performed using SNMP and a suitable
868
MIB to be published later. Ordinarily, SNTP servers and clients are
869
expected to operate with little or no site-specific configuration,
870
other than specifying the IP address and subnet mask or OSI NSAP
873
Unicast clients must be provided with the designated server name or
874
address. If a server name is used, the address of one of more DNS
875
servers must be provided. Multicast servers and anycast clients must
876
be provided with the TTL and local broadcast or multicast group
877
address. Anycast servers and multicast clients may be configured with
878
a list of address-mask pairs for access control, so that only those
879
clients or servers known to be trusted will be used. These servers
880
and clients must implement the IGMP protocol and be provided with the
881
local broadcast or multicast group address as well. The configuration
882
data for cryptographic authentication is beyond the scope of this
885
There are several scenarios which provide automatic server discovery
886
and selection for SNTP clients with no pre-specified configuration,
887
other than the IP address and subnet mask or OSI NSAP address. For a
888
IP subnet or LAN segment including a fully functional NTP server, the
889
clients can be configured for multicast mode using the local
890
broadcast address. The same approach can be used with other servers
891
using the multicast group address. In both cases, provision of an
892
access control list is a good way to insure only trusted sources can
893
be used to set the local clock.
898
Mills Informational [Page 16]
900
RFC 2030 SNTPv4 for IPv4, IPv6 and OSI October 1996
903
In another scenario suitable for an extended network with significant
904
network propagation delays, clients can be configured for anycast
905
mode, both upon initial startup and after some period when the
906
currently selected unicast source has not been heard. Following the
907
defined protocol, the client binds to the first reply heard and
908
continues operation in unicast mode. In this mode the local clock can
909
be automatically adjusted to compensate for the propagation delay.
911
In still another scenario suitable for any network and where
912
multicast service is not available, the DNS can be set up with a
913
common CNAME, like time.domain.net, and a list of address records for
914
NTP servers in the same domain. Upon resolving time.domain.net and
915
obtaining the list, the client selects a server at random and begins
916
operation in unicast mode with that server. Many variations on this
921
Jeff Learman was helpful in developing the OSI model for this
922
protocol. Ajit Thyagarajan provided valuable suggestions and
927
[COL94] Colella, R., R. Callon, E. Gardner, Y. Rekhter, "Guidelines
928
for OSI NSAP allocation in the Internet", RFC 1629, NIST, May 1994.
930
[DAR81] Postel, J., "Internet Protocol", STD 5, RFC 791,
931
USC Information Sciences Institute, September 1981.
933
[DEE89] Deering, S., "Host extensions for IP multicasting", STD 5,
934
RFC 1112, Stanford University, August 1989.
936
[DEE96] Deering, S., R. Hinden, "Internet Protocol, Version 6 (IPv6)
937
Specification", RFC 1883, Xerox and Ipsilon, January 1996.
939
[DOB91] Dobbins, K, W. Haggerty, C. Shue, "OSI connectionless
940
transport services on top of UDP - Version: 1", RFC 1240, Open
941
Software Foundation, June 1991.
943
[EAS95] Eastlake, D., 3rd., and C. Kaufman, "Domain Name System
944
Security Extensions", Work in Progress.
946
[FUR94] Furniss, P., "Octet sequences for upper-layer OSI to support
947
basic communications applications", RFC 1698, Consultant,
954
Mills Informational [Page 17]
956
RFC 2030 SNTPv4 for IPv4, IPv6 and OSI October 1996
959
[HIN96] Hinden, R., and S. Deering, "IP Version 6 addressing
960
Architecture", RFC 1884, Ipsilon and Xerox, January 1996.
962
[ISO86] International Standards 8602 - Information Processing Systems
963
- OSI: Connectionless Transport Protocol Specification. International
964
Standards Organization, December 1986.
966
[MIL92] Mills, D., "Network Time Protocol (Version 3) specification,
967
implementation and analysis", RFC 1305, University of Delaware,
970
[PAR93] Partridge, C., T. Mendez and W. Milliken, "Host anycasting
971
service", RFC 1546, Bolt Beranek Newman, November 1993.
973
[POS80] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
974
USC Information Sciences Institute, August 1980.
976
[POS83] Postel, J., "Time Protocol", STD 26, RFC 868,
977
USC Information Sciences Institute, May 1983.
979
Security Considerations
981
Security issues are not discussed in this memo.
986
Electrical Engineering Department
987
University of Delaware
990
Phone: (302) 831-8247
1010
Mills Informational [Page 18]
added
removed
sntp/RFC2030.TXT
