Network Time Protocol Working
NTP WG                                                   J. Burbank (Editor)
Group                                                            JHU/APL Burbank, Ed.
Internet-Draft                                     J. Martin (co-Editor)                                                   JHU APL
Expires: January 9, April 26, 2006                                   J. Martin, Ed.
                                                             Netzwert AG
                                                              July,
                                                                D. Mills
                                                                 U. Del.
                                                        October 23, 2005

       The Network Time Protocol Version 4 Protocol Specification
                     <draft-ietf-ntp-ntpv4-proto-00>
                     draft-ietf-ntp-ntpv4-proto-01

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of Section 3 of RFC 3978.

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts. Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This document is a submission of the IETF NTP WG.  Comments should be
   directed to the NTP WG mailing list, ntpwg@lists.ntp.isc.org.

   This Internet-Draft will expire on January 9, April 26, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   The Network Time Protocol (NTP) is widely used to synchronize
   computer clocks in the Internet.  This memorandum describes Version 4
   of the NTP (NTPv4), introducing several changes from Version 3 of NTP
   (NTPv3) described in RFC 1305, including the introduction of a
   modified protocol header to accomodate Internet Protocol Version 6.

   NTPv4 also includes optional extensions to the NTPv3
   protocol,including an anycast mode a dynamic server discovery mechanism and an
   authentication scheme designed specifically for multicast and anycast modes.
   dynamically discovered servers.

Table of Contents

   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3   4
   2.  NTPv4 Protocol Operation   NTP Timestamp  . . . . . . . . . . . . . . . . . . .  4 . . . .   5
   3.  NTPv4 Timestamp Format   NTP Message Formats  . . . . . . . . . . . . . . . . . . . .  6

   4.  NTPv4 Message Formats   7
     3.1  Leap Indicator (LI)  . . . . . . . . . . . . . . . . . . .   8
     3.2  Version (VN) .  7

   5.  NTPv4 Client Operations . . . . . . . . . . . . . . . . . . . 13

   6.  NTPv4 Server Operations . . .   9
     3.3  Mode . . . . . . . . . . . . . . . . 15

   7.  NTPv4 Security . . . . . . . . . . .   9
     3.4  Stratum (Strat)  . . . . . . . . . . . . . 19
       7.1 Session Keys and Cookies . . . . . . . .  10
     3.5  Poll Interval (Poll) . . . . . . . . . 19
       7.2 Session Key List Generation . . . . . . . . . .  10
     3.6  Precision (Prec) . . . . . 20
       7.3 Sending Messages . . . . . . . . . . . . . . . .  10
     3.7  Root Delay . . . . . 20
       7.4 Receiving Messages . . . . . . . . . . . . . . . . . . .  10
     3.8  Root Dispersion  . 20
       7.5 Autokey Protocol Exchanges . . . . . . . . . . . . . . . . 20

   8.  Operation and Management Issues . . . .  10
     3.9  Reference Identifier . . . . . . . . . . . 22

   9.  Kiss o' Death Message . . . . . . . .  11
     3.10   Reference Timestamp  . . . . . . . . . . . . 22

   10. Security Considerations . . . . . .  12
     3.11   Originate Timestamp  . . . . . . . . . . . . . 24

   11. IANA Considerations . . . . .  12
     3.12   Receive Timestamp  . . . . . . . . . . . . . . . . 25

   12. Other Considerations . . .  12
     3.13   Transmit Timestamp . . . . . . . . . . . . . . . . . . 25

   13. Acknowledgments .  12
     3.14   NTPv4 Extension Fields . . . . . . . . . . . . . . . . .  12
     3.15   Authentication (optional)  . . . . . 27

   14. References . . . . . . . . . .  13
   4.   NTP Protocol Operation . . . . . . . . . . . . . . . . 27
      14.1   Normative References . . .  14
   5.   SNTP Protocol Operation  . . . . . . . . . . . . . . . 27
      14.2   Informative References . . .  14
   6.   NTP Server Operations  . . . . . . . . . . . . . . 27
   15. Authors' Addresses . . . . .  15
   7.   NTP Client Operations  . . . . . . . . . . . . . . . . . 28

       Intellectual Property and Copyright Statements . .  17
   8.   NTP Symmetric Peer Operations  . . . . . . 29

1.  Introduction

   The Network Time Protocol Version 3 (NTPv3) specified in RFC 1305
   [MIL92] has been widely used to synchronize computer clocks in the
   global Internet.  It provides comprehensive mechanisms to access
   national time and frequency dissemination . . . . . . . . .  20
   9.   NTPv4 Security . . . . . . . . . . . . . . . . . . . . . . .  20
     9.1  Session Keys and Cookies . . . . . . . . . . . . . . . . .  20
     9.2  Session Key List Generation  . . . . . . . . . . . . . . .  21
     9.3  Sending Messages . . . . . . . . . . . . . . . . . . . . .  21
     9.4  Receiving Messages . . . . . . . . . . . . . . . . . . . .  21
     9.5  Autokey Protocol Exchanges . . . . . . . . . . . . . . . .  22
   10.  Dynamic Server Discovery . . . . . . . . . . . . . . . . . .  23
   11.  NTP Control Messages . . . . . . . . . . . . . . . . . . . .  24
     11.1   NTP Control Message Format . . . . . . . . . . . . . . .  26
     11.2   Status Words . . . . . . . . . . . . . . . . . . . . . .  27
       11.2.1   System Status Word . . . . . . . . . . . . . . . . .  28
       11.2.2   Peer Status Word . . . . . . . . . . . . . . . . . .  29
       11.2.3   Clock Status Word  . . . . . . . . . . . . . . . . .  31
       11.2.4   Error Status Word  . . . . . . . . . . . . . . . . .  32
     11.3   Commands . . . . . . . . . . . . . . . . . . . . . . . .  33
   12.  The Kiss-o'-Death Packet . . . . . . . . . . . . . . . . . .  35
   13.  Security Considerations  . . . . . . . . . . . . . . . . . .  36
   14.  IANA Considerations  . . . . . . . . . . . . . . . . . . . .  37
   15.  Other Considerations . . . . . . . . . . . . . . . . . . . .  37
   16.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . .  39
   17.  References . . . . . . . . . . . . . . . . . . . . . . . . .  39
     17.1   Normative References . . . . . . . . . . . . . . . . . .  39
     17.2   Informative References . . . . . . . . . . . . . . . . .  39
        Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  40
        Intellectual Property and Copyright Statements . . . . . . .  42

1.  Introduction

   The Network Time Protocol Version 3 (NTPv3) specified in [1] has been
   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 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.

   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,
   mitigation algorithms and security schemes, is a relatively complex,
   real-time application.  While 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.  This facilitated the development of the Simple
   Network Time Protocol Version 4 (SNTPv4) as described in [2].

   Since the standardization of NTPv3, there has been significant
   development which has led to Version 4 of the Network Time Protocol
   (NTPv4).  This document describes NTPv4, which introduces new
   functionality to NTPv3 as described in RFC 1305, and functionality
   expanded from that of SNTPv4 as described in RFC 2030 (SNTPv4 is a
   subset of NTPv4).

   When operating with current and previous versions of NTP and SNTP,
   NTPv4 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
   round trip delay are the same.  To a NTP or SNTP server, NTP and SNTP
   clients are indistinguishable; to a NTP or SNTP client, NTP and SNTP
   servers are indistinguishable.

   An important provision in this memo is the interpretation of certain
   NTP header fields which provide for IPv6 and OSI addressing.  The
   only significant difference between the NTPv3 and NTPv4 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, while
   secondary servers use the 32-bit IPv4 address of the synchronization
   source.  In NTPv4 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
   document.

   In the case of OSI, the Connectionless Transport Service (CLTS) is
   used as in [3].  Each NTP packet is transmitted as the TS- Userdata
   parameter of a T-UNITDATA Request primitive.  Alternately, the header
   can be encapsulated in a TPDU which itself is transported using UDP,
   as described in [4].  It is not advised that NTP be operated at the
   upper layers of the OSI stack, such as might be inferred from [5], 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 document is organized as follows.Section 2 describes the NTP
   timestamp format and Section 3 the NTP message format.  Section 4
   provides general NTP protocol details, with the subset SNTP described
   in Section 5.  This is followed by specific sections on Server
   (Section 6), Client(Section 7), and Symmetric Peer(Section 8) modes
   of operation.Section 9 summarizes the optional security mechanisms
   present within the NTPv4 protocol.  Section 10 defines the new
   mechanism for server discovery.  Section 11 describes the control and
   management mechanism for NTP.  Section 12 describes the kiss-o'-death
   message, whose functionality is similar to the ICMP Source Quench and
   ICMP Destination Unreachable messages.  Section 13 presents NTPv4
   security considerations and Section 14 discusses IANA Considerations.
   Finally, Section 15 presents various other considerations when
   implementing and/or configuring NTPv4.

   NTPv4 is hereafter referred to simply as NTP, unless explicitly
   noted.

2.  NTP Timestamp

   NTPv4 uses the standard NTP timestamp format described in RFC 1305.
   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.

   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 ordinarily set to 0.  The NTP timestamp format is
   defined as:

    0                   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                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            Fraction                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   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).  It is important that the bitstring be unpredictable by
   a 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.

   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.

   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 a leap year and leap seconds are not included
   in the reckoning.

3.  NTP Message Formats

   Both NTP and SNTP are layered above of the User Datagram Protocol
   (UDP) [6], which itself is layered on the Internet Protocol (IP) [7]
   [8].  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.

   Below is a description of the NTPv4 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:

    0                   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 |     Strat     |     Poll      |     Prec      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Root Delay                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Root Dispersion                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Reference ID                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                       Reference Timestamp                     +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                        Origin Timestamp                       +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                        Receive Timestamp                      +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                        Transmit Timestamp                     +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                    Extension Field 1 (Optional)               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                    Extension Field 2 (Optional)               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   .                                                               .
   .                          Authentication                       .
   .                       (Optional) (160 bits)                   .
   .                                                               .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3.1  Leap Indicator (LI)

   This is a two-bit field indicating an impending leap second to be
   inserted in the NTP timescale.  The bits are set before 23:59 on the
   day of insertion and reset after 00:00 on the following day.  This
   causes the number of seconds (rollover interval) in the day of
   insertion to be increased or decreased by one.  In the case of
   primary servers the bits are set by operator intervention, while in
   the case of secondary servers the bits are set by the protocol.  The
   possible values of the LI field, and corresponding meanings, are as
   follows:

           +----+------------------------------------------+
           | 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 other than 3, the field is never set to
   that value again, even if all synchronization sources become
   unreachable or defective.

