doc: Add RFC documents

1 files changed, 787 insertions, 0 deletions

diff --git a/doc/rfc/rfc1769.txt b/doc/rfc/rfc1769.txt
new file mode 100644
index 0000000..b34465b
--- /dev/null
+++ b/doc/rfc/rfc1769.txt
@@ -0,0 +1,787 @@
+
+
+
+
+
+
+Network Working Group                                           D. Mills
+Request for Comments: 1769                        University of Delaware
+Obsoletes: 1361                                               March 1995
+Category: 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, diverse
+
+
+
+Mills                                                           [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 case
+
+
+
+Mills                                                           [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 representation
+
+
+
+Mills                                                           [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
+   specification.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mills                                                           [Page 5]
+
+RFC 1769                          SNTP                       March 1995
+
+
+   Following is a description of the SNTP message format, which follows
+   the IP and UDP headers. The SNTP message format is identical to the
+   NTP format described in RFC-1305, with the exception that some of the
+   data fields are "canned," that is, initialized to pre-specified
+   values. The format of the NTP message is shown below.
+
+                           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)                    |
+      |                                                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                                                               |
+      |                                                               |
+      |                  Authenticator (optional) (96)                |
+      |                                                               |
+      |                                                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   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                                                           [Page 6]
+
+RFC 1769                          SNTP                       March 1995
+
+
+   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
+   version number, currently 3.
+
+   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 mode 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: 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
+
+   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).
+
+
+
+
+Mills                                                           [Page 7]
+
+RFC 1769                          SNTP                       March 1995
+
+
+   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 Clock Identifier: This is a 32-bit code identifying the
+   particular reference source. In the case of stratum 0 (unspecified)
+   or stratum 1 (primary reference), this is a four-octet, left-
+   justified, 0-padded ASCII string. While not enumerated as part of the
+   NTP specification, the following are representative ASCII
+   identifiers:
+
+      Stratum Code  Meaning
+      ----------------------------------------------------------------
+      1   pps       precision calibrated source, such as ATOM (atomic
+                    clock), PPS (precision pulse-per-second source),
+                    etc.
+      1   service   generic time service other than NTP, such as ACTS
+                    (Automated Computer Time Service), TIME (UDP/Time
+                    Protocol), TSP (Unix Time Service Protocol), DTSS
+                    (Digital Time Synchronization Service), etc.
+      1   radio     Generic radio service, with callsigns such as CHU,
+                    DCF77, MSF, TDF, WWV, WWVB, WWVH, etc.
+      1   nav       radionavigation system, such as OMEG (OMEGA), LORC
+                    (LORAN-C), etc.
+      1   satellite generic satellite service, such as GOES
+                    (Geostationary Orbit Environment Satellite, GPS
+                    (Global Positioning Service), etc.
+      2   address   secondary reference (four-octet Internet address of
+                    the NTP server)
+
+
+
+
+
+
+Mills                                                           [Page 8]
+
+RFC 1769                          SNTP                       March 1995
+
+
+   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 mechanism is
+   implemented, this contains the authenticator information defined in
+   Appendix C of RFC-1305. In SNTP this field is ignored for incoming
+   messages and is not generated for outgoing messages.
+
+5. SNTP Client Operations
+
+   The model for n SNTP client operating with either a NTP or SNTP
+   server is a RPC client with no persistent state. In unicast mode, the
+   client sends a client request (mode 3) to the server and expects a
+   server reply (mode 4). In broadcast mode, the client sends no request
+   and waits for a broadcast message (mode 5) from one or more servers,
+   depending on configuration. Unicast client and broadcast server
+   messages are normally sent at periods from 64 s to 1024 s, depending
+   on the client and server configurations.
+
+   A unicast client initializes the SNTP message header, sends the
+   message to the server and strips the time of day from the reply. For
+   this purpose all of the message-header fields shown above are set to
+   0, except the first octet. In this 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 software version of the NTP or SNTP server; however,
+   NTP Version 3 (RFC-1305) servers will also accept Version 2 (RFC-
+   1119) and Version 1 (RFC-1059) messages, while NTP Version 2 servers
+   will also accept NTP Version 1 messages. Version 0 (RFC-959) messages
+   are no longer supported. Since there are NTP servers of all three
+   versions interoperating in the Internet of today, it is recommended
+   that the VN field be set to 1.
+
+   In both unicast and broadcast modes, the unicast server reply or
+   broadcast message includes all the fields described above; however,
+   in SNTP only the Transmit Timestamp has explicit meaning and then
+   only if nonzero. The integer part of this field contains the server
+   time of day in the same format as the UDP/TIME Protocol [POS83].
+   While the fraction part of this field will usually be valid, the
+   accuracy achieved with SNTP may justify its use only to a significant
+
+
+
+Mills                                                           [Page 9]
+
+RFC 1769                          SNTP                       March 1995
+
+
+   fraction of a second. If the Transmit Timestamp field is 0, the
+   message should be disregarded.
+
+   In broadcast mode, a client has no additional information to
+   calculate the propagation delay between the server and client, as the
+   Transmit Timestamp and Receive Timestamp fields have no meaning in
+   this mode. Even in unicast mode, most clients will probably elect to
+   ignore the Originate Timestamp and Receive Timestamp fields anyway.
+   However, in unicast mode a simple calculation can be used to provide
+   the roundtrip delay d and local clock offset t relative to the
+   server, generally to within a few tens of milliseconds. To do this,
+   the client sets the Originate Timestamp in the request to the time of
+   day according to its local clock converted to NTP timestamp format.
+   When the reply is received, the client determines a Destination
+   Timestamp as the time of arrival according to its local clock
+   converted to 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 at server
+      Transmit Timestamp      T3   time reply sent by server
+      Destination Timestamp   T4   time reply received at 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 is a summary of the SNTP client operations. There
+   are two recommended error checks shown in the table. In all NTP
+   versions, if the LI field is 3, or the Stratum field is not in the
+   range 1-15, or the Transmit Timestamp is 0, the server has never
+   synchronized or not synchronized to a valid timing source within the
+   last 24 hours. At the client discretion, the values of the remaining
+   fields can be checked as well. Whether to believe the transmit
+   timestamp or not in case one or more of these fields appears invalid
+   is at the discretion of the implementation.
+
+
+
+
+
+
+
+
+
+
+
+
+Mills                                                          [Page 10]
+
+RFC 1769                          SNTP                       March 1995
+
+
+      Field Name              Request        Reply
+      -------------------------------------------------------------
+      LI                      0              leap indicator; if 3
+                                             (unsynchronized), disregard
+                                             message
+      VN                      1 (see text)   ignore
+      Mode                    3 (client)     ignore
+      Stratum                 0              ignore
+      Poll                    0              ignore
+      Precision               0              ignore
+      Root Delay              0              ignore
+      Root Dispersion         0              ignore
+      Reference Identifier    0              ignore
+      Reference Timestamp     0              ignore
+      Originate Timestamp     0 (see text)   ignore (see text)
+      Receive Timestamp       0              ignore (see text)
+      Transmit Timestamp      0              time of day; if 0
+                                             (unsynchronized), disregard
+                                             message
+      Authenticator           (not used)     ignore
+
+6. SNTP Server Operations
+
+   The model for a SNTP server operating with either a NTP or SNTP
+   client is an RPC server with 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, it is
+   recommended that a SNTP server be operated only in conjunction with a
+   source of external synchronization, such as a reliable radio clock.
+   In this case the server always operates at stratum 1.
+
+   A server can operate in unicast mode, broadcast mode or both at the
+   same time. In unicast mode the server receives a request message,
+   modifies certain fields in the NTP or SNTP header, and returns the
+   message to the sender, possibly using the same message buffer as the
+   request. 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 unicast mode, 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.
+
+   In broadcast mode, the server sends messages only if synchronized to
+   a correctly operating reference clock. In this mode, the VN field is
+   set to 3 (for the current SNTP version), and the Mode field to 5
+   (broadcast). The Poll field is set to the server poll interval, in
+
+
+
+Mills                                                          [Page 11]
+
+RFC 1769                          SNTP                       March 1995
+
+
+   seconds to the nearest power of two. It is highly desirable that, if
+   a server supports broadcast mode, it also supports unicast mode. This
+   is necessary so a potential broadcast client can calculate the
+   propagation delay using client/server messages prior to regular
+   operation using only broadcast messages.
+
+   The remaining fields are set in the same way in both unicast and
+   broadcast modes. Assuming the server is synchronized to a radio clock
+   or other primary reference source and operating correctly, the
+   Stratum field is set to 1 (primary server) and the LI field is set to
+   0; 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 above.
+
+   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, if unavailable, to
+   the time of day when the message is sent. The Receive Timestamp and
+   Transmit Timestamp fields are set to the time of day when the message
+   is sent. In unicast mode, 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 check for replays. In broadcast mode, this field is set to the
+   time of day when the message is sent. The following table summarizes
+   these actions.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mills                                                          [Page 12]
+
+RFC 1769                          SNTP                       March 1995
+
+
+      Field Name              Request        Reply
+      ----------------------------------------------------------
+      LI                      ignore         0 (normal), 3
+                                             (unsynchronized)
+      VN                      1, 2 or 3      3 or copied from request
+      Mode                    3 (see text)   2, 4 or 5 (see text)
+      Stratum                 ignore         1 server stratum
+      Poll                    ignore         copied from request
+      Precision               ignore         server precision
+      Root Delay              ignore         0
+      Root Dispersion         ignore         0 (see text)
+      Reference Identifier    ignore         source identifier
+      Reference Timestamp     ignore         0 or time of day
+      Originate Timestamp     ignore         0 or time of day or copied
+                                             from Transmit Timestamp of
+                                             request
+      Receive Timestamp       ignore         0 or time of day
+      Transmit Timestamp      (see text)     0 or time of day
+      Authenticator           ignore         (not used)
+
+   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. References
+
+   [DAR81] Postel, J., "Internet Protocol - DARPA Internet Program
+   Protocol Specification", STD 5, RFC 791, DARPA, September 1981.
+
+   [DEE89] Deering, S., "Host Extensions for IP Multicasting. STD 5,
+   RFC 1112, Stanford University, August 1989.
+
+   [MIL92] Mills, D., "Network Time Protocol (Version 3) Specification,
+   Implementation and Analysis. RFC 1305, University of Delaware,
+   March 1992.
+
+   [POS80] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
+   USC/Information Sciences Institute, August 1980.
+
+   [POS83] Postel, J., and K. Harrenstien, "Time Protocol", STD 26,
+   RFC 868, USC/Information Sciences Institute, SRI, May 1983.
+
+
+
+
+
+
+Mills                                                          [Page 13]
+
+RFC 1769                          SNTP                       March 1995
+
+
+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
+   EMail: mills@udel.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mills                                                          [Page 14]
+