Internet Engineering Task Force (IETF) F. Gont
Request for Comments: 7123 SI6 Networks/UTN-FRH
Category: Informational W. Liu
ISSN: 2070-1721 Huawei Technologies
February 2014
Internet Engineering Task Force (IETF) F. Gont
Request for Comments: 7123 SI6 Networks/UTN-FRH
Category: Informational W. Liu
ISSN: 2070-1721 Huawei Technologies
February 2014
Security Implications of IPv6 on IPv4 Networks
IPv6对IPv4网络的安全影响
Abstract
摘要
This document discusses the security implications of native IPv6 support and IPv6 transition/coexistence technologies on "IPv4-only" networks and describes possible mitigations for the aforementioned issues.
本文档讨论了“仅IPv4”网络上本机IPv6支持和IPv6转换/共存技术的安全影响，并描述了上述问题的可能缓解措施。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7123.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7123.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Security Implications of Native IPv6 Support . . . . . . . . 4
2.1. Filtering Native IPv6 Traffic . . . . . . . . . . . . . . 4
3. Security Implications of Tunneling Mechanisms . . . . . . . . 5
3.1. Filtering 6in4 . . . . . . . . . . . . . . . . . . . . . 6
3.2. Filtering 6over4 . . . . . . . . . . . . . . . . . . . . 7
3.3. Filtering 6rd . . . . . . . . . . . . . . . . . . . . . . 7
3.4. Filtering 6to4 . . . . . . . . . . . . . . . . . . . . . 8
3.5. Filtering ISATAP . . . . . . . . . . . . . . . . . . . . 9
3.6. Filtering Teredo . . . . . . . . . . . . . . . . . . . . 9
3.7. Filtering Tunnel Broker with Tunnel Setup Protocol (TSP) 11
3.8. Filtering AYIYA . . . . . . . . . . . . . . . . . . . . . 11
4. Additional Considerations when Filtering IPv6 Traffic . . . . 12
5. Security Considerations . . . . . . . . . . . . . . . . . . . 13
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.1. Normative References . . . . . . . . . . . . . . . . . . 13
7.2. Informative References . . . . . . . . . . . . . . . . . 14
Appendix A. Summary of Filtering Rules . . . . . . . . . . . . . 18
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Security Implications of Native IPv6 Support . . . . . . . . 4
2.1. Filtering Native IPv6 Traffic . . . . . . . . . . . . . . 4
3. Security Implications of Tunneling Mechanisms . . . . . . . . 5
3.1. Filtering 6in4 . . . . . . . . . . . . . . . . . . . . . 6
3.2. Filtering 6over4 . . . . . . . . . . . . . . . . . . . . 7
3.3. Filtering 6rd . . . . . . . . . . . . . . . . . . . . . . 7
3.4. Filtering 6to4 . . . . . . . . . . . . . . . . . . . . . 8
3.5. Filtering ISATAP . . . . . . . . . . . . . . . . . . . . 9
3.6. Filtering Teredo . . . . . . . . . . . . . . . . . . . . 9
3.7. Filtering Tunnel Broker with Tunnel Setup Protocol (TSP) 11
3.8. Filtering AYIYA . . . . . . . . . . . . . . . . . . . . . 11
4. Additional Considerations when Filtering IPv6 Traffic . . . . 12
5. Security Considerations . . . . . . . . . . . . . . . . . . . 13
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.1. Normative References . . . . . . . . . . . . . . . . . . 13
7.2. Informative References . . . . . . . . . . . . . . . . . 14
Appendix A. Summary of Filtering Rules . . . . . . . . . . . . . 18
Most general-purpose operating systems implement and enable native IPv6 [RFC2460] support and a number of transition/coexistence technologies by default. Support of IPv6 by all nodes is intended to become best current practice [RFC6540]. Some enterprise networks might, however, choose to delay active use of IPv6.
默认情况下，大多数通用操作系统实现并启用本机IPv6[RFC2460]支持和许多转换/共存技术。所有节点对IPv6的支持旨在成为当前最佳实践[RFC6540]。但是，一些企业网络可能会选择延迟IPv6的主动使用。
This document describes operational practices to prevent security exposure in enterprise networks resulting from unplanned use of IPv6 on such networks. This document is only applicable to enterprise networks: networks where the network operator is not providing a general-purpose internet, but rather a business-specific network. The solutions proposed here are not practical for home networks, nor are they appropriate for provider networks such as ISPs, mobile providers, WiFi hotspot providers, or any other public internet service.
本文档描述了防止企业网络因在此类网络上意外使用IPv6而导致安全暴露的操作实践。本文件仅适用于企业网络：网络运营商不提供通用互联网，而是提供特定业务网络的网络。此处提出的解决方案不适用于家庭网络，也不适用于提供商网络，如ISP、移动提供商、WiFi热点提供商或任何其他公共互联网服务。
In scenarios in which IPv6-enabled devices are deployed on enterprise networks that are intended to be IPv4-only, native IPv6 support and/ or IPv6 transition/coexistence technologies could be leveraged by local or remote attackers for a number of (illegitimate) purposes. For example,
在将启用IPv6的设备部署在仅用于IPv4的企业网络上的场景中，本地或远程攻击者可能会利用本机IPv6支持和/或IPv6转换/共存技术来达到许多（非法）目的。例如
o A Network Intrusion Detection System (NIDS) might be prepared to detect attack patterns for IPv4 traffic, but might be unable to detect the same attack patterns when a transition/coexistence technology is leveraged for that purpose.
o 网络入侵检测系统（NIDS）可能已准备好检测IPv4流量的攻击模式，但在为此目的利用转换/共存技术时，可能无法检测相同的攻击模式。
o An IPv4 firewall might enforce a specific security policy in IPv4, but might be unable to enforce the same policy in IPv6.
o IPv4防火墙可能在IPv4中强制执行特定的安全策略，但可能无法在IPv6中强制执行相同的策略。
o A NIDS or firewall might support both IPv4 and IPv6, but might not be configured to enforce on IPv6 traffic the same controls/ policies it enforces on IPv4 traffic.
o NIDS或防火墙可能同时支持IPv4和IPv6，但可能未配置为在IPv6流量上实施它在IPv4流量上实施的相同控制/策略。
o Some transition/coexistence mechanisms could cause an internal host with otherwise limited IPv4 connectivity to become globally reachable over IPv6, therefore resulting in increased (and possibly unexpected) host exposure.
o 某些转换/共存机制可能会导致IPv4连接受限的内部主机在IPv6上全局可访问，从而导致主机暴露增加（可能是意外的）。
NOTE: Some transition/coexistence mechanisms (notably Teredo) are designed to traverse Network Address Port Translation (NAPT) [RFC2663] devices, allowing incoming IPv6 connections from the Internet to hosts behind the organizational firewall or NAPT (which in many deployments provides a minimum level of protection by only allowing those instances of communication that have been initiated from the internal network).
注意：一些转换/共存机制（特别是Teredo）设计用于遍历网络地址端口转换（NAPT）[RFC2663]设备，允许从Internet到组织防火墙或NAPT后面的主机的传入IPv6连接（在许多部署中，仅允许从内部网络启动的通信实例，从而提供最低级别的保护）。
o IPv6 support could, either inadvertently or as a result of a deliberate attack, result in Virtual Private Network (VPN) traffic leaks if IPv6-unaware VPN software is employed by dual-stacked hosts [VPN-LEAKS].
o 如果双堆叠主机使用IPv6非感知VPN软件[VPN-leaks]，IPv6支持可能会无意中或由于蓄意攻击而导致虚拟专用网络（VPN）流量泄漏。
In general, most of the aforementioned security implications can be mitigated by enforcing security controls on native IPv6 traffic and on IPv4-tunneled IPv6 traffic. Among such controls, is the enforcement of filtering policies to block undesirable traffic. While IPv6 widespread/global IPv6 deployment has been slower than expected, it is nevertheless happening; and thus, filtering IPv6 traffic (whether native or transition/coexistence) to mitigate IPv6 security implications on IPv4 networks should (generally) only be considered as a temporary measure until IPv6 is deployed.
通常，通过对本机IPv6流量和IPv4隧道IPv6流量实施安全控制，可以减轻上述大部分安全影响。在这些控制措施中，包括强制执行过滤策略以阻止不良流量。虽然IPv6广泛/全球IPv6部署的速度比预期的慢，但它仍在发生；因此，在部署IPv6之前，过滤IPv6流量（无论是本机流量还是转换/共存流量）以减轻IPv6对IPv4网络的安全影响（通常）只应被视为临时措施。
NOTE: The aforementioned security controls should contemplate not only network-based solutions, but also host-based solutions (such as, e.g., personal firewalls).
注：上述安全控制不仅应考虑基于网络的解决方案，还应考虑基于主机的解决方案（例如，个人防火墙）。
Most popular operating systems include IPv6 support that is enabled by default. This means that even if a network is expected to be IPv4-only, much of its infrastructure is nevertheless likely to be IPv6-enabled. For example, hosts are likely to have at least link-local IPv6 connectivity, which might be exploited by attackers with access to the local network.
大多数流行的操作系统包括默认启用的IPv6支持。这意味着，即使网络预期仅为IPv4，其大部分基础设施仍可能启用IPv6。例如，主机可能至少具有链路本地IPv6连接，这可能被访问本地网络的攻击者利用。
Additionally, unless appropriate measures are taken, an attacker with access to an "IPv4-only" local network could impersonate a local router and cause local hosts to enable their 'non-link-local' IPv6 connectivity (e.g., by sending Router Advertisement messages), possibly circumventing security controls that were enforced only on IPv4 communications.
此外，除非采取适当措施，否则访问“仅IPv4”本地网络的攻击者可能会模拟本地路由器并使本地主机启用其“非链路本地”IPv6连接（例如，通过发送路由器广告消息），可能会绕过仅在IPv4通信上实施的安全控制。
NOTE: [THC-IPV6] and [IPv6-Toolkit] include tools that implement this attack vector (along with many others). [Waters2011] provides an example of how this could be achieved using publicly available tools.
注意：[THC-IPV6]和[IPv6工具包]包含实现此攻击向量的工具（以及许多其他）。[Waters2011]提供了一个示例，说明如何使用公开可用的工具实现这一点。
Native IPv6 support could also possibly lead to VPN-traffic leakages when hosts employ VPN software that, not only does not support IPv6, but does nothing about IPv6 traffic. [VPN-LEAKS] describes this issue, along with possible mitigations.
当主机使用VPN软件时，本机IPv6支持也可能导致VPN流量泄漏，该软件不仅不支持IPv6，而且对IPv6流量一无所知。[VPN-LEAKS]描述了此问题以及可能的缓解措施。
In general, networks should enforce on native IPv6 traffic the same security policies currently enforced on IPv4 traffic. However, in those networks in which IPv6 has not yet been deployed and enforcing the aforementioned policies is deemed as infeasible, a network administrator might mitigate IPv6-based attack vectors by means of appropriate packet filtering.
通常，网络应在本机IPv6流量上实施与当前在IPv4流量上实施的相同的安全策略。然而，在那些尚未部署IPv6的网络中，实施上述策略被认为是不可行的，网络管理员可以通过适当的包过滤来缓解基于IPv6的攻击向量。
Some layer-2 devices might have the ability to selectively filter packets based on the type of layer-2 payload. When such functionality is available, IPv6 traffic could be blocked at those layer-2 devices by blocking, for example, Ethernet frames with the Protocol Type field set to 0x86dd [IANA-ETHER]. We note, however, that blocking IPv6 at layer-2 might create problems that are difficult to diagnose, inclusive of intentional or incidental use of link-local addressing (as in Multicast DNS/DNS-based Service Discovery [RFC6762] [RFC6763]); sites that enforce such a filtering policy should keep that possibility in mind when debugging the network.
一些第二层设备可能具有基于第二层有效载荷的类型选择性地过滤分组的能力。当此类功能可用时，可以通过阻止（例如）协议类型字段设置为0x86dd[IANA-ETHER]的以太网帧来阻止这些第2层设备上的IPv6通信。然而，我们注意到，在第2层阻止IPv6可能会产生难以诊断的问题，包括故意或偶然使用链路本地寻址（如在基于DNS/DNS的多播服务发现[RFC6762][RFC6763]中）；在调试网络时，实施这种过滤策略的站点应该记住这种可能性。
Attacks based on Stateless Address Autoconfiguration (SLAAC) [RFC3756] can be mitigated with technologies such as Router Advertisement Guard (RA-Guard) [RFC6105] [RA-GRD-IMP]. In a similar way, DHCPv6-based attacks can be mitigated with technologies such as DHCPv6-Shield [SHIELD]. However, both RA-Guard and DHCPv6-Shield are incapable of mitigating attack vectors that employ IPv6 link-local addresses, since configuration of such addresses does not rely on Router Advertisement messages or DHCPv6-server messages.
基于无状态地址自动配置（SLAAC）[RFC3756]的攻击可以通过路由器广告防护（RA防护）[RFC6105][RA-GRD-IMP]等技术来缓解。类似地，基于DHCPv6的攻击可以通过DHCPv6 Shield[Shield]等技术来缓解。然而，RA Guard和DHCPv6 Shield都无法缓解使用IPv6链路本地地址的攻击向量，因为此类地址的配置不依赖于路由器广告消息或DHCPv6服务器消息。
Administrators considering the filtering of native IPv6 traffic at layer-3 devices are urged to pay attention to the general considerations for IPv6 traffic filtering discussed in Section 4.
敦促考虑在第3层设备上过滤本机IPv6流量的管理员注意第4节中讨论的IPv6流量过滤的一般注意事项。
NOTE: If native IPv6 traffic is filtered at layer-2, local IPv6 nodes would only get to configure IPv6 link-local addresses.
注意：如果在第2层过滤本机IPv6流量，则本地IPv6节点只能配置IPv6链路本地地址。
In order to mitigate attacks based on native IPv6 traffic, IPv6 security controls should be enforced on both IPv4 and IPv6 networks. The aforementioned controls might include: deploying IPv6-enabled NIDS, implementing IPv6 firewalling, etc.
为了减轻基于本机IPv6流量的攻击，应在IPv4和IPv6网络上实施IPv6安全控制。上述控制措施可能包括：部署支持IPv6的NID、实施IPv6防火墙等。
NOTE: In some very specific scenarios (e.g., military operations networks) in which only IPv4 service might be desired, a network administrator might want to disable IPv6 support in all the communicating devices.
注意：在某些可能只需要IPv4服务的非常特定的场景（例如军事行动网络）中，网络管理员可能希望在所有通信设备中禁用IPv6支持。
Unless properly managed, tunneling mechanisms might result in negative security implications. For example, they might increase host exposure, might be leveraged to evade security controls, might contain protocol-based vulnerabilities, and/or the corresponding code might contain bugs with security implications.
除非管理得当，否则隧道机制可能会导致负面的安全影响。例如，它们可能增加主机暴露，可能被用来逃避安全控制，可能包含基于协议的漏洞，和/或相应的代码可能包含具有安全隐患的错误。
NOTE: [RFC6169] describes the security implications of tunneling mechanisms in detail. Of the plethora of tunneling mechanisms that have so far been standardized and widely implemented, the so-called "automatic tunneling" mechanisms (such as Teredo, Intra-Site Automatic Tunnel Addressing Protocol (ISATAP), and 6to4) are of particular interest from a security standpoint, since they might be employed without prior consent or action of the user or network administrator.
注：[RFC6169]详细描述了隧道机制的安全含义。在迄今为止已被标准化和广泛实施的大量隧道机制中，从安全角度来看，所谓的“自动隧道”机制（如Teredo、站点内自动隧道寻址协议（ISATAP）和6to4）尤其令人感兴趣，因为他们可能在未经用户或网络管理员事先同意或采取行动的情况下被雇用。
Tunneling mechanisms should be a concern not only to network administrators that have consciously deployed them, but also to those who have not deployed them, as these mechanisms might be leveraged to bypass their security policies.
隧道机制不仅应该引起有意识地部署它们的网络管理员的关注，也应该引起尚未部署它们的网络管理员的关注，因为这些机制可能被用来绕过它们的安全策略。
NOTE: [CERT2009] contains some examples of how tunnels can be leveraged to bypass firewall rules.
注意：[CERT2009]包含一些示例，说明如何利用隧道绕过防火墙规则。
The aforementioned issues could be mitigated by applying the common security practice of only allowing traffic deemed as "necessary" (i.e., the so-called "default deny" policy). Thus, when such policy is enforced, IPv6 transition/coexistence traffic would be blocked by default and would only be allowed as a result of an explicit decision.
通过应用仅允许被视为“必要”的流量的通用安全实践（即所谓的“默认拒绝”策略），可以缓解上述问题。因此，当强制执行此类策略时，IPv6转换/共存流量将在默认情况下被阻止，并且仅在明确决定的情况下才被允许。
NOTE: It should be noted that this type of policy is usually enforced on a network that is the target of such traffic (such as an enterprise network). IPv6 transition traffic should generally never be filtered, e.g., by an ISP when it is transit traffic.
注意：应该注意的是，这种类型的策略通常在此类流量的目标网络（如企业网络）上实施。IPv6转换流量通常不应被过滤，例如，当它是传输流量时，ISP会对其进行过滤。
In those scenarios in which transition/coexistence traffic is meant to be blocked, it is highly recommended that, in addition to the enforcement of filtering policies at the organizational perimeter, the corresponding transition/coexistence mechanisms be disabled on each node connected to the organizational network. This would not only prevent security breaches resulting from accidental use of these mechanisms, but would also disable this functionality altogether, possibly mitigating vulnerabilities that might be present in the host implementation of these transition/coexistence mechanisms.
在那些要阻止过渡/共存流量的场景中，强烈建议除了在组织外围强制实施过滤策略外，在连接到组织网络的每个节点上禁用相应的过渡/共存机制。这不仅可以防止因意外使用这些机制而导致的安全漏洞，还可以完全禁用此功能，可能会减少这些转换/共存机制的主机实现中可能存在的漏洞。
IPv6-in-IPv4 tunneling mechanisms (such as 6to4 or configured tunnels) can generally be blocked by dropping IPv4 packets that contain a Protocol field set to 41. Security devices such as NIDS might also include signatures that detect such transition/coexistence traffic.
IPv6-in-IPv4隧道机制（如6to4或配置的隧道）通常可以通过丢弃包含设置为41的协议字段的IPv4数据包来阻止。诸如NID之类的安全设备还可能包括检测此类转换/共存流量的签名。
Administrators considering the filtering of transition/coexistence traffic are urged to pay attention to the general considerations for IPv6 traffic filtering discussed in Section 4.
敦促考虑过渡/共存流量过滤的管理员注意第4节中讨论的IPv6流量过滤的一般注意事项。
We note that this document only covers standardized IPv6 tunneling mechanisms; it does not aim to cover non-standard tunneling mechanisms or tunneling based on IPsec [RFC4301] or on SSL/TLS [RFC5246] [RFC6101].
我们注意到，本文件仅涵盖标准化IPv6隧道机制；其目的不在于涵盖基于IPsec[RFC4301]或SSL/TLS[RFC5246][RFC6101]的非标准隧道机制或隧道。
Probably the most basic type of tunnel employed for connecting IPv6 "islands" is the so-called "6in4", in which IPv6 packets are encapsulated within IPv4 packets. These tunnels typically result from manual configuration at the two tunnel endpoints.
可能用于连接IPv6“孤岛”的最基本类型的隧道是所谓的“6in4”，其中IPv6数据包封装在IPv4数据包中。这些隧道通常由两个隧道端点处的手动配置产生。
6in4 tunnels can be blocked by blocking IPv4 packets with a Protocol field of 41.
6in4隧道可以通过使用协议字段41阻止IPv4数据包来阻止。
[RFC2529] specifies a mechanism known as 6over4 or 'IPv6 over IPv4' (or colloquially as 'virtual Ethernet'), which comprises a set of mechanisms and policies to allow isolated IPv6 hosts located on physical links with no directly connected IPv6 router to become fully functional IPv6 hosts by using an IPv4 domain that supports IPv4 multicast as their virtual local link.
[RFC2529]指定一种称为6over4或“IPv6 overipv4”（或通俗地称为“虚拟以太网”）的机制，它包含一组机制和策略，通过使用支持IPv4多播的IPv4域作为其虚拟本地链路，允许位于物理链路上且没有直接连接IPv6路由器的孤立IPv6主机成为功能齐全的IPv6主机。
NOTE: This transition technology has never been widely deployed because of the low level of deployment of multicast in most networks.
注意：由于大多数网络中多播的部署水平较低，因此这种过渡技术从未被广泛部署。
6over4 encapsulates IPv6 packets in IPv4 packets with their Protocol field set to 41. As a result, simply filtering all IPv4 packets that have a Protocol field equal to 41 will filter 6over4 (along with many other transition technologies).
6over4将IPv6数据包封装在IPv4数据包中，其协议字段设置为41。因此，只需过滤协议字段等于41的所有IPv4数据包，即可过滤6over4（以及许多其他转换技术）。
A more selective filtering could be enforced such that 6over4 traffic is filtered while other transition traffic is still allowed. Such a filtering policy would block all IPv4 packets that have their Protocol field set to 41, and that have a Destination Address that belongs to the prefix 239.0.0.0/8.
可以实施更具选择性的过滤，以便在仍然允许其他过渡流量的情况下过滤6over4流量。这种过滤策略将阻止所有协议字段设置为41且目标地址属于前缀239.0.0.0/8的IPv4数据包。
This filtering policy basically blocks 6over4 Neighbor Discovery traffic directed to multicast addresses, thus preventing SLAAC, address resolution, etc. Additionally, it would prevent the 6over4 multicast addresses from being leveraged for the purpose of network reconnaissance.
此过滤策略基本上会阻止指向多播地址的6over4邻居发现通信，从而防止SLAAC、地址解析等。此外，它还将防止6over4多播地址被用于网络侦察。
6rd builds upon the mechanisms of 6to4 to enable the rapid deployment of IPv6 on IPv4 infrastructures, while avoiding some downsides of 6to4. Usage of 6rd was originally documented in [RFC5569], and the mechanism was generalized to other access technologies and formally standardized in [RFC5969].
6rd以6to4的机制为基础，支持在IPv4基础设施上快速部署IPv6，同时避免了6to4的一些缺点。6rd的使用最初记录在[RFC5569]中，该机制被推广到其他访问技术，并在[RFC5969]中正式标准化。
6rd can be blocked by blocking IPv4 packets with the Protocol field set to 41.
通过将协议字段设置为41阻止IPv4数据包，可以阻止第6rd。
6to4 [RFC3056] is an address assignment and router-to-router, host-to-router, and router-to-host automatic tunneling mechanism that is meant to provide IPv6 connectivity between IPv6 sites and hosts across the IPv4 Internet.
6to4[RFC3056]是一种地址分配和路由器到路由器、主机到路由器和路由器到主机的自动隧道机制，旨在通过IPv4 Internet在IPv6站点和主机之间提供IPv6连接。
NOTE: The security considerations for 6to4 are discussed in detail in [RFC3964]. [RFC6343] provides advice to network operators about 6to4 (some of which relates to security mitigations).
注：6to4的安全注意事项在[RFC3964]中有详细讨论。[RFC6343]向网络运营商提供有关6to4的建议（其中一些与安全缓解措施有关）。
As discussed in Section 3, all IPv6-in-IPv4 traffic, including 6to4, could be easily blocked by filtering IPv4 packets that contain their Protocol field set to 41. This is the most effective way of filtering such traffic.
如第3节所述，通过过滤包含其协议字段设置为41的IPv4数据包，可以轻松阻止所有IPv6-in-IPv4流量，包括6to4。这是过滤此类流量的最有效方法。
If 6to4 traffic is meant to be filtered while other IPv6-in-IPv4 traffic is allowed, then more finer-grained filtering rules could be applied. For example, 6to4 traffic could be filtered by applying filtering rules such as:
如果要过滤6to4流量，而允许其他IPv6-in-IPv4流量，则可以应用更细粒度的过滤规则。例如，可以通过应用过滤规则来过滤6to4流量，例如：
o Filter outgoing IPv4 packets that have the Destination Address set to an address that belongs to the prefix 192.88.99.0/24.
o 筛选将目标地址设置为属于前缀192.88.99.0/24的地址的传出IPv4数据包。
o Filter incoming IPv4 packets that have the Source Address set to an address that belongs to the prefix 192.88.99.0/24.
o 筛选将源地址设置为属于前缀192.88.99.0/24的地址的传入IPv4数据包。
NOTE: These rules assume that the corresponding nodes employ the "Anycast Prefix for 6to4 Relay Routers" [RFC3068]. It has been suggested that 6to4 relays send their packets with their IPv4 Source Address set to 192.88.99.1.
注意：这些规则假设相应的节点使用“6to4中继路由器的选播前缀”[RFC3068]。有人建议6to4中继发送其IPv4源地址设置为192.88.99.1的数据包。
o Filter outgoing IPv4 packets that have the Destination Address set to the IPv4 address of well-known 6to4 relays.
o 筛选目标地址设置为已知6to4中继的IPv4地址的传出IPv4数据包。
o Filter incoming IPv4 packets that have the Source Address set to the IPv4 address of well-known 6to4 relays.
o 筛选将源地址设置为已知6to4中继的IPv4地址的传入IPv4数据包。
These last two filtering policies will generally be unnecessary, and possibly infeasible to enforce (given the number of potential 6to4 relays, and the fact that many relays might remain unknown to the network administrator). If anything, they should be applied with the additional requirement that such IPv4 packets have their Protocol field set to 41 to avoid the case where other services available at the same IPv4 address as a 6to4 relay are mistakenly made inaccessible.
最后两个过滤策略通常是不必要的，并且可能无法实施（考虑到潜在的6to4中继的数量，以及网络管理员可能不知道许多中继的事实）。如果有什么不同的话，那么应该附加一个要求，即这些IPv4数据包的协议字段设置为41，以避免在与6to4中继相同的IPv4地址上可用的其他服务被错误地设置为不可访问。
If the filtering device has capabilities to inspect the payload of IPv4 packets, then the following filtering rules could be enforced:
如果过滤设备能够检查IPv4数据包的有效负载，则可以强制执行以下过滤规则：
o Filter outgoing IPv4 packets that have their Protocol field set to 41, and that have an IPv6 Source Address (embedded in the IPv4 payload) that belongs to the prefix 2002::/16.
o 筛选协议字段设置为41且IPv6源地址（嵌入IPv4有效负载中）属于前缀2002:：/16的传出IPv4数据包。
o Filter incoming IPv4 packets that have their Protocol field set to 41, and that have an IPv6 Destination address (embedded in the IPv4 payload) that belongs to the prefix 2002::/16.
o 筛选协议字段设置为41且IPv6目标地址（嵌入IPv4有效负载中）属于前缀2002:：/16的传入IPv4数据包。
ISATAP [RFC5214] is an Intra-site tunneling protocol, and thus it is generally expected that such traffic will not traverse the organizational firewall of an IPv4-only network. Nevertheless, ISATAP can be easily blocked by blocking IPv4 packets with a Protocol field of 41.
ISATAP[RFC5214]是一种站点内隧道协议，因此通常预期此类流量不会穿越仅IPv4网络的组织防火墙。然而，ISATAP可以通过使用协议字段41阻止IPv4数据包来轻松阻止。
The most popular operating system that includes an implementation of ISATAP in the default installation is Microsoft Windows. Microsoft Windows obtains the ISATAP router address by resolving the domain name isatap.<localdomain> to DNS A resource records. Additionally, it tries to learn the ISATAP router address by employing Link-Local Multicast Name Resolution (LLMNR) [RFC4795] to resolve the name "isatap". As a result, blocking ISATAP by preventing hosts from successfully performing name resolution for the aforementioned names and/or by filtering packets with specific IPv4 destination addresses is both difficult and undesirable.
默认安装中包含ISATAP实现的最流行的操作系统是Microsoft Windows。Microsoft Windows通过将域名ISATAP.<localdomain>解析为DNS A资源记录来获取ISATAP路由器地址。此外，它试图通过使用链路本地多播名称解析（LLMNR）[RFC4795]来解析名称“ISATAP”，从而学习ISATAP路由器地址。因此，通过阻止主机成功执行上述名称的名称解析和/或通过过滤具有特定IPv4目标地址的数据包来阻止ISATAP既困难又不可取。
Teredo [RFC4380] is an address assignment and automatic tunneling technology that provides IPv6 connectivity to dual-stack nodes that are behind one or more Network Address Port Translation (NAPT) [RFC2663] devices, by encapsulating IPv6 packets in IPv4-based UDP datagrams. Teredo is meant to be a 'last-resort' IPv6 connectivity technology, to be used only when other technologies such as 6to4 cannot be deployed (e.g., because the edge device has not been assigned a public IPv4 address).
Teredo[RFC4380]是一种地址分配和自动隧道技术，通过将IPv6数据包封装在基于IPv4的UDP数据报中，为一个或多个网络地址端口转换（NAPT）[RFC2663]设备后面的双堆栈节点提供IPv6连接。Teredo是一种“万不得已”的IPv6连接技术，仅在无法部署其他技术（如6to4）时使用（例如，因为边缘设备尚未分配公共IPv4地址）。
As noted in [RFC4380], in order for a Teredo client to configure its Teredo IPv6 address, it must contact a Teredo server through the Teredo service port (UDP port number 3544).
如[RFC4380]中所述，为了让Teredo客户端配置其Teredo IPv6地址，它必须通过Teredo服务端口（UDP端口号3544）与Teredo服务器联系。
To prevent the Teredo initialization process from succeeding, and hence prevent the use of Teredo, an organizational firewall could filter outgoing UDP packets with a Destination Port of 3544.
为了防止Teredo初始化过程成功，从而防止Teredo的使用，组织防火墙可以过滤目标端口为3544的传出UDP数据包。
NOTE: It is clear that such a filtering policy does not prevent an attacker from running its own Teredo server in the public Internet, using a non-standard UDP port for the Teredo service port (i.e., a port number other than 3544).
注意：很明显，这种过滤策略不会阻止攻击者在公共Internet上运行自己的Teredo服务器，使用Teredo服务端口的非标准UDP端口（即3544以外的端口号）。
If the filtering device has capabilities to inspect the payload of IPv4 packets, the following (additional) filtering policy could be enforced:
如果筛选设备能够检查IPv4数据包的有效负载，则可以强制执行以下（附加）筛选策略：
o Filter outgoing IPv4/UDP packets that embed an IPv6 packet with the "Version" field set to 6, and an IPv6 Source Address that belongs to the prefix 2001::/32.
o 筛选嵌入IPv6数据包的传出IPv4/UDP数据包，该数据包的“版本”字段设置为6，并且IPv6源地址属于前缀2001:：/32。
o Filter incoming IPv4/UDP packets that embed an IPv6 packet with the "Version" field set to 6, and an IPv6 Destination Address that belongs to the prefix 2001::/32.
o 筛选嵌入IPv6数据包的传入IPv4/UDP数据包，该数据包的“版本”字段设置为6，并且IPv6目标地址属于前缀2001:：/32。
NOTE: These two filtering rules could, at least in theory, result in false positives. Additionally, they would generally require the filtering device to reassemble fragments prior to enforcing filtering rules, since the information required to enforce them might be missing in the received fragments (which should be expected if Teredo is being employed for malicious purposes).
注意：至少在理论上，这两个过滤规则可能导致误报。此外，它们通常会要求过滤设备在强制执行过滤规则之前重新组装片段，因为强制执行规则所需的信息可能会在接收到的片段中丢失（如果Teredo被用于恶意目的，这应该是意料之中的）。
The most popular operating system that includes an implementation of Teredo in the default installation is Microsoft Windows. Microsoft Windows obtains the Teredo server addresses (primary and secondary) by resolving the domain name teredo.ipv6.microsoft.com into DNS A records. A network administrator might want to prevent Microsoft Windows hosts from obtaining Teredo service by filtering, at the organizational firewall, outgoing UDP datagrams (i.e., IPv4 packets with the Protocol field set to 17) that contain in the IPv4 Destination Address any of the IPv4 addresses that the domain name teredo.ipv6.microsoft.com maps to (or the IPv4 address of any well-known Teredo server). Additionally, the firewall would filter incoming UDP datagrams from any of the IPv4 addresses to which the domain names of well-known Teredo servers (such as teredo.ipv6.microsoft.com) resolve.
默认安装中包含Teredo实现的最流行的操作系统是Microsoft Windows。Microsoft Windows通过将域名Teredo.ipv6.Microsoft.com解析为DNS A记录来获取Teredo服务器地址（主要和次要）。网络管理员可能希望通过在组织防火墙上过滤传出的UDP数据报（即，协议字段设置为17的IPv4数据包），阻止Microsoft Windows主机获取Teredo服务在IPv4目标地址中包含域名teredo.ipv6.microsoft.com映射到的任何IPv4地址（或任何知名teredo服务器的IPv4地址）。此外，防火墙将过滤来自知名Teredo服务器（如Teredo.ipv6.microsoft.com）域名解析的任何IPv4地址的传入UDP数据报。
NOTE: As these IPv4 addresses might change over time, an administrator should obtain these addresses when implementing the filtering policy, and should also be prepared to keep this list up to date. The corresponding addresses can be easily obtained from a UNIX host by issuing the command 'dig teredo.ipv6.microsoft.com a' (without quotes), where dig(1) is a free-software tool (part of the "dnsutils" package) produced by the Internet Software Consortium (ISC).
注意：由于这些IPv4地址可能会随着时间的推移而改变，管理员应在实施筛选策略时获取这些地址，并且还应准备使此列表保持最新。通过发出命令“dig teredo.ipv6.microsoft.com a”（不带引号），可以很容易地从UNIX主机获得相应的地址，其中dig（1）是由Internet软件联盟（ISC）生产的自由软件工具（“dnsutils”包的一部分）。
It should be noted that even with all these filtering policies in place, a node in the internal network might still be able to communicate with some Teredo clients. That is, it could configure an IPv6 address itself (without even contacting a Teredo server), and it might send Teredo traffic to those peers for which intervention of the host's Teredo server is not required (e.g., Teredo clients behind a cone NAT).
应该注意的是，即使有了所有这些过滤策略，内部网络中的节点仍然可以与一些Teredo客户端通信。也就是说，它可以自行配置IPv6地址（甚至不联系Teredo服务器），并且它可以向不需要主机Teredo服务器干预的对等方发送Teredo流量（例如，cone NAT后面的Teredo客户端）。
The tunnel broker model enables dynamic configuration of tunnels between a tunnel client and a tunnel server. The tunnel broker provides a control channel for creating, deleting, or updating a tunnel between the tunnel client and the tunnel server. Additionally, the tunnel broker may register the user's IPv6 address and name in the DNS. Once the tunnel is configured, data can flow between the tunnel client and the tunnel server. [RFC3053] describes the tunnel broker model, while [RFC5572] specifies the Tunnel Setup Protocol (TSP), which can be used by clients to communicate with the Tunnel Broker.
隧道代理模型支持在隧道客户端和隧道服务器之间动态配置隧道。隧道代理提供用于在隧道客户端和隧道服务器之间创建、删除或更新隧道的控制通道。此外，隧道代理可以在DNS中注册用户的IPv6地址和名称。配置隧道后，数据可以在隧道客户端和隧道服务器之间流动。[RFC3053]描述了隧道代理模型，[RFC5572]指定了隧道设置协议（TSP），客户端可以使用该协议与隧道代理进行通信。
TSP can use either TCP or UDP as the transport protocol. In both cases, TSP uses port number 3653, which has been assigned by the IANA for this purpose. As a result, TSP (the Tunnel Broker control channel) can be blocked by blocking TCP and UDP packets originating from the local network and destined to UDP port 3653 or TCP port 3653. Additionally, the data channel can be blocked by blocking UDP packets originated from the local network and destined to UDP port 3653, and IPv4 packets with a Protocol field set to 41.
TSP可以使用TCP或UDP作为传输协议。在这两种情况下，TSP都使用IANA为此指定的端口号3653。因此，TSP（隧道代理控制通道）可以通过阻止来自本地网络并发送到UDP端口3653或TCP端口3653的TCP和UDP数据包来阻止。此外，可以通过阻止源自本地网络且目的地为UDP端口3653的UDP数据包和协议字段设置为41的IPv4数据包来阻止数据信道。
AYIYA ("Anything In Anything") [AYIYA] allows the tunneling of packets across Network Address Port Translation (NAPT) [RFC2663] devices. While the specification of this tunneling mechanism was never published as an RFC, it is nevertheless widely deployed [SixXS-stats].
AYIYA（“任何事物中的任何事物”）[AYIYA]允许通过网络地址端口转换（NAPT）[RFC2663]设备对数据包进行隧道传输。虽然该隧道机制的规范从未作为RFC发布，但它仍被广泛部署[SixXS stats]。
AYIYA can be blocked by blocking TCP and UDP packets originating from the local network and destined to UDP port 5072 or TCP port 5072.
可以通过阻止来自本地网络并发送到UDP端口5072或TCP端口5072的TCP和UDP数据包来阻止AYIYA。
IPv6 deployments in the Internet are continually increasing, and some hosts default to preferring IPv6 connectivity whenever it is available. This is likely to cause IPv6-capable hosts to attempt to reach an ever-increasing number of popular destinations via IPv6, even if this IPv6 connectivity relies on a transition technology over an "IPv4-only" network.
Internet中的IPv6部署不断增加，一些主机默认在IPv6连接可用时优先使用。这可能会导致支持IPv6的主机尝试通过IPv6到达越来越多的流行目的地，即使这种IPv6连接依赖于“仅IPv4”网络上的转换技术。
A large source of IPv6 brokenness today comes from nodes that believe that they have functional IPv6 connectivity, but the path to their destination fails somewhere upstream [Anderson2010] [Anderson2011] [Huston2010b] [Huston2012]. Upstream filtering of transition technologies or situations where a misconfigured node attempts to "provide" native IPv6 service on a given network without proper upstream IPv6 connectivity may result in hosts attempting to reach remote nodes via IPv6, and depending on the absence or presence and specific implementation details of "Happy Eyeballs" [RFC6555], there might be a non-trivial timeout period before the host falls back to IPv4 [Huston2010a] [Huston2012].
如今，IPv6断开的一个主要原因是节点认为它们具有功能性IPv6连接，但到达其目的地的路径在上游某个地方出现故障[Anderson2010][Anderson2011][Huston2010b][Huston2012]。过渡技术的上游过滤或配置错误的节点试图在给定网络上“提供”本机IPv6服务而没有适当的上游IPv6连接的情况可能会导致主机试图通过IPv6到达远程节点，具体情况取决于“快乐眼球”的缺失或存在以及具体实施细节[RFC6555]，在主机返回IPv4[Huston2010a][Huston2012]之前，可能会有一个非常重要的超时时间。
For this reason, networks attempting to prevent IPv6 traffic from traversing their devices should consider configuring their local recursive DNS servers to respond to queries for AAAA DNS records with a DNS RCODE of 0 (NOERROR) [RFC1035] or to silently ignore such queries, and should even consider filtering AAAA records at the network ingress point to prevent the internal hosts from attempting their own DNS resolution. This will ensure that hosts that are on an "IPv4-only" network will only receive DNS A records, and they will be unlikely to attempt to use (likely broken) IPv6 connectivity to reach their desired destinations.
出于这个原因，试图阻止IPv6流量穿越其设备的网络应该考虑配置其本地递归DNS服务器，以响应具有0（NoCurror）的DNS RDCOR[RBC1035]的AAAA DNS记录的查询，或者默默地忽略这样的查询，甚至应该考虑在网络入口点过滤AAAA记录，以防止内部主机尝试自己的DNS解析。这将确保位于“仅IPv4”网络上的主机将只接收DNS A记录，并且它们不太可能尝试使用（可能已断开）IPv6连接来到达所需的目的地。
We note that in scenarios where DNSSEC [RFC4033] is deployed, stripping AAAA records from DNS responses would lead to DNS responses elicited by queries with the DO and CD bits set [RFC4035] to be considered invalid, and hence discarded. This situation is similar to that of DNS64 [RFC6147] in the presence of DNSSEC and should be considered a drawback associated with this approach.
我们注意到，在部署DNSSEC[RFC4033]的场景中，从DNS响应中剥离AAAA记录将导致DO和CD位设置为[RFC4035]的查询引发的DNS响应被视为无效，因此被丢弃。这种情况与DNSSEC在场时的DNS64[RFC6147]类似，应视为与此方法相关的缺陷。
Additionally, it should be noted that when filtering IPv6 traffic, it is good practice to signal the packet drop to the source node, such that it is able to react to the packet drop in a more appropriate and timely way. For example, a firewall could signal the packet drop by means of an ICMPv6 error message (or TCP [RFC0793] RST segment if appropriate), such that the source node can, e.g., quickly react as described in [RFC5461]. For obvious reasons, if the traffic being
此外，应当注意，在过滤IPv6通信量时，向源节点发送分组丢弃信号是一种良好的实践，以便它能够以更合适和及时的方式对分组丢弃作出反应。例如，防火墙可以通过ICMPv6错误消息（或TCP[RFC0793]RST段，如果合适）向数据包丢弃发送信号，以便源节点可以（例如）如[RFC5461]中所述快速做出反应。由于明显的原因，如果交通
filtered is IPv6 transition/coexistence traffic, the signaling packet should be sent by means of the corresponding IPv6 transition/ coexistence technology.
过滤的是IPv6过渡/共存流量，信令包应通过相应的IPv6过渡/共存技术发送。
This document discusses the security implications of IPv6 on IPv4 networks and describes a number of techniques to mitigate the aforementioned issues. In general, the possible mitigations boil down to enforcing on native IPv6 and IPv6 transition/coexistence traffic the same security policies currently enforced for IPv4 traffic and/or blocking the aforementioned traffic when it is deemed as undesirable.
本文档讨论了IPv6对IPv4网络的安全影响，并描述了一些缓解上述问题的技术。一般来说，可能的缓解措施归结为在本机IPv6和IPv6转换/共存流量上实施当前针对IPv4流量实施的相同安全策略和/或在认为不需要时阻止上述流量。
The authors would like to thank Wes George, who contributed most of the text that comprises Section 4 of this document.
作者要感谢韦斯·乔治，他贡献了构成本文件第4节的大部分文本。
The authors would like to thank (in alphabetical order) Ran Atkinson, Brian Carpenter, Stephen Farrell, Guillermo Gont, Joel Jaeggli, Panos Kampanakis, Warren Kumari, Ted Lemon, David Malone, Joseph Salowey, Arturo Servin, Donald Smith, Tina Tsou, and Eric Vyncke for providing valuable comments on earlier versions of this document.
作者要感谢（按字母顺序）Ran Atkinson、Brian Carpenter、Stephen Farrell、Guillermo Gont、Joel Jaeggli、Panos Kampanakis、Warren Kumari、Ted Lemon、David Malone、Joseph Salowey、Arturo Servin、Donald Smith、Tina Tsou和Eric Vyncke对本文件早期版本提供了宝贵意见。
This document is based on the results of the project "Security Assessment of the Internet Protocol version 6 (IPv6)" [CPNI-IPv6], carried out by Fernando Gont on behalf of the UK Centre for the Protection of National Infrastructure (CPNI). Fernando Gont would like to thank the UK CPNI for their continued support.
本文件基于Fernando Gont代表英国国家基础设施保护中心（CPNI）开展的项目“互联网协议第6版（IPv6）安全评估”[CPNI-IPv6]的结果。费尔南多·冈特感谢英国CPNI的持续支持。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC1035]Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 1035，1987年11月。
[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月。
[RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 Domains without Explicit Tunnels", RFC 2529, March 1999.
[RFC2529]Carpenter，B.和C.Jung，“在没有明确隧道的IPv4域上传输IPv6”，RFC 2529，1999年3月。
[RFC3053] Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6 Tunnel Broker", RFC 3053, January 2001.
[RFC3053]Durand，A.，Fasano，P.，Guardini，I.，和D.Lento，“IPv6隧道代理”，RFC 3053，2001年1月。
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001.
[RFC3056]Carpenter，B.和K.Moore，“通过IPv4云连接IPv6域”，RFC 3056，2001年2月。
[RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", RFC 3068, June 2001.
[RFC3068]Huitema，C.，“6to4中继路由器的选播前缀”，RFC3068，2001年6月。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
[RFC4033]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全介绍和要求”，RFC 4033，2005年3月。
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005.
[RFC4035]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全扩展的协议修改”，RFC 4035，2005年3月。
[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月。
[RFC4795] Aboba, B., Thaler, D., and L. Esibov, "Link-local Multicast Name Resolution (LLMNR)", RFC 4795, January 2007.
[RFC4795]Aboba，B.，Thaler，D.，和L.Esibov，“链路本地多播名称解析（LLMNR）”，RFC 47952007年1月。
[RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, March 2008.
[RFC5214]Templin，F.，Gleeson，T.，和D.Thaler，“站点内自动隧道寻址协议（ISATAP）”，RFC 52142008年3月。
[RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)", RFC 5569, January 2010.
[RFC5569]Despres，R.，“IPv4基础设施上的IPv6快速部署（第6次）”，RFC 5569，2010年1月。
[RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification", RFC 5969, August 2010.
[RFC5969]Townsley，W.和O.Troan，“IPv4基础设施上的IPv6快速部署（第6条）——协议规范”，RFC 5969，2010年8月。
[RFC5572] Blanchet, M. and F. Parent, "IPv6 Tunnel Broker with the Tunnel Setup Protocol (TSP)", RFC 5572, February 2010.
[RFC5572]Blanchet，M.和F.Parent，“具有隧道设置协议（TSP）的IPv6隧道代理”，RFC 5572，2010年2月。
[RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van Beijnum, "DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers", RFC 6147, April 2011.
[RFC6147]Bagnulo，M.，Sullivan，A.，Matthews，P.，和I.van Beijnum，“DNS64：用于从IPv6客户端到IPv4服务器的网络地址转换的DNS扩展”，RFC 61472011年4月。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793]Postel，J.，“传输控制协议”，标准7，RFC 793，1981年9月。
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.
[RFC2663]Srisuresh，P.和M.Holdrege，“IP网络地址转换器（NAT）术语和注意事项”，RFC 2663，1999年8月。
[RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor Discovery (ND) Trust Models and Threats", RFC 3756, May 2004.
[RFC3756]Nikander，P.，Kempf，J.，和E.Nordmark，“IPv6邻居发现（ND）信任模型和威胁”，RFC 37562004年5月。
[RFC3964] Savola, P. and C. Patel, "Security Considerations for 6to4", RFC 3964, December 2004.
[RFC3964]Savola，P.和C.Patel，“6to4的安全考虑”，RFC 3964，2004年12月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，2008年8月。
[RFC5461] Gont, F., "TCP's Reaction to Soft Errors", RFC 5461, February 2009.
[RFC5461]Gont，F.，“TCP对软错误的反应”，RFC 54612009年2月。
[RFC6101] Freier, A., Karlton, P., and P. Kocher, "The Secure Sockets Layer (SSL) Protocol Version 3.0", RFC 6101, August 2011.
[RFC6101]Freier，A.，Karlton，P.，和P.Kocher，“安全套接字层（SSL）协议版本3.0”，RFC 61012011年8月。
[RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, February 2011.
[RFC6105]Levy Abegnoli，E.，Van de Velde，G.，Popoviciu，C.，和J.Mohacsi，“IPv6路由器广告保护”，RFC 61052011年2月。
[RFC6169] Krishnan, S., Thaler, D., and J. Hoagland, "Security Concerns with IP Tunneling", RFC 6169, April 2011.
[RFC6169]Krishnan，S.，Thaler，D.，和J.Hoagland，“IP隧道的安全问题”，RFC 61692011年4月。
[RFC6343] Carpenter, B., "Advisory Guidelines for 6to4 Deployment", RFC 6343, August 2011.
[RFC6343]Carpenter，B.，“6to4部署咨询指南”，RFC 63432011年8月。
[RFC6540] George, W., Donley, C., Liljenstolpe, C., and L. Howard, "IPv6 Support Required for All IP-Capable Nodes", BCP 177, RFC 6540, April 2012.
[RFC6540]George，W.，Donley，C.，Liljenstolpe，C.，和L.Howard，“所有具有IP能力的节点都需要IPv6支持”，BCP 177，RFC 65402012年4月。
[RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with Dual-Stack Hosts", RFC 6555, April 2012.
[RFC6555]Wing，D.和A.Yourtchenko，“快乐眼球：双堆栈主机的成功”，RFC 6555，2012年4月。
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, February 2013.
[RFC6762]Cheshire，S.和M.Krochmal，“多播DNS”，RFC 67622013年2月。
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, February 2013.
[RFC6763]Cheshire，S.和M.Krocmal，“基于DNS的服务发现”，RFC 67632013年2月。
[RA-GRD-IMP] Gont, F., "Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)", Work in Progress, November 2012.
[RA-GRD-IMP]Gont，F.，“IPv6路由器广告防护（RA防护）的实施建议”，正在进行的工作，2012年11月。
[VPN-LEAKS] Gont, F., "Virtual Private Network (VPN) traffic leakages in dual-stack hosts/ networks", Work in Progress, August 2013.
[VPN-LEAKS]Gont，F.，“双堆栈主机/网络中的虚拟专用网络（VPN）流量泄漏”，正在进行的工作，2013年8月。
[SHIELD] Gont, F., Liu, W., and G. Van de Velde, "DHCPv6-Shield: Protecting Against Rogue DHCPv6 Servers", Work in Progress, October 2013.
[SHIELD]Gont，F.，Liu，W.，和G.Van de Velde，“DHCPv6防护：防范恶意DHCPv6服务器”，正在进行的工作，2013年10月。
[AYIYA] Massar, J., "AYIYA: Anything In Anything", Work in Progress, July 2004.
[AYIYA]Massar，J.，“AYIYA:任何事物中的任何事物”，进展中的工作，2004年7月。
[IANA-ETHER] IANA, "Ethernet Numbers", <http://www.iana.org/assignments/ethernet-numbers>.
[IANA-ETHER]IANA，“以太网编号”<http://www.iana.org/assignments/ethernet-numbers>.
[CERT2009] Giobbi, R., "Bypassing Firewalls with IPv6 Tunnels", CERT/ CC Blog, April 2009, <http://www.cert.org/blogs/vuls/2009/ 04/bypassing_firewalls_with_ipv6.html>.
[CERT2009]Giobbi，R.，“使用IPv6隧道绕过防火墙”，CERT/CC博客，2009年4月<http://www.cert.org/blogs/vuls/2009/ 04/使用ipv6.html>绕过防火墙。
[Huston2010a] Huston, G., "IPv6 Measurements", 2010, <http://www.potaroo.net/stats/1x1/>.
[Huston2010a]Huston，G.，“IPv6测量”，2010年<http://www.potaroo.net/stats/1x1/>.
[Huston2010b] Huston, G., "Flailing IPv6", The ISP Column: A monthly column on things Internet, December 2010, <http://www.potaroo.net/ispcol/2010-12/6to4fail.pdf>.
[Huston2010b]Huston，G.，“打击IPv6”，ISP专栏：物联网月刊，2010年12月<http://www.potaroo.net/ispcol/2010-12/6to4fail.pdf>.
[Huston2012] Huston, G., "Bemused Eyeballs: Tailoring Dual Stack Applications in a CGN Environment", The ISP Column: A monthly column on things Internet, May 2012, <http://www.potaroo.net/ispcol/2012-05/notquite.pdf>.
[Huston2012]Huston，G.，“困惑的眼球：在CGN环境中定制双堆栈应用”，ISP专栏：物联网月刊，2012年5月<http://www.potaroo.net/ispcol/2012-05/notquite.pdf>.
[Anderson2010] Anderson, T., "Measuring and combating IPv6 brokenness", RIPE 61, Roma, November 2010, <http://ripe61.ripe.net/presentations/162-ripe61.pdf>.
[Anderson 2010]Anderson，T.，“衡量和打击IPv6断档”，罗马，第61届会议，2010年11月<http://ripe61.ripe.net/presentations/162-ripe61.pdf>.
[Anderson2011] Anderson, T., "IPv6 dual-stack client loss in Norway", 2011, <http://www.fud.no/ipv6/>.
[Anderson 2011]Anderson，T.，“挪威的IPv6双栈客户端丢失”，2011年<http://www.fud.no/ipv6/>.
[CPNI-IPv6] Gont, F., "Security Assessment of the Internet Protocol version 6 (IPv6)", UK Centre for the Protection of National Infrastructure, (available on request), .
[CPNI-IPv6]Gont，F.，“互联网协议第6版（IPv6）的安全评估”，英国国家基础设施保护中心，（可根据要求提供）。
[IPv6-Toolkit] SI6 Networks, "SI6 Networks' IPv6 Toolkit", <http://www.si6networks.com/tools/ipv6toolkit>.
[IPv6工具包]SI6网络，“SI6网络的IPv6工具包”<http://www.si6networks.com/tools/ipv6toolkit>.
[THC-IPV6] The Hacker's Choice, "THC-IPV6 - attacking the IPV6 protocol suite", December 2013, <http://www.thc.org/thc-ipv6/>.
[THC-IPV6]黑客的选择，“THC-IPV6-攻击IPV6协议套件”，2013年12月<http://www.thc.org/thc-ipv6/>.
[Waters2011] Waters, A., "The SLAAC Attack - using IPv6 as a weapon against IPv4", April 2011, <http://wirewatcher.wordpress.com/2011/04/04/ the-slaac-attack-using-ipv6-as-a-weapon-against-ipv4/>.
[Waters2011]Waters，A.，“斯拉克攻击-使用IPv6作为对付IPv4的武器”，2011年4月<http://wirewatcher.wordpress.com/2011/04/04/ -slaac-attack-using-ipv6-as-a-arm-antights-ipv4/>。
[SixXS-stats] SixXS, , "SixXS - IPv6 Deployment & Tunnel Broker :: Statistics", 2013, <http://www.sixxs.net/misc/usage/>.
[SixXS统计]SixXS，“SixXS-IPv6部署和隧道代理：：统计”，2013年<http://www.sixxs.net/misc/usage/>.
+-------------+-----------------------------------------------------+
| Technology | Filtering rules |
+-------------+-----------------------------------------------------+
| Native IPv6 | EtherType 0x86DD |
+-------------+-----------------------------------------------------+
| 6in4 | IP proto 41 |
+-------------+-----------------------------------------------------+
| 6over4 | IP proto 41 |
+-------------+-----------------------------------------------------+
| 6rd | IP proto 41 |
+-------------+-----------------------------------------------------+
| 6to4 | IP proto 41 |
+-------------+-----------------------------------------------------+
| ISATAP | IP proto 41 |
+-------------+-----------------------------------------------------+
| Teredo | UDP Dest Port 3544 |
+-------------+-----------------------------------------------------+
| TB with TSP | (IP proto 41) || (UDP Dest Port 3653 || TCP Dest |
| | Port 3653) |
+-------------+-----------------------------------------------------+
| AYIYA | UDP Dest Port 5072 || TCP Dest Port 5072 |
+-------------+-----------------------------------------------------+
+-------------+-----------------------------------------------------+
| Technology | Filtering rules |
+-------------+-----------------------------------------------------+
| Native IPv6 | EtherType 0x86DD |
+-------------+-----------------------------------------------------+
| 6in4 | IP proto 41 |
+-------------+-----------------------------------------------------+
| 6over4 | IP proto 41 |
+-------------+-----------------------------------------------------+
| 6rd | IP proto 41 |
+-------------+-----------------------------------------------------+
| 6to4 | IP proto 41 |
+-------------+-----------------------------------------------------+
| ISATAP | IP proto 41 |
+-------------+-----------------------------------------------------+
| Teredo | UDP Dest Port 3544 |
+-------------+-----------------------------------------------------+
| TB with TSP | (IP proto 41) || (UDP Dest Port 3653 || TCP Dest |
| | Port 3653) |
+-------------+-----------------------------------------------------+
| AYIYA | UDP Dest Port 5072 || TCP Dest Port 5072 |
+-------------+-----------------------------------------------------+
Table 1: Summary of filtering rules
表1：筛选规则摘要
NOTE: the table above describes general and simple filtering rules for blocking the corresponding traffic. More finer-grained rules might be available in each of the corresponding sections of this document.
注：上表描述了阻止相应流量的一般和简单过滤规则。更细粒度的规则可能会出现在本文档的每个相应部分中。
Authors' Addresses
作者地址
Fernando Gont SI6 Networks / UTN-FRH Evaristo Carriego 2644 Haedo, Provincia de Buenos Aires 1706 Argentina
Fernando Gont SI6 Networks/UTN-FRH Evaristo Carriego 2644 Haedo，布宜诺斯艾利斯省1706阿根廷
Phone: +54 11 4650 8472
EMail: fgont@si6networks.com
URI: http://www.si6networks.com
Phone: +54 11 4650 8472
EMail: fgont@si6networks.com
URI: http://www.si6networks.com
Will (Shucheng) Liu Huawei Technologies Bantian, Longgang District Shenzhen 518129 P.R. China
威尔（舒城）刘华威科技有限公司，深圳市龙岗区，邮编：518129
EMail: liushucheng@huawei.com
EMail: liushucheng@huawei.com