<?xml version="1.0" encoding="US-ASCII"?> encoding="UTF-8"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?> [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" category="historic"
consensus="true" docName="draft-ietf-ntp-mode-6-cmds-11" ipr="pre5378Trust200902"> number="9327" ipr="pre5378Trust200902" obsoletes="" updates="" xml:lang="en" tocInclude="true"
tocDepth="3" symRefs="true" sortRefs="true" version="3">

  <!-- xml2rfc v2v3 conversion 3.15.0 -->
  <front>
    <title abbrev="NTP Control Messages">Control Messages Protocol for Use
    with Network Time Protocol Version 4</title>
    <seriesInfo name="RFC" value="9327"/>
    <author fullname="Brian Haberman" initials="B." surname="Haberman" role="editor">
      <organization>JHU</organization>
      <address>
        <email>brian@innovationslab.net</email>
      </address>
    </author>
    <date month="February" year="2022" /> month="October" year="2022"/>
    <area>int</area>
    <workgroup>ntp</workgroup>

    <abstract>
      <t>This document describes the structure of the control messages that were
      historically used
      with the Network Time Protocol (NTP) before the advent of more modern control and
      management approaches. These control messages have been used to
      monitor and control the Network Time Protocol NTP application running on any
      IP network attached computer. The information in this document
      was originally described in Appendix B of RFC 1305. The goal of this document
      is to provide an updated description of the control messages described in RFC
      1305 in order to conform with the updated Network Time Protocol NTP specification
      documented in RFC 5905.</t>
      <t>The publication of this document is not meant to encourage the development
      and deployment of these control messages. This document is only providing a
      current reference for these control messages given the current status of RFC
      1305.</t>
    </abstract>
  </front>
  <middle>
    <section title="Introduction">
      <t>RFC 1305 <xref numbered="true" toc="default">

      <name>Introduction</name>
      <t><xref target="RFC1305" /> described format="default"/> describes a set of control messages
      for use within the Network Time Protocol (NTP) when a comprehensive network
      management solution was not available. The definitions of these control messages
      were not promulgated to RFC 5905 <xref target="RFC5905" /> format="default"/> when NTP version
      4 was documented.  These messages were intended for use only in
      systems where no other management facilities were available or
      appropriate, such as in dedicated-function bus peripherals. Support for
      these messages is not required in order to conform to RFC 5905
      <xref target="RFC5905" />. format="default"/>. The control messages are described here as a
      current reference for use with an RFC 5905 implementation of NTP.</t> NTP from RFC 5905.</t>
      <t>The publication of this document is not meant to encourage the development
      and deployment of these control messages. This document is only providing a
      current reference for these control messages given the current status of RFC
      1305.</t>
      <section title="Control numbered="true" toc="default">

	<name>Terminology</name>
	<t>
    The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>",
    "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and
    "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described in
    BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and
    only when, they appear in all capitals, as shown here.
        </t>
      </section>
      <section numbered="true" toc="default">
        <name>Control Message Overview"> Overview</name>
        <t>The NTP Mode mode 6 control messages are used by NTP management programs
	(e.g., ntpq) when a more robust network management facility (e.g., SNMP)
	is not available. These control messages provide rudimentary control and
	monitoring functions to manage a running instance of an NTP server. These
	commands are not designed to be used for communication between instances
	of running NTP servers.</t>
        <t>The NTP Control Message control message has the value 6 specified in the mode field
        of the first octet of the NTP header and is formatted as shown in
        <xref target="M6Hdr" />. format="default"/>.
        The format of the data field is specific to each command or response;
        however, in most cases cases, the format is designed to be constructed and
        viewed by humans and so is coded in free-form ASCII. This facilitates
        the 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 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.</t>

        <t>IP hosts are not required to reassemble datagrams over a certain size
	(576 octets for IPv4 <xref target="RFC0791" /> format="default"/> and 1280 octets for
	IPv6 <xref target="RFC2460" />); target="RFC8200" format="default"/>); 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 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.</t>
        <t>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 field, "R" bit, and "E"
        bits
        bit to zero. The responder interprets the opcode and additional
        information in the data field, updates the status field, sets the "R" bit
        to one and returns the three 32-bit words of the header along with
        additional information in the data field. In the case of invalid message
        format or contents 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.</t>
        <t>Some commands read or write system variables (e.g., s.offset) and peer
        variables (e.g., p.stratum) 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 association, the Association ID 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 that 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.</t>
        <t>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 retrieval, to send an asynchronous response (called a trap) trap), or
        both. In case of a trap trap, the IP address and port number is are 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.</t>
        <t>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 in Section <xref target="Security" />
	elsewhere in this document format="default"/>
	 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.</t>
      </section>
      <section title="Remote numbered="true" toc="default">
        <name>Remote Facility Message Overview"> Overview</name>
        <t>The original development of the NTP daemon included a remote facility Remote Facility
        for monitoring and configuration. This facility used mode 7 commands
        to communicate with the NTP daemon. This document illustrates the mode
        7 packet format only. The commands embedded in the mode 7 messages are
        implementation specific and not standardized in any way. The mode 7 message
        format is described in <xref target="mode7" />.</t> format="default"/>.</t>
      </section>
    </section>
    <section title="NTP numbered="true" toc="default">
      <name>NTP Control Message Format"> Format</name>
      <t>The format of the NTP Control Message header, which immediately
      follows the UDP header, is shown in <xref target="M6Hdr" />. format="default"/>. Following the figure is a description
      of its header fields.</t>
      <figure anchor="M6Hdr" title="NTP anchor="M6Hdr">
        <name>NTP Control Message Header"> Header</name>
        <artwork align="center"><![CDATA[ align="center" name="" type="" alt=""><![CDATA[
 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 |R|E|M| OpCode opcode  |       Sequence Number         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            Status             |       Association ID          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            Offset             |            Count              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
/                    Data (up to 468 bytes)                     /
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Padding (optional)                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
/              Authenticator (optional, 20 or 24 bits)          /
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        ]]></artwork>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
      </figure>

      <t>Leap

<dl newline="true" spacing="normal">
      <dt>Leap Indicator (LI): This (LI):</dt><dd>This is a two-bit 2-bit integer that is set to
      b00 for control message requests and responses. The Leap Indicator
      value used at this position in most NTP modes is in the System Status
      Word system status
      word provided in some control message responses.</t>

      <t>Version responses.</dd>
      <dt>Version Number (VN): This (VN):</dt><dd>This is a three-bit 3-bit integer indicating a minimum
      NTP version number. NTP servers do not respond to control messages with
      an unrecognized version number. Requests may intentionally use a lower
      version number to enable interoperability with earlier versions of NTP.
      Responses carry the same version as the corresponding request.</t>

      <t>Mode: This request.</dd>
      <dt>Mode:</dt><dd>This is a three-bit 3-bit integer indicating the mode.
      The value 6 indicates an NTP control message.</t>

      <t>Response message.</dd>
      <dt>Response Bit (R): Set (R):</dt><dd>Set to zero for commands, commands; set to one for responses.</t>

      <t>Error responses.</dd>
      <dt>Error Bit (E): Set (E):</dt><dd>Set to zero for normal response, responses; set to one for an error
      response.</t>

      <t>More
      response.</dd>
      <dt>More Bit (M): Set (M):</dt><dd>Set to zero for the last fragment, fragment; set to one for all others.</t>

      <t>Operation others.</dd>
      <dt>Operation Code (OpCode): This (opcode):</dt><dd>This is a five-bit 5-bit integer specifying the
      command function. Values currently defined include the following:</t>

      <t><figure>
          <artwork align="center" name="Operation Codes"><![CDATA[
+-------+--------------------------------------------------+
|  Code |                     Meaning                      |
+-------+--------------------------------------------------+
|   0   | reserved                                         |
|   1   | read status command/response                     |
|   2   | read following:</dd>

</dl>
<table anchor="opcodes">
  <name>Operation Codes</name>
  <thead>
    <tr>
      <th>Code</th>
      <th>Meaning</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>0</td>
      <td>reserved</td>
    </tr>
    <tr>
      <td>1</td>
      <td>read status command/response</td>
    </tr>
    <tr>
      <td>2</td>
      <td>read variables command/response                  |
|   3   | write command/response</td>
    </tr>
    <tr>
      <td>3</td>
      <td>write variables command/response                 |
|   4   | read command/response</td>
    </tr>
    <tr>
      <td>4</td>
      <td>read clock variables command/response            |
|   5   | write command/response</td>
    </tr>
    <tr>
      <td>5</td>
      <td>write clock variables command/response           |
|   6   | set command/response</td>
    </tr>
    <tr>
      <td>6</td>
      <td>set trap address/port command/response           |
|   7   | trap response                                    |
|   8   | runtime command/response</td>
    </tr>
    <tr>
      <td>7</td>
      <td>trap response</td>
    </tr>
    <tr>
      <td>8</td>
      <td>runtime configuration command/response           |
|   9   | export command/response</td>
    </tr>
    <tr>
      <td>9</td>
      <td>export configuration to file command/response    |
|  10   | retrieve command/response</td>
    </tr>
    <tr>
      <td>10</td>
      <td>retrieve remote address stats command/response   |
|  11   | retrieve command/response</td>
    </tr>
    <tr>
      <td>11</td>
      <td>retrieve ordered list command/response           |
|  12   | request command/response</td>
    </tr>
    <tr>
      <td>12</td>
      <td>request client-specific nonce command/response   |
| 13-30 | reserved                                         |
|  31   | unset command/response</td>
    </tr>
    <tr>
      <td>13-30</td>
      <td>reserved</td>
    </tr>
    <tr>
      <td>31</td>
      <td>unset trap address/port command/response         |
+-------+--------------------------------------------------+
           ]]></artwork>
        </figure></t>

      <t>Sequence Number: This command/response</td>
    </tr>
  </tbody>
</table>
<dl newline="true" spacing="normal">
      <dt>Sequence Number:</dt><dd>This is a 16-bit integer indicating the sequence number of
      the command or response. Each request uses a different sequence number. Each
      response carries the same sequence number as its corresponding request. For
      asynchronous trap responses, the responder increments the sequence number by
      one for each response, allowing trap receivers to detect missing trap responses.
      The sequence number of each fragment of a multiple-datagram response carries the
      same sequence number, copied from the request.</t>

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

      <t>Association ID: This
      sections.</dd>
      <dt>Association ID:</dt><dd>This is a 16-bit unsigned integer identifying a valid
      association,
      association or zero for the system clock.</t>

      <t>Offset: This clock.</dd>
      <dt>Offset:</dt><dd>This is a 16-bit unsigned integer indicating the offset, in octets, of
      the first octet in the data area. The offset is set to zero in requests. Responses
      spanning multiple datagrams use a positive offset in all but the first datagram.</t>

      <t>Count: This datagram.</dd>
      <dt>Count:</dt><dd>This is a 16-bit unsigned integer indicating the length of the data
      field, in octets.</t>

      <t>Data: This octets.</dd>
      <dt>Data:</dt><dd>This contains the message data for the command or response. The
      maximum number of data octets is 468.</t>

      <t>Padding (optional): Contains 468.</dd>
      <dt>Padding (optional):</dt><dd>Contains zero to three 3 octets with a value of zero, as needed to
      ensure the overall control message size is a multiple of 4 octets.</t>

      <t>Authenticator (optional): When octets.</dd>
      <dt>Authenticator (optional):</dt><dd>When the NTP authentication mechanism is
      implemented, this contains the authenticator information defined in
	      Appendix C of
      <xref target="RFC1305" />.</t> sectionFormat="of" section="Appendix C"/>.</dd>
</dl>
  </section>
    <section title="Status Words "> numbered="true" toc="default">
      <name>Status Words</name>
      <t>Status words indicate the present status of the system, associations associations,
      and clock. They are designed to be interpreted by network-monitoring
      programs and are in one of four 16-bit formats shown in <xref target="M6SW" /> format="default"/>
      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 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.</t>
      <figure anchor="M6SW" title="Status anchor="M6SW">
        <name>Status Word Formats"> Formats</name>
        <artwork align="center"><![CDATA[ align="center" name="" type="" alt=""><![CDATA[
 0                   1
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LI| Clock Src | Count | Code  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       System Status Word

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Status | SEL | Count | Code  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        Peer Status Word

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Clock Status  |    Code       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        Radio Status Word

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Error Code  |   Reserved    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        Error Status Word

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Reserved    | Count | Code  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        Clock Status Word

        ]]></artwork> Word]]></artwork>
      </figure>
      <section title="System numbered="true" toc="default">
        <name>System Status Word "> Word</name>
        <t>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:</t>

        <t>Leap
<dl newline="true" spacing="normal">
	<dt>Leap Indicator (LI): This (LI):</dt><dd>This is a two-bit 2-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:</t>

        <t><figure>
            <artwork align="center" name="Leap Indicator"><![CDATA[
+------+------------------------------------------------------------+
|  LI  |                       Meaning                              |
+------+------------------------------------------------------------+
|  00  | no warning                                                 |
|  01  | insert follows:</dd>
	</dl>
<table anchor="LeapIndicator">
  <name>Leap Indicator Codes</name>
  <thead>
    <tr>
      <th>LI</th>
      <th>Meaning</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>00</td>
      <td>no warning</td>
    </tr>
    <tr>
      <td>01</td>
      <td>insert second after 23:59:59 of the current day            |
|  10  | delete day</td>
    </tr>
    <tr>
      <td>10</td>
      <td>delete second 23:59:59 of the current day                  |
|  11  | unsynchronized                                             |
+------+------------------------------------------------------------+
             ]]></artwork>
          </figure></t>

        <t>Clock day</td>
    </tr>
    <tr>
      <td>11</td>
      <td>unsynchronized</td>
    </tr>
  </tbody>
</table>
<dl newline="true" spacing="normal">
        <dt>Clock Source (Clock Src): This Src):</dt><dd>This is a six-bit 6-bit integer
        indicating the current synchronization source, with values coded as follows:</t>

        <t><figure>
            <artwork align="center" name="Clock Source"><![CDATA[
+-------+-----------------------------------------------------------+
|  Code |                     Meaning                               |
+-------+-----------------------------------------------------------+
|   0   | unspecified or unknown                                    |
|   1   | Calibrated
        follows:</dd>
</dl>
<table anchor="ClockSource">
  <name>Clock Source Values</name>
  <thead>
    <tr>
      <th>Code</th>
      <th>Meaning</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>0</td>
      <td>unspecified or unknown</td>
    </tr>
    <tr>
      <td>1</td>
      <td>Calibrated atomic clock (e.g., PPS, HP 5061)              |
|   2   | VLF 5061)</td>
    </tr>
    <tr>
      <td>2</td>
      <td>VLF (band 4) or LF (band 5) radio (e.g., OMEGA,, WWVB)    |
|   3   | HF WWVB)</td>
    </tr>
    <tr>
      <td>3</td>
      <td>HF (band 7) radio (e.g., CHU, MSF, WWV/H)                 |
|   4   | UHF WWV/H)</td>
    </tr>
    <tr>
      <td>4</td>
      <td>UHF (band 9) satellite (e.g., GOES, GPS)                  |