3.2  Version (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.

3.3  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 mode or discovery 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).

3.4  Stratum (Strat)

   This is a 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                 |
  |    1    | primary reference (e.g., synchronized by radio clock) |
  |   2-15  |   secondary reference (synchronized by NTP or SNTP)   |
  |  16-255 |                        reserved                       |
  +---------+-------------------------------------------------------+

3.5  Poll Interval (Poll)

   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).

3.6  Precision (Prec)

   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.

3.7  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.  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.

3.8  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.  This field is significant
   only in server messages, where the values range from zero to several
   hundred milliseconds.

3.9  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 the below table.

  +------+----------------------------------------------------------+
  | 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 | Kaui 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                               |
  +------+----------------------------------------------------------+

   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 and adjust this field was
   often used to walk-back the synchronization subnet to the root
   (primary server) for management purposes.

3.10  Reference Timestamp

   This field is significant only in server messages, where the value is
   the time at which the system clock was last set or corrected, in each
   participant. In most places of 64-
   bit timestamp format.

3.11  Originate Timestamp

   This is the Internet of today, NTP provides
   accuracies of 1-50 ms, depending on time at which the characteristics of request departed the
   synchronization source and network paths.

   NTP is designed client 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 the
   server, in 64-bit timestamp format.

3.12  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.

3.13  Transmit Timestamp

   This is the Internet
   of today use a software distribution available from www.ntp.org.  The
   distribution, time at which includes the full suite of NTP options,
   mitigation algorithms request departed the client or the
   reply departed the server, in 64-bit timestamp format.

3.14  NTPv4 Extension Fields

   NTPv4 defines new extension field formats.  These fields are
   processed in order and security schemes, may be transmitted with or without value
   fields.  The last field is a relatively complex,
   real-time application.  While the software has been ported padded to a wide
   variety of hardware platforms ranging from personal computers 64-bit boundary, all others
   fields are padded to
   supercomputers, its sheer size and complexity 32-bit boundaries.  The field length is not appropriate for
   many applications.  This facilitated the development of the Simple
   Network Time Protocol Version all
   payload and padding.

    0                   1                   2                   3
    0 1 2 3 4 (SNTPv4) as described in RFC 2030
   [MIL96].

   Since the standardization of NTPv3, there has been significant
   development which has led to Version 5 6 7 8 9 0 1 2 3 4 of 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Field Type           |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Association ID                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Timestamp                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Filestamp                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Value Length                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   .                                                               .
   .                             Value                             .
   .                                                               .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Signature Length                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   .                                                               .
   .                           Signature                           .
   .                                                               .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Padding (as needed)                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3.15  Authentication (optional)

   The authentication field format is defined as:

    0                   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Key Identifier                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                                                               |
   +                         Message Digest                        +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   When the Network Time Protocol
   (NTPv4).  This document describes NTPv4, which introduces new
   functionality to NTPv3 as described in RFC 1305, and functionality
   expanded from that of SNTPv4 as described in RFC 2030 (SNTPv4 NTP authentication scheme is a
   subset of NTPv4).

   When operating with current implemented, the 16-bit Key
   Identifier and previous versions 128-bit Message Digest fields contain the Message
   Authentication Code (MAC) information which uses an MD5 cryptosum of
   NTP and SNTP,
   NTPv4 requires no changes to the protocol or implementations now
   running or likely to be implemented specifically for future header plus extension fields.

4.  NTP or
   SNTP versions. Protocol Operation

   The NTP protocol defines three operational roles, Client, Server, 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 a NTP
   Symmetric Peer.  Clients request or SNTP server, NTP and SNTP
   clients are indistinguishable; receive time unsolicited from
   Servers.  Servers respond to a NTP requests or SNTP client, send periodic time updates
   to Clients.  Symmetric Peers exchange time data bidirectionally.  A
   given NTP and SNTP
   servers are indistinguishable.

   An important provision implementation can operate in this memo is the interpretation any or all of certain these modes.

   NTP header fields which provide for IPv6 messages make use of two different communication modes, one to
   one and OSI addressing.  The
   only significant difference between the NTPv3 one to many, commonly referred to as unicast and NTPv4 header
   formats is broadcast.
   For the four-octet Reference Identifier field, which purposes of this document, the term broadcast is used
   primarily interpreted
   to detect and avoid synchronization loops.  In all NTP and
   SNTP versions providing mean any available one to many mechanism.  For IPv4 this equates
   to either IPv4 broadcast or IPv4 addressing, primary servers use a four-
   character ASCII reference clock identifier in multicast.  For IPv6 this field, while
   secondary servers use equates to
   IPv6 multicast.  For OSI this XXXXX.  For this purpose, IANA has
   allocated the 32-bit IPv4 multicast address of the synchronization
   source.  In NTPv4 providing IPv6 224.0.1.1 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 multicast
   address of ending :101, with prefix determined by scoping rules.  The
   NTP broadcast address for OSI has yet to be determined.

      It is important to adjust the
   synchronization source.  A further use of this time-to-live (TTL) field is when in the
   server sends IP
      header of multicast messages to a kiss-o'-death message documented later reasonable value in order to
      limit the network resources used by this
   document.

   In (and any other) multicast
      service.  Only multicast clients in scope will receive multicast
      server messages.  Only cooperating anycast servers in scope will
      reply to a client request.  The engineering principles which
      determine the case proper values to be used are beyond the scope of OSI,
      this memo.

      While not integral to the Connectionless Transport Service (CLTS) NTP specification, it is intended that
      IP broadcast addresses will be used as primarily in [ISO86].  Each IP subnets and
      LAN segments including a fully functional NTP packet is transmitted as the TS-
   Userdata parameter of server with a T-UNITDATA Request primitive.  Alternately, number
      of dependent NTP broadcast clients on the header can same subnet, while IP
      multicast group addresses will be encapsulated in a TPDU which itself is transported
   using UDP, as described used only in RFC-1240 [DOB91].  It is not advised that cases where the TTL
      is engineered specifically for each service domain.

   NTP messages are layered on top of UDP.  All messages MUST be operated at the upper layers sent
   with a destination port of the OSI stack, such as might 123, and SHOULD be inferred from RFC-1698 [FUR94], as this could seriously degrade
   accuracy.  With sent with a source port
   of 123.

5.  SNTP Protocol Operation

   SNTP operates using the header formats defined in this memo, same message formats, addresses, and ports as
   NTP.  However, it is stateless, operating only in
   principle possible to interwork between servers and clients of one
   protocol family and another, although the practical difficulties may
   make this inadvisable.

      In Client or
   Server roles.  Thus it is compatible with, and a subset of, NTP.

   Without the following, indented paragraphs such as this one contain
      information not complexity and state required by the formal protocol specification, but
      considered good practice in protocol implementations.

   This document Symmetric Peer, SNTP
   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 apropriate for devices which require a significantly smaller
   resource footprint.  Since a SNTP server ordinarily does not
   implement the NTP timestamp format full suite of grooming and Section 4
   the NTP message format.  Section 5 summarizes NTP client operations mitigation algorithms
   intended to support redundant servers and Section 6 summarizes NTP diverse network paths, a
   SNTP server operations.  Section 7 summarizes
   the optional security mechanisms present within the NTPv4 protocol.
   Section 8 summarizes operation 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.

      Note that SNTP servers normally operate as primary (stratum 1)
      servers.  While operating at higher strata (up to 15) and management issues.  Section 9
   describes at the kiss-o'-death message, whose functionality is
   similar
      same time synchronizing to an external source such as a GPS
      receiver is not forbidden, this is strongly discouraged.

6.  NTP Server Operations

   Fundamentally, the ICMP Source Quench NTP Server role consists of listening for client
   requests, and ICMP Destination Unreachable
   messages.  Section 10 presents NTPv4 security considerations.
   Section 11 presents various other considerations when implementing
   and/or configuring NTPv4.

   NTPv4 is hereafter referred to simply providing time and associated details as NTP, unless explicitly
   noted.

2.  NTP Protocol Operation

   Unless excepted in context, reference to broadcast address means IPv4 a response.
   Additionally, a Server can provide time and associated details
   periodically via a broadcast address, IPv4 multicast group address mechanism.  An NTP server operating with
   either an NTP or IPv6 site-local
   scope address.  Further information on the broadcast/multicast model
   is in RFC 1112 [DEE89].  Details SNTP client of address format, scoping rules,
   etc., are beyond the scope of this memo.  NTPv4 same or previous versions retains
   no persistent state.

   An NTP server can operate with
   either unicast (point to point), broadcast (point to multipoint) communicate via unicast, broadcast, or
   anycast (multipoint to point) addressing modes. both.  A unicast client
   sends a request to a designated
   server at its receiving a unicast address request (NTP mode 3), modifies fields in
   the NTP header as described below, and
   expects sends a reply from which it can determine (NTP mode 4),
   possibly using the time and, optionally, same message buffer as the roundtrip delay and clock offset relative request.  When
   operating in a broadcast mode, unsolicited messages (NTP mode 5) with
   field values as described below are normally sent at intervals
   ranging from 64 s to 1024 s, depending on the expected frequency
   tolerance of the client clocks and the server. required accuracy.

   A broadcast server periodically sends an unsolicited message may or may not send messages if not synchronized
   to a
   designated broadcast address.  A broadcast client listens on this
   address and ordinarily sends no requests.

   Anycast correctly operating source, but the preferred option is designed for use with a set to
   transmit, since this allows reachability to be determined regardless
   of cooperating servers whose
   addresses are not known beforehand. synchronization state.

   The anycast client sends an
   ordinary NTP client request Leap Indicator (LI) is set to a designated broadcast address.  One
   or more anycast servers listen on that address.  Upon receiving a
   request, an anycast server sends an ordinary NTP 3 (unsynchronized) if the server reply
   has never synchronized to a reference source.  Once synchronized, the
   client.  The client then binds
   LI field is set to one of the server from which the first
   such message was received other three values and continues operation with that unicast
   addresses.  Subsequent replies remains at the
   last value set even if the reference source becomes unreachable or
   turns faulty.

   The Version (VN) is copied from other anycast servers are
   ignored.

      Broadcast servers should respond the request packet, if responding to client unicast requests, as
      well as send unsolicited broadcast messages.  Broadcast clients
      may send
   a unicast requests in order request.  For broadcast, this is set to measure the network
      propagation delay between the server and client and then continue
      operation in listen-only mode.  However, broadcast servers may
      choose not 4.

   The Mode is set to respond Server (4) if in response to a unicast requests, so unicast clients
      should be prepared request.
   For broadcast, this is set to Broadcast (5).

   The Stratum field to the server's current stratum, if synchronized.
   If synchronized to abandon the measurement and assume a default
      value for reference source the delay. Stratum field is set to 1.
   If unsynchronized this field is set to 0.

   The client and server addresses are assigned following Poll field is coppied from the usual
   IPv4, IPv6 or OSI conventions. request, if responding to a
   unicast request.  For NTP multicast, the IANA has
   reserved broadcast, this is set to the IPv4 group address 224.0.1.1 and nearest integer
   base-2 logarithm of the IPv6 group address
   ending :101, with prefix determined by scoping rules. poll interval.

   The NTP
   broadcast address for OSI has yet Precision field is set to be determined.  Notwithstanding
   the IANA reserved addresses, other multicast addresses can be used
   which do not conflict with others assigned in scope.  In reflect the case maximum reading error of
   IPv4 multicast or IPv6 broadcast addresses, the client must implement
   the Internet Group Management Protocol (IGMP) system clock.  For all practical cases it is computed as described in RFC-
   3376 [CAIN02], in order that the local router joins
   negative base-2 logarithm of the multicast
   group and relays messages number of significant bits to the IPv4 or IPv6 multicast group.
   right of the decimal point in the NTP timestamp format.  The
   scoping, routing Root
   Delay and group membership procedures Root Dispersion fields are determined by
   considerations beyond the scope of this memo.

      It is important set to adjust 0 for a primary server;
   optionally, the time-to-live (TTL) Root Dispersion field in the IP
      header of multicast messages can be set to a reasonable value in order
   corresponding 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 anycast servers in scope will
      reply to a client request.  The engineering principles which
      determine maximum expected error of the proper values radio clock
   itself.

   If the server is synchronized to be used are beyond a reference source, the scope value of
      this memo.

      While not integral to the NTP specification, it
   Reference ID is intended that
      IP broadcast addresses will be used primarily in IP subnets and
      LAN segments including a fully functional NTP server with set to a number four-character ASCII string identifying the
   source, left justified and zero padded to 32bits.  For IPv4 secondary
   servers,the value is the 32-bit IPv4 address of dependent NTP broadcast clients on the same subnet, while IP
      multicast group addresses will be used only in cases where synchronization
   source.  For IPv6 and OSI secondary servers, the TTL value is engineered specifically for each service domain.

