[要約] RFC 9327 は、NTPバージョン4と共に使用される制御メッセージプロトコルの構造を説明し、RFC 1305の制御メッセージを更新しています。この文書は、更新されたNTP仕様に準拠するための参照情報を提供することを目的としており、制御メッセージの開発や展開を奨励するものではありません。
Internet Engineering Task Force (IETF) B. Haberman, Ed.
Request for Comments: 9327 JHU
Category: Historic November 2022
ISSN: 2070-1721
Control Messages Protocol for Use with Network Time Protocol Version 4
ネットワークタイムプロトコルバージョン4で使用するためのコントロールメッセージプロトコル
Abstract
概要
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 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 NTP specification documented in RFC 5905.
このドキュメントでは、より近代的な制御および管理アプローチの出現前に、ネットワークタイムプロトコル（NTP）で歴史的に使用されていた制御メッセージの構造について説明します。これらの制御メッセージは、IPネットワーク接続コンピューターで実行されているNTPアプリケーションを監視および制御するために使用されています。このドキュメントの情報は、元々RFC 1305の付録Bで説明されていました。このドキュメントの目標は、RFC 5905で文書化された更新されたNTP仕様に準拠するために、RFC 1305で説明されているコントロールメッセージの更新された説明を提供することです。
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.
このドキュメントの公開は、これらの制御メッセージの開発と展開を促進することを意図したものではありません。このドキュメントは、RFC 1305の現在のステータスを考慮して、これらの制御メッセージの現在の参照のみを提供しています。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for the historical record.
このドキュメントは、インターネット標準の追跡仕様ではありません。歴史的記録のために公開されています。
This document defines a Historic Document for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントでは、インターネットコミュニティ向けの歴史的なドキュメントを定義しています。このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。IESGによって承認されたすべてのドキュメントが、インターネット標準のあらゆるレベルの候補者であるわけではありません。RFC 7841のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9327.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9327で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2022 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、修正されたBSDライセンスで説明されているように保証なしで提供される修正されたBSDライセンステキストを含める必要があります。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版またはそれを英語以外の言語に翻訳するため。
Table of Contents
目次
1. Introduction
1.1. Terminology
1.2. Control Message Overview
1.3. Remote Facility Message Overview
2. NTP Control Message Format
3. Status Words
3.1. System Status Word
3.2. Peer Status Word
3.3. Clock Status Word
3.4. Error Status Word
4. Commands
5. IANA Considerations
6. Security Considerations
7. References
7.1. Normative References
7.2. Informative References
Appendix A. NTP Remote Facility Message Format
Acknowledgements
Contributors
Author's Address
[RFC1305] 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 [RFC5905] 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 [RFC5905]. The control messages are described here as a current reference for use with an implementation of NTP from RFC 5905.
[RFC1305]は、包括的なネットワーク管理ソリューションが利用できなかった場合に、ネットワーク時間プロトコル（NTP）内で使用する一連の制御メッセージを説明します。これらの制御メッセージの定義は、NTPバージョン4が文書化されたときに[RFC5905]に公布されませんでした。これらのメッセージは、専用の機能バス周辺機器など、他の管理施設が利用できない、または適切なシステムでのみ使用することを目的としています。[RFC5905]に準拠するためには、これらのメッセージのサポートは必要ありません。制御メッセージは、RFC 5905からのNTPの実装で使用するための現在の参照としてここで説明されています。
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.
このドキュメントの公開は、これらの制御メッセージの開発と展開を促進することを意図したものではありません。このドキュメントは、RFC 1305の現在のステータスを考慮して、これらの制御メッセージの現在の参照のみを提供しています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
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) 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.
NTPモード6コントロールメッセージは、より堅牢なネットワーク管理機能（SNMPなど）が利用できない場合に、NTP管理プログラム（NTPQなど）で使用されます。これらの制御メッセージは、NTPサーバーの実行中のインスタンスを管理するための基本的な制御および監視機能を提供します。これらのコマンドは、NTPサーバーを実行するインスタンス間の通信に使用するようには設計されていません。
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 Figure 1. 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 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, 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.
NTP制御メッセージには、NTPヘッダーの最初のオクテットのモードフィールドで指定された値6があり、図1に示すようにフォーマットされています。データフィールドの形式は、各コマンドまたは応答に固有です。ただし、ほとんどの場合、この形式は人間によって構築および表示されるように設計されているため、フリーフォームASCIIでコーディングされます。これにより、完全に進化したネットワーク管理施設がない場合、シンプルな管理ツールの仕様と実装が容易になります。通常のNTPメッセージと同様に、Authenticatorフィールドはデータフィールドに従います。認証器を使用すると、データフィールドは32ビットの境界にゼロパッドされますが、パディングビットはデータフィールドの一部とは見なされず、フィールドカウントに含まれていません。
IP hosts are not required to reassemble datagrams over a certain size (576 octets for IPv4 [RFC0791] and 1280 octets for IPv6 [RFC8200]); however, some commands or responses may involve more data than will fit into a single datagram. Accordingly, a simple reassembly feature is included in which each octet of the message data is numbered starting with zero. As each fragment is transmitted, the number of its first octet is inserted in the offset field and the number of octets is inserted in the count field. The more-data (M) bit is set in all fragments except the last.
IPホストは、特定のサイズ（IPv4 [RFC0791]の場合は576オクテット、IPv6 [RFC8200]の1280オクテット）でデータグラムを再組み立てる必要はありません。ただし、一部のコマンドまたは応答には、単一のデータグラムに収まるよりも多くのデータが含まれる場合があります。したがって、メッセージデータの各オクテットにゼロから数えられる単純な再組み立て機能が含まれています。各フラグメントが送信されると、最初のオクテットの数がオフセットフィールドに挿入され、オクテットの数がカウントフィールドに挿入されます。よりデータ（m）ビットは、最後を除くすべてのフラグメントに設定されます。
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, "R" bit, and "E" 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, 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.
ほとんどの制御関数には、コマンドの送信と応答の受信が含まれます。おそらくいくつかのフラグメントが含まれます。送信者は、異なる非ゼロシーケンス番号を選択し、ステータスフィールド、「r」ビット、および「e」ビットをゼロに設定します。レスポンダーは、データフィールドのオペコードと追加情報を解釈し、ステータスフィールドを更新し、「r」ビットを1つに設定し、ヘッダーの3つの32ビット単語をデータフィールドの追加情報とともに返します。無効なメッセージ形式または内容の場合、レスポンダーはステータスフィールドにコードを挿入し、「r」および「e」ビットを1つに設定し、オプションではデータフィールドに診断メッセージを挿入します。
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, 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 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.
一部のコマンドは、コマンドで識別された関連付けのシステム変数（s.offsetなど）およびピア変数（p.stratumなど）を読み取りまたは書き込みます。他の人は、無線時計またはプライマリ同期情報のソースに直接接続された他のデバイスに関連付けられた変数を読み取りまたは書き込みます。どのタイプの変数と関連性を特定するために、Association IDが使用されます。システム変数は、識別子ゼロによって示されます。各関連付けが動員されるため、一意の非ゼロ識別子が作成されます。これらの識別子は周期的に使用されるため、新しく作成された関連付けに一致する古い識別子を使用する可能性はリモートです。管理エンティティは、現在の識別子のリストを要求し、その後、各協会の変数を読み書きするために使用できます。期限切れの識別子を使用しようとすると、例外応答が発生し、その後、リストを再度要求できます。
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, to send an asynchronous response (called a trap), or both. In case of a trap, the IP address and port number 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.
ピアが到達可能または到達不能になったときなど、いくつかの例外イベントは自然に発生し、必ずしもコマンドに関連付けられていません。実装は、イベント情報を後で検索するために保存し、非同期応答（トラップと呼ばれる）またはその両方を送信することを選択する場合があります。トラップの場合、IPアドレスとポート番号は前のコマンドによって決定され、以下のようにシーケンスフィールドが設定されます。最新の例外イベントの現在のステータスと要約情報は、すべての通常の回答で返されます。ステータスフィールドのビットは、最後の応答以来例外が発生したかどうか、および複数の例外が発生したかどうかを示します。
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 6 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.
コマンドは必ずしもNTPピアによって送信される必要はないため、通常のアクセス制御手順は適用されない場合があります。ただし、セクション6で提案されているオプションのマスク/マッチメカニズムは、モード番号ごとにアクセスを制御する機能を提供するため、これを使用して、選択されたアドレス範囲に制御メッセージ（モード6）のアクセスを制限できます。
The original development of the NTP daemon included a 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 Appendix A.
NTPデーモンの元の開発には、監視と構成のためのリモート機能が含まれていました。この施設は、NTPデーモンと通信するためにモード7コマンドを使用しました。このドキュメントは、モード7パケット形式のみを示しています。モード7メッセージに組み込まれたコマンドは実装固有であり、いかなる方法でも標準化されていません。モード7メッセージ形式は、付録Aで説明されています。
The format of the NTP Control Message header, which immediately follows the UDP header, is shown in Figure 1. Following the figure is a description of its header fields.
UDPヘッダーの直後に次のNTP制御メッセージヘッダーの形式を図1に示します。図には、そのヘッダーフィールドの説明があります。
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 | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status | Association ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Offset | Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ Data (up to 468 bytes) /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Padding (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ Authenticator (optional, 20 or 24 bits) /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: NTP Control Message Header
図1：NTPコントロールメッセージヘッダー
Leap Indicator (LI): This is a 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 provided in some control message responses.
LEAPインジケーター（LI）：これは、コントロールメッセージのリクエストと応答のためにB00に設定されている2ビット整数です。ほとんどのNTPモードでこの位置で使用されるLEAPインジケーター値は、一部のコントロールメッセージ応答で提供されるシステムステータスワードにあります。
Version Number (VN): This is a 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.
バージョン番号（VN）：これは、最小NTPバージョン番号を示す3ビット整数です。NTPサーバーは、認識されていないバージョン番号のコントロールメッセージに応答しません。リクエストは、以前のバージョンのNTPとの相互運用性を有効にするために、意図的に低いバージョン番号を使用する場合があります。応答は、対応するリクエストと同じバージョンを運びます。
Mode: This is a 3-bit integer indicating the mode. The value 6 indicates an NTP control message.
モード：これは、モードを示す3ビット整数です。値6は、NTP制御メッセージを示します。
Response Bit (R): Set to zero for commands; set to one for responses.
応答ビット（r）：コマンドの場合はゼロに設定されています。応答のために1つに設定します。
Error Bit (E): Set to zero for normal responses; set to one for an error response.
エラービット（e）：通常の応答の場合はゼロに設定されています。エラー応答のために1つに設定します。
More Bit (M): Set to zero for the last fragment; set to one for all others.
より多くのビット（m）：最後のフラグメントの場合はゼロに設定します。他のすべてのために1つに設定します。
Operation Code (opcode): This is a 5-bit integer specifying the command function. Values currently defined include the following:
操作コード（OPCODE）：これは、コマンド関数を指定する5ビット整数です。現在定義されている値には、以下が含まれます。
+=======+================================================+
| 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 |
+-------+------------------------------------------------+
Table 1: Operation Codes
表1：操作コード
Sequence Number: 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.
シーケンス番号：これは、コマンドまたは応答のシーケンス番号を示す16ビット整数です。各リクエストは、異なるシーケンス番号を使用します。各応答は、対応する要求と同じシーケンス番号を持ちます。非同期トラップ応答の場合、応答者は応答ごとにシーケンス番号を1つずつ増加させ、トラップレシーバーが欠落したトラップ応答を検出できるようにします。マルチダタグラム応答の各フラグメントのシーケンス番号は、リクエストからコピーされた同じシーケンス番号を持ちます。
Status: This is a 16-bit code indicating the current status of the system, peer, or clock with values coded as described in following sections.
ステータス：これは、以下のセクションで説明されているようにコード化された値を備えたシステム、ピア、またはクロックの現在のステータスを示す16ビットコードです。
Association ID: This is a 16-bit unsigned integer identifying a valid association or zero for the system clock.
Association ID：これは、システムクロックの有効なアソシエーションまたはゼロを識別する16ビットの署名のない整数です。
Offset: 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.
オフセット：これは、データ領域の最初のオクテットのオフセットを示す16ビットの署名整合体です。オフセットは、リクエストでゼロに設定されています。複数のデータグラムにまたがる応答は、最初のデータグラムを除くすべてで正のオフセットを使用します。
Count: This is a 16-bit unsigned integer indicating the length of the data field, in octets.
カウント：これは、オクテット内のデータフィールドの長さを示す16ビットの署名整合体です。
Data: This contains the message data for the command or response. The maximum number of data octets is 468.
データ：これには、コマンドまたは応答のメッセージデータが含まれます。データの最大数は468です。
Padding (optional): Contains zero to 3 octets with a value of zero, as needed to ensure the overall control message size is a multiple of 4 octets.
パディング（オプション）：必要に応じて、ゼロから3オクテットがゼロで、全体のコントロールメッセージサイズが4オクテットの倍数であることを確認します。
Authenticator (optional): When the NTP authentication mechanism is implemented, this contains the authenticator information defined in Appendix C of [RFC1305].
Authenticator（オプション）：NTP認証メカニズムが実装されている場合、これには[RFC1305]の付録Cで定義されている認証情報が含まれています。
Status words indicate the present status of the system, associations, and clock. They are designed to be interpreted by network-monitoring programs and are in one of four 16-bit formats shown in Figure 2 and described in this section. System and peer status words are associated with responses for all commands except the read clock variables, write clock variables, and set trap address/port commands. The association identifier zero specifies the system status word, while a nonzero identifier specifies a particular peer association. The status word returned in response to read clock variables and write clock variables commands indicates the state of the clock hardware and decoding software. A special error status word is used to report malformed command fields or invalid values.
ステータスワードは、システム、関連性、および時計の現在のステータスを示します。これらは、ネットワークモニタリングプログラムによって解釈されるように設計されており、図2に示す4つの16ビット形式のいずれかで、このセクションで説明されています。システムとピアステータスの単語は、読み取りクロック変数、クロック変数の書き込み、およびトラップアドレス/ポートコマンドの設定を除くすべてのコマンドの応答に関連付けられています。Association Identifier Zeroはシステムステータスワードを指定し、非ゼロ識別子は特定のピアアソシエーションを指定します。読み取りクロック変数と書き込みクロック変数コマンドに応じて返されるステータスワードは、クロックハードウェアとデコードソフトウェアの状態を示します。特別なエラーステータスワードを使用して、不正なコマンドフィールドまたは無効な値を報告します。
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
Figure 2: Status Word Formats
図2：ステータスワード形式
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:
システムステータスワードは、ゼロアソシエーション識別子を使用して、読み取りステータスまたは読み取り変数コマンドに対する応答のステータスフィールドに表示されます。システムステータスワードの形式は次のとおりです。
Leap Indicator (LI): This is a 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:
Leap Indicator（LI）：これは、2番目のLeapの2ビットコードであり、現在の日の最後の最後に挿入/削除され、それぞれビット0とビット1が次のようにコーディングされます。
+====+=================================================+
| LI | Meaning |
+====+=================================================+
| 00 | no warning |
+----+-------------------------------------------------+
| 01 | insert second after 23:59:59 of the current day |
+----+-------------------------------------------------+
| 10 | delete second 23:59:59 of the current day |
+----+-------------------------------------------------+
| 11 | unsynchronized |
+----+-------------------------------------------------+
Table 2: Leap Indicator Codes
表2：LEAPインジケーターコード
Clock Source (Clock Src): This is a 6-bit integer indicating the current synchronization source, with values coded as follows:
クロックソース（クロックSRC）：これは、現在の同期ソースを示す6ビット整数であり、値は次のようにコーディングされています。
+=======+========================================================+
| Code | Meaning |
+=======+========================================================+
| 0 | unspecified or unknown |
+-------+--------------------------------------------------------+
| 1 | Calibrated atomic clock (e.g., PPS, HP 5061) |
+-------+--------------------------------------------------------+
| 2 | VLF (band 4) or LF (band 5) radio (e.g., OMEGA,, WWVB) |
+-------+--------------------------------------------------------+
| 3 | HF (band 7) radio (e.g., CHU, MSF, WWV/H) |
+-------+--------------------------------------------------------+
| 4 | UHF (band 9) satellite (e.g., GOES, GPS) |
+-------+--------------------------------------------------------+
| 5 | local net (e.g., DCN, TSP, DTS) |
+-------+--------------------------------------------------------+
| 6 | UDP/NTP |
+-------+--------------------------------------------------------+
| 7 | UDP/TIME |
+-------+--------------------------------------------------------+
| 8 | eyeball-and-wristwatch |
+-------+--------------------------------------------------------+
| 9 | telephone modem (e.g., NIST) |
+-------+--------------------------------------------------------+
| 10-63 | reserved |
+-------+--------------------------------------------------------+
Table 3: Clock Source Values
表3：クロックソース値
System Event Counter (Count): This is a 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.
システムイベントカウンター（count）：これは、システムイベントコードが最後に変更されたときから発生するシステムイベントの数を示す4ビット整数です。15に達すると、同じコードを持つ後続のイベントはカウントされません。
System Event Code (Code): This is a 4-bit integer identifying the latest system exception event, with new values overwriting previous values, and coded as follows:
システムイベントコード（コード）：これは、最新のシステム例外イベントを識別する4ビット整数であり、以前の値を上書きし、次のようにコード化されています。
+======+============================================================+
| Code | Meaning |
+======+============================================================+
| 0 | unspecified |
+------+------------------------------------------------------------+
| 1 | frequency correction (drift) file not available |
+------+------------------------------------------------------------+
| 2 | frequency correction started (frequency stepped) |
+------+------------------------------------------------------------+
| 3 | spike detected and ignored, starting stepout timer |
+------+------------------------------------------------------------+
| 4 | frequency training started |
+------+------------------------------------------------------------+
| 5 | clock synchronized |
+------+------------------------------------------------------------+
| 6 | system restart |
+------+------------------------------------------------------------+
| 7 | panic stop (required step greater than panic threshold) |
+------+------------------------------------------------------------+
| 8 | no system peer |
+------+------------------------------------------------------------+
| 9 | leap second insertion/deletion armed for the current |
| | month |
+------+------------------------------------------------------------+
| 10 | leap second disarmed |
+------+------------------------------------------------------------+
| 11 | leap second inserted or deleted |
+------+------------------------------------------------------------+
| 12 | clock stepped (stepout timer expired) |
+------+------------------------------------------------------------+
| 13 | kernel loop discipline status changed |
+------+------------------------------------------------------------+
| 14 | leapseconds table loaded from file |
+------+------------------------------------------------------------+
| 15 | leapseconds table outdated, updated file needed |
+------+------------------------------------------------------------+
Table 4: System Event Codes
表4：システムイベントコード
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 in the list of Association IDs and status words returned by a read status command with a zero Association ID. The format of a peer status word is as follows:
ピアステータスワードは、読み取りステータス、読み取り変数、または書き込み変数コマンドへの応答のステータスフィールドで返され、ゼロアソシエーションIDを持つ読み取りステータスコマンドによって返される関連IDおよびステータスワードのリストに表示されます。ピアステータスワードの形式は次のとおりです。
Peer Status (Status): This is a 5-bit code indicating the status of the peer determined by the packet procedure, with bits assigned as follows:
ピアステータス（ステータス）：これは、パケット手順によって決定されたピアのステータスを示す5ビットコードであり、ビットは次のように割り当てられます。
+=================+==========================================+
| Peer Status bit | Meaning |
+=================+==========================================+
| 0 | configured (peer.config) |
+-----------------+------------------------------------------+
| 1 | authentication enabled (peer.authenable) |
+-----------------+------------------------------------------+
| 2 | authentication okay (peer.authentic) |
+-----------------+------------------------------------------+
| 3 | reachability okay (peer.reach != 0) |
+-----------------+------------------------------------------+
| 4 | broadcast association |
+-----------------+------------------------------------------+
Table 5: Peer Status Bits
表5：ピアステータスビット
Peer Selection (SEL): This is a 3-bit integer indicating the status of the peer determined by the clock-selection procedure, with values coded as follows:
ピアセレクション（SEL）：これは、クロック選択手順によって決定されるピアのステータスを示す3ビット整数であり、値は次のようにコーディングされています。
+=====+=======================================================+
| Sel | Meaning |
+=====+=======================================================+
| 0 | rejected |
+-----+-------------------------------------------------------+
| 1 | discarded by intersection algorithm |
+-----+-------------------------------------------------------+
| 2 | discarded by table overflow (not currently used) |
+-----+-------------------------------------------------------+
| 3 | discarded by the cluster algorithm |
+-----+-------------------------------------------------------+
| 4 | included by the combine algorithm |
+-----+-------------------------------------------------------+
| 5 | backup source (with more than sys.maxclock survivors) |
+-----+-------------------------------------------------------+
| 6 | system peer (synchronization source) |
+-----+-------------------------------------------------------+
| 7 | PPS (pulse per second) peer |
+-----+-------------------------------------------------------+
Table 6: Peer Selection Values
表6：ピア選択値
Peer Event Counter (Count): This is a 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.
ピアイベントカウンター（カウント）：これは、ピアイベントコードが最後に変更されたときから発生したピア例外イベントの数を示す4ビット整数です。15に達すると、同じコードを持つ後続のイベントはカウントされません。
Peer Event Code (Code): This is a 4-bit integer identifying the latest peer exception event, with new values overwriting previous values, and coded as follows:
ピアイベントコード（コード）：これは、最新のピア例外イベントを識別する4ビット整数であり、以前の値を上書きし、次のようにコーディングされています。
+=================+===================================+
| Peer Event Code | Meaning |
+=================+===================================+
| 0 | unspecified |
+-----------------+-----------------------------------+
| 1 | association mobilized |
+-----------------+-----------------------------------+
| 2 | association demobilized |
+-----------------+-----------------------------------+
| 3 | peer unreachable (peer.reach was |
| | nonzero now zero) |
+-----------------+-----------------------------------+
| 4 | peer reachable (peer.reach was |
| | zero now nonzero) |
+-----------------+-----------------------------------+
| 5 | association restarted or timed |
| | out |
+-----------------+-----------------------------------+
| 6 | no reply (only used with one-shot |
| | clock set command) |
+-----------------+-----------------------------------+
| 7 | peer rate limit exceeded (kiss |
| | code RATE received) |
+-----------------+-----------------------------------+
| 8 | access denied (kiss code DENY |
| | received) |
+-----------------+-----------------------------------+
| 9 | leap second insertion/deletion at |
| | month's end armed by peer vote |
+-----------------+-----------------------------------+
| 10 | became system peer (sys.peer) |
+-----------------+-----------------------------------+
| 11 | reference clock event (see clock |
| | status word) |
+-----------------+-----------------------------------+
| 12 | authentication failed |
+-----------------+-----------------------------------+
| 13 | popcorn spike suppressed by peer |
| | clock filter register |
+-----------------+-----------------------------------+
| 14 | entering interleaved mode |
+-----------------+-----------------------------------+
| 15 | recovered from interleave error |
+-----------------+-----------------------------------+
Table 7: Peer Event Code Values
表7：ピアイベントコード値
There are two ways a reference clock can be attached to an NTP 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, the Association ID is used to identify 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:
参照クロックをNTPサービスホストに添付する方法は2つあります。オペレーティングシステムによって管理される専用のデバイスとして、およびNTPが管理する合成ピアとして。読み取りステータスコマンドのように、Association IDは、各クロックの正しい変数を識別するために使用されます：システムクロックのゼロ、ピアクロックでは非ゼロです。プロトコルによってサポートされているシステムクロックのみがサポートされていますが、多くのピアクロックをサポートできます。システムまたはピアクロックステータスワードは、読み取りクロック変数への応答のステータスフィールドに表示されるか、クロック変数を書き込みます。この単語は、必要に応じて、システムステータスワードまたはピアステータスワードの拡張機能と見なすことができます。クロックステータスワードの形式は次のとおりです。
Reserved: This is an 8-bit integer that is ignored by requesters and zeroed by responders.
予約済み：これは、リクエスターによって無視され、レスポンダーによってゼロになっている8ビット整数です。
Count: This is a 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.
Count：これは、クロックイベントコードが最後に変更されたときから発生した時計イベントの数を示す4ビット整数です。15に達すると、同じコードを持つ後続のイベントはカウントされません。
Clock Code (Code): This is a 4-bit integer indicating the current clock status, with values coded as follows:
クロックコード（コード）：これは、現在のクロックステータスを示す4ビット整数であり、値は次のとおりです。
+==============+=================================+
| Clock Status | Meaning |
+==============+=================================+
| 0 | clock operating within nominals |
+--------------+---------------------------------+
| 1 | reply timeout |
+--------------+---------------------------------+
| 2 | bad reply format |
+--------------+---------------------------------+
| 3 | hardware or software fault |
+--------------+---------------------------------+
| 4 | propagation failure |
+--------------+---------------------------------+
| 5 | bad date format or value |
+--------------+---------------------------------+
| 6 | bad time format or value |
+--------------+---------------------------------+
| 7-15 | reserved |
+--------------+---------------------------------+
Table 8: Clock Code Values
表8：クロックコード値
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 8-bit integer coded as follows:
無効なメッセージ形式またはコンテンツの結果として、エラーステータスワードがエラー応答のステータスフィールドで返されます。その存在は、e（エラー）ビットが応答（r）ビットとともに設定された場合に示されます。次のようにコード化された8ビット整数で構成されています。
+==============+==================================+
| Error Status | Meaning |
+==============+==================================+
| 0 | unspecified |
+--------------+----------------------------------+
| 1 | authentication failure |
+--------------+----------------------------------+
| 2 | invalid message length or format |
+--------------+----------------------------------+
| 3 | invalid opcode |
+--------------+----------------------------------+
| 4 | unknown Association ID |
+--------------+----------------------------------+
| 5 | unknown variable name |
+--------------+----------------------------------+
| 6 | invalid variable value |
+--------------+----------------------------------+
| 7 | administratively prohibited |
+--------------+----------------------------------+
| 8-255 | reserved |
+--------------+----------------------------------+
Table 9: Error Status Word Codes
表9：エラーステータスワードコード
Commands consist of the header and optional data field shown in Figure 1. When present, the data field contains a list of identifiers or assignments in the form <<identifier>>[=<<value>>],<<identifier>>[=<<value>>],... where <<identifier>> is the ASCII name of a system or peer variable such as the ones specified in RFC 5905 and <<value>> is expressed as a decimal, hexadecimal, or string constant in the syntax of the C programming language. Where no ambiguity exists, the "sys." or "peer." prefixes can be suppressed. Space characters (ASCII nonprinting format effectors) can be added to improve readability for simple monitoring programs that do not reformat the data field. Representations of note are as follows:
コマンドは、図1に示すヘッダーとオプションのデータフィールドで構成されています。存在する場合、データフィールドには識別子または割り当てのリストが含まれています<<識別子>> [= <<値>>]、<<識別子>> [= << value >>]、...ここで、<<識別子>>は、RFC 5905および<<値>>で指定されたものなどのシステムまたはピア変数のASCII名です。Cプログラミング言語の構文の文字列定数。あいまいさが存在しない場合、「sys」。または「ピア」。プレフィックスは抑制できます。スペース文字（ASCII非印刷形式エフェクター）を追加して、データフィールドを再フォーマットしない簡単な監視プログラムの読みやすさを向上させることができます。メモの表現は次のとおりです。
* IPv4 internet addresses are written in the form [n.n.n.n], where n is in decimal notation and the brackets are optional
* IPv4インターネットアドレスは[n.n.n.n]の形式で記述されています。ここで、nは10進表記で、ブラケットはオプションです
* IPv6 internet addresses are formulated based on the guidelines defined in [RFC5952].
* IPv6インターネットアドレスは、[RFC5952]で定義されているガイドラインに基づいて策定されています。
* Timestamps (including reference, originate, receive, and transmit values) and the logical clock are represented in units of seconds and fractions, preferably in hexadecimal notation.
* タイムスタンプ（参照、発信、受信、および送信値を含む）および論理クロックは、秒単位と分数、できれば16進表記で表されます。
* Delay, offset, dispersion, and distance values are represented in units of milliseconds and fractions, preferably in decimal notation.
* 遅延、オフセット、分散、距離の値は、ミリ秒および分数の単位で、できれば小数表記で表されます。
* All other values are represented as is, preferably in decimal notation.
* 他のすべての値は、できれば小数表で表現されます。
Implementations may define variables other than those described in RFC 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.
実装は、RFC 5905で説明されている変数以外の変数を定義する場合があります。「双方向変数」と呼ばれるこれらは、英数字以外の文字タイプを含めることによって区別されます。名前に。応答データフィールドの割り当てリストを返すコマンドの場合、コマンドデータフィールドが空の場合、RFC 5905で定義されているすべての利用可能な変数が応答に含まれることが予想されます。読み取りコマンドの場合、コマンドデータフィールドが空でない場合、実装はこのフィールドを処理して、どの変数を返すかを個別に選択することを選択できます。
Commands are interpreted as follows:
コマンドは次のように解釈されます。
Read Status (1): 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 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; the data field contains a list of binary-coded pairs <<Association ID>> <<status word>>, one for each currently defined association.
読み取りステータス（1）：コマンドデータフィールドは空であるか、コンマで区切られた識別子のリストが含まれています。コマンドは、関連付けIDの値に応じて2つの方法で動作します。この識別子がゼロでない場合、応答にはピア識別子とステータスワードが含まれます。オプションで、応答データフィールドには、読み取り変数コマンドに記載されているような他の情報が含まれる場合があります。関連付け識別子がゼロの場合、応答にはシステム識別子（0）とステータスワードが含まれます。データフィールドには、現在定義されているそれぞれのアソシエーション用のバイナリコーディングペア<< Association ID >> << Status Word >>のリストが含まれています。
Read Variables (2): The command data field is empty or contains a list of identifiers separated by commas. If the Association ID is nonzero, the response includes the requested peer identifier and status word; the data field contains a list of peer variables and values as described above. If the 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.
変数を読む（2）：コマンドデータフィールドは空であるか、コンマで区切られた識別子のリストが含まれています。Association IDがゼロ以外の場合、応答には要求されたピア識別子とステータスワードが含まれます。データフィールドには、上記のようにピア変数と値のリストが含まれています。Association IDがゼロの場合、データフィールドにはシステム変数のリストが含まれています。同期ソースとしてピアが選択されている場合、応答にはピア識別子とステータスワードが含まれます。それ以外の場合、応答にはシステム識別子（0）とステータスワードが含まれます。
Write Variables (3): 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.
変数の書き込み（3）：コマンドデータフィールドには、上記のように割り当てのリストが含まれています。変数は示されているように更新されます。応答は、読み取り変数コマンドの説明とおりです。
Read Clock Variables (4): The command data field is empty or contains a list of identifiers separated by commas. The 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; the data field contains a list of clock variables and values, including the last timecode message received from the clock.
時計変数（4）を読む：コマンドデータフィールドは空であるか、コンマで区切られた識別子のリストが含まれています。Association IDは、読み取り変数コマンドと同じ方法で、システムクロック変数またはピアクロック変数を選択します。応答には、要求されたクロック識別子とステータスワードが含まれます。データフィールドには、クロックから受信した最後のタイムコードメッセージを含む、クロック変数と値のリストが含まれています。
Write Clock Variables (5): 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.
クロック変数の書き込み（5）：コマンドデータフィールドには、上記のように割り当てのリストが含まれています。クロック変数は、示されているように更新されます。応答は、読み取りクロック変数コマンドで説明されているとおりです。
Set Trap Address/Port (6): The command 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, and data fields are not significant. Implementations should include logical timeouts that prevent trap transmissions if the monitoring program does not renew this information after a lengthy interval.
TRAPアドレス/ポートの設定（6）：コマンドアソシエーションID、ステータス、およびデータフィールドは無視されます。後続のトラップメッセージのアドレスとポート番号は、コントロールメッセージ自体のソースアドレスとポートから取得されます。トラップ応答メッセージの最初のトラップカウンターは、コマンドのシーケンスフィールドから取得されます。応答関連の識別子、ステータス、およびデータフィールドは重要ではありません。実装には、監視プログラムが長い間隔の後にこの情報を更新しない場合、トラップ送信を防ぐ論理タイムアウトを含める必要があります。
Trap Response (7): This message is sent when a system, 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, the Association ID field is set to zero and the status field contains the system status word. If a peer trap, the 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.
トラップ応答（7）：このメッセージは、システム、ピア、またはクロック例外イベントが発生したときに送信されます。オペコードフィールドは7で、Rビットが設定されています。トラップカウンターは、送信されるトラップごとに1つずつ増加し、シーケンスフィールドはその値に設定されます。TRAPメッセージは、SET TRAPアドレス/ポートコマンドによって確立されたIPアドレスとポートフィールドを使用して送信されます。システムトラップの場合、Association IDフィールドはゼロに設定され、ステータスフィールドにはシステムステータスワードが含まれます。ピアトラップの場合、Association IDフィールドはそのピアに設定され、ステータスフィールドにはピアステータスワードが含まれています。オプションのASCIIコード化された情報は、データフィールドに含めることができます。
Configure (8): The command data is parsed and applied as if supplied in the daemon configuration file.
configure（8）：コマンドデータは、デーモン構成ファイルに提供されているかのように解析および適用されます。
Save Configuration (9): 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.
構成を保存（9）：現在の構成のスナップショットを、コマンドデータとして提供されたファイル名に書き込みます。さらに、結果のファイルを保存するディレクトリがオペレーターによって明示的に構成されていない限り、コマンドは拒否されます。
Read Most Recently Used (MRU) list (10): Retrieves records of recently seen remote addresses and associated statistics. This command supports all of the state variables defined in Section 9 of [RFC5905]. 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). 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 and to associate elements of the same record with the same index. A new nonce is provided with each successful response.
最近使用された（MRU）リスト（10）を読む：最近見られたリモートアドレスと関連する統計の記録を取得します。このコマンドは、[RFC5905]のセクション9で定義されているすべての状態変数をサポートします。コマンドデータは、レコードの選択を制御する名前=値ペアと、このコマンドまたはOpCode 12（要求NonCE）を使用して以前に取得した要求者固有のNonCEで構成されています。応答は、name = valueペアで構成されています。ここでは、一部の名前がドットを使用して複数回表示でき、その後にゼロベースのインデックスを使用してそれらを区別し、同じレコードの要素を同じインデックスに関連付けます。新しいNonCEは、それぞれの成功した応答が提供されます。
Read ordered list (11): 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, and counters for each local address are returned. If the command data is the characters "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.
注文リスト（11）を読む：IPアドレスで注文したリストを取得します（IPv4情報はIPv6情報の前にあります）。コマンドデータが空であるか、7文字「Ifstat」である場合、各ローカルアドレスの関連する統計、ステータス、およびカウンターが返されます。コマンドデータが文字「ADDR_RESTRICTIONS」である場合、IPv4リモートアドレス制限のセットとその後のIPv6リモートアドレス制限（アクセス制御リスト）のセットが返されます。その他のコマンドデータは、エラーコード5（不明な変数名）を返します。読み取りMRUと同様に、応答情報は、等しい符号と値の前にある変数名の一部としてゼロベースのインデックスを使用します。各インデックスは、単一のアドレスまたはネットワークの情報を関連付けます。このオペコードには認証が必要です。
Request Nonce (12): 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, 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.
Nonce（12）を要求する：限られた期間有効なリクエストリモートアドレスに固有の96ビットのNonceを取得します。コマンドデータはリクエストでは使用されません。NonCEは、64ビットNTPタイムスタンプと、そのタイムスタンプ、リモートアドレス、およびデーモンの実行によって異なるサーバーにのみ知られている塩に由来する32ビットのハッシュで構成されています。管理エージェントによるNonCeを含めることは、エージェントがリクエストのソースアドレスに送信されたデータグラムを受け取ることができることをサーバーに示し、ソースアドレスをTCPの3方向の握手と同様の方法でより困難にします。
Unset Trap (31): 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).
Unset Trap（31）：TRAPレシーバーのリストからリクエストリモートアドレスとポートを削除します。コマンドデータはリクエストでは使用されません。アドレスとポートがトラップレシーバーのリストにない場合、エラーコードは4です（バッドアソシエーション）。
This document has no IANA actions.
このドキュメントにはIANAアクションがありません。
A number of security vulnerabilities have been identified with these control messages.
これらの制御メッセージでは、多くのセキュリティの脆弱性が特定されています。
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. 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:
NTPのコントロールクエリインターフェイスにより、セクション4で言及されたコマンドを使用して、任意のIPアドレスからシステム、ピア、およびクロック変数の読み書きができます。これらの変数を上書きしますが、読み取りではなく、デフォルトで認証が必要です。ただし、このドキュメントは、NTPホストがこれらの変数を上書きするだけでなく、すべての制御クエリを認証する必要があると主張しています。または、ホストはアクセス制御リストを使用して、クライアントのクエリを制御できるIPアドレスを明示的にリストすることができます。これらのアクセス制御は、次の理由で必要です。
NTP as a Distributed Denial-of-Service (DDoS) vector: 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 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 [CVE-DOS]). 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 [RFC3704].
分散型サービス拒否（DDOS）ベクトルとしてのNTP：NTPタイミングクエリと応答パケット（モード1-2、3-4、および5）のサイズは短いです。ただし、一部のNTP制御クエリは、短いクエリに応じて非常に長いパケットを生成します。そのため、DOS攻撃を実行するために、そのような動作を示すNTPの制御クエリの使用履歴があります。これらのオフパス攻撃は、NTP制御クエリの大きなサイズを活用してUDPベースの増幅攻撃を引き起こします（例：モード7モンリストコマンドは、小さなクエリ[CVE-DOS]に応じて非常に長いパケットを生成します）。これらの攻撃は、NTPを他のプロトコルに対するDOS攻撃のベクトルとしてのみ使用しますが、NTPホスト自体のタイムサービスには影響しません。これらの悪意のあるコマンドのソースを制限するために、NTPサーバー演算子は、イングレスフィルタリング[RFC3704]を展開するために推奨されます。
Time-shifting attacks through information leakage/overwriting: 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 DDoS attacks on NTP clients. These attacks do affect time synchronization on the NTP hosts. For instance:
情報の漏れ/上書きによる時間シフト攻撃：NTPホストは、重要なシステムとピア状態の変数を保存します。これらの変数をリモートで読み取ることができるオフパス攻撃者は、これらの制御クエリによって漏れた情報を活用して、NTPクライアントに対してタイムシフトおよびDDOS攻撃を実行できます。これらの攻撃は、NTPホストの時間同期に影響します。例えば：
* 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., if the origin 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 to read this variable can easily spoof server response packets for the client, which will pass TEST2 and can deny service or shift time on the NTP client. The specific attack is described in [CVE-SPOOF].
* クライアント/サーバーモードでは、クライアントはXMTピア変数でサーバーにクエリを送信するときにローカルタイムを保存します。この変数は、test2を実行するために使用され、サーバーを非結晶化します（つまり、対応するサーバー応答パケットのオリジンタイムスタンプフィールドがXMTピア変数と一致する場合、クライアントはパケットを受け入れます）。この変数を読み取る機能を備えたオフパス攻撃者は、クライアントのサーバー応答パケットを簡単にスプーフィングすることができます。これにより、test2に合格し、NTPクライアントのサービスまたはシフト時間を拒否できます。特定の攻撃は[CVE-Spoof]で説明されています。
* 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 [CVE-SHIFT].
* また、クライアントは、サーバーの応答がRECピア変数で受信されたときに現地時間を保存します。この変数は、インターリーブピボットモードの認証に使用されます。この状態変数を読み取る機能を備えたオフパス攻撃者は、このテストに合格することでクライアントの時間を簡単にシフトできます。この攻撃は[cve-shift]で説明されています。
Fast-Scanning: 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.
高速スキャニング：NTPモード6コントロールメッセージは通常、小さなUDPパケットです。ZMAPなどの高速スキャンツールを使用して、脆弱なホストを特定するために、これらのメッセージを数時間以内に（潜在的に到達可能な）インターネット全体にスプレーできます。さらに悪いことに、これらの攻撃は非常に低いレートであり、偵察のための制御クエリと脆弱なクライアントのシフト時間に対するスプーフィングされた応答のみを必要とすることができます。
The mode 6 and 7 messages are vulnerable to replay attacks [CVE-Replay]: 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 by simply sending the packets to the server again. The use of the nonce (Request Nonce command) provides limited protection against replay attacks.
モード6および7のメッセージは、リプレイ攻撃に対して脆弱です[CVE-Replay]：攻撃者がサーバーの構成を何らかの方法で変更するモード6/7パケットを観察すると、攻撃者はいつでも同じ変更を適用できます。パケットを再度サーバーに送信します。NonCe（Request NonCeコマンド）の使用は、リプレイ攻撃に対する限定的な保護を提供します。
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.
NTPベストプラクティスは、NO-queryパラメーターでNTPを構成することをお勧めします。No-queryパラメーターは、すべてのリモートコントロールクエリへのアクセスをブロックします。ただし、ホストがすべてのクエリをブロックしたくなく、特定のコントロールクエリへのアクセスをリモートで提供したい場合があります。これは、特定のシナリオでホストのリモート管理と構成を目的とする可能性があります。このようなホストは、ファイアウォールまたはその他のミドルボックスを使用して、ネットワーク内の特定のクエリをブラックリストに登録する傾向があります。
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 [RFC5905].
有名で悪用されたコントロールクエリであるため、他のコントロールクエリと比較して、モード7モンリストクエリに対応するホストが大幅に少なくなります。これらのクエリは、NTPホストのクエリなしオプションではなく、ファイアウォールとミドルボックスのブラックリストを使用してブロックされる可能性があります。悪用される可能性のある残りのコントロールクエリは、現在のNTP仕様[RFC5905]で文書化されていないため、ブラックリストから外れたままである可能性があります。
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 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 Access Control Lists (ACLs)). Additionally, the legacy interface for mode 6 commands SHOULD NOT be utilized in new deployments or implementation of NTP.
このドキュメントでは、NTPが許可されているモード6制御クエリのすべてを説明し、管理者がNTPデバイスを有害なクエリから保護し、それらのシステムを脆弱にする可能性が高いセキュリティ対策に関する情報に基づいた決定を下すのに役立ちます。レガシーモード6インターフェイスの使用は推奨されません。管理者が許可することを選択できるモード6コマンドに関係なく、この施設へのリモートアクセスは、不正アクセスから保護する必要があります（例：Strict Access Controlリスト（ACLS））。さらに、モード6コマンドのレガシーインターフェイスは、NTPの新しい展開または実装で使用しないでください。
[RFC1305] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation and Analysis", RFC 1305, DOI 10.17487/RFC1305, March 1992, <https://www.rfc-editor.org/info/rfc1305>.
[RFC1305] Mills、D。、「ネットワークタイムプロトコル（バージョン3）仕様、実装、分析」、RFC 1305、DOI 10.17487/RFC1305、1992年3月、<https://www.rfc-editor.org/info/rfc1305555555555555555555555555>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487/RFC2119、1997年3月、<https://www.rfc-editor.org/info/RFC2119>。
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March 2004, <https://www.rfc-editor.org/info/rfc3704>.
[RFC3704] Baker、F。およびP. Savola、「マルチホームネットワークのイングレスフィルタリング」、BCP 84、RFC 3704、DOI 10.17487/RFC3704、2004年3月、<https://www.rfc-editor.org/info/rfc3704>。
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, <https://www.rfc-editor.org/info/rfc5905>.
[RFC5905] Mills、D.、Martin、J.、Ed。、Burbank、J.、およびW. Kasch、「ネットワークタイムプロトコルバージョン4：プロトコルとアルゴリズムの仕様」、RFC 5905、DOI 10.17487/RFC5905、2010年6月、<https://www.rfc-editor.org/info/rfc5905>。
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 Address Text Representation", RFC 5952, DOI 10.17487/RFC5952, August 2010, <https://www.rfc-editor.org/info/rfc5952>.
[RFC5952] Kawamura、S。およびM. Kawashima、「IPv6アドレステキスト表現の推奨」、RFC 5952、DOI 10.17487/RFC5952、2010年8月、<https://www.rfc-editor.org/info/rfc5952>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487/RFC8174、2017年5月、<https：//www.rfc-editor.org/info/RFC8174>。
[CVE-DOS] NIST National Vulnerability Database, "CVE-2013-5211 Detail", 2 January 2014, <https://nvd.nist.gov/vuln/detail/CVE-2013-5211>.
[CVE-DOS] NIST National Ulnerabilityデータベース、「CVE-2013-5211詳細」、2014年1月2日、<https://nvd.nist.gov/vuln/detail/cve-2013-5211>。
[CVE-Replay] NIST National Vulnerability Database, "CVE-2015-8140 Detail", 30 January 2015, <https://nvd.nist.gov/vuln/detail/CVE-2015-8140>.
[CVE-Replay] NIST National Ulnerabilityデータベース、「CVE-2015-8140詳細」、2015年1月30日、<https://nvd.nist.gov/vuln/detail/cve-2015-8140>。
[CVE-SHIFT] NIST National Vulnerability Database, "CVE-2016-1548 Detail", 6 January 2017, <https://nvd.nist.gov/vuln/detail/CVE-2016-1548>.
[CVE-Shift] NIST National Ulnerabilityデータベース、「CVE-2016-1548詳細」、2017年1月6日、<https://nvd.nist.gov/vuln/detail/cve-2016-1548>。
[CVE-SPOOF] NIST National Vulnerability Database, "CVE-2015-8139 Detail", 30 January 2017, <https://nvd.nist.gov/vuln/detail/CVE-2015-8139>.
[CVE-Spoof] NIST National Ulnerabilityデータベース、「CVE-2015-8139詳細」、2017年1月30日、<https://nvd.nist.gov/vuln/detail/cve-2015-8139>。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, <https://www.rfc-editor.org/info/rfc791>.
[RFC0791] POSTEL、J。、「インターネットプロトコル」、STD 5、RFC 791、DOI 10.17487/RFC0791、1981年9月、<https://www.rfc-editor.org/info/rfc791>。
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, <https://www.rfc-editor.org/info/rfc8200>.
[RFC8200] Deering、S。and R. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、STD 86、RFC 8200、DOI 10.17487/RFC8200、2017年7月、<https://www.rfc-editor.org/info/rfc8200>。
The format of the NTP Remote Facility Message header, which immediately follows the UDP header, is shown in Figure 3. A description of its fields follows Figure 3. Bit positions marked as zero are reserved and should always be transmitted as zero.
UDPヘッダーの直後に次のNTPリモート施設メッセージヘッダーの形式を図3に示します。そのフィールドの説明は、図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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|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) /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: NTP Remote Facility Message Header
図3：NTPリモート施設メッセージヘッダー
Response Bit (R): Set to 0 if the packet is a request. Set to 1 if the packet is a response.
応答ビット（r）：パケットがリクエストの場合は0に設定されています。パケットが応答である場合、1に設定します。
More Bit (M): Set to 0 if this is the last packet in a response; otherwise, set to 1 in responses requiring more than one packet.
より多くのビット（m）：これが応答の最後のパケットである場合、0に設定します。それ以外の場合は、複数のパケットを必要とする応答の1に設定します。
Version Number (VN): Set to the version number of the NTP daemon.
バージョン番号（VN）：NTPデーモンのバージョン番号に設定します。
Mode: Set to 7 for Remote Facility messages.
モード：リモート施設メッセージの7に設定します。
Authenticated Bit (A): If set to 1, this packet contains authentication information.
認証ビット（a）：1に設定されている場合、このパケットには認証情報が含まれています。
Sequence: 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.
シーケンス：マルチパケット応答の場合、このフィールドにはこのパケットのシーケンス番号が含まれています。マルチパケット応答のパケットには、0から始まる番号が付けられています。すべてのパケットで1ビットが1に設定されていますが、最後です。
Implementation: 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 supported by all versions of the NTP daemon. The value 255 is reserved for future extensions.
実装：このメッセージで使用されたリクエストコードを定義した実装のバージョン番号。0の実装番号は、NTPデーモンのすべてのバージョンでサポートされているリクエストコードに使用されます。値255は、将来の拡張機能のために予約されています。
Request Code (Req Code): An implementation-specific code that specifies the operation being requested. A request code definition includes the format and semantics of the data included in the packet.
リクエストコード（REQコード）：要求されている操作を指定する実装固有のコード。要求コード定義には、パケットに含まれるデータの形式とセマンティクスが含まれます。
Error (Err): Set to 0 for a request. For a response, this field contains an error code relating to the request. If the Error is nonzero, the operation requested wasn't performed.
エラー（ERR）：リクエストに対して0に設定します。応答の場合、このフィールドにはリクエストに関連するエラーコードが含まれています。エラーがゼロでない場合、要求された操作は実行されませんでした。
0: no error
0：エラーなし
1: incompatible implementation number
1：互換性のない実装番号
2: unimplemented request code
2：実装されていないリクエストコード
3: format error
3：フォーマットエラー
4: no data available
4：データはありません
7: authentication failure
7：認証障害
Count: The number of data items in the packet. Range is 0 to 500.
カウント：パケット内のデータ項目の数。範囲は0〜500です。
Must Be Zero (MBZ): A reserved field set to 0 in requests and responses.
ゼロである必要があります（MBZ）：リクエストと応答で0に設定された予約フィールド。
Size: The size of each data item in the packet. Range is 0 to 500.
サイズ：パケット内の各データ項目のサイズ。範囲は0〜500です。
Data: 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.
データ：要求/応答データを含む可変サイズのフィールド。リクエストと応答の場合、オクテットのサイズは、データ項目の数（カウント）の積とデータ項目のサイズ（サイズ）以上でなければなりません。リクエストの場合、データ領域の長さは正確に40オクテットです。応答の場合、データ領域の範囲は0〜500オクテットの範囲です。
Encryption KeyID: 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.
暗号化KeyID：メッセージ認証コードに使用されるキーを指定するために使用される32ビットの符号なし整数。このフィールドは、Aが1に設定されている場合にのみ含まれています。
Message Authentication Code: 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.
メッセージ認証コード：実装フィールドに示されているNTPデーモンのバージョンで定義されたオプションのメッセージ認証コード。このフィールドは、Aが1に設定されている場合にのみ含まれています。
Acknowledgements
謝辞
Tim Plunkett created the original version of this document. Aanchal Malhotra provided the initial version of the Security Considerations section.
Tim Plunkettは、このドキュメントの元のバージョンを作成しました。Aanchal Malhotraは、セキュリティに関する考慮事項セクションの初期バージョンを提供しました。
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.
Karen O'Donoghue、David Hart、Harlan Stenn、およびPhilip Chimentoは、これらのコマンドを文書化する以前の努力により、この文書の一部に功績があります。
Miroshav Lichvar, Ulrich Windl, Dieter Sibold, J Ignacio Alvarez-Hamelin, and Alex Campbell provided valuable comments on various draft versions of this document.
Miroshav Lichvar、Ulrich Windl、Dieter Sibold、J Ignacio Alvarez-Hamelin、およびAlex Campbellは、この文書のさまざまなドラフトバージョンに関する貴重なコメントを提供しました。
Contributors
貢献者
Dr. David Mills specified the vast majority of the mode 6 commands during the development of [RFC1305] and deserves the credit for their existence and use.
David Mills博士は、[RFC1305]の開発中にモード6コマンドの大部分を指定し、その存在と使用に値します。
Author's Address
著者の連絡先
Brian Haberman (editor) JHU Email: brian@innovationslab.net
Brian Haberman（編集者）JHUメール：brian@innovationslab.net