|   5   | local GPS)</td>
    </tr>
    <tr>
      <td>5</td>
      <td>local net (e.g., DCN, TSP, DTS)                           |
|   6   | UDP/NTP                                                   |
|   7   | UDP/TIME                                                  |
|   8   | eyeball-and-wristwatch                                    |
|   9   | telephone DTS)</td>
    </tr>
    <tr>
      <td>6</td>
      <td>UDP/NTP</td>
    </tr>
    <tr>
      <td>7</td>
      <td>UDP/TIME</td>
    </tr>
    <tr>
      <td>8</td>
      <td>eyeball-and-wristwatch</td>
    </tr>
    <tr>
      <td>9</td>
      <td>telephone modem (e.g., NIST)                              |
| 10-63 | reserved                                                  |
+-------+-----------------------------------------------------------+
             ]]></artwork>
          </figure></t>

        <t>System NIST)</td>
    </tr>
    <tr>
      <td>10-63</td>
      <td>reserved</td>
    </tr>
  </tbody>
</table>
<dl newline="true" spacing="normal">
        <dt>System Event Counter (Count): This (Count):</dt><dd>This is a four-bit 4-bit integer indicating the
        number of system events occurring since the last time the
        System Event Code changed. Upon reaching 15, subsequent events with the same
        code are not counted.</t>

        <t> System counted.</dd>
        <dt>System Event Code (Code): This (Code):</dt><dd>This is a four-bit 4-bit integer identifying the
        latest system exception event, with new values overwriting previous
        values, and coded as follows:</t>

        <t><figure>
            <artwork align="center" name="System follows:</dd>
