doc: Add RFC documents

1 files changed, 1515 insertions, 0 deletions

diff --git a/doc/rfc/rfc4330.txt b/doc/rfc/rfc4330.txt
new file mode 100644
index 0000000..6d93a8e
--- /dev/null
+++ b/doc/rfc/rfc4330.txt
@@ -0,0 +1,1515 @@
+
+
+
+
+
+
+Network Working Group                                           D. Mills
+Request for Comments: 4330                        University of Delaware
+Obsoletes: 2030, 1769                                       January 2006
+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.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   This memorandum describes the Simple Network Time Protocol Version 4
+   (SNTPv4), which is a subset of the Network Time Protocol (NTP) used
+   to synchronize computer clocks in the Internet.  SNTPv4 can be used
+   when the ultimate performance of a full NTP implementation based on
+   RFC 1305 is neither needed nor justified.  When operating with
+   current and previous NTP and SNTP versions, SNTPv4 requires no
+   changes to the specifications or known implementations, but rather
+   clarifies certain design features that 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 1769, which describes SNTP Version 3
+   (SNTPv3), and RFC 2030, which describes SNTPv4.  Its purpose is to
+   correct certain inconsistencies in the previous documents and to
+   clarify header formats and protocol operations for NTPv3 (IPv4) and
+   SNTPv4 (IPv4, IPv6, and OSI), which are also used for SNTP.  A
+   further purpose is to provide guidance for home and business client
+   implementations for routers and other consumer devices to protect the
+   server population from abuse.  A working knowledge of the NTPv3
+   specification, RFC 1305, is not required for an implementation of
+   SNTP.
+
+
+
+
+
+
+
+
+Mills                        Informational                      [Page 1]
+
+RFC 4330             SNTPv4 for IPv4, IPv6 and OSI          January 2006
+
+
+Table of Contents
+
+   1. Introduction ....................................................2
+      1.1. Specification of Requirements ..............................5
+   2. Operating Modes and Addressing ..................................5
+   3. NTP Timestamp Format ............................................6
+   4. Message Format ..................................................8
+   5. SNTP Client Operations .........................................13
+   6. SNTP Server Operations .........................................16
+   7. Configuration and Management ...................................19
+   8. The Kiss-o'-Death Packet .......................................20
+   9. On Being a Good Network Citizen ................................21
+   10. Best Practices ................................................21
+   11. Security Considerations .......................................24
+   12. Acknowledgements ..............................................24
+   13. Contributors ..................................................24
+   14. Informative References ........................................25
+
+1.  Introduction
+
+   The Network Time Protocol Version 3 (NTPv3), 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 NTP subnet of
+   servers and clients, and adjust the system clock in each participant.
+   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 protocol machine in terms of events,
+   states, transition functions and actions, and engineered algorithms
+   to improve the timekeeping quality and to mitigate several
+   synchronization sources, some of which may be faulty.  To achieve
+   accuracies in the low milliseconds over paths spanning major portions
+   of the Internet, these intricate algorithms, or their functional
+   equivalents, are necessary.  In many applications, accuracies on the
+   order of significant fractions of a second are acceptable.  In simple
+   home router applications, accuracies of up to a minute may suffice.
+   In such cases, simpler protocols, such as the Time Protocol specified
+   in RFC 868 [POS83], have been used for this purpose.  These protocols
+   involve an RPC exchange where the client requests the time of day and
+   the server returns it in seconds past a 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 jitter and clock
+   frequency wander characteristics.  Many users of NTP in the Internet
+   of today use a software distribution available from www.ntp.org.  The
+   distribution, which includes the full suite of NTP options,
+
+
+
+Mills                        Informational                      [Page 2]
+
+RFC 4330             SNTPv4 for IPv4, IPv6 and OSI          January 2006
+
+
+   mitigation algorithms, and security schemes, is a relatively complex,
+   real-time application.  Although 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
+   strategies using simpler software appropriate for less stringent
+   accuracy expectations.
+
+   This memo describes the Simple Network Time Protocol Version 4
+   (SNTPv4), which is a simplified access paradigm for servers and
+   clients using current and previous versions of NTP and SNTP.  The
+   access paradigm is identical to the UDP/TIME Protocol, and, in fact,
+   it should be easy 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 on the order of
+   microseconds.
+
+   The only significant protocol change in SNTPv4 from previous SNTP
+   versions is a modified header interpretation to accommodate Internet
+   Protocol Version 6 (IPv6) (RFC 2460) and OSI (RFC 1629) addressing.
+   However, SNTPv4 includes certain optional extensions to the basic NTP
+   Version 3 (NTPv3) model, including a manycast mode and a public-key-
+   based authentication scheme designed specifically for broadcast and
+   manycast applications.  Although the manycast mode is described in
+   this memo, the authentication scheme is described in another RFC to
+   be submitted later.  Until such time that a definitive NTPv4
+   specification is published, the manycast and authentication features
+   should be considered provisional.  In addition, this memo introduces
+   the kiss-o'-death message, which can be used by servers to suppress
+   client requests as circumstances require.
+
+   When operating with current and previous versions of NTP and SNTP,
+   SNTPv4 requires no changes to the protocol or implementations now
+   running or likely to be implemented specifically for future NTP or
+   SNTP versions.  The NTP and SNTP packet formats are the same, and the
+   arithmetic operations to calculate the client time, clock offset, and
+   roundtrip delay are the same.  To an NTP or SNTP server, NTP and SNTP
+   clients are indistinguishable; to an NTP or SNTP client, NTP and SNTP
+   servers are indistinguishable.  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 at a time.
+
+   The full degree of reliability ordinarily expected of NTP servers is
+   possible only using redundant sources, diverse paths, and the crafted
+
+
+
+Mills                        Informational                      [Page 3]
+
+RFC 4330             SNTPv4 for IPv4, IPv6 and OSI          January 2006
+
+
+   algorithms of a full NTP implementation.  It is strongly recommended
+   that SNTP clients 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 or
+   telephone modem is available.
+
+   An important provision in this memo is the interpretation of certain
+   NTP header fields that provide for IPv6 [DEE98] and OSI [COL94]
+   addressing.  The only significant difference between the NTP and
+   SNTPv4 header formats is the four-octet Reference Identifier field,
+   which is used primarily to detect and avoid synchronization loops.
+   In all NTP and SNTP versions providing IPv4 addressing, primary
+   servers use a four-character ASCII reference clock identifier in this
+   field, whereas secondary servers use the 32-bit IPv4 address of the
+   synchronization source.  In SNTPv4 providing IPv6 and OSI addressing,
+   primary servers use the same clock identifier, but secondary servers
+   use the first 32 bits of the MD5 hash of the IPv6 or NSAP address of
+   the synchronization source.  A further use of this field is when the
+   server sends a kiss-o'-death message, documented later in this memo.
+
+      NTP Version 4 (NTPv4), now in deployment, but not yet the subject
+      of a standards document, uses the same Reference Identifier field
+      as SNTPv4.
+
+   In the case of OSI, the Connectionless Transport Service (CLTS) is
+   used as in [ISO86].  Each SNTP packet is transmitted as the TS-
+   Userdata parameter of a T-UNITDATA Request primitive.  Alternately,
+   the header can be encapsulated in a Transport Protocol Data Unit
+   (TPDU), which itself is transported using UDP, as described in RFC
+   1240 [DOB91].  It is not advised that NTP be operated at the upper
+   layers of the OSI stack, such as might be inferred from RFC 1698
+   [FUR94], as this could seriously degrade accuracy.  With the header
+   formats defined in this memo, 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.
+
+   This memo is organized as follows.  Section 2 describes how the
+   protocol works, the various modes, and how IP addresses and UDP ports
+   are used.  Section 3 describes the NTP timestamp format, and Section
+
+
+
+Mills                        Informational                      [Page 4]
+
+RFC 4330             SNTPv4 for IPv4, IPv6 and OSI          January 2006
+
+
+   4 the NTP message format.  Section 5 summarizes SNTP client
+   operations, and Section 6 summarizes SNTP server operations.  Section
+   7 summarizes operation and management issues.  Section 8 describes
+   the kiss-o'-death message, newly minted with functions similar to the
+   ICMP Source Quench and ICMP Destination Unreachable messages.
+   Section 9 summarizes design issues important for good network
+   citizenry and presents an example algorithm designed to give good
+   reliability while minimizing network and server resource demands.
+
+1.1.  Specification of Requirements
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [BRA97].
+
+2.  Operating Modes and Addressing
+
+   Unless excepted in context, a reference to broadcast address means
+   IPv4 broadcast address, IPv4 multicast group address, or IPv6 address
+   of appropriate scope.  Further information on the broadcast/multicast
+   model is in RFC 1112 [DEE89].  Details of address format, scoping
+   rules, etc., are beyond the scope of this memo.  SNTPv4 can operate
+   with either unicast (point to point), broadcast (point to
+   multipoint), or manycast (multipoint to point) addressing 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 clock offset relative to the
+   server.  A broadcast server periodically sends an unsolicited message
+   to a designated broadcast address.  A broadcast client listens on
+   this address and ordinarily sends no requests.
+
+   Manycast is an extension of the anycast paradigm described in RFC
+   1546 [PAR93].  It is designed for use with a set of cooperating
+   servers whose addresses are not known beforehand.  The manycast
+   client sends an ordinary NTP client request to a designated broadcast
+   address.  One or more manycast servers listen on that address.  Upon
+   receiving a request, a manycast server sends an ordinary NTP server
+   reply to the client.  The client then mobilizes an association for
+   each server found and continues operation with all of them.
+   Subsequently, the NTP mitigation algorithms operate to cast out all
+   except the best three.
+
+      Broadcast servers should respond to client unicast requests, as
+      well as send unsolicited broadcast messages.  Broadcast clients
+      may send unicast requests in order to measure the network
+      propagation delay between the server and client and then continue
+      operation in listen-only mode.  However, broadcast servers may
+
+
+
+
+Mills                        Informational                      [Page 5]
+
+RFC 4330             SNTPv4 for IPv4, IPv6 and OSI          January 2006
+
+
+      choose not to respond to unicast requests, so unicast clients
+      should be prepared to abandon the measurement and assume a default
+      value for the delay.
+
+   The client and server addresses are assigned following the usual
+   IPv4, IPv6 or OSI conventions.  For NTP multicast, the IANA has
+   reserved the IPv4 group address 224.0.1.1 and the IPv6 address ending
+   :101 with appropriate scope.  The NTP broadcast address for OSI has
+   yet to be determined.  Notwithstanding the IANA reserved addresses,
+   other multicast addresses can be used that do not conflict with
+   others assigned in scope.  The scoping, routing, and group membership
+   procedures are determined by considerations beyond the scope of this
+   memo.
+
+      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 manycast servers in scope will
+      reply to a client request.  The engineering principles that
+      determine the proper values to be used are beyond the scope of
+      this memo.
+
+      In the case of SNTP as specified herein, there is a very real
+      vulnerability that SNTP broadcast clients can be disrupted by
+      misbehaving or hostile SNTP or NTP broadcast servers elsewhere in
+      the Internet.  It is strongly recommended that access controls
+      and/or cryptographic authentication means be provided for
+      additional security in such cases.
+
+      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 broadcast clients on the
+      same subnet, and that IP multicast group addresses will be used
+      only in cases where the TTL is engineered specifically for each
+      service domain.  However, these uses are not integral to the SNTP
+      specification.
+
+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 most significant end.  Unless specified otherwise, all
+   quantities are unsigned and may occupy the full field width with an
+   implied 0 preceding bit 0.
+
+
+
+
+Mills                        Informational                      [Page 6]
+
+RFC 4330             SNTPv4 for IPv4, IPv6 and OSI          January 2006
+
+
+   Because 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 are not specified and are ordinarily 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 to provide loop detection and
+      replay detection (see below).  It is important that the bitstring
+      be unpredictable by an intruder.  One way of doing this is to
+      generate a random 128-bit bitstring at startup.  After that, each
+      time the system clock is read, the string consisting of the
+      timestamp and bitstring is hashed with the MD5 algorithm, then the
+      non-significant bits of the timestamp are copied from the result.
+
+   The NTP format allows convenient multiple-precision arithmetic and
+   conversion to UDP/TIME message (seconds), but does complicate the
+   conversion to ICMP Timestamp message (milliseconds) and Unix time
+   values (seconds and microseconds or seconds and nanoseconds).  The
+   maximum number that can be represented is 4,294,967,295 seconds with
+   a precision of about 232 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).
+   There will exist a 232-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 over 20 years, it
+      is possible that it will be in use 32 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
+
+
+
+Mills                        Informational                      [Page 7]
+
+RFC 4330             SNTPv4 for IPv4, IPv6 and OSI          January 2006
+
+
+      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 a leap year, and
+      leap seconds are not included in the reckoning.
+
+      The arithmetic calculations used by NTP to determine the clock
+      offset and roundtrip delay require the client time to be within 34
+      years of the server time before the client is launched.  As the
+      time since the Unix base 1970 is now more than 34 years, means
+      must be available to initialize the clock at a date closer to the
+      present, either with a time-of-year (TOY) chip or from firmware.
+
+4.  Message Format
+
+   Both NTP and SNTP are clients of the User Datagram Protocol (UDP)
+   specified in RFC 768 [POS80].  The structures of the IP and UDP
+   headers are described in the cited specification documents and will
+   not be detailed further here.  The UDP port number assigned by the
+   IANA to NTP is 123.  The SNTP client should use this value in the UDP
+   Destination Port field for client request messages.  The Source Port
+   field of these messages can be any nonzero value chosen for
+   identification or multiplexing purposes.  The server interchanges
+   these fields for the corresponding reply messages.
+
+      This differs from the RFC 2030 specifications, which required both
+      the source and destination ports to be 123.  The intent of this
+      change is to allow the identification of particular client
+      implementations (which are now allowed to use unreserved port
+      numbers, including ones of their choosing) and to attain
+      compatibility with Network Address Port Translation (NAPT)
+      described in RFC 2663 [SRI99] and RFC 3022 [SRI01].
+
+   Figure 1 is a description of the NTP and SNTP message format, which
+   follows the IP and UDP headers in the message.  This format is
+   identical to the NTP message format described in RFC 1305, with the
+   exception of the Reference Identifier field described below.  For
+   SNTP client messages, most of these fields are zero or initialized
+   with pre-specified data.  For completeness, the function of each
+   field is briefly summarized below.
+
+
+
+
+
+
+
+
+
+
+
+
+Mills                        Informational                      [Page 8]
+
+RFC 4330             SNTPv4 for IPv4, IPv6 and OSI          January 2006
+
+
+                           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)                |
+      |                                                                |
+      |                                                                |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                        Figure 1.  NTP Packet Header
+
+   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.  This field is significant only in server messages, where the
+   values are defined as follows:
+
+
+
+
+
+
+
+
+
+Mills                        Informational                      [Page 9]
+
+RFC 4330             SNTPv4 for IPv4, IPv6 and OSI          January 2006
+
+
+      LI       Meaning
+      ---------------------------------------------
+      0        no warning
+      1        last minute has 61 seconds
+      2        last minute has 59 seconds
+      3        alarm condition (clock not synchronized)
+
+   On startup, servers set this field to 3 (clock not synchronized), and
+   set this field to some other value when synchronized to the primary
+   reference clock.  Once set to a value other than 3, the field is
+   never set to that value again, even if all synchronization sources
+   become unreachable or defective.
+
+   Version Number (VN): This is a three-bit integer indicating the
+   NTP/SNTP version number, currently 4.  If necessary to distinguish
+   between IPv4, IPv6, and OSI, the encapsulating context must be
+   inspected.
+
+   Mode: This is a three-bit number indicating the protocol mode.  The
+   values are 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 manycast modes, 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).  The other modes are not used by SNTP servers and
+   clients.
+
+   Stratum: This is an eight-bit unsigned integer indicating the
+   stratum.  This field is significant only in SNTP server messages,
+   where the values are defined as follows:
+
+      Stratum  Meaning
+      ----------------------------------------------
+      0        kiss-o'-death message (see below)
+      1        primary reference (e.g., synchronized by radio clock)
+      2-15     secondary reference (synchronized by NTP or SNTP)
+      16-255   reserved
+
+
+
+Mills                        Informational                     [Page 10]
+
+RFC 4330             SNTPv4 for IPv4, IPv6 and OSI          January 2006
+
+
+   Poll Interval: This is an eight-bit unsigned integer used as an
+   exponent of two, where the resulting value is the maximum interval
+   between successive messages in seconds.  This field is significant
+   only in SNTP server messages, where the values range from 4 (16 s) to
+   17 (131,072 s -- about 36 h).
+
+   Precision: This is an eight-bit signed integer used as an exponent of
+   two, where the resulting value is the precision of the system clock
+   in seconds.  This field is significant only in server messages, where
+   the values 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 the 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.  This field is significant
+   only in server messages, where the values range from negative values
+   of a few milliseconds to positive values of several hundred
+   milliseconds.
+
+      Code       External Reference Source
+      ------------------------------------------------------------------
+      LOCL       uncalibrated local clock
+      CESM       calibrated Cesium clock
+      RBDM       calibrated Rubidium clock
+      PPS        calibrated quartz clock or other pulse-per-second
+                 source
+      IRIG       Inter-Range Instrumentation Group
+      ACTS       NIST telephone modem service
+      USNO       USNO telephone modem service
+      PTB        PTB (Germany) telephone 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       Kauai 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
+
+                     Figure 2.  Reference Identifier Codes
+
+
+
+
+
+
+
+Mills                        Informational                     [Page 11]
+
+RFC 4330             SNTPv4 for IPv4, IPv6 and OSI          January 2006
+
+
+   Root Dispersion: This is a 32-bit unsigned fixed-point number
+   indicating the maximum error due to the clock frequency tolerance, in
+   seconds with the fraction point between bits 15 and 16.  This field
+   is significant only in server messages, where the values range from
+   zero to several hundred milliseconds.
+
+   Reference Identifier: This is a 32-bit bitstring identifying the
+   particular reference source.  This field is significant only in
+   server messages, where for stratum 0 (kiss-o'-death message) and 1
+   (primary server), the value is a four-character ASCII string, left
+   justified and zero padded to 32 bits.  For IPv4 secondary servers,
+   the value is the 32-bit IPv4 address of the synchronization source.
+   For IPv6 and OSI secondary servers, the value is the first 32 bits of
+   the MD5 hash of the IPv6 or NSAP address of the synchronization
+   source.
+
+   Primary (stratum 1) servers set this field to a code identifying the
+   external reference source according to Figure 2.  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.
+
+      In previous NTP and SNTP secondary servers and clients, this field
+      was often used to walk-back the synchronization subnet to the root
+      (primary server) for management purposes.  In SNTPv4 with IPv6 or
+      OSI, this feature is not available, because the addresses are
+      longer than 32 bits, and only a hash is available.  However, a
+      walk-back can be accomplished using the NTP control message and
+      the reference identifier field described in RFC 1305.
+
+   Reference Timestamp: This field is the time the system 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 or the reply arrived at the client, in 64-bit timestamp
+   format.
+
+   Transmit Timestamp: This is the time at which the request departed
+   the client or the reply departed the server, 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.
+
+
+
+
+Mills                        Informational                     [Page 12]
+
+RFC 4330             SNTPv4 for IPv4, IPv6 and OSI          January 2006
+
+
+5.  SNTP Client Operations
+
+   An SNTP client can operate in unicast, broadcast, or manycast modes.
+   In unicast mode, the client sends a request (NTP mode 3) to a
+   designated unicast server and expects a reply (NTP mode 4) from that
+   server.  In broadcast client mode, it sends no request and waits for
+   a broadcast (NTP mode 5) from one or more broadcast servers.  In
+   manycast mode, the client sends a request (NTP mode 3) to a
+   designated broadcast address and expects a reply (NTP mode 4) from
+   one or more manycast servers.  The client uses the first reply
+   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 manycast and unicast clients are
+   identical.
+
+      Client requests are normally sent at intervals depending on the
+      frequency tolerance of the client clock and the required accuracy.
+      However, under no conditions should requests be sent at less than
+      one minute intervals.  Further discussion on this point is in
+      Section 9.
+
+   A unicast or manycast 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 the NTP
+   header fields shown above are set to 0, except the Mode, VN, and
+   optional Transmit Timestamp fields.
+
+   NTP and SNTP clients set the mode field to 3 (client) for unicast and
+   manycast requests.  They set the VN field to any version number that
+   is supported by the server, selected by configuration or discovery,
+   and that can interoperate with all previous version NTP and SNTP
+   servers.  Servers reply with the same version as the request, so the
+   VN field of the request also specifies the VN field of the reply.  A
+   prudent SNTP client can specify the earliest acceptable version on
+   the expectation that any server of that or a later version will
+   respond.  NTP Version 3 (RFC 1305) and Version 2 (RFC 1119) servers
+   accept all previous versions, including Version 1 (RFC 1059).  Note
+   that Version 0 (RFC 959) is no longer supported by current and future
+   NTP and SNTP servers.
+
+   Although setting the Transmit Timestamp field in the request to the
+   time of day according to the client clock in NTP timestamp format is
+   not necessary in a conforming client implementation, it is highly
+   recommended in unicast and manycast modes.  This allows a simple
+   calculation to determine the propagation delay between the server and
+   client and to align the system clock generally within a few tens of
+   milliseconds relative to the server.  In addition, this provides a
+
+
+
+Mills                        Informational                     [Page 13]
+
+RFC 4330             SNTPv4 for IPv4, IPv6 and OSI          January 2006
+
+
+   simple method for verifying that the server reply is in fact a
+   legitimate response to the specific client request and thereby for
+   avoiding replays.  In broadcast mode, the client has no information
+   to calculate the propagation delay or to determine the validity of
+   the server, unless one of the NTP authentication schemes is used.
+
+   To calculate the roundtrip delay d and system clock offset t relative
+   to the server, the client sets the Transmit Timestamp field in the
+   request to the time of day according to the client clock in NTP
+   timestamp format.  For this purpose, the clock need not be
+   synchronized.  The server copies this field to the Originate
+   Timestamp in the reply and sets the Receive Timestamp and Transmit
+   Timestamp fields 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 system clock offset t are defined as:
+
+      d = (T4 - T1) - (T3 - T2)     t = ((T2 - T1) + (T3 - T4)) / 2.
+
+   Note that in general both delay and offset are signed quantities and
+   can be less than zero; however, a delay less than zero is possible
+   only in symmetric modes, which SNTP clients are forbidden to use.
+   The following table summarizes the required SNTP client operations in
+   unicast, manycast, and broadcast modes.  The recommended error checks
+   are shown in the Reply and Broadcast 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.
+
+
+
+
+
+
+
+
+
+
+Mills                        Informational                     [Page 14]
+
+RFC 4330             SNTPv4 for IPv4, IPv6 and OSI          January 2006
+
+
+      Field Name               Unicast/Manycast            Broadcast
+                               Request     Reply
+      ---------------------------------------------------------------
+      LI                       0           0-3            0-3
+
+      VN                       1-4         copied from    1-4
+                                           request
+
+      Mode                     3           4              5
+
+      Stratum                  0           0-15           0-15
+
+      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
+
+   Although not required in a conforming SNTP client implementation, it
+   is wise to consider a suite of sanity checks designed to avoid
+   various kinds of abuse that might happen as the result of server
+   implementation errors or malicious attack.  Following is a list of
+   suggested checks.
+
+   1.  When the IP source and destination addresses are available for
+       the client request, they should match the interchanged addresses
+       in the server reply.
+
+   2.  When the UDP source and destination ports are available for the
+       client request, they should match the interchanged ports in the
+       server reply.
+
+   3.  The Originate Timestamp in the server reply should match the
+       Transmit Timestamp used in the client request.
+
+
+
+Mills                        Informational                     [Page 15]
+
+RFC 4330             SNTPv4 for IPv4, IPv6 and OSI          January 2006
+
+
+   4.  The server reply should be discarded if any of the LI, Stratum,
+       or Transmit Timestamp fields is 0 or the Mode field is not 4
+       (unicast) or 5 (broadcast).
+
+   5.  A truly paranoid client can check that the Root Delay and Root
+       Dispersion fields are each greater than or equal to 0 and less
+       than infinity, where infinity is currently a cozy number like one
+       second.  This check avoids using a server whose synchronization
+       source has expired for a very long time.
+
+6.  SNTP Server Operations
+
+   A SNTP server operating with either an NTP or SNTP client of the same
+   or previous versions retains no persistent state.  Because an SNTP
+   server ordinarily does not implement the full suite of grooming and
+   mitigation algorithms intended to support redundant servers and
+   diverse network paths, it 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 operates as a primary (stratum
+   1) server.
+
+   A SNTP server can operate with any unicast, manycast, or broadcast
+   address or any combination of these addresses.  A unicast or manycast
+   server receives a request (NTP mode 3), modifies certain fields in
+   the NTP header, and sends a reply (NTP mode 4), possibly using the
+   same message buffer as the request.  A manycast server listens on the
+   designated broadcast address, but uses its own unicast IP address in
+   the source address field of the reply.  Other than the selection of
+   address in the reply, the operations of manycast and unicast servers
+   are identical.  Broadcast messages are normally sent at intervals
+   from 64 s to 1024 s, depending on the expected frequency tolerance of
+   the client clocks and the required accuracy.
+
+   Unicast and manycast servers copy the VN and Poll fields of the
+   request intact to the reply and set the Stratum field to 1.
+
+      Note that SNTP servers normally operate as primary (stratum 1)
+      servers.  Although operating at higher strata (up to 15) while
+      synchronizing to an external source such as a GPS receiver is not
+      forbidden, this is strongly discouraged.
+
+   If the Mode field of the request is 3 (client), the reply is set to 4
+   (server).  If this field is set to 1 (symmetric active), the reply is
+   set to 2 (symmetric passive).  This allows clients configured in
+   either client (NTP mode 3) or symmetric active (NTP mode 1) to
+   interoperate successfully, even if configured in possibly suboptimal
+   ways.  For any other value in the Mode field, the request is
+
+
+
+
+Mills                        Informational                     [Page 16]
+
+RFC 4330             SNTPv4 for IPv4, IPv6 and OSI          January 2006
+
+
+   discarded.  In broadcast (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 a broadcast server also
+      supports unicast clients.  This is so a potential broadcast client
+      can calculate the propagation delay using a client/server exchange
+      prior to switching to broadcast client (listen-only) mode.  By
+      design, a manycast server is also a unicast server.  There does
+      not seem to be a great advantage for a server to operate as both
+      broadcast and manycast at the same time, although the protocol
+      specification does not forbid it.
+
+   A broadcast or manycast server does not send packets if not
+   synchronized to a correctly operating reference source.  It may or
+   may not respond to a client request if it is not synchronized, but
+   the preferred option is to respond because this allows reachability
+   to be determined regardless of synchronization state.  If the server
+   has never synchronized to a reference source, the LI field is set to
+   3 (unsynchronized).  Once synchronized to a reference source, the LI
+   field is set to one of the other three values and remains at the last
+   value set even if the reference source becomes unreachable or turns
+   faulty.
+
+   If the server is synchronized to a reference source, the Stratum
+   field is set to 1, and the Reference Identifier field is set to the
+   ASCII source identifier shown in Figure 2.  If the server is not
+   synchronized, the Stratum field is set to zero, and the Reference
+   Identifier field is set to an ASCII error identifier described below.
+
+   The Precision field is set to reflect the maximum reading error of
+   the system clock.  For all practical cases it is computed as the
+   negative base-2 logarithm 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.
+
+   The timestamp fields in the server message are set as follows.  If
+   the server is unsynchronized or first coming up, all timestamp fields
+   are set to zero, with one exception.  If the message is a reply to a
+   previously received client request, the Transmit Timestamp field of
+   the request is copied unchanged to the Originate Timestamp field of
+   the reply.  It is important that this field be copied intact, as an
+   NTP or SNTP client uses it to avoid bogus messages.
+
+   If the server is synchronized, the Reference Timestamp is set to the
+   time the last update was received from the reference source.  The
+   Originate Timestamp field is set as in the unsynchronized case above.
+   The Transmit Timestamp field is set to the time of day when the
+
+
+
+Mills                        Informational                     [Page 17]
+
+RFC 4330             SNTPv4 for IPv4, IPv6 and OSI          January 2006
+
+
+   message is sent.  In broadcast messages the Receive Timestamp field
+   is set to zero and copied from the Transmit Timestamp field in other
+   messages.  The following table summarizes these actions.
+
+      Field Name             Unicast/Manycast             Broadcast
+                             Request     Reply
+      ----------------------------------------------------------------
+      LI                     ignore      as needed       as needed
+
+      VN                     1-4         copied from     4
+                                         request
+
+      Mode                   3           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
+                                         source update   source update
+
+      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 the server is first coming up or
+   during periods when the reference source is inoperative.  The most
+   important indicator of an unhealthy server is the Stratum field, in
+
+
+
+
+
+Mills                        Informational                     [Page 18]
+
+RFC 4330             SNTPv4 for IPv4, IPv6 and OSI          January 2006
+
+
+   which a value of 0 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 web
+   client, if available, or a serial port, if not.  Some folks hoped
+   that in-service management of NTP and SNTPv4 servers and clients
+   could be performed using SNMP and a suitable MIB to be published, and
+   this has happened in some commercial SNTP servers.  But, the means
+   that have been used in the last two decades and probably will be used
+   in the next is the NTP control and monitoring protocol defined in RFC
+   1305.  Ordinarily, SNTP servers and clients are expected to operate
+   with little or no site-specific configuration, other than specifying
+   the client IP address, subnet mask, and gateway.
+
+   Unicast clients must be provided with one or more designated server
+   names or IP addresses.  If more than one server is provided, one can
+   be used for active operation and one of the others for backup should
+   the active one fail or show an error condition.  It is not normally
+   useful to use more than one server at a time, as with millions of
+   SNTP-enabled devices expected in the near future, such use would
+   represent unnecessary drain on network and server resources.
+
+   Broadcast servers and manycast clients must be provided with the TTL
+   and local broadcast or multicast group address.  Unicast and manycast
+   servers and broadcast 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 accepted.  Multicast 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 memo.
+
+   There are several scenarios that provide automatic server discovery
+   and selection for SNTP clients with no pre-specified server
+   configuration.  For instance, a role server with CNAME such as
+   pool.ntp.org returns a randomized list of volunteer secondary server
+   addresses, and the client can select one or more as candidates.  For
+   an IP subnet or LAN segment including an NTP or SNTP server, SNTP
+   clients can be configured as broadcast clients.  The same approach
+   can be used with multicast servers and clients.  In both cases,
+   provision of an access control list is a good way to ensure that only
+   trusted sources can be used to set the system clock.
+
+
+
+
+
+
+Mills                        Informational                     [Page 19]
+
+RFC 4330             SNTPv4 for IPv4, IPv6 and OSI          January 2006
+
+
+   In another scenario suitable for an extended network with significant
+   network propagation delays, clients can be configured for manycast
+   addresses, 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 server from which the first
+   reply is received and continues operation in unicast mode.
+
+8.  The Kiss-o'-Death Packet
+
+   In the rambunctious Internet of today, it is imperative that some
+   means be available to tell a client to stop making requests and to go
+   somewhere else.  A recent experience involved a large number of
+   home/office routers all configured to use a particular university
+   time server.  Under some error conditions, a substantial fraction of
+   these routers would send packets at intervals of one second.  The
+   resulting traffic spike was dramatic, and extreme measures were
+   required to diagnose the problem and to bring it under control.  The
+   conclusion is that clients must respect the means available to
+   targeted servers to stop them from sending packets.
+
+   According to the NTP specification RFC 1305, if the Stratum field in
+   the NTP header is 1, indicating a primary server, the Reference
+   Identifier field contains an ASCII string identifying the particular
+   reference clock type.  However, in RFC 1305 nothing is said about the
+   Reference Identifier field if the Stratum field is 0, which is called
+   out as "unspecified".  However, if the Stratum field is 0, the
+   Reference Identifier field can be used to convey messages useful for
+   status reporting and access control.  In NTPv4 and SNTPv4, packets of
+   this kind are called Kiss-o'-Death (KoD) packets, and the ASCII
+   messages they convey are called kiss codes.  The KoD packets got
+   their name because an early use was to tell clients to stop sending
+   packets that violate server access controls.
+
+   In general, an SNTP client should stop sending to a particular server
+   if that server returns a reply with a Stratum field of 0, regardless
+   of kiss code, and an alternate server is available.  If no alternate
+   server is available, the client should retransmit using an
+   exponential-backoff algorithm described in the next section.
+
+   The kiss codes can provide useful information for an intelligent
+   client.  These codes are encoded in four-character ASCII strings left
+   justified and zero filled.  The strings are designed for character
+   displays and log files.  Usually, only a few of these codes can occur
+   with SNTP clients, including DENY, RSTR, and RATE.  Others can occur
+   more rarely, including INIT and STEP, when the server is in some
+   special temporary condition.  Figure 3 shows a list of the kiss codes
+   currently defined.  These are for informational purposes only; the
+   list might be modified or extended in the future.
+
+
+
+Mills                        Informational                     [Page 20]
+
+RFC 4330             SNTPv4 for IPv4, IPv6 and OSI          January 2006
+
+
+      Code    Meaning
+      --------------------------------------------------------------
+      ACST    The association belongs to a anycast server
+      AUTH    Server authentication failed
+      AUTO    Autokey sequence failed
+      BCST    The association belongs to a broadcast server
+      CRYP    Cryptographic authentication or identification failed
+      DENY    Access denied by remote server
+      DROP    Lost peer in symmetric mode
+      RSTR    Access denied due to local policy
+      INIT    The association has not yet synchronized for the first
+              time
+      MCST    The association belongs to a manycast server
+      NKEY    No key found.  Either the key was never installed or
+              is not trusted
+      RATE    Rate exceeded.  The server has temporarily denied access
+              because the client exceeded the rate threshold
+      RMOT    Somebody is tinkering with the association from a remote
+              host running ntpdc.  Not to worry unless some rascal has
+              stolen your keys
+      STEP    A step change in system time has occurred, but the
+              association has not yet resynchronized
+
+                           Figure 3.  Kiss Codes
+
+9.  On Being a Good Network Citizen
+
+   SNTP and its big brother NTP have been in explosive growth over the
+   last few years, mirroring the growth of the Internet.  Just about
+   every Internet appliance has some kind of NTP support, including
+   Windows XP, Cisco routers, embedded controllers, and software systems
+   of all kinds.  This is the first edition of the SNTP RFC where it has
+   become necessary to lay down rules of engagement in the form of
+   design criteria for SNTP client implementations.  This is necessary
+   to educate software developers regarding the proper use of Internet
+   time server resources as the Internet expands and demands on time
+   servers increase, and to prevent the recurrence of the sort of
+   problem mentioned above.
+
+10.  Best Practices
+
+   NTP and SNTP clients can consume considerable network and server
+   resources if they are not good network citizens.  There are now
+   consumer Internet commodity devices numbering in the millions that
+   are potential customers of public and private NTP and SNTP servers.
+   Recent experience strongly suggests that device designers pay
+   particular attention to minimizing resource impacts, especially if
+   large numbers of these devices are deployed.  The most important
+
+
+
+Mills                        Informational                     [Page 21]
+
+RFC 4330             SNTPv4 for IPv4, IPv6 and OSI          January 2006
+
+
+   design consideration is the interval between client requests, called
+   the poll interval.  It is extremely important that the design use the
+   maximum poll interval consistent with acceptable accuracy.
+
+   1.  A client MUST NOT under any conditions use a poll interval less
+       than 15 seconds.
+
+   2.  A client SHOULD increase the poll interval using exponential
+       backoff as performance permits and especially if the server does
+       not respond within a reasonable time.
+
+   3.  A client SHOULD use local servers whenever available to avoid
+       unnecessary traffic on backbone networks.
+
+   4.  A client MUST allow the operator to configure the primary and/or
+       alternate server names or addresses in addition to or in place of
+       a firmware default IP address.
+
+   5.  If a firmware default server IP address is provided, it MUST be a
+       server operated by the manufacturer or seller of the device or
+       another server, but only with the operator's permission.
+
+   6.  A client SHOULD use the Domain Name System (DNS) to resolve the
+       server IP addresses, so the operator can do effective load
+       balancing among a server clique and change IP address binding to
+       canonical names.
+
+   7.  A client SHOULD re-resolve the server IP address at periodic
+       intervals, but not at intervals less than the time-to-live field
+       in the DNS response.
+
+   8.  A client SHOULD support the NTP access-refusal mechanism so that
+       a server kiss-o'-death reply in response to a client request
+       causes the client to cease sending requests to that server and to
+       switch to an alternate, if available.
+
+   The following algorithm can be used as a pattern for specific
+   implementations.  It uses the following variables:
+
+   Timer: This is a counter that decrements at a fixed rate.  When it
+   reaches zero, a packet is sent, and the timer is initialized with the
+   timeout for the next packet.
+
+   Maximum timeout: This is the maximum timeout determined from the
+   given oscillator frequency tolerance and the required accuracy.
+
+
+
+
+
+
+Mills                        Informational                     [Page 22]
+
+RFC 4330             SNTPv4 for IPv4, IPv6 and OSI          January 2006
+
+
+   Server Name: This is the DNS name of the server.  There may be more
+   than one of them, to be selected by some algorithm not considered
+   here.
+
+   Server IP Address: This is the IPv4, IPv6, or OSI address of the
+   server.
+
+   If the firmware or documentation includes specific server names, the
+   names should be those the manufacturer or seller operates as a
+   customer convenience or those for which specific permission has been
+   obtained from the operator.  A DNS request for a generic server name,
+   such as ntp.mytimeserver.com, should result in a random selection of
+   server IP addresses available for that purpose.  Each time a DNS
+   request is received, a new randomized list is returned.  The client
+   ordinarily uses the first address on the list.
+
+      When candidate SNTP or NTP servers are selected, it is imperative
+      to respect the server operator's conditions of access.  Lists of
+      public servers and their conditions of access are available at
+      www.ntp.org.  A semi-automatic server discovery scheme using DNS
+      is described at that site.  Some ISPs operate public servers,
+      although finding them via their help desks can be difficult.
+
+   A well-behaved client operates as follows (note that steps 2-4
+   constitute a synchronization loop):
+
+   1.  Consider the specified frequency tolerance of the system clock
+       oscillator.  Define the required accuracy of the system clock,
+       then calculate the maximum timeout.  For instance, if the
+       frequency tolerance is 200 parts per million (PPM) and the
+       required accuracy is one minute, the maximum timeout is about 3.5
+       days.  Use the longest maximum timeout possible given the system
+       constraints to minimize time server aggregate load, but never
+       make it less than 15 minutes.
+
+   2.  When the client is first coming up or after reset, randomize the
+       timeout from one to five minutes.  This is to minimize shock when
+       3000 PCs are rebooted at the same time power is restored after a
+       blackout.  Assume at this time that the IP address is unknown and
+       that the system clock is unsynchronized.  Otherwise, use the
+       timeout value as calculated in previous loop steps.  Note that it
+       may be necessary to refrain from implementing the aforementioned
+       random delay for some classes of International Computer Security
+       Association (ICSA) certification.
+
+
+
+
+
+
+
+Mills                        Informational                     [Page 23]
+
+RFC 4330             SNTPv4 for IPv4, IPv6 and OSI          January 2006
+
+
+   3.  When the timer reaches zero, if the IP address is not known, send
+       a DNS query packet; otherwise, send an NTP request packet to that
+       address.  If no reply packet has been heard since the last
+       timeout, double the timeout, but do not make it greater than the
+       maximum timeout.  If primary and secondary time servers have been
+       configured, alternate queries between the primary and secondary
+       servers when no successful response has been received.
+
+   4.  If a DNS reply packet is received, save the IP address and
+       continue at step 2.  If a KoD packet is received, remove that
+       time server from the list, activate the secondary time server,
+       and continue at step 2.  If a received packet fails the sanity
+       checks, drop that packet and also continue at step 2.  If a valid
+       NTP packet is received, update the system clock, set the timeout
+       to the maximum, and continue at step 2.
+
+11.  Security Considerations
+
+   Without cryptographic authentication, SNTPv4 service is vulnerable to
+   disruption by misbehaving or hostile SNTP or NTP broadcast servers
+   elsewhere in the Internet.  It is strongly recommended that access
+   controls and/or cryptographic authentication means be provided for
+   additional security.  This document includes protocol provisions for
+   adding such security mechanisms, but it does not define the
+   mechanisms themselves.  A separate document [MIL03] in preparation
+   will define a cryptographic security mechanism for SNTP.
+
+12.  Acknowledgements
+
+   Jeff Learman was helpful in developing the OSI model for this
+   protocol.  Ajit Thyagarajan provided valuable suggestions and
+   corrections.
+
+13.  Contributors
+
+   D. Plonka
+
+   J. Montgomery
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mills                        Informational                     [Page 24]
+
+RFC 4330             SNTPv4 for IPv4, IPv6 and OSI          January 2006
+
+
+14.  Informative References
+
+   [BRA97]  Bradner, S., "Key words for use in RFCs to Indicate
+            Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [COL94]  Colella, R., Callon, R., Gardner, E., and Y. Rekhter,
+            "Guidelines for OSI NSAP Allocation in the Internet", RFC
+            1629, May 1994.
+
+   [DEE89]  Deering, S., "Host extensions for IP multicasting", STD 5,
+            RFC 1112, August 1989.
+
+   [DEE98]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
+            (IPv6) Specification", RFC 2460, December 1998.
+
+   [DOB91]  Shue, C., Haggerty, W., and K. Dobbins, "OSI connectionless
+            transport services on top of UDP: Version 1", RFC 1240, June
+            1991.
+
+   [FUR94]  Furniss, P., "Octet Sequences for Upper-Layer OSI to Support
+            Basic Communications Applications", RFC 1698, October 1994.
+
+   [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, March 1992.
+
+   [MIL03]  Mills, D., "The Autokey Security Architecture, Protocol and
+            Algorithms", http://eecis.udel.edu/~mills/database/reports/
+            stime/stime.pdf, August 2003.
+
+   [PAR93]  Partridge, C., Mendez, T., and W. Milliken, "Host Anycasting
+            Service", RFC 1546, November 1993.
+
+   [POS80]  Postel, J., "User Datagram Protocol", STD 6, RFC 768, August
+            1980.
+
+   [POS83]  Postel, J. and K. Harrenstien, "Time Protocol", STD 26, RFC
+            868, May 1983.
+
+   [SRI99]  Srisuresh, P. and M. Holdrege, "IP Network Address
+            Translator (NAT) Terminology and Considerations", RFC 2663,
+            August 1999.
+
+
+
+
+
+Mills                        Informational                     [Page 25]
+
+RFC 4330             SNTPv4 for IPv4, IPv6 and OSI          January 2006
+
+
+   [SRI01]  Srisuresh, P. and K. Egevang, "Traditional IP Network
+            Address Translator (Traditional NAT)", RFC 3022, January
+            2001.
+
+Author's Address
+
+   David L. Mills
+   Electrical and Computer Engineering Department
+   University of Delaware
+   Newark, DE 19716
+
+   Phone: (302) 831-8247
+   EMail: mills@udel.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mills                        Informational                     [Page 26]
+
+RFC 4330             SNTPv4 for IPv4, IPv6 and OSI          January 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78 and at www.rfc-editor.org/copyright.html, and
+   except as set forth therein, the authors retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Mills                        Informational                     [Page 27]
+