NTP WG                                                   J. Burbank, Ed.
Internet-Draft                                                   JHU APL
Expires: April 26, 2006                                                   JHU/APL
Obsoletes: RFC 4330 (if approved)                         J. Martin, Ed.
Expires: September 2, 2006                                   Netzwert AG
                                                                D. Mills
                                                                 U. Del.
                                                        October 23, 2005
                                                              March 2006

       The Network Time Protocol Version 4 Protocol Specification
                     draft-ietf-ntp-ntpv4-proto-01
                     draft-ietf-ntp-ntpv4-proto-02

Status of this Memo

   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 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 Internet-Draft will expire on April 26, September 2, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005). (2006).

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 a dynamic server discovery mechanism and an
   authentication scheme designed specifically for multicast and
   dynamically discovered servers. mechanism.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Requirements Notation  . . . . . . . . . . . . . . . . . .  4
   2.  NTP Timestamp  . . . . . . . . . . . . . . . . . . . . . . .   5 .  4
   3.  NTP Message Formats  . . . . . . . . . . . . . . . . . . . .   7
     3.1 .  6
     3.1.  Leap Indicator (LI)  . . . . . . . . . . . . . . . . . . .   8
     3.2  7
     3.2.  Version (VN) . . . . . . . . . . . . . . . . . . . . . . .   9
     3.3  8
     3.3.  Mode . . . . . . . . . . . . . . . . . . . . . . . . . . .   9
     3.4  8
     3.4.  Stratum (Strat)  . . . . . . . . . . . . . . . . . . . . .  10
     3.5  9
     3.5.  Poll Interval (Poll) . . . . . . . . . . . . . . . . . . .  10
     3.6  9
     3.6.  Precision (Prec) . . . . . . . . . . . . . . . . . . . . .  10
     3.7  9
     3.7.  Root Delay . . . . . . . . . . . . . . . . . . . . . . . .  10
     3.8  9
     3.8.  Root Dispersion  . . . . . . . . . . . . . . . . . . . . . 10
     3.9
     3.9.  Reference Identifier . . . . . . . . . . . . . . . . . . .  11
     3.10 10
     3.10. Reference Timestamp  . . . . . . . . . . . . . . . . . .  12
     3.11 . 11
     3.11. Originate Timestamp  . . . . . . . . . . . . . . . . . .  12
     3.12 . 11
     3.12. Receive Timestamp  . . . . . . . . . . . . . . . . . . .  12
     3.13 . 11
     3.13. Transmit Timestamp . . . . . . . . . . . . . . . . . . .  12
     3.14 . 11
     3.14. NTPv4 Extension Fields . . . . . . . . . . . . . . . . . . 12
     3.15
     3.15. Authentication (optional)  . . . . . . . . . . . . . . . . 13
   4.  NTP Protocol Operation . . . . . . . . . . . . . . . . . . . . 14
   5.  SNTP Protocol Operation  . . . . . . . . . . . . . . . . . .  14 . 17
   6.  NTP Server Operations  . . . . . . . . . . . . . . . . . . .  15 . 18
   7.  NTP Client Operations  . . . . . . . . . . . . . . . . . . .  17 . 20
   8.  NTP Symmetric Peer Operations  . . . . . . . . . . . . . . .  20
   9.   NTPv4 Security . . . . . . . 22
   9.  Dynamic Server Discovery . . . . . . . . . . . . . . . .  20
     9.1  Session Keys and Cookies . . . 22
   10. The Kiss-o'-Death Packet . . . . . . . . . . . . . .  20
     9.2  Session Key List Generation . . . . . 23
   11. Security Considerations  . . . . . . . . . .  21
     9.3  Sending Messages . . . . . . . . . 24
   12. IANA Considerations  . . . . . . . . . . . .  21
     9.4  Receiving Messages . . . . . . . . . 25
   13. Acknowledgements . . . . . . . . . . .  21
     9.5  Autokey Protocol Exchanges . . . . . . . . . . . . 25
   14. References . . . .  22
   10.  Dynamic Server Discovery . . . . . . . . . . . . . . . . . .  23
   11.  NTP Control Messages . . . . 25
     14.1. Normative References . . . . . . . . . . . . . . . .  24
     11.1   NTP Control Message Format . . . 25
     14.2. Informative References . . . . . . . . . . . .  26
     11.2   Status Words . . . . . . 25
   Appendix A.  NTP Control Messages  . . . . . . . . . . . . . . . . 27
       11.2.1   System Status Word .
     A.1.  NTP Control Message Format . . . . . . . . . . . . . . . . 28
       11.2.2   Peer
     A.2.  Status Word . . . . . . . . . . . . Words . . . . . .  29
       11.2.3   Clock Status Word . . . . . . . . . . . . . . . . .  31
       11.2.4   Error 30
       A.2.1.  System Status Word . . . . . . . . . . . . . . . . .  32
     11.3   Commands . . . . . 31
       A.2.2.  Peer Status Word . . . . . . . . . . . . . . . . . . . 33
   12.  The Kiss-o'-Death Packet . . . . . . . . . . . . .
       A.2.3.  Clock Status Word  . . . . .  35
   13.  Security Considerations . . . . . . . . . . . . . 34
       A.2.4.  Error Status Word  . . . . .  36
   14.  IANA Considerations . . . . . . . . . . . . . 35
     A.3.  Commands . . . . . . .  37
   15.  Other Considerations . . . . . . . . . . . . . . . . . . 36
   Authors' Addresses . .  37
   16.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 39
   17.  References . . . . . . . . . . . . . . . . . . . . . . . . .  39
     17.1   Normative References . . . . . . . . . . . . . . . . . .  39
     17.2   Informative References . . . . . . . . . . . . . . . . .  39
        Authors' Addresses . . . . . . . . . . .
   Intellectual Property and Copyright Statements . . . . . . . . . . 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 of servers and
   clients and adjust the system clock in each participant.  In most
   places of on 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
   capabilities.  Thus, the Simple Network Time Protocol Version 4
   (SNTPv4) as described in [2]. [2] was developed for platforms that cannot
   afford the size and complexity of NTP as a whole.

   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 4330 (SNTPv4 is a
   subset of NTPv4).  This document obsoletes RFC 4330.

   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 [3]and OSI [4] 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]. [5].  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]. [6].  It is not advised that NTP be operated at the
   upper layers of the OSI stack, such as might be inferred from [5], [7], as
   this could seriously degrade accuracy.  With the header formats
   defined in this memo, it is is, in principle 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 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. operation.  Section 10 9 defines the new mechanism for server
   discovery.  Section 11 describes the control and management mechanism for NTP.
   Section 12 10 describes the kiss-o'-death message, whose functionality
   is similar to the ICMP Source Quench and ICMP Destination Unreachable
   messages.  Section 13 11 presents NTPv4 security considerations and
   Section 14 12 discusses IANA Considerations.
   Finally, Section 15 Considerations.Appendix A presents various other considerations when
   implementing and/or configuring NTPv4. optional
   NTP control messages.

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

2.  NTP Timestamp

   NTPv4 uses the standard NTP timestamp format

1.1.  Requirements Notation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 1305. 2119 [8].

2.  NTP data Timestamp

   There are specified as integer or fixed-point quantities, with
   bits numbered in big-endian fashion from three NTP formats used to represent time values: a 128-bit
   date format, a 64-bit timestamp format, and a 32-bit short format.
   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  Note that dates cannot be produced by NTP, but can
   rather be obtained from external means and conveyed via the protocol.
   Date values are represented as a 64-bit unsigned fixed-point
   number, in seconds twos compliment arithmetic relative to 0h on 1 January 1900.  The integer
   part is in
   the first 32 base date of 0628:16h 7 February 2036 UTC (when all 128 bits and the fraction part in the last 32
   bits.  In are
   zero).  Values greater than zero represent times after the fraction part, base date;
   values less than zero represent times before the non-significant low order bits base date.  Dates
   are
   not specified and ordinarily set to 0.  The NTP timestamp format signed values.  Timestamps are signed values.  A value of zero is
   defined as:
   a special case representing unknown or unsynchronized time.

   Figure 1 illustrates the three NTP time formats.

    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            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                            NTP Short Format

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

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Era Number                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Era Offset                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                           Fraction                            |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                           NTP Date Format

   Figure 1: NTP Timestamp Format

   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 calculated
   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],
   [9], which itself is layered on the Internet Protocol (IP) [7]
   [8]. [10] [3].
   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 MUST 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

   Figure 2 provides a description of the NTPv4 message format, which follows the
   IP and UDP headers. format.  This
   format is identical to that described in RFC 1305, with the exception
   of the contents of the reference identifier field. field and optional
   extension fields.  The header fields are defined as: in Figure 2.

    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

   Figure 2: NTPv4 Message Format

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  A leap second is
   inserted or deleted in the case of secondary servers the bits are set by timescale on the protocol. last day of June or
   December.  The possible values of the LI field, and corresponding
   meanings, are as
   follows:

           +----+------------------------------------------+ given in Table 1.

            +----+--------------------------------------------+
            | LI |                   Meaning                  |
           +----+------------------------------------------+
            +----+--------------------------------------------+
            |  0 |                 no warning                 |
            |  1 |    last minute of the day has 61 seconds   |
            |  2 |    last minute of the day has 59 seconds   |
            |  3 | alarm condition (clock not never synchronized) |
           +----+------------------------------------------+
            +----+--------------------------------------------+

                  Table 1: Length Indicator Field Values

   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

3.2.  Version (VN)

   This is a three-bit integer indicating the NTP/SNTP version number,
   currently 4.
   set to 4 for NTPv4.  If necessary to distinguish between IPv4, IPv6
   and OSI, the encapsulating context must be inspected.

3.3

3.3.  Mode

   This is a three-bit number indicating the protocol mode.  The values
   are defined as follows:

              +------+----------------------------------+ in Table 2.

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

                        Table 2: Mode Field Values
   Mode 0 is reserved.  Modes 1 and 2 are intended for use by symmetric
   peers who set this mode to 1 or 2 depending on whether it is active
   or passive mode.  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  A mode type of 6 is reserved for NTP control
   messages.  Mode 7 is reserved for private usage.

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: in Table 3.

    +---------+-------------------------------------------------------+
    | Stratum |                        Meaning                        |
    +---------+-------------------------------------------------------+
    |    0    |                 kiss-o'-death message                 |
    |    1    | primary reference (e.g., synchronized by radio clock) |
    |   2-15  2-255  |   secondary reference (synchronized by NTP or SNTP)   |
  |  16-255 |                        reserved                       |
    +---------+-------------------------------------------------------+

3.5

                       Table 3: Stratum Field Values