</dl>
<table anchor="SystemEventCode">
  <name>System Event Code"><![CDATA[
+------+---------------------------------------------------------+
| Code |                         Meaning                         |
+------+---------------------------------------------------------+
|   0  | unspecified                                             |
|   1  | frequency Codes</name>
  <thead>
    <tr>
      <th>Code</th>
      <th>Meaning</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>0</td>
      <td>unspecified</td>
    </tr>
    <tr>
      <td>1</td>
      <td>frequency correction (drift) file not available         |
|   2  | frequency available</td>
    </tr>
    <tr>
      <td>2</td>
      <td>frequency correction started (frequency stepped)        |
|   3  | spike stepped)</td>
    </tr>
    <tr>
      <td>3</td>
      <td>spike detected and ignored, starting stepout timer      |
|   4  | frequency timer</td>
    </tr>
    <tr>
      <td>4</td>
      <td>frequency training started                              |
|   5  | clock synchronized                                      |
|   6  | system restart                                          |
|   7  | panic started</td>
    </tr>
    <tr>
      <td>5</td>
      <td>clock synchronized</td>
    </tr>
    <tr>
      <td>6</td>
      <td>system restart</td>
    </tr>
    <tr>
      <td>7</td>
      <td>panic stop (required step greater than panic threshold) |
|   8  | no threshold)</td>
    </tr>
    <tr>
      <td>8</td>
      <td>no system peer                                          |
|   9  | leap peer</td>
    </tr>
    <tr>
      <td>9</td>
      <td>leap second insertion/deletion armed for the            |
|      | of the current month                                    |
|  10  | leap month</td>
    </tr>
    <tr>
      <td>10</td>
      <td>leap second disarmed                                    |
|  11  | leap disarmed</td>
    </tr>
    <tr>
      <td>11</td>
      <td>leap second inserted or deleted                         |
|  12  | clock deleted</td>
    </tr>
    <tr>
      <td>12</td>
      <td>clock stepped (stepout timer expired)                   |
|  13  | kernel expired)</td>
    </tr>
    <tr>
      <td>13</td>
      <td>kernel loop discipline status changed                   |
|  14  | leapseconds changed</td>
    </tr>
    <tr>
      <td>14</td>
      <td>leapseconds table loaded from file                      |
|  15  | leapseconds file</td>
    </tr>
    <tr>
      <td>15</td>
      <td>leapseconds table outdated, updated file needed         |
+------+---------------------------------------------------------+
             ]]></artwork>
          </figure></t> needed</td>
    </tr>
  </tbody>
</table>
      </section>
      <section title="Peer numbered="true" toc="default">
        <name>Peer Status Word"> Word</name>
        <t>A peer status word is returned in the status field of a response to
        a read status, read variables variables, or write variables command and appears
        also
        in the list of association identifiers Association IDs and status words returned
        by a read status command with a zero association identifier. Association ID. The
        format of a peer status word is as follows:</t>

        <t>Peer
