rfc2030.txt

VC++实现的时间同步程序

   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