[要約] RFC 6450は、マルチキャストPingプロトコルに関する仕様です。このプロトコルの目的は、ネットワーク上の複数のホストに対して一括でPingを送信することで、ネットワークの状態を監視することです。
Internet Engineering Task Force (IETF) S. Venaas
Request for Comments: 6450 Cisco Systems
Category: Standards Track December 2011
ISSN: 2070-1721
Multicast Ping Protocol
マルチキャストpingプロトコル
Abstract
概要
The Multicast Ping Protocol specified in this document allows for checking whether an endpoint can receive multicast -- both Source-Specific Multicast (SSM) and Any-Source Multicast (ASM). It can also be used to obtain additional multicast-related information, such as multicast tree setup time. This protocol is based on an implementation of tools called "ssmping" and "asmping".
このドキュメントで指定されているマルチキャストPINGプロトコルは、エンドポイントがマルチキャスト（ソース固有のマルチキャスト（SSM）と任意のソースマルチキャスト（ASM）の両方）を受信できるかどうかを確認できます。また、マルチキャストツリーのセットアップ時間など、追加のマルチキャスト関連情報を取得するためにも使用できます。このプロトコルは、「ssmping」と「asmping」と呼ばれるツールの実装に基づいています。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
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). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 5741のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6450.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6450で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Requirements Language ......................................2
2. Architecture ....................................................3
3. Protocol Specification ..........................................6
3.1. Option Format ..............................................7
3.2. Defined Options ............................................7
3.3. Packet Format .............................................13
3.4. Message Types and Options .................................13
3.5. Rate Limiting .............................................15
3.5.1. Message Rate Variables .............................16
4. Client Behaviour ...............................................16
5. Server Behaviour ...............................................18
6. Recommendations for Implementers ...............................19
7. IANA Considerations ............................................20
8. Security Considerations ........................................21
9. Acknowledgments ................................................22
10. References ....................................................23
10.1. Normative References .....................................23
10.2. Informative References ...................................23
The Multicast Ping Protocol specified in this document allows for checking multicast connectivity. In addition to checking reception of multicast (SSM or ASM), the protocol can provide related information, such as multicast tree setup time, the number of hops the packets have traveled, and packet delay and loss. This functionality resembles, in part, the ICMP Echo Request/Reply mechanism [RFC0792], but uses UDP [RFC0768] and requires that both a client and a server implement this protocol. Intermediate routers are not required to support this protocol. They forward protocol messages and data traffic as usual.
このドキュメントで指定されたマルチキャストPINGプロトコルは、マルチキャスト接続を確認できます。マルチキャスト（SSMまたはASM）の受信をチェックすることに加えて、プロトコルは、マルチキャストツリーのセットアップ時間、パケットが移動したホップ数、パケットの遅延と損失などの関連情報を提供できます。この機能は、部分的にはICMPエコー要求/返信メカニズム[RFC0792]に似ていますが、UDP [RFC0768]を使用しており、クライアントとサーバーの両方がこのプロトコルを実装する必要があります。このプロトコルをサポートするために中間ルーターは必要ありません。彼らはいつものようにプロトコルメッセージとデータトラフィックを転送します。
This protocol is based on the current implementation of the ssmping and asmping tools [IMPL], which are widely used by the Internet community to conduct multicast connectivity tests.
このプロトコルは、インターネットコミュニティがマルチキャスト接続テストを実施するために広く使用されているSSMPINGおよびASMPINGツールの現在の実装に基づいています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]で説明されているように解釈されます。
Before describing the protocol in detail, we provide a brief overview of how the protocol may be used and what information it may provide.
プロトコルを詳細に説明する前に、プロトコルの使用方法とそれが提供する情報の簡単な概要を説明します。
The protocol is used between clients and servers to check multicast connectivity. Servers are multicast sources, and clients are multicast receivers. A server may be configured with a set of ranges of multicast addresses that can be used for testing, or it may use some implementation defaults. Depending on the server configuration or the implementation, it may control which clients (which unicast addresses) are allowed to use different group ranges, and also whether clients can select a group address, or if the group address is selected by the server. Whether several clients are allowed to simultaneously use the same multicast address also depends on configuration and/or implementation.
プロトコルは、クライアントとサーバー間で使用され、マルチキャスト接続を確認します。サーバーはマルチキャストソースであり、クライアントはマルチキャストレシーバーです。サーバーは、テストに使用できる一連のマルチキャストアドレスで構成されている場合があります。または、いくつかの実装デフォルトを使用する場合があります。サーバーの構成または実装に応じて、どのクライアント（ユニキャストアドレス）が異なるグループ範囲を使用できるか、またクライアントがグループアドレスを選択できるかどうか、またはグループアドレスがサーバーによって選択されているかどうかを制御できます。複数のクライアントが同じマルチキャストアドレスを同時に使用できるかどうかは、構成および/または実装にも依存します。
In addition to the above state, a server normally has runtime soft state. The server must generally perform rate limiting to restrict the number of client requests it handles. This rate limiting is per-client IP address. This state need usually only be maintained for a few seconds, depending on the limit used. If the server provides unique multicast addresses to clients, it must also have soft state for tracking which multicast addresses are used by which client IP address. This state should expire if the server has not received requests within a few minutes. The exact timeout should ideally be configurable to cope with different environments. If a client is expected to perform multicast ping checks continuously for a long period of time, and to cope with requests not reaching the client for several minutes, then this timeout needs to be extended. In order to verify the client IP address, the server should perform a return routability check by giving the client a non-predictable session ID. This would then also be part of the server soft state for that client.
上記の状態に加えて、サーバーには通常、ランタイムソフト状態があります。通常、サーバーは、処理するクライアント要求の数を制限するためにレート制限を実行する必要があります。このレート制限は、クライアントIPアドレスです。この状態は、通常、使用される制限に応じて数秒間しか維持されません。サーバーがクライアントに一意のマルチキャストアドレスを提供する場合、クライアントIPアドレスで使用されるマルチキャストアドレスを追跡するためのソフト状態も必要です。サーバーが数分以内にリクエストを受信していない場合、この状態は期限切れになります。正確なタイムアウトは、さまざまな環境に対処するために理想的に構成できる必要があります。クライアントがマルチキャストPingチェックを長期間継続的に実行し、数分間クライアントに届かないリクエストに対処することが期待される場合は、このタイムアウトを延長する必要があります。クライアントIPアドレスを確認するために、サーバーは、クライアントに予測不可能なセッションIDを提供して、返信可能性チェックを実行する必要があります。これは、そのクライアントのサーバーソフトステートの一部にもなります。
Before it can perform a multicast ping test, a client must know the unicast address of a server. In addition, it may be configured with a multicast address or range to use. In that case, the client will tell the server which group or range it wishes to use. If not, the server is left to decide the group. Normally, a client sends Default-Client-Request-Rate requests per second. It may, however, be configured to use another rate. See the definition of Default-Client-Request-Rate in Section 3.5.1. Note that the value can be less than 1.
マルチキャストPingテストを実行する前に、クライアントはサーバーのユニキャストアドレスを知っている必要があります。さらに、使用するマルチキャストアドレスまたは範囲で構成される場合があります。その場合、クライアントは、使用したいグループまたは範囲をサーバーに指示します。そうでない場合、サーバーはグループを決定するために残されています。通常、クライアントはデフォルトクライアントリクエストレートリクエストを1秒あたり送信します。ただし、別のレートを使用するように構成されている場合があります。セクション3.5.1のデフォルトクライアントレクエストレートの定義を参照してください。値は1未満になる可能性があることに注意してください。
At runtime, a client generates a client ID that is unique for the ping test. This ID is included in all messages sent by the client. Further, if not supplied with a specific group address, the client will receive from the server a group address that is used for the ping requests. It may also receive a Session ID from the server. The client ID, group address, and Session ID (if received) will then be fixed for all ping requests in this session. When a client receives replies from a server, it will verify the client ID in the reply, and ignore it if not matching what it used in the requests. For each reply, it may print or record information like round trip time, number of hops, etc. The client may, once a ping session is ended, calculate and print or record statistics based on the entire ping session.
実行時に、クライアントはPingテストに一意のクライアントIDを生成します。このIDは、クライアントが送信したすべてのメッセージに含まれています。さらに、特定のグループアドレスが提供されていない場合、クライアントはサーバーからPINGリクエストに使用されるグループアドレスを受け取ります。また、サーバーからセッションIDを受信する場合があります。クライアントID、グループアドレス、およびセッションID（受信した場合）は、このセッションのすべてのPingリクエストに対して修正されます。クライアントがサーバーから返信を受信すると、返信のクライアントIDが確認され、リクエストで使用されているものと一致しない場合は無視します。返信ごとに、往復時間、ホップ数などの情報を印刷または記録できます。クライアントは、Pingセッションが終了したら、Pingセッション全体に基づいて統計を計算および印刷または記録することができます。
The typical protocol usage is as follows:
典型的なプロトコルの使用は次のとおりです。
A server runs continuously to serve requests from clients. A client has somehow learned the unicast address of the server and tests the multicast reception from the server.
サーバーは継続的に実行され、クライアントからのリクエストを提供します。クライアントは、何らかの形でサーバーのユニキャストアドレスを学習し、サーバーからのマルチキャストレセプションをテストしました。
The client application will then send a unicast message to the server, asking for a group to use. Optionally, a user may request a specific group or scope, in which case the client will ask for a group matching the user's request. The server will respond with a group to use, or an error if no group is available.
クライアントアプリケーションは、ユニキャストメッセージをサーバーに送信し、グループを使用するように要求します。オプションで、ユーザーは特定のグループまたはスコープを要求する場合があります。その場合、クライアントはユーザーのリクエストに一致するグループを要求します。サーバーは、使用するグループで応答し、グループが利用できない場合はエラーに応答します。
Next, for ASM, the client joins an ASM group G, while for SSM it joins a channel (S,G), where G is the multicast group address specified by the server, and S is the unicast address used to reach the server.
次に、ASMの場合、クライアントはASMグループGに参加しますが、SSMの場合、チャネル（S、G）に結合します。Gはサーバーで指定されたマルチキャストグループアドレス、Sはサーバーに到達するために使用されるユニキャストアドレスです。
After joining the group/channel, the client unicasts multicast ping requests to the server. The requests are sent using UDP with the destination port set to the standardised multicast ping port (9903). The requests are sent periodically to the server. The rate is by default Default-Client-Request-Rate (Section 3.5.1) requests per second, but the client may be configured to use another rate. These requests contain a sequence number and, typically, a timestamp. The requests are echoed by the server, which may add a few options.
グループ/チャネルに参加した後、クライアントはマルチキャストPINGリクエストをサーバーにユニカストします。リクエストは、標準化されたマルチキャストPingポート（9903）に設定されている宛先ポートを使用してUDPを使用して送信されます。リクエストは定期的にサーバーに送信されます。レートは、デフォルトでデフォルトクライアントレクストレート（セクション3.5.1）要求であるが、クライアントは別のレートを使用するように構成されている場合があります。これらの要求には、シーケンス番号と通常、タイムスタンプが含まれています。リクエストはサーバーによって反映されているため、いくつかのオプションが追加される場合があります。
For each request, the server sends two replies. One reply is unicast to the source IP address and source UDP port of the requesting client. The other reply is multicast to the requested multicast group G and the source UDP port of the requesting client.
要求ごとに、サーバーは2つの返信を送信します。1つの返信は、ソースIPアドレスへのユニキャストと、リクエストクライアントのソースUDPポートです。もう1つの返信は、要求されたマルチキャストグループGおよびリクエストクライアントのソースUDPポートへのマルチキャストです。
Both replies are sent from the same port on which the request was received. The server should specify the TTL (IPv4 time-to-live or IPv6 hop-count) used for both the unicast and multicast messages (TTL of at least 64 is recommended) by including a TTL option. This allows the client to compute the number of hops. The client should leave the group/channel when it has finished its measurements.
両方の返信は、リクエストが受信された同じポートから送信されます。サーバーは、TTLオプションを含めることにより、ユニキャストメッセージとマルチキャストメッセージ（少なくとも64のTTLが推奨される）に使用されるTTL（IPv4 Time-to-LiveまたはIPv6 Hop-Count）を指定する必要があります。これにより、クライアントはホップ数を計算できます。クライアントは、測定が終了したら、グループ/チャネルを離れる必要があります。
By use of this protocol, a client (or a user of the client) can obtain information about several multicast delivery characteristics. First, by receiving unicast replies, the client can verify that the server is receiving the unicast requests, and is operational and responding. Hence, provided that the client receives unicast replies, a failure to receive multicast indicates either a multicast problem or a multicast administrative restriction. If it does receive multicast, it knows not only that it can receive multicast traffic but that it may also estimate the amount of time it took to establish the multicast tree (at least if it is in the range of seconds), whether there are packet drops, and the length and variation of round trip times (RTTs).
このプロトコルを使用することにより、クライアント（またはクライアントのユーザー）は、いくつかのマルチキャスト配信特性に関する情報を取得できます。まず、ユニキャストの返信を受信することにより、クライアントはサーバーがユニキャスト要求を受信していることを確認でき、動作して応答しています。したがって、クライアントがユニキャスト応答を受信した場合、マルチキャストの受信の失敗は、マルチキャストの問題またはマルチキャストの管理制限のいずれかを示します。マルチキャストを受け取っている場合、マルチキャストトラフィックを受けることができるだけでなく、マルチキャストツリーを確立するのにかかった時間（少なくとも秒の範囲の場合）を推定する可能性があることを知っています。ドロップ、および往復時間（RTT）の長さとバリエーション。
For unicast, the RTT is the time from when the unicast request is sent to the time when the reply is received. The measured multicast RTT also references the client's unicast request. By specifying the TTL of the replies when they are originated, the client can also determine the number of router hops it is from the source. Since similar information is obtained in the unicast replies, the host may compare its multicast and unicast results and is able to check for differences, such as the number of hops, and RTT.
ユニキャストの場合、RTTは、Unicastリクエストが返信を受信した時期に送信される時期からです。測定されたマルチキャストRTTは、クライアントのユニキャスト要求も参照しています。応答が発生したときにTTLを指定することにより、クライアントはソースからのルーターホップの数を決定することもできます。ユニキャスト応答で同様の情報が取得されるため、ホストはマルチキャストとユニキャストの結果を比較し、ホップ数やRTTなどの違いを確認できます。
The number of multicast hops and changes in the number of hops over time may reveal details about the multicast tree and multicast tree changes. Provided that the server sends the unicast and multicast replies nearly simultaneously, the client may also be able to measure the difference in one-way delay for unicast and multicast on the path from server to client.
マルチキャストホップの数と時間の経過に伴うホップ数の変化は、マルチキャストツリーとマルチキャストツリーの変更に関する詳細を明らかにする場合があります。サーバーがユニキャストとマルチキャストの応答をほぼ同時に送信すると、クライアントは、サーバーからクライアントへのパス上のユニキャストとマルチキャストの一方向遅延の違いを測定することもできます。
Servers may optionally specify a timestamp. This may be useful, since the unicast and multicast replies cannot be sent simultaneously (the delay is dependent on the host's operating system and load).
サーバーはオプションでタイムスタンプを指定できます。ユニキャストとマルチキャストの応答を同時に送信できないため、これは有用かもしれません（遅延はホストのオペレーティングシステムと負荷に依存します）。
There are four different message types:
4つの異なるメッセージタイプがあります。
o Echo Request and Echo Reply messages, which are used for the actual measurements.
o 実際の測定に使用されるエコーリクエストとエコー応答メッセージ。
o An Init message, which SHOULD be used to initialise a ping session and negotiate which group to use.
o Pingセッションの初期化と使用するグループをネゴシエートするために使用する必要があるINITメッセージ。
o A Server Response message, which is mainly used in response to the Init message.
o 主にinitメッセージに応じて使用されるサーバー応答メッセージ。
The messages MUST always be in network byte order. UDP checksums MUST always be used.
メッセージは常にネットワークバイトの順序である必要があります。UDPチェックサムは常に使用する必要があります。
The messages share a common format: one octet specifying the message type, followed by a number of options in TLV (Type, Length, and Value) format. This makes the protocol easily extendible.
メッセージは共通の形式を共有します。メッセージタイプを指定する1つのオクテット、その後、TLV（タイプ、長さ、および値）形式の多くのオプションが続きます。これにより、プロトコルが簡単に拡張可能になります。
Message types in the range 0-253 are reserved and available for allocation in an IANA registry. Message types 254 and 255 are freely available for experimental use. See Section 7.
範囲0-253のメッセージタイプは予約されており、IANAレジストリでの割り当てに使用できます。メッセージタイプ254および255は、実験的に使用できるように自由に利用できます。セクション7を参照してください。
The Init message generally contains some prefix options asking the server for a group from one of the specified prefixes. The server responds with a Server Response message that contains the group address to use, or possibly prefix options describing what multicast groups the server may be able to provide.
INITメッセージには、通常、指定されたプレフィックスの1つからグループをサーバーに求めるいくつかのプレフィックスオプションが含まれています。サーバーは、使用するグループアドレスを含むサーバー応答メッセージ、またはサーバーが提供できるマルチキャストグループを説明するプレフィックスオプションで応答します。
For an Echo Request, the client includes a number of options, and a server MAY simply echo the contents (only changing the message type) without inspecting the options if it does not support any options. This might be true for a simple Multicast Ping Protocol server, but it severely limits what information a client can obtain and hence makes the protocol less useful. However, the server SHOULD add a TTL option (allowing the client to determine the number of router hops a reply has traversed), and there are other options that a server implementation MAY support; e.g., the client may ask for certain information or a specific behaviour from the server. The Echo Reply messages (one unicast and one multicast) MUST first contain the exact options from the request (in the same order), and then, immediately following, any options appended by the server. A server MUST NOT process unknown options, but they MUST still be included in the Echo Reply. A client MUST ignore any unknown options.
エコーリクエストの場合、クライアントには多くのオプションが含まれており、サーバーは、オプションがサポートされていない場合、オプションを検査せずにコンテンツを単にエコー（メッセージタイプのみを変更する）だけです。これは、単純なマルチキャストPingプロトコルサーバーに当てはまるかもしれませんが、クライアントが取得できる情報を厳しく制限するため、プロトコルの有用性が低下します。ただし、サーバーはTTLオプションを追加する必要があります（クライアントが応答が横ばいになっているルーターホップの数を決定できるようにします）。また、サーバーの実装がサポートできる他のオプションがあります。たとえば、クライアントは、サーバーから特定の情報または特定の動作を要求する場合があります。エコー応答メッセージ（1つのユニキャストと1つのマルチキャスト）には、最初にリクエストからの正確なオプション（同じ順序）を含める必要があります。次に、サーバーによって追加されたオプションをすぐに含める必要があります。サーバーは不明なオプションを処理してはなりませんが、エコー応答に含まれる必要があります。クライアントは、未知のオプションを無視する必要があります。
The size of the protocol messages is generally smaller than the Path MTU, and fragmentation is not a concern. There may, however, be cases where the Path MTU is really small, or where a client sends large requests in order to verify that it can receive fragmented multicast datagrams. This document does not specify whether Path MTU Discovery should be performed, etc. A possible extension could be an option where a client requests Path MTU Discovery and receives the current Path MTU from the server.
プロトコルメッセージのサイズは一般にPath MTUよりも小さく、断片化は懸念事項ではありません。ただし、パスMTUが本当に小さい場合、またはクライアントが断片化されたマルチキャストデータグラムを受信できることを確認するために、クライアントが大きなリクエストを送信する場合があります。このドキュメントでは、Path MTU発見を実行する必要があるかどうかなどを指定しません。可能な拡張機能は、クライアントがPATH MTUディスカバリーを要求し、サーバーから現在のPATH MTUを受信するオプションになる可能性があります。
This document defines a number of different options. Some options do not require processing by servers and are simply returned unmodified in the reply. There are, however, other client options that the server may care about, as well as server options that may be requested by a client. Unless otherwise specified, an option MUST NOT be used multiple times in the same message.
このドキュメントでは、さまざまなオプションを定義しています。一部のオプションでは、サーバーによる処理を必要とせず、返信で単に変更されていません。ただし、サーバーが気にする他のクライアントオプションや、クライアントが要求するサーバーオプションがあります。特に指定されていない限り、同じメッセージでオプションを複数回使用してはなりません。
All options are TLVs formatted as below.
すべてのオプションは、以下のようにTLVSフォーマットされています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value |
| . |
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type (2 octets) specifies the option.
タイプ（2オクテット）オプションを指定します。
Length (2 octets) specifies the length of the value field. Depending on the option type, it can be from 0 to 65535.
長さ（2オクテット）は、値フィールドの長さを指定します。オプションタイプに応じて、0〜65535になります。
Value must always be of the specified length. See the respective option definitions for possible values. If the length is 0, the value field is not included.
値は常に指定された長さでなければなりません。可能な値については、それぞれのオプション定義を参照してください。長さが0の場合、値フィールドは含まれていません。
This document defines the following options: Version (0), Client ID (1), Sequence Number (2), Client Timestamp (3), Multicast Group (4), Option Request (5), Server Information (6), TTL (9), Multicast Prefix (10), Session ID (11), and Server Timestamp (12). Option values 7 and 8 are deprecated and must not be allocated by any future document. The options are defined below.
このドキュメントでは、次のオプションを定義します。バージョン（0）、クライアントID（1）、シーケンス番号（2）、クライアントタイムスタンプ（3）、マルチキャストグループ（4）、オプションリクエスト（5）、サーバー情報（6）、TTL（9）、マルチキャストプレフィックス（10）、セッションID（11）、およびサーバータイムスタンプ（12）。オプション値7と8は非推奨であり、将来のドキュメントで割り当てられてはなりません。オプションは以下に定義されています。
Option types in the range 0-65531 are reserved and available for allocation in an IANA registry. Option types in the range 65532-65535 are not registered and are freely available for experimental use. See Section 7.
範囲0-65531のオプションタイプは予約されており、IANAレジストリでの割り当てに使用できます。範囲65532-65535のオプションタイプは登録されておらず、実験的に使用できるように自由に利用できます。セクション7を参照してください。
Version, type 0
バージョン、タイプ0
Length MUST be 1. This option MUST always be included in all messages, and for the current specified protocol this value MUST be set to 2 (in decimal). Note that there are implementations of older revisions of this protocol that only partly follow this specification. They can be regarded as version 1 and do not use this option. If a server receives a message with a version other than 2 (or missing), the server SHOULD (unless it supports the particular version) send a Server Response message back with version set to 2. This tells the client that the server expects version 2 messages. Client ID and Sequence Number options MUST be echoed if present, so that a client can be certain it is a response to one of its messages, and to exactly which message. The server SHOULD NOT include any other options. A client receiving a response with a version other than 2 MUST stop sending requests to the server (unless it supports the particular version).
長さは1でなければなりません。このオプションは常にすべてのメッセージに含める必要があり、現在の指定されたプロトコルの場合、この値は2（小数で）に設定する必要があります。この仕様に一部従うだけで、このプロトコルの古い改訂版の実装があることに注意してください。それらはバージョン1と見なすことができ、このオプションを使用しません。サーバーが2以外のバージョン（または欠落）を含むメッセージを受信した場合、サーバーは（特定のバージョンをサポートしない限り）2に設定されたバージョンでサーバーの応答メッセージを送信する必要があります。メッセージ。クライアントが存在する場合は、クライアントIDおよびシーケンス番号オプションをエコーする必要があります。これにより、クライアントはメッセージの1つであり、正確なメッセージへの応答であることを確認できます。サーバーには、他のオプションを含めるべきではありません。2以外のバージョンで応答を受信するクライアントは、サーバーにリクエストの送信を停止する必要があります（特定のバージョンをサポートしない限り）。
Client ID, type 1
クライアントID、タイプ1
Length MUST be non-zero. A client SHOULD always include this option in all messages (both Init and Echo Request). The client may use any value it likes to detect whether a reply is a reply to its Init/Echo Request or not. A server should treat this as opaque data, and MUST echo this option back in the reply if present (both Server Response and Echo Reply). The value might be a pseudo-random byte string that is likely to be unique, possibly combined with the client IP address. Predictability is not a big concern here. This is used by the client to ensure that server messages are in response to its requests. In some cases, a client may receive multicast responses to queries from other clients. It is left to the client implementer how to use this option.
長さはゼロ以外でなければなりません。クライアントは、常にすべてのメッセージにこのオプションを含める必要があります（initとechoリクエストの両方）。クライアントは、返信がinit/echoリクエストへの返信であるかどうかを検出するのが好きな値を使用できます。サーバーはこれを不透明なデータとして扱う必要があり、存在する場合はこのオプションを返信に戻す必要があります（サーバーの応答とエコー応答の両方）。値は、クライアントIPアドレスと組み合わされる可能性が高い可能性が高い擬似ランダムバイト文字列である可能性があります。ここでは、予測可能性は大きな懸念ではありません。これは、クライアントがサーバーメッセージがリクエストに応じて確実に行われるようにするために使用されます。場合によっては、クライアントが他のクライアントからのクエリに対するマルチキャスト応答を受け取ることがあります。クライアントの実装者にこのオプションの使用方法を任せます。
Sequence Number, type 2
シーケンス番号、タイプ2
Length MUST be 4. A client MUST always include this in Echo Request messages and MUST NOT include it in Init messages. A server replying to an Echo Request message MUST copy it into the Echo Reply (or Server Response message on error). The sequence number is a 32-bit integer. Values typically start at 1 and increase by one for each Echo Request in a sequence.
長さは4でなければなりません。クライアントは常にこれをエコーリクエストメッセージに含める必要があり、initメッセージにそれを含めてはなりません。エコーリクエストメッセージに返信するサーバーは、それをエコー返信（またはエラー時にサーバー応答メッセージ）にコピーする必要があります。シーケンス番号は32ビット整数です。通常、値は1から始まり、シーケンスでエコー要求ごとに1つ増加します。
Client Timestamp, type 3
クライアントタイムスタンプ、タイプ3
Length MUST be 8. A client SHOULD include this in Echo Request messages and MUST NOT include it in Init messages. A server replying to an Echo Request message MUST copy it into the Echo Reply. The timestamp specifies the time when the Echo Request message is sent. The first 4 bytes specify the number of seconds since the Epoch (0000 UTC Jan 1, 1970). The next 4 bytes specify the number of microseconds since the second specified in the first 4 bytes. This option would typically be used by a client to compute round trip times.
長さは8でなければなりません。クライアントはこれをエコーリクエストメッセージに含める必要があり、initメッセージにそれを含めてはなりません。エコーリクエストメッセージに返信するサーバーは、それをエコー返信にコピーする必要があります。タイムスタンプは、エコーリクエストメッセージが送信される時間を指定します。最初の4バイトでは、エポック以来の秒数を指定します（0000 UTC 1970年1月1日）。次の4バイトでは、最初の4バイトで指定された2番目のバイト以降のマイクロ秒数を指定します。このオプションは通常、クライアントが往復時間を計算するために使用します。
Note that while this protocol uses the above 32-bit format, it would have been better to use another format, such as the one defined in NTPv4 [RFC5905]. This should be considered for future extensions of the protocol.
このプロトコルは上記の32ビット形式を使用しますが、NTPV4 [RFC5905]で定義されているものなど、別の形式を使用する方が良いでしょう。これは、プロトコルの将来の拡張で考慮する必要があります。
Multicast Group, type 4
マルチキャストグループ、タイプ4
Length MUST be greater than 2. It MAY be used in Server Response messages to tell the client what group to use in subsequent Echo Request messages. It MUST be used in Echo Request messages to tell the server what group address to respond to (this group would typically be previously obtained in a Server Response message). It MUST be used in Echo Reply messages (copied from the Echo Request message). It MUST NOT be used in Init messages. The format of the option value is as below.
長さは2を超える必要があります。サーバー応答メッセージで使用して、後続のエコーリクエストメッセージで使用するグループをクライアントに伝えることができます。エコーリクエストメッセージで使用する必要があります。サーバーに応答するグループアドレスを伝える必要があります（このグループは通常、サーバー応答メッセージで以前に取得されます）。Echo Replyメッセージ（Echo要求メッセージからコピーされた）で使用する必要があります。initメッセージで使用してはなりません。オプション値の形式は以下のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Family | Multicast group address... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .... |
The address family is a value 0-65535 as assigned by IANA for Internet address families [ADDRFAMILY]. This is followed by the group address. Length of the option value will be 6 for IPv4, and 18 for IPv6.
アドレスファミリは、INAがインターネットアドレスファミリに割り当てた値0-65535です[Addrfamily]。これに続いて、グループアドレスが続きます。オプション値の長さは、IPv4の場合は6、IPv6の場合は18です。
Option Request, type 5
オプションリクエスト、タイプ5
Length MUST be greater than 1. This option MAY be used in client messages (Init and Echo Request messages). A server MUST NOT send this option, except that if it is present in an Echo Request message, the server MUST echo it in replies (Echo Reply message) to the Echo Request. This option contains a list of option types for options that the client is requesting
長さは1より大きくなければなりません。このオプションは、クライアントメッセージ（initおよびecho要求メッセージ）で使用できます。サーバーはこのオプションを送信してはなりませんが、エコーリクエストメッセージに存在する場合、サーバーはエコーリクエストへの返信（エコー応答メッセージ）にエコーする必要があります。このオプションには、クライアントが要求しているオプションのオプションタイプのリストが含まれています
from the server. Support for this option is OPTIONAL for both clients and servers. The length of this option will be a non-zero even number, since it contains one or more option types that are two octets each. The format of the option value is as below.
サーバーから。このオプションのサポートは、クライアントとサーバーの両方でオプションです。このオプションの長さは、それぞれ2オクテットの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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ..... |
This option might be used by the client to ask the server to include options like Server Timestamp or Server Information. A client MAY request Server Information in Init messages; it MUST NOT request it in other messages. A client MAY request a Server Timestamp in Echo Request messages; it MUST NOT request it in other messages. Subject to enforcing the above restrictions, a server supporting this option SHOULD include the requested options in responses (Echo Reply messages) to the Echo Request containing the Option Request option. The server may, according to implementation or local configuration, not necessarily include all the requested options, or possibly none. Any options included are appended to the echoed options, similar to other options included by the server.
このオプションは、サーバーにサーバーのタイムスタンプやサーバー情報などのオプションを含めるようサーバーに依頼するために使用される場合があります。クライアントは、initメッセージのサーバー情報を要求できます。他のメッセージで要求してはなりません。クライアントは、エコーリクエストメッセージのサーバータイムスタンプを要求する場合があります。他のメッセージで要求してはなりません。上記の制限を実施する場合、このオプションをサポートするサーバーには、オプションリクエストオプションを含むエコーリクエストへの応答（エコー応答メッセージ）に要求されたオプションを含める必要があります。サーバーは、実装またはローカル構成に応じて、必ずしもすべての要求されたオプションが含まれているわけではなく、おそらく何も含まれない場合があります。含まれるオプションは、サーバーに含まれる他のオプションと同様に、エコーされたオプションに追加されます。
Server Information, type 6
サーバー情報、タイプ6
Length MUST be non-zero. It MAY be used in Server Response messages and MUST NOT be used in other messages. Support for this option is OPTIONAL. A server supporting this option SHOULD add it in Server Response messages if and only if requested by the client. The value is a UTF-8 [RFC3629] string that might contain vendor and version information for the server implementation. It may also contain information on which options the server supports. An interactive client MAY support this option, and SHOULD then allow a user to request this string and display it. Although support for this is OPTIONAL, we say that a server SHOULD return it if requested, since this may be helpful to a user running the client. It is, however, purely informational; it is not needed for the protocol to function.
長さはゼロ以外でなければなりません。サーバー応答メッセージで使用される場合があり、他のメッセージで使用してはなりません。このオプションのサポートはオプションです。このオプションをサポートするサーバーは、クライアントが要求した場合にのみ、サーバー応答メッセージに追加する必要があります。値は、サーバーの実装のベンダーとバージョン情報を含む可能性のあるUTF-8 [RFC3629]文字列です。また、サーバーがサポートするオプションに関する情報も含まれている場合があります。インタラクティブなクライアントがこのオプションをサポートし、ユーザーがこの文字列を要求して表示できるようにする必要があります。これのサポートはオプションですが、クライアントを実行しているユーザーに役立つ可能性があるため、サーバーは要求された場合にそれを返す必要があると言います。しかし、それは純粋に情報です。プロトコルが機能する必要はありません。
Deprecated, type 7
非推奨、タイプ7
This option code value was used by implementations of version 1 of this protocol, and is not used in this version. Servers MUST treat it as an unknown option (not process it if received, but if received in an Echo Request message, it MUST be echoed in the Echo Reply message).
このオプションコード値は、このプロトコルのバージョン1の実装で使用され、このバージョンでは使用されません。サーバーはそれを未知のオプションとして扱う必要があります（受信した場合は処理しませんが、エコーリクエストメッセージで受信した場合は、echo返信メッセージでエコーする必要があります）。
Deprecated, type 8
非推奨、タイプ8
This option code value was used by implementations of version 1 of this protocol, and is not used in this version. Servers MUST treat it as an unknown option (not process it if received, but if received in an Echo Request message, it MUST be echoed in the Echo Reply message).
このオプションコード値は、このプロトコルのバージョン1の実装で使用され、このバージョンでは使用されません。サーバーはそれを未知のオプションとして扱う必要があります（受信した場合は処理しませんが、エコーリクエストメッセージで受信した場合は、echo返信メッセージでエコーする必要があります）。
TTL, type 9
TTL、タイプ9
Length MUST be 1. This option contains a single octet specifying the TTL of an Echo Reply message. Every time a server sends a unicast or multicast Echo Reply message, it SHOULD include this option specifying the TTL. This is used by clients to determine the number of hops the messages have traversed. It MUST NOT be used in other messages. A server SHOULD specify this option if it knows what the TTL of the Echo Reply will be. In general, the server can specify a specific TTL to the host stack. Note that the TTL is not necessarily the same for unicast and multicast. Also note that this option SHOULD be included even when not requested by the client. The protocol will work even if this option is not included, but it limits what information a client can obtain.
長さは1でなければなりません。このオプションには、エコー応答メッセージのTTLを指定する単一のオクテットが含まれています。サーバーがユニキャストまたはマルチキャストエコー応答メッセージを送信するたびに、TTLを指定するこのオプションを含める必要があります。これは、メッセージが横断したホップの数を決定するためにクライアントが使用します。他のメッセージで使用してはなりません。サーバーは、エコー応答のTTLがどうなるかを知っている場合、このオプションを指定する必要があります。一般に、サーバーはホストスタックに特定のTTLを指定できます。TTLは、ユニキャストとマルチキャストで必ずしも同じではないことに注意してください。また、クライアントから要求されていない場合でも、このオプションを含める必要があることに注意してください。このオプションが含まれていなくても、プロトコルは機能しますが、クライアントが取得できる情報が制限されます。
If the server did not include this TTL option, there is no reliable way for the client to know the initial TTL of the Echo Reply, and therefore the client SHOULD NOT attempt to calculate the number of hops the message has traversed.
サーバーにこのTTLオプションが含まれていなかった場合、クライアントがECHO応答の初期TTLを知る信頼できる方法はありません。したがって、クライアントはメッセージが通過したホップの数を計算しようとしてはなりません。
Multicast Prefix, type 10
マルチキャストプレフィックス、タイプ10
Length MUST be greater than 2. It MAY be used in Init messages to request a group within the prefix(es), and it MAY be used in Server Response messages to tell the client from what prefix(es) it may try to obtain a group. It MUST NOT be used in Echo Request/Reply messages. Note that this option MAY be included multiple times to specify multiple prefixes.
長さは2より大きくする必要があります。INITメッセージでプレフィックス内のグループをリクエストするために使用できます。また、サーバー応答メッセージで使用して、プレフィックス（ES）からクライアントに伝えることができます。グループ。エコーリクエスト/返信メッセージで使用してはなりません。このオプションは、複数のプレフィックスを指定するために複数回含めることができることに注意してください。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Family | Prefix Length |Partial address|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .... |
The address family is a value 0-65535 as assigned by IANA for Internet address families [ADDRFAMILY]. This is followed by a prefix length (4-32 for IPv4, 8-128 for IPv6, or 0 for the special "wildcard" use discussed below), and finally a group address. For any family, prefix length 0 means that any multicast address from that family is acceptable. This is what we call "wildcard". The group address need only contain enough octets to cover the prefix length bits (i.e., the group address would have to be 3 octets long if the prefix length is 17-24, and there need be no group address for the wildcard with prefix length 0). Any bits past the prefix length MUST be ignored. For IPv4, the option value length will be 4-7, while for IPv6, it will be 4-19, and for the wildcard, it will be 3.
アドレスファミリは、INAがインターネットアドレスファミリに割り当てた値0-65535です[Addrfamily]。これに続いて、プレフィックスの長さ（IPv4の場合は4-32、IPv6の場合は8-128、または以下で説明する特別な「ワイルドカード」使用の場合は0）、最後にグループアドレスが続きます。家族の場合、プレフィックスの長さ0は、その家族からのマルチキャストアドレスが許容できることを意味します。これは私たちが「ワイルドカード」と呼ぶものです。グループアドレスには、プレフィックスの長さビットをカバーするのに十分なオクテットを含む必要があります（つまり、接頭辞の長さが17-24の場合、グループアドレスは3オクテットである必要があり、プレフィックス長さ0のワイルドカードのグループアドレスは必要ありません）。プレフィックスの長さを超えるビットは無視する必要があります。IPv4の場合、オプション値の長さは4〜7になりますが、IPv6の場合は4〜19になり、ワイルドカードの場合は3になります。
Session ID, type 11
セッションID、タイプ11
Length MUST be 4 or larger. A server SHOULD include this in Server Response messages. If a client receives this option in a message, the client MUST echo the Session ID option in subsequent Echo Request messages, with the exact same value. The Session ID may help the server in keeping track of clients and possibly manage per-client state. The value of a new Session ID SHOULD be a pseudo-random byte string that is hard to predict; see [RFC4086]. The string MUST be at least 4 bytes long. The Session ID can be used to mitigate spoofing of the source address of Echo Request messages. We say that this option SHOULD be used, because it is important for security reasons. There may, however, be environments where this is not required. See Section 8, "Security Considerations", for details.
長さは4以上でなければなりません。サーバーは、これをサーバー応答メッセージに含める必要があります。クライアントがメッセージでこのオプションを受信した場合、クライアントは、まったく同じ値で、後続のエコーリクエストメッセージでセッションIDオプションをエコーする必要があります。セッションIDは、サーバーがクライアントを追跡し、クライアントごとの状態を管理するのに役立ちます。新しいセッションIDの値は、予測するのが難しい擬似ランダムバイト文字列である必要があります。[RFC4086]を参照してください。文字列の長さは少なくとも4バイトでなければなりません。セッションIDを使用して、エコーリクエストメッセージのソースアドレスのスプーフィングを軽減できます。セキュリティ上の理由で重要であるため、このオプションを使用する必要があると言います。ただし、これには不要な環境がある場合があります。詳細については、セクション8「セキュリティ上の考慮事項」を参照してください。
Server Timestamp, type 12
サーバータイムスタンプ、タイプ12
Length MUST be 8 bytes. A server supporting this option SHOULD include it in Echo Reply messages, if requested by the client. The timestamp specifies the time when the Echo Reply message is sent. The first 4 bytes specify the number of seconds since the Epoch (0000 UTC Jan 1, 1970). The next 4 bytes specify the number of microseconds since the second specified in the first 4 bytes. If this option is not included, the protocol will still work, but it makes it impossible for a client to compute one-way delay.
長さは8バイトでなければなりません。このオプションをサポートするサーバーには、クライアントが要求した場合、エコー応答メッセージに含める必要があります。タイムスタンプは、エコー応答メッセージが送信される時間を指定します。最初の4バイトでは、エポック以来の秒数を指定します（0000 UTC 1970年1月1日）。次の4バイトでは、最初の4バイトで指定された2番目のバイト以降のマイクロ秒数を指定します。このオプションが含まれていない場合、プロトコルは引き続き機能しますが、クライアントが一元配置遅延を計算することは不可能になります。
Note that while this protocol uses the above 32-bit format, it would have been better to use another format, such as the one defined in NTPv4 [RFC5905]. This should be considered for future extensions of the protocol.
このプロトコルは上記の32ビット形式を使用しますが、NTPV4 [RFC5905]で定義されているものなど、別の形式を使用する方が良いでしょう。これは、プロトコルの将来の拡張で考慮する必要があります。
The format of all messages is a one-octet message type, followed by a variable number of options.
すべてのメッセージの形式は、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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Options ... |
+-+-+-+-+-+-+-+-+ . |
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- .....
There are four message types defined. Type 81 (the character Q in ASCII) specifies an Echo Request (Query). Type 65 (the character A in ASCII) specifies an Echo Reply (Answer). Type 73 (the character I in ASCII) is an Init message. Type 83 (the character S in ASCII) is a Server Response message.
定義された4つのメッセージタイプがあります。タイプ81（ASCIIの文字Q）は、エコー要求（クエリ）を指定します。タイプ65（ASCIIの文字A）は、エコーの応答（回答）を指定します。タイプ73（ASCIIの文字I）はINITメッセージです。タイプ83（ASCIIの文字S）はサーバー応答メッセージです。
The options immediately follow the type octet and are not aligned in any way (no spacing or padding); i.e., options might start at any octet boundary. The option format is specified above.
オプションはタイプのオクテットに続き、決して間隔やパディングはありません）。つまり、オプションは任意のオクテットの境界で始まる場合があります。オプション形式は上記で指定されています。
We will now describe each of the four message types and which options they may contain.
次に、4つのメッセージタイプのそれぞれと、それらに含まれる可能性のあるオプションについて説明します。
Init, type 73
init、タイプ73
This message is sent by a client to request information from a server. It is mainly used for requesting a group address, but it may also be used to check which group prefixes the server may provide groups from, or other server information. It MUST include a Version option, and SHOULD include a Client ID. It MAY include Option Request and Multicast Prefix options. This message is a request for a group address if and only if it contains Multicast Prefix options. If multiple Prefix options are included, they should be in prioritised order. That is, the server will consider the prefixes in the order they are specified, and if it finds a group for a prefix, it will only return that one group, not considering the remaining prefixes.
このメッセージは、サーバーから情報を要求するためにクライアントによって送信されます。これは主にグループアドレスを要求するために使用されますが、サーバーがグループまたは他のサーバー情報を提供できるグループのプレフィックスを確認するためにも使用される場合があります。バージョンオプションを含める必要があり、クライアントIDを含める必要があります。オプションリクエストとマルチキャストプレフィックスオプションが含まれる場合があります。このメッセージは、マルチキャストプレフィックスオプションが含まれている場合にのみ、グループアドレスのリクエストです。複数のプレフィックスオプションが含まれている場合、それらは優先順位付けされている必要があります。つまり、サーバーは指定された順序でプレフィックスを考慮し、プレフィックスのグループを見つけた場合、残りのプレフィックスを考慮せずにその1つのグループのみを返します。
Server Response, type 83
サーバーの応答、タイプ83
This message is sent by a server, either as a response to an Init, or in response to an Echo Request. When responding to an Init, it may provide the client with a multicast group (if requested by the client), or it may provide other server information. In response to an Echo Request, the message tells the client to stop sending Echo Request messages. The Version option MUST always be included. Client ID and Sequence Number options are echoed if present in the client message. When providing a group to the client, it includes a Multicast Group option. It SHOULD include Server Information and Prefix options if requested. It SHOULD also include the Session ID option.
このメッセージは、initへの応答として、またはエコーリクエストへの応答として、サーバーによって送信されます。INITに応答する場合、クライアントにマルチキャストグループ（クライアントが要求した場合）を提供するか、他のサーバー情報を提供する場合があります。エコーリクエストに応じて、メッセージはクライアントにエコーリクエストメッセージの送信を停止するように指示します。バージョンオプションは常に含める必要があります。クライアントメッセージとシーケンス番号オプションは、クライアントメッセージに存在する場合にエコーされます。クライアントにグループを提供する場合、マルチキャストグループオプションが含まれます。要求された場合、サーバー情報とプレフィックスオプションを含める必要があります。また、セッションIDオプションを含める必要があります。
Echo Request, type 81
エコーリクエスト、タイプ81
This message is sent by a client, asking the server to send unicast and multicast Echo Reply messages. It MUST include Version, Sequence Number, and Multicast Group options. If a Session ID was received in a Server Response message, then the Session ID MUST be included. It SHOULD include Client ID and Client Timestamp options. It MAY include an Option Request option.
このメッセージはクライアントによって送信され、サーバーにユニキャストとマルチキャストのエコー応答メッセージを送信するように依頼します。バージョン、シーケンス番号、マルチキャストグループオプションを含める必要があります。サーバー応答メッセージでセッションIDが受信された場合、セッションIDを含める必要があります。クライアントIDとクライアントタイムスタンプのオプションを含める必要があります。オプションリクエストオプションが含まれる場合があります。
Echo Reply, type 65
エコー返信、タイプ65
This message is sent by a server in response to an Echo Request message. This message is always sent in pairs, one as unicast and one as multicast. The contents of the messages are mostly the same. The server always echoes all of the options (but never the Session ID) from the Echo Request. Any options in the Echo Request that are unsupported by the server are also to be echoed. The two Echo Reply messages SHOULD both always contain a TTL option (not necessarily equal). When requested, both Echo Reply messages SHOULD also contain Server Timestamps (not necessarily equal).
このメッセージは、エコーリクエストメッセージに応じてサーバーによって送信されます。このメッセージは常にペアで送信され、1つはユニキャストとして、もう1つはマルチキャストとして送信されます。メッセージの内容はほとんど同じです。サーバーは、常にECHOリクエストからすべてのオプション（ただしセッションIDではありません）を常にエコーします。サーバーによってサポートされていないエコーリクエストのオプションもエコーする必要があります。2つのエコー応答メッセージには、両方とも常にTTLオプションを含める必要があります（必ずしも等しいとは限りません）。要求された場合、両方のエコー応答メッセージには、サーバータイムスタンプ（必ずしも等しくない）も含める必要があります。
The matrix below summarises what options can go in what messages.
以下のマトリックスは、どのメッセージにどのオプションが得られるかを要約しています。
\ Message Type | Init | Server | Echo | Echo |
Option \ | | Response | Request | Reply |
---------------------- -+--------+----------+---------+--------+
Version (0) | MUST | MUST | MUST | ECHO |
Client ID (1) | SHOULD | ECHO | SHOULD | ECHO |
Sequence Number (2) | NOT | ECHO | MUST | ECHO |
Client Timestamp (3) | NOT | NOT | SHOULD | ECHO |
Multicast Group (4) | NOT | MAY | MUST | ECHO |
Option Request (5) | MAY | NOT | MAY | ECHO |
Server Information (6) | NOT | RQ | NOT | NOT |
Deprecated (7) | NOT | NOT | NOT | ECHO |
Deprecated (8) | NOT | NOT | NOT | ECHO |
TTL (9) | NOT | NOT | NOT | SHOULD |
Multicast Prefix (10) | MAY | MAY | NOT | NOT |
Session ID (11) | NOT | SHOULD | ECHO | NOT |
Server Timestamp (12) | NOT | NOT | NOT | RQ |
---------------------- -+--------+----------+---------+--------+
"NOT" means that the option MUST NOT be included. "ECHO" for a server means that if the option is specified by the client, then the server MUST echo the option in the response, with the exact same option value. ECHO for a client only applies to the Session ID option. If it is present in the Server Response, then it MUST be present with the exact same option value in the following Echo Request messages. "RQ" means that the server SHOULD include the option in the response, when requested by the client using the Option Request option.
「ではない」とは、オプションを含めてはならないことを意味します。サーバーの「エコー」とは、オプションがクライアントによって指定されている場合、サーバーはまったく同じオプション値で応答のオプションをエコーする必要があることを意味します。クライアントのエコーは、セッションIDオプションにのみ適用されます。サーバーの応答に存在する場合は、次のエコーリクエストメッセージにまったく同じオプション値が存在する必要があります。「RQ」とは、オプション要求オプションを使用してクライアントが要求した場合、サーバーに応答にオプションを含める必要があることを意味します。
Clients MUST by default send at most Default-Client-Request-Rate (Section 3.5.1) Echo Request messages per second. Note that the value can be less than 1. Servers MUST by default perform rate limiting, to guard against this protocol being used for denial-of-service (DoS) attacks. A server MUST by default limit the number of clients that can be served at the same time, and for a given client, a server MUST also by default respond to, on average, at most Default-Server-Rate-Limit (see Section 3.5.1) Echo Request messages per second. Note that the value can be less than 1. Server implementations should provide configuration options allowing certain clients to perform more rapid rates of Echo Request messages. If higher rates are allowed for specific client IP addresses, then Init messages and the Session ID option MUST be used to help mitigate spoofing.
クライアントは、デフォルトで最大のデフォルトクライアントレクエストレート（セクション3.5.1）でエコーリクエストメッセージを1秒あたりに送信する必要があります。値は1未満になる可能性があることに注意してください。サーバーは、デフォルトでレート制限を実行する必要があります。サーバーはデフォルトで同時にサービスを提供できるクライアントの数を制限する必要があり、特定のクライアントについては、デフォルトでは、デフォルトで平均して、最大のデフォルトのサーバーレートライミットに応答する必要があります（セクション3.5を参照してください.1）エコーは、1秒あたりのメッセージを要求します。値は1未満になる可能性があることに注意してください。サーバーの実装は、特定のクライアントがより迅速なエコー要求メッセージを実行できるようにする構成オプションを提供する必要があります。特定のクライアントIPアドレスでより高いレートが許可されている場合、INITメッセージとセッションIDオプションを使用して、スプーフィングを軽減する必要があります。
Implementers of applications/tools using this protocol SHOULD consider the UDP guidelines [RFC5405], in particular if clients are to send, or servers are to accept, Echo Request messages at rates exceeding the defaults given in this document. See Section 8, "Security Considerations", for additional discussion.
このプロトコルを使用したアプリケーション/ツールの実装者は、特にクライアントが送信される場合、またはサーバーを受け入れる場合、このドキュメントで指定されたデフォルトを超えるレートでメッセージを要求する場合に、UDPガイドライン[RFC5405]を考慮する必要があります。追加の議論については、セクション8「セキュリティ上の考慮事項」を参照してください。
There are two variables that control message rates. They are defined as follows.
メッセージレートを制御する2つの変数があります。それらは次のように定義されています。
Default-Client-Request-Rate
デフォルトクライアントレクエストレート
This variable defines the default client echo request rate, specifying the number of requests per second. Note that the value may be less than one. For example, a value of 0.1 means one packet per 10 seconds. The value 1 is RECOMMENDED, but the value might be too small or large, depending on the type of network in which the client is deployed. The value 1 is chosen because it should be safe in most deployments, and it is similar to what is typically used for the common tool "ping" for ICMP Echo Request messages.
この変数は、デフォルトのクライアントエコー要求レートを定義し、1秒あたりの要求数を指定します。値は1未満かもしれないことに注意してください。たとえば、0.1の値は、10秒あたり1つのパケットを意味します。値1は推奨されますが、クライアントが展開されているネットワークのタイプに応じて、値は小さすぎるまたは大きすぎる場合があります。値1は、ほとんどの展開で安全である必要があり、ICMPエコーリクエストメッセージの一般的なツール「ping」に通常使用されるものと類似しているため、選択されます。
Default-Server-Rate-Limit
デフォルトサーバーレートライミット
This variable defines the default per-client rate limit that a server uses for responding to Echo Request messages. The average rate of replies MUST NOT exceed Default-Server-Rate-Limit per second. Note that the value may be less than one. For example, a value of 0.1 means an average of one packet per 10 seconds. The value 1 is RECOMMENDED, but the value might be too small or large, depending on the type of network in which the client is deployed. The value 1 is chosen because it should be safe in most deployments. This value SHOULD be high enough to accept the value chosen for the Default-Client-Request-Rate.
この変数は、サーバーがエコーリクエストメッセージに応答するために使用するデフォルトのクライアントごとのレート制限を定義します。返信の平均率は、デフォルトサーバーレートライミットあたりのデフォルトの販売率を超えてはなりません。値は1未満かもしれないことに注意してください。たとえば、0.1の値は、10秒あたり平均1パケットを意味します。値1は推奨されますが、クライアントが展開されているネットワークのタイプに応じて、値は小さすぎるまたは大きすぎる場合があります。値1は、ほとんどの展開で安全である必要があるため、選択されます。この値は、デフォルトのクライアントレクエストレートに選択された値を受け入れるのに十分な高さでなければなりません。
We will consider how a typical interactive client using the above protocol would behave.
上記のプロトコルを使用した典型的なインタラクティブなクライアントがどのように動作するかを検討します。
A client only requires a user to specify the unicast address of the server. It can then send an Init message with a prefix option containing the desired address family and zero prefix length (wildcard entry). The server can then decide which group, from the specified family, it should return. A client may also allow the user to specify group address(es) or prefix(es) (for IPv6, the user may
クライアントは、ユーザーがサーバーのユニキャストアドレスを指定することのみを要求します。次に、目的のアドレスファミリとゼロプレフィックスの長さ（ワイルドカードエントリ）を含むプレフィックスオプションを使用してinitメッセージを送信できます。サーバーは、指定されたファミリからどのグループが返されるかを決定できます。クライアントは、ユーザーがグループアドレス（ES）またはプレフィックス（ES）を指定できるようにすることもできます（IPv6の場合、ユーザーは
only be required to specify a scope or a Rendezvous Point (RP) address, from which the client can construct the desired prefix, possibly embedded-RP). From this, the client can specify one or more prefix options in an Init message to tell the server which address it would prefer. If the user specifies a group address, that can be encoded as a prefix of maximal length (e.g., 32 for IPv4). The prefix options are in prioritised order; i.e., the client should put the most preferred prefix first.
クライアントが目的のプレフィックス、場合によっては埋め込まれたRPを構築できるスコープまたはランデブーポイント（RP）アドレスを指定するためにのみ必要です。このことから、クライアントはINITメッセージに1つ以上のプレフィックスオプションを指定して、どのアドレスを好むかをサーバーに伝えることができます。ユーザーがグループアドレスを指定した場合、最大長のプレフィックスとしてエンコードできます（例：IPv4の場合は32）。プレフィックスオプションは優先順位付けされています。つまり、クライアントは最初に最も優先されるプレフィックスを配置する必要があります。
If the client receives a Server Response message containing a group address, it can start sending Echo Request messages; see the next paragraph. If there is no group address option, the client would typically exit with an error message. The server may have included some prefix options in the Server Response. The client may use this to provide the user some feedback on what prefixes or scopes are available.
クライアントがグループアドレスを含むサーバー応答メッセージを受信した場合、エコーリクエストメッセージの送信を開始できます。次の段落を参照してください。グループアドレスオプションがない場合、クライアントは通常、エラーメッセージで終了します。サーバーには、サーバーの応答にいくつかのプレフィックスオプションが含まれている場合があります。クライアントはこれを使用して、ユーザーに使用可能なプレフィックスまたはスコープに関するフィードバックを提供する場合があります。
Assuming the client got a group address in a Server Response, it can start the multicast pings, after letting the user know which group is being used. Normally, a client should send at most Default-Client-Request-Rate (Section 3.5.1) Echo Request messages per second.
クライアントがサーバーの応答でグループアドレスを取得したと仮定すると、ユーザーに使用されているグループをユーザーに知らせた後、マルチキャストPingを開始できます。通常、クライアントは、デフォルトクライアントレクエストレート（セクション3.5.1）で最もデフォルトのクライアントレクエストレート（セクション3.5.1）を送信する必要があります。
When sending the Echo Request messages, the client must always include the group option. If the Server Response contained a Session ID option, then it must also include a Session ID option, with the exact same value, in the Echo Request messages. If a client receives a Server Response message in response to an Echo Request (that is, a Server Response message containing a sequence number), this means there is an error, and it should stop sending Echo Request messages. This could happen after server restart.
Echo要求メッセージを送信するとき、クライアントは常にグループオプションを含める必要があります。サーバーの応答にセッションIDオプションが含まれている場合、エコーリクエストメッセージに、まったく同じ値のセッションIDオプションも含める必要があります。クライアントがエコー要求（つまり、シーケンス番号を含むサーバー応答メッセージ）に応じてサーバー応答メッセージを受信した場合、これはエラーがあることを意味し、エコーリクエストメッセージの送信を停止する必要があります。これは、サーバーの再起動後に発生する可能性があります。
The client may allow the user to request server information. If the user requests server information, the client can send an Init message with no prefix options, but with an Option Request option, requesting that the server return a Server Information option. The server will return server information, if supported, and it may also return a list of prefixes it supports. It will not, however, return a group address. The client may also try to obtain only a list of prefixes by sending an Init message with no prefixes and not requesting any specific options.
クライアントは、ユーザーがサーバー情報を要求できるようにする場合があります。ユーザーがサーバー情報を要求する場合、クライアントはプレフィックスオプションなしでinitメッセージを送信できますが、オプションリクエストオプションを使用して、サーバーがサーバー情報オプションを返すように要求します。サーバーは、サポートされている場合はサーバー情報を返し、サポートするプレフィックスのリストを返すこともあります。ただし、グループアドレスを返しません。クライアントは、プレフィックスなしでinitメッセージを送信し、特定のオプションを要求しないことにより、プレフィックスのリストのみを取得しようとすることもできます。
Although this technique is not recommended, a client may pick a multicast group and send Echo Request messages without first going through the Init - Server Response negotiation. If this is supported
この手法はお勧めしませんが、クライアントはマルチキャストグループを選択し、最初にINIT -Server Response Negotiationを通過せずにエコーリクエストメッセージを送信する場合があります。これがサポートされている場合
by the server and the server is okay with the group used, the server can then send Echo Reply messages as usual. If the server is not okay with the group used, it will send a Server Response telling the client to stop.
サーバーとサーバーが使用されているグループでは問題ありません。サーバーは、通常どおりEcho Replyメッセージを送信できます。サーバーが使用されているグループで問題がない場合、クライアントに停止するようにサーバーの応答を送信します。
We will consider how a typical server using the above protocol would behave, first looking at how to respond to Init messages.
上記のプロトコルを使用する典型的なサーバーがどのように動作するかを検討し、最初にinitメッセージへの応答方法を検討します。
If the Init message contains prefix options, the server should look at them in order and see if it can assign a multicast address from the given prefix. The server would be configured with a (possibly default) set of groups it can offer. It may have a large pool and pick a group at random, or possibly choose a group based on hashing of the client's IP address or identifier, or simply use a fixed group. A server could possibly decide whether to include site-scoped group ranges based on the client's IP address. It is left to the server to decide whether it should allow the same address to be used simultaneously by multiple clients.
initメッセージにプレフィックスオプションが含まれている場合、サーバーはそれらを順番に調べ、指定されたプレフィックスからマルチキャストアドレスを割り当てることができるかどうかを確認する必要があります。サーバーは、提供できる（おそらくデフォルトの）グループのセットで構成されます。大きなプールがあり、ランダムにグループを選択するか、クライアントのIPアドレスまたは識別子のハッシュに基づいてグループを選択するか、単に固定グループを使用する場合があります。サーバーは、クライアントのIPアドレスに基づいて、サイトスコープ付きグループ範囲を含めるかどうかを決定できます。同じアドレスを複数のクライアントが同時に使用できるかどうかを決定するのは、サーバーに任されています。
If the server finds a suitable group address, it returns this address in a group option in a Server Response message. The server should additionally include a Session ID. This may help the server if it is to keep some state -- for instance, to make sure the client uses the group assigned to it. A good Session ID would be a pseudo-random byte string that is hard to predict; see [RFC4086]. If the server cannot find a suitable group address, or if there were no prefixes in the Init message, it may send a Server Response message containing prefix options listing what prefixes may be available to the client. Finally, if the Init message requests the Server Information option, the server should include that option.
サーバーが適切なグループアドレスを見つけた場合、サーバー応答メッセージのグループオプションでこのアドレスを返します。サーバーには、セッションIDを追加する必要があります。これは、たとえば、クライアントがそれに割り当てられたグループを使用することを確認するために、ある状態を保持する場合にサーバーに役立つ場合があります。優れたセッションIDは、予測するのが難しい疑似ランダムバイト文字列です。[RFC4086]を参照してください。サーバーが適切なグループアドレスを見つけることができない場合、またはinitメッセージにプレフィックスがなかった場合、クライアントが使用できるプレフィックスをリストするプレフィックスオプションを含むサーバー応答メッセージを送信する場合があります。最後に、initメッセージがサーバー情報オプションを要求する場合、サーバーにそのオプションを含める必要があります。
When the server receives an Echo Request message, it must first check that the group address and Session ID (if provided) are valid. If the server is satisfied, it will send a unicast Echo Reply message back to the client, and also a multicast Echo Reply message to the group address. The Echo Reply messages contain the exact options (but no Session ID), and in the same order as in the Echo Request; after that, the server adds a TTL option and additional options if needed. For example, it may add a timestamp if requested by the client. If the server is not happy with the Echo Request (such as bad group address or Session ID, or request is too large), it may send a Server Response message asking the client to stop. This Server Response must echo the sequence number from the Echo Request.
サーバーがエコーリクエストメッセージを受信した場合、最初にグループアドレスとセッションID（提供されている場合）が有効であることを確認する必要があります。サーバーが満たされている場合、クライアントにUnicast Echo Replyメッセージを送信し、グループアドレスにマルチキャストエコー応答メッセージを送信します。Echo Replyメッセージには、正確なオプション（ただしセッションIDなし）が含まれており、Echoリクエストと同じ順序で含まれています。その後、サーバーは、必要に応じてTTLオプションと追加オプションを追加します。たとえば、クライアントから要求された場合、タイムスタンプを追加する場合があります。サーバーがエコー要求（悪いグループアドレスやセッションIDなど、リクエストが大きすぎるなど）に満足していない場合、クライアントに停止を求めるサーバー応答メッセージが送信される場合があります。このサーバーの応答は、Echo要求からシーケンス番号をエコーする必要があります。
This Server Response may contain group prefixes from which a client can try to request a group address. The unicast and multicast Echo Reply messages have identical UDP payload, apart from possibly TTL and timestamp option values.
このサーバーの応答には、クライアントがグループアドレスを要求しようとするグループのプレフィックスが含まれている場合があります。UnicastおよびMulticast Echo Replyメッセージには、TTLおよびタイムスタンプのオプション値とは別に、同一のUDPペイロードがあります。
Note that the server may receive Echo Request messages with no prior Init message. This may happen when the server restarts or if a client sends an Echo Request with no prior Init message. The server may go ahead and respond if it is okay with the group and Session ID (if included) used. If it is not okay with this information, the server sends back a Server Response.
サーバーは、事前のinitメッセージなしでエコーリクエストメッセージを受信する場合があることに注意してください。これは、サーバーが再起動したとき、またはクライアントが事前のinitメッセージなしでエコー要求を送信する場合に発生する場合があります。サーバーは、使用されているグループとセッションID（含まれている場合）で問題がある場合は、先に進んで応答する場合があります。この情報で問題なくなった場合、サーバーはサーバーの応答を送り返します。
The protocol, as specified, is fairly flexible and leaves a lot of freedom for implementers. In this section, we present some recommendations.
指定されたプロトコルは、かなり柔軟であり、実装者に多くの自由を残します。このセクションでは、いくつかの推奨事項を提示します。
Server administrators should be able to configure one group prefix or multiple group prefixes in a server implementation. When deploying servers on the Internet and in other environments, the server administrator should be able to restrict the server to respond to only a few multicast groups that should not be currently used by multicast applications. A server implementation should also provide flexibility for an administrator to apply various policies to provide one group prefix or multiple group prefixes to specific clients, e.g., site-scoped addresses for clients that are inside the site.
サーバー管理者は、サーバーの実装で1つのグループプレフィックスまたは複数のグループプレフィックスを構成できる必要があります。インターネットや他の環境にサーバーを展開する場合、サーバー管理者は、現在マルチキャストアプリケーションで使用されていないいくつかのマルチキャストグループのみに応答するようにサーバーを制限できるはずです。また、サーバーの実装では、管理者がさまざまなポリシーを適用して、特定のクライアントに1つのグループプレフィックスまたは複数のグループプレフィックスを提供する柔軟性を提供する必要があります。
As specified in Section 3.5, for a given client, a server must by default respond to at most an average rate of Default-Server-Rate-Limit Echo Request messages per second. A leaky bucket algorithm is suggested, where the rate can be higher for a few seconds, but the average rate should by default be limited to Default-Server-Rate-Limit messages per client per second. Server implementations should provide administrative control of which client IP addresses to serve, and may also allow certain clients to perform more rapid rates of Echo Request messages.
セクション3.5で指定されているように、特定のクライアントについて、サーバーはデフォルトでデフォルトのデフォルトサーバーレートリミットエコーリクエストメッセージの平均レートの最大レートに応答する必要があります。漏れやすいバケットアルゴリズムが提案されています。ここでは、レートは数秒間高くなる可能性がありますが、デフォルトではクライアントあたりのデフォルトサーバーレートリミットメッセージにデフォルトに制限する必要があります。サーバーの実装は、どのクライアントIPアドレスがサービスを提供するかを管理する管理制御を提供し、特定のクライアントがより迅速なエコー要求メッセージを実行できるようにする必要があります。
If a server uses different policies for different IP addresses, it should require clients to send Init messages and return an unpredictable Session ID to help mitigate spoofing. This is an absolute requirement if exceeding the default rate limit. See the specification in Section 3.5.
サーバーがさまざまなIPアドレスに対して異なるポリシーを使用している場合、クライアントにINITメッセージを送信し、予測不可能なセッションIDを返してスプーフィングを緩和する必要があります。これは、デフォルトのレート制限を超える場合の絶対要件です。セクション3.5の仕様を参照してください。
IANA has assigned UDP user port 9903 (multicast-ping) for use by this protocol. IANA also provides registries for message and option types.
IANAは、このプロトコルで使用するためにUDPユーザーポート9903（マルチキャスト-Ping）を割り当てました。IANAは、メッセージタイプとオプションタイプのレジストリも提供しています。
IANA has created a message types registry. Message types are in the range 0-255. Message types 0-253 are registered following the procedures for Specification Required from RFC 5226 [RFC5226], while types 254 and 255 are for experimental use. The registry includes the messages defined in Section 3.4. A message specification MUST describe the behaviour with known option types as well as the default behaviour with unknown option types.
IANAはメッセージタイプレジストリを作成しました。メッセージタイプは0-255の範囲です。メッセージタイプ0-253は、RFC 5226 [RFC5226]から必要な仕様の手順に従って登録され、タイプ254と255は実験用です。レジストリには、セクション3.4で定義されたメッセージが含まれます。メッセージ仕様は、既知のオプションタイプの動作と、不明なオプションタイプのデフォルトの動作を記述する必要があります。
IANA has created an option type registry. Option types 0-65531 are registered following the procedures for Specification Required from RFC 5226 [RFC5226], while types 65532-65535 are for experimental use. The registry should include the options defined in Section 3.2. An option specification must describe how the option may be used with the known message types. This includes which message types the option may be used with.
IANAはオプションタイプレジストリを作成しました。オプションタイプ0-65531は、RFC 5226 [RFC5226]から必要な仕様の手順に従って登録され、タイプ65532-65535は実験用です。レジストリには、セクション3.2で定義されているオプションを含める必要があります。オプション仕様は、既知のメッセージタイプでオプションを使用する方法を説明する必要があります。これには、オプションを使用できるメッセージタイプが含まれます。
The initial registry definitions are as follows:
最初のレジストリ定義は次のとおりです。
Multicast Ping Protocol Parameters:
マルチキャストpingプロトコルパラメーター：
Registry Name: Multicast Ping Protocol Message Types Reference: RFC 6450 Registration Procedures: Specification Required
レジストリ名：マルチキャストPingプロトコルメッセージタイプリファレンス：RFC 6450登録手順：仕様が必要です
Registry:
Type Name Reference
----------- ------------------------------------ ----------
65 Echo Reply RFC 6450
73 Init RFC 6450
81 Echo Request RFC 6450
83 Server Response RFC 6450
254-255 Experimental
Registry Name: Multicast Ping Protocol Option Types Reference: RFC 6450 Registration Procedures: Specification Required
レジストリ名：マルチキャストPingプロトコルオプションタイプリファレンス：RFC 6450登録手順：仕様が必要です
Registry:
Type Name Reference
----------- ------------------------------------ ----------
0 Version RFC 6450
1 Client ID RFC 6450
2 Sequence Number RFC 6450
3 Client Timestamp RFC 6450
4 Multicast Group RFC 6450
5 Option Request RFC 6450
6 Server Information RFC 6450
7 Deprecated RFC 6450
8 Deprecated RFC 6450
9 TTL RFC 6450
10 Multicast Prefix RFC 6450
11 Session ID RFC 6450
12 Server Timestamp RFC 6450
65532-65535 Experimental
There are some security issues to consider. One is that a host may send an Echo Request with an IP source address of another host, and make an arbitrary multicast ping server on the Internet send packets to this other host. This behaviour is fairly harmless. The worst case is if the host receiving the unicast Echo Reply messages also happens to be joined to the multicast group used. This is less of a problem for SSM, where also the source address of the server must match the address joined. In this case, there would be an amplification effect, where the host receives twice as many replies as there are requests sent. See below for how spoofing can be mitigated.
考慮すべきセキュリティの問題がいくつかあります。1つは、ホストが別のホストのIPソースアドレスを使用してエコーリクエストを送信し、インターネット上の任意のマルチキャストPingサーバーがこの他のホストにパケットを送信することです。この動作はかなり無害です。最悪の場合は、ユニキャストエコー応答メッセージを受け取ったホストが、使用されたマルチキャストグループにも結合された場合です。これは、SSMにとって問題ではありません。SSMでは、サーバーのソースアドレスも結合されたアドレスと一致する必要があります。この場合、増幅効果があり、ホストは送信されたリクエストの2倍の返信を受信します。スプーフィングを緩和する方法については、以下を参照してください。
For ASM (Any-Source Multicast), a host could also make a multicast ping server send multicast packets to a group that is used for something else, possibly disturbing other uses of that group. However, server implementations should allow administrators to restrict which groups a server responds to. The administrator should then try to configure a set of groups that are not used for other purposes. Another concern is bandwidth. To limit the bandwidth used, a server MUST by default limit the number of clients that can be served at the same time, and a server MUST also by default perform per-client rate limiting.
ASM（Any-Source Multicast）の場合、ホストはマルチキャストPingサーバーを、他の何かに使用されるグループにマルチキャストパケットを送信し、そのグループの他の使用を妨害する可能性もあります。ただし、サーバーの実装により、管理者はサーバーが応答するグループを制限できるようにする必要があります。その後、管理者は、他の目的に使用されないグループのセットを構成しようとする必要があります。別の懸念は帯域幅です。使用する帯域幅を制限するには、サーバーはデフォルトで同時に提供できるクライアントの数をデフォルトで制限する必要があり、サーバーはデフォルトでクライアントごとのレート制限を実行する必要があります。
In order to help mitigate spoofing, a server SHOULD require that the client send an Init message, and return an unpredictable Session ID in the response. The ID should be associated with the IP address and have a limited lifetime. The server SHOULD then only respond to Echo Request messages that have a valid Session ID associated with the source IP address of the Echo Request. Note, however, that a server is replying with a Server Response message if the Session ID is invalid. This is used to tell the client that something is wrong and that it should stop sending requests, and start over if necessary. This means, however, that someone may spoof a client request, and have the server send a message back to the client address. One solution here would be for the server to have a very low rate limit for the Server Response messages.
スプーフィングを緩和するために、サーバーはクライアントがinitメッセージを送信することを要求し、応答で予測不可能なセッションIDを返す必要があります。IDはIPアドレスに関連付けられ、寿命が限られている必要があります。サーバーは、Echo要求のソースIPアドレスに関連付けられた有効なセッションIDがあるEcho要求メッセージにのみ応答する必要があります。ただし、セッションIDが無効である場合、サーバーがサーバー応答メッセージで返信していることに注意してください。これは、何かが間違っており、リクエストの送信を停止し、必要に応じて最初からやり直す必要があることをクライアントに伝えるために使用されます。ただし、これは、誰かがクライアントのリクエストを投げかけ、サーバーにメッセージをクライアントアドレスに返送させることを意味します。ここでの解決策の1つは、サーバーがサーバー応答メッセージの非常に低いレート制限を持つことです。
Note that the use of a Session ID only to some degree helps mitigate spoofing. An attacker that is on the path between a client and a server may eavesdrop the traffic, learn a valid Session ID, and generate Echo Request messages using this ID. The server will respond as long as the Session ID remains valid.
セッションIDをある程度のみ使用すると、スプーフィングを軽減するのに役立つことに注意してください。クライアントとサーバーの間のパス上にある攻撃者は、トラフィックを盗聴し、有効なセッションIDを学習し、このIDを使用してEcho要求メッセージを生成できます。セッションIDが有効である限り、サーバーは応答します。
This protocol may be used to establish a covert channel between a multicast ping client and other hosts listening to a multicast group. A client can, for instance, send an Echo Request containing an undefined option with arbitrary data. The server would echo this back in an Echo Reply that may reach other hosts listening to that group. One solution that should be considered for future protocol versions is to reply with a hash of the data, rather than simply a copy of the same data.
このプロトコルを使用して、マルチキャストPingクライアントと他のホストがマルチキャストグループを聴くホストとの間に秘密チャネルを確立することができます。たとえば、クライアントは、任意のデータを使用して未定義のオプションを含むエコーリクエストを送信できます。サーバーは、このグループを聞いて他のホストに届く可能性のあるエコー応答でこれをエコーします。将来のプロトコルバージョンで考慮すべきソリューションの1つは、同じデータのコピーではなく、データのハッシュで返信することです。
The ssmping concept was proposed by Pavan Namburi, Kamil Sarac, and Kevin C. Almeroth in the paper "SSM-Ping: A Ping Utility for Source Specific Multicast" (2004) and also "MPing: A Ping Utility for IP Multicast" (Sarac and Almeroth, 2004). Mickael Hoerdt contributed several ideas. Alexander Gall, Nicholas Humfrey, Nick Lamb, and Dave Thaler have contributed in different ways to the implementation of the ssmping tools [IMPL]. Many people in communities like the Trans-European Research and Education Networking Association (TERENA), Internet2, and the M6Bone (IPv6 multicast network) have used early implementations of ssmping and provided feedback that influenced the current protocol. Thanks to Kevin Almeroth, Tony Ballardie, Bill Cerveny, Toerless Eckert, Marshall Eubanks, Gorry Fairhurst, Alfred Hoenes, Liu Hui, Bharat Joshi, Olav Kvittem, Hugo Santos, Kamil Sarac, Pekka Savola, Trond Skjesol, and Cao Wei for reviewing and providing feedback on this document. In particular, Hugo, Gorry, and Bharat provided lots of input on several revisions of the document.
SSMPINGの概念は、パバンナンブリ、カミルサラック、ケビンC.アルメロスによって提案されました。およびAlmeroth、2004）。 Mickael Hoerdtはいくつかのアイデアを提供しました。アレクサンダー・ギャル、ニコラス・ハンフリー、ニック・ラム、デイブ・ターラーは、SSMPINGツールの実装にさまざまな方法で貢献しました[Impl]。トランスヨーロッパ研究教育ネットワーク協会（Terena）、Internet2、およびM6Bone（IPV6マルチキャストネットワーク）などのコミュニティの多くの人々は、SSMPINGの早期実装を使用し、現在のプロトコルに影響を与えるフィードバックを提供しました。ケビン・アルメロス、トニー・バラルディ、ビル・セルヴィー、トアーレス・エッカート、マーシャル・ユーバンクス、ゴーリー・フェアハースト、アルフレッド・ホーネス、リュー・フイ、バラト・ジョシ、オラヴ・クヴィッテム、ヒューゴ・サントス、カミル・サラック、ペッカ・サヴォラ、トロンド・スカジョル、カオ・スケソル、カミル・サヴォラ、このドキュメントに関するフィードバックを提供します。特に、Hugo、Gorry、およびBharatは、文書のいくつかの改訂に関する多くの入力を提供しました。
[ADDRFAMILY] IANA, "Address Family Numbers", <http://www.iana.org/assignments/address-family-numbers>.
[addrfamily] iana、 "address family numbers"、<http://www.iana.org/assignments/address-family-numbers>。
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[RFC0768] POSTEL、J。、「ユーザーデータグラムプロトコル」、STD 6、RFC 768、1980年8月。
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.
[RFC0792] Postel、J。、「インターネット制御メッセージプロトコル」、STD 5、RFC 792、1981年9月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629] Yergeau、F。、「UTF-8、ISO 10646の変換形式」、STD 63、RFC 3629、2003年11月。
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086] EastLake 3rd、D.、Schiller、J。、およびS. Crocker、「セキュリティのランダム性要件」、BCP 106、RFC 4086、2005年6月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[IMPL] Venaas, S., "ssmping implementation", <http://software.uninett.no/ssmping/>.
[empl] venaas、S。、「ssmping実装」、<http://software.uninett.no/ssmping/>。
[RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines for Application Designers", BCP 145, RFC 5405, November 2008.
[RFC5405] Eggert、L。およびG. Fairhurst、「アプリケーションデザイナーのユニキャストUDP使用ガイドライン」、BCP 145、RFC 5405、2008年11月。
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, June 2010.
[RFC5905] Mills、D.、Martin、J.、Ed。、Burbank、J.、およびW. Kasch、「ネットワークタイムプロトコルバージョン4：プロトコルとアルゴリズムの仕様」、RFC 5905、2010年6月。
Author's Address
著者の連絡先
Stig Venaas Cisco Systems Tasman Drive San Jose, CA 95134 USA
Stig Venaas Cisco Systems Tasman Drive San Jose、CA 95134 USA
EMail: stig@cisco.com