Network Working Group A. Conta
Request for Comments: 4443 Transwitch
Obsoletes: 2463 S. Deering
Updates: 2780 Cisco Systems
Category: Standards Track M. Gupta, Ed.
Tropos Networks
March 2006
Network Working Group A. Conta
Request for Comments: 4443 Transwitch
Obsoletes: 2463 S. Deering
Updates: 2780 Cisco Systems
Category: Standards Track M. Gupta, Ed.
Tropos Networks
March 2006
Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification
Internet协议版本6（IPv6）规范的Internet控制消息协议（ICMPv6）
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 Internet Society (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
This document describes the format of a set of control messages used in ICMPv6 (Internet Control Message Protocol). ICMPv6 is the Internet Control Message Protocol for Internet Protocol version 6 (IPv6).
本文档描述了ICMPv6（Internet控制消息协议）中使用的一组控制消息的格式。ICMPv6是Internet协议版本6（IPv6）的Internet控制消息协议。
Table of Contents
目录
1. Introduction ....................................................2
2. ICMPv6 (ICMP for IPv6) ..........................................3
2.1. Message General Format .....................................3
2.2. Message Source Address Determination .......................5
2.3. Message Checksum Calculation ...............................5
2.4. Message Processing Rules ...................................5
3. ICMPv6 Error Messages ...........................................8
3.1. Destination Unreachable Message ............................8
3.2. Packet Too Big Message ....................................10
3.3. Time Exceeded Message .....................................11
3.4. Parameter Problem Message .................................12
4. ICMPv6 Informational Messages ..................................13
4.1. Echo Request Message ......................................13
4.2. Echo Reply Message ........................................14
5. Security Considerations ........................................15
5.1. Authentication and Confidentiality of ICMP Messages .......15
5.2. ICMP Attacks ..............................................16
6. IANA Considerations ............................................17
6.1. Procedure for New ICMPV6 Type and Code Value Assignments ..17
6.2. Assignments for This Document .............................18
7. References .....................................................19
7.1. Normative References ......................................19
7.2. Informative References ....................................19
8. Acknowledgements ...............................................20
Appendix A - Changes since RFC 2463................................21
1. Introduction ....................................................2
2. ICMPv6 (ICMP for IPv6) ..........................................3
2.1. Message General Format .....................................3
2.2. Message Source Address Determination .......................5
2.3. Message Checksum Calculation ...............................5
2.4. Message Processing Rules ...................................5
3. ICMPv6 Error Messages ...........................................8
3.1. Destination Unreachable Message ............................8
3.2. Packet Too Big Message ....................................10
3.3. Time Exceeded Message .....................................11
3.4. Parameter Problem Message .................................12
4. ICMPv6 Informational Messages ..................................13
4.1. Echo Request Message ......................................13
4.2. Echo Reply Message ........................................14
5. Security Considerations ........................................15
5.1. Authentication and Confidentiality of ICMP Messages .......15
5.2. ICMP Attacks ..............................................16
6. IANA Considerations ............................................17
6.1. Procedure for New ICMPV6 Type and Code Value Assignments ..17
6.2. Assignments for This Document .............................18
7. References .....................................................19
7.1. Normative References ......................................19
7.2. Informative References ....................................19
8. Acknowledgements ...............................................20
Appendix A - Changes since RFC 2463................................21
The Internet Protocol version 6 (IPv6) uses the Internet Control Message Protocol (ICMP) as defined for IPv4 [RFC-792], with a number of changes. The resulting protocol is called ICMPv6 and has an IPv6 Next Header value of 58.
Internet协议版本6（IPv6）使用为IPv4[RFC-792]定义的Internet控制消息协议（ICMP），但有一些更改。产生的协议称为ICMPv6，其IPv6下一报头值为58。
This document describes the format of a set of control messages used in ICMPv6. It does not describe the procedures for using these messages to achieve functions like Path MTU discovery; these procedures are described in other documents (e.g., [PMTU]). Other documents may also introduce additional ICMPv6 message types, such as Neighbor Discovery messages [IPv6-DISC], subject to the general rules for ICMPv6 messages given in Section 2 of this document.
本文档描述了ICMPv6中使用的一组控制消息的格式。它没有描述使用这些消息实现路径MTU发现等功能的过程；其他文件（如[PMTU]）中描述了这些程序。根据本文档第2节中给出的ICMPv6消息的一般规则，其他文档也可能引入其他ICMPv6消息类型，例如邻居发现消息[IPv6光盘]。
Terminology defined in the IPv6 specification [IPv6] and the IPv6 Routing and Addressing specification [IPv6-ADDR] applies to this document as well.
IPv6规范[IPv6]和IPv6路由和寻址规范[IPv6 ADDR]中定义的术语也适用于本文档。
This document obsoletes RFC 2463 [RFC-2463] and updates RFC 2780 [RFC-2780].
本文件淘汰RFC 2463[RFC-2463]并更新RFC 2780[RFC-2780]。
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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC-2119]中所述进行解释。
ICMPv6 is used by IPv6 nodes to report errors encountered in processing packets, and to perform other internet-layer functions, such as diagnostics (ICMPv6 "ping"). ICMPv6 is an integral part of IPv6, and the base protocol (all the messages and behavior required by this specification) MUST be fully implemented by every IPv6 node.
IPv6节点使用ICMPv6报告处理数据包时遇到的错误，并执行其他internet层功能，如诊断（ICMPv6“ping”）。ICMPv6是IPv6不可分割的一部分，基本协议（本规范要求的所有消息和行为）必须由每个IPv6节点完全实现。
Every ICMPv6 message is preceded by an IPv6 header and zero or more IPv6 extension headers. The ICMPv6 header is identified by a Next Header value of 58 in the immediately preceding header. (This is different from the value used to identify ICMP for IPv4.)
每个ICMPv6消息前面都有一个IPv6头和零个或多个IPv6扩展头。ICMPv6标头由前一个标头中的下一个标头值58标识。（这与用于标识IPv4的ICMP的值不同。）
The ICMPv6 messages have the following general format:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Message Body +
| |
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Message Body +
| |
The type field indicates the type of the message. Its value determines the format of the remaining data.
类型字段指示消息的类型。其值决定剩余数据的格式。
The code field depends on the message type. It is used to create an additional level of message granularity.
代码字段取决于消息类型。它用于创建额外级别的消息粒度。
The checksum field is used to detect data corruption in the ICMPv6 message and parts of the IPv6 header.
校验和字段用于检测ICMPv6消息和IPv6标头部分中的数据损坏。
ICMPv6 messages are grouped into two classes: error messages and informational messages. Error messages are identified as such by a zero in the high-order bit of their message Type field values. Thus, error messages have message types from 0 to 127; informational messages have message types from 128 to 255.
ICMPv6消息分为两类：错误消息和信息消息。错误消息由其消息类型字段值的高位中的零标识。因此，错误消息的消息类型从0到127；信息性消息的消息类型从128到255。
This document defines the message formats for the following ICMPv6 messages:
本文档定义了以下ICMPv6消息的消息格式：
ICMPv6 error messages:
ICMPv6错误消息：
1 Destination Unreachable (see Section 3.1) 2 Packet Too Big (see Section 3.2) 3 Time Exceeded (see Section 3.3) 4 Parameter Problem (see Section 3.4)
1无法到达目的地（见第3.1节）2数据包太大（见第3.2节）3超过时间（见第3.3节）4参数问题（见第3.4节）
100 Private experimentation 101 Private experimentation
100个私人实验101个私人实验
127 Reserved for expansion of ICMPv6 error messages
127保留用于扩展ICMPv6错误消息
ICMPv6 informational messages:
ICMPv6信息性消息：
128 Echo Request (see Section 4.1) 129 Echo Reply (see Section 4.2)
128回送请求（见第4.1节）129回送回复（见第4.2节）
200 Private experimentation 201 Private experimentation
200个私人实验201个私人实验
255 Reserved for expansion of ICMPv6 informational messages
255保留用于扩展ICMPv6信息性消息
Type values 100, 101, 200, and 201 are reserved for private experimentation. They are not intended for general use. It is expected that multiple concurrent experiments will be done with the same type values. Any wide-scale and/or uncontrolled usage should obtain real allocations as defined in Section 6.
类型值100、101、200和201保留用于私人实验。它们不适用于一般用途。预计将使用相同的类型值进行多个并行实验。任何大规模和/或不受控制的使用应获得第6节中定义的实际分配。
Type values 127 and 255 are reserved for future expansion of the type value range if there is a shortage in the future. The details of this are left for future work. One possible way of doing this that would not cause any problems with current implementations is that if the type equals 127 or 255, the code field should be used for the new assignment. Existing implementations would ignore the new assignments as specified in Section 2.4, (b). The new messages using these expanded type values could assign fields in the message body for its code values.
类型值127和255是保留的，以便在将来出现短缺时扩展类型值范围。这方面的细节留待今后的工作。一种可能的方法是，如果类型等于127或255，则应将代码字段用于新的赋值，这样做不会对当前实现造成任何问题。现有实现将忽略第2.4节（b）中规定的新分配。使用这些扩展类型值的新消息可以在消息体中为其代码值分配字段。
Sections 3 and 4 describe the message formats for the ICMPv6 error message types 1 through 4 and informational message types 128 and 129.
第3节和第4节描述了ICMPv6错误消息类型1到4以及信息消息类型128和129的消息格式。
Inclusion of, at least, the start of the invoking packet is intended to allow the originator of a packet that has resulted in an ICMPv6 error message to identify the upper-layer protocol and process that sent the packet.
至少包括调用分组的开始旨在允许导致ICMPv6错误消息的分组的发起人识别发送分组的上层协议和过程。
A node that originates an ICMPv6 message has to determine both the Source and Destination IPv6 Addresses in the IPv6 header before calculating the checksum. If the node has more than one unicast address, it MUST choose the Source Address of the message as follows:
在计算校验和之前，发起ICMPv6消息的节点必须确定IPv6报头中的源IPv6地址和目标IPv6地址。如果节点有多个单播地址，则必须按如下方式选择消息的源地址：
(a) If the message is a response to a message sent to one of the node's unicast addresses, the Source Address of the reply MUST be that same address.
(a) 如果消息是对发送到节点单播地址之一的消息的响应，则应答的源地址必须是该地址。
(b) If the message is a response to a message sent to any other address, such as
(b) 如果消息是对发送到任何其他地址的消息的响应，例如
- a multicast group address, - an anycast address implemented by the node, or - a unicast address that does not belong to the node
- 多播组地址，-由节点实现的选播地址，或-不属于节点的单播地址
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.
ICMPv6数据包的源地址必须是属于该节点的单播地址。地址应根据规则选择，该规则将用于选择由节点发起的任何其他数据包的源地址，给定数据包的目的地地址。然而，如果这将导致可从ICMPv6分组的目的地到达的地址的更具信息性的选择，则可以以替代方式选择它。
The checksum is the 16-bit one's complement of the one's complement sum of the entire ICMPv6 message, starting with the ICMPv6 message type field, and prepended with a "pseudo-header" of IPv6 header fields, as specified in [IPv6, Section 8.1]. The Next Header value used in the pseudo-header is 58. (The inclusion of a pseudo-header in the ICMPv6 checksum is a change from IPv4; see [IPv6] for the rationale for this change.)
校验和是整个ICMPv6消息的补码和的16位1的补码，从ICMPv6消息类型字段开始，并以IPv6报头字段的“伪报头”作为前缀，如[IPv6，第8.1节]中所述。伪报头中使用的下一个报头值是58。（在ICMPv6校验和中包含伪报头是对IPv4的更改；有关此更改的基本原理，请参阅[IPv6]）
For computing the checksum, the checksum field is first set to zero.
为了计算校验和，校验和字段首先设置为零。
Implementations MUST observe the following rules when processing ICMPv6 messages (from [RFC-1122]):
在处理ICMPv6消息（来自[RFC-1122]）时，实现必须遵守以下规则：
(a) If an ICMPv6 error message of unknown type is received at its destination, it MUST be passed to the upper-layer process that originated the packet that caused the error, where this can be identified (see Section 2.4, (d)).
(a) 如果在其目的地接收到未知类型的ICMPv6错误消息，则必须将其传递给发起导致错误的数据包的上层进程，在该上层进程中可以识别错误（参见第2.4节（d））。
(b) If an ICMPv6 informational message of unknown type is received, it MUST be silently discarded.
(b) 如果收到未知类型的ICMPv6信息性消息，则必须以静默方式将其丢弃。
(c) Every ICMPv6 error message (type < 128) MUST include as much of the IPv6 offending (invoking) packet (the packet that caused the error) as possible without making the error message packet exceed the minimum IPv6 MTU [IPv6].
(c) 每个ICMPv6错误消息（类型<128）必须包含尽可能多的IPv6违规（调用）数据包（导致错误的数据包），而不会使错误消息数据包超过最小IPv6 MTU[IPv6]。
(d) In cases where the internet-layer protocol is required to pass an ICMPv6 error message to the upper-layer process, the upper-layer protocol type is extracted from the original packet (contained in the body of the ICMPv6 error message) and used to select the appropriate upper-layer process to handle the error.
(d) 如果需要internet层协议将ICMPv6错误消息传递给上层进程，则从原始数据包（包含在ICMPv6错误消息正文中）提取上层协议类型，并用于选择适当的上层进程来处理错误。
In cases where it is not possible to retrieve the upper-layer protocol type from the ICMPv6 message, the ICMPv6 message is silently dropped after any IPv6-layer processing. One example of such a case is an ICMPv6 message with an unusually large amount of extension headers that does not have the upper-layer protocol type due to truncation of the original packet to meet the minimum IPv6 MTU [IPv6] limit. Another example is an ICMPv6 message with an ESP extension header for which it is not possible to decrypt the original packet due to either truncation or the unavailability of the state necessary to decrypt the packet.
在无法从ICMPv6消息中检索上层协议类型的情况下，在任何IPv6层处理之后，ICMPv6消息都会自动删除。这种情况的一个示例是ICMPv6消息，由于原始数据包被截断以满足最小IPv6 MTU[IPv6]限制，因此该消息具有异常大量的扩展头，不具有上层协议类型。另一个示例是带有ESP扩展头的ICMPv6消息，由于截断或解密数据包所需的状态不可用，因此无法对原始数据包进行解密。
(e) An ICMPv6 error message MUST NOT be originated as a result of receiving the following:
(e) ICMPv6错误消息不得因接收到以下内容而发出：
(e.1) An ICMPv6 error message.
（e.1）ICMPv6错误消息。
(e.2) An ICMPv6 redirect message [IPv6-DISC].
（e.2）ICMPv6重定向消息[IPv6光盘]。
(e.3) A packet destined to an IPv6 multicast address. (There are two exceptions to this rule: (1) the Packet Too Big Message (Section 3.2) to allow Path MTU discovery to work for IPv6 multicast, and (2) the Parameter Problem Message, Code 2 (Section 3.4) reporting an unrecognized IPv6 option (see Section 4.2 of [IPv6]) that has the Option Type highest-order two bits set to 10).
（e.3）目的地为IPv6多播地址的数据包。（此规则有两个例外：（1）数据包太大消息（第3.2节）不允许路径MTU发现用于IPv6多播，以及（2）参数问题消息，代码2（第3.4节）报告未识别的IPv6选项（请参见[IPv6]第4.2节），该选项类型的最高阶2位设置为10）。
(e.4) A packet sent as a link-layer multicast (the exceptions from e.3 apply to this case, too).
（e.4）作为链路层多播发送的数据包（e.3的例外情况也适用于这种情况）。
(e.5) A packet sent as a link-layer broadcast (the exceptions from e.3 apply to this case, too).
（e.5）作为链路层广播发送的数据包（e.3的例外情况也适用于这种情况）。
(e.6) A packet whose source address does not uniquely identify a single node -- e.g., the IPv6 Unspecified Address, an IPv6 multicast address, or an address known by the ICMP message originator to be an IPv6 anycast address.
（e.6）其源地址不能唯一标识单个节点的数据包，例如，IPv6未指定地址、IPv6多播地址或ICMP消息发起人已知为IPv6选播地址的地址。
(f) Finally, in order to limit the bandwidth and forwarding costs incurred by originating ICMPv6 error messages, an IPv6 node MUST limit the rate of ICMPv6 error messages it originates. This situation may occur when a source sending a stream of erroneous packets fails to heed the resulting ICMPv6 error messages.
(f) 最后，为了限制发起ICMPv6错误消息所产生的带宽和转发成本，IPv6节点必须限制其发起ICMPv6错误消息的速率。当发送错误数据包流的源未能注意到产生的ICMPv6错误消息时，可能会发生这种情况。
Rate-limiting of forwarded ICMP messages is out of scope of this specification.
转发ICMP消息的速率限制超出本规范的范围。
A recommended method for implementing the rate-limiting function is a token bucket, limiting the average rate of transmission to N, where N can be either packets/second or a fraction of the attached link's bandwidth, but allowing up to B error messages to be transmitted in a burst, as long as the long-term average is not exceeded.
实现速率限制功能的推荐方法是令牌桶，将平均传输速率限制为N，其中N可以是分组/秒或连接链路带宽的一小部分，但只要不超过长期平均值，允许在突发中传输多达B条错误消息。
Rate-limiting mechanisms that cannot cope with bursty traffic (e.g., traceroute) are not recommended; for example, a simple timer-based implementation, allowing an error message every T milliseconds (even with low values for T), is not reasonable.
不建议使用无法应对突发流量的速率限制机制（如跟踪路由）；例如，一个简单的基于计时器的实现，允许每T毫秒一次错误消息（即使T的值很低），是不合理的。
The rate-limiting parameters SHOULD be configurable. In the case of a token-bucket implementation, the best defaults depend on where the implementation is expected to be deployed (e.g., a high-end router vs. an embedded host). For example, in a small/mid-size device, the possible defaults could be B=10, N=10/s.
速率限制参数应该是可配置的。在令牌桶实现的情况下，最佳默认值取决于实现的预期部署位置（例如，高端路由器与嵌入式主机）。例如，在小型/中型设备中，可能的默认值为B=10，N=10/s。
NOTE: THE RESTRICTIONS UNDER (e) AND (f) ABOVE TAKE PRECEDENCE OVER ANY REQUIREMENT ELSEWHERE IN THIS DOCUMENT FOR ORIGINATING ICMP ERROR MESSAGES.
注：上述（e）和（f）项下的限制优先于本文件其他地方对原始ICMP错误消息的任何要求。
The following sections describe the message formats for the above ICMPv6 messages.
以下各节介绍上述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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| As much of invoking packet |
+ as possible without the ICMPv6 packet +
| exceeding the minimum IPv6 MTU [IPv6] |
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| As much of invoking packet |
+ as possible without the ICMPv6 packet +
| exceeding the minimum IPv6 MTU [IPv6] |
IPv6 Fields:
IPv6字段：
Destination Address
目的地址
Copied from the Source Address field of the invoking packet.
从调用数据包的源地址字段复制。
ICMPv6 Fields:
ICMPv6字段：
Type 1
类型1
Code 0 - No route to destination 1 - Communication with destination administratively prohibited 2 - Beyond scope of source address 3 - Address unreachable 4 - Port unreachable 5 - Source address failed ingress/egress policy 6 - Reject route to destination
代码0-没有到目的地1的路由-与目的地的通信管理禁止2-超出源地址3的范围-地址不可访问4-端口不可访问5-源地址失败的入口/出口策略6-拒绝到目的地的路由
Unused This field is unused for all code values. It must be initialized to zero by the originator and ignored by the receiver. Description
未使用此字段未用于所有代码值。发起者必须将其初始化为零，接收者必须忽略它。描述
A Destination Unreachable message SHOULD be generated by a router, or by the IPv6 layer in the originating node, in response to a packet that cannot be delivered to its destination address for reasons other than congestion. (An ICMPv6 message MUST NOT be generated if a packet is dropped due to congestion.)
目的地不可到达消息应由路由器生成，或由发起节点中的IPv6层生成，以响应由于拥塞以外的原因而无法传递到其目的地地址的数据包。（如果数据包因拥塞而丢失，则不得生成ICMPv6消息。）
If the reason for the failure to deliver is lack of a matching entry in the forwarding node's routing table, the Code field is set to 0.
如果传递失败的原因是转发节点的路由表中缺少匹配项，则代码字段设置为0。
(This error can occur only in nodes that do not hold a "default route" in their routing tables.)
（此错误只能发生在其路由表中没有“默认路由”的节点中。）
If the reason for the failure to deliver is administrative prohibition (e.g., a "firewall filter"), the Code field is set to 1.
如果未能交付的原因是行政禁止（例如，“防火墙过滤器”），则代码字段设置为1。
If the reason for the failure to deliver is that the destination is beyond the scope of the source address, the Code field is set to 2. This condition can occur only when the scope of the source address is smaller than the scope of the destination address (e.g., when a packet has a link-local source address and a global-scope destination address) and the packet cannot be delivered to the destination without leaving the scope of the source address.
如果未能传递的原因是目标地址超出了源地址的范围，则代码字段设置为2。只有当源地址的作用域小于目标地址的作用域时（例如，当分组具有链路本地源地址和全局作用域目标地址时），并且分组在不离开源地址的作用域的情况下不能被递送到目标时，才可能发生这种情况。
If the reason for the failure to deliver cannot be mapped to any of other codes, the Code field is set to 3. Example of such cases are an inability to resolve the IPv6 destination address into a corresponding link address, or a link-specific problem of some sort.
如果未能交付的原因无法映射到任何其他代码，则代码字段设置为3。此类情况的示例是无法将IPv6目标地址解析为相应的链路地址，或某种特定于链路的问题。
One specific case in which a Destination Unreachable message is sent with a code 3 is in response to a packet received by a router from a point-to-point link, destined to an address within a subnet assigned to that same link (other than one of the receiving router's own addresses). In such a case, the packet MUST NOT be forwarded back onto the arrival link.
发送带有代码3的目的地不可到达消息的一种特定情况是响应路由器从点到点链路接收到的分组，该分组的目的地是分配给同一链路的子网内的地址（接收路由器自己的地址之一除外）。在这种情况下，数据包不得转发回到达链路。
A destination node SHOULD originate a Destination Unreachable message with Code 4 in response to a packet for which the transport protocol (e.g., UDP) has no listener, if that transport protocol has no alternative means to inform the sender.
如果传输协议（例如UDP）没有监听器，则目标节点应发起代码为4的目标不可到达消息，以响应该传输协议（例如UDP）没有监听器的数据包，前提是该传输协议没有其他方法通知发送方。
If the reason for the failure to deliver is that the packet with this source address is not allowed due to ingress or egress filtering policies, the Code field is set to 5.
如果未能交付的原因是由于入口或出口过滤策略而不允许使用此源地址的数据包，则代码字段设置为5。
If the reason for the failure to deliver is that the route to the destination is a reject route, the Code field is set to 6. This may occur if the router has been configured to reject all the traffic for a specific prefix.
如果未能交付的原因是到目的地的路线是拒绝路线，则代码字段设置为6。如果路由器已配置为拒绝特定前缀的所有通信量，则可能发生这种情况。
Codes 5 and 6 are more informative subsets of code 1.
代码5和6是代码1的更多信息子集。
For security reasons, it is recommended that implementations SHOULD allow sending of ICMP destination unreachable messages to be disabled, preferably on a per-interface basis.
出于安全原因，建议实现应允许禁用发送ICMP目标不可访问消息，最好是基于每个接口。
Upper Layer Notification
上层通知
A node receiving the ICMPv6 Destination Unreachable message MUST notify the upper-layer process if the relevant process can be identified (see Section 2.4, (d)).
如果可以识别相关进程，则接收ICMPv6目的地不可到达消息的节点必须通知上层进程（参见第2.4节（d））。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MTU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| As much of invoking packet |
+ as possible without the ICMPv6 packet +
| exceeding the minimum IPv6 MTU [IPv6] |
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MTU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| As much of invoking packet |
+ as possible without the ICMPv6 packet +
| exceeding the minimum IPv6 MTU [IPv6] |
IPv6 Fields:
IPv6字段：
Destination Address
目的地址
Copied from the Source Address field of the invoking packet.
从调用数据包的源地址字段复制。
ICMPv6 Fields:
ICMPv6字段：
Type 2
类型2
Code Set to 0 (zero) by the originator and ignored by the receiver.
发起者将代码设置为0（零），接收者将其忽略。
MTU The Maximum Transmission Unit of the next-hop link.
MTU下一跳链路的最大传输单位。
Description
描述
A Packet Too Big MUST be sent by a router in response to a packet that it cannot forward because the packet is larger than the MTU of the outgoing link. The information in this message is used as part of the Path MTU Discovery process [PMTU].
太大的数据包必须由路由器发送，以响应它无法转发的数据包，因为该数据包大于传出链路的MTU。此消息中的信息用作路径MTU发现过程[PMTU]的一部分。
Originating a Packet Too Big Message makes an exception to one of the rules as to when to originate an ICMPv6 error message. Unlike other messages, it is sent in response to a packet received with an IPv6 multicast destination address, or with a link-layer multicast or link-layer broadcast address.
发起数据包过大的消息会使关于何时发起ICMPv6错误消息的规则之一出现异常。与其他消息不同，它是响应使用IPv6多播目标地址或链路层多播或链路层广播地址接收的数据包而发送的。
Upper Layer Notification
上层通知
An incoming Packet Too Big message MUST be passed to the upper-layer process if the relevant process can be identified (see Section 2.4, (d)).
如果可以识别相关进程，则传入的数据包过大消息必须传递给上层进程（参见第2.4节（d））。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| As much of invoking packet |
+ as possible without the ICMPv6 packet +
| exceeding the minimum IPv6 MTU [IPv6] |
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| As much of invoking packet |
+ as possible without the ICMPv6 packet +
| exceeding the minimum IPv6 MTU [IPv6] |
IPv6 Fields:
IPv6字段：
Destination Address Copied from the Source Address field of the invoking packet.
从调用数据包的源地址字段复制的目标地址。
ICMPv6 Fields:
ICMPv6字段：
Type 3
类型3
Code 0 - Hop limit exceeded in transit 1 - Fragment reassembly time exceeded
代码0-传输过程中超过跃点限制1-超过碎片重新组装时间
Unused This field is unused for all code values. It must be initialized to zero by the originator and ignored by the receiver.
未使用此字段未用于所有代码值。发起者必须将其初始化为零，接收者必须忽略它。
Description
描述
If a router receives a packet with a Hop Limit of zero, or if a router decrements a packet's Hop Limit to zero, it MUST discard the packet and originate an ICMPv6 Time Exceeded message with Code 0 to the source of the packet. This indicates either a routing loop or too small an initial Hop Limit value.
如果路由器接收到跃点限制为零的数据包，或者如果路由器将数据包的跃点限制减至零，则必须丢弃该数据包，并向数据包源发出代码为0的ICMPv6超时消息。这表示路由循环或初始跃点限制值太小。
An ICMPv6 Time Exceeded message with Code 1 is used to report fragment reassembly timeout, as specified in [IPv6, Section 4.5].
根据[IPv6，第4.5节]的规定，代码为1的ICMPv6超时消息用于报告片段重组超时。
Upper Layer Notification
上层通知
An incoming Time Exceeded message MUST be passed to the upper-layer process if the relevant process can be identified (see Section 2.4, (d)).
如果可以识别相关流程，则传入的超时消息必须传递给上层流程（参见第2.4节（d））。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| As much of invoking packet |
+ as possible without the ICMPv6 packet +
| exceeding the minimum IPv6 MTU [IPv6] |
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| As much of invoking packet |
+ as possible without the ICMPv6 packet +
| exceeding the minimum IPv6 MTU [IPv6] |
IPv6 Fields:
IPv6字段：
Destination Address
目的地址
Copied from the Source Address field of the invoking packet.
从调用数据包的源地址字段复制。
ICMPv6 Fields:
ICMPv6字段：
Type 4
类型4
Code 0 - Erroneous header field encountered 1 - Unrecognized Next Header type encountered 2 - Unrecognized IPv6 option encountered
代码0-遇到错误的标头字段1-遇到无法识别的下一个标头类型2-遇到无法识别的IPv6选项
Pointer Identifies the octet offset within the invoking packet where the error was detected.
指针标识检测到错误的调用数据包内的八位字节偏移量。
The pointer will point beyond the end of the ICMPv6 packet if the field in error is beyond what can fit in the maximum size of an ICMPv6 error message.
如果错误字段超出了ICMPv6错误消息的最大大小，指针将指向ICMPv6数据包的结尾。
Description
描述
If an IPv6 node processing a packet finds a problem with a field in the IPv6 header or extension headers such that it cannot complete processing the packet, it MUST discard the packet and SHOULD originate an ICMPv6 Parameter Problem message to the packet's source, indicating the type and location of the problem.
如果处理数据包的IPv6节点发现IPv6报头或扩展报头中的某个字段存在问题，以致无法完成对该数据包的处理，则必须丢弃该数据包，并应向数据包的源发出ICMPv6参数问题消息，指示问题的类型和位置。
Codes 1 and 2 are more informative subsets of Code 0.
代码1和2是代码0的更多信息子集。
The pointer identifies the octet of the original packet's header where the error was detected. For example, an ICMPv6 message with a Type field of 4, Code field of 1, and Pointer field of 40 would indicate that the IPv6 extension header following the IPv6 header of the original packet holds an unrecognized Next Header field value.
指针标识检测到错误的原始数据包头的八位字节。例如，类型字段为4、代码字段为1、指针字段为40的ICMPv6消息将指示原始数据包的IPv6标头后面的IPv6扩展标头包含无法识别的下一个标头字段值。
Upper Layer Notification
上层通知
A node receiving this ICMPv6 message MUST notify the upper-layer process if the relevant process can be identified (see Section 2.4, (d)).
如果可以识别相关流程，则接收此ICMPv6消息的节点必须通知上层流程（参见第2.4节（d））。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ...
+-+-+-+-+-
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ...
+-+-+-+-+-
IPv6 Fields:
IPv6字段：
Destination Address
目的地址
Any legal IPv6 address.
任何合法的IPv6地址。
ICMPv6 Fields:
ICMPv6字段：
Type 128
128型
Code 0
代码0
Identifier An identifier to aid in matching Echo Replies to this Echo Request. May be zero.
标识符用于帮助匹配对此回显请求的回显答复的标识符。可能是零。
Sequence Number
序列号
A sequence number to aid in matching Echo Replies to this Echo Request. May be zero.
一个序列号，用于帮助匹配对此回送请求的回送回复。可能是零。
Data Zero or more octets of arbitrary data.
数据任意数据的零个或多个八位字节。
Description
描述
Every node MUST implement an ICMPv6 Echo responder function that receives Echo Requests and originates corresponding Echo Replies. A node SHOULD also implement an application-layer interface for originating Echo Requests and receiving Echo Replies, for diagnostic purposes.
每个节点都必须实现ICMPv6回显响应器功能，该功能接收回显请求并发起相应的回显响应。节点还应该实现一个应用层接口，用于发起回显请求和接收回显回复，以便进行诊断。
Upper Layer Notification
上层通知
Echo Request messages MAY be passed to processes receiving ICMP messages.
回显请求消息可以传递给接收ICMP消息的进程。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ...
+-+-+-+-+-
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ...
+-+-+-+-+-
IPv6 Fields:
IPv6字段：
Destination Address
目的地址
Copied from the Source Address field of the invoking Echo Request packet.
从调用回显请求数据包的源地址字段复制。
ICMPv6 Fields:
ICMPv6字段：
Type 129
129型
Code 0
代码0
Identifier The identifier from the invoking Echo Request message.
标识符调用回显请求消息中的标识符。
Sequence Number
序列号
The sequence number from the invoking Echo Request message.
调用回显请求消息的序列号。
Data The data from the invoking Echo Request message.
数据来自调用回显请求消息的数据。
Description
描述
Every node MUST implement an ICMPv6 Echo responder function that receives Echo Requests and originates corresponding Echo Replies. A node SHOULD also implement an application-layer interface for originating Echo Requests and receiving Echo Replies, for diagnostic purposes.
每个节点都必须实现ICMPv6回显响应器功能，该功能接收回显请求并发起相应的回显响应。节点还应该实现一个应用层接口，用于发起回显请求和接收回显回复，以便进行诊断。
The source address of an Echo Reply sent in response to a unicast Echo Request message MUST be the same as the destination address of that Echo Request message.
为响应单播回显请求消息而发送的回显回复的源地址必须与该回显请求消息的目标地址相同。
An Echo Reply SHOULD be sent in response to an Echo Request message sent to an IPv6 multicast or anycast address. In this case, the source address of the reply MUST be a unicast address belonging to the interface on which the Echo Request message was received.
应发送回显回复以响应发送到IPv6多播或选播地址的回显请求消息。在这种情况下，应答的源地址必须是属于接收回显请求消息的接口的单播地址。
The data received in the ICMPv6 Echo Request message MUST be returned entirely and unmodified in the ICMPv6 Echo Reply message.
在ICMPv6回显请求消息中接收的数据必须在ICMPv6回显回复消息中完全返回且不作修改。
Upper Layer Notification
上层通知
Echo Reply messages MUST be passed to the process that originated an Echo Request message. An Echo Reply message MAY be passed to processes that did not originate the Echo Request message.
回送回复消息必须传递给发出回送请求消息的进程。回显回复消息可以传递给未发起回显请求消息的进程。
Note that there is no limitation on the amount of data that can be put in Echo Request and Echo Reply Messages.
请注意，对可以放入回显请求和回显回复消息中的数据量没有限制。
ICMP protocol packet exchanges can be authenticated using the IP Authentication Header [IPv6-AUTH] or IP Encapsulating Security Payload Header [IPv6-ESP]. Confidentiality for the ICMP protocol packet exchanges can be achieved using the IP Encapsulating Security Payload Header [IPv6-ESP].
ICMP协议数据包交换可以使用IP身份验证标头[IPv6 AUTH]或IP封装安全有效负载标头[IPv6 ESP]进行身份验证。ICMP协议数据包交换的机密性可以使用IP封装安全有效负载头[IPv6 ESP]实现。
[SEC-ARCH] describes the IPsec handling of ICMP traffic in detail.
[SEC-ARCH]详细描述了ICMP通信的IPsec处理。
ICMP messages may be subject to various attacks. A complete discussion can be found in the IP Security Architecture [IPv6-SA]. A brief discussion of these attacks and their prevention follows:
ICMP消息可能会受到各种攻击。完整的讨论可以在IP安全体系结构[IPv6 SA]中找到。下面简要讨论这些攻击及其预防：
1. ICMP messages may be subject to actions intended to cause the receiver to believe the message came from a different source from that of the message originator. The protection against this attack can be achieved by applying the IPv6 Authentication mechanism [IPv6-AUTH] to the ICMP message.
1. ICMP消息可能会受到旨在使接收方相信消息来自与消息发起人不同来源的行为的影响。可以通过对ICMP消息应用IPv6身份验证机制[IPv6 AUTH]来实现对此攻击的保护。
2. ICMP messages may be subject to actions intended to cause the message or the reply to it to go to a destination different from that of the message originator's intention. The protection against this attack can be achieved by using the Authentication Header [IPv6-AUTH] or the Encapsulating Security Payload Header [IPv6-ESP]. The Authentication Header provides the protection against change for the source and the destination address of the IP packet. The Encapsulating Security Payload Header does not provide this protection, but the ICMP checksum calculation includes the source and the destination addresses, and the Encapsulating Security Payload Header protects the checksum. Therefore, the combination of ICMP checksum and the Encapsulating Security Payload Header provides protection against this attack. The protection provided by the Encapsulating Security Payload Header will not be as strong as the protection provided by the Authentication Header.
2. ICMP消息可能会受到旨在使消息或对消息的回复转到与消息发起人意图不同的目的地的操作的影响。可以通过使用身份验证标头[IPv6 AUTH]或封装安全有效负载标头[IPv6 ESP]来实现对此攻击的保护。身份验证报头为IP数据包的源地址和目标地址提供了防止更改的保护。封装安全有效负载标头不提供此保护，但ICMP校验和计算包括源地址和目标地址，封装安全有效负载标头保护校验和。因此，ICMP校验和和和封装安全有效负载头的组合提供了针对这种攻击的保护。封装安全有效负载头提供的保护不如身份验证头提供的保护强大。
3. ICMP messages may be subject to changes in the message fields, or payload. The authentication [IPv6-AUTH] or encryption [IPv6-ESP] of the ICMP message protects against such actions.
3. ICMP消息可能会在消息字段或有效负载中发生更改。ICMP消息的身份验证[IPv6身份验证]或加密[IPv6 ESP]可防止此类操作。
4. ICMP messages may be used to attempt denial-of-service attacks by sending back to back erroneous IP packets. An implementation that correctly followed Section 2.4, paragraph (f), of this specification, would be protected by the ICMP error rate limiting mechanism.
4. ICMP消息可通过发送背对背的错误IP数据包来尝试拒绝服务攻击。正确遵循本规范第2.4节（f）段的实施将受到ICMP错误率限制机制的保护。
5. The exception number 2 of rule e.3 in Section 2.4 gives a malicious node the opportunity to cause a denial-of-service attack to a multicast source. A malicious node can send a multicast packet with an unknown destination option marked as mandatory, with the IPv6 source address of a valid multicast source. A large number of destination nodes will send an ICMP Parameter Problem Message to the multicast source, causing a denial-of-service attack. The way multicast traffic is forwarded by the multicast routers requires that the malicious node be part of the correct
5. 第2.4节规则e.3中的例外情况2使恶意节点有机会对多播源发起拒绝服务攻击。恶意节点可以发送带有标记为强制的未知目标选项的多播数据包，其中包含有效多播源的IPv6源地址。大量目标节点将向多播源发送ICMP参数问题消息，导致拒绝服务攻击。多播路由器转发多播流量的方式要求恶意节点是正确路由的一部分
multicast path, i.e., near to the multicast source. This attack can only be avoided by securing the multicast traffic. The multicast source should be careful while sending multicast traffic with the destination options marked as mandatory, because they can cause a denial-of-service attack to themselves if the destination option is unknown to a large number of destinations.
多播路径，即多播源附近。这种攻击只能通过保护多播流量来避免。在发送目标选项标记为强制的多播流量时，多播源应小心，因为如果大量目标不知道目标选项，则它们可能会对自身造成拒绝服务攻击。
6. As the ICMP messages are passed to the upper-layer processes, it is possible to perform attacks on the upper layer protocols (e.g., TCP) with ICMP [TCP-attack]. It is recommended that the upper layers perform some form of validation of ICMP messages (using the information contained in the payload of the ICMP message) before acting upon them. The actual validation checks are specific to the upper layers and are out of the scope of this specification. Protecting the upper layer with IPsec mitigates these attacks.
6. 当ICMP消息被传递到上层进程时，可能会使用ICMP[TCP攻击]对上层协议（例如TCP）进行攻击。建议上层在对ICMP消息执行操作之前，对ICMP消息执行某种形式的验证（使用ICMP消息有效负载中包含的信息）。实际验证检查针对上层，不在本规范范围内。使用IPsec保护上层可以减轻这些攻击。
ICMP error messages signal network error conditions that were encountered while processing an internet datagram. Depending on the particular scenario, the error conditions being reported might or might not get solved in the near term. Therefore, reaction to ICMP error messages may depend not only on the error type and code but also on other factors, such as the time at which the error messages are received, previous knowledge of the network error conditions being reported, and knowledge of the network scenario in which the receiving host is operating.
ICMP错误消息表示在处理internet数据报时遇到的网络错误情况。根据特定的场景，报告的错误条件可能在短期内得到解决，也可能无法得到解决。因此，对ICMP错误消息的反应可能不仅取决于错误类型和代码，还取决于其他因素，例如接收错误消息的时间、先前对报告的网络错误状况的了解以及对接收主机运行的网络场景的了解。
The IPv6 ICMP header defined in this document contains the following fields that carry values assigned from IANA-managed name spaces: Type and Code. Code field values are defined relative to a specific Type value.
本文档中定义的IPv6 ICMP标头包含以下字段，这些字段携带从IANA托管名称空间分配的值：类型和代码。代码字段值是相对于特定类型值定义的。
Values for the IPv6 ICMP Type fields are allocated using the following procedure:
使用以下过程分配IPv6 ICMP类型字段的值：
1. The IANA should allocate and permanently register new ICMPv6 type codes from IETF RFC publication. This is for all RFC types, including standards track, informational, and experimental status, that originate from the IETF and have been approved by the IESG for publication.
1. IANA应从IETF RFC出版物中分配并永久注册新的ICMPv6类型代码。这适用于所有RFC类型，包括源于IETF并经IESG批准发布的标准跟踪、信息和实验状态。
2. IETF working groups with working group consensus and area director approval can request reclaimable ICMPV6 type code assignments from the IANA. The IANA will tag the values as "reclaimable in future".
2. 具有工作组共识和区域主管批准的IETF工作组可以向IANA请求可回收的ICMPV6类型代码分配。IANA将这些值标记为“将来可回收”。
The "reclaimable in the future" tag will be removed when an RFC is published that documents the protocol as defined in 1. This will make the assignment permanent and update the reference on the IANA web pages.
当发布RFC时，“将来可回收”标签将被删除，RFC记录了1中定义的协议。这将使分配永久化，并更新IANA网页上的参考。
At the point where the ICMPv6 type values are 85% assigned, the IETF will review the assignments tagged "reclaimable in the future" and inform the IANA which ones should be reclaimed and reassigned.
当ICMPv6类型值分配85%时，IETF将审查标记为“将来可回收”的分配，并通知IANA哪些分配应回收和重新分配。
3. Requests for new ICMPv6 type value assignments from outside the IETF are only made through the publication of an IETF document, per 1 above. Note also that documents published as "RFC Editor contributions" [RFC-3978] are not considered IETF documents.
3. 根据上文第1条，只有通过发布IETF文件，才能从IETF外部请求新的ICMPv6类型值分配。另请注意，作为“RFC编辑器贡献”[RFC-3978]发布的文件不被视为IETF文件。
The assignment of new Code values for the Type values defined in this document require standards action or IESG approval. The policy for assigning Code values for new IPv6 ICMP Types not defined in this document should be defined in the document defining the new Type values.
为本文件中定义的类型值分配新代码值需要标准行动或IESG批准。为本文档中未定义的新IPv6 ICMP类型分配代码值的策略应在定义新类型值的文档中定义。
The following has updated assignments located at:
以下更新了位于的作业：
http://www.iana.org/assignments/icmpv6-parameters
http://www.iana.org/assignments/icmpv6-parameters
The IANA has reassigned ICMPv6 type 1 "Destination Unreachable" code 2, which was unassigned in [RFC-2463], to:
IANA已将[RFC-2463]中未分配的ICMPv6类型1“无法到达目的地”代码2重新分配给：
2 - Beyond scope of source address
2-超出源地址的范围
The IANA has assigned the following two new codes values for ICMPv6 type 1 "Destination Unreachable":
IANA为ICMPv6类型1“无法到达目的地”分配了以下两个新代码值：
5 - Source address failed ingress/egress policy 6 - Reject route to destination
5-源地址失败的入口/出口策略6-拒绝到目标的路由
The IANA has assigned the following new type values:
IANA已指定以下新类型值：
100 Private experimentation 101 Private experimentation
100个私人实验101个私人实验
127 Reserved for expansion of ICMPv6 error messages
127保留用于扩展ICMPv6错误消息
200 Private experimentation 201 Private experimentation
200个私人实验201个私人实验
255 Reserved for expansion of ICMPv6 informational messages
255保留用于扩展ICMPv6信息性消息
[IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[IPv6]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，1998年12月。
[IPv6-DISC] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[IPv6光盘]Narten，T.，Nordmark，E.，和W.Simpson，“IP版本6（IPv6）的邻居发现”，RFC 2461，1998年12月。
[RFC-792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.
[RFC-792]Postel，J.，“互联网控制消息协议”，STD 5，RFC 792，1981年9月。
[RFC-2463] Conta, A. and S. Deering, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 2463, December 1998.
[RFC-2463]Conta，A.和S.Deering，“互联网协议版本6（IPv6）规范的互联网控制消息协议（ICMPv6）”，RFC 2463，1998年12月。
[RFC-1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[RFC-1122]Braden，R.，“互联网主机的要求-通信层”，标准3，RFC 1122，1989年10月。
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC-2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC-3978] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 3978, March 2005.
[RFC-3978]Bradner，S.，“IETF在贡献中的权利”，BCP 78，RFC 3978，2005年3月。
[RFC-2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers", BCP 37, RFC 2780, March 2000.
[RFC-2780]Bradner，S.和V.Paxson，“互联网协议和相关报头中值的IANA分配指南”，BCP 37，RFC 2780，2000年3月。
[IPv6-ADDR] Hinden, R. and S. Deering, "Intpernet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003.
[IPv6地址]Hinden，R.和S.Deering，“Intpernet协议版本6（IPv6）寻址体系结构”，RFC 3513，2003年4月。
[PMTU] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.
[PMTU]McCann，J.，Deering，S.，和J.Mogul，“IP版本6的路径MTU发现”，RFC 1981，1996年8月。
[IPv6-SA] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[IPv6 SA]Kent，S.和R.Atkinson，“互联网协议的安全架构”，RFC 2401，1998年11月。
[IPv6-AUTH] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[IPv6认证]Kent，S.，“IP认证头”，RFC 4302，2005年12月。
[IPv6-ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4203, December 2005.
[IPv6 ESP]Kent，S.，“IP封装安全有效负载（ESP）”，RFC 4203，2005年12月。
[SEC-ARCH] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[SEC-ARCH]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[TCP-attack] Gont, F., "ICMP attacks against TCP", Work in Progress.
[TCP攻击]Gont，F.，“针对TCP的ICMP攻击”，正在进行中。
The document is derived from previous ICMP documents of the SIPP and IPng working group.
本文件源自SIPP和IPng工作组先前的ICMP文件。
The IPng working group, and particularly Robert Elz, Jim Bound, Bill Simpson, Thomas Narten, Charlie Lynn, Bill Fink, Scott Bradner, Dimitri Haskin, Bob Hinden, Jun-ichiro Itojun Hagino, Tatuya Jinmei, Brian Zill, Pekka Savola, Fred Templin, and Elwyn Davies (in chronological order) provided extensive review information and feedback.
IPng工作组，特别是Robert Elz、Jim Bound、Bill Simpson、Thomas Narten、Charlie Lynn、Bill Fink、Scott Bradner、Dimitri Haskin、Bob Hinden、Jun ichiro Itojun Hagino、Tatuya Jinmei、Brian Zill、Pekka Savola、Fred Templin和Elwyn Davies（按时间顺序）提供了广泛的审查信息和反馈。
Bob Hinden was the document editor for this document.
Bob Hinden是该文档的文档编辑器。
Appendix A - Changes since RFC 2463
附录A-自RFC 2463以来的变更
The following changes were made from RFC 2463:
RFC 2463进行了以下更改：
- Edited the Abstract to make it a little more elaborate.
- 编辑了这篇摘要，使它更详细一点。
- Corrected typos in Section 2.4, where references to sub-bullet e.2 were supposed to be references to e.3.
- 更正了第2.4节中的打字错误，其中对子项目符号e.2的引用应为对e.3的引用。
- Removed the Timer-based and the Bandwidth-based methods from the example rate-limiting mechanism for ICMP error messages. Added Token-bucket based method.
- 从ICMP错误消息的示例速率限制机制中删除了基于计时器和基于带宽的方法。增加了基于令牌桶的方法。
- Added specification that all ICMP error messages shall have exactly 32 bits of type-specific data, so that receivers can reliably find the embedded invoking packet even when they don't recognize the ICMP message Type.
- 增加了所有ICMP错误消息应具有确切的32位类型特定数据的规范，以便接收方即使不识别ICMP消息类型也能可靠地找到嵌入的调用数据包。
- In the description of Destination Unreachable messages, Code 3, added rule prohibiting forwarding of packets back onto point-to-point links from which they were received, if their destination addresses belong to the link itself ("anti-ping-ponging" rule).
- 在目的地不可到达消息的描述中，代码3添加了禁止将数据包转发回接收数据包的点到点链路的规则（如果数据包的目的地地址属于链路本身）（“反乒乓”规则）。
- Added description of Time Exceeded Code 1 (fragment reassembly timeout).
- 增加了超过代码1的时间描述（片段重组超时）。
- Added "beyond scope of source address", "source address failed ingress/egress policy", and "reject route to destination" messages to the family of "unreachable destination" type ICMP error messages (Section 3.1).
- 在“无法到达的目的地”类型ICMP错误消息系列中添加了“超出源地址范围”、“源地址失败的入口/出口策略”和“拒绝路由到目的地”消息（第3.1节）。
- Reserved some ICMP type values for experimentation.
- 为实验保留了一些ICMP类型值。
- Added a NOTE in Section 2.4 that specifies ICMP message processing rules precedence.
- 在第2.4节中添加了一个注释，指定ICMP消息处理规则的优先级。
- Added ICMP REDIRECT to the list in Section 2.4, (e) of cases in which ICMP error messages are not to be generated.
- 将ICMP重定向添加到第2.4节（e）中不生成ICMP错误消息的情况列表中。
- Made minor editorial changes in Section 2.3 on checksum calculation, and in Section 5.2.
- 在关于校验和计算的第2.3节和第5.2节中进行了微小的编辑性修改。
- Clarified in Section 4.2, regarding the Echo Reply Message; the source address of an Echo Reply to an anycast Echo Request should be a unicast address, as in the case of multicast.
- 在第4.2节中阐明了回声回复信息；对选播回显请求的回显回复的源地址应该是单播地址，就像多播的情况一样。
- Revised the Security Considerations section. Added the use of the Encapsulating Security Payload Header for authentication. Changed the requirement of an option of "not allowing unauthenticated ICMP messages" to MAY from SHOULD.
- 修订了安全考虑部分。添加了用于身份验证的封装安全负载头的使用。将“不允许未经验证的ICMP消息”选项的要求从“应”改为“可”。
- Added a new attack in the list of possible ICMP attacks in Section 5.2.
- 在第5.2节中可能的ICMP攻击列表中添加了新的攻击。
- Separated References into Normative and Informative.
- 将参考文献分为规范性参考文献和信息性参考文献。
- Added reference to RFC 2780 "IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers". Also added a note that this document updates RFC 2780.
- 增加了对RFC 2780“互联网协议和相关标题中值的IANA分配指南”的参考。还添加了一条注释，说明本文档更新了RFC 2780。
- Added a procedure for new ICMPv6 Type and Code value assignments in the IANA Considerations section.
- 在IANA注意事项部分中添加了新ICMPv6类型和代码值分配的过程。
- Replaced word "send" with "originate" to make it clear that ICMP packets being forwarded are out of scope of this specification.
- 将单词“send”替换为“origine”，以明确转发的ICMP数据包不在本规范的范围内。
- Changed the ESP and AH references to the updated ESP and AH documents.
- 将ESP和AH引用更改为更新的ESP和AH文档。
- Added reference to the updated IPsec Security Architecture document.
- 添加了对更新的IPsec安全体系结构文档的引用。
- Added a SHOULD requirement for allowing the sending of ICMP destination unreachable messages to be disabled.
- 增加了允许禁用发送ICMP目标不可到达消息的应要求。
- Simplified the source address selection of the ICMPv6 packet.
- 简化了ICMPv6数据包的源地址选择。
- Reorganized the General Message Format (Section 2.1).
- 重新组织通用消息格式（第2.1节）。
- Removed the general packet format from Section 2.1. It refers to Sections 3 and 4 for packet formats now.
- 从第2.1节中删除了通用数据包格式。关于数据包格式，请参见第3节和第4节。
- Added text about attacks to the transport protocols that could potentially be caused by ICMP.
- 添加了关于可能由ICMP引起的传输协议攻击的文本。
Authors' Addresses
作者地址
Alex Conta Transwitch Corporation 3 Enterprise Drive Shelton, CT 06484 USA
美国密苏里州谢尔顿市企业大道3号Alex Conta Transwitch Corporation 06484
EMail: aconta@txc.com
EMail: aconta@txc.com
Stephen Deering Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 USA
史蒂芬·迪林思科系统公司，美国加利福尼亚州圣何塞市西塔斯曼大道170号，邮编95134-1706
Mukesh Gupta, Ed. Tropos Networks 555 Del Rey Avenue Sunnyvale, CA 94085
Mukesh Gupta，Ed.Tropos Networks加利福尼亚州桑尼维尔市德雷大道555号，邮编94085
Phone: +1 408-331-6889
EMail: mukesh.gupta@tropos.com
Phone: +1 408-331-6889
EMail: mukesh.gupta@tropos.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
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 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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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 provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。