3.5.  Poll Interval (Poll)

   This is an eight-bit unsigned integer used as an exponent of two,
   where the resulting value is indicating the maximum interval
   between successive
   messages messages, in log2 seconds.  This field is significant only in SNTP server
   messages, where the values range from 4 (16 s)  A client SHOULD NOT
   use a poll interval less than 15 seconds, except at initial startup
   when it MAY send a sequence of 8 packets at 1 second intervals to 17 (131,072 s -
   about 36 h).

3.6
   provide initial synchronization of the clients with each server.  A
   client SHOULD increase the poll interval as performance permits and
   especially if the server does not respond within a reasonable time.

3.6.  Precision (Prec)

   This is an eight-bit signed integer used as an exponent of two, where
   the resulting value is indicating the precision of the
   system clock in log2 seconds.
   This field  Precision is significant only in server messages, where normally determined when
   the values
   range from -6 for mains-frequency clocks service is established as the minimum number of iterations of the
   time to -20 for microsecond
   clocks found in some workstations.

3.7 read the system clock.  As an example, a value of -18
   corresponds to a precision of about one microsecond.

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. 32-bit NTP short
   format.  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

3.8.  Root Dispersion

   This is a 32-bit unsigned fixed-point number indicating the nominal
   error relative to the primary reference source, source in seconds with
   fraction point between bits 15 and 16.  This field is significant
   only seconds, in server messages, where the values range from zero to several
   hundred milliseconds.

3.9 32-bit
   NTP short format.

