RFC 4443中文版

Internet Control Message Protocol (ICMPv6)
for the Internet Protocol Version 6 (IPv6) Specification

Status of This Memo

本文档为互联网社区指定了一种 Internet 标准轨道协议，并请求讨论和改进建议。请参考 “Internet Official Protocol Standards”（STD 1）的最新版本，了解该协议的标准化状态和进展情况。本备忘录的发布不受限制。

Copyright Notice

版权所有（C）互联网协会（2006）。

Abstract

本文档描述了 ICMPv6（Internet Control Message Protocol version 6）中一组控制消息的格式。ICMPv6 是 Internet Protocol version 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. 引言

IPv6 使用了 Internet 控制消息协议（ICMP），该协议在 IPv4 中已定义 [RFC-792]，但有一些变化。由此产生的协议称为 ICMPv6，并具有 IPv6 的下一个报头值为 58。

本文描述了 ICMPv6 中使用的一组控制消息的格式。它不描述使用这些消息来实现路径 MTU 发现等功能的程序；这些程序在其他文档中进行了描述（例如，[PMTU]）。其他文档可能还会引入额外的 ICMPv6 消息类型，例如邻居发现消息 [IPv6-DISC]，遵循本文档第 2 节中给出的 ICMPv6 消息的一般规则。

在 IPv6 规范 [IPv6] 和 IPv6 路由和寻址规范 [IPv6-ADDR] 中定义的术语也适用于本文档。

本文档废弃了 RFC 2463 [RFC-2463] 并更新了 RFC 2780 [RFC-2780]。

本文档中的关键词 “MUST”、“MUST NOT”、“REQUIRED”、“SHALL”、“SHALL NOT”、“SHOULD”、“SHOULD NOT”、“RECOMMENDED”、“MAY” 和 “OPTIONAL” 的解释请参考 [RFC-2119]。

2. ICMPv6（IPv6 的 ICMP）

ICMPv6 被 IPv6 节点用于报告处理数据包时遇到的错误，并执行其他 Internet 层功能，例如诊断（ICMPv6 “ping”）。 ICMPv6 是 IPv6 的一个组成部分，基础协议（本规范要求的所有消息和行为）必须被每个 IPv6 节点完全实现。

2.1. 消息通用格式

每个 ICMPv6 消息前都有一个 IPv6 头部和零个或多个 IPv6 扩展头部。 ICMPv6 头部由前一个报头中的 Next Header 值为 58 标识。（这与用于识别 ICMPv4 的值不同。）

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                          +
      |                                                               |

类型字段指示消息的类型。其值决定了剩余数据的格式。

代码字段取决于消息类型。它用于创建额外的消息粒度级别。

校验和字段用于检测 ICMPv6 消息和 IPv6 头部部分的数据损坏。

ICMPv6 消息分为两类：错误消息和信息消息。错误消息由其消息类型字段中高位为 0 标识为错误消息。因此，错误消息的消息类型为 0 到 127；信息消息的消息类型为 128 到 255。

本文档定义了以下 ICMPv6 消息的消息格式：

ICMPv6 错误消息：

• 1 目标不可达 (参见第 3.1 节)
• 2 包太大 (参见第 3.2 节)
• 3 超时 (参见第 3.3 节)
• 4 参数问题 (参见第 3.4 节)
• 100 私有实验
• 101 私有实验
• 127 保留以扩展 ICMPv6 错误消息

ICMPv6 信息消息：

• 128 回显请求 (参见第 4.1 节)
• 129 回显应答 (参见第 4.2 节)
• 200 私有实验
• 201 私有实验
• 255 保留以扩展 ICMPv6 信息消息

类型值 100、101、200 和 201 保留供私有实验使用，不用于一般用途。预期将使用相同类型值进行多个并发实验。任何大规模和/或不受控制的使用应按照第 6 节中定义的实际分配获取。

类型值 127 和 255 保留以在将来的类型值范围中扩展，以防将来出现短缺情况。具体细节将留待未来工作。一种可能的做法是，如果类型等于 127 或 255，则应使用代码字段进行新分配。现有实现将根据本文档第 2.4 节（b）中规定的方式忽略新的分配。使用这些扩展类型值的新消息可以为其代码值分配消息正文中的字段。