<dl newline="true" spacing="normal">
        <dt>Peer Status (Status): This (Status):</dt><dd>This is a five-bit 5-bit code indicating
        the status of the peer determined by the packet procedure, with bits
        assigned as
        follows:</t>

        <t><figure>
            <artwork align="center" name="Peer Status"><![CDATA[
+-------------+---------------------------------------------------+
| Peer follows:</dd>
</dl>
<table anchor="PeerStatus">
  <name>Peer Status |                      Meaning                      |
|     bit     |                                                   |
+-------------+---------------------------------------------------+
|      0      | configured (peer.config)                          |
|      1      | authentication Bits</name>
  <thead>
    <tr>
      <th>Peer Status bit</th>
      <th>Meaning</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>0</td>
      <td>configured (peer.config)</td>
    </tr>
    <tr>
      <td>1</td>
      <td>authentication enabled (peer.authenable)          |
|      2      | authentication (peer.authenable)</td>
    </tr>
    <tr>
      <td>2</td>
      <td>authentication okay (peer.authentic)              |
|      3      | reachability (peer.authentic)</td>
    </tr>
    <tr>
      <td>3</td>
      <td>reachability okay (peer.reach != 0)               |
|      4      | broadcast association                             |
+-------------+---------------------------------------------------+
             ]]></artwork>
          </figure></t>

        <t>Peer 0)</td>
    </tr>
    <tr>
      <td>4</td>
      <td>broadcast association</td>
    </tr>
  </tbody>
</table>
<dl newline="true" spacing="normal">
        <dt>Peer Selection (SEL): This (SEL):</dt><dd>This is a three-bit 3-bit integer indicating the
        status of the peer determined by the clock-selection procedure, with
        values coded as follows:</t>

        <t><figure>
            <artwork align="center" name="Peer Selection"><![CDATA[
+-----+-------------------------------------------------------------+
| Sel |                        Meaning                              |
+-----+-------------------------------------------------------------+
|  0  | rejected                                                    |
|  1  | discarded follows:</dd>
</dl>
<table anchor="PeerSelection">
  <name>Peer Selection Values</name>
  <thead>
    <tr>
      <th>Sel</th>
      <th>Meaning</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>0</td>
      <td>rejected</td>
    </tr>
    <tr>
      <td>1</td>
      <td>discarded by intersection algorithm                         |
|  2  | discarded algorithm</td>
    </tr>
    <tr>
      <td>2</td>
      <td>discarded by table overflow (not currently used)            |
|  3  | discarded used)</td>
    </tr>
    <tr>
      <td>3</td>
      <td>discarded by the cluster algorithm                          |
|  4  | included algorithm</td>
    </tr>
    <tr>
      <td>4</td>
      <td>included by the combine algorithm                           |
|  5  | backup algorithm</td>
    </tr>
    <tr>
      <td>5</td>
      <td>backup source (with more than sys.maxclock survivors)       |
|  6  | system survivors)</td>
    </tr>
    <tr>
      <td>6</td>
      <td>system peer (synchronization source)                        |
|  7  | PPS source)</td>
    </tr>
    <tr>
      <td>7</td>
      <td>PPS (pulse per second) peer                                 |
+-----+-------------------------------------------------------------+
             ]]></artwork>
          </figure></t>

        <t>Peer peer</td>
    </tr>
  </tbody>
</table>
<dl newline="true" spacing="normal">
        <dt>Peer Event Counter (Count): This (Count):</dt><dd>This is a four-bit 4-bit integer indicating the
        number of peer exception events that occurred since the last time the
        peer event code changed. Upon reaching 15, subsequent events with the same
        code are not counted.</t>

        <t>Peer counted.</dd>
        <dt>Peer Event Code (Code): This (Code):</dt><dd>This is a four-bit 4-bit integer identifying the
        latest peer exception event, with new values overwriting previous values,
        and coded as follows:</t>

        <t><figure>
            <artwork align="center" name="Peer Event Code"><![CDATA[
+-------+--------------------------------------------------------+
| Peer  |                                                        |
| follows:</dd>
</dl>
<table anchor="PeerEventCode">
  <name>Peer Event |                            Meaning                     |
| Code  |                                                        |
+-------+--------------------------------------------------------+
|   0   | unspecified                                            |
|   1   | association mobilized                                  |
|   2   | association demobilized                                |
|   3   | peer Values</name>
  <thead>
    <tr>
      <th>Peer Event Code</th>
      <th>Meaning</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>0</td>
      <td>unspecified</td>
    </tr>
    <tr>
      <td>1</td>
      <td>association mobilized</td>
    </tr>
   <tr>
      <td>2</td>
      <td>association demobilized</td>
    </tr>
    <tr>
      <td>3</td>
      <td>peer unreachable (peer.reach was nonzero now zero)     |
|   4   | peer zero)</td>
    </tr>
    <tr>
      <td>4</td>
      <td>peer reachable (peer.reach was zero now nonzero)       |
|   5   | association nonzero)</td>
    </tr>
    <tr>
      <td>5</td>
      <td>association restarted or timed out                     |
|   6   | no out</td>
    </tr>
    <tr>
      <td>6</td>
      <td>no reply (only used with one-shot clock set command)   |
|   7   | peer command)</td>
    </tr>
    <tr>
      <td>7</td>
      <td>peer rate limit exceeded (kiss code RATE received)     |
|   8   | access received)</td>
    </tr>
    <tr>
      <td>8</td>
      <td>access denied (kiss code DENY received)                |
|   9   | leap received)</td>
    </tr>
    <tr>
      <td>9</td>
      <td>leap second insertion/deletion at month's end armed    |
|       | by peer vote                                           |
|  10   | became vote</td>
    </tr>
    <tr>
      <td>10</td>
      <td>became system peer (sys.peer)                          |
|  11   | reference (sys.peer)</td>
    </tr>
    <tr>
      <td>11</td>
      <td>reference clock event (see clock status word)          |
|  12   | authentication failed                                  |
|  13   | popcorn word)</td>
    </tr>
    <tr>
      <td>12</td>
      <td>authentication failed</td>
    </tr>
    <tr>
      <td>13</td>
      <td>popcorn spike suppressed by peer clock filter register |
|  14   | entering register</td>
    </tr>
    <tr>
      <td>14</td>
      <td>entering interleaved mode                              |
|  15   | recovered mode</td>
    </tr>
    <tr>
      <td>15</td>
      <td>recovered from interleave error                        |
+-------+--------------------------------------------------------+
             ]]></artwork>
          </figure></t> error</td>
    </tr>
  </tbody>
</table>
      </section>
      <section title="Clock numbered="true" toc="default">
        <name>Clock Status Word "> Word</name>
        <t>There are two ways a reference clock can be attached to a an NTP
        service host, host: as a dedicated device managed by the operating system
        and as a synthetic peer managed by NTP.  As in the read status command, the association identifier Association ID is used to
identify which one, the correct variable for each clock: 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 to be an extension of the system status word or
        the peer status word as appropriate. The format of the clock status
        word is as follows:</t>

        <t>Reserved: An eight-bit