3.9.  Reference Identifier

   This is a 32-bit bitstring identifying the particular reference
   source.  This  The interpretation of this field is significant only in server messages, where for
   stratum 0 (kiss-o'-death message) and 1 (primary server), depends on the value in the
   stratum field.  For stratum 0, this is a four-character ASCII string, left justified and zero padded
   referred to
   32 bits. as a 'kiss code' and is used for debugging and monitoring
   purposes.  For IPv4 secondary servers,the value stratum 1, this is a four-octet, left-justified, zero-
   padded ASCII string assigned to the 32-bit IPv4
   address reference source.  Above stratum
   1 (secondary servers and clients), this is the reference identifier
   of the server.  If employing IPv4, the value is the 32-bit IPv4
   address of the synchronization source.  For IPv6 and OSI secondary
   servers, OSI, the value
   is the first 32 bits of the MD5 hash of the IPv6 or NSAP address of
   the synchronization source.  The fASCII identifiers that are
   currently defined are given in Table 4.

   Primary (stratum 1) servers set this field to a code identifying the
   external reference source according to the below table.

  +------+----------------------------------------------------------+ Table 4.

      +-------+----------------------------------------------------+
      | Code  | External Reference Source                          |
  +------+----------------------------------------------------------+
  | LOCL | uncalibrated local clock                                 |
      +-------+----------------------------------------------------+
      | CESM GOES  | calibrated Cesium clock Geosynchronous Orbit Environment Satellite         |
      | RBDM GPS   | calibrated Rubidium clock Global Position System                             |
      | PPS   | calibrated quartz clock or other Generic pulse-per-second source                           |
      | IRIG  | Inter-Range Instrumentation Group                  |
      | ACTS WWVB  | NIST telephone modem service LF Radio WWVB Ft.  Collins, CO 60 kHz              |
      | USNO DCF77 | USNO telephone modem service LF Radio DCF77 Mainflingen, DE 77.5 kHz            |
      | PTB HBG   | PTB (Germany) telephone modem service LF Radio HBG Prangins, HB 75 kHz                   |
      | TDF MSF   | Allouis (France) LF Radio 164 MSF Rugby, UK 60 kHz                      |
      | DCF JJY   | Mainflingen (Germany) LF Radio 77.5 JJY Fukushima, JP 40 kHz, Saga, JP 60 kHz |
      | MSF LORC  | Rugby (UK) MF Radio 60 LORAN C 100 kHz                           |
      | WWV TDF   | Ft. Collins (US) MF Radio 2.5, 5, 10, 15, 20 MHz Allouis, FR 162 kHz                       |
      | WWVB CHU   | Boulder (US) HF Radio 60 kHz CHU Ottawa, Ontario                       |
      | WWVH WWV   | Kaui Hawaii (US) HF Radio 2.5, 5, 10, 15 MHz WWV Ft.  Collins, CO                      |
      | CHU WWVH  | Ottawa (Canada) HF Radio 3330, 7335, 14670 kHz WWVH Kauai, HI                            |
      | LORC NIST  | LORAN-C radionavigation system NIST telephone modem                               |
      | OMEG USNO  | OMEGA radionavigation system USNO telephone modem                               |
      | GPS PTB   | Global Positioning Service European telephone modem                           |
  +------+----------------------------------------------------------+
      +-------+----------------------------------------------------+

             Table 4: Currently-defined Reference Identifiers

   If the external reference is one of those listed, the associated code
   should be used.  Codes for sources not listed can be contrived created as
   appropriate.

   In previous NTP and SNTP secondary servers and clients
   appropriate (see IANA Considerations section of this field was
   often used to walk-back the synchronization subnet to the root
   (primary server) for management purposes.

3.10 document).

3.10.  Reference Timestamp

   This field is significant only in server messages, where the value is a 64 bit signed integer indicating the time at which when the system
   clock was last set or corrected, correctetd, in 64-
   bit 64-bit NTP timestamp format.

3.11

3.11.  Originate Timestamp

   This is the time at which the request departed the client for the
   server, in 64-bit NTP timestamp format.

3.12

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 NTP timestamp format.

3.13

3.13.  Transmit Timestamp

   This is the time at which the request departed the client or the
   reply departed the server, in 64-bit NTP timestamp format.

3.14

3.14.  NTPv4 Extension Fields

   NTPv4 defines new extension field formats.  These fields are
   processed in order and may be transmitted with or without value
   fields.  The last minimum extension
   field length is padded to a 64-bit boundary, all others
   fields are padded to 32-bit boundaries. 8 octets.  The format of the NTP extension field length is for all
   payload and padding.
   given in Figure Figure 3.

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

3.15  Authentication (optional)

   Figure 3: NTP Extension Field Format

   The authentication Field Type field format is defined as:

    0                   1                   2                   3
    0 a 16-bit integer which indicates the type of
   extension message contained within the extension field.

   The Length field is a 16-bit integer indicates the length of the
   entire extension field in octets, including the Length and Padding
   fields.

   The 32-bit Association ID field is set by clients to the value
   previously received from the server or 0 otherwise.  The server sets
   the Association ID field when sending a response as a handle for
   subsequent exchanges.  If the association ID value in a request does
   not match the association ID of any association, the server returns
   the request with the first two bits of the Field Type field set to 1.

   The Timestamp and Filestamp 32-bit fields carry the seconds field of
   an NTP timestamp.  The Timestamp field establishes the signature
   epoch of the data field in the message, while the filestamp
   establishes the generation epoch of the file that ultimately produced
   the data.

   The 32-bit Value Length field indicates the length of the Value field
   in octets.  The minimum length of the Value field is 0.

   The 32-bit Signature Length field indicates the length of the
   Signature field in octets.

   Zero padding is applied, as necessary, to extend the extension field
   to a word (4-octet) boundary.  If multiple extension fields are
   present, the last extension field is zero-padded to a double-word (8
   octet) boundary.

3.15.  Authentication (optional)

   NTPv4 provides an optional 160-bit Authentication field.  When
   implemented, the 32-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.  The
   authentication field format is shown in Figure Figure 4.
   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

   Figure 4: NTP authentication scheme is implemented, the 16-bit Authentication Field

   The 32-bit Key Identifier and is an integer identifying the 128-bit
   private key used to generate the MAC.  The Message Digest fields contain field
   contains the MD5 Message
   Authentication Code (MAC) information which uses Digest.  In NTPv4, the presence of one or
   more extension fields requires the presence of an MD5 cryptosum authentication
   field.  The presence of
   NTP header plus the Authentication field and extension fields. fields
   is determined from the Length field.

   The Key Identifier is initialized to zero at the start of an
   association.  The type of association then determines the key
   identifier.  If the association is active (modes 1, 3, 5) the key is
   determined from the system key identifier.  If the association is
   passive (modes 2, 4) the key is determined from the peer key
   identifier, if the authentic bit is set (see [1]), or as the default
   key (zero) otherwise.

4.  NTP Protocol Operation

   The NTP protocol defines three operational roles, Client, Server, and
   Symmetric Peer.  Clients request or receive time unsolicited from
   Servers. Servers
   (solicited or unsolicited).  Servers respond to requests or send
   periodic time updates to Clients.  Symmetric Peers exchange time data
   bidirectionally.  A given NTP NTPv4 implementation can operate in any or
   all of these modes.

   NTP messages make use of two different communication modes, one to
   one and one to many, commonly referred to as unicast and broadcast.
   For the purposes of this document, the term broadcast is interpreted
   to mean any available one to many mechanism.  For IPv4 this equates
   to either IPv4 broadcast or IPv4 multicast.  For IPv6 this equates to
   IPv6 multicast.  For OSI this XXXXX.  For this purpose, IANA has allocated the IPv4
   multicast address 224.0.1.1 and the IPv6 multicast address ending
   :101, with prefix determined by scoping rules.  The
   NTP

   Except in broadcast address for OSI has yet to be determined.

      It mode, an NTP association is important to adjust formed when two peers
   exchange messages and one or both of them create and maintain an
   instantiation of the time-to-live (TTL) field protocol machine, called an association.  The
   association can operate in the IP
      header one of multicast messages to five modes as indicated by the
   host- mode variable (peer.mode) (see [1] for a reasonable value in order to
      limit description of the network resources used by this (and any other) multicast
      service.  Only multicast clients in scope will receive multicast NTP
   variables): symmetric active, symmetric passive, client, server messages.  Only cooperating anycast servers in scope will
      reply to a client request.  The engineering principles and
   broadcast, which
      determine the proper values to be used are beyond the scope of defined as follows:

   Symmetric Active (1): A host operating in this memo.

      While not integral to mode sends periodic
   messages regardless of the NTP specification, it is intended that
      IP broadcast addresses will be used primarily reachability state or stratum of its peer.
   By operating in IP subnets this mode the host announces its willingness to
   synchronize and
      LAN segments including be synchronized by the peer.

   Symmetric Passive (2): This type of association is ordinarily created
   upon arrival of a fully functional NTP server with message from a number
      of dependent NTP broadcast clients on peer operating in the same subnet, while IP
      multicast group addresses symmetric
   active mode and persists only as long as the peer is reachable and
   operating at a stratum level less than or equal to the host;
   otherwise, the association is dissolved.  However, the association
   will always persist until at least one message has been sent in
   reply.  By operating in this mode the host announces its willingness
   to synchronize and be used synchronized by the peer.

   Client (3): A host operating in this mode sends periodic messages
   regardless of the reachability state or stratum of its peer.  By
   operating in this mode the host announces its willingness to be
   synchronized by, but not to synchronize the peer.

   Server (4): This type of association is ordinarily created upon
   arrival of a client request message and exists only in cases where order to reply
   to that request, after which the TTL association is engineered specifically for each service domain. dissolved.  By
   operating in this mode the host announces its willingness to
   synchronize, but not to be synchronized by the peer.

   Broadcast (5): A host operating in this mode sends periodic messages
   regardless of the reachability state or stratum of the peers.  By
   operating in this mode the host announces its willingness to
   synchronize all of the peers, but not to be synchronized by any of
   them.

   NTP messages are layered on top of UDP.  All messages MUST be sent
   with a destination port of 123, and SHOULD be sent with a source port
   of 123.

5.  SNTP Protocol Operation

   SNTP operates using the same message formats, addresses,

   The on-wire protocol uses four timestamps numbered T1 through T4 and ports
   three state variables org, rec, and xmt, as
   NTP.  However, it is stateless, operating only shown in Figure Figure 5,
   where T1 corresponds to the Client or
   Server roles.  Thus it is compatible with, and a subset of, NTP.

   Without Reference Timestamp T2 corresponds to the complexity
   Originate Timestamp, T3 corresponds to the Receive Timestamp, and state required by T4
   corresponds to the Symmetric Peer, SNTP
   is apropriate for devices which require a significantly smaller
   resource footprint.  Since a SNTP server ordinarily does not
   implement Transmit Timestamp.

              t2            t3           t6            t7
         +---------+   +---------+   +---------+   +---------+
     T1  |    0    |   |    t2   |   |   t4    |   |    t6   |
         +---------+   +---------+   +---------+   +---------+
     T2  |    0    |   |    t1   |   |   t3    |   |    t5   |  Packet
         +---------+   +---------+   +---------+   +---------+ Variables
     T3  |t2=clock |   |    t2   |   |t6=clock |   |    t6   |
         +---------+   +---------+   +---------+   +---------+
     T4  |   t1    |   |t3=clock |   |   t5    |   |t7=clock |
         +---------+   +---------+   +---------+   +---------+
                                                                Peer B
         +---------+   +---------+   +---------+   +---------+
    org  |   t1    |   |    t1   |   | T3<>t1? |   |    t5   |
         +---------+   +---------+   +---------+   +---------+   State
    rec  |   t2    |   |    t2   |   |   t6    |   |    t6   | Variables
         +---------+   +---------+   +---------+   +---------+
    xmt  |    0    |   |    t3   |   | T1<>t3? |   |    t7   |
         +---------+   +---------+   +---------+   +---------+

                   t2      t3                 t6          t7
         ---------------------------------------------------------
                  /\         \                 /\            \
                  /           \                /              \
                 /             \              /                \
                /               \/           /                 \/
         ---------------------------------------------------------
              t1                t4         t5                  t8

             t1            t4            t5             t8
         +---------+   +---------+   +---------+   +---------+
     T1  |    0    |   |    t2   |   |   t4    |   |    t6   |
         +---------+   +---------+   +---------+   +---------+
     T2  |    0    |   |    t1   |   |   t3    |   |    t5   |  Packet
         +---------+   +---------+   +---------+   +---------+ Variables
     T3  |    0    |   |t4=clock |   |   t4    |   |t8=clock |
         +---------+   +---------+   +---------+   +---------+
     T4  |t1=clock |   |    t3   |   |t5=clock |   |    t7   |
         +---------+   +---------+   +---------+   +---------+
                                                                Peer A
         +---------+   +---------+   +---------+   +---------+
    org  |    0    |   |  T3<>0? |   |   t3    |   | T3<>t3? |
         +---------+   +---------+   +---------+   +---------+   State
    rec  |    0    |   |    t4   |   |   t4    |   |    t8   | Variables
         +---------+   +---------+   +---------+   +---------+
    xmt  |   t1    |   |  T1=t1? |   |   t5    |   | T1<>t5? |
         +---------+   +---------+   +---------+   +---------+

   Figure 5: NTPState
   This figure shows the full suite most general case, where each of grooming two peers, A
   and mitigation algorithms
   intended to support redundant servers B, independently measure the offset and diverse network paths, a
   SNTP server should be operated only delay relative to the
   other.  For illustrative purposes, the individual timestamp values
   are shown in conjunction lower case with a source subscripts indicating the order of
   external synchronization, such as a reliable radio clock or telephone
   modem.
   transmission and reception.  In this case it operates as a primary (stratum 1) server.

      Note that SNTP servers normally operate as primary (stratum 1)
      servers.  While operating the figure, the first packet
   transmitted by A contains only the transmit timestamp T4 with value
   t1.  B receives the packet at higher strata (up t2 and saves the originate timestamp T2
   with value t1 in state variable org and the receive timestamp T3 with
   value t2 in state variable rec.  Afterwards, B sends a packet to 15) A
   containing the org and rec state variables in T2 and T1 respectively
   and additionally the transmit timestamp T4 with value t3, which is
   saved in the xmt state variable.  When this packet arrives at A the
      same time synchronizing
   packet header variables T1, T2, T3, and T4 represent the four
   timestampes necessary to an external source such as compute the offset and delay of B relative
   to A.

   Before the A state variables are updated, two sanity checks are
   performed in order to protect against duplicate or invalid packets.
   A packet is a GPS
      receiver duplicate if the transmit timestamp T4 in the packet
   matches the xmt state variable.  A packet is invalid if the origin
   timestamp T2 in the packet does not forbidden, this match the org state variable.  In
   either of these cases the state variables are updated, but the packet
   is discarded.

   The general rules that govern the updating of state variables and
   packet variables are given in Figure 6.
   +-------------------------------------------------------+
   |        Receive           |        Transmit            |
   +-------------------------------------------------------+
   |   org=T4                 |   org=unchanged            |
   |   rec=Time of Receipt    |   rec=unchanged            |
   |   xmt=unchanged          |   xmt=Time of transmission |
   |                          |                            |
   |   T1=Received T3         |   T1=rcv                   |
   |   T2=Received T2         |   T2=org                   |
   |   T3=rec                 |   T3=unchanged             |
   |   T4=Received T4         |   T4=xmt                   |
   +-------------------------------------------------------+

   Figure 6: Relationship between NTP State Variables and NTP Packet
   Variables

5.  SNTP Protocol Operation

   SNTP operates using the same message formats, addresses, and ports as
   NTP.  However, it is strongly discouraged. stateless, operating only in the client or
   server roles.  Thus it is compatible with, and a subset of, NTP.

6.  NTP Server Operations

   Fundamentally, the NTP Server role consists of listening for client
   requests, and providing time and associated details as a response.
   Additionally, a Server server can provide time and associated details
   periodically via a broadcast mechanism.

   An NTP server operating with
   either an NTP or SNTP client of the same or previous versions retains
   no persistent state.

   An NTP server can communicate via unicast, broadcast, can communicate via unicast, broadcast, or both.  A
   server receiving a unicast request (NTP mode 3), modifies fields in
   the NTP header as described below, and sends a reply (NTP mode 4),
   possibly using the same message buffer as the 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 required accuracy.

   A broadcast server may or may not send messages if not synchronized
   to a correctly operating source, but the preferred option is to
   transmit, since this allows reachability to be determined regardless
   of synchronization state.

   The Leap Indicator (LI) is set to 3 (unsynchronized) if the server
   has never synchronized to a reference source.  Once synchronized, the
   LI field is set to one of the other three values and remains at the
   last value set even if the reference source becomes unreachable or
   turns faulty.

   The Version (VN) is copied from the request packet, if responding to
   a unicast request.  For broadcast, this is set to 4.

   The Mode is set to Server (4) if in response to a unicast request.
   For broadcast, this is set to Broadcast (5).

   The Stratum field is set to the server's current stratum, if
   synchronized.  If synchronized to a primary reference source the
   Stratum field is set to 1.  If unsynchronized this field is set to 0.

   The Poll field is coppied from the request, if responding to a
   unicast request.  For broadcast, this is set to the nearest integer
   base-2 logarithm
   log2 of the poll interval.

   The Precision field is set to reflect the maximum reading error of
   the system clock.  For all practical cases it is computed as the
   negative base-2 logarithm of the number of significant bits to the
   right of the decimal point in the NTP timestamp format.  The Root Delay and Root Dispersion fields are set
   to 0 for a primary server; optionally, the Root Dispersion field can
   be set to a value corresponding to the maximum expected error of the radio
   clock itself.

   If the server is synchronized to a reference source, the value of the
   Reference ID is set to a 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 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.  If unsynchronized, it is set to an ASCII
   error identifier.

   The timestamp fields in the server message are set as follows.  If
   the server is unsynchronized or first coming up, all timestamp fields
   are set to zero with one exception.  If the server is synchronized
   and up, synchronized,
   the Transmit Timestamp field of the request is copied unchanged to
   the Originate Timestamp field of the reply.  It is
   important that this field be copied intact, as an NTP or SNTP client
   uses it to avoid bogus messages.

   If the server is synchronized, the Reference Timestamp is set to the
   time the last update was received from the reference source.  The
   Originate Timestamp field is set as in the unsynchronized case above.
   The Transmit Timestamp field are is set to the time of day when the
   message is sent.  In broadcast messages the Receive Timestamp field
   is set to zero and copied from the Transmit Timestamp field in other
   messages.

   The following table

   Table 5 summarizes these actions:

   +----------------+----------------+----------------+----------------+ actions.

   +---------------+-----------+-------------------+-------------------+
   |   Field Name  |  Unicast  |   Unicast Reply   |     Broadcast     |
   |               |  Request  |                   |                   |
   +----------------+----------------+----------------+----------------+
   +---------------+-----------+-------------------+-------------------+
   |       LI      |   ignore  |     as needed     |     as needed     |
   |       VN      |    1-4    |    copied from    |         4         |
   |               |           |      request      |                   |
   |      Mode     |   1 or 3  |       2 or 4      |         5         |
   |    Stratum    |   ignore  |         1         |         1         |
   |      Poll     |   ignore  |    copied from    |     log2 poll     |
   |               |           |      request      |      interval     |
   |   Precision   |   ignore  |    -log2 server   |    -log2 server   |
   |               |           |  significant  |   significant  |
   |                |                | bits |  significant bits |
   |   Root Delay  |   ignore  |         0         |         0         |
   |      Root     |   ignore  |         0         |         0         |
   |   Dispersion  |           |                   |                   |
   |   Reference   |   ignore  |    source ident   |    source ident   |
   |   Identifier  |           |                   |                   |
   |   Reference   |   ignore  | time of last src. | time of last src. |
   |   Timestamp   |           |   src.       update      |   src.       update      |
   |   Originate   |   ignore  |  copied from xmit |         0         |
   |   Timestamp   |           | xmit     timestamp     |                   |
   |    Receive    |   ignore  |    time of day    |         0         |
   |   Timestamp   |           |                   |                   |
   |    Transmit   |    (see text)   |    time of day    |    time of day    |
   |   Timestamp   |   text)   |                   |                   |
   | Authenticator |  optional |      optional     |      optional     |
   +----------------+----------------+----------------+----------------+
   +---------------+-----------+-------------------+-------------------+

               Table 5: NTP Server Message Field Population

      Broadcast servers should respond to client unicast requests, as
      well as send unsolicited broadcast messages.  Broadcast clients
      may send unicast requests in order to measure the network
      propagation delay between the server and client and then continue
      operation in listen-only mode.  However, broadcast servers may
      choose not to respond to unicast requests, so unicast clients
      should be prepared to abandon the measurement and assume a default
      value for the delay delay.

