RFC 2030 (rfc2030) - Page 3 of 18

Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI

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