类型值 127 和 255 保留以在将来的类型值范围中扩展，以防将来出现短缺情况。具体细节将留待未来工作。一种可能的做法是，如果类型等于 127 或 255，则应使用代码字段进行新分配。现有实现将根据本文档第 2.4 节（b）中规定的方式忽略新的分配。使用这些扩展类型值的新消息可以为其代码值分配消息正文中的字段。

类型值 127 和 255 保留以在将来的类型值范围中扩展，以防将来出现短缺情况。具体细节将留待未来工作。一种可能的做法是，如果类型等于 127 或 255，则应使用代码字段进行新分配。现有实现将根据本文档第 2.4 节（b）中规定的方式忽略新的分配。使用这些扩展类型值的新消息可以为其代码值分配消息正文中的字段。

类型值 127 和 255 保留以在将来的类型值范围中扩展，以防将来出现短缺情况。具体细节将留待未来工作。一种可能的做法是，如果类型等于 127 或 255，则应使用代码字段进行新分配。现有实现将根据本文档第 2.4 节（b）中规定的方式忽略新的分配。使用这些扩展类型值的新消息可以为其代码值分配消息正文中的字段。

类型值 127 和 255 保留以在将来的类型值范围中扩展，以防将来出现短缺情况。具体细节将留待未来工作。一种可能的做法是，如果类型等于 127 或 255，则应使用代码字段进行新分配。现有实现将根据本文档第 2.4 节（b）中规定的方式忽略新的分配。使用这些扩展类型值的新消息可以为其代码值分配消息正文中的字段。

类型值 127 和 255 保留以在将来的类型值范围中扩展，以防将来出现短缺情况。具体细节将留待未来工作。一种可能的做法是，如果类型等于 127 或 255，则应使用代码字段进行新分配。现有实现将根据本文档第 2.4 节（b）中规定的方式忽略新的分配。使用这些扩展类型值的新消息可以为其代码值分配消息正文中的字段。

第 3 和第 4 节描述了上述 ICMPv6 消息的消息格式。
至少包含调用数据包的开头旨在允许导致 ICMPv6 错误消息的数据包的发起者识别发送该数据包的上层协议和进程。

2.2. 消息源地址确定

发起 ICMPv6 消息的节点在计算校验和之前必须确定 IPv6 报头中的源地址和目标地址。如果节点有多个单播地址，则应根据以下规则选择消息的源地址：

• 如果消息是对发送到节点的单播地址之一的消息的响应，则回复的源地址必须是相同的地址。
• 如果消息是对发送到任何其他地址的消息的响应，例如：
  • 多播组地址，
  • 节点实现的任播地址，
  • 不属于节点的单播地址
    则 ICMPv6 数据包的源地址必须是属于节点的单播地址。地址应根据将要发送的数据包的目的地地址的规则选择源地址。然而，如果这会导致从 ICMPv6 数据包的目的地到达的地址选择更具信息性，可以以其他方式选择地址。

2.3. 消息校验和计算

校验和是 ICMPv6 消息的整体的一的补码之和的 16 位一的补码。其计算从 ICMPv6 消息类型字段开始，并在 IPv6 报头字段之前增加一个 IPv6 报头的伪报头，如 [IPv6, Section 8.1] 所指定。伪报头中使用的 Next Header 值为 58。（将伪报头包括在 ICMPv6 校验和中是与 IPv4 不同的变化；有关此更改的原因，请参阅 [IPv6]。）

在计算校验和时，首先将校验和字段设置为零。

2.4. ICMPv6 消息处理规则

在处理 ICMPv6 消息时，实现必须遵循以下规则（参考自 [RFC-1122]）：

(a) 如果目的地收到未知类型的 ICMPv6 错误消息，则必须将其传递给导致错误的数据包的上层处理程序（如果可以识别）（见第 2.4 节 (d)）。

(b) 如果收到未知类型的 ICMPv6 信息消息，则必须悄悄地丢弃它。

© 每个 ICMPv6 错误消息（类型 < 128）必须包含尽可能多的引发错误的 IPv6 数据包（导致错误的数据包），但不得使错误消息数据包超过最小的 IPv6 MTU [IPv6]。