7.  NTP Client Operations

   The role of an NTP client is to determine the current time (and
   associated information) from an NTP server.  This can be done
   actively, by sending a unicast request to a configured server, or
   passively by listening on a known address for periodic server
   messages.

   An NTP client can operate in unicast or broadcast modes.  In unicast
   mode the client sends a request (NTP mode 3) to a designated unicast
   server and expects a reply (NTP mode 4) from that server.  In
   broadcast client mode it sends no request and waits for a broadcast
   (NTP mode 5) from one or more broadcast servers.

      Broadcast clients may send unicast requests in order to measure
      the network propagation delay between the server and client and
      then continue operation in listen-only mode.  However, broadcast
      servers may choose not to respond to unicast requests, so unicast
      clients should be prepared to abandon the measurement and assume a
      default value for the delay.

      Client requests are normally sent at intervals depending on the
      frequency tolerance of the client clock and the required accuracy.
      However, under no conditions should requests be sent at less than
      one minute intervals.  Further discussion on this point is in
      Section 12.

   A unicast client initializes the NTP message header, sends the
   request to the server and strips the time of day from the Transmit
   Timestamp field of the reply.  For this purpose, all of the NTP
   header fields shown in Section 3 are set to 0, except the Mode, VN
   and optional Transmit Timestamp fields.

   NTP and SNTP clients set the mode field to 3 (client) for unicast and
   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
   request also specifies the VN field of the 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 [9], [11], and NTPv1 as defined in [10]. [12].  NTPv0 defined in [11] [13]
   is not supported.

   In unicast mode, the Transmit Timestamp field in the request should SHOULD
   be set to the time of day according to the client clock in NTP
   timestamp format.  This allows a simple calculation to determine for the determination of the
   propagation delay between the server and client and to align the
   system clock generally within a few tens of milliseconds relative to the server.  In addition, this provides a
   simple method to verify that the server reply is in fact a legitimate
   response to the specific client request and avoid replays.  In  Note that
   in broadcast mode, the client has no information to cannot necessarily calculate the
   propagation delay or determine the validity of the server, unless one server.

   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 NTP
   authentication schemes reference source is used.  The following table summarizes the
   required NTP client operations in unicast, anycast and broadcast
   modes.  The recommended error checks are shown in the Reply and
   Broadcast columns in the table.  The message should be considered
   valid only if all the fields shown contain values in the respective
   ranges.  Whether to believe the message if one or more of the fields
   marked "ignore" contain invalid values is at the discretion of the
   implementation.

   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. inoperative.  The most important
   indicator of an unhealthy server is the Stratum field, in which a
   value of 0 indicates an unsynchronized condition.  When this value is
   displayed, clients should discard the server message, regardless of
   the contents of other fields.

   The following table

   Table 6 summarizes the proper setting of these fields:

   +----------------+----------------+----------------+----------------+ required NTP client operations in unicast and
   broadcast modes

   +-------------------+---------------+-------------------+-----------+
   |     Field Name    |    Unicast    |   Unicast Reply   | Broadcast |
   |                   |    Request    |                   |           |
   +----------------+----------------+----------------+----------------+
   +-------------------+---------------+-------------------+-----------+
   |         LI        |       0       |        0-3        |    0-3    |
   |         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  |
   |   Dispersion   |                |                |                |
   |     Reference     |       0       |       ignore      |   ignore  |
   |     Identifier    |               |                   |           |
   |     Reference     |       0       |       ignore      |   ignore  |
   |     Timestamp     |               |                   |           |
   |     Originate     |       0       |     (see text)    |   ignore  |
   |     Timestamp     |               |                   |           |
   | Receive Timestamp |       0       |     (see text)    |   ignore  |
   |    Timestamp   |                |                |                |
   |      Transmit     |   (see text)  |      nonzero      |  nonzero  |
   |     Timestamp     |               |                   |           |
   |   Authenticator   |    optional   |      optional     |  optional |
   +----------------+----------------+----------------+----------------+
   +-------------------+---------------+-------------------+-----------+

               Table 6: NTP Client Message Field Population

8.  NTP Symmetric Peer Operations

   NTP Symmetric Peer mode is intended for configurations where a set of
   low-stratum peers operate as mutual backups for each other.  Each
   peer normally operates with oner one or more sources, such as a reference
   clock, or a subset of primary or secondry servers known to be
   reliable or authentic.

   Symmetric Peer mode is exclusive to the NTP protocol and is
   specifically excluded from SNTP operation.  For the purposes of this
   document, an NTP peer operates like a client.

9.  Dynamic Server Discovery

   NTPv4 Security

   NTPv4 employs the Autokey security protocol, which works
   independently provides a mechanism, commonly known as "Manycast", for each client, 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 and
   the message digest (keyed MD5).  A proventic trail is a sequence of
   NTP servers each synchronized and cryptographically veritifed
   client to dynamically discover the
   next lower stratum server and ending on existance of one or more trusted servers.
   Proventic trails servers
   with no a-priori knowledge.  Once servers are constructed from each discovered, they are
   then treated as any other unicast server.

   A client employing server to discovery is configured with MinServers,
   the trusted minimum number of desired servers at decreasing stratum levels.  When server time and at least
   one proventic trail are verified, the peer is admitted to MaxServers, the
   population and maximum
   number of desired servers.  The discovery mechanism is a simple
   expanding ring search, using IP multicast with increasing TTLs or Hop
   Counts.  The multicast address used MUST be scoped to synchronize the system clock.

9.1  Session Keys and Cookies

   NTPv4 session keys have four 32-bit words, local site,
   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 defined by [14].

   The session key value is client initiates the 16-octet MD5 discovery process by sending an NTP message digest of
   to the
   session key.  Key IDs have pseudo-random values configured multicast address (224.0.1.1 for IPv4 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 address ending :101 for IPv6 with proper scoping.) with an extension field, the
   cookie
   IP TTL or Hop Count of 1.  This message has a public value (zero).  In client/server modes, the cookie
   is a hash all of the addresses and a private value.  In symmetric modes, NTP header
   fields set to 0, except the cookie Mode, VN and optional Transmit Timestamp
   fields.  The Mode is set to 3.  It then starts a random roll.  In the event that both peers generate
   cookies, the agreed-upon cookie is the exclusive-OR of the two
   values. retry timer
   (Default: 64 seconds) and listens for unicast responses from servers.
   The source address of any server generates a cookie unique responses are treated as newly
   configured unicast servers, up to a limit of MaxServers.  If the client and server
   addresses and its own private value.  It returns the cookie,
   signature, and timestampe to
   number of discovered servers is less than MinServers when the client in retry
   timer expires, an extension field.  The
   cookie identical NTP message is transmitted from server to client encrypted by the client
   public key.  The server uses the cookie to validate requests sent with an increased
   TTL/Hop Count, and
   construct replies.  The client uses the cookie retry timer is restarted.  This continues
   until either MinServers servers have been discovered or a configured
   maximum TTL/Hop Count is reached.  If the configured maximum TTL/Hop
   Count is reached, packets continue to validate be periodically sent at the reply
   and checks that
   maximum TTL/Hop Count.  If at some subsequent time, the request key ID matches number of
   valid servers drops below MinServers, the reply key ID.

9.2  Session Key List Generation

   The server rolls a random 32-bit seed as process restarts at the
   initial key ID and
   selects state.

   A server configured to provide server discovery will listen on the cookie.  Messages with a zero cookie contain only public
   values.  The initial session key is constructed using
   specified multicast address for discovery messages from clients.  If
   the given
   addressses, cookie and initial key ID.  The session key value server is
   stored in scope of the key cache.  The next session key current TTL and is constructed using itself synchronized
   to a valid source it replies to the first four octets of discovery message from the session key value client
   with an ordinary unicast server message as the new key ID. described in Section 6

10.  The server continues Kiss-o'-Death Packet

   According to generate the full list.  The final index
   number and last key ID are provided in an extension field with
   signature and timestamp.

9.3  Sending Messages

   The MAC consists of NTPv3 specification [1], if the MD5 message digest of Stratum field in the
   NTP header and
   extension fields using is 1, indicating a primary server, the session key ID and value stored in the key
   cache.  The server uses Reference
   Identifier field contains an ASCII string identifying the session key ID list particular
   reference clock type.  However, in reverse order and
   discards each key value after use.  An extension [1] nothing is said about the
   Reference Identifier field containing if the
   last index number and key ID Stratum field is included in 0, which is called
   out as "unspecified".  However, if the first packet
   transmitted (last on Stratum field is 0, the list).  This extension
   Reference Identifier field can be provided
   upon request at any time.  When all entries in 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 key list ASCII
   messages they convey are used,
   a new one is generated.