<dl newline="true" spacing="normal">
        <dt>Reserved:</dt><dd>This is an 8-bit integer that is ignored by requesters and
        zeroed by responders.</t>

        <t>Count: This responders.</dd>
        <dt>Count:</dt><dd>This is a four-bit 4-bit integer indicating the number of clock
        events that occurred since the last time the clock event code changed.
        Upon reaching 15, subsequent events with the same code are not counted.</t>

        <t>Clock counted.</dd>
        <dt>Clock Code (Code): This (Code):</dt><dd>This is a four-bit 4-bit integer indicating the current
        clock status, with values coded as follows:</t>

        <t><figure>
            <artwork align="center" name="Clock Status"><![CDATA[
+--------------+--------------------------------------------------+
| Clock Status |                      Meaning                     |
+--------------+--------------------------------------------------+
|       0      | clock follows:</dd>
</dl>
<table anchor="ClockStatus">
  <name>Clock Code Values</name>
  <thead>
    <tr>
      <th>Clock Status</th>
      <th>Meaning</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>0</td>
      <td>clock operating within nominals                  |
|       1      | reply timeout                                    |
|       2      | bad nominals</td>
    </tr>
    <tr>
      <td>1</td>
      <td>reply timeout</td>
    </tr>
    <tr>
      <td>2</td>
      <td>bad reply format                                 |
|       3      | hardware format</td>
    </tr>
    <tr>
      <td>3</td>
      <td>hardware or software fault                       |
|       4      | propagation failure                              |
|       5      | bad fault</td>
    </tr>
    <tr>
      <td>4</td>
      <td>propagation failure</td>
    </tr>
    <tr>
      <td>5</td>
      <td>bad date format or value                         |
|       6      | bad value</td>
    </tr>
    <tr>
      <td>6</td>
      <td>bad time format or value                         |
|      7-15    | reserved                                         |
+--------------+--------------------------------------------------+
             ]]></artwork>
          </figure></t> value</td>
    </tr>
    <tr>
      <td>7-15</td>
      <td>reserved</td>
    </tr>
  </tbody>
</table>
      </section>
      <section title="Error numbered="true" toc="default">
        <name>Error Status Word"> Word</name>
        <t>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 8-bit integer
        coded as follows:</t>

        <t><figure>
            <artwork align="center" name="Error Status"><![CDATA[
+--------------+--------------------------------------------------+
| Error
<table anchor="ErrorStatus">
  <name>Error Status |                    Meaning                       |
+--------------+--------------------------------------------------+
|       0      | unspecified                                      |
|       1      | authentication failure                           |
|       2      | invalid Word Codes</name>
  <thead>
    <tr>
      <th>Error Status</th>
      <th>Meaning</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>0</td>
      <td>unspecified</td>
    </tr>
    <tr>
      <td>1</td>
      <td>authentication failure</td>
    </tr>
    <tr>
      <td>2</td>
      <td>invalid message length or format                 |
|       3      | invalid opcode                                   |
|       4      | unknown association identifier                   |
|       5      | unknown format</td>
    </tr>
    <tr>
      <td>3</td>
      <td>invalid opcode</td>
    </tr>
    <tr>
      <td>4</td>
      <td>unknown Association ID</td>
    </tr>
    <tr>
      <td>5</td>
      <td>unknown variable name                            |
|       6      | invalid name</td>
    </tr>
    <tr>
      <td>6</td>
      <td>invalid variable value                           |
|       7      | administratively prohibited                      |
|     8-255    | reserved                                         |
+--------------+--------------------------------------------------+
             ]]></artwork>
          </figure></t> value</td>
    </tr>
    <tr>
      <td>7</td>
      <td>administratively prohibited</td>
    </tr>
    <tr>
      <td>8-255</td>
      <td>reserved</td>
    </tr>
  </tbody>
</table>
      </section>
    </section>
    <section title="Commands"> anchor="commands" numbered="true" toc="default">
      <name>Commands</name>
      <t>Commands consist of the header and optional data field shown in
      <xref target="M6Hdr" />. format="default"/>. When present, the data field contains a list of
      identifiers or assignments in the form
      &lt;&lt;identifier&gt;&gt;[=&lt;&lt;value&gt;&gt;],&lt;&lt;identifier&gt;&gt;[=&lt;&lt;value&gt;&gt;],...
      where &lt;&lt;identifier&gt;&gt; is the ASCII name of a system or peer
      variable such as the ones specified in RFC 5905 and
      &lt;&lt;value&gt;&gt; is expressed as a decimal, hexadecimal hexadecimal, or string
      constant in the syntax of the C programming language. Where no ambiguity
      exists, the "sys." or "peer." prefixes can be suppressed.
      Whitespace
      Space characters (ASCII nonprinting format effectors) can be added to improve
      readability for simple monitoring programs that do not reformat the data
      field. Internet addresses  Representations of note are represented as follows: follows:</t>
<ul><li>
      IPv4 internet addresses
      are written in the form [n.n.n.n], where n is in decimal notation and
      the brackets are optional; IPv6 optional</li>
      <li>IPv6 internet addresses are formulated based on the
      guidelines defined in <xref target="RFC5952" />.
      Timestamps, including format="default"/>.</li>
      <li>Timestamps (including reference, originate, receive receive, and transmit values,
      as well as values)
      and the logical clock, clock are represented in units of seconds and
      fractions, preferably in hexadecimal notation. Delay, notation.</li>
      <li>Delay, offset,
      dispersion
      dispersion, and distance values are represented in units of milliseconds
      and fractions, preferably in decimal notation. All notation.</li>
      <li>All other values are
      represented as-is, as is, preferably in decimal notation.</t> notation.</li>
</ul>
      <t>Implementations may define variables other than those described in
      RFC 5905. Called extramural variables, 5905; called "extramural variables", these are
      distinguished by the inclusion of some character type other than
      alphanumeric or "." in the name. For those commands
      that return a list of assignments in the response data field, if the
      command data field is empty, it is expected that all available variables
      defined in RFC 5905 will be included in the
      response. For the read commands, if the command data field is nonempty,
      an implementation may choose to process this field to individually
      select which variables are to be returned.</t>
      <t>Commands are interpreted as follows:</t>

      <t>Read
