idnits 2.17.1 draft-ietf-ntp-ntpv4-proto-02.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 1744. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1721. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1728. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1734. ** 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 2 instances 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 'Obsoletes: ' line in the draft header should list only the _numbers_ of the RFCs which will be obsoleted by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document obsoletes RFC4330, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (March 2006) is 6616 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) ** Obsolete normative reference: RFC 1305 (ref. '1') (Obsoleted by RFC 5905) -- Obsolete informational reference (is this intentional?): RFC 4330 (ref. '2') (Obsoleted by RFC 5905) -- Obsolete informational reference (is this intentional?): RFC 2460 (ref. '3') (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 1119 (ref. '11') (Obsoleted by RFC 1305) -- Obsolete informational reference (is this intentional?): RFC 1059 (ref. '12') (Obsoleted by RFC 1119, RFC 1305) -- Obsolete informational reference (is this intentional?): RFC 2434 (ref. '16') (Obsoleted by RFC 5226) Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 13 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 Obsoletes: RFC 4330 (if approved) J. Martin, Ed. 5 Expires: September 2, 2006 Netzwert AG 6 D. Mills 7 U. Del. 8 March 2006 10 The Network Time Protocol Version 4 Protocol Specification 11 draft-ietf-ntp-ntpv4-proto-02 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 September 2, 2006. 38 Copyright Notice 40 Copyright (C) The Internet Society (2006). 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. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 4 57 2. NTP Timestamp . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. NTP Message Formats . . . . . . . . . . . . . . . . . . . . . 6 59 3.1. Leap Indicator (LI) . . . . . . . . . . . . . . . . . . . 7 60 3.2. Version (VN) . . . . . . . . . . . . . . . . . . . . . . . 8 61 3.3. Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 62 3.4. Stratum (Strat) . . . . . . . . . . . . . . . . . . . . . 9 63 3.5. Poll Interval (Poll) . . . . . . . . . . . . . . . . . . . 9 64 3.6. Precision (Prec) . . . . . . . . . . . . . . . . . . . . . 9 65 3.7. Root Delay . . . . . . . . . . . . . . . . . . . . . . . . 9 66 3.8. Root Dispersion . . . . . . . . . . . . . . . . . . . . . 10 67 3.9. Reference Identifier . . . . . . . . . . . . . . . . . . . 10 68 3.10. Reference Timestamp . . . . . . . . . . . . . . . . . . . 11 69 3.11. Originate Timestamp . . . . . . . . . . . . . . . . . . . 11 70 3.12. Receive Timestamp . . . . . . . . . . . . . . . . . . . . 11 71 3.13. Transmit Timestamp . . . . . . . . . . . . . . . . . . . . 11 72 3.14. NTPv4 Extension Fields . . . . . . . . . . . . . . . . . . 12 73 3.15. Authentication (optional) . . . . . . . . . . . . . . . . 13 74 4. NTP Protocol Operation . . . . . . . . . . . . . . . . . . . . 14 75 5. SNTP Protocol Operation . . . . . . . . . . . . . . . . . . . 17 76 6. NTP Server Operations . . . . . . . . . . . . . . . . . . . . 18 77 7. NTP Client Operations . . . . . . . . . . . . . . . . . . . . 20 78 8. NTP Symmetric Peer Operations . . . . . . . . . . . . . . . . 22 79 9. Dynamic Server Discovery . . . . . . . . . . . . . . . . . . . 22 80 10. The Kiss-o'-Death Packet . . . . . . . . . . . . . . . . . . . 23 81 11. Security Considerations . . . . . . . . . . . . . . . . . . . 24 82 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 83 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25 84 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 85 14.1. Normative References . . . . . . . . . . . . . . . . . . . 25 86 14.2. Informative References . . . . . . . . . . . . . . . . . . 25 87 Appendix A. NTP Control Messages . . . . . . . . . . . . . . . . 27 88 A.1. NTP Control Message Format . . . . . . . . . . . . . . . . 28 89 A.2. Status Words . . . . . . . . . . . . . . . . . . . . . . . 30 90 A.2.1. System Status Word . . . . . . . . . . . . . . . . . . 31 91 A.2.2. Peer Status Word . . . . . . . . . . . . . . . . . . . 33 92 A.2.3. Clock Status Word . . . . . . . . . . . . . . . . . . 34 93 A.2.4. Error Status Word . . . . . . . . . . . . . . . . . . 35 94 A.3. Commands . . . . . . . . . . . . . . . . . . . . . . . . . 36 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39 96 Intellectual Property and Copyright Statements . . . . . . . . . . 40 98 1. Introduction 100 The Network Time Protocol Version 3 (NTPv3) [1] has been widely used 101 to synchronize computer clocks in the global Internet. It provides 102 comprehensive mechanisms to access national time and frequency 103 dissemination services, organize the NTP subnet of servers and 104 clients and adjust the system clock in each participant. In most 105 places on the Internet of today, NTP provides accuracies of 1-50 ms, 106 depending on the characteristics of the synchronization source and 107 network paths. 109 NTP is designed for use by clients and servers with a wide range of 110 capabilities. Thus, the Simple Network Time Protocol Version 4 111 (SNTPv4) as described in [2] was developed for platforms that cannot 112 afford the size and complexity of NTP as a whole. 114 Since the standardization of NTPv3, there has been significant 115 development which has led to Version 4 of the Network Time Protocol 116 (NTPv4). This document describes NTPv4, which introduces new 117 functionality to NTPv3 as described in RFC 1305, and functionality 118 expanded from that of SNTPv4 as described in RFC 4330 (SNTPv4 is a 119 subset of NTPv4). This document obsoletes RFC 4330. 121 When operating with current and previous versions of NTP and SNTP, 122 NTPv4 requires no changes to the protocol or implementations now 123 running or likely to be implemented specifically for future NTP or 124 SNTP versions. The NTP and SNTP packet formats are the same and the 125 arithmetic operations to calculate the client time, clock offset and 126 round trip delay are the same. To a NTP or SNTP server, NTP and SNTP 127 clients are indistinguishable; to a NTP or SNTP client, NTP and SNTP 128 servers are indistinguishable. 130 An important provision in this memo is the interpretation of certain 131 NTP header fields which provide for IPv6 [3]and OSI [4] addressing. 132 The only significant difference between the NTPv3 and NTPv4 header 133 formats is the four-octet Reference Identifier field, which is used 134 primarily to detect and avoid synchronization loops. In all NTP and 135 SNTP versions providing IPv4 addressing, primary servers use a four- 136 character ASCII reference clock identifier in this field, while 137 secondary servers use the 32-bit IPv4 address of the synchronization 138 source. In NTPv4 providing IPv6 and OSI addressing, primary servers 139 use the same clock identifier, but secondary servers use the first 32 140 bits of the MD5 hash of the IPv6 or NSAP address of the 141 synchronization source. A further use of this field is when the 142 server sends a kiss-o'-death message documented later in this 143 document. 145 In the case of OSI, the Connectionless Transport Service (CLTS) is 146 used as in [5]. Each NTP packet is transmitted as the TS- Userdata 147 parameter of a T-UNITDATA Request primitive. Alternately, the header 148 can be encapsulated in a TPDU which itself is transported using UDP, 149 as described in [6]. It is not advised that NTP be operated at the 150 upper layers of the OSI stack, such as might be inferred from [7], as 151 this could seriously degrade accuracy. With the header formats 152 defined in this memo, it is, in principle, possible to interwork 153 between servers and clients of one protocol family and another, 154 although the practical difficulties may make this inadvisable. 156 This document is organized as follows. Section 2 describes the NTP 157 timestamp format and Section 3 the NTP message format. Section 4 158 provides general NTP protocol details, with the subset SNTP described 159 in Section 5. This is followed by specific sections on Server 160 (Section 6), Client(Section 7), and Symmetric Peer(Section 8) modes 161 of operation. Section 9 defines the new mechanism for server 162 discovery. describes the control and management mechanism for NTP. 163 Section 10 describes the kiss-o'-death message, whose functionality 164 is similar to the ICMP Source Quench and ICMP Destination Unreachable 165 messages. Section 11 presents NTPv4 security considerations and 166 Section 12 discusses IANA Considerations.Appendix A presents optional 167 NTP control messages. 169 NTPv4 is hereafter referred to simply as NTP, unless explicitly 170 noted. 172 1.1. Requirements Notation 174 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 175 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 176 document are to be interpreted as described in RFC 2119 [8]. 178 2. NTP Timestamp 180 There are three NTP formats used to represent time values: a 128-bit 181 date format, a 64-bit timestamp format, and a 32-bit short format. 182 NTP data are specified as integer or fixed-point quantities, with 183 bits numbered in big-endian fashion from 0 starting at the left or 184 most significant end. Unless specified otherwise, all quantities are 185 unsigned and may occupy the full field width with an implied 0 186 preceding bit 0. Note that dates cannot be produced by NTP, but can 187 rather be obtained from external means and conveyed via the protocol. 188 Date values are represented in twos compliment arithmetic relative to 189 the base date of 0628:16h 7 February 2036 UTC (when all 128 bits are 190 zero). Values greater than zero represent times after the base date; 191 values less than zero represent times before the base date. Dates 192 are signed values. Timestamps are signed values. A value of zero is 193 a special case representing unknown or unsynchronized time. 195 Figure 1 illustrates the three NTP time formats. 197 0 1 2 3 198 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 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 | Seconds | Fraction | 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 NTP Short Format 204 0 1 2 3 205 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 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | Seconds | 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 | Fraction | 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 NTP Timestamp Format 213 0 1 2 3 214 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 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 | Era Number | 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 | Era Offset | 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 | | 221 | Fraction | 222 | | 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 NTP Date Format 226 Figure 1: NTP Timestamp Format 228 Note that, since some time in 1968 (second 2,147,483,648) the most 229 significant bit (bit 0 of the integer part) has been set and that the 230 64-bit field will overflow some time in 2036 (second 4,294,967,296). 231 There will exist a 232-picosecond interval, henceforth ignored, every 232 136 years when the 64-bit field will be 0, which by convention is 233 interpreted as an invalid or unavailable timestamp. 235 If bit 0 is set, the UTC time is in the range 1968-2036 and UTC time 236 is reckoned from 0h 0m 0s UTC on 1 January 1900. If bit 0 is not 237 set, the time is in the range 2036-2104 and UTC time is calculated 238 from 6h 28m 16s UTC on 7 February 2036. Note that when calculating 239 the correspondence, 2000 is a leap year and leap seconds are not 240 included in the reckoning. 242 3. NTP Message Formats 244 Both NTP and SNTP are layered above the User Datagram Protocol (UDP) 245 [9], which itself is layered on the Internet Protocol (IP) [10] [3]. 246 The structure of the IP and UDP headers is described in the cited 247 specification documents and will not be detailed further here. The 248 UDP port number assigned to NTP is 123, which MUST be used in both 249 the Source Port and Destination Port fields in the UDP header. The 250 remaining UDP header fields should be set as described in the 251 specification. 253 Figure 2 provides a description of the NTPv4 message format. This 254 format is identical to that described in RFC 1305, with the exception 255 of the contents of the reference identifier field and optional 256 extension fields. The header fields are defined in Figure 2. 258 0 1 2 3 259 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 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 |LI | VN |Mode | Strat | Poll | Prec | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | Root Delay | 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | Root Dispersion | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | Reference ID | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 | | 270 + Reference Timestamp + 271 | | 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 | | 274 + Origin Timestamp + 275 | | 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 | | 278 + Receive Timestamp + 279 | | 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 | | 282 + Transmit Timestamp + 283 | | 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 | | 286 + Extension Field 1 (Optional) + 287 | | 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 | | 290 + Extension Field 2 (Optional) + 291 | | 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 . . 294 . Authentication . 295 . (Optional) (160 bits) . 296 . . 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 Figure 2: NTPv4 Message Format 301 3.1. Leap Indicator (LI) 303 This is a two-bit field indicating an impending leap second to be 304 inserted in the NTP timescale. The bits are set before 23:59 on the 305 day of insertion and reset after 00:00 on the following day. This 306 causes the number of seconds (rollover interval) in the day of 307 insertion to be increased or decreased by one. A leap second is 308 inserted or deleted in the timescale on the last day of June or 309 December. The possible values of the LI field, and corresponding 310 meanings, are given in Table 1. 312 +----+--------------------------------------------+ 313 | LI | Meaning | 314 +----+--------------------------------------------+ 315 | 0 | no warning | 316 | 1 | last minute of the day has 61 seconds | 317 | 2 | last minute of the day has 59 seconds | 318 | 3 | alarm condition (clock never synchronized) | 319 +----+--------------------------------------------+ 321 Table 1: Length Indicator Field Values 323 On startup, servers set this field to 3 (clock not synchronized) and 324 set this field to some other value when synchronized to the primary 325 reference clock. Once set to other than 3, the field is never set to 326 that value again, even if all synchronization sources become 327 unreachable or defective. 329 3.2. Version (VN) 331 This is a three-bit integer indicating the NTP/SNTP version number, 332 set to 4 for NTPv4. If necessary to distinguish between IPv4, IPv6 333 and OSI, the encapsulating context must be inspected. 335 3.3. Mode 337 This is a three-bit number indicating the protocol mode. The values 338 are defined in Table 2. 340 +------+--------------------------+ 341 | Mode | Meaning | 342 +------+--------------------------+ 343 | 0 | reserved | 344 | 1 | symmetric active | 345 | 2 | symmetric passive | 346 | 3 | client | 347 | 4 | server | 348 | 5 | broadcast | 349 | 6 | NTP control message | 350 | 7 | reserved for private use | 351 +------+--------------------------+ 353 Table 2: Mode Field Values 355 Mode 0 is reserved. Modes 1 and 2 are intended for use by symmetric 356 peers who set this mode to 1 or 2 depending on whether it is active 357 or passive mode. In unicast mode or discovery mode, the client sets 358 this field to 3 (client) in the request and the server sets it to 4 359 (server) in the reply. In broadcast mode, the server sets this field 360 to 5 (broadcast). A mode type of 6 is reserved for NTP control 361 messages. Mode 7 is reserved for private usage. 363 3.4. Stratum (Strat) 365 This is a eight-bit unsigned integer indicating the stratum. This 366 field is significant only in SNTP server messages, where the values 367 are defined in Table 3. 369 +---------+-------------------------------------------------------+ 370 | Stratum | Meaning | 371 +---------+-------------------------------------------------------+ 372 | 0 | kiss-o'-death message | 373 | 1 | primary reference (e.g., synchronized by radio clock) | 374 | 2-255 | secondary reference (synchronized by NTP or SNTP) | 375 +---------+-------------------------------------------------------+ 377 Table 3: Stratum Field Values 379 3.5. Poll Interval (Poll) 381 This is an eight-bit unsigned integer indicating the maximum interval 382 between successive messages, in log2 seconds. A client SHOULD NOT 383 use a poll interval less than 15 seconds, except at initial startup 384 when it MAY send a sequence of 8 packets at 1 second intervals to 385 provide initial synchronization of the clients with each server. A 386 client SHOULD increase the poll interval as performance permits and 387 especially if the server does not respond within a reasonable time. 389 3.6. Precision (Prec) 391 This is an eight-bit signed integer indicating the precision of the 392 system clock in log2 seconds. Precision is normally determined when 393 the service is established as the minimum number of iterations of the 394 time to read the system clock. As an example, a value of -18 395 corresponds to a precision of about one microsecond. 397 3.7. Root Delay 399 This is a 32-bit signed fixed-point number indicating the total 400 roundtrip delay to the primary reference source, in 32-bit NTP short 401 format. Note that this variable can take on both positive and 402 negative values, depending on the relative time and frequency 403 offsets. This field is significant only in server messages, where 404 the values range from negative values of a few milliseconds to 405 positive values of several hundred milliseconds. 407 3.8. Root Dispersion 409 This is a 32-bit unsigned fixed-point number indicating the nominal 410 error relative to the primary reference source in seconds, in 32-bit 411 NTP short format. 413 3.9. Reference Identifier 415 This is a 32-bit bitstring identifying the particular reference 416 source. The interpretation of this field depends on the value in the 417 stratum field. For stratum 0, this is a four-character ASCII string, 418 referred to as a 'kiss code' and is used for debugging and monitoring 419 purposes. For stratum 1, this is a four-octet, left-justified, zero- 420 padded ASCII string assigned to the reference source. Above stratum 421 1 (secondary servers and clients), this is the reference identifier 422 of the server. If employing IPv4, the value is the 32-bit IPv4 423 address of the synchronization source. For IPv6 and OSI, the value 424 is the first 32 bits of the MD5 hash of the IPv6 or NSAP address of 425 the synchronization source. The fASCII identifiers that are 426 currently defined are given in Table 4. 428 Primary (stratum 1) servers set this field to a code identifying the 429 external reference source according to Table 4. 431 +-------+----------------------------------------------------+ 432 | Code | External Reference Source | 433 +-------+----------------------------------------------------+ 434 | GOES | Geosynchronous Orbit Environment Satellite | 435 | GPS | Global Position System | 436 | PPS | Generic pulse-per-second | 437 | IRIG | Inter-Range Instrumentation Group | 438 | WWVB | LF Radio WWVB Ft. Collins, CO 60 kHz | 439 | DCF77 | LF Radio DCF77 Mainflingen, DE 77.5 kHz | 440 | HBG | LF Radio HBG Prangins, HB 75 kHz | 441 | MSF | LF Radio MSF Rugby, UK 60 kHz | 442 | JJY | LF Radio JJY Fukushima, JP 40 kHz, Saga, JP 60 kHz | 443 | LORC | MF Radio LORAN C 100 kHz | 444 | TDF | MF Radio Allouis, FR 162 kHz | 445 | CHU | HF Radio CHU Ottawa, Ontario | 446 | WWV | HF Radio WWV Ft. Collins, CO | 447 | WWVH | HF Radio WWVH Kauai, HI | 448 | NIST | NIST telephone modem | 449 | USNO | USNO telephone modem | 450 | PTB | European telephone modem | 451 +-------+----------------------------------------------------+ 453 Table 4: Currently-defined Reference Identifiers 455 If the external reference is one of those listed, the associated code 456 should be used. Codes for sources not listed can be created as 457 appropriate (see IANA Considerations section of this document). 459 3.10. Reference Timestamp 461 This is a 64 bit signed integer indicating the time when the system 462 clock was last set or correctetd, in 64-bit NTP timestamp format. 464 3.11. Originate Timestamp 466 This is the time at which the request departed the client for the 467 server, in 64-bit NTP timestamp format. 469 3.12. Receive Timestamp 471 This is the time at which the request arrived at the server or the 472 reply arrived at the client, in 64-bit NTP timestamp format. 474 3.13. Transmit Timestamp 476 This is the time at which the request departed the client or the 477 reply departed the server, in 64-bit NTP timestamp format. 479 3.14. NTPv4 Extension Fields 481 NTPv4 defines new extension field formats. The minimum extension 482 field length is 8 octets. The format of the NTP extension field is 483 given in Figure Figure 3. 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 Figure 3: NTP Extension Field Format 513 The Field Type field is a 16-bit integer which indicates the type of 514 extension message contained within the extension field. 516 The Length field is a 16-bit integer indicates the length of the 517 entire extension field in octets, including the Length and Padding 518 fields. 520 The 32-bit Association ID field is set by clients to the value 521 previously received from the server or 0 otherwise. The server sets 522 the Association ID field when sending a response as a handle for 523 subsequent exchanges. If the association ID value in a request does 524 not match the association ID of any association, the server returns 525 the request with the first two bits of the Field Type field set to 1. 527 The Timestamp and Filestamp 32-bit fields carry the seconds field of 528 an NTP timestamp. The Timestamp field establishes the signature 529 epoch of the data field in the message, while the filestamp 530 establishes the generation epoch of the file that ultimately produced 531 the data. 533 The 32-bit Value Length field indicates the length of the Value field 534 in octets. The minimum length of the Value field is 0. 536 The 32-bit Signature Length field indicates the length of the 537 Signature field in octets. 539 Zero padding is applied, as necessary, to extend the extension field 540 to a word (4-octet) boundary. If multiple extension fields are 541 present, the last extension field is zero-padded to a double-word (8 542 octet) boundary. 544 3.15. Authentication (optional) 546 NTPv4 provides an optional 160-bit Authentication field. When 547 implemented, the 32-bit Key Identifier and 128-bit Message Digest 548 fields contain the Message Authentication Code (MAC) information 549 which uses an MD5 cryptosum of NTP header plus extension fields. The 550 authentication field format is shown in Figure Figure 4. 551 0 1 2 3 552 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 553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 554 | Key Identifier | 555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 556 | | 557 + + 558 | | 559 + Message Digest + 560 | | 561 + + 562 | | 563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 Figure 4: NTP Authentication Field 567 The 32-bit Key Identifier is an integer identifying the 128-bit 568 private key used to generate the MAC. The Message Digest field 569 contains the MD5 Message Digest. In NTPv4, the presence of one or 570 more extension fields requires the presence of an authentication 571 field. The presence of the Authentication field and extension fields 572 is determined from the Length field. 574 The Key Identifier is initialized to zero at the start of an 575 association. The type of association then determines the key 576 identifier. If the association is active (modes 1, 3, 5) the key is 577 determined from the system key identifier. If the association is 578 passive (modes 2, 4) the key is determined from the peer key 579 identifier, if the authentic bit is set (see [1]), or as the default 580 key (zero) otherwise. 582 4. NTP Protocol Operation 584 The NTP protocol defines three operational roles, Client, Server, and 585 Symmetric Peer. Clients request or receive time from Servers 586 (solicited or unsolicited). Servers respond to requests or send 587 periodic time updates to Clients. Symmetric Peers exchange time data 588 bidirectionally. A given NTPv4 implementation can operate in any or 589 all of these modes. 591 NTP messages make use of two different communication modes, one to 592 one and one to many, commonly referred to as unicast and broadcast. 593 For the purposes of this document, the term broadcast is interpreted 594 to mean any available one to many mechanism. For IPv4 this equates 595 to either IPv4 broadcast or IPv4 multicast. For IPv6 this equates to 596 IPv6 multicast. For this purpose, IANA has allocated the IPv4 597 multicast address 224.0.1.1 and the IPv6 multicast address ending 598 :101, with prefix determined by scoping rules. 600 Except in broadcast mode, an NTP association is formed when two peers 601 exchange messages and one or both of them create and maintain an 602 instantiation of the protocol machine, called an association. The 603 association can operate in one of five modes as indicated by the 604 host- mode variable (peer.mode) (see [1] for a description of the NTP 605 variables): symmetric active, symmetric passive, client, server and 606 broadcast, which are defined as follows: 608 Symmetric Active (1): A host operating in this mode sends periodic 609 messages regardless of the reachability state or stratum of its peer. 610 By operating in this mode the host announces its willingness to 611 synchronize and be synchronized by the peer. 613 Symmetric Passive (2): This type of association is ordinarily created 614 upon arrival of a message from a peer operating in the symmetric 615 active mode and persists only as long as the peer is reachable and 616 operating at a stratum level less than or equal to the host; 617 otherwise, the association is dissolved. However, the association 618 will always persist until at least one message has been sent in 619 reply. By operating in this mode the host announces its willingness 620 to synchronize and be synchronized by the peer. 622 Client (3): A host operating in this mode sends periodic messages 623 regardless of the reachability state or stratum of its peer. By 624 operating in this mode the host announces its willingness to be 625 synchronized by, but not to synchronize the peer. 627 Server (4): This type of association is ordinarily created upon 628 arrival of a client request message and exists only in order to reply 629 to that request, after which the association is dissolved. By 630 operating in this mode the host announces its willingness to 631 synchronize, but not to be synchronized by the peer. 633 Broadcast (5): A host operating in this mode sends periodic messages 634 regardless of the reachability state or stratum of the peers. By 635 operating in this mode the host announces its willingness to 636 synchronize all of the peers, but not to be synchronized by any of 637 them. 639 NTP messages are layered on top of UDP. All messages MUST be sent 640 with a destination port of 123, and SHOULD be sent with a source port 641 of 123. 643 The on-wire protocol uses four timestamps numbered T1 through T4 and 644 three state variables org, rec, and xmt, as shown in Figure Figure 5, 645 where T1 corresponds to the Reference Timestamp T2 corresponds to the 646 Originate Timestamp, T3 corresponds to the Receive Timestamp, and T4 647 corresponds to the Transmit Timestamp. 649 t2 t3 t6 t7 650 +---------+ +---------+ +---------+ +---------+ 651 T1 | 0 | | t2 | | t4 | | t6 | 652 +---------+ +---------+ +---------+ +---------+ 653 T2 | 0 | | t1 | | t3 | | t5 | Packet 654 +---------+ +---------+ +---------+ +---------+ Variables 655 T3 |t2=clock | | t2 | |t6=clock | | t6 | 656 +---------+ +---------+ +---------+ +---------+ 657 T4 | t1 | |t3=clock | | t5 | |t7=clock | 658 +---------+ +---------+ +---------+ +---------+ 659 Peer B 660 +---------+ +---------+ +---------+ +---------+ 661 org | t1 | | t1 | | T3<>t1? | | t5 | 662 +---------+ +---------+ +---------+ +---------+ State 663 rec | t2 | | t2 | | t6 | | t6 | Variables 664 +---------+ +---------+ +---------+ +---------+ 665 xmt | 0 | | t3 | | T1<>t3? | | t7 | 666 +---------+ +---------+ +---------+ +---------+ 668 t2 t3 t6 t7 669 --------------------------------------------------------- 670 /\ \ /\ \ 671 / \ / \ 672 / \ / \ 673 / \/ / \/ 674 --------------------------------------------------------- 675 t1 t4 t5 t8 677 t1 t4 t5 t8 678 +---------+ +---------+ +---------+ +---------+ 679 T1 | 0 | | t2 | | t4 | | t6 | 680 +---------+ +---------+ +---------+ +---------+ 681 T2 | 0 | | t1 | | t3 | | t5 | Packet 682 +---------+ +---------+ +---------+ +---------+ Variables 683 T3 | 0 | |t4=clock | | t4 | |t8=clock | 684 +---------+ +---------+ +---------+ +---------+ 685 T4 |t1=clock | | t3 | |t5=clock | | t7 | 686 +---------+ +---------+ +---------+ +---------+ 687 Peer A 688 +---------+ +---------+ +---------+ +---------+ 689 org | 0 | | T3<>0? | | t3 | | T3<>t3? | 690 +---------+ +---------+ +---------+ +---------+ State 691 rec | 0 | | t4 | | t4 | | t8 | Variables 692 +---------+ +---------+ +---------+ +---------+ 693 xmt | t1 | | T1=t1? | | t5 | | T1<>t5? | 694 +---------+ +---------+ +---------+ +---------+ 696 Figure 5: NTPState 697 This figure shows the most general case, where each of two peers, A 698 and B, independently measure the offset and delay relative to the 699 other. For illustrative purposes, the individual timestamp values 700 are shown in lower case with subscripts indicating the order of 701 transmission and reception. In the figure, the first packet 702 transmitted by A contains only the transmit timestamp T4 with value 703 t1. B receives the packet at t2 and saves the originate timestamp T2 704 with value t1 in state variable org and the receive timestamp T3 with 705 value t2 in state variable rec. Afterwards, B sends a packet to A 706 containing the org and rec state variables in T2 and T1 respectively 707 and additionally the transmit timestamp T4 with value t3, which is 708 saved in the xmt state variable. When this packet arrives at A the 709 packet header variables T1, T2, T3, and T4 represent the four 710 timestampes necessary to compute the offset and delay of B relative 711 to A. 713 Before the A state variables are updated, two sanity checks are 714 performed in order to protect against duplicate or invalid packets. 715 A packet is a duplicate if the transmit timestamp T4 in the packet 716 matches the xmt state variable. A packet is invalid if the origin 717 timestamp T2 in the packet does not match the org state variable. In 718 either of these cases the state variables are updated, but the packet 719 is discarded. 721 The general rules that govern the updating of state variables and 722 packet variables are given in Figure 6. 723 +-------------------------------------------------------+ 724 | Receive | Transmit | 725 +-------------------------------------------------------+ 726 | org=T4 | org=unchanged | 727 | rec=Time of Receipt | rec=unchanged | 728 | xmt=unchanged | xmt=Time of transmission | 729 | | | 730 | T1=Received T3 | T1=rcv | 731 | T2=Received T2 | T2=org | 732 | T3=rec | T3=unchanged | 733 | T4=Received T4 | T4=xmt | 734 +-------------------------------------------------------+ 736 Figure 6: Relationship between NTP State Variables and NTP Packet 737 Variables 739 5. SNTP Protocol Operation 741 SNTP operates using the same message formats, addresses, and ports as 742 NTP. However, it is stateless, operating only in the client or 743 server roles. Thus it is compatible with, and a subset of, NTP. 745 6. NTP Server Operations 747 Fundamentally, the NTP Server role consists of listening for client 748 requests, and providing time and associated details as a response. 749 Additionally, a server can provide time and associated details 750 periodically via a broadcast mechanism. 752 An NTP server can communicate via unicast, broadcast, or both. A 753 server receiving a unicast request (NTP mode 3), modifies fields in 754 the NTP header as described below, and sends a reply (NTP mode 4), 755 possibly using the same message buffer as the request. When 756 operating in a broadcast mode, unsolicited messages (NTP mode 5) with 757 field values as described below are normally sent at intervals 758 ranging from 64 s to 1024 s, depending on the expected frequency 759 tolerance of the client clocks and the required accuracy. 761 A broadcast server may or may not send messages if not synchronized 762 to a correctly operating source, but the preferred option is to 763 transmit, since this allows reachability to be determined regardless 764 of synchronization state. 766 The Leap Indicator (LI) is set to 3 (unsynchronized) if the server 767 has never synchronized to a reference source. Once synchronized, the 768 LI field is set to one of the other three values and remains at the 769 last value set even if the reference source becomes unreachable or 770 turns faulty. 772 The Version (VN) is copied from the request packet, if responding to 773 a unicast request. For broadcast, this is set to 4. 775 The Mode is set to Server (4) if in response to a unicast request. 776 For broadcast, this is set to Broadcast (5). 778 The Stratum field is set to the server's current stratum, if 779 synchronized. If synchronized to a primary reference source the 780 Stratum field is set to 1. If unsynchronized this field is set to 0. 782 The Poll field is coppied from the request, if responding to a 783 unicast request. For broadcast, this is set to the nearest integer 784 log2 of the poll interval. 786 The Precision field is set to reflect the maximum reading error of 787 the system clock. The Root Delay and Root Dispersion fields are set 788 to 0 for a primary server; optionally, the Root Dispersion field can 789 be set to a value corresponding to the maximum error of the radio 790 clock itself. 792 If the server is synchronized to a reference source, the value of the 793 Reference ID is set to a four-character ASCII string identifying the 794 source, left justified and zero padded to 32bits. For IPv4 secondary 795 servers,the value is the 32-bit IPv4 address of the synchronization 796 source. For IPv6 and OSI secondary servers, the value is the first 797 32 bits of the MD5 hash of the IPv6 or NSAP address of the 798 synchronization source. If unsynchronized, it is set to an ASCII 799 error identifier. 801 The timestamp fields in the server message are set as follows. If 802 the server is unsynchronized or first coming up, all timestamp fields 803 are set to zero with one exception. If the server is synchronized, 804 the Transmit Timestamp field of the request is copied unchanged to 805 the Originate Timestamp field of the reply. 807 If the server is synchronized, the Reference Timestamp is set to the 808 time the last update was received from the reference source. The 809 Originate Timestamp field is set as in the unsynchronized case above. 810 The Transmit Timestamp field is set to the time of day when the 811 message is sent. In broadcast messages the Receive Timestamp field 812 is set to zero and copied from the Transmit Timestamp field in other 813 messages. 815 Table 5 summarizes these actions. 817 +---------------+-----------+-------------------+-------------------+ 818 | Field Name | Unicast | Unicast Reply | Broadcast | 819 | | Request | | | 820 +---------------+-----------+-------------------+-------------------+ 821 | LI | ignore | as needed | as needed | 822 | VN | 1-4 | copied from | 4 | 823 | | | request | | 824 | Mode | 1 or 3 | 2 or 4 | 5 | 825 | Stratum | ignore | 1 | 1 | 826 | Poll | ignore | copied from | log2 poll | 827 | | | request | interval | 828 | Precision | ignore | -log2 server | -log2 server | 829 | | | significant bits | significant bits | 830 | Root Delay | ignore | 0 | 0 | 831 | Root | ignore | 0 | 0 | 832 | Dispersion | | | | 833 | Reference | ignore | source ident | source ident | 834 | Identifier | | | | 835 | Reference | ignore | time of last src. | time of last src. | 836 | Timestamp | | update | update | 837 | Originate | ignore | copied from xmit | 0 | 838 | Timestamp | | timestamp | | 839 | Receive | ignore | time of day | 0 | 840 | Timestamp | | | | 841 | Transmit | (see | time of day | time of day | 842 | Timestamp | text) | | | 843 | Authenticator | optional | optional | optional | 844 +---------------+-----------+-------------------+-------------------+ 846 Table 5: NTP Server Message Field Population 848 Broadcast servers should respond to client unicast requests, as 849 well as send unsolicited broadcast messages. Broadcast clients 850 may send unicast requests in order to measure the network 851 propagation delay between the server and client and then continue 852 operation in listen-only mode. However, broadcast servers may 853 choose not to respond to unicast requests, so unicast clients 854 should be prepared to abandon the measurement and assume a default 855 value for the delay. 857 7. NTP Client Operations 859 The role of an NTP client is to determine the current time (and 860 associated information) from an NTP server. This can be done 861 actively, by sending a unicast request to a configured server, or 862 passively by listening on a known address for periodic server 863 messages. 865 An NTP client can operate in unicast or broadcast modes. In unicast 866 mode the client sends a request (NTP mode 3) to a designated unicast 867 server and expects a reply (NTP mode 4) from that server. In 868 broadcast client mode it sends no request and waits for a broadcast 869 (NTP mode 5) from one or more broadcast servers. 871 A unicast client initializes the NTP message header, sends the 872 request to the server and strips the time of day from the Transmit 873 Timestamp field of the reply. For this purpose, all of the NTP 874 header fields shown in Section 3 are set to 0, except the Mode, VN 875 and optional Transmit Timestamp fields. 877 NTP and SNTP clients set the mode field to 3 (client) for unicast 878 requests. They set the VN field to any version number supported by 879 the server selected by configuration or discovery and can 880 interoperate with all previous version NTP and SNTP servers. Servers 881 reply with the same version as the request, so the VN field of the 882 request also specifies the VN field of the reply. An NTP client can 883 specify the earliest acceptable version on the expectation that any 884 server of that or later version will respond. NTPv4 servers are 885 backwards compatible with NTPv3 as defined in RFC 1305, NTPv2 as 886 defined in [11], and NTPv1 as defined in [12]. NTPv0 defined in [13] 887 is not supported. 889 In unicast mode, the Transmit Timestamp field in the request SHOULD 890 be set to the time of day according to the client clock in NTP 891 timestamp format. This allows for the determination of the 892 propagation delay between the server and client and to align the 893 system clock relative to the server. In addition, this provides a 894 simple method to verify that the server reply is in fact a legitimate 895 response to the specific client request and avoid replays. Note that 896 in broadcast mode, the client cannot necessarily calculate the 897 propagation delay or determine the validity of the server. 899 There is some latitude on the part of most clients to forgive invalid 900 timestamps, such as might occur when first coming up or during 901 periods when the reference source is inoperative. The most important 902 indicator of an unhealthy server is the Stratum field, in which a 903 value of 0 indicates an unsynchronized condition. When this value is 904 displayed, clients should discard the server message, regardless of 905 the contents of other fields. 907 Table 6 summarizes the required NTP client operations in unicast and 908 broadcast modes 910 +-------------------+---------------+-------------------+-----------+ 911 | Field Name | Unicast | Unicast Reply | Broadcast | 912 | | Request | | | 913 +-------------------+---------------+-------------------+-----------+ 914 | LI | 0 | 0-3 | 0-3 | 915 | VN | 1-4 | copied from | 1-4 | 916 | | | request | | 917 | Mode | 1 or 3 | 2 or 4 | 5 | 918 | Stratum | 0 | 0-15 | 0-15 | 919 | Poll | 0 | ignore | ignore | 920 | Precision | 0 | ignore | ignore | 921 | Root Delay | 0 | ignore | ignore | 922 | Root Dispersion | 0 | ignore | ignore | 923 | Reference | 0 | ignore | ignore | 924 | Identifier | | | | 925 | Reference | 0 | ignore | ignore | 926 | Timestamp | | | | 927 | Originate | 0 | (see text) | ignore | 928 | Timestamp | | | | 929 | Receive Timestamp | 0 | (see text) | ignore | 930 | Transmit | (see text) | nonzero | nonzero | 931 | Timestamp | | | | 932 | Authenticator | optional | optional | optional | 933 +-------------------+---------------+-------------------+-----------+ 935 Table 6: NTP Client Message Field Population 937 8. NTP Symmetric Peer Operations 939 NTP Symmetric Peer mode is intended for configurations where a set of 940 low-stratum peers operate as mutual backups for each other. Each 941 peer normally operates with one or more sources, such as a reference 942 clock, or a subset of primary or secondry servers known to be 943 reliable or authentic. 945 Symmetric Peer mode is exclusive to the NTP protocol and is 946 specifically excluded from SNTP operation. For the purposes of this 947 document, an NTP peer operates like a client. 949 9. Dynamic Server Discovery 951 NTPv4 provides a mechanism, commonly known as "Manycast", for a 952 client to dynamically discover the existance of one or more servers 953 with no a-priori knowledge. Once servers are discovered, they are 954 then treated as any other unicast server. 956 A client employing server discovery is configured with MinServers, 957 the minimum number of desired servers and MaxServers, the maximum 958 number of desired servers. The discovery mechanism is a simple 959 expanding ring search, using IP multicast with increasing TTLs or Hop 960 Counts. The multicast address used MUST be scoped to the local site, 961 as defined by [14]. 963 The client initiates the discovery process by sending an NTP message 964 to the configured multicast address (224.0.1.1 for IPv4 and a 965 multicast address ending :101 for IPv6 with proper scoping.) with an 966 IP TTL or Hop Count of 1. This message has all of the NTP header 967 fields set to 0, except the Mode, VN and optional Transmit Timestamp 968 fields. The Mode is set to 3. It then starts a retry timer 969 (Default: 64 seconds) and listens for unicast responses from servers. 970 The source address of any server responses are treated as newly 971 configured unicast servers, up to a limit of MaxServers. If the 972 number of discovered servers is less than MinServers when the retry 973 timer expires, an identical NTP message is sent with an increased 974 TTL/Hop Count, and the retry timer is restarted. This continues 975 until either MinServers servers have been discovered or a configured 976 maximum TTL/Hop Count is reached. If the configured maximum TTL/Hop 977 Count is reached, packets continue to be periodically sent at the 978 maximum TTL/Hop Count. If at some subsequent time, the number of 979 valid servers drops below MinServers, the process restarts at the 980 initial state. 982 A server configured to provide server discovery will listen on the 983 specified multicast address for discovery messages from clients. If 984 the server is in scope of the current TTL and is itself synchronized 985 to a valid source it replies to the discovery message from the client 986 with an ordinary unicast server message as described in Section 6 988 10. The Kiss-o'-Death Packet 990 According to the NTPv3 specification [1], if the Stratum field in the 991 NTP header is 1, indicating a primary server, the Reference 992 Identifier field contains an ASCII string identifying the particular 993 reference clock type. However, in [1] nothing is said about the 994 Reference Identifier field if the Stratum field is 0, which is called 995 out as "unspecified". However, if the Stratum field is 0, the 996 Reference Identifier field can be used to convey messages useful for 997 status reporting and access control. In NTPv4 and SNTPv4, packets of 998 this kind are called Kiss-o'-Death (KoD) packets and the ASCII 999 messages they convey are called kiss codes. The KoD packets got 1000 their name because an early use was to tell clients to stop sending 1001 packets that violate server access controls. 1003 The kiss codes can provide useful information for an intelligent 1004 client. These codes are encoded in four-character ASCII strings left 1005 justified and zero filled. The strings are designed for character 1006 displays and log files. A list of the currently-defined kiss codes 1007 is given in Table 7. 1009 +------+------------------------------------------------------------+ 1010 | Code | Meaning | 1011 +------+------------------------------------------------------------+ 1012 | ACST | The association belongs to a unicast server | 1013 | AUTH | Server authentication failed | 1014 | AUTO | Autokey sequence failed | 1015 | BCST | The association belongs to a broadcast server | 1016 | CRYP | Cryptographic authentication or identification failed | 1017 | DENY | Access denied by remote server | 1018 | DROP | Lost peer in symmetric mode | 1019 | RSTR | Access denied due to local policy | 1020 | INIT | The association has not yet synchronized for the first | 1021 | | time | 1022 | MCST | The association belongs to a dynamically discovered server | 1023 | NKEY | No key found. Either the key was never installed or is | 1024 | | not trusted | 1025 | RATE | Rate exceeded. The server has temporarily denied access | 1026 | | because the client exceeded the rate threshold | 1027 | RMOT | Alteration of association from a remote host running | 1028 | | ntpdc. | 1029 | STEP | A step change in system time has occurred, but the | 1030 | | association has not yet resynchronized | 1031 +------+------------------------------------------------------------+ 1033 Table 7: Currently-defined NTP Kiss Codes 1035 In general, an NTP client should stop sending to a particular server 1036 if that server returns a reply with a Stratum field of 0, regardless 1037 of kiss code, and an alternate server is available. If no alternate 1038 server is available, the client SHOULD increase the poll interval as 1039 performance permits. 1041 11. Security Considerations 1043 NTPv4 provides an optional authentication field that utilizes the MD5 1044 algorithm. MD5, as the case for SHA-1, is derived from MD4, which 1045 has long been known to be weak. In 2004, techniques for efficiently 1046 finding collisions in MD5 were announced. A summary of the weakness 1047 of MD5 can be found in [15]. 1049 In the case of NTP as specified herein, there is a vulnerability that 1050 NTP broadcast clients can be disrupted by misbehaving or hostile SNTP 1051 or NTP broadcast servers elsewhere in the Internet. Access controls 1052 and/or cryptographic authentication means should be provided for 1053 additional security in such cases. 1055 While not required in a conforming NTP client implementation, there 1056 are a variety of recommended checks that an NTP client can perform 1057 that are designed to avoid various types of abuse that might happen 1058 as the result of server implementation errors or malicious attack. 1059 These recommended checks are as follows: 1061 When the IP source and destination addresses are available for the 1062 client request, they should match the interchanged addresses in 1063 the server reply. 1065 When the UDP source and destination ports are available for the 1066 client request, they should match the interchanged ports in the 1067 server reply. 1069 The Originate Timestamp in the server reply should match the 1070 Transmit Timestamp used in the client request. 1072 A client can check the Root Delay and Root Dispersion fields are 1073 each greater than or equal to 0 and less than infinity, where 1074 infinity is is on the order of 15-20 seconds. This check avoids 1075 using a server whose synchronization source has expired for a very 1076 long time. 1078 12. IANA Considerations 1080 UDP/TCP Port 123 was previously assigned by IANA for this protocol. 1081 The IANA has assigned the IPv4 multicast group address 224.0.1.1 and 1082 the IPv6 multicast address ending :101 for NTP. 1084 This document identifies the set of defined 4-character (ASCII) 1085 Reference Identifier values. This document also defines the set of 1086 defined Kiss Codes. This document also introduces NTP extension 1087 fields allowing for the development of future extensions to the 1088 protocol, where a particular extension is to be identified by the 1089 Field Type sub-field within the extension field. 1091 IANA is requested to establish and maintain a registry for Reference 1092 Identifiers, Kiss codes, and Extension Field Types associated with 1093 this protocol, populating this registry from the Reference 1094 Identifiers given in Section 3.9 and Kiss Codes given in Section 11 1095 as the initial entries. The Extension Field Types registry will have 1096 no initial entries. As future needs arise, new Reference 1097 Identifiers, Kiss Codes, and Extension Field Types may be defined. 1098 Following the policies outlined in [16], new values are to be defined 1099 by IETF Consensus. 1101 13. Acknowledgements 1103 This document has drawn material from RFC 4330, "Simple Network Time 1104 Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI." As a result, the 1105 authors would like to acknowledge D. Plonka of the University of 1106 Wisconsin and J. Montgomery of Netgear, who were contributors. The 1107 authors would also like to thank B. Haberman for providing rigorous 1108 reviews of this document. 1110 14. References 1112 14.1. Normative References 1114 [1] Mills, D., "Network Time Protocol (Version 3) Specification, 1115 Implementation", RFC 1305, March 1992. 1117 14.2. Informative References 1119 [2] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 for 1120 IPv4, IPv6 and OSI", RFC 4330, January 2006. 1122 [3] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 1123 Specification", RFC 2460, December 1998. 1125 [4] Colella, R., Callon, R., Gardner, E., and Y. Rekhter, 1126 "Guidelines for OSI NSAP Allocation in the Internet", RFC 1629, 1127 May 1994. 1129 [5] International Standards Organization, "International Standards 1130 8602 - Information Processing Systems - OSI: Connectionless 1131 Transport Protocol Specification.", NDSS , December 1986. 1133 [6] Shue, C., Haggerty, W., and K. Dobbins, "OSI connectionless 1134 transport services on top of UDP: Version 1", RFC 1240, 1135 June 1991. 1137 [7] Furniss, P., "Octet Sequences for Upper-Layer OSI to Support 1138 Basic Communications Applications", RFC 1698, October 1994. 1140 [8] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1141 Levels", BCP 14, RFC 2119, March 1997. 1143 [9] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1144 August 1980. 1146 [10] Postel, J., "Internet Protocol", STD 5, RFC 791, 1147 September 1981. 1149 [11] Mills, D., "Network Time Protocol (version 2) specification and 1150 implementation", STD 12, RFC 1119, September 1989. 1152 [12] Mills, D., "Network Time Protocol (version 1) specification and 1153 implementation", RFC 1059, July 1988. 1155 [13] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, 1156 RFC 959, October 1985. 1158 [14] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, 1159 RFC 2365, July 1998. 1161 [15] Bellovin, S. and E. Rescorla, "Deploying a New Hash Algorithm", 1162 Proceedings of the 13th Annual ISOC Network and Distributed 1163 System Security Symposium (NDSS) , February 2006. 1165 [16] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 1166 Considerations Section in RFCs", BCP 26, RFC 2434, 1167 October 1998. 1169 Appendix A. NTP Control Messages 1171 In a comprehensive network-management environment, facilities are 1172 presumed available to perform routine NTP control and monitoring 1173 functions, such as setting the leap-indicator bits at the primary 1174 servers, adjusting the various system parameters and monitoring 1175 regular operations. Ordinarily, these functions can be implemented 1176 using a network-management protocol such as SNMP and suitable 1177 extensions to the MIB database. However, in those cases where such 1178 facilities are not available, these functions can be implemented 1179 using special NTP control messages described herein. These messages 1180 are intended for use only in systems where no other management 1181 facilities are available or appropriate, such as in dedicated- 1182 function bus peripherals. Support for these messages is not required 1183 in order to conform to this specification. 1185 The NTP Control Message has the value 6 specified in the mode field 1186 of the first octet of the NTP header and is formatted as shown in 1187 Section 10.1. The format of the data field is specific to each 1188 command or response; however, in most cases the format is designed to 1189 be constructed and viewed by humans and so is coded in free-form 1190 ASCII. This facilitates the specification and implementation of 1191 simple management tools in the absence of fully evolved network- 1192 management facilities. As in ordinary NTP messages, the 1193 authenticator field follows the data field. If the authenticator is 1194 used the data field is zero-padded to a 32-bit boundary, but the 1195 padding bits are not considered part of the data field and are not 1196 included in the field count. 1198 IP hosts are not required to reassemble datagrams larger than 576 1199 octets; however, some commands or responses may involve more data 1200 than will fit into a single datagram. Accordingly, a simple 1201 reassembly feature is included in which each octet of the message 1202 data is numbered starting with zero. As each fragment is transmitted 1203 the number of its first octet is inserted in the offset field and the 1204 number of octets is inserted in the count field. The more-data (M) 1205 bit is set in all fragments except the last. 1207 Most control functions involve sending a command and receiving a 1208 response, perhaps involving several fragments. The sender chooses a 1209 distinct, nonzero sequence number and sets the status field and R and 1210 E bits to zero. The responder interprets the opcode and additional 1211 information in the data field, updates the status field, sets the R 1212 bit to one and returns the three 32-bit words of the header along 1213 with additional information in the data field. In case of invalid 1214 message format or contents the responder inserts a code in the status 1215 field, sets the R and E bits to one and, optionally, inserts a 1216 diagnostic message in the data field. 1218 Some commands read or write system variables and peer variables for 1219 an association identified in the command. Others read or write 1220 variables associated with a radio clock or other device directly 1221 connected to a source of primary synchronization information. To 1222 identify which type of variable and association a 16-bit association 1223 identifier is used. System variables are indicated by the identifier 1224 zero. As each association is mobilized a unique, nonzero identifier 1225 is created for it. These identifiers are used in a cyclic fashion, 1226 so that the chance of using an old identifier which matches a newly 1227 created association is remote. A management entity can request a 1228 list of current identifiers and subsequently use them to read and 1229 write variables for each association. An attempt to use an expired 1230 identifier results in an exception response, following which the list 1231 can be requested again. 1233 Some exception events, such as when a peer becomes reachable or 1234 unreachable, occur spontaneously and are not necessarily associated 1235 with a command. An implementation may elect to save the event 1236 information for later retrieval or to send an asynchronous response 1237 (called a trap) or both. In case of a trap the IP address and port 1238 number is determined by a previous command and the sequence field is 1239 set as described below. Current status and summary information for 1240 the latest exception event is returned in all normal responses. Bits 1241 in the status field indicate whether an exception has occurred since 1242 the last response and whether more than one exception has occurred. 1244 Commands need not necessarily be sent by an NTP peer, so ordinary 1245 access-control procedures may not apply; however, the optional mask/ 1246 match mechanism suggested elsewhere in this document provides the 1247 capability to control access by mode number, so this could be used to 1248 limit access for control messages (mode 6) to selected address 1249 ranges. 1251 A.1. NTP Control Message Format 1253 The format of the NTP Control Message header, which immediately 1254 follows the UDP header, is shown in Figure 7. Following is a 1255 description of its fields. Bit positions marked as zero are reserved 1256 and should always be transmitted as zero. 1258 0 1 2 3 1259 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 1260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1261 |00 | VN | 6 | REM | Op | Sequence | 1262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1263 | Status | Association ID | 1264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1265 | Offset | Count | 1266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1267 . . 1268 . Data (468 Octets Max) . 1269 . . 1270 | | Padding (zeros) | 1271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1272 | Authenticator (optional)(96) | 1273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1275 Figure 7: NTP Control Message Format 1277 Version Number (VN): This is a three-bit integer indicating the NTP 1278 version number, currently four (4) 1280 Mode: This is a three-bit integer indicating the mode. It must have 1281 the value 6, indicating an NTP control message. 1283 Response Bit (R): Set to zero for commands, one for responses. 1285 Error Bit (E): Set to zero for normal response, one for error 1286 response. 1288 More Bit (M): Set to zero for last fragment, one for all others. 1290 Operation Code (Op): This is a five-bit integer specifying the 1291 command function. Values currently defined are given in Table 8. 1293 +-------+----------------------------------------+ 1294 | Value | Meaning | 1295 +-------+----------------------------------------+ 1296 | 0 | reserved | 1297 | 1 | read status command/response | 1298 | 2 | read variables command/response | 1299 | 3 | write variables command/response | 1300 | 4 | read clock variables command/response | 1301 | 5 | write clock variables command/response | 1302 | 6 | set trap address/port command/response | 1303 | 7 | trap response | 1304 | 8-31 | reserved | 1305 +-------+----------------------------------------+ 1307 Table 8: Currently-defined Operation Codes 1309 Sequence: This is a 16-bit integer indicating the sequence number of 1310 the command or response. 1312 Status: This is a 16-bit code indicating the current status of the 1313 system, peer or clock, with values coded as described in following 1314 sections. 1316 Association ID: This is a 16-bit integer identifying a valid 1317 association. 1319 Offset: This is a 16-bit integer indicating the offset, in octets, of 1320 the first octet in the data area. 1322 Count: This is a 16-bit integer indicating the length of the data 1323 field, in octets. 1325 Data: This contains the message data for the command or response. 1326 The maximum number of data octets is 468. 1328 Authenticator (optional): When the NTP authentication mechanism is 1329 implemented, this contains the authenticator information. 1331 A.2. Status Words 1333 Status words indicate the present status of the system, associations 1334 and clock. They are designed to be interpreted by network-monitoring 1335 programs and are in one of four 16-bit formats described in this 1336 section. System and peer status words are associated with responses 1337 for all commands except the read clock variables, write clock 1338 variables and set trap address/port commands. The association 1339 identifier zero specifies the system status word, while a nonzero 1340 identifier specifies a particular peer association. The status word 1341 returned in response to read clock variables and write clock 1342 variables commands indicates the state of the clock hardware and 1343 decoding software. A special error status word is used to report 1344 malformed command fields or invalid values. 1346 A.2.1. System Status Word 1348 The system status word appears in the status field of the response to 1349 a read status or read variables command with a zero association 1350 identifier. The format of the system status word is given in 1351 Figure 8. 1352 0 1 1353 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1354 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1355 | LI | Clock Source | Count | Code | 1356 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1358 Figure 8: System Status Word Format 1360 Leap Indicator (LI): This is a two-bit code warning of an impending 1361 leap second to be inserted/deleted in the last minute of the current 1362 day, with bit 0 and bit 1, respectively, coded as shown in Table 9. 1364 +-------+------------------------------------------+ 1365 | Value | Meaning | 1366 +-------+------------------------------------------+ 1367 | 00 | no warning | 1368 | 01 | last minute has 61 seconds | 1369 | 10 | last minute has 59 seconds | 1370 | 11 | alarm condition (clock not synchronized) | 1371 +-------+------------------------------------------+ 1373 Table 9: Leap Indicator Field 1375 Clock Source: This is a six-bit integer indicating the current 1376 synchronization source, with values coded as shown in Table 10. 1378 +-------+---------------------------------------------------------+ 1379 | Value | Meaning | 1380 +-------+---------------------------------------------------------+ 1381 | 0 | unspecified or unknown | 1382 | 1 | Calibrated atomic clock (e.g.,, HP 5061) | 1383 | 2 | VLF (band 4) or LF (band 5) radio (e.g.,, OMEGA,, WWVB) | 1384 | 3 | HF (band 7) radio (e.g.,, CHU,, MSF,, WWV/H) | 1385 | 4 | UHF (band 9) satellite (e.g.,, GOES,, GPS) | 1386 | 5 | local net (e.g.,, DCN,, TSP,, DTS) | 1387 | 6 | UDP/NTP | 1388 | 7 | UDP/TIME | 1389 | 8 | wall time | 1390 | 9 | telephone modem (e.g. NIST) | 1391 | 10-31 | reserved | 1392 | 32 | PPS signal | 1393 | 33-63 | reserved | 1394 +-------+---------------------------------------------------------+ 1396 Table 10: Clock Source Field Values 1398 System Event Counter: This is a four-bit integer indicating the 1399 number of system exception events occurring since the last time the 1400 system status word was returned in a response or included in a trap 1401 message. The counter is cleared when returned in the status field of 1402 a response and freezes when it reaches the value 15. 1404 System Event Code: This is a four-bit integer identifying the latest 1405 system exception event, with new values overwriting previous values, 1406 and coded as shown in Table 11. 1408 +-------+-----------------------------------------------------------+ 1409 | Value | Meaning | 1410 +-------+-----------------------------------------------------------+ 1411 | 0 | unspecified | 1412 | 1 | system restart | 1413 | 2 | system or hardware fault | 1414 | 3 | system new status word (leap bits or synchronization | 1415 | | change) | 1416 | 4 | system new synchronization source or stratum (sys.peer or | 1417 | | sys.stratum) change | 1418 | 5 | system clock reset (offset correction exceeds CLOCK.MAX) | 1419 | 6 | system invalid time or date | 1420 | 7 | system clock exception (see system clock status word) | 1421 | 8-15 | reserved | 1422 +-------+-----------------------------------------------------------+ 1424 Table 11: System Event Code Values 1426 A.2.2. Peer Status Word 1428 A peer status word is returned in the status field of a response to a 1429 read status, read variables or write variables command and appears 1430 also in the list of association identifiers and status words returned 1431 by a read status command with a zero association identifier. The 1432 format of a peer status word is shown in Figure 9. 1433 0 1 1434 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1435 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1436 | Peer Status | Sel | Count | Code | 1437 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1438 Peer Status Word 1440 Figure 9: Peer Status Word Format 1442 Peer Status: This is a five-bit code indicating the status of the 1443 peer determined by the packet procedure, with bits assigned as shown 1444 in Table 12. 1446 +-------+------------------------------------------+ 1447 | Value | Meaning | 1448 +-------+------------------------------------------+ 1449 | 0 | configured (peer.config) | 1450 | 1 | authentication enabled (peer.authenable) | 1451 | 2 | authentication okay (peer.authentic) | 1452 | 3 | reachability okay (peer.reach) | 1453 | 4 | reserved | 1454 +-------+------------------------------------------+ 1456 Table 12: Peer Status Values 1458 Peer Selection (Sel): This is a three-bit integer indicating the 1459 status of the peer determined by the clock-selection procedure, with 1460 values coded as shown in Table 13. 1462 +-------+-----------------------------------------------------------+ 1463 | Value | Meaning | 1464 +-------+-----------------------------------------------------------+ 1465 | 0 | rejected | 1466 | 1 | passed sanity checks | 1467 | 2 | passed correctness checks | 1468 | 3 | passed candidate checks (if limit check implemented) | 1469 | 4 | passed outlyer checks | 1470 | 5 | current synchronization source; max distance exceeded (if | 1471 | | limit check implemented) | 1472 | 6 | current synchronization source; max distance okay | 1473 | 7 | reserved | 1474 +-------+-----------------------------------------------------------+ 1476 Table 13: Peer Selection Field Values 1478 Peer Event Counter: This is a four-bit integer indicating the number 1479 of peer exception events that occurred since the last time the peer 1480 status word was returned in a response or included in a trap message. 1481 The counter is cleared when returned in the status field of a 1482 response and freezes when it reaches the value 15. 1484 Peer Event Code: This is a four-bit integer identifying the latest 1485 peer exception event, with new values overwriting previous values, 1486 and coded as shown in Table 14. 1488 +-------+-----------------------------------------------------------+ 1489 | Value | Meaning | 1490 +-------+-----------------------------------------------------------+ 1491 | 0 | unspecified | 1492 | 1 | peer IP error | 1493 | 2 | peer authentication failure (peer.authentic bit was one | 1494 | | now zero) | 1495 | 3 | peer unreachable (peer.reach was nonzero now zero) | 1496 | 4 | peer reachable (peer.reach was zero now nonzero) | 1497 | 5 | peer clock exception (see peer clock status word) | 1498 | 6-15 | reserved | 1499 +-------+-----------------------------------------------------------+ 1501 Table 14: Peer Event Codes 1503 A.2.3. Clock Status Word 1505 There are two ways a reference clock can be attached to a NTP service 1506 host, as an dedicated device managed by the operating system and as a 1507 synthetic peer managed by NTP. As in the read status command, the 1508 association identifier is used to identify which one, zero for the 1509 system clock and nonzero for a peer clock. Only one system clock is 1510 supported by the protocol, although many peer clocks can be 1511 supported. A system or peer clock status word appears in the status 1512 field of the response to a read clock variables or write clock 1513 variables command. This word can be considered an extension of the 1514 system status word or the peer status word as appropriate. The 1515 format of the clock status word is shown in Figure 10. 1516 0 1 1517 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1518 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1519 | Clock Status | Code | 1520 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1522 Figure 10: Clock Status Word Format 1524 Clock Status: This is an eight-bit integer indicating the current 1525 clock status, with values coded as shown in Table 15. 1527 +-------+----------------------------+ 1528 | Value | Meaning | 1529 +-------+----------------------------+ 1530 | 0 | clock nominally operating | 1531 | 1 | reply timeout | 1532 | 2 | bad reply format | 1533 | 3 | hardware or software fault | 1534 | 4 | propagation failure | 1535 | 5 | bad date format or value | 1536 | 6 | bad time format or value | 1537 | 7-255 | reserved | 1538 +-------+----------------------------+ 1540 Table 15: Clock Status Values 1542 Clock Event Code: This is an eight-bit integer identifying the latest 1543 clock exception event, with new values overwriting previous values. 1544 When a change to any nonzero value occurs in the radio status field, 1545 the radio status field is copied to the clock event code field and a 1546 system or peer clock exception event is declared as appropriate. 1548 A.2.4. Error Status Word 1550 An error status word is returned in the status field of an error 1551 response as the result of invalid message format or contents. Its 1552 presence is indicated when the E (error) bit is set along with the 1553 response (R) bit in the response. It consists of an eight-bit 1554 integer coded as shown in Figure 11. 1556 0 1 1557 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1558 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1559 | Error Code | Reserved | 1560 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1562 Figure 11: Error Status Word Format 1564 Currently-defined error codes are given in Table 16. 1566 +-------+----------------------------------+ 1567 | Value | Meaning | 1568 +-------+----------------------------------+ 1569 | 0 | unspecified | 1570 | 1 | authentication failure | 1571 | 2 | invalid message length or format | 1572 | 3 | invalid opcode | 1573 | 4 | unknown association identifier | 1574 | 5 | unknown variable name | 1575 | 6 | invalid variable value | 1576 | 7 | administratively prohibited | 1577 | 8-255 | reserved | 1578 +-------+----------------------------------+ 1580 Table 16: Error Code Values 1582 A.3. Commands 1584 Commands consist of the header and optional data field of the Status 1585 Word. When present, the data field contains a list of identifiers or 1586 assignments in the form 1588 <>[=<>],<>[=<>],... 1590 where <> is the ASCII name of a system or peer variable 1591 specified in Table 2 or Table 3 of [1] and <> is expressed as 1592 a decimal, hexadecimal or string constant in the syntax of the C 1593 programming language. Where no ambiguity exists, the <169>sys.<170> 1594 or <169>peer.<170> prefixes shown in Table 2 or Table 4 of [1] can be 1595 suppressed. Whitespace (ASCII nonprinting format effectors) can be 1596 added to improve readability for simple monitoring programs that do 1597 not reformat the data field. Internet addresses are represented as 1598 four octets in the form [n.n.n.n], where n is in decimal notation and 1599 the brackets are optional. Timestamps, including reference, 1600 originate, receive and transmit values, as well as the logical clock, 1601 are represented in units of seconds and fractions, preferably in 1602 hexadecimal notation, while delay, offset, dispersion and distance 1603 values are represented in units of milliseconds and fractions, 1604 preferably in decimal notation.All other values are represented 1605 as-is, preferably in decimal notation. 1607 Implementations may define variables other than those listed in Table 1608 2 or Table 3 of [1]. Called extramural variables, these are 1609 distinguished by the inclusion of some character type other than 1610 alphanumeric or <169>.<170> in the name. For those commands that 1611 return a list of assignments in the response data field, if the 1612 command data field is empty, it is expected that all available 1613 variables defined in Table 3 or Table 4 of [1] will be included in 1614 the response. For the read commands, if the command data field is 1615 nonempty, an implementation may choose to process this field to 1616 individually select which variables are to be returned. 1618 Commands are interpreted as follows: 1620 Read Status (1): The command data field is empty or contains a list 1621 of identifiers separated by commas. The command operates in two ways 1622 depending on the value of the association identifier. If this 1623 identifier is nonzero, the response includes the peer identifier and 1624 status word. Optionally, the response data field may contain other 1625 information, such as described in the Read Variables command. If the 1626 association identifier is zero, the response includes the system 1627 identifier (0) and status word, while the data field contains a list 1628 of binary-coded pairs 1630 <> <>, 1632 one for each currently defined association. 1634 Read Variables (2): The command data field is empty or contains a 1635 list of identifiers separated by commas. If the association 1636 identifier is nonzero, the response includes the requested peer 1637 identifier and status word, while the data field contains a list of 1638 peer variables and values as described above. If the association 1639 identifier is zero, the data field contains a list of system 1640 variables and values. If a peer has been selected as the 1641 synchronization source, the response includes the peer identifier and 1642 status word; otherwise, the response includes the system identifier 1643 (0) and status word. 1645 Write Variables (3): The command data field contains a list of 1646 assignments as described above. The variables are updated as 1647 indicated. The response is as described for the Read Variables 1648 command. 1650 Read Clock Variables (4): The command data field is empty or contains 1651 a list of identifiers separated by commas. The association 1652 identifier selects the system clock variables or peer clock variables 1653 in the same way as in the Read Variables command. The response 1654 includes the requested clock identifier and status word and the data 1655 field contains a list of clock variables and values, including the 1656 last timecode message received from the clock. 1658 Write Clock Variables (5): The command data field contains a list of 1659 assignments as described above. The clock variables are updated as 1660 indicated. The response is as described for the Read Clock Variables 1661 command. 1663 Set Trap Address/Port (6): The command association identifier, status 1664 and data fields are ignored. The address and port number for 1665 subsequent trap messages are taken from the source address and port 1666 of the control message itself. The initial trap counter for trap 1667 response messages is taken from the sequence field of the command. 1668 The response association identifier, status and data fields are not 1669 significant. Implementations should include sanity timeouts which 1670 prevent trap transmissions if the monitoring program does not renew 1671 this information after a lengthy interval. 1673 Trap Response (7): This message is sent when a system, peer or clock 1674 exception event occurs. The opcode field is 7 and the R bit is set. 1675 The trap counter is incremented by one for each trap sent and the 1676 sequence field set to that value. The trap message is sent using the 1677 IP address and port fields established by the set trap address/port 1678 command. If a system trap the association identifier field is set to 1679 zero and the status field contains the system status word. If a peer 1680 trap the association identifier field is set to that peer and the 1681 status field contains the peer status word. Optional ASCII-coded 1682 information can be included in the data field. 1684 Authors' Addresses 1686 Jack Burbank (editor) 1687 The Johns Hopkins University Applied Physics Laboratory 1688 11100 Johns Hopkins Road 1689 Laurel, MD 20723-6099 1690 US 1692 Phone: +1 443 778 7127 1693 Email: jack.burbank@jhuapl.edu 1695 Jim Martin (editor) 1696 Netzwert AG 1697 An den Treptowers 1 1698 Berlin 12435 1699 Germany 1701 Phone: +49.30/5 900 80-1180 1702 Email: jim@netzwert.ag 1704 Dr. David L. Mills 1705 University of Delaware 1706 Newark, DE 19716 1707 US 1709 Phone: +1 302 831 8247 1710 Email: mills@udel.edu 1712 Intellectual Property Statement 1714 The IETF takes no position regarding the validity or scope of any 1715 Intellectual Property Rights or other rights that might be claimed to 1716 pertain to the implementation or use of the technology described in 1717 this document or the extent to which any license under such rights 1718 might or might not be available; nor does it represent that it has 1719 made any independent effort to identify any such rights. Information 1720 on the procedures with respect to rights in RFC documents can be 1721 found in BCP 78 and BCP 79. 1723 Copies of IPR disclosures made to the IETF Secretariat and any 1724 assurances of licenses to be made available, or the result of an 1725 attempt made to obtain a general license or permission for the use of 1726 such proprietary rights by implementers or users of this 1727 specification can be obtained from the IETF on-line IPR repository at 1728 http://www.ietf.org/ipr. 1730 The IETF invites any interested party to bring to its attention any 1731 copyrights, patents or patent applications, or other proprietary 1732 rights that may cover technology that may be required to implement 1733 this standard. Please address the information to the IETF at 1734 ietf-ipr@ietf.org. 1736 Disclaimer of Validity 1738 This document and the information contained herein are provided on an 1739 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1740 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1741 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1742 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1743 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1744 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1746 Copyright Statement 1748 Copyright (C) The Internet Society (2006). This document is subject 1749 to the rights, licenses and restrictions contained in BCP 78, and 1750 except as set forth therein, the authors retain all their rights. 1752 Acknowledgment 1754 Funding for the RFC Editor function is currently provided by the 1755 Internet Society.