9.4  Receiving Messages called kiss codes.  The intent is not KoD packets got
   their name because an early use was to hide the message contents.  Rather, the goal is tell clients to verify its source and stop sending
   packets that it has not been modified in transit. violate server access controls.

   The MAC message digest is compared with the computed digest of the
   NTP header and extension fields using the session key ID kiss codes can provide useful information for an intelligent
   client.  These codes are encoded in the MAC four-character ASCII strings left
   justified and the key value computed from the addresses, key ID zero filled.  The strings are designed for character
   displays and cookie.  If log files.  A list of the cookie currently-defined kiss codes
   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 given in Table 7.

   +------+------------------------------------------------------------+
   | Code |                           Meaning                          |
   +------+------------------------------------------------------------+
   | ACST |         The association belongs 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ unicast server        |     Digest/Signature NID
   |    Client AUTH | Ident                Server authentication failed                | Host
   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Figure 6 Status Word Format

      If the server digest NID and ID scheme agree, the server responds
      with an association response message, sending host name and status
      word. AUTO |                   Autokey sequence failed                  |
   | BCST |        The client, upon agreeing with digest NID and ID scheme,
      then sends association belongs to a certificate request.  The broadcast 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
      signed       |
   | CRYP |    Cryptographic authentication or identification failed   |
   | DENY |               Access denied by the next lower stratum remote server and validated with its
      public key.

      Certificate Exchange (CERT message): This exchange is used               |
   | DROP |                 Lost peer in symmetric mode                |
   | RSTR |              Access denied due to
      obtain and verify certificates on local policy             |
   | INIT |   The association has not yet synchronized for the trail first   |
   |      |                            time                            |
   | MCST | The association belongs to a trusted root
      certificate.  Certificate exchanges follow the same process as
      parameter exchanges.

      Identity Exchange (IFF, GW, and MV messages): This exchange is
      used to verify dynamically discovered server identity using an agreed identity scheme
      (TC, IFF, GQ, MV).  This exchange |
   | NKEY |   No key found.  Either the key was never installed or is a challenge-response scheme.
      The client initiates by sending a challenge request.  |
   |      |                         not trusted                        |
   | RATE |  Rate exceeded.  The server
      then provides the challenge response.

      Values Exchange (COOKIE and AUTO messages): This exchange is used
      to obtain and verify has temporarily denied access  |
   |      |       because the cookie, autokey values, and leapseconds
      table, depending on client exceeded the rate threshold       |
   | RMOT |    Alteration of association mode (client-server,
      broadcast, symmetric).  For cookie exchanges, from a remote host running    |
   |      |                           ntpdc.                           |
   | STEP |     A step change in system time has occurred, but the     |
   |      |           association has not yet resynchronized           |
   +------+------------------------------------------------------------+

                 Table 7: Currently-defined NTP Kiss Codes

   In general, an NTP client sends its
      public key should stop sending to the a particular server without signature when not synchronized.
      Symmetric active peers send its public key and signature to
      passive peer when synchronized.  The
   if that server cookie is encrypted
      from the hash returns a reply with a Stratum field of source/destination addresses, zero key ID, 0, regardless
   of kiss code, and an alternate server private value.  A symmetric passive cookie is a random
      value for every exchange.  The available.  If no alternate
   server private value is refreshed
      and protocol restarted once per day.  For autokey exchanges, available, the
      server generates a key list and signature is calculated to last
      about one hour.  A client sends requests to the server without
      signature when not synchronized.  The server replies with the last
      index number and key ID on SHOULD increase the list.  Broadcast servers uses AUTO
      response for poll interval as
   performance permits.

11.  Security Considerations

   NTPv4 provides an optional authentication field that utilizes the first message after regenerating MD5
   algorithm.  MD5, as the key and
      ASSOC responses case for all other messages.

      Signature Exchange (SIGN message): This exchange requests the
      server to sign and return a client certificate.  The exchange SHA-1, is
      valid only when the client has synchronized to a proventic source
      and the server identity derived from MD4, which
   has long been confirmed.  This exchange is used
      to authenticate clients known to servers, with be weak.  In 2004, techniques for efficiently
   finding collisions in MD5 were announced.  A summary of the server acting weakness
   of MD5 can be found in [15].

   In the case of NTP as de
      facto certificate authority using an encrypted credential scheme.
      The specified herein, there is a vulnerability that
   NTP broadcast clients can be disrupted by misbehaving or hostile SNTP
   or NTP broadcast servers elsewhere in the Internet.  Access controls
   and/or cryptographic authentication means should be provided for
   additional security in such cases.

   While not required in a conforming NTP client sends implementation, there
   are a certificate 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 with implementation errors or without
      signature.  The server extracts malicious attack.
   These recommended checks are as follows:

      When the requested data IP source and signs that
      data with destination addresses are available for the server private key.  The
      client then verifies request, they should match the interchanged addresses in
      the server reply.

      When the
      certificate UDP source and signature.  Subsequently, destination ports are available for the
      client supplies this
      certificate rather than self-signed certificates, so clients can
      verify with request, they should match the interchanged ports in the
      server public key.

10.  Dynamic Server Discovery

   NTPv4 provides a mechanism, commonly known as "Manycast", for a
   client to dynamically discover reply.

      The Originate Timestamp in the existance of one or more servers
   with no a-priori knowledge.  Once servers are discovered, they are
   then treated as any other unicast server. server reply should match the
      Transmit Timestamp used in the client request.

      A client employing server discovery is configured with MinServers, can check the minimum number of desired servers Root Delay and MaxServers, the maximum
   number of desired servers.  The discovery mechanism is a simple
   expanding ring search, using IP multicast with increasing TTLs Root Dispersion fields are
      each greater than or Hop
   Counts.  The multicast address used MUST be scoped equal to 0 and less than infinity, where
      infinity is is on the local site,
   as defined order of 15-20 seconds.  This check avoids
      using a server whose synchronization source has expired for a very
      long time.

12.  IANA Considerations

   UDP/TCP Port 123 was previously assigned by [12]. IANA for this protocol.
   The client initiates IANA has assigned the discovery process by sending an NTP message
   to IPv4 multicast group address 224.0.1.1 and
   the configured IPv6 multicast address with an IP TTL or Hop Count of 1. ending :101 for NTP.

   This message has all document identifies the set of defined 4-character (ASCII)
   Reference Identifier values.  This document also defines the set of
   defined Kiss Codes.  This document also introduces NTP header extension
   fields set allowing for the development of future extensions to 0, except the
   Mode, VN and optional Transmit Timestamp fields.  The Mode
   protocol, where a particular extension is set to
   3.  It then starts a retry timer (Default: 64 seconds) be identified by the
   Field Type sub-field within the extension field.

   IANA is requested to establish and listens maintain a registry for unicast responses Reference
   Identifiers, Kiss codes, and Extension Field Types associated with
   this protocol, populating this registry from servers. the Reference
   Identifiers given in Section 3.9 and Kiss Codes given in Section 11
   as the initial entries.  The source address of any server
   responses Extension Field Types registry will have
   no initial entries.  As future needs arise, new Reference
   Identifiers, Kiss Codes, and Extension Field Types may be defined.
   Following the policies outlined in [16], new values 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. be defined
   by IETF Consensus.

13.  Acknowledgements

   This continues until either MinServers servers have
   been discovered or document has drawn material from RFC 4330, "Simple Network Time
   Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI."  As a configured maximum TTL/Hop Count is reached.  If result, the configured maximum TTL/Hop Count is reached, packets continue
   authors would like to
   be periodically sent at the maximum TTL/Hop Count.  If at some
   subsequent time, the number acknowledge D. Plonka of valid servers drops below MinServers, the process restarts at the initial state.

   A server configured University of
   Wisconsin and J. Montgomery of Netgear, who were contributors.  The
   authors would also like to provide server discovery will listen on the
   specified multicast address thank B. Haberman for discovery messages from clients.  If
   the server is in scope providing rigorous
   reviews of the current TTL this document.

14.  References

14.1.  Normative References

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

14.2.  Informative References

   [2]   Mills, D., "Simple Network Time Protocol (SNTP) Version 4 for
         IPv4, IPv6 and is itself synchronized
   to a valid source it replies to the discovery message from the client
   with an ordinary unicast server message as described in Section 6

11.  NTP Control Messages

   In a comprehensive network-management environment, facilities are
   presumed available to perform routine NTP control OSI", RFC 4330, January 2006.

   [3]   Deering, S. 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 network-management protocol such as SNMP and suitable
   extensions to the MIB database.  However, in those cases where such
   facilities are not available, these functions can 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 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 R. Hinden, "Internet Protocol, Version 6 specified (IPv6)
         Specification", RFC 2460, December 1998.

   [4]   Colella, R., Callon, R., Gardner, E., and Y. Rekhter,
         "Guidelines for OSI NSAP Allocation in the mode field
   of the first octet of the NTP header Internet", RFC 1629,
         May 1994.

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

   [6]   Shue, C., Haggerty, W., and is formatted as shown below.
   The format K. Dobbins, "OSI connectionless
         transport services on top of the data field is specific UDP: Version 1", RFC 1240,
         June 1991.

   [7]   Furniss, P., "Octet Sequences for Upper-Layer OSI to each command or response;
   however, Support
         Basic Communications Applications", RFC 1698, October 1994.

   [8]   Bradner, S., "Key words for use in most cases the format is designed RFCs to be constructed and
   viewed by humans and so is coded in free-form ASCII.  This
   facilitates the Indicate Requirement
         Levels", BCP 14, RFC 2119, March 1997.

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

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

   [11]  Mills, D., "Network Time Protocol (version 2) specification and implementation of simple management
   tools in the absence of fully evolved network-management facilities.
   As in ordinary NTP messages, the authenticator field follows the data
   field.  If the authenticator is used the data field is zero-padded to
   a 32-bit boundary, but the padding bits are not considered part of
   the data field and are not included in the 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 message
   data is numbered starting with zero.  As each fragment is transmitted
   the number of its first octet is inserted in the offset field and the
   number of 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 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 zero.  The responder interprets the opcode
         implementation", STD 12, RFC 1119, September 1989.

   [12]  Mills, D., "Network Time Protocol (version 1) specification and additional
   information in the data field, updates the status field, sets the R
   bit to one
         implementation", RFC 1059, July 1988.

   [13]  Postel, J. 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 status
   field, sets the R and E bits to one and, optionally, inserts a
   diagnostic message in the data field.

   Some commands read or write system variables and peer variables for
   an association identified in the command.  Others read or write
   variables associated with a radio clock or other device directly
   connected to a source of primary synchronization information.  To
   identify which type of variable and association a 16-bit association
   identifier is used.  System variables are indicated by the identifier
   zero.  As each association is mobilized a unique, nonzero identifier
   is created for it.  These identifiers are used in a cyclic fashion,
   so that the chance of using an old identifier which matches a newly
   created association is remote.  A management entity can request a
   list of current identifiers and subsequently use them to read and
   write variables for each association.  An attempt to use an expired
   identifier results in an exception response, following which the list
   can be requested again.

   Some exception events, such as when a peer becomes reachable or
   unreachable, occur spontaneously and are not necessarily associated
   with a command.  An implementation may elect to save the event
   information for later retrieval or to send an asynchronous response
   (called a trap) or both.  In case of a trap the J. Reynolds, "File Transfer Protocol", STD 9,
         RFC 959, October 1985.

   [14]  Meyer, D., "Administratively Scoped IP address and port
   number is determined by a previous command and the sequence field is
   set as described below.  Current status and summary information for
   the latest exception event is returned in all normal responses.  Bits
   in the status field indicate whether an exception has occurred since
   the last response and whether more than one exception has occurred.

   Commands need not necessarily be sent by an NTP peer, so ordinary
   access-control procedures may not apply; however, the optional mask/
   match mechanism suggested elsewhere in this document provides the
   capability to control access by mode number, so this could be used to
   limit access for control messages (mode 6) to selected address
   ranges.

