idnits 2.17.1 draft-ietf-ntp-ntpv4-proto-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1830. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1807. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1814. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1820. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 3 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 568: '...top of UDP. All messages MUST be sent...' RFC 2119 keyword, line 569: '...port of 123, and SHOULD be sent with a...' RFC 2119 keyword, line 990: '...ast address used MUST be scoped to the...' RFC 2119 keyword, line 1628: '... A client MUST NOT use a poll int...' RFC 2119 keyword, line 1630: '... A client SHOULD increase the pol...' (6 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (October 23, 2005) is 6761 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '13' is defined on line 1764, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 1768, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1305 (ref. '1') (Obsoleted by RFC 5905) ** Obsolete normative reference: RFC 2030 (ref. '2') (Obsoleted by RFC 4330) -- Obsolete informational reference (is this intentional?): RFC 2460 (ref. '8') (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 1119 (ref. '9') (Obsoleted by RFC 1305) -- Obsolete informational reference (is this intentional?): RFC 1059 (ref. '10') (Obsoleted by RFC 1119, RFC 1305) Summary: 6 errors (**), 0 flaws (~~), 6 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NTP WG J. Burbank, Ed. 3 Internet-Draft JHU APL 4 Expires: April 26, 2006 J. Martin, Ed. 5 Netzwert AG 6 D. Mills 7 U. Del. 8 October 23, 2005 10 The Network Time Protocol Version 4 Protocol Specification 11 draft-ietf-ntp-ntpv4-proto-01 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on April 26, 2006. 38 Copyright Notice 40 Copyright (C) The Internet Society (2005). 42 Abstract 44 The Network Time Protocol (NTP) is widely used to synchronize 45 computer clocks in the Internet. This memorandum describes Version 4 46 of the NTP (NTPv4), introducing several changes from Version 3 of NTP 47 (NTPv3) described in RFC 1305, including the introduction of a 48 modified protocol header to accomodate Internet Protocol Version 6. 50 NTPv4 also includes optional extensions to the NTPv3 51 protocol,including a dynamic server discovery mechanism and an 52 authentication scheme designed specifically for multicast and 53 dynamically discovered servers. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2. NTP Timestamp . . . . . . . . . . . . . . . . . . . . . . . 5 59 3. NTP Message Formats . . . . . . . . . . . . . . . . . . . . 7 60 3.1 Leap Indicator (LI) . . . . . . . . . . . . . . . . . . . 8 61 3.2 Version (VN) . . . . . . . . . . . . . . . . . . . . . . . 9 62 3.3 Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 63 3.4 Stratum (Strat) . . . . . . . . . . . . . . . . . . . . . 10 64 3.5 Poll Interval (Poll) . . . . . . . . . . . . . . . . . . . 10 65 3.6 Precision (Prec) . . . . . . . . . . . . . . . . . . . . . 10 66 3.7 Root Delay . . . . . . . . . . . . . . . . . . . . . . . . 10 67 3.8 Root Dispersion . . . . . . . . . . . . . . . . . . . . . 10 68 3.9 Reference Identifier . . . . . . . . . . . . . . . . . . . 11 69 3.10 Reference Timestamp . . . . . . . . . . . . . . . . . . 12 70 3.11 Originate Timestamp . . . . . . . . . . . . . . . . . . 12 71 3.12 Receive Timestamp . . . . . . . . . . . . . . . . . . . 12 72 3.13 Transmit Timestamp . . . . . . . . . . . . . . . . . . . 12 73 3.14 NTPv4 Extension Fields . . . . . . . . . . . . . . . . . 12 74 3.15 Authentication (optional) . . . . . . . . . . . . . . . 13 75 4. NTP Protocol Operation . . . . . . . . . . . . . . . . . . . 14 76 5. SNTP Protocol Operation . . . . . . . . . . . . . . . . . . 14 77 6. NTP Server Operations . . . . . . . . . . . . . . . . . . . 15 78 7. NTP Client Operations . . . . . . . . . . . . . . . . . . . 17 79 8. NTP Symmetric Peer Operations . . . . . . . . . . . . . . . 20 80 9. NTPv4 Security . . . . . . . . . . . . . . . . . . . . . . . 20 81 9.1 Session Keys and Cookies . . . . . . . . . . . . . . . . . 20 82 9.2 Session Key List Generation . . . . . . . . . . . . . . . 21 83 9.3 Sending Messages . . . . . . . . . . . . . . . . . . . . . 21 84 9.4 Receiving Messages . . . . . . . . . . . . . . . . . . . . 21 85 9.5 Autokey Protocol Exchanges . . . . . . . . . . . . . . . . 22 86 10. Dynamic Server Discovery . . . . . . . . . . . . . . . . . . 23 87 11. NTP Control Messages . . . . . . . . . . . . . . . . . . . . 24 88 11.1 NTP Control Message Format . . . . . . . . . . . . . . . 26 89 11.2 Status Words . . . . . . . . . . . . . . . . . . . . . . 27 90 11.2.1 System Status Word . . . . . . . . . . . . . . . . . 28 91 11.2.2 Peer Status Word . . . . . . . . . . . . . . . . . . 29 92 11.2.3 Clock Status Word . . . . . . . . . . . . . . . . . 31 93 11.2.4 Error Status Word . . . . . . . . . . . . . . . . . 32 94 11.3 Commands . . . . . . . . . . . . . . . . . . . . . . . . 33 95 12. The Kiss-o'-Death Packet . . . . . . . . . . . . . . . . . . 35 96 13. Security Considerations . . . . . . . . . . . . . . . . . . 36 97 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . 37 98 15. Other Considerations . . . . . . . . . . . . . . . . . . . . 37 99 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 39 100 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 39 101 17.1 Normative References . . . . . . . . . . . . . . . . . . 39 102 17.2 Informative References . . . . . . . . . . . . . . . . . 39 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 40 104 Intellectual Property and Copyright Statements . . . . . . . 42 106 1. Introduction 108 The Network Time Protocol Version 3 (NTPv3) specified in [1] has been 109 widely used to synchronize computer clocks in the global Internet. 110 It provides comprehensive mechanisms to access national time and 111 frequency dissemination services, organize the NTP subnet of servers 112 and clients and adjust the system clock in each participant. In most 113 places of the Internet of today, NTP provides accuracies of 1-50 ms, 114 depending on the characteristics of the synchronization source and 115 network paths. 117 NTP is designed for use by clients and servers with a wide range of 118 capabilities and over a wide range of network jitter and clock 119 frequency wander characteristics. Many users of NTP in the Internet 120 of today use a software distribution available from www.ntp.org. The 121 distribution, which includes the full suite of NTP options, 122 mitigation algorithms and security schemes, is a relatively complex, 123 real-time application. While the software has been ported to a wide 124 variety of hardware platforms ranging from personal computers to 125 supercomputers, its sheer size and complexity is not appropriate for 126 many applications. This facilitated the development of the Simple 127 Network Time Protocol Version 4 (SNTPv4) as described in [2]. 129 Since the standardization of NTPv3, there has been significant 130 development which has led to Version 4 of the Network Time Protocol 131 (NTPv4). This document describes NTPv4, which introduces new 132 functionality to NTPv3 as described in RFC 1305, and functionality 133 expanded from that of SNTPv4 as described in RFC 2030 (SNTPv4 is a 134 subset of NTPv4). 136 When operating with current and previous versions of NTP and SNTP, 137 NTPv4 requires no changes to the protocol or implementations now 138 running or likely to be implemented specifically for future NTP or 139 SNTP versions. The NTP and SNTP packet formats are the same and the 140 arithmetic operations to calculate the client time, clock offset and 141 round trip delay are the same. To a NTP or SNTP server, NTP and SNTP 142 clients are indistinguishable; to a NTP or SNTP client, NTP and SNTP 143 servers are indistinguishable. 145 An important provision in this memo is the interpretation of certain 146 NTP header fields which provide for IPv6 and OSI addressing. The 147 only significant difference between the NTPv3 and NTPv4 header 148 formats is the four-octet Reference Identifier field, which is used 149 primarily to detect and avoid synchronization loops. In all NTP and 150 SNTP versions providing IPv4 addressing, primary servers use a four- 151 character ASCII reference clock identifier in this field, while 152 secondary servers use the 32-bit IPv4 address of the synchronization 153 source. In NTPv4 providing IPv6 and OSI addressing, primary servers 154 use the same clock identifier, but secondary servers use the first 32 155 bits of the MD5 hash of the IPv6 or NSAP address of the 156 synchronization source. A further use of this field is when the 157 server sends a kiss-o'-death message documented later in this 158 document. 160 In the case of OSI, the Connectionless Transport Service (CLTS) is 161 used as in [3]. Each NTP packet is transmitted as the TS- Userdata 162 parameter of a T-UNITDATA Request primitive. Alternately, the header 163 can be encapsulated in a TPDU which itself is transported using UDP, 164 as described in [4]. It is not advised that NTP be operated at the 165 upper layers of the OSI stack, such as might be inferred from [5], as 166 this could seriously degrade accuracy. With the header formats 167 defined in this memo, it is in principle possible to interwork 168 between servers and clients of one protocol family and another, 169 although the practical difficulties may make this inadvisable. 171 In the following, indented paragraphs such as this one contain 172 information not required by the formal protocol specification, but 173 considered good practice in protocol implementations. 175 This document is organized as follows.Section 2 describes the NTP 176 timestamp format and Section 3 the NTP message format. Section 4 177 provides general NTP protocol details, with the subset SNTP described 178 in Section 5. This is followed by specific sections on Server 179 (Section 6), Client(Section 7), and Symmetric Peer(Section 8) modes 180 of operation.Section 9 summarizes the optional security mechanisms 181 present within the NTPv4 protocol. Section 10 defines the new 182 mechanism for server discovery. Section 11 describes the control and 183 management mechanism for NTP. Section 12 describes the kiss-o'-death 184 message, whose functionality is similar to the ICMP Source Quench and 185 ICMP Destination Unreachable messages. Section 13 presents NTPv4 186 security considerations and Section 14 discusses IANA Considerations. 187 Finally, Section 15 presents various other considerations when 188 implementing and/or configuring NTPv4. 190 NTPv4 is hereafter referred to simply as NTP, unless explicitly 191 noted. 193 2. NTP Timestamp 195 NTPv4 uses the standard NTP timestamp format described in RFC 1305. 196 NTP data are specified as integer or fixed-point quantities, with 197 bits numbered in big-endian fashion from 0 starting at the left or 198 most significant end. Unless specified otherwise, all quantities are 199 unsigned and may occupy the full field width with an implied 0 200 preceding bit 0. 202 NTP timestamps are represented as a 64-bit unsigned fixed-point 203 number, in seconds relative to 0h on 1 January 1900. The integer 204 part is in the first 32 bits and the fraction part in the last 32 205 bits. In the fraction part, the non-significant low order bits are 206 not specified and ordinarily set to 0. The NTP timestamp format is 207 defined as: 209 0 1 2 3 210 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 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 | Seconds | 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 | Fraction | 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 It is advisable to fill the non-significant low order bits of the 218 timestamp with a random, unbiased bitstring, both to avoid systematic 219 roundoff errors and as a means of loop detection and replay detection 220 (see below). It is important that the bitstring be unpredictable by 221 a intruder. One way of doing this is to generate a random 128-bit 222 bitstring at startup. After that, each time the system clock is read 223 the string consisting of the timestamp and bitstring is hashed with 224 the MD5 algorithm, then the non-significant bits of the timestamp are 225 copied from the result. 227 The NTP format allows convenient multiple-precision arithmetic and 228 conversion to UDP/TIME message (seconds), but does complicate the 229 conversion to ICMP Timestamp message (milliseconds) and Unix time 230 values (seconds and microseconds or seconds and nanoseconds). The 231 maximum number that can be represented is 4,294,967,295 seconds with 232 a precision of about 232 picoseconds, which should be adequate for 233 even the most exotic requirements. 235 Note that, since some time in 1968 (second 2,147,483,648) the most 236 significant bit (bit 0 of the integer part) has been set and that the 237 64-bit field will overflow some time in 2036 (second 4,294,967,296). 238 There will exist a 232-picosecond interval, henceforth ignored, every 239 136 years when the 64-bit field will be 0, which by convention is 240 interpreted as an invalid or unavailable timestamp. 242 If bit 0 is set, the UTC time is in the range 1968-2036 and UTC time 243 is reckoned from 0h 0m 0s UTC on 1 January 1900. If bit 0 is not 244 set, the time is in the range 2036-2104 and UTC time is reckoned from 245 6h 28m 16s UTC on 7 February 2036. Note that when calculating the 246 correspondence, 2000 is a leap year and leap seconds are not included 247 in the reckoning. 249 3. NTP Message Formats 251 Both NTP and SNTP are layered above of the User Datagram Protocol 252 (UDP) [6], which itself is layered on the Internet Protocol (IP) [7] 253 [8]. The structure of the IP and UDP headers is described in the 254 cited specification documents and will not be detailed further here. 255 The UDP port number assigned to NTP is 123, which should be used in 256 both the Source Port and Destination Port fields in the UDP header. 257 The remaining UDP header fields should be set as described in the 258 specification. 260 Below is a description of the NTPv4 message format, which follows the 261 IP and UDP headers. This format is identical to that described in 262 RFC 1305, with the exception of the contents of the reference 263 identifier field. The header fields are defined as: 265 0 1 2 3 266 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 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 |LI | VN |Mode | Strat | Poll | Prec | 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | Root Delay | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | Root Dispersion | 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | Reference ID | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | | 277 + Reference Timestamp + 278 | | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 | | 281 + Origin Timestamp + 282 | | 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 | | 285 + Receive Timestamp + 286 | | 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 | | 289 + Transmit Timestamp + 290 | | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 | | 293 + Extension Field 1 (Optional) + 294 | | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | | 297 + Extension Field 2 (Optional) + 298 | | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 . . 301 . Authentication . 302 . (Optional) (160 bits) . 303 . . 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 3.1 Leap Indicator (LI) 308 This is a two-bit field indicating an impending leap second to be 309 inserted in the NTP timescale. The bits are set before 23:59 on the 310 day of insertion and reset after 00:00 on the following day. This 311 causes the number of seconds (rollover interval) in the day of 312 insertion to be increased or decreased by one. In the case of 313 primary servers the bits are set by operator intervention, while in 314 the case of secondary servers the bits are set by the protocol. The 315 possible values of the LI field, and corresponding meanings, are as 316 follows: 318 +----+------------------------------------------+ 319 | LI | Meaning | 320 +----+------------------------------------------+ 321 | 0 | no warning | 322 | 1 | last minute has 61 seconds | 323 | 2 | last minute has 59 seconds | 324 | 3 | alarm condition (clock not synchronized) | 325 +----+------------------------------------------+ 327 On startup, servers set this field to 3 (clock not synchronized) and 328 set this field to some other value when synchronized to the primary 329 reference clock. Once set to other than 3, the field is never set to 330 that value again, even if all synchronization sources become 331 unreachable or defective. 333 3.2 Version (VN) 335 This is a three-bit integer indicating the NTP/SNTP version number, 336 currently 4. If necessary to distinguish between IPv4, IPv6 and OSI, 337 the encapsulating context must be inspected. 339 3.3 Mode 341 This is a three-bit number indicating the protocol mode. The values 342 are defined as follows: 344 +------+----------------------------------+ 345 | Mode | Meaning | 346 +------+----------------------------------+ 347 | 0 | reserved | 348 | 1 | symmetric active | 349 | 2 | symmetric passive | 350 | 3 | client | 351 | 4 | server | 352 | 5 | broadcast | 353 | 6 | reserved for NTP control message | 354 | 7 | reserved for private use | 355 +------+----------------------------------+ 357 In unicast mode or discovery mode, the client sets this field to 3 358 (client) in the request and the server sets it to 4 (server) in the 359 reply. In broadcast mode, the server sets this field to 5 360 (broadcast). 362 3.4 Stratum (Strat) 364 This is a eight-bit unsigned integer indicating the stratum. This 365 field is significant only in SNTP server messages, where the values 366 are defined as follows: 368 +---------+-------------------------------------------------------+ 369 | Stratum | Meaning | 370 +---------+-------------------------------------------------------+ 371 | 0 | kiss-o'-death message | 372 | 1 | primary reference (e.g., synchronized by radio clock) | 373 | 2-15 | secondary reference (synchronized by NTP or SNTP) | 374 | 16-255 | reserved | 375 +---------+-------------------------------------------------------+ 377 3.5 Poll Interval (Poll) 379 This is an eight-bit unsigned integer used as an exponent of two, 380 where the resulting value is the maximum interval between successive 381 messages in seconds. This field is significant only in SNTP server 382 messages, where the values range from 4 (16 s) to 17 (131,072 s - 383 about 36 h). 385 3.6 Precision (Prec) 387 This is an eight-bit signed integer used as an exponent of two, where 388 the resulting value is the precision of the system clock in seconds. 389 This field is significant only in server messages, where the values 390 range from -6 for mains-frequency clocks to -20 for microsecond 391 clocks found in some workstations. 393 3.7 Root Delay 395 This is a 32-bit signed fixed-point number indicating the total 396 roundtrip delay to the primary reference source, in seconds with 397 fraction point between bits 15 and 16. Note that this variable can 398 take on both positive and negative values, depending on the relative 399 time and frequency offsets. This field is significant only in server 400 messages, where the values range from negative values of a few 401 milliseconds to positive values of several hundred milliseconds. 403 3.8 Root Dispersion 405 This is a 32-bit unsigned fixed-point number indicating the nominal 406 error relative to the primary reference source, in seconds with 407 fraction point between bits 15 and 16. This field is significant 408 only in server messages, where the values range from zero to several 409 hundred milliseconds. 411 3.9 Reference Identifier 413 This is a 32-bit bitstring identifying the particular reference 414 source. This field is significant only in server messages, where for 415 stratum 0 (kiss-o'-death message) and 1 (primary server), the value 416 is a four-character ASCII string, left justified and zero padded to 417 32 bits. For IPv4 secondary servers,the value is the 32-bit IPv4 418 address of the synchronization source. For IPv6 and OSI secondary 419 servers, the value is the first 32 bits of the MD5 hash of the IPv6 420 or NSAP address of the synchronization source. 422 Primary (stratum 1) servers set this field to a code identifying the 423 external reference source according to the below table. 425 +------+----------------------------------------------------------+ 426 | Code | External Reference Source | 427 +------+----------------------------------------------------------+ 428 | LOCL | uncalibrated local clock | 429 | CESM | calibrated Cesium clock | 430 | RBDM | calibrated Rubidium clock | 431 | PPS | calibrated quartz clock or other pulse-per-second source | 432 | IRIG | Inter-Range Instrumentation Group | 433 | ACTS | NIST telephone modem service | 434 | USNO | USNO telephone modem service | 435 | PTB | PTB (Germany) telephone modem service | 436 | TDF | Allouis (France) Radio 164 kHz | 437 | DCF | Mainflingen (Germany) Radio 77.5 kHz | 438 | MSF | Rugby (UK) Radio 60 kHz | 439 | WWV | Ft. Collins (US) Radio 2.5, 5, 10, 15, 20 MHz | 440 | WWVB | Boulder (US) Radio 60 kHz | 441 | WWVH | Kaui Hawaii (US) Radio 2.5, 5, 10, 15 MHz | 442 | CHU | Ottawa (Canada) Radio 3330, 7335, 14670 kHz | 443 | LORC | LORAN-C radionavigation system | 444 | OMEG | OMEGA radionavigation system | 445 | GPS | Global Positioning Service | 446 +------+----------------------------------------------------------+ 448 If the external reference is one of those listed, the associated code 449 should be used. Codes for sources not listed can be contrived as 450 appropriate. 452 In previous NTP and SNTP secondary servers and clients this field was 453 often used to walk-back the synchronization subnet to the root 454 (primary server) for management purposes. 456 3.10 Reference Timestamp 458 This field is significant only in server messages, where the value is 459 the time at which the system clock was last set or corrected, in 64- 460 bit timestamp format. 462 3.11 Originate Timestamp 464 This is the time at which the request departed the client for the 465 server, in 64-bit timestamp format. 467 3.12 Receive Timestamp 469 This is the time at which the request arrived at the server or the 470 reply arrived at the client, in 64-bit timestamp format. 472 3.13 Transmit Timestamp 474 This is the time at which the request departed the client or the 475 reply departed the server, in 64-bit timestamp format. 477 3.14 NTPv4 Extension Fields 479 NTPv4 defines new extension field formats. These fields are 480 processed in order and may be transmitted with or without value 481 fields. The last field is padded to a 64-bit boundary, all others 482 fields are padded to 32-bit boundaries. The field length is for all 483 payload and padding. 485 0 1 2 3 486 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 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 | Field Type | Length | 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 | Association ID | 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 | Timestamp | 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 | Filestamp | 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 496 | Value Length | 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 . . 499 . Value . 500 . . 501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 502 | Signature Length | 503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 504 . . 505 . Signature . 506 . . 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 | Padding (as needed) | 509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 511 3.15 Authentication (optional) 513 The authentication field format is defined as: 515 0 1 2 3 516 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 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 518 | Key Identifier | 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 | | 521 + + 522 | | 523 + Message Digest + 524 | | 525 + + 526 | | 527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 529 When the NTP authentication scheme is implemented, the 16-bit Key 530 Identifier and 128-bit Message Digest fields contain the Message 531 Authentication Code (MAC) information which uses an MD5 cryptosum of 532 NTP header plus extension fields. 534 4. NTP Protocol Operation 536 The NTP protocol defines three operational roles, Client, Server, and 537 Symmetric Peer. Clients request or receive time unsolicited from 538 Servers. Servers respond to requests or send periodic time updates 539 to Clients. Symmetric Peers exchange time data bidirectionally. A 540 given NTP implementation can operate in any or all of these modes. 542 NTP messages make use of two different communication modes, one to 543 one and one to many, commonly referred to as unicast and broadcast. 544 For the purposes of this document, the term broadcast is interpreted 545 to mean any available one to many mechanism. For IPv4 this equates 546 to either IPv4 broadcast or IPv4 multicast. For IPv6 this equates to 547 IPv6 multicast. For OSI this XXXXX. For this purpose, IANA has 548 allocated the IPv4 multicast address 224.0.1.1 and the IPv6 multicast 549 address ending :101, with prefix determined by scoping rules. The 550 NTP broadcast address for OSI has yet to be determined. 552 It is important to adjust the time-to-live (TTL) field in the IP 553 header of multicast messages to a reasonable value in order to 554 limit the network resources used by this (and any other) multicast 555 service. Only multicast clients in scope will receive multicast 556 server messages. Only cooperating anycast servers in scope will 557 reply to a client request. The engineering principles which 558 determine the proper values to be used are beyond the scope of 559 this memo. 561 While not integral to the NTP specification, it is intended that 562 IP broadcast addresses will be used primarily in IP subnets and 563 LAN segments including a fully functional NTP server with a number 564 of dependent NTP broadcast clients on the same subnet, while IP 565 multicast group addresses will be used only in cases where the TTL 566 is engineered specifically for each service domain. 568 NTP messages are layered on top of UDP. All messages MUST be sent 569 with a destination port of 123, and SHOULD be sent with a source port 570 of 123. 572 5. SNTP Protocol Operation 574 SNTP operates using the same message formats, addresses, and ports as 575 NTP. However, it is stateless, operating only in the Client or 576 Server roles. Thus it is compatible with, and a subset of, NTP. 578 Without the complexity and state required by the Symmetric Peer, SNTP 579 is apropriate for devices which require a significantly smaller 580 resource footprint. Since a SNTP server ordinarily does not 581 implement the full suite of grooming and mitigation algorithms 582 intended to support redundant servers and diverse network paths, a 583 SNTP server should be operated only in conjunction with a source of 584 external synchronization, such as a reliable radio clock or telephone 585 modem. In this case it operates as a primary (stratum 1) server. 587 Note that SNTP servers normally operate as primary (stratum 1) 588 servers. While operating at higher strata (up to 15) and at the 589 same time synchronizing to an external source such as a GPS 590 receiver is not forbidden, this is strongly discouraged. 592 6. NTP Server Operations 594 Fundamentally, the NTP Server role consists of listening for client 595 requests, and providing time and associated details as a response. 596 Additionally, a Server can provide time and associated details 597 periodically via a broadcast mechanism. An NTP server operating with 598 either an NTP or SNTP client of the same or previous versions retains 599 no persistent state. 601 An NTP server can communicate via unicast, broadcast, or both. A 602 server receiving a unicast request (NTP mode 3), modifies fields in 603 the NTP header as described below, and sends a reply (NTP mode 4), 604 possibly using the same message buffer as the request. When 605 operating in a broadcast mode, unsolicited messages (NTP mode 5) with 606 field values as described below are normally sent at intervals 607 ranging from 64 s to 1024 s, depending on the expected frequency 608 tolerance of the client clocks and the required accuracy. 610 A broadcast server may or may not send messages if not synchronized 611 to a correctly operating source, but the preferred option is to 612 transmit, since this allows reachability to be determined regardless 613 of synchronization state. 615 The Leap Indicator (LI) is set to 3 (unsynchronized) if the server 616 has never synchronized to a reference source. Once synchronized, the 617 LI field is set to one of the other three values and remains at the 618 last value set even if the reference source becomes unreachable or 619 turns faulty. 621 The Version (VN) is copied from the request packet, if responding to 622 a unicast request. For broadcast, this is set to 4. 624 The Mode is set to Server (4) if in response to a unicast request. 625 For broadcast, this is set to Broadcast (5). 627 The Stratum field to the server's current stratum, if synchronized. 628 If synchronized to a reference source the Stratum field is set to 1. 629 If unsynchronized this field is set to 0. 631 The Poll field is coppied from the request, if responding to a 632 unicast request. For broadcast, this is set to the nearest integer 633 base-2 logarithm of the poll interval. 635 The Precision field is set to reflect the maximum reading error of 636 the system clock. For all practical cases it is computed as the 637 negative base-2 logarithm of the number of significant bits to the 638 right of the decimal point in the NTP timestamp format. The Root 639 Delay and Root Dispersion fields are set to 0 for a primary server; 640 optionally, the Root Dispersion field can be set to a value 641 corresponding to the maximum expected error of the radio clock 642 itself. 644 If the server is synchronized to a reference source, the value of the 645 Reference ID is set to a four-character ASCII string identifying the 646 source, left justified and zero padded to 32bits. For IPv4 secondary 647 servers,the value is the 32-bit IPv4 address of the synchronization 648 source. For IPv6 and OSI secondary servers, the value is the first 649 32 bits of the MD5 hash of the IPv6 or NSAP address of the 650 synchronization source. If unsynchronized, it is set to an ASCII 651 error identifier. 653 The timestamp fields in the server message are set as follows. If 654 the server is unsynchronized or first coming up, all timestamp fields 655 are set to zero with one exception. If the server is synchronized 656 and up, the Transmit Timestamp field of the request is copied 657 unchanged to the Originate Timestamp field of the reply. It is 658 important that this field be copied intact, as an NTP or SNTP client 659 uses it to avoid bogus messages. 661 If the server is synchronized, the Reference Timestamp is set to the 662 time the last update was received from the reference source. The 663 Originate Timestamp field is set as in the unsynchronized case above. 664 The Transmit Timestamp field are set to the time of day when the 665 message is sent. In broadcast messages the Receive Timestamp field 666 is set to zero and copied from the Transmit Timestamp field in other 667 messages. 669 The following table summarizes these actions: 671 +----------------+----------------+----------------+----------------+ 672 | Field Name | Unicast | Unicast Reply | Broadcast | 673 | | Request | | | 674 +----------------+----------------+----------------+----------------+ 675 | LI | ignore | as needed | as needed | 676 | VN | 1-4 | copied from | 4 | 677 | | | request | | 678 | Mode | 1 or 3 | 2 or 4 | 5 | 679 | Stratum | ignore | 1 | 1 | 680 | Poll | ignore | copied from | log2 poll | 681 | | | request | interval | 682 | Precision | ignore | -log2 server | -log2 server | 683 | | | significant | significant | 684 | | | bits | bits | 685 | Root Delay | ignore | 0 | 0 | 686 | Root | ignore | 0 | 0 | 687 | Dispersion | | | | 688 | Reference | ignore | source ident | source ident | 689 | Identifier | | | | 690 | Reference | ignore | time of last | time of last | 691 | Timestamp | | src. update | src. update | 692 | Originate | ignore | copied from | 0 | 693 | Timestamp | | xmit timestamp | | 694 | Receive | ignore | time of day | 0 | 695 | Timestamp | | | | 696 | Transmit | (see text) | time of day | time of day | 697 | Timestamp | | | | 698 | Authenticator | optional | optional | optional | 699 +----------------+----------------+----------------+----------------+ 701 Broadcast servers should respond to client unicast requests, as 702 well as send unsolicited broadcast messages. Broadcast clients 703 may send unicast requests in order to measure the network 704 propagation delay between the server and client and then continue 705 operation in listen-only mode. However, broadcast servers may 706 choose not to respond to unicast requests, so unicast clients 707 should be prepared to abandon the measurement and assume a default 708 value for the delay 710 7. NTP Client Operations 712 The role of an NTP client is to determine the current time (and 713 associated information) from an NTP server. This can be done 714 actively, by sending a unicast request to a configured server, or 715 passively by listening on a known address for periodic server 716 messages. 718 An NTP client can operate in unicast or broadcast modes. In unicast 719 mode the client sends a request (NTP mode 3) to a designated unicast 720 server and expects a reply (NTP mode 4) from that server. In 721 broadcast client mode it sends no request and waits for a broadcast 722 (NTP mode 5) from one or more broadcast servers. 724 Broadcast clients may send unicast requests in order to measure 725 the network propagation delay between the server and client and 726 then continue operation in listen-only mode. However, broadcast 727 servers may choose not to respond to unicast requests, so unicast 728 clients should be prepared to abandon the measurement and assume a 729 default value for the delay. 731 Client requests are normally sent at intervals depending on the 732 frequency tolerance of the client clock and the required accuracy. 733 However, under no conditions should requests be sent at less than 734 one minute intervals. Further discussion on this point is in 735 Section 12. 737 A unicast client initializes the NTP message header, sends the 738 request to the server and strips the time of day from the Transmit 739 Timestamp field of the reply. For this purpose, all of the NTP 740 header fields shown in Section 3 are set to 0, except the Mode, VN 741 and optional Transmit Timestamp fields. 743 NTP and SNTP clients set the mode field to 3 (client) for unicast and 744 anycast requests. They set the VN field to any version number 745 supported by the server selected by configuration or discovery and 746 can interoperate with all previous version NTP and SNTP servers. 747 Servers reply with the same version as the request, so the VN field 748 of the request also specifies the VN field of the reply. An NTP 749 client can specify the earliest acceptable version on the expectation 750 that any server of that or later version will respond. NTPv4 servers 751 are backwards compatible with NTPv3 as defined in RFC 1305, NTPv2 as 752 defined in [9], and NTPv1 as defined in [10]. NTPv0 defined in [11] 753 is not supported. 755 In unicast mode, the Transmit Timestamp field in the request should 756 be set to the time of day according to the client clock in NTP 757 timestamp format. This allows a simple calculation to determine the 758 propagation delay between the server and client and to align the 759 system clock generally within a few tens of milliseconds relative to 760 the server. In addition, this provides a simple method to verify 761 that the server reply is in fact a legitimate response to the 762 specific client request and avoid replays. In broadcast mode, the 763 client has no information to calculate the propagation delay or 764 determine the validity of the server, unless one of the NTP 765 authentication schemes is used. The following table summarizes the 766 required NTP client operations in unicast, anycast and broadcast 767 modes. The recommended error checks are shown in the Reply and 768 Broadcast columns in the table. The message should be considered 769 valid only if all the fields shown contain values in the respective 770 ranges. Whether to believe the message if one or more of the fields 771 marked "ignore" contain invalid values is at the discretion of the 772 implementation. 774 There is some latitude on the part of most clients to forgive invalid 775 timestamps, such as might occur when first coming up or during 776 periods when the reference source is inoperative. The most important 777 indicator of an unhealthy server is the Stratum field, in which a 778 value of 0 indicates an unsynchronized condition. When this value is 779 displayed, clients should discard the server message, regardless of 780 the contents of other fields. 782 The following table summarizes the proper setting of these fields: 784 +----------------+----------------+----------------+----------------+ 785 | Field Name | Unicast | Unicast Reply | Broadcast | 786 | | Request | | | 787 +----------------+----------------+----------------+----------------+ 788 | LI | 0 | 0-3 | 0-3 | 789 | VN | 1-4 | copied from | 1-4 | 790 | | | request | | 791 | Mode | 1 or 3 | 2 or 4 | 5 | 792 | Stratum | 0 | 0-15 | 0-15 | 793 | Poll | 0 | ignore | ignore | 794 | Precision | 0 | ignore | ignore | 795 | Root Delay | 0 | ignore | ignore | 796 | Root | 0 | ignore | ignore | 797 | Dispersion | | | | 798 | Reference | 0 | ignore | ignore | 799 | Identifier | | | | 800 | Reference | 0 | ignore | ignore | 801 | Timestamp | | | | 802 | Originate | 0 | (see text) | ignore | 803 | Timestamp | | | | 804 | Receive | 0 | (see text) | ignore | 805 | Timestamp | | | | 806 | Transmit | (see text) | nonzero | nonzero | 807 | Timestamp | | | | 808 | Authenticator | optional | optional | optional | 809 +----------------+----------------+----------------+----------------+ 811 8. NTP Symmetric Peer Operations 813 NTP Symmetric Peer mode is intended for configurations where a set of 814 low-stratum peers operate as mutual backups for each other. Each 815 peer normally operates with oner or more sources, such as a reference 816 clock, or a subset of primary or secondry servers known to be 817 reliable or authentic. 819 Symmetric Peer mode is exclusive to the NTP protocol and is 820 specifically excluded from SNTP operation. 822 9. NTPv4 Security 824 NTPv4 employs the Autokey security protocol, which works 825 independently for each client, with tentative outcomes confirmed only 826 after both succeed. Public keys and certificates are obtained and 827 verified relatively infrequently using X.509 certificates and 828 certificate trails. Session keys are derived from public keys. Each 829 NTP message is individually authenticated using the session key and 830 the message digest (keyed MD5). A proventic trail is a sequence of 831 NTP servers each synchronized and cryptographically veritifed to the 832 next lower stratum server and ending on one or more trusted servers. 833 Proventic trails are constructed from each server to the trusted 834 servers at decreasing stratum levels. When server time and at least 835 one proventic trail are verified, the peer is admitted to the 836 population and used to synchronize the system clock. 838 9.1 Session Keys and Cookies 840 NTPv4 session keys have four 32-bit words, as shown in Figure 5. 842 0 1 2 3 843 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 844 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 845 | Source Address | 846 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 847 | Destination Address | 848 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 849 | Key ID | 850 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 851 | Cookie | 852 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 854 Figure 5. NTPv4 Session Key Format 856 The session key value is the 16-octet MD5 message digest of the 857 session key. Key IDs have pseudo-random values and are used only 858 once. A special key ID value of zero is used as a NAK reply. In 859 multicast mode, and in any message including an extension field, the 860 cookie has a public value (zero). In client/server modes, the cookie 861 is a hash of the addresses and a private value. In symmetric modes, 862 the cookie is a random roll. In the event that both peers generate 863 cookies, the agreed-upon cookie is the exclusive-OR of the two 864 values. 866 The server generates a cookie unique to the client and server 867 addresses and its own private value. It returns the cookie, 868 signature, and timestampe to the client in an extension field. The 869 cookie is transmitted from server to client encrypted by the client 870 public key. The server uses the cookie to validate requests and 871 construct replies. The client uses the cookie to validate the reply 872 and checks that the request key ID matches the reply key ID. 874 9.2 Session Key List Generation 876 The server rolls a random 32-bit seed as the initial key ID and 877 selects the cookie. Messages with a zero cookie contain only public 878 values. The initial session key is constructed using the given 879 addressses, cookie and initial key ID. The session key value is 880 stored in the key cache. The next session key is constructed using 881 the first four octets of the session key value as the new key ID. 882 The server continues to generate the full list. The final index 883 number and last key ID are provided in an extension field with 884 signature and timestamp. 886 9.3 Sending Messages 888 The MAC consists of the MD5 message digest of the NTP header and 889 extension fields using the session key ID and value stored in the key 890 cache. The server uses the session key ID list in reverse order and 891 discards each key value after use. An extension field containing the 892 last index number and key ID is included in the first packet 893 transmitted (last on the list). This extension field can be provided 894 upon request at any time. When all entries in the key list are used, 895 a new one is generated. 897 9.4 Receiving Messages 899 The intent is not to hide the message contents. Rather, the goal is 900 to verify its source and that it has not been modified in transit. 901 The MAC message digest is compared with the computed digest of the 902 NTP header and extension fields using the session key ID in the MAC 903 and the key value computed from the addresses, key ID and cookie. If 904 the cookie is zero, the message contains public values. Anybody can 905 validate the message or make a valid message containing any values. 906 If the cookie has been determined by secret means, nobody except the 907 parties to the secret can validate a message or make a valid message. 909 9.5 Autokey Protocol Exchanges 911 There are five types of Autokey protocol exchanges: 913 Parameter Exchange (ASSOC message): This message exchanges host 914 names, agrees on digest/signature and identity schemes. This 915 protocol exchange is unsigned. Optionally, host name/address can 916 be verified using reverse-DNS. An initial association request is 917 sent by the client, sending the host name and status word 919 0 1 2 3 920 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 921 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 922 | Digest/Signature NID | Client | Ident | Host | 923 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 925 Figure 6 Status Word Format 927 If the server digest NID and ID scheme agree, the server responds 928 with an association response message, sending host name and status 929 word. The client, upon agreeing with digest NID and ID scheme, 930 then sends a certificate request. The server responds with an 931 X.509 certificate and signature. The certificate request/response 932 cycle repeats as needed. A primary (Stratum 1) certifcate is 933 explicitly trusted and self-signed. Secondary certificates are 934 signed by the next lower stratum server and validated with its 935 public key. 937 Certificate Exchange (CERT message): This exchange is used to 938 obtain and verify certificates on the trail to a trusted root 939 certificate. Certificate exchanges follow the same process as 940 parameter exchanges. 942 Identity Exchange (IFF, GW, and MV messages): This exchange is 943 used to verify server identity using an agreed identity scheme 944 (TC, IFF, GQ, MV). This exchange is a challenge-response scheme. 945 The client initiates by sending a challenge request. The server 946 then provides the challenge response. 948 Values Exchange (COOKIE and AUTO messages): This exchange is used 949 to obtain and verify the cookie, autokey values, and leapseconds 950 table, depending on the association mode (client-server, 951 broadcast, symmetric). For cookie exchanges, the client sends its 952 public key to the server without signature when not synchronized. 953 Symmetric active peers send its public key and signature to 954 passive peer when synchronized. The server cookie is encrypted 955 from the hash of source/destination addresses, zero key ID, and 956 server private value. A symmetric passive cookie is a random 957 value for every exchange. The server private value is refreshed 958 and protocol restarted once per day. For autokey exchanges, the 959 server generates a key list and signature is calculated to last 960 about one hour. A client sends requests to the server without 961 signature when not synchronized. The server replies with the last 962 index number and key ID on the list. Broadcast servers uses AUTO 963 response for the first message after regenerating the key and 964 ASSOC responses for all other messages. 966 Signature Exchange (SIGN message): This exchange requests the 967 server to sign and return a client certificate. The exchange is 968 valid only when the client has synchronized to a proventic source 969 and the server identity has been confirmed. This exchange is used 970 to authenticate clients to servers, with the server acting as de 971 facto certificate authority using an encrypted credential scheme. 972 The client sends a certificate to the server with or without 973 signature. The server extracts the requested data and signs that 974 data with the server private key. The client then verifies the 975 certificate and signature. Subsequently, the client supplies this 976 certificate rather than self-signed certificates, so clients can 977 verify with the server public key. 979 10. Dynamic Server Discovery 981 NTPv4 provides a mechanism, commonly known as "Manycast", for a 982 client to dynamically discover the existance of one or more servers 983 with no a-priori knowledge. Once servers are discovered, they are 984 then treated as any other unicast server. 986 A client employing server discovery is configured with MinServers, 987 the minimum number of desired servers and MaxServers, the maximum 988 number of desired servers. The discovery mechanism is a simple 989 expanding ring search, using IP multicast with increasing TTLs or Hop 990 Counts. The multicast address used MUST be scoped to the local site, 991 as defined by [12]. 993 The client initiates the discovery process by sending an NTP message 994 to the configured multicast address with an IP TTL or Hop Count of 1. 995 This message has all of the NTP header fields set to 0, except the 996 Mode, VN and optional Transmit Timestamp fields. The Mode is set to 997 3. It then starts a retry timer (Default: 64 seconds) and listens 998 for unicast responses from servers. The source address of any server 999 responses are treated as newly configured unicast servers, up to a 1000 limit of MaxServers. If the number of discovered servers is less 1001 than MinServers when the retry timer expires, an identical NTP 1002 message is sent with an increased TTL/Hop Count, and the retry timer 1003 is restarted. This continues until either MinServers servers have 1004 been discovered or a configured maximum TTL/Hop Count is reached. If 1005 the configured maximum TTL/Hop Count is reached, packets continue to 1006 be periodically sent at the maximum TTL/Hop Count. If at some 1007 subsequent time, the number of valid servers drops below MinServers, 1008 the process restarts at the initial state. 1010 A server configured to provide server discovery will listen on the 1011 specified multicast address for discovery messages from clients. If 1012 the server is in scope of the current TTL and is itself synchronized 1013 to a valid source it replies to the discovery message from the client 1014 with an ordinary unicast server message as described in Section 6 1016 11. NTP Control Messages 1018 In a comprehensive network-management environment, facilities are 1019 presumed available to perform routine NTP control and monitoring 1020 functions, such as setting the leap-indicator bits at the primary 1021 servers, adjusting the various system parameters and monitoring 1022 regular operations. Ordinarily, these functions can be implemented 1023 using a network-management protocol such as SNMP and suitable 1024 extensions to the MIB database. However, in those cases where such 1025 facilities are not available, these functions can be implemented 1026 using special NTP control messages described herein. These messages 1027 are intended for use only in systems where no other management 1028 facilities are available or appropriate, such as in dedicated- 1029 function bus peripherals. Support for these messages is not required 1030 in order to conform to this specification. 1032 The NTP Control Message has the value 6 specified in the mode field 1033 of the first octet of the NTP header and is formatted as shown below. 1034 The format of the data field is specific to each command or response; 1035 however, in most cases the format is designed to be constructed and 1036 viewed by humans and so is coded in free-form ASCII. This 1037 facilitates the specification and implementation of simple management 1038 tools in the absence of fully evolved network-management facilities. 1039 As in ordinary NTP messages, the authenticator field follows the data 1040 field. If the authenticator is used the data field is zero-padded to 1041 a 32-bit boundary, but the padding bits are not considered part of 1042 the data field and are not included in the field count. 1044 IP hosts are not required to reassemble datagrams larger than 576 1045 octets; however, some commands or responses may involve more data 1046 than will fit into a single datagram. Accordingly, a simple 1047 reassembly feature is included in which each octet of the message 1048 data is numbered starting with zero. As each fragment is transmitted 1049 the number of its first octet is inserted in the offset field and the 1050 number of octets is inserted in the count field. The more-data (M) 1051 bit is set in all fragments except the last. 1053 Most control functions involve sending a command and receiving a 1054 response, perhaps involving several fragments. The sender chooses a 1055 distinct, nonzero sequence number and sets the status field and R and 1056 E bits to zero. The responder interprets the opcode and additional 1057 information in the data field, updates the status field, sets the R 1058 bit to one and returns the three 32-bit words of the header along 1059 with additional information in the data field. In case of invalid 1060 message format or contents the responder inserts a code in the status 1061 field, sets the R and E bits to one and, optionally, inserts a 1062 diagnostic message in the data field. 1064 Some commands read or write system variables and peer variables for 1065 an association identified in the command. Others read or write 1066 variables associated with a radio clock or other device directly 1067 connected to a source of primary synchronization information. To 1068 identify which type of variable and association a 16-bit association 1069 identifier is used. System variables are indicated by the identifier 1070 zero. As each association is mobilized a unique, nonzero identifier 1071 is created for it. These identifiers are used in a cyclic fashion, 1072 so that the chance of using an old identifier which matches a newly 1073 created association is remote. A management entity can request a 1074 list of current identifiers and subsequently use them to read and 1075 write variables for each association. An attempt to use an expired 1076 identifier results in an exception response, following which the list 1077 can be requested again. 1079 Some exception events, such as when a peer becomes reachable or 1080 unreachable, occur spontaneously and are not necessarily associated 1081 with a command. An implementation may elect to save the event 1082 information for later retrieval or to send an asynchronous response 1083 (called a trap) or both. In case of a trap the IP address and port 1084 number is determined by a previous command and the sequence field is 1085 set as described below. Current status and summary information for 1086 the latest exception event is returned in all normal responses. Bits 1087 in the status field indicate whether an exception has occurred since 1088 the last response and whether more than one exception has occurred. 1090 Commands need not necessarily be sent by an NTP peer, so ordinary 1091 access-control procedures may not apply; however, the optional mask/ 1092 match mechanism suggested elsewhere in this document provides the 1093 capability to control access by mode number, so this could be used to 1094 limit access for control messages (mode 6) to selected address 1095 ranges. 1097 11.1 NTP Control Message Format 1099 The format of the NTP Control Message header, which immediately 1100 follows the UDP header, is shown in Figure X. Following is a 1101 description of its fields. Bit positions marked as zero are reserved 1102 and should always be transmitted as zero. 1103 0 1 2 3 1104 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 1105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1106 |00 |VN | 6 | REM | Op | Sequence | 1107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1108 | Status | Association ID | 1109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1110 | Offset | Count | 1111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1112 . . 1113 . Data (468 Octets Max) . 1114 . . 1115 | | Padding (zeros) | 1116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1117 | Authenticator (optional)(96) | 1118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1119 NTP Control Message Format 1121 Version Number (VN): This is a three-bit integer indicating the NTP 1122 version number, currently four (4) 1124 Mode: This is a three-bit integer indicating the mode. It must have 1125 the value 6, indicating an NTP control message. 1127 Response Bit (R): Set to zero for commands, one for responses. 1129 Error Bit (E): Set to zero for normal response, one for error 1130 response. 1132 More Bit (M): Set to zero for last fragment, one for all others. 1134 Operation Code (Op): This is a five-bit integer specifying the 1135 command function. Values currently defined include the following: 1137 +-------+----------------------------------------+ 1138 | Value | Meaning | 1139 +-------+----------------------------------------+ 1140 | 0 | reserved | 1141 | 1 | read status command/response | 1142 | 2 | read variables command/response | 1143 | 3 | write variables command/response | 1144 | 4 | read clock variables command/response | 1145 | 5 | write clock variables command/response | 1146 | 6 | set trap address/port command/response | 1147 | 7 | trap response | 1148 | 8-31 | reserved | 1149 +-------+----------------------------------------+ 1151 Sequence: This is a 16-bit integer indicating the sequence number of 1152 the command or response. 1154 Status: This is a 16-bit code indicating the current status of the 1155 system, peer or clock, with values coded as described in following 1156 sections. 1158 Association ID: This is a 16-bit integer identifying a valid 1159 association. 1161 Offset: This is a 16-bit integer indicating the offset, in octets, of 1162 the first octet in the data area. 1164 Count: This is a 16-bit integer indicating the length of the data 1165 field, in octets. 1167 Data: This contains the message data for the command or response. 1168 The maximum number of data octets is 468. 1170 Authenticator (optional): When the NTP authentication mechanism is 1171 implemented, this contains the authenticator information. 1173 11.2 Status Words 1175 Status words indicate the present status of the system, associations 1176 and clock. They are designed to be interpreted by network-monitoring 1177 programs and are in one of four 16-bit formats shown in Figure 1178 6<$&fig6> and described in this section. System and peer status 1179 words are associated with responses for all commands except the read 1180 clock variables, write clock variables and set trap address/port 1181 commands. The association identifier zero specifies the system 1182 status word, while a nonzero identifier specifies a particular peer 1183 association. The status word returned in response to read clock 1184 variables and write clock variables commands indicates the state of 1185 the clock hardware and decoding software. A special error status 1186 word is used to report malformed command fields or invalid values. 1188 11.2.1 System Status Word 1190 The system status word appears in the status field of the response to 1191 a read status or read variables command with a zero association 1192 identifier. The format of the system status word is as follows: 1193 0 1 1194 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1195 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1196 | LI | Clock Source | Count | Code | 1197 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1198 System Status Word 1200 Leap Indicator (LI): This is a two-bit code warning of an impending 1201 leap second to be inserted/deleted in the last minute of the current 1202 day, with bit 0 and bit 1, respectively, coded as follows: 1204 +-------+------------------------------------------+ 1205 | Value | Meaning | 1206 +-------+------------------------------------------+ 1207 | 00 | no warning | 1208 | 01 | last minute has 61 seconds | 1209 | 10 | last minute has 59 seconds | 1210 | 11 | alarm condition (clock not synchronized) | 1211 +-------+------------------------------------------+ 1213 Clock Source: This is a six-bit integer indicating the current 1214 synchronization source, with values coded as follows: 1216 +-------+---------------------------------------------------------+ 1217 | Value | Meaning | 1218 +-------+---------------------------------------------------------+ 1219 | 0 | unspecified or unknown | 1220 | 1 | Calibrated atomic clock (e.g.,, HP 5061) | 1221 | 2 | VLF (band 4) or LF (band 5) radio (e.g.,, OMEGA,, WWVB) | 1222 | 3 | HF (band 7) radio (e.g.,, CHU,, MSF,, WWV/H) | 1223 | 4 | UHF (band 9) satellite (e.g.,, GOES,, GPS) | 1224 | 5 | local net (e.g.,, DCN,, TSP,, DTS) | 1225 | 6 | UDP/NTP | 1226 | 7 | UDP/TIME | 1227 | 8 | eyeball-and-wristwatch | 1228 | 9 | telephone modem (e.g. NIST) | 1229 | 10-63 | reserved | 1230 +-------+---------------------------------------------------------+ 1232 System Event Counter: This is a four-bit integer indicating the 1233 number of system exception events occurring since the last time the 1234 system status word was returned in a response or included in a trap 1235 message. The counter is cleared when returned in the status field of 1236 a response and freezes when it reaches the value 15. 1238 System Event Code: This is a four-bit integer identifying the latest 1239 system exception event, with new values overwriting previous values, 1240 and coded as follows: 1242 +---------------------------------+---------------------------------+ 1243 | Value | Meaning | 1244 +---------------------------------+---------------------------------+ 1245 | 0 | unspecified | 1246 | 1 | system restart | 1247 | 2 | system or hardware fault | 1248 | 3 | system new status word (leap | 1249 | | bits or synchronization change) | 1250 | 4 | system new synchronization | 1251 | | source or stratum (sys.peer or | 1252 | | sys.stratum change | 1253 | 5 | system clock reset (offset | 1254 | | correction exceeds CLOCK.MAX) | 1255 | 6 | system invalid time or date | 1256 | | (see NTP specification) | 1257 | 7 | system clock exception (see | 1258 | | system clock status word) | 1259 | 8-15 | reserved | 1260 +---------------------------------+---------------------------------+ 1262 11.2.2 Peer Status Word 1264 A peer status word is returned in the status field of a response to a 1265 read status, read variables or write variables command and appears 1266 also in the list of association identifiers and status words returned 1267 by a read status command with a zero association identifier. The 1268 format of a peer status word is as follows: 1269 0 1 1270 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1271 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1272 | Peer Status | Sel | Count | Code | 1273 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1274 Peer Status Word 1276 Peer Status: This is a five-bit code indicating the status of the 1277 peer determined by the packet procedure, with bits assigned as 1278 follows: 1280 +-------+------------------------------------------+ 1281 | Value | Meaning | 1282 +-------+------------------------------------------+ 1283 | 0 | configured (peer.config) | 1284 | 1 | authentication enabled (peer.authenable) | 1285 | 2 | authentication okay (peer.authentic) | 1286 | 3 | reachability okay (peer.reach) | 1287 | 4 | reserved | 1288 +-------+------------------------------------------+ 1290 Peer Selection (Sel): This is a three-bit integer indicating the 1291 status of the peer determined by the clock-selection procedure, with 1292 values coded as follows: 1294 +---------------------------------+---------------------------------+ 1295 | Value | Meaning | 1296 +---------------------------------+---------------------------------+ 1297 | 0 | rejected | 1298 | 1 | passed sanity checks | 1299 | 2 | passed correctness checks | 1300 | 3 | passed candidate checks (if | 1301 | | limit check implemented) | 1302 | 4 | passed outlyer checks | 1303 | 5 | current synchronization source; | 1304 | | max distance exceeded (if limit | 1305 | | check implemented) | 1306 | 6 | current synchronization source; | 1307 | | max distance okay | 1308 | 7 | reserved | 1309 +---------------------------------+---------------------------------+ 1311 Peer Event Counter: This is a four-bit integer indicating the number 1312 of peer exception events that occurred since the last time the peer 1313 status word was returned in a response or included in a trap message. 1314 The counter is cleared when returned in the status field of a 1315 response and freezes when it reaches the value 15. 1317 Peer Event Code: This is a four-bit integer identifying the latest 1318 peer exception event, with new values overwriting previous values, 1319 and coded as follows: 1321 +---------------------------------+---------------------------------+ 1322 | Value | Meaning | 1323 +---------------------------------+---------------------------------+ 1324 | 0 | unspecified | 1325 | 1 | peer IP error | 1326 | 2 | peer authentication failure | 1327 | | (peer.authentic bit was one now | 1328 | | zero) | 1329 | 3 | peer unreachable (peer.reach | 1330 | | was nonzero now zero) | 1331 | 4 | peer reachable (peer.reach was | 1332 | | zero now nonzero) | 1333 | 5 | peer clock exception (see peer | 1334 | | clock status word) | 1335 | 6-15 | reserved | 1336 +---------------------------------+---------------------------------+ 1338 11.2.3 Clock Status Word 1340 There are two ways a reference clock can be attached to a NTP service 1341 host, as an dedicated device managed by the operating system and as a 1342 synthetic peer managed by NTP. As in the read status command, the 1343 association identifier is used to identify which one, zero for the 1344 system clock and nonzero for a peer clock. Only one system clock is 1345 supported by the protocol, although many peer clocks can be 1346 supported. A system or peer clock status word appears in the status 1347 field of the response to a read clock variables or write clock 1348 variables command. This word can be considered an extension of the 1349 system status word or the peer status word as appropriate. The 1350 format of the clock status word is as follows: 1351 0 1 1352 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1353 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1354 | Clock Status | Code | 1355 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1356 Clock Status Word 1358 Clock Status: This is an eight-bit integer indicating the current 1359 clock status, with values coded as follows: 1361 +-------+---------------------------------+ 1362 | Value | Meaning | 1363 +-------+---------------------------------+ 1364 | 0 | clock operating within nominals | 1365 | 1 | reply timeout | 1366 | 2 | bad reply format | 1367 | 3 | hardware or software fault | 1368 | 4 | propagation failure | 1369 | 5 | bad date format or value | 1370 | 6 | bad time format or value | 1371 | 7-255 | reserved | 1372 +-------+---------------------------------+ 1374 Clock Event Code: This is an eight-bit integer identifying the latest 1375 clock exception event, with new values overwriting previous values. 1376 When a change to any nonzero value occurs in the radio status field, 1377 the radio status field is copied to the clock event code field and a 1378 system or peer clock exception event is declared as appropriate. 1380 11.2.4 Error Status Word 1382 An error status word is returned in the status field of an error 1383 response as the result of invalid message format or contents. Its 1384 presence is indicated when the E (error) bit is set along with the 1385 response (R) bit in the response. It consists of an eight-bit 1386 integer coded as follows: 1387 0 1 1388 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1389 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1390 | Error Code | Reserved | 1391 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1392 Error Status Word 1394 +-------+----------------------------------+ 1395 | Value | Meaning | 1396 +-------+----------------------------------+ 1397 | 0 | unspecified | 1398 | 1 | authentication failure | 1399 | 2 | invalid message length or format | 1400 | 3 | invalid opcode | 1401 | 4 | unknown association identifier | 1402 | 5 | unknown variable name | 1403 | 6 | invalid variable value | 1404 | 7 | administratively prohibited | 1405 | 8-255 | reserved | 1406 +-------+----------------------------------+ 1408 11.3 Commands 1410 Commands consist of the header and optional data field shown in 1411 Figure 6. When present, the data field contains a list of 1412 identifiers or assignments in the form 1414 <>[=<>],<>[=<>],... 1416 where <> is the ASCII name of a system or peer variable 1417 specified in Table 2 or Table 3 and <> is expressed as a 1418 decimal, hexadecimal or string constant in the syntax of the C 1419 programming language. Where no ambiguity exists, the <169>sys.<170> 1420 or <169>peer.<170> prefixes shown in Table 2 or Table 4 can be 1421 suppressed. Whitespace (ASCII nonprinting format effectors) can be 1422 added to improve readability for simple monitoring programs that do 1423 not reformat the data field. Internet addresses are represented as 1424 four octets in the form [n.n.n.n], where n is in decimal notation and 1425 the brackets are optional. Timestamps, including reference, 1426 originate, receive and transmit values, as well as the logical clock, 1427 are represented in units of seconds and fractions, preferably in 1428 hexadecimal notation, while delay, offset, dispersion and distance 1429 values are represented in units of milliseconds and fractions, 1430 preferably in decimal notation.All other values are represented 1431 as-is, preferably in decimal notation. 1433 Implementations may define variables other than those listed in Table 1434 2 or Table 3. Called extramural variables, these are distinguished 1435 by the inclusion of some character type other than alphanumeric or 1436 <169>.<170> in the name. For those commands that return a list of 1437 assignments in the response data field, if the command data field is 1438 empty, it is expected that all available variables defined in Table 3 1439 or Table 4 of the NTP specification will be included in the response. 1440 For the read commands, if the command data field is nonempty, an 1441 implementation may choose to process this field to individually 1442 select which variables are to be returned. 1444 Commands are interpreted as follows: 1446 Read Status (1): The command data field is empty or contains a list 1447 of identifiers separated by commas. The command operates in two ways 1448 depending on the value of the association identifier. If this 1449 identifier is nonzero, the response includes the peer identifier and 1450 status word. Optionally, the response data field may contain other 1451 information, such as described in the Read Variables command. If the 1452 association identifier is zero, the response includes the system 1453 identifier (0) and status word, while the data field contains a list 1454 of binary-coded pairs 1455 <> <>, 1457 one for each currently defined association. 1459 Read Variables (2): The command data field is empty or contains a 1460 list of identifiers separated by commas. If the association 1461 identifier is nonzero, the response includes the requested peer 1462 identifier and status word, while the data field contains a list of 1463 peer variables and values as described above. If the association 1464 identifier is zero, the data field contains a list of system 1465 variables and values. If a peer has been selected as the 1466 synchronization source, the response includes the peer identifier and 1467 status word; otherwise, the response includes the system identifier 1468 (0) and status word. 1470 Write Variables (3): The command data field contains a list of 1471 assignments as described above. The variables are updated as 1472 indicated. The response is as described for the Read Variables 1473 command. 1475 Read Clock Variables (4): The command data field is empty or contains 1476 a list of identifiers separated by commas. The association 1477 identifier selects the system clock variables or peer clock variables 1478 in the same way as in the Read Variables command. The response 1479 includes the requested clock identifier and status word and the data 1480 field contains a list of clock variables and values, including the 1481 last timecode message received from the clock. 1483 Write Clock Variables (5): The command data field contains a list of 1484 assignments as described above. The clock variables are updated as 1485 indicated. The response is as described for the Read Clock Variables 1486 command. 1488 Set Trap Address/Port (6): The command association identifier, status 1489 and data fields are ignored. The address and port number for 1490 subsequent trap messages are taken from the source address and port 1491 of the control message itself. The initial trap counter for trap 1492 response messages is taken from the sequence field of the command. 1493 The response association identifier, status and data fields are not 1494 significant. Implementations should include sanity timeouts which 1495 prevent trap transmissions if the monitoring program does not renew 1496 this information after a lengthy interval. 1498 Trap Response (7): This message is sent when a system, peer or clock 1499 exception event occurs. The opcode field is 7 and the R bit is set. 1500 The trap counter is incremented by one for each trap sent and the 1501 sequence field set to that value. The trap message is sent using the 1502 IP address and port fields established by the set trap address/port 1503 command. If a system trap the association identifier field is set to 1504 zero and the status field contains the system status word. If a peer 1505 trap the association identifier field is set to that peer and the 1506 status field contains the peer status word. Optional ASCII-coded 1507 information can be included in the data field. 1509 12. The Kiss-o'-Death Packet 1511 In the interest of self-preservation, it is important that NTP 1512 servers have a mechanism to supress or otherwise influence the amount 1513 of queries performed by NTP clients. 1515 According to the NTPv3 specification RFC 1305, if the Stratum field 1516 in the NTP header is 1, indicating a primary server, the Reference 1517 Identifier field contains an ASCII string identifying the particular 1518 reference clock type. However, in RFC 1305 nothing is said about the 1519 Reference Identifier field if the Stratum field is 0, which is called 1520 out as "unspecified". However, if the Stratum field is 0, the 1521 Reference Identifier field can be used to convey messages useful for 1522 status reporting and access control. In NTPv4 and SNTPv4, packets of 1523 this kind are called Kiss-o'-Death (KoD) packets and the ASCII 1524 messages they convey are called kiss codes. The KoD packets got 1525 their name because an early use was to tell clients to stop sending 1526 packets that violate server access controls. 1528 The kiss codes can provide useful information for an intelligent 1529 client. These codes are encoded in four-character ASCII strings left 1530 justified and zero filled. The strings are designed for character 1531 displays and log files. A list of the currently-defined kiss codes 1532 is in the following table. 1534 +---------------------------------+---------------------------------+ 1535 | Code | Meaning | 1536 +---------------------------------+---------------------------------+ 1537 | ACST | The association belongs to an | 1538 | | anycast server | 1539 | AUTH | Server authentication failed | 1540 | AUTO | Autokey sequence failed | 1541 | BCST | The association belongs to a | 1542 | | broadcast server | 1543 | CRYP | Cryptographic authentication or | 1544 | | identification failed | 1545 | DENY | Access denied by remote server | 1546 | DROP | Lost peer in symmetric mode | 1547 | RSTR | Access denied due to local | 1548 | | policy | 1549 | INIT | The association has not yet | 1550 | | synchronized for the first time | 1551 | MCST | The association belongs to a | 1552 | | dynamically discovered server | 1553 | NKEY | No key found. Either the key | 1554 | | was never installed or is not | 1555 | | trusted | 1556 | RATE | Rate exceeded. The server has | 1557 | | temporarily denied access | 1558 | | because the client exceeded the | 1559 | | rate threshold | 1560 | RMOT | Somebody is tinkering with the | 1561 | | association from a remote host | 1562 | | running ntpdc. Not to worry | 1563 | | unless some rascal has stolen | 1564 | | your keys | 1565 | STEP | A step change in system time | 1566 | | has occurred, but the | 1567 | | association has not yet | 1568 | | resynchronized | 1569 +---------------------------------+---------------------------------+ 1571 In general, an NTP client should stop sending to a particular server 1572 if that server returns a reply with a Stratum field of 0, regardless 1573 of kiss code, and an alternate server is available. If no alternate 1574 server is available, the client should retransmit using an 1575 exponential-backoff algorithm described in Section 15. 1577 13. Security Considerations 1579 In the case of NTP as specified herein, there is a very real 1580 vulnerability that NTP broadcast clients can be disrupted by 1581 misbehaving or hostile SNTP or NTP broadcast servers elsewhere in the 1582 Internet. It is strongly recommended that access controls and/or 1583 cryptographic authentication means be provided for additional 1584 security in such cases. 1586 While not required in a conforming NTP client implementation, there 1587 are a variety of recommended checks that an NTP client can perform 1588 that are designed to avoid various types of abuse that might happen 1589 as the result of server implementation errors or malicious attack. 1590 These recommended checks are as follows: 1592 When the IP source and destination addresses are available for the 1593 client request, they should match the interchanged addresses in 1594 the server reply. 1596 When the UDP source and destination ports are available for the 1597 client request, they should match the interchanged ports in the 1598 server reply. 1600 The Originate Timestamp in the server reply should match the 1601 Transmit Timestamp used in the client request. 1603 The server reply should be discarded if any of the LI, Stratum, or 1604 Transmit Timestamp fields are 0 or the Mode field is not 4 1605 (unicast) or 5 (broadcast). 1607 A truly paranoid client can check the Root Delay and Root 1608 Dispersion fields are each greater than or equal to 0 and less 1609 than infinity, where infinity is currently a cozy number like 16 1610 seconds. This check avoids using a server whose synchronization 1611 source has expired for a very long time. 1613 14. IANA Considerations 1615 15. Other Considerations 1617 NTP and SNTP clients can consume considerable network and server 1618 resources if not "good network citizens." There are now consumer 1619 Internet commodity devices numbering in the millions that are 1620 potential customers of public and private NTP and SNTP servers. 1621 Recent experience strongly suggests that device designers pay 1622 particular attention to minimizing resource impacts, especially if 1623 large numbers of these devices are deployed. The most important 1624 design consideration is the interval between client requests, called 1625 the poll interval. It is extremely important that the design use the 1626 maximum poll interval consistent with acceptable accuracy. 1628 A client MUST NOT use a poll interval less than TBD minutes. 1630 A client SHOULD increase the poll interval using exponential 1631 backoff as performance permits and especially if the server does 1632 not respond within a reasonable time. 1634 A client SHOULD use local servers whenever available to avoid 1635 unnecessary traffic on backbone networks. 1637 A client MUST allow the operator to configure the primary and/or 1638 alternate server names or addresses in addition to or in place of 1639 a firmware default IP address. 1641 If a firmware default server IP address is provided, it MUST be a 1642 server operated by the manufacturer or seller of the device or 1643 another server, but only with the operator's permission. 1645 A client SHOULD use the Domain Name System (DNS) to resolve the 1646 server IP addresses, so the operator can do effective load 1647 balancing among a server clique and change IP address binding to 1648 canonical names. 1650 A client SHOULD re-resolve the server IP address on a periodic 1651 intervals, but not less than the time-to-live field in the DNS 1652 response. 1654 A client SHOULD support the NTP access-refusal mechanism, so that 1655 a server kiss-o'-death reply in response to a client request 1656 causes the client to cease sending requests to that server and to 1657 switch to an alternate, if available. 1659 If the firmware or documentation includes specific server names, the 1660 names should be those the manufacturer or seller operates as a 1661 customer convenience or those for which specific permission has been 1662 obtained from the operator. A DNS request for a generic server name 1663 such as ntp.mytimeserver.com results should result in a random 1664 selection of server IP addresses available for that purpose. Each 1665 time a DNS request is received, a new randomized list is returned. 1666 The client ordinarily uses the first address on the list. 1668 When selecting candidate SNTP or NTP servers, it is imperative to 1669 respect the server operator's conditions of access. Lists of 1670 public servers and their conditions of access are available at 1671 www.ntp.org. A semi-automatic server discovery scheme using DNS 1672 is described at that site. Some ISPs operate public servers, 1673 although finding them via their helpdesks can be difficult. 1675 A well behaved client operates as follows (note that steps 2 - 4 1676 comprise a synchronization loop): 1678 Consider the specified frequency tolerance of the system clock 1679 oscillator. Define the required accuracy of the system clock, 1680 then calculate the maximum timeout. For instance, if the 1681 frequency tolerance is 200 parts-per-million (PPM) and the 1682 required accuracy is one minute, the maximum timeout is about 3.5 1683 days. Use the longest maximum timeout possible given the system 1684 constraints to minimize time server aggregate load, but never less 1685 than 15 minutes. 1687 When first coming up or after reset, randomize the timeout from 1688 one to five minutes. This is to minimize shock when 3000 PCs are 1689 rebooted at the same time power is restored after a blackout. 1690 Assume at this time the IP address is unknown and the system clock 1691 is unsynchronized. Otherwise use the timeout value as calculated 1692 in previous loop steps. Note that it may be necessary to refrain 1693 from implementing the aforementioned random delay for some classes 1694 of ICSA certification. 1696 When the timer reaches zero, if the IP address is not known, send 1697 a DNS query packet; otherwise send a NTP request packet to that 1698 address. If no reply packet has been heard since the last 1699 timeout, double the timeout, but not greater than the maximum 1700 timeout. If primary and secondary time servers have been 1701 configured, alternate queries between the primary and secondary 1702 servers when no successful response has been received. 1704 If a DNS reply packet is received, save the IP address and 1705 continue in step 2. If a KoD packet is received remove that time 1706 server from the list, activate the secondary time server and 1707 continue in step 2. If a received packet fails the sanity checks, 1708 drop that packet and also continue in step 2. If a valid NTP 1709 packet is received, update the system clock, set the timeout to 1710 the maximum, and continue to step 2. 1712 16. Acknowledgements 1714 This document has drawn significant material from the document 1715 draft-mills-sntp-v4-00.txt. As a result, the authors would like to 1716 acknowledge D. Plonka of the University of Wisconsin and J. 1717 Montgomery of Netgear, who were significant contributors to that 1718 draft. 1720 17. References 1722 17.1 Normative References 1724 [1] Mills, D., "Network Time Protocol (Version 3) Specification, 1725 Implementation", RFC 1305, March 1992. 1727 [2] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 for 1728 IPv4, IPv6 and OSI", RFC 2030, October 1996. 1730 17.2 Informative References 1732 [3] International Standards Organization, "International Standards 1733 8602 - Information Processing Systems - OSI: Connectionless 1734 Transport Protocol Specification.", ISO 8602, December 1986. 1736 [4] Shue, C., Haggerty, W., and K. Dobbins, "OSI connectionless 1737 transport services on top of UDP: Version 1", RFC 1240, 1738 June 1991. 1740 [5] Furniss, P., "Octet Sequences for Upper-Layer OSI to Support 1741 Basic Communications Applications", RFC 1698, October 1994. 1743 [6] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1744 August 1980. 1746 [7] Postel, J., "Internet Protocol", STD 5, RFC 791, 1747 September 1981. 1749 [8] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 1750 Specification", RFC 2460, December 1998. 1752 [9] Mills, D., "Network Time Protocol (version 2) specification and 1753 implementation", STD 12, RFC 1119, September 1989. 1755 [10] Mills, D., "Network Time Protocol (version 1) specification and 1756 implementation", RFC 1059, July 1988. 1758 [11] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, 1759 RFC 959, October 1985. 1761 [12] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, 1762 RFC 2365, July 1998. 1764 [13] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 1765 Thyagarajan, "Internet Group Management Protocol, Version 3", 1766 RFC 3376, October 2002. 1768 [14] Deering, S., "Host extensions for IP multicasting", STD 5, 1769 RFC 1112, August 1989. 1771 Authors' Addresses 1773 Jack Burbank (editor) 1774 Johns Hopkins University Applied Physics Lab 1775 11100 Johns Hopkins Road 1776 Laurel, MD 20723-6099 1777 US 1779 Phone: +1 443 778 7127 1780 Email: jack.burbank@jhuapl.edu 1781 Jim Martin (editor) 1782 Netzwert AG 1783 An den Treptowers 1 1784 Berlin 12435 1785 Germany 1787 Phone: +49.30/5 900 80-1180 1788 Email: jim@netzwert.ag 1790 Dr. David L. Mills 1791 University of Delaware 1792 Newark, DE 19716 1793 US 1795 Phone: +1 302 831 8247 1796 Email: mills@udel.edu 1798 Intellectual Property Statement 1800 The IETF takes no position regarding the validity or scope of any 1801 Intellectual Property Rights or other rights that might be claimed to 1802 pertain to the implementation or use of the technology described in 1803 this document or the extent to which any license under such rights 1804 might or might not be available; nor does it represent that it has 1805 made any independent effort to identify any such rights. Information 1806 on the procedures with respect to rights in RFC documents can be 1807 found in BCP 78 and BCP 79. 1809 Copies of IPR disclosures made to the IETF Secretariat and any 1810 assurances of licenses to be made available, or the result of an 1811 attempt made to obtain a general license or permission for the use of 1812 such proprietary rights by implementers or users of this 1813 specification can be obtained from the IETF on-line IPR repository at 1814 http://www.ietf.org/ipr. 1816 The IETF invites any interested party to bring to its attention any 1817 copyrights, patents or patent applications, or other proprietary 1818 rights that may cover technology that may be required to implement 1819 this standard. Please address the information to the IETF at 1820 ietf-ipr@ietf.org. 1822 Disclaimer of Validity 1824 This document and the information contained herein are provided on an 1825 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1826 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1827 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1828 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1829 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1830 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1832 Copyright Statement 1834 Copyright (C) The Internet Society (2005). This document is subject 1835 to the rights, licenses and restrictions contained in BCP 78, and 1836 except as set forth therein, the authors retain all their rights. 1838 Acknowledgment 1840 Funding for the RFC Editor function is currently provided by the 1841 Internet Society.