3.  NTP Timestamp

   NTPv4 uses the standard NTP first
   32 bits of the MD5 hash of the IPv6 or NSAP address of the
   synchronization source.  If unsynchronized, it is set to an ASCII
   error identifier.

   The timestamp format described fields in RFC-1305.
   NTP data the server message are specified set as integer or fixed-point quantities, with
   bits numbered in big-endian fashion from 0 starting at follows.  If
   the left server is unsynchronized or
   most significant end.  Unless specified otherwise, first coming up, all quantities timestamp fields
   are unsigned set to zero with one exception.  If the server is synchronized
   and may occupy up, the full Transmit Timestamp field width with 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 implied 0
   preceding bit 0. NTP timestamps are represented as a 64-bit unsigned fixed-point
   number, in seconds relative or SNTP client
   uses it to avoid bogus messages.

   If the server is synchronized, the Reference Timestamp is set to 0h on 1 January 1900. the
   time the last update was received from the reference source.  The integer
   part
   Originate Timestamp field is set as in the first 32 bits and unsynchronized case above.
   The Transmit Timestamp field are set to the fraction part in time of day when the
   last 32 bits.
   message is sent.  In broadcast messages the fraction part, the non-significant low order
   bits are not specified and ordinarily Receive Timestamp field
   is set to 0. zero and copied from the Transmit Timestamp field in other
   messages.

   The NTP timestamp
   format is following table summarizes these actions:

   +----------------+----------------+----------------+----------------+
   |   Field Name   |     Unicast    |  Unicast Reply |    Broadcast   |
   |                |     Request    |                |                |
   +----------------+----------------+----------------+----------------+
   |       LI       |     ignore     |    as shown in Figure 1.

   0 needed   |    as needed   |
   |       VN       |       1-4      |   copied from  |        4       |
   |                |                |     request    |                |
   |      Mode      |     1                   2 or 3
   0 1     |     2 3 or 4     |        5 6 7 8 9 0       |
   |     Stratum    |     ignore     |        1 2 3 4 5 6 7 8 9       |        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      |     ignore     |        0       |        0       |
   |   Dispersion   |                |                |                |
   |    Reference   |     ignore     |  source ident  |  source ident  |
   |   Identifier   |                |                |                |
   |    Reference   |     ignore     |  time of last  |  time of last  |
   |    Timestamp   |                |   src. update  |   src. update  |
   |    Originate   |     ignore     |   copied from  |        0 1 2 3 4 5 6 7 8 9       |
   |    Timestamp   |                | xmit timestamp |                |
   |     Receive    |     ignore     |   time of day  |        0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+       |                            Seconds
   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+    Timestamp   |                |                |                |
   |    Transmit    |   (see text)   |   time of day  |   time of day  |                            Fraction
   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 1. NTP    Timestamp Format

   It is advisable   |                |                |                |
   |  Authenticator |    optional    |    optional    |    optional    |
   +----------------+----------------+----------------+----------------+

      Broadcast servers should respond to fill the non-significant low client unicast requests, as
      well as send unsolicited broadcast messages.  Broadcast clients
      may send unicast requests in order bits of the
   timestamp with a random, unbiased bitstring, both to avoid
   systematic roundoff errors measure the network
      propagation delay between the server and as a means of loop detection client and
   replay detection (see below).  It is important that the bitstring then continue
      operation in listen-only mode.  However, broadcast servers may
      choose not to respond to unicast requests, so unicast clients
      should be unpredictable by a intruder.  One way of doing this is prepared to
   generate a random 128-bit bitstring at startup.  After that, each
   time the system clock is read the string consisting of abandon the
   timestamp measurement and bitstring is hashed with the MD5 algorithm, then the
   non-significant bits of the timestamp are copied from assume a default
      value for the result. delay

7.  NTP Client Operations

   The role of an NTP format allows convenient multiple-precision arithmetic and
   conversion client is to UDP/TIME message (seconds), but does complicate determine the
   conversion to ICMP Timestamp message (milliseconds) and Unix current time
   values (seconds and microseconds or seconds and nanoseconds).  The
   maximum number that (and
   associated information) from an NTP server.  This can be represented is 4,294,967,295 seconds with done
   actively, by sending a precision of about 232 picoseconds, which should be adequate unicast request to a configured server, or
   passively by listening on a known address for
   even the most exotic requirements.

   Note that, since some time periodic server
   messages.

   An NTP client can operate in 1968 (second 2,147,483,648) the most
   significant bit (bit 0 of unicast or broadcast modes.  In unicast
   mode the integer part) has been set 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.

      Broadcast clients may send unicast requests in order to measure
      the
   64-bit field will overflow some time network propagation delay between the server and client and
      then continue operation in 2036 (second 4,294,967,296).
   There will exist listen-only mode.  However, broadcast
      servers may choose not to respond to unicast requests, so unicast
      clients should be prepared to abandon the measurement and assume a 232-picosecond interval, henceforth ignored, every
   136 years when
      default value for the 64-bit field will be 0, which by convention is
   interpreted as an invalid or unavailable timestamp.

   If bit 0 is set, delay.

      Client requests are normally sent at intervals depending on the UTC time is in
      frequency tolerance of the range 1968-2036 client clock and UTC time
   is reckoned from 0h 0m 0s UTC on 1 January 1900.  If bit 0 is not
   set, the time required accuracy.
      However, under no conditions should requests be sent at less than
      one minute intervals.  Further discussion on this point is in
      Section 12.

   A unicast client initializes the range 2036-2104 NTP message header, sends the
   request to the server and UTC strips the time is reckoned of day 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 Transmit
   Timestamp field of the reply.  For this purpose, all of the reckoning.