11.1  NTP Control Message Format

   The format of the NTP Control Message header, which immediately
   follows the UDP header, is shown in Figure X. Following is a
   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 a three-bit integer indicating the NTP
   version number, currently four (4)

   Mode: This is a three-bit integer indicating the mode.  It must have
   the value 6, indicating an NTP control message.

   Response Bit (R): Set to zero for commands, one for responses.

   Error Bit (E): Set to zero for normal response, one for error
   response.

   More Bit (M): Set to zero for last fragment, one for all others.

   Operation Code (Op): This is a five-bit integer specifying the
   command function.  Values currently defined include the 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 a 16-bit integer indicating the sequence number of
   the command or response.

   Status: This is a 16-bit code indicating the current status of the
   system, peer or clock, with values coded as described in following
   sections.

   Association ID: This is a 16-bit integer identifying a valid
   association.

   Offset: This is a 16-bit integer indicating the offset, in octets, of
   the first octet in the data area.

   Count: This is a 16-bit integer indicating the length of the data
   field, in octets.

   Data: This contains the message data for the command or response.
   The maximum number of data octets is 468.

   Authenticator (optional): When the NTP authentication mechanism is
   implemented, this contains the authenticator information.

11.2  Status Words

   Status words indicate the present status of the 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 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 status word returned in response to read clock
   variables and write clock variables commands indicates the state of
   the clock hardware and decoding software.  A special error status
   word is used to report malformed command fields or invalid values.

11.2.1  System Status Word

   The system status word appears in the status field of the response to
   a read status or read variables command with a zero association
   identifier.  The format of the system status word is as follows:
     0                                       1
     0   1   2   3   4   5   6   7   8   9   0   1   2   3   4   5
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
   |  LI   |     Clock Source      |     Count     |     Code      |
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
   System Status Word

   Leap Indicator (LI): This is a two-bit code warning of an impending
   leap second to be inserted/deleted in the last minute of the current
   day, with bit 0 and bit 1, respectively, coded as follows:

          +-------+------------------------------------------+
          | 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 six-bit integer indicating the current
   synchronization source, with values coded as follows:

  +-------+---------------------------------------------------------+
  | Value |                         Meaning                         |
  +-------+---------------------------------------------------------+
  |   0   |                  unspecified or 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
   number of system exception events occurring since the last time the
   system status word was returned in a response or included in a trap
   message.  The counter is cleared when returned in the status field of
   a response and freezes when it reaches the value 15.

   System Event Code: This is a four-bit integer identifying the latest
   system exception event, with new values overwriting previous values,
   and coded as 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                |   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
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
   |    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   | authentication enabled (peer.authenable) |
          |   2   |   authentication okay (peer.authentic)   |
          |   3   |      reachability okay (peer.reach)      |
          |   4   |                 reserved                 |
          +-------+------------------------------------------+

   Peer Selection (Sel): This is a three-bit integer indicating the
   status of the peer determined by the 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 number
   of peer exception events that occurred since the last time Multicast", BCP 23,
         RFC 2365, July 1998.

   [15]  Bellovin, S. and E. Rescorla, "Deploying a New Hash Algorithm",
         Proceedings of the peer
   status word was returned in a response or included in a trap message.
   The counter is cleared when returned 13th Annual ISOC Network and Distributed
         System Security Symposium (NDSS) , February 2006.

   [16]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
         Considerations Section in the status field of RFCs", BCP 26, RFC 2434,
         October 1998.

Appendix A.  NTP Control Messages

   In a
   response comprehensive network-management environment, facilities are
   presumed available to perform routine NTP control and freezes when it reaches monitoring
   functions, such as setting the value 15.

   Peer Event Code: This is a four-bit integer identifying leap-indicator bits at the latest
   peer exception event, with new values overwriting previous values, primary
   servers, adjusting the various system parameters and coded monitoring
   regular operations.  Ordinarily, these functions can be implemented
   using a network-management protocol such 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 SNMP and suitable
   extensions to the MIB database.  However, in those cases where such
   facilities are two ways a reference clock not available, these functions can be attached 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 appropriate, such as in dedicated-
   function bus peripherals.  Support for these messages is not required
   in order to a conform to this specification.

   The NTP service
   host, as an dedicated device managed by Control Message has the operating system value 6 specified in the mode field
   of the first octet of the NTP header and is formatted as a
   synthetic peer managed by NTP.  As shown in
   Section 10.1.  The format of the read status command, the
   association identifier data field is used specific to identify which one, zero for each
   command or response; however, in most cases the
   system clock and nonzero for a peer clock.  Only one system clock format is
   supported designed to
   be constructed and viewed by humans and so is coded in free-form
   ASCII.  This facilitates the protocol, although many peer clocks can be
   supported.  A system or peer clock status word appears specification and implementation of
   simple management tools in the status
   field absence of fully evolved network-
   management facilities.  As in ordinary NTP messages, the response
   authenticator field follows the data field.  If the authenticator is
   used the data field is zero-padded to a read clock variables or write clock
   variables command.  This word can be 32-bit boundary, but the
   padding bits are not considered an extension part of the data field and are not
   included in the 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 message
   data is numbered starting with zero.  As each fragment is transmitted
   the number of its first octet is inserted in the
   system status word or offset field and the peer status word as appropriate.  The
   format
   number of the 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 octets is an eight-bit integer indicating inserted in the 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    |
              |   6   |     bad time format or value    |
              | 7-255 |             reserved            |
              +-------+---------------------------------+

   Clock Event Code: This count field.  The more-data (M)
   bit is an eight-bit integer identifying set in all fragments except the latest
   clock exception event, with new values overwriting previous values.
   When last.

   Most control functions involve sending a change to any command and receiving a
   response, perhaps involving several fragments.  The sender chooses a
   distinct, nonzero value occurs in the radio status field, sequence number and sets the radio status field is copied and R and
   E bits to zero.  The responder interprets the clock event code field opcode and a
   system or peer clock exception event is declared as appropriate.

11.2.4  Error Status Word

   An error status word is returned additional
   information in the status field data field, updates the status field, sets the R
   bit to one and returns the three 32-bit words of an error
   response as the result header along
   with additional information in the data field.  In case of invalid
   message format or contents.  Its
   presence is indicated when contents the E (error) bit is set along with responder inserts a code in the
   response (R) bit status
   field, sets the R and E bits to one and, optionally, inserts a
   diagnostic message in the response.  It consists of data field.

   Some commands read or write system variables and peer variables for
   an eight-bit
   integer coded as follows:
     0                                       1
     0   1   2   3   4   5   6   7   8   9   0   1   2   3   4   5
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
   |          Error Code           |           Reserved            |
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
   Error Status Word

              +-------+----------------------------------+
              | Value |              Meaning             |
              +-------+----------------------------------+
              |   0   |            unspecified           |
              |   1   |      authentication failure      |
              |   2   | invalid message length association identified in the command.  Others read or format |
              |   3   |          invalid opcode          |
              |   4   |  unknown write
   variables associated with a radio clock or other device directly
   connected to a source of primary synchronization information.  To
   identify which type of variable and association a 16-bit association
   identifier  |
              |   5   |       unknown variable name      |
              |   6   |      invalid variable value      |
              |   7   |    administratively prohibited   |
              | 8-255 |             reserved             |
              +-------+----------------------------------+

11.3  Commands

   Commands consist of is used.  System variables are indicated by the header and optional data field shown identifier
   zero.  As each association is mobilized a unique, nonzero identifier
   is created for it.  These identifiers are used in
   Figure 6.  When present, a cyclic fashion,
   so that the data field contains chance of using an old identifier which matches a newly
   created association is remote.  A management entity can request a
   list of current identifiers or assignments and subsequently use them to read and
   write variables for each association.  An attempt to use an expired
   identifier results in an exception response, following which the form

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

   where <<identifier>> is the ASCII name of list
   can be requested again.

   Some exception events, such as when a system or peer variable
   specified in Table 2 becomes reachable or Table 3
   unreachable, occur spontaneously and <<value>> is expressed as are not necessarily associated
   with a
   decimal, hexadecimal or string constant in the syntax of the C
   programming language.  Where no ambiguity exists, command.  An implementation may elect to save the <169>sys.<170>
   or <169>peer.<170> prefixes shown in Table 2 event
   information for later retrieval 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 represented as
   four octets in send an asynchronous response
   (called a trap) or both.  In case of a trap the form [n.n.n.n], where n IP address and port
   number is in decimal notation determined by a previous command and the brackets are optional.  Timestamps, including reference,
   originate, receive and transmit values, as well sequence field is
   set as the logical clock,
   are represented in units of seconds and fractions, preferably in
   hexadecimal notation, while delay, offset, dispersion and distance
   values are represented in units of milliseconds described below.  Current status and fractions,
   preferably summary information for
   the latest exception event is returned in decimal notation.All other values are represented
   as-is, preferably all normal responses.  Bits
   in decimal notation.

   Implementations may define variables other the status field indicate whether an exception has occurred since
   the last response and whether more than those listed in Table
   2 or Table 3.  Called extramural variables, these are distinguished one exception has occurred.

   Commands need not necessarily be sent by an NTP peer, so ordinary
   access-control procedures may not apply; however, the inclusion of some character type other than alphanumeric or
   <169>.<170> optional mask/
   match mechanism suggested elsewhere in this document provides the name.  For those commands that return a list
   capability to control access by mode number, so this could be used to
   limit access for control messages (mode 6) to selected address
   ranges.

