[要約] RFC 8335は、インターフェースをプローブするためのユーティリティであり、ネットワークデバイスの状態を調査するために使用されます。このRFCの目的は、ネットワーク管理者がネットワークの問題を特定し、トラブルシューティングを行うための手段を提供することです。
Internet Engineering Task Force (IETF) R. Bonica
Request for Comments: 8335 R. Thomas
Updates: 4884 Juniper Networks
Category: Standards Track J. Linkova
ISSN: 2070-1721 Google
C. Lenart
Verizon
M. Boucadair
Orange
February 2018
PROBE: A Utility for Probing Interfaces
PROBE：インターフェイスをプローブするためのユーティリティ
Abstract
概要
This document describes a network diagnostic tool called PROBE. PROBE is similar to PING in that it can be used to query the status of a probed interface, but it differs from PING in that it does not require bidirectional connectivity between the probing and probed interfaces. Instead, PROBE requires bidirectional connectivity between the probing interface and a proxy interface. The proxy interface can reside on the same node as the probed interface, or it can reside on a node to which the probed interface is directly connected. This document updates RFC 4884.
このドキュメントでは、PROBEと呼ばれるネットワーク診断ツールについて説明します。プローブは、プローブされたインターフェースのステータスを照会するために使用できるという点でPINGに似ていますが、プローブインターフェースとプローブされたインターフェース間の双方向接続を必要としない点でPINGとは異なります。代わりに、プローブには、プローブインターフェイスとプロキシインターフェイス間の双方向接続が必要です。プロキシインターフェースは、プローブされたインターフェースと同じノードに常駐することも、プローブされたインターフェースが直接接続されているノードに常駐することもできます。このドキュメントはRFC 4884を更新します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（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/rfc8335.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8335で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2018 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 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文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. ICMP Extended Echo Request . . . . . . . . . . . . . . . . . 5
2.1. Interface Identification Object . . . . . . . . . . . . . 6
3. ICMP Extended Echo Reply . . . . . . . . . . . . . . . . . . 7
4. ICMP Message Processing . . . . . . . . . . . . . . . . . . . 9
4.1. Code Field Processing . . . . . . . . . . . . . . . . . . 11
5. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 11
6. Updates to RFC 4884 . . . . . . . . . . . . . . . . . . . . . 12
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.1. Normative References . . . . . . . . . . . . . . . . . . 15
9.2. Informative References . . . . . . . . . . . . . . . . . 16
Appendix A. The PROBE Application . . . . . . . . . . . . . . . 17
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
Network operators use PING [RFC2151] to test bidirectional connectivity between two interfaces. For the purposes of this document, these interfaces are called the probing and probed interfaces. PING sends an ICMP [RFC792] [RFC4443] Echo Request message from the probing interface to the probed interface. The probing interface resides on a probing node while the probed interface resides on a probed node.
ネットワークオペレーターは、PING [RFC2151]を使用して、2つのインターフェイス間の双方向接続をテストします。このドキュメントでは、これらのインターフェイスをプローブインターフェイスおよびプローブインターフェイスと呼びます。 PINGは、ICMP [RFC792] [RFC4443] Echo Requestメッセージをプローブインターフェイスからプローブインターフェイスに送信します。プローブインターフェイスはプローブノードにあり、プローブインターフェイスはプローブノードにあります。
If the probed interface receives the ICMP Echo Request message, it returns an ICMP Echo Reply. When the probing interface receives the ICMP Echo Reply, it has verified bidirectional connectivity between the probing and probed interfaces. Specifically, it has verified that:
プローブされたインターフェイスがICMPエコー要求メッセージを受信すると、ICMPエコー応答を返します。プローブインターフェイスがICMPエコー応答を受信すると、プローブインターフェイスとプローブインターフェイス間の双方向接続が確認されます。具体的には、次のことが確認されています。
o The probing node can reach the probed interface.
o プローブノードは、プローブされたインターフェイスに到達できます。
o The probed interface is active.
o プローブされたインターフェースはアクティブです。
o The probed node can reach the probing interface.
o プローブされたノードは、プローブインターフェイスに到達できます。
o The probing interface is active.
o プローブインターフェイスがアクティブです。
This document describes a network diagnostic tool called PROBE. PROBE is similar to PING in that it can be used to query the status of a probed interface, but it differs from PING in that it does not require bidirectional connectivity between the probing and probed interfaces. Instead, PROBE requires bidirectional connectivity between the probing interface and a proxy interface. The proxy interface can reside on the same node as the probed interface, or it can reside on a node to which the probed interface is directly connected. Section 5 of this document describes scenarios in which this characteristic is useful.
このドキュメントでは、PROBEと呼ばれるネットワーク診断ツールについて説明します。プローブは、プローブされたインターフェースのステータスを照会するために使用できるという点でPINGに似ていますが、プローブインターフェースとプローブされたインターフェース間の双方向接続を必要としない点でPINGとは異なります。代わりに、プローブには、プローブインターフェイスとプロキシインターフェイス間の双方向接続が必要です。プロキシインターフェースは、プローブされたインターフェースと同じノードに常駐することも、プローブされたインターフェースが直接接続されているノードに常駐することもできます。このドキュメントのセクション5では、この特性が役立つシナリオについて説明します。
Like PING, PROBE executes on a probing node. It sends an ICMP Extended Echo Request message from a local interface, called the probing interface, to a proxy interface. The proxy interface resides on a proxy node.
PINGと同様に、PROBEはプローブノードで実行されます。 ICMP拡張エコー要求メッセージを、プローブインターフェイスと呼ばれるローカルインターフェイスからプロキシインターフェイスに送信します。プロキシインターフェイスはプロキシノードに常駐します。
The ICMP Extended Echo Request contains an ICMP Extension Structure and the ICMP Extension Structure contains an Interface Identification Object. The Interface Identification Object identifies the probed interface. The probed interface can reside on or directly connect to the proxy node.
ICMP拡張エコー要求にはICMP拡張構造が含まれており、ICMP拡張構造にはインターフェース識別オブジェクトが含まれています。インターフェイス識別オブジェクトは、プローブされたインターフェイスを識別します。プローブされたインターフェースは、プロキシノードに常駐するか、プロキシノードに直接接続できます。
When the proxy interface receives the ICMP Extended Echo Request, the proxy node executes access control procedures. If access is granted, the proxy node determines the status of the probed interface and returns an ICMP Extended Echo Reply message. The ICMP Extended Echo Reply indicates the status of the probed interface.
プロキシインターフェイスがICMP拡張エコー要求を受信すると、プロキシノードはアクセス制御手順を実行します。アクセスが許可されると、プロキシノードはプローブされたインターフェイスのステータスを判別し、ICMP拡張エコー応答メッセージを返します。 ICMP拡張エコー応答は、プローブされたインターフェイスのステータスを示します。
If the probed interface resides on the proxy node, PROBE determines the status of the probed interface as it would determine its oper-status [RFC7223]. If oper-status is equal to 'up' (1), PROBE reports that the probed interface is active. Otherwise, PROBE reports that the probed interface is inactive.
プローブされたインターフェースがプロキシノードにある場合、PROBEはプローブされたインターフェースの動作ステータスを決定するのと同じように、プローブされたインターフェースのステータスを決定します[RFC7223]。 oper-statusが「up」（1）に等しい場合、プローブされたインターフェースがアクティブであることをPROBEが報告します。それ以外の場合、プローブは、プローブされたインターフェースが非アクティブであることを報告します。
If the probed interface resides on a node that is directly connected to the proxy node, and the probed interface appears in the IPv4 Address Resolution Protocol (ARP) table [RFC826] or IPv6 Neighbor Cache [RFC4861], PROBE reports interface reachability. Otherwise, PROBE reports that the table entry does not exist.
プローブされたインターフェイスがプロキシノードに直接接続されているノードにあり、プローブされたインターフェイスがIPv4アドレス解決プロトコル（ARP）テーブル[RFC826]またはIPv6ネイバーキャッシュ[RFC4861]にある場合、PROBEはインターフェイスの到達可能性を報告します。それ以外の場合、PROBEはテーブルエントリが存在しないことを報告します。
This document uses the following terms:
このドキュメントでは、次の用語を使用します。
o Probing interface: The interface that sends the ICMP Extended Echo Request.
o プローブインターフェイス：ICMP拡張エコー要求を送信するインターフェイス。
o Probing node: The node upon which the probing interface resides.
o プローブノード：プローブインターフェイスが存在するノード。
o Proxy interface: The interface to which the ICMP Extended Echo Request message is sent.
o プロキシインターフェイス：ICMP拡張エコー要求メッセージが送信されるインターフェイス。
o Proxy node: The node upon which the proxy interface resides.
o プロキシノード：プロキシインターフェイスが存在するノード。
o Probed interface: The interface whose status is being queried.
o プローブされたインターフェース：状況が照会されているインターフェース。
o Probed node: The node upon which the probed interface resides. If the proxy interface and the probed interface reside upon the same node, the proxy node is also the probed node. Otherwise, the proxy node is directly connected to the probed node.
o プローブされたノード：プローブされたインターフェースが存在するノード。プロキシインターフェースとプローブされたインターフェースが同じノードにある場合、プロキシノードもプローブされたノードです。それ以外の場合、プロキシノードはプローブされたノードに直接接続されます。
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」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
The ICMP Extended Echo Request message is defined for both ICMPv4 and ICMPv6. Like any ICMP message, the ICMP Extended Echo Request message is encapsulated in an IP header. The ICMPv4 version of the Extended Echo Request message is encapsulated in an IPv4 header, while the ICMPv6 version is encapsulated in an IPv6 header.
ICMP拡張エコー要求メッセージは、ICMPv4とICMPv6の両方に定義されています。 ICMPメッセージと同様に、ICMP拡張エコー要求メッセージはIPヘッダーにカプセル化されます。 ICMPv6バージョンがIPv6ヘッダーにカプセル化されるのに対して、拡張エコー要求メッセージのICMPv4バージョンはIPv4ヘッダーにカプセル化されます。
Figure 1 depicts the ICMP Extended Echo Request message.
図1は、ICMP拡張エコー要求メッセージを示しています。
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 | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier |Sequence Number| Reserved |L|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ICMP Extension Structure
Figure 1: ICMP Extended Echo Request Message
図1：ICMP拡張エコー要求メッセージ
IP Header fields:
IPヘッダーフィールド：
o Source Address: The Source Address identifies the probing interface. It MUST be a valid IPv4 or IPv6 unicast address.
o 送信元アドレス：送信元アドレスは、プローブインターフェイスを識別します。有効なIPv4またはIPv6ユニキャストアドレスである必要があります。
o Destination Address: The Destination Address identifies the proxy interface. It MUST be a unicast address.
o 宛先アドレス：宛先アドレスは、プロキシインターフェイスを識別します。ユニキャストアドレスである必要があります。
ICMP fields:
ICMPフィールド：
o Type: Extended Echo Request. The value for ICMPv4 is 42. The value for ICMPv6 is 160.
o タイプ：拡張エコー要求。 ICMPv4の値は42です。ICMPv6の値は160です。
o Code: MUST be set to 0 and MUST be ignored upon receipt.
o コード：0に設定する必要があり、受信時に無視する必要があります。
o Checksum: For ICMPv4, see RFC 792. For ICMPv6, see RFC 4443.
o チェックサム：ICMPv4については、RFC 792を参照してください。ICMPv6については、RFC 4443を参照してください。
o Identifier: An Identifier to aid in matching Extended Echo Replies to Extended Echo Requests. May be 0.
o 識別子：拡張エコー応答を拡張エコー要求に一致させるのに役立つ識別子。 0の場合があります。
o Sequence Number: A Sequence Number to aid in matching Extended Echo Replies to Extended Echo Requests. May be 0.
o シーケンス番号：拡張エコー応答を拡張エコー要求に一致させるのに役立つシーケンス番号。 0の場合があります。
o Reserved: This field MUST be set to 0 and ignored upon receipt.
o 予約済み：このフィールドは0に設定する必要があり、受信時に無視されます。
o L (local): The L-bit is set if the probed interface resides on the proxy node. The L-bit is clear if the probed interface is directly connected to the proxy node.
o L（ローカル）：プローブされたインターフェースがプロキシノードにある場合、Lビットが設定されます。プローブされたインターフェースが直接プロキシノードに接続されている場合、Lビットはクリアされます。
o ICMP Extension Structure: The ICMP Extension Structure identifies the probed interface.
o ICMP拡張構造：ICMP拡張構造は、プローブされたインターフェースを識別します。
Section 7 of [RFC4884] defines the ICMP Extension Structure. As per RFC 4884, the Extension Structure contains exactly one Extension Header followed by one or more objects. When applied to the ICMP Extended Echo Request message, the ICMP Extension Structure MUST contain exactly one instance of the Interface Identification Object (see Section 2.1).
[RFC4884]のセクション7は、ICMP拡張構造を定義しています。 RFC 4884によると、拡張構造には1つの拡張ヘッダーとそれに続く1つ以上のオブジェクトが含まれます。 ICMP拡張エコー要求メッセージに適用される場合、ICMP拡張構造には、インターフェイス識別オブジェクトのインスタンスが1つだけ含まれている必要があります（セクション2.1を参照）。
If the L-bit is set, the Interface Identification Object can identify the probed interface by name, index, or address. If the L-bit is clear, the Interface Identification Object MUST identify the probed interface by address.
Lビットが設定されている場合、インターフェース識別オブジェクトは、名前、インデックス、またはアドレスによってプローブされたインターフェースを識別できます。 Lビットがクリアされている場合、インターフェイス識別オブジェクトは、プローブされたインターフェイスをアドレスで識別する必要があります。
If the Interface Identification Object identifies the probed interface by address, that address can be a member of any address family. For example, an ICMPv4 Extended Echo Request message can carry an Interface Identification Object that identifies the probed interface by IPv4, IPv6, or IEEE 802 address. Likewise, an ICMPv6 Extended Echo Request message can carry an Interface Identification Object that identifies the probed interface by IPv4, IPv6, or IEEE 802 address.
インターフェイス識別オブジェクトがプローブされたインターフェイスをアドレスで識別する場合、そのアドレスは任意のアドレスファミリのメンバーになることができます。たとえば、ICMPv4拡張エコー要求メッセージは、IPv4、IPv6、またはIEEE 802アドレスによってプローブされたインターフェースを識別するインターフェース識別オブジェクトを運ぶことができます。同様に、ICMPv6拡張エコー要求メッセージは、IPv4、IPv6、またはIEEE 802アドレスによってプローブされたインターフェースを識別するインターフェース識別オブジェクトを運ぶことができます。
The Interface Identification Object identifies the probed interface by name, index, or address. Like any other ICMP Extension Object, it contains an Object Header and Object Payload. The Object Header contains the following fields:
インターフェイス識別オブジェクトは、名前、インデックス、またはアドレスによって、プローブされたインターフェイスを識別します。他のICMP拡張オブジェクトと同様に、オブジェクトヘッダーとオブジェクトペイロードが含まれています。オブジェクトヘッダーには次のフィールドが含まれます。
o Class-Num: Interface Identification Object. The value is 3.
o Class-Num：インターフェース識別オブジェクト。値は3です。
o C-Type: Values are (1) Identifies Interface by Name, (2) Identifies Interface by Index, and (3) Identifies Interface by Address.
o Cタイプ：値は、（1）インターフェースを名前で識別し、（2）インターフェースをインデックスで識別し、（3）インターフェースをアドレスで識別します。
o Length: Length of the object, measured in octets, including the Object Header and Object Payload.
o 長さ：オクテットで測定されたオブジェクトの長さ。オブジェクトヘッダーとオブジェクトペイロードを含みます。
If the Interface Identification Object identifies the probed interface by name, the Object Payload MUST be the interface name as defined in [RFC7223]. If the Object Payload would not otherwise terminate on a 32-bit boundary, it MUST be padded with ASCII NULL characters.
インターフェイス識別オブジェクトがプローブされたインターフェイスを名前で識別する場合、オブジェクトペイロードは、[RFC7223]で定義されているインターフェイス名である必要があります。オブジェクトペイロードが32ビット境界で終了しない場合は、ASCII NULL文字で埋める必要があります。
If the Interface Identification Object identifies the probed interface by index, the length is equal to 8 and the payload contains the if-index [RFC7223].
インターフェイス識別オブジェクトがプローブされたインターフェイスをインデックスで識別する場合、長さは8に等しく、ペイロードにはif-index [RFC7223]が含まれます。
If the Interface Identification Object identifies the probed interface by address, the payload is as depicted in Figure 2.
インターフェイス識別オブジェクトがプローブされたインターフェイスをアドレスで識別する場合、ペイロードは図2のようになります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFI | Address Length| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address ....
Figure 2: Interface Identification Object - C-Type 3 Payload
図2：インターフェイス識別オブジェクト-Cタイプ3ペイロード
Payload fields are defined as follows:
ペイロードフィールドは次のように定義されます。
o Address Family Identifier (AFI): This 16-bit field identifies the type of address represented by the Address field. All values found in the IANA registry of Address Family Numbers (available from <https://www.iana.org/assignments/address-family-numbers>) are valid in this field.
o アドレスファミリ識別子（AFI）：この16ビットのフィールドは、アドレスフィールドで表されるアドレスの種類を識別します。アドレスファミリー番号のIANAレジストリにあるすべての値（<https://www.iana.org/assignments/address-family-numbers>から入手可能）は、このフィールドで有効です。
o Address Length: Number of significant bytes contained by the Address field. (The Address field contains significant bytes and padding bytes.)
o アドレス長：アドレスフィールドに含まれる有効バイト数。 （アドレスフィールドには、有効バイトとパディングバイトが含まれています。）
o Reserved: This field MUST be set to 0 and ignored upon receipt.
o 予約済み：このフィールドは0に設定する必要があり、受信時に無視されます。
o Address: This variable-length field represents an address associated with the probed interface. If the address field would not otherwise terminate on a 32-bit boundary, it MUST be padded with zeroes.
o アドレス：この可変長フィールドは、プローブされたインターフェースに関連付けられたアドレスを表します。アドレスフィールドが32ビット境界で終了しない場合は、ゼロで埋める必要があります。
The ICMP Extended Echo Reply message is defined for both ICMPv4 and ICMPv6. Like any ICMP message, the ICMP Extended Echo Reply message is encapsulated in an IP header. The ICMPv4 version of the Extended Echo Reply message is encapsulated in an IPv4 header, while the ICMPv6 version is encapsulated in an IPv6 header.
ICMP拡張エコー応答メッセージは、ICMPv4とICMPv6の両方に定義されています。他のICMPメッセージと同様に、ICMP拡張エコー応答メッセージはIPヘッダーにカプセル化されます。 ICMPv4バージョンのExtended Echo ReplyメッセージはIPv4ヘッダーにカプセル化され、ICMPv6バージョンはIPv6ヘッダーにカプセル化されます。
Figure 3 depicts the ICMP Extended Echo Reply message.
図3は、ICMP拡張エコー応答メッセージを示しています。
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 | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier |Sequence Number|State|Res|A|4|6|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: ICMP Extended Echo Reply Message
図3：ICMP拡張エコー応答メッセージ
IP Header fields:
IPヘッダーフィールド：
o Source Address: Copied from the Destination Address field of the invoking Extended Echo Request message.
o 送信元アドレス：呼び出し元の拡張エコー要求メッセージの宛先アドレスフィールドからコピーされます。
o Destination Address: Copied from the Source Address field of the invoking Extended Echo Request message.
o 宛先アドレス：呼び出し元の拡張エコー要求メッセージの送信元アドレスフィールドからコピーされます。
ICMP fields:
ICMPフィールド：
o Type: Extended Echo Reply. The value for ICMPv4 is 43. The value for ICMPv6 is 161.
o タイプ：拡張エコー応答。 ICMPv4の値は43です。ICMPv6の値は161です。
o Code: Values are (0) No Error, (1) Malformed Query, (2) No Such Interface, (3) No Such Table Entry, and (4) Multiple Interfaces Satisfy Query.
o コード：値は、（0）エラーなし、（1）不正なクエリ、（2）そのようなインターフェースがない、（3）そのようなテーブルエントリがない、（4）複数のインターフェースがクエリを満たす。
o Checksum: For ICMPv4, see RFC 792. For ICMPv6, see RFC 4443.
o チェックサム：ICMPv4については、RFC 792を参照してください。ICMPv6については、RFC 4443を参照してください。
o Identifier: Copied from the Identifier field of the invoking Extended Echo Request packet.
o 識別子：呼び出し元の拡張エコー要求パケットの識別子フィールドからコピーされます。
o Sequence Number: Copied from the Sequence Number field of the invoking Extended Echo Request packet.
o シーケンス番号：呼び出し元の拡張エコー要求パケットのシーケンス番号フィールドからコピーされます。
o State: If Code is not equal to 0, this field MUST be set to 0 and ignored upon receipt. Likewise, if the probed interface resides upon the proxy node, this field MUST be set to 0 and ignored upon receipt. Otherwise, this field reflects the state of the ARP table or Neighbor Cache entry associated with the probed interface. Values are (0) Reserved, (1) Incomplete, (2) Reachable, (3) Stale, (4) Delay, (5) Probe, and (6) Failed.
o 状態：コードが0に等しくない場合、このフィールドは0に設定され、受信時に無視される必要があります。同様に、プローブされたインターフェイスがプロキシノードに存在する場合、このフィールドは0に設定され、受信時に無視される必要があります。それ以外の場合、このフィールドは、プローブされたインターフェイスに関連付けられたARPテーブルまたはネイバーキャッシュエントリの状態を反映します。値は、（0）予約済み、（1）不完全、（2）到達可能、（3）失効、（4）遅延、（5）プローブ、（6）失敗です。
o Res: This field MUST be set to 0 and ignored upon receipt.
o Res：このフィールドは0に設定する必要があり、受信時に無視されます。
o A (Active): The A-bit is set if the Code is equal to 0, the probed interface resides on the proxy node, and the probed interface is active. Otherwise, the A-bit is clear.
o A（アクティブ）：コードが0に等しく、プローブされたインターフェースがプロキシノードに存在し、プローブされたインターフェースがアクティブである場合、Aビットが設定されます。それ以外の場合、Aビットはクリアされます。
o 4 (IPv4): The 4-bit is set if the A-bit is also set and IPv4 is running on the probed interface. Otherwise, the 4-bit is clear.
o 4（IPv4）：Aビットも設定され、プローブされたインターフェースでIPv4が実行されている場合、4ビットが設定されます。それ以外の場合、4ビットはクリアされます。
o 6 (IPv6): The 6-bit is set if the A-bit is also set and IPv6 is running on the probed interface. Otherwise, the 6-bit is clear.
o 6（IPv6）：Aビットも設定され、プローブされたインターフェースでIPv6が実行されている場合、6ビットが設定されます。それ以外の場合、6ビットはクリアされます。
When a node receives an ICMP Extended Echo Request message and any of the following conditions apply, the node MUST silently discard the incoming message:
ノードがICMP拡張エコー要求メッセージを受信し、次のいずれかの条件が当てはまる場合、ノードは着信メッセージを黙って破棄する必要があります。
o The node does not recognize ICMP Extended Echo Request messages.
o ノードはICMP拡張エコー要求メッセージを認識しません。
o The node has not explicitly enabled ICMP Extended Echo functionality.
o ノードはICMP拡張エコー機能を明示的に有効にしていません。
o The incoming ICMP Extend Echo Request carries a Source Address that is not explicitly authorized for the L-bit setting of the incoming ICMP Extended Echo Request.
o 着信ICMP拡張エコー要求は、着信ICMP拡張エコー要求のLビット設定に対して明示的に承認されていないソースアドレスを伝送します。
o The incoming ICMP Extend Echo Request carries a Source Address that is not explicitly authorized for the incoming ICMP Extended Echo Request type (i.e., by ifName, by IfIndex, or by Address).
o 着信ICMP拡張エコー要求は、着信ICMP拡張エコー要求タイプに対して明示的に許可されていないソースアドレスを運びます（つまり、ifName、IfIndex、またはアドレスによって）。
o The Source Address of the incoming message is not a unicast address.
o 着信メッセージの送信元アドレスがユニキャストアドレスではありません。
o The Destination Address of the incoming message is a multicast address.
o 着信メッセージの宛先アドレスはマルチキャストアドレスです。
Otherwise, when a node receives an ICMPv4 Extended Echo Request, it MUST format an ICMP Extended Echo Reply as follows:
それ以外の場合、ノードがICMPv4拡張エコー要求を受信すると、次のようにICMP拡張エコー応答をフォーマットする必要があります。
o Don't Fragment (DF) flag is 1
o 断片化しない（DF）フラグは1
o More Fragments flag is 0
o More Fragmentsフラグは0です
o Fragment Offset is 0
o フラグメントオフセットは0です
o TTL is 255
o TTLは255
o Protocol is ICMP When a node receives an ICMPv6 Extended Echo Request, it MUST format an ICMPv6 Extended Echo Reply as follows:
oプロトコルはICMPです。ノードがICMPv6拡張エコー要求を受信すると、次のようにICMPv6拡張エコー応答をフォーマットする必要があります。
o Hop Limit is 255
o ホップ制限は255です
o Next Header is ICMPv6
o 次のヘッダーはICMPv6です
In either case, the responding node MUST do the following:
どちらの場合も、応答ノードは次のことを実行する必要があります。
o Copy the Source Address from the Extended Echo Request message to the Destination Address of the Extended Echo Reply.
o 送信元アドレスを拡張エコー要求メッセージから拡張エコー応答の宛先アドレスにコピーします。
o Copy the Destination Address from the Extended Echo Request message to the Source Address of the Extended Echo Reply.
o 宛先アドレスを拡張エコー要求メッセージから拡張エコー応答の送信元アドレスにコピーします。
o Set the DiffServ codepoint to CS0 [RFC4594].
o DiffServコードポイントをCS0 [RFC4594]に設定します。
o Set the ICMP Type to Extended Echo Reply.
o ICMPタイプをExtended Echo Replyに設定します。
o Copy the Identifier from the Extended Echo Request message to the Extended Echo Reply.
o IdentifierをExtended Echo RequestメッセージからExtended Echo Replyにコピーします。
o Copy the Sequence Number from the Extended Echo Request message to the Extended Echo Reply.
o シーケンス番号を拡張エコー要求メッセージから拡張エコー応答にコピーします。
o Set the Code field as described in Section 4.1.
o セクション4.1の説明に従って、コードフィールドを設定します。
o Set the State field to 0.
o 「状態」フィールドを0に設定します。
o Clear the A-bit, the 4-bit, and the 6-bit.
o Aビット、4ビット、および6ビットをクリアします。
o If (1) the Code Field is equal to (0) No Error, (2) the L-bit is set, and (3) the probed interface is active, set the A-bit. Also, set the 4-bit and the 6-bit as appropriate.
o （1）コードフィールドが（0）エラーなし、（2）Lビットが設定されている、（3）プローブされたインターフェイスがアクティブの場合は、Aビットを設定します。また、4ビットと6ビットを適宜設定します。
o If the Code field is equal to (0) No Error and the L-bit is clear, then set the State field to reflect the state of the ARP table or Neighbor Cache entry that represents the probed interface.
o Codeフィールドが（0）No Errorに等しく、Lビットがクリアされている場合は、プローブされたインターフェイスを表すARPテーブルまたはネイバーキャッシュエントリの状態を反映するようにStateフィールドを設定します。
o Set the Checksum appropriately.
o チェックサムを適切に設定します。
o Forward the ICMP Extended Echo Reply to its destination.
o ICMP拡張エコー応答を宛先に転送します。
The Code field MUST be set to (1) Malformed Query if any of the following conditions apply:
次のいずれかの条件に該当する場合、コードフィールドは（1）不正なクエリに設定する必要があります。
o The ICMP Extended Echo Request does not include an ICMP Extension Structure.
o ICMP拡張エコー要求には、ICMP拡張構造は含まれていません。
o The ICMP Extension Structure does not include exactly one Interface Identification Object.
o ICMP拡張構造には、インターフェイス識別オブジェクトが1つだけ含まれていません。
o The L-bit is clear and the Interface Identification Object identifies the probed interface by ifName or ifIndex.
o Lビットはクリアで、インターフェイス識別オブジェクトはifNameまたはifIndexによってプローブされたインターフェイスを識別します。
o The query is otherwise malformed.
o それ以外の場合、クエリは不正な形式です。
The Code field MUST be set to (2) No Such Interface if the L-bit is set and the ICMP Extension Structure does not identify an interface that resides on the proxy node.
Lビットが設定されており、ICMP拡張構造がプロキシノードに存在するインターフェイスを識別しない場合、コードフィールドは（2）No such Interfaceに設定する必要があります。
The Code field MUST be set to (3) No Such Table Entry if the L-bit is clear and the address found in the Interface Identification Object does not appear in the IPv4 Address Resolution Protocol (ARP) table or the IPv6 Neighbor Cache.
Lビットがクリアで、インターフェイス識別オブジェクトで見つかったアドレスがIPv4アドレス解決プロトコル（ARP）テーブルまたはIPv6ネイバーキャッシュに表示されない場合は、コードフィールドを（3）そのようなテーブルエントリに設定する必要があります。
The Code field MUST be set to (4) Multiple Interfaces Satisfy Query if any of the following conditions apply:
以下の条件のいずれかが当てはまる場合、Codeフィールドは（4）Multiple Interfaces Satisfy Queryに設定する必要があります。
o The L-bit is set and the ICMP Extension Structure identifies more than one interface that resides in the proxy node.
o Lビットが設定され、ICMP拡張構造がプロキシノードにある複数のインターフェイスを識別します。
o The L-bit is clear and the address found in the Interface Identification Object maps to multiple IPv4 ARP or IPv6 Neighbor Cache entries.
o Lビットはクリアで、インターフェイス識別オブジェクトにあるアドレスは、複数のIPv4 ARPまたはIPv6ネイバーキャッシュエントリにマップされます。
Otherwise, the Code field MUST be set to (0) No Error.
それ以外の場合、コードフィールドは（0）エラーなしに設定する必要があります。
In the scenarios listed below, network operators can use PROBE to determine the status of a probed interface but cannot use PING for the same purpose. In all scenarios, assume bidirectional connectivity between the probing and proxy interfaces. However, bidirectional connectivity between the probing and probed interfaces is lacking.
以下に示すシナリオでは、ネットワークオペレーターはプローブを使用してプローブされたインターフェイスのステータスを判別できますが、同じ目的でPINGを使用することはできません。すべてのシナリオで、プローブインターフェイスとプロキシインターフェイス間の双方向接続を想定しています。ただし、プローブインターフェイスとプローブインターフェイス間の双方向接続が不足しています。
o The probed interface is unnumbered.
o プローブされたインターフェイスは番号付けされていません。
o The probing and probed interfaces are not directly connected to one another. The probed interface has an IPv6 link-local address but does not have a more globally scoped address.
o プローブインターフェイスとプローブインターフェイスは互いに直接接続されていません。プローブされたインターフェイスにはIPv6リンクローカルアドレスがありますが、よりグローバルなスコープのアドレスはありません。
o The probing interface runs IPv4 only while the probed interface runs IPv6 only.
o プローブインターフェイスはIPv4のみを実行し、プローブインターフェイスはIPv6のみを実行します。
o The probing interface runs IPv6 only while the probed interface runs IPv4 only.
o プローブインターフェイスはIPv6のみを実行し、プローブインターフェイスはIPv4のみを実行します。
o For lack of a route, the probing node cannot reach the probed interface.
o ルートがないため、プローブノードはプローブされたインターフェイスに到達できません。
Section 4.6 of [RFC4884] provides a list of extensible ICMP messages (i.e., messages that can carry the ICMP Extension Structure). This document adds the ICMP Extended Echo Request message and the ICMP Extended Echo Reply message to that list.
[RFC4884]のセクション4.6は、拡張可能なICMPメッセージ（つまり、ICMP拡張構造を運ぶことができるメッセージ）のリストを提供します。このドキュメントでは、ICMP拡張エコー要求メッセージとICMP拡張エコー応答メッセージをそのリストに追加します。
IANA has performed the following actions:
IANAは次のアクションを実行しました。
o Added the following to the "ICMP Type Numbers" registry:
o 「ICMPタイプ番号」レジストリに以下を追加しました。
42 Extended Echo Request
42拡張エコー要求
Added the following to the "Type 42 - Extended Echo Request" subregistry:
「Type 42-Extended Echo Request」サブレジストリに以下を追加しました。
(0) No Error
（0）エラーなし
o Added the following to the "ICMPv6 'type' Numbers" registry:
o 「ICMPv6 'type' Numbers」レジストリに以下を追加しました：
160 Extended Echo Request
160拡張エコー要求
As ICMPv6 distinguishes between informational and error messages, and this is an informational message, the value has been assigned from the range 128-255.
ICMPv6は情報メッセージとエラーメッセージを区別し、これは情報メッセージであるため、値は128〜255の範囲から割り当てられています。
Added the following to the "Type 160 - Extended Echo Request" subregistry:
「Type 160-Extended Echo Request」サブレジストリに以下を追加しました。
(0) No Error
（0）エラーなし
o Added the following to the "ICMP Type Numbers" registry:
o 「ICMPタイプ番号」レジストリに以下を追加しました。
43 Extended Echo Reply
43拡張エコー応答
Added the following to the "Type 43 - Extended Echo Reply" subregistry:
「Type 43-Extended Echo Reply」サブレジストリに以下を追加しました。
(0) No Error (1) Malformed Query (2) No Such Interface (3) No Such Table Entry (4) Multiple Interfaces Satisfy Query
（0）エラーなし（1）不正なクエリ（2）そのようなインターフェースがない（3）そのようなテーブルエントリがない（4）複数のインターフェースがクエリを満たす
o Added the following to the "ICMPv6 'type' Numbers" registry:
o 「ICMPv6 'type' Numbers」レジストリに以下を追加しました：
161 Extended Echo Reply
161拡張エコー応答
As ICMPv6 distinguishes between informational and error messages, and this is an informational message, the value has been assigned from the range 128-255.
ICMPv6は情報メッセージとエラーメッセージを区別し、これは情報メッセージであるため、値は128〜255の範囲から割り当てられています。
Added the following to the "Type 161 - Extended Echo Reply" subregistry:
「Type 161-Extended Echo Reply」サブレジストリに以下を追加しました。
(0) No Error (1) Malformed Query (2) No Such Interface (3) No Such Table Entry (4) Multiple Interfaces Satisfy Query
（0）エラーなし（1）不正なクエリ（2）そのようなインターフェースがない（3）そのようなテーブルエントリがない（4）複数のインターフェースがクエリを満たす
o Added the following to the "ICMP Extension Object Classes and Class Sub-types" registry:
o 「ICMP拡張オブジェクトクラスとクラスサブタイプ」レジストリに以下を追加しました。
(3) Interface Identification Object
（3）インターフェース識別オブジェクト
Added the following C-types to the "Sub-types - Class 3 - Interface Identification Object" subregistry:
「サブタイプ-クラス3-インターフェイス識別オブジェクト」サブレジストリに次のCタイプを追加しました。
(0) Reserved (1) Identifies Interface by Name (2) Identifies Interface by Index (3) Identifies Interface by Address
（0）予約済み（1）インターフェースを名前で識別（2）インターフェースをインデックスで識別（3）インターフェースをアドレスで識別
C-Type values are assigned on a First Come First Serve (FCFS) basis with a range of 0-255.
Cタイプの値は、先着順（FCFS）で0〜255の範囲で割り当てられます。
All codes mentioned above are assigned on an FCFS basis with a range of 0-255.
上記のすべてのコードは、0〜255の範囲でFCFSベースで割り当てられます。
The following are legitimate uses of PROBE:
以下は、PROBEの正当な使用法です。
o to determine the operational status of an interface.
o インターフェイスの動作ステータスを判別します。
o to determine which protocols (e.g., IPv4 or IPv6) are active on an interface.
o どのプロトコル（IPv4やIPv6など）がインターフェース上でアクティブであるかを判別します。
However, malicious parties can use PROBE to obtain additional information. For example, a malicious party can use PROBE to discover interface names. Having discovered an interface name, the malicious party may be able to infer additional information. Additional information may include:
ただし、悪意のある当事者はPROBEを使用して追加情報を取得できます。たとえば、悪意のある当事者はPROBEを使用してインターフェース名を発見できます。悪意のある者がインターフェース名を発見すると、追加情報を推測できる可能性があります。追加情報には次のものがあります。
o interface bandwidth
o インターフェース帯域幅
o the type of device that supports the interface (e.g., vendor identity)
o インターフェースをサポートするデバイスのタイプ（ベンダーIDなど）
o the operating system version that the above-mentioned device executes
o 上記のデバイスが実行するオペレーティングシステムのバージョン
Understanding this risk, network operators establish policies that restrict access to ICMP Extended Echo functionality. In order to enforce these policies, nodes that support ICMP Extended Echo functionality MUST support the following configuration options:
このリスクを理解すると、ネットワークオペレーターは、ICMP拡張エコー機能へのアクセスを制限するポリシーを確立します。これらのポリシーを適用するために、ICMP拡張エコー機能をサポートするノードは、次の構成オプションをサポートする必要があります。
o Enable/disable ICMP Extended Echo functionality. By default, ICMP Extend Echo functionality is disabled.
o ICMP拡張エコー機能を有効/無効にします。デフォルトでは、ICMP拡張エコー機能は無効になっています。
o Define enabled L-bit settings. By default, the option to set the L-bit is enabled and the option to clear the L-bit is disabled.
o 有効なLビット設定を定義します。デフォルトでは、Lビットを設定するオプションは有効になっており、Lビットをクリアするオプションは無効になっています。
o Define enabled query types (i.e., by name, by index, or by address); by default, all query types are disabled.
o 有効なクエリタイプを定義します（名前、インデックス、アドレスなど）。デフォルトでは、すべてのクエリタイプが無効になっています。
o For each enabled query type, define the prefixes from which ICMP Extended Echo Request messages are permitted.
o 有効なクエリタイプごとに、ICMP拡張エコー要求メッセージが許可されるプレフィックスを定義します。
o For each interface, determine whether ICMP Echo Request messages are accepted.
o インターフェイスごとに、ICMPエコー要求メッセージを受け入れるかどうかを決定します。
When a node receives an ICMP Extended Echo Request message that it is not configured to support, it MUST silently discard the message. See Section 4 for details.
ノードがサポートするように構成されていないICMP拡張エコー要求メッセージを受信した場合、メッセージを静かに破棄する必要があります。詳細については、セクション4を参照してください。
PROBE must not leak information about one Virtual Private Network (VPN) into another. Therefore, when a node receives an ICMP Extended Echo Request and the proxy interface is in a different VPN than the probed interface, the node MUST return an ICMP Extended Echo Reply with error code equal to (2) No Such Interface.
プローブは、ある仮想プライベートネットワーク（VPN）に関する情報を別の仮想プライベートネットワークに漏出してはなりません。したがって、ノードがICMP拡張エコー要求を受信し、プロキシインターフェイスがプローブされたインターフェイスとは異なるVPNにある場合、ノードはエラーコードが（2）そのようなインターフェイスではないICMP拡張エコー応答を返さなければなりません（MUST）。
In order to protect local resources, implementations SHOULD rate-limit incoming ICMP Extended Echo Request messages.
ローカルリソースを保護するために、実装は着信ICMP拡張エコー要求メッセージをレート制限する必要があります（SHOULD）。
[RFC792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, DOI 10.17487/RFC0792, September 1981, <https://www.rfc-editor.org/info/rfc792>.
[RFC792] Postel、J。、「インターネット制御メッセージプロトコル」、STD 5、RFC 792、DOI 10.17487 / RFC0792、1981年9月、<https://www.rfc-editor.org/info/rfc792>。
[RFC826] Plummer, D., "Ethernet Address Resolution Protocol: Or Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware", STD 37, RFC 826, DOI 10.17487/RFC0826, November 1982, <https://www.rfc-editor.org/info/rfc826>.
[RFC826] Plummer、D。、「イーサネットアドレス解決プロトコル：またはネットワークプロトコルアドレスをイーサネットハードウェアで伝送するために48ビットイーサネットアドレスに変換する」、STD 37、RFC 826、DOI 10.17487 / RFC0826、1982年11月、<https：/ /www.rfc-editor.org/info/rfc826>。
[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>。
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", STD 89, RFC 4443, DOI 10.17487/RFC4443, March 2006, <https://www.rfc-editor.org/info/rfc4443>.
[RFC4443]コンタ、A。、ディアリング、S。、およびM.グプタ編、「インターネットプロトコルバージョン6（IPv6）仕様のインターネット制御メッセージプロトコル（ICMPv6）」、STD 89、RFC 4443、DOI 10.17487 / RFC4443、2006年3月、<https://www.rfc-editor.org/info/rfc4443>。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, September 2007, <https://www.rfc-editor.org/info/rfc4861>.
[RFC4861] Narten、T.、Nordmark、E.、Simpson、W。、およびH. Soliman、「Neighbor Discovery for IP version 6（IPv6）」、RFC 4861、DOI 10.17487 / RFC4861、2007年9月、<https：/ /www.rfc-editor.org/info/rfc4861>。
[RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, "Extended ICMP to Support Multi-Part Messages", RFC 4884, DOI 10.17487/RFC4884, April 2007, <https://www.rfc-editor.org/info/rfc4884>.
[RFC4884] Bonica、R.、Gan、D.、Tappan、D。、およびC. Pignataro、「マルチパートメッセージをサポートするための拡張ICMP」、RFC 4884、DOI 10.17487 / RFC4884、2007年4月、<https：// www.rfc-editor.org/info/rfc4884>。
[RFC7223] Bjorklund, M., "A YANG Data Model for Interface Management", RFC 7223, DOI 10.17487/RFC7223, May 2014, <https://www.rfc-editor.org/info/rfc7223>.
[RFC7223] Bjorklund、M。、「A YANG Data Model for Interface Management」、RFC 7223、DOI 10.17487 / RFC7223、2014年5月、<https://www.rfc-editor.org/info/rfc7223>。
[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>。
[RFC2151] Kessler, G. and S. Shepard, "A Primer On Internet and TCP/ IP Tools and Utilities", FYI 30, RFC 2151, DOI 10.17487/RFC2151, June 1997, <https://www.rfc-editor.org/info/rfc2151>.
[RFC2151]ケスラー、G.、S。シェパード、「インターネットとTCP / IPツールとユーティリティの入門書」、FYI 30、RFC 2151、DOI 10.17487 / RFC2151、1997年6月、<https：//www.rfc-editor .org / info / rfc2151>。
[RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration Guidelines for DiffServ Service Classes", RFC 4594, DOI 10.17487/RFC4594, August 2006, <https://www.rfc-editor.org/info/rfc4594>.
[RFC4594] Babiarz、J.、Chan、K。、およびF. Baker、「DiffServサービスクラスの構成ガイドライン」、RFC 4594、DOI 10.17487 / RFC4594、2006年8月、<https://www.rfc-editor.org / info / rfc4594>。
The PROBE application accepts input parameters, sets a counter, and enters a loop to be exited when the counter is equal to 0. On each iteration of the loop, PROBE emits an ICMP Extended Echo Request, decrements the counter, sets a timer, and waits. The ICMP Extended Echo Request includes an Identifier and a Sequence Number.
PROBEアプリケーションは、入力パラメーターを受け入れ、カウンターを設定し、カウンターが0に等しいときに終了するループに入ります。ループの各反復で、PROBEはICMP拡張エコー要求を発行し、カウンターをデクリメントし、タイマーを設定し、待ちます。 ICMP拡張エコー要求には、識別子とシーケンス番号が含まれています。
If an ICMP Extended Echo Reply carrying the same Identifier and Sequence Number arrives, PROBE relays information returned by that message to its user. However, on each iteration of the loop, PROBE waits for the timer to expire regardless of whether an Extended Echo Reply message arrives.
同じ識別子とシーケンス番号を持つICMP拡張エコー応答が到着すると、PROBEはそのメッセージによって返された情報をユーザーに中継します。ただし、ループの各反復で、拡張エコー応答メッセージが到着したかどうかに関係なく、プローブはタイマーの期限が切れるまで待機します。
PROBE accepts the following parameters:
PROBEは以下のパラメーターを受け入れます。
o Count
o カウント
o Wait
o 待つ
o Probing Interface Address
o インターフェイスアドレスのプローブ
o Hop Count
o ホップ数
o Proxy Interface Address
o プロキシインターフェイスアドレス
o Local
o 地元
o Probed Interface Identifier
o プローブされたインターフェイス識別子
Count is a positive integer whose default value is 3. Count determines the number of times that PROBE iterates through the above-mentioned loop.
Countは正の整数で、デフォルト値は3です。Countは、PROBEが上記のループを反復する回数を決定します。
Wait is a positive integer whose minimum and default values are 1. Wait determines the duration of the above-mentioned timer, measured in seconds.
待機は、最小値とデフォルト値が1である正の整数です。待機は、上記のタイマーの持続時間を秒単位で決定します。
Probing Interface Address specifies the Source Address of the ICMP Extended Echo Request. The Probing Interface Address MUST be a unicast address and MUST identify an interface that resides on the probing node.
プローブインターフェイスアドレスは、ICMP拡張エコー要求の送信元アドレスを指定します。プローブインターフェイスアドレスはユニキャストアドレスである必要があり、プローブノードにあるインターフェイスを識別しなければなりません。
The Proxy Interface Address identifies the interface to which the ICMP Extended Echo Request message is sent. It must be an IPv4 or IPv6 unicast address. If it is an IPv4 address, PROBE emits an ICMPv4 message. If it is an IPv6 address, PROBE emits an ICMPv6 message.
プロキシインターフェイスアドレスは、ICMP拡張エコー要求メッセージが送信されるインターフェイスを識別します。 IPv4またはIPv6ユニキャストアドレスである必要があります。 IPv4アドレスの場合、PROBEはICMPv4メッセージを送信します。 IPv6アドレスの場合、PROBEはICMPv6メッセージを送信します。
Local is a boolean value. It is TRUE if the proxy and probed interfaces both reside on the same node. Otherwise, it is FALSE.
ローカルはブール値です。プロキシーとプローブされたインターフェースの両方が同じノードにある場合はTRUEです。それ以外の場合はFALSEです。
The Probed Interface Identifier identifies the probed interface. It is one of the following:
プローブインターフェイスIDは、プローブインターフェイスを識別します。次のいずれかです。
o an interface name;
o インターフェース名;
o an address from any address family (e.g., IPv4, IPv6, IEEE 802, 48-bit MAC, or 64-bit MAC); or
o 任意のアドレスファミリのアドレス（IPv4、IPv6、IEEE 802、48ビットMAC、64ビットMACなど）。または
o an if-index.
o if-index。
If the Probed Interface Identifier is an address, it does not need to be of the same address family as the proxy interface address. For example, PROBE accepts an IPv4 Proxy Interface Address and an IPv6 Probed Interface Identifier.
プローブインターフェイス識別子がアドレスである場合、プロキシインターフェイスアドレスと同じアドレスファミリである必要はありません。たとえば、PROBEはIPv4プロキシインターフェイスアドレスとIPv6プローブインターフェイス識別子を受け入れます。
Acknowledgments
謝辞
Thanks to Sowmini Varadhan, Jeff Haas, Carlos Pignataro, Jonathan Looney, Dave Thaler, Mikio Hara, Joel Halpern, Yaron Sheffer, Stefan Winter, Jean-Michel Combes, Amanda Barber, and Joe Touch for their thoughtful review of this document.
このドキュメントをよく読んでいただいたSowmini Varadhan、Jeff Haas、Carlos Pignataro、Jonathan Looney、Dave Thaler、Mikio Hara、Joel Halpern、Yaron Sheffer、Stefan Winter、Jean-Michel Combes、Amanda Barber、Joe Touchに感謝します。
Authors' Addresses
著者のアドレス
Ron Bonica Juniper Networks 2251 Corporate Park Drive Herndon, Virginia 20171 United States of America
Ron Bonica Juniper Networks 2251 Corporate Park Drive Herndon、Virginia 20171アメリカ合衆国
Email: rbonica@juniper.net
Reji Thomas Juniper Networks Elnath-Exora Business Park Survey Bangalore, Karnataka 560103 India
Reji Thomas Juniper Networks Elnath-Exora Business Park Survey Bangalore、Karnataka、560103 India
Email: rejithomas@juniper.net
Jen Linkova Google 1600 Amphitheatre Parkway Mountain View, California 94043 United States of America
Jen Linkova Google 1600 Amphitheatre Parkway Mountain View、California 94043 United States of America
Email: furry@google.com
Chris Lenart Verizon 22001 Loudoun County Parkway Ashburn, Virginia 20147 United States of America
Chris Lenart Verizon 22001 Loudoun County Parkwayバージニア州アシュバーン20147アメリカ合衆国
Email: chris.lenart@verizon.com
Mohamed Boucadair Orange Rennes 35000 France
Mohamed Boucadair Orange Rennes 35000フランス
Email: mohamed.boucadair@orange.com