4. NTP Message Formats

   Both
   header fields shown in Section 3 are set to 0, except the Mode, VN
   and optional Transmit Timestamp fields.

   NTP and SNTP are clients of set the User Datagram Protocol (UDP)
   [POS80], which itself is a client mode field to 3 (client) for unicast and
   anycast requests.  They set the VN field to any version number
   supported by the server selected by configuration or discovery and
   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 Internet Protocol (IP)
   [DAR81] [DER98]. The structure request also specifies the VN field of the IP and UDP headers is described reply.  An NTP
   client can specify the earliest acceptable version on the expectation
   that any server of that or later version will respond.  NTPv4 servers
   are backwards compatible with NTPv3 as defined in RFC 1305, NTPv2 as
   defined in the cited specification documents [9], and will not be detailed further
   here. The UDP port number assigned to NTP is 123, which should be
   used NTPv1 as defined in both [10].  NTPv0 defined in [11]
   is not supported.

   In unicast mode, the Source Port and Destination Port fields Transmit Timestamp field in the UDP
   header. The remaining UDP header fields request should
   be set as described in to the specification.

   Below is a description time of day according to the NTPv4 message format, which follows client clock in NTP
   timestamp format.  This allows a simple calculation to determine the IP
   propagation delay between the server and UDP headers. This format is identical client and to align the
   system clock generally within a few tens of milliseconds relative to
   the server.  In addition, this provides a simple method to verify
   that described the server reply is in
   RFC 1305, with fact a legitimate response to the exception
   specific client request and avoid replays.  In broadcast mode, the
   client has no information to calculate the propagation delay or
   determine the validity of the contents server, unless one of the reference
   identifier field. The header fields are defined in Figure 2.

   Leap Indicator (LI):
      This NTP
   authentication schemes is a two-bit field indicating an impending leap second to be
      inserted in used.  The following table summarizes the
   required NTP timescale. client operations in unicast, anycast and broadcast
   modes.  The bits recommended error checks are set before 23:59 on shown in the day of insertion Reply and reset after 00:00 on
   Broadcast columns in the following day.
      This causes table.  The message should be considered
   valid only if all the number of seconds (rollover interval) fields shown contain values in the day
      of insertion respective
   ranges.  Whether to be increased or decreased by one. In believe the case message if one or more of
      primary servers the bits are set by operator intervention, while
      in fields
   marked "ignore" contain invalid values is at the case discretion of secondary servers the bits are set by
   implementation.

   There is some latitude on the protocol. part of most clients to forgive invalid
   timestamps, such as might occur when first coming up or during
   periods when the reference source is inoperative.  The possible values most important
   indicator of an unhealthy server is the LI Stratum field, and corresponding meanings,
      are as follows:

         LI       Meaning
         --------------------------------------------- in which a
   value of 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 indicates an unsynchronized condition.  When this field to some other value when synchronized to is
   displayed, clients should discard the
      primary reference clock.  Once set to server message, regardless of
   the contents of other than 3, fields.

   The following table summarizes the field is
      never set to that value again, even if all synchronization sources
      become unreachable or defective.

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 proper setting of these fields:

   +----------------+----------------+----------------+----------------+
   |   Field Name   |     Unicast    |  Unicast Reply |    Broadcast   |
   |                |     Request    |                |                |
   +----------------+----------------+----------------+----------------+
   |       LI       |        0       |       0-3      |       0-3      |
   |       VN       |       1-4      |   copied from  |       1-4      |
   |                |                |     request    |                |
   |      Mode      |     1 2 or 3     |     2 or 4     |        5 6 7 8 9       |
   |     Stratum    |        0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |LI       | VN  |Mode      0-15      |      0-15      |     Strat
   |      Poll      |     Prec        0       |     ignore     |     ignore     |
   |    Precision   |        0       |     ignore     |     ignore     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Root Delay   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+        0       |     ignore     |     ignore     |
   |      Root      |        0       |     ignore     |     ignore     |
   |   Dispersion   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                |                          Reference ID                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                |
   |
   +    Reference Timestamp                     +   |        0       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     ignore     |     ignore     |
   +                        Origin Timestamp                       +
   |   Identifier   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                |                |
   +                        Receive Timestamp                      +                |
   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+    Reference   |        0       |     ignore     |     ignore     |
   |
   +                        Transmit    Timestamp                     +   |                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                |                |
   +                    Extension Field 1 (Optional)               +
   |    Originate   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+        0       |   (see text)   |
   +                    Extension Field 2 (Optional)               +     ignore     |
   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   .                                                               .
   .                          Authentication                       .
   .                       (Optional) (160 bits)                   .
   .                                                               .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       Figure 2 NTP Message Format
   Version (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
         ------------------------------------    Timestamp   |                |                |                |
   |     Receive    |        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 broadcast mode, the server sets this field to 5
      (broadcast).

   Stratum (Strat):
      This is a eight-bit unsigned integer indicating the stratum.
      This field       |   (see text)   |     ignore     |
   |    Timestamp   |                |                |                |
   |    Transmit    |   (see text)   |     nonzero    |     nonzero    |
   |    Timestamp   |                |                |                |
   |  Authenticator |    optional    |    optional    |    optional    |
   +----------------+----------------+----------------+----------------+

8.  NTP Symmetric Peer Operations

   NTP Symmetric Peer mode is significant only in SNTP server messages, intended for configurations where the
      values are defined a set of
   low-stratum peers operate as follows:

         Stratum  Meaning
         ----------------------------------------------
         0        kiss-o'-death message
         1        primary reference (e.g., synchronized by radio clock)
         2-15     secondary reference (synchronized by NTP mutual backups for each other.  Each
   peer normally operates with oner or SNTP)
         16-255   reserved

   Poll Interval (Poll):
      This is an eight-bit unsigned integer used more sources, such as an exponent a reference
   clock, or a subset 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) primary or secondry servers known to 17
      (131,072 s - about 36 h).

   Precision (Prec):
      This is an eight-bit signed integer used as an exponent of
      two, where the resulting value be
   reliable or authentic.

   Symmetric Peer mode is exclusive to the precision of the system
      clock in seconds.  This field NTP protocol and is significant only in server
      messages, where the values range
   specifically excluded 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 SNTP operation.