<dl newline="true" spacing="normal">
      <dt>Read Status (1): The (1):</dt><dd>The command data field is empty or contains a list
      of identifiers separated by commas. The command operates in two ways
      depending on the value of the association identifier. Association ID. If this identifier
      is nonzero, the response includes the peer identifier and status word.
      Optionally, the response data field may contain other information, such
      as described in the Read Variables command. If the association
      identifier is zero, the response includes the system identifier (0) and
      status word, while word; the data field contains a list of binary-coded pairs
      &lt;&lt;association identifier&gt;&gt;
      &lt;&lt;Association ID&gt;&gt; &lt;&lt;status word&gt;&gt;, one
      for each currently defined association.</t>

      <t>Read association.</dd>
      <dt>Read Variables (2): The (2):</dt><dd>The command data field is empty or contains a
      list of identifiers separated by commas. If the association identifier Association ID
      is nonzero, the response includes the requested peer identifier and
      status word, while word; the data field contains a list of peer variables and
      values as described above. If the association identifier Association ID is zero, the
      data field contains a list of system variables. If a peer has
      been selected as the synchronization source, the response includes the
      peer identifier and status word; otherwise, the response includes the
      system identifier (0) and status word.</t>

      <t>Write word.</dd>
      <dt>Write Variables (3): The (3):</dt><dd>The command data field contains a list of
      assignments as described above. The variables are updated as indicated.
      The response is as described for the Read Variables command.</t>

      <t>Read command.</dd>
      <dt>Read Clock Variables (4): The (4):</dt><dd>The command data field is empty or contains
      a list of identifiers separated by commas. The association identifier Association ID
      selects the system clock variables or peer clock variables in the same
      way as in the Read Variables command. The response includes the
      requested clock identifier and status word and word; the data field contains a
      list of clock variables and values, including the last timecode message
      received from the clock.</t>

      <t>Write clock.</dd>
      <dt>Write Clock Variables (5): The (5):</dt><dd>The command data field contains a list of
      assignments as described above. The clock variables are updated as
      indicated. The response is as described for the Read Clock Variables
      command.</t>

      <t>Set read clock variables
      command.</dd>
      <dt>Set Trap Address/Port (6): The (6):</dt><dd>The command association identifier, status Association ID, status,
      and data fields are ignored. The address and port number for subsequent
      trap messages are taken from the source address and 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 status, and data fields are not significant. Implementations
      should include sanity logical timeouts which that prevent trap transmissions if the
      monitoring program does not renew this information after a lengthy
      interval.</t>

      <t>Trap
      interval.</dd>
      <dt>Trap Response (7): This (7):</dt><dd>This message is sent when a system, peer peer, or clock
      exception event occurs. The opcode field is 7 and 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 address
      and port fields established by the set trap address/port command. If a
      system trap trap, the association identifier Association ID field is set to zero and the
      status field contains the system status word. If a peer trap trap, the
      association identifier
      Association ID 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.</t>

      <t>Configure (8): The field.</dd>
      <dt>Configure (8):</dt><dd>The command data is parsed and applied as if supplied
	      in the daemon configuration file.</t>

      <t>Save file.</dd>
      <dt>Save Configuration (9): Write (9):</dt><dd>Writes a snapshot of the current configuration
      to the file name supplied as the command data.
      Further, the command is refused unless a directory in which to store
      the resulting files has been explicitly configured by the operator.</t>

      <t>Read operator.</dd>
      <dt>Read Most Recently Used (MRU) list (10): Retrieves (10):</dt><dd>Retrieves records
      of recently seen remote addresses and associated statistics.  This
      command supports all of the state variables defined in Section 9 of <xref
      target="RFC5905" />. sectionFormat="of" section="9"/>.  Command data
      consists of name=value pairs controlling the selection of records, as
      well as a requestor-specific nonce previously retrieved using this
      command or opcode 12, Request
      Nonce. 12 (Request Nonce).  The response consists of
      name=value pairs where some names can appear multiple times using a dot
      followed by a zero-based index to distinguish them, them and to associate
      elements of the same record with the same index.  A new nonce is
      provided with each successful
      response.</t>

      <t>Read response.</dd>
      <dt>Read ordered list (11): Retrieves (11):</dt><dd>Retrieves a list ordered by IP address
      (IPv4 information precedes IPv6 information).  If the command
      data is empty or is the seven characters "ifstats", the associated
      statistics, status status, and counters for each local address are returned.
      If the command data is the characters "addr_restrictions" "addr_restrictions", then the
      set of IPv4 remote address restrictions followed by the set of IPv6
      remote address restrictions (access control lists) are returned.
      Other command data returns error code 5 (unknown variable name).
      Similar to Read MRU, response information uses zero-based indexes as
      part of the variable name preceding the equals sign and value, where
      each index relates information for a single address or network.  This
      opcode requires authentication.</t>

      <t>Request authentication.</dd>
      <dt>Request Nonce (12): Retrieves (12):</dt><dd>Retrieves a 96-bit nonce specific to the
      requesting remote address, which is valid for a limited period.
      Command data is not used in the request.  The nonce consists of a
      64-bit NTP timestamp and 32 bits of hash derived from that timestamp,
      the remote address, and salt known only to the server server, which varies
      between daemon runs. Inclusion of the
      nonce by a management agent demonstrates to the server that the agent
      can receive datagrams sent to the source address of the request,
      making source address "spoofing" more difficult in a similar way as
      TCP's three-way handshake.</t>

      <t>Unset handshake.</dd>
      <dt>Unset Trap (31): Removes (31):</dt><dd>Removes the requesting remote address and port from
      the list of trap receivers.  Command data is not used in the request.
      If the address and port are not in the list of trap receivers, the
      error code is 4, bad association.</t> 4 (bad association).</dd>
    </dl>
    </section>
    <section anchor="IANA" title="IANA Considerations"> numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>This document makes has no request of IANA.</t>

      <t>Note to RFC Editor: this section may be removed on publication as an
      RFC.</t> IANA actions.</t>

    </section>
    <section anchor="Security" title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>A number of security vulnerabilities have been identified with
      these control messages.</t>
      <t>NTP's control query interface allows reading and writing of system,
      peer, and clock variables remotely from arbitrary IP addresses using
      commands mentioned in Section 4. Traditionally, overwriting <xref target="commands"/>.  Overwriting these
      variables, but not reading them, requires authentication by default.
      However, this document argues that an NTP host must authenticate all
      control queries and not just ones that overwrite these variables.
      Alternatively, the host can use an access control list to explicitly list IP
      addresses that are allowed to control query the clients. These access
      controls are required for the following reasons:<list style="symbols">

         <t>NTP reasons:</t>

     <dl newline="true" spacing="normal">
        <dt>NTP as a Distributed Denial-of-Service (DDoS) vector. NTP vector:</dt><dd>NTP timing query
         and response packets (modes 1-2, 3-4, and 5) are usually short in size. However,
         some NTP control queries generate a very long packet in response to a
         short query. As such, there is a history of use of NTP's control queries,
         which exhibit such behavior, to perform DDoS DoS attacks. These off-path attacks
         exploit the large size of NTP control queries to cause UDP-based
         amplification attacks (e.g., mode 7 monlist command generates a very long
         packet in response to a small query <xref target="CVE-DOS" />). format="default"/>). These attacks only
         use NTP as a vector for DoS attacks on other protocols, but do not affect
         the time service on the NTP host itself. To limit the sources of these
         malicious commands, NTP server operators are recommended to deploy ingress
         filtering <xref target="RFC3704" />.</t>

         <t>Time-shifting format="default"/>.</dd>
        <dt>Time-shifting attacks through information leakage/overwriting. NTP leakage/overwriting:</dt><dd>NTP hosts
         save important system and peer state variables. An off-path attacker who can
         read these variables remotely can leverage the information leaked by these
         control queries to perform time-shifting and DoS DDoS attacks on NTP clients. These
         attacks do affect time synchronization on the NTP hosts.  For instance,<list style="symbols">

            <t>In instance:</dd>