A.1.  NTP Control Message Format

   The format of
   assignments in the response data field, if NTP Control Message header, which immediately
   follows the command data field UDP header, is
   empty, it shown in Figure 7.  Following is a
   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)                |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure 7: NTP Control Message Format

   Version Number (VN): This is expected that all available variables defined in Table 3
   or Table 4 of a three-bit integer indicating the NTP specification will be included in the response.
   For
   version number, currently four (4)

   Mode: This is a three-bit integer indicating the read commands, if mode.  It must have
   the command data field is nonempty, value 6, indicating an
   implementation may choose NTP control message.

   Response Bit (R): Set to process this field zero for commands, one for responses.

   Error Bit (E): Set to individually
   select which variables are zero for normal response, one for error
   response.

   More Bit (M): Set to be returned.

   Commands are interpreted as follows:

   Read Status (1): The command data field zero for last fragment, one for all others.

   Operation Code (Op): This is empty or contains a list
   of identifiers separated by commas.  The five-bit integer specifying the
   command operates function.  Values currently defined are given in two ways
   depending on Table 8.

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

                Table 8: Currently-defined Operation Codes

   Sequence: This is a 16-bit integer indicating the value sequence number of
   the association identifier.  If this
   identifier command or response.

   Status: This is nonzero, the response includes a 16-bit code indicating the peer identifier and current status word.  Optionally, of the response data field may contain other
   information, such
   system, peer or clock, with values coded as described in the Read Variables command.  If the
   association identifier following
   sections.

   Association ID: This is zero, the response includes the system
   identifier (0) and status word, while the data field contains a list
   of binary-coded pairs
   <<association identifier>> <<status word>>,

   one for each currently defined 16-bit integer identifying a valid
   association.

   Read Variables (2): The command data field

   Offset: This is empty or contains a
   list of identifiers separated by commas.  If the association
   identifier is nonzero, 16-bit integer indicating the response includes offset, in octets, of
   the requested peer
   identifier and status word, while first octet in the data field contains area.

   Count: This is a list of
   peer variables and values as described above.  If 16-bit integer indicating the association
   identifier is zero, length of the data field
   field, in octets.

   Data: This contains a list of system
   variables and values.  If a peer has been selected as the
   synchronization source, message data for the response includes command or response.
   The maximum number of data octets is 468.

   Authenticator (optional): When the peer identifier and
   status word; otherwise, NTP authentication mechanism is
   implemented, this contains the response includes authenticator information.

A.2.  Status Words

   Status words indicate the system identifier
   (0) and present status word.

   Write Variables (3): The command data field contains a list of
   assignments as described above.  The variables the system, associations
   and clock.  They are updated as
   indicated.  The response is as designed to be interpreted by network-monitoring
   programs and are in one of four 16-bit formats described in this
   section.  System and peer status words are associated with responses
   for all commands except the Read Variables
   command.

   Read Clock Variables (4): The command data field is empty or contains
   a list of identifiers separated by commas. read clock variables, write clock
   variables and set trap address/port commands.  The association
   identifier selects zero specifies the system status word, while a nonzero
   identifier specifies a particular peer association.  The status word
   returned in response to read clock variables or peer and write clock
   variables
   in the same way as in commands indicates the Read Variables command.  The response
   includes state of the requested clock identifier hardware and
   decoding software.  A special error status word and is used to report
   malformed command fields or invalid values.