(d) 在因特网层协议需要将 ICMPv6 错误消息传递给上层处理程序的情况下，应从原始数据包（包含在 ICMPv6 错误消息的正文中）中提取上层协议类型，并用于选择适当的上层处理程序来处理错误。

(e) 不得由于收到以下内容而发起 ICMPv6 错误消息：

   (e.1) ICMPv6 错误消息。
   (e.2) ICMPv6 重定向消息 [IPv6-DISC]。
   (e.3) 发送到 IPv6 多播地址的数据包。（此规则有两个例外：（1）Packet Too Big 消息（第 3.2 节）允许用于 IPv6 多播的路径 MTU 发现，（2）Parameter Problem 消息，代码 2（第 3.4 节）报告一个未识别的 IPv6 选项（请参见 [IPv6] 第 4.2 节），其选项类型的最高两位设置为 10）。
   (e.4) 作为链路层多播发送的数据包（e.3 的例外也适用于此情况）。
   (e.5) 作为链路层广播发送的数据包（e.3 的例外也适用于此情况）。
   (e.6) 源地址不能唯一标识单个节点的数据包，例如：IPv6 未指定地址、IPv6 多播地址或 ICMP 消息发起者知道是 IPv6 任播地址的地址。

(f) 最后，为了限制发起 ICMPv6 错误消息所产生的带宽和转发成本，IPv6 节点必须限制其发起的 ICMPv6 错误消息的速率。当源发送一系列错误数据包而不注意导致的 ICMPv6 错误消息时，可能会发生这种情况。
转发 ICMP 消息的速率限制不在此规范的范围之内。
实施速率限制功能的建议方法是令牌桶，将传输速率的平均速率限制为 N，其中 N 可以是每秒的数据包数或附加链路带宽的一部分，但允许以一个突发传输 B 个错误消息，只要长期平均值未超过。
不能应对突发流量的限速机制（例如 traceroute）不建议使用；例如，基于简单计时器的实现，允许每 T 毫秒发送一条错误消息（即使 T 值较低），也不合理。
应该能够配置速率限制参数。在令牌桶实现的情况下，最佳默认值取决于实现的部署位置（例如，高端路由器 vs 嵌入式主机）。例如，在小型/中型设备中，可能的默认值为 B=10，N=10/s。

注意：上述 (e) 和 (f) 中的限制优先于本文档中任何其他产生 ICMP 错误消息的要求。

以下各节描述了上述 ICMPv6 消息的消息格式。

3. ICMPv6 错误消息

3.1. 目的地不可达消息

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 字段：

Destination Address
复制自引发数据包的源地址字段。

ICMPv6 字段：

Type 1

Code 0 - 没有到达目的地的路由
1 - 目的地与通信被管理员禁止
2 - 超出源地址的范围
3 - 地址不可达
4 - 端口不可达
5 - 源地址未通过入口/出口策略
6 - 拒绝到达目的地的路由

Unused 对于所有代码值，此字段未使用。
它必须由发起者初始化为零，并被接收者忽略。

描述

当数据包因其他原因而无法传递到其目的地地址（而不是因拥塞）时，应由路由器或起始节点的 IPv6 层生成目的地不可达消息。 （如果由于拥塞而丢弃数据包，则不得生成 ICMPv6 消息。）

如果无法传递的原因是由于转发节点的路由表中缺少匹配条目，则将代码字段设置为 0。（此错误仅发生在其路由表中没有“默认路由”的节点上。）

如果无法传递的原因是管理上的禁止（例如，“防火墙过滤器”），则将代码字段设置为 1。

如果无法传递的原因是目的地超出源地址的范围，则将代码字段设置为 2。此条件仅在源地址的范围小于目的地地址的范围时才会发生（例如，当数据包具有链路本地源地址和全球范围目的地地址时），并且数据包无法传递到目的地地址而不离开源地址的范围。

如果无法传递的原因无法映射到任何其他代码，则将代码字段设置为 3。此类情况的示例是无法将 IPv6 目标地址解析为相应的链路地址，或者某种链路特定的问题。

发送具有代码 3 的目的地不可达消息的一个具体情况是，在路由器从点到点链路接收到一个数据包，该数据包被定向到分配给同一链路的子网中的地址（而不是接收路由器自己的地址之一）。在这种情况下，不得将数据包转发回到到达的链路。