</dl>
          <ul spacing="normal">
            <li>In the client/server mode, the client stores its local time when it sends the
            query to the server in its xmt peer variable. This variable is used to perform
            TEST2 to non-cryptographically authenticate the server, i.e., server (i.e., if the origin
            timestamp field in the corresponding server response packet matches the xmt peer
            variable, then the client accepts the packet. packet). An off-path attacker, attacker with the ability
            to read this variable can easily spoof server response packets for the client, which
            will pass TEST2, TEST2 and can deny service or shift time on the NTP client. The specific
            attack is described in <xref target="CVE-SPOOF" />.</t>

            <t>The format="default"/>.</li>
<li>The client also stores its local time when the server response is received in its
            rec peer variable. This variable is used for authentication in interleaved-pivot mode.
            An off-path attacker with the ability to read this state variable can easily shift time
            on the client by passing this test. This attack is described in <xref target="CVE-SHIFT" />.</t>
         </list></t>

         <t>Fast-Scanning. NTP format="default"/>.</li>
          </ul>
<dl newline="true" spacing="normal">
        <dt>Fast-Scanning:</dt><dd>NTP mode 6 control messages are usually small UDP packets. Fast-scanning
         tools like ZMap can be used to spray the entire (potentially reachable) Internet with these
         messages within hours to identify vulnerable hosts. To make things worse, these attacks can
         be extremely low-rate, only requiring a control query for reconnaissance and a spoofed
         response to shift time on vulnerable clients.</t>

         <t>The clients.</dd>
        <dt>The mode 6 and 7 messages are vulnerable to replay attacks <xref target="CVE-Replay" />. format="default"/>:</dt><dd>
         If an attacker observes mode 6/7 packets that modify the configuration of the server in any
         way, the attacker can apply the same change at any time later simply by simply sending the packets
         to the server again. The use of the nonce (Request Nonce command) provides limited protection
         against replay attacks.</t>

      </list></t> attacks.</dd>
      </dl>
      <t>NTP best practices recommend configuring NTP with the no-query parameter. The no-query
      parameter blocks access to all remote control queries. However, sometimes the hosts do not
      want to block all queries and want to give access for certain control queries remotely. This
      could be for the purpose of remote management and configuration of the hosts in certain
      scenarios. Such hosts tend to use firewalls or other middleboxes to blacklist certain queries
      within the network.</t>
      <t>Significantly fewer hosts respond to mode 7
      monlist queries as compared to other control queries because it is a well-known and exploited
      control query. These queries are likely blocked using blacklists on firewalls and middleboxes
      rather than the no-query option on NTP hosts. The remaining control queries that can be
      exploited likely remain out of the blacklist because they are undocumented in the current
      NTP specification <xref target="RFC5905" />.</t> format="default"/>.</t>
      <t>This document describes all of the mode 6 control queries allowed by NTP and can help
      administrators make informed decisions on security measures to protect NTP devices from
      harmful queries and likely make those systems less vulnerable. The use of the legacy mode 6
      interface is NOT RECOMMENDED.Regardless <bcp14>NOT RECOMMENDED</bcp14>.  Regardless of which mode
      6 commands an administrator may elect to allow, remote access to this facility needs to be
      protected from unauthorized access (e.g., strict ACLs). Access Control Lists (ACLs)). Additionally, the legacy interface
      for mode 6 commands SHOULD NOT <bcp14>SHOULD NOT</bcp14> be utilized in new deployments or implementation of NTP.</t>
    </section>

    <section title="Contributors">
      <t>Dr. David Mills specified the vast majority of the mode 6 commands during the development
      of RFC 1305 <xref target="RFC1305" /> and deserves the credit for their existence and use.</t>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>Tim Plunkett created the original version of this document. Aanchal
      Malhotra provided the initial version of the Security Considerations section.</t>
      <t>Karen O'Donoghue, David Hart, Harlan Stenn, and Philip Chimento deserve credit
      for portions of this document due to their earlier efforts to document these commands.</t>
      <t>Miroshav Lichvar, Ulrich Windl, Dieter Sibold, J Ignacio Alvarez-Hamelin, and Alex Campbell
      provided valuable comments on various versions of this document.</t>
    </section>
  </middle>
  <back>

    <references title="Normative References">
      <?rfc include="reference.RFC.1305"?>
      <?rfc include="reference.RFC.5905"?>
      <?rfc include="reference.RFC.5952"?>
      <?rfc include="reference.RFC.3704"?>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1305.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5905.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5952.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3704.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
      </references>

    <references title="Informative References">
      <?rfc include="reference.RFC.0791"?>
      <?rfc include="reference.RFC.2460"?>
      <references>

        <name>Informative References</name>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.0791.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8200.xml"/>

