Network Working Group E. Davies
Request for Comments: 4890 Consultant
Category: Informational J. Mohacsi
NIIF/HUNGARNET
May 2007
Network Working Group E. Davies
Request for Comments: 4890 Consultant
Category: Informational J. Mohacsi
NIIF/HUNGARNET
May 2007
Recommendations for Filtering ICMPv6 Messages in Firewalls
在防火墙中过滤ICMPv6消息的建议
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
Abstract
摘要
In networks supporting IPv6, the Internet Control Message Protocol version 6 (ICMPv6) plays a fundamental role with a large number of functions, and a correspondingly large number of message types and options. ICMPv6 is essential to the functioning of IPv6, but there are a number of security risks associated with uncontrolled forwarding of ICMPv6 messages. Filtering strategies designed for the corresponding protocol, ICMP, in IPv4 networks are not directly applicable, because these strategies are intended to accommodate a useful auxiliary protocol that may not be required for correct functioning.
在支持IPv6的网络中，Internet控制消息协议版本6（ICMPv6）起着基础性作用，具有大量功能，相应地有大量消息类型和选项。ICMPv6对IPv6的功能至关重要，但不受控制地转发ICMPv6消息会带来许多安全风险。IPv4网络中为相应协议ICMP设计的过滤策略不直接适用，因为这些策略旨在容纳一个有用的辅助协议，而这些协议可能不需要正常运行。
This document provides some recommendations for ICMPv6 firewall filter configuration that will allow propagation of ICMPv6 messages that are needed to maintain the functioning of the network but drop messages that are potential security risks.
本文档提供了有关ICMPv6防火墙筛选器配置的一些建议，这些配置将允许传播维护网络功能所需的ICMPv6消息，但会删除具有潜在安全风险的消息。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Classifying ICMPv6 Messages . . . . . . . . . . . . . . . . . 6
2.1. Error and Informational ICMPv6 Messages . . . . . . . . . 6
2.2. Addressing of ICMPv6 . . . . . . . . . . . . . . . . . . . 6
2.3. Network Topology and Address Scopes . . . . . . . . . . . 7
2.4. Role in Establishing and Maintaining Communication . . . . 7
3. Security Considerations . . . . . . . . . . . . . . . . . . . 8
3.1. Denial-of-Service Attacks . . . . . . . . . . . . . . . . 9
3.2. Probing . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.3. Redirection Attacks . . . . . . . . . . . . . . . . . . . . 9
3.4. Renumbering Attacks . . . . . . . . . . . . . . . . . . . 10
3.5. Problems Resulting from ICMPv6 Transparency . . . . . . . 10
4. Filtering Recommendations . . . . . . . . . . . . . . . . . . 10
4.1. Common Considerations . . . . . . . . . . . . . . . . . . 11
4.2. Interaction of Link-Local Messages with
Firewall/Routers and Firewall/Bridges . . . . . . . . . . 12
4.3. Recommendations for ICMPv6 Transit Traffic . . . . . . . . 13
4.3.1. Traffic That Must Not Be Dropped . . . . . . . . . . . 14
4.3.2. Traffic That Normally Should Not Be Dropped . . . . . 14
4.3.3. Traffic That Will Be Dropped Anyway -- No Special
Attention Needed . . . . . . . . . . . . . . . . . . . 15
4.3.4. Traffic for Which a Policy Should Be Defined . . . . . 16
4.3.5. Traffic That Should Be Dropped Unless a Good Case
Can Be Made . . . . . . . . . . . . . . . . . . . . . 17
4.4. Recommendations for ICMPv6 Local Configuration Traffic . . 18
4.4.1. Traffic That Must Not Be Dropped . . . . . . . . . . . 18
4.4.2. Traffic That Normally Should Not Be Dropped . . . . . 19
4.4.3. Traffic That Will Be Dropped Anyway -- No Special
Attention Needed . . . . . . . . . . . . . . . . . . . 19
4.4.4. Traffic for Which a Policy Should Be Defined . . . . . 20
4.4.5. Traffic That Should Be Dropped Unless a Good Case
Can Be Made . . . . . . . . . . . . . . . . . . . . . 21
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
6.1. Normative References . . . . . . . . . . . . . . . . . . . 21
6.2. Informative References . . . . . . . . . . . . . . . . . . 22
Appendix A. Notes on Individual ICMPv6 Messages . . . . . . . . . 24
A.1. Destination Unreachable Error Message . . . . . . . . . . 24
A.2. Packet Too Big Error Message . . . . . . . . . . . . . . . 24
A.3. Time Exceeded Error Message . . . . . . . . . . . . . . . 25
A.4. Parameter Problem Error Message . . . . . . . . . . . . . 25
A.5. ICMPv6 Echo Request and Echo Response . . . . . . . . . . 26
A.6. Neighbor Solicitation and Neighbor Advertisement
Messages . . . . . . . . . . . . . . . . . . . . . . . . . 26
A.7. Router Solicitation and Router Advertisement Messages . . 27
A.8. Redirect Messages . . . . . . . . . . . . . . . . . . . . 27
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Classifying ICMPv6 Messages . . . . . . . . . . . . . . . . . 6
2.1. Error and Informational ICMPv6 Messages . . . . . . . . . 6
2.2. Addressing of ICMPv6 . . . . . . . . . . . . . . . . . . . 6
2.3. Network Topology and Address Scopes . . . . . . . . . . . 7
2.4. Role in Establishing and Maintaining Communication . . . . 7
3. Security Considerations . . . . . . . . . . . . . . . . . . . 8
3.1. Denial-of-Service Attacks . . . . . . . . . . . . . . . . 9
3.2. Probing . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.3. Redirection Attacks . . . . . . . . . . . . . . . . . . . . 9
3.4. Renumbering Attacks . . . . . . . . . . . . . . . . . . . 10
3.5. Problems Resulting from ICMPv6 Transparency . . . . . . . 10
4. Filtering Recommendations . . . . . . . . . . . . . . . . . . 10
4.1. Common Considerations . . . . . . . . . . . . . . . . . . 11
4.2. Interaction of Link-Local Messages with
Firewall/Routers and Firewall/Bridges . . . . . . . . . . 12
4.3. Recommendations for ICMPv6 Transit Traffic . . . . . . . . 13
4.3.1. Traffic That Must Not Be Dropped . . . . . . . . . . . 14
4.3.2. Traffic That Normally Should Not Be Dropped . . . . . 14
4.3.3. Traffic That Will Be Dropped Anyway -- No Special
Attention Needed . . . . . . . . . . . . . . . . . . . 15
4.3.4. Traffic for Which a Policy Should Be Defined . . . . . 16
4.3.5. Traffic That Should Be Dropped Unless a Good Case
Can Be Made . . . . . . . . . . . . . . . . . . . . . 17
4.4. Recommendations for ICMPv6 Local Configuration Traffic . . 18
4.4.1. Traffic That Must Not Be Dropped . . . . . . . . . . . 18
4.4.2. Traffic That Normally Should Not Be Dropped . . . . . 19
4.4.3. Traffic That Will Be Dropped Anyway -- No Special
Attention Needed . . . . . . . . . . . . . . . . . . . 19
4.4.4. Traffic for Which a Policy Should Be Defined . . . . . 20
4.4.5. Traffic That Should Be Dropped Unless a Good Case
Can Be Made . . . . . . . . . . . . . . . . . . . . . 21
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
6.1. Normative References . . . . . . . . . . . . . . . . . . . 21
6.2. Informative References . . . . . . . . . . . . . . . . . . 22
Appendix A. Notes on Individual ICMPv6 Messages . . . . . . . . . 24
A.1. Destination Unreachable Error Message . . . . . . . . . . 24
A.2. Packet Too Big Error Message . . . . . . . . . . . . . . . 24
A.3. Time Exceeded Error Message . . . . . . . . . . . . . . . 25
A.4. Parameter Problem Error Message . . . . . . . . . . . . . 25
A.5. ICMPv6 Echo Request and Echo Response . . . . . . . . . . 26
A.6. Neighbor Solicitation and Neighbor Advertisement
Messages . . . . . . . . . . . . . . . . . . . . . . . . . 26
A.7. Router Solicitation and Router Advertisement Messages . . 27
A.8. Redirect Messages . . . . . . . . . . . . . . . . . . . . 27
A.9. SEND Certificate Path Messages . . . . . . . . . . . . . . 27
A.10. Multicast Listener Discovery Messages . . . . . . . . . . 27
A.11. Multicast Router Discovery Messages . . . . . . . . . . . 28
A.12. Router Renumbering Messages . . . . . . . . . . . . . . . 28
A.13. Node Information Query and Reply . . . . . . . . . . . . . 28
A.14. Mobile IPv6 Messages . . . . . . . . . . . . . . . . . . . 28
A.15. Unused and Experimental Messages . . . . . . . . . . . . . 29
Appendix B. Example Script to Configure ICMPv6 Firewall Rules . . 30
A.9. SEND Certificate Path Messages . . . . . . . . . . . . . . 27
A.10. Multicast Listener Discovery Messages . . . . . . . . . . 27
A.11. Multicast Router Discovery Messages . . . . . . . . . . . 28
A.12. Router Renumbering Messages . . . . . . . . . . . . . . . 28
A.13. Node Information Query and Reply . . . . . . . . . . . . . 28
A.14. Mobile IPv6 Messages . . . . . . . . . . . . . . . . . . . 28
A.15. Unused and Experimental Messages . . . . . . . . . . . . . 29
Appendix B. Example Script to Configure ICMPv6 Firewall Rules . . 30
When a network supports IPv6 [RFC2460], the Internet Control Message Protocol version 6 (ICMPv6) [RFC4443] plays a fundamental role including being an essential component in establishing and maintaining communications both at the interface level and for sessions to remote nodes. This means that overly aggressive filtering of ICMPv6 by firewalls may have a detrimental effect on the establishment and maintenance of IPv6 communications. On the other hand, allowing indiscriminate passage of all ICMPv6 messages can be a major security risk. This document recommends a set of rules that seek to balance effective IPv6 communication against the needs of site security.
当网络支持IPv6[RFC2460]时，Internet控制消息协议版本6（ICMPv6）[RFC4443]起着基本作用，包括在接口级和远程节点会话中作为建立和维护通信的基本组件。这意味着防火墙对ICMPv6的过度积极过滤可能会对IPv6通信的建立和维护产生不利影响。另一方面，允许任意传递所有ICMPv6消息可能是一个重大的安全风险。本文档推荐了一套规则，旨在平衡有效的IPv6通信与站点安全需求。
In a few cases, the appropriate rules will depend on whether the firewall is protecting
在少数情况下，适当的规则将取决于防火墙是否正在保护
o an individual host,
o 一个单独的主持人，
o an end site where all ICMPv6 messages originate or terminate within the site, or
o 所有ICMPv6消息在站点内发起或终止的终端站点，或
o a transit site such as an Internet Service Provider's site where some ICMPv6 messages will be passing through.
o 一些ICMPv6消息将通过的中转站点，如Internet服务提供商的站点。
The document suggests alternative rules appropriate to each situation where it is relevant. It also notes some situations where alternative rules could be adopted according to the nature of the work being carried out on the site and consequent security policies. In general, Internet Service Providers should not filter ICMPv6 messages transiting their sites so that all the necessary communication elements are available to their customers to decide and filter according to their policy.
该文件建议了适用于每种相关情况的替代规则。它还注意到，在某些情况下，可以根据现场正在进行的工作的性质和随后的安全政策，采用替代规则。一般来说，互联网服务提供商不应过滤通过其网站的ICMPv6消息，以便其客户能够根据其策略决定和过滤所有必要的通信元素。
Readers familiar with ICMPv6 can skip to the recommended filtering rules in Section 4 and an example configuration script for Linux Netfilter in Appendix B.
熟悉ICMPv6的读者可以跳到第4节中推荐的过滤规则和附录B中Linux Netfilter的示例配置脚本。
ICMPv6 has a large number of functions defined in a number of sub-protocols, and there are a correspondingly large number of messages and options within these messages. The functions currently defined fall into a number of categories:
ICMPv6在许多子协议中定义了大量功能，并且在这些消息中有相应大量的消息和选项。当前定义的功能分为若干类别：
Returning Error Messages
返回错误消息
* Returning error messages to the source if a packet could not be delivered. Four different error messages, each with a number of sub-types, are specified in [RFC4443].
* 如果无法传递数据包，则向源返回错误消息。[RFC4443]中规定了四种不同的错误消息，每种错误消息都有若干子类型。
Connection Checking
连接检查
* Simple monitoring of connectivity through echo requests and responses used by the ping and traceroute utilities. The Echo Request and Echo Response messages are specified in [RFC4443].
* 通过ping和traceroute实用程序使用的回显请求和响应对连接进行简单监控。[RFC4443]中规定了回显请求和回显响应消息。
Discovery Functions
发现功能
* Finding neighbors (both routers and hosts) connected to the same link and determining their IP and link layer addresses. These messages are also used to check the uniqueness of any addresses that an interface proposes to use (Duplicate Address Detection - DAD). Four messages -- Neighbor Solicitation (NS), Neighbor Advertisement (NA), Router Solicitation (RS) and Router Advertisement (RA) -- are specified in [RFC2461].
* 查找连接到同一链路的邻居（路由器和主机），并确定其IP和链路层地址。这些消息还用于检查接口建议使用的任何地址的唯一性（重复地址检测-DAD）。[RFC2461]中规定了四条消息——邻居请求（NS）、邻居公告（NA）、路由器请求（RS）和路由器公告（RA）。
* Ensuring that neighbors remain reachable using the same IP and link layer addresses after initial discovery (Neighbor Unreachability Discovery - NUD) and notifying neighbors of changes to link layer addresses. Uses NS and NA [RFC2461].
* 确保在初始发现（邻居不可访问性发现-NUD）后，使用相同的IP和链路层地址仍然可以访问邻居，并通知邻居链路层地址的更改。使用NS和NA[RFC2461]。
* Finding routers and determining how to obtain IP addresses to join the subnets supported by the routers. Uses RS and RA [RFC2461].
* 查找路由器并确定如何获取IP地址以加入路由器支持的子网。使用RS和RA[RFC2461]。
* If stateless autoconfiguration of hosts is enabled, communicating prefixes and other configuration information (including the link Maximum Transmission Unit (MTU) and suggested hop limit default) from routers to hosts. Uses RS and RA [RFC2462].
* 如果启用了主机的无状态自动配置，则将前缀和其他配置信息（包括链路最大传输单元（MTU）和建议的跃点限制默认值）从路由器传送到主机。使用RS和RA[RFC2462]。
* When using SEcure Neighbor Discovery (SEND) to authenticate a router attached to a link, the Certificate Path Solicitation and Advertisement messages specified in [RFC3971] are used by hosts to retrieve the certificates
* 当使用安全邻居发现（SEND）对连接到链路的路由器进行身份验证时，[RFC3971]中指定的证书路径请求和播发消息被主机用于检索证书
documenting the trust chain between a trust anchor and the router from the router.
记录信任锚点和路由器之间的信任链。
* Determining the MTU along a path. The Packet Too Big error message is essential to this function [RFC1981].
* 确定沿路径的MTU。数据包过大错误消息对于此功能至关重要[RFC1981]。
* Providing a means to discover the IPv6 addresses associated with the link layer address of an interface (the inverse of Neighbor Discovery, where the link layer address is
* 提供一种方法来发现与接口的链路层地址相关联的IPv6地址（与邻居发现相反，其中链路层地址为
discovered given an IPv6 address). Two messages, Inverse Neighbor Discovery Solicitation and Advertisement messages, are specified in [RFC3122].
已发现（给定IPv6地址）。[RFC3122]中指定了两条消息，反向邻居发现请求和广告消息。
* Communicating which multicast groups have listeners on a link to the multicast capable routers connected to the link. Uses messages Multicast Listener Query, Multicast Listener Report (two versions), and Multicast Listener Done (protocol version 1 only) as specified in Multicast Listener Discovery MLDv1 [RFC2710] and MLDv2 [RFC3810].
* 将链路上具有侦听器的多播组与连接到该链路的支持多播的路由器进行通信。按照多播侦听器发现MLDv1[RFC2710]和MLDv2[RFC3810]中的指定，使用消息多播侦听器查询、多播侦听器报告（两个版本）和多播侦听器完成（仅协议版本1）。
* Discovering multicast routers attached to the local link. Uses messages Multicast Router Advertisement, Multicast Router Solicitation, and Multicast Router Termination as specified in Multicast Router Discovery [RFC4286].
* 发现连接到本地链路的多播路由器。按照多播路由器发现[RFC4286]中的规定，使用消息多播路由器播发、多播路由器请求和多播路由器终止。
Reconfiguration Functions
重构功能
* Redirecting packets to a more appropriate router on the local link for the destination address or pointing out that a destination is actually on the local link even if it is not obvious from the IP address (where a link supports multiple subnets). The Redirect message is specified in [RFC2461].
* 将数据包重定向到本地链路上更合适的路由器以获得目标地址，或指出目标实际上位于本地链路上，即使从IP地址看不明显（链路支持多个子网）。重定向消息在[RFC2461]中指定。
* Supporting renumbering of networks by allowing the prefixes advertised by routers to be altered. Uses NS, NA, RS and RA together with the Router Renumbering message specified in [RFC2894].
* 通过允许更改路由器公布的前缀，支持网络重新编号。使用NS、NA、RS和RA以及[RFC2894]中指定的路由器重新编号消息。
Mobile IPv6 Support
移动IPv6支持
* Providing support for some aspects of Mobile IPv6 especially dealing with the IPv6 Mobile Home Agent functionality provided in routers and needed to support a Mobile node homed on the link. The Home Agent Address Discovery Request and Reply and the Mobile Prefix Solicitation and Advertisement messages are specified in [RFC3775].
* 为移动IPv6的某些方面提供支持，特别是处理路由器中提供的IPv6移动归属代理功能，以及支持位于链路上的移动节点所需的功能。[RFC3775]中规定了归属代理地址发现请求和回复以及移动前缀请求和广告消息。
Experimental Extensions
实验扩展
* An experimental extension to ICMPv6 specifies the ICMP Node Information Query and Response messages that can be used to retrieve some basic information about nodes [RFC4620].
* ICMPv6的一个实验性扩展指定了ICMP节点信息查询和响应消息，可用于检索有关节点的一些基本信息[RFC4620]。
* The SEAmless IP MOBility (SEAMOBY) working group specified a pair of experimental protocols that use an ICMPv6 message specified in [RFC4065] to help in locating an access router and moving the attachment point of a mobile node from one access router to another.
* 无缝IP移动（SEAMOBY）工作组指定了一对实验协议，使用[RFC4065]中指定的ICMPv6消息来帮助定位接入路由器并将移动节点的连接点从一个接入路由器移动到另一个接入路由器。
Many of these messages should only be used in a link-local context rather than end-to-end, and filters need to be concerned with the type of addresses in ICMPv6 packets as well as the specific source and destination addresses.
其中许多消息应仅在链路本地上下文中使用，而不是端到端，并且筛选器需要关注ICMPv6数据包中的地址类型以及特定的源地址和目标地址。
Compared with the corresponding IPv4 protocol, ICMP, ICMPv6 cannot be treated as an auxiliary function with packets that can be dropped in most cases without damaging the functionality of the network. This means that firewall filters for ICMPv6 have to be more carefully configured than was the case for ICMP, where typically a small set of blanket rules could be applied.
与相应的IPv4协议ICMP、ICMPv6相比，ICMP、ICMPv6不能被视为具有数据包的辅助功能，在大多数情况下，这些数据包可以在不损害网络功能的情况下丢弃。这意味着ICMPv6的防火墙过滤器必须比ICMP更仔细地配置，因为ICMP通常可以应用一小部分一揽子规则。
ICMPv6 messages contain an eight-bit Type field interpreted as an integer between 0 and 255. Messages with Type values less than or equal to 127 are Error messages. The remainder are Informational messages. In general terms, Error messages with well-known (standardized) Type values would normally be expected to be allowed to be sent to or pass through firewalls, and may be essential to the establishment and maintenance of communications (see Section 2.4) whereas Informational messages will generally be the subject of policy rules, and those passing through end site firewalls can, in many but by no means all cases, be dropped without damaging IPv6 communications.
ICMPv6消息包含一个解释为0到255之间的整数的八位类型字段。类型值小于或等于127的消息是错误消息。其余的是信息性消息。一般来说，具有已知（标准化）类型值的错误消息通常被允许发送到防火墙或通过防火墙，并且可能对通信的建立和维护至关重要（见第2.4节），而信息消息通常是政策规则的主题，在许多情况下，但并非所有情况下，通过终端站点防火墙的用户都可以在不破坏IPv6通信的情况下被丢弃。
ICMPv6 messages are sent using various kinds of source and destination address types and scopes. The source address is usually a unicast address, but during address autoconfiguration message exchanges, the unspecified address (::) is also used as a source address [RFC2462].
ICMPv6消息使用各种源和目标地址类型和作用域发送。源地址通常是单播地址，但在地址自动配置消息交换期间，未指定的地址（：：）也用作源地址[RFC2462]。
Multicast Listener Discovery (MLD) Report and Done messages are sent with a link-local address as the IPv6 source address, if a valid address is available on the interface. If a valid link-local address is not available (e.g., one has not been configured), the message is sent with the unspecified address (::) as the IPv6 source address. Subsequently, the node will generate new MLD Report messages with proper link-local source address once it has been configured [RFC3590].
如果接口上有有效地址，则发送多播侦听器发现（MLD）报告和完成消息时，会使用链接本地地址作为IPv6源地址。如果有效的链路本地地址不可用（例如，尚未配置一个），则发送消息时会使用未指定的地址（：：）作为IPv6源地址。随后，一旦配置完成，节点将生成具有正确链路本地源地址的新MLD报告消息[RFC3590]。
The destination address can be either a well-known multicast address, a generated multicast address such as the solicited-node multicast address, an anycast address, or a unicast address. While many ICMPv6 messages use multicast addresses most of the time, some also use unicast addresses. For instance, the Router Advertisement messages are sent to the all-nodes multicast address when unsolicited, but can also be sent to a unicast address in response to a specific Router Solicitation, although this is rarely seen in current implementations.
目的地地址可以是众所周知的多播地址、生成的多播地址（例如请求的节点多播地址）、选播地址或单播地址。虽然许多ICMPv6消息大部分时间使用多播地址，但有些消息也使用单播地址。例如，路由器广告消息在未经请求时被发送到所有节点多播地址，但是也可以被发送到单播地址以响应特定的路由器请求，尽管这在当前实现中很少见到。
ICMPv6 messages can be classified according to whether they are meant for end-to-end communications or local communications within a link. There are also messages that we can classify as 'any-to-end', which can be sent from any point within a path back to the source; typically, these are used to announce an error in processing the original packet. For instance, the address resolution messages are solely for local communications [RFC2461], whereas the Destination Unreachable messages are any-to-end in nature. Generally, end-to-end and any-to-end messages might be expected to pass through firewalls depending on policies but local communications must not.
ICMPv6消息可根据其是用于端到端通信还是链路内的本地通信进行分类。还有一些消息，我们可以归类为“any to end”，可以从路径中的任何点发送回源；通常，它们用于宣布处理原始数据包时的错误。例如，地址解析消息仅用于本地通信[RFC2461]，而目的地不可到达消息本质上是任意结束的。通常，端到端和任意端到端消息可能会通过防火墙，具体取决于策略，但本地通信不能。
Local communications will use link-local addresses in many cases but may also use global unicast addresses when configuring global addresses, for example. Also, some ICMPv6 messages used in local communications may contravene the usual rules requiring compatible scopes for source and destination addresses.
在许多情况下，本地通信将使用链路本地地址，但在配置全局地址时也可能使用全局单播地址。此外，在本地通信中使用的某些ICMPv6消息可能会违反要求源地址和目标地址具有兼容作用域的常规规则。
Many ICMPv6 messages have a role in establishing or maintaining communications to and from the firewall and such messages have to be accepted by firewalls for local delivery. Generally, a firewall will also be acting as a router so that all the messages that might be used in configuring a router interface need to be accepted and generated. These messages should not transit through a firewall that is also acting as a router as they are normally intended for use within a link.
许多ICMPv6消息在建立或维护与防火墙之间的通信方面起着作用，防火墙必须接受这些消息以进行本地传递。一般来说，防火墙也将充当路由器，因此需要接受和生成配置路由器接口时可能使用的所有消息。这些消息不应通过防火墙传输，防火墙也充当路由器，因为它们通常用于链路中。
On the other hand, most ICMPv6 error messages traveling end-to-end or any-to-end are essential to the establishment and maintenance of communications. These messages must be passed through firewalls and might also be sent to and from firewalls to assist with establishment and maintenance of communications. For example, the Packet Too Big error message is needed to determine the MTU along a path both when a communication session is established initially and later if the path is rerouted during the session.
另一方面，大多数端到端或任意端传输的ICMPv6错误消息对于建立和维护通信至关重要。这些消息必须通过防火墙传递，也可以发送到防火墙或从防火墙发送，以帮助建立和维护通信。例如，在最初建立通信会话时以及在会话期间重新路由路径时，都需要分组过大错误消息来确定沿路径的MTU。
The remaining ICMPv6 messages that are not associated with communication establishment or maintenance will normally be legitimately attempting to pass through a firewall from inside to out or vice versa, but in most cases decisions as to whether or not to allow them to pass can be made on the basis of local policy without interfering with IPv6 communications.
与通信建立或维护无关的其余ICMPv6消息通常会合法地尝试从内到外通过防火墙，反之亦然，但在大多数情况下，关于是否允许它们通过的决定可以根据本地政策做出，而不会干扰IPv6通信。
The filtering rules for the various message roles will generally be different.
不同消息角色的过滤规则通常会有所不同。
This memo recommends filtering configurations for firewalls designed to minimize the security vulnerabilities that can arise in using the many different sub-protocols of ICMPv6 in support of IPv6 communication.
本备忘录建议对防火墙进行过滤配置，以最大限度地减少在使用ICMPv6的许多不同子协议支持IPv6通信时可能出现的安全漏洞。
A major concern is that it is generally not possible to use IPsec or other means to authenticate the sender and validate the contents of many ICMPv6 messages. To a large extent, this is because a site can legitimately expect to receive certain error and other messages from almost any location in the wider Internet, and these messages may occur as a result of the first message sent to a destination. Establishing security associations with all possible sources of ICMPv6 messages is therefore impossible.
一个主要问题是，通常不可能使用IPsec或其他方法来验证发送方身份并验证许多ICMPv6消息的内容。在很大程度上，这是因为一个站点可以合理地期望从更广泛的互联网中的几乎任何位置接收某些错误和其他消息，而这些消息可能是发送到目的地的第一条消息的结果。因此，不可能与所有可能的ICMPv6消息源建立安全关联。
The inability to establish security associations to protect some messages that are needed to establish and maintain communications means that alternative means have to be used to reduce the vulnerability of sites to ICMPv6-based attacks. The most common way of doing this is to establish strict filtering policies in site firewalls to limit the unauthenticated ICMPv6 messages that can pass between the site and the wider Internet. This makes control of ICMPv6 filtering a delicate balance between protecting the site by dropping some of the ICMPv6 traffic passing through the firewall and allowing enough of the traffic through to make sure that efficient communication can be established.
无法建立安全关联来保护建立和维护通信所需的某些消息，这意味着必须使用替代手段来降低站点对基于ICMPv6的攻击的脆弱性。最常见的方法是在站点防火墙中建立严格的过滤策略，以限制未经验证的ICMPv6消息在站点和更广泛的Internet之间传递。这使得对ICMPv6过滤的控制在通过丢弃一些通过防火墙的ICMPv6流量来保护站点和允许足够的流量通过以确保建立有效通信之间取得了微妙的平衡。
SEND [RFC3971] has been specified as a means to improve the security of local ICMPv6 communications. SEND sidesteps security association bootstrapping problems that would result if IPsec was used. SEND affects only link-local messages and does not limit the filtering that firewalls can apply, and its role in security is therefore not discussed further in this document.
已将发送[RFC3971]指定为提高本地ICMPv6通信安全性的一种方法。发送sidesteps安全关联引导问题，如果使用IPsec将导致这些问题。SEND只影响链接本地消息，不限制防火墙可以应用的过滤，因此本文档不再进一步讨论它在安全性中的作用。
Firewalls will normally be used to monitor ICMPv6 to control the following security concerns:
防火墙通常用于监控ICMPv6，以控制以下安全问题：
ICMPv6 can be used to cause a denial of service (DoS) in a number of ways, including simply sending excessive numbers of ICMPv6 packets to destinations in the site and sending error messages that disrupt established communications by causing sessions to be dropped. Also, if spurious communication establishment or maintenance messages can be infiltrated onto a link, it might be possible to invalidate legitimate addresses or disable interfaces.
ICMPv6可用于以多种方式造成拒绝服务（DoS），包括简单地向站点中的目的地发送过多的ICMPv6数据包，以及发送错误消息，导致会话中断，从而中断已建立的通信。此外，如果虚假的通信建立或维护消息可以渗透到链路上，则可能使合法地址无效或禁用接口。
A major security consideration is preventing attackers from probing the site to determine the topology and identify hosts that might be vulnerable to attack. Carefully crafted but, often, malformed messages can be used to provoke ICMPv6 responses from hosts thereby informing attackers of potential targets for future attacks. However, the very large address space of IPv6 makes probing a less effective weapon as compared with IPv4 provided that addresses are not allocated in an easily guessable fashion. This subject is explored in more depth in [SCAN-IMP].
一个主要的安全考虑是防止攻击者探测站点以确定拓扑并识别可能易受攻击的主机。精心编制但通常格式错误的消息可用于激发主机的ICMPv6响应，从而通知攻击者未来攻击的潜在目标。然而，与IPv4相比，IPv6非常大的地址空间使得探测成为一种效率较低的武器，前提是地址分配方式不易猜测。[SCAN-IMP]对该主题进行了更深入的探讨。
A redirection attack could be used by a malicious sender to perform man-in-the-middle attacks or divert packets either to a malicious monitor or to cause DoS by blackholing the packets. These attacks would normally have to be carried out locally on a link using the Redirect message. Administrators need to decide if the improvement in efficiency from using Redirect messages is worth the risk of malicious use. Factors to consider include the physical security of the link and the complexity of addressing on the link. For example, on an open wireless link, redirection would be a serious hazard due to the lack of physical security. On the other hand, with a wired link in a secure building with complex addressing and redundant routers, the efficiency gains might well outweigh the small risk of a rogue node being connected.
恶意发送方可以使用重定向攻击来执行中间人攻击，或将数据包转移到恶意监视器，或通过对数据包进行黑洞来造成拒绝服务。这些攻击通常必须使用重定向消息在本地链路上执行。管理员需要决定是否值得冒恶意使用的风险来提高使用重定向消息的效率。考虑的因素包括链路的物理安全性和链路上寻址的复杂性。例如，在开放的无线链路上，由于缺乏物理安全性，重定向将是一种严重的危险。另一方面，在具有复杂寻址和冗余路由器的安全建筑中使用有线链路，效率的提高可能远远超过连接恶意节点的小风险。
Spurious Renumbering messages can lead to the disruption of a site. Although Renumbering messages are required to be authenticated with IPsec, so that it is difficult to carry out such attacks in practice, they should not be allowed through a site boundary firewall. On the other hand, a site may employ multiple "layers" of firewalls. In this case, Renumbering messages might be expected to be allowed to transit interior firewalls but not pass across the outer boundary.
虚假的重新编号消息可能会导致站点中断。尽管重新编号的消息需要通过IPsec验证，因此在实践中很难执行此类攻击，但不应允许它们通过站点边界防火墙。另一方面，站点可以使用多个“层”防火墙。在这种情况下，重新编号的消息可能会被允许通过内部防火墙，但不会通过外部边界。
Because some ICMPv6 error packets need to be passed through a firewall in both directions, malicious users can potentially use these messages to communicate between inside and outside, bypassing administrative inspection. For example, it might be possible to carry out a covert conversation through the payload of ICMPv6 error messages or tunnel inappropriate encapsulated IP packets in ICMPv6 error messages. This problem can be alleviated by filtering ICMPv6 errors using a deep packet inspection mechanism to ensure that the packet carried as a payload is associated with legitimate traffic to or from the protected network.
由于某些ICMPv6错误数据包需要双向通过防火墙，恶意用户可能会绕过管理检查，利用这些消息在内部和外部进行通信。例如，可以通过ICMPv6错误消息的有效负载或在ICMPv6错误消息中隧道封装不适当的IP数据包来执行隐蔽对话。通过使用深度数据包检查机制过滤ICMPv6错误，以确保作为有效负载携带的数据包与进出受保护网络的合法流量相关联，可以缓解此问题。
When designing firewall filtering rules for ICMPv6, the rules can be divided into two classes:
在为ICMPv6设计防火墙过滤规则时，这些规则可分为两类：
o Rules for ICMPv6 traffic transiting the firewall, with some minor variations for
o 通过防火墙的ICMPv6流量规则，对于
* firewalls protecting end sites or individual hosts, and
* 保护终端站点或单个主机的防火墙，以及
* firewalls protecting transit sites
* 保护过境点的防火墙
o Rules for ICMPv6 directed to interfaces on the firewall
o 定向到防火墙上接口的ICMPv6规则
Firewalls integrated with an individual host ("end host firewalls") can be treated as end site firewalls, but the special considerations discussed in Section 4.2 may be relevant because the firewall is not a router.
与单个主机集成的防火墙（“终端主机防火墙”）可被视为终端站点防火墙，但第4.2节中讨论的特殊注意事项可能是相关的，因为防火墙不是路由器。
This section suggests some common considerations that should be borne in mind when designing filtering rules and then categorizes the rules for each class. The categories are:
本节建议在设计过滤规则时应牢记的一些常见注意事项，然后对每个类的规则进行分类。这些类别包括：
o Messages that must not be dropped: usually because establishment or maintenance of communications will be prevented or severely impacted.
o 不得丢弃的消息：通常是因为通信的建立或维护将被阻止或严重影响。
o Messages that should not be dropped: administrators need to have a very good reason for dropping this category.
o 不应删除的邮件：管理员需要有一个很好的理由删除此类邮件。
o Messages that may be dropped in firewall/routers, but these messages may already be targeted to drop for other reasons (e.g., because they are using link-local addresses) or because the protocol specification would cause the messages to be rejected if they had passed through a router. Special considerations apply to transit traffic if the firewall is not a router as discussed in Section 4.2.
o 可能在防火墙/路由器中丢弃的消息，但这些消息可能由于其他原因（例如，因为它们正在使用链路本地地址）或因为协议规范会导致消息在通过路由器时被拒绝，而已经成为丢弃的目标。如果防火墙不是第4.2节中讨论的路由器，则特殊注意事项适用于传输流量。
o Messages that administrators may or may not want to drop depending on local policy.
o 管理员可能希望或不希望删除的邮件取决于本地策略。
o Messages that administrators should consider dropping (e.g., ICMP node information name lookup queries).
o 管理员应该考虑删除的消息（例如，ICMP节点信息名称查找查询）。
More detailed analysis of each of the message types can be found in Appendix A.
有关每种消息类型的更详细分析，请参见附录A。
Depending on the classification of the message to be filtered (see Section 2), ICMPv6 messages should be filtered based on the ICMPv6 type of the message and the type (unicast, multicast, etc.) and scope (link-local, global unicast, etc.) of source and destination addresses. In some cases, it may be desirable to filter on the Code field of ICMPv6 error messages.
根据要过滤的消息的分类（见第2节），应根据消息的ICMPv6类型以及源地址和目标地址的类型（单播、多播等）和范围（链路本地、全局单播等）过滤ICMPv6消息。在某些情况下，可能需要对ICMPv6错误消息的代码字段进行过滤。
Messages that can be authenticated on delivery, probably because they contain an IPsec AH header or ESP header with authentication, may be subject to less strict policies than messages that cannot be authenticated. In the remainder of this section, we are generally considering what should be configured for unauthenticated messages. In many cases, it is not realistic to expect more than a tiny fraction of the messages to be authenticated.
可以在传递时进行身份验证的消息（可能是因为它们包含具有身份验证的IPsec AH头或ESP头）可能受比无法进行身份验证的消息更严格的策略约束。在本节的其余部分中，我们通常会考虑为未经身份验证的消息配置什么。在许多情况下，期望超过一小部分的消息经过身份验证是不现实的。
Where messages are not essential to the establishment or maintenance of communications, local policy can be used to determine whether a message should be allowed or dropped.
如果消息对于通信的建立或维护不是必需的，则可以使用本地策略来确定是否允许或删除消息。
Depending on the capabilities of the firewall being configured, it may be possible for the firewall to maintain state about packets that may result in error messages being returned or about ICMPv6 packets (e.g., Echo Requests) that are expected to receive a specific response. This state may allow the firewall to perform more precise checks based on this state, and to apply limits on the number of ICMPv6 packets accepted incoming or outgoing as a result of a packet traveling in the opposite direction. The capabilities of firewalls to perform such stateful packet inspection vary from model to model, and it is not assumed that firewalls are uniformly capable in this respect.
根据正在配置的防火墙的功能，防火墙可能会保持关于可能导致返回错误消息的数据包或关于预期接收特定响应的ICMPv6数据包（例如，回显请求）的状态。此状态可允许防火墙基于此状态执行更精确的检查，并对因数据包向相反方向移动而接收的传入或传出ICMPv6数据包的数量施加限制。防火墙执行这种有状态数据包检查的能力因模型而异，并且并不假定防火墙在这方面的能力是一致的。
Firewalls that are able to perform deep packet inspection may be able to check the header fields in the start of the errored packet that is carried by ICMPv6 error messages. If the embedded packet has a source address that does not match the destination of the error message, the packet can be dropped. This provides a partial defense against some possible attacks on TCP that use spoofed ICMPv6 error messages, but the checks can also be carried out at the destination. For further information on these attacks see [ICMP-ATTACKS].
能够执行深度数据包检查的防火墙可能能够检查ICMPv6错误消息携带的错误数据包开头的报头字段。如果嵌入式数据包的源地址与错误消息的目的地不匹配，则可以丢弃该数据包。这提供了对TCP的部分防御，这些攻击可能使用伪造的ICMPv6错误消息，但也可以在目的地执行检查。有关这些攻击的更多信息，请参阅[ICMP-attacks]。
In general, the scopes of source and destination addresses of ICMPv6 messages should be matched, and packets with mismatched addresses should be dropped if they attempt to transit a router. However, some of the address configuration messages carried locally on a link may legitimately have mismatched addresses. Node implementations must accept these messages delivered locally on a link, and administrators should be aware that they can exist.
一般来说，ICMPv6消息的源地址和目标地址的范围应该匹配，地址不匹配的数据包如果试图传输路由器，应该丢弃。但是，链路上本地承载的某些地址配置消息可能合法地具有不匹配的地址。节点实现必须接受这些在本地通过链接传递的消息，管理员应该知道它们可以存在。
ICMPv6 messages transiting firewalls inbound to a site may be treated differently depending on whether they are addressed to a node on the site or to some other node. For end sites, packets addressed to nodes not on the site should be dropped, but would generally be forwarded by firewalls on transit sites.
将入站防火墙传输到站点的ICMPv6消息可能会受到不同的处理，这取决于它们是发往站点上的节点还是发往其他节点。对于终端站点，应丢弃发往不在站点上的节点的数据包，但通常由传输站点上的防火墙转发。
4.2. Interaction of Link-Local Messages with Firewall/Routers and Firewall/Bridges
4.2. 链路本地消息与防火墙/路由器和防火墙/网桥的交互
Firewalls can be implemented both as IP routers (firewall/routers) and as link layer bridges (e.g., Ethernet bridges) that are transparent to the IP layer although they will actually be inspecting the IP packets as they pass through (firewall/bridges).
防火墙可以实现为IP路由器（防火墙/路由器）和链路层网桥（例如以太网网桥），它们对IP层是透明的，尽管它们实际上会在IP数据包通过时检查它们（防火墙/网桥）。
Many of the messages used for establishment and maintenance of communications on the local link will be sent with link-local addresses for at least one of their source and destination. Routers conforming to the IPv6 standards will not forward these packets; there is no need to configure additional rules to prevent these
用于在本地链路上建立和维护通信的许多消息将与至少一个源和目的地的链路本地地址一起发送。符合IPv6标准的路由器不会转发这些数据包；不需要配置其他规则来防止这些错误
packets traversing a firewall/router, although administrators may wish to configure rules that would drop these packets for insurance and as a means of monitoring for attacks. Also, the specifications of ICMPv6 messages intended for use only on the local link specify various measures that would allow receivers to detect if the message had passed through a router, including:
通过防火墙/路由器的数据包，尽管管理员可能希望配置丢弃这些数据包的规则，以用于保险和监视攻击。此外，仅在本地链路上使用的ICMPv6消息规范规定了允许接收者检测消息是否通过路由器的各种措施，包括：
o Requiring that the hop limit in the IPv6 header is set to 255 on transmission. Receivers verify that the hop limit is still 255, to ensure that the packet has not passed through a router.
o 要求在传输时将IPv6标头中的跃点限制设置为255。接收器验证跃点限制仍然是255，以确保数据包没有通过路由器。
o Checking that the source address is a link-local unicast address.
o 检查源地址是否为链路本地单播地址。
Accordingly, it is not essential to configure firewall/router rules to drop out-of-specification packets of these types. If they have non-link-local source and destination addresses, allowing them to traverse the firewall/router, they would be rejected because of the checks performed at the destination. Again, firewall administrators may still wish to configure rules to log or drop such out-of-specification packets.
因此，没有必要将防火墙/路由器规则配置为丢弃这些类型的超出规范的数据包。如果它们具有非链接本地源地址和目标地址，允许它们穿越防火墙/路由器，则它们将被拒绝，因为在目标位置执行了检查。同样，防火墙管理员可能仍然希望配置规则来记录或删除此类不符合规范的数据包。
For firewall/bridges, slightly different considerations apply. The physical links on either side of the firewall/bridge are treated as a single logical link for the purposes of IP. Hence, the link local messages used for discovery functions on the link must be allowed to transit the transparent bridge. Administrators should ensures that routers and hosts attached to the link containing the firewall/bridge are built to the correct specifications so that out-of-specification packets are actually dropped as described in the earlier part of this section.
对于防火墙/网桥，应用的注意事项略有不同。出于IP的目的，防火墙/网桥两侧的物理链路被视为单个逻辑链路。因此，必须允许链路上用于发现功能的链路本地消息通过透明网桥。管理员应确保连接到包含防火墙/网桥的链路的路由器和主机按照正确的规范构建，以便按照本节前面部分所述，实际丢弃不符合规范的数据包。
An end host firewall can generally be thought of as a special case of a firewall/bridge, but the only link-local messages that need to be allowed through are those directed to the host's interface.
终端主机防火墙通常被认为是防火墙/网桥的特例，但需要允许通过的唯一链路本地消息是指向主机接口的消息。
This section recommends rules that should be applied to ICMPv6 traffic attempting to transit a firewall.
本节建议应用于试图通过防火墙的ICMPv6流量的规则。
Error messages that are essential to the establishment and maintenance of communications:
对建立和维护通信至关重要的错误消息：
o Destination Unreachable (Type 1) - All codes o Packet Too Big (Type 2) o Time Exceeded (Type 3) - Code 0 only o Parameter Problem (Type 4) - Codes 1 and 2 only
o 无法到达目的地（类型1）-所有代码o数据包太大（类型2）o超过时间（类型3）-仅代码0 o参数问题（类型4）-仅代码1和2
Appendix A.4 suggests some more specific checks that could be performed on Parameter Problem messages if a firewall has the necessary packet inspection capabilities.
附录A.4建议，如果防火墙具有必要的数据包检查功能，则可以对参数问题消息执行一些更具体的检查。
Connectivity checking messages:
连接检查消息：
o Echo Request (Type 128) o Echo Response (Type 129)
o 回声请求（128型）o回声响应（129型）
For Teredo tunneling [RFC4380] to IPv6 nodes on the site to be possible, it is essential that the connectivity checking messages are allowed through the firewall. It has been common practice in IPv4 networks to drop Echo Request messages in firewalls to minimize the risk of scanning attacks on the protected network. As discussed in Section 3.2, the risks from port scanning in an IPv6 network are much less severe, and it is not necessary to filter IPv6 Echo Request messages.
要使Teredo隧道[RFC4380]能够连接到站点上的IPv6节点，必须允许连接检查消息通过防火墙。IPv4网络中的常见做法是在防火墙中丢弃回显请求消息，以将扫描受保护网络的攻击风险降至最低。如第3.2节所述，IPv6网络中端口扫描的风险要小得多，不需要过滤IPv6回显请求消息。
Error messages other than those listed in Section 4.3.1:
除第4.3.1节所列信息外的错误信息：
o Time Exceeded (Type 3) - Code 1 o Parameter Problem (Type 4) - Code 0
o 超出时间（类型3）-代码1 o参数问题（类型4）-代码0
Mobile IPv6 messages that are needed to assist mobility:
协助移动所需的移动IPv6消息：
o Home Agent Address Discovery Request (Type 144) o Home Agent Address Discovery Reply (Type 145) o Mobile Prefix Solicitation (Type 146) o Mobile Prefix Advertisement (Type 147)
o 归属代理地址发现请求（类型144）o归属代理地址发现回复（类型145）o移动前缀请求（类型146）o移动前缀广告（类型147）
Administrators may wish to apply more selective rules as described in Appendix A.14 depending on whether the site is catering for mobile nodes that would normally be at home on the site and/or foreign mobile nodes roaming onto the site.
管理员可能希望应用附录A.14中所述的更具选择性的规则，这取决于站点是否适合通常位于站点上的移动节点和/或漫游到站点上的外国移动节点。
4.3.3. Traffic That Will Be Dropped Anyway -- No Special Attention Needed
4.3.3. 不管怎样，流量都会下降——不需要特别注意
The messages listed in this section are all involved with local management of nodes connected to the logical link on which they were initially transmitted. All these messages should never be propagated beyond the link on which they were initially transmitted. If the firewall is a firewall/bridge rather than a firewall/router, these messages should be allowed to transit the firewall as they would be intended for establishing communications between the two physical parts of the link that are bridged into a single logical link.
本节中列出的消息都涉及到对连接到逻辑链路的节点的本地管理，这些节点最初是在逻辑链路上传输的。所有这些消息都不应传播到最初传输它们的链路之外。如果防火墙是防火墙/网桥而不是防火墙/路由器，则应允许这些消息通过防火墙，因为它们将用于在桥接到单个逻辑链路的链路的两个物理部分之间建立通信。
During normal operations, these messages will have destination addresses, mostly link local but in some cases global unicast addresses, of interfaces on the local link. No special action is needed to filter messages with link-local addresses in a firewall/ router. As discussed in Section 4.1, these messages are specified so that either the receiver is able to check that the message has not passed through a router or it will be dropped at the first router it encounters.
在正常操作期间，这些消息将具有本地链路上接口的目标地址，主要是本地链路，但在某些情况下是全局单播地址。在防火墙/路由器中过滤带有链接本地地址的邮件不需要特殊操作。如第4.1节所述，指定这些消息是为了使接收方能够检查消息是否未通过路由器，或者在遇到的第一个路由器处丢弃消息。
Administrators may also wish to consider providing rules in firewall/ routers to catch illegal packets sent with hop limit = 1 to avoid ICMPv6 Time Exceeded messages being generated for these packets.
管理员还可以考虑在防火墙/路由器中提供规则以捕获具有跳数限制＝1的非法分组，以避免为这些分组生成ICMPv6超过时间的消息。
Address Configuration and Router Selection messages (must be received with hop limit = 255):
地址配置和路由器选择消息（必须在跃点限制为255时接收）：
o Router Solicitation (Type 133) o Router Advertisement (Type 134) o Neighbor Solicitation (Type 135) o Neighbor Advertisement (Type 136) o Redirect (Type 137) o Inverse Neighbor Discovery Solicitation (Type 141) o Inverse Neighbor Discovery Advertisement (Type 142)
o 路由器请求（133型）o路由器公告（134型）o邻居请求（135型）o邻居公告（136型）o重定向（137型）o反向邻居发现请求（141型）o反向邻居发现公告（142型）
Link-local multicast receiver notification messages (must have link-local source address):
链路本地多播接收器通知消息（必须具有链路本地源地址）：
o Listener Query (Type 130) o Listener Report (Type 131) o Listener Done (Type 132) o Listener Report v2 (Type 143)
o 侦听器查询（类型130）o侦听器报告（类型131）o侦听器完成（类型132）o侦听器报告v2（类型143）
SEND Certificate Path notification messages (must be received with hop limit = 255):
发送证书路径通知消息（必须在跃点限制为255时接收）：
o Certificate Path Solicitation (Type 148) o Certificate Path Advertisement (Type 149)
o 证书路径请求（148型）o证书路径公告（149型）
Multicast Router Discovery messages (must have link-local source address and hop limit = 1):
多播路由器发现消息（必须具有链路本地源地址和跃点限制=1）：
o Multicast Router Advertisement (Type 151) o Multicast Router Solicitation (Type 152) o Multicast Router Termination (Type 153)
o 多播路由器广告（151型）o多播路由器请求（152型）o多播路由器终止（153型）
The message type that the experimental Seamoby protocols are using will be expected to have to cross site boundaries in normal operation. Transit sites must allow these messages to transit the site. End site administrators should determine if they need to support these experiments and otherwise messages of this type should be dropped:
实验Seamoby协议使用的消息类型预计必须在正常操作中跨越站点边界。传输站点必须允许这些邮件传输站点。终端站点管理员应确定是否需要支持这些实验，否则应删除此类消息：
o Seamoby Experimental (Type 150)
o Seamoby实验型（150型）
Error messages not currently defined by IANA: o Unallocated Error messages (Types 5-99 inclusive and 102-126 inclusive)
IANA当前未定义的错误消息：o未分配的错误消息（类型5-99和102-126）
The base ICMPv6 specification suggests that error messages that are not explicitly known to a node should be forwarded and passed to any higher-level protocol that might be able to interpret them. There is a small risk that such messages could be used to provide a covert channel or form part of a DoS attack. Administrators of end sites should be aware of this and determine whether they wish to allow these messages through the firewall. Firewalls protecting transit sites must allow all types of error messages to transit the site but may adopt different policies for error messages addressed to nodes within the site.
基本ICMPv6规范建议，节点不明确知道的错误消息应该转发并传递给可能能够解释它们的任何高级协议。这类消息可能被用于提供隐蔽通道或构成DoS攻击的一部分，这种风险很小。终端站点的管理员应该知道这一点，并确定他们是否希望允许这些消息通过防火墙。保护传输站点的防火墙必须允许所有类型的错误消息传输站点，但对于发往站点内节点的错误消息，可能采用不同的策略。
All informational messages with types not explicitly assigned by IANA, currently:
IANA未明确指定类型的所有信息性消息，当前：
o Unallocated Informational messages (Types 154-199 inclusive and 202-254 inclusive).
o 未分配的信息性消息（包括154-199类型和202-254类型）。
Note that the base ICMPv6 specification requires that received informational messages with unknown types must be silently discarded. Transit sites must allow these messages to transit the site. End
请注意，基本ICMPv6规范要求接收到的类型未知的信息性消息必须以静默方式丢弃。传输站点必须允许这些邮件传输站点。终止
site administrators can either adopt a policy of allowing all these messages through the firewall, relying on end hosts to drop unrecognized messages, or drop all such messages at the firewall. Different policies could be adopted for inbound and outbound messages.
站点管理员可以采用允许所有这些消息通过防火墙的策略，依靠终端主机删除无法识别的消息，也可以在防火墙上删除所有此类消息。入站和出站消息可以采用不同的策略。
If administrators choose to implement policies that drop currently unallocated error or informational messages, it is important to review the set of messages affected in case new message types are assigned by IANA.
如果管理员选择实施删除当前未分配的错误或信息性消息的策略，则在IANA分配新消息类型的情况下，查看受影响的消息集非常重要。
Node Information enquiry messages should generally not be forwarded across site boundaries. Some of these messages will be using non-link-local unicast addresses so that they will not necessarily be dropped by address scope limiting rules:
节点信息查询消息通常不应跨站点边界转发。其中一些消息将使用非链路本地单播地址，因此它们不一定会被地址范围限制规则丢弃：
o Node Information Query (Type 139) o Node Information Response (Type 140)
o 节点信息查询（139型）o节点信息响应（140型）
Router Renumbering messages should not be forwarded across site boundaries. As originally specified, these messages may use a site scope multicast address or a site local unicast address. They should be caught by standard rules that are intended to stop any packet with a multicast site scope or site local destination being forwarded across a site boundary provided these are correctly configured. Since site local addresses have now been deprecated, it seems likely that changes may be made to allow the use of unique local addresses or global unicast addresses. Should this happen, it will be essential to explicitly filter these messages at site boundaries. If a site has internal as well as boundary firewalls, individual policies should be established for the internal firewalls depending on whether or not the site wishes to use Router Renumbering:
路由器重新编号消息不应跨站点边界转发。如最初指定的，这些消息可以使用站点范围多播地址或站点本地单播地址。如果正确配置了多播站点作用域或站点本地目的地，则应通过标准规则捕获这些数据包，这些规则旨在阻止跨站点边界转发多播站点作用域或站点本地目的地的任何数据包。由于站点本地地址现在已被弃用，因此可能会进行更改以允许使用唯一的本地地址或全局单播地址。如果发生这种情况，则必须在站点边界明确过滤这些消息。如果站点具有内部防火墙和边界防火墙，则应根据站点是否希望使用路由器重新编号为内部防火墙制定单独的策略：
o Router Renumbering (Type 138)
o 路由器重新编号（138型）
Messages with types in the experimental allocations:
实验分配中包含类型的消息：
o Types 100, 101, 200, and 201.
o 类型100、101、200和201。
Messages using the extension type numbers until such time as ICMPv6 needs to use such extensions:
在ICMPv6需要使用扩展名之前，使用扩展名类型编号的消息：
o Types 127 and 255.
o 类型127和255。
This section recommends filtering rules for ICMPv6 traffic addressed to an interface on a firewall. For a small number of messages, the desired behavior may differ between interfaces on the site or private side of the firewall and the those on the public Internet side of the firewall.
本节建议针对发往防火墙接口的ICMPv6通信量筛选规则。对于少量消息，在防火墙的站点或专用端上的接口和防火墙的公用Internet端上的接口之间，所需的行为可能有所不同。
Error messages that are essential to the establishment and maintenance of communications:
对建立和维护通信至关重要的错误消息：
o Destination Unreachable (Type 1) - All codes o Packet Too Big (Type 2) o Time Exceeded (Type 3) - Code 0 only o Parameter Problem (Type 4) - Codes 1 and 2 only
o 无法到达目的地（类型1）-所有代码o数据包太大（类型2）o超过时间（类型3）-仅代码0 o参数问题（类型4）-仅代码1和2
Connectivity checking messages:
连接检查消息：
o Echo Request (Type 128) o Echo Response (Type 129)
o 回声请求（128型）o回声响应（129型）
As discussed in Section 4.3.1, dropping connectivity checking messages will prevent the firewall being the destination of a Teredo tunnel and it is not considered necessary to disable connectivity checking in IPv6 networks because port scanning is less of a security risk.
如第4.3.1节所述，丢弃连接检查消息将防止防火墙成为Teredo隧道的目标，并且认为没有必要在IPv6网络中禁用连接检查，因为端口扫描的安全风险较小。
There are a number of other sets of messages that play a role in configuring the node and maintaining unicast and multicast communications through the interfaces of a node. These messages must not be dropped if the node is to successfully participate in an IPv6 network. The exception to this is the Redirect message for which an explicit policy decision should be taken (see Section 4.4.4).
还有许多其他消息集在配置节点和通过节点接口维护单播和多播通信方面发挥作用。如果节点要成功参与IPv6网络，则不得删除这些消息。例外情况是应作出明确策略决定的重定向消息（见第4.4.4节）。
Address Configuration and Router Selection messages:
地址配置和路由器选择消息：
o Router Solicitation (Type 133) o Router Advertisement (Type 134) o Neighbor Solicitation (Type 135) o Neighbor Advertisement (Type 136) o Inverse Neighbor Discovery Solicitation (Type 141) o Inverse Neighbor Discovery Advertisement (Type 142)
o 路由器请求（133型）o路由器公告（134型）o邻居请求（135型）o邻居公告（136型）o反向邻居发现请求（141型）o反向邻居发现公告（142型）
Link-Local Multicast Receiver Notification messages:
链接本地多播接收器通知消息：
o Listener Query (Type 130) o Listener Report (Type 131) o Listener Done (Type 132) o Listener Report v2 (Type 143)
o 侦听器查询（类型130）o侦听器报告（类型131）o侦听器完成（类型132）o侦听器报告v2（类型143）
SEND Certificate Path Notification messages:
发送证书路径通知消息：
o Certificate Path Solicitation (Type 148) o Certificate Path Advertisement (Type 149)
o 证书路径请求（148型）o证书路径公告（149型）
Multicast Router Discovery messages:
多播路由器发现消息：
o Multicast Router Advertisement (Type 151) o Multicast Router Solicitation (Type 152) o Multicast Router Termination (Type 153)
o 多播路由器广告（151型）o多播路由器请求（152型）o多播路由器终止（153型）
Error messages other than those listed in Section 4.4.1:
除第4.4.1节中列出的错误消息以外的错误消息：
o Time Exceeded (Type 3) - Code 1 o Parameter Problem (Type 4) - Code 0
o 超出时间（类型3）-代码1 o参数问题（类型4）-代码0
4.4.3. Traffic That Will Be Dropped Anyway -- No Special Attention Needed
4.4.3. 不管怎样，流量都会下降——不需要特别注意
Router Renumbering messages must be authenticated using IPsec, so it is not essential to filter these messages even if they are not allowed at the firewall/router:
路由器重新编号消息必须使用IPsec进行身份验证，因此，即使防火墙/路由器不允许这些消息，也不必过滤这些消息：
o Router Renumbering (Type 138)
o 路由器重新编号（138型）
Mobile IPv6 messages that are needed to assist mobility:
协助移动所需的移动IPv6消息：
o Home Agent Address Discovery Request (Type 144) o Home Agent Address Discovery Reply (Type 145) o Mobile Prefix Solicitation (Type 146) o Mobile Prefix Advertisement (Type 147)
o 归属代理地址发现请求（类型144）o归属代理地址发现回复（类型145）o移动前缀请求（类型146）o移动前缀广告（类型147）
It may be desirable to drop these messages, especially on public interfaces, if the firewall is not also providing mobile home agent services, but they will be ignored otherwise.
如果防火墙不同时提供移动归属代理服务，则可能需要删除这些消息，尤其是在公共接口上，否则这些消息将被忽略。
The message used by the experimental Seamoby protocols may be dropped but will be ignored if the service is not implemented:
实验Seamoby协议使用的消息可能会被丢弃，但如果服务未实现，则会被忽略：
o Seamoby Experimental (Type 150)
o Seamoby实验型（150型）
Redirect messages provide a significant security risk, and administrators should take a case-by-case approach to whether firewalls, routers in general, and other nodes should accept these messages:
重定向消息会带来严重的安全风险，管理员应采取逐案处理的方法来确定防火墙、路由器和其他节点是否应接受这些消息：
o Redirect (Type 137)
o 重定向（137型）
Conformant nodes must provide configuration controls that allow nodes to control their behavior with respect to Redirect messages so that it should only be necessary to install specific filtering rules under special circumstances, such as if Redirect messages are accepted on private interfaces but not public ones.
一致性节点必须提供允许节点控制其重定向消息行为的配置控件，以便只有在特殊情况下才需要安装特定的过滤规则，例如，如果在私有接口上接受重定向消息，而在公共接口上不接受重定向消息。
If a node implements the experimental Node Information service, the administrator needs to make an explicit decision as to whether the node should respond to or accept Node Information messages on each interface:
如果节点实现了实验节点信息服务，则管理员需要明确决定节点是否应响应或接受每个接口上的节点信息消息：
o Node Information Query (Type 139) o Node Information Response (Type 140)
o 节点信息查询（139型）o节点信息响应（140型）
It may be possible to disable the service on the node if it is not wanted, in which case these messages will be ignored and no filtering is necessary.
如果不需要，可以禁用节点上的服务，在这种情况下，这些消息将被忽略，无需过滤。
Error messages not currently defined by IANA:
IANA当前未定义的错误消息：
o Unallocated Error messages (Types 5-99 inclusive and 102-126 inclusive)
o 未分配的错误消息（类型5-99和102-126）
The base ICMPv6 specification suggests that error messages that are not explicitly known to a node should be forwarded and passed to any higher-level protocol that might be able to interpret them. There is a small risk that such messages could be used to provide a covert channel or form part of a DoS attack. Administrators should be aware of this and determine whether they wish to allow these messages to be sent to the firewall.
基本ICMPv6规范建议，节点不明确知道的错误消息应该转发并传递给可能能够解释它们的任何高级协议。这类消息可能被用于提供隐蔽通道或构成DoS攻击的一部分，这种风险很小。管理员应该知道这一点，并确定是否允许将这些消息发送到防火墙。
Messages with types in the experimental allocations:
实验分配中包含类型的消息：
o Types 100, 101, 200, and 201.
o 类型100、101、200和201。
Messages using the extension type numbers until such time as ICMPv6 needs to use such extensions:
在ICMPv6需要使用扩展名之前，使用扩展名类型编号的消息：
o Types 127 and 255.
o 类型127和255。
All informational messages with types not explicitly assigned by IANA, currently:
IANA未明确指定类型的所有信息性消息，当前：
o Types 154-199 inclusive and 202-254 inclusive.
o 154-199型（含）和202-254型（含）。
Note that the base ICMPv6 specification requires that received informational messages with unknown types must be silently discarded.
请注意，基本ICMPv6规范要求接收到的类型未知的信息性消息必须以静默方式丢弃。
Pekka Savola created the original IPv6 Security Overview document, which contained suggestions for ICMPv6 filter setups. This information has been incorporated into this document. He has also provided important comments. Some analysis of the classification of ICMPv6 messages and the term 'any-to-end' were used by Jari Arkko in a document relating to ICMPv6 and IKE.
Pekka Savola创建了最初的IPv6安全概述文档，其中包含对ICMPv6筛选器设置的建议。此信息已纳入本文件。他还发表了重要评论。Jari Arkko在一份与ICMPv6和IKE相关的文件中使用了对ICMPv6消息分类和术语“any to end”的一些分析。
The Netfilter configuration script in Appendix B was contributed by Suresh Krishnan.
附录B中的Netfilter配置脚本由Suresh Krishnan提供。
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.
[RFC1981]McCann，J.，Deering，S.，和J.Mogul，“IP版本6的路径MTU发现”，RFC 1981，1996年8月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，1998年12月。
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[RFC2461]Narten，T.，Nordmark，E.，和W.Simpson，“IP版本6（IPv6）的邻居发现”，RFC2461，1998年12月。
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.
[RFC2462]Thomson，S.和T.Narten，“IPv6无状态地址自动配置”，RFC2462，1998年12月。
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999.
[RFC2710]Deering，S.，Fenner，W.，和B.Haberman，“IPv6的多播侦听器发现（MLD）”，RFC 2710，1999年10月。
[RFC2894] Crawford, M., "Router Renumbering for IPv6", RFC 2894, August 2000.
[RFC2894]克劳福德，M.，“IPv6的路由器重新编号”，RFC 28942000年8月。
[RFC3122] Conta, A., "Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification", RFC 3122, June 2001.
[RFC3122]Conta，A.，“反向发现规范对IPv6邻居发现的扩展”，RFC3122，2001年6月。
[RFC3590] Haberman, B., "Source Address Selection for the Multicast Listener Discovery (MLD) Protocol", RFC 3590, September 2003.
[RFC3590]Haberman，B.，“多播侦听器发现（MLD）协议的源地址选择”，RFC 35902003年9月。
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[RFC3775]Johnson，D.，Perkins，C.，和J.Arkko，“IPv6中的移动支持”，RFC 37752004年6月。
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[RFC3810]Vida，R.和L.Costa，“IPv6多播侦听器发现版本2（MLDv2）”，RFC 3810，2004年6月。
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC3971]Arkko，J.，Kempf，J.，Zill，B.，和P.Nikander，“安全邻居发现（SEND）”，RFC 39712005年3月。
[RFC4065] Kempf, J., "Instructions for Seamoby and Experimental Mobility Protocol IANA Allocations", RFC 4065, July 2005.
[RFC4065]Kempf，J.，“Seamoby和实验移动协议IANA分配说明”，RFC4065，2005年7月。
[RFC4286] Haberman, B. and J. Martin, "Multicast Router Discovery", RFC 4286, December 2005.
[RFC4286]Haberman，B.和J.Martin，“多播路由器发现”，RFC 4286，2005年12月。
[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006.
[RFC4443]Conta，A.，Deering，S.和M.Gupta，“互联网协议版本6（IPv6）规范的互联网控制消息协议（ICMPv6）”，RFC 4443，2006年3月。
[RFC4620] Crawford, M. and B. Haberman, "IPv6 Node Information Queries", RFC 4620, August 2006.
[RFC4620]Crawford，M.和B.Haberman，“IPv6节点信息查询”，RFC4620，2006年8月。
[ICMP-ATTACKS] Gont, F., "ICMP attacks against TCP", Work in Progress, October 2006.
[ICMP-ATTACKS]Gont，F.，“针对TCP的ICMP攻击”，正在进行的工作，2006年10月。
[RFC3041] Narten, T. and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001.
[RFC3041]Narten，T.和R.Draves，“IPv6中无状态地址自动配置的隐私扩展”，RFC 3041，2001年1月。
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)", RFC 4380, February 2006.
[RFC4380]Huitema，C.，“Teredo：通过网络地址转换（NAT）通过UDP传输IPv6”，RFC 43802006年2月。
[SCAN-IMP] Chown, T., "IPv6 Implications for Network Scanning", Work in Progress, March 2007.
[SCAN-IMP]Chown，T.，“IPv6对网络扫描的影响”，正在进行的工作，2007年3月。
[netfilter] netfilter.org, "The netfilter.org project", Firewalling, NAT and Packet Mangling for Linux , 2006, <http://www.netfilter.org/>.
[netfilter]netfilter.org，“netfilter.org项目”，Linux防火墙、NAT和数据包破坏，2006年<http://www.netfilter.org/>.
Destination Unreachable (Type 1) error messages [RFC4443] are sent any-to-end between unicast addresses. The message can be generated from any node that a packet traverses when the node is unable to forward the packet for any reason except congestion.
目标不可到达（类型1）错误消息[RFC4443]在单播地址之间发送到任意端。当节点由于拥塞以外的任何原因无法转发数据包时，可以从数据包经过的任何节点生成消息。
Destination Unreachable messages are useful for debugging, but are also important to speed up cycling through possible addresses, as they can avoid the need to wait through timeouts and hence can be part of the process of establishing or maintaining communications. It is a common practice in IPv4 to refrain from generating ICMP Destination Unreachable messages in an attempt to hide the networking topology and/or service structure. The same idea could be applied to IPv6, but this can slow down connection if a host has multiple addresses, some of which are deprecated, as they may be when using privacy addresses [RFC3041]. If policy allows the generation of ICMPv6 Destination Unreachable messages, it is important that nodes provide the correct reason code, one of: no route to destination, administratively prohibited, beyond scope of source address, address unreachable, port unreachable, source address failed ingress/egress policy, or reject route to destination.
目的地不可到达消息对于调试很有用，但对于加快可能的地址循环也很重要，因为它们可以避免超时等待，因此可以作为建立或维护通信过程的一部分。IPv4中的一种常见做法是避免生成ICMP目的地不可访问的消息，以试图隐藏网络拓扑和/或服务结构。同样的想法也可以应用于IPv6，但如果主机有多个地址（其中一些地址已被弃用），这可能会降低连接速度，就像使用隐私地址时一样[RFC3041]。如果策略允许生成ICMPv6目标不可访问消息，则节点必须提供正确的原因码，其中之一是：没有到目标的路由、管理禁止、超出源地址范围、地址不可访问、端口不可访问、源地址失败的入口/出口策略或拒绝到目标的路由。
Packet Too Big (Type 2) error messages [RFC4443] are sent any-to-end between unicast addresses. The message can be generated from any node that a packet traverses on the path when the node is unable to forward the packet because the packet is too large for the MTU of the next link. This message is vital to the correct functioning of Path MTU Discovery and hence is part of the establishment and maintenance of communications. Since routers are not allowed to fragment packets, informing sources of the need to fragment large packets is more important than for IPv4. If these messages are not generated when appropriate, hosts will continue to send packets that are too large or may assume that the route is congested. Effectively, parts of the Internet will become inaccessible.
数据包太大（类型2）错误消息[RFC4443]在单播地址之间发送到任意端。当节点由于数据包对于下一链路的MTU来说太大而无法转发数据包时，可以从数据包在路径上经过的任何节点生成消息。此消息对于路径MTU发现的正确功能至关重要，因此是建立和维护通信的一部分。由于不允许路由器对数据包进行分段，所以通知来源需要对大数据包进行分段比IPv4更重要。如果在适当的时候没有生成这些消息，主机将继续发送过大的数据包，或者可能认为路由拥塞。实际上，互联网的某些部分将变得无法访问。
If a network chooses to generate packets that are no larger than the Guaranteed Minimum MTU (1280 octets) and the site's links to the wider Internet have corresponding MTUs, Packet Too Big messages should not be expected at the firewall and could be dropped if they arrive.
如果网络选择生成不大于保证的最小MTU（1280个八位字节）的数据包，并且站点与更广泛的Internet的链接具有相应的MTU，则防火墙不应预期数据包过大的消息，如果它们到达，则可能会丢弃。
Time Exceeded (Type 3) error messages [RFC4443] can occur in two contexts:
超出时间（类型3）错误消息[RFC4443]可在两种情况下出现：
o Code 0 are generated at any node on the path being taken by the packet and sent, any-to-end between unicast addresses, if the Hop Limit value is decremented to zero at that node.
o 如果跳数限制值在该节点处减为零，则在数据包所采用并发送的路径上的任何节点处生成代码0，在单播地址之间的任何端点。
o Code 1 messages are generated at the destination node and sent end-to-end between unicast addresses if all the segments of a fragmented message are not received within the reassembly time limit.
o 如果在重组时间限制内未收到分段消息的所有段，则在目标节点生成代码1消息，并在单播地址之间端到端发送。
Code 0 messages can be needed as part of the establishment of communications if the path to a particular destination requires an unusually large number of hops.
如果到特定目的地的路径需要异常多的跳数，则可能需要代码0消息作为建立通信的一部分。
Code 1 messages will generally only result from congestion in the network, and it is less essential to propagate these messages.
代码1消息通常仅由网络拥塞引起，传播这些消息的必要性较低。
The great majority of Parameter Problem (Type 4) error messages will be generated by the destination node when processing destination options and other extension headers, and hence are sent end-to-end between unicast addresses. Exceptionally, these messages might be generated by any node on the path if a faulty or unrecognized hop-by-hop option is included or from any routing waypoint if there are faulty or unrecognized destination options associated with a Type 0 routing header. In these cases, the message will be sent any-to-end using unicast source and destination addresses.
绝大多数参数问题（类型4）错误消息将由目标节点在处理目标选项和其他扩展头时生成，因此在单播地址之间端到端发送。例外情况下，如果包含错误或无法识别的逐跳选项，则这些消息可能由路径上的任何节点生成；如果存在与类型0路由标头关联的错误或无法识别的目的地选项，则这些消息可能由任何路由航路点生成。在这些情况下，消息将使用单播源地址和目标地址发送到任意一端。
Parameter Problem Code 1 (Unrecognized Next Header) and Code 2 (Unrecognized IPv6 Option) messages may result if a node on the path (usually the destination) is unable to process a correctly formed extension header or option. If these messages are not returned to the source, communication cannot be established, as the source would need to adapt its choice of options probably because the destination does not implement these capabilities. Hence, these messages need to be generated and allowed for effective IPv6 communications.
如果路径（通常是目标）上的节点无法处理格式正确的扩展标头或选项，则可能会产生参数问题代码1（无法识别的下一个标头）和代码2（无法识别的IPv6选项）消息。如果这些消息没有返回到源，则无法建立通信，因为源可能需要调整其选项选择，因为目的地没有实现这些功能。因此，需要生成并允许这些消息进行有效的IPv6通信。
Code 0 (Erroneous Header) messages indicate a malformed extension header generally as a result of incorrectly generated packets. Hence, these messages are useful for debugging purposes, but it is unlikely that a node generating such packets could establish communications without human intervention to correct the problem.
代码0（错误标头）消息通常表示由于生成的数据包不正确而导致的扩展标头格式错误。因此，这些消息对于调试目的很有用，但生成此类数据包的节点不太可能在没有人为干预的情况下建立通信来纠正问题。
Code 2 messages, only, can be generated for packets with multicast destination addresses.
只能为具有多播目标地址的数据包生成代码2消息。
It is possible that attackers may seek to probe or scan a network by deliberately generating packets with unknown extension headers or options or with faulty headers. If nodes generate Parameter Problem error messages in all cases and these outgoing messages are allowed through firewalls, the attacker may be able to identify active addresses that can be probed further or learn about the network topology. The vulnerability could be mitigated whilst helping to establish communications if the firewall was able to examine such error messages in depth and was configured to only allow Parameter Problem messages for headers that had been standardized but were not supported in the protected network. If the network administrator believes that all nodes in the network support all legitimate extension headers, then it would be reasonable to drop all outgoing Parameter Problem messages. Note that this is not a major vulnerability in a well-designed IPv6 network because of the difficulties of performing scanning attacks (see Section 3.2).
攻击者可能会通过故意生成具有未知扩展头或选项或错误头的数据包来探测或扫描网络。如果节点在所有情况下都生成参数问题错误消息，并且允许通过防火墙发送这些消息，则攻击者可能能够识别可进一步探测或了解网络拓扑的活动地址。如果防火墙能够深入检查此类错误消息，并且配置为仅允许已标准化但受保护网络不支持的标头的参数问题消息，则该漏洞可以在帮助建立通信的同时得到缓解。如果网络管理员认为网络中的所有节点都支持所有合法的扩展头，那么删除所有传出的参数问题消息是合理的。请注意，在设计良好的IPv6网络中，这不是一个主要漏洞，因为执行扫描攻击很困难（请参见第3.2节）。
Echo Request (Type 128) uses unicast addresses as source addresses, but may be sent to any legal IPv6 address, including multicast and anycast addresses [RFC4443]. Echo Requests travel end-to-end. Similarly, Echo Responses (Type 129) travel end-to-end and would have a unicast address as destination and either a unicast or anycast address as source. They are mainly used in combination for monitoring and debugging connectivity. Their only role in establishing communication is that they are required when verifying connectivity through Teredo tunnels [RFC4380]: Teredo tunneling to IPv6 nodes on the site will not be possible if these messages are blocked. It is not thought that there is a significant risk from scanning attacks on a well-designed IPv6 network (see Section 3.2), and so connectivity checks should be allowed by default.
Echo请求（类型128）使用单播地址作为源地址，但可以发送到任何合法的IPv6地址，包括多播和选播地址[RFC4443]。Echo请求端到端传输。类似地，回波响应（类型129）端到端地传输，并将单播地址作为目的地，单播或选播地址作为源。它们主要用于监控和调试连接。它们在建立通信中的唯一作用是，在通过Teredo隧道[RFC4380]验证连接时需要它们：如果这些消息被阻止，则无法通过Teredo隧道连接到站点上的IPv6节点。人们并不认为在设计良好的IPv6网络上扫描攻击会有很大的风险（请参见第3.2节），因此默认情况下应允许进行连接检查。
ICMPv6 Neighbor Solicitation and Neighbor Advertisement (Type 135 and 136) messages are essential to the establishment and maintenance of communications on the local link. Firewalls need to generate and accept these messages to allow them to establish and maintain interfaces onto their connected links.
ICMPv6邻居请求和邻居公告（135和136型）消息对于在本地链路上建立和维护通信至关重要。防火墙需要生成并接受这些消息，以允许它们在连接的链路上建立和维护接口。
Note that the address scopes of the source and destination addresses on Neighbor Solicitations and Neighbor Advertisements may not match. The exact functions that these messages will be carrying out depends on the mechanism being used to configure IPv6 addresses on the link (Stateless, Stateful, or Static configuration).
请注意，邻居请求和邻居播发上的源地址和目标地址的地址范围可能不匹配。这些消息将执行的确切功能取决于用于在链路上配置IPv6地址的机制（无状态、有状态或静态配置）。
ICMPv6 Router Solicitation and Router Advertisement (Type 133 and 134) messages are essential to the establishment and maintenance of communications on the local link. Firewalls need to generate (since the firewall will generally be behaving as a router) and accept these messages to allow them to establish and maintain interfaces onto their connected links.
ICMPv6路由器请求和路由器广告（133和134型）消息对于在本地链路上建立和维护通信至关重要。防火墙需要生成（因为防火墙通常作为路由器）并接受这些消息，以允许它们在连接的链路上建立和维护接口。
ICMPv6 Redirect Messages (Type 137) are used on the local link to indicate that nodes are actually link-local and communications need not go via a router, or to indicate a more appropriate first-hop router. Although they can be used to make communications more efficient, they are not essential to the establishment of communications and may be a security vulnerability, particularly if a link is not physically secured. Conformant nodes are required to provide configuration controls that suppress the generation of Redirect messages and allow them to be ignored on reception. Using Redirect messages on, for example, a wireless link without link level encryption/authentication is particularly hazardous because the link is open to eavesdropping and packet injection.
在本地链路上使用ICMPv6重定向消息（类型137）来指示节点实际上是本地链路，通信不需要通过路由器，或者指示更合适的第一跳路由器。尽管它们可用于提高通信效率，但它们对建立通信并不重要，而且可能是一个安全漏洞，特别是在链路没有物理安全的情况下。一致性节点需要提供配置控制，以抑制重定向消息的生成，并允许在接收时忽略这些消息。例如，在没有链路级加密/认证的无线链路上使用重定向消息尤其危险，因为该链路容易被窃听和数据包注入。
SEND [RFC3971] uses two messages (Certificate Path Solicitation and Advertisement - Types 148 and 149) sent from nodes to supposed routers on the same local link to obtain a certificate path that will allow the node to authenticate the router's claim to provide routing services for certain prefixes. If a link connected to a firewall/ router is using SEND, the firewall must be able to exchange these messages with nodes on the link that will use its routing services.
SEND[RFC3971]使用从节点发送到同一本地链路上的假定路由器的两条消息（证书路径请求和公告-类型148和149）来获取证书路径，该路径将允许节点验证路由器为某些前缀提供路由服务的声明。如果连接到防火墙/路由器的链路正在使用SEND，则防火墙必须能够与链路上将使用其路由服务的节点交换这些消息。
Multicast Listener Discovery (MLD) version 1 [RFC2710] (Listener Query, Listener Report, and Listener Done - Types 130, 131, and 132) and version 2 [RFC3810] (Listener Query and Listener Report version 2 - Types 130 and 143) messages are sent on the local link to communicate between multicast-capable routers and nodes that wish to join or leave specific multicast groups. Firewalls need to be able
多播侦听器发现（MLD）版本1[RFC2710]（侦听器查询、侦听器报告和侦听器完成-类型130、131和132）和版本2[RFC3810]（侦听器查询和侦听器报告版本2-类型130和143）消息在本地链路上发送，以在支持多播的路由器和希望加入或离开特定多播组的节点之间进行通信。防火墙需要能够
to generate Listener messages in order to establish communications and may generate all the messages if they also provide multicast routing services.
生成侦听器消息以建立通信，如果它们还提供多播路由服务，则可能生成所有消息。
Multicast Router Discovery [RFC4286] (Router Advertisement, Router Solicitation, and Router Termination - Types 151, 152, and 153) messages are sent by nodes on the local link to discover multicast-capable routers on the link, and by multicast-capable routers to notify other nodes of their existence or change of state. Firewalls that also act as multicast routers need to process these messages on their interfaces.
多播路由器发现[RFC4286]（路由器公告、路由器请求和路由器终止-类型151、152和153）消息由本地链路上的节点发送，以发现链路上具有多播能力的路由器，并由具有多播能力的路由器发送，以通知其他节点其存在或状态变化。同时充当多播路由器的防火墙需要在其接口上处理这些消息。
ICMPv6 Router Renumbering (Type 138) command messages can be received and results messages sent by routers to change the prefixes that they advertise as part of Stateless Address Configuration [RFC2461], [RFC2462]. These messages are sent end-to-end to either the all-routers multicast address (site or local scope) or specific unicast addresses from a unicast address.
ICMPv6路由器重新编号（138型）命令消息可由路由器接收并发送结果消息，以更改作为无状态地址配置[RFC2461]、[RFC2462]一部分公布的前缀。这些消息被端到端发送到所有路由器多播地址（站点或本地范围）或单播地址中的特定单播地址。
Router Renumbering messages are required to be protected by IPsec authentication since they could be readily misused by attackers to disrupt or divert site communications. Renumbering messages should generally be confined to sites for this reason.
路由器重新编号消息需要受到IPsec身份验证的保护，因为攻击者很容易滥用这些消息来中断或转移站点通信。因此，对邮件重新编号通常应限于站点。
ICMPv6 Node Information Query and Reply (Type 139 and 140) messages defined in [RFC4620] are sent end-to-end between unicast addresses, and they can also be sent to link-local multicast addresses. They can, in theory, be sent from any node to any other, but it would generally not be desirable for nodes outside the local site to be able to send queries to nodes within the site. Also, these messages are not required to be authenticated.
[RFC4620]中定义的ICMPv6节点信息查询和回复（类型139和140）消息在单播地址之间端到端发送，也可以发送到链路本地多播地址。理论上，它们可以从任何节点发送到任何其他节点，但本地站点之外的节点通常不希望能够向站点内的节点发送查询。此外，这些消息不需要进行身份验证。
Mobile IPv6 [RFC3775] defines four ICMPv6 messages that are used to support mobile operations: Home Agent Address Discovery Request, Home Agent Address Discovery Reply, Mobile Prefix Solicitation, and ICMP Mobile Prefix Advertisement (Type 144, 145, 146, and 147) messages. These messages are sent end-to-end between unicast addresses of a mobile node and its home agent. They must be expected to be sent from outside a site and must traverse site-boundary firewalls to reach the home agent in order for Mobile IPv6 to function. The two
移动IPv6[RFC3775]定义了四条用于支持移动操作的ICMPv6消息：归属代理地址发现请求、归属代理地址发现回复、移动前缀请求和ICMP移动前缀广告（类型144、145、146和147）消息。这些消息在移动节点及其归属代理的单播地址之间端到端发送。它们必须预期从站点外部发送，并且必须穿过站点边界防火墙到达归属代理，以便移动IPv6正常工作。两个
Mobile prefix messages should be protected by the use of IPsec authentication.
移动前缀消息应通过使用IPsec身份验证进行保护。
o If the site provides home agents for mobile nodes, the firewall must allow incoming Home Agent Address Discovery Request and Mobile Prefix Solicitation messages, and outgoing Home Agent Address Discovery Reply and ICMP Mobile Prefix Advertisement messages. It may be desirable to limit the destination addresses for the incoming messages to links that are known to support home agents.
o 如果站点为移动节点提供归属代理，防火墙必须允许传入归属代理地址发现请求和移动前缀请求消息，以及传出归属代理地址发现回复和ICMP移动前缀广告消息。可能希望将传入消息的目的地地址限制为已知支持归属代理的链路。
o If the site is prepared to host roaming mobile nodes, the firewall must allow outgoing Home Agent Address Discovery Request and Mobile Prefix Solicitation messages, and incoming Home Agent Address Discovery Reply and ICMP Mobile Prefix Advertisement messages.
o 如果站点准备承载漫游移动节点，防火墙必须允许传出的归属代理地址发现请求和移动前缀请求消息，以及传入的归属代理地址发现回复和ICMP移动前缀广告消息。
o Administrators may find it desirable to prevent static nodes that are normally resident on the site from behaving as mobile nodes by dropping Mobile IPv6 messages from these nodes.
o 管理员可能会发现，通过从这些节点删除移动IPv6消息，可以防止通常驻留在站点上的静态节点表现为移动节点。
A large number of ICMPv6 Type values are currently unused. These values have not had a specific function registered with IANA. This section describes how to treat messages that attempt to use these Type values in a way of which the network administrator (and hence the firewall) is not aware.
大量ICMPv6类型值当前未使用。这些值没有在IANA中注册特定的函数。本节介绍如何以网络管理员（以及防火墙）不知道的方式处理试图使用这些类型值的消息。
[RFC4443] defines a number of experimental Type values for ICMPv6 Error and Informational messages, which could be used in site-specific ways. These messages should be dropped by transit networks and at site edges. They should also not be propagated within sites unless the network administrator is explicitly made aware of usage.
[RFC4443]为ICMPv6错误和信息消息定义了许多实验类型值，这些值可以以特定于站点的方式使用。这些信息应由交通网络和站点边缘丢弃。除非网络管理员明确了解使用情况，否则也不应在站点内传播它们。
The codes reserved for future extension of the ICMPv6 Type space should currently be dropped as this functionality is as yet undefined.
为ICMPv6类型空间的未来扩展保留的代码当前应删除，因为此功能尚未定义。
Any ICMPv6 Informational messages of which the firewall is not aware should be allowed to transit through the firewall but should not be accepted for local delivery on any of its interfaces.
应允许防火墙不知道的任何ICMPv6信息性消息通过防火墙传输，但不应在其任何接口上接受本地传递。
Unknown ICMPv6 Error messages should be allowed to pass through transit networks. At end site boundaries any incoming ICMPv6 Error messages of which the firewall is not aware may be allowed through the firewall in line with the specification in [RFC4443], which requests delivery of unknown error messages to higher-layer protocol
应允许未知ICMPv6错误消息通过传输网络。根据[RFC4443]中的规范，在终端站点边界，防火墙不知道的任何传入ICMPv6错误消息可通过防火墙，该规范要求将未知错误消息传递给更高层协议
processes. However, administrators may wish to disallow forwarding of these incoming messages as a potential security risk. Unknown outgoing Error messages should be dropped as the administrator should be aware of all messages that could be generated on the site.
过程。但是，管理员可能希望禁止转发这些传入消息，因为这有潜在的安全风险。应该删除未知的传出错误消息，因为管理员应该知道站点上可能生成的所有消息。
Also, the SEAMOBY working group has had an ICMPv6 message (Type 150) allocated for experimental use in two protocols. This message is sent end-to-end and may need to pass through firewalls on sites that are supporting the experimental protocols.
此外，SEAMOBY工作组已将ICMPv6消息（类型150）分配给两个协议，供实验使用。此消息是端到端发送的，可能需要通过支持实验协议的站点上的防火墙。
This appendix contains an example script to implement most of the rules suggested in this document when using the Netfilter packet filtering system for Linux [netfilter]. When used with IPv6, the 'ip6tables' command is used to configure packet filtering rules for the Netfilter system. The script is targeted at a simple enterprise site that may or may not support Mobile IPv6.
本附录包含一个示例脚本，用于在使用针对Linux的Netfilter数据包过滤系统[Netfilter]时实现本文档中建议的大多数规则。与IPv6一起使用时，“ip6tables”命令用于为Netfilter系统配置数据包过滤规则。该脚本针对可能支持或不支持移动IPv6的简单企业站点。
#!/bin/bash
# Set of prefixes on the trusted ("inner") side of the firewall
export INNER_PREFIXES="2001:DB8:85::/60"
# Set of hosts providing services so that they can be made pingable
export PINGABLE_HOSTS="2001:DB8:85::/64"
# Configuration option: Change this to 1 if errors allowed only for
# existing sessions
export STATE_ENABLED=0
# Configuration option: Change this to 1 if messages to/from link
# local addresses should be filtered.
# Do not use this if the firewall is a bridge.
# Optional for firewalls that are routers.
export FILTER_LINK_LOCAL_ADDRS=0
# Configuration option: Change this to 0 if the site does not support
# Mobile IPv6 Home Agents - see Appendix A.14
export HOME_AGENTS_PRESENT=1
# Configuration option: Change this to 0 if the site does not support
# Mobile IPv6 mobile nodes being present on the site -
# see Appendix A.14
export MOBILE_NODES_PRESENT=1
#!/bin/bash
# Set of prefixes on the trusted ("inner") side of the firewall
export INNER_PREFIXES="2001:DB8:85::/60"
# Set of hosts providing services so that they can be made pingable
export PINGABLE_HOSTS="2001:DB8:85::/64"
# Configuration option: Change this to 1 if errors allowed only for
# existing sessions
export STATE_ENABLED=0
# Configuration option: Change this to 1 if messages to/from link
# local addresses should be filtered.
# Do not use this if the firewall is a bridge.
# Optional for firewalls that are routers.
export FILTER_LINK_LOCAL_ADDRS=0
# Configuration option: Change this to 0 if the site does not support
# Mobile IPv6 Home Agents - see Appendix A.14
export HOME_AGENTS_PRESENT=1
# Configuration option: Change this to 0 if the site does not support
# Mobile IPv6 mobile nodes being present on the site -
# see Appendix A.14
export MOBILE_NODES_PRESENT=1
ip6tables -N icmpv6-filter
ip6tables -A FORWARD -p icmpv6 -j icmpv6-filter
ip6tables -N icmpv6-filter
ip6tables -A FORWARD -p icmpv6 -j icmpv6-filter
# Match scope of src and dest else deny
# This capability is not provided for in base ip6tables functionality
# An extension (agr) exists which may support it.
#@TODO@
# Match scope of src and dest else deny
# This capability is not provided for in base ip6tables functionality
# An extension (agr) exists which may support it.
#@TODO@
# ECHO REQUESTS AND RESPONSES
# ===========================
# ECHO REQUESTS AND RESPONSES
# ===========================
# Allow outbound echo requests from prefixes which belong to the site for inner_prefix in $INNER_PREFIXES do ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \ --icmpv6-type echo-request -j ACCEPT done
#允许来自属于站点的前缀的出站回显请求用于$INERNER_prefixes do ip6tables中的INERNER_prefixes do ip6tables-A icmpv6筛选器-p icmpv6-s$INERNER_prefix \--icmpv6类型回显请求-j ACCEPT done
# Allow inbound echo requests towards only predetermined hosts for pingable_host in $PINGABLE_HOSTS do ip6tables -A icmpv6-filter -p icmpv6 -d $pingable_host \ --icmpv6-type echo-request -j ACCEPT done
#只允许针对$pingable_hosts do ip6tables中pingable_主机的预定主机的入站回显请求-A icmpv6筛选器-p icmpv6-d$pingable_主机\--icmpv6类型回显请求-j接受完成
if [ "$STATE_ENABLED" -eq "1" ] then # Allow incoming and outgoing echo reply messages # only for existing sessions ip6tables -A icmpv6-filter -m state -p icmpv6 \ --state ESTABLISHED,RELATED --icmpv6-type \ echo-reply -j ACCEPT else # Allow both incoming and outgoing echo replies for pingable_host in $PINGABLE_HOSTS do # Outgoing echo replies from pingable hosts ip6tables -A icmpv6-filter -p icmpv6 -s $pingable_host \ --icmpv6-type echo-reply -j ACCEPT done # Incoming echo replies to prefixes which belong to the site for inner_prefix in $INNER_PREFIXES do ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \ --icmpv6-type echo-reply -j ACCEPT done fi
如果[“$STATE_ENABLED”-eq“1”]，则#允许传入和传出回显回复消息#仅适用于现有会话ip6tables-icmpv6筛选器-m状态-p icmpv6 \-已建立状态，相关--icmpv6 type\echo reply-j ACCEPT else#允许$pingable_HOSTS do中pingable_主机的传入和传出回显回复#来自pingable HOSTS ip6tables的传出回显回复-A icmpv6筛选器-p icmpv6-s$pingable_HOSTS \--icmpv6 type echo reply-j ACCEPT done#传入回显回复到属于站点的前缀$INERNER_前缀中的INERNER_前缀do ip6tables-A icmpv6筛选器-p icmpv6-d$INERNER_前缀\--icmpv6类型回显应答-j接受完成
# Deny icmps to/from link local addresses
# If the firewall is a router:
# These rules should be redundant as routers should not forward
# link local addresses but to be sure...
# DO NOT ENABLE these rules if the firewall is a bridge
if [ "$FILTER_LINK_LOCAL_ADDRS" -eq "1" ]
then
ip6tables -A icmpv6-filter -p icmpv6 -d fe80::/10 -j DROP
# Deny icmps to/from link local addresses
# If the firewall is a router:
# These rules should be redundant as routers should not forward
# link local addresses but to be sure...
# DO NOT ENABLE these rules if the firewall is a bridge
if [ "$FILTER_LINK_LOCAL_ADDRS" -eq "1" ]
then
ip6tables -A icmpv6-filter -p icmpv6 -d fe80::/10 -j DROP
ip6tables -A icmpv6-filter -p icmpv6 -s fe80::/10 -j DROP
fi
ip6tables -A icmpv6-filter -p icmpv6 -s fe80::/10 -j DROP
fi
# Drop echo replies which have a multicast address as a
# destination
ip6tables -A icmpv6-filter -p icmpv6 -d ff00::/8 \
--icmpv6-type echo-reply -j DROP
# Drop echo replies which have a multicast address as a
# destination
ip6tables -A icmpv6-filter -p icmpv6 -d ff00::/8 \
--icmpv6-type echo-reply -j DROP
# DESTINATION UNREACHABLE ERROR MESSAGES
# ======================================
# DESTINATION UNREACHABLE ERROR MESSAGES
# ======================================
if [ "$STATE_ENABLED" -eq "1" ] then # Allow incoming destination unreachable messages # only for existing sessions for inner_prefix in $INNER_PREFIXES do ip6tables -A icmpv6-filter -m state -p icmpv6 \ -d $inner_prefix \ --state ESTABLISHED,RELATED --icmpv6-type \ destination-unreachable -j ACCEPT done else # Allow incoming destination unreachable messages for inner_prefix in $INNER_PREFIXES do ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \ --icmpv6-type destination-unreachable -j ACCEPT done fi
如果[“$STATE_ENABLED”-eq“1”]，则#允许传入的目标不可访问消息#仅针对$internal_PREFIXES中的internal_PREFIXES的现有会话执行ip6tables-icmpv6筛选器-m STATE-p icmpv6 \-d$internal_prefix \-已建立状态，相关--icmpv6 type\destination unreachable-j ACCEPT done else#允许$inner_PREFIXES do ip6tables中的inner_PREFIXES的传入目标不可访问消息-A icmpv6 filter-p icmpv6-d$inner_prefix \--icmpv6 type destination unreachable-j ACCEPT done fi
# Allow outgoing destination unreachable messages for inner_prefix in $INNER_PREFIXES do ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \ --icmpv6-type destination-unreachable -j ACCEPT done
#允许$INERNAR\U PREFIXS do ip6tables中的INERNAR\U PREFIXS的传出目标不可访问消息-A icmpv6筛选器-p icmpv6-s$INERNAR\U prefix \--icmpv6类型目标不可访问-j ACCEPT done
# PACKET TOO BIG ERROR MESSAGES
# =============================
# PACKET TOO BIG ERROR MESSAGES
# =============================
if [ "$STATE_ENABLED" -eq "1" ] then # Allow incoming Packet Too Big messages # only for existing sessions for inner_prefix in $INNER_PREFIXES do ip6tables -A icmpv6-filter -m state -p icmpv6 \
如果[“$STATE_ENABLED”-eq“1”]，则#允许传入的数据包过大消息#仅适用于$internal_PREFIXES中的internal_PREFIXES的现有会话执行ip6tables-A icmpv6筛选器-m STATE-p icmpv6\
-d $inner_prefix \ --state ESTABLISHED,RELATED \ --icmpv6-type packet-too-big \ -j ACCEPT done else # Allow incoming Packet Too Big messages for inner_prefix in $INNER_PREFIXES do ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \ --icmpv6-type packet-too-big -j ACCEPT done fi
-d$INERNER_prefix \--状态已建立，相关\--icmpv6类型数据包太大\-j接受完成其他\#允许$INERNER_PREFIXS do ip6tables中的INERNER_PREFIXS的传入数据包太大消息-A icmpv6筛选器-p icmpv6-d$INERNER_prefix \-icmpv6类型数据包太大-j接受完成
# Allow outgoing Packet Too Big messages for inner_prefix in $INNER_PREFIXES do ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \ --icmpv6-type packet-too-big -j ACCEPT done
#允许$INTERNAR_PREFIXS do ip6tables中的INTERNAR_PREFIXS的传出数据包过大消息-icmpv6筛选器-p icmpv6-s$INTERNAR_prefix \--icmpv6类型数据包过大-j ACCEPT done
# TIME EXCEEDED ERROR MESSAGES
# ============================
# TIME EXCEEDED ERROR MESSAGES
# ============================
if [ "$STATE_ENABLED" -eq "1" ] then # Allow incoming time exceeded code 0 messages # only for existing sessions for inner_prefix in $INNER_PREFIXES do ip6tables -A icmpv6-filter -m state -p icmpv6 \ -d $inner_prefix \ --state ESTABLISHED,RELATED --icmpv6-type packet-too-big \ -j ACCEPT done else # Allow incoming time exceeded code 0 messages for inner_prefix in $INNER_PREFIXES do ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \ --icmpv6-type ttl-zero-during-transit -j ACCEPT done fi
如果[“$STATE_ENABLED”-eq“1”]，则#允许传入超过时间的代码0消息#仅针对$internal_PREFIXES中的internal_PREFIXES的现有会话执行ip6tables-icmpv6筛选器-m STATE-p icmpv6 \-d$internal_prefix \-已建立状态，相关--icmpv6类型数据包太大\-j接受完成其他\#允许传入时间超过$INERNER_PREFIXS do ip6tables中INERNER_PREFIXS的代码0消息ip6tables-A icmpv6筛选器-p icmpv6-d$INERNER_prefix \-icmpv6类型ttl在传输期间为零-j接受完成fi
#@POLICY@ # Allow incoming time exceeded code 1 messages for inner_prefix in $INNER_PREFIXES do
#@策略@#允许$INERNER_前缀中的INERNER_前缀的传入时间超过代码1消息do
ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \
--icmpv6-type ttl-zero-during-reassembly -j ACCEPT
done
ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \
--icmpv6-type ttl-zero-during-reassembly -j ACCEPT
done
# Allow outgoing time exceeded code 0 messages for inner_prefix in $INNER_PREFIXES do ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \ --icmpv6-type ttl-zero-during-transit -j ACCEPT done
#允许超时$INERNAR_PREFIXES do ip6tables中的INERNAR_PREFIXES代码0消息-A icmpv6筛选器-p icmpv6-s$INERNAR_prefix \--icmpv6类型ttl zero在传输期间-j ACCEPT done
#@POLICY@
# Allow outgoing time exceeded code 1 messages
for inner_prefix in $INNER_PREFIXES
do
ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \
--icmpv6-type ttl-zero-during-reassembly -j ACCEPT
done
#@POLICY@
# Allow outgoing time exceeded code 1 messages
for inner_prefix in $INNER_PREFIXES
do
ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \
--icmpv6-type ttl-zero-during-reassembly -j ACCEPT
done
# PARAMETER PROBLEM ERROR MESSAGES
# ================================
# PARAMETER PROBLEM ERROR MESSAGES
# ================================
if [ "$STATE_ENABLED" -eq "1" ] then # Allow incoming parameter problem code 1 and 2 messages # for an existing session for inner_prefix in $INNER_PREFIXES do ip6tables -A icmpv6-filter -m state -p icmpv6 \ -d $inner_prefix \ --state ESTABLISHED,RELATED --icmpv6-type \ unknown-header-type \ -j ACCEPT ip6tables -A icmpv6-filter -m state -p icmpv6 \ -d $inner_prefix \ --state ESTABLISHED,RELATED \ --icmpv6-type unknown-option \ -j ACCEPT done fi
如果[“$STATE_ENABLED”-eq“1”]，则#允许传入参数问题代码1和2消息#对于$internal_PREFIXES do ip6tables中的internal_PREFIXES现有会话-icmpv6过滤器-m STATE-p icmpv6 \-d$internal_prefix \-已建立状态，相关--icmpv6类型\未知标头类型\-j接受ip6tables-一个icmpv6筛选器-m状态-p icmpv6 \-d$内部前缀\-状态已建立，相关\-icmpv6类型未知选项\-j接受已完成
# Allow outgoing parameter problem code 1 and code 2 messages
for inner_prefix in $INNER_PREFIXES
do
ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \
--icmpv6-type unknown-header-type -j ACCEPT
ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \
# Allow outgoing parameter problem code 1 and code 2 messages
for inner_prefix in $INNER_PREFIXES
do
ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \
--icmpv6-type unknown-header-type -j ACCEPT
ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \
--icmpv6-type unknown-option -j ACCEPT done
--icmpv6类型未知选项-j接受完成
#@POLICY@ # Allow incoming and outgoing parameter # problem code 0 messages for inner_prefix in $INNER_PREFIXES do ip6tables -A icmpv6-filter -p icmpv6 \ --icmpv6-type bad-header \ -j ACCEPT done
#@策略@#允许传入和传出参数#问题代码0$INERNER_PREFIXES do ip6tables中的INERNER_PREFIXES的消息ip6tables-A icmpv6筛选器-p icmpv6 \-icmpv6 type bad header \-j接受完成
# NEIGHBOR DISCOVERY MESSAGES
# ===========================
# NEIGHBOR DISCOVERY MESSAGES
# ===========================
# Drop NS/NA messages both incoming and outgoing
ip6tables -A icmpv6-filter -p icmpv6 \
--icmpv6-type neighbor-solicitation -j DROP
ip6tables -A icmpv6-filter -p icmpv6 \
--icmpv6-type neighbor-advertisement -j DROP
# Drop NS/NA messages both incoming and outgoing
ip6tables -A icmpv6-filter -p icmpv6 \
--icmpv6-type neighbor-solicitation -j DROP
ip6tables -A icmpv6-filter -p icmpv6 \
--icmpv6-type neighbor-advertisement -j DROP
# Drop RS/RA messages both incoming and outgoing
ip6tables -A icmpv6-filter -p icmpv6 \
--icmpv6-type router-solicitation -j DROP
ip6tables -A icmpv6-filter -p icmpv6 \
--icmpv6-type router-advertisement -j DROP
# Drop RS/RA messages both incoming and outgoing
ip6tables -A icmpv6-filter -p icmpv6 \
--icmpv6-type router-solicitation -j DROP
ip6tables -A icmpv6-filter -p icmpv6 \
--icmpv6-type router-advertisement -j DROP
# Drop Redirect messages both incoming and outgoing
ip6tables -A icmpv6-filter -p icmpv6 --icmpv6-type redirect -j DROP
# Drop Redirect messages both incoming and outgoing
ip6tables -A icmpv6-filter -p icmpv6 --icmpv6-type redirect -j DROP
# MLD MESSAGES
# ============
# MLD MESSAGES
# ============
# Drop incoming and outgoing
# Multicast Listener queries (MLDv1 and MLDv2)
ip6tables -A icmpv6-filter -p icmpv6 --icmpv6-type 130 -j DROP
# Drop incoming and outgoing
# Multicast Listener queries (MLDv1 and MLDv2)
ip6tables -A icmpv6-filter -p icmpv6 --icmpv6-type 130 -j DROP
# Drop incoming and outgoing Multicast Listener reports (MLDv1)
ip6tables -A icmpv6-filter -p icmpv6 --icmpv6-type 131 -j DROP
# Drop incoming and outgoing Multicast Listener reports (MLDv1)
ip6tables -A icmpv6-filter -p icmpv6 --icmpv6-type 131 -j DROP
# Drop incoming and outgoing Multicast Listener Done messages (MLDv1)
ip6tables -A icmpv6-filter -p icmpv6 --icmpv6-type 132 -j DROP
# Drop incoming and outgoing Multicast Listener Done messages (MLDv1)
ip6tables -A icmpv6-filter -p icmpv6 --icmpv6-type 132 -j DROP
# Drop incoming and outgoing Multicast Listener reports (MLDv2)
ip6tables -A icmpv6-filter -p icmpv6 --icmpv6-type 143 -j DROP
# Drop incoming and outgoing Multicast Listener reports (MLDv2)
ip6tables -A icmpv6-filter -p icmpv6 --icmpv6-type 143 -j DROP
# ROUTER RENUMBERING MESSAGES
#路由器对消息重新编号
# ===========================
# ===========================
# Drop router renumbering messages
ip6tables -A icmpv6-filter -p icmpv6 --icmpv6-type 138 -j DROP
# Drop router renumbering messages
ip6tables -A icmpv6-filter -p icmpv6 --icmpv6-type 138 -j DROP
# NODE INFORMATION QUERIES
# ========================
# NODE INFORMATION QUERIES
# ========================
# Drop node information queries (139) and replies (140)
ip6tables -A icmpv6-filter -p icmpv6 --icmpv6-type 139 -j DROP
ip6tables -A icmpv6-filter -p icmpv6 --icmpv6-type 140 -j DROP
# Drop node information queries (139) and replies (140)
ip6tables -A icmpv6-filter -p icmpv6 --icmpv6-type 139 -j DROP
ip6tables -A icmpv6-filter -p icmpv6 --icmpv6-type 140 -j DROP
# MOBILE IPv6 MESSAGES
# ====================
# MOBILE IPv6 MESSAGES
# ====================
# If there are mobile ipv6 home agents present on the
# trusted side allow
if [ "$HOME_AGENTS_PRESENT" -eq "1" ]
then
for inner_prefix in $INNER_PREFIXES
do
#incoming Home Agent address discovery request
ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \
--icmpv6-type 144 -j ACCEPT
#outgoing Home Agent address discovery reply
ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \
--icmpv6-type 145 -j ACCEPT
#incoming Mobile prefix solicitation
ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \
--icmpv6-type 146 -j ACCEPT
#outgoing Mobile prefix advertisement
ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \
--icmpv6-type 147 -j ACCEPT
done
fi
# If there are mobile ipv6 home agents present on the
# trusted side allow
if [ "$HOME_AGENTS_PRESENT" -eq "1" ]
then
for inner_prefix in $INNER_PREFIXES
do
#incoming Home Agent address discovery request
ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \
--icmpv6-type 144 -j ACCEPT
#outgoing Home Agent address discovery reply
ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \
--icmpv6-type 145 -j ACCEPT
#incoming Mobile prefix solicitation
ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \
--icmpv6-type 146 -j ACCEPT
#outgoing Mobile prefix advertisement
ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \
--icmpv6-type 147 -j ACCEPT
done
fi
# If there are roaming mobile nodes present on the
# trusted side allow
if [ "$MOBILE_NODES_PRESENT" -eq "1" ]
then
for inner_prefix in $INNER_PREFIXES
do
#outgoing Home Agent address discovery request
ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \
--icmpv6-type 144 -j ACCEPT
#incoming Home Agent address discovery reply
ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \
# If there are roaming mobile nodes present on the
# trusted side allow
if [ "$MOBILE_NODES_PRESENT" -eq "1" ]
then
for inner_prefix in $INNER_PREFIXES
do
#outgoing Home Agent address discovery request
ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \
--icmpv6-type 144 -j ACCEPT
#incoming Home Agent address discovery reply
ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \
--icmpv6-type 145 -j ACCEPT
#outgoing Mobile prefix solicitation
ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \
--icmpv6-type 146 -j ACCEPT
#incoming Mobile prefix advertisement
ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \
--icmpv6-type 147 -j ACCEPT
done
fi
--icmpv6-type 145 -j ACCEPT
#outgoing Mobile prefix solicitation
ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \
--icmpv6-type 146 -j ACCEPT
#incoming Mobile prefix advertisement
ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \
--icmpv6-type 147 -j ACCEPT
done
fi
# DROP EVERYTHING ELSE
# ====================
# DROP EVERYTHING ELSE
# ====================
ip6tables -A icmpv6-filter -p icmpv6 -j DROP
ip6tables -A icmpv6-filter -p icmpv6 -j DROP
Example Netfilter Configuration Script for ICMPv6 Filtering
用于ICMPv6筛选的Netfilter配置脚本示例
Authors' Addresses
作者地址
Elwyn B. Davies Consultant Soham, Cambs UK
Elwyn B.Davies咨询公司Soham，英国剑桥
Phone: +44 7889 488 335
EMail: elwynd@dial.pipex.com
Phone: +44 7889 488 335
EMail: elwynd@dial.pipex.com
Janos Mohacsi NIIF/HUNGARNET Victor Hugo u. 18-22 Budapest, H-1132 Hungary
雅诺斯·莫哈西·尼夫/亨加内特·维克托·雨果u。18-22布达佩斯，H-1132匈牙利
Phone: +36 1 4503070
EMail: mohacsi@niif.hu
Phone: +36 1 4503070
EMail: mohacsi@niif.hu
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编辑功能的资金目前由互联网协会提供。