目的节点应在传输协议（例如，UDP）没有侦听器的数据包中发起带有代码 4 的目的地不可达消息，如果该传输协议没有其他通知发送者的方法。

如果无法传递的原因是该数据包具有此源地址时不允许的入口或出口策略，则将代码字段设置为 5。

如果无法传递的原因是到达目的地的路由是拒绝路由，则将代码字段设置为 6。如果路由器已配置为拒绝特定前缀的所有流量，则可能会发生此情况。

代码 5 和 6 是代码 1 的更详细的子集。

出于安全原因，建议实现应该允许禁用发送 ICMP 目的地不可达消息，最好是基于每个接口的基础。

上层通知

如果可以识别相关进程（请参阅第 2.4 节 (d)），则接收 ICMPv6 目的地不可达消息的节点必须通知上层进程。

3.2. 数据包太大消息

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 字段：

Destination Address
复制自引发数据包的源地址字段。

ICMPv6 字段：

Type 2

Code 由发起者设置为 0（零），接收者忽略。

MTU 下一跳链路的最大传输单元。

描述

路由器必须发送“数据包太大”消息作为对无法转发的数据包的响应，因为该数据包大于传出链路的 MTU。此消息中的信息是路径 MTU 发现过程 [PMTU] 的一部分。

发送“数据包太大”消息违反了有关何时发送 ICMPv6 错误消息的规则之一。与其他消息不同，它是针对收到具有 IPv6 多播目的地地址或具有链路层多播或链路层广播地址的数据包发送的。

上层通知

如果可以识别相关进程（请参阅第 2.4 节 (d)），则必须将收到的“数据包太大”消息传递给上层进程。

3.3. 时间超过消息

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 字段：

Destination Address
复制自引发数据包的源地址字段。

ICMPv6 字段：

Type 3

Code 0 - 在传输中超过跳限
1 - 片段重组超时

Unused 对于所有代码值，此字段未使用。
必须由发起者初始化为零，并由接收者忽略。

描述

如果路由器收到一个 TTL 为零的数据包，或者路由器将数据包的 TTL 减少到零，它必须丢弃该数据包，并向数据包的源地址发起一个 ICMPv6 时间超过消息，其代码为 0。这表示路由环路或者初始 TTL 值太小。

用代码 1 的 ICMPv6 时间超过消息用于报告片段重组超时，如 [IPv6, Section 4.5] 中所指定。

上层通知

如果可以识别相关进程（请参阅第 2.4 节 (d)），则必须将收到的时间超过消息传递给上层进程。

3.4. 参数问题消息

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 字段：

Destination Address
复制自引发数据包的源地址字段。

ICMPv6 字段：

Type 4

Code 0 - 遇到错误的报头字段
1 - 遇到未识别的下一个报头类型
2 - 遇到未识别的 IPv6 选项
Pointer
标识在引发数据包中检测到错误的八位偏移量。
如果在 ICMPv6 错误消息的最大大小内无法容纳该字段，则指针将指向 ICMPv6 包的末尾之后。

描述

如果 IPv6 节点处理数据包时发现 IPv6 报头或扩展报头中的字段存在问题，导致无法完成数据包的处理，它必须丢弃该数据包，并应向数据包的源发起一个 ICMPv6 参数问题消息，指示问题的类型和位置。

代码 1 和代码 2 是代码 0 的更详细的子集。

指针标识原始数据包报头中检测到错误的八位字节。例如，具有类型字段为 4、代码字段为 1 和指针字段为 40 的 ICMPv6 消息将指示原始数据包的 IPv6 报头后面的 IPv6 扩展报头具有未识别的下一个报头字段值。

上层通知

如果可以识别相关进程（请参阅第 2.4 节 (d)），则收到此 ICMPv6 消息的节点必须通知上层进程。

4.1. 回显请求消息

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 字段：

Destination Address 任何合法的 IPv6 地址。
ICMPv6 字段：
Type 128
Code 0
Identifier 用于将回显回复与此回显请求进行匹配的标识符。可以为零。
Sequence Number 用于将回显回复与此回显请求进行匹配的序列号。可以为零。
Data 任意数据的零个或多个八位字节。
描述
每个节点必须实现一个 ICMPv6 回显响应器功能，用于接收回显请求并生成相应的回显回复。为了诊断目的，节点还应该实现一个应用层接口，用于发起回显请求并接收回显回复。
上层通知
回显请求消息可以传递给接收 ICMP 消息的进程。

