idnits 2.17.1 draft-mills-sntp-v4-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == There are 4 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 1 instance of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 977: '... 1. A client MUST NOT under any cond...' RFC 2119 keyword, line 980: '... 2. A client SHOULD increase the pol...' RFC 2119 keyword, line 984: '... 3. A client SHOULD use local server...' RFC 2119 keyword, line 987: '... 4. A client MUST allow the operator...' RFC 2119 keyword, line 991: '...r IP address is provided, it MUST be a...' (3 more instances...) -- The draft header indicates that this document obsoletes RFC2030, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document obsoletes RFC1769, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 667 has weird spacing: '...ptional opt...' == Line 812 has weird spacing: '...ntifier igno...' == Line 814 has weird spacing: '...mestamp ign...' == Line 815 has weird spacing: '... update sour...' == Line 817 has weird spacing: '...mestamp ign...' == (1 more instance...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 2003) is 7527 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'SRI02' is mentioned on line 353, but not defined == Unused Reference: 'COL94' is defined on line 1091, but no explicit reference was found in the text == Unused Reference: 'DEE96' is defined on line 1101, but no explicit reference was found in the text == Unused Reference: 'EAS95' is defined on line 1108, but no explicit reference was found in the text == Unused Reference: 'HIN96' is defined on line 1114, but no explicit reference was found in the text == Unused Reference: 'HIN03' is defined on line 1117, but no explicit reference was found in the text == Unused Reference: 'PAR93' is defined on line 1128, but no explicit reference was found in the text == Unused Reference: 'SRI01' is defined on line 1140, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 1883 (ref. 'DEE96') (Obsoleted by RFC 2460) -- Obsolete informational reference (is this intentional?): RFC 1884 (ref. 'HIN96') (Obsoleted by RFC 2373) -- Obsolete informational reference (is this intentional?): RFC 3513 (ref. 'HIN03') (Obsoleted by RFC 4291) -- Obsolete informational reference (is this intentional?): RFC 1305 (ref. 'MIL92') (Obsoleted by RFC 5905) Summary: 6 errors (**), 0 flaws (~~), 17 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET DRAFT D. Mills 3 Network Working Group University of Delaware 4 Obsoletes: 2030, 1769 D. Plonka 5 Category: Informational University of Wisconsin 6 J. Montgomery 7 Netgear 8 September 2003 10 Simple Network Time Protocol (SNTP) Version 4 11 for IPv4, IPv6 and OSI 12 14 Status of this memo 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC2026. Internet-Drafts are working 18 documents of the Internet Engineering Task Force (IETF), its areas, 19 and its working groups. Note that other groups may also distribute 20 working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsolete by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Abstract 35 This memorandum describes the Simple Network Time Protocol (SNTP) 36 Version 4, which is a subset of the Network Time Protocol (NTP) used 37 to synchronize computer clocks in the Internet. SNTP can be used when 38 the ultimate performance of the full NTP implementation described in 39 RFC-1305 is not needed or justified. SNTP Version 4 clarifies 40 certain design features of NTP which allow operation in a simple, 41 stateless remote-procedure call (RPC) mode with accuracy and 42 reliability expectations similar to the UDP/TIME protocol described 43 in RFC-868. 45 The only significant protocol change in SNTP Version 4 is a modified 46 header interpretation to accommodate Internet Protocol Version 6 47 (IPv6) (RFC-1883) and OSI (RFC-1629) addressing. However, SNTP 48 Version 4 includes an anycast mode and a public-key based 49 authentication scheme designed specifically for broadcast and anycast 50 applications. The authentication scheme extension is described in 51 another RFC. Until a definitive specification is published, these 52 extensions should be considered provisional. In addition, this memo 53 introduces the kiss-o'-death message, which can be used by servers to 54 suppress client requests as circumstances require. 56 This memorandum obsoletes RFC-1769, which describes SNTP Version 3, 57 and RFC-2030, which describes SNTP Version 4. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Operating Modes and Addressing . . . . . . . . . . . . . . . . 5 63 3. NTP Timestamp Format . . . . . . . . . . . . . . . . . . . . . 6 64 4. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 8 65 5. SNTP Client Operations . . . . . . . . . . . . . . . . . . . . 12 66 6. SNTP Server Operations . . . . . . . . . . . . . . . . . . . . 16 67 7. Configuration and Management . . . . . . . . . . . . . . . . . 19 68 8. The Kiss-o'-Death Packet . . . . . . . . . . . . . . . . . . . 20 69 9. On Being a Good Network Citizen. . . . . . . . . . . . . . . . 21 70 10. Best Practices . . . . . . . . . . . . . . . . . . . . . . . . 22 71 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24 72 12. Informative References . . . . . . . . . . . . . . . . . . . . 24 73 13. Security Considerations. . . . . . . . . . . . . . . . . . . . 26 74 14. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 26 75 15. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 27 77 1. Introduction 79 The Network Time Protocol Version 3 (NTPv3) specified in RFC-1305 80 [MIL92] is widely used to synchronize computer clocks in the global 81 Internet. It provides comprehensive mechanisms to access national 82 time and frequency dissemination services, organize the NTP subnet of 83 servers and clients and adjust the system clock in each participant. 84 In most places of the Internet of today, NTP provides accuracies of 85 1-50 ms, depending on the characteristics of the synchronization 86 source and network paths. 88 RFC-1305 specifies the NTP protocol machine in terms of events, 89 states, transition functions and actions and, in addition, engineered 90 algorithms to improve the timekeeping quality and mitigate among 91 several synchronization sources, some of which may be faulty. To 92 achieve accuracies in the low milliseconds over paths spanning major 93 portions of the Internet, these intricate algorithms, or their 94 functional equivalents, are necessary. In many applications, 95 accuracies in the order of significant fractions of a second are 96 acceptable. In simple home router applications, accuracies of up to 97 a minute may suffice. In such cases, simpler protocols such as the 98 Time Protocol specified in RFC-868 [POS83], have been used for this 99 purpose. These protocols involve an RPC exchange where the client 100 requests the time of day and the server returns it in seconds past a 101 known reference epoch. 103 NTP is designed for use by clients and servers with a wide range of 104 capabilities and over a wide range of network jitter and clock 105 frequency wander characteristics. Many users of NTP in the Internet 106 of today use a software distribution available from www.ntp.org. The 107 distribution, which includes the full suite of NTP options, 108 mitigation algorithms and security schemes, is a relatively complex, 109 real-time application. While the software has been ported to a wide 110 variety of hardware platforms ranging from personal computers to 111 supercomputers, its sheer size and complexity is not appropriate for 112 many applications. Accordingly, it is useful to explore alternative 113 strategies using simpler software appropriate for less stringent 114 accuracy expectations. 116 This memo describes the Simple Network Time Protocol Version 4 117 (SNTPv4), which is a simplified access paradigm for servers and 118 clients using NTP and SNTP, current and previous versions. The 119 access paradigm is identical to the UDP/TIME Protocol and, in fact, 120 it should be easily possible to adapt a UDP/TIME client 121 implementation, say for a personal computer, to operate using SNTP. 122 Moreover, SNTP is also designed to operate in a dedicated server 123 configuration including an integrated radio clock. With careful 124 design and control of the various latencies in the system, which is 125 practical in a dedicated design, it is possible to deliver time 126 accurate to the order of microseconds. 128 When operating with current and previous versions of NTP and SNTP, 129 SNTPv4 requires no changes to the protocol or implementations now 130 running or likely to be implemented specifically for future NTP or 131 SNTP versions. The NTP and SNTP packet formats are the same and the 132 arithmetic operations to calculate the client time, clock offset and 133 roundtrip delay are the same. To a NTP or SNTP server, NTP and SNTP 134 clients are indistinguishable; to a NTP or SNTP client, NTP and SNTP 135 servers are indistinguishable. Like NTP servers operating in non- 136 symmetric modes, SNTP servers are stateless and can support large 137 numbers of clients; however, unlike most NTP clients, SNTP clients 138 normally operate with only a single server at a time. 140 The full degree of reliability ordinarily expected of NTP servers is 141 possible only using redundant sources, diverse paths and the crafted 142 algorithms of a full NTP implementation. It is strongly recommended 143 that SNTP clients be used only at the extremities of the 144 synchronization subnet. SNTP clients should operate only at the 145 leaves (highest stratum) of the subnet and in configurations where no 146 NTP or SNTP client is dependent on another SNTP client for 147 synchronization. SNTP servers should operate only at the root 148 (stratum 1) of the subnet and then only in configurations where no 149 other source of synchronization other than a reliable radio clock or 150 telephone modem is available. 152 An important provision in this memo is the interpretation of certain 153 NTP header fields which provide for IPv6 and OSI addressing. The 154 only significant difference between the NTP and SNTPv4 header formats 155 is the four-octet Reference Identifier field, which is used primarily 156 to detect and avoid synchronization loops. In all NTP and SNTP 157 versions providing IPv4 addressing, primary servers use a four- 158 character ASCII reference clock identifier in this field, while 159 secondary servers use the 32-bit IPv4 address of the synchronization 160 source. In SNTP version 4 providing IPv6 and OSI addressing, primary 161 servers use the same clock identifier, but secondary servers use the 162 first 32 bits of the MD5 hash of the IPv6 or NSAP address of the 163 synchronization source. A further use of this field is when the 164 server sends a kiss-o'-death message documented later in this memo. 166 NTP Version 4 (NTPv4) now in deployment, but not yet the subject 167 of a standards document, uses the same Reference Identifier field 168 as SNTPv4. 170 In the case of OSI, the Connectionless Transport Service (CLTS) is 171 used as in [ISO86]. Each SNTP packet is transmitted as the TS- 172 Userdata parameter of a T-UNITDATA Request primitive. Alternately, 173 the header can be encapsulated in a TPDU which itself is transported 174 using UDP, as described in RFC-1240 [DOB91]. It is not advised that 175 NTP be operated at the upper layers of the OSI stack, such as might 176 be inferred from RFC-1698 [FUR94], as this could seriously degrade 177 accuracy. With the header formats defined in this memo, it is in 178 principle possible to interwork between servers and clients of one 179 protocol family and another, although the practical difficulties may 180 make this inadvisable. 182 In the following, indented paragraphs such as this one contain 183 information not required by the formal protocol specification, but 184 considered good practice in protocol implementations. 186 This memo is organized as follows. Section 2 describes how the 187 protocol works, the various modes and how IP addresses and UDP ports 188 are used. Section 3 describes the NTP timestamp format and Section 4 189 the NTP message format. Section 5 summarizes SNTP client operations 190 and Section 6 summarizes SNTP server operations. Section 7 191 summarizes operation and management issues. Section 8 describes the 192 kiss-o'-death message newly minted with functions similar to the ICMP 193 Source Quench and ICMP Destination Unreachable messages. Section 9 194 summarizes design issues important for good network citizenry and 195 presents an example algorithm designed to give good reliability while 196 minimizing network and server resource demands. 198 2. Operating Modes and Addressing 200 Unless excepted in context, reference to broadcast address means IPv4 201 broadcast address, IPv4 multicast group address or IPv6 site-local 202 scope address. Further information on the broadcast/multicast model 203 is in RFC-1112 [DEE89]. Details of address format, scoping rules, 204 etc., are beyond the scope of this memo. SNTPv4 can operate with 205 either unicast (point to point), broadcast (point to multipoint) or 206 anycast (multipoint to point) addressing modes. A unicast client 207 sends a request to a designated server at its unicast address and 208 expects a reply from which it can determine the time and, optionally, 209 the roundtrip delay and clock offset relative to the server. A 210 broadcast server periodically sends an unsolicited message to a 211 designated broadcast address. A broadcast client listens on this 212 address and ordinarily sends no requests. 214 Anycast is designed for use with a set of cooperating servers whose 215 addresses are not known beforehand. The anycast client sends an 216 ordinary NTP client request to a designated broadcast address. One 217 or more anycast servers listen on that address. Upon receiving a 218 request, an anycast server sends an ordinary NTP server reply to the 219 client. The client then binds to the server from which the first 220 such message was received and continues operation with that unicast 221 addresses. Subsequent replies from other anycast servers are 222 ignored. 224 Broadcast servers should respond to client unicast requests, as 225 well as send unsolicited broadcast messages. Broadcast clients 226 may send unicast requests in order to measure the network 227 propagation delay between the server and client and then continue 228 operation in listen-only mode. However, broadcast servers may 229 choose not to respond to unicast requests, so unicast clients 230 should be prepared to abandon the measurement and assume a default 231 value for the delay. 233 The client and server addresses are assigned following the usual 234 IPv4, IPv6 or OSI conventions. For NTP multicast, the IANA has 235 reserved the IPv4 group address 224.0.1.1 and the IPv6 group address 236 ending :101, with prefix determined by scoping rules. The NTP 237 broadcast address for OSI has yet to be determined. Notwithstanding 238 the IANA reserved addresses, other multicast addresses can be used 239 which do not conflict with others assigned in scope. In the case of 240 IPv4 multicast or IPv6 broadcast addresses, the client must implement 241 the Internet Group Management Protocol (IGMP) as described in RFC- 242 3376 [CAIN02], in order that the local router joins the multicast 243 group and relays messages to the IPv4 or IPv6 multicast group. The 244 scoping, routing and group membership procedures are determined by 245 considerations beyond the scope of this memo. 247 It is important to adjust the time-to-live (TTL) field in the IP 248 header of multicast messages to a reasonable value in order to 249 limit the network resources used by this (and any other) multicast 250 service. Only multicast clients in scope will receive multicast 251 server messages. Only cooperating anycast servers in scope will 252 reply to a client request. The engineering principles which 253 determine the proper values to be used are beyond the scope of 254 this memo. 256 In the case of SNTP as specified herein, there is a very real 257 vulnerability that SNTP broadcast clients can be disrupted by 258 misbehaving or hostile SNTP or NTP broadcast servers elsewhere in 259 the Internet. It is strongly recommended that access controls 260 and/or cryptographic authentication means be provided for 261 additional security in such cases. 263 While not integral to the SNTP specification, it is intended that 264 IP broadcast addresses will be used primarily in IP subnets and 265 LAN segments including a fully functional NTP server with a number 266 of dependent SNTP broadcast clients on the same subnet, while IP 267 multicast group addresses will be used only in cases where the TTL 268 is engineered specifically for each service domain. 270 3. NTP Timestamp Format 272 SNTP uses the standard NTP timestamp format described in RFC-1305 and 273 previous versions of that document. In conformance with standard 274 Internet practice, NTP data are specified as integer or fixed-point 275 quantities, with bits numbered in big-endian fashion from 0 starting 276 at the left or most significant end. Unless specified otherwise, all 277 quantities are unsigned and may occupy the full field width with an 278 implied 0 preceding bit 0. 280 Since NTP timestamps are cherished data and, in fact, represent the 281 main product of the protocol, a special timestamp format has been 282 established. NTP timestamps are represented as a 64-bit unsigned 283 fixed-point number, in seconds relative to 0h on 1 January 1900. The 284 integer part is in the first 32 bits and the fraction part in the 285 last 32 bits. In the fraction part, the non-significant low order 286 bits are not specified and ordinarily set to 0. 288 It is advisable to fill the non-significant low order bits of the 289 timestamp with a random, unbiased bitstring, both to avoid 290 systematic roundoff errors and as a means of loop detection and 291 replay detection (see below). It is important that the bitstring 292 be unpredictable by a intruder. One way of doing this is to 293 generate a random 128-bit bitstring at startup. After that, Each 294 time the system clock is read the string consisting of the 295 timestamp and bitstring is hashed with the MD5 algorithm, then the 296 non-significant bits of the timestamp are copied from the result. 298 The NTP format allows convenient multiple-precision arithmetic and 299 conversion to UDP/TIME message (seconds), but does complicate the 300 conversion to ICMP Timestamp message (milliseconds) and Unix time 301 values (seconds and microseconds or seconds and nanoseconds). The 302 maximum number that can be represented is 4,294,967,295 seconds with 303 a precision of about 232 picoseconds, which should be adequate for 304 even the most exotic requirements. 306 1 2 3 307 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 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 | Seconds | 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 | Seconds Fraction (0-padded) | 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 Note that, since some time in 1968 (second 2,147,483,648) the most 315 significant bit (bit 0 of the integer part) has been set and that the 316 64-bit field will overflow some time in 2036 (second 4,294,967,296). 317 There will exist a 232-picosecond interval, henceforth ignored, every 318 136 years when the 64-bit field will be 0, which by convention is 319 interpreted as an invalid or unavailable timestamp. 321 As the NTP timestamp format has been in use for over 20 years, it 322 remains a possibility that it will be in use 33 years from now 323 when the seconds field overflows. As it is probably inappropriate 324 to archive NTP timestamps before bit 0 was set in 1968, a 325 convenient way to extend the useful life of NTP timestamps is the 326 following convention: If bit 0 is set, the UTC time is in the 327 range 1968-2036 and UTC time is reckoned from 0h 0m 0s UTC on 1 328 January 1900. If bit 0 is not set, the time is in the range 329 2036-2104 and UTC time is reckoned from 6h 28m 16s UTC on 7 330 February 2036. Note that when calculating the correspondence, 331 2000 is a leap year and leap seconds are not included in the 332 reckoning. 334 4. Message Format 336 Both NTP and SNTP are clients of the User Datagram Protocol (UDP) 337 specified in RFC-768 [POS80], which itself is a client of the 338 Internet Protocol (IP) specified in RFC-791) [DAR81]. The structure 339 of the IP and UDP headers is described in the cited specification 340 documents and will not be detailed further here. The UDP port number 341 assigned by the IANA to NTP is 123. The SNTP client should use this 342 value in the UDP Destination Port field for client request messages. 343 The Source Port field of these messages can be any nonzero value 344 chosen for identification or multiplexing purposes. The server 345 interchanges these fields for the corresponding reply messages. 347 This differs from the RFC-2030 specifications which required both 348 the source and destination ports to be 123. The intent of this 349 change is to allow the identification of particular client 350 implementations (which are now allowed to use unreserved port 351 numbers, including ones of their choosing) and also for 352 compatibility with Network Address Port Translation (NAPT) 353 described in RFC-2663 [SRI99] and RFC-3022 [SRI02]. 355 Figure 1 is a description of the NTP and SNTP message format, which 356 follows the IP and UDP headers in the message. This format is 357 identical to the NTP message format described in RFC-1305, with the 358 exception of the Reference Identifier field described below. For 359 SNTP client messages most of these fields are zero or initialized 360 with pre-specified data. For completeness, the function of each 361 field is briefly summarized below. 363 Leap Indicator (LI): This is a two-bit code warning of an impending 364 leap second to be inserted/deleted in the last minute of the current 365 day. This field is significant only in server messages, where the 366 values are defined as follows: 368 1 2 3 369 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 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 |LI | VN |Mode | Stratum | Poll | Precision | 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 | Root Delay | 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 | Root Dispersion | 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 | Reference Identifier | 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 | | 380 | Reference Timestamp (64) | 381 | | 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 | | 384 | Originate Timestamp (64) | 385 | | 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 | | 388 | Receive Timestamp (64) | 389 | | 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 | | 392 | Transmit Timestamp (64) | 393 | | 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 | Key Identifier (optional) (32) | 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 | | 398 | | 399 | Message Digest (optional) (128) | 400 | | 401 | | 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 Figure 1. NTP Packet Header 406 LI Meaning 407 --------------------------------------------- 408 0 no warning 409 1 last minute has 61 seconds 410 2 last minute has 59 seconds) 411 3 alarm condition (clock not synchronized) 413 On startup, servers set this field to 3 (clock not synchronized) and 414 set this field to some other value when synchronized to the primary 415 reference clock. Once set to other than 3, the field is never set to 416 that value again, even if all synchronization sources become 417 unreachable or defective. 419 Version Number (VN): This is a three-bit integer indicating the 420 NTP/SNTP version number, currently 4. If necessary to distinguish 421 between IPv4, IPv6 and OSI, the encapsulating context must be 422 inspected. 424 Mode: This is a three-bit number indicating the protocol mode. The 425 values are defined as follows: 427 Mode Meaning 428 ------------------------------------ 429 0 reserved 430 1 symmetric active 431 2 symmetric passive 432 3 client 433 4 server 434 5 broadcast 435 6 reserved for NTP control message 436 7 reserved for private use 438 In unicast and anycast modes, the client sets this field to 3 439 (client) in the request and the server sets it to 4 (server) in the 440 reply. In broadcast mode, the server sets this field to 5 441 (broadcast). The other modes are not used by SNTP servers and 442 clients. 444 Stratum: This is a eight-bit unsigned integer indicating the stratum. 445 This field is significant only in SNTP server messages, where the 446 values are defined as follows: 448 Stratum Meaning 449 ---------------------------------------------- 450 0 kiss-o'-death message (see below) 451 1 primary reference (e.g., synchronized by radio clock) 452 2-15 secondary reference (synchronized by NTP or SNTP) 453 16-255 reserved 455 Poll Interval: This is an eight-bit unsigned integer used as an 456 exponent of two, where the resulting value is the maximum interval 457 between successive messages in seconds. This field is significant 458 only in SNTP server messages, where the values range from 4 (16 s) to 459 17 (131,072 s - about 36 h). 461 Precision: This is an eight-bit signed integer used as an exponent of 462 two, where the resulting value is the precision of the system clock 463 in seconds. This field is significant only in server messages, where 464 the values range from -6 for mains-frequency clocks to -20 for 465 microsecond clocks found in some workstations. 467 Root Delay: This is a 32-bit signed fixed-point number indicating the 468 total roundtrip delay to the primary reference source, in seconds 469 with fraction point between bits 15 and 16. Note that this variable 470 can take on both positive and negative values, depending on the 471 relative time and frequency offsets. This field is significant only 472 in server messages, where the values range from negative values of a 473 few milliseconds to positive values of several hundred milliseconds. 475 Root Dispersion: This is a 32-bit unsigned fixed-point number 476 indicating the nominal error relative to the primary reference 477 source, in seconds with fraction point between bits 15 and 16. This 478 field is significant only in server messages, where the values range 479 from zero to several hundred milliseconds. 481 Code External Reference Source 482 ------------------------------------------------------------------ 483 LOCL uncalibrated local clock 484 CESM calibrated Cesium clock 485 RBDM calibrated Rubidium clock 486 PPS calibrated quartz clock or other pulse-per-second 487 source 488 IRIG Inter-Range Instrumentation Group 489 ACTS NIST telephone modem service 490 USNO USNO telephone modem service 491 PTB PTB (Germany) telephone modem service 492 TDF Allouis (France) Radio 164 kHz 493 DCF Mainflingen (Germany) Radio 77.5 kHz 494 MSF Rugby (UK) Radio 60 kHz 495 WWV Ft. Collins (US) Radio 2.5, 5, 10, 15, 20 MHz 496 WWVB Boulder (US) Radio 60 kHz 497 WWVH Kaui Hawaii (US) Radio 2.5, 5, 10, 15 MHz 498 CHU Ottawa (Canada) Radio 3330, 7335, 14670 kHz 499 LORC LORAN-C radionavigation system 500 OMEG OMEGA radionavigation system 501 GPS Global Positioning Service 503 Figure 2. Reference Identifier Codes 505 Reference Identifier: This is a 32-bit bitstring identifying the 506 particular reference source. This field is significant only in 507 server messages, where for stratum 0 (kiss-o'-death message) and 1 508 (primary server), the value is a four-character ASCII string, left 509 justified and zero padded to 32 bits. For IPv4 secondary servers, 510 the value is the 32-bit IPv4 address of the synchronization source. 511 For IPv6 and OSI secondary servers, the value is the first 32 bits of 512 the MD5 hash of the IPv6 or NSAP address of the synchronization 513 source. 515 Primary (stratum 1) servers set this field to a code identifying the 516 external reference source according to Figure 2. If the external 517 reference is one of those listed, the associated code should be used. 518 Codes for sources not listed can be contrived as appropriate. 520 In previous NTP and SNTP secondary servers and clients this field 521 was often used to walk-back the synchronization subnet to the root 522 (primary server) for management purposes. In SNTPv4 with IPv6 or 523 OSI, this feature is not available, since the addresses are longer 524 than 32 bits and only a hash is available. However, a walk-back 525 can be accomplished using the NTP control message and the 526 reference identifier field described in RFC-1305. 528 Reference Timestamp: This field is significant only in server 529 messages, where the value is the time at which the system clock was 530 last set or corrected, in 64-bit timestamp format. 532 Originate Timestamp: This is the time at which the request departed 533 the client for the server, in 64-bit timestamp format. 535 Receive Timestamp: This is the time at which the request arrived at 536 the server or the reply arrived at the client, in 64-bit timestamp 537 format. 539 Transmit Timestamp: This is the time at which the request departed 540 the client or the reply departed the server, in 64-bit timestamp 541 format. 543 Authenticator (optional): When the NTP authentication scheme is 544 implemented, the Key Identifier and Message Digest fields contain the 545 message authentication code (MAC) information defined in Appendix C 546 of RFC-1305. 548 5. SNTP Client Operations 550 A SNTP client can operate in unicast, broadcast or anycast modes. In 551 unicast mode the client sends a request (NTP mode 3) to a designated 552 unicast server and expects a reply (NTP mode 4) from that server. In 553 broadcast client mode it sends no request and waits for a broadcast 554 (NTP mode 5) from one or more broadcast servers. In anycast mode, 555 the client sends a request (NTP mode 3) to a designated broadcast 556 address and expects a reply (NTP mode 4) from one or more anycast 557 servers. The client uses the first reply received to establish the 558 particular server for subsequent unicast operations. Later replies 559 from this server (duplicates) or any other server are ignored. Other 560 than the selection of address in the request, the operations of 561 anycast and unicast clients are identical. 563 Client requests are normally sent at intervals depending on the 564 frequency tolerance of the client clock and the required accuracy. 565 However, under no conditions should requests be sent at less than 566 one minute intervals. Further discussion on this point is in 567 Section 9. 569 A unicast or anycast client initializes the NTP message header, sends 570 the request to the server and strips the time of day from the 571 Transmit Timestamp field of the reply. For this purpose, all of the 572 NTP header fields shown above are set to 0, except the Mode, VN and 573 optional Transmit Timestamp fields. 575 NTP and SNTP clients set the mode field to 3 (client) for unicast and 576 anycast requests. They set the VN field to any version number 577 supported by the server selected by configuration or discovery and 578 can interoperate with all previous version NTP and SNTP servers. 579 Servers reply with the same version as the request, so the VN field 580 of the request also specifies the VN field of the reply. A prudent 581 SNTP client can specify the earliest acceptable version on the 582 expectation that any server of that or later version will respond. 583 NTP Version 3 (RFC-1305) and Version 2 (RFC-1119) servers accept all 584 previous versions, including Version 1 (RFC-1059). Note that Version 585 0 (RFC-959) is no longer supported by current and future NTP and SNTP 586 servers. 588 While not necessary in a conforming client implementation, in unicast 589 and anycast modes it highly recommended that the Transmit Timestamp 590 field in the request is set to the time of day according to the 591 client clock in NTP timestamp format. This allows a simple 592 calculation to determine the propagation delay between the server and 593 client and to align the system clock generally within a few tens of 594 milliseconds relative to the server. In addition, this provides a 595 simple method to verify that the server reply is in fact a legitimate 596 response to the specific client request and avoid replays. In 597 broadcast mode, the client has no information to calculate the 598 propagation delay or determine the validity of the server, unless one 599 of the NTP authentication schemes is used. 601 To calculate the roundtrip delay d and system clock offset t relative 602 to the server, the client sets the Transmit Timestamp field in the 603 request to the time of day according to the client clock in NTP 604 timestamp format. For this purpose the clock need not be 605 synchronized. The server copies this field to the originate timestamp 606 in the reply and sets the Receive Timestamp and Transmit Timestamp 607 fields to the time of day according to the server clock in NTP 608 timestamp format. 610 When the server reply is received, the client determines a 611 Destination Timestamp variable as the time of arrival according to 612 its clock in NTP timestamp format. The following table summarizes 613 the four timestamps. 615 Timestamp Name ID When Generated 616 ------------------------------------------------------------ 617 Originate Timestamp T1 time request sent by client 618 Receive Timestamp T2 time request received by server 619 Transmit Timestamp T3 time reply sent by server 620 Destination Timestamp T4 time reply received by client 622 The roundtrip delay d and local clock offset t are defined as 624 d = (T4 - T1) - (T3 - T2) t = ((T2 - T1) + (T3 - T4)) / 2. 626 Note that in general both delay and offset are signed quantities and 627 can in general be less than zero; however, a delay less than zero is 628 possible only in symmetric modes, which SNTP clients are forbidden to 629 use. The following table summarizes the required SNTP client 630 operations in unicast, anycast and broadcast modes. The recommended 631 error checks are shown in the Reply and Broadcast columns in the 632 table. The message should be considered valid only if all the fields 633 shown contain values in the respective ranges. Whether to believe 634 the message if one or more of the fields marked "ignore" contain 635 invalid values is at the discretion of the implementation. 637 Field Name Unicast/Anycast Broadcast 638 Request Reply 639 --------------------------------------------------------------- 640 LI 0 0-3 0-3 642 VN 1-4 copied from 1-4 643 request 645 Mode 1 or 3 2 or 4 5 647 Stratum 0 0-15 0-15 649 Poll 0 ignore ignore 651 Precision 0 ignore ignore 653 Root Delay 0 ignore ignore 655 Root Dispersion 0 ignore ignore 657 Reference Identifier 0 ignore ignore 659 Reference Timestamp 0 ignore ignore 661 Originate Timestamp 0 (see text) ignore 663 Receive Timestamp 0 (see text) ignore 665 Transmit Timestamp (see text) nonzero nonzero 667 Authenticator optional optional optional 669 While not required in a conforming SNTP client implementation, it is 670 wise to consider a suite of sanity checks designed to avoid various 671 kinds of abuse that might happen as the result of server 672 implementation errors or malicious attack. Following is a list of 673 suggested checks. 675 1. When the IP source and destination addresses are available for the 676 client request, they should match the interchanged addresses in 677 the server reply. 679 2. When the UDP source and destination ports are available for the 680 client request, they should match the interchanged ports in the 681 server reply. 683 3. The Originate Timestamp in the server reply should match the 684 Transmit Timestamp used in the client request. 686 4. The server reply should be discarded if any of the LI, Stratum, or 687 Transmit Timestamp fields are 0 or the Mode field is not 4 688 (unicast) or 5 (broadcast). 690 5. A truly paranoid client can check the Root Delay and Root 691 Dispersion fields are each greater than or equal to 0 and less 692 than infinity, where infinity is currently a cozy number like 16 693 seconds. This check avoids using a server whose synchronization 694 source has expired for a very long time. 696 6. SNTP Server Operations 698 A SNTP server operating with either a NTP or SNTP client of the same 699 or previous versions retains no persistent state. Since a SNTP 700 server ordinarily does not implement the full suite of grooming and 701 mitigation algorithms intended to support redundant servers and 702 diverse network paths, a SNTP server should be operated only in 703 conjunction with a source of external synchronization, such as a 704 reliable radio clock or telephone modem. In this case it operates as 705 a primary (stratum 1) server. 707 A SNTP server can operate with any unicast, anycast or broadcast 708 address or any combination of these addresses. A unicast or anycast 709 server receives a request (NTP mode 3), modifies certain fields in 710 the NTP header, and sends a reply (NTP mode 4), possibly using the 711 same message buffer as the request. A anycast server listens on the 712 designated broadcast address, but uses its own unicast IP address in 713 the source address field of the reply. Other than the selection of 714 address in the reply, the operations of anycast and unicast servers 715 are identical. Broadcast messages are normally sent at poll 716 intervals from 64 s to 1024 s, depending on the expected frequency 717 tolerance of the client clocks and the required accuracy. 719 Unicast and anycast servers copy the VN and Poll fields of the 720 request intact to the reply and set the Stratum field to 1. 722 Note that SNTP servers normally operate as primary (stratum 1) 723 servers. While operating at higher strata (up to 15) and at the 724 same time synchronizing to an external source such as a GPS 725 receiver is not forbidden, this is strongly discouraged. 727 If the Mode field of the request is 3 (client), the reply is set to 4 728 (server). If this field is set to 1 (symmetric active), the reply is 729 set to 2 (symmetric passive). This allows clients configured in 730 either client (NTP mode 3) or symmetric active (NTP mode 1) to 731 interoperate successfully, even if configured in possibly suboptimal 732 ways. For any other value in the Mode field, the request is 733 discarded. In broadcast (unsolicited) mode, the VN field is set to 734 4, the Mode field is set to 5 (broadcast), and the Poll field set to 735 the nearest integer base-2 logarithm of the poll interval. 737 Note that it is highly desirable that a broadcast server also 738 supports unicast clients. This is so a potential broadcast client 739 can calculate the propagation delay using a client/server exchange 740 prior to switching to broadcast client (listen-only) mode. A 741 anycast server by design also is a unicast server. There does not 742 seem to be a great advantage for a server to operate as both 743 broadcast and anycast at the same time, although the protocol 744 specification does not forbid it. 746 A broadcast or anycast server may or may not respond if not 747 synchronized to a correctly operating reference source, but the 748 preferred option is to respond, since this allows reachability to be 749 determined regardless of synchronization state. If the server has 750 never synchronized to a reference source, the LI field is set to 3 751 (unsynchronized). Once synchronized to a reference source, the LI 752 field is set to one of the other three values and remains at the last 753 value set even if the reference source becomes unreachable or turns 754 faulty. 756 If synchronized to a reference source the Stratum field is set to 1 757 and the Reference Identifier field is set to the ASCII source 758 identifier shown in Figure 2. If not synchronized, the Stratum field 759 is set to zero and the Reference Identifier field set to an ASCII 760 error identifier described below. In broadcast mode, the server 761 sends broadcasts only if synchronized to a correctly operating 762 reference source. 764 The Precision field is set to reflect the maximum reading error of 765 the system clock. For all practical cases it is computed as the 766 negative base-2 logarithm of the number of significant bits to the 767 right of the decimal point in the NTP timestamp format. The Root 768 Delay and Root Dispersion fields are set to 0 for a primary server; 769 optionally, the Root Dispersion field can be set to a value 770 corresponding to the maximum expected error of the radio clock 771 itself. 773 The timestamp fields in the server message are set as follows. If 774 the server is unsynchronized or first coming up, all timestamp fields 775 are set to zero with one exception. If the message is a reply to a 776 previously received client request, the Transmit Timestamp field of 777 the request is copied unchanged to the Originate Timestamp field of 778 the reply. It is important that this field be copied intact, as an 779 NTP or SNTP client uses it to avoid bogus messages. 781 If the server is synchronized, the Reference Timestamp is set to the 782 time the last update was received from the reference source. The 783 Originate Timestamp field is set as in the unsynchronized case above. 784 The Transmit Timestamp field are set to the time of day when the 785 message is sent. In broadcast messages the Receive Timestamp field 786 is set to zero and copied from the Transmit Timestamp field in other 787 messages. The following table summarizes these actions. 789 Field Name Unicast/Anycast Broadcast 790 Request Reply 791 ---------------------------------------------------------------- 792 LI ignore as needed as needed 794 VN 1-4 copied from 4 795 request 797 Mode 1 or 3 2 or 4 5 799 Stratum ignore 1 1 801 Poll ignore copied from log2 poll 802 request interval 804 Precision ignore -log2 server -log2 server 805 significant significant 806 bits bits 808 Root Delay ignore 0 0 810 Root Dispersion ignore 0 0 812 Reference Identifier ignore source ident source ident 814 Reference Timestamp ignore time of last time of last 815 source update source update 817 Originate Timestamp ignore copied from 0 818 transmit 819 timestamp 821 Receive Timestamp ignore time of day 0 823 Transmit Timestamp (see text) time of day time of day 825 Authenticator optional optional optional 827 There is some latitude on the part of most clients to forgive invalid 828 timestamps, such as might occur when first coming up or during 829 periods when the reference source is inoperative. The most important 830 indicator of an unhealthy server is the Stratum field, in which a 831 value of 0 indicates an unsynchronized condition. When this value is 832 displayed, clients should discard the server message, regardless of 833 the contents of other fields. 835 7. Configuration and Management 837 Initial setup for SNTP servers and clients can be done using a web 838 client, if available, or a serial port if not. Some folks hoped that 839 in-service management of NTP and SNTPv4 servers and clients be 840 performed using SNMP and a suitable MIB to be published, and this has 841 happened in some commercial SNTP servers. But, the means used in the 842 last decade and probably in the next is the NTP control and 843 monitoring protocol defined in RFC-1305. Ordinarily, SNTP servers 844 and clients are expected to operate with little or no site-specific 845 configuration, other than specifying the client IP address, subnet 846 mask, gateway. 848 Unicast clients must be provided with one or more designated server 849 names or IP addresses. If more than one server is provided, one can 850 be used for active operation and one of the others for backup should 851 the active one fail or show an error condition. It is not normally 852 useful to use more than one server at a time, as with millions of 853 SNTP-enabled devices expected in the near future, such use would 854 represent unnecessary drain on network and server resources. 856 Broadcast servers and anycast clients must be provided with the TTL 857 and local broadcast or multicast group address. Unicast and anycast 858 servers and broadcast clients may be configured with a list of 859 address-mask pairs for access control, so that only those clients or 860 servers known to be trusted will be accepted. Multicast servers and 861 clients must implement the IGMP protocol and be provided with the 862 local broadcast or multicast group address as well. The 863 configuration data for cryptographic authentication is beyond the 864 scope of this memo. 866 There are several scenarios which provide automatic server discovery 867 and selection for SNTP clients with no pre-specified server 868 configuration. For instance a role server with CNAME such as 869 pool.ntp.org returns a randomized list of volunteer secondary server 870 addresses and the client can select one or more as candidates. For 871 an IP subnet or LAN segment including a NTP or SNTP server, SNTP 872 clients can be configured as broadcast clients. The same approach 873 can be used with multicast servers and clients. In both cases, 874 provision of an access control list is a good way to insure only 875 trusted sources can be used to set the system clock. 877 In another scenario suitable for an extended network with significant 878 network propagation delays, clients can be configured for anycast 879 addresses, both upon initial startup and after some period when the 880 currently selected unicast source has not been heard. Following the 881 defined protocol, the client binds to the server from which the first 882 reply is received and continues operation in unicast mode. 884 8. The Kiss-o'-Death Packet 886 In the rambunctious Internet of today, it is imperative that some 887 means be available to tell a client to stop making requests and go 888 somewhere else. A recent experience involved a large number of 889 home/office routers all configured to use a particular university 890 time server. Under some error conditions a substantial fraction of 891 these routers would send packets at intervals of one second. The 892 resulting traffic spike was dramatic, and extreme measures were 893 required to diagnose the problem and bring it under control. The 894 conclusion is that clients must respect the means available to 895 targeted servers to stop them from sending packets. 897 According to the NTP specification RFC-1305, if the Stratum field in 898 the NTP header is 1, indicating a primary server, the Reference 899 Identifier field contains an ASCII string identifying the particular 900 reference clock type. However, in RFC-1305 nothing is said about the 901 Reference Identifier field if the Stratum field is 0, which is called 902 out as "unspecified". However, if the Stratum field is 0, the 903 Reference Identifier field can be used to convey messages useful for 904 status reporting and access control. In NTPv4 and SNTPv4, packets of 905 this kind are called Kiss-o'-Death (KoD) packets and the ASCII 906 messages they convey are called kiss codes. The KoD packets got 907 their name because an early use was to tell clients to stop sending 908 packets that violate server access controls. 910 Code Meaning 911 -------------------------------------------------------------- 912 ACST The association belongs to a anycast server 913 AUTH Server authentication failed 914 AUTO Autokey sequence failed 915 BCST The association belongs to a broadcast server 916 CRYP Cryptographic authentication or identification failed 917 DENY Access denied by remote server 918 DROP Lost peer in symmetric mode 919 RSTR Access denied due to local policy 920 INIT The association has not yet synchronized for the first 921 time 922 MCST The association belongs to a manycast server 923 NKEY No key found. Either the key was never installed or 924 is not trusted 925 RATE Rate exceeded. The server has temporarily denied access 926 because the client exceeded the rate threshold 927 RMOT Somebody is tinkering with the association from a remote 928 host running ntpdc. Not to worry unless some rascal has 929 stolen your keys 930 STEP A step change in system time has occurred, but the 931 association has not yet resynchronized 933 Figure 3. Kiss Codes 935 In general, a SNTP client should stop sending to a particular server 936 if that server returns a reply with a Stratum field of 0, regardless 937 of kiss code, and an alternate server is available. If no alternate 938 server is available, the client should retransmit using an 939 exponential-backoff algorithm described in the next section. 941 The kiss codes can provide useful information for an intelligent 942 client. These codes are encoded in four-character ASCII strings left 943 justified and zero filled. The strings are designed for character 944 displays and log files. Usually, only a few of these codes can occur 945 with SNTP clients, including DENY, RSTR and RATE. Others can occur 946 more rarely, including INIT and STEP, when the server is in some 947 special temporary condition. Figure 3 shows a list of the kiss codes 948 currently defined. 950 9. On Being a Good Network Citizen 952 SNTP and its big brother NTP have been in explosive growth over the 953 last few years, mirroring the growth of the Internet. Just about 954 every Internet appliance has some kind of NTP support, including 955 Windows XP, Cisco routers, embedded controllers and software systems 956 of all kinds. This is the first edition of the SNTP RFC where it has 957 become necessary to lay down rules of engagement in the form of 958 design criteria for SNTP client implementations. This is necessary 959 to educate software developers regarding the proper use of Internet 960 time server resources as the Internet expands and demands on time 961 servers increase, and to prevent the recurrence of the sort of 962 problem mentioned above. 964 10. Best Practices 966 NTP and SNTP clients can consume considerable network and server 967 resources if not good network citizens. There are now consumer 968 Internet commodity devices numbering in the millions that are 969 potential customers of public and private NTP and SNTP servers. 970 Recent experience strongly suggests that device designers pay 971 particular attention to minimizing resource impacts, especially if 972 large numbers of these devices are deployed. The most important 973 design consideration is the interval between client requests, called 974 the poll interval. It is extremely important that the design use the 975 maximum poll interval consistent with acceptable accuracy. 977 1. A client MUST NOT under any conditions use a poll interval less 978 than one minute. 980 2. A client SHOULD increase the poll interval using exponential 981 backoff as performance permits and especially if the server does 982 not respond within a reasonable time. 984 3. A client SHOULD use local servers whenever available to avoid 985 unnecessary traffic on backbone networks. 987 4. A client MUST allow the operator to configure the primary and/or 988 alternate server names or addresses in addition to or in place of 989 a firmware default IP address. 991 5. If a firmware default server IP address is provided, it MUST be a 992 server operated by the manufacturer or seller of the device or 993 another server, but only with the operator's permission. 995 6. A client SHOULD use the Domain Name System (DNS) to resolve the 996 server IP addresses, so the operator can do effective load 997 balancing among a server clique and change IP address binding to 998 canonical names. 1000 7. A client SHOULD re-resolve the server IP address on a periodic 1001 intervals, but not less than the time-to-live field in the DNS 1002 response. 1004 8. A client SHOULD support the NTP access-refusal mechanism, so that 1005 a server kiss-o'-death reply in response to a client request 1006 causes the client to cease sending requests to that server and to 1007 switch to an alternate, if available. 1009 The following algorithm can be used as a pattern for specific 1010 implementations. It uses the following variables: 1012 Timer: This is a counter that decrements at a fixed rate. When it 1013 reaches zero, a packet is sent and the timer initialized with the 1014 timeout for the next packet. 1016 Maximum timeout: This is the maximum timeout determined from the 1017 given oscillator frequency tolerance and the required accuracy. 1019 Server Name: This is the DNS name of the server. There may be more 1020 than one of them to be selected by some algorithm not considered 1021 here. 1023 Server IP Address: This is the IPv4, IPv6 or OSI address of the 1024 server. 1026 If the firmware or documentation includes specific server names, the 1027 names should be those the manufacturer or seller operates as a 1028 customer convenience or those for which specific permission has been 1029 obtained from the operator. A DNS request for a generic server name 1030 such as ntp.mytimeserver.com results should result in a random 1031 selection of server IP addresses available for that purpose. Each 1032 time a DNS request is received, a new randomized list is returned. 1033 The client ordinarily uses the first address on the list. 1035 When selecting candidate SNTP or NTP servers, it is imperative to 1036 respect the server operator's conditions of access. Lists of 1037 public servers and their conditions of access are available at 1038 www.ntp.org. A semi-automatic server discovery scheme using DNS 1039 is described at that site. Some ISPs operate public servers, 1040 although finding them via their helpdesks can be difficult. 1042 A well behaved client operates as follows (note that steps 2 - 4 1043 comprise a synchronization loop): 1045 1. Consider the specified frequency tolerance of the system clock 1046 oscillator. Define the required accuracy of the system clock, 1047 then calculate the maximum timeout. For instance, if the 1048 frequency tolerance is 200 parts-per-million (PPM) and the 1049 required accuracy is one minute, the maximum timeout is about 3.5 1050 days. Use the longest maximum timeout possible given the system 1051 constraints to minimize time server aggregate load, but never less 1052 than 15 minutes. 1054 2. When first coming up or after reset, randomize the timeout from 1055 one to five minutes. This is to minimize shock when 3000 PCs are 1056 rebooted at the same time power is restored after a blackout. 1057 Assume at this time the IP address is unknown and the system clock 1058 is unsynchronized. Otherwise use the timeout value as calculated 1059 in previous loop steps. Note that it may be necessary to refrain 1060 from implementing the aforementioned random delay for some classes 1061 of ICSA certification. 1063 3. When the timer reaches zero, if the IP address is not known, send 1064 a DNS query packet; otherwise send a NTP request packet to that 1065 address. If no reply packet has been heard since the last 1066 timeout, double the timeout, but not greater than the maximum 1067 timeout. If primary and secondary time servers have been 1068 configured, alternate queries between the primary and secondary 1069 servers when no successful response has been received. 1071 4. If a DNS reply packet is received, save the IP address and 1072 continue in step 2. If a KoD packet is received remove that time 1073 server from the list, activate the secondary time server and 1074 continue in step 2. If a received packet fails the sanity checks, 1075 drop that packet and also continue in step 2. If a valid NTP 1076 packet is received, update the system clock, set the timeout to 1077 the maximum, and continue to step 2. 1079 11. Acknowledgements 1081 Jeff Learman was helpful in developing the OSI model for this 1082 protocol. Ajit Thyagarajan provided valuable suggestions and 1083 corrections. 1085 12. Informative References 1087 [CAIN02] Cain, B., Deering, S., Kouvalas, I., Fenner, B. and A. 1088 Thyagarajan, "Internet Group Management Protocol, Version 1089 3", RFC 3376, Cereva Networks, October 2002. 1091 [COL94] Colella, R., Callon, R., Gardner, E. and Y. Rekhter, 1092 "Guidelines for OSI NSAP Allocation in the Internet", RFC 1093 1629, May 1994. 1095 [DAR81] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1096 1981. 1098 [DEE89] Deering, S., "Host extensions for IP multicasting", STD 5, 1099 RFC 1112, August 1989. 1101 [DEE96] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1102 (IPv6) Specification", RFC 1883, January 1996. 1104 [DOB91] Dobbins, K, Haggerty, W. and C. Shue, "OSI connectionless 1105 transport services on top of UDP - Version: 1", RFC 1240, 1106 June 1991. 1108 [EAS95] Eastlake, D., 3rd., and C. Kaufman, "Domain Name System 1109 Security Extensions", Work in Progress. 1111 [FUR94] Furniss, P., "Octet Sequences for Upper-Layer OSI to Support 1112 Basic Communications Applications", RFC 1698, October 1994. 1114 [HIN96] Hinden, R. and S. Deering, "IP Version 6 Addressing 1115 Architecture", RFC 1884, January 1996. 1117 [HIN03] Hinden, R. and S. Deering, "Internet Protocol Version 6 1118 (IPv6) Addressing Architecture", RFC 3513, April 2003. 1120 [ISO86] International Standards 8602 - Information Processing 1121 Systems - OSI: Connectionless Transport Protocol 1122 Specification. International Standards Organization, 1123 December 1986. 1125 [MIL92] Mills, D., "Network Time Protocol (Version 3) Specification, 1126 Implementation", RFC 1305, March 1992. 1128 [PAR93] Partridge, C., Mendez, T. and W. Milliken, "Host Anycasting 1129 Service", RFC 1546, November 1993. 1131 [POS80] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1132 1980. 1134 [POS83] Postel, J., "Time Protocol", STD 26, RFC 868, May 1983. 1136 [SRI99] Srisuresh, P. and M. Holdrege. "IP Network Address 1137 Translator (NAT) Terminology and Considerations", RFC 2663, 1138 August 1999. 1140 [SRI01] Srisuresh, P. and K. Egevang. "Traditional IP Network 1141 Address Translator (Traditional NAT)", RFC 3022, January 1142 2001. 1144 13. Security Considerations 1146 Security issues are not discussed in this memo. 1148 14. Author's Address 1150 David L. Mills 1151 Electrical and Computer Engineering Department 1152 University of Delaware 1153 Newark, DE 19716 1154 Phone: (302) 831-8247 1156 15. Full Copyright Statement 1158 Copyright (C) The Internet Society (2003). All Rights Reserved. 1160 This document and translations of it may be copied and furnished to 1161 others, and derivative works that comment on or otherwise explain it 1162 or assist in its implementation may be prepared, copied, published 1163 and distributed, in whole or in part, without restriction of any 1164 kind, provided that the above copyright notice and this paragraph are 1165 included on all such copies and derivative works. However, this 1166 document itself may not be modified in any way, such as by removing 1167 the copyright notice or references to the Internet Society or other 1168 Internet organizations, except as needed for the purpose of 1169 developing Internet standards in which case the procedures for 1170 copyrights defined in the Internet Standards process must be 1171 followed, or as required to translate it into languages other than 1172 English. 1174 The limited permissions granted above are perpetual and will not be 1175 revoked by the Internet Society or its successors or assignees. 1177 This document and the information contained herein is provided on an 1178 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1179 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1180 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1181 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1182 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1184 Acknowledgement 1186 Funding for the RFC Editor function is currently provided by the 1187 Internet Society.