Internet Engineering Task Force (IETF) A. Atlas, Ed.
Request for Comments: 5837 BT
Category: Standards Track R. Bonica, Ed.
ISSN: 2070-1721 Juniper Networks
C. Pignataro, Ed.
N. Shen
Cisco Systems
JR. Rivers
Consultant
April 2010
Extending ICMP for Interface and Next-Hop Identification
Abstract
抽象
This memo defines a data structure that can be appended to selected ICMP messages. The ICMP extension defined herein can be used to identify any combination of the following: the IP interface upon which a datagram arrived, the sub-IP component of an IP interface upon which a datagram arrived, the IP interface through which the datagram would have been forwarded had it been forwardable, and the IP next hop to which the datagram would have been forwarded.
このメモは、選択されたICMPメッセージに付加することができるデータ構造を定義します。データグラムが到着した時にIPインターフェイス、データグラムがあったであろう、それを通してデータグラムが到着した時にIPインターフェイス、IPインタフェースのサブIP成分：本明細書で定義されるICMPの拡張は、以下のいずれかの組み合わせを同定するために使用することができますそれが転送されていた転送され、データグラムが転送されていた先のIPネクストホップ。
Devices can use this ICMP extension to identify interfaces and their components by any combination of the following: ifIndex, IPv4 address, IPv6 address, name, and MTU. ICMP-aware devices can use these extensions to identify both numbered and unnumbered interfaces.
ifIndexの、IPv4アドレス、IPv6アドレス、名前、およびMTU：デバイスは、次の任意の組み合わせによってインターフェイスとそのコンポーネントを識別するために、このICMP拡張を使用することができます。 ICMP対応デバイスは、番号と番号なしの両方のインターフェイスを識別するために、これらの拡張機能を使用することができます。
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/rfc5837.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc5837で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版RFCとして、英語以外の言語に翻訳します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used In This Document . . . . . . . . . . . . . . 5
3. Applications . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Application to Traceroute . . . . . . . . . . . . . . . . 5
3.2. Policy and MTU Detection . . . . . . . . . . . . . . . . . 6
4. Interface Information Object . . . . . . . . . . . . . . . . . 6
4.1. C-Type Meaning in an Interface Information Object . . . . 7
4.2. Interface IP Address Sub-Object . . . . . . . . . . . . . 9
4.3. Interface Name Sub-Object . . . . . . . . . . . . . . . . 10
4.4. Interface Information Object Examples . . . . . . . . . . 10
4.5. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5. Network Address Translation Considerations . . . . . . . . . . 14
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.1. Normative References . . . . . . . . . . . . . . . . . . . 16
9.2. Informative References . . . . . . . . . . . . . . . . . . 16
IP devices use the Internet Control Message Protocol (ICMPv4 [RFC0792] and ICMPv6 [RFC4443]) to convey control information. In particular, when an IP device receives a datagram that it cannot process, it may send an ICMP message to the datagram's originator. Network operators and higher-level protocols use these ICMP messages to detect and diagnose network issues.
IPデバイスは、制御情報を伝えるために、インターネット制御メッセージプロトコル（ICMPv4の[RFC0792]とのICMPv6 [RFC4443]）を使用します。具体的には、IPデバイスは、プロセス、それがデータグラムの発信元にICMPメッセージを送信してもよいことができないデータグラムを受信した場合。ネットワークオペレータと高レベルプロトコルは、ネットワークの問題を検出し、診断するために、これらのICMPメッセージを使用しています。
In the simplest case, the source address of the ICMP message identifies the interface upon which the datagram arrived. However, in many cases, the incoming interface is not identified by the ICMP message at all. Details follow:
最も単純なケースでは、ICMPメッセージの送信元アドレスは、データグラムが到着した時にインターフェースを識別する。しかし、多くの場合、着信インターフェイスは全くICMPメッセージによって識別されません。詳細は以下のとおりです。
According to [RFC1812], when a router generates an ICMPv4 message, the source address of that message MUST be one of the following:
ルータはICMPv4のメッセージを生成する[RFC1812]によると、そのメッセージの送信元アドレスは、次のいずれかである必要があります
o one of the IP addresses associated with the physical interface over which the ICMPv4 message is transmitted
ICMPv4のメッセージが伝送される物理インタフェースに関連付けられたIPアドレスの1つO
o if that interface has no IP addresses associated with it, the device's router-id or host-id is used instead.
そのインターフェイスは、それに関連付けられたIPアドレスを持っていない場合は、O、デバイスのルータIDまたはホストIDが代わりに使用されます。
If all of the following conditions are true, the source address of the ICMPv4 message identifies the interface upon which the original datagram arrived:
次の条件がすべて真である場合、ICMPv4のメッセージの送信元アドレスは、元のデータグラムが到着した時にインターフェースを識別する。
o the device sends an ICMPv4 message through the same interface upon which the original datagram was received
Oデバイスは、元のデータグラムを受信した際に同じインタフェースを介しICMPv4のメッセージを送信します
o that interface is numbered
そのインターフェイスは、番号はO
However, the incoming and outgoing interfaces may be different due to an asymmetric return path, which can occur due to asymmetric link costs, parallel links, or Equal Cost Multipath (ECMP).
しかし、着信および発信インターフェイスが原因非対称リンクコスト、平行リンク、または等価コストマルチパス（ECMP）に起因する起こり得る非対称リターンパスに異なっていてもよいです。
Similarly, [RFC1122] provides guidance for source address selection for multihomed IPv4 hosts. These recommendations, like those stated above, do not always cause the source address of an ICMPv4 message to identify the incoming interface.
同様に、[RFC1122]は、マルチホームIPv4ホストの送信元アドレスを選択するためのガイダンスを提供します。これらの推奨事項は、前述のものと同様、常にICMPv4のメッセージの送信元アドレスが着信インターフェイスを識別することはありません。
ICMPv6 is somewhat more flexible. [RFC4443] states that for responses to messages sent to a non-local interface, the source address must be chosen as follows:
ICMPv6のは多少柔軟です。 [RFC4443]は次のように非ローカルインタフェースに送信されたメッセージに応答するために、送信元アドレスを選択しなければならないと述べています。
o the Source Address of the ICMPv6 packet MUST be a unicast address belonging to the node. The address SHOULD be chosen according to the rules that would be used to select the source address for any other packet originated by the node, given the destination address of the packet. However, it MAY be selected in an alternative way if this would lead to a more informative choice of address reachable from the destination of the ICMPv6 packet.
OのICMPv6パケットの送信元アドレスは、ノードに属するユニキャストアドレスであるに違いありません。アドレスは、パケットの宛先アドレスが与えられると、ノードによって発信され、他のパケットの送信元アドレスを選択するために使用される規則に従って選択されるべきです。これはのICMPv6パケットの宛先から到達可能なアドレスより多くの有益な選択につながる場合は、それは別の方法で選択することができます。
When a datagram that cannot be processed arrives on an unnumbered interface, neither ICMPv4 nor ICMPv6 is currently capable of identifying the incoming interface. Even when an ICMP message is generated such that the ICMP source address identifies the incoming interface, the receiver of that ICMP message has no way of knowing if this is the case. ICMP extensions are required to explicitly identify the incoming interface.
処理できないデータグラムが無数インターフェイスに到着すると、ICMPv4のもICMPv6のいずれも現在着信インターフェイスを識別することが可能です。このような場合にはICMPメッセージがICMP送信元アドレスは、着信インターフェイスを識別するように生成された場合でも、そのICMPメッセージの受信者は知る方法がありません。 ICMP拡張は、明示的に着信インターフェイスを識別するために必要とされています。
Using the extension defined herein, a device can explicitly identify the incoming IP interface or its sub-IP components by any combination of the following:
本明細書で定義される拡張機能を使用して、デバイスは、明示的に次のいずれかの組み合わせによって、着信IPインターフェイスまたはそのサブIPコンポーネントを識別することができます。
o ifIndex
OのifIndex
o IPv4 address
O IPv4アドレス
o IPv6 address
O IPv6アドレス
o name
O名
o MTU
MTU O
The interface name SHOULD be identical to the first 63 octets of the ifName, as defined in [RFC2863]. The ifIndex is also defined in [RFC2863].
インタフェース名は[RFC2863]で定義されるように、のifNameの最初の63オクテットと同一であるべきです。 ifIndexのはまた、[RFC2863]で定義されています。
Using the same extension, an IP device can explicitly identify by the above the outgoing interface over which a datagram would have been forwarded if that datagram had been deliverable.
同じ拡張子を使用して、IPデバイスは、明示的にそのデータグラムが成果となっていた場合、データグラムが転送されていたであろう、その上、発信インターフェイス上で識別することができます。
The next-hop IP address, to which the datagram would have been forwarded, can also be identified using this same extension. This information can be used for creating a downstream map. The next-hop information may not always be available. There are corner-cases where it doesn't exist and there may be implementations where it is not practical to provide this information. This specification provides an encoding for providing the next-hop IP address when it is available.
データグラムが転送されていた先のネクストホップIPアドレスも、この同じ拡張子を使用して識別することができます。この情報は、下流のマップを作成するために使用することができます。ネクストホップ情報は常に利用できない場合があります。それは存在せず、この情報を提供することは現実的ではない実装があるかもしれないコーナーケースがあります。この仕様は、それが利用可能な場合、ネクストホップIPアドレスを提供するための符号化を提供します。
The extension defined herein uses the ICMP multi-part message framework defined in [RFC4884]. The same backward compatibility issues that apply to [RFC4884] apply to this extension.
本明細書で定義される拡張機能は[RFC4884]で定義されたICMPマルチパートメッセージのフレームワークを使用します。 [RFC4884]に適用されるのと同じ下位互換性の問題は、この拡張機能に適用されます。
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]に記載されているように解釈されます。
ICMP extensions defined in this memo provide additional capability to traceroute. An enhanced traceroute application, like older implementations, identifies nodes that a datagram visited en route to its destination. It differs from older implementations in that it can explicitly identify the following at each node:
このメモで定義されたICMPの拡張は、トレースルートに追加の機能を提供します。拡張tracerouteのアプリケーションは、古い実装と同様に、データグラムが宛先への途中で訪れたノードを識別します。それが明示的に各ノードで次のように識別できるように古い実装と異なります。
o the IP interface upon which a datagram arrived
データグラムが到着した時にIPインタフェースO
o the sub-IP component of an IP interface upon which a datagram arrived
データグラムが到着した時にIPインターフェイスのサブIP成分O
o the IP interface through which the datagram would have been forwarded had it been forwardable
それが転送されていたデータグラムが転送されていたであろう、それを通してIPインタフェースO
o the IP next hop to which the datagram would have been forwarded
データグラムが転送されていた先のIPネクストホップO
Enhanced traceroute applications can identify the above listed entities by:
：拡張tracerouteのアプリケーションは、上記で列挙されたエンティティを識別することができます
o ifIndex
OのifIndex
o IPv4 address
O IPv4アドレス
o IPv6 address
O IPv6アドレス
o name
O名
o MTU
MTU O
The ifIndex can be utilized within a management domain to map to an actual interface, but it is also valuable in public applications. The ifIndex can be used as an opaque token to discern whether or not two ICMP messages generated from the same router involve the same interface.
ifIndexが、実際のインタフェースにマッピングするには、管理ドメイン内で利用することができますが、それは公共の用途にも貴重です。 ifIndexの同じルータから生成された2つのICMPメッセージは同じインタフェースを含むか否かを識別する不透明トークンとして使用することができます。
A general application would be to identify which outgoing interface triggered a given function for the original packet. For example, if an access control list (ACL) drops the packet and Dest Unreachable/ Admin Prohibited denies the packet, being able to identify the outgoing interface might be useful. Another example would be to support Path MTU Discovery (PMTUD), since this would allow identification of which outgoing interface can't support a given MTU size. For example, knowledge of the problematic interface would allow an informed request for reconfiguration of the MTU of that interface.
一般的なアプリケーションは、元のパケットのために与えられた機能をトリガした出力インターフェースを識別することであろう。例えば、アクセス制御リスト（ACL）は、パケットをドロップし、取引先到達不能/管理禁止は有用かもしれない発信インターフェイスを識別することができる、パケットを拒否します。別の例では、これは、発信インターフェイスは、所与のMTUサイズをサポートすることができないの同定を可能にするため、パスMTUディスカバリ（PMTUD）をサポートすることであろう。例えば、問題のインタフェースの知識は、そのインターフェースのMTUの再構成のための通知要求を可能にします。
This section defines the Interface Information Object, an ICMP extension object with a Class-Num (Object Class Value) of 2 that can be appended to the following messages:
このセクションでは、インターフェイス情報オブジェクト、次のメッセージに付加することができる2のクラスのNum（オブジェクト・クラス値）とICMP拡張オブジェクトを定義します。
o ICMPv4 Time Exceeded
O ICMPv4の時間が超過します
o ICMPv4 Destination Unreachable
OのICMPv4の宛先到達不能
o ICMPv4 Parameter Problem
O ICMPv4のパラメータ問題
o ICMPv6 Time Exceeded
OのICMPv6時間超過します
o ICMPv6 Destination Unreachable
OのICMPv6宛先到達不能
For reasons described in [RFC4884], this extension cannot be appended to any of the currently defined ICMPv4 or ICMPv6 messages other than those listed above.
[RFC4884]に記載の理由により、この拡張は、上記以外の現在定義されているのICMPv4またはICMPv6のメッセージのいずれかに付加することができません。
The extension defined herein MAY be appended to any of the above listed messages and SHOULD be appended whenever required to identify an unnumbered interface and when local policy or security considerations do not supersede this requirement.
本明細書で定義される拡張は、上記のメッセージのいずれかに付加されてもよく、無数のインタフェースおよび場合ローカルポリシーまたはセキュリティの考慮事項は、この要件を優先していないを識別するために必要なときはいつでも追加されます。
A single ICMP message can contain as few as zero and as many as four instances of the Interface Information Object. It is illegal if it contains more than four instances, because that means that an interface role is used more than once (see Section 4.5).
単一ICMPメッセージはゼロとして数とインタフェース情報オブジェクトの最大4つのインスタンスとして含めることができます。それはインターフェースの役割は、（セクション4.5を参照）を1回以上使用されていることを意味するので、それは、以上の4つのインスタンスが含まれている場合は違法です。
A single instance of the Interface Information Object can provide information regarding any one of the following interface roles:
インタフェース情報オブジェクトの単一のインスタンスは、以下のインターフェースの役割のいずれかに関する情報を提供することができます。
o the IP interface upon which a datagram arrived o the sub-IP component of an IP interface upon which a datagram arrived
データグラムは、データグラムが到着した時にIPインターフェイスのサブIPコンポーネントoを到着した時にIPインターフェイスO
o the IP interface through which the datagram would have been forwarded had it been forwardable
それが転送されていたデータグラムが転送されていたであろう、それを通してIPインタフェースO
o the IP next hop to which the datagram would have been forwarded
データグラムが転送されていた先のIPネクストホップO
The following are examples of sub-IP components of IP interfaces upon which a datagram might arrive:
データグラムが到着する可能性があり、その上にIPインターフェイスのサブIP成分の例です。
o Ethernet Link Aggregation Group Member
イーサネットリンクアグリゲーショングループメンバーO
o Multilink PPP bundle member
マルチリンクPPPバンドルメンバーO
o Multilink frame relay bundle member
Oマルチリンクフレームリレーバンドルメンバー
To minimize the number of octets required for this extension, there are four different pieces of information that can appear in an Interface Information Object.
この拡張機能に必要なオクテット数を最小限に抑えるために、インタフェース情報オブジェクトに表示できる情報4つの異なる部分があります。
1. The ifIndex of the interface of interest MAY be included. This is the 32-bit ifIndex assigned to the interface by the device as specified by the Interfaces Group MIB [RFC2863].
1.関心のインタフェースのifIndexが含まれるかもしれません。これは、インタフェースグループMIB [RFC2863]で指定されたデバイスによってインタフェースに割り当てられた32ビットのifIndexです。
2. An IP Address Sub-Object MAY be included if either of the following conditions is true: a) the eliciting datagram is IPv4 and the identified interface has at least one IPv4 address associated with it, or b) the eliciting datagram is IPv6 and the identified interface has at least one IPv6 address associated with it. The IP Address Sub-Object is described in Section 4.2 of this memo.
以下の条件のいずれかに該当する場合2.アンIPアドレスのサブオブジェクトが含まれていてもよい：A）誘発データグラムは、IPv4であると同定されたインタフェースは、それに関連付けられた少なくとも1つのIPv4アドレスを持つ、またはb）誘発データグラムがIPv6であり識別インタフェースは、それに関連付けられた少なくとも1つのIPv6アドレスを持っています。 IPアドレスのサブオブジェクトは、このメモのセクション4.2に記載されています。
3. An Interface Name Sub-Object, containing a string of no more than 63 octets, MAY be included. That string, as specified in Section 4.3, is the interface name and SHOULD be the MIB-II ifName [RFC2863], but MAY be some other human-meaningful name of the interface.
せいぜい63オクテットの文字列を含む前記アンインタフェース名サブオブジェクトが含まれてもよいです。その文字列は、セクション4.3で指定されるように、インタフェース名、MIB-IIのifName [RFC2863]であるべきであるが、インターフェースのいくつかの他の人間がわかりやすい名前であるかもしれ。
For this object, the C-Type [RFC4884] is used to indicate both the role of the interface and the information that is included. This is illustrated in Figure 1.
この目的のために、C型[RFC4884]はインターフェイスの役割と含まれている情報の両方を示すために使用されます。これは、図1に示されています。
Bit 0 1 2 3 4 5 6 7
+-------+-------+-------+-------+-------+-------+-------+-------+
| Interface Role| Rsvd1 | Rsvd2 |ifIndex| IPAddr| name | MTU |
+-------+-------+-------+-------+-------+-------+-------+-------+
Figure 1: C-Type for the Interface Information Object
図1：インタフェースの情報オブジェクトのためのC型
The following are bit-field definitions for C-Type:
以下は、C型のビット・フィールドの定義です：
Interface Role (bits 0-1): These bits indicates the role of the interface being identified. The enumerated values are given below:
インタフェースの役割（ビット0-1）：これらのビットは、識別されるインタフェースの役割を示しています。列挙値は以下の通りです：
Value 0: This object describes the IP interface upon which a datagram arrived
値0：このオブジェクトは、データグラムが到着した時にIPインタフェースを記述する
Value 1: This object describes the sub-IP component of an IP interface upon which a datagram arrived
値1：このオブジェクトは、データグラムが到着した時にIPインターフェイスのサブIPコンポーネントを記述します
Value 2: This object describes the IP interface through which the datagram would have been forwarded had it been forwardable
値2：このオブジェクトは、それが転送されていたデータグラムが転送されていたであろう、それを通してIPインタフェースを記述する
Value 3: This object describes the IP next hop to which the datagram would have been forwarded
値3：このオブジェクトは、データグラムが転送されていた先のIPネクストホップを記述する
Reserved 1 (bit 2): This bit is reserved for future use and MUST be set to 0 and MUST be ignored on receipt.
予約1（ビット2）：このビットは将来の使用のために予約され、0に設定しなければならなくて、領収書の上で無視しなければなりません。
Reserved 2 (bit 3): This bit is reserved for future use and MUST be set to 0 and MUST be ignored on receipt.
予約2（ビット3）：このビットは将来の使用のために予約され、0に設定しなければならなくて、領収書の上で無視しなければなりません。
ifIndex (bit 4) : When set, the 32-bit ifIndex of the interface is included. When clear, the ifIndex is not included.
ifIndexの（ビット4）：セット、インターフェースの32ビットのifIndexが含まれています。クリアすると、ifIndexのは含まれていません。
IP Addr (bit 5) : When set, an IP Address Sub-Object is present. When clear, an IP Address Sub-Object is not present. The IP Address Sub-Object is described in Section 4.2 of this memo.
IP ADDR（ビット5）：セット、IPアドレスのサブオブジェクトが存在します。クリアすると、IPアドレスのサブオブジェクトは存在しません。 IPアドレスのサブオブジェクトは、このメモのセクション4.2に記載されています。
Interface Name (bit 6): When set, an Interface Name Sub-Object is included. When clear, it is not included. The Name Sub-Object is described in Section 4.3 of this memo.
インターフェース名（ビット6）：セット、インタフェース名のサブオブジェクトが含まれています。クリアすると、それが含まれていません。名前サブオブジェクトは、このメモのセクション4.3に記載されています。
MTU (bit 7): When set, a 32-bit integer representing the MTU is present. When clear, this 32-bit integer is not present.
MTU（ビット7）：セット、MTUを表す32ビット整数が存在します。場合明らかに、この32ビットの整数は存在しません。
The information included does not self-identify, so this specification defines a specific ordering for sending the information that must be followed.
含まれている情報は、自己識別していないので、この仕様に従わなければならない情報を送信するための特定の順序を定義します。
If bit 4 (ifIndex) is set, then the 32-bit ifIndex MUST be sent first. If bit 5 (IP Address) is set, an IP Address Sub-Object MUST be sent next. If bit 6 (Name) is set, an Interface Name Sub-Object MUST be sent next. If bit 7 is set, an MTU MUST be sent next. The information order is thus: ifIndex, IP Address Sub-Object, Interface Name Sub-Object, and MTU. Any or all pieces of information may be present or absent, as indicated by the C-Type. Any data that follows these optional pieces of information MUST be ignored.
ビット4（ifIndexの）が設定されている場合、32ビットのifIndexは、最初に送信されなければなりません。ビット5（IPアドレス）が設定されている場合、IPアドレスのサブオブジェクトは、次に送らなければなりません。ビット6（名）が設定されている場合、インタフェース名サブオブジェクトは、次に送らなければなりません。ビット7が設定されている場合は、MTUは次送らなければなりません。情報の順序は、このようです：ifIndexの、IPアドレスのサブオブジェクト、インターフェイス名サブオブジェクト、およびMTU。 C型によって示されるように情報のいずれかまたはすべての部分は、存在するか又は存在しなくてもよいです。これらの情報の任意の部分を次のいずれかのデータは無視しなければなりません。
It is valid (though pointless until additional bits are assigned by IANA) to receive an Interface Information Object where bits 4, 5, 6, and 7 are all 0; this MUST NOT generate a warning or error.
これは、ビット4、5、6、及び7は、全て0である場合、オブジェクトインタフェース情報を受信する（無意味ただし、追加ビットはIANAによって割り当てられるまで）が有効です。これは、警告またはエラーを生成してはなりません。
Figure 2 depicts the Interface Address Sub-Object:
図2は、インターフェイスアドレスサブオブジェクトを表しています。
0 31
+-------+-------+-------+-------+
| AFI | Reserved |
+-------+-------+-------+-------+
| IP Address ....
Figure 2: Interface Address Sub-Object
図2：インターフェイスアドレスのサブオブジェクト
The IP Address Sub-Object contains the following fields:
IPアドレスのサブオブジェクトには、次のフィールドが含まれています。
o Address Family Identifier (AFI): This 16-bit bit field identifies the type of address represented by the IP Address field. It also determines the length of that field and the length of the entire sub-object. Values for this field represent a subset of values found in the IANA registry of Address Family Numbers (available from <http://www.iana.org>). Valid values are 1 (representing a 32-bit IPv4 address) and 2 (representing a 128-bit IPv6 address).
Oアドレスファミリ識別子（AFI）：この16ビットのビットフィールドは、IPアドレスフィールドによって示されるアドレスのタイプを識別する。それはまた、そのフィールドの長さと全体サブオブジェクトの長さを決定します。このフィールドの値は、アドレスファミリ番号（<http://www.iana.org>から入手可能）のIANAレジストリで見つかった値のサブセットを表します。有効値は1（32ビットのIPv4アドレスを表す）及び2（128ビットのIPv6アドレスを表す）です。
o Reserved: This 16-bit field MUST be set to zero and ignored upon receipt.
O予約：この16ビットのフィールドはゼロに設定され、受信時に無視しなければなりません。
o IP Address: This variable-length field represents an IP address associated with the identified interface.
O IPアドレス：この可変長フィールドは、識別されたインターフェイスに関連付けられたIPアドレスを表します。
If the eliciting datagram was IPv4, the IP Interface Sub-Object MUST represent an IPv4 address. Likewise, if the eliciting datagram was IPv6, the IP Interface Sub-Object MUST represent an IPv6 address.
誘発データグラムは、IPv4であった場合、IPインターフェイスサブオブジェクトは、IPv4アドレスを表現しなければなりません。同様に、引き出すデータグラムだった場合のIPv6、IPインタフェースのサブオブジェクトは、IPv6アドレスを表現しなければなりません。
Figure 3 depicts the Interface Name Sub-Object:
図3は、インタフェース名サブオブジェクトを示します。
octet 0 1 63
+--------+-----------................-----------------+
| length | interface name octets 1-63 |
+--------+-----------................-----------------+
Figure 3: Interface Name Sub-Object
図3：インターフェイス名サブオブジェクト
The Interface Name Sub-Object MUST have a length that is a multiple of 4 octets and MUST NOT exceed 64 octets.
インタフェース名サブオブジェクトは、4つのオクテットの倍数であり、64個のオクテットを超えない長さでなければなりません。
The Length field represents the length of the Interface Name Sub-Object, including the length and the interface name in octets. The maximum valid length is 64 octets. The length is constrained to ensure there is space for the start of the original packet and additional information.
Lengthフィールドは、オクテットの長さとインタフェース名を含むインタフェース名のサブオブジェクトの長さを表します。有効な最大長は64オクテットです。長さは、元のパケットと付加情報の開始のためのスペースがあることを確認するように制約されます。
The second field contains the human-readable interface name. The interface name SHOULD be the full MIB-II ifName [RFC2863], if less than 64 octets, or the first 63 octets of the ifName, if the ifName is longer. The interface name MAY be some other human-meaningful name of the interface. It is useful to provide the ifName for cross-correlation with other MIB information and for human-reader familiarity. The interface name MUST be padded with ASCII NULL characters if the object would not otherwise terminate on a 4-octet boundary.
2番目のフィールドは、人間が読めるインターフェース名が含まれています。 64オクテット未満、またはのifNameの最初の63個のオクテット場合のifNameが長い場合、インタフェース名は、完全なMIB-IIのifName [RFC2863]であるべきです。インタフェース名は、インタフェースのいくつかの他の人間が意味のある名前かもしれ。他のMIB情報との相互相関およびヒトリーダー親密のためのifNameを提供することが有用です。オブジェクトは、それ以外の場合は4オクテット境界で終了しないならば、インタフェース名はASCII NULL文字で埋めなければなりません。
The interface name MUST be represented in the UTF-8 charset [RFC3629] using the Default Language [RFC2277].
インターフェース名は、デフォルト言語[RFC2277]を使用して、UTF-8文字セット[RFC3629]で表現されなければなりません。
Figure 4 shows a full ICMPv4 Time Exceeded message, including the Interface Information Object, which must be preceded by an ICMP Extension Structure Header and an ICMP Object Header. Both are defined in [RFC4884].
図4は、ICMP延長構造ヘッダーとICMPオブジェクトヘッダが先行されなければならないインタフェース情報オブジェクトを含む完全ICMPv4の時間超過メッセージを、示しています。双方は、[RFC4884]で定義されています。
Although examples show an Interface Name Sub-Object of length 64, this is only for illustration and depicts the maximum allowable length.
例は、長さ64のインタフェース名のサブオブジェクトを示すが、これは例示のためのみであり、最大許容長を示します。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| unused | Length | unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Internet Header + leading octets of original datagram |
| |
| // |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver=2 | (Reserved) | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length |Class-Num=2 | C-Type=00001010b |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ifIndex |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Name Sub-Object, 32-bit word 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Name Sub-Object, 32-bit word 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: ICMPv4 Time Exceeded Message with Interface Information Object
図4：インタフェース情報オブジェクトとICMPv4の時間超過メッセージ
Figure 5 depicts an Interface Information Object representing an incoming interface identified by ifIndex and Name.
図5は、ifIndexのと名前によって識別される着信インタフェースを表すインタフェース情報オブジェクトを示します。
Class-Num = 2
C-Type = 00001010b // Indicates incoming interface
Length = 72 (4 + 4 + 64)
0 1 2 3
+--------------+--------------+--------------+--------------+
| Interface ifIndex |
+--------------+--------------+--------------+--------------+
| Length | Name, word 1 |
+--------------+--------------+--------------+--------------+
... ...
+--------------+--------------+--------------+--------------+
| Name, word 16 |
+--------------+--------------+--------------+--------------+
Figure 5: Incoming Interface: By ifIndex and Name
図5：着信インターフェイス：のifIndexと名前で
Figure 6 depicts an Interface Information Object representing an incoming interface identified by ifIndex, IPv4 Address, and Name.
図6はifIndexの、IPv4アドレス、および名前によって識別される着信インタフェースを表すインタフェース情報オブジェクトを示します。
Class-Num = 2
C-Type = 00001110b // Indicates incoming interface
Length = 80 (4 + 4 + 8 + 64)
0 1 2 3
+--------------+--------------+--------------+--------------+
| Interface ifIndex |
+--------------+--------------+--------------+--------------+
| AFI | Reserved |
+--------------+--------------+--------------+--------------+
| IPv4 address |
+--------------+--------------+--------------+--------------+
| Length | Name, word 1 |
+--------------+--------------+--------------+--------------+
... ...
+--------------+--------------+--------------+--------------+
| Name, word 16 |
+--------------+--------------+--------------+--------------+
Figure 6: Incoming Interface: by ifIndex, IPv4 Address, and Name
図6：着信インターフェイス：ifIndexによって、IPv4アドレス、および名前
Figure 7 depicts an Interface Information Object representing an incoming interface identified by ifIndex and IPv6 Address.
図7は、ifIndexのとIPv6アドレスによって識別着信インタフェースを表すインタフェース情報オブジェクトを示します。
Class-Num = 2
C-Type = 00001100b // Indicates incoming interface
Length = 28 (4 + 4 + 20)
0 1 2 3
+--------------+--------------+--------------+--------------+
| Interface ifIndex |
+--------------+--------------+--------------+--------------+
| AFI | Reserved |
+--------------+--------------+--------------+--------------+
| IPv6 address, 32-bit word 1 |
+--------------+--------------+--------------+--------------+
| IPv6 address, 32-bit word 2 |
+--------------+--------------+--------------+--------------+
| IPv6 address, 32-bit word 3 |
+--------------+--------------+--------------+--------------+
| IPv6 address, 32-bit word 4 |
+--------------+--------------+--------------+--------------+
Figure 7: Incoming Interface: By ifIndex and IPv6 Address
図7：着信インターフェイス：のifIndexとIPv6アドレスで
Figure 8 depicts an Interface Information Object representing an outgoing interface identified by ifIndex and Name.
図8は、ifIndexのと名前によって識別発信インタフェースを表すインタフェース情報オブジェクトを示します。
Class-Num = 2
C-Type = 10001010b // Indicates outgoing interface
Length = 72 (4 + 4 + 64)
0 1 2 3
+--------------+--------------+--------------+--------------+
| Interface ifIndex |
+--------------+--------------+--------------+--------------+
| Length | Name, word 1 |
+--------------+--------------+--------------+--------------+
... ...
+--------------+--------------+--------------+--------------+
| Name, word 16 |
+--------------+--------------+--------------+--------------+
Figure 8: Outgoing Interface: By ifIndex and Name
図8：発信インターフェース：のifIndexと名前で
Multiple Interface Information Objects MAY be included within a single ICMP message, provided that each Interface Information Object specifies a unique role. A single ICMP message MUST NOT contain two Interface Information Objects that specify the same role.
複数インターフェース情報オブジェクトは、各インターフェイスの情報オブジェクトは、独自の役割を指定することを提供し、単一ICMPメッセージ内に含めることができます。単一ICMPメッセージは、同じ役割を指定する2つのインタフェース情報オブジェクトを含めることはできません。
ifIndex, MTU, and name information MAY be included whenever it is available; more than one instance of each of these three information elements MUST NOT be included per Interface Information Object.
それが利用可能であるたびのifIndex、MTU、および名前の情報が含まれるかもしれ。これらの3つの情報要素のそれぞれの複数のインスタンスは、インターフェイス情報オブジェクトごとに含んではいけません。
A single instance of IP Address information MAY be included in an Interface Information Object under the following circumstances:
IPアドレス情報の単一のインスタンスは、以下のような状況でインタフェース情報オブジェクトに含まれることがあります。
o if the eliciting datagram is IPv4 and an IPv4 address is associated with the identified interface. In this case, if an IP Address Sub-Object is included, it must specify an IPv4 address.
O誘発データグラムは、IPv4であり、IPv4アドレスが特定のインタフェースに関連付けられている場合。 IPアドレスのサブオブジェクトが含まれている場合は、この場合には、それはIPv4アドレスを指定する必要があります。
o if the eliciting datagram is IPv6 and an IPv6 address is associated with the identified interface. In this case, if an IP Address Sub-Object is included, it must specify an IPv6 address.
O誘発データグラムは、IPv6であるとIPv6アドレスが識別されたインタフェースに関連付けられている場合。 IPアドレスのサブオブジェクトが含まれている場合は、この場合には、それはIPv6アドレスを指定する必要があります。
In all other circumstances, IP address information MUST NOT be included.
他のすべての状況では、IPアドレス情報を含んではいけません。
An ICMP message that does not conform to these rules and contains multiple instances of the same information is considered illegal; specifically, an ICMP message containing more than one Interface
これらの規則に準拠し、同じ情報の複数のインスタンスを含んでいないICMPメッセージが不正であると考えられます。具体的には、複数のインターフェイスを含むICMPメッセージ
Information Object with the same role, as well as an ICMP message containing a duplicate information element in a given role are considered illegal. If such an illegal ICMP message is received, it MUST be silently discarded.
同じ役割を持つ情報オブジェクト、ならびに所与の役割に重複する情報要素を含むICMPメッセージが不正であると考えられます。このような違法なICMPメッセージが受信される場合、それは静かに捨てなければなりません。
[RFC5508] encourages Traditional IP Network Address Translators (Traditional NATs; see [RFC3022]) to support ICMP extension objects. This document defines an ICMP extension that includes IP addresses and therefore contains realm-specific information, and consequently describes possible NAT behaviors in the presence of these extensions.
[RFC5508]は従来のIPネットワークアドレス変換奨励（繁体NATのを、[RFC3022]を参照）ICMP拡張オブジェクトをサポートします。この文書では、IPアドレスを含み、したがって、レルム固有の情報が含まれているICMP拡張を定義し、その結果、これらの拡張機能の存在下で可能なNATの動作を説明します。
NAT devices MUST NOT translate or overwrite the ICMP extensions described herein. That is, they MUST either remove the extension entirely or pass it unchanged.
NATデバイスは、本明細書に記載のICMP拡張を翻訳したり上書きしてはなりません。つまり、彼らはどちらかの完全拡張子を削除するか、そのままそれを渡す必要があります。
It is conceivable that a NAT device might translate an ICMP header without translating the extension defined herein. In this case, the ICMP message might contain two instances of the same address, one translated and the other untranslated. Therefore, application developers should not assume addresses in the extension are of the same realm as the addresses in the datagram's header.
NATデバイスは、本明細書に定義された拡張を変換することなく、ICMPヘッダを翻訳するかもしれないことが考えられます。この場合、ICMPメッセージは同じアドレス、翻訳された1および他の非翻訳の2つのインスタンスが含まれている場合があります。したがって、アプリケーション開発者は、拡張のアドレスがデータグラムのヘッダ内のアドレスと同じ領域であると仮定してはなりません。
It also is conceivable that a NAT device might translate an ICMPv4 message into ICMPv6 or vice versa. If that were to occur, applications might receive ICMPv6 messages that contain IP Address Sub-Objects that specify IPv4 addresses. Likewise, applications might receive ICMPv4 messages that contain IP Address Sub-Objects that specify IPv6 addresses.
また、NATデバイスがICMPv6のか、その逆にICMPv4のメッセージを翻訳可能性があることが考えられます。それが発生した場合、アプリケーションは、IPv4アドレスを指定するIPアドレスのサブオブジェクトが含まれているICMPv6メッセージを受け取ることがあります。同様に、アプリケーションはIPv6アドレスを指定するIPアドレスのサブオブジェクトが含まれているICMPv4のメッセージを受け取ることがあります。
This extension can provide the user of traceroute with additional network information that is not currently available. Implementations SHOULD provide configuration switches that suppress the generation of this extension based upon role (i.e., incoming interface, outgoing interface, sub-IP data). Implementations SHOULD also provide configuration switches that conceal various types of information (e.g., ifIndex, interface name).
この拡張機能は現在使用できません追加のネットワーク情報とトレースルートのユーザに提供することができます。実装は、役割（即ち、着信インターフェース、出力インターフェース、サブIPデータ）に基づいて、この拡張の発生を抑える構成スイッチを提供すべきです。実装はまた、様々なタイプの情報を隠すコンフィギュレーションスイッチを提供すべきである（例えば、ifIndexの、インタフェース名）。
It may be desirable to provide this information to a particular network's operators and not to others. If such policy controls are desirable, then an implementation could determine what sub-objects to include based upon the destination IP address of the ICMP message that will contain the sub-objects. The implementation of policy controls could also be based upon the mechanisms described in [TRACEROUTE-EXT] for those limited cases supported.
特定のネットワークのオペレータにしていない他の人にこの情報を提供することが望ましい場合があります。そのようなポリシー制御が望ましい場合、インプリメンテーションは、サブオブジェクトはサブオブジェクトを含むことになるICMPメッセージの宛先IPアドレスに基づいて含まするかを決定することができます。ポリシー制御の実装にも対応し、それらの限られたケースについて[TRACEROUTE-EXT]で説明されたメカニズムに基づくことができました。
For instance, the IP address may be included for all potential recipients. The ifIndex and interface name could be included as well if the destination IP address is a management address of the network that has administrative control of the router.
例えば、IPアドレスは、すべての潜在的な受信者のために含まれてもよいです。送信先IPアドレスは、ルータの管理制御を持つネットワークの管理アドレスである場合のifIndexおよびインターフェース名も同様に含めることができます。
Another example use case would be where the detailed information in these extensions may be provided to ICMP destinations within the local administrative domain, but only traditional information is provided to 'external' or untrusted ICMP destinations.
これらの拡張機能での詳細な情報は、ローカルの管理ドメイン内のICMP宛先に提供することができるが、唯一の伝統的な情報は、「外部」または信頼されていないICMPの宛先に提供される場合、別の例のユースケースは次のようになります。
The intended field of use for the extensions defined in this document is administrative debugging and troubleshooting. The extensions herein defined supply additional information in ICMP responses. These mechanisms are not intended to be used in non-debugging applications.
この文書で定義された拡張の使用の意図したフィールドは、管理、デバッグとトラブルシューティングです。拡張子は、ここにICMP応答における供給の追加情報を定義しました。これらのメカニズムは、非デバッグ用途で使用するためのものではありません。
This document does not specify an authentication mechanism for the extension that it defines. Application developers should be aware that ICMP messages and their contents are easily spoofed.
この文書では、それが定義拡張のための認証メカニズムを指定していません。アプリケーション開発者は、ICMPメッセージとその内容を簡単に詐称されていることに注意する必要があります。
IANA has reserved 2 for the Interface Information Object from the ICMP Extension Object Classes registry available from <http://www.iana.org>.
IANAは、<http://www.iana.org>から入手ICMP拡張オブジェクトクラスのレジストリからインターフェイス情報オブジェクトのための2を予約しています。
From the Interface Information Object's C-Type, IANA has reserved values as follows:
次のようにインターフェイスの情報オブジェクトのC型からは、IANAが値を予約しました。
o Bit 0-1: Interface Role field
インタフェース役割フィールド：O 0-1ビット
o Bit 2: Unallocated - allocatable with Standards Action
Oビット2：未割り当て - 標準アクションで割り当て可能
o Bit 3: Unallocated - allocatable with Standards Action
Oビット3：未割り当て - 標準アクションで割り当て可能
o Bit 4: ifIndex included
Oビット4：ifIndexを含ま
o Bit 5: IP Address Sub-Object included
Oビット5：IPアドレスのサブオブジェクトが含ま
o Bit 6: Name Sub-Object included
Oビット6：名前のサブオブジェクトが含まれ
o Bit 7: MTU included
Oビット7：MTU含ま
IANA has reserved the following values for Interface Role:
IANAは、インタフェースの役割について、次の値を予約しました：
o Value 0: Incoming IP Interface
O値0：受信IPインターフェース
o Value 1: Sub-IP Component of Incoming IP Interface o Value 2: Outgoing IP Interface
O値1：値2 O着信IPインタフェースのサブIPコンポーネント：発信IPインタフェース
o Value 3: IP Next Hop
O値3：IPネクストホップ
The authors would like to thank Sasha Vainshtein, Enke Chen, and Joe Touch for their comments and suggestions. They would also like to thank Dr. Ali Assefi.
作者は彼らのコメントと提案のためサーシャVainshtein、エンケチェン、およびジョー・タッチに感謝したいと思います。彼らはまた、博士アリAssefiに感謝したいと思います。
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.
[RFC0792]ポステル、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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000.
[RFC2863] McCloghrie、K.およびF. Kastenholzと、 "インターフェイスグループMIB"、RFC 2863、2000年6月。
[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月。
[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006.
[RFC4443]コンタ、A.、デアリング、S.、およびM.グプタ、 "インターネットプロトコルバージョン6（IPv6）の仕様のためのインターネット制御メッセージプロトコル（ICMPv6の）"、RFC 4443、2006年3月。
[RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, "Extended ICMP to Support Multi-Part Messages", RFC 4884, April 2007.
[RFC4884] Bonica、R.、ガン、D.、タッパン、D.、およびC. Pignataro、RFC 4884、2007年4月 "拡張ICMPは、マルチパートメッセージをサポートするために"。
[RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122]ブレーデン、R.、 "インターネットホストのための要件 - 通信層"、STD 3、RFC 1122、1989年10月。
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[RFC1812]ベイカー、F.、RFC 1812、1995年6月 "IPバージョン4つのルータのための要件"。
[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998.
[RFC2277] Alvestrand、H.、 "文字セットと言語のIETF方針"、BCP 18、RFC 2277、1998年1月。
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001.
[RFC3022] Srisuresh、P.とK. Egevang、 "伝統的なIPネットワークアドレス変換（NAT繁体字）"、RFC 3022、2001年1月。
[RFC5508] Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT Behavioral Requirements for ICMP", BCP 148, RFC 5508, April 2009.
[RFC5508] Srisuresh、P.、フォード、B.、シバクマー、S.、およびS.グハ、 "ICMPのためのNAT行動要件"、BCP 148、RFC 5508、2009年4月。
[TRACEROUTE-EXT] Shen, N., Pignataro, C., Asati, R., and E. Chen, "UDP Traceroute Message Extension", Work in Progress, June 2008.
[TRACEROUTE-EXT]シェン、N.、Pignataro、C.、Asati、R.、およびE.チェン、 "UDP tracerouteのメッセージ拡張"、進歩、2008年6月の作業。
Authors' Addresses
著者のアドレス
Alia K. Atlas (editor) BT
アリアアトラスK.（編集者）BT
EMail: alia.atlas@bt.com
メールアドレス：alia.atlas@bt.com
Ronald P. Bonica (editor) Juniper Networks 2251 Corporate Park Drive Herndon, VA 20171 USA
ロナルド・P. Bonica（編集者）ジュニパーネットワークスの2251年コーポレートパークドライブハーンドン、VA 20171 USA
EMail: rbonica@juniper.net
メールアドレス：rbonica@juniper.net
Carlos Pignataro (editor) Cisco Systems 7200-12 Kit Creek Road PO Box 14987 Research Triangle Park, NC 27709 USA
カルロスPignataro（編集者）、シスコシステムズ7200から12キットクリーク道路私書箱14987リサーチトライアングルパーク、NC 27709 USA
EMail: cpignata@cisco.com
メールアドレス：cpignata@cisco.com
Naiming Shen Cisco Systems 225 West Tasman Drive San Jose, CA 95134 USA
Naimingシェンシスコシステムズ225西タスマン・ドライブサンノゼ、CA 95134 USA
EMail: naiming@cisco.com
メールアドレス：naiming@cisco.com
JR. Rivers Consultant
JR。川コンサルタント
EMail: jrrivers@yahoo.com
メールアドレス：jrrivers@yahoo.com