4.2. 回显回复消息

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 字段：
Destination Address 从发起的回显请求数据包的源地址字段中复制。
ICMPv6 字段：
Type 129
Code 0
Identifier 来自发起的回显请求消息的标识符。
Sequence Number 来自发起的回显请求消息的序列号。
Data 来自发起的回显请求消息的数据。
描述
每个节点必须实现一个 ICMPv6 回显响应器功能，用于接收回显请求并生成相应的回显回复。为了诊断目的，节点还应该实现一个应用层接口，用于发起回显请求并接收回显回复。

发送的回显回复的源地址，对于针对单播回显请求消息的回复，必须与该回显请求消息的目标地址相同。

对于发送到 IPv6 多播地址或任播地址的回显请求消息，应发送一个回显回复。在这种情况下，回复的源地址必须是接收到回显请求消息的接口上属于单播地址。

ICMPv6 回显请求消息中接收到的数据必须完整且未经修改地返回到 ICMPv6 回显回复消息中。

上层通知

回显回复消息必须传递给发起回显请求消息的进程。回显回复消息可以传递给未发起回显请求消息的进程。

请注意，对于回显请求消息和回显回复消息中可以放置的数据量没有限制。

5. 安全考虑

5.1. ICMP 消息的认证和机密性

ICMP 协议数据包交换可以使用 IP 身份验证头 [IPv6-AUTH] 或 IP 封装安全载荷头 [IPv6-ESP] 进行认证。对于 ICMP 协议的数据包交换，可以使用 IP 封装安全载荷头 [IPv6-ESP] 实现机密性。

[SEC-ARCH] 详细描述了 ICMP 流量的 IPsec 处理方式。

5.2. ICMP 攻击

ICMP 消息可能受到各种攻击。可以在 IP 安全体系结构 [IPv6-SA] 中找到完整的讨论。以下是这些攻击及其预防的简要讨论：

1. ICMP 消息可能受到旨在使接收方相信消息来自于与消息发起者不同源的动作影响。可通过对 ICMP 消息应用 IPv6 认证机制 [IPv6-AUTH] 来防止此类攻击。

2. ICMP 消息可能受到旨在使消息或其回复到达与消息发起者意图不同目标的动作影响。可通过使用身份验证头 [IPv6-AUTH] 或封装安全载荷头 [IPv6-ESP] 来防止此类攻击。身份验证头为 IP 数据包的源地址和目的地地址提供保护。封装安全载荷头不提供此保护，但是 ICMP 校验和包括源地址和目的地地址，并且封装安全载荷头保护了校验和。因此，ICMP 校验和和封装安全载荷头的组合提供了防范此类攻击的保护。封装安全载荷头提供的保护将不如身份验证头提供的保护强。

3. ICMP 消息可能受到消息字段或有效载荷更改的影响。ICMP 消息的认证 [IPv6-AUTH] 或加密 [IPv6-ESP] 可防止此类操作。

4. ICMP 消息可能被用于尝试通过发送连续的错误 IP 数据包进行拒绝服务攻击。正确遵循本规范第 2.4 段 (f) 的实现将受到 ICMP 错误速率限制机制的保护。

5. 第 2.4 节中规则 e.3 的例外情况为恶意节点提供了向多播源发起拒绝服务攻击的机会。恶意节点可以发送带有标记为必需但未知目的地选项的多播数据包，并具有有效多播源的 IPv6 源地址。大量目标节点将向多播源发送 ICMP 参数问题消息，导致拒绝服务攻击。多播路由器转发多播流量的方式要求恶意节点是正确多播路径的一部分，即靠近多播源。只有通过保护多播流量才能避免此攻击。多播源在发送带有标记为必需的目的地选项的多播流量时应谨慎，因为如果大量目标不知道目的地选项，则可能会对自身发起拒绝服务攻击。