9.  NTPv4 Security

   NTPv4 employs the primary reference source, in seconds Autokey security protocol, which works
   independently for each client, with fraction point between bits 15 and 16.  Note that this
      variable can take on tentative outcomes confirmed only
   after both positive succeed.  Public keys and negative values, depending
      on the relative time certificates are obtained and frequency offsets.  This field
   verified relatively infrequently using X.509 certificates and
   certificate trails.  Session keys are derived from public keys.  Each
   NTP message is
      significant only in server messages, where individually authenticated using the values range from
      negative values of a few milliseconds to positive values of
      several hundred milliseconds.

   Root Dispersion:
      This session key and
   the message digest (keyed MD5).  A proventic trail is a 32-bit unsigned fixed-point number indicating the
      nominal error relative sequence of
   NTP servers each synchronized and cryptographically veritifed to the primary reference source, in seconds
      with fraction point between bits 15 and 16.  This field is
      significant only in
   next lower stratum server messages, where the values range and ending on one or more trusted servers.
   Proventic trails are constructed from
      zero each server 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 trusted
   servers at decreasing stratum 0 (kiss-o'-death message) levels.  When server time and 1 (primary server), at least
   one proventic trail are verified, the
      value peer is a four-character ASCII string, left justified admitted to the
   population and zero
      padded used to 32 bits. For IPv4 secondary servers,the synchronize the system clock.

9.1  Session Keys and Cookies

   NTPv4 session keys have four 32-bit words, as shown in Figure 5.

    0                   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Source Address                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Destination Address                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Key ID                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Cookie                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure 5.  NTPv4 Session Key Format

   The session key value is the
      32-bit IPv4 address 16-octet MD5 message digest of the synchronization source. For IPv6
   session key.  Key IDs have pseudo-random values and
      OSI secondary servers, the are used only
   once.  A special key ID value of zero is used as a NAK reply.  In
   multicast mode, and in any message including an extension field, the first 32 bits of
   cookie has a public value (zero).  In client/server modes, the MD5 cookie
   is a hash of the IPv6 or NSAP address of the synchronization source.

      Primary (stratum 1) servers set this field to addresses and a code identifying
      the external reference source according to private value.  In symmetric modes,
   the below table.

         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       Kaui 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

      If cookie is a random roll.  In the external reference event that both peers generate
   cookies, the agreed-upon cookie is one the exclusive-OR of those listed, the associated
      code should be used. Codes for sources not listed can be contrived
      as appropriate.

      In previous NTP two
   values.

   The server generates a cookie unique to the client and SNTP secondary servers server
   addresses and clients this field
      was often used to walk-back its own private value.  It returns the synchronization subnet cookie,
   signature, and timestampe to the root
      (primary server) for management purposes.

   Reference Timestamp:
      This field is significant only client in an extension field.  The
   cookie is transmitted from server messages, where to client encrypted by the value
      is client
   public key.  The server uses the time at which cookie to validate requests and
   construct replies.  The client uses the system clock was last set or corrected,
      in 64-bit timestamp format.

   Originate Timestamp:
      This is cookie to validate the time at which reply
   and checks that the request departed key ID matches the client for reply key ID.

9.2  Session Key List Generation

   The server rolls a random 32-bit seed as the
      server, initial key ID and
   selects the cookie.  Messages with a zero cookie contain only public
   values.  The initial session key is constructed using the given
   addressses, cookie and initial key ID.  The session key value is
   stored in 64-bit timestamp format.

   Receive Timestamp:
      This the key cache.  The next session key is constructed using
   the time at which first four octets of the request arrived at session key value as the new key ID.
   The server or the
      reply arrived at continues to generate the client, full list.  The final index
   number and last key ID are provided in 64-bit timestamp format.

   Transmit Timestamp:
      This is an extension field with
   signature and timestamp.

9.3  Sending Messages

   The MAC consists of the time at which MD5 message digest of the request departed NTP header and
   extension fields using the client or session key ID and value stored in the
      reply departed key
   cache.  The server uses the server, in 64-bit timestamp format.

   NTPv4 Extension Fields:
      NTPv4 defines new extension field formats.  These fields are
      processed session key ID list in reverse order and may be transmitted with or without
   discards each key value
      fields.  The last after use.  An extension field containing the
   last index number and key ID is padded to a 64-bit boundary, included in the first packet
   transmitted (last on the list).  This extension field can be provided
   upon request at any time.  When all others
      fields entries in the key list are padded to 32-bit boundaries. used,
   a new one is generated.

9.4  Receiving Messages

   The field length intent is for
      all payload not to hide the message contents.  Rather, the goal is
   to verify its source and padding.

      0                   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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Field Type           |            Length             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          Association ID                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Timestamp                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Filestamp                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          Value Length                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      .                                                               .
      .                             Value                             .
      .                                                               .
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Signature Length                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      .                                                               .
      .                           Signature                           .
      .                                                               .
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Padding (as needed)                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       Figure 3 NTPv4 Extension Field
   Authentication (optional): that it has not been modified in transit.
   The authentication field format MAC message digest is shown compared with the computed digest of the
   NTP header and extension fields using the session key ID in Figure 4. the MAC
   and the key value computed from the addresses, key ID and cookie.  If
   the cookie is zero, the message contains public values.  Anybody can
   validate the message or make a valid message containing any values.
   If the cookie has been determined by secret means, nobody except the
   parties to the secret can validate a message or make a valid message.

9.5  Autokey Protocol Exchanges

   There are five types of Autokey protocol exchanges:

      Parameter Exchange (ASSOC message): This message exchanges host
      names, agrees on digest/signature and identity schemes.  This
      protocol exchange is unsigned.  Optionally, host name/address can
      be verified using reverse-DNS.  An initial association request is
      sent by the client, sending the host name and status word

    0                   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Key Identifier                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                                                               +
      |                                                               |
      +                         Message Digest                        +     Digest/Signature NID      |    Client     |
      +                                                               + Ident | Host  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Figure 4 Optional Authentication Field

      When the NTP authentication scheme is implemented, the 16-bit Key
      Identifier and 128-bit Message Digest fields contain the Message
      Authentication Code (MAC) information which uses an MD5 cryptosum
      of NTP header plus extension fields.

5.  NTP Client Operations

   An NTP client can operate in unicast, broadcast or anycast modes.  In
   unicast mode 6 Status Word Format

      If 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 server digest NID and waits for a broadcast
   (NTP mode 5) from one or more broadcast servers.  In anycast mode, ID scheme agree, the client sends a request (NTP mode 3) to a designated broadcast
   address server responds
      with an association response message, sending host name and expects status
      word.  The client, upon agreeing with digest NID and ID scheme,
      then sends a reply (NTP mode 4) from one or more anycast
   servers. certificate request.  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 responds with an
      X.509 certificate and signature.  The certificate request/response
      cycle repeats as needed.  A primary (Stratum 1) certifcate is
      explicitly trusted and self-signed.  Secondary certificates are ignored.  Other
   than the selection of address in the request,
      signed by the operations of
   anycast next lower stratum server and unicast clients are identical.

      Client requests are normally sent at intervals depending validated with its
      public key.

      Certificate Exchange (CERT message): This exchange is used to
      obtain and verify certificates on the
      frequency tolerance of trail to a trusted root
      certificate.  Certificate exchanges follow the client clock same process as
      parameter exchanges.

      Identity Exchange (IFF, GW, and the required accuracy.
      However, under no conditions should requests be sent at less than
      one minute intervals. Further discussion on this point MV messages): This exchange is in
      Section 9.

   A unicast or anycast
      used to verify server identity using an agreed identity scheme
      (TC, IFF, GQ, MV).  This exchange is a challenge-response scheme.
      The client initializes the NTP message header, sends initiates by sending a challenge request.  The server
      then provides the request challenge response.

      Values Exchange (COOKIE and AUTO messages): This exchange is used
      to the server obtain and strips the time of day from verify the
   Transmit Timestamp field of cookie, autokey values, and leapseconds
      table, depending on the reply. association mode (client-server,
      broadcast, symmetric).  For this purpose, all of cookie exchanges, the
   NTP header fields shown above are set client sends its
      public key to 0, except the Mode, VN and
   optional Transmit Timestamp fields.

   NTP server without signature when not synchronized.
      Symmetric active peers send its public key and SNTP clients set the mode field signature to 3 (client)
      passive peer when synchronized.  The server cookie is encrypted
      from the hash of source/destination addresses, zero key ID, and
      server private value.  A symmetric passive cookie is a random
      value for unicast every exchange.  The server private value is refreshed
      and
   anycast requests.  They set protocol restarted once per day.  For autokey exchanges, the VN field
      server generates a key list and signature is calculated to last
      about one hour.  A client sends requests to any version number
   supported by the server selected by configuration or discovery and
   can interoperate with all previous version NTP and SNTP servers.
   Servers reply without
      signature when not synchronized.  The server replies with the same version as the request, so the VN field
   of the request also specifies last
      index number and key ID on the VN field of list.  Broadcast servers uses AUTO
      response for the reply.  An NTP
   client can specify first message after regenerating the earliest acceptable version on key and
      ASSOC responses for all other messages.

      Signature Exchange (SIGN message): This exchange requests the expectation
   that any
      server of that or later version will respond.  NTPv4 servers
   are backwards compatible with NTPv3 as defined in RFC 1305, NTPv2
   as defined in RFC 1119 [MIL89], to sign and NTPv1 as defined in RFC 1059
   [MIL88].  NTPv0 defined in RFC 959 [MIL85] return a client certificate.  The exchange is not supported.

   In unicast and anycast modes, the Transmit Timestamp field in
      valid only when the
   request should be set client has synchronized to a proventic source
      and the time of day according server identity has been confirmed.  This exchange is used
      to authenticate clients to servers, with the server acting as de
      facto certificate authority using an encrypted credential scheme.
      The client
   clock in NTP timestamp format.  This allows sends a simple calculation certificate to
   determine the propagation delay between the server with or without
      signature.  The server extracts the requested data and signs that
      data with the server private key.  The client and to
   align then verifies the system clock generally within a few tens of milliseconds
   relative to
      certificate and signature.  Subsequently, the server.  In addition, client supplies this provides a simple method
   to
      certificate rather than self-signed certificates, so clients can
      verify that with the server reply is in fact public key.

10.  Dynamic Server Discovery

   NTPv4 provides a mechanism, commonly known as "Manycast", for a legitimate response to
   the specific client request and avoid replays.  In broadcast mode,
   the
   client has no information to calculate the propagation delay or
   determine dynamically discover the validity existance of the server, unless one of the NTP
   authentication schemes is used. The following table summarizes the
   required NTP client operations in unicast, anycast and broadcast
   modes.  The recommended error checks or more servers
   with no a-priori knowledge.  Once servers are shown in discovered, they are
   then treated as any other unicast server.

   A client employing server discovery is configured with MinServers,
   the Reply minimum number of desired servers and
   Broadcast columns in MaxServers, the table. maximum
   number of desired servers.  The message should discovery mechanism is a simple
   expanding ring search, using IP multicast with increasing TTLs or Hop
   Counts.  The multicast address used MUST be considered
   valid only if all scoped to the fields shown contain values in local site,
   as defined by [12].

   The client initiates the respective
   ranges.  Whether discovery process by sending an NTP message
   to believe the message if one configured multicast address with an IP TTL or more Hop Count of 1.
   This message has all of the NTP header fields
   marked "ignore" contain invalid values is at the discretion of set to 0, except the
   implementation.

      Field Name               Unicast/Anycast            Broadcast
                               Request     Reply
      ---------------------------------------------------------------
      LI                       0           0-3            0-3
   Mode, VN                       1-4         copied from    1-4
                                           request

      Mode                     1 or 3      2 or 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 and optional Transmit Timestamp       (see text)  nonzero        nonzero

      Authenticator            optional    optional       optional

 [Need fields.  The Mode is set to add
   3.  It then starts a similar table retry timer (Default: 64 seconds) and listens
   for symmetric modes unicast responses from servers.  The source address of operation]

6.  NTP Server Operations

   An NTP any server operating with either
   responses are treated as newly configured unicast servers, up to a
   limit of MaxServers.  If the number of discovered servers is less
   than MinServers when the retry timer expires, an identical NTP
   message is sent with an increased TTL/Hop Count, and the retry timer
   is restarted.  This continues until either MinServers servers have
   been discovered or SNTP client a configured maximum TTL/Hop Count is reached.  If
   the configured maximum TTL/Hop Count is reached, packets continue to
   be periodically sent at the maximum TTL/Hop Count.  If at some
   subsequent time, the number of valid servers drops below MinServers,
   the same
   or previous versions retains no persistent process restarts at the initial state.  Since a SNTP

   A server ordinarily does not implement configured to provide server discovery will listen on the full suite
   specified multicast address for discovery messages from clients.  If
   the server is in scope of grooming the current TTL and
   mitigation algorithms intended is itself synchronized
   to support redundant servers and
   diverse network paths, a SNTP valid source it replies to the discovery message from the client
   with an ordinary unicast server should be operated only message as described in
   conjunction with Section 6

11.  NTP Control Messages

   In a source of external synchronization, comprehensive network-management environment, facilities are
   presumed available to perform routine NTP control and monitoring
   functions, such as setting the leap-indicator bits at the primary
   servers, adjusting the various system parameters and monitoring
   regular operations.  Ordinarily, these functions can be implemented
   using a
   reliable radio clock or telephone modem.  In this case it operates network-management protocol such as
   a primary (stratum 1) server.

   An NTP server SNMP and suitable
   extensions to the MIB database.  However, in those cases where such
   facilities are not available, these functions can operate with any unicast, anycast or broadcast
   address be implemented
   using special NTP control messages described herein.  These messages
   are intended for use only in systems where no other management
   facilities are available or any combination appropriate, such as in dedicated-
   function bus peripherals.  Support for these messages is not required
   in order to conform to this specification.

   The NTP Control Message has the value 6 specified in the mode field
   of the first octet of the NTP header and is formatted as shown below.
   The format of these addresses.  A unicast the data field is specific to each command or anycast
   server receives a request (NTP mode 3), modifies certain fields response;
   however, in most cases the NTP header, format is designed to be constructed and sends a reply (NTP mode 4), possibly using
   viewed by humans and so is coded in free-form ASCII.  This
   facilitates the
   same message buffer as specification and implementation of simple management
   tools in the request.  A anycast server listens on absence of fully evolved network-management facilities.
   As in ordinary NTP messages, the
   designated broadcast address, authenticator field follows the data
   field.  If the authenticator is used the data field is zero-padded to
   a 32-bit boundary, but uses its own unicast IP address the padding bits are not considered part of
   the data field and are not included in the source address field count.

   IP hosts are not required to reassemble datagrams larger than 576
   octets; however, some commands or responses may involve more data
   than will fit into a single datagram.  Accordingly, a simple
   reassembly feature is included in which each octet of the reply.  Other than message
   data is numbered starting with zero.  As each fragment is transmitted
   the selection number of
   address its first octet is inserted in the reply, offset field and the operations
   number of anycast octets is inserted in the count field.  The more-data (M)
   bit is set in all fragments except the last.

   Most control functions involve sending a command and unicast servers
   are identical.  Broadcast messages are normally sent at poll
   intervals from 64 s receiving a
   response, perhaps involving several fragments.  The sender chooses a
   distinct, nonzero sequence number and sets the status field and R and
   E bits to 1024 s, depending on zero.  The responder interprets the expected frequency
   tolerance of opcode and additional
   information in the client clocks data field, updates the status field, sets the R
   bit to one and returns the three 32-bit words of the header along
   with additional information in the data field.  In case of invalid
   message format or contents the responder inserts a code in the required accuracy.

   Unicast and anycast servers copy status
   field, sets the VN R and Poll fields of the
   request intact E bits to one and, optionally, inserts a
   diagnostic message in the reply data field.

   Some commands read or write system variables and set peer variables for
   an association identified in the Stratum field command.  Others read or write
   variables associated with a radio clock or other device directly
   connected to 1.

      Note that SNTP servers normally operate as a source of primary (stratum 1)
      servers.  While operating at higher strata (up to 15) synchronization information.  To
   identify which type of variable and at the
      same time synchronizing to an external source such as association a GPS
      receiver is not forbidden, this is strongly discouraged.

   If the Mode field of the request 16-bit association
   identifier is 3 (client), used.  System variables are indicated by the reply identifier
   zero.  As each association is set to 4
   (server).  If this field mobilized a unique, nonzero identifier
   is set to 1 (symmetric active), created for it.  These identifiers are used in a cyclic fashion,
   so that the reply chance of using an old identifier which matches a newly
   created association is
   set remote.  A management entity can request a
   list of current identifiers and subsequently use them to 2 (symmetric passive).  This allows clients configured read and
   write variables for each association.  An attempt to use an expired
   identifier results in
   either client (NTP mode 3) an exception response, following which the list
   can be requested again.

   Some exception events, such as when a peer becomes reachable or symmetric active (NTP mode 1)
   unreachable, occur spontaneously and are not necessarily associated
   with a command.  An implementation may elect to
   interoperate successfully, even if configured in possibly suboptimal
   ways.  For any other value in save the Mode field, event
   information for later retrieval or to send an asynchronous response
   (called a trap) or both.  In case of a trap the request IP address and port
   number is
   discarded.  In broadcast (unsolicited) mode, determined by a previous command and the VN sequence field is
   set to
   4, as described below.  Current status and summary information for
   the Mode field latest exception event is set to 5 (broadcast), and returned in all normal responses.  Bits
   in the Poll status field set to
   the nearest integer base-2 logarithm of indicate whether an exception has occurred since
   the poll interval.

      Note that it is highly desirable that a broadcast server also
      supports unicast clients.  This is last response and whether more than one exception has occurred.

   Commands need not necessarily be sent by an NTP peer, so a potential broadcast client
      can calculate ordinary
   access-control procedures may not apply; however, the propagation delay using a client/server exchange
      prior to switching optional mask/
   match mechanism suggested elsewhere in this document provides the
   capability to broadcast client (listen-only) mode.  A
      anycast server control access by design also is a unicast server.  There does not
      seem to mode number, so this could be a great advantage used to
   limit access for a server control messages (mode 6) to operate as both
      broadcast and anycast at selected address
   ranges.

11.1  NTP Control Message Format

   The format of the same time, although NTP Control Message header, which immediately
   follows the protocol
      specification does not forbid it.

   A broadcast or anycast server may or may not respond if not
   synchronized to UDP header, is shown in Figure X. Following is a correctly operating reference source, but the
   preferred option
   description of its fields.  Bit positions marked as zero are reserved
   and should always be transmitted as zero.
     0                   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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |00 |VN |   6   |  REM  |  Op   |           Sequence            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |            Status             |         Association ID        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |            Offset             |             Count             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    .                                                               .
    .                     Data (468 Octets Max)                     .
    .                                                               .
    |                               |         Padding (zeros)       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                   Authenticator (optional)(96)                |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   NTP Control Message Format

   Version Number (VN): This is to respond, since this allows reachability to be
   determined regardless of synchronization state.  If the server has
   never synchronized to a reference source, three-bit integer indicating the LI field NTP
   version number, currently four (4)

   Mode: This is set to 3
   (unsynchronized).  Once synchronized to a reference source, the LI
   field is set to one of three-bit integer indicating the other three values and remains at mode.  It must have
   the last value set even if the reference source becomes unreachable or turns
   faulty.

   If 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 not synchronized, the Stratum field
   is set 6, indicating an NTP control message.

   Response Bit (R): Set to zero and the Reference Identifier field set for commands, one for responses.

   Error Bit (E): Set to an ASCII zero for normal response, one for error identifier described below.  In broadcast mode, the server
   sends broadcasts only if synchronized
   response.

   More Bit (M): Set to a correctly operating
   reference source.

   The Precision field zero for last fragment, one for all others.

   Operation Code (Op): This is set to reflect a five-bit integer specifying the maximum reading error of
   command function.  Values currently defined include the system clock.  For all practical cases it following:

           +-------+----------------------------------------+
           | Value |                 Meaning                |
           +-------+----------------------------------------+
           |   0   |                reserved                |
           |   1   |      read status command/response      |
           |   2   |     read variables command/response    |
           |   3   |    write variables command/response    |
           |   4   |  read clock variables command/response |
           |   5   | write clock variables command/response |
           |   6   | set trap address/port command/response |
           |   7   |              trap response             |
           |  8-31 |                reserved                |
           +-------+----------------------------------------+

   Sequence: This is computed as the
   negative base-2 logarithm of a 16-bit integer indicating the sequence number of significant bits to
   the
   right command or response.

   Status: This is a 16-bit code indicating the current status of the decimal point
   system, peer or clock, with values coded as described in the NTP timestamp format.  The Root
   Delay and Root Dispersion fields are set to 0 for following
   sections.

   Association ID: This is a primary server;
   optionally, the Root Dispersion field can be set to 16-bit integer identifying a value
   corresponding to the maximum expected error of valid
   association.

   Offset: This is a 16-bit integer indicating the radio clock
   itself.

   The timestamp fields offset, in octets, of
   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 octet in the message data area.

   Count: This is a reply to a
   previously received client request, 16-bit integer indicating the Transmit Timestamp field length of the request is copied unchanged to data
   field, in octets.

   Data: This contains the Originate Timestamp field of message data for the reply.  It is important that this field be copied intact, as an
   NTP command or SNTP client uses it to avoid bogus messages.

   If the server response.
   The maximum number of data octets is synchronized, 468.

   Authenticator (optional): When the Reference Timestamp NTP authentication mechanism is set to
   implemented, this contains the
   time authenticator information.

11.2  Status Words

   Status words indicate the last update was received from present status of the reference source.  The
   Originate Timestamp field is set as system, associations
   and clock.  They are designed to be interpreted by network-monitoring
   programs and are in one of four 16-bit formats shown in Figure
   6<$&fig6> and described in this section.  System and peer status
   words are associated with responses for all commands except the unsynchronized case above. read
   clock variables, write clock variables and set trap address/port
   commands.  The association identifier zero specifies the system
   status word, while a nonzero identifier specifies a particular peer
   association.  The Transmit Timestamp field are set status word returned in response to read clock
   variables and write clock variables commands indicates the time state of day when
   the
   message clock hardware and decoding software.  A special error status
   word is sent.  In broadcast messages used to report malformed command fields or invalid values.

11.2.1  System Status Word

   The system status word appears in the Receive Timestamp status field
   is set of the response to
   a read status or read variables command with a zero and copied from the Transmit Timestamp field in other
   messages. association
   identifier.  The following table summarizes these actions.

      Field Name             Unicast/Anycast             Broadcast
                             Request     Reply
      ----------------------------------------------------------------
      LI                     ignore      as needed format of the system status word is as needed

      VN                     1-4         copied from     4
                                         request

      Mode follows:
     0                                       1
     0   1 or 3   2 or   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   6   7   8   9   0

      Transmit Timestamp     (see text)  time of day     time of day

      Authenticator          optional    optional        optional

 [Need to add a similar table for symmetric modes of operation]

   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 reference source is inoperative.  The most important
   indicator of an unhealthy server   1   2   3   4   5
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
   |  LI   |     Clock Source      |     Count     |     Code      |
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
   System Status Word

   Leap Indicator (LI): This is the Stratum field, in which a
   value two-bit code warning of 0 indicates an unsynchronized condition.  When this value is
   displayed, clients should discard the server message, regardless of impending
   leap second to be inserted/deleted in the contents last minute of other fields.

7.  NTPv4 Security

   NTPv4 employs the Autokey security protocol, which works
   independently for each client, current
   day, with tentative outcomes confirmed only
   after both succeed.  Public keys and certificates are obtained and
   verified relatively infrequently using X.509 certificates and
   certificate trails. Session keys are derived from public keys.  Each
   NTP message is individually authenticated using the session key bit 0 and
   the message digest (keyed MD5).  A proventic trail bit 1, respectively, coded as follows:

          +-------+------------------------------------------+
          | Value |                  Meaning                 |
          +-------+------------------------------------------+
          |   00  |                no warning                |
          |   01  |        last minute has 61 seconds        |
          |   10  |        last minute has 59 seconds        |
          |   11  | alarm condition (clock not synchronized) |
          +-------+------------------------------------------+

   Clock Source: This is a sequence of
   NTP servers each synchronized and cryptographically veritifed to six-bit integer indicating the
   next lower stratum server and ending on one current
   synchronization source, with values coded as follows:

  +-------+---------------------------------------------------------+
  | Value |                         Meaning                         |
  +-------+---------------------------------------------------------+
  |   0   |                  unspecified or more trusted servers.
   Proventic trails are constructed from each server to unknown                 |
  |   1   |         Calibrated atomic clock (e.g.,, HP 5061)        |
  |   2   | VLF (band 4) or LF (band 5) radio (e.g.,, OMEGA,, WWVB) |
  |   3   |       HF (band 7) radio (e.g.,, CHU,, MSF,, WWV/H)      |
  |   4   |        UHF (band 9) satellite (e.g.,, GOES,, GPS)       |
  |   5   |            local net (e.g.,, DCN,, TSP,, DTS)           |
  |   6   |                         UDP/NTP                         |
  |   7   |                         UDP/TIME                        |
  |   8   |                  eyeball-and-wristwatch                 |
  |   9   |               telephone modem (e.g. NIST)               |
  | 10-63 |                         reserved                        |
  +-------+---------------------------------------------------------+

   System Event Counter: This is a four-bit integer indicating the trusted
   servers at decreasing stratum levels.  When server
   number of system exception events occurring since the last time and at least
   one proventic trail are verified, the peer
   system status word was returned in a response or included in a trap
   message.  The counter is admitted to cleared when returned in the
   population status field of
   a response and used to synchronize freezes when it reaches the value 15.

   System Event Code: This is a four-bit integer identifying the latest
   system clock.

7.1 Session Keys exception event, with new values overwriting previous values,
   and Cookies

   NTPv4 session keys have four 32-bit words, coded as shown in Figure 5.

   0                   1                   2                   3 follows:

   +---------------------------------+---------------------------------+
   |              Value              |             Meaning             |
   +---------------------------------+---------------------------------+
   |                0                |           unspecified           |
   |                1                |          system restart         |
   |                2                |     system or hardware fault    |
   |                3                |   system new status word (leap  |
   |                                 | bits or synchronization change) |
   |                4                |    system new synchronization   |
   |                                 |  source or stratum (sys.peer or |
   |                                 |        sys.stratum change       |
   |                5                |    system clock reset (offset   |
   |                                 |  correction exceeds CLOCK.MAX)  |
   |                6                |   system invalid time or date   |
   |                                 |     (see NTP specification)     |
   |                7 8 9                |   system clock exception (see   |
   |                                 |    system clock status word)    |
   |               8-15              |             reserved            |
   +---------------------------------+---------------------------------+

11.2.2  Peer Status Word

   A peer status word is returned in the status field of a response to a
   read status, read variables or write variables command and appears
   also in the list of association identifiers and status words returned
   by a read status command with a zero association identifier.  The
   format of a peer status word is as follows:
     0                                       1
     0   1   2   3   4   5   6   7   8   9   0   1   2   3   4   5 6 7 8 9
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
   |    Peer Status    |    Sel    |     Count     |     Code      |
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
   Peer Status Word

   Peer Status: This is a five-bit code indicating the status of the
   peer determined by the packet procedure, with bits assigned as
   follows:

          +-------+------------------------------------------+
          | Value |                  Meaning                 |
          +-------+------------------------------------------+
          |   0   |         configured (peer.config)         |
          |   1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |                         Source Address authentication enabled (peer.authenable) |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          |                      Destination Address   2   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   authentication okay (peer.authentic)   |                             Key ID
          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   3   |                             Cookie      reachability okay (peer.reach)      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 5. NTPv4 Session Key Format

   The session key value is the 16-octet MD5 message digest of the
   session key.  Key IDs have pseudo-random values and are used only
   once.  A special key ID value of zero is used as a NAK reply.  In
   multicast mode, and in any message including an extension field, the
   cookie has a public value (zero).  In client/server modes, the cookie
   is a hash of the addresses and a private value.  In symmetric modes,
   the cookie
          |   4   |                 reserved                 |
          +-------+------------------------------------------+

   Peer Selection (Sel): This is a random roll.  In the event that both peers generate
   cookies, the agreed-upon cookie is three-bit integer indicating the exclusive-OR
   status of the two
   values.

   The server generates a cookie unique to the client and server
   addresses and its own private value.  It returns the cookie,
   signature, and timestampe to the client in an extension field.  The
   cookie is transmitted from server to client encrypted peer determined by the client
   public key. The server uses the cookie to validate requests and
   construct replies. The client uses the cookie to validate clock-selection procedure, with
   values coded as follows:

   +---------------------------------+---------------------------------+
   |              Value              |             Meaning             |
   +---------------------------------+---------------------------------+
   |                0                |             rejected            |
   |                1                |       passed sanity checks      |
   |                2                |    passed correctness checks    |
   |                3                |   passed candidate checks (if   |
   |                                 |     limit check implemented)    |
   |                4                |      passed outlyer checks      |
   |                5                | current synchronization source; |
   |                                 | max distance exceeded (if limit |
   |                                 |        check implemented)       |
   |                6                | current synchronization source; |
   |                                 |        max distance okay        |
   |                7                |             reserved            |
   +---------------------------------+---------------------------------+

   Peer Event Counter: This is a four-bit integer indicating the reply
   and checks number
   of peer exception events that occurred since the request key ID matches last time the reply key ID.

7.2 Session Key List Generation

   The server rolls peer
   status word was returned in a random 32-bit seed as the initial key ID and
   selects the cookie.  Messages with response or included in a zero cookie contain only public
   values. The initial session key is constructed using the given
   addressses, cookie and initial key ID. trap message.
   The session key value counter is
   stored cleared when returned in the key cache.  The next session key is constructed using
   the first four octets status field of a
   response and freezes when it reaches the session key value as 15.

   Peer Event Code: This is a four-bit integer identifying the latest
   peer exception event, with new key ID.
   The server continues to generate the full list.  The final index
   number values overwriting previous values,
   and last key ID coded as follows:

   +---------------------------------+---------------------------------+
   |              Value              |             Meaning             |
   +---------------------------------+---------------------------------+
   |                0                |           unspecified           |
   |                1                |          peer IP error          |
   |                2                |   peer authentication failure   |
   |                                 | (peer.authentic bit was one now |
   |                                 |              zero)              |
   |                3                |   peer unreachable (peer.reach  |
   |                                 |      was nonzero now zero)      |
   |                4                |  peer reachable (peer.reach was |
   |                                 |        zero now nonzero)        |
   |                5                |  peer clock exception (see peer |
   |                                 |        clock status word)       |
   |               6-15              |             reserved            |
   +---------------------------------+---------------------------------+

11.2.3  Clock Status Word

   There are provided in an extension field with
   signature and timestamp.

7.3 Sending Messages

   The MAC consists of the MD5 message digest of the two ways a reference clock can be attached to a NTP header and
   extension fields using service
   host, as an dedicated device managed by the session key ID operating system and value stored as a
   synthetic peer managed by NTP.  As in the key
   cache. The server uses read status command, the session key ID list in reverse order and
   discards each key value after use. An extension field containing
   association identifier is used to identify which one, zero for the
   last index number
   system clock and key ID nonzero for a peer clock.  Only one system clock is included in the first packet
   transmitted (last on
   supported by the list). This extension field protocol, although many peer clocks can be provided
   upon request at any time. When all entries
   supported.  A system or peer clock status word appears in the key list are used,
   a new one is generated.

7.4 Receiving Messages

   The intent is not to hide the message contents. Rather, status
   field of the goal is response to verify its source and that it has not been modified in transit.
   The MAC message digest is compared with the computed digest a read clock variables or write clock
   variables command.  This word can be considered an extension of the
   NTP header and extension fields using
   system status word or the session key ID in peer status word as appropriate.  The
   format of the MAC
   and clock status word is as follows:
     0                                       1
     0   1   2   3   4   5   6   7   8   9   0   1   2   3   4   5
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
   |          Clock Status         |            Code               |
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
   Clock Status Word

   Clock Status: This is an eight-bit integer indicating the key current
   clock status, with values coded as follows:

              +-------+---------------------------------+
              | Value |             Meaning             |
              +-------+---------------------------------+
              |   0   | clock operating within nominals |
              |   1   |          reply timeout          |
              |   2   |         bad reply format        |
              |   3   |    hardware or software fault   |
              |   4   |       propagation failure       |
              |   5   |     bad date format or value computed from the addresses, key ID and cookie. If
   the cookie    |
              |   6   |     bad time format or value    |
              | 7-255 |             reserved            |
              +-------+---------------------------------+

   Clock Event Code: This is zero, an eight-bit integer identifying the message contains public latest
   clock exception event, with new values overwriting previous values. Anybody can
   validate the message or make
   When a valid message containing change to any values.
   If nonzero value occurs in the cookie has been determined by secret means, nobody except radio status field,
   the
   parties radio status field is copied to the secret can validate clock event code field and a message
   system or make a valid message.

7.5 Autokey Protocol Exchanges

   There are five types peer clock exception event is declared as appropriate.

11.2.4  Error Status Word

   An error status word is returned in the status field of Autokey protocol exchanges:

   1.  Parameter Exchange (ASSOC message): This an error
   response as the result of invalid message exchanges host
       names, agrees on digest/signature and identity schemes. This
       protocol exchange format or contents.  Its
   presence is unsigned. Optionally, host name/address can
       be verified using reverse-DNS. An initial association request indicated when the E (error) bit is
       sent by set along with the client, sending
   response (R) bit in the host name and status word response.  It consists of an eight-bit
   integer coded as follows:
     0                                       1                   2                   3
     0   1   2   3   4   5   6   7   8   9   0   1   2   3   4   5 6 7 8 9
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
   |          Error Code           |           Reserved            |
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
   Error Status Word

              +-------+----------------------------------+
              | Value |              Meaning             |
              +-------+----------------------------------+
              |   0   |            unspecified           |
              |   1   |      authentication failure      |
              |   2   | invalid message length or format |
              |   3   |          invalid opcode          |
              |   4   |  unknown association identifier  |
              |   5   |       unknown variable name      |
              |   6   |      invalid variable value      |
              |   7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |     Digest/Signature NID    administratively prohibited   |    Client
              | Ident 8-255 | Host             reserved             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                         Figure 6 Status Word Format

       If
              +-------+----------------------------------+

11.3  Commands

   Commands consist of the server digest NID header and ID scheme agree, optional data field shown in
   Figure 6.  When present, the server responds
       with an association response message, sending host data field contains a list of
   identifiers or assignments in the form

   <<identifier>>[=<<value>>],<<identifier>>[=<<value>>],...

   where <<identifier>> is the ASCII name and
       status word.  The client, upon agreeing with digest NID and ID
       scheme, then sends of a certificate request.  The server responds
       with an X.509 certificate system or peer variable
   specified in Table 2 or Table 3 and signature.  The certificate
       request/response cycle repeats as needed.  A primary (Stratum 1)
       certifcate <<value>> is explicitly trusted and self-signed.  Secondary
       certificates expressed as a
   decimal, hexadecimal or string constant in the syntax of the C
   programming language.  Where no ambiguity exists, the <169>sys.<170>
   or <169>peer.<170> prefixes shown in Table 2 or Table 4 can be
   suppressed.  Whitespace (ASCII nonprinting format effectors) can be
   added to improve readability for simple monitoring programs that do
   not reformat the data field.  Internet addresses are signed by represented as
   four octets in the next lower stratum server and
       validated with its public key.

   2.  Certificate Exchange (CERT message):  This exchange form [n.n.n.n], where n is used to
       obtain in decimal notation and verify certificates on the trail to a trusted root
       certificate.  Certificate exchanges follow
   the same process brackets are optional.  Timestamps, including reference,
   originate, receive and transmit values, as
       parameter exchanges.

   3.  Identity Exchange (IFF, GW, well as the logical clock,
   are represented in units of seconds and MV messages): This exchange is
       used to verify server identity using an agreed identity scheme
       (TC, IFF, GQ, MV).  This exchange is a challenge-response scheme.
       The client initiates fractions, preferably in
   hexadecimal notation, while delay, offset, dispersion and distance
   values are represented in units of milliseconds and fractions,
   preferably in decimal notation.All other values are represented
   as-is, preferably in decimal notation.

   Implementations may define variables other than those listed in Table
   2 or Table 3.  Called extramural variables, these are distinguished
   by sending the inclusion of some character type other than alphanumeric or
   <169>.<170> in the name.  For those commands that return a challenge request.  The server
       then provides list of
   assignments in the challenge response.

   4.  Values Exchange (COOKIE and AUTO messages): This exchange response data field, if the command data field is used
       to obtain and verify
   empty, it is expected that all available variables defined in Table 3
   or Table 4 of the cookie, autokey values, and leapseconds
       table, depending on NTP specification will be included in the association mode (client-server,
       broadcast, symmetric). response.
   For cookie exchanges, the client sends
       its public key to read commands, if the server without signature when not
       synchronized.  Symmetric active peers send its public key and
       signature command data field is nonempty, an
   implementation may choose to passive peer when synchronized. process this field to individually
   select which variables are to be returned.

   Commands are interpreted as follows:

   Read Status (1): The server cookie
       is encrypted from the hash of source/destination addresses, zero
       key ID, and server private value. A symmetric passive cookie command data field is empty or contains a
       random value for every exchange. list
   of identifiers separated by commas.  The server private command operates in two ways
   depending on the value is
       refreshed and protocol restarted once per day. For autokey
       exchanges, of the server generates a key list and signature association identifier.  If this
   identifier is
       calculated to last about one hour.  A client sends requests to nonzero, the server without signature when not synchronized.  The server
       replies with response includes the last index number peer identifier and key ID on
   status word.  Optionally, the response data field may contain other
   information, such as described in the list.
       Broadcast servers uses AUTO response for Read Variables command.  If the first message after
       regenerating
   association identifier is zero, the key and ASSOC responses for all other messages.

   5.  Signature Exchange (SIGN message): This exchange requests response includes the
       server to sign system
   identifier (0) and return status word, while the data field contains a client certificate. list
   of binary-coded pairs
   <<association identifier>> <<status word>>,

   one for each currently defined association.

   Read Variables (2): The exchange command data field is
       valid only when the client has synchronized to empty or contains a proventic source
       and
   list of identifiers separated by commas.  If the server identity has been confirmed.  This exchange association
   identifier is
       used to authenticate clients to servers, with the server acting
       as de facto certificate authority using an encrypted credential
       scheme.  The client sends a certificate to nonzero, the server with or
       without signature.  The server extracts response includes the requested data peer
   identifier and
       signs that status word, while the data with field contains a list of
   peer variables and values as described above.  If the server private key.  The client then
       verifies association
   identifier is zero, the certificate data field contains a list of system
   variables and signature.  Subsequently, values.  If a peer has been selected as the client
       supplies this certificate rather than self-signed certificates,
       so clients can verify with
   synchronization source, the server public key.
8.  Configuration and Management

   The means used in response includes the configuration and management of NTP servers peer identifier and clients is
   status word; otherwise, the NTP control and monitoring protocol defined in
   RFC 1305.

   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 response includes the system identifier
   (0) and one status word.

   Write Variables (3): The command data field contains a list of the others
   assignments as described above.  The variables are updated as
   indicated.  The response is as described for backup should the active one fail or show an error condition.  It Read Variables
   command.

   Read Clock Variables (4): The command data field is not normally
   useful to use more than one server at empty or contains
   a time, as with millions list of
   NTP-enabled devices expected identifiers separated by commas.  The association
   identifier selects the system clock variables or peer clock variables
   in the near future, such use could
   result same way as in unnecessary strain on network and server resources.

   Broadcast servers and anycast clients must be provided with the TTL
   and local broadcast or multicast group address.  Unicast Read Variables command.  The response
   includes the requested clock identifier and anycast
   servers status word and broadcast clients may be configured with the data
   field contains 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 clock variables and
   clients must implement values, including the IGMP protocol and be provided with
   last timecode message received from the
   local broadcast or multicast group address as well. clock.

   Write Clock Variables (5): The
   configuration command data for cryptographic authentication is beyond the
   scope of this memo.

   There are several scenarios which provide automatic server discovery
   and selection for NTP clients with no pre-specified server
   configuration.  For instance a role server with CNAME such as
   pool.ntp.org returns field contains a randomized list of volunteer secondary server
   addresses and the client can select one or more
   assignments as candidates.  For
   an IP subnet or LAN segment including a NTP or SNTP server, NTP
   clients can be configured described above.  The clock variables are updated as broadcast clients.
   indicated.  The same approach
   can be used with multicast servers response is as described for the Read Clock Variables
   command.

   Set Trap Address/Port (6): The command association identifier, status
   and data fields are ignored.  The address and port number for
   subsequent trap messages are taken from the source address and clients.  In both cases,
   provision port
   of an access the control list message itself.  The initial trap counter for trap
   response messages is a good way to insure only
   trusted sources can be used to set taken from the system clock.

   In another scenario suitable for an extended network with significant
   network propagation delays, clients can be configured for anycast
   addresses, both upon initial startup sequence field of the command.
   The response association identifier, status and data fields are not
   significant.  Implementations should include sanity timeouts which
   prevent trap transmissions if the monitoring program does not renew
   this information after some period a lengthy interval.

   Trap Response (7): This message is sent when a system, peer or clock
   exception event occurs.  The opcode field is 7 and the
   currently selected unicast source has not been heard.  Following R bit is set.
   The trap counter is incremented by one for each trap sent and the
   defined protocol,
   sequence field set to that value.  The trap message is sent using the client binds
   IP address and port fields established by the set trap address/port
   command.  If a system trap the association identifier field is set to
   zero and the server from which status field contains the first
   reply system status word.  If a peer
   trap the association identifier field is received set to that peer and continues operation the
   status field contains the peer status word.  Optional ASCII-coded
   information can be included in unicast mode.

9. the data field.

12.  The Kiss-o'-Death Packet

   In the interest of self-preservation, it is important that NTP
   servers have a mechanism to supress or otherwise influence the amount
   of queries performed by NTP clients.

   According to the NTPv3 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.

   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.  A list of the currently-defined kiss codes
   is in the following table.

   +---------------------------------+---------------------------------+
   |               Code              |             Meaning
      --------------------------------------------------------------             |
   +---------------------------------+---------------------------------+
   |               ACST              |  The association belongs to a an  |
   |                                 |          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  |
   |                                 |  dynamically discovered 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         |
   +---------------------------------+---------------------------------+

   In general, an NTP 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 Section 11.

10. 15.

13.  Security Considerations

   In the case of NTP as specified herein, there is a very real
   vulnerability that NTP 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.

   While not required in a conforming NTP client implementation, there
   are a variety of recommended checks that an NTP client can perform
   that are designed to avoid various types of abuse that might happen
   as the result of server implementation errors or malicious attack.
   These recommended checks are as follows:

   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.

   4.

      The server reply should be discarded if any of the LI, Stratum, or
      Transmit Timestamp fields are 0 or the Mode field is not 4
      (unicast) or 5 (broadcast).

   5.

      A truly paranoid client can check 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 16
      seconds.  This check avoids using a server whose synchronization
      source has expired for a very long time.

11.

14.  IANA Considerations

12.

15.  Other Considerations

   NTP and SNTP clients can consume considerable network and server
   resources if 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
   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 use a poll interval less than TBD minutes.

   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 on a periodic
      intervals, but not 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.

   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 results 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 selecting candidate SNTP or NTP servers, 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 helpdesks can be difficult.

   A well behaved client operates as follows (note that steps 2 - 4
   comprise 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 less
      than 15 minutes.

   2.

      When 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 the IP address is unknown and 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 ICSA certification.

   3.

      When the timer reaches zero, if the IP address is not known, send
      a DNS query packet; otherwise send a NTP request packet to that
      address.  If no reply packet has been heard since the last
      timeout, double the timeout, but not 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 in step 2.  If a KoD packet is received remove that time
      server from the list, activate the secondary time server and
      continue in step 2.  If a received packet fails the sanity checks,
      drop that packet and also continue in step 2.  If a valid NTP
      packet is received, update the system clock, set the timeout to
      the maximum, and continue to step 2.

13.

16.  Acknowledgements

   This document has drawn significant material from the document
   <draft-mills-sntp-v4-00.txt>.
   draft-mills-sntp-v4-00.txt.  As a result, the authors would like to
   acknowledge D. Plonka of the University of Wisconsin and J.
   Montgomery of Netgear, who were significant contributors to that
   draft.

14.

17.  References

14.1

17.1  Normative References

[MIL92]

   [1]  Mills, D., "Network Time Protocol (Version 3) Specification,
        Implementation", RFC 1305, March 1992.

[MIL96]

   [2]  Mills, D., "Simple Network Time Protocol (SNTP) Version 4 for
        IPv4, IPv6, IPv6 and OSI", RFC 2030, October 1996.

14.2

17.2  Informative References

[CAIN02] Cain, B., Deering, S., Kouvalas, I., Fenner, B.

   [3]   International Standards Organization, "International Standards
         8602 - Information Processing Systems - OSI: Connectionless
         Transport Protocol Specification.", ISO 8602, December 1986.

   [4]   Shue, C., Haggerty, W., and A.
         Thyagarajan, "Internet Group Management Protocol, K. Dobbins, "OSI connectionless
         transport services on top of UDP: Version
         3", 1", RFC 3376, Cereva Networks, 1240,
         June 1991.

   [5]   Furniss, P., "Octet Sequences for Upper-Layer OSI to Support
         Basic Communications Applications", RFC 1698, October 2002.

[DAR81] 1994.

   [6]   Postel, J., "User Datagram Protocol", STD 6, RFC 768,
         August 1980.

   [7]   Postel, J., "Internet Protocol", STD 5, RFC 791,
         September 1981.

[DEE89]  Deering, S., "Host extensions for IP multicasting", STD 5,
         RFC 1112, August 1989.

[DER98]

   [8]   Deering, S., Hinden R., S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)," (IPv6)
         Specification", RFC 2460, December 1998.

[DOB91]  Dobbins, K, Haggerty, W. and C. Shue, "OSI connectionless
         transport services on top of UDP - Version: 1", RFC 1240,
         June 1991.

[ISO86]  International Standards 8602 - Information Processing
         Systems - OSI: Connectionless Transport Protocol
         Specification. International Standards Organization,
         December 1986.

[MIL85]

   [9]   Mills, D., "Network Time Protocol (NTP)", (version 2) specification and
         implementation", STD 12, RFC 958, 1119, September 1985.

[MIL88] 1989.

   [10]  Mills, D., "Network Time Protocol (Version (version 1) Specification specification and Implementation",
         implementation", RFC 1059, July 1988.

[MIL89]  Mills,

   [11]  Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9,
         RFC 959, October 1985.

   [12]  Meyer, D., "Network Time Protocol (Version 2) Specification "Administratively Scoped IP Multicast", BCP 23,
         RFC 2365, July 1998.

   [13]  Cain, B., Deering, S., Kouvelas, I., Fenner, B., and Implementation," A.
         Thyagarajan, "Internet Group Management Protocol, Version 3",
         RFC 1119, September 1989.

[POS80]  Postel, J., "User Datagram Protocol", 3376, October 2002.

   [14]  Deering, S., "Host extensions for IP multicasting", STD 6, 5,
         RFC 768, 1112, August
         1980.

15. 1989.

Authors' Addresses

   Jack L. Burbank (Editor)
   The (editor)
   Johns Hopkins University Applied Physics Laboratory (JHU/APL) Lab
   11100 Johns Hopkins Road
   Laurel, MD  20723  20723-6099
   US

   Phone: +1 443-778-7127
   EMail: 443 778 7127
   Email: jack.burbank@jhuapl.edu
   Jim Martin (co-Editor) (editor)
   Netzwert AG
   An den Treptowers 1
   D-12435
   Berlin  12435
   Germany

   Phone: +49.30/5 900 800-180
   EMail: jim@Netzwert.AG 80-1180
   Email: jim@netzwert.ag

   Dr. David L. Mills
   The University of Delaware
   Electrical Engineering Department
   University of Delaware
   Newark, DE  19716
   US

   Phone: (302) 831-8247
   EMail: +1 302 831 8247
   Email: mills@udel.edu

Intellectual Property Statement

   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.

Disclaimer of Validity

   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.

Copyright Statement

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.