NTP WG J. Burbank, Ed. Internet-Draft JHU/APL Obsoletes: RFC 4330 (if approved) J. Martin, Ed. Expires: September 2, 2006 Netzwert AG D. Mills U. Del. March 2006 The Network Time Protocol Version 4 Protocol Specification draft-ietf-ntp-ntpv4-proto-02 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on September 2, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract The Network Time Protocol (NTP) is widely used to synchronize computer clocks in the Internet. This memorandum describes Version 4 of the NTP (NTPv4), introducing several changes from Version 3 of NTP (NTPv3) described in RFC 1305, including the introduction of a modified protocol header to accomodate Internet Protocol Version 6. Burbank, et al. Expires September 2, 2006 [Page 1]
Internet-Draft NTPv4 Protocol Specification March 2006 NTPv4 also includes optional extensions to the NTPv3 protocol,including a dynamic server discovery mechanism. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 4 2. NTP Timestamp . . . . . . . . . . . . . . . . . . . . . . . . 4 3. NTP Message Formats . . . . . . . . . . . . . . . . . . . . . 6 3.1. Leap Indicator (LI) . . . . . . . . . . . . . . . . . . . 7 3.2. Version (VN) . . . . . . . . . . . . . . . . . . . . . . . 8 3.3. Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.4. Stratum (Strat) . . . . . . . . . . . . . . . . . . . . . 9 3.5. Poll Interval (Poll) . . . . . . . . . . . . . . . . . . . 9 3.6. Precision (Prec) . . . . . . . . . . . . . . . . . . . . . 9 3.7. Root Delay . . . . . . . . . . . . . . . . . . . . . . . . 9 3.8. Root Dispersion . . . . . . . . . . . . . . . . . . . . . 10 3.9. Reference Identifier . . . . . . . . . . . . . . . . . . . 10 3.10. Reference Timestamp . . . . . . . . . . . . . . . . . . . 11 3.11. Originate Timestamp . . . . . . . . . . . . . . . . . . . 11 3.12. Receive Timestamp . . . . . . . . . . . . . . . . . . . . 11 3.13. Transmit Timestamp . . . . . . . . . . . . . . . . . . . . 11 3.14. NTPv4 Extension Fields . . . . . . . . . . . . . . . . . . 12 3.15. Authentication (optional) . . . . . . . . . . . . . . . . 13 4. NTP Protocol Operation . . . . . . . . . . . . . . . . . . . . 14 5. SNTP Protocol Operation . . . . . . . . . . . . . . . . . . . 17 6. NTP Server Operations . . . . . . . . . . . . . . . . . . . . 18 7. NTP Client Operations . . . . . . . . . . . . . . . . . . . . 20 8. NTP Symmetric Peer Operations . . . . . . . . . . . . . . . . 22 9. Dynamic Server Discovery . . . . . . . . . . . . . . . . . . . 22 10. The Kiss-o'-Death Packet . . . . . . . . . . . . . . . . . . . 23 11. Security Considerations . . . . . . . . . . . . . . . . . . . 24 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 14.1. Normative References . . . . . . . . . . . . . . . . . . . 25 14.2. Informative References . . . . . . . . . . . . . . . . . . 25 Appendix A. NTP Control Messages . . . . . . . . . . . . . . . . 27 A.1. NTP Control Message Format . . . . . . . . . . . . . . . . 28 A.2. Status Words . . . . . . . . . . . . . . . . . . . . . . . 30 A.2.1. System Status Word . . . . . . . . . . . . . . . . . . 31 A.2.2. Peer Status Word . . . . . . . . . . . . . . . . . . . 33 A.2.3. Clock Status Word . . . . . . . . . . . . . . . . . . 34 A.2.4. Error Status Word . . . . . . . . . . . . . . . . . . 35 A.3. Commands . . . . . . . . . . . . . . . . . . . . . . . . . 36 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39 Intellectual Property and Copyright Statements . . . . . . . . . . 40 Burbank, et al. Expires September 2, 2006 [Page 2]
Internet-Draft NTPv4 Protocol Specification March 2006 1. Introduction The Network Time Protocol Version 3 (NTPv3) [1] has been widely used to synchronize computer clocks in the global Internet. It provides comprehensive mechanisms to access national time and frequency dissemination services, organize the NTP subnet of servers and clients and adjust the system clock in each participant. In most places on the Internet of today, NTP provides accuracies of 1-50 ms, depending on the characteristics of the synchronization source and network paths. NTP is designed for use by clients and servers with a wide range of capabilities. Thus, the Simple Network Time Protocol Version 4 (SNTPv4) as described in [2] was developed for platforms that cannot afford the size and complexity of NTP as a whole. Since the standardization of NTPv3, there has been significant development which has led to Version 4 of the Network Time Protocol (NTPv4). This document describes NTPv4, which introduces new functionality to NTPv3 as described in RFC 1305, and functionality expanded from that of SNTPv4 as described in RFC 4330 (SNTPv4 is a subset of NTPv4). This document obsoletes RFC 4330. When operating with current and previous versions of NTP and SNTP, NTPv4 requires no changes to the protocol or implementations now running or likely to be implemented specifically for future NTP or SNTP versions. The NTP and SNTP packet formats are the same and the arithmetic operations to calculate the client time, clock offset and round trip delay are the same. To a NTP or SNTP server, NTP and SNTP clients are indistinguishable; to a NTP or SNTP client, NTP and SNTP servers are indistinguishable. An important provision in this memo is the interpretation of certain NTP header fields which provide for IPv6 [3]and OSI [4] addressing. The only significant difference between the NTPv3 and NTPv4 header formats is the four-octet Reference Identifier field, which is used primarily to detect and avoid synchronization loops. In all NTP and SNTP versions providing IPv4 addressing, primary servers use a four- character ASCII reference clock identifier in this field, while secondary servers use the 32-bit IPv4 address of the synchronization source. In NTPv4 providing IPv6 and OSI addressing, primary servers use the same clock identifier, but secondary servers use the first 32 bits of the MD5 hash of the IPv6 or NSAP address of the synchronization source. A further use of this field is when the server sends a kiss-o'-death message documented later in this document. In the case of OSI, the Connectionless Transport Service (CLTS) is Burbank, et al. Expires September 2, 2006 [Page 3]
Internet-Draft NTPv4 Protocol Specification March 2006 used as in [5]. Each NTP packet is transmitted as the TS- Userdata parameter of a T-UNITDATA Request primitive. Alternately, the header can be encapsulated in a TPDU which itself is transported using UDP, as described in [6]. It is not advised that NTP be operated at the upper layers of the OSI stack, such as might be inferred from [7], as this could seriously degrade accuracy. With the header formats defined in this memo, it is, in principle, possible to interwork between servers and clients of one protocol family and another, although the practical difficulties may make this inadvisable. This document is organized as follows. Section 2 describes the NTP timestamp format and Section 3 the NTP message format. Section 4 provides general NTP protocol details, with the subset SNTP described in Section 5. This is followed by specific sections on Server (Section 6), Client(Section 7), and Symmetric Peer(Section 8) modes of operation. Section 9 defines the new mechanism for server discovery. describes the control and management mechanism for NTP. Section 10 describes the kiss-o'-death message, whose functionality is similar to the ICMP Source Quench and ICMP Destination Unreachable messages. Section 11 presents NTPv4 security considerations and Section 12 discusses IANA Considerations.Appendix A presents optional NTP control messages. NTPv4 is hereafter referred to simply as NTP, unless explicitly noted. 1.1. Requirements Notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [8]. 2. NTP Timestamp There are three NTP formats used to represent time values: a 128-bit date format, a 64-bit timestamp format, and a 32-bit short format. NTP data are specified as integer or fixed-point quantities, with bits numbered in big-endian fashion from 0 starting at the left or most significant end. Unless specified otherwise, all quantities are unsigned and may occupy the full field width with an implied 0 preceding bit 0. Note that dates cannot be produced by NTP, but can rather be obtained from external means and conveyed via the protocol. Date values are represented in twos compliment arithmetic relative to the base date of 0628:16h 7 February 2036 UTC (when all 128 bits are zero). Values greater than zero represent times after the base date; values less than zero represent times before the base date. Dates are signed values. Timestamps are signed values. A value of zero is Burbank, et al. Expires September 2, 2006 [Page 4]
Internet-Draft NTPv4 Protocol Specification March 2006 a special case representing unknown or unsynchronized time. Figure 1 illustrates the three NTP time formats. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Seconds | Fraction | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ NTP Short Format 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Seconds | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Fraction | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ NTP Timestamp Format 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Era Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Era Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Fraction | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ NTP Date Format Figure 1: NTP Timestamp Format Note that, since some time in 1968 (second 2,147,483,648) the most significant bit (bit 0 of the integer part) has been set and that the 64-bit field will overflow some time in 2036 (second 4,294,967,296). There will exist a 232-picosecond interval, henceforth ignored, every 136 years when the 64-bit field will be 0, which by convention is interpreted as an invalid or unavailable timestamp. If bit 0 is set, the UTC time is in the range 1968-2036 and UTC time is reckoned from 0h 0m 0s UTC on 1 January 1900. If bit 0 is not set, the time is in the range 2036-2104 and UTC time is calculated from 6h 28m 16s UTC on 7 February 2036. Note that when calculating Burbank, et al. Expires September 2, 2006 [Page 5]
Internet-Draft NTPv4 Protocol Specification March 2006 the correspondence, 2000 is a leap year and leap seconds are not included in the reckoning. 3. NTP Message Formats Both NTP and SNTP are layered above the User Datagram Protocol (UDP) [9], which itself is layered on the Internet Protocol (IP) [10] [3]. The structure of the IP and UDP headers is described in the cited specification documents and will not be detailed further here. The UDP port number assigned to NTP is 123, which MUST be used in both the Source Port and Destination Port fields in the UDP header. The remaining UDP header fields should be set as described in the specification. Figure 2 provides a description of the NTPv4 message format. This format is identical to that described in RFC 1305, with the exception of the contents of the reference identifier field and optional extension fields. The header fields are defined in Figure 2. Burbank, et al. Expires September 2, 2006 [Page 6]
Internet-Draft NTPv4 Protocol Specification March 2006 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |LI | VN |Mode | Strat | Poll | Prec | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Root Delay | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Root Dispersion | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reference ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Reference Timestamp + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Origin Timestamp + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Receive Timestamp + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Transmit Timestamp + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Extension Field 1 (Optional) + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Extension Field 2 (Optional) + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . Authentication . . (Optional) (160 bits) . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: NTPv4 Message Format 3.1. Leap Indicator (LI) This is a two-bit field indicating an impending leap second to be inserted in the NTP timescale. The bits are set before 23:59 on the day of insertion and reset after 00:00 on the following day. This Burbank, et al. Expires September 2, 2006 [Page 7]
Internet-Draft NTPv4 Protocol Specification March 2006 causes the number of seconds (rollover interval) in the day of insertion to be increased or decreased by one. A leap second is inserted or deleted in the timescale on the last day of June or December. The possible values of the LI field, and corresponding meanings, are given in Table 1. +----+--------------------------------------------+ | LI | Meaning | +----+--------------------------------------------+ | 0 | no warning | | 1 | last minute of the day has 61 seconds | | 2 | last minute of the day has 59 seconds | | 3 | alarm condition (clock never synchronized) | +----+--------------------------------------------+ Table 1: Length Indicator Field Values On startup, servers set this field to 3 (clock not synchronized) and set this field to some other value when synchronized to the primary reference clock. Once set to other than 3, the field is never set to that value again, even if all synchronization sources become unreachable or defective. 3.2. Version (VN) This is a three-bit integer indicating the NTP/SNTP version number, set to 4 for NTPv4. If necessary to distinguish between IPv4, IPv6 and OSI, the encapsulating context must be inspected. 3.3. Mode This is a three-bit number indicating the protocol mode. The values are defined in Table 2. +------+--------------------------+ | Mode | Meaning | +------+--------------------------+ | 0 | reserved | | 1 | symmetric active | | 2 | symmetric passive | | 3 | client | | 4 | server | | 5 | broadcast | | 6 | NTP control message | | 7 | reserved for private use | +------+--------------------------+ Table 2: Mode Field Values Burbank, et al. Expires September 2, 2006 [Page 8]
Internet-Draft NTPv4 Protocol Specification March 2006 Mode 0 is reserved. Modes 1 and 2 are intended for use by symmetric peers who set this mode to 1 or 2 depending on whether it is active or passive mode. In unicast mode or discovery mode, the client sets this field to 3 (client) in the request and the server sets it to 4 (server) in the reply. In broadcast mode, the server sets this field to 5 (broadcast). A mode type of 6 is reserved for NTP control messages. Mode 7 is reserved for private usage. 3.4. Stratum (Strat) This is a eight-bit unsigned integer indicating the stratum. This field is significant only in SNTP server messages, where the values are defined in Table 3. +---------+-------------------------------------------------------+ | Stratum | Meaning | +---------+-------------------------------------------------------+ | 0 | kiss-o'-death message | | 1 | primary reference (e.g., synchronized by radio clock) | | 2-255 | secondary reference (synchronized by NTP or SNTP) | +---------+-------------------------------------------------------+ Table 3: Stratum Field Values 3.5. Poll Interval (Poll) This is an eight-bit unsigned integer indicating the maximum interval between successive messages, in log2 seconds. A client SHOULD NOT use a poll interval less than 15 seconds, except at initial startup when it MAY send a sequence of 8 packets at 1 second intervals to provide initial synchronization of the clients with each server. A client SHOULD increase the poll interval as performance permits and especially if the server does not respond within a reasonable time. 3.6. Precision (Prec) This is an eight-bit signed integer indicating the precision of the system clock in log2 seconds. Precision is normally determined when the service is established as the minimum number of iterations of the time to read the system clock. As an example, a value of -18 corresponds to a precision of about one microsecond. 3.7. Root Delay This is a 32-bit signed fixed-point number indicating the total roundtrip delay to the primary reference source, in 32-bit NTP short format. Note that this variable can take on both positive and negative values, depending on the relative time and frequency Burbank, et al. Expires September 2, 2006 [Page 9]
Internet-Draft NTPv4 Protocol Specification March 2006 offsets. This field is significant only in server messages, where the values range from negative values of a few milliseconds to positive values of several hundred milliseconds. 3.8. Root Dispersion This is a 32-bit unsigned fixed-point number indicating the nominal error relative to the primary reference source in seconds, in 32-bit NTP short format. 3.9. Reference Identifier This is a 32-bit bitstring identifying the particular reference source. The interpretation of this field depends on the value in the stratum field. For stratum 0, this is a four-character ASCII string, referred to as a 'kiss code' and is used for debugging and monitoring purposes. For stratum 1, this is a four-octet, left-justified, zero- padded ASCII string assigned to the reference source. Above stratum 1 (secondary servers and clients), this is the reference identifier of the server. If employing IPv4, the value is the 32-bit IPv4 address of the synchronization source. For IPv6 and OSI, the value is the first 32 bits of the MD5 hash of the IPv6 or NSAP address of the synchronization source. The fASCII identifiers that are currently defined are given in Table 4. Primary (stratum 1) servers set this field to a code identifying the external reference source according to Table 4. Burbank, et al. Expires September 2, 2006 [Page 10]
Internet-Draft NTPv4 Protocol Specification March 2006 +-------+----------------------------------------------------+ | Code | External Reference Source | +-------+----------------------------------------------------+ | GOES | Geosynchronous Orbit Environment Satellite | | GPS | Global Position System | | PPS | Generic pulse-per-second | | IRIG | Inter-Range Instrumentation Group | | WWVB | LF Radio WWVB Ft. Collins, CO 60 kHz | | DCF77 | LF Radio DCF77 Mainflingen, DE 77.5 kHz | | HBG | LF Radio HBG Prangins, HB 75 kHz | | MSF | LF Radio MSF Rugby, UK 60 kHz | | JJY | LF Radio JJY Fukushima, JP 40 kHz, Saga, JP 60 kHz | | LORC | MF Radio LORAN C 100 kHz | | TDF | MF Radio Allouis, FR 162 kHz | | CHU | HF Radio CHU Ottawa, Ontario | | WWV | HF Radio WWV Ft. Collins, CO | | WWVH | HF Radio WWVH Kauai, HI | | NIST | NIST telephone modem | | USNO | USNO telephone modem | | PTB | European telephone modem | +-------+----------------------------------------------------+ Table 4: Currently-defined Reference Identifiers If the external reference is one of those listed, the associated code should be used. Codes for sources not listed can be created as appropriate (see IANA Considerations section of this document). 3.10. Reference Timestamp This is a 64 bit signed integer indicating the time when the system clock was last set or correctetd, in 64-bit NTP timestamp format. 3.11. Originate Timestamp This is the time at which the request departed the client for the server, in 64-bit NTP timestamp format. 3.12. Receive Timestamp This is the time at which the request arrived at the server or the reply arrived at the client, in 64-bit NTP timestamp format. 3.13. Transmit Timestamp This is the time at which the request departed the client or the reply departed the server, in 64-bit NTP timestamp format. Burbank, et al. Expires September 2, 2006 [Page 11]
Internet-Draft NTPv4 Protocol Specification March 2006 3.14. NTPv4 Extension Fields NTPv4 defines new extension field formats. The minimum extension field length is 8 octets. The format of the NTP extension field is given in Figure Figure 3. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Association ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Filestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . Value . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signature Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . Signature . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Padding (as needed) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: NTP Extension Field Format The Field Type field is a 16-bit integer which indicates the type of extension message contained within the extension field. The Length field is a 16-bit integer indicates the length of the entire extension field in octets, including the Length and Padding fields. The 32-bit Association ID field is set by clients to the value previously received from the server or 0 otherwise. The server sets the Association ID field when sending a response as a handle for subsequent exchanges. If the association ID value in a request does not match the association ID of any association, the server returns the request with the first two bits of the Field Type field set to 1. Burbank, et al. Expires September 2, 2006 [Page 12]
Internet-Draft NTPv4 Protocol Specification March 2006 The Timestamp and Filestamp 32-bit fields carry the seconds field of an NTP timestamp. The Timestamp field establishes the signature epoch of the data field in the message, while the filestamp establishes the generation epoch of the file that ultimately produced the data. The 32-bit Value Length field indicates the length of the Value field in octets. The minimum length of the Value field is 0. The 32-bit Signature Length field indicates the length of the Signature field in octets. Zero padding is applied, as necessary, to extend the extension field to a word (4-octet) boundary. If multiple extension fields are present, the last extension field is zero-padded to a double-word (8 octet) boundary. 3.15. Authentication (optional) NTPv4 provides an optional 160-bit Authentication field. When implemented, the 32-bit Key Identifier and 128-bit Message Digest fields contain the Message Authentication Code (MAC) information which uses an MD5 cryptosum of NTP header plus extension fields. The authentication field format is shown in Figure Figure 4. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Message Digest + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: NTP Authentication Field The 32-bit Key Identifier is an integer identifying the 128-bit private key used to generate the MAC. The Message Digest field contains the MD5 Message Digest. In NTPv4, the presence of one or more extension fields requires the presence of an authentication field. The presence of the Authentication field and extension fields is determined from the Length field. The Key Identifier is initialized to zero at the start of an Burbank, et al. Expires September 2, 2006 [Page 13]
Internet-Draft NTPv4 Protocol Specification March 2006 association. The type of association then determines the key identifier. If the association is active (modes 1, 3, 5) the key is determined from the system key identifier. If the association is passive (modes 2, 4) the key is determined from the peer key identifier, if the authentic bit is set (see [1]), or as the default key (zero) otherwise. 4. NTP Protocol Operation The NTP protocol defines three operational roles, Client, Server, and Symmetric Peer. Clients request or receive time from Servers (solicited or unsolicited). Servers respond to requests or send periodic time updates to Clients. Symmetric Peers exchange time data bidirectionally. A given NTPv4 implementation can operate in any or all of these modes. NTP messages make use of two different communication modes, one to one and one to many, commonly referred to as unicast and broadcast. For the purposes of this document, the term broadcast is interpreted to mean any available one to many mechanism. For IPv4 this equates to either IPv4 broadcast or IPv4 multicast. For IPv6 this equates to IPv6 multicast. For this purpose, IANA has allocated the IPv4 multicast address 224.0.1.1 and the IPv6 multicast address ending :101, with prefix determined by scoping rules. Except in broadcast mode, an NTP association is formed when two peers exchange messages and one or both of them create and maintain an instantiation of the protocol machine, called an association. The association can operate in one of five modes as indicated by the host- mode variable (peer.mode) (see [1] for a description of the NTP variables): symmetric active, symmetric passive, client, server and broadcast, which are defined as follows: Symmetric Active (1): A host operating in this mode sends periodic messages regardless of the reachability state or stratum of its peer. By operating in this mode the host announces its willingness to synchronize and be synchronized by the peer. Symmetric Passive (2): This type of association is ordinarily created upon arrival of a message from a peer operating in the symmetric active mode and persists only as long as the peer is reachable and operating at a stratum level less than or equal to the host; otherwise, the association is dissolved. However, the association will always persist until at least one message has been sent in reply. By operating in this mode the host announces its willingness to synchronize and be synchronized by the peer. Burbank, et al. Expires September 2, 2006 [Page 14]
Internet-Draft NTPv4 Protocol Specification March 2006 Client (3): A host operating in this mode sends periodic messages regardless of the reachability state or stratum of its peer. By operating in this mode the host announces its willingness to be synchronized by, but not to synchronize the peer. Server (4): This type of association is ordinarily created upon arrival of a client request message and exists only in order to reply to that request, after which the association is dissolved. By operating in this mode the host announces its willingness to synchronize, but not to be synchronized by the peer. Broadcast (5): A host operating in this mode sends periodic messages regardless of the reachability state or stratum of the peers. By operating in this mode the host announces its willingness to synchronize all of the peers, but not to be synchronized by any of them. NTP messages are layered on top of UDP. All messages MUST be sent with a destination port of 123, and SHOULD be sent with a source port of 123. The on-wire protocol uses four timestamps numbered T1 through T4 and three state variables org, rec, and xmt, as shown in Figure Figure 5, where T1 corresponds to the Reference Timestamp T2 corresponds to the Originate Timestamp, T3 corresponds to the Receive Timestamp, and T4 corresponds to the Transmit Timestamp. Burbank, et al. Expires September 2, 2006 [Page 15]
Internet-Draft NTPv4 Protocol Specification March 2006 t2 t3 t6 t7 +---------+ +---------+ +---------+ +---------+ T1 | 0 | | t2 | | t4 | | t6 | +---------+ +---------+ +---------+ +---------+ T2 | 0 | | t1 | | t3 | | t5 | Packet +---------+ +---------+ +---------+ +---------+ Variables T3 |t2=clock | | t2 | |t6=clock | | t6 | +---------+ +---------+ +---------+ +---------+ T4 | t1 | |t3=clock | | t5 | |t7=clock | +---------+ +---------+ +---------+ +---------+ Peer B +---------+ +---------+ +---------+ +---------+ org | t1 | | t1 | | T3<>t1? | | t5 | +---------+ +---------+ +---------+ +---------+ State rec | t2 | | t2 | | t6 | | t6 | Variables +---------+ +---------+ +---------+ +---------+ xmt | 0 | | t3 | | T1<>t3? | | t7 | +---------+ +---------+ +---------+ +---------+ t2 t3 t6 t7 --------------------------------------------------------- /\ \ /\ \ / \ / \ / \ / \ / \/ / \/ --------------------------------------------------------- t1 t4 t5 t8 t1 t4 t5 t8 +---------+ +---------+ +---------+ +---------+ T1 | 0 | | t2 | | t4 | | t6 | +---------+ +---------+ +---------+ +---------+ T2 | 0 | | t1 | | t3 | | t5 | Packet +---------+ +---------+ +---------+ +---------+ Variables T3 | 0 | |t4=clock | | t4 | |t8=clock | +---------+ +---------+ +---------+ +---------+ T4 |t1=clock | | t3 | |t5=clock | | t7 | +---------+ +---------+ +---------+ +---------+ Peer A +---------+ +---------+ +---------+ +---------+ org | 0 | | T3<>0? | | t3 | | T3<>t3? | +---------+ +---------+ +---------+ +---------+ State rec | 0 | | t4 | | t4 | | t8 | Variables +---------+ +---------+ +---------+ +---------+ xmt | t1 | | T1=t1? | | t5 | | T1<>t5? | +---------+ +---------+ +---------+ +---------+ Figure 5: NTPState Burbank, et al. Expires September 2, 2006 [Page 16]
Internet-Draft NTPv4 Protocol Specification March 2006 This figure shows the most general case, where each of two peers, A and B, independently measure the offset and delay relative to the other. For illustrative purposes, the individual timestamp values are shown in lower case with subscripts indicating the order of transmission and reception. In the figure, the first packet transmitted by A contains only the transmit timestamp T4 with value t1. B receives the packet at t2 and saves the originate timestamp T2 with value t1 in state variable org and the receive timestamp T3 with value t2 in state variable rec. Afterwards, B sends a packet to A containing the org and rec state variables in T2 and T1 respectively and additionally the transmit timestamp T4 with value t3, which is saved in the xmt state variable. When this packet arrives at A the packet header variables T1, T2, T3, and T4 represent the four timestampes necessary to compute the offset and delay of B relative to A. Before the A state variables are updated, two sanity checks are performed in order to protect against duplicate or invalid packets. A packet is a duplicate if the transmit timestamp T4 in the packet matches the xmt state variable. A packet is invalid if the origin timestamp T2 in the packet does not match the org state variable. In either of these cases the state variables are updated, but the packet is discarded. The general rules that govern the updating of state variables and packet variables are given in Figure 6. +-------------------------------------------------------+ | Receive | Transmit | +-------------------------------------------------------+ | org=T4 | org=unchanged | | rec=Time of Receipt | rec=unchanged | | xmt=unchanged | xmt=Time of transmission | | | | | T1=Received T3 | T1=rcv | | T2=Received T2 | T2=org | | T3=rec | T3=unchanged | | T4=Received T4 | T4=xmt | +-------------------------------------------------------+ Figure 6: Relationship between NTP State Variables and NTP Packet Variables 5. SNTP Protocol Operation SNTP operates using the same message formats, addresses, and ports as NTP. However, it is stateless, operating only in the client or server roles. Thus it is compatible with, and a subset of, NTP. Burbank, et al. Expires September 2, 2006 [Page 17]
Internet-Draft NTPv4 Protocol Specification March 2006 6. NTP Server Operations Fundamentally, the NTP Server role consists of listening for client requests, and providing time and associated details as a response. Additionally, a server can provide time and associated details periodically via a broadcast mechanism. An NTP server can communicate via unicast, broadcast, or both. A server receiving a unicast request (NTP mode 3), modifies fields in the NTP header as described below, and sends a reply (NTP mode 4), possibly using the same message buffer as the request. When operating in a broadcast mode, unsolicited messages (NTP mode 5) with field values as described below are normally sent at intervals ranging from 64 s to 1024 s, depending on the expected frequency tolerance of the client clocks and the required accuracy. A broadcast server may or may not send messages if not synchronized to a correctly operating source, but the preferred option is to transmit, since this allows reachability to be determined regardless of synchronization state. The Leap Indicator (LI) is set to 3 (unsynchronized) if the server has never synchronized to a reference source. Once synchronized, the LI field is set to one of the other three values and remains at the last value set even if the reference source becomes unreachable or turns faulty. The Version (VN) is copied from the request packet, if responding to a unicast request. For broadcast, this is set to 4. The Mode is set to Server (4) if in response to a unicast request. For broadcast, this is set to Broadcast (5). The Stratum field is set to the server's current stratum, if synchronized. If synchronized to a primary reference source the Stratum field is set to 1. If unsynchronized this field is set to 0. The Poll field is coppied from the request, if responding to a unicast request. For broadcast, this is set to the nearest integer log2 of the poll interval. The Precision field is set to reflect the maximum reading error of the system clock. The Root Delay and Root Dispersion fields are set to 0 for a primary server; optionally, the Root Dispersion field can be set to a value corresponding to the maximum error of the radio clock itself. If the server is synchronized to a reference source, the value of the Burbank, et al. Expires September 2, 2006 [Page 18]
Internet-Draft NTPv4 Protocol Specification March 2006 Reference ID is set to a four-character ASCII string identifying the source, left justified and zero padded to 32bits. For IPv4 secondary servers,the value is the 32-bit IPv4 address of the synchronization source. For IPv6 and OSI secondary servers, the value is the first 32 bits of the MD5 hash of the IPv6 or NSAP address of the synchronization source. If unsynchronized, it is set to an ASCII error identifier. The timestamp fields in the server message are set as follows. If the server is unsynchronized or first coming up, all timestamp fields are set to zero with one exception. If the server is synchronized, the Transmit Timestamp field of the request is copied unchanged to the Originate Timestamp field of the reply. If the server is synchronized, the Reference Timestamp is set to the time the last update was received from the reference source. The Originate Timestamp field is set as in the unsynchronized case above. The Transmit Timestamp field is set to the time of day when the message is sent. In broadcast messages the Receive Timestamp field is set to zero and copied from the Transmit Timestamp field in other messages. Table 5 summarizes these actions. +---------------+-----------+-------------------+-------------------+ | Field Name | Unicast | Unicast Reply | Broadcast | | | Request | | | +---------------+-----------+-------------------+-------------------+ | LI | ignore | as needed | as needed | | VN | 1-4 | copied from | 4 | | | | request | | | Mode | 1 or 3 | 2 or 4 | 5 | | Stratum | ignore | 1 | 1 | | Poll | ignore | copied from | log2 poll | | | | request | interval | | Precision | ignore | -log2 server | -log2 server | | | | significant bits | significant bits | | Root Delay | ignore | 0 | 0 | | Root | ignore | 0 | 0 | | Dispersion | | | | | Reference | ignore | source ident | source ident | | Identifier | | | | | Reference | ignore | time of last src. | time of last src. | | Timestamp | | update | update | | Originate | ignore | copied from xmit | 0 | | Timestamp | | timestamp | | | Receive | ignore | time of day | 0 | | Timestamp | | | | Burbank, et al. Expires September 2, 2006 [Page 19]
Internet-Draft NTPv4 Protocol Specification March 2006 | Transmit | (see | time of day | time of day | | Timestamp | text) | | | | Authenticator | optional | optional | optional | +---------------+-----------+-------------------+-------------------+ Table 5: NTP Server Message Field Population Broadcast servers should respond to client unicast requests, as well as send unsolicited broadcast messages. Broadcast clients may send unicast requests in order to measure the network propagation delay between the server and client and then continue operation in listen-only mode. However, broadcast servers may choose not to respond to unicast requests, so unicast clients should be prepared to abandon the measurement and assume a default value for the delay. 7. NTP Client Operations The role of an NTP client is to determine the current time (and associated information) from an NTP server. This can be done actively, by sending a unicast request to a configured server, or passively by listening on a known address for periodic server messages. An NTP client can operate in unicast or broadcast modes. In unicast mode the client sends a request (NTP mode 3) to a designated unicast server and expects a reply (NTP mode 4) from that server. In broadcast client mode it sends no request and waits for a broadcast (NTP mode 5) from one or more broadcast servers. A unicast client initializes the NTP message header, sends the request to the server and strips the time of day from the Transmit Timestamp field of the reply. For this purpose, all of the NTP header fields shown in Section 3 are set to 0, except the Mode, VN and optional Transmit Timestamp fields. NTP and SNTP clients set the mode field to 3 (client) for unicast requests. They set the VN field to any version number supported by the server selected by configuration or discovery and can interoperate with all previous version NTP and SNTP servers. Servers reply with the same version as the request, so the VN field of the request also specifies the VN field of the reply. An NTP client can specify the earliest acceptable version on the expectation that any server of that or later version will respond. NTPv4 servers are backwards compatible with NTPv3 as defined in RFC 1305, NTPv2 as defined in [11], and NTPv1 as defined in [12]. NTPv0 defined in [13] is not supported. Burbank, et al. Expires September 2, 2006 [Page 20]
Internet-Draft NTPv4 Protocol Specification March 2006 In unicast mode, the Transmit Timestamp field in the request SHOULD be set to the time of day according to the client clock in NTP timestamp format. This allows for the determination of the propagation delay between the server and client and to align the system clock relative to the server. In addition, this provides a simple method to verify that the server reply is in fact a legitimate response to the specific client request and avoid replays. Note that in broadcast mode, the client cannot necessarily calculate the propagation delay or determine the validity of the server. There is some latitude on the part of most clients to forgive invalid timestamps, such as might occur when first coming up or during periods when the reference source is inoperative. The most important indicator of an unhealthy server is the Stratum field, in which a value of 0 indicates an unsynchronized condition. When this value is displayed, clients should discard the server message, regardless of the contents of other fields. Table 6 summarizes the required NTP client operations in unicast and broadcast modes +-------------------+---------------+-------------------+-----------+ | Field Name | Unicast | Unicast Reply | Broadcast | | | Request | | | +-------------------+---------------+-------------------+-----------+ | LI | 0 | 0-3 | 0-3 | | VN | 1-4 | copied from | 1-4 | | | | request | | | Mode | 1 or 3 | 2 or 4 | 5 | | Stratum | 0 | 0-15 | 0-15 | | Poll | 0 | ignore | ignore | | Precision | 0 | ignore | ignore | | Root Delay | 0 | ignore | ignore | | Root Dispersion | 0 | ignore | ignore | | Reference | 0 | ignore | ignore | | Identifier | | | | | Reference | 0 | ignore | ignore | | Timestamp | | | | | Originate | 0 | (see text) | ignore | | Timestamp | | | | | Receive Timestamp | 0 | (see text) | ignore | | Transmit | (see text) | nonzero | nonzero | | Timestamp | | | | | Authenticator | optional | optional | optional | +-------------------+---------------+-------------------+-----------+ Table 6: NTP Client Message Field Population Burbank, et al. Expires September 2, 2006 [Page 21]
Internet-Draft NTPv4 Protocol Specification March 2006 8. NTP Symmetric Peer Operations NTP Symmetric Peer mode is intended for configurations where a set of low-stratum peers operate as mutual backups for each other. Each peer normally operates with one or more sources, such as a reference clock, or a subset of primary or secondry servers known to be reliable or authentic. Symmetric Peer mode is exclusive to the NTP protocol and is specifically excluded from SNTP operation. For the purposes of this document, an NTP peer operates like a client. 9. Dynamic Server Discovery NTPv4 provides a mechanism, commonly known as "Manycast", for a client to dynamically discover the existance of one or more servers with no a-priori knowledge. Once servers are discovered, they are then treated as any other unicast server. A client employing server discovery is configured with MinServers, the minimum number of desired servers and MaxServers, the maximum number of desired servers. The discovery mechanism is a simple expanding ring search, using IP multicast with increasing TTLs or Hop Counts. The multicast address used MUST be scoped to the local site, as defined by [14]. The client initiates the discovery process by sending an NTP message to the configured multicast address (224.0.1.1 for IPv4 and a multicast address ending :101 for IPv6 with proper scoping.) with an IP TTL or Hop Count of 1. This message has all of the NTP header fields set to 0, except the Mode, VN and optional Transmit Timestamp fields. The Mode is set to 3. It then starts a retry timer (Default: 64 seconds) and listens for unicast responses from servers. The source address of any server responses are treated as newly configured unicast servers, up to a limit of MaxServers. If the number of discovered servers is less than MinServers when the retry timer expires, an identical NTP message is sent with an increased TTL/Hop Count, and the retry timer is restarted. This continues until either MinServers servers have been discovered or a configured maximum TTL/Hop Count is reached. If the configured maximum TTL/Hop Count is reached, packets continue to be periodically sent at the maximum TTL/Hop Count. If at some subsequent time, the number of valid servers drops below MinServers, the process restarts at the initial state. A server configured to provide server discovery will listen on the specified multicast address for discovery messages from clients. If Burbank, et al. Expires September 2, 2006 [Page 22]
Internet-Draft NTPv4 Protocol Specification March 2006 the server is in scope of the current TTL and is itself synchronized to a valid source it replies to the discovery message from the client with an ordinary unicast server message as described in Section 6 10. The Kiss-o'-Death Packet According to the NTPv3 specification [1], if the Stratum field in the NTP header is 1, indicating a primary server, the Reference Identifier field contains an ASCII string identifying the particular reference clock type. However, in [1] nothing is said about the Reference Identifier field if the Stratum field is 0, which is called out as "unspecified". However, if the Stratum field is 0, the Reference Identifier field can be used to convey messages useful for status reporting and access control. In NTPv4 and SNTPv4, packets of this kind are called Kiss-o'-Death (KoD) packets and the ASCII messages they convey are called kiss codes. The KoD packets got their name because an early use was to tell clients to stop sending packets that violate server access controls. The kiss codes can provide useful information for an intelligent client. These codes are encoded in four-character ASCII strings left justified and zero filled. The strings are designed for character displays and log files. A list of the currently-defined kiss codes is given in Table 7. +------+------------------------------------------------------------+ | Code | Meaning | +------+------------------------------------------------------------+ | ACST | The association belongs to a unicast server | | AUTH | Server authentication failed | | AUTO | Autokey sequence failed | | BCST | The association belongs to a broadcast server | | CRYP | Cryptographic authentication or identification failed | | DENY | Access denied by remote server | | DROP | Lost peer in symmetric mode | | RSTR | Access denied due to local policy | | INIT | The association has not yet synchronized for the first | | | time | | MCST | The association belongs to a dynamically discovered server | | NKEY | No key found. Either the key was never installed or is | | | not trusted | | RATE | Rate exceeded. The server has temporarily denied access | | | because the client exceeded the rate threshold | | RMOT | Alteration of association from a remote host running | | | ntpdc. | Burbank, et al. Expires September 2, 2006 [Page 23]
Internet-Draft NTPv4 Protocol Specification March 2006 | STEP | A step change in system time has occurred, but the | | | association has not yet resynchronized | +------+------------------------------------------------------------+ Table 7: Currently-defined NTP Kiss Codes In general, an NTP client should stop sending to a particular server if that server returns a reply with a Stratum field of 0, regardless of kiss code, and an alternate server is available. If no alternate server is available, the client SHOULD increase the poll interval as performance permits. 11. Security Considerations NTPv4 provides an optional authentication field that utilizes the MD5 algorithm. MD5, as the case for SHA-1, is derived from MD4, which has long been known to be weak. In 2004, techniques for efficiently finding collisions in MD5 were announced. A summary of the weakness of MD5 can be found in [15]. In the case of NTP as specified herein, there is a vulnerability that NTP broadcast clients can be disrupted by misbehaving or hostile SNTP or NTP broadcast servers elsewhere in the Internet. Access controls and/or cryptographic authentication means should be provided for additional security in such cases. While not required in a conforming NTP client implementation, there are a variety of recommended checks that an NTP client can perform that are designed to avoid various types of abuse that might happen as the result of server implementation errors or malicious attack. These recommended checks are as follows: When the IP source and destination addresses are available for the client request, they should match the interchanged addresses in the server reply. When the UDP source and destination ports are available for the client request, they should match the interchanged ports in the server reply. The Originate Timestamp in the server reply should match the Transmit Timestamp used in the client request. A client can check the Root Delay and Root Dispersion fields are each greater than or equal to 0 and less than infinity, where infinity is is on the order of 15-20 seconds. This check avoids using a server whose synchronization source has expired for a very Burbank, et al. Expires September 2, 2006 [Page 24]
Internet-Draft NTPv4 Protocol Specification March 2006 long time. 12. IANA Considerations UDP/TCP Port 123 was previously assigned by IANA for this protocol. The IANA has assigned the IPv4 multicast group address 224.0.1.1 and the IPv6 multicast address ending :101 for NTP. This document identifies the set of defined 4-character (ASCII) Reference Identifier values. This document also defines the set of defined Kiss Codes. This document also introduces NTP extension fields allowing for the development of future extensions to the protocol, where a particular extension is to be identified by the Field Type sub-field within the extension field. IANA is requested to establish and maintain a registry for Reference Identifiers, Kiss codes, and Extension Field Types associated with this protocol, populating this registry from the Reference Identifiers given in Section 3.9 and Kiss Codes given in Section 11 as the initial entries. The Extension Field Types registry will have no initial entries. As future needs arise, new Reference Identifiers, Kiss Codes, and Extension Field Types may be defined. Following the policies outlined in [16], new values are to be defined by IETF Consensus. 13. Acknowledgements This document has drawn material from RFC 4330, "Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI." As a result, the authors would like to acknowledge D. Plonka of the University of Wisconsin and J. Montgomery of Netgear, who were contributors. The authors would also like to thank B. Haberman for providing rigorous reviews of this document. 14. References 14.1. Normative References [1] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation", RFC 1305, March 1992. 14.2. Informative References [2] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI", RFC 4330, January 2006. Burbank, et al. Expires September 2, 2006 [Page 25]
Internet-Draft NTPv4 Protocol Specification March 2006 [3] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [4] Colella, R., Callon, R., Gardner, E., and Y. Rekhter, "Guidelines for OSI NSAP Allocation in the Internet", RFC 1629, May 1994. [5] International Standards Organization, "International Standards 8602 - Information Processing Systems - OSI: Connectionless Transport Protocol Specification.", NDSS , December 1986. [6] Shue, C., Haggerty, W., and K. Dobbins, "OSI connectionless transport services on top of UDP: Version 1", RFC 1240, June 1991. [7] Furniss, P., "Octet Sequences for Upper-Layer OSI to Support Basic Communications Applications", RFC 1698, October 1994. [8] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [9] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980. [10] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [11] Mills, D., "Network Time Protocol (version 2) specification and implementation", STD 12, RFC 1119, September 1989. [12] Mills, D., "Network Time Protocol (version 1) specification and implementation", RFC 1059, July 1988. [13] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, October 1985. [14] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC 2365, July 1998. [15] Bellovin, S. and E. Rescorla, "Deploying a New Hash Algorithm", Proceedings of the 13th Annual ISOC Network and Distributed System Security Symposium (NDSS) , February 2006. [16] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. Burbank, et al. Expires September 2, 2006 [Page 26]
Internet-Draft NTPv4 Protocol Specification March 2006 Appendix A. NTP Control Messages In a comprehensive network-management environment, facilities are presumed available to perform routine NTP control and monitoring functions, such as setting the leap-indicator bits at the primary servers, adjusting the various system parameters and monitoring regular operations. Ordinarily, these functions can be implemented using a network-management protocol such as SNMP and suitable extensions to the MIB database. However, in those cases where such facilities are not available, these functions can be implemented using special NTP control messages described herein. These messages are intended for use only in systems where no other management facilities are available or appropriate, such as in dedicated- function bus peripherals. Support for these messages is not required in order to conform to this specification. The NTP Control Message has the value 6 specified in the mode field of the first octet of the NTP header and is formatted as shown in Section 10.1. The format of the data field is specific to each command or response; however, in most cases the format is designed to be constructed and viewed by humans and so is coded in free-form ASCII. This facilitates the specification and implementation of simple management tools in the absence of fully evolved network- management facilities. As in ordinary NTP messages, the authenticator field follows the data field. If the authenticator is used the data field is zero-padded to a 32-bit boundary, but the padding bits are not considered part of the data field and are not included in the field count. IP hosts are not required to reassemble datagrams larger than 576 octets; however, some commands or responses may involve more data than will fit into a single datagram. Accordingly, a simple reassembly feature is included in which each octet of the message data is numbered starting with zero. As each fragment is transmitted the number of its first octet is inserted in the offset field and the number of octets is inserted in the count field. The more-data (M) bit is set in all fragments except the last. Most control functions involve sending a command and receiving a response, perhaps involving several fragments. The sender chooses a distinct, nonzero sequence number and sets the status field and R and E bits to zero. The responder interprets the opcode and additional information in the data field, updates the status field, sets the R bit to one and returns the three 32-bit words of the header along with additional information in the data field. In case of invalid message format or contents the responder inserts a code in the status field, sets the R and E bits to one and, optionally, inserts a diagnostic message in the data field. Burbank, et al. Expires September 2, 2006 [Page 27]
Internet-Draft NTPv4 Protocol Specification March 2006 Some commands read or write system variables and peer variables for an association identified in the command. Others read or write variables associated with a radio clock or other device directly connected to a source of primary synchronization information. To identify which type of variable and association a 16-bit association identifier is used. System variables are indicated by the identifier zero. As each association is mobilized a unique, nonzero identifier is created for it. These identifiers are used in a cyclic fashion, so that the chance of using an old identifier which matches a newly created association is remote. A management entity can request a list of current identifiers and subsequently use them to read and write variables for each association. An attempt to use an expired identifier results in an exception response, following which the list can be requested again. Some exception events, such as when a peer becomes reachable or unreachable, occur spontaneously and are not necessarily associated with a command. An implementation may elect to save the event information for later retrieval or to send an asynchronous response (called a trap) or both. In case of a trap the IP address and port number is determined by a previous command and the sequence field is set as described below. Current status and summary information for the latest exception event is returned in all normal responses. Bits in the status field indicate whether an exception has occurred since the last response and whether more than one exception has occurred. Commands need not necessarily be sent by an NTP peer, so ordinary access-control procedures may not apply; however, the optional mask/ match mechanism suggested elsewhere in this document provides the capability to control access by mode number, so this could be used to limit access for control messages (mode 6) to selected address ranges. A.1. NTP Control Message Format The format of the NTP Control Message header, which immediately follows the UDP header, is shown in Figure 7. Following is a description of its fields. Bit positions marked as zero are reserved and should always be transmitted as zero. Burbank, et al. Expires September 2, 2006 [Page 28]
Internet-Draft NTPv4 Protocol Specification March 2006 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |00 | VN | 6 | REM | Op | Sequence | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status | Association ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Offset | Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . Data (468 Octets Max) . . . | | Padding (zeros) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authenticator (optional)(96) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7: NTP Control Message Format Version Number (VN): This is a three-bit integer indicating the NTP version number, currently four (4) Mode: This is a three-bit integer indicating the mode. It must have the value 6, indicating an NTP control message. Response Bit (R): Set to zero for commands, one for responses. Error Bit (E): Set to zero for normal response, one for error response. More Bit (M): Set to zero for last fragment, one for all others. Operation Code (Op): This is a five-bit integer specifying the command function. Values currently defined are given in Table 8. Burbank, et al. Expires September 2, 2006 [Page 29]
Internet-Draft NTPv4 Protocol Specification March 2006 +-------+----------------------------------------+ | Value | Meaning | +-------+----------------------------------------+ | 0 | reserved | | 1 | read status command/response | | 2 | read variables command/response | | 3 | write variables command/response | | 4 | read clock variables command/response | | 5 | write clock variables command/response | | 6 | set trap address/port command/response | | 7 | trap response | | 8-31 | reserved | +-------+----------------------------------------+ Table 8: Currently-defined Operation Codes Sequence: This is a 16-bit integer indicating the sequence number of the command or response. Status: This is a 16-bit code indicating the current status of the system, peer or clock, with values coded as described in following sections. Association ID: This is a 16-bit integer identifying a valid association. Offset: This is a 16-bit integer indicating the offset, in octets, of the first octet in the data area. Count: This is a 16-bit integer indicating the length of the data field, in octets. Data: This contains the message data for the command or response. The maximum number of data octets is 468. Authenticator (optional): When the NTP authentication mechanism is implemented, this contains the authenticator information. A.2. Status Words Status words indicate the present status of the system, associations and clock. They are designed to be interpreted by network-monitoring programs and are in one of four 16-bit formats described in this section. System and peer status words are associated with responses for all commands except the read clock variables, write clock variables and set trap address/port commands. The association identifier zero specifies the system status word, while a nonzero identifier specifies a particular peer association. The status word Burbank, et al. Expires September 2, 2006 [Page 30]
Internet-Draft NTPv4 Protocol Specification March 2006 returned in response to read clock variables and write clock variables commands indicates the state of the clock hardware and decoding software. A special error status word is used to report malformed command fields or invalid values. A.2.1. System Status Word The system status word appears in the status field of the response to a read status or read variables command with a zero association identifier. The format of the system status word is given in Figure 8. 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | LI | Clock Source | Count | Code | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ Figure 8: System Status Word Format Leap Indicator (LI): This is a two-bit code warning of an impending leap second to be inserted/deleted in the last minute of the current day, with bit 0 and bit 1, respectively, coded as shown in Table 9. +-------+------------------------------------------+ | Value | Meaning | +-------+------------------------------------------+ | 00 | no warning | | 01 | last minute has 61 seconds | | 10 | last minute has 59 seconds | | 11 | alarm condition (clock not synchronized) | +-------+------------------------------------------+ Table 9: Leap Indicator Field Clock Source: This is a six-bit integer indicating the current synchronization source, with values coded as shown in Table 10. Burbank, et al. Expires September 2, 2006 [Page 31]
Internet-Draft NTPv4 Protocol Specification March 2006 +-------+---------------------------------------------------------+ | Value | Meaning | +-------+---------------------------------------------------------+ | 0 | unspecified or unknown | | 1 | Calibrated atomic clock (e.g.,, HP 5061) | | 2 | VLF (band 4) or LF (band 5) radio (e.g.,, OMEGA,, WWVB) | | 3 | HF (band 7) radio (e.g.,, CHU,, MSF,, WWV/H) | | 4 | UHF (band 9) satellite (e.g.,, GOES,, GPS) | | 5 | local net (e.g.,, DCN,, TSP,, DTS) | | 6 | UDP/NTP | | 7 | UDP/TIME | | 8 | wall time | | 9 | telephone modem (e.g. NIST) | | 10-31 | reserved | | 32 | PPS signal | | 33-63 | reserved | +-------+---------------------------------------------------------+ Table 10: Clock Source Field Values System Event Counter: This is a four-bit integer indicating the number of system exception events occurring since the last time the system status word was returned in a response or included in a trap message. The counter is cleared when returned in the status field of a response and freezes when it reaches the value 15. System Event Code: This is a four-bit integer identifying the latest system exception event, with new values overwriting previous values, and coded as shown in Table 11. +-------+-----------------------------------------------------------+ | Value | Meaning | +-------+-----------------------------------------------------------+ | 0 | unspecified | | 1 | system restart | | 2 | system or hardware fault | | 3 | system new status word (leap bits or synchronization | | | change) | | 4 | system new synchronization source or stratum (sys.peer or | | | sys.stratum) change | | 5 | system clock reset (offset correction exceeds CLOCK.MAX) | | 6 | system invalid time or date | | 7 | system clock exception (see system clock status word) | | 8-15 | reserved | +-------+-----------------------------------------------------------+ Table 11: System Event Code Values Burbank, et al. Expires September 2, 2006 [Page 32]
Internet-Draft NTPv4 Protocol Specification March 2006 A.2.2. Peer Status Word A peer status word is returned in the status field of a response to a read status, read variables or write variables command and appears also in the list of association identifiers and status words returned by a read status command with a zero association identifier. The format of a peer status word is shown in Figure 9. 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | Peer Status | Sel | Count | Code | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ Peer Status Word Figure 9: Peer Status Word Format Peer Status: This is a five-bit code indicating the status of the peer determined by the packet procedure, with bits assigned as shown in Table 12. +-------+------------------------------------------+ | Value | Meaning | +-------+------------------------------------------+ | 0 | configured (peer.config) | | 1 | authentication enabled (peer.authenable) | | 2 | authentication okay (peer.authentic) | | 3 | reachability okay (peer.reach) | | 4 | reserved | +-------+------------------------------------------+ Table 12: Peer Status Values Peer Selection (Sel): This is a three-bit integer indicating the status of the peer determined by the clock-selection procedure, with values coded as shown in Table 13. Burbank, et al. Expires September 2, 2006 [Page 33]
Internet-Draft NTPv4 Protocol Specification March 2006 +-------+-----------------------------------------------------------+ | Value | Meaning | +-------+-----------------------------------------------------------+ | 0 | rejected | | 1 | passed sanity checks | | 2 | passed correctness checks | | 3 | passed candidate checks (if limit check implemented) | | 4 | passed outlyer checks | | 5 | current synchronization source; max distance exceeded (if | | | limit check implemented) | | 6 | current synchronization source; max distance okay | | 7 | reserved | +-------+-----------------------------------------------------------+ Table 13: Peer Selection Field Values Peer Event Counter: This is a four-bit integer indicating the number of peer exception events that occurred since the last time the peer status word was returned in a response or included in a trap message. The counter is cleared when returned in the status field of a response and freezes when it reaches the value 15. Peer Event Code: This is a four-bit integer identifying the latest peer exception event, with new values overwriting previous values, and coded as shown in Table 14. +-------+-----------------------------------------------------------+ | Value | Meaning | +-------+-----------------------------------------------------------+ | 0 | unspecified | | 1 | peer IP error | | 2 | peer authentication failure (peer.authentic bit was one | | | now zero) | | 3 | peer unreachable (peer.reach was nonzero now zero) | | 4 | peer reachable (peer.reach was zero now nonzero) | | 5 | peer clock exception (see peer clock status word) | | 6-15 | reserved | +-------+-----------------------------------------------------------+ Table 14: Peer Event Codes A.2.3. Clock Status Word There are two ways a reference clock can be attached to a NTP service host, as an dedicated device managed by the operating system and as a synthetic peer managed by NTP. As in the read status command, the association identifier is used to identify which one, zero for the system clock and nonzero for a peer clock. Only one system clock is Burbank, et al. Expires September 2, 2006 [Page 34]
Internet-Draft NTPv4 Protocol Specification March 2006 supported by the protocol, although many peer clocks can be supported. A system or peer clock status word appears in the status field of the response to a read clock variables or write clock variables command. This word can be considered an extension of the system status word or the peer status word as appropriate. The format of the clock status word is shown in Figure 10. 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | Clock Status | Code | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ Figure 10: Clock Status Word Format Clock Status: This is an eight-bit integer indicating the current clock status, with values coded as shown in Table 15. +-------+----------------------------+ | Value | Meaning | +-------+----------------------------+ | 0 | clock nominally operating | | 1 | reply timeout | | 2 | bad reply format | | 3 | hardware or software fault | | 4 | propagation failure | | 5 | bad date format or value | | 6 | bad time format or value | | 7-255 | reserved | +-------+----------------------------+ Table 15: Clock Status Values Clock Event Code: This is an eight-bit integer identifying the latest clock exception event, with new values overwriting previous values. When a change to any nonzero value occurs in the radio status field, the radio status field is copied to the clock event code field and a system or peer clock exception event is declared as appropriate. A.2.4. Error Status Word An error status word is returned in the status field of an error response as the result of invalid message format or contents. Its presence is indicated when the E (error) bit is set along with the response (R) bit in the response. It consists of an eight-bit integer coded as shown in Figure 11. Burbank, et al. Expires September 2, 2006 [Page 35]
Internet-Draft NTPv4 Protocol Specification March 2006 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | Error Code | Reserved | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ Figure 11: Error Status Word Format Currently-defined error codes are given in Table 16. +-------+----------------------------------+ | Value | Meaning | +-------+----------------------------------+ | 0 | unspecified | | 1 | authentication failure | | 2 | invalid message length or format | | 3 | invalid opcode | | 4 | unknown association identifier | | 5 | unknown variable name | | 6 | invalid variable value | | 7 | administratively prohibited | | 8-255 | reserved | +-------+----------------------------------+ Table 16: Error Code Values A.3. Commands Commands consist of the header and optional data field of the Status Word. When present, the data field contains a list of identifiers or assignments in the form <<identifier>>[=<<value>>],<<identifier>>[=<<value>>],... where <<identifier>> is the ASCII name of a system or peer variable specified in Table 2 or Table 3 of [1] and <<value>> is expressed as a decimal, hexadecimal or string constant in the syntax of the C programming language. Where no ambiguity exists, the <169>sys.<170> or <169>peer.<170> prefixes shown in Table 2 or Table 4 of [1] can be suppressed. Whitespace (ASCII nonprinting format effectors) can be added to improve readability for simple monitoring programs that do not reformat the data field. Internet addresses are represented as four octets in the form [n.n.n.n], where n is in decimal notation and the brackets are optional. Timestamps, including reference, originate, receive and transmit values, as well as the logical clock, are represented in units of seconds and fractions, preferably in hexadecimal notation, while delay, offset, dispersion and distance values are represented in units of milliseconds and fractions, Burbank, et al. Expires September 2, 2006 [Page 36]
Internet-Draft NTPv4 Protocol Specification March 2006 preferably in decimal notation.All other values are represented as-is, preferably in decimal notation. Implementations may define variables other than those listed in Table 2 or Table 3 of [1]. Called extramural variables, these are distinguished by the inclusion of some character type other than alphanumeric or <169>.<170> in the name. For those commands that return a list of assignments in the response data field, if the command data field is empty, it is expected that all available variables defined in Table 3 or Table 4 of [1] will be included in the response. For the read commands, if the command data field is nonempty, an implementation may choose to process this field to individually select which variables are to be returned. Commands are interpreted as follows: Read Status (1): The command data field is empty or contains a list of identifiers separated by commas. The command operates in two ways depending on the value of the association identifier. If this identifier is nonzero, the response includes the peer identifier and status word. Optionally, the response data field may contain other information, such as described in the Read Variables command. If the association identifier is zero, the response includes the system identifier (0) and status word, while the data field contains a list of binary-coded pairs <<association identifier>> <<status word>>, one for each currently defined association. Read Variables (2): The command data field is empty or contains a list of identifiers separated by commas. If the association identifier is nonzero, the response includes the requested peer identifier and status word, while the data field contains a list of peer variables and values as described above. If the association identifier is zero, the data field contains a list of system variables and values. If a peer has been selected as the synchronization source, the response includes the peer identifier and status word; otherwise, the response includes the system identifier (0) and status word. Write Variables (3): The command data field contains a list of assignments as described above. The variables are updated as indicated. The response is as described for the Read Variables command. Read Clock Variables (4): The command data field is empty or contains a list of identifiers separated by commas. The association Burbank, et al. Expires September 2, 2006 [Page 37]
Internet-Draft NTPv4 Protocol Specification March 2006 identifier selects the system clock variables or peer clock variables in the same way as in the Read Variables command. The response includes the requested clock identifier and status word and the data field contains a list of clock variables and values, including the last timecode message received from the clock. Write Clock Variables (5): The command data field contains a list of assignments as described above. The clock variables are updated as indicated. The response is as described for the Read Clock Variables command. Set Trap Address/Port (6): The command association identifier, status and data fields are ignored. The address and port number for subsequent trap messages are taken from the source address and port of the control message itself. The initial trap counter for trap response messages is taken from the sequence field of the command. The response association identifier, status and data fields are not significant. Implementations should include sanity timeouts which prevent trap transmissions if the monitoring program does not renew this information after a lengthy interval. Trap Response (7): This message is sent when a system, peer or clock exception event occurs. The opcode field is 7 and the R bit is set. The trap counter is incremented by one for each trap sent and the sequence field set to that value. The trap message is sent using the IP address and port fields established by the set trap address/port command. If a system trap the association identifier field is set to zero and the status field contains the system status word. If a peer trap the association identifier field is set to that peer and the status field contains the peer status word. Optional ASCII-coded information can be included in the data field. Burbank, et al. Expires September 2, 2006 [Page 38]
Internet-Draft NTPv4 Protocol Specification March 2006 Authors' Addresses Jack Burbank (editor) The Johns Hopkins University Applied Physics Laboratory 11100 Johns Hopkins Road Laurel, MD 20723-6099 US Phone: +1 443 778 7127 Email: jack.burbank@jhuapl.edu Jim Martin (editor) Netzwert AG An den Treptowers 1 Berlin 12435 Germany Phone: +49.30/5 900 80-1180 Email: jim@netzwert.ag Dr. David L. Mills University of Delaware Newark, DE 19716 US Phone: +1 302 831 8247 Email: mills@udel.edu Burbank, et al. Expires September 2, 2006 [Page 39]
Internet-Draft NTPv4 Protocol Specification March 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Burbank, et al. Expires September 2, 2006 [Page 40]
