rfc9327xml2.original.xml   rfc9327.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?> <!DOCTYPE rfc [
<?rfc tocompact="yes"?> <!ENTITY nbsp "&#160;">
<?rfc tocdepth="3"?> <!ENTITY zwsp "&#8203;">
<?rfc tocindent="yes"?> <!ENTITY nbhy "&#8209;">
<?rfc symrefs="yes"?> <!ENTITY wj "&#8288;">
<?rfc sortrefs="yes"?> ]>
<?rfc comments="yes"?>
<?rfc inline="yes"?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" category="
<?rfc compact="yes"?> historic"
<?rfc subcompact="no"?> consensus="true" docName="draft-ietf-ntp-mode-6-cmds-11" number="9327" ipr="pre5
<rfc category="historic" docName="draft-ietf-ntp-mode-6-cmds-11" ipr="pre5378Tru 378Trust200902" obsoletes="" updates="" xml:lang="en" tocInclude="true"
st200902"> tocDepth="3" symRefs="true" sortRefs="true" version="3">
<!-- xml2rfc v2v3 conversion 3.15.0 -->
<front> <front>
<title abbrev="NTP Control Messages">Control Messages Protocol for Use <title abbrev="NTP Control Messages">Control Messages Protocol for Use
with Network Time Protocol Version 4</title> with Network Time Protocol Version 4</title>
<seriesInfo name="RFC" value="9327"/>
<author fullname="Brian Haberman" initials="B." surname="Haberman" role="edi tor"> <author fullname="Brian Haberman" initials="B." surname="Haberman" role="edi tor">
<organization>JHU</organization> <organization>JHU</organization>
<address> <address>
<email>brian@innovationslab.net</email> <email>brian@innovationslab.net</email>
</address> </address>
</author> </author>
<date month="October" year="2022"/>
<date month="February" year="2022" /> <area>int</area>
<workgroup>ntp</workgroup>
<abstract> <abstract>
<t>This document describes the structure of the control messages that were <t>This document describes the structure of the control messages that were
historically used historically used
with the Network Time Protocol before the advent of more modern control an d with the Network Time Protocol (NTP) before the advent of more modern cont rol and
management approaches. These control messages have been used to management approaches. These control messages have been used to
monitor and control the Network Time Protocol application running on any monitor and control the NTP application running on any
IP network attached computer. The information in this document IP network attached computer. The information in this document
was originally described in Appendix B of RFC 1305. The goal of this docum ent was originally described in Appendix B of RFC 1305. The goal of this docum ent
is to provide an updated description of the control messages described in RFC is to provide an updated description of the control messages described in RFC
1305 in order to conform with the updated Network Time Protocol specificat ion 1305 in order to conform with the updated NTP specification
documented in RFC 5905.</t> documented in RFC 5905.</t>
<t>The publication of this document is not meant to encourage the developm ent <t>The publication of this document is not meant to encourage the developm ent
and deployment of these control messages. This document is only providing a and deployment of these control messages. This document is only providing a
current reference for these control messages given the current status of R FC current reference for these control messages given the current status of R FC
1305.</t> 1305.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section title="Introduction"> <section numbered="true" toc="default">
<t>RFC 1305 <xref target="RFC1305" /> described a set of control messages
<name>Introduction</name>
<t><xref target="RFC1305" format="default"/> describes a set of control me
ssages
for use within the Network Time Protocol (NTP) when a comprehensive networ k for use within the Network Time Protocol (NTP) when a comprehensive networ k
management solution was not available. The definitions of these control me ssages management solution was not available. The definitions of these control me ssages
were not promulgated to RFC 5905 <xref target="RFC5905" /> when NTP versio n were not promulgated to <xref target="RFC5905" format="default"/> when NTP version
4 was documented. These messages were intended for use only in 4 was documented. These messages were intended for use only in
systems where no other management facilities were available or systems where no other management facilities were available or
appropriate, such as in dedicated-function bus peripherals. Support for appropriate, such as in dedicated-function bus peripherals. Support for
these messages is not required in order to conform to RFC 5905 these messages is not required in order to conform to
<xref target="RFC5905" />. The control messages are described here as a <xref target="RFC5905" format="default"/>. The control messages are descri
current reference for use with an RFC 5905 implementation of NTP.</t> bed here as a
current reference for use with an implementation of NTP from RFC 5905.</t>
<t>The publication of this document is not meant to encourage the developm ent <t>The publication of this document is not meant to encourage the developm ent
and deployment of these control messages. This document is only providing a and deployment of these control messages. This document is only providing a
current reference for these control messages given the current status of R FC current reference for these control messages given the current status of R FC
1305.</t> 1305.</t>
<section numbered="true" toc="default">
<section title="Control Message Overview"> <name>Terminology</name>
<t>The NTP Mode 6 control messages are used by NTP management programs <t>
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>",
"<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</b
cp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and
"<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as describe
d 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</name>
<t>The NTP mode 6 control messages are used by NTP management programs
(e.g., ntpq) when a more robust network management facility (e.g., SNMP) (e.g., ntpq) when a more robust network management facility (e.g., SNMP)
is not available. These control messages provide rudimentary control and is not available. These control messages provide rudimentary control and
monitoring functions to manage a running instance of an NTP server. These monitoring functions to manage a running instance of an NTP server. These
commands are not designed to be used for communication between instances commands are not designed to be used for communication between instances
of running NTP servers.</t> of running NTP servers.</t>
<t>The NTP control message has the value 6 specified in the mode field
<t>The NTP Control Message has the value 6 specified in the mode field
of the first octet of the NTP header and is formatted as shown in of the first octet of the NTP header and is formatted as shown in
<xref target="M6Hdr" />. <xref target="M6Hdr" format="default"/>.
The format of the data field is specific to each command or response; The format of the data field is specific to each command or response;
however, in most cases the format is designed to be constructed and however, in most cases, the format is designed to be constructed and
viewed by humans and so is coded in free-form ASCII. This facilitates viewed by humans and so is coded in free-form ASCII. This facilitates
the specification and implementation of simple management tools in the the specification and implementation of simple management tools in the
absence of fully evolved network-management facilities. As in ordinary absence of fully evolved network-management facilities. As in ordinary
NTP messages, the authenticator field follows the data field. If the NTP messages, the authenticator field follows the data field. If the
authenticator is used the data field is zero-padded to a 32-bit 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 boundary, but the padding bits are not considered part of the data field
and are not included in the field count.</t> and are not included in the field count.</t>
<t>IP hosts are not required to reassemble datagrams over a certain size <t>IP hosts are not required to reassemble datagrams over a certain size
(576 octets for IPv4 <xref target="RFC0791" /> and 1280 octets for (576 octets for IPv4 <xref target="RFC0791" format="default"/> and 1280 o
IPv6 <xref target="RFC2460" />); however, some commands or responses may ctets for
IPv6 <xref target="RFC8200" format="default"/>); however, some commands o
r responses may
involve more data than involve more data than
will fit into a single datagram. Accordingly, a simple reassembly will fit into a single datagram. Accordingly, a simple reassembly
feature is included in which each octet of the message data is numbered 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 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 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 inserted in the count field. The more-data (M) bit is set in all
fragments except the last.</t> fragments except the last.</t>
<t>Most control functions involve sending a command and receiving a <t>Most control functions involve sending a command and receiving a
response, perhaps involving several fragments. The sender chooses a response, perhaps involving several fragments. The sender chooses a
distinct, nonzero sequence number and sets the status field and "R" and distinct, nonzero sequence number and sets the status field, "R" bit, an
"E" d "E"
bits to zero. The responder interprets the opcode and additional bit to zero. The responder interprets the opcode and additional
information in the data field, updates the status field, sets the "R" bi t information in the data field, updates the status field, sets the "R" bi t
to one and returns the three 32-bit words of the header along with to one and returns the three 32-bit words of the header along with
additional information in the data field. In case of invalid message additional information in the data field. In the case of invalid message
format or contents the responder inserts a code in the status field, 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 sets the "R" and "E" bits to one and, optionally, inserts a diagnostic
message in the data field.</t> message in the data field.</t>
<t>Some commands read or write system variables (e.g., s.offset) and pee r <t>Some commands read or write system variables (e.g., s.offset) and pee r
variables (e.g., p.stratum) for variables (e.g., p.stratum) for
an association identified in the command. Others read or write variables an association identified in the command. Others read or write variables
associated with a radio clock or other device directly connected to a associated with a radio clock or other device directly connected to a
source of primary synchronization information. To identify which type of source of primary synchronization information. To identify which type of
variable and association the Association ID is used. System variable and association, the Association ID is used. System
variables are indicated by the identifier zero. As each association is variables are indicated by the identifier zero. As each association is
mobilized a unique, nonzero identifier is created for it. These mobilized a unique, nonzero identifier is created for it. These
identifiers are used in a cyclic fashion, so that the chance of using an 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 old identifier that matches a newly created association is remote. A
management entity can request a list of current identifiers and management entity can request a list of current identifiers and
subsequently use them to read and write variables for each association. subsequently use them to read and write variables for each association.
An attempt to use an expired identifier results in an exception An attempt to use an expired identifier results in an exception
response, following which the list can be requested again.</t> response, following which the list can be requested again.</t>
<t>Some exception events, such as when a peer becomes reachable or <t>Some exception events, such as when a peer becomes reachable or
unreachable, occur spontaneously and are not necessarily associated with unreachable, occur spontaneously and are not necessarily associated with
a command. An implementation may elect to save the event information for a command. An implementation may elect to save the event information for
later retrieval or to send an asynchronous response (called a trap) or later retrieval, to send an asynchronous response (called a trap), or
both. In case of a trap the IP address and port number is determined by both. In case of a trap, the IP address and port number are determined b
y
a previous command and the sequence field is set as described below. a previous command and the sequence field is set as described below.
Current status and summary information for the latest exception event is Current status and summary information for the latest exception event is
returned in all normal responses. Bits in the status field indicate returned in all normal responses. Bits in the status field indicate
whether an exception has occurred since the last response and whether whether an exception has occurred since the last response and whether
more than one exception has occurred.</t> more than one exception has occurred.</t>
<t>Commands need not necessarily be sent by an NTP peer, so ordinary <t>Commands need not necessarily be sent by an NTP peer, so ordinary
access-control procedures may not apply; however, the optional access-control procedures may not apply; however, the optional
mask/match mechanism suggested in Section <xref target="Security" /> mask/match mechanism suggested in <xref target="Security" format="default
elsewhere in this document provides the "/>
provides the
capability to control access by mode number, so this could be used to capability to control access by mode number, so this could be used to
limit access for control messages (mode 6) to selected address limit access for control messages (mode 6) to selected address
ranges.</t> ranges.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Remote Facility Message Overview"> <name>Remote Facility Message Overview</name>
<t>The original development of the NTP daemon included a remote facility <t>The original development of the NTP daemon included a Remote Facility
for monitoring and configuration. This facility used mode 7 commands for monitoring and configuration. This facility used mode 7 commands
to communicate with the NTP daemon. This document illustrates the mode to communicate with the NTP daemon. This document illustrates the mode
7 packet format only. The commands embedded in the mode 7 messages are 7 packet format only. The commands embedded in the mode 7 messages are
implementation specific and not standardized in any way. The mode 7 mess age implementation specific and not standardized in any way. The mode 7 mess age
format is described in <xref target="mode7" />.</t> format is described in <xref target="mode7" format="default"/>.</t>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<section title="NTP Control Message Format"> <name>NTP Control Message Format</name>
<t>The format of the NTP Control Message header, which immediately <t>The format of the NTP Control Message header, which immediately
follows the UDP header, is shown in <xref target="M6Hdr" />. Following is follows the UDP header, is shown in <xref target="M6Hdr" format="default"/
a description >. Following the figure is a description
of its fields.</t> of its header fields.</t>
<figure anchor="M6Hdr">
<figure anchor="M6Hdr" title="NTP Control Message Header"> <name>NTP Control Message Header</name>
<artwork align="center"><![CDATA[ <artwork align="center" name="" type="" alt=""><![CDATA[
0 1 2 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 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 | Sequence Number | |LI | VN |Mode |R|E|M| opcode | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status | Association ID | | Status | Association ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Offset | Count | | Offset | Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
/ Data (up to 468 bytes) / / Data (up to 468 bytes) /
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Padding (optional) | | Padding (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
/ Authenticator (optional, 20 or 24 bits) / / Authenticator (optional, 20 or 24 bits) /
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
]]></artwork>
</figure> </figure>
<t>Leap Indicator (LI): This is a two-bit integer that is set to <dl newline="true" spacing="normal">
<dt>Leap Indicator (LI):</dt><dd>This is a 2-bit integer that is set to
b00 for control message requests and responses. The Leap Indicator b00 for control message requests and responses. The Leap Indicator
value used at this position in most NTP modes is in the System Status value used at this position in most NTP modes is in the system status
Word provided in some control message responses.</t> word provided in some control message responses.</dd>
<dt>Version Number (VN):</dt><dd>This is a 3-bit integer indicating a mini
<t>Version Number (VN): This is a three-bit integer indicating a minimum mum
NTP version number. NTP servers do not respond to control messages with NTP version number. NTP servers do not respond to control messages with
an unrecognized version number. Requests may intentionally use a lower an unrecognized version number. Requests may intentionally use a lower
version number to enable interoperability with earlier versions of NTP. version number to enable interoperability with earlier versions of NTP.
Responses carry the same version as the corresponding request.</t> Responses carry the same version as the corresponding request.</dd>
<dt>Mode:</dt><dd>This is a 3-bit integer indicating the mode.
<t>Mode: This is a three-bit integer indicating the mode. The value 6 indicates an NTP control message.</dd>
The value 6 indicates an NTP control message.</t> <dt>Response Bit (R):</dt><dd>Set to zero for commands; set to one for res
ponses.</dd>
<t>Response Bit (R): Set to zero for commands, one for responses.</t> <dt>Error Bit (E):</dt><dd>Set to zero for normal responses; set to one fo
r an error
<t>Error Bit (E): Set to zero for normal response, one for error response.</dd>
response.</t> <dt>More Bit (M):</dt><dd>Set to zero for the last fragment; set to one fo
r all others.</dd>
<t>More Bit (M): Set to zero for last fragment, one for all others.</t> <dt>Operation Code (opcode):</dt><dd>This is a 5-bit integer specifying th
e
<t>Operation Code (OpCode): This is a five-bit integer specifying the command function. Values currently defined include the following:</dd>
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 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 | runtime configuration command/response |
| 9 | export configuration to file command/response |
| 10 | retrieve remote address stats command/response |
| 11 | retrieve ordered list command/response |
| 12 | request client-specific nonce command/response |
| 13-30 | reserved |
| 31 | unset trap address/port command/response |
+-------+--------------------------------------------------+
]]></artwork>
</figure></t>
<t>Sequence Number: This is a 16-bit integer indicating the sequence numbe </dl>
r of <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</td>
</tr>
<tr>
<td>3</td>
<td>write variables command/response</td>
</tr>
<tr>
<td>4</td>
<td>read clock variables command/response</td>
</tr>
<tr>
<td>5</td>
<td>write clock variables command/response</td>
</tr>
<tr>
<td>6</td>
<td>set trap address/port command/response</td>
</tr>
<tr>
<td>7</td>
<td>trap response</td>
</tr>
<tr>
<td>8</td>
<td>runtime configuration command/response</td>
</tr>
<tr>
<td>9</td>
<td>export configuration to file command/response</td>
</tr>
<tr>
<td>10</td>
<td>retrieve remote address stats command/response</td>
</tr>
<tr>
<td>11</td>
<td>retrieve ordered list command/response</td>
</tr>
<tr>
<td>12</td>
<td>request client-specific nonce command/response</td>
</tr>
<tr>
<td>13-30</td>
<td>reserved</td>
</tr>
<tr>
<td>31</td>
<td>unset trap address/port command/response</td>
</tr>
</tbody>
</table>
<dl newline="true" spacing="normal">
<dt>Sequence Number:</dt><dd>This is a 16-bit integer indicating the seque
nce number of
the command or response. Each request uses a different sequence number. Ea ch the command or response. Each request uses a different sequence number. Ea ch
response carries the same sequence number as its corresponding request. Fo r response carries the same sequence number as its corresponding request. Fo r
asynchronous trap responses, the responder increments the sequence number by asynchronous trap responses, the responder increments the sequence number by
one for each response, allowing trap receivers to detect missing trap resp onses. one for each response, allowing trap receivers to detect missing trap resp onses.
The sequence number of each fragment of a multiple-datagram response carri es the The sequence number of each fragment of a multiple-datagram response carri es the
same sequence number, copied from the request.</t> same sequence number, copied from the request.</dd>
<dt>Status:</dt><dd>This is a 16-bit code indicating the current status of
<t>Status: This is a 16-bit code indicating the current status of the the
system, peer or clock, with values coded as described in following system, peer, or clock with values coded as described in following
sections.</t> sections.</dd>
<dt>Association ID:</dt><dd>This is a 16-bit unsigned integer identifying
<t>Association ID: This is a 16-bit unsigned integer identifying a valid a valid
association, or zero for the system clock.</t> association or zero for the system clock.</dd>
<dt>Offset:</dt><dd>This is a 16-bit unsigned integer indicating the offse
<t>Offset: This is a 16-bit unsigned integer indicating the offset, in oct t, in octets, of
ets, of
the first octet in the data area. The offset is set to zero in requests. R esponses the first octet in the data area. The offset is set to zero in requests. R esponses
spanning multiple datagrams use a positive offset in all but the first dat spanning multiple datagrams use a positive offset in all but the first dat
agram.</t> agram.</dd>
<dt>Count:</dt><dd>This is a 16-bit unsigned integer indicating the length
<t>Count: This is a 16-bit unsigned integer indicating the length of the d of the data
ata field, in octets.</dd>
field, in octets.</t> <dt>Data:</dt><dd>This contains the message data for the command or respon
se. The
<t>Data: This contains the message data for the command or response. The maximum number of data octets is 468.</dd>
maximum number of data octets is 468.</t> <dt>Padding (optional):</dt><dd>Contains zero to 3 octets with a value of
zero, as needed to
<t>Padding (optional): Contains zero to three octets with value zero, as n ensure the overall control message size is a multiple of 4 octets.</dd>
eeded to <dt>Authenticator (optional):</dt><dd>When the NTP authentication mechanis
ensure the overall control message size is a multiple of 4 octets.</t> m is
<t>Authenticator (optional): When the NTP authentication mechanism is
implemented, this contains the authenticator information defined in implemented, this contains the authenticator information defined in
Appendix C of <xref target="RFC1305" />.</t> <xref target="RFC1305" sectionFormat="of" section="Appendix C"/>.</dd>
</section> </dl>
</section>
<section title="Status Words "> <section numbered="true" toc="default">
<t>Status words indicate the present status of the system, associations <name>Status Words</name>
<t>Status words indicate the present status of the system, associations,
and clock. They are designed to be interpreted by network-monitoring 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 " /> 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 and described in this section. System and peer status words are associated
with responses for all commands except the read clock variables, write with responses for all commands except the read clock variables, write
clock variables and set trap address/port commands. The association clock variables, and set trap address/port commands. The association
identifier zero specifies the system status word, while a nonzero identifier zero specifies the system status word, while a nonzero
identifier specifies a particular peer association. The status word identifier specifies a particular peer association. The status word
returned in response to read clock variables and write clock variables returned in response to read clock variables and write clock variables
commands indicates the state of the clock hardware and decoding commands indicates the state of the clock hardware and decoding
software. A special error status word is used to report malformed software. A special error status word is used to report malformed
command fields or invalid values.</t> command fields or invalid values.</t>
<figure anchor="M6SW">
<figure anchor="M6SW" title="Status Word Formats"> <name>Status Word Formats</name>
<artwork align="center"><![CDATA[ <artwork align="center" name="" type="" alt=""><![CDATA[
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LI| Clock Src | Count | Code | | LI| Clock Src | Count | Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
System Status Word System Status Word
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status | SEL | Count | Code | | Status | SEL | Count | Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at line 304 skipping to change at line 347
Radio Status Word Radio Status Word
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Code | Reserved | | Error Code | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Error Status Word Error Status Word
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Count | Code | | Reserved | Count | Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Clock Status Word Clock Status Word]]></artwork>
]]></artwork>
</figure> </figure>
<section title="System Status Word "> <section numbered="true" toc="default">
<name>System Status Word</name>
<t>The system status word appears in the status field of the response <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 to a read status or read variables command with a zero association
identifier. The format of the system status word is as follows:</t> identifier. The format of the system status word is as follows:</t>
<dl newline="true" spacing="normal">
<t>Leap Indicator (LI): This is a two-bit code warning of an impending <dt>Leap Indicator (LI):</dt><dd>This is a 2-bit code warning of an impen
ding
leap second to be inserted/deleted in the last minute of the current 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> day, with bit 0 and bit 1, respectively, coded as follows:</dd>
</dl>
<t><figure> <table anchor="LeapIndicator">
<artwork align="center" name="Leap Indicator"><![CDATA[ <name>Leap Indicator Codes</name>
+------+------------------------------------------------------------+ <thead>
| LI | Meaning | <tr>
+------+------------------------------------------------------------+ <th>LI</th>
| 00 | no warning | <th>Meaning</th>
| 01 | insert second after 23:59:59 of the current day | </tr>
| 10 | delete second 23:59:59 of the current day | </thead>
| 11 | unsynchronized | <tbody>
+------+------------------------------------------------------------+ <tr>
]]></artwork> <td>00</td>
</figure></t> <td>no warning</td>
</tr>
<t>Clock Source (Clock Src): This is a six-bit integer indicating the cu <tr>
rrent <td>01</td>
synchronization source, with values coded as follows:</t> <td>insert second after 23:59:59 of the current day</td>
</tr>
<t><figure> <tr>
<artwork align="center" name="Clock Source"><![CDATA[ <td>10</td>
+-------+-----------------------------------------------------------+ <td>delete second 23:59:59 of the current day</td>
| Code | Meaning | </tr>
+-------+-----------------------------------------------------------+ <tr>
| 0 | unspecified or unknown | <td>11</td>
| 1 | Calibrated atomic clock (e.g., PPS, HP 5061) | <td>unsynchronized</td>
| 2 | VLF (band 4) or LF (band 5) radio (e.g., OMEGA,, WWVB) | </tr>
| 3 | HF (band 7) radio (e.g., CHU, MSF, WWV/H) | </tbody>
| 4 | UHF (band 9) satellite (e.g., GOES, GPS) | </table>
| 5 | local net (e.g., DCN, TSP, DTS) | <dl newline="true" spacing="normal">
| 6 | UDP/NTP | <dt>Clock Source (Clock Src):</dt><dd>This is a 6-bit integer
| 7 | UDP/TIME | indicating the current synchronization source, with values coded as
| 8 | eyeball-and-wristwatch | follows:</dd>
| 9 | telephone modem (e.g., NIST) | </dl>
| 10-63 | reserved | <table anchor="ClockSource">
+-------+-----------------------------------------------------------+ <name>Clock Source Values</name>
]]></artwork> <thead>
</figure></t> <tr>
<th>Code</th>
<t>System Event Counter (Count): This is a four-bit integer indicating t <th>Meaning</th>
he </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)</td>
</tr>
<tr>
<td>2</td>
<td>VLF (band 4) or LF (band 5) radio (e.g., OMEGA,, WWVB)</td>
</tr>
<tr>
<td>3</td>
<td>HF (band 7) radio (e.g., CHU, MSF, WWV/H)</td>
</tr>
<tr>
<td>4</td>
<td>UHF (band 9) satellite (e.g., GOES, GPS)</td>
</tr>
<tr>
<td>5</td>
<td>local net (e.g., DCN, TSP, 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)</td>
</tr>
<tr>
<td>10-63</td>
<td>reserved</td>
</tr>
</tbody>
</table>
<dl newline="true" spacing="normal">
<dt>System Event Counter (Count):</dt><dd>This is a 4-bit integer indica
ting the
number of system events occurring since the last time the number of system events occurring since the last time the
System Event Code changed. Upon reaching 15, subsequent events with the same System Event Code changed. Upon reaching 15, subsequent events with the same
code are not counted.</t> code are not counted.</dd>
<dt>System Event Code (Code):</dt><dd>This is a 4-bit integer identifyin
<t> System Event Code (Code): This is a four-bit integer identifying the g the
latest system exception event, with new values overwriting previous latest system exception event, with new values overwriting previous
values, and coded as follows:</t> values, and coded as follows:</dd>
</dl>
<t><figure> <table anchor="SystemEventCode">
<artwork align="center" name="System Event Code"><![CDATA[ <name>System Event Codes</name>
+------+---------------------------------------------------------+ <thead>
| Code | Meaning | <tr>
+------+---------------------------------------------------------+ <th>Code</th>
| 0 | unspecified | <th>Meaning</th>
| 1 | frequency correction (drift) file not available | </tr>
| 2 | frequency correction started (frequency stepped) | </thead>
| 3 | spike detected and ignored, starting stepout timer | <tbody>
| 4 | frequency training started | <tr>
| 5 | clock synchronized | <td>0</td>
| 6 | system restart | <td>unspecified</td>
| 7 | panic stop (required step greater than panic threshold) | </tr>
| 8 | no system peer | <tr>
| 9 | leap second insertion/deletion armed for the | <td>1</td>
| | of the current month | <td>frequency correction (drift) file not available</td>
| 10 | leap second disarmed | </tr>
| 11 | leap second inserted or deleted | <tr>
| 12 | clock stepped (stepout timer expired) | <td>2</td>
| 13 | kernel loop discipline status changed | <td>frequency correction started (frequency stepped)</td>
| 14 | leapseconds table loaded from file | </tr>
| 15 | leapseconds table outdated, updated file needed | <tr>
+------+---------------------------------------------------------+ <td>3</td>
]]></artwork> <td>spike detected and ignored, starting stepout timer</td>
</figure></t> </tr>
<tr>
<td>4</td>
<td>frequency training 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)</td>
</tr>
<tr>
<td>8</td>
<td>no system peer</td>
</tr>
<tr>
<td>9</td>
<td>leap second insertion/deletion armed for the current month</td>
</tr>
<tr>
<td>10</td>
<td>leap second disarmed</td>
</tr>
<tr>
<td>11</td>
<td>leap second inserted or deleted</td>
</tr>
<tr>
<td>12</td>
<td>clock stepped (stepout timer expired)</td>
</tr>
<tr>
<td>13</td>
<td>kernel loop discipline status changed</td>
</tr>
<tr>
<td>14</td>
<td>leapseconds table loaded from file</td>
</tr>
<tr>
<td>15</td>
<td>leapseconds table outdated, updated file needed</td>
</tr>
</tbody>
</table>
</section> </section>
<section numbered="true" toc="default">
<section title="Peer Status Word"> <name>Peer Status Word</name>
<t>A peer status word is returned in the status field of a response to <t>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 a read status, read variables, or write variables command and appears
also in the list of association identifiers and status words returned in the list of Association IDs and status words returned
by a read status command with a zero association identifier. The by a read status command with a zero Association ID. The
format of a peer status word is as follows:</t> format of a peer status word is as follows:</t>
<dl newline="true" spacing="normal">
<t>Peer Status (Status): This is a five-bit code indicating the status o <dt>Peer Status (Status):</dt><dd>This is a 5-bit code indicating
f the the status of the peer determined by the packet procedure, with bits
peer determined by the packet procedure, with bits assigned as assigned as follows:</dd>
follows:</t> </dl>
<table anchor="PeerStatus">
<t><figure> <name>Peer Status Bits</name>
<artwork align="center" name="Peer Status"><![CDATA[ <thead>
+-------------+---------------------------------------------------+ <tr>
| Peer Status | Meaning | <th>Peer Status bit</th>
| bit | | <th>Meaning</th>
+-------------+---------------------------------------------------+ </tr>
| 0 | configured (peer.config) | </thead>
| 1 | authentication enabled (peer.authenable) | <tbody>
| 2 | authentication okay (peer.authentic) | <tr>
| 3 | reachability okay (peer.reach != 0) | <td>0</td>
| 4 | broadcast association | <td>configured (peer.config)</td>
+-------------+---------------------------------------------------+ </tr>
]]></artwork> <tr>
</figure></t> <td>1</td>
<td>authentication enabled (peer.authenable)</td>
<t>Peer Selection (SEL): This is a three-bit integer indicating the </tr>
<tr>
<td>2</td>
<td>authentication okay (peer.authentic)</td>
</tr>
<tr>
<td>3</td>
<td>reachability okay (peer.reach != 0)</td>
</tr>
<tr>
<td>4</td>
<td>broadcast association</td>
</tr>
</tbody>
</table>
<dl newline="true" spacing="normal">
<dt>Peer Selection (SEL):</dt><dd>This is a 3-bit integer indicating the
status of the peer determined by the clock-selection procedure, with status of the peer determined by the clock-selection procedure, with
values coded as follows:</t> values coded as follows:</dd>
</dl>
<t><figure> <table anchor="PeerSelection">
<artwork align="center" name="Peer Selection"><![CDATA[ <name>Peer Selection Values</name>
+-----+-------------------------------------------------------------+ <thead>
| Sel | Meaning | <tr>
+-----+-------------------------------------------------------------+ <th>Sel</th>
| 0 | rejected | <th>Meaning</th>
| 1 | discarded by intersection algorithm | </tr>
| 2 | discarded by table overflow (not currently used) | </thead>
| 3 | discarded by the cluster algorithm | <tbody>
| 4 | included by the combine algorithm | <tr>
| 5 | backup source (with more than sys.maxclock survivors) | <td>0</td>
| 6 | system peer (synchronization source) | <td>rejected</td>
| 7 | PPS (pulse per second) peer | </tr>
+-----+-------------------------------------------------------------+ <tr>
]]></artwork> <td>1</td>
</figure></t> <td>discarded by intersection algorithm</td>
</tr>
<t>Peer Event Counter (Count): This is a four-bit integer indicating the <tr>
<td>2</td>
<td>discarded by table overflow (not currently used)</td>
</tr>
<tr>
<td>3</td>
<td>discarded by the cluster algorithm</td>
</tr>
<tr>
<td>4</td>
<td>included by the combine algorithm</td>
</tr>
<tr>
<td>5</td>
<td>backup source (with more than sys.maxclock survivors)</td>
</tr>
<tr>
<td>6</td>
<td>system peer (synchronization source)</td>
</tr>
<tr>
<td>7</td>
<td>PPS (pulse per second) peer</td>
</tr>
</tbody>
</table>
<dl newline="true" spacing="normal">
<dt>Peer Event Counter (Count):</dt><dd>This is a 4-bit integer indicati
ng the
number of peer exception events that occurred since the last time the number of peer exception events that occurred since the last time the
peer event code changed. Upon reaching 15, subsequent events with the sa me peer event code changed. Upon reaching 15, subsequent events with the sa me
code are not counted.</t> code are not counted.</dd>
<dt>Peer Event Code (Code):</dt><dd>This is a 4-bit integer identifying
<t>Peer Event Code (Code): This is a four-bit integer identifying the the
latest peer exception event, with new values overwriting previous values , latest peer exception event, with new values overwriting previous values ,
and coded as follows:</t> and coded as follows:</dd>
</dl>
<t><figure> <table anchor="PeerEventCode">
<artwork align="center" name="Peer Event Code"><![CDATA[ <name>Peer Event Code Values</name>
+-------+--------------------------------------------------------+ <thead>
| Peer | | <tr>
| Event | Meaning | <th>Peer Event Code</th>
| Code | | <th>Meaning</th>
+-------+--------------------------------------------------------+ </tr>
| 0 | unspecified | </thead>
| 1 | association mobilized | <tbody>
| 2 | association demobilized | <tr>
| 3 | peer unreachable (peer.reach was nonzero now zero) | <td>0</td>
| 4 | peer reachable (peer.reach was zero now nonzero) | <td>unspecified</td>
| 5 | association restarted or timed out | </tr>
| 6 | no reply (only used with one-shot clock set command) | <tr>
| 7 | peer rate limit exceeded (kiss code RATE received) | <td>1</td>
| 8 | access denied (kiss code DENY received) | <td>association mobilized</td>
| 9 | leap second insertion/deletion at month's end armed | </tr>
| | by peer vote | <tr>
| 10 | became system peer (sys.peer) | <td>2</td>
| 11 | reference clock event (see clock status word) | <td>association demobilized</td>
| 12 | authentication failed | </tr>
| 13 | popcorn spike suppressed by peer clock filter register | <tr>
| 14 | entering interleaved mode | <td>3</td>
| 15 | recovered from interleave error | <td>peer unreachable (peer.reach was nonzero now zero)</td>
+-------+--------------------------------------------------------+ </tr>
]]></artwork> <tr>
</figure></t> <td>4</td>
<td>peer reachable (peer.reach was zero now nonzero)</td>
</tr>
<tr>
<td>5</td>
<td>association restarted or timed out</td>
</tr>
<tr>
<td>6</td>
<td>no reply (only used with one-shot clock set command)</td>
</tr>
<tr>
<td>7</td>
<td>peer rate limit exceeded (kiss code RATE received)</td>
</tr>
<tr>
<td>8</td>
<td>access denied (kiss code DENY received)</td>
</tr>
<tr>
<td>9</td>
<td>leap second insertion/deletion at month's end armed by peer vote</td>
</tr>
<tr>
<td>10</td>
<td>became system peer (sys.peer)</td>
</tr>
<tr>
<td>11</td>
<td>reference clock event (see clock status 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</td>
</tr>
<tr>
<td>14</td>
<td>entering interleaved mode</td>
</tr>
<tr>
<td>15</td>
<td>recovered from interleave error</td>
</tr>
</tbody>
</table>
</section> </section>
<section numbered="true" toc="default">
<section title="Clock Status Word "> <name>Clock Status Word</name>
<t>There are two ways a reference clock can be attached to a NTP <t>There are two ways a reference clock can be attached to an NTP
service host, as a dedicated device managed by the operating system service host: as a dedicated device managed by the operating system
and as a synthetic peer managed by NTP. As in the read status command, 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 the Association ID is used to
system clock and nonzero for a peer clock. Only one system clock is identify the correct variable for each clock: zero for the system clock and nonz
ero for a peer clock. Only one system clock is
supported by the protocol, although many peer clocks can be supported. 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 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. response to a read clock variables or write clock variables command.
This word can be considered an extension of the system status word or 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 the peer status word as appropriate. The format of the clock status
word is as follows:</t> word is as follows:</t>
<dl newline="true" spacing="normal">
<t>Reserved: An eight-bit integer that is ignored by requesters and <dt>Reserved:</dt><dd>This is an 8-bit integer that is ignored by reques
zeroed by responders.</t> ters and
zeroed by responders.</dd>
<t>Count: This is a four-bit integer indicating the number of clock <dt>Count:</dt><dd>This is a 4-bit integer indicating the number of cloc
k
events that occurred since the last time the clock event code changed. events that occurred since the last time the clock event code changed.
Upon reaching 15, subsequent events with the same code are not counted.< Upon reaching 15, subsequent events with the same code are not counted.<
/t> /dd>
<dt>Clock Code (Code):</dt><dd>This is a 4-bit integer indicating the cu
<t>Clock Code (Code): This is a four-bit integer indicating the current rrent
clock status, with values coded as follows:</t> clock status, with values coded as follows:</dd>
</dl>
<t><figure> <table anchor="ClockStatus">
<artwork align="center" name="Clock Status"><![CDATA[ <name>Clock Code Values</name>
+--------------+--------------------------------------------------+ <thead>
| Clock Status | Meaning | <tr>
+--------------+--------------------------------------------------+ <th>Clock Status</th>
| 0 | clock operating within nominals | <th>Meaning</th>
| 1 | reply timeout | </tr>
| 2 | bad reply format | </thead>
| 3 | hardware or software fault | <tbody>
| 4 | propagation failure | <tr>
| 5 | bad date format or value | <td>0</td>
| 6 | bad time format or value | <td>clock operating within nominals</td>
| 7-15 | reserved | </tr>
+--------------+--------------------------------------------------+ <tr>
]]></artwork> <td>1</td>
</figure></t> <td>reply timeout</td>
</tr>
<tr>
<td>2</td>
<td>bad reply format</td>
</tr>
<tr>
<td>3</td>
<td>hardware or software fault</td>
</tr>
<tr>
<td>4</td>
<td>propagation failure</td>
</tr>
<tr>
<td>5</td>
<td>bad date format or value</td>
</tr>
<tr>
<td>6</td>
<td>bad time format or value</td>
</tr>
<tr>
<td>7-15</td>
<td>reserved</td>
</tr>
</tbody>
</table>
</section> </section>
<section numbered="true" toc="default">
<section title="Error Status Word"> <name>Error Status Word</name>
<t>An error status word is returned in the status field of an error <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 response as the result of invalid message format or contents. Its
presence is indicated when the E (error) bit is set along with the 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 response (R) bit in the response. It consists of an 8-bit integer
coded as follows:</t> coded as follows:</t>
<table anchor="ErrorStatus">
<t><figure> <name>Error Status Word Codes</name>
<artwork align="center" name="Error Status"><![CDATA[ <thead>
+--------------+--------------------------------------------------+ <tr>
| Error Status | Meaning | <th>Error Status</th>
+--------------+--------------------------------------------------+ <th>Meaning</th>
| 0 | unspecified | </tr>
| 1 | authentication failure | </thead>
| 2 | invalid message length or format | <tbody>
| 3 | invalid opcode | <tr>
| 4 | unknown association identifier | <td>0</td>
| 5 | unknown variable name | <td>unspecified</td>
| 6 | invalid variable value | </tr>
| 7 | administratively prohibited | <tr>
| 8-255 | reserved | <td>1</td>
+--------------+--------------------------------------------------+ <td>authentication failure</td>
]]></artwork> </tr>
</figure></t> <tr>
<td>2</td>
<td>invalid message length or 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</td>
</tr>
<tr>
<td>6</td>
<td>invalid variable 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> </section>
<section anchor="commands" numbered="true" toc="default">
<section title="Commands"> <name>Commands</name>
<t>Commands consist of the header and optional data field shown in <t>Commands consist of the header and optional data field shown in
<xref target="M6Hdr" />. When present, the data field contains a list of <xref target="M6Hdr" format="default"/>. When present, the data field cont ains a list of
identifiers or assignments in the form 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;],... &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 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 variable such as the ones specified in RFC 5905 and
&lt;&lt;value&gt;&gt; is expressed as a decimal, hexadecimal or string &lt;&lt;value&gt;&gt; is expressed as a decimal, hexadecimal, or string
constant in the syntax of the C programming language. Where no ambiguity constant in the syntax of the C programming language. Where no ambiguity
exists, the "sys." or "peer." prefixes can be suppressed. exists, the "sys." or "peer." prefixes can be suppressed.
Whitespace (ASCII nonprinting format effectors) can be added to improve Space characters (ASCII nonprinting format effectors) can be added to impr ove
readability for simple monitoring programs that do not reformat the data readability for simple monitoring programs that do not reformat the data
field. Internet addresses are represented as follows: IPv4 addresses field. Representations of note are as follows:</t>
<ul><li>
IPv4 internet addresses
are written in the form [n.n.n.n], where n is in decimal notation and are written in the form [n.n.n.n], where n is in decimal notation and
the brackets are optional; IPv6 addresses are formulated based on the the brackets are optional</li>
guidelines defined in <xref target="RFC5952" />. <li>IPv6 internet addresses are formulated based on the
Timestamps, including reference, originate, receive and transmit values, guidelines defined in <xref target="RFC5952" format="default"/>.</li>
as well as the logical clock, are represented in units of seconds and <li>Timestamps (including reference, originate, receive, and transmit valu
fractions, preferably in hexadecimal notation. Delay, offset, es)
dispersion and distance values are represented in units of milliseconds and the logical clock are represented in units of seconds and
and fractions, preferably in decimal notation. All other values are fractions, preferably in hexadecimal notation.</li>
represented as-is, preferably in decimal notation.</t> <li>Delay, offset,
dispersion, and distance values are represented in units of milliseconds
and fractions, preferably in decimal notation.</li>
<li>All other values are
represented as is, preferably in decimal notation.</li>
</ul>
<t>Implementations may define variables other than those described in <t>Implementations may define variables other than those described in
RFC 5905. Called extramural variables, these are RFC 5905; called "extramural variables", these are
distinguished by the inclusion of some character type other than distinguished by the inclusion of some character type other than
alphanumeric or "." in the name. For those commands alphanumeric or "." in the name. For those commands
that return a list of assignments in the response data field, if the 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 command data field is empty, it is expected that all available variables
defined in RFC 5905 will be included in the defined in RFC 5905 will be included in the
response. For the read commands, if the command data field is nonempty, response. For the read commands, if the command data field is nonempty,
an implementation may choose to process this field to individually an implementation may choose to process this field to individually
select which variables are to be returned.</t> select which variables are to be returned.</t>
<t>Commands are interpreted as follows:</t> <t>Commands are interpreted as follows:</t>
<dl newline="true" spacing="normal">
<t>Read Status (1): The command data field is empty or contains a list <dt>Read Status (1):</dt><dd>The command data field is empty or contains a
list
of identifiers separated by commas. The command operates in two ways of identifiers separated by commas. The command operates in two ways
depending on the value of the association identifier. If this identifier depending on the value of the Association ID. If this identifier
is nonzero, the response includes the peer identifier and status word. is nonzero, the response includes the peer identifier and status word.
Optionally, the response data field may contain other information, such Optionally, the response data field may contain other information, such
as described in the Read Variables command. If the association as described in the Read Variables command. If the association
identifier is zero, the response includes the system identifier (0) and identifier is zero, the response includes the system identifier (0) and
status word, while the data field contains a list of binary-coded pairs status word; the data field contains a list of binary-coded pairs
&lt;&lt;association identifier&gt;&gt; &lt;&lt;status word&gt;&gt;, one &lt;&lt;Association ID&gt;&gt; &lt;&lt;status word&gt;&gt;, one
for each currently defined association.</t> for each currently defined association.</dd>
<dt>Read Variables (2):</dt><dd>The command data field is empty or contain
<t>Read Variables (2): The command data field is empty or contains a s a
list of identifiers separated by commas. If the association identifier list of identifiers separated by commas. If the Association ID
is nonzero, the response includes the requested peer identifier and is nonzero, the response includes the requested peer identifier and
status word, while the data field contains a list of peer variables and status word; the data field contains a list of peer variables and
values as described above. If the association identifier is zero, the values as described above. If the Association ID is zero, the
data field contains a list of system variables. If a peer has data field contains a list of system variables. If a peer has
been selected as the synchronization source, the response includes the been selected as the synchronization source, the response includes the
peer identifier and status word; otherwise, the response includes the peer identifier and status word; otherwise, the response includes the
system identifier (0) and status word.</t> system identifier (0) and status word.</dd>
<dt>Write Variables (3):</dt><dd>The command data field contains a list of
<t>Write Variables (3): The command data field contains a list of
assignments as described above. The variables are updated as indicated. assignments as described above. The variables are updated as indicated.
The response is as described for the Read Variables command.</t> The response is as described for the Read Variables command.</dd>
<dt>Read Clock Variables (4):</dt><dd>The command data field is empty or c
<t>Read Clock Variables (4): The command data field is empty or contains ontains
a list of identifiers separated by commas. The association identifier a list of identifiers separated by commas. The Association ID
selects the system clock variables or peer clock variables in the same selects the system clock variables or peer clock variables in the same
way as in the Read Variables command. The response includes the way as in the Read Variables command. The response includes the
requested clock identifier and status word and the data field contains a requested clock identifier and status word; the data field contains a
list of clock variables and values, including the last timecode message list of clock variables and values, including the last timecode message
received from the clock.</t> received from the clock.</dd>
<dt>Write Clock Variables (5):</dt><dd>The command data field contains a l
<t>Write Clock Variables (5): The command data field contains a list of ist of
assignments as described above. The clock variables are updated as assignments as described above. The clock variables are updated as
indicated. The response is as described for the Read Clock Variables indicated. The response is as described for the read clock variables
command.</t> command.</dd>
<dt>Set Trap Address/Port (6):</dt><dd>The command Association ID, status,
<t>Set Trap Address/Port (6): The command association identifier, status
and data fields are ignored. The address and port number for subsequent 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 trap messages are taken from the source address and port of the control
message itself. The initial trap counter for trap response messages is message itself. The initial trap counter for trap response messages is
taken from the sequence field of the command. The response association taken from the sequence field of the command. The response association
identifier, status and data fields are not significant. Implementations identifier, status, and data fields are not significant. Implementations
should include sanity timeouts which prevent trap transmissions if the should include logical timeouts that prevent trap transmissions if the
monitoring program does not renew this information after a lengthy monitoring program does not renew this information after a lengthy
interval.</t> interval.</dd>
<dt>Trap Response (7):</dt><dd>This message is sent when a system, peer, o
<t>Trap Response (7): This message is sent when a system, peer or clock r clock
exception event occurs. The opcode field is 7 and the R bit is set. The 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 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 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 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 system trap, the Association ID field is set to zero and the
status field contains the system status word. If a peer trap 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 Association ID field is set to that peer and the status field
contains the peer status word. Optional ASCII-coded information can be contains the peer status word. Optional ASCII-coded information can be
included in the data field.</t> included in the data field.</dd>
<dt>Configure (8):</dt><dd>The command data is parsed and applied as if su
<t>Configure (8): The command data is parsed and applied as if supplied pplied
in the daemon configuration file.</t> in the daemon configuration file.</dd>
<dt>Save Configuration (9):</dt><dd>Writes a snapshot of the current confi
<t>Save Configuration (9): Write a snapshot of the current configuration guration
to the file name supplied as the command data. to the file name supplied as the command data.
Further, the command is refused unless a directory in which to store Further, the command is refused unless a directory in which to store
the resulting files has been explicitly configured by the operator.</t> the resulting files has been explicitly configured by the operator.</dd>
<dt>Read Most Recently Used (MRU) list (10):</dt><dd>Retrieves records
<t>Read Most Recently Used (MRU) list (10): Retrieves records of recently of recently seen remote addresses and associated statistics. This
seen remote addresses and associated statistics. This command supports command supports all of the state variables defined in <xref
all of the state variables defined in Section 9 of <xref target="RFC5905" target="RFC5905" sectionFormat="of" section="9"/>. Command data
/>. consists of name=value pairs controlling the selection of records, as
Command data consists of name=value pairs well as a requestor-specific nonce previously retrieved using this
controlling the selection of records, as well as a requestor-specific command or opcode 12 (Request Nonce). The response consists of
nonce previously retrieved using this command or opcode 12, Request name=value pairs where some names can appear multiple times using a dot
Nonce. The response consists of name=value pairs where some names followed by a zero-based index to distinguish them and to associate
can appear multiple times using a dot followed by a zero-based index elements of the same record with the same index. A new nonce is
to distinguish them, and to associate elements of the same record provided with each successful response.</dd>
with the same index. A new nonce is provided with each successful <dt>Read ordered list (11):</dt><dd>Retrieves a list ordered by IP address
response.</t>
<t>Read ordered list (11): Retrieves a list ordered by IP address
(IPv4 information precedes IPv6 information). If the command (IPv4 information precedes IPv6 information). If the command
data is empty or the seven characters "ifstats", the associated data is empty or is the seven characters "ifstats", the associated
statistics, status and counters for each local address are returned. statistics, status, and counters for each local address are returned.
If the command data is the characters "addr_restrictions" then the If the command data is the characters "addr_restrictions", then the
set of IPv4 remote address restrictions followed by the set of IPv6 set of IPv4 remote address restrictions followed by the set of IPv6
remote address restrictions (access control lists) are returned. remote address restrictions (access control lists) are returned.
Other command data returns error code 5 (unknown variable name). Other command data returns error code 5 (unknown variable name).
Similar to Read MRU, response information uses zero-based indexes as Similar to Read MRU, response information uses zero-based indexes as
part of the variable name preceding the equals sign and value, where part of the variable name preceding the equals sign and value, where
each index relates information for a single address or network. This each index relates information for a single address or network. This
opcode requires authentication.</t> opcode requires authentication.</dd>
<dt>Request Nonce (12):</dt><dd>Retrieves a 96-bit nonce specific to the
<t>Request Nonce (12): Retrieves a 96-bit nonce specific to the
requesting remote address, which is valid for a limited period. requesting remote address, which is valid for a limited period.
Command data is not used in the request. The nonce consists of a 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, 64-bit NTP timestamp and 32 bits of hash derived from that timestamp,
the remote address, and salt known only to the server which varies the remote address, and salt known only to the server, which varies
between daemon runs. Inclusion of the between daemon runs. Inclusion of the
nonce by a management agent demonstrates to the server that the agent nonce by a management agent demonstrates to the server that the agent
can receive datagrams sent to the source address of the request, can receive datagrams sent to the source address of the request,
making source address "spoofing" more difficult in a similar way as making source address "spoofing" more difficult in a similar way as
TCP's three-way handshake.</t> TCP's three-way handshake.</dd>
<dt>Unset Trap (31):</dt><dd>Removes the requesting remote address and por
<t>Unset Trap (31): Removes the requesting remote address and port from t from
the list of trap receivers. Command data is not used in the request. 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 If the address and port are not in the list of trap receivers, the
error code is 4, bad association.</t> error code is 4 (bad association).</dd>
</dl>
</section> </section>
<section anchor="IANA" numbered="true" toc="default">
<name>IANA Considerations</name>
<t>This document has no IANA actions.</t>
<section anchor="IANA" title="IANA Considerations">
<t>This document makes no request of IANA.</t>
<t>Note to RFC Editor: this section may be removed on publication as an
RFC.</t>
</section> </section>
<section anchor="Security" numbered="true" toc="default">
<section anchor="Security" title="Security Considerations"> <name>Security Considerations</name>
<t>A number of security vulnerabilities have been identified with <t>A number of security vulnerabilities have been identified with
these control messages.</t> these control messages.</t>
<t>NTP's control query interface allows reading and writing of system, <t>NTP's control query interface allows reading and writing of system,
peer, and clock variables remotely from arbitrary IP addresses using peer, and clock variables remotely from arbitrary IP addresses using
commands mentioned in Section 4. Traditionally, overwriting these commands mentioned in <xref target="commands"/>. Overwriting these
variables, but not reading them, requires authentication by default. variables, but not reading them, requires authentication by default.
However, this document argues that an NTP host must authenticate all However, this document argues that an NTP host must authenticate all
control queries and not just ones that overwrite these variables. control queries and not just ones that overwrite these variables.
Alternatively, the host can use an access control list to explicitly list IP Alternatively, the host can use an access control list to explicitly list IP
addresses that are allowed to control query the clients. These access addresses that are allowed to control query the clients. These access
controls are required for the following reasons:<list style="symbols"> controls are required for the following reasons:</t>
<t>NTP as a Distributed Denial-of-Service (DDoS) vector. NTP timing que <dl newline="true" spacing="normal">
ry <dt>NTP as a Distributed Denial-of-Service (DDoS) vector:</dt><dd>NTP ti
and response packets (modes 1-2, 3-4, 5) are usually short in size. How ming query
ever, 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 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 querie s, short query. As such, there is a history of use of NTP's control querie s,
which exhibit such behavior, to perform DDoS attacks. These off-path at tacks which exhibit such behavior, to perform DoS attacks. These off-path att acks
exploit the large size of NTP control queries to cause UDP-based exploit the large size of NTP control queries to cause UDP-based
amplification attacks (e.g., mode 7 monlist command generates a very lo ng amplification attacks (e.g., mode 7 monlist command generates a very lo ng
packet in response to a small query <xref target="CVE-DOS" />). These a ttacks only packet in response to a small query <xref target="CVE-DOS" format="defa ult"/>). These attacks only
use NTP as a vector for DoS attacks on other protocols, but do not affe ct use NTP as a vector for DoS attacks on other protocols, but do not affe ct
the time service on the NTP host itself. To limit the sources of these the time service on the NTP host itself. To limit the sources of these
malicious commands, NTP server operators are recommended to deploy ingr ess malicious commands, NTP server operators are recommended to deploy ingr ess
filtering <xref target="RFC3704" />.</t> filtering <xref target="RFC3704" format="default"/>.</dd>
<dt>Time-shifting attacks through information leakage/overwriting:</dt><
<t>Time-shifting attacks through information leakage/overwriting. NTP h dd>NTP hosts
osts
save important system and peer state variables. An off-path attacker wh o can save important system and peer state variables. An off-path attacker wh o can
read these variables remotely can leverage the information leaked by th ese read these variables remotely can leverage the information leaked by th ese
control queries to perform time-shifting and DoS attacks on NTP clients control queries to perform time-shifting and DDoS attacks on NTP client
. These s. These
attacks do affect time synchronization on the NTP hosts. For instance,< attacks do affect time synchronization on the NTP hosts. For instance:
list style="symbols"> </dd>
</dl>
<t>In the client/server mode, the client stores its local time when <ul spacing="normal">
it sends the <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 query to the server in its xmt peer variable. This variable is used to perform
TEST2 to non-cryptographically authenticate the server, i.e., if the origin TEST2 to non-cryptographically authenticate the server (i.e., if the origin
timestamp field in the corresponding server response packet matches the xmt peer timestamp field in the corresponding server response packet matches the xmt peer
variable, then the client accepts the packet. An off-path attacker, with the ability variable, then the client accepts the packet). An off-path attacker with the ability
to read this variable can easily spoof server response packets for t he client, which to read this variable can easily spoof server response packets for t he client, which
will pass TEST2, and can deny service or shift time on the NTP clien will pass TEST2 and can deny service or shift time on the NTP client
t. The specific . The specific
attack is described in <xref target="CVE-SPOOF" />.</t> attack is described in <xref target="CVE-SPOOF" format="default"/>.<
/li>
<t>The client also stores its local time when the server response is <li>The client also stores its local time when the server response is received i
received in its n its
rec peer variable. This variable is used for authentication in inter leaved-pivot mode. rec peer variable. This variable is used for authentication in inter leaved-pivot mode.
An off-path attacker with the ability to read this state variable ca n easily shift time An off-path attacker with the ability to read this state variable ca n easily shift time
on the client by passing this test. This attack is described in <xre on the client by passing this test. This attack is described in <xre
f target="CVE-SHIFT" />.</t> f target="CVE-SHIFT" format="default"/>.</li>
</list></t> </ul>
<dl newline="true" spacing="normal">
<t>Fast-Scanning. NTP mode 6 control messages are usually small UDP pac <dt>Fast-Scanning:</dt><dd>NTP mode 6 control messages are usually small
kets. Fast-scanning UDP packets. Fast-scanning
tools like ZMap can be used to spray the entire (potentially reachable) Internet with these 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 wors e, these attacks can messages within hours to identify vulnerable hosts. To make things wors e, these attacks can
be extremely low-rate, only requiring a control query for reconnaissanc e and a spoofed be extremely low-rate, only requiring a control query for reconnaissanc e and a spoofed
response to shift time on vulnerable clients.</t> response to shift time on vulnerable clients.</dd>
<dt>The mode 6 and 7 messages are vulnerable to replay attacks <xref tar
<t>The mode 6 and 7 messages are vulnerable to replay attacks <xref tar get="CVE-Replay" format="default"/>:</dt><dd>
get="CVE-Replay" />.
If an attacker observes mode 6/7 packets that modify the configuration of the server in any 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 sending the packets way, the attacker can apply the same change at any time later by simply sending the packets
to the server again. The use of the nonce (Request Nonce command) provi des limited protection to the server again. The use of the nonce (Request Nonce command) provi des limited protection
against replay attacks.</t> against replay attacks.</dd>
</dl>
</list></t>
<t>NTP best practices recommend configuring NTP with the no-query paramete r. The no-query <t>NTP best practices recommend configuring NTP with the no-query paramete r. The no-query
parameter blocks access to all remote control queries. However, sometimes the hosts do not 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 quer ies remotely. This want to block all queries and want to give access for certain control quer ies remotely. This
could be for the purpose of remote management and configuration of the hos ts in certain could be for the purpose of remote management and configuration of the hos ts in certain
scenarios. Such hosts tend to use firewalls or other middleboxes to blackl ist certain queries scenarios. Such hosts tend to use firewalls or other middleboxes to blackl ist certain queries
within the network.</t> within the network.</t>
<t>Significantly fewer hosts respond to mode 7 <t>Significantly fewer hosts respond to mode 7
monlist queries as compared to other control queries because it is a well- known and exploited 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 firewa lls and middleboxes control query. These queries are likely blocked using blacklists on firewa lls and middleboxes
rather than the no-query option on NTP hosts. The remaining control querie s that can be rather than the no-query option on NTP hosts. The remaining control querie s that can be
exploited likely remain out of the blacklist because they are undocumented in the current exploited likely remain out of the blacklist because they are undocumented in the current
NTP specification <xref target="RFC5905" />.</t> NTP specification <xref target="RFC5905" format="default"/>.</t>
<t>This document describes all of the mode 6 control queries allowed by NT P and can help <t>This document describes all of the mode 6 control queries allowed by NT P and can help
administrators make informed decisions on security measures to protect NTP devices from 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 harmful queries and likely make those systems less vulnerable. The use of the legacy mode 6
interface is NOT RECOMMENDED.Regardless of which mode interface is <bcp14>NOT RECOMMENDED</bcp14>. Regardless of which mode
6 commands an administrator may elect to allow, remote access to this faci lity needs to be 6 commands an administrator may elect to allow, remote access to this faci lity needs to be
protected from unauthorized access (e.g., strict ACLs). Additionally, the protected from unauthorized access (e.g., strict Access Control Lists (ACL
legacy interface s)). Additionally, the legacy interface
for mode 6 commands SHOULD NOT be utilized in new deployments or implement for mode 6 commands <bcp14>SHOULD NOT</bcp14> be utilized in new deploymen
ation of NTP.</t> ts or implementation of NTP.</t>
</section>
<section title="Contributors">
<t>Dr. David Mills specified the vast majority of the mode 6 commands duri
ng the development
of RFC 1305 <xref target="RFC1305" /> and deserves the credit for their ex
istence 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 secti
on.</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 the
se commands.</t>
<t>Miroshav Lichvar, Ulrich Windl, Dieter Sibold, J Ignacio Alvarez-Hameli
n, and Alex Campbell
provided valuable comments on various versions of this document.</t>
</section> </section>
</middle> </middle>
<back> <back>
<references>
<name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1
305.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.21
19.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
905.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
952.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
704.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.81
74.xml"/>
</references>
<references>
<references title="Normative References"> <name>Informative References</name>
<?rfc include="reference.RFC.1305"?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.0
<?rfc include="reference.RFC.5905"?> 791.xml"/>
<?rfc include="reference.RFC.5952"?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<?rfc include="reference.RFC.3704"?> 200.xml"/>
</references>
<references title="Informative References"> <reference anchor="CVE-SHIFT" target="https://nvd.nist.gov/vuln/detail/CVE-2016-
<?rfc include="reference.RFC.0791"?> 1548">
<?rfc include="reference.RFC.2460"?> <front>
<reference anchor="CVE-SHIFT"> <title>CVE-2016-1548 Detail</title>
<front>
<title>CVE-2016-1548, https://nvd.nist.gov/vuln/detail/CVE-2016-1548
</title>
<author> <author>
<organization>NIST National Vulnerability Database</organization> <organization>NIST National Vulnerability Database</organization>
</author> </author>
<date month="January" year="2017" day="06" /> <date month="January" year="2017" day="06"/>
</front> </front>
</reference> </reference>
<reference anchor="CVE-SPOOF">
<front> <reference anchor="CVE-SPOOF" target="https://nvd.nist.gov/vuln/detail/C
<title>CVE-2015-8139, https://nvd.nist.gov/vuln/detail/CVE-2015-8139 VE-2015-8139">
</title> <front>
<title>CVE-2015-8139 Detail</title>
<author> <author>
<organization>NIST National Vulnerability Database</organization> <organization>NIST National Vulnerability Database</organization>
</author> </author>
<date month="January" year="2017" day="30" /> <date month="January" year="2017" day="30"/>
</front> </front>
</reference> </reference>
<reference anchor="CVE-Replay">
<front> <reference anchor="CVE-Replay" target="https://nvd.nist.gov/vuln/detail/
<title>CVE-2015-8140, https://nvd.nist.gov/vuln/detail/CVE-2015-8140 CVE-2015-8140">
</title> <front>
<title>CVE-2015-8140 Detail</title>
<author> <author>
<organization>NIST National Vulnerability Database</organization> <organization>NIST National Vulnerability Database</organization>
</author> </author>
<date month="January" year="2015" day="30" /> <date month="January" year="2015" day="30"/>
</front> </front>
</reference> </reference>
<reference anchor="CVE-DOS">
<front> <reference anchor="CVE-DOS" target="https://nvd.nist.gov/vuln/detail/CVE
<title>CVE-2013-5211, https://nvd.nist.gov/vuln/detail/CVE-2013-5211 -2013-5211">
</title> <front>
<title>CVE-2013-5211 Detail</title>
<author> <author>
<organization>NIST National Vulnerability Database</organization> <organization>NIST National Vulnerability Database</organization>
</author> </author>
<date month="January" year="2014" day="02" /> <date month="January" year="2014" day="02"/>
</front> </front>
</reference> </reference>
</references>
</references> </references>
<section anchor="mode7" numbered="true" toc="default">
<section anchor="mode7" title="NTP Remote Facility Message Format"> <name>NTP Remote Facility Message Format</name>
<t>The format of the NTP Remote Facility Message header, which immediately <t>The format of the NTP Remote Facility Message header, which immediately
follows the UDP header, is shown in <xref target="M7Hdr" />. Following is follows the UDP header, is shown in <xref target="M7Hdr" format="default"/
a description >. A description
of its fields. Bit positions marked as zero are reserved and should of its fields follows <xref target="M7Hdr" format="default"/>. Bit positio
ns marked as zero are reserved and should
always be transmitted as zero.</t> always be transmitted as zero.</t>
<figure anchor="M7Hdr">
<figure anchor="M7Hdr" title="NTP Remote Facility Message Header"> <name>NTP Remote Facility Message Header</name>
<artwork align="center"><![CDATA[ <artwork align="center" name="" type="" alt=""><![CDATA[
0 1 2 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 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 | |R|M| VN |Mode |A| Sequence | Implementation| Req Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Err | Count | MBZ | Size | | Err | Count | MBZ | Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
/ Data (up to 500 bytes) / / Data (up to 500 bytes) /
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encryption KeyID (when A bit set) | | Encryption KeyID (when A bit set) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
/ Message Authentication Code (when A bit set) / / Message Authentication Code (when A bit set) /
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
]]></artwork>
</figure> </figure>
<dl newline="true" spacing="normal">
<t>Response Bit (R) : Set to 0 if the packet is a request. Set to 1 if the <dt>Response Bit (R):</dt><dd>Set to 0 if the packet is a request. Set to
packet is a response.</t> 1 if the
packet is a response.</dd>
<t>More Bit (M) : Set to 0 if this is the last packet in a response, otherwi <dt>More Bit (M):</dt><dd>Set to 0 if this is the last packet in a respons
se e; otherwise,
set to 1 in responses requiring more than one packet.</t> set to 1 in responses requiring more than one packet.</dd>
<dt>Version Number (VN):</dt><dd>Set to the version number of the NTP daem
<t>Version Number (VN) : Set to the version number of the NTP daemon.</t> on.</dd>
<dt>Mode:</dt><dd>Set to 7 for Remote Facility messages.</dd>
<t>Mode : Set to 7 for Remote Facility messages.</t> <dt>Authenticated Bit (A):</dt><dd>If set to 1, this packet contains
authentication information.</dd>
<t>Authenticated Bit (A) : If set to 1, this packet contains authentication <dt>Sequence:</dt><dd>For a multi-packet response, this field contains the
information.</t> 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
<t>Sequence : For a multi-packet response, this field contains the sequence the last.</dd>
number of this <dt>Implementation:</dt><dd>The version number of the implementation
packet. Packets in a multi-packet response are numbered starting with 0. The that defined the request code used in this message. An implementation
More Bit is number of 0 is used for a request code supported by all versions of the
set to 1 for all packets but the last.</t> NTP daemon. The value 255 is reserved for future extensions.</dd>
<dt>Request Code (Req Code):</dt><dd>An implementation-specific code
<t>Implementation : The version number of the implementation that defined th that specifies the operation being requested. A request code definition
e request includes the format and semantics of the data included in the
code used in this message. An implementation number of 0 is used for a Reque packet.</dd>
st Code <dt>Error (Err):</dt><dd><t>Set to 0 for a request. For a response, this f
supported by all versions of the NTP daemon. The value 255 is reserved for f ield
uture contains an error code relating to the request. If the Error is
extensions.</t> nonzero, the operation requested wasn't performed.</t>
<dl newline="false" spacing="normal">
<t>Request Code (Req Code) : An implementation-specific code which specifies <dt>0:</dt><dd>no error</dd>
the operation <dt>1:</dt><dd>incompatible implementation number</dd>
being requested. A Request Code definition includes the format and semantics <dt>2:</dt><dd>unimplemented request code</dd>
of the data <dt>3:</dt><dd>format error</dd>
included in the packet.</t> <dt>4:</dt><dd>no data available</dd>
<dt>7:</dt><dd>authentication failure</dd>
<t>Error (Err) : Set to 0 for a request. For a response, this field contains </dl>
an error code </dd>
relating to the request. If the Error is non-zero, the operation requested w </dl>
asn't performed. <dl newline="true" spacing="normal">
<list style="empty"> <dt>Count:</dt><dd>The number of data items in the packet. Range is 0 to
<t>0 - no error</t> 500.</dd>
<t>1 - incompatible implementation number</t> <dt>Must Be Zero (MBZ):</dt><dd>A reserved field set to 0 in requests and
<t>2 - unimplemented request code</t> responses.</dd>
<t>3 - format error</t> <dt>Size:</dt><dd>The size of each data item in the packet. Range is 0 to
<t>4 - no data available</t> 500.</dd>
<t>7 - authentication failure</t> <dt>Data:</dt><dd>A variable-sized field containing request/response data.
</list></t> For requests and
<t>Count : The number of data items in the packet. Range is 0 to 500.</t>
<t>Must Be Zero (MBZ) : A reserved field set to 0 in requests and responses.
</t>
<t>Size : The size of each data item in the packet. Range is 0 to 500.</t>
<t>Data : A variable-sized field containing request/response data. For reque
sts and
responses, the size in octets must be greater than or equal to the product o f the number responses, the size in octets must be greater than or equal to the product o f the number
of data items (Count) and the size of a data item (Size). For requests, the data area 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 is exactly 40 octets in length. For responses, the data area will range from 0 to 500
octets, inclusive.</t> octets, inclusive.</dd>
<dt>Encryption KeyID:</dt><dd>A 32-bit unsigned integer used to designate
<t>Encryption KeyID : A 32-bit unsigned integer used to designate the key us the key used for the
ed for the Message Authentication Code. This field is included only when the A bit is s
Message Authentication Code. This field is included only when the A bit is s et to 1.</dd>
et to 1.</t> <dt>Message Authentication Code:</dt><dd>An optional Message Authenticatio
n Code defined by the
<t>Message Authentication Code : An optional Message Authentication Code def
ined by the
version of the NTP daemon indicated in the Implementation field. This field is included version of the NTP daemon indicated in the Implementation field. This field is included
only when the A bit is set to 1.</t> only when the A bit is set to 1.</dd>
</section> </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> </back>
</rfc> </rfc>
 End of changes. 135 change blocks. 
650 lines changed or deleted 964 lines changed or added

This html diff was produced by rfcdiff 1.48.