[要約] RFC 5837は、ICMPを拡張してインターフェースと次ホップの識別を行うための仕様です。その目的は、ネットワークトラブルシューティングやパフォーマンスモニタリングのために、ICMPメッセージによるより詳細な情報を提供することです。
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
インターフェイスおよびネクストホップ識別用のICMPを拡張します
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メッセージに追加できるデータ構造を定義します。本明細書で定義されているICMP拡張機能を使用して、次の任意の組み合わせを識別することができます。データグラムが到着したIPインターフェイス、データグラムが到着したIPインターフェイスのサブIPコンポーネント、データグラムが存在するIPインターフェイスのサブIPコンポーネント転送された場合、それがフォワーダブルであった場合、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.
デバイスは、このICMP拡張機能を使用して、次の任意の組み合わせにより、インターフェイスとそのコンポーネントを識別できます：IFINDEX、IPv4アドレス、IPv6アドレス、名前、およびMTU。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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2010 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ライセンステキストを含める必要があります。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版またはそれを英語以外の言語に翻訳するため。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 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:
[RFC1812]によると、ルーターがICMPV4メッセージを生成する場合、そのメッセージのソースアドレスは次のいずれかでなければなりません。
o one of the IP addresses associated with the physical interface over which the ICMPv4 message is transmitted
o ICMPV4メッセージが送信される物理インターフェイスに関連付けられているIPアドレスの1つ
o if that interface has no IP addresses associated with it, the device's router-id or host-id is used instead.
o そのインターフェイスにIPアドレスが関連付けられていない場合、代わりにデバイスのルーター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
o MTU
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.
データグラムが転送される次のHOP IPアドレスは、この同じ拡張子を使用して識別することもできます。この情報は、ダウンストリームマップの作成に使用できます。Next-Hopの情報が常に利用できるとは限りません。存在しないコーナーケースがあり、この情報を提供することが実用的ではない実装があるかもしれません。この仕様では、使用可能なときにネクストホップ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に追加の機能を提供します。拡張されたTracerouteアプリケーションは、古い実装と同様に、データグラムが目的地に向かって訪れたノードを識別します。各ノードで以下を明示的に識別できるという点で、古い実装とは異なります。
o the IP interface upon which a datagram arrived
o データグラムが到着したIPインターフェイス
o the sub-IP component of an IP interface upon which a datagram arrived
o データグラムが到着したIPインターフェイスのサブIPコンポーネント
o the IP interface through which the datagram would have been forwarded had it been forwardable
o データグラムが転送されていたIPインターフェイスは、それが転送可能であれば転送されていたでしょう
o the IP next hop to which the datagram would have been forwarded
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
o MTU
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）がパケットをドロップし、到達不可能/管理者が禁止されている場合、パケットを拒否し、発信インターフェイスを識別できることが役立つ場合があります。別の例は、PATH MTU Discovery（PMTUD）をサポートすることです。これにより、どの発信インターフェイスが特定のMTUサイズをサポートできないかを特定できるためです。たとえば、問題のあるインターフェイスの知識により、そのインターフェイスの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:
このセクションでは、次のメッセージに追加できるクラス-Num（オブジェクトクラス値）を持つICMP拡張オブジェクトである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つ以上のインスタンスが含まれている場合は違法です。これは、インターフェイスの役割が複数回使用されることを意味するためです（セクション4.5を参照）。
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
o データグラムが到着したIPインターフェースo sデータグラムが到着したIPインターフェイスのサブIPコンポーネントから
o the IP interface through which the datagram would have been forwarded had it been forwardable
o データグラムが転送されていたIPインターフェイスは、それが転送可能であれば転送されていたでしょう
o the IP next hop to which the datagram would have been forwarded
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
o マルチリンクPPPバンドルメンバー
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アドレスが関連付けられています。インターフェイスには、少なくとも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.
3. 63オクテット以下の文字列を含むインターフェイス名サブオブジェクトを含めることができます。セクション4.3で指定されているように、その文字列はインターフェイス名であり、MIB-II IFName [RFC2863]である必要がありますが、インターフェイスの他の人間の意味のある名前である可能性があります。
4. A 32-bit unsigned integer reflecting the MTU MAY be included.
4. MTUを反映する32ビットの署名のない整数が含まれている場合があります。
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：このオブジェクトは、データグラムが転送される次のホップを説明しています
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アドレスフィールドで表されるアドレスのタイプを識別します。また、そのフィールドの長さとサブオブジェクト全体の長さも決定します。このフィールドの値は、住所ファミリ番号のIANAレジストリに見られる値のサブセットを表します（<http://www.iana.org>から入手可能）。有効な値は、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.
インターフェイス名Sub-Objectの長さは、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.
長さフィールドは、オクテットの長さとインターフェイス名を含むインターフェイス名サブオブジェクトの長さを表します。最大有効な長さは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の最初の63オクテットの場合、完全なMIB-II IFName [rfc2863]である必要があります。インターフェイス名は、インターフェイスの他の人間の意味のある名前です。IFNameを他のMIB情報と相互相関させ、人間読者の親しみやすさのために提供すると便利です。オブジェクトが4オクテットの境界で終了しない場合、インターフェイス名はASCIIヌル文字でパッドで入れる必要があります。
The interface name MUST be represented in the UTF-8 charset [RFC3629] using the Default Language [RFC2277].
インターフェイス名は、デフォルト言語[RFC2277]を使用して、UTF-8 charset [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 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メッセージと、特定の役割に重複した情報要素を含む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メッセージには同じアドレスの2つのインスタンスが含まれている場合があります。1つは翻訳され、もう1つは翻訳されていません。したがって、アプリケーション開発者は、拡張機能内のアドレスがデータグラムのヘッダーのアドレスと同じ領域であると想定してはなりません。
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デバイスがICMPV4メッセージをICMPv6に翻訳したり、その逆に翻訳する可能性があると考えられます。それが発生した場合、アプリケーションは、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).
この拡張機能は、Tracerouteのユーザーに現在利用できない追加のネットワーク情報を提供できます。実装は、役割に基づいてこの拡張機能の生成を抑制する構成スイッチを提供する必要があります（つまり、着信インターフェイス、発信インターフェイス、サブ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：sub-objectが含まれています
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：着信IPインターフェイスのサブIPコンポーネントo値2：発信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.
著者は、サーシャ・ヴァインシュテイン、エンケ・チェン、ジョー・タッチのコメントと提案に感謝したいと思います。彼らはまた、アリ・アスセフィ博士に感謝したいと思います。
[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月。
[RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000.
[RFC2863] McCloghrie、K。およびF. Kastenholz、「The Interfaces Group 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] Conta、A.、Deering、S。、およびM. Gupta、「インターネットプロトコルバージョン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.、Gan、D.、Tappan、D.、およびC. Pignataro、「マルチパートメッセージをサポートするためにICMPを拡張」、RFC 4884、2007年4月。
[RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122] Braden、R。、「インターネットホストの要件 - 通信レイヤー」、STD 3、RFC 1122、1989年10月。
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[RFC1812] Baker、F。、「IPバージョン4ルーターの要件」、RFC 1812、1995年6月。
[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.、Ford、B.、Sivakumar、S。、およびS. Guha、「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] Shen、N.、Pignataro、C.、Asati、R。、およびE. Chen、「UDP Tracerouteメッセージ拡張」、2008年6月、作業進行中。
Authors' Addresses
著者のアドレス
Alia K. Atlas (editor) BT
Alia K. Atlas（編集者）Bt
EMail: alia.atlas@bt.com
Ronald P. Bonica (editor) Juniper Networks 2251 Corporate Park Drive Herndon, VA 20171 USA
Ronald P. Bonica（編集者）ジュニパーネットワーク2251コーポレートパークドライブハーンドン、バージニア州20171 USA
EMail: rbonica@juniper.net
Carlos Pignataro (editor) Cisco Systems 7200-12 Kit Creek Road PO Box 14987 Research Triangle Park, NC 27709 USA
Carlos Pignataro（編集者）Cisco Systems 7200-12 Kit Creek Road PO Box 14987 Research Triangle Park、NC 27709 USA
EMail: cpignata@cisco.com
Naiming Shen Cisco Systems 225 West Tasman Drive San Jose, CA 95134 USA
ナイミングシェンシスコシステム225ウェストタスマンドライブサンノゼ、カリフォルニア95134 USA
EMail: naiming@cisco.com
JR. Rivers Consultant
Jr。リバーズコンサルタント
EMail: jrrivers@yahoo.com