summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc2030.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc2030.txt')
-rw-r--r--doc/rfc/rfc2030.txt1011
1 files changed, 1011 insertions, 0 deletions
diff --git a/doc/rfc/rfc2030.txt b/doc/rfc/rfc2030.txt
new file mode 100644
index 0000000..ba0acf1
--- /dev/null
+++ b/doc/rfc/rfc2030.txt
@@ -0,0 +1,1011 @@
+
+
+
+
+
+
+Network Working Group D. Mills
+Request for Comments: 2030 University of Delaware
+Obsoletes: 1769 October 1996
+Category: Informational
+
+
+ Simple Network Time Protocol (SNTP) Version 4
+ for IPv4, IPv6 and OSI
+
+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)
+ Version 4, 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. When operating with
+ current and previous NTP and SNTP versions, SNTP Version 4 involves
+ no changes to the NTP specification 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.
+
+ The only significant protocol change in SNTP Version 4 over previous
+ versions of NTP and SNTP is a modified header interpretation to
+ accommodate Internet Protocol Version 6 (IPv6) [DEE96] and OSI
+ [COL94] addressing. However, SNTP Version 4 includes certain optional
+ extensions to the basic Version 3 model, including an anycast mode
+ and an authentication scheme designed specifically for multicast and
+ anycast modes. While the anycast mode extension is described in this
+ document, the authentication scheme extension will be described in
+ another document to be published later. Until such time that a
+ definitive specification is published, these extensions should be
+ considered provisional.
+
+ This memorandum obsoletes RFC-1769, which describes SNTP Version 3.
+ Its purpose is to correct certain inconsistencies in the previous
+ document and to clarify header formats and protocol operations for
+ current NTP Version 3 (IPv4) and proposed NTP Version 4 (IPv6 and
+ OSI), which are also used for SNTP. A working knowledge of the NTP
+ Version 3 specification RFC-1305 is not required for an
+ implementation of SNTP.
+
+
+
+Mills Informational [Page 1]
+
+RFC 2030 SNTPv4 for IPv4, IPv6 and OSI October 1996
+
+
+1. Introduction
+
+ The Network Time Protocol (NTP) Version 3 specified in RFC-1305
+ [MIL92] is widely 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.
+
+ RFC-1305 specifies the NTP Version 3 protocol machine in terms of
+ events, states, transition functions and actions and, in addition,
+ engineered algorithms to improve the timekeeping quality and mitigate
+ among several synchronization sources, some of which may be faulty.
+ 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 in the order of significant fractions of a second
+ are acceptable. 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 (see http://www.eecis.udel.edu/~ntp). 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. Accordingly, it is useful
+ to explore alternative access strategies using simpler software
+ appropriate for less stringent accuracy expectations.
+
+ This document describes the Simple Network Time Protocol (SNTP)
+ Version 4, which is a simplified access strategy for servers and
+ clients using NTP Version 3 as now specified and deployed in the
+ Internet, as well as NTP Version 4 now under development. 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
+
+
+
+Mills Informational [Page 2]
+
+RFC 2030 SNTPv4 for IPv4, IPv6 and OSI October 1996
+
+
+ order of microseconds.
+
+ SNTP Version 4 is designed to coexist with existing NTP and SNTP
+ Version 3 clients and servers, as well as proposed Version 4 clients
+ and servers. When operating with current and previous versions of NTP
+ and SNTP, SNTP Version 4 requires no changes to the protocol or
+ implementations now running or likely to be implemented specifically
+ for NTP ir SNTP Version 4. To a NTP or SNTP server, NTP and SNTP
+ clients are undistinguishable; to a NTP or SNTP client, NTP and SNTP
+ servers are undistinguishable. Like NTP servers operating in non-
+ symmetric modes, SNTP servers are stateless and can support large
+ numbers of clients; however, unlike most NTP clients, SNTP clients
+ normally operate with only a single server. NTP and SNTP Version 3
+ servers can operate in unicast and multicast modes. In addition, SNTP
+ Version 4 clients and servers can implement extensions to operate in
+ anycast mode.
+
+ 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 or modem
+ time service is available. The full degree of reliability ordinarily
+ expected of primary servers is possible only using the redundant
+ sources, diverse 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 or modem sources and backup
+ paths to other primary servers should all sources fail or the
+ majority deliver incorrect time. Therefore, the use of SNTP rather
+ than NTP in primary servers should be carefully considered.
+
+ An important provision in this document is the reinterpretation of
+ certain NTP Versino 4 header fields which provide for IPv6 and OSI
+ addressing and optional anycast extensions designed specifically for
+ multicast service. These additions are in conjunction with the
+ proposed NTP Version 4 specification, which will appear as a separate
+ document. The only difference between the current NTP Version 3 and
+ proposed NTP Version 4 header formats is the interpretation of the
+ four-octet Reference Identifier field, which is used primarily to
+ detect and avoid synchronization loops. In Version 3 and Version 4
+ primary (stratum-1) servers, this field contains the four-character
+ ASCII reference identifier defined later in this document. In Version
+ 3 secondary servers and clients, it contains the 32-bit IPv4 address
+ of the synchronization source. In Version 4 secondary servers and
+ clients, it contains the low order 32 bits of the last transmit
+ timestamp received from the synchronization source.
+
+
+
+Mills Informational [Page 3]
+
+RFC 2030 SNTPv4 for IPv4, IPv6 and OSI October 1996
+
+
+ In the case of OSI, the Connectionless Transport Service (CLTS) is
+ used [ISO86]. Each SNTP packet is transmitted as tht TS-Userdata
+ parameter of a T-UNITDATA Request primitive. Alternately, the header
+ can be encapsulated in a TPDU which itself is transported using UDP
+ [DOB91]. It is not advised that NTP be operated at the upper layers
+ of the OSI stack, such as might be inferred from [FUR94], as this
+ could seriously degrade accuracy. With the header formats defined in
+ this document, 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.
+
+2. Operating Modes and Addressing
+
+ SNTP Version 4 can operate in either unicast (point to point),
+ multicast (point to multipoint) or anycast (multipoint to point)
+ 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, the roundtrip delay and local clock offset
+ relative to the server. A multicast server periodically sends a
+ unsolicited message to a designated IPv4 or IPv6 local broadcast
+ address or multicast group address and ordinarily expects no requests
+ from clients. A multicast client listens on this address and
+ ordinarily sends no requests. An anycast client sends a request to a
+ designated IPv4 or IPv6 local broadcast address or multicast group
+ address. One or more anycast servers reply with their individual
+ unicast addresses. The client binds to the first one received, then
+ continues operation in unicast mode.
+
+ Multicast servers should respond to client unicast requests, as
+ well as send unsolicited multicast messages. Multicast clients may
+ send unicast requests in order to determine the network
+ propagation delay between the server and client and then continue
+ operation in multicast mode.
+
+ In unicast mode, the client and server end-system addresses are
+ assigned following the usual IPv4, IPv6 or OSI conventions. In
+ multicast mode, the server uses a designated local broadcast address
+ or multicast group address. An IP local broadcast address has scope
+ limited to a single IP subnet, since routers do not propagate IP
+ broadcast datagrams. On the other hand, an IP multicast group address
+ has scope extending to potentially the entire Internet. The scoping,
+ routing and group membership procedures are determined by
+ considerations beyond the scope of this document. For IPv4, the IANA
+ has assigned the multicast group address 224.0.1.1 for NTP, which is
+
+
+
+Mills Informational [Page 4]
+
+RFC 2030 SNTPv4 for IPv4, IPv6 and OSI October 1996
+
+
+ used both by multicast servers and anycast clients. NTP multicast
+ addresses for IPv6 and OSI have yet to be determined.
+
+ Multicast clients listen on the designated local broadcast address or
+ multicast group address. In the case of local broadcast addresses, no
+ further provisions are necessary. In the case of IP multicast
+ addresses, the multicast client and anycast server must implement the
+ Internet Group Management Protocol (IGMP) [DEE89], in order that the
+ local router joins the multicast group and relays messages to the
+ IPv4 or IPv6 multicast group addresses assigned by the IANA. Other
+ than the IP addressing conventions and IGMP, there is no difference
+ in server or client operations with either the local broadcast
+ address or multicast group address.
+
+ 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 value to be used are beyond the scope of this
+ document.
+
+ Anycast mode is designed for use with a set of cooperating servers
+ whose addresses are not known beforehand by the client. An anycast
+ client sends a request to the designated local broadcast or multicast
+ group address as described below. For this purpose, the NTP multicast
+ group address assigned by the IANA is used. One or more anycast
+ servers listen on the designated local broadcast address or multicast
+ group address. Each anycast server, upon receiving a request, sends a
+ unicast reply message to the originating client. The client then
+ binds to the first such message received and continues operation in
+ unicast mode. Subsequent replies from other anycast servers are
+ ignored.
+
+ 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 IPv4
+ multicast group address assigned by the IANA. Where necessary,
+ access control based on the server source address can be used to
+ select only the designated server known to and trusted by the
+ client. The use of cryptographic authentication scheme defined in
+ RFC-1305 is optional; however, implementors should be advised that
+ extensions to this scheme are planned specifically for NTP
+ multicast and anycast modes.
+
+
+
+
+
+Mills Informational [Page 5]
+
+RFC 2030 SNTPv4 for IPv4, IPv6 and OSI October 1996
+
+
+ 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 dependent SNTP multicast 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.
+
+ In NTP Version 3, the reference identifier was often used to
+ walk-back the synchronization subnet to the root (primary server)
+ for management purposes. In NTP Version 4, this feature is not
+ available, since the addresses are longer than 32 bits. However,
+ the intent in the protocol design was to provide a way to detect
+ and avoid loops. A peer could determine that a loop was possible
+ by comparing the contents of this field with the IPv4 destination
+ address in the same packet. A NTP Version 4 server can accomplish
+ the same thing by comparing the contents of this field with the
+ low order 32 bits of the originate timestamp in the same packet.
+ There is a small possibility of false alarm in this scheme, but
+ the false alarm rate can be minimized by randomizing the low order
+ unused bits of the transmit timestamp.
+
+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 can
+ be set to 0.
+
+ 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). One way of doing this is to generate
+ a random bitstring in a 64-bit word, then perform an arithmetic
+ right shift a number of bits equal to the number of significant
+ bits of the timestamp, then add the result to the original
+ timestamp.
+
+
+
+
+Mills Informational [Page 6]
+
+RFC 2030 SNTPv4 for IPv4, IPv6 and OSI October 1996
+
+
+ This format allows convenient multiple-precision arithmetic and
+ conversion to UDP/TIME representation (seconds), but does complicate
+ the conversion to ICMP Timestamp message representation, which is in
+ milliseconds. The maximum number that can be represented is
+ 4,294,967,295 seconds with a precision of 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 (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).
+ 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). 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.
+
+ As the NTP timestamp format has been in use for the last 17 years,
+ it remains a possibility that it will be in use 40 years from now
+ when the seconds field overflows. As it is probably inappropriate
+ to archive NTP timestamps before bit 0 was set in 1968, a
+ convenient way to extend the useful life of NTP timestamps is the
+ following convention: 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 not a
+ leap year. Note also that leap seconds are not counted in the
+ reckoning.
+
+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 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.
+
+
+
+Mills Informational [Page 7]
+
+RFC 2030 SNTPv4 for IPv4, IPv6 and OSI October 1996
+
+
+ Below is a description of the NTP/SNTP Version 4 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 as follows:
+
+ 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 | Stratum | Poll | Precision |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Root Delay |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Root Dispersion |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Reference Identifier |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ | Reference Timestamp (64) |
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ | Originate Timestamp (64) |
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ | Receive Timestamp (64) |
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ | Transmit Timestamp (64) |
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Key Identifier (optional) (32) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ | |
+ | Message Digest (optional) (128) |
+ | |
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ As described in the next section, in SNTP most of these fields are
+ initialized with pre-specified data. For completeness, the function
+ of each field is briefly summarized below.
+
+
+
+
+
+
+
+Mills Informational [Page 8]
+
+RFC 2030 SNTPv4 for IPv4, IPv6 and OSI October 1996
+
+
+ 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 follows:
+
+ LI Value Meaning
+ -------------------------------------------------------
+ 00 0 no warning
+ 01 1 last minute has 61 seconds
+ 10 2 last minute has 59 seconds)
+ 11 3 alarm condition (clock not synchronized)
+
+ Version Number (VN): This is a three-bit integer indicating the
+ NTP/SNTP version number. The version number is 3 for Version 3 (IPv4
+ only) and 4 for Version 4 (IPv4, IPv6 and OSI). If necessary to
+ distinguish between IPv4, IPv6 and OSI, the encapsulating context
+ must be inspected.
+
+ Mode: This is a three-bit integer indicating the mode, with values
+ 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 multicast mode, the server sets this field to 5
+ (broadcast).
+
+ Stratum: This is a eight-bit unsigned integer indicating the stratum
+ level of the local clock, with values defined as follows:
+
+ Stratum Meaning
+ ----------------------------------------------
+ 0 unspecified or unavailable
+ 1 primary reference (e.g., radio clock)
+ 2-15 secondary reference (via NTP or SNTP)
+ 16-255 reserved
+
+
+
+
+
+
+Mills Informational [Page 9]
+
+RFC 2030 SNTPv4 for IPv4, IPv6 and OSI October 1996
+
+
+ Poll Interval: This is an eight-bit signed integer indicating the
+ maximum interval between successive messages, in seconds to the
+ nearest power of two. The values that can appear in this field
+ presently range from 4 (16 s) to 14 (16284 s); however, most
+ applications use only the sub-range 6 (64 s) to 10 (1024 s).
+
+ Precision: This is an eight-bit signed integer indicating the
+ precision of the local clock, in seconds to the nearest power of two.
+ The values that normally appear in this field 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. The values that normally appear
+ in this field 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. The
+ values that normally appear in this field range from 0 to several
+ hundred milliseconds.
+
+ Reference Identifier: This is a 32-bit bitstring identifying the
+ particular reference source. In the case of NTP Version 3 or Version
+ 4 stratum-0 (unspecified) or stratum-1 (primary) servers, this is a
+ four-character ASCII string, left justified and zero padded to 32
+ bits. In NTP Version 3 secondary servers, this is the 32-bit IPv4
+ address of the reference source. In NTP Version 4 secondary servers,
+ this is the low order 32 bits of the latest transmit timestamp of the
+ reference source. NTP primary (stratum 1) servers should set this
+ field to a code identifying the external reference source according
+ to the following list. 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mills Informational [Page 10]
+
+RFC 2030 SNTPv4 for IPv4, IPv6 and OSI October 1996
+
+
+ Code External Reference Source
+ ----------------------------------------------------------------
+ LOCL uncalibrated local clock used as a primary reference for
+ a subnet without external means of synchronization
+ PPS atomic clock or other pulse-per-second source
+ individually calibrated to national standards
+ ACTS NIST dialup modem service
+ USNO USNO modem service
+ PTB PTB (Germany) 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
+ GOES Geostationary Orbit Environment Satellite
+
+ Reference Timestamp: This is the time at which the local 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, in 64-bit timestamp format.
+
+ Transmit Timestamp: This is the time at which the reply departed the
+ server for the client, in 64-bit timestamp format.
+
+ Authenticator (optional): When the NTP authentication scheme is
+ implemented, the Key Identifier and Message Digest fields contain the
+ message authentication code (MAC) information defined in Appendix C
+ of RFC-1305.
+
+5. SNTP Client Operations
+
+ A SNTP client can operate in multicast mode, unicast mode or anycast
+ mode. In multicast mode, the client sends no request and waits for a
+ broadcast (mode 5) from a designated multicast server. In unicast
+ mode, the client sends a request (mode 3) to a designated unicast
+ server and expects a reply (mode 4) from that server. In anycast
+ mode, the client sends a request (mode 3) to a designated local
+ broadcast or multicast group address and expects a reply (mode 4)
+ from one or more anycast servers. The client uses the first reply
+
+
+
+Mills Informational [Page 11]
+
+RFC 2030 SNTPv4 for IPv4, IPv6 and OSI October 1996
+
+
+ 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.
+ Requests are normally sent at intervals from 64 s to 1024 s,
+ depending on the frequency tolerance of the client clock and the
+ required accuracy.
+
+ 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 can be set to 0, except the first octet
+ and (optional) Transmit Timestamp fields. In the first octet, the LI
+ field is set to 0 (no warning) and the Mode field is set to 3
+ (client). The VN field must agree with the version number of the
+ NTP/SNTP server; however, Version 4 servers will also accept previous
+ versions. Version 3 (RFC-1305) and Version 2 (RFC-1119) servers
+ already accept all previous versions, including Version 1 (RFC-1059).
+ Note that Version 0 (RFC-959) is no longer supported by any other
+ version.
+
+ Since there will probably continue to be NTP and SNTP servers of all
+ four versions interoperating in the Internet, careful consideration
+ should be given to the version used by SNTP Version 4 clients. It is
+ recommended that clients use the latest version known to be supported
+ by the selected server in the interest of the highest accuracy and
+ reliability. SNTP Version 4 clients can interoperate with all
+ previous version NTP and SNTP servers, since the header fields used
+ by SNTP clients are unchanged. Version 4 servers are required to
+ reply in the same version as the request, so the VN field of the
+ request also specifies the version of the reply.
+
+ While not necessary in a conforming client implementation, in unicast
+ and anycast modes it highly recommended that the transmit timestamp
+ in the request is 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 local 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 multicast mode, the
+ client has no information to calculate the propagation delay or
+ determine the validity of the server, unless the NTP authentication
+ scheme is used.
+
+ To calculate the roundtrip delay d and local clock offset t relative
+ to the server, the client sets the transmit timestamp in the request
+ to the time of day according to the client clock in NTP timestamp
+
+
+
+Mills Informational [Page 12]
+
+RFC 2030 SNTPv4 for IPv4, IPv6 and OSI October 1996
+
+
+ format. The server copies this field to the originate timestamp in
+ the reply and sets the receive timestamp and transmit timestamp to
+ the time of day according to the server clock in NTP timestamp
+ format.
+
+ When the server reply is received, the client determines a
+ Destination Timestamp variable as the time of arrival according to
+ its clock in NTP timestamp format. The following table summarizes the
+ four timestamps.
+
+ Timestamp Name ID When Generated
+ ------------------------------------------------------------
+ Originate Timestamp T1 time request sent by client
+ Receive Timestamp T2 time request received by server
+ Transmit Timestamp T3 time reply sent by server
+ Destination Timestamp T4 time reply received by client
+
+ The roundtrip delay d and local clock offset t are defined as
+
+ d = (T4 - T1) - (T2 - T3) t = ((T2 - T1) + (T3 - T4)) / 2.
+
+ The following table summarizes the SNTP client operations in unicast,
+ anycast and multicast modes. The recommended error checks are shown
+ in the Reply and Multicast 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.
+
+ Field Name Unicast/Anycast Multicast
+ Request Reply
+ ----------------------------------------------------------
+ LI 0 0-2 0-2
+ VN 1-4 copied from 1-4
+ request
+ Mode 3 4 5
+ Stratum 0 1-14 1-14
+ 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
+
+
+
+
+Mills Informational [Page 13]
+
+RFC 2030 SNTPv4 for IPv4, IPv6 and OSI October 1996
+
+
+6. SNTP Server Operations
+
+ A SNTP Version 4 server operating with either a NTP or SNTP client of
+ the same or previous versions retains no persistent state. Since a
+ SNTP server ordinarily does not implement the full set of NTP
+ algorithms intended to support redundant peers 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 always operates as a primary
+ (stratum 1) server.
+
+ A SNTP server can operate in unicast mode, anycast mode, multicast
+ mode or any combination of these modes. In unicast and anycast modes,
+ the server receives a request (mode 3), modifies certain fields in
+ the NTP header, and sends a reply (mode 4), possibly using the same
+ message buffer as the request. In anycast mode, the server listens on
+ the designated local broadcast or multicast group address assigned by
+ the IANA, but uses its own unicast 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.
+ Multicast 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.
+
+ In unicast and anycast modes, the VN and Poll fields of the request
+ are copied intact to the reply. If the Mode field of the request is 3
+ (client), it is set to 4 (server) in the reply; otherwise, this field
+ is set to 2 (symmetric passive) in order to conform to the NTP
+ specification. This allows clients configured in symmetric active
+ (mode 1) to interoperate successfully, even if configured in possibly
+ suboptimal ways. In multicast (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, if a server supports
+ multicast mode, it also supports unicast mode. This is so a
+ potential multicast client can calculate the propagation delay
+ using a client/server exchange prior to regular operation using
+ only multicast mode. If the server supports anycast mode, then it
+ must support unicast mode. There does not seem to be a great
+ advantage to operate both multicast and anycast modes at the same
+ time, although the protocol specification does not forbid it.
+
+ In unicast and anycast modes, the server may or may not respond if
+ not synchronized to a correctly operating radio clock, but the
+ preferred option is to respond, since this allows reachability to be
+ determined regardless of synchronization state. In multicast mode,
+ the server sends broadcasts only if synchronized to a correctly
+
+
+
+Mills Informational [Page 14]
+
+RFC 2030 SNTPv4 for IPv4, IPv6 and OSI October 1996
+
+
+ operating reference clock.
+
+ The remaining fields of the NTP header are set in the following way.
+ Assuming the server is synchronized to a radio clock or other primary
+ reference source and operating correctly, the LI field is set to 0
+ and the Stratum field is set to 1 (primary server); if not, the
+ Stratum field is set to 0 and the LI field is set to 3. The Precision
+ field is set to reflect the maximum reading error of the local clock.
+ For all practical cases it is computed as the negative 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 Reference Identifier is set to designate the
+ primary reference source, as indicated in the table of Section 5 of
+ this document.
+
+ The timestamp fields are set as follows. If the server is
+ unsynchronized or first coming up, all timestamp fields are set to
+ zero. If synchronized, the Reference Timestamp is set to the time the
+ last update was received from the radio clock or modem. In unicast
+ and anycast modes, the Receive Timestamp and Transmit Timestamp
+ fields are set to the time of day when the message is sent and the
+ Originate Timestamp field is copied unchanged from the Transmit
+ Timestamp field of the request. It is important that this field be
+ copied intact, as a NTP client uses it to avoid replays. In multicast
+ mode, the Originate Timestamp and Receive Timestamp fields are set to
+ 0 and the Transmit Timestamp field is set to the time of day when the
+ message is sent. The following table summarizes these actions.
+
+ Field Name Unicast/Anycast Multicast
+ Request Reply
+ ----------------------------------------------------------
+ LI ignore 0 or 3 0 or 3
+ VN 1-4 copied from 4
+ request
+ Mode 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
+ radio update radio update
+
+
+
+Mills Informational [Page 15]
+
+RFC 2030 SNTPv4 for IPv4, IPv6 and OSI October 1996
+
+
+ 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
+
+ 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 primary reference source is inoperative. The most
+ important indicator of an unhealthy server is the LI field, in which
+ a value of 3 indicates an unsynchronized condition. When this value
+ is displayed, clients should discard the server message, regardless
+ of the contents of other fields.
+
+7. Configuration and Management
+
+ Initial setup for SNTP servers and clients can be done using a
+ configuration file if a file system is available, or a serial port if
+ not. It is intended that in-service management of NTP and SNTP
+ Version 4 servers and clients be performed using SNMP and a suitable
+ MIB to be published later. Ordinarily, SNTP servers and clients are
+ expected to operate with little or no site-specific configuration,
+ other than specifying the IP address and subnet mask or OSI NSAP
+ address.
+
+ Unicast clients must be provided with the designated server name or
+ address. If a server name is used, the address of one of more DNS
+ servers must be provided. Multicast servers and anycast clients must
+ be provided with the TTL and local broadcast or multicast group
+ address. Anycast servers and multicast 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 used. These 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
+ document.
+
+ There are several scenarios which provide automatic server discovery
+ and selection for SNTP clients with no pre-specified configuration,
+ other than the IP address and subnet mask or OSI NSAP address. For a
+ IP subnet or LAN segment including a fully functional NTP server, the
+ clients can be configured for multicast mode using the local
+ broadcast address. The same approach can be used with other servers
+ using the multicast group address. In both cases, provision of an
+ access control list is a good way to insure only trusted sources can
+ be used to set the local clock.
+
+
+
+
+Mills Informational [Page 16]
+
+RFC 2030 SNTPv4 for IPv4, IPv6 and OSI October 1996
+
+
+ In another scenario suitable for an extended network with significant
+ network propagation delays, clients can be configured for anycast
+ mode, 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 first reply heard and
+ continues operation in unicast mode. In this mode the local clock can
+ be automatically adjusted to compensate for the propagation delay.
+
+ In still another scenario suitable for any network and where
+ multicast service is not available, the DNS can be set up with a
+ common CNAME, like time.domain.net, and a list of address records for
+ NTP servers in the same domain. Upon resolving time.domain.net and
+ obtaining the list, the client selects a server at random and begins
+ operation in unicast mode with that server. Many variations on this
+ theme are possible.
+
+8. Acknowledgements
+
+ Jeff Learman was helpful in developing the OSI model for this
+ protocol. Ajit Thyagarajan provided valuable suggestions and
+ corrections.
+
+9. References
+
+ [COL94] Colella, R., R. Callon, E. Gardner, Y. Rekhter, "Guidelines
+ for OSI NSAP allocation in the Internet", RFC 1629, NIST, May 1994.
+
+ [DAR81] Postel, J., "Internet Protocol", STD 5, RFC 791,
+ USC Information Sciences Institute, September 1981.
+
+ [DEE89] Deering, S., "Host extensions for IP multicasting", STD 5,
+ RFC 1112, Stanford University, August 1989.
+
+ [DEE96] Deering, S., R. Hinden, "Internet Protocol, Version 6 (IPv6)
+ Specification", RFC 1883, Xerox and Ipsilon, January 1996.
+
+ [DOB91] Dobbins, K, W. Haggerty, C. Shue, "OSI connectionless
+ transport services on top of UDP - Version: 1", RFC 1240, Open
+ Software Foundation, June 1991.
+
+ [EAS95] Eastlake, D., 3rd., and C. Kaufman, "Domain Name System
+ Security Extensions", Work in Progress.
+
+ [FUR94] Furniss, P., "Octet sequences for upper-layer OSI to support
+ basic communications applications", RFC 1698, Consultant,
+ October 1994.
+
+
+
+
+
+Mills Informational [Page 17]
+
+RFC 2030 SNTPv4 for IPv4, IPv6 and OSI October 1996
+
+
+ [HIN96] Hinden, R., and S. Deering, "IP Version 6 addressing
+ Architecture", RFC 1884, Ipsilon and Xerox, January 1996.
+
+ [ISO86] International Standards 8602 - Information Processing Systems
+ - OSI: Connectionless Transport Protocol Specification. International
+ Standards Organization, December 1986.
+
+ [MIL92] Mills, D., "Network Time Protocol (Version 3) specification,
+ implementation and analysis", RFC 1305, University of Delaware,
+ March 1992.
+
+ [PAR93] Partridge, C., T. Mendez and W. Milliken, "Host anycasting
+ service", RFC 1546, Bolt Beranek Newman, November 1993.
+
+ [POS80] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
+ USC Information Sciences Institute, August 1980.
+
+ [POS83] Postel, J., "Time Protocol", STD 26, RFC 868,
+ USC Information Sciences Institute, May 1983.
+
+Security Considerations
+
+ Security issues are not discussed in this memo.
+
+Author's Address
+
+ David L. Mills
+ Electrical Engineering Department
+ University of Delaware
+ Newark, DE 19716
+
+ Phone: (302) 831-8247
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mills Informational [Page 18]
+