6. 由于 ICMP 消息被传递到上层进程，因此可能会对上层协议（例如 TCP）进行 ICMP 攻击 [TCP-attack]。建议上层在执行操作之前对 ICMP 消息进行某种形式的验证（使用 ICMP 消息的有效载荷中包含的信息）。实际的验证检查是特定于上层的，并且超出了本规范的范围。使用 IPsec 保护上层可以缓解这些攻击。

   ICMP 错误消息会信号处理互联网数据报期间遇到的网络错误条件。根据特定情景，被报告的错误条件可能或可能不会在近期得到解决。因此，对 ICMP 错误消息的反应可能不仅取决于错误类型和代码，还取决于其他因素，例如接收主机接收到错误消息的时间、先前对被报告的网络错误条件的了解，以及接收主机所操作的网络情景的了解。

6. IANA 考虑事项

6.1. 新 ICMPv6 类型和代码值分配程序

本文档中定义的 IPv6 ICMP 头包含以下字段，这些字段携带从 IANA 管理的名称空间分配的值：Type 和 Code。Code 字段的值是相对于特定的 Type 值定义的。

分配 IPv6 ICMP Type 字段的值使用以下流程：

1. IANA 应当从 IETF RFC 出版物中分配并永久注册新的 ICMPv6 类型代码。这适用于所有来源于 IETF 并已获得 IESG 批准出版的 RFC 类型，包括标准轨、信息性和实验性状态的 RFC。

2. 具有工作组共识和区域主任批准的 IETF 工作组可以向 IANA 请求可回收的 ICMPV6 类型代码分配。IANA 将标记这些值为“将来可回收”。
   “将来可回收”的标记将在出版记录该协议的 RFC 文档时被移除。这将使分配变为永久，并更新 IANA 网页上的参考资料。

   当 ICMPv6 类型值分配达到 85% 时，IETF 将审核标记为“将来可回收”的分配，并通知 IANA 应当回收和重新分配哪些值。

3. 外部请求分配新的 ICMPv6 类型值，只能通过发布 IETF 文档进行，遵循 1 中的规定。还要注意，“RFC 编辑器贡献” [RFC-3978] 不被视为 IETF 文档。

对于本文档中定义的 Type 值的新 Code 值的分配需要标准操作或 IESG 批准。对于在本文档中未定义的新 IPv6 ICMP 类型的 Code 值的分配政策应在定义新 Type 值的文档中进行定义。

6.2. 本文档的分配

下列内容位于更新的分配位置：

http://www.iana.org/assignments/icmpv6-parameters

IANA 已经重新分配了 ICMPv6 类型 1 “Destination Unreachable” 的代码 2，这在 [RFC-2463] 中尚未分配，分配给了:

     2 - 源地址范围之外

IANA 已经为 ICMPv6 类型 1 “Destination Unreachable” 分配了以下两个新代码值：

     5 - 源地址未通过进出策略
     6 - 拒绝到目的地的路由

IANA 已经分配了以下新的类型值：

     100  私有实验
     101  私有实验

     127  用于扩展 ICMPv6 错误消息

     200  私有实验
     201  私有实验
     255  用于扩展 ICMPv6 信息性消息

7. 参考资料

7.1. 规范性参考

[IPv6] Deering, S. 和 R. Hinden, “Internet Protocol, Version 6
(IPv6) Specification”, RFC 2460, 1998 年 12 月。

[IPv6-DISC] Narten, T., Nordmark, E., 和 W. Simpson, “Neighbor
Discovery for IP Version 6 (IPv6)”, RFC 2461, 1998 年 12 月。

[RFC-792] Postel, J., “Internet Control Message Protocol”, STD 5,
RFC 792, 1981 年 9 月。

[RFC-2463] Conta, A. 和 S. Deering, “Internet Control Message
Protocol (ICMPv6) for the Internet Protocol Version 6
(IPv6) Specification”, RFC 2463, 1998 年 12 月。

[RFC-1122] Braden, R., “Requirements for Internet Hosts -
Communication Layers”, STD 3, RFC 1122, 1989 年 10 月。

[RFC-2119] Bradner, S., “Key words for use in RFCs to Indicate
Requirement Levels”, BCP 14, RFC 2119, 1997 年 3 月。

[RFC-3978] Bradner, S., “IETF Rights in Contributions”, BCP 78, RFC
3978, 2005 年 3 月。

7.2. 信息性参考

