Network Time Protocol Working J. Burbank (Editor) Group JHU/APL Internet-Draft J. Martin (co-Editor) Expires: January 9, 2006 Netzwert AG July, 2005 The Network Time Protocol Version 4 Protocol Specification Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3978. 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 document is a submission of the IETF NTP WG. Comments should be directed to the NTP WG mailing list, ntpwg@lists.ntp.isc.org. This Internet-Draft will expire on January 9, 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. NTPv4 also includes optional extensions to the NTPv3 protocol,including an anycast mode and an authentication scheme designed specifically for multicast and anycast modes. Burbank, et al. Expires January 9, 2006 [Page 1] Internet-Draft NTPv4 Protocol Specification June 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. NTPv4 Protocol Operation . . . . . . . . . . . . . . . . . . . 4 3. NTPv4 Timestamp Format . . . . . . . . . . . . . . . . . . . . 6 4. NTPv4 Message Formats . . . . . . . . . . . . . . . . . . . . 7 5. NTPv4 Client Operations . . . . . . . . . . . . . . . . . . . 13 6. NTPv4 Server Operations . . . . . . . . . . . . . . . . . . . 15 7. NTPv4 Security . . . . . . . . . . . . . . . . . . . . . . . . 19 7.1 Session Keys and Cookies . . . . . . . . . . . . . . . . . 19 7.2 Session Key List Generation . . . . . . . . . . . . . . . 20 7.3 Sending Messages . . . . . . . . . . . . . . . . . . . . . 20 7.4 Receiving Messages . . . . . . . . . . . . . . . . . . . . 20 7.5 Autokey Protocol Exchanges . . . . . . . . . . . . . . . . 20 8. Operation and Management Issues . . . . . . . . . . . . . . . 22 9. Kiss o' Death Message . . . . . . . . . . . . . . . . . . . . 22 10. Security Considerations . . . . . . . . . . . . . . . . . . . 24 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 12. Other Considerations . . . . . . . . . . . . . . . . . . . . . 25 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 14.1 Normative References . . . . . . . . . . . . . . . . . . 27 14.2 Informative References . . . . . . . . . . . . . . . . . 27 15. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 28 Intellectual Property and Copyright Statements . . . . . . . . 29 Burbank, et al. Expires January 9, 2006 [Page 2] Internet-Draft NTPv4 Protocol Specification June 2005 1. Introduction The Network Time Protocol Version 3 (NTPv3) specified in RFC 1305 [MIL92] 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 of 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 and over a wide range of network jitter and clock frequency wander characteristics. Many users of NTP in the Internet of today use a software distribution available from www.ntp.org. The distribution, which includes the full suite of NTP options, mitigation algorithms and security schemes, is a relatively complex, real-time application. While the software has been ported to a wide variety of hardware platforms ranging from personal computers to supercomputers, its sheer size and complexity is not appropriate for many applications. This facilitated the development of the Simple Network Time Protocol Version 4 (SNTPv4) as described in RFC 2030 [MIL96]. 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 2030 (SNTPv4 is a subset of NTPv4). 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 roundtrip 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 and OSI 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 Burbank, et al. Expires January 9, 2006 [Page 3] Internet-Draft NTPv4 Protocol Specification June 2005 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 used as in [ISO86]. 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 RFC-1240 [DOB91]. It is not advised that NTP be operated at the upper layers of the OSI stack, such as might be inferred from RFC-1698 [FUR94], 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. In the following, indented paragraphs such as this one contain information not required by the formal protocol specification, but considered good practice in protocol implementations. This document is organized as follows. Section 2 describes how the protocol works, the various modes and how IP addresses and UDP ports are used. Section 3 describes the NTP timestamp format and Section 4 the NTP message format. Section 5 summarizes NTP client operations and Section 6 summarizes NTP server operations. Section 7 summarizes the optional security mechanisms present within the NTPv4 protocol. Section 8 summarizes operation and management issues. Section 9 describes the kiss-o'-death message, whose functionality is similar to the ICMP Source Quench and ICMP Destination Unreachable messages. Section 10 presents NTPv4 security considerations. Section 11 presents various other considerations when implementing and/or configuring NTPv4. NTPv4 is hereafter referred to simply as NTP, unless explicitly noted. 2. NTP Protocol Operation Unless excepted in context, reference to broadcast address means IPv4 broadcast address, IPv4 multicast group address or IPv6 site-local scope address. Further information on the broadcast/multicast model is in RFC 1112 [DEE89]. Details of address format, scoping rules, etc., are beyond the scope of this memo. NTPv4 can operate with either unicast (point to point), broadcast (point to multipoint) or anycast (multipoint to point) addressing modes. A unicast client sends a request to a designated server at its unicast address and expects a reply from which it can determine the time and, optionally, Burbank, et al. Expires January 9, 2006 [Page 4] Internet-Draft NTPv4 Protocol Specification June 2005 the roundtrip delay and clock offset relative to the server. A broadcast server periodically sends an unsolicited message to a designated broadcast address. A broadcast client listens on this address and ordinarily sends no requests. Anycast is designed for use with a set of cooperating servers whose addresses are not known beforehand. The anycast client sends an ordinary NTP client request to a designated broadcast address. One or more anycast servers listen on that address. Upon receiving a request, an anycast server sends an ordinary NTP server reply to the client. The client then binds to the server from which the first such message was received and continues operation with that unicast addresses. Subsequent replies from other anycast servers are ignored. 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. The client and server addresses are assigned following the usual IPv4, IPv6 or OSI conventions. For NTP multicast, the IANA has reserved the IPv4 group address 224.0.1.1 and the IPv6 group address ending :101, with prefix determined by scoping rules. The NTP broadcast address for OSI has yet to be determined. Notwithstanding the IANA reserved addresses, other multicast addresses can be used which do not conflict with others assigned in scope. In the case of IPv4 multicast or IPv6 broadcast addresses, the client must implement the Internet Group Management Protocol (IGMP) as described in RFC- 3376 [CAIN02], in order that the local router joins the multicast group and relays messages to the IPv4 or IPv6 multicast group. The scoping, routing and group membership procedures are determined by considerations beyond the scope of this memo. It is important to adjust the time-to-live (TTL) field in the IP header of multicast messages to a reasonable value in order to limit the network resources used by this (and any other) multicast service. Only multicast clients in scope will receive multicast server messages. Only cooperating anycast servers in scope will reply to a client request. The engineering principles which determine the proper values to be used are beyond the scope of this memo. While not integral to the NTP specification, it is intended that IP broadcast addresses will be used primarily in IP subnets and LAN segments including a fully functional NTP server with a number Burbank, et al. Expires January 9, 2006 [Page 5] Internet-Draft NTPv4 Protocol Specification June 2005 of dependent NTP broadcast clients on the same subnet, while IP multicast group addresses will be used only in cases where the TTL is engineered specifically for each service domain. 3. NTP Timestamp NTPv4 uses the standard NTP timestamp format described in RFC-1305. 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. NTP timestamps are represented as a 64-bit unsigned fixed-point number, in seconds relative to 0h on 1 January 1900. The integer part is in the first 32 bits and the fraction part in the last 32 bits. In the fraction part, the non-significant low order bits are not specified and ordinarily set to 0. The NTP timestamp format is as shown in Figure 1. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1. NTP Timestamp Format It is advisable to fill the non-significant low order bits of the timestamp with a random, unbiased bitstring, both to avoid systematic roundoff errors and as a means of loop detection and replay detection (see below). It is important that the bitstring be unpredictable by a intruder. One way of doing this is to generate a random 128-bit bitstring at startup. After that, each time the system clock is read the string consisting of the timestamp and bitstring is hashed with the MD5 algorithm, then the non-significant bits of the timestamp are copied from the result. The NTP format allows convenient multiple-precision arithmetic and conversion to UDP/TIME message (seconds), but does complicate the conversion to ICMP Timestamp message (milliseconds) and Unix time values (seconds and microseconds or seconds and nanoseconds). The maximum number that can be represented is 4,294,967,295 seconds with a precision of about 232 picoseconds, which should be adequate for even the most exotic requirements. Burbank, et al. Expires January 9, 2006 [Page 6] Internet-Draft NTPv4 Protocol Specification June 2005 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 reckoned from 6h 28m 16s UTC on 7 February 2036. Note that when calculating the correspondence, 2000 is a leap year and leap seconds are not included in the reckoning. 4. NTP Message Formats Both NTP and SNTP are clients of the User Datagram Protocol (UDP) [POS80], which itself is a client of the Internet Protocol (IP) [DAR81] [DER98]. 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 should 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. Below is a description of the NTPv4 message format, which follows the IP and UDP headers. This format is identical to that described in RFC 1305, with the exception of the contents of the reference identifier field. The header fields are defined in Figure 2. 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 causes the number of seconds (rollover interval) in the day of insertion to be increased or decreased by one. In the case of primary servers the bits are set by operator intervention, while in the case of secondary servers the bits are set by the protocol. The possible values of the LI field, and corresponding meanings, are as follows: LI Meaning --------------------------------------------- 0 no warning 1 last minute has 61 seconds 2 last minute has 59 seconds) 3 alarm condition (clock not synchronized) On startup, servers set this field to 3 (clock not synchronized) and set this field to some other value when synchronized to the Burbank, et al. Expires January 9, 2006 [Page 7] Internet-Draft NTPv4 Protocol Specification June 2005 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. 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 NTP Message Format Burbank, et al. Expires January 9, 2006 [Page 8] Internet-Draft NTPv4 Protocol Specification June 2005 Version (VN): This is a three-bit integer indicating the NTP/SNTP version number, currently 4. If necessary to distinguish between IPv4, IPv6 and OSI, the encapsulating context must be inspected. Mode: This is a three-bit number indicating the protocol mode. The values are defined as follows: Mode Meaning ------------------------------------ 0 reserved 1 symmetric active 2 symmetric passive 3 client 4 server 5 broadcast 6 reserved for NTP control message 7 reserved for private use In unicast and anycast modes, 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). 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 as follows: Stratum Meaning ---------------------------------------------- 0 kiss-o'-death message 1 primary reference (e.g., synchronized by radio clock) 2-15 secondary reference (synchronized by NTP or SNTP) 16-255 reserved Poll Interval (Poll): This is an eight-bit unsigned integer used as an exponent of two, where the resulting value is the maximum interval between successive messages in seconds. This field is significant only in SNTP server messages, where the values range from 4 (16 s) to 17 (131,072 s - about 36 h). Burbank, et al. Expires January 9, 2006 [Page 9] Internet-Draft NTPv4 Protocol Specification June 2005 Precision (Prec): This is an eight-bit signed integer used as an exponent of two, where the resulting value is the precision of the system clock in seconds. This field is significant only in server messages, where the values range from -6 for mains-frequency clocks to -20 for microsecond clocks found in some workstations. Root Delay: This is a 32-bit signed fixed-point number indicating the total roundtrip delay to the primary reference source, in seconds with fraction point between bits 15 and 16. Note that this variable can take on both positive and negative values, depending on the relative time and frequency 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. Root Dispersion: This is a 32-bit unsigned fixed-point number indicating the nominal error relative to the primary reference source, in seconds with fraction point between bits 15 and 16. This field is significant only in server messages, where the values range from zero to several hundred milliseconds. Reference Identifier: This is a 32-bit bitstring identifying the particular reference source. This field is significant only in server messages, where for stratum 0 (kiss-o'-death message) and 1 (primary server), the value is a four-character ASCII string, left justified and zero padded to 32 bits. 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. Burbank, et al. Expires January 9, 2006 [Page 10] Internet-Draft NTPv4 Protocol Specification June 2005 Primary (stratum 1) servers set this field to a code identifying the external reference source according to the below table. Code External Reference Source ---------------------------------------------------------------- LOCL uncalibrated local clock CESM calibrated Cesium clock RBDM calibrated Rubidium clock PPS calibrated quartz clock or other pulse-per-second source IRIG Inter-Range Instrumentation Group ACTS NIST telephone modem service USNO USNO telephone modem service PTB PTB (Germany) telephone modem service TDF Allouis (France) Radio 164 kHz DCF Mainflingen (Germany) Radio 77.5 kHz MSF Rugby (UK) Radio 60 kHz WWV Ft. Collins (US) Radio 2.5, 5, 10, 15, 20 MHz WWVB Boulder (US) Radio 60 kHz WWVH Kaui Hawaii (US) Radio 2.5, 5, 10, 15 MHz CHU Ottawa (Canada) Radio 3330, 7335, 14670 kHz LORC LORAN-C radionavigation system OMEG OMEGA radionavigation system GPS Global Positioning Service If the external reference is one of those listed, the associated code should be used. Codes for sources not listed can be contrived as appropriate. In previous NTP and SNTP secondary servers and clients this field was often used to walk-back the synchronization subnet to the root (primary server) for management purposes. Reference Timestamp: This field is significant only in server messages, where the value is the time at which the system clock was last set or corrected, in 64-bit timestamp format. Originate Timestamp: This is the time at which the request departed the client for the server, in 64-bit timestamp format. Receive Timestamp: This is the time at which the request arrived at the server or the reply arrived at the client, in 64-bit timestamp format. Burbank, et al. Expires January 9, 2006 [Page 11] Internet-Draft NTPv4 Protocol Specification June 2005 Transmit Timestamp: This is the time at which the request departed the client or the reply departed the server, in 64-bit timestamp format. NTPv4 Extension Fields: NTPv4 defines new extension field formats. These fields are processed in order and may be transmitted with or without value fields. The last field is padded to a 64-bit boundary, all others fields are padded to 32-bit boundaries. The field length is for all payload and padding. 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 NTPv4 Extension Field Burbank, et al. Expires January 9, 2006 [Page 12] Internet-Draft NTPv4 Protocol Specification June 2005 Authentication (optional): The authentication field format is shown in 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 Optional Authentication Field When the NTP authentication scheme is implemented, the 16-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. 5. NTP Client Operations An NTP client can operate in unicast, broadcast or anycast 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. In anycast mode, the client sends a request (NTP mode 3) to a designated broadcast address and expects a reply (NTP mode 4) from one or more anycast servers. The client uses the first reply received to establish the particular server for subsequent unicast operations. Later replies from this server (duplicates) or any other server are ignored. Other than the selection of address in the request, the operations of anycast and unicast clients are identical. Client requests are normally sent at intervals depending on the frequency tolerance of the client clock and the required accuracy. However, under no conditions should requests be sent at less than one minute intervals. Further discussion on this point is in Section 9. Burbank, et al. Expires January 9, 2006 [Page 13] Internet-Draft NTPv4 Protocol Specification June 2005 A unicast or anycast 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 above 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 and anycast 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 RFC 1119 [MIL89], and NTPv1 as defined in RFC 1059 [MIL88]. NTPv0 defined in RFC 959 [MIL85] is not supported. In unicast and anycast modes, 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 a simple calculation to determine the propagation delay between the server and client and to align the system clock generally within a few tens of milliseconds 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. In broadcast mode, the client has no information to calculate the propagation delay or determine the validity of the server, unless one of the NTP authentication schemes is used. The following table summarizes the required NTP client operations in unicast, anycast and broadcast modes. The recommended error checks are shown in the Reply and Broadcast columns in the table. The message should be considered valid only if all the fields shown contain values in the respective ranges. Whether to believe the message if one or more of the fields marked "ignore" contain invalid values is at the discretion of the implementation. Burbank, et al. Expires January 9, 2006 [Page 14] Internet-Draft NTPv4 Protocol Specification June 2005 Field Name Unicast/Anycast Broadcast Request Reply --------------------------------------------------------------- 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 Identifier 0 ignore ignore Reference Timestamp 0 ignore ignore Originate Timestamp 0 (see text) ignore Receive Timestamp 0 (see text) ignore Transmit Timestamp (see text) nonzero nonzero Authenticator optional optional optional [Need to add a similar table for symmetric modes of operation] 6. NTP Server Operations An NTP server operating with either an NTP or SNTP client of the same or previous versions retains no persistent state. Since a SNTP server ordinarily does not implement the full suite of grooming and mitigation algorithms intended to support redundant servers and diverse network paths, a SNTP server should be operated only in conjunction with a source of external synchronization, such as a reliable radio clock or telephone modem. In this case it operates as a primary (stratum 1) server. Burbank, et al. Expires January 9, 2006 [Page 15] Internet-Draft NTPv4 Protocol Specification June 2005 An NTP server can operate with any unicast, anycast or broadcast address or any combination of these addresses. A unicast or anycast server receives a request (NTP mode 3), modifies certain fields in the NTP header, and sends a reply (NTP mode 4), possibly using the same message buffer as the request. A anycast server listens on the designated broadcast address, but uses its own unicast IP address in the source address field of the reply. Other than the selection of address in the reply, the operations of anycast and unicast servers are identical. Broadcast messages are normally sent at poll intervals from 64 s to 1024 s, depending on the expected frequency tolerance of the client clocks and the required accuracy. Unicast and anycast servers copy the VN and Poll fields of the request intact to the reply and set the Stratum field to 1. Note that SNTP servers normally operate as primary (stratum 1) servers. While operating at higher strata (up to 15) and at the same time synchronizing to an external source such as a GPS receiver is not forbidden, this is strongly discouraged. If the Mode field of the request is 3 (client), the reply is set to 4 (server). If this field is set to 1 (symmetric active), the reply is set to 2 (symmetric passive). This allows clients configured in either client (NTP mode 3) or symmetric active (NTP mode 1) to interoperate successfully, even if configured in possibly suboptimal ways. For any other value in the Mode field, the request is discarded. In broadcast (unsolicited) mode, the VN field is set to 4, the Mode field is set to 5 (broadcast), and the Poll field set to the nearest integer base-2 logarithm of the poll interval. Note that it is highly desirable that a broadcast server also supports unicast clients. This is so a potential broadcast client can calculate the propagation delay using a client/server exchange prior to switching to broadcast client (listen-only) mode. A anycast server by design also is a unicast server. There does not seem to be a great advantage for a server to operate as both broadcast and anycast at the same time, although the protocol specification does not forbid it. A broadcast or anycast server may or may not respond if not synchronized to a correctly operating reference source, but the preferred option is to respond, since this allows reachability to be determined regardless of synchronization state. If the server has never synchronized to a reference source, the LI field is set to 3 (unsynchronized). Once synchronized to a reference source, 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. Burbank, et al. Expires January 9, 2006 [Page 16] Internet-Draft NTPv4 Protocol Specification June 2005 If synchronized to a reference source the Stratum field is set to 1 and the Reference Identifier field is set to the ASCII source identifier shown in Figure 2. If not synchronized, the Stratum field is set to zero and the Reference Identifier field set to an ASCII error identifier described below. In broadcast mode, the server sends broadcasts only if synchronized to a correctly operating reference source. The Precision field is set to reflect the maximum reading error of the system clock. For all practical cases it is computed as the negative base-2 logarithm of the number of significant bits to the right of the decimal point in the NTP timestamp format. 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 expected error of the radio clock itself. 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 message is a reply to a previously received client request, the Transmit Timestamp field of the request is copied unchanged to the Originate Timestamp field of the reply. It is important that this field be copied intact, as an NTP or SNTP client uses it to avoid bogus messages. 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 are 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. The following table summarizes these actions. Burbank, et al. Expires January 9, 2006 [Page 17] Internet-Draft NTPv4 Protocol Specification June 2005 Field Name Unicast/Anycast Broadcast Request Reply ---------------------------------------------------------------- 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 significant bits bits Root Delay ignore 0 0 Root Dispersion ignore 0 0 Reference Identifier ignore source ident source ident Reference Timestamp ignore time of last time of last source update source update Originate Timestamp ignore copied from 0 transmit timestamp Receive Timestamp ignore time of day 0 Transmit Timestamp (see text) time of day time of day Authenticator optional optional optional [Need to add a similar table for symmetric modes of operation] 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. Burbank, et al. Expires January 9, 2006 [Page 18] Internet-Draft NTPv4 Protocol Specification June 2005 7. NTPv4 Security NTPv4 employs the Autokey security protocol, which works independently for each client, with tentative outcomes confirmed only after both succeed. Public keys and certificates are obtained and verified relatively infrequently using X.509 certificates and certificate trails. Session keys are derived from public keys. Each NTP message is individually authenticated using the session key and the message digest (keyed MD5). A proventic trail is a sequence of NTP servers each synchronized and cryptographically veritifed to the next lower stratum server and ending on one or more trusted servers. Proventic trails are constructed from each server to the trusted servers at decreasing stratum levels. When server time and at least one proventic trail are verified, the peer is admitted to the population and used to synchronize the system clock. 7.1 Session Keys and Cookies NTPv4 session keys have four 32-bit words, as shown in Figure 5. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cookie | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5. NTPv4 Session Key Format The session key value is the 16-octet MD5 message digest of the session key. Key IDs have pseudo-random values and are used only once. A special key ID value of zero is used as a NAK reply. In multicast mode, and in any message including an extension field, the cookie has a public value (zero). In client/server modes, the cookie is a hash of the addresses and a private value. In symmetric modes, the cookie is a random roll. In the event that both peers generate cookies, the agreed-upon cookie is the exclusive-OR of the two values. The server generates a cookie unique to the client and server addresses and its own private value. It returns the cookie, signature, and timestampe to the client in an extension field. The cookie is transmitted from server to client encrypted by the client public key. The server uses the cookie to validate requests and construct replies. The client uses the cookie to validate the reply and checks that the request key ID matches the reply key ID. Burbank, et al. Expires January 9, 2006 [Page 19] Internet-Draft NTPv4 Protocol Specification June 2005 7.2 Session Key List Generation The server rolls a random 32-bit seed as the initial key ID and selects the cookie. Messages with a zero cookie contain only public values. The initial session key is constructed using the given addressses, cookie and initial key ID. The session key value is stored in the key cache. The next session key is constructed using the first four octets of the session key value as the new key ID. The server continues to generate the full list. The final index number and last key ID are provided in an extension field with signature and timestamp. 7.3 Sending Messages The MAC consists of the MD5 message digest of the NTP header and extension fields using the session key ID and value stored in the key cache. The server uses the session key ID list in reverse order and discards each key value after use. An extension field containing the last index number and key ID is included in the first packet transmitted (last on the list). This extension field can be provided upon request at any time. When all entries in the key list are used, a new one is generated. 7.4 Receiving Messages The intent is not to hide the message contents. Rather, the goal is to verify its source and that it has not been modified in transit. The MAC message digest is compared with the computed digest of the NTP header and extension fields using the session key ID in the MAC and the key value computed from the addresses, key ID and cookie. If the cookie is zero, the message contains public values. Anybody can validate the message or make a valid message containing any values. If the cookie has been determined by secret means, nobody except the parties to the secret can validate a message or make a valid message. 7.5 Autokey Protocol Exchanges There are five types of Autokey protocol exchanges: 1. Parameter Exchange (ASSOC message): This message exchanges host names, agrees on digest/signature and identity schemes. This protocol exchange is unsigned. Optionally, host name/address can be verified using reverse-DNS. An initial association request is sent by the client, sending the host name and status word Burbank, et al. Expires January 9, 2006 [Page 20] Internet-Draft NTPv4 Protocol Specification June 2005 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Digest/Signature NID | Client | Ident | Host | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6 Status Word Format If the server digest NID and ID scheme agree, the server responds with an association response message, sending host name and status word. The client, upon agreeing with digest NID and ID scheme, then sends a certificate request. The server responds with an X.509 certificate and signature. The certificate request/response cycle repeats as needed. A primary (Stratum 1) certifcate is explicitly trusted and self-signed. Secondary certificates are signed by the next lower stratum server and validated with its public key. 2. Certificate Exchange (CERT message): This exchange is used to obtain and verify certificates on the trail to a trusted root certificate. Certificate exchanges follow the same process as parameter exchanges. 3. Identity Exchange (IFF, GW, and MV messages): This exchange is used to verify server identity using an agreed identity scheme (TC, IFF, GQ, MV). This exchange is a challenge-response scheme. The client initiates by sending a challenge request. The server then provides the challenge response. 4. Values Exchange (COOKIE and AUTO messages): This exchange is used to obtain and verify the cookie, autokey values, and leapseconds table, depending on the association mode (client-server, broadcast, symmetric). For cookie exchanges, the client sends its public key to the server without signature when not synchronized. Symmetric active peers send its public key and signature to passive peer when synchronized. The server cookie is encrypted from the hash of source/destination addresses, zero key ID, and server private value. A symmetric passive cookie is a random value for every exchange. The server private value is refreshed and protocol restarted once per day. For autokey exchanges, the server generates a key list and signature is calculated to last about one hour. A client sends requests to the server without signature when not synchronized. The server replies with the last index number and key ID on the list. Broadcast servers uses AUTO response for the first message after regenerating the key and ASSOC responses for all other messages. Burbank, et al. Expires January 9, 2006 [Page 21] Internet-Draft NTPv4 Protocol Specification June 2005 5. Signature Exchange (SIGN message): This exchange requests the server to sign and return a client certificate. The exchange is valid only when the client has synchronized to a proventic source and the server identity has been confirmed. This exchange is used to authenticate clients to servers, with the server acting as de facto certificate authority using an encrypted credential scheme. The client sends a certificate to the server with or without signature. The server extracts the requested data and signs that data with the server private key. The client then verifies the certificate and signature. Subsequently, the client supplies this certificate rather than self-signed certificates, so clients can verify with the server public key. 8. Configuration and Management The means used in the configuration and management of NTP servers and clients is the NTP control and monitoring protocol defined in RFC 1305. Unicast clients must be provided with one or more designated server names or IP addresses. If more than one server is provided, one can be used for active operation and one of the others for backup should the active one fail or show an error condition. It is not normally useful to use more than one server at a time, as with millions of NTP-enabled devices expected in the near future, such use could result in unnecessary strain on network and server resources. Broadcast servers and anycast clients must be provided with the TTL and local broadcast or multicast group address. Unicast and anycast servers and broadcast clients may be configured with a list of address-mask pairs for access control, so that only those clients or servers known to be trusted will be accepted. Multicast servers and clients must implement the IGMP protocol and be provided with the local broadcast or multicast group address as well. The configuration data for cryptographic authentication is beyond the scope of this memo. There are several scenarios which provide automatic server discovery and selection for NTP clients with no pre-specified server configuration. For instance a role server with CNAME such as pool.ntp.org returns a randomized list of volunteer secondary server addresses and the client can select one or more as candidates. For an IP subnet or LAN segment including a NTP or SNTP server, NTP clients can be configured as broadcast clients. The same approach can be used with multicast servers and clients. In both cases, provision of an access control list is a good way to insure only trusted sources can be used to set the system clock. Burbank, et al. Expires January 9, 2006 [Page 22] Internet-Draft NTPv4 Protocol Specification June 2005 In another scenario suitable for an extended network with significant network propagation delays, clients can be configured for anycast addresses, both upon initial startup and after some period when the currently selected unicast source has not been heard. Following the defined protocol, the client binds to the server from which the first reply is received and continues operation in unicast mode. 9. The Kiss-o'-Death Packet In the interest of self-preservation, it is important that NTP servers have a mechanism to supress or otherwise influence the amount of queries performed by NTP clients. According to the NTPv3 specification RFC 1305, 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 RFC 1305 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 in the following table. Burbank, et al. Expires January 9, 2006 [Page 23] Internet-Draft NTPv4 Protocol Specification June 2005 Code Meaning -------------------------------------------------------------- ACST The association belongs to a anycast 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 manycast 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 Somebody is tinkering with the association from a remote host running ntpdc. Not to worry unless some rascal has stolen your keys STEP A step change in system time has occurred, but the association has not yet resynchronized 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 retransmit using an exponential-backoff algorithm described in Section 11. 10. Security Considerations In the case of NTP as specified herein, there is a very real vulnerability that NTP broadcast clients can be disrupted by misbehaving or hostile SNTP or NTP broadcast servers elsewhere in the Internet. It is strongly recommended that access controls and/or cryptographic authentication means 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: 1. When the IP source and destination addresses are available for the client request, they should match the interchanged addresses in the server reply. Burbank, et al. Expires January 9, 2006 [Page 24] Internet-Draft NTPv4 Protocol Specification June 2005 2. When the UDP source and destination ports are available for the client request, they should match the interchanged ports in the server reply. 3. The Originate Timestamp in the server reply should match the Transmit Timestamp used in the client request. 4. The server reply should be discarded if any of the LI, Stratum, or Transmit Timestamp fields are 0 or the Mode field is not 4 (unicast) or 5 (broadcast). 5. A truly paranoid 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 currently a cozy number like 16 seconds. This check avoids using a server whose synchronization source has expired for a very long time. 11. IANA Considerations 12. Other Considerations NTP and SNTP clients can consume considerable network and server resources if not "good network citizens." There are now consumer Internet commodity devices numbering in the millions that are potential customers of public and private NTP and SNTP servers. Recent experience strongly suggests that device designers pay particular attention to minimizing resource impacts, especially if large numbers of these devices are deployed. The most important design consideration is the interval between client requests, called the poll interval. It is extremely important that the design use the maximum poll interval consistent with acceptable accuracy. 1. A client MUST NOT use a poll interval less than TBD minutes. 2. A client SHOULD increase the poll interval using exponential backoff as performance permits and especially if the server does not respond within a reasonable time. 3. A client SHOULD use local servers whenever available to avoid unnecessary traffic on backbone networks. 4. A client MUST allow the operator to configure the primary and/or alternate server names or addresses in addition to or in place of a firmware default IP address. 5. If a firmware default server IP address is provided, it MUST be a server operated by the manufacturer or seller of the device or another server, but only with the operator's permission. Burbank, et al. Expires January 9, 2006 [Page 25] Internet-Draft NTPv4 Protocol Specification June 2005 6. A client SHOULD use the Domain Name System (DNS) to resolve the server IP addresses, so the operator can do effective load balancing among a server clique and change IP address binding to canonical names. 7. A client SHOULD re-resolve the server IP address on a periodic intervals, but not less than the time-to-live field in the DNS response. 8. A client SHOULD support the NTP access-refusal mechanism, so that a server kiss-o'-death reply in response to a client request causes the client to cease sending requests to that server and to switch to an alternate, if available. If the firmware or documentation includes specific server names, the names should be those the manufacturer or seller operates as a customer convenience or those for which specific permission has been obtained from the operator. A DNS request for a generic server name such as ntp.mytimeserver.com results should result in a random selection of server IP addresses available for that purpose. Each time a DNS request is received, a new randomized list is returned. The client ordinarily uses the first address on the list. When selecting candidate SNTP or NTP servers, it is imperative to respect the server operator's conditions of access. Lists of public servers and their conditions of access are available at www.ntp.org. A semi-automatic server discovery scheme using DNS is described at that site. Some ISPs operate public servers, although finding them via their helpdesks can be difficult. A well behaved client operates as follows (note that steps 2 - 4 comprise a synchronization loop): 1. Consider the specified frequency tolerance of the system clock oscillator. Define the required accuracy of the system clock, then calculate the maximum timeout. For instance, if the frequency tolerance is 200 parts-per-million (PPM) and the required accuracy is one minute, the maximum timeout is about 3.5 days. Use the longest maximum timeout possible given the system constraints to minimize time server aggregate load, but never less than 15 minutes. 2. When first coming up or after reset, randomize the timeout from one to five minutes. This is to minimize shock when 3000 PCs are rebooted at the same time power is restored after a blackout. Assume at this time the IP address is unknown and the system clock is unsynchronized. Otherwise use the timeout value as calculated in previous loop steps. Note that it may be necessary to refrain from implementing the aforementioned random delay for some classes of ICSA certification. Burbank, et al. Expires January 9, 2006 [Page 26] Internet-Draft NTPv4 Protocol Specification June 2005 3. When the timer reaches zero, if the IP address is not known, send a DNS query packet; otherwise send a NTP request packet to that address. If no reply packet has been heard since the last timeout, double the timeout, but not greater than the maximum timeout. If primary and secondary time servers have been configured, alternate queries between the primary and secondary servers when no successful response has been received. 4. If a DNS reply packet is received, save the IP address and continue in step 2. If a KoD packet is received remove that time server from the list, activate the secondary time server and continue in step 2. If a received packet fails the sanity checks, drop that packet and also continue in step 2. If a valid NTP packet is received, update the system clock, set the timeout to the maximum, and continue to step 2. 13. Acknowledgements This document has drawn significant material from the document . As a result, the authors would like to acknowledge D. Plonka of the University of Wisconsin and J. Montgomery of Netgear, who were significant contributors to that draft. 14. References 14.1 Normative References [MIL92] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation", RFC 1305, March 1992. [MIL96] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6, and OSI", RFC 2030, October 1996. 14.2 Informative References [CAIN02] Cain, B., Deering, S., Kouvalas, I., Fenner, B. and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, Cereva Networks, October 2002. [DAR81] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [DEE89] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989. [DER98] Deering, S., Hinden R., "Internet Protocol, Version 6 (IPv6)," RFC 2460, December 1998. Burbank, et al. Expires January 9, 2006 [Page 27] Internet-Draft NTPv4 Protocol Specification June 2005 [DOB91] Dobbins, K, Haggerty, W. and C. Shue, "OSI connectionless transport services on top of UDP - Version: 1", RFC 1240, June 1991. [ISO86] International Standards 8602 - Information Processing Systems - OSI: Connectionless Transport Protocol Specification. International Standards Organization, December 1986. [MIL85] Mills, D., "Network Time Protocol (NTP)", RFC 958, September 1985. [MIL88] Mills, D., "Network Time Protocol (Version 1) Specification and Implementation", RFC 1059, July 1988. [MIL89] Mills, D., "Network Time Protocol (Version 2) Specification and Implementation," RFC 1119, September 1989. [POS80] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980. 15. Authors' Addresses Jack L. Burbank (Editor) The Johns Hopkins University Applied Physics Laboratory (JHU/APL) 11100 Johns Hopkins Road Laurel, MD 20723 Phone: +1 443-778-7127 EMail: jack.burbank@jhuapl.edu Jim Martin (co-Editor) Netzwert AG An den Treptowers 1 D-12435 Berlin Phone: +49.30/5 900 800-180 EMail: jim@Netzwert.AG Dr. David L. Mills The University of Delaware Electrical Engineering Department University of Delaware Newark, DE 19716 Phone: (302) 831-8247 EMail: mills@udel.edu Burbank, et al. Expires January 9, 2006 [Page 28] Internet-Draft NTPv4 Protocol Specification June 2005 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 (2005). 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 January 9, 2006 [Page 29]