RFC 2030 (rfc2030) - Page 3 of 18
Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI
Alternative Format: Original Text Document
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