[RFC-2780] Bradner, S. 和 V. Paxson, “IANA Allocation Guidelines
For Values In the Internet Protocol and Related
Headers”, BCP 37, RFC 2780, 2000 年 3 月。

[IPv6-ADDR] Hinden, R. 和 S. Deering, “Intpernet Protocol Version 6
(IPv6) Addressing Architecture”, RFC 3513, 2003 年 4 月。

[PMTU] McCann, J., Deering, S., 和 J. Mogul, “Path MTU
Discovery for IP version 6”, RFC 1981, 1996 年 8 月。

[IPv6-SA] Kent, S. 和 R. Atkinson, “Security Architecture for the
Internet Protocol”, RFC 2401, 1998 年 11 月。

[IPv6-AUTH] Kent, S., “IP Authentication Header”, RFC 4302, 2005 年
12 月。

[IPv6-ESP] Kent, S., “IP Encapsulating Security Payload (ESP)”, RFC
4203, 2005 年 12 月。

[SEC-ARCH] Kent, S. 和 K. Seo, “Security Architecture for the
Internet Protocol”, RFC 4301, 2005 年 12 月。

[TCP-attack] Gont, F., “ICMP attacks against TCP”, Work in Progress.

8. 致谢

本文档源自 SIPP 和 IPng 工作组之前的 ICMP 文档。

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 是本文档的编辑。

附录 A - 自 RFC 2463 以来的更改

以下是自 RFC 2463 以来所做的更改：

• 编辑了摘要，使其更为详尽。

• 在第 2.4 节中纠正了拼写错误，其中对子项目 e.2 的引用应该是 e.3。

• 从 ICMP 错误消息的示例限速机制中删除了基于定时器和基于带宽的方法。添加了基于令牌桶的方法。

• 增加了一个规范，即所有 ICMP 错误消息都应具有确切的 32 位类型特定数据，以便在接收者不认识 ICMP 消息类型时，它们仍然能够可靠地找到嵌入的调用数据包。

• 在目的地不可达消息的描述中，对于代码 3，增加了规则，禁止将数据包转发回到接收到它们的点对点链接，如果其目的地地址属于链接本身（“反跳回”规则）。

• 在时限已过代码 1（片段重组超时）的描述中进行了添加。

• 在“无法到达目的地”类型 ICMP 错误消息的系列中（第 3.1 节），增加了“超出源地址范围”，“源地址未通过入口/出口策略”，和“拒绝路由到目的地”的描述。

• 为实验保留了一些 ICMP 类型值。

• 在第 2.4 节添加了一条注释，指定了 ICMP 消息处理规则的优先级。

• 在第 2.4 节的消息不生成列表中添加了 ICMP 重定向。

• 在第 2.3 节的校验和计算以及第 5.2 节进行了一些编辑。

• 在回复消息（Echo Reply Message）的第 4.2 节进行了澄清；针对任播 Echo 请求，回复的源地址应该是一个单播地址，就像多播的情况一样。

• 对安全考虑部分进行了修订。增加了使用封装安全有效载荷头进行身份验证。将“不允许未经身份验证的 ICMP 消息”选项的要求从应当更改为可能。

• 在第 5.2 节的可能 ICMP 攻击列表中添加了一个新的攻击。

• 将参考文献分为规范性和信息性两部分。

• 添加了对 RFC 2780 “互联网协议及相关头部值的 IANA 分配准则”。还添加了一条说明，指出本文档更新了 RFC 2780。

• 在 IANA 考虑事项部分添加了新的 ICMPv6 类型和代码值分配程序。

• 将“发送”一词更改为“起源”，以明确指出本规范范围之外的转发 ICMP 数据包。

• 将 ESP 和 AH 的引用更改为更新后的 ESP 和 AH 文档。

• 添加了对更新后的 IPsec 安全架构文档的引用。

• 对允许发送 ICMP 目的地不可达消息的要求进行了 SHOULD 要求。

• 简化了 ICMPv6 数据包的源地址选择。

• 重新组织了一般消息格式（第 2.1 节）。

• 从第 2.1 节中删除了一般数据包格式。它现在引用第 3 和第 4 节的数据包格式。

• 添加了有关由 ICMP 引起的对传输协议的攻击的文本说明。