A.2.1.  System Status Word

   The system status word appears in the data status field contains a list of clock variables and values, including the
   last timecode message received from the clock.

   Write Clock Variables (5): The command data field contains response to
   a list of
   assignments as described above.  The clock read status or read variables are updated as
   indicated.  The response is as described for the Read Clock Variables
   command.

   Set Trap Address/Port (6): The command with a zero association identifier, status
   and data fields are ignored.
   identifier.  The address and port number for
   subsequent trap messages are taken from the source address and port format of the control message itself.  The initial trap counter for trap
   response messages system status word is given in
   Figure 8.
     0                                       1
     0   1   2   3   4   5   6   7   8   9   0   1   2   3   4   5
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
   |  LI   |     Clock Source      |     Count     |     Code      |
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

   Figure 8: System Status Word Format

   Leap Indicator (LI): This is taken from a two-bit code warning of an impending
   leap second to be inserted/deleted in the sequence field last minute of the command.
   The response association identifier, status current
   day, with bit 0 and data fields are not
   significant.  Implementations should include sanity timeouts which
   prevent trap transmissions if the monitoring program does bit 1, respectively, coded as shown in Table 9.

           +-------+------------------------------------------+
           | Value |                  Meaning                 |
           +-------+------------------------------------------+
           |   00  |                no warning                |
           |   01  |        last minute has 61 seconds        |
           |   10  |        last minute has 59 seconds        |
           |   11  | alarm condition (clock not renew
   this information after a lengthy interval.

   Trap Response (7): synchronized) |
           +-------+------------------------------------------+

                       Table 9: Leap Indicator Field

   Clock Source: This message is sent when a system, peer six-bit integer indicating the current
   synchronization source, with values coded as shown in Table 10.

    +-------+---------------------------------------------------------+
    | Value |                         Meaning                         |
    +-------+---------------------------------------------------------+
    |   0   |                  unspecified or unknown                 |
    |   1   |         Calibrated atomic clock
   exception event occurs.  The opcode field is (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 and the R bit is set.
   The trap counter   |                         UDP/TIME                        |
    |   8   |                        wall time                        |
    |   9   |               telephone modem (e.g.  NIST)              |
    | 10-31 |                         reserved                        |
    |   32  |                        PPS signal                       |
    | 33-63 |                         reserved                        |
    +-------+---------------------------------------------------------+

                    Table 10: Clock Source Field Values

   System Event Counter: This is incremented by one for each trap sent and a four-bit integer indicating the
   sequence field set to that value.  The trap message is sent using
   number of system exception events occurring since the
   IP address and port fields established by last time the set trap address/port
   command.  If a
   system status word was returned in a response or included in a trap the association identifier field
   message.  The counter is set to
   zero and cleared when returned in the status field contains the system status word.  If of
   a peer
   trap response and freezes when it reaches the association identifier field value 15.

   System Event Code: This is set to that peer and a four-bit integer identifying the latest
   system exception event, with new values overwriting previous values,
   and coded as shown in Table 11.

   +-------+-----------------------------------------------------------+
   | Value |                          Meaning                          |
   +-------+-----------------------------------------------------------+
   |   0   |                        unspecified                        |
   |   1   |                       system restart                      |
   |   2   |                  system or hardware fault                 |
   |   3   |    system new status field contains the 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                |
   |   7   |   system clock exception (see system clock status word)   |
   |  8-15 |                          reserved                         |
   +-------+-----------------------------------------------------------+

                    Table 11: System Event Code Values

A.2.2.  Peer Status Word

   A peer status word.  Optional ASCII-coded
   information can be included word is returned in the data field.

12.  The Kiss-o'-Death Packet

   In the interest status field of self-preservation, it is important that NTP
   servers have a mechanism response to supress a
   read status, read variables or otherwise influence write variables command and appears
   also in the amount list of queries performed association identifiers and status words returned
   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 read status command with a zero association identifier.  The
   format of a peer status word is called
   out as "unspecified".  However, if the Stratum field shown in Figure 9.
     0                                       1
     0   1   2   3   4   5   6   7   8   9   0   1   2   3   4   5
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
   |    Peer Status    |    Sel    |     Count     |     Code      |
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
   Peer Status Word

   Figure 9: Peer Status Word Format

   Peer Status: This is 0, a five-bit code indicating 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
   peer determined by the currently-defined kiss codes
   is packet procedure, with bits assigned as shown
   in the following table.

   +---------------------------------+---------------------------------+ Table 12.

           +-------+------------------------------------------+
           |               Code Value |                  Meaning                 |
   +---------------------------------+---------------------------------+
           +-------+------------------------------------------+
           |               ACST   0   |  The association belongs to an         configured (peer.config)         |
           |   1   |          anycast server authentication enabled (peer.authenable) |
           |               AUTH   2   |   Server   authentication failed okay (peer.authentic)   |
           |               AUTO   3   |     Autokey sequence failed      reachability okay (peer.reach)      |
           |               BCST   4   |                 reserved                 |
           +-------+------------------------------------------+

                       Table 12: Peer Status Values

   Peer Selection (Sel): This is a three-bit integer indicating the
   status of the peer determined by the clock-selection procedure, with
   values coded as shown in Table 13.

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

                   Table 13: Peer Selection Field Values

   Peer Event Counter: This is a four-bit integer indicating the number
   of peer exception events that occurred since the last time the peer
   status word was returned in a response or included in a trap message.
   The association belongs to counter is cleared when returned in the status field of a
   response and freezes when it reaches the value 15.

   Peer Event Code: This is a four-bit integer identifying the latest
   peer exception event, with new values overwriting previous values,
   and coded as shown in Table 14.

   +-------+-----------------------------------------------------------+
   | Value |                          Meaning                          |
   +-------+-----------------------------------------------------------+
   |   0   |                        unspecified                        |
   |         broadcast server   1   |                       peer IP error                       |               CRYP
   | Cryptographic   2   |  peer authentication or failure (peer.authentic bit was one  |
   |       |      identification failed                         now zero)                         |
   |               DENY   3   |  Access denied by remote server     peer unreachable (peer.reach was nonzero now zero)    |
   |               DROP   4   |   Lost      peer in symmetric mode reachable (peer.reach was zero now nonzero)     |
   |               RSTR   5   |    Access denied due to local     peer clock exception (see peer clock status word)     |
   |  6-15 |              policy                          reserved                         |
   +-------+-----------------------------------------------------------+

                        Table 14: Peer Event Codes

A.2.3.  Clock Status Word

   There are two ways a reference clock can be attached to a NTP service
   host, as an dedicated device managed by the operating system and as a
   synthetic peer managed by NTP.  As in the read status command, the
   association identifier is used to identify which one, zero for the
   system clock and nonzero for a peer clock.  Only one system clock is
   supported by the protocol, although many peer clocks can be
   supported.  A system or peer clock status word appears in the status
   field of the response to a read clock variables or write clock
   variables command.  This word can be considered an extension of the
   system status word or the peer status word as appropriate.  The
   format of the clock status word is shown in Figure 10.
     0                                       1
     0   1   2   3   4   5   6   7   8   9   0   1   2   3   4   5
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
   |               INIT          Clock Status         |   The association has not yet            Code               |
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

   Figure 10: Clock Status Word Format

   Clock Status: This is an eight-bit integer indicating the current
   clock status, with values coded as shown in Table 15.

                  +-------+----------------------------+
                  | Value | synchronized for the first time           Meaning          |
                  +-------+----------------------------+
                  |               MCST   0   |   The association belongs to a  clock nominally operating |
                  |   1   |  dynamically discovered server        reply timeout       |
                  |               NKEY   2   |   No key found. Either the key      bad reply format      |
                  |   3   |  was never installed hardware or is not software fault |
                  |   4   |             trusted     propagation failure    |
                  |               RATE   5   |  Rate exceeded. The server has  bad date format or value  |
                  |   6   |    temporarily denied access  bad time format or value  |
                  | 7-255 | because          reserved          |
                  +-------+----------------------------+

                       Table 15: Clock Status Values

   Clock Event Code: This is an eight-bit integer identifying the client exceeded latest
   clock exception event, with new values overwriting previous values.
   When a change to any nonzero value occurs in the radio status field,
   the radio status field is copied to the clock event code field and a
   system or peer clock exception event is declared as appropriate.

A.2.4.  Error Status Word

   An error status word is returned in the status field of an error
   response as the result of invalid message format or contents.  Its
   presence is indicated when the E (error) bit is set along with the
   response (R) bit in the response.  It consists of an eight-bit
   integer coded as shown in Figure 11.

     0                                       1
     0   1   2   3   4   5   6   7   8   9   0   1   2   3   4   5
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
   |          Error Code           |           Reserved            |          rate threshold
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

   Figure 11: Error Status Word Format

   Currently-defined error codes are given in Table 16.

               +-------+----------------------------------+
               | Value |               RMOT              Meaning             |  Somebody is tinkering with the
               +-------+----------------------------------+
               |   0   |            unspecified           |  association from a remote host
               |   1   |      authentication failure      |   running ntpdc. Not to worry
               |   2   | invalid message length or format |
               |   3   |  unless some rascal has stolen          invalid opcode          |
               |   4   |            your keys  unknown association identifier  |
               |               STEP   5   |   A step change in system time       unknown variable name      |
               |   6   |      has occurred, but the      invalid variable value      |
               |   7   |     association has not yet    administratively prohibited   |
               | 8-255 |          resynchronized             reserved             |
   +---------------------------------+---------------------------------+

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

      When the IP source and destination addresses are available for the
      client request, they should match the interchanged addresses in
      the server reply.

      When the UDP source and destination ports are available for the
      client request, they should match the interchanged ports in the
      server reply.

      The Originate Timestamp in the server reply should match the
      Transmit Timestamp used in
               +-------+----------------------------------+

                        Table 16: Error Code Values

A.3.  Commands

   Commands consist of the client request.

      The server reply should be discarded if any header and optional data field of the LI, Stratum, or
      Transmit Timestamp fields are 0 or Status
   Word.  When present, the Mode data field is not 4
      (unicast) contains a list of identifiers or 5 (broadcast).

      A truly paranoid client can check
   assignments in the Root Delay and Root
      Dispersion fields are each greater than or equal to 0 and less
      than infinity, form

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

   where infinity <<identifier>> is currently a cozy number like 16
      seconds.  This check avoids using a server whose synchronization
      source has expired for a very long time.

14.  IANA Considerations

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 ASCII name 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.

      A client MUST NOT use a poll interval less than TBD minutes.

      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.

      A client SHOULD use local servers whenever available to avoid
      unnecessary traffic on backbone networks.

      A client MUST allow the operator to configure the primary and/or
      alternate server names or addresses in addition to system or peer variable
   specified in place of
      a firmware default IP address.

      If a firmware default server IP address is provided, it MUST be a
      server operated by the manufacturer Table 2 or seller Table 3 of [1] and <<value>> is expressed as
   a decimal, hexadecimal or string constant in the device or
      another server, but only with the operator's permission.

      A client SHOULD use the Domain Name System (DNS) to resolve syntax of the
      server IP addresses, so C
   programming language.  Where no ambiguity exists, the operator <169>sys.<170>
   or <169>peer.<170> prefixes shown in Table 2 or Table 4 of [1] can do effective load
      balancing among a server clique and change IP address binding be
   suppressed.  Whitespace (ASCII nonprinting format effectors) can be
   added to
      canonical names.

      A client SHOULD re-resolve the server IP address on a periodic
      intervals, but improve readability for simple monitoring programs that do
   not less than reformat the time-to-live field data field.  Internet addresses are represented as
   four octets in the DNS
      response.

      A client SHOULD support the NTP access-refusal mechanism, so that
      a server kiss-o'-death reply form [n.n.n.n], where n is in response to a client request
      causes the client to cease sending requests to that server decimal notation and to
      switch to an alternate, if available.

   If
   the firmware or documentation includes specific server names, brackets are optional.  Timestamps, including reference,
   originate, receive and transmit values, as well as the
   names should be logical clock,
   are represented in units of seconds and 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 the manufacturer or seller operates as a
   customer convenience listed in Table
   2 or those for which specific permission has been
   obtained from Table 3 of [1].  Called extramural variables, these are
   distinguished by the operator.  A DNS request for a generic server name
   such as ntp.mytimeserver.com results should result in a random
   selection inclusion of server IP addresses available for some character type other than
   alphanumeric or <169>.<170> in the name.  For those commands that purpose.  Each
   time a DNS request is received,
   return a new randomized list is returned.
   The client ordinarily uses of assignments in the first address on response data field, if the list.

      When selecting candidate SNTP or NTP servers,
   command data field is empty, it is imperative to
      respect the server operator's conditions of access.  Lists of
      public servers and their conditions of access are expected that all available at
      www.ntp.org.  A semi-automatic server discovery scheme using DNS
   variables defined in Table 3 or Table 4 of [1] will be included in
   the response.  For the read commands, if the command data field is described at that site.  Some ISPs operate public servers,
      although finding them via their helpdesks can
   nonempty, an implementation may choose to process this field to
   individually select which variables are to be difficult.

   A well behaved client operates returned.

   Commands are interpreted as follows (note that steps 2 - 4
   comprise follows:

   Read Status (1): The command data field is empty or contains a synchronization loop):

      Consider the specified frequency tolerance list
   of identifiers separated by commas.  The command operates in two ways
   depending on the system clock
      oscillator.  Define the required accuracy value of the system clock,
      then calculate association identifier.  If this
   identifier is nonzero, the maximum timeout.  For instance, if response includes the
      frequency tolerance is 200 parts-per-million (PPM) peer identifier and
   status word.  Optionally, the
      required accuracy is one minute, response data field may contain other
   information, such as described in the maximum timeout Read Variables command.  If the
   association identifier is about 3.5
      days.  Use zero, the longest maximum timeout possible given response includes the system
      constraints to minimize time server aggregate load, but never less
      than 15 minutes.

      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
   identifier (0) and status word, while the same time power data field contains a list
   of binary-coded pairs

   <<association identifier>> <<status word>>,

   one for each currently defined association.

   Read Variables (2): The command data field is restored after empty or contains a blackout.
      Assume at this time
   list of identifiers separated by commas.  If the IP address association
   identifier is unknown and nonzero, the system clock
      is unsynchronized.  Otherwise use response includes the timeout value as calculated
      in previous loop steps.  Note that it may be necessary to refrain
      from implementing requested peer
   identifier and status word, while the aforementioned random delay for some classes data field contains a list of ICSA certification.

      When
   peer variables and values as described above.  If the timer reaches association
   identifier is zero, if the IP address is not known, send
      a DNS query packet; otherwise send data field contains a NTP request packet to that
      address. list of system
   variables and values.  If no reply packet a peer has been heard since selected as the last
      timeout, double
   synchronization source, the timeout, but not greater than response includes the maximum
      timeout.  If primary peer identifier and secondary time servers have been
      configured, alternate queries between
   status word; otherwise, the primary and secondary
      servers when no successful response has been received.

      If a DNS reply packet is received, save includes the IP address system identifier
   (0) and
      continue in step 2.  If status word.

   Write Variables (3): The command data field contains a KoD packet list of
   assignments as described above.  The variables are updated as
   indicated.  The response is received remove that time
      server from the list, activate as described for the secondary time server and
      continue in step 2.  If Read Variables
   command.

   Read Clock Variables (4): The command data field is empty or contains
   a received packet fails list of identifiers separated by commas.  The association
   identifier selects the sanity checks,
      drop that packet and also continue in step 2.  If a valid NTP
      packet is received, update system clock variables or peer clock variables
   in the system clock, set same way as in the timeout to Read Variables command.  The response
   includes the maximum, requested clock identifier and status word and continue to step 2.

16.  Acknowledgements

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

17.  References

17.1  Normative References

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

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

17.2  Informative References

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

   [4]   Shue, C., Haggerty, W., clock variables and K. Dobbins, "OSI connectionless
         transport services on top values, including the
   last timecode message received from the clock.

   Write Clock Variables (5): The command data field contains a list of UDP: Version 1", RFC 1240,
         June 1991.

   [5]   Furniss, P., "Octet Sequences
   assignments as described above.  The clock variables are updated as
   indicated.  The response is as described for Upper-Layer OSI to Support
         Basic Communications Applications", RFC 1698, October 1994.

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

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

   [8]   Deering, S. the Read Clock Variables
   command.

   Set Trap Address/Port (6): The command association identifier, status
   and R. Hinden, "Internet Protocol, Version 6 (IPv6)
         Specification", RFC 2460, December 1998.

   [9]   Mills, D., "Network Time Protocol (version 2) specification data fields are ignored.  The address and
         implementation", STD 12, RFC 1119, September 1989.

   [10]  Mills, D., "Network Time Protocol (version 1) specification port number for
   subsequent trap messages are taken from the source address and
         implementation", RFC 1059, July 1988.

   [11]  Postel, J. port
   of the control message itself.  The initial trap counter for trap
   response messages is taken from the sequence field of the command.
   The response association identifier, status and J. Reynolds, "File Transfer Protocol", STD 9,
         RFC 959, October 1985.

   [12]  Meyer, D., "Administratively Scoped IP Multicast", BCP 23,
         RFC 2365, July 1998.

   [13]  Cain, B., Deering, S., Kouvelas, I., Fenner, B., data fields are not
   significant.  Implementations should include sanity timeouts which
   prevent trap transmissions if the monitoring program does not renew
   this information after 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 A.
         Thyagarajan, "Internet Group Management Protocol, Version 3",
         RFC 3376, October 2002.

   [14]  Deering, S., "Host extensions the R bit is set.
   The trap counter is incremented by one for each trap sent and the
   sequence field set to that value.  The trap message is sent using the
   IP multicasting", STD 5,
         RFC 1112, August 1989. 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 status field contains the system status word.  If a peer
   trap the association identifier field is set to that peer and the
   status field contains the peer status word.  Optional ASCII-coded
   information can be included in the data field.

Authors' Addresses

   Jack Burbank (editor)
   The Johns Hopkins University Applied Physics Lab Laboratory
   11100 Johns Hopkins Road
   Laurel, MD  20723-6099
   US

   Phone: +1 443 778 7127
   Email: jack.burbank@jhuapl.edu

   Jim Martin (editor)
   Netzwert AG
   An den Treptowers 1
   Berlin  12435
   Germany

   Phone: +49.30/5 900 80-1180
   Email: jim@netzwert.ag

   Dr. David L. Mills
   University of Delaware
   Newark, DE  19716
   US

   Phone: +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). (2006).  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.