Network Working Group                                           D. MillsRequest for Comments: 1769                        University of DelawareObsoletes: 1361                                               March 1995Category: Informational                  Simple Network Time Protocol (SNTP)Status of this Memo   This memo provides information for the Internet community.  This memo   does not specify an Internet standard of any kind.  Distribution of   this memo is unlimited.Abstract   This memorandum describes the Simple Network Time Protocol (SNTP),   which is an adaptation of the Network Time Protocol (NTP) used to   synchronize computer clocks in the Internet. SNTP can be used when   the ultimate performance of the full NTP implementation described in   RFC-1305 is not needed or justified. It can operate in both unicast   modes (point to point) and broadcast modes (point to multipoint). It   can also operate in IP multicast mode where this service is   available. SNTP involves no change to the current or previous NTP   specification versions or known implementations, but rather a   clarification of certain design features of NTP which allow operation   in a simple, stateless remote-procedure call (RPC) mode with accuracy   and reliability expectations similar to the UDP/TIME protocol   described in RFC-868.   This memorandum obsoletes RFC-1361 of the same title. Its purpose is   to explain the protocol model for operation in broadcast mode, to   provide additional clarification in some places and to correct a few   typographical errors. A working knowledge of the NTP Version 3   specification RFC-1305 is not required for an implementation of SNTP.   Distribution of this memorandum is unlimited.1. Introduction   The Network Time Protocol (NTP) specified in RFC-1305 [MIL92] is used   to synchronize computer clocks in the global Internet. It provides   comprehensive mechanisms to access national time and frequency   dissemination services, organize the time-synchronization subnet and   adjust the local clock in each participating subnet peer. 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.Mills                                                           [Page 1]RFC 1769                          SNTP                       March 1995   RFC-1305 specifies the NTP protocol machine in terms of events,   states, transition functions and actions and, in addition, optional   algorithms to improve the timekeeping quality and mitigate among   several, possibly faulty, synchronization sources. To achieve   accuracies in the low milliseconds over paths spanning major portions   of the Internet of today, these intricate algorithms, or their   functional equivalents, are necessary. However, in many cases   accuracies of this order are not required and something less, perhaps   in the order of large fractions of the second, is sufficient. In such   cases simpler protocols such as the Time Protocol [POS83], have been   used for this purpose. These protocols usually involve an RPC   exchange where the client requests the time of day and the server   returns it in seconds past some known reference epoch.   NTP is designed for use by clients and servers with a wide range of   capabilities and over a wide range of network delays and jitter   characteristics. Most users of the Internet NTP synchronization   subnet of today use a software package including the full suite of   NTP options and algorithms, which are relatively complex, real-time   applications. While the software has been ported to a wide variety of   hardware platforms ranging from supercomputers to personal computers,   its sheer size and complexity is not appropriate for many   applications. Accordingly, it is useful to explore alternative access   strategies using far simpler software appropriate for less stringent   accuracy expectations.   This memorandum describes the Simple Network Time Protocol (SNTP),   which is a simplified access strategy for servers and clients using   NTP as now specified and deployed in the Internet. There are no   changes to the protocol or implementations now running or likely to   be implemented in the near future. The access paradigm is identical   to the UDP/TIME Protocol and, in fact, it should be easily possible   to adapt a UDP/TIME client implementation, say for a personal   computer, to operate using SNTP. Moreover, SNTP is also designed to   operate in a dedicated server configuration including an integrated   radio clock. With careful design and control of the various latencies   in the system, which is practical in a dedicated design, it is   possible to deliver time accurate to the order of microseconds.   It is strongly recommended that SNTP be used only at the extremities   of the synchronization subnet. SNTP clients should operate only at   the leaves (highest stratum) of the subnet and in configurations   where no NTP or SNTP client is dependent on another SNTP client for   synchronization. SNTP servers should operate only at the root   (stratum 1) of the subnet and then only in configurations where no   other source of synchronization other than a reliable radio clock is   available. The full degree of reliability ordinarily expected of   primary servers is possible only using the redundant sources, diverseMills                                                           [Page 2]RFC 1769                          SNTP                       March 1995   subnet paths and crafted algorithms of a full NTP implementation.   This extends to the primary source of synchronization itself in the   form of multiple radio clocks and backup paths to other primary   servers should the radio clock fail or deliver incorrect time.   Therefore, the use of SNTP rather than NTP in primary servers should   be carefully considered.2. Operating Modes and Addressing   Like NTP, SNTP can operate in either unicast (point to point) or   broadcast (point to multipoint) modes. A unicast client sends a   request to a server and expects a reply from which it can determine   the time and, optionally, the roundtrip delay and local clock offset   relative to the server. A broadcast server periodically sends a   message to a designated IP broadcast address or IP multicast group   address and ordinarily expects no requests from clients, while a   broadcast client listens on this address and ordinarily sends no   requests to servers. Some broadcast servers may elect to respond to   client requests as well as send unsolicited broadcast messages, while   some broadcast clients may elect to send requests only in order to   determine the network propagation delay between the server and   client.   In unicast mode the client and server IP addresses are assigned   following the usual conventions. In broadcast mode the server uses a   designated IP broadcast address or IP multicast group address,   together with a designated media-access broadcast address, and the   client listens on these addresses. For this purpose, an IP broadcast   address has scope limited to a single IP subnet, since routers do not   propagate IP broadcast datagrams. In the case of Ethernets, for   example, the Ethernet media-access broadcast address (all ones) is   used with an IP address consisting of the IP subnet number in the net   field and all ones in the host field.   On the other hand, an IP multicast group address has scope extending   to potentially the entire Internet. The actual scope, group   membership and routing are determined by the Internet Group   Management Protocol (IGMP) [DEE89] and various routing protocols,   which are beyond the scope of this document. In the case of   Ethernets, for example, the Ethernet media-access broadcast address   (all ones) is used with the assigned IP multicast group address of   224.0.1.1. Other than the IP addressing conventions and IGMP, there   is no difference in server operations with either the IP broadcast   address or IP multicast group address.   Broadcast clients listen on the designated media-access broadcast   address, such as all ones in the case of Ethernets. In the case of IP   broadcast addresses, no further provisions are necessary. In the caseMills                                                           [Page 3]RFC 1769                          SNTP                       March 1995   of IP multicast group addresses, the host may need to implement IGMP   in order that the local router intercepts messages to the 224.0.1.1   multicast group. These considerations are beyond the scope of this   document.   In the case of SNTP as specified herein, there is a very real   vulnerability that SNTP multicast clients can be disrupted by   misbehaving or hostile SNTP or NTP multicast servers elsewhere in the   Internet, since at present all such servers use the same IP multicast   group address 224.0.1.1. Where necessary, access control based on the   server source address can be used to select only those servers known   to and trusted by the client. Alternatively, by convention and   informal agreement, all NTP multicast servers now include an MD5-   encrypted message digest in every message, so that clients can   determine if the message is authentic and not modified in transit. It   is in principle possible that SNTP clients could implement the   necessary encryption and key-distribution schemes, but this is   considered not likely in the simple systems for which SNTP is   intended.   While not integral to the SNTP 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 of   SNTP clients in the same subnet, while IP multicast group addresses   will be used only in special cases engineered for the purpose. In   particular, IP multicast group addresses should be used in SNTP   servers only if the server implements the NTP authentication scheme   described in RFC-1305, including support for the MD5 message-digest   algorithm.3. NTP Timestamp Format   SNTP uses the standard NTP timestamp format described in RFC-1305 and   previous versions of that document. In conformance with standard   Internet practice, NTP data are specified as integer or fixed-point   quantities, with bits numbered in big-endian fashion from 0 starting   at the left, or high-order, position. Unless specified otherwise, all   quantities are unsigned and may occupy the full field width with an   implied 0 preceding bit 0.   Since NTP timestamps are cherished data and, in fact, represent the   main product of the protocol, a special timestamp format has been   established. 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 should be set to 0. This format allows convenient multiple-   precision arithmetic and conversion to UDP/TIME representationMills                                                           [Page 4]RFC 1769                          SNTP                       March 1995   (seconds), but does complicate the conversion to ICMP Timestamp   message representation (milliseconds). The precision of this   representation is about 200 picoseconds, which should be adequate for   even the most exotic requirements.                           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                             |      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+      |                  Seconds Fraction (0-padded)                  |      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   Note that, since some time in 1968 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. Should NTP or SNTP be in use in 2036,   some external means will be necessary to qualify time relative to   1900 and time relative to 2036 (and other multiples of 136 years).   Timestamped data requiring such qualification will be so precious   that appropriate means should be readily available. There will exist   a 200-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.4. NTP Message Format   Both NTP and SNTP are clients of the User Datagram Protocol (UDP)   [POS80], which itself is a client of the Internet Protocol (IP)   [DAR81]. The structure of the IP and UDP headers is described in the   cited specification documents and will not be described 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