Network Working Group R. Bonica
Request for Comments: 4884 Juniper Networks
Updates: 792, 4443 D. Gan
Category: Standards Track Consultant
D. Tappan
Consultant
C. Pignataro
Cisco Systems, Inc.
April 2007
Network Working Group R. Bonica
Request for Comments: 4884 Juniper Networks
Updates: 792, 4443 D. Gan
Category: Standards Track Consultant
D. Tappan
Consultant
C. Pignataro
Cisco Systems, Inc.
April 2007
Extended ICMP to Support Multi-Part Messages
支持多部分消息的扩展ICMP
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
Abstract
摘要
This document redefines selected ICMP messages to support multi-part operation. A multi-part ICMP message carries all of the information that ICMP messages carried previously, as well as additional information that applications may require.
本文档重新定义所选ICMP消息以支持多部分操作。多部分ICMP消息包含以前ICMP消息包含的所有信息，以及应用程序可能需要的附加信息。
Multi-part messages are supported by an ICMP extension structure. The extension structure is situated at the end of the ICMP message. It includes an extension header followed by one or more extension objects. Each extension object contains an object header and object payload. All object headers share a common format.
ICMP扩展结构支持多部分消息。扩展结构位于ICMP消息的末尾。它包括一个扩展标头，后跟一个或多个扩展对象。每个扩展对象都包含一个对象头和对象负载。所有对象标题共享一种通用格式。
This document further redefines the above mentioned ICMP messages by specifying a length attribute. All of the currently defined ICMP messages to which an extension structure can be appended include an "original datagram" field. The "original datagram" field contains the initial octets of the datagram that elicited the ICMP error message. Although the original datagram field is of variable length, the ICMP message does not include a field that specifies its length. Therefore, in order to facilitate message parsing, this document allocates eight previously reserved bits to reflect the length of the "original datagram" field.
本文档通过指定长度属性进一步重新定义上述ICMP消息。可附加扩展结构的所有当前定义的ICMP消息都包含“原始数据报”字段。“原始数据报”字段包含引发ICMP错误消息的数据报的初始八位字节。虽然原始数据报字段长度可变，但ICMP消息不包括指定其长度的字段。因此，为了方便消息解析，本文档分配了八个先前保留的位来反映“原始数据报”字段的长度。
The proposed modifications change the requirements for ICMP compliance. The impact of these changes on compliant implementations is discussed, and new requirements for future implementations are presented.
提议的修改改变了ICMP合规性的要求。讨论了这些变更对兼容实现的影响，并提出了未来实现的新要求。
This memo updates RFC 792 and RFC 4443.
本备忘录更新了RFC 792和RFC 4443。
Table of Contents
目录
1. Introduction ....................................................3
2. Conventions Used in This Document ...............................4
3. Summary of Changes to ICMP ......................................4
4. ICMP Extensibility ..............................................4
4.1. ICMPv4 Destination Unreachable .............................7
4.2. ICMPv4 Time Exceeded .......................................8
4.3. ICMPv4 Parameter Problem ...................................8
4.4. ICMPv6 Destination Unreachable .............................9
4.5. ICMPv6 Time Exceeded .......................................9
4.6. ICMP Messages That Can Be Extended ........................10
5. Backwards Compatibility ........................................10
5.1. Classic Application Receives ICMP Message with
Extensions ................................................12
5.2. Non-Compliant Application Receives ICMP Message
with No Extensions ........................................12
5.3. Non-Compliant Application Receives ICMP Message
with Compliant Extensions .................................13
5.4. Compliant Application Receives ICMP Message with
No Extensions .............................................14
5.5. Compliant Application Receives ICMP Message with
Non-Compliant Extensions ..................................14
6. Interaction with Network Address Translation ...................14
7. The ICMP Extension Structure ...................................15
8. ICMP Extension Objects .........................................16
9. Security Considerations ........................................16
10. IANA Considerations ...........................................17
11. Acknowledgments ...............................................17
12. References ....................................................17
12.1. Normative References .....................................17
12.2. Informative References ...................................17
1. Introduction ....................................................3
2. Conventions Used in This Document ...............................4
3. Summary of Changes to ICMP ......................................4
4. ICMP Extensibility ..............................................4
4.1. ICMPv4 Destination Unreachable .............................7
4.2. ICMPv4 Time Exceeded .......................................8
4.3. ICMPv4 Parameter Problem ...................................8
4.4. ICMPv6 Destination Unreachable .............................9
4.5. ICMPv6 Time Exceeded .......................................9
4.6. ICMP Messages That Can Be Extended ........................10
5. Backwards Compatibility ........................................10
5.1. Classic Application Receives ICMP Message with
Extensions ................................................12
5.2. Non-Compliant Application Receives ICMP Message
with No Extensions ........................................12
5.3. Non-Compliant Application Receives ICMP Message
with Compliant Extensions .................................13
5.4. Compliant Application Receives ICMP Message with
No Extensions .............................................14
5.5. Compliant Application Receives ICMP Message with
Non-Compliant Extensions ..................................14
6. Interaction with Network Address Translation ...................14
7. The ICMP Extension Structure ...................................15
8. ICMP Extension Objects .........................................16
9. Security Considerations ........................................16
10. IANA Considerations ...........................................17
11. Acknowledgments ...............................................17
12. References ....................................................17
12.1. Normative References .....................................17
12.2. Informative References ...................................17
This document redefines selected ICMPv4 [RFC0792] and ICMPv6 [RFC4443] messages to include an extension structure and a length attribute. The extension structure supports multi-part ICMP operation. Protocol designers can make an ICMP message carry additional information by encoding that information in the extension structure.
本文档重新定义选定的ICMPv4[RFC0792]和ICMPv6[RFC4443]消息，以包括扩展结构和长度属性。扩展结构支持多部分ICMP操作。协议设计者可以通过在扩展结构中对ICMP消息进行编码，使其携带附加信息。
This document also addresses a fundamental problem in ICMP extensibility. All of the ICMP messages addressed by this memo include an "original datagram" field. The "original datagram" field contains the initial octets of the datagram that elicited the ICMP error message. Although the "original datagram" field is of variable length, the ICMP message does not include a field that specifies its length.
本文档还解决了ICMP可扩展性中的一个基本问题。本备忘录处理的所有ICMP消息都包含一个“原始数据报”字段。“原始数据报”字段包含引发ICMP错误消息的数据报的初始八位字节。虽然“原始数据报”字段长度可变，但ICMP消息不包括指定其长度的字段。
Application software infers the length of the "original datagram" field from the total length of the ICMP message. If an extension structure were appended to the message without adding a length attribute for the "original datagram" field, the message would become unparsable. Specifically, application software would not be able to determine where the "original datagram" field ends and where the extension structure begins. Therefore, this document proposes a length attribute as well as an extension structure that is appended to the ICMP message.
应用软件根据ICMP消息的总长度推断“原始数据报”字段的长度。如果在消息中附加了扩展结构，而没有为“原始数据报”字段添加长度属性，则消息将变得不可解析。“原始数据报”字段不能确定“原始数据报”结构的起始位置。因此，本文提出了一个长度属性以及附加到ICMP消息的扩展结构。
The current memo also addresses backwards compatibility with existing ICMP implementations that either do not implement the extensions defined herein or implement them without adding the required length attributes. In particular, this document addresses backwards compatibility with certain, widely deployed, MPLS-aware ICMPv4 implementations that send the extensions defined herein without adding the required length attribute.
当前的备忘录还解决了与现有ICMP实现的向后兼容性问题，这些ICMP实现要么不实现本文定义的扩展，要么在不添加所需长度属性的情况下实现它们。特别是，本文档解决了与某些广泛部署、支持MPLS的ICMPv4实现的向后兼容性问题，这些实现在不添加所需长度属性的情况下发送本文定义的扩展。
The current memo does not define any ICMP extension objects. It defines only the extension header and a common header that all extension objects share. [UNNUMBERED], [ROUTING-INST], and [MPLS-ICMP] provide sample applications of the ICMP Extension Object.
当前备忘录未定义任何ICMP扩展对象。它仅定义所有扩展对象共享的扩展头和公共头。[Unnumber]、[ROUTING-INST]和[MPLS-ICMP]提供了ICMP扩展对象的示例应用程序。
The above mentioned memos share a common characteristic. They all append information to the ICMP Time Expired message for consumption by TRACEROUTE. In this case, as in many others, appending information to the existing ICMP Time Expired Message is preferable to defining a new message and emitting two messages whenever a packet is dropped due to TTL expiration.
上述备忘录有一个共同特点。它们都将信息附加到ICMP超时消息中，以供跟踪路由使用。在这种情况下，与许多其他情况一样，将信息附加到现有ICMP超时消息比定义一个新消息并在由于TTL过期而丢弃数据包时发出两条消息更可取。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
The following is a summary of changes to ICMP that are introduced by this memo:
以下是本备忘录介绍的ICMP变更摘要：
An ICMP Extension Structure MAY be appended to ICMPv4 Destination Unreachable, Time Exceeded, and Parameter Problem messages.
ICMP扩展结构可以附加到ICMPv4目标不可访问、超出时间和参数问题消息。
An ICMP Extension Structure MAY be appended to ICMPv6 Destination Unreachable, and Time Exceeded messages.
ICMP扩展结构可以附加到ICMPv6目的地不可访问和超出时间的消息。
The above mentioned messages include an "original datagram" field, and the message formats are updated to specify a length attribute for the "original datagram" field.
上述消息包括“原始数据报”字段，并且消息格式被更新以指定“原始数据报”字段的长度属性。
When the ICMP Extension Structure is appended to an ICMP message and that ICMP message contains an "original datagram" field, the "original datagram" field MUST contain at least 128 octets.
当ICMP扩展结构附加到ICMP消息且该ICMP消息包含“原始数据报”字段时，“原始数据报”字段必须至少包含128个八位字节。
When the ICMP Extension Structure is appended to an ICMPv4 message and that ICMPv4 message contains an "original datagram" field, the "original datagram" field MUST be zero padded to the nearest 32-bit boundary.
当ICMP扩展结构附加到ICMPv4消息且该ICMPv4消息包含“原始数据报”字段时，“原始数据报”字段必须零填充到最近的32位边界。
When the ICMP Extension Structure is appended to an ICMPv6 message and that ICMPv6 message contains an "original datagram" field, the "original datagram" field MUST be zero padded to the nearest 64-bit boundary.
当ICMP扩展结构附加到ICMPv6消息且该ICMPv6消息包含“原始数据报”字段时，“原始数据报”字段必须零填充到最近的64位边界。
ICMP messages defined in the future SHOULD indicate whether or not they support the extension mechanism defined in this specification. It is recommended that all new messages support extensions.
将来定义的ICMP消息应指明它们是否支持本规范中定义的扩展机制。建议所有新邮件都支持扩展。
RFC 792 defines the following ICMPv4 message types:
RFC 792定义了以下ICMPv4消息类型：
- Destination Unreachable
- 无法到达目的地
- Time Exceeded
- 超过时间
- Parameter Problem
- 参数问题
- Source Quench
- 源淬火
- Redirect
- 重新使用
- Echo Request/Reply
- 回应请求/答复
- Timestamp/Timestamp Reply
- 时间戳/时间戳回复
- Information Request/Information Reply
- 信息请求/信息回复
[RFC1191] reserves bits for the "Next-Hop MTU" field in the Destination Unreachable message.
[RFC1191]为目标不可访问消息中的“下一跳MTU”字段保留位。
RFC 4443 defines the following ICMPv6 message types:
RFC 4443定义了以下ICMPv6消息类型：
- Destination Unreachable
- 无法到达目的地
- Packet Too Big
- 包太大了
- Time Exceeded
- 超过时间
- Parameter Problem
- 参数问题
- Echo Request/Reply
- 回应请求/答复
Many ICMP messages are extensible as currently defined. Protocol designers can extend ICMP messages by simply appending fields or data structures to them.
许多ICMP消息可以按照当前定义进行扩展。协议设计者可以通过简单地向ICMP消息附加字段或数据结构来扩展ICMP消息。
However, the following ICMP messages are not extensible as currently defined:
但是，以下ICMP消息不可按当前定义扩展：
- ICMPv4 Destination Unreachable (type = 3)
- 无法访问ICMPv4目标（类型=3）
- ICMPv4 Time Exceeded (type = 11)
- 超过ICMPv4时间（类型=11）
- ICMPv4 Parameter Problem (type = 12)
- ICMPv4参数问题（类型=12）
- ICMPv6 Destination Unreachable (type = 1)
- 无法访问ICMPv6目标（类型=1）
- ICMPv6 Packet Too Big (type = 2)
- ICMPv6数据包太大（类型=2）
- ICMPv6 Time Exceeded (type = 3)
- 超过ICMPv6时间（类型=3）
- ICMPv6 Parameter Problem (type = 4)
- ICMPv6参数问题（类型=4）
These messages contain an "original datagram" field which represents the leading octets of the datagram to which the ICMP message is a response. RFC 792 defines the "original datagram" field for ICMPv4 messages. In RFC 792, the "original datagram" field includes the IP header plus the next eight octets of the original datagram. [RFC1812] extends the "original datagram" field to contain as many octets as possible without causing the ICMP message to exceed the minimum IPv4 reassembly buffer size (i.e., 576 octets). RFC 4443 defines the "original datagram" field for ICMPv6 messages. In RFC 4443, the "original datagram" field always contained as many octets as possible without causing the ICMP message to exceed the minimum IPv6 MTU (i.e., 1280 octets).
这些消息包含一个“原始数据报”字段，该字段表示ICMP消息响应的数据报的前导八位字节。RFC 792为ICMPv4消息定义“原始数据报”字段。在RFC 792中，“原始数据报”字段包括IP报头加上原始数据报的下八个八位字节。[RFC1812]扩展“原始数据报”字段以包含尽可能多的八位字节，而不会导致ICMP消息超过最小IPv4重组缓冲区大小（即576个八位字节）。RFC 4443为ICMPv6消息定义“原始数据报”字段。在RFC 4443中，“原始数据报”字段始终包含尽可能多的八位字节，而不会导致ICMP消息超过最小IPv6 MTU（即1280个八位字节）。
Unfortunately, the "original datagram" field lacks a length attribute. Application software infers the length of this field from the total length of the ICMP message. If an extension structure were appended to the message without adding a length attribute for the "original datagram" field, the message would become unparsable. Specifically, application software would not be able to determine where the "original datagram" field ends and where the extension structure begins.
不幸的是，“原始数据报”字段缺少长度属性。应用软件根据ICMP消息的总长度推断此字段的长度。如果在消息中附加了扩展结构，而没有为“原始数据报”字段添加长度属性，则消息将变得不可解析。具体来说，应用软件将无法确定“原始数据报”字段的结束位置和扩展结构的开始位置。
In order to solve this problem, this memo introduces an 8-bit length attribute to the following ICMPv4 messages.
为了解决此问题，此备忘录为以下ICMPv4消息引入了8位长度属性。
- Destination Unreachable (type = 3)
- 无法到达目标（类型=3）
- Time Exceeded (type = 11)
- 超出时间（类型=11）
- Parameter Problem (type = 12)
- 参数问题（类型=12）
It also introduces an 8-bit length attribute to the following ICMPv6 messages.
它还为以下ICMPv6消息引入了8位长度属性。
- Destination Unreachable (type = 1)
- 无法到达目标（类型=1）
- Time Exceeded (type = 3)
- 超出时间（类型=3）
The length attribute MUST be specified when the ICMP Extension Structure is appended to the above mentioned ICMP messages.
当ICMP扩展结构附加到上述ICMP消息时，必须指定length属性。
The length attribute represents the length of the "original datagram" field. Space for the length attribute is claimed from reserved octets, whose value was previously required to be zero.
length属性表示“原始数据报”字段的长度。长度属性的空间是从保留的八位字节中声明的，其值以前要求为零。
For ICMPv4 messages, the length attribute represents 32-bit words. When the length attribute is specified, the "original datagram" field MUST be zero padded to the nearest 32-bit boundary. Because the
对于ICMPv4消息，length属性表示32位字。指定长度属性时，“原始数据报”字段必须零填充到最近的32位边界。因为
sixth octet of each of the impacted ICMPv4 messages was reserved for future use, this octet was selected as the location of the length attribute in ICMPv4.
每个受影响的ICMPv4消息的第六个八位字节已保留供将来使用，此八位字节已被选为ICMPv4中长度属性的位置。
For ICMPv6 messages, the length attribute represents 64-bit words. When the length attribute is specified, the "original datagram" field MUST be zero padded to the nearest 64-bit boundary. Because the fifth octet of each of the impacted ICMPv6 messages was reserved for future use, this octet was selected as the location of the length attribute in ICMPv6.
对于ICMPv6消息，length属性表示64位字。指定长度属性时，“原始数据报”字段必须零填充到最近的64位边界。由于每个受影响的ICMPv6消息的第五个八位字节已保留供将来使用，因此选择此八位字节作为ICMPv6中长度属性的位置。
In order to achieve backwards compatibility, when the ICMP Extension Structure is appended to an ICMP message and that ICMP message contains an "original datagram" field, the "original datagram" field MUST contain at least 128 octets. If the original datagram did not contain 128 octets, the "original datagram" field MUST be zero padded to 128 octets. (See Section 5.1 for rationale.)
为了实现向后兼容性，当ICMP扩展结构附加到ICMP消息且该ICMP消息包含“原始数据报”字段时，“原始数据报”字段必须至少包含128个八位字节。如果原始数据报不包含128个八位字节，“原始数据报”字段必须零填充到128个八位字节。（基本原理见第5.1节。）
The following sub-sections depict length attribute as it has been introduced to selected ICMP messages.
以下小节描述了长度属性，因为它已被引入到选定的ICMP消息中。
Figure 1 depicts the ICMPv4 Destination Unreachable Message.
图1描述了ICMPv4目标不可访问消息。
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 | Next-Hop MTU* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Internet Header + leading octets of original datagram |
| |
| // |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | Next-Hop MTU* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Internet Header + leading octets of original datagram |
| |
| // |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: ICMPv4 Destination Unreachable
图1:ICMPv4目标不可到达
The syntax and semantics of all fields are unchanged from RFC 792. However, a length attribute is added to the second word. The length attribute represents length of the padded "original datagram" field, measured in 32-bit words.
所有字段的语法和语义与RFC 792相同。但是，将在第二个单词中添加长度属性。length属性表示填充的“原始数据报”字段的长度，以32位字度量。
* The Next-Hop MTU field is not required in all cases. It is depicted only to demonstrate that those bits are not available for assignment in this memo.
* 并非所有情况下都需要下一跳MTU字段。描述这些位只是为了说明这些位在本备忘录中不可分配。
Figure 2 depicts the ICMPv4 Time Exceeded Message.
图2描述了ICMPv4超时消息。
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 |
| |
| // |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
| |
| // |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: ICMPv4 Time Exceeded
图2：超出ICMPv4时间
The syntax and semantics of all fields are unchanged from RFC 792, except for a length attribute which is added to the second word. The length attribute represents length of the padded "original datagram" field, measured in 32-bit words.
所有字段的语法和语义与RFC 792相同，但添加到第二个单词的长度属性除外。length属性表示填充的“原始数据报”字段的长度，以32位字度量。
Figure 3 depicts the ICMPv4 Parameter Problem Message.
图3描述了ICMPv4参数问题消息。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pointer | Length | unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Internet Header + leading octets of original datagram |
| |
| // |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pointer | Length | unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Internet Header + leading octets of original datagram |
| |
| // |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: ICMPv4 Parameter Problem
图3:ICMPv4参数问题
The syntax and semantics of all fields are unchanged from RFC 792, except for a length attribute which is added to the second word. The length attribute represents length of the padded "original datagram" field, measured in 32-bit words.
所有字段的语法和语义与RFC 792相同，但添加到第二个单词的长度属性除外。length属性表示填充的“原始数据报”字段的长度，以32位字度量。
Figure 4 depicts the ICMPv6 Destination Unreachable Message.
图4描述了ICMPv6目标不可访问消息。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| As much of invoking packet |
+ as possible without the ICMPv6 packet +
| exceeding the minimum IPv6 MTU [RFC4443] |
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| As much of invoking packet |
+ as possible without the ICMPv6 packet +
| exceeding the minimum IPv6 MTU [RFC4443] |
Figure 4: ICMPv6 Destination Unreachable
图4:ICMPv6目标不可到达
The syntax and semantics of all fields are unchanged from RFC 4443. However, a length attribute is added to the second word. The length attribute represents length of the padded "original datagram" field, measured in 64-bit words.
所有字段的语法和语义与RFC 4443相同。但是，将在第二个单词中添加长度属性。length属性表示填充的“原始数据报”字段的长度，以64位字度量。
Figure 5 depicts the ICMPv6 Time Exceeded Message.
图5描述了ICMPv6超时消息。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| As much of invoking packet |
+ as possible without the ICMPv6 packet +
| exceeding the minimum IPv6 MTU [RFC4443] |
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| As much of invoking packet |
+ as possible without the ICMPv6 packet +
| exceeding the minimum IPv6 MTU [RFC4443] |
Figure 5: ICMPv6 Time Exceeded
图5：超出ICMPv6时间
The syntax and semantics of all fields are unchanged from RFC 4443, except for a length attribute which is added to the second word. The length attribute represents length of the padded "original datagram" field, measured in 64-bit words.
所有字段的语法和语义与RFC 4443相同，但添加到第二个单词的长度属性除外。length属性表示填充的“原始数据报”字段的长度，以64位字度量。
The ICMP Extension Structure MAY be appended to messages of the following types:
ICMP扩展结构可以附加到以下类型的消息中：
- ICMPv4 Destination Unreachable
- ICMPv4目标不可到达
- ICMPv4 Time Exceeded
- 超过ICMPv4时间
- ICMPv4 Parameter Problem
- ICMPv4参数问题
- ICMPv6 Destination Unreachable
- ICMPv6目标不可到达
- ICMPv6 Time Exceeded
- 已超过ICMPv6时间
The ICMP Extension Structure MUST NOT be appended to any of the other ICMP messages mentioned in Section 4. Extensions were not defined for the ICMPv6 "Packet Too Big" and "Parameter Problem" messages because these messages lack space for a length attribute.
ICMP扩展结构不得附加到第4节中提到的任何其他ICMP消息中。没有为ICMPv6“数据包太大”和“参数问题”消息定义扩展，因为这些消息缺少用于长度属性的空间。
ICMP messages can be categorized as follows:
ICMP消息可分为以下几类：
- Messages that do not include any ICMP extensions
- 不包括任何ICMP扩展的消息
- Messages that include non-compliant ICMP extensions
- 包含不符合ICMP扩展的消息
- Messages that includes compliant ICMP extensions
- 包含兼容ICMP扩展的消息
Any ICMP implementation can send a message that does not include extensions. ICMP implementations produced prior to 1999 are not known to send ICMP extensions.
任何ICMP实现都可以发送不包含扩展名的消息。1999年之前生产的ICMP实现不知道是否发送ICMP扩展。
Some ICMP implementations, produced between 1999 and the time of this publication, may send a non-compliant version of ICMP extensions described in this memo. Specifically, these implementations may append the ICMP Extension Structure to the Time Exceeded and Destination Unreachable messages. When they do this, they send exactly 128 octets representing the original datagram, zero padding if required. They also calculate checksums as described in this document. However, they do not specify a length attribute to be associated with the "original datagram" field.
1999年至本出版物发布期间产生的某些ICMP实施可能会发送本备忘录中所述的ICMP扩展的不符合版本。具体地说，这些实现可能会将ICMP扩展结构附加到超时和目标不可访问的消息中。当他们这样做时，他们只发送代表原始数据报的128个八位字节，如果需要，则零填充。它们还计算本文档中所述的校验和。但是，它们没有指定要与“原始数据报”字段关联的长度属性。
It is assumed that ICMP implementations produced in the future will send ICMP extensions that are compliant with this specification.
假定将来产生的ICMP实现将发送符合此规范的ICMP扩展。
Likewise, applications that consume ICMP messages can be categorized as follows:
同样，使用ICMP消息的应用程序可分为以下几类：
- Classic applications
- 经典应用
- Non-compliant applications
- 不符合要求的应用程序
- Compliant applications
- 兼容应用程序
Classic applications do not parse extensions defined in this memo. They are insensitive to the length attribute that is associated with the "original datagram" field.
经典应用程序不解析此备忘录中定义的扩展。它们对与“原始数据报”字段关联的长度属性不敏感。
Non-compliant implementations parse the extensions defined in this memo, but only in conjunction with the Time Expired and Destination Unreachable messages. They require the "original datagram" field to contain exactly 128 octets and are insensitive to the length attribute that is associated with the "original datagram" field. Non-compliant applications were produced between 1999 and the time of publication of this memo.
非兼容实现解析此备忘录中定义的扩展，但仅与过期消息和目标不可访问消息结合使用。它们要求“原始数据报”字段正好包含128个八位字节，并且对与“原始数据报”字段关联的长度属性不敏感。1999年至本备忘录发布之日期间产生了不合规申请。
Compliant applications comply fully with the specifications of this document.
符合要求的应用程序完全符合本文档的规范。
In order to demonstrate backwards compatibility, Table 1 describes how members of each application category would parse each category of ICMP message.
为了演示向后兼容性，表1描述了每个应用程序类别的成员将如何解析ICMP消息的每个类别。
+----------------+----------------+----------------+----------------+
| | No Extensions | Non-compliant | Compliant |
| | | Extensions | Extensions |
+----------------+----------------+----------------+----------------+
| Classic | - | Section 5.1 | Section 5.1 |
| Application | | | |
| | | | |
| Non-compliant | Section 5.2 | - | Section 5.3 |
| Application | | | |
| | | | |
| Compliant | Section 5.4 | Section 5.5 | - |
| Application | | | |
+----------------+----------------+----------------+----------------+
+----------------+----------------+----------------+----------------+
| | No Extensions | Non-compliant | Compliant |
| | | Extensions | Extensions |
+----------------+----------------+----------------+----------------+
| Classic | - | Section 5.1 | Section 5.1 |
| Application | | | |
| | | | |
| Non-compliant | Section 5.2 | - | Section 5.3 |
| Application | | | |
| | | | |
| Compliant | Section 5.4 | Section 5.5 | - |
| Application | | | |
+----------------+----------------+----------------+----------------+
Table 1
表1
In the table above, cells that contain a dash represent the nominal case and require no explanation. In the following sections, we assume that the ICMP message type is "Time Exceeded".
在上表中，包含破折号的单元格表示标称情况，无需解释。在以下部分中，我们假设ICMP消息类型为“超时”。
When a classic application receives an ICMP message that includes extensions, it will incorrectly interpret those extensions as being part of the "original datagram" field. Fortunately, the extensions are guaranteed to begin at least 128 octets beyond the beginning of the "original datagram" field. So, only those ICMP applications that process the 129th octet of the "original datagram" field will be adversely effected. To date, only two applications falling into this category have been identified, and the degree to which they are effected is minimal.
当经典应用程序收到包含扩展的ICMP消息时，它将错误地将这些扩展解释为“原始数据报”字段的一部分。幸运的是，扩展保证在“原始数据报”字段的开头至少有128个八位字节。因此，只有那些处理“原始数据报”字段第129个八位字节的ICMP应用程序才会受到不利影响。到目前为止，只有两份属于这一类的申请被确定，其影响程度很小。
Some TCP stacks, when they receive an ICMP message, verify the checksum in the original datagram field [ATTACKS]. If the checksum is incorrect, the TCP stack discards the ICMP message for security reasons. If the trailing octets of the original datagram field are overwritten by ICMP extensions, the TCP stack will discard an ICMP message that it would not otherwise have discarded. The impact of this issue is considered to be minimal because many ICMP messages are discarded for other reasons (e.g., ICMP filtering, network congestion, checksum was incorrect because original datagram field was truncated.)
一些TCP堆栈在收到ICMP消息时，会验证原始数据报字段[攻击]中的校验和。如果校验和不正确，出于安全原因，TCP堆栈将丢弃ICMP消息。如果原始数据报字段的尾随八位字节被ICMP扩展覆盖，TCP堆栈将丢弃一条本来不会丢弃的ICMP消息。此问题的影响被认为是最小的，因为许多ICMP消息由于其他原因被丢弃（例如，ICMP过滤、网络拥塞、校验和不正确，因为原始数据报字段被截断）
Another theoretically possible, but highly improbably scenario occurs when ICMP extensions overwrite the portion of the original datagram field that represents the TCP header, causing the TCP stack to operate upon the wrong TCP connection. This scenario is highly unlikely because it occurs only when the TCP header appears at or beyond the 128th octet of the original datagram field and then only when the extensions approximate a valid TCP header.
另一种理论上可能但极不可能发生的情况是，ICMP扩展覆盖原始数据报字段中表示TCP头的部分，导致TCP堆栈在错误的TCP连接上运行。这种情况不太可能发生，因为只有当TCP报头出现在原始数据报字段的第128个八位字节或以上时，并且只有当扩展接近有效的TCP报头时，才会发生这种情况。
When a non-compliant ICMPv4 application receives a message that contains no extensions, the application examines the total length of the ICMPv4 message. If the total ICMPv4 message length is less than the length of its IP header plus 144 octets, the application correctly determines that the message does not contain any extensions.
当不兼容的ICMPv4应用程序收到不包含扩展名的消息时，应用程序将检查ICMPv4消息的总长度。如果ICMPv4消息的总长度小于其IP头的长度加上144个八位字节，则应用程序将正确确定消息不包含任何扩展名。
The 144-octet sum is derived from 8 octets for the first two words of the ICMPv4 Time Exceeded message, 128 octets for the "original datagram" field, 4 octets for the ICMP Extension Header, and 4 octets for a single ICMP Object header. All of these octets would be required if extensions were present.
144个八位字节的总和来自ICMPv4超时消息前两个字的8个八位字节、“原始数据报”字段的128个八位字节、ICMP扩展标头的4个八位字节和单个ICMP对象标头的4个八位字节。如果存在扩展，则需要所有这些八位字节。
If the ICMPv4 payload contains 144 octets or more, the application must examine the 137th octet to determine whether it represents a valid ICMPv4 Extension Header. In order to represent a valid Extension Header, it must contain a valid version number and checksum. If it does not contain a valid version number and checksum, the application correctly determines that the message does not contain any extensions.
如果ICMPv4有效负载包含144个八位字节或更多，则应用程序必须检查第137个八位字节，以确定它是否表示有效的ICMPv4扩展头。为了表示有效的扩展标头，它必须包含有效的版本号和校验和。如果消息不包含有效的版本号和校验和，应用程序将正确确定消息不包含任何扩展名。
Non-compliant applications assume that the ICMPv4 Extension Structure begins on the 137th octet of the Time Exceeded message, after a 128-octet field representing the padded "original datagram" message.
不兼容的应用程序假定ICMPv4扩展结构从超时消息的第137个八位字节开始，在代表填充的“原始数据报”消息的128个八位字节字段之后。
It is possible that a non-compliant application will parse an ICMPv4 message incorrectly under the following conditions:
在以下情况下，不符合要求的应用程序可能会错误地解析ICMPv4消息：
- the message does not contain extensions
- 消息不包含扩展名
- the original datagram field contains 144 octets or more
- 原始数据报字段包含144个八位字节或更多
- selected octets of the original datagram field represent the correct values for an extension header version number and checksum
- 原始数据报字段的选定八位字节表示扩展标头版本号和校验和的正确值
Although this is possible, it is very unlikely.
虽然这是可能的，但可能性不大。
A similar analysis can be performed for ICMPv6. However, the numeric constants would change as appropriate.
可以对ICMPv6执行类似的分析。但是，数值常量将根据需要进行更改。
5.3. Non-Compliant Application Receives ICMP Message with Compliant Extensions
5.3. 不兼容的应用程序接收具有兼容扩展名的ICMP消息
When a non-compliant application receives a message that contains compliant ICMP extensions, it will parse those extensions correctly only if the "original datagram" field contains exactly 128 octets. This is because non-compliant applications are insensitive to the length attribute that is associated with the "original datagram" field. (They assume its value to be 128.)
当不兼容的应用程序收到包含兼容ICMP扩展的消息时，只有在“原始数据报”字段正好包含128个八位字节时，它才会正确解析这些扩展。这是因为不兼容的应用程序对与“原始数据报”字段关联的长度属性不敏感。（它们假定其值为128。）
Provided that the entire ICMP message does not exceed the minimum reassembly buffer size (576 octets for ICMPv4 or 1280 octets for ICMPv6), there is no upper limit upon the length of the "original datagram" field. However, each implementation will decide how many octets to include. Those wishing to be backward compatible with non-compliant TRACEROUTE implementations will include exactly 128 octets. Those not requiring compatibility with non-compliant TRACEROUTE applications may include more octets.
如果整个ICMP消息不超过最小重组缓冲区大小（ICMPv4为576个八位字节，ICMPv6为1280个八位字节），则“原始数据报”字段的长度没有上限。但是，每个实现将决定包含多少个八位字节。那些希望与不兼容的TRACEROUTE实现向后兼容的将包括128个八位字节。那些不需要与不兼容的TRACEROUTE应用程序兼容的应用程序可能包括更多的八位字节。
When a compliant application receives an ICMP message, it examines the length attribute that is associated with the "original datagram" field. If the length attribute is zero, the compliant application MUST determine that the message contains no extensions.
当兼容应用程序收到ICMP消息时，它将检查与“原始数据报”字段关联的长度属性。如果length属性为零，则兼容应用程序必须确定消息不包含扩展名。
5.5. Compliant Application Receives ICMP Message with Non-Compliant Extensions
5.5. 兼容应用程序接收带有不兼容扩展的ICMP消息
When a compliant application receives an ICMP message, it examines the length attribute that is associated with the "original datagram" field. If the length attribute is zero, the compliant application MUST determine that the message contains no extensions. In this case, that determination is technically correct, but not backwards compatible with the non-compliant implementation that originated the ICMP message.
当兼容应用程序收到ICMP消息时，它将检查与“原始数据报”字段关联的长度属性。如果length属性为零，则兼容应用程序必须确定消息不包含扩展名。在这种情况下，该确定在技术上是正确的，但与产生ICMP消息的不兼容实现不向后兼容。
So, to ease transition yet encourage compliant implementation, compliant TRACEROUTE implementations MUST include a non-default operation mode to also interpret non-compliant responses. Specifically, when a TRACEROUTE application operating in non-compliant mode receives a sufficiently long ICMP message that does not specify a length attribute, it will parse for a valid extension header at a fixed location, assuming a 128-octet "original datagram" field. If the application detects a valid version and checksum, it will treat the octets that follow as an extension structure.
所以，为了简化转换，同时鼓励兼容的实现，兼容的TRACEROUTE实现必须包括一个非默认的操作模式，以解释不兼容的响应。具体地说，当在非兼容模式下运行的跟踪路由应用程序接收到足够长且未指定长度属性的ICMP消息时，它将在固定位置解析有效的扩展标头，假设有128个八位字节的“原始数据报”字段。如果应用程序检测到有效版本和校验和，它会将后面的八位字节视为扩展结构。
The ICMP extensions defined in this memo do not interfere with Network Address Translation. [RFC3022] permits traditional NAT devices to modify selected fields within ICMP messages. These fields include the "original datagram" field mentioned above. However, if a NAT device modifies the "original datagram" field, it should modify only the leading octets of that field, which represent the outermost IP header. Because the outermost IP header is guaranteed to be contained by the first 128 octets of the "original datagram" field, ICMP extensions and NAT will not interfere with one another.
本备忘录中定义的ICMP扩展不会干扰网络地址转换。[RFC3022]允许传统NAT设备修改ICMP消息中的选定字段。这些字段包括上述“原始数据报”字段。但是，如果NAT设备修改了“原始数据报”字段，它应该只修改该字段的前导八位字节，它表示最外层的IP报头。因为最外层的IP报头保证包含在“原始数据报”字段的前128个八位字节中，所以ICMP扩展和NAT不会相互干扰。
It is conceivable that a NAT implementation might overstep the restrictions of RFC 3022 and overwrite the length attribute specified by this memo. If a NAT implementation were to overwrite the length attribute with zeros, the resulting packet will be indistinguishable from a packet that was generated by a non-compliant ICMP implementation. See Section 5.5 for packet details and a discussion of backwards compatibility.
可以想象，NAT实现可能会超越RFC 3022的限制，并覆盖此备忘录指定的长度属性。如果NAT实现要用零覆盖长度属性，则生成的数据包将无法与不符合ICMP实现生成的数据包区分开来。有关数据包的详细信息和向后兼容性的讨论，请参见第5.5节。
This memo proposes an optional ICMP Extension Structure that can be appended to the ICMP messages referenced in Section 4.6 of this document.
本备忘录提出了一个可选的ICMP扩展结构，可附加到本文件第4.6节中引用的ICMP消息中。
The Extension Structure contains exactly one Extension Header followed by one or more objects. Having received an ICMP message with extensions, application software MAY process selected objects while ignoring others. The presence of an unrecognized object does not imply that an ICMP message is malformed.
扩展结构仅包含一个扩展标头，后跟一个或多个对象。收到带有扩展名的ICMP消息后，应用程序软件可能会处理选定的对象，而忽略其他对象。存在无法识别的对象并不意味着ICMP消息格式不正确。
As stated above, the total length of the ICMP message, including extensions, MUST NOT exceed the minimum reassembly buffer size. Figure 6 depicts the ICMP Extension Header.
如上所述，ICMP消息的总长度（包括扩展名）不得超过最小重组缓冲区大小。图6描述了ICMP扩展头。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| (Reserved) | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| (Reserved) | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: ICMP Extension Header
图6:ICMP扩展头
The fields of the ICMP Extension Header are as follows:
ICMP扩展标头的字段如下所示：
Version: 4 bits
版本：4位
ICMP extension version number. This is version 2.
ICMP扩展版本号。这是第2版。
Reserved: 12 bits
保留：12位
Must be set to 0.
必须设置为0。
Checksum: 16 bits
校验和：16位
The one's complement of the one's complement sum of the data structure, with the checksum field replaced by zero for the purpose of computing the checksum. An all-zero value means that no checksum was transmitted. See Section 5.2 for a description of how this field is used.
数据结构的补码和的补码中的补码，校验和字段替换为零以计算校验和。全零值表示未传输校验和。有关如何使用该字段的说明，请参见第5.2节。
Each extension object contains one or more 32-bit words, representing an object header and payload. All object headers share a common format. Figure 7 depicts the object header and payload.
每个扩展对象包含一个或多个32位字，表示对象头和负载。所有对象标题共享一种通用格式。图7描述了对象头和负载。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num | C-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| // (Object payload) // |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num | C-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| // (Object payload) // |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Object Header and Payload
图7：对象头和有效负载
An object header has the following fields:
对象标头具有以下字段：
Length: 16 bits
长度：16位
Length of the object, measured in octets, including the object header and object payload.
对象的长度，以八位字节为单位，包括对象头和对象有效负载。
Class-Num: 8 bits
类别编号：8位
Identifies object class.
标识对象类。
C-Type: 8 bits
C型：8位
Identifies object sub-type.
标识对象子类型。
Upon receipt of an ICMP message, application software must check it for syntactic correctness. The extension checksum must be verified. Improperly specified length attributes and other syntax problems may result in buffer overruns.
收到ICMP消息后，应用软件必须检查其语法正确性。必须验证扩展校验和。不正确指定长度属性和其他语法问题可能会导致缓冲区溢出。
This memo does not define the conditions under which a router sends an ICMP message. Therefore, it does not expose routers to any new denial-of-service attacks. Routers may need to limit the rate at which ICMP messages are sent.
此备忘录未定义路由器发送ICMP消息的条件。因此，它不会使路由器受到任何新的拒绝服务攻击。路由器可能需要限制ICMP消息的发送速率。
The ICMP Extension Object header contains two 8-bit fields: The Class-Num identifies the object class, and the C-Type identifies the class sub-type. Sub-type values are defined relative to a specific object class value, and are defined per class.
ICMP扩展对象头包含两个8位字段：Class Num标识对象类，C-Type标识类子类型。子类型值是相对于特定对象类值定义的，并且是按类定义的。
IANA has established a registry of ICMP extension objects classes and class sub-types. There are no values assigned within this document to maintain. Object classes 0xF7 - 0xFF are reserved for private use. Object class values are assignable on a first-come-first-serve basis. The policy for assigning sub-type values should be defined in the document defining new class values.
IANA已经建立了ICMP扩展对象类和类子类型的注册表。此文档中没有指定要维护的值。对象类0xF7-0xFF保留供私人使用。对象类值可根据先到先得的原则进行分配。分配子类型值的策略应在定义新类值的文档中定义。
Thanks to Pekka Nikander, Mark Doll, Fernando Gont, Joe Touch, Christian Voiqt, and Sharon Chrisholm for their comments regarding this document.
感谢Pekka Nikander、Mark Doll、Fernando Gont、Joe Touch、Christian Voiqt和Sharon Chrisholm对本文件的评论。
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.
[RFC0792]Postel，J.，“互联网控制消息协议”，STD 5，RFC 792，1981年9月。
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[RFC1191]Mogul，J.和S.Deering，“MTU发现路径”，RFC1191，1990年11月。
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[RFC1812]Baker，F.，“IP版本4路由器的要求”，RFC1812，1995年6月。
[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月。
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006.
[RFC4443]Conta，A.，Deering，S.，和M.Gupta，Ed.，“互联网协议版本6（IPv6）规范的互联网控制消息协议（ICMPv6）”，RFC 4443，2006年3月。
[UNNUMBERED] Atlas, A., Bonica, R., Rivers, JR., Shen, N., and E. Chen, "ICMP Extensions for Unnumbered Interfaces", Work in Progress, March 2007.
[未编号]Atlas，A.，Bonica，R.，Rivers，JR.，Shen，N.，和E.Chen，“未编号接口的ICMP扩展”，正在进行的工作，2007年3月。
[MPLS-ICMP] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, "ICMP Extensions for MultiProtocol Label Switching", Work in Progress, January 2007.
[MPLS-ICMP]Bonica，R.，Gan，D.，Tappan，D.，和C.Pignataro，“用于多协议标签交换的ICMP扩展”，正在进行的工作，2007年1月。
[ATTACKS] Gont, F., "ICMP attacks against TCP", Work in Progress, October 2006.
[攻击]Gont，F.，“ICMP对TCP的攻击”，正在进行的工作，2006年10月。
[ROUTING-INST] Shen, N. and E. Chen, "ICMP Extensions for Routing Instances", Work in Progress, November 2006.
[ROUTING-INST]Shen，N.和E.Chen，“路由实例的ICMP扩展”，正在进行的工作，2006年11月。
[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月。
Authors' Addresses
作者地址
Ronald P. Bonica Juniper Networks 2251 Corporate Park Drive Herndon, VA 20171 US
罗纳德P.博尼卡Juniper Networks 2251美国弗吉尼亚州赫恩登市企业园大道20171
EMail: rbonica@juniper.net
EMail: rbonica@juniper.net
Der-Hwa Gan Consultant
德华根顾问
EMail: derhwagan@yahoo.com
EMail: derhwagan@yahoo.com
Daniel C. Tappan Consultant
Daniel C.Tappan顾问
EMail: Dan.Tappan@gmail.com
EMail: Dan.Tappan@gmail.com
Carlos Pignataro Cisco Systems, Inc. 7025 Kit Creek Road Research Triangle Park, NC 27709 US
卡洛斯·皮格纳塔罗思科系统公司，美国北卡罗来纳州基特克里克路研究三角公园7025号，邮编27709
EMail: cpignata@cisco.com
EMail: cpignata@cisco.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。