<reference anchor="CVE-SHIFT"> anchor="CVE-SHIFT" target="https://nvd.nist.gov/vuln/detail/CVE-2016-1548">
          <front>
            <title>CVE-2016-1548, https://nvd.nist.gov/vuln/detail/CVE-2016-1548</title>
            <title>CVE-2016-1548 Detail</title>
            <author>
              <organization>NIST National Vulnerability Database</organization>
            </author>
            <date month="January" year="2017" day="06" /> day="06"/>
          </front>
        </reference>

        <reference anchor="CVE-SPOOF"> anchor="CVE-SPOOF" target="https://nvd.nist.gov/vuln/detail/CVE-2015-8139">
          <front>
            <title>CVE-2015-8139, https://nvd.nist.gov/vuln/detail/CVE-2015-8139</title>
            <title>CVE-2015-8139 Detail</title>
            <author>
              <organization>NIST National Vulnerability Database</organization>
            </author>
            <date month="January" year="2017" day="30" /> day="30"/>
          </front>
        </reference>

        <reference anchor="CVE-Replay"> anchor="CVE-Replay" target="https://nvd.nist.gov/vuln/detail/CVE-2015-8140">
          <front>
            <title>CVE-2015-8140, https://nvd.nist.gov/vuln/detail/CVE-2015-8140</title>
            <title>CVE-2015-8140 Detail</title>
            <author>
              <organization>NIST National Vulnerability Database</organization>
            </author>
            <date month="January" year="2015" day="30" /> day="30"/>
          </front>
        </reference>

        <reference anchor="CVE-DOS"> anchor="CVE-DOS" target="https://nvd.nist.gov/vuln/detail/CVE-2013-5211">
          <front>
            <title>CVE-2013-5211, https://nvd.nist.gov/vuln/detail/CVE-2013-5211</title>
            <title>CVE-2013-5211 Detail</title>
            <author>
              <organization>NIST National Vulnerability Database</organization>
            </author>
            <date month="January" year="2014" day="02" /> day="02"/>
          </front>
        </reference>
      </references>
    </references>
    <section anchor="mode7" title="NTP numbered="true" toc="default">
      <name>NTP Remote Facility Message Format"> Format</name>
      <t>The format of the NTP Remote Facility Message header, which immediately
      follows the UDP header, is shown in <xref target="M7Hdr" />. Following is a format="default"/>. A description
      of its fields. fields follows <xref target="M7Hdr" format="default"/>. Bit positions marked as zero are reserved and should
      always be transmitted as zero.</t>
      <figure anchor="M7Hdr" title="NTP anchor="M7Hdr">
        <name>NTP Remote Facility Message Header"> Header</name>
        <artwork align="center"><![CDATA[ align="center" name="" type="" alt=""><![CDATA[
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|M| VN  |Mode |A|  Sequence   | Implementation|   Req Code    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Err  |        Count          |  MBZ  |       Size            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
/                    Data (up to 500 bytes)                     /
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                Encryption KeyID (when A bit set)              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
/          Message Authentication Code (when A bit set)         /
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        ]]></artwork>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
      </figure>

    <t>Response
<dl newline="true" spacing="normal">
      <dt>Response Bit (R) : Set (R):</dt><dd>Set to 0 if the packet is a request. Set to 1 if the
    packet is a response.</t>

    <t>More response.</dd>
      <dt>More Bit (M) : Set (M):</dt><dd>Set to 0 if this is the last packet in a response, otherwise response; otherwise,
    set to 1 in responses requiring more than one packet.</t>

    <t>Version packet.</dd>
      <dt>Version Number (VN) : Set (VN):</dt><dd>Set to the version number of the NTP daemon.</t>

    <t>Mode : Set daemon.</dd>
      <dt>Mode:</dt><dd>Set to 7 for Remote Facility messages.</t>

    <t>Authenticated messages.</dd>
      <dt>Authenticated Bit (A) : If (A):</dt><dd>If set to 1, this packet contains
      authentication information.</t>

    <t>Sequence : For information.</dd>
      <dt>Sequence:</dt><dd>For a multi-packet response, this field contains the
      sequence number of this packet. Packets in a multi-packet response are
      numbered starting with 0. The More Bit is set to 1 for all packets but
      the last.</t>

    <t>Implementation : The last.</dd>
      <dt>Implementation:</dt><dd>The version number of the implementation
      that defined the request code used in this message. An implementation
      number of 0 is used for a Request Code request code supported by all versions of the
      NTP daemon. The value 255 is reserved for future
    extensions.</t>

    <t>Request extensions.</dd>
      <dt>Request Code (Req Code) : An Code):</dt><dd>An implementation-specific code which
      that specifies the operation being requested. A Request Code request code definition
      includes the format and semantics of the data included in the packet.</t>

    <t>Error (Err) : Set
      packet.</dd>
      <dt>Error (Err):</dt><dd><t>Set to 0 for a request. For a response, this field
      contains an error code relating to the request. If the Error is non-zero,
      nonzero, the operation requested wasn't performed.
    <list style="empty">
       <t>0 - no error</t>
       <t>1 - incompatible performed.</t>
     	<dl newline="false" spacing="normal">
        <dt>0:</dt><dd>no error</dd>
        <dt>1:</dt><dd>incompatible implementation number</t>
       <t>2 - unimplemented number</dd>
        <dt>2:</dt><dd>unimplemented request code</t>
       <t>3 - format error</t>
       <t>4 - no data available</t>
       <t>7 - authentication failure</t>
    </list></t>

    <t>Count : The code</dd>
        <dt>3:</dt><dd>format error</dd>
        <dt>4:</dt><dd>no data available</dd>
        <dt>7:</dt><dd>authentication failure</dd>
	</dl>
</dd>
</dl>
<dl newline="true" spacing="normal">
      <dt>Count:</dt><dd>The number of data items in the packet. Range is 0 to 500.</t>

    <t>Must
      500.</dd>
      <dt>Must Be Zero (MBZ) : A (MBZ):</dt><dd>A reserved field set to 0 in requests and responses.</t>

    <t>Size : The responses.</dd>
      <dt>Size:</dt><dd>The size of each data item in the packet. Range is 0 to 500.</t>

    <t>Data : A 500.</dd>
      <dt>Data:</dt><dd>A variable-sized field containing request/response data. For requests and
    responses, the size in octets must be greater than or equal to the product of the number
    of data items (Count) and the size of a data item (Size). For requests, the data area
    is exactly 40 octets in length. For responses, the data area will range from 0 to 500
    octets, inclusive.</t>

    <t>Encryption KeyID : A inclusive.</dd>
      <dt>Encryption KeyID:</dt><dd>A 32-bit unsigned integer used to designate the key used for the
    Message Authentication Code. This field is included only when the A bit is set to 1.</t>

    <t>Message 1.</dd>
      <dt>Message Authentication Code : An Code:</dt><dd>An optional Message Authentication Code defined by the
    version of the NTP daemon indicated in the Implementation field. This field is included
    only when the A bit is set to 1.</t> 1.</dd>
</dl>
</section>
    <section anchor="Acknowledgements" numbered="false" toc="default">
      <name>Acknowledgements</name>

      <t><contact fullname="Tim Plunkett"/> created the original version of
      this document. <contact fullname="Aanchal Malhotra"/> provided the initial version of the
      Security Considerations section.</t>
      <t><contact fullname="Karen O'Donoghue"/>, <contact fullname="David
      Hart"/>, <contact fullname="Harlan Stenn"/>, and <contact
      fullname="Philip Chimento"/> deserve credit for portions of this
      document due to their earlier efforts to document these commands.</t>
      <t><contact fullname="Miroshav Lichvar"/>, <contact fullname="Ulrich
      Windl"/>, <contact fullname="Dieter Sibold"/>, <contact fullname="J
      Ignacio Alvarez-Hamelin"/>, and <contact fullname="Alex Campbell"/>
      provided valuable comments on various draft versions of this document.</t>
    </section>
  <section numbered="false" toc="default">
      <name>Contributors</name>
      <t>Dr. <contact fullname="David Mills"/> specified the vast majority of
      the mode 6 commands during the development of <xref
      target="RFC1305" format="default"/> and deserves the credit for their
      existence and use.</t>
    </section>
  </back>
</rfc>