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
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下一跳。
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.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问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信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第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标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在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
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地址之一
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
o ICMPv6数据包的源地址必须是属于该节点的单播地址。地址的选择应根据用于选择任何源地址的规则
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.
由节点发起的其他数据包，给定数据包的目标地址。然而，如果这将导致可从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.
下一跳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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照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
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 数据报将转发到的IP下一跳
Enhanced traceroute applications can identify the above listed entities by:
增强型跟踪路由应用程序可通过以下方式识别上述实体：
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可用作不透明令牌，以区分从同一路由器生成的两条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）丢弃数据包，而Dest Unreachable/Admin Probited拒绝该数据包，那么能够识别传出接口可能会很有用。另一个例子是支持路径MTU发现（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（对象类值）为2的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.5节）。
A single instance of the Interface Information Object can provide information regarding any one of the following interface roles:
Interface Information对象的单个实例可以提供有关以下任一接口角色的信息：
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 数据报将转发到的IP下一跳
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.
为了尽量减少此扩展所需的八位字节数，接口信息对象中可以出现四条不同的信息。
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且标识的接口至少有一个IPv4地址与其关联，或b）引出数据报为IPv6且标识的接口至少有一个IPv6地址与其关联。本备忘录第4.2节描述了IP地址子对象。
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-Type[RFC4884]用于指示接口的角色和包含的信息。这如图1所示。
Bit 0 1 2 3 4 5 6 7
+-------+-------+-------+-------+-------+-------+-------+-------+
| Interface Role| Rsvd1 | Rsvd2 |ifIndex| IPAddr| name | MTU |
+-------+-------+-------+-------+-------+-------+-------+-------+
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-Type的位字段定义：
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地址（位5）：设置时，存在IP地址子对象。清除时，IP地址子对象不存在。本备忘录第4.2节描述了IP地址子对象。
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-Type所示。必须忽略这些可选信息之后的任何数据。
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 ....
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 |
+--------+-----------................-----------------+
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.
长度字段表示接口名称子对象的长度，包括长度和以八位字节为单位的接口名称。最大有效长度为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.
第二个字段包含人类可读的接口名称。如果接口名小于64个八位字节，则接口名应为完整的MIB-II ifName[RFC2863]，如果ifName较长，则接口名应为ifName的前63个八位字节。接口名称可能是接口的其他有人类意义的名称。提供ifName有助于与其他MIB信息进行互相关，并有助于读者熟悉。如果对象不会以4个八位字节边界终止，则接口名称必须用ASCII空字符填充。
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显示了完整的ICMPv4超时消息，包括接口信息对象，该对象前面必须有ICMP扩展结构头和ICMP对象头。[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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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和Name标识的传入接口。
Class-Num = 2
C-Type = 00001010b // Indicates incoming interface
Length = 72 (4 + 4 + 64)
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 |
+--------------+--------------+--------------+--------------+
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)
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 |
+--------------+--------------+--------------+--------------+
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)
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 |
+--------------+--------------+--------------+--------------+
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和Name标识的传出接口。
Class-Num = 2
C-Type = 10001010b // Indicates outgoing interface
Length = 72 (4 + 4 + 64)
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 |
+--------------+--------------+--------------+--------------+
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消息不得包含指定相同角色的两个接口信息对象。
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和名称信息可随时包括在内；每个接口信息对象不得包含这三个信息元素中每个元素的多个实例。
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扩展对象。本文档定义了一个ICMP扩展，该扩展包含IP地址，因此包含领域特定的信息，并因此描述了存在这些扩展时可能出现的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消息可能包含同一地址的两个实例，一个已翻译，另一个未翻译。因此，应用程序开发人员不应假定扩展中的地址与数据报报头中的地址属于同一领域。
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).
此扩展可以向跟踪路由用户提供当前不可用的其他网络信息。实现应提供配置开关，以抑制基于角色（即传入接口、传出接口、子IP数据）的此扩展的生成。实现还应提供隐藏各种类型信息的配置开关（例如，iIndex、接口名称）。
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地址是对路由器进行管理控制的网络的管理地址，则还可以包括iIndex和接口名称。
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已从ICMP扩展对象类注册表中为接口信息对象保留了2个可从<http://www.iana.org>.
From the Interface Information Object's C-Type, IANA has reserved values as follows:
从接口信息对象的C-Type中，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 值1：传入IP接口的子IP组件
o Value 2: Outgoing IP Interface
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.
作者要感谢Sasha Vainstein、Enke Chen和Joe Touch的评论和建议。他们还要感谢阿里·阿塞菲博士。
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.translate error, please retry
[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，“接口组MIB”，RFC 28632000年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.，“互联网主机的要求-通信层”，标准3，RFC 1122，1989年10月。
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[RFC1812]Baker，F.，“IP版本4路由器的要求”，RFC1812，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跟踪路由消息扩展”，正在进行的工作，2008年6月。
Authors' Addresses
作者地址
Alia K. Atlas (editor) BT
Alia K.Atlas（编辑）BT
EMail: alia.atlas@bt.com
EMail: alia.atlas@bt.com
Ronald P. Bonica (editor) Juniper Networks 2251 Corporate Park Drive Herndon, VA 20171 USA
Ronald P.Bonica（编辑）Juniper Networks 2251 Corporate Park Drive Herndon，弗吉尼亚州，20171美国
EMail: rbonica@juniper.net
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（编辑）思科系统7200-12 Kit Creek路邮政信箱14987美国北卡罗来纳州三角研究园27709
EMail: cpignata@cisco.com
EMail: cpignata@cisco.com
Naiming Shen Cisco Systems 225 West Tasman Drive San Jose, CA 95134 USA
美国加利福尼亚州圣何塞市西塔斯曼大道225号思科系统公司沈乃明95134
EMail: naiming@cisco.com
EMail: naiming@cisco.com
JR. Rivers Consultant
小河顾问
EMail: jrrivers@yahoo.com
EMail: jrrivers@yahoo.com