Network Working Group E. Davies
Request for Comments: 4942 Consultant
Category: Informational S. Krishnan
Ericsson
P. Savola
CSC/Funet
September 2007
Network Working Group E. Davies
Request for Comments: 4942 Consultant
Category: Informational S. Krishnan
Ericsson
P. Savola
CSC/Funet
September 2007
IPv6 Transition/Coexistence Security Considerations
IPv6转换/共存安全注意事项
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.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Abstract
摘要
The transition from a pure IPv4 network to a network where IPv4 and IPv6 coexist brings a number of extra security considerations that need to be taken into account when deploying IPv6 and operating the dual-protocol network and the associated transition mechanisms. This document attempts to give an overview of the various issues grouped into three categories: o issues due to the IPv6 protocol itself, o issues due to transition mechanisms, and o issues due to IPv6 deployment.
从纯IPv4网络过渡到IPv4和IPv6共存的网络带来了许多额外的安全注意事项，在部署IPv6和操作双协议网络及相关过渡机制时需要考虑这些安全注意事项。本文档试图概述分为三类的各种问题：IPv6协议本身引起的问题、转换机制引起的问题以及IPv6部署引起的问题。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Issues Due to IPv6 Protocol . . . . . . . . . . . . . . . . . 4
2.1. IPv6 Protocol-Specific Issues . . . . . . . . . . . . . . 5
2.1.1. Routing Headers and Hosts . . . . . . . . . . . . . . 5
2.1.2. Routing Headers for Mobile IPv6 and Other Purposes . . 6
2.1.3. Site-Scope Multicast Addresses . . . . . . . . . . . . 7
2.1.4. ICMPv6 and Multicast . . . . . . . . . . . . . . . . . 7
2.1.5. Bogus Errored Packets in ICMPv6 Error Messages . . . . 8
2.1.6. Anycast Traffic Identification and Security . . . . . 9
2.1.7. Address Privacy Extensions Interact with DDoS
Defenses . . . . . . . . . . . . . . . . . . . . . . . 10
2.1.8. Dynamic DNS: Stateless Address Autoconfiguration,
Privacy Extensions, and SEND . . . . . . . . . . . . . 10
2.1.9. Extension Headers . . . . . . . . . . . . . . . . . . 11
2.1.10. Fragmentation: Reassembly and Deep Packet
Inspection . . . . . . . . . . . . . . . . . . . . . . 14
2.1.11. Fragmentation Related DoS Attacks . . . . . . . . . . 15
2.1.12. Link-Local Addresses and Securing Neighbor
Discovery . . . . . . . . . . . . . . . . . . . . . . 16
2.1.13. Securing Router Advertisements . . . . . . . . . . . . 17
2.1.14. Host-to-Router Load Sharing . . . . . . . . . . . . . 18
2.1.15. Mobile IPv6 . . . . . . . . . . . . . . . . . . . . . 18
2.2. IPv4-Mapped IPv6 Addresses . . . . . . . . . . . . . . . . 19
2.3. Increased End-to-End Transparency . . . . . . . . . . . . 20
2.3.1. IPv6 Networks without NATs . . . . . . . . . . . . . . 20
2.3.2. Enterprise Network Security Model for IPv6 . . . . . . 21
2.4. IPv6 in IPv6 Tunnels . . . . . . . . . . . . . . . . . . . 22
3. Issues Due to Transition Mechanisms . . . . . . . . . . . . . 23
3.1. IPv6 Transition/Coexistence Mechanism-Specific Issues . . 23
3.2. Automatic Tunneling and Relays . . . . . . . . . . . . . . 23
3.3. Tunneling IPv6 through IPv4 Networks May Break IPv4
Network Security Assumptions . . . . . . . . . . . . . . . 24
4. Issues Due to IPv6 Deployment . . . . . . . . . . . . . . . . 26
4.1. Avoiding the Trap of Insecure IPv6 Service Piloting . . . 26
4.2. DNS Server Problems . . . . . . . . . . . . . . . . . . . 28
4.3. Addressing Schemes and Securing Routers . . . . . . . . . 28
4.4. Consequences of Multiple Addresses in IPv6 . . . . . . . . 28
4.5. Deploying ICMPv6 . . . . . . . . . . . . . . . . . . . . . 29
4.5.1. Problems Resulting from ICMPv6 Transparency . . . . . 30
4.6. IPsec Transport Mode . . . . . . . . . . . . . . . . . . . 30
4.7. Reduced Functionality Devices . . . . . . . . . . . . . . 31
4.8. Operational Factors when Enabling IPv6 in the Network . . 31
4.9. Security Issues Due to Neighbor Discovery Proxies . . . . 32
5. Security Considerations . . . . . . . . . . . . . . . . . . . 32
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Issues Due to IPv6 Protocol . . . . . . . . . . . . . . . . . 4
2.1. IPv6 Protocol-Specific Issues . . . . . . . . . . . . . . 5
2.1.1. Routing Headers and Hosts . . . . . . . . . . . . . . 5
2.1.2. Routing Headers for Mobile IPv6 and Other Purposes . . 6
2.1.3. Site-Scope Multicast Addresses . . . . . . . . . . . . 7
2.1.4. ICMPv6 and Multicast . . . . . . . . . . . . . . . . . 7
2.1.5. Bogus Errored Packets in ICMPv6 Error Messages . . . . 8
2.1.6. Anycast Traffic Identification and Security . . . . . 9
2.1.7. Address Privacy Extensions Interact with DDoS
Defenses . . . . . . . . . . . . . . . . . . . . . . . 10
2.1.8. Dynamic DNS: Stateless Address Autoconfiguration,
Privacy Extensions, and SEND . . . . . . . . . . . . . 10
2.1.9. Extension Headers . . . . . . . . . . . . . . . . . . 11
2.1.10. Fragmentation: Reassembly and Deep Packet
Inspection . . . . . . . . . . . . . . . . . . . . . . 14
2.1.11. Fragmentation Related DoS Attacks . . . . . . . . . . 15
2.1.12. Link-Local Addresses and Securing Neighbor
Discovery . . . . . . . . . . . . . . . . . . . . . . 16
2.1.13. Securing Router Advertisements . . . . . . . . . . . . 17
2.1.14. Host-to-Router Load Sharing . . . . . . . . . . . . . 18
2.1.15. Mobile IPv6 . . . . . . . . . . . . . . . . . . . . . 18
2.2. IPv4-Mapped IPv6 Addresses . . . . . . . . . . . . . . . . 19
2.3. Increased End-to-End Transparency . . . . . . . . . . . . 20
2.3.1. IPv6 Networks without NATs . . . . . . . . . . . . . . 20
2.3.2. Enterprise Network Security Model for IPv6 . . . . . . 21
2.4. IPv6 in IPv6 Tunnels . . . . . . . . . . . . . . . . . . . 22
3. Issues Due to Transition Mechanisms . . . . . . . . . . . . . 23
3.1. IPv6 Transition/Coexistence Mechanism-Specific Issues . . 23
3.2. Automatic Tunneling and Relays . . . . . . . . . . . . . . 23
3.3. Tunneling IPv6 through IPv4 Networks May Break IPv4
Network Security Assumptions . . . . . . . . . . . . . . . 24
4. Issues Due to IPv6 Deployment . . . . . . . . . . . . . . . . 26
4.1. Avoiding the Trap of Insecure IPv6 Service Piloting . . . 26
4.2. DNS Server Problems . . . . . . . . . . . . . . . . . . . 28
4.3. Addressing Schemes and Securing Routers . . . . . . . . . 28
4.4. Consequences of Multiple Addresses in IPv6 . . . . . . . . 28
4.5. Deploying ICMPv6 . . . . . . . . . . . . . . . . . . . . . 29
4.5.1. Problems Resulting from ICMPv6 Transparency . . . . . 30
4.6. IPsec Transport Mode . . . . . . . . . . . . . . . . . . . 30
4.7. Reduced Functionality Devices . . . . . . . . . . . . . . 31
4.8. Operational Factors when Enabling IPv6 in the Network . . 31
4.9. Security Issues Due to Neighbor Discovery Proxies . . . . 32
5. Security Considerations . . . . . . . . . . . . . . . . . . . 32
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
7.1. Normative References . . . . . . . . . . . . . . . . . . . 33
7.2. Informative References . . . . . . . . . . . . . . . . . . 34
Appendix A. IPv6 Probing/Mapping Considerations . . . . . . . . . 37
Appendix B. IPv6 Privacy Considerations . . . . . . . . . . . . . 38
B.1. Exposing MAC Addresses . . . . . . . . . . . . . . . . . . 38
B.2. Exposing Multiple Devices . . . . . . . . . . . . . . . . 39
B.3. Exposing the Site by a Stable Prefix . . . . . . . . . . . 39
7.1. Normative References . . . . . . . . . . . . . . . . . . . 33
7.2. Informative References . . . . . . . . . . . . . . . . . . 34
Appendix A. IPv6 Probing/Mapping Considerations . . . . . . . . . 37
Appendix B. IPv6 Privacy Considerations . . . . . . . . . . . . . 38
B.1. Exposing MAC Addresses . . . . . . . . . . . . . . . . . . 38
B.2. Exposing Multiple Devices . . . . . . . . . . . . . . . . 39
B.3. Exposing the Site by a Stable Prefix . . . . . . . . . . . 39
The transition from a pure IPv4 network to a network where IPv4 and IPv6 coexist brings a number of extra security considerations that need to be taken into account when deploying IPv6 and operating the dual-protocol network with its associated transition mechanisms. This document attempts to give an overview of the various issues grouped into three categories: o issues due to the IPv6 protocol itself, o issues due to transition mechanisms, and o issues due to IPv6 deployment.
从纯IPv4网络过渡到IPv4和IPv6共存的网络带来了许多额外的安全注意事项，在部署IPv6和操作双协议网络及其相关过渡机制时需要考虑这些安全注意事项。本文档试图概述分为三类的各种问题：IPv6协议本身引起的问题、转换机制引起的问题以及IPv6部署引起的问题。
It is important to understand that deployments are unlikely to be replacing IPv4 with IPv6 (in the short term), but rather will be adding IPv6 to be operated in parallel with IPv4 over a considerable period, so that security issues with transition mechanisms and dual stack networks will be of ongoing concern. This extended transition and coexistence period stems primarily from the scale of the current IPv4 network. It is unreasonable to expect that the many millions of IPv4 nodes will be converted overnight. It is more likely that it will take two or three capital equipment replacement cycles (between nine and 15 years) for IPv6 capabilities to spread through the network, and many services will remain available over IPv4 only for a significant period whilst others will be offered either just on IPv6 or on both protocols. To maintain current levels of service, enterprises and service providers will need to support IPv4 and IPv6 in parallel for some time.
重要的是要了解，部署不太可能（在短期内）用IPv6取代IPv4，而是将在相当长的一段时间内添加IPv6以与IPv4并行运行，因此过渡机制和双堆栈网络的安全问题将成为持续关注的问题。这种延长的过渡和共存期主要源于当前IPv4网络的规模。期望数百万IPv4节点在一夜之间被转换是不合理的。IPv6功能很可能需要两到三个资本设备更换周期（9到15年之间）才能在网络中普及，许多服务将仅在很长一段时间内通过IPv4保持可用，而其他服务将仅通过IPv6或两种协议提供。为了保持当前的服务水平，企业和服务提供商需要在一段时间内并行支持IPv4和IPv6。
This document also describes two matters that have been wrongly identified as potential security concerns for IPv6 in the past and explains why they are unlikely to cause problems: considerations about probing/mapping IPv6 addresses (Appendix A) and considerations with respect to privacy in IPv6 (Appendix B).
本文档还描述了过去被错误地确定为IPv6潜在安全问题的两个事项，并解释了它们不太可能导致问题的原因：关于探测/映射IPv6地址的注意事项（附录A）和关于IPv6中隐私的注意事项（附录B）。
Administrators should be aware that some of the rules suggested in this section could potentially lead to a small amount of legitimate traffic being dropped because the source has made unusual and arguably unreasonable choices when generating the packet. The IPv6 specification [RFC2460] contains a number of areas where choices are available to packet originators that will result in packets that conform to the specification but are unlikely to be the result of a rational packet generation policy for legitimate traffic (e.g., sending a fragmented packet in a much larger than necessary number of small segments). This document highlights choices that could be made by malicious sources with the intention of damaging the target host or network, and suggests rules that try to differentiate
管理员应该知道，本节中建议的一些规则可能会导致少量合法流量被丢弃，因为源在生成数据包时做出了不寻常且可能不合理的选择。IPv6规范[RFC2460]包含许多领域，在这些领域中，数据包发起人可以进行选择，这些选择将产生符合规范的数据包，但不太可能是合法流量的合理数据包生成策略的结果（例如，以远远大于必要数量的小段发送碎片数据包）。本文档强调恶意来源可能做出的选择，目的是破坏目标主机或网络，并建议尝试区分这些选择的规则
specification-conforming packets that are legitimate traffic from conforming packets that may be trying to subvert the specification to cause damage. The differentiation tries to offer a reasonable compromise between securing the network and passing every possible conforming packet. To avoid loss of important traffic, administrators are advised to log packets dropped according to these rules and examine these logs periodically to ensure that they are having the desired effect, and are not excluding traffic inappropriately.
符合规范的数据包是来自可能试图破坏规范造成损害的符合规范的数据包的合法通信量。这种区别试图在保护网络和传递每个可能的一致性数据包之间提供合理的折衷。为了避免重要流量的丢失，建议管理员根据这些规则记录丢弃的数据包，并定期检查这些日志，以确保它们具有预期的效果，并且不会不适当地排除流量。
The built-in flexibility of the IPv6 protocol may also lead to changes in the boundaries between legitimate and malicious traffic as identified by these rules. New options may be introduced in the future, and rules may need to be altered to allow the new capabilities to be (legitimately) exploited by applications. The document therefore recommends that filtering needs to be configurable to allow administrators the flexibility to update rules as new pieces of IPv6 specification are standardized.
IPv6协议的内置灵活性还可能导致这些规则确定的合法和恶意流量之间的边界发生变化。将来可能会引入新的选项，并且可能需要修改规则以允许应用程序（合法地）利用新功能。因此，本文档建议，过滤需要可配置，以便管理员能够灵活地在新的IPv6规范标准化时更新规则。
There are significant differences between the features of IPv6 and IPv4: some of these specification changes may result in potential security issues. Several of these issues have been discussed in separate documents but are summarized here to avoid normative references that may not become RFCs. The following specification-related problems have been identified, but this is not necessarily a complete list.
IPv6和IPv4的功能有很大的区别：其中一些规范更改可能会导致潜在的安全问题。其中几个问题已在单独的文件中进行了讨论，但此处进行了总结，以避免可能不会成为RFC的规范性参考。已确定以下与规范相关的问题，但这不一定是一个完整的列表。
All IPv6 nodes must be able to process routing headers [RFC2460]. This RFC can be interpreted, although it is not explicitly stated, to mean that all nodes (including hosts) must have this processing enabled. The "Requirements for Internet Hosts" [RFC1122] permits implementations to perform "local source routing", that is, forwarding a packet with a routing header through the same interface on which it was received: no restrictions are placed on this operation even on hosts. In combination, these rules can result in hosts forwarding received traffic to another node if there are segments left in the Routing Header when it arrives at the host.
所有IPv6节点必须能够处理路由头[RFC2460]。尽管没有明确说明，但可以将此RFC解释为所有节点（包括主机）都必须启用此处理。“互联网主机要求”[RFC1122]允许实现执行“本地源路由”，即通过接收数据包的同一接口转发带有路由报头的数据包：即使在主机上，也不限制此操作。结合起来，如果路由报头在到达主机时还留有段，这些规则可能会导致主机将接收到的流量转发到另一个节点。
A number of potential security issues associated with this behavior have been identified. Some of these issues have been resolved (a separate routing header (Type 2) has been standardized for Mobile IPv6 [RFC3775], and ICMP Traceback has not been standardized), but two issues remain:
已经确定了许多与此行为相关的潜在安全问题。其中一些问题已得到解决（移动IPv6[RFC3775]的单独路由报头（类型2）已标准化，ICMP回溯尚未标准化），但仍存在两个问题：
o Both existing types of routing header can be used to evade access controls based on destination addresses. This could be achieved by sending a packet ostensibly to a publicly accessible host address but with a routing header containing a 'forbidden' address. If the publicly accessible host is processing routing headers, it will forward the packet to the destination address in the routing header that would have been forbidden by the packet filters if the address had been in the destination field when the packet was checked.
o 两种现有类型的路由报头都可用于规避基于目标地址的访问控制。这可以通过将数据包表面上发送到一个可公开访问的主机地址，但路由报头包含一个“禁止”地址来实现。如果可公开访问的主机正在处理路由报头，它会将数据包转发到路由报头中的目标地址，如果在检查数据包时地址位于目的地字段中，则该地址将被数据包过滤器禁止。
o If the packet source address can be spoofed when using a Type 0 routing header, the mechanism described in the previous bullet could be used with any host to mediate an anonymous reflection denial-of-service attack by having any publicly accessible host redirect the attack packets. (This attack cannot use Type 2 routing headers because the packet cannot be forwarded outside the host that processes the routing header, i.e., the original destination of the packet.)
o 如果在使用类型0路由报头时可以伪造数据包源地址，则上一个项目符号中描述的机制可用于任何主机，通过让任何可公开访问的主机重定向攻击数据包来调解匿名反射拒绝服务攻击。（此攻击无法使用类型2路由头，因为无法在处理路由头的主机（即数据包的原始目的地）之外转发数据包。）
To counteract these threats, if a device is enforcing access controls based on destination addresses, it needs to examine both the destination address in the base IPv6 header and any waypoint destinations in a routing header that have not yet been reached by the packet at the point where it is being checked.
为了应对这些威胁，如果设备基于目的地地址实施访问控制，则需要检查基本IPv6报头中的目的地地址和路由报头中的任何航路点目的地，这些目的地在数据包被检查的点尚未到达。
Various forms of amplification attack on routers and firewalls using the routing header could be envisaged. A simple form involves repeating the address of a waypoint several times in the routing header. More complex forms could involve alternating waypoint addresses that would result in the packet re-transiting the router or firewall. These attacks can be counteracted by ensuring that routing headers do not contain the same waypoint address more than once, and performing ingress/egress filtering to check that the source address is appropriate to the destination: packets made to reverse their path will fail this test.
可以设想使用路由报头对路由器和防火墙进行各种形式的放大攻击。一种简单的形式是在路由报头中多次重复一个航路点的地址。更复杂的形式可能涉及交替的航路点地址，这将导致数据包重新通过路由器或防火墙。这些攻击可以通过确保路由报头不多次包含相同的航路点地址，并执行入口/出口过滤以检查源地址是否适合目的地来抵消：用于反转其路径的数据包将无法通过此测试。
In addition to the basic Routing Header (Type 0), which is intended to influence the trajectory of a packet through a network by specifying a sequence of router waypoints, Routing Header (Type 2) has been defined as part of the Mobile IPv6 specifications in [RFC3775]. The Type 2 Routing Header is intended for use by hosts to handle 'interface local' forwarding needed when packets are sent to the care-of address of a mobile node that is away from its home address.
除了基本路由报头（类型0）外，路由报头（类型2）还被定义为[RFC3775]中移动IPv6规范的一部分。基本路由报头（类型0）旨在通过指定一系列路由器航路点来影响数据包通过网络的轨迹。当数据包被发送到远离其家庭地址的移动节点的转交地址时，类型2路由报头用于主机处理所需的“接口本地”转发。
It is important that nodes treat the different types of routing header appropriately. It should be possible to apply separate filtering rules to the different types of Routing Header. By design, hosts must process Type 2 Routing Headers to support Mobile IPv6 but routers should not: to avoid the issues in Section 2.1.1, it may be desirable to forbid or limit the processing of Type 0 Routing Headers in hosts and some routers.
节点适当地处理不同类型的路由头是很重要的。应该可以对不同类型的路由标头应用单独的筛选规则。根据设计，主机必须处理类型2路由头以支持移动IPv6，但路由器不应：为了避免第2.1.1节中的问题，可能需要禁止或限制主机和某些路由器中处理类型0路由头。
Routing Headers are an extremely powerful and general capability. Alternative future uses of Routing Headers need to be carefully assessed to ensure that they do not open new avenues of attack that can be exploited.
路由头是一种非常强大的通用功能。需要仔细评估路由头的其他未来用途，以确保它们不会打开可利用的新攻击途径。
IPv6 supports multicast addresses with site scope that can potentially allow an attacker to identify certain important resources on the site if misused.
IPv6支持具有站点范围的多播地址，如果该地址被滥用，攻击者可能会识别站点上的某些重要资源。
Particular examples are the 'all routers' (FF05::2) and 'all Dynamic Host Configuration Protocol (DHCP) servers' (FF05::1:3) addresses defined in [RFC2375]. An attacker that is able to infiltrate a message destined for these addresses on to the site will potentially receive in return information identifying key resources on the site. This information can then be the target of directed attacks ranging from simple flooding to more specific mechanisms designed to subvert the device.
具体示例为[RFC2375]中定义的“所有路由器”（FF05:：2）和“所有动态主机配置协议（DHCP）服务器”（FF05:：1:3）地址。能够将发送给这些地址的邮件渗透到站点的攻击者可能会收到标识站点上关键资源的信息。然后，这些信息可能成为定向攻击的目标，攻击范围从简单的泛洪攻击到旨在破坏设备的更具体的机制。
Some of these addresses have current legitimate uses within a site. The risk can be minimized by ensuring that all firewalls and site boundary routers are configured to drop packets with site-scope destination addresses. Also, nodes should not join multicast groups for which there is no legitimate use on the site, and site routers should be configured to drop packets directed to these unused addresses.
其中一些地址在站点中具有当前合法用途。通过确保所有防火墙和站点边界路由器配置为丢弃具有站点范围目标地址的数据包，可以将风险降至最低。此外，节点不应加入在站点上没有合法用途的多播组，并且站点路由器应配置为丢弃指向这些未使用地址的数据包。
It is possible to launch a Denial-of-Service (DoS) attack using IPv6 that could be amplified by the multicast infrastructure.
使用IPv6发起拒绝服务（DoS）攻击是可能的，这种攻击可能会被多播基础设施放大。
Unlike ICMP for IPv4, ICMPv6 [RFC4443] allows error notification responses to be sent when certain unprocessable packets are sent to multicast addresses.
与IPv4的ICMP不同，ICMPv6[RFC4443]允许在将某些无法处理的数据包发送到多播地址时发送错误通知响应。
The cases in which responses are sent are:
发送响应的情况包括：
o The received packet is longer than the next link Maximum Transmission Unit (MTU): 'Packet Too Big' responses are needed to support Path MTU Discovery for multicast traffic.
o 接收到的数据包长于下一链路最大传输单元（MTU）：“数据包太大”响应需要支持多播流量的路径MTU发现。
o The received packet contains an unrecognized option in a hop-by-hop or destination options extension header with the first two bits of the option type set to binary '10': 'Parameter Problem' responses are intended to inform the source that some or all of the recipients cannot handle the option in question.
o 接收到的数据包在逐跳或目标选项扩展标头中包含无法识别的选项，选项类型的前两位设置为二进制“10”：“参数问题”响应旨在通知源某些或所有收件人无法处理有问题的选项。
If an attacker can craft a suitable packet sent to a multicast destination, it may be possible to elicit multiple responses directed at the victim (the spoofed source of the multicast packet). On the other hand, the use of 'reverse path forwarding' checks (to eliminate loops in multicast forwarding) automatically limits the range of addresses that can be spoofed.
如果攻击者能够精心制作发送到多播目的地的合适数据包，则可能会引发针对受害者（多播数据包的伪造源）的多个响应。另一方面，使用“反向路径转发”检查（以消除多播转发中的循环）会自动限制可以伪造的地址范围。
In practice, an attack using oversize packets is unlikely to cause much amplification unless the attacker is able to carefully tune the packet size to exploit a network with smaller MTU in the edge than the core. Similarly, a packet with an unrecognized hop-by-hop option would be dropped by the first router without resulting in multiple responses. However, a packet with an unrecognized destination option could generate multiple responses.
实际上，使用超大数据包的攻击不太可能造成太大的放大，除非攻击者能够仔细调整数据包大小，以利用边缘MTU小于核心MTU的网络进行攻击。类似地，具有无法识别的逐跳选项的数据包将被第一个路由器丢弃，而不会导致多个响应。但是，具有无法识别的目的地选项的数据包可能会生成多个响应。
In addition to amplification, this kind of attack would potentially consume large amounts of forwarding state resources in routers on multicast-enabled networks.
除了放大之外，这种攻击还可能消耗启用多播的网络上路由器中的大量转发状态资源。
Apart from the spurious load on the network, routers, and hosts, bogus ICMPv6 error messages (types 0 to 127) containing a spoofed errored packet can impact higher-layer protocols when the alleged errored packet is referred to the higher layer at the destination of the ICMPv6 packet [RFC4443]. The potentially damaging effects on TCP connections, and some ways to mitigate the threats, are documented in [ICMP-ATT].
除了网络、路由器和主机上的虚假负载外，当声称的错误数据包被引用到ICMPv6数据包目的地的更高层时，包含伪造错误数据包的虚假ICMPv6错误消息（类型0到127）可能会影响更高层协议[RFC4443]。[ICMP-ATT]中记录了对TCP连接的潜在破坏性影响以及缓解威胁的一些方法。
Specific countermeasures for particular higher-layer protocols are beyond the scope of this document, but firewalls may be able to help counter the threat by inspecting the alleged errored packet embedded in the ICMPv6 error message. Measures to mitigate the threat include:
特定高层协议的具体对策超出了本文件的范围，但防火墙可以通过检查嵌入在ICMPv6错误消息中的所谓错误数据包来帮助应对威胁。缓解威胁的措施包括：
o The receiving host should test that the embedded packet is all or part of a packet that was transmitted by the host.
o 接收主机应测试嵌入的数据包是否是主机发送的数据包的全部或部分。
o The firewall may be able to test that the embedded packet contains addresses that would have been legitimate (i.e., would have passed ingress/egress filtering) for a packet sent from the receiving host, but the possibility of asymmetric routing of the outgoing and returning packets may prevent this sort of test depending on the topology of the network, the location of the firewall, and whether state synchronization between firewalls is in use.
o 防火墙可能能够测试嵌入式分组是否包含对于从接收主机发送的分组来说是合法的（即，将通过入口/出口过滤）地址，但是，根据网络拓扑结构、防火墙位置以及防火墙之间是否正在使用状态同步，传出和返回数据包的不对称路由可能会阻止此类测试。
o If the firewall is stateful and the test is not prevented by asymmetric routing, the firewall may also be able to check that the embedded packet is all or part of a packet that recently transited the firewall in the opposite direction.
o 如果防火墙是有状态的，并且测试没有被非对称路由阻止，那么防火墙还可以检查嵌入的数据包是否是最近以相反方向通过防火墙的数据包的全部或部分。
o Firewalls and destination hosts should be suspicious of ICMPv6 error messages with unnecessarily truncated errored packets (e.g., those that only carry the address fields of the IPv6 base header). The specification of ICMPv6 requires that error messages carry as much of the errored packet as possible (unlike ICMP for IPv4 which requires only a minimum amount of the errored packet) and IPv6 networks must have a guaranteed minimum MTU of 1280 octets. Accordingly, the ICMPv6 message should normally carry all the header fields of the errored packet, together with a significant amount of the payload, in order to allow robust comparison against the outgoing packet.
o 防火墙和目标主机应怀疑ICMPv6错误消息包含不必要的截断错误数据包（例如，仅携带IPv6基本头的地址字段的数据包）。ICMPv6的规范要求错误消息携带尽可能多的错误数据包（不像IPv4的ICMP只需要最少数量的错误数据包），IPv6网络必须保证最小MTU为1280个八位字节。因此，ICMPv6消息通常应携带出错数据包的所有报头字段以及大量有效载荷，以便允许与传出数据包进行稳健比较。
IPv6 introduces the notion of anycast addresses and services. Originally the IPv6 standards disallowed using an anycast address as the source address of a packet. Responses from an anycast server would therefore supply a unicast address for the responding server. To avoid exposing knowledge about the internal structure of the network, it is recommended that anycast servers now take advantage of the ability to return responses with the anycast address as the source address if possible.
IPv6引入了选播地址和服务的概念。最初，IPv6标准不允许使用选播地址作为数据包的源地址。因此，来自选播服务器的响应将为响应服务器提供单播地址。为了避免暴露有关网络内部结构的知识，建议选播服务器现在利用以选播地址作为源地址返回响应的能力（如果可能）。
If the server needs to use a unicast address for any reason, it may be desirable to consider using specialized addresses for anycast servers, which are not used for any other part of the network, to restrict the information exposed. Alternatively, operators may wish to restrict the use of anycast services from outside the domain, thus requiring firewalls to filter anycast requests. For this purpose, firewalls need to know which addresses are being used for anycast services: these addresses are arbitrary and not distinguishable from any other IPv6 unicast address by structure or pattern.
如果服务器出于任何原因需要使用单播地址，则可能需要考虑使用未被用于网络的任何其他部分的选播服务器的专用地址来限制所公开的信息。或者，运营商可能希望限制来自域外的选播服务的使用，从而要求防火墙过滤选播请求。为此，防火墙需要知道选播服务使用了哪些地址：这些地址是任意的，并且不能通过结构或模式与任何其他IPv6单播地址区分开来。
One particular class of anycast addresses that should be given special attention is the set of Subnet-Router anycast addresses defined in "IP Version 6 Addressing Architecture" [RFC4291]. All routers are required to support these addresses for all subnets for which they have interfaces. For most subnets using global unicast addresses, filtering anycast requests to these addresses can be achieved by dropping packets with the lower 64 bits (the Interface Identifier) set to all zeros.
应特别注意的一类选播地址是“IP版本6寻址体系结构”[RFC4291]中定义的子网路由器选播地址集。所有路由器都需要为其具有接口的所有子网支持这些地址。对于大多数使用全局单播地址的子网，可以通过丢弃低64位（接口标识符）设置为全零的数据包来过滤对这些地址的选播请求。
The purpose of the privacy extensions for stateless address autoconfiguration [RFC4941] is to change the interface identifier (and hence the global scope addresses generated from it) from time to time. By varying the addresses used, eavesdroppers and other information collectors find it more difficult to identify which transactions actually relate to a specific node.
无状态地址自动配置隐私扩展[RFC4941]的目的是不时更改接口标识符（以及由此生成的全局作用域地址）。通过改变使用的地址，窃听者和其他信息收集者发现更难识别哪些事务实际上与特定节点相关。
A security issue may result from this if the frequency of node address change is sufficiently great to achieve the intended aim of the privacy extensions: with a relatively high rate of change, the observed behavior has some characteristics of a node or nodes involved in a Distributed Denial-of-Service (DDoS) attack. It should be noted, however, that addresses created in this way are topologically correct and that the other characteristics of the traffic may reveal that there is no malicious intent.
如果节点地址更改的频率足以达到隐私扩展的预期目的，则可能会导致安全问题：在相对较高的更改率下，观察到的行为具有参与分布式拒绝服务（DDoS）攻击的一个或多个节点的某些特征。然而，应注意，以这种方式创建的地址在拓扑上是正确的，并且通信量的其他特征可能表明没有恶意意图。
This issue can be addressed in most cases by tuning the rate of change in an appropriate manner.
在大多数情况下，可以通过以适当的方式调整变化率来解决此问题。
Note that even if a node is well behaved, a change in the address could make it harder for a security administrator to define an address-based policy rule (e.g., access control list). However, nodes that employ privacy addresses do not have to use them for all communications.
请注意，即使节点表现良好，地址的更改也可能使安全管理员难以定义基于地址的策略规则（例如，访问控制列表）。但是，使用隐私地址的节点不必在所有通信中使用它们。
2.1.8. Dynamic DNS: Stateless Address Autoconfiguration, Privacy Extensions, and SEND
2.1.8. 动态DNS：无状态地址自动配置、隐私扩展和发送
The introduction of Stateless Address Autoconfiguration (SLAAC) [RFC2462] with IPv6 provides an additional challenge to the security of Dynamic Domain Name System (DDNS). With manual addressing or the use of DHCP, the number of security associations that need to be maintained to secure access to the Domain Name Service (DNS) server is limited, assuming any necessary updates are carried out by the DHCP server. This is true equally for IPv4 and IPv6.
IPv6引入无状态地址自动配置（SLAAC）[RFC2462]对动态域名系统（DDNS）的安全性提出了额外的挑战。在手动寻址或使用DHCP的情况下，如果DHCP服务器执行任何必要的更新，则需要维护以确保对域名服务（DNS）服务器的访问安全的安全关联的数量是有限的。IPv4和IPv6也是如此。
Since SLAAC does not make use of a single and potentially trusted DHCP server, but depends on the node obtaining the address, securing the insertion of updates into DDNS may need a security association between each node and the DDNS server. This is discussed further in [RFC4472].
由于SLAAC不使用单个且可能受信任的DHCP服务器，而是依赖于获取地址的节点，因此确保将更新插入DDNS可能需要每个节点和DDNS服务器之间的安全关联。这将在[RFC4472]中进一步讨论。
Using the Privacy Extensions to SLAAC [RFC4941] may significantly increase the rate of updates of DDNS. Even if a node using the Privacy Extensions does not publish its address for 'forward' lookup (as that would effectively compromise the privacy that it is seeking), it may still need to update the reverse DNS records. If the reverse DNS records are not updated, servers that perform reverse DNS checks will not accept connections from the node and it will not be possible to gain access to IP Security (IPsec) keying material stored in DNS [RFC4025]. If the rate of change needed to achieve real privacy has to be increased (see Section 2.1.7), the update rate for DDNS may be excessive.
使用SLAAC[RFC4941]的隐私扩展可以显著提高DDN的更新率。即使使用隐私扩展的节点不发布其地址以进行“正向”查找（因为这将有效地损害其正在寻求的隐私），它可能仍然需要更新反向DNS记录。如果未更新反向DNS记录，则执行反向DNS检查的服务器将不接受来自节点的连接，并且无法访问存储在DNS中的IP安全（IPsec）密钥材料[RFC4025]。如果必须提高实现真正隐私所需的变更率（见第2.1.7节），DDN的更新率可能过高。
Similarly, the cryptographically generated addresses used by SEND [RFC3971] are expected to be periodically regenerated in line with recommendations for maximum key lifetimes. This regeneration could also impose a significant extra load on DDNS.
类似地，SEND[RFC3971]使用的加密生成的地址预期会根据最大密钥寿命的建议定期重新生成。这种再生还可能对DDN施加显著的额外负载。
A number of security issues relating to IPv6 Extension headers have been identified. Several of these are a result of ambiguous or incomplete specification in the base IPv6 specification [RFC2460].
已经确定了许多与IPv6扩展头相关的安全问题。其中一些是由于基本IPv6规范[RFC2460]中的规范不明确或不完整造成的。
In IPv4, deep packet inspection techniques are used to implement policing and filtering both as part of routers and in middleboxes such as firewalls. Fully extending these techniques to IPv6 would require inspection of all the extension headers in a packet. This is essential to ensure that policy constraints on the use of certain headers and options are enforced and to remove, at the earliest opportunity, packets containing potentially damaging unknown options.
在IPv4中，深度数据包检查技术被用来作为路由器和防火墙等中间盒的一部分来实现监控和过滤。将这些技术完全扩展到IPv6需要检查数据包中的所有扩展头。这对于确保对某些报头和选项的使用实施策略约束，并尽早删除包含潜在破坏性未知选项的数据包至关重要。
This requirement appears to conflict with Section 4 of the IPv6 specification in [RFC2460] which requires that only hop-by-hop options are processed at any node through which the packet passes until the packet reaches the appropriate destination (either the final destination or a routing header waypoint).
该要求似乎与[RFC2460]中IPv6规范的第4节相冲突，该节要求在数据包经过的任何节点上只处理逐跳选项，直到数据包到达适当的目的地（最终目的地或路由报头航路点）。
Also, [RFC2460] forbids processing the headers other than in the order in which they appear in the packet.
此外，[RFC2460]禁止处理报头，而不是按照它们在数据包中出现的顺序。
A further ambiguity relates to whether an intermediate node should discard a packet that contains a header or destination option which it does not recognize. If the rules above are followed slavishly, it is not (or may not be) legitimate for the intermediate node to discard the packet because it should not be processing those headers or options.
另一个模糊性涉及中间节点是否应丢弃包含其不识别的报头或目的地选项的分组。如果严格遵循上述规则，中间节点放弃数据包是不合法的（或者可能不合法），因为它不应该处理这些头或选项。
Therefore, [RFC2460] does not appear to take account of the behavior of middleboxes and other non-final destinations that may be inspecting the packet, and thereby potentially limits the security protection of these boxes. Firewall vendors and administrators may choose to ignore these rules in order to provide enhanced security as this does not appear to have any serious consequences with the currently defined set of extensions. However, administrators should be aware that future extensions might require different treatment.
因此，[RFC2460]似乎没有考虑到可能正在检查数据包的中间盒和其他非最终目的地的行为，因此可能会限制这些盒子的安全保护。防火墙供应商和管理员可以选择忽略这些规则以提供增强的安全性，因为这似乎不会对当前定义的扩展集产生任何严重后果。但是，管理员应该知道，将来的扩展可能需要不同的处理。
There is a further problem for middleboxes that want to examine the transport headers that are located at the end of the IPv6 header chain. In order to locate the transport header or other protocol data unit, the node has to parse the header chain.
对于想要检查位于IPv6报头链末端的传输报头的中间盒，还有一个问题。为了定位传输头或其他协议数据单元，节点必须解析头链。
The IPv6 specification [RFC2460] does not mandate the use of the Type-Length-Value (TLV) format with a fixed layout for the start of each header although it is used for the majority of headers currently defined. (Only the Type field is guaranteed in size and offset.)
IPv6规范[RFC2460]没有强制要求在每个报头的开头使用具有固定布局的类型长度值（TLV）格式，尽管它用于当前定义的大多数报头。（只有类型字段的大小和偏移量得到保证。）
Therefore, a middlebox cannot guarantee to be able to process header chains that may contain headers defined after the box was manufactured. As discussed further in Section 2.1.9.3, middleboxes ought not to have to know the detailed layout of all header types in use but still need to be able to skip over such headers to find the transport payload start. If this is not possible, it either limits the security policy that can be applied in firewalls or makes it difficult to deploy new extension header types.
因此，中间盒不能保证能够处理可能包含在盒子制造后定义的标题的标题链。如第2.1.9.3节中进一步讨论的，中间盒不必知道所有正在使用的报头类型的详细布局，但仍然需要能够跳过这些报头以找到传输有效负载的起点。如果这是不可能的，它会限制可应用于防火墙的安全策略，或者使部署新的扩展头类型变得困难。
At the time of writing, only the Fragment Header does not fully conform to the TLV format used for other extension headers. In practice, many firewalls reconstruct fragmented packets before performing deep packet inspection, so this divergence is less problematic than it might have been, and is at least partially justified because the full header chain is not present in all fragments.
在编写本文时，只有片段头不完全符合用于其他扩展头的TLV格式。在实践中，许多防火墙在执行深度数据包检查之前会重建碎片数据包，因此这种分歧的问题比可能的要小，并且至少部分合理，因为完整的头链并不存在于所有碎片中。
Hop-by-hop and destination options may also contain unknown options. However, the options are required to be encoded in TLV format so that intermediate nodes can skip over them during processing, unlike the enclosing extension headers.
逐跳和目标选项也可能包含未知选项。但是，这些选项需要以TLV格式编码，以便中间节点可以在处理过程中跳过它们，这与封闭的扩展头不同。
A strict security policy might dictate that packets containing either unknown headers or destination options are discarded by firewalls or other filters. This requires the firewall to process the whole extension header chain, which may be currently in conflict with the IPv6 specification as discussed in Section 2.1.9.1.
严格的安全策略可能要求防火墙或其他过滤器丢弃包含未知标头或目标选项的数据包。这要求防火墙处理整个扩展头链，这可能与第2.1.9.1节中讨论的IPv6规范存在冲突。
Even if the firewall does inspect the whole header chain, it may not be sensible to discard packets with items unrecognized by the firewall: the intermediate node has no knowledge of which options and headers are implemented in the destination node and IPv6 has been deliberately designed to be extensible through adding new header options. This poses a dilemma for firewall administrators. On the one hand, admitting packets with 'unknown' options is a security risk, but dropping them may disable a useful new extension. The best compromise appears to be to select firewalls that provide a configurable discard policy based on the types of the extensions. Then, if a new extension is standardized, administrators can reconfigure firewalls to pass packets with legitimate items that they would otherwise not recognize because their hardware or software is not aware of a new definition. Provided that the new extensions conform to the TLV layout followed by current extensions, the firewall would not need detailed knowledge of the function or layout of the extension header.
即使防火墙确实检查了整个报头链，丢弃包含防火墙无法识别的项目的数据包也可能是不明智的：中间节点不知道在目标节点中实现了哪些选项和报头，IPv6被故意设计为通过添加新的报头选项来扩展。这给防火墙管理员带来了一个难题。一方面，允许具有“未知”选项的数据包存在安全风险，但丢弃它们可能会禁用有用的新扩展。最好的折衷办法似乎是根据扩展的类型选择提供可配置丢弃策略的防火墙。然后，如果一个新的扩展被标准化，管理员可以重新配置防火墙，以传递包含合法项目的数据包，否则他们将无法识别这些项目，因为他们的硬件或软件不知道新的定义。如果新扩展符合当前扩展遵循的TLV布局，则防火墙不需要详细了解扩展头的功能或布局。
IPv6 does not limit the number of hop-by-hop options that can be present in a hop-by-hop option header, and any option can appear multiple times. The lack of a limit and the provision of extensibility bits that force nodes to ignore classes of options that they do not understand can be used to mount denial-of-service attacks affecting all nodes on a path. A packet with large numbers of unknown hop-by-hop options will be processed at every node through which it is forwarded, consuming significant resources to determine what action should be taken for each option. Current options with the exception of Pad1 and PadN should not appear more than once so that packets with inappropriately repeated options can be dropped. However, keeping track of which options have been seen adds complexity to firewalls and may not apply to future extensions. See Section 2.1.9.3 for a discussion of the advisability of dropping packets with unknown options in firewalls.
IPv6不限制可以出现在逐跳选项标头中的逐跳选项的数量，任何选项都可以出现多次。缺乏限制和提供可扩展性位迫使节点忽略其不了解的选项类，可用于发起影响路径上所有节点的拒绝服务攻击。具有大量未知逐跳选项的数据包将在转发它的每个节点上进行处理，消耗大量资源来确定每个选项应采取的操作。除Pad1和PadN之外的当前选项不应出现一次以上，以便丢弃具有不适当重复选项的数据包。但是，跟踪已经看到的选项会增加防火墙的复杂性，并且可能不适用于未来的扩展。有关在防火墙中丢弃具有未知选项的数据包的可取性的讨论，请参见第2.1.9.3节。
IPv6 allows multiple padding options of arbitrary sizes to be placed in both Hop-by-Hop and Destination option headers.
IPv6允许在逐跳和目标选项标题中放置任意大小的多个填充选项。
PadN options are required to contain zero octets as 'payload'; there is, however, no incentive for receivers to check this. It may therefore be possible to use the 'payload' of padding options as a covert channel. Firewalls and receiving hosts should actively check that PadN only has zero octets in its 'payload'.
PadN选项必须包含零个八位字节作为“有效负载”；然而，没有激励接收者检查这一点。因此，可以使用填充选项的“有效负载”作为隐蔽通道。防火墙和接收主机应主动检查PadN的“有效负载”中是否只有零个八位字节。
There is no legitimate reason for padding beyond the next eight octet boundary since the whole option header is aligned on an eight-octet boundary but cannot be guaranteed to be on a 16 (or higher power of two)-octet boundary. The IPv6 specification allows multiple Pad1 and PadN options to be combined in any way that the source chooses to make up the required padding. Reasonable design choices would appear to be using however many Pad1 options (i.e., zero octets) are needed or using a single PadN option of the required size (from two up to seven octets). Administrators should consider at least logging unusual padding patterns, and may consider dropping packets that contain unusual patterns if they are certain of expected source behavior.
没有正当理由在下一个八位字节边界之外进行填充，因为整个选项标头在八位字节边界上对齐，但不能保证在16位（或更高的二次幂）八位字节边界上。IPv6规范允许以源选择的任何方式组合多个Pad1和PadN选项，以构成所需的填充。合理的设计选择似乎是使用多个Pad1选项（即零个八位字节）或使用所需大小的单个PadN选项（从两个八位字节到七个八位字节）。管理员应该考虑至少记录不寻常的填充模式，并且如果考虑到预期的源行为，则可以考虑丢弃包含异常模式的分组。
The IPv6 router alert option specifies a hop-by-hop option that, if present, signals the router to take a closer look at the packet. This can be used for denial-of-service attacks. By sending a large number of packets containing a router alert option, an attacker can deplete the processor cycles on the routers available to legitimate traffic.
IPv6路由器警报选项指定一个逐跳选项，如果存在该选项，将向路由器发出信号，让其仔细查看数据包。这可用于拒绝服务攻击。通过发送大量包含路由器警报选项的数据包，攻击者可以耗尽合法流量可用的路由器上的处理器周期。
The current specifications of IPv6 in [RFC2460] do not mandate any minimum packet size for the fragments of a packet before the last one, except for the need to carry the unfragmentable part in all fragments.
[RFC2460]中IPv6的当前规范没有要求在最后一个数据包之前，对数据包的片段使用任何最小数据包大小，除非需要在所有片段中携带不可分割的部分。
The unfragmentable part does not include the transport port numbers, so it is possible that the first fragment does not contain sufficient information to carry out deep packet inspection involving the port numbers.
不可分割部分不包括传输端口号，因此第一个片段可能不包含足够的信息来执行涉及端口号的深度包检查。
Packets with overlapping fragments are considered to be a major security risk, but the reassembly rules for fragmented packets in [RFC2460] do not mandate behavior that would minimize the effects of overlapping fragments.
具有重叠片段的数据包被认为是一个主要的安全风险，但[RFC2460]中针对碎片数据包的重组规则并不强制要求将重叠片段的影响降至最低的行为。
In order to ensure that deep packet inspection can be carried out correctly on fragmented packets, many firewalls and other nodes that use deep packet inspection will collect the fragments and reassemble the packet before examining it. Depending on the implementation of packet reassembly and the treatment of packet fragments in these nodes, the specification issues mentioned potentially leave IPv6 open to the sort of attacks described in [RFC1858] and [RFC3128] for IPv4.
为了确保能够对碎片数据包正确执行深度数据包检查，许多使用深度数据包检查的防火墙和其他节点将在检查数据包之前收集碎片并重新组装数据包。根据数据包重组的实现和这些节点中数据包碎片的处理，上述规范问题可能会导致IPv6受到[RFC1858]和[RFC3128]中描述的IPv4攻击。
The following steps can be taken to mitigate these threats:
可以采取以下步骤来缓解这些威胁：
o Although permitted in [RFC2460], there is no reason for a source to generate overlapping packet fragments, and overlaps could be prohibited in a future revision of the protocol specification. Firewalls should drop all packets with overlapped fragments: certain implementations both in firewalls and other nodes already drop such packets.
o 尽管[RFC2460]中允许，但源没有理由生成重叠的数据包片段，并且在协议规范的未来版本中可以禁止重叠。防火墙应该丢弃所有具有重叠片段的数据包：防火墙和其他节点中的某些实现已经丢弃了此类数据包。
o Specifying a minimum size for packet fragments does not help in the same way as it does for IPv4 because IPv6 extension headers can be made to appear very long: an attacker could insert one or more undefined destination options with long lengths and the 'ignore if unknown' bit set. Given the guaranteed minimum MTU of IPv6, it seems reasonable that hosts should be able to ensure that the transport port numbers are in the first fragment in almost all cases and that deep packet inspection should be very suspicious of first fragments that do not contain them (see also the discussion of fragment sizes in Section 2.1.11).
o 指定数据包片段的最小大小与对IPv4的帮助不同，因为IPv6扩展头可能会显示得很长：攻击者可以插入一个或多个长度较长的未定义目标选项和“如果未知则忽略”位集。考虑到IPv6保证的最小MTU，主机应该能够在几乎所有情况下确保传输端口号在第一个片段中，并且深度数据包检查应该非常怀疑不包含它们的第一个片段（另请参见第2.1.11节中关于片段大小的讨论）。
Packet reassembly in IPv6 hosts also opens up the possibility of various fragment-related security attacks. Some of these are analogous to attacks identified for IPv4. Of particular concern is a DoS attack based on sending large numbers of small fragments without a terminating last fragment that would potentially overload the reconstruction buffers and consume large amounts of CPU resources.
IPv6主机中的数据包重组还可能引发各种碎片相关的安全攻击。其中一些类似于针对IPv4的攻击。特别值得关注的是，基于发送大量小片段而不终止最后一个片段的DoS攻击可能会使重建缓冲区过载并消耗大量CPU资源。
Mandating the size of packet fragments could reduce the impact of this kind of attack by limiting the rate at which fragments could arrive and limiting the number of fragments that need to be processed, but this is not currently specified by the IPv6 standard. In practice, reasonable design choices in protocol stacks are likely to either maximize the size of all fragments except the final one
规定数据包碎片的大小可以通过限制碎片可能到达的速率和限制需要处理的碎片的数量来减少此类攻击的影响，但IPv6标准目前并未规定这一点。在实践中，协议栈中的合理设计选择可能会使除最后一个片段之外的所有片段的大小最大化
using the path MTU (most likely choice), or distribute the data evenly in the required minimum number of fragments. In either case, the smallest non-final fragment would be at least half the guaranteed minimum MTU (640 octets) -- the worst case arises when a payload is just too large for a single packet and is divided approximately equally between two packets. Administrators should consider configuring firewalls and hosts to drop non-final fragments smaller than 640 octets.
使用路径MTU（最有可能的选择），或将数据均匀地分布在所需的最小片段数中。在任何一种情况下，最小的非最终片段都至少是保证的最小MTU（640个八位组）的一半——最坏的情况是，有效负载对于单个数据包来说太大，并且在两个数据包之间几乎相等。管理员应该考虑配置防火墙和主机来删除小于640个八位字节的非最终片段。
All IPv6 nodes are required to configure a link-local address on each interface. This address is used to communicate with other nodes directly connected to the link accessed via the interface, especially during the neighbor discovery and autoconfiguration processes. Link-local addresses are fundamental to the operation of the Neighbor Discovery Protocol (NDP) [RFC2461] and Stateless Address Autoconfiguration (SLAAC) [RFC2462]. NDP also provides the functionality of associating link-layer and IP addresses provided by the Address Resolution Protocol (ARP) in IPv4 networks.
所有IPv6节点都需要在每个接口上配置链路本地地址。此地址用于与直接连接到通过接口访问的链路的其他节点通信，尤其是在邻居发现和自动配置过程中。链路本地地址是邻居发现协议（NDP）[RFC2461]和无状态地址自动配置（SLAAC）[RFC2462]操作的基础。NDP还提供了关联IPv4网络中地址解析协议（ARP）提供的链路层和IP地址的功能。
The standard version of NDP is subject to a number of security threats related to ARP spoofing attacks on IPv4. These threats are documented in [RFC3756], and mechanisms to combat them are specified in SEcure Neighbor Discovery (SEND) [RFC3971]. SEND is an optional mechanism that is particularly applicable to wireless and other environments where it is difficult to physically secure the link.
NDP的标准版本受到许多与IPv4上的ARP欺骗攻击相关的安全威胁。[RFC3756]中记录了这些威胁，安全邻居发现（SEND）[RFC3971]中规定了应对这些威胁的机制。发送是一种可选机制，特别适用于无线和其他难以物理保护链路的环境。
Because the link-local address can, by default, be acquired without external intervention or control, it allows an attacker to commence communication on the link without needing to acquire information about the address prefixes in use or communicate with any authorities on the link. This feature gives a malicious node the opportunity to mount an attack on any other node that is attached to this link; this vulnerability exists in addition to possible direct attacks on NDP. Link-local addresses may also facilitate the unauthorized use of the link bandwidth ('bandwidth theft') to communicate with another unauthorized node on the same link.
由于默认情况下，可以在无需外部干预或控制的情况下获取链路本地地址，因此攻击者无需获取有关正在使用的地址前缀的信息或与链路上的任何机构进行通信即可在链路上开始通信。此功能使恶意节点有机会在连接到此链接的任何其他节点上发起攻击；除了可能对NDP进行直接攻击外，还存在此漏洞。链路本地地址还可促进未经授权使用链路带宽（“带宽盗窃”）与同一链路上的另一未经授权节点通信。
The vulnerabilities of IPv6 link-local addresses in NDP can be mitigated in several ways. A general solution will require
NDP中IPv6链路本地地址的漏洞可以通过多种方式缓解。一般解决方案需要
o authenticating the link-layer connectivity, for example, by using IEEE 802.1X functionality [IEEE.802-1X] or physical security, and
o 例如，通过使用IEEE 802.1X功能[IEEE.802-1X]或物理安全性验证链路层连接，以及
o using SEcure Neighbor Discovery (SEND) to create a cryptographically generated link-local address (as described in [RFC3971]) that is tied to the authenticated link-layer address.
o 使用安全邻居发现（SEND）创建加密生成的链接本地地址（如[RFC3971]中所述），该地址与经过身份验证的链接层地址相关联。
This solution would be particularly appropriate in wireless LAN deployments where it is difficult to physically secure the infrastructure, but it may not be considered necessary in wired environments where the physical infrastructure can be kept secure by other means.
此解决方案特别适用于无线LAN部署，在无线LAN部署中，基础设施的物理安全性很难实现，但在有线环境中，物理基础设施可以通过其他方式保持安全，因此可能不需要此解决方案。
Limiting the potentiality for abuse of link-local addresses in general packet exchanges is more problematic because there may be circumstances, such as isolated networks, where usage is appropriate and discrimination between use and abuse requires complex filtering rules which have to be implemented on hosts. The risk of misuse may be deemed too small compared with the effort needed to control it, but special attention should be paid to tunnel end-points (see 2.4, 3.2, and 3.3).
限制在一般分组交换中滥用链路本地地址的可能性更成问题，因为在某些情况下，例如隔离网络，使用是适当的，使用和滥用之间的区分需要复杂的过滤规则，必须在主机上实施。与控制滥用所需的努力相比，滥用的风险可能被认为太小，但应特别注意隧道端点（见2.4、3.2和3.3）。
Any filtering has to be provided by a host-based or bridging firewall. In general, link-local addresses are expected to be used by applications that are written to deal with specific interfaces and links. Typically these applications are used for control and management. A node which is attached to multiple links has to deal with the potentially overlapping link-local address spaces associated with these links. IPv6 provides for this through zone identifiers that are used to discriminate between the different address scopes [RFC4007] and the scope identifier that can be associated with a socket address structure [RFC3493]. Most users are unfamiliar with these issues and general purpose applications are not intended to handle this kind of discrimination. link-local addresses are not normally used with the Domain Name System (DNS), and DNS cannot supply zone identifiers. If it is considered necessary to prevent the use of link-local addresses by means other than control and management protocols, administrators may wish to consider limiting the protocols that can be used with link-local addresses. At a minimum, ICMPv6 and any intra-domain routing protocol in use (such as Open Shortest Path First (OSPF) or Routing Information Protocol (RIP)) need to be allowed, but other protocols may also be needed. RIP illustrates the complexity of the filtering problem: its messages are encapsulated as User Datagram Protocol (UDP) payloads, and filtering needs to distinguish RIP messages addressed to UDP port 521 from other UDP messages.
任何过滤都必须由基于主机的防火墙或桥接防火墙提供。一般来说，为处理特定接口和链接而编写的应用程序将使用链接本地地址。通常，这些应用程序用于控制和管理。连接到多个链接的节点必须处理与这些链接相关联的可能重叠的链接本地地址空间。IPv6通过用于区分不同地址作用域[RFC4007]和可与套接字地址结构[RFC3493]关联的作用域标识符的区域标识符来实现这一点。大多数用户不熟悉这些问题，通用应用程序不打算处理此类歧视。链接本地地址通常不与域名系统（DNS）一起使用，DNS不能提供区域标识符。如果认为有必要防止通过控制和管理协议以外的方式使用链路本地地址，管理员可能希望考虑限制可与链路本地地址一起使用的协议。至少需要允许使用ICMPv6和任何正在使用的域内路由协议（如开放最短路径优先（OSPF）或路由信息协议（RIP）），但也可能需要其他协议。RIP说明了过滤问题的复杂性：它的消息被封装为用户数据报协议（UDP）有效负载，过滤需要将发往UDP端口521的RIP消息与其他UDP消息区分开来。
As part of the Neighbor Discovery process, routers on a link advertise their capabilities in Router Advertisement messages. The version of NDP defined in [RFC2461] does not protect the integrity of these messages or validate the assertions made in the messages with the result that any node that connects to the link can maliciously claim to offer routing services that it will not fulfill, and
作为邻居发现过程的一部分，链路上的路由器在路由器公告消息中公布其功能。[RFC2461]中定义的NDP版本不保护这些消息的完整性，也不验证消息中的断言，从而导致连接到链路的任何节点都可以恶意声称提供其无法实现的路由服务，以及
advertise inappropriate prefixes and parameters. These threats have been documented in [RFC3756].
公布不适当的前缀和参数。这些威胁已记录在[RFC3756]中。
A malicious node may also be able to carry out a DoS attack by deprecating an established valid prefix (by advertising it with a zero lifetime). Similar DoS attacks are possible if the optional Router Selection mechanism is implemented as described in the security considerations of [RFC4191].
恶意节点还可以通过弃用已建立的有效前缀（以零生存期公布）来执行DoS攻击。如果按照[RFC4191]中的安全注意事项实施可选的路由器选择机制，则可能发生类似的DoS攻击。
SEND [RFC3971] can be used to provide verification that routers are authorized to provide the services they advertise through a certificate-based mechanism. This capability of SEND is also particularly appropriate for wireless environments where clients are reliant on the assertions of the routers rather than a physically secured connection.
SEND[RFC3971]可用于验证路由器是否有权通过基于证书的机制提供其发布的服务。这种发送功能也特别适合于无线环境，其中客户端依赖于路由器的断言，而不是物理安全连接。
If a host deploys the optional host-to-router load-sharing mechanism [RFC4311], a malicious application could carry out a DoS attack on one or more of the load-sharing routers if the application is able to use knowledge of the load-sharing algorithm to synthesize traffic that subverts the load-sharing algorithm and directs a large volume of bogus traffic towards a subset of the routers. The likelihood of such an attack can be reduced if the implementation uses a sufficiently sophisticated load sharing algorithm as described in the security considerations of [RFC4311].
如果主机部署可选的主机到路由器负载共享机制[RFC4311]，如果恶意应用程序能够使用负载共享算法的知识来合成破坏负载共享算法并将大量虚假流量导向路由器子集的流量，则恶意应用程序可以对一个或多个负载共享路由器执行DoS攻击。如果实现使用[RFC4311]的安全注意事项中描述的足够复杂的负载共享算法，则可以降低此类攻击的可能性。
Mobile IPv6 offers significantly enhanced security compared with Mobile IPv4 especially when using optimized routing and care-of addresses. Return routability checks are used to provide relatively robust assurance that the different addresses that a mobile node uses as it moves through the network do indeed all refer to the same node. The threats and solutions are described in [RFC3775], and a more extensive discussion of the security aspects of the design can be found in [RFC4225].
与移动IPv4相比，移动IPv6提供了显著增强的安全性，特别是在使用优化的路由和转交地址时。返回可路由性检查用于提供相对可靠的保证，即移动节点在网络中移动时使用的不同地址确实都指向同一节点。[RFC3775]中描述了威胁和解决方案，在[RFC4225]中可以找到对设计安全方面更广泛的讨论。
The Home Address option specified in early versions of Mobile IPv6 would have allowed a trivial source spoofing attack: hosts were required to substitute the source address of incoming packets with the address in the option, thereby potentially evading checks on the packet source address. The version of Mobile IPv6 as standardized in
在早期版本的移动IPv6中指定的Home Address选项将允许一次微不足道的源欺骗攻击：要求主机用选项中的地址替换传入数据包的源地址，从而可能避免对数据包源地址的检查。中标准化的移动IPv6版本
[RFC3775] has removed this issue by ensuring that the Home Address destination option is only processed if there is a corresponding binding cache entry and securing Binding Update messages.
[RFC3775]已通过确保只有在存在相应的绑定缓存项和保护绑定更新消息时，才会处理Home Address destination选项，从而消除了此问题。
A number of pre-standard implementations of Mobile IPv6 were available that implemented this obsolete and insecure option: care should be taken to avoid running such obsolete systems.
许多移动IPv6的预标准实现都实现了这一过时且不安全的选项：应注意避免运行此类过时的系统。
Overloaded functionality is always a double-edged sword: it may yield some deployment benefits, but often also incurs the price that comes with ambiguity.
过载的功能总是一把双刃剑：它可能会带来一些部署好处，但往往也会带来模糊性带来的代价。
One example of such is IPv4-mapped IPv6 addresses (::ffff/96): a representation of an IPv4 address as an IPv6 address inside an operating system as defined in [RFC3493]. Since the original specification, the use of IPv4-mapped addresses has been extended to a transition mechanism, Stateless IP/ICMP Translation algorithm (SIIT) [RFC2765], where they are potentially used in the addresses of packets on the wire.
其中一个例子是IPv4映射的IPv6地址（：：ffff/96）：IPv4地址作为操作系统内IPv6地址的表示，如[RFC3493]中所定义。自最初的规范以来，IPv4映射地址的使用已扩展到一种转换机制，即无状态IP/ICMP转换算法（SIIT）[RFC2765]，在这种机制中，它们可能用于有线数据包的地址。
Therefore, it becomes difficult to unambiguously discern whether an IPv4 mapped address is really an IPv4 address represented in the IPv6 address format (basic API behavior) *or* an IPv6 address received from the wire (which may be subject to address forgery, etc.). (SIIT behavior). The security issues that arise from the ambiguous behavior when IPv4-mapped addresses are used on the wire include:
因此，很难明确区分IPv4映射地址是否真的是以IPv6地址格式表示的IPv4地址（基本API行为）*或*从线路接收的IPv6地址（可能存在地址伪造等）。（SIIT行为）。当在线路上使用IPv4映射地址时，由于不明确的行为而产生的安全问题包括：
o If an attacker transmits an IPv6 packet with ::ffff:127.0.0.1 in the IPv6 source address field, he might be able to bypass a node's access controls by deceiving applications into believing that the packet is from the node itself (specifically, the IPv4 loopback address, 127.0.0.1). The same attack might be performed using the node's IPv4 interface address instead.
o 如果攻击者在IPv6源地址字段中传输带有：：ffff:127.0.0.1的IPv6数据包，他可能会通过欺骗应用程序使其相信数据包来自节点本身（特别是IPv4环回地址127.0.0.1），从而绕过节点的访问控制。可能使用节点的IPv4接口地址执行相同的攻击。
o If an attacker transmits an IPv6 packet with IPv4-mapped addresses in the IPv6 destination address field corresponding to IPv4 addresses inside a site's security perimeter (e.g., ::ffff: 10.1.1.1), he might be able to bypass IPv4 packet filtering rules and traverse a site's firewall.
o 如果攻击者在与站点安全周界内的IPv4地址相对应的IPv6目标地址字段（例如：：ffff:10.1.1.1）中传输具有IPv4映射地址的IPv6数据包，则他可能能够绕过IPv4数据包过滤规则并穿越站点防火墙。
o If an attacker transmits an IPv6 packet with IPv4-mapped addresses in the IPv6 source and destination fields to a protocol that swaps IPv6 source and destination addresses, he might be able to use a node as a proxy for certain types of attacks. For example, this might be used to construct broadcast multiplication and proxy TCP port scan attacks.
o 如果攻击者将IPv6源和目标字段中具有IPv4映射地址的IPv6数据包传输到交换IPv6源和目标地址的协议，则他可能能够使用节点作为某些类型攻击的代理。例如，这可能用于构造广播乘法和代理TCP端口扫描攻击。
In addition, special cases like these, while giving deployment benefits in some areas, require a considerable amount of code complexity (e.g., in the implementations of bind() system calls and reverse DNS lookups) that is probably undesirable but can be managed in this case.
此外，类似这样的特殊情况虽然在某些方面有部署优势，但需要相当大的代码复杂性（例如，在bind（）系统调用和反向DNS查找的实现中），这可能是不需要的，但在这种情况下可以管理。
In practice, although the packet translation mechanisms of SIIT are specified for use in "Network Address Translator - Protocol Translator (NAT-PT)" [RFC2766], NAT-PT uses a mechanism different from IPv4-mapped IPv6 addresses for communicating embedded IPv4 addresses in IPv6 addresses. Also, SIIT is not recommended for use as a standalone transition mechanism. Given the issues that have been identified, it seems appropriate that mapped addresses should not be used on the wire. However, changing application behavior by deprecating the use of mapped addresses in the operating system interface would have significant impact on application porting methods as described in [RFC4038], and it is expected that IPv4- mapped IPv6 addresses will continue to be used within the API to aid application portability.
实际上，尽管SIIT的数据包转换机制指定用于“网络地址转换器-协议转换器（NAT-PT）”[RFC2766]，但NAT-PT使用不同于IPv4映射IPv6地址的机制来通信IPv6地址中的嵌入式IPv4地址。此外，不建议将SIIT用作独立的转换机制。鉴于已确定的问题，似乎不应在线路上使用映射地址。但是，通过在操作系统接口中不使用映射地址来改变应用程序行为将对[RFC4038]中所述的应用程序移植方法产生重大影响，预计API中将继续使用IPv4映射的IPv6地址来帮助应用程序的可移植性。
Using the basic API behavior has some security implications in that it adds additional complexity to address-based access controls. The main issue that arises is that an IPv6 (AF_INET6) socket will accept IPv4 packets even if the node has no IPv4 (AF_INET) sockets open. This has to be taken into account by application developers and may allow a malicious IPv4 peer to access a service even if there are no open IPv4 sockets. This violates the security principle of "least surprise".
使用基本API行为会带来一些安全隐患，因为它会增加基于地址的访问控制的复杂性。出现的主要问题是，即使节点没有打开IPv4（AF_INET）套接字，IPv6（AF_INET 6）套接字也会接受IPv4数据包。应用程序开发人员必须考虑这一点，即使没有打开的IPv4套接字，也可能允许恶意IPv4对等方访问服务。这违反了“最少意外”的安全原则。
One of the major design aims of IPv6 has been to maintain the original IP architectural concept of end-to-end transparency. Transparency can help foster technological innovation in areas such as peer-to-peer communication, but maintaining the security of the network at the same time requires some modifications in the network architecture. Ultimately, it is also likely to need changes in the security model as compared with the norms for IPv4 networks.
IPv6的主要设计目标之一是保持端到端透明的原始IP体系结构概念。透明度有助于促进对等通信等领域的技术创新，但同时维护网络安全需要对网络架构进行一些修改。最终，与IPv4网络的规范相比，还可能需要对安全模型进行更改。
The necessity of introducing Network Address Translators (NATs) into IPv4 networks, resulting from a shortage of IPv4 addresses, has removed the end-to-end transparency of most IPv4 connections: the use of IPv6 would restore this transparency. However, the use of NATs, and the associated private addressing schemes, has become inappropriately linked to the provision of security in enterprise networks. The restored end-to-end transparency of IPv6 networks can
由于IPv4地址不足，有必要在IPv4网络中引入网络地址转换器（NAT），这消除了大多数IPv4连接的端到端透明度：使用IPv6将恢复这种透明度。然而，NAT的使用以及相关的专用寻址方案已与企业网络的安全性提供不适当地联系在一起。可以恢复IPv6网络的端到端透明度
therefore be seen as a threat by poorly informed enterprise network managers. Some seem to want to limit the end-to-end capabilities of IPv6, for example by deploying private, local addressing and translators, even when it is not necessary because of the abundance of IPv6 addresses.
因此，信息不灵通的企业网络经理会将其视为一种威胁。有些人似乎想限制IPv6的端到端功能，例如通过部署专用、本地寻址和转换器，即使由于IPv6地址丰富而不需要这样做。
Recommendations for designing an IPv6 network to meet the perceived security and connectivity requirements implicit in the current usage of IPv4 NATs whilst maintaining the advantages of IPv6 end-to-end transparency are described in "IP Version 6 Network Architecture Protection" [RFC4864].
“IP版本6网络体系结构保护”[RFC4864]中介绍了设计IPv6网络以满足当前IPv4 NAT使用中隐含的安全性和连接性要求，同时保持IPv6端到端透明性优势的建议。
The favored model for enterprise network security in IPv4 stresses the use of a security perimeter policed by autonomous firewalls and incorporating the NATs. Both perimeter firewalls and NATs introduce asymmetry and reduce the transparency of communications through these perimeters. The symmetric bidirectionality and transparency that are extolled as virtues of IPv6 may seem to be at odds with this model. Consequently, network managers may even see them as undesirable attributes, in conflict with their need to control threats to and attacks on the networks they administer.
IPv4中受欢迎的企业网络安全模型强调使用由自主防火墙控制的安全周界，并结合NAT。周界防火墙和NAT都引入了不对称性，降低了通过这些周界进行通信的透明度。被誉为IPv6优点的对称双向性和透明性似乎与此模型不符。因此，网络管理员甚至可能将其视为不受欢迎的属性，这与他们控制对其管理的网络的威胁和攻击的需要相冲突。
It is worth noting that IPv6 does not *require* end-to-end connectivity. It merely provides end-to-end addressability; the connectivity can still be controlled using firewalls (or other mechanisms), and it is indeed wise to do so.
值得注意的是，IPv6不*需要*端到端连接。它只提供端到端的寻址能力；仍然可以使用防火墙（或其他机制）控制连接，这样做确实是明智的。
A number of matters indicate that IPv6 networks should migrate towards an improved security model, which will increase the overall security of the network while at the same time facilitating end-to-end communication:
许多问题表明，IPv6网络应向改进的安全模型迁移，这将提高网络的整体安全性，同时促进端到端通信：
o Increased usage of end-to-end security especially at the network layer. IPv6 mandates the provision of IPsec capability in all nodes, and increasing usage of end-to-end security is a challenge to current autonomous firewalls that are unable to perform deep packet inspection on encrypted packets. It is also incompatible with NATs because they modify the packets, even when packets are only authenticated rather than encrypted.
o 增加了端到端安全性的使用，尤其是在网络层。IPv6要求在所有节点中提供IPsec功能，而端到端安全性的增加使用对当前无法对加密数据包执行深度数据包检查的自治防火墙是一个挑战。它也与NAT不兼容，因为NAT修改数据包，即使数据包只是经过身份验证而不是加密。
o Acknowledgement that over-reliance on the perimeter model is potentially dangerous. An attacker who can penetrate today's perimeters will have free rein within the perimeter, in many cases. Also a successful attack will generally allow the attacker to capture information or resources and make use of them.
o 承认过度依赖周边模型具有潜在危险。在许多情况下，一个能够穿透今天周界的攻击者可以在周界内自由驰骋。此外，成功的攻击通常允许攻击者捕获信息或资源并加以利用。
o Development of mechanisms such as 'Trusted Computing' [TCGARCH] that will increase the level of trust that network managers are able to place on hosts.
o 开发“可信计算”[TCGARCH]等机制，提高网络管理员对主机的信任水平。
o Development of centralized security policy repositories and secure distribution mechanisms that, in conjunction with trusted hosts, will allow network managers to place more reliance on security mechanisms at the end-points. The mechanisms are likely to include end-node firewalling and intrusion detection systems as well as secure protocols that allow end-points to influence the behavior of perimeter security devices.
o 开发集中的安全策略存储库和安全分发机制，与受信任的主机一起使用，将允许网络管理员在端点更多地依赖安全机制。这些机制可能包括端节点防火墙和入侵检测系统，以及允许端点影响周边安全设备行为的安全协议。
o Review of the role of perimeter devices with increased emphasis on intrusion detection, and network resource protection and coordination to thwart distributed denial-of-service attacks.
o 审查外围设备的作用，更加强调入侵检测、网络资源保护和协调，以阻止分布式拒绝服务攻击。
Several of the technologies required to support an enhanced security model are still under development, including secure protocols to allow end-points to control firewalls: the complete security model utilizing these technologies is now emerging but still requires some development.
支持增强安全模型所需的若干技术仍在开发中，包括允许端点控制防火墙的安全协议：利用这些技术的完整安全模型目前正在出现，但仍需要一些开发。
In the meantime, initial deployments will need to make use of similar firewalling and intrusion detection techniques to IPv4 that may limit end-to-end transparency temporarily, but should be prepared to use the new security model as it develops and avoid the use of NATs by the use of the architectural techniques described in [RFC4864]. In particular, using NAT-PT [RFC2766] as a general purpose transition mechanism should be avoided as it is likely to limit the exploitation of end-to-end security and other IPv6 capabilities in the future as explained in [RFC4966].
同时，初始部署将需要使用与IPv4类似的防火墙和入侵检测技术，这可能暂时限制端到端的透明度，但应准备在开发时使用新的安全模型，并通过使用[RFC4864]中描述的体系结构技术避免使用NAT。特别是，应避免使用NAT-PT[RFC2766]作为通用转换机制，因为如[RFC4966]中所述，这可能会限制未来对端到端安全和其他IPv6功能的利用。
IPv6 in IPv6 tunnels can be used to circumvent security checks, so it is essential to filter packets both at tunnel ingress and egress points (the encapsulator and decapsulator) to ensure that both the inner and outer addresses are acceptable, and the tunnel is not being used to carry inappropriate traffic. [RFC3964], which is primarily about the 6to4 transition tunneling mechanism (see Section 3.1), contains useful discussions of possible attacks and ways to counteract these threats.
IPv6隧道中的IPv6可用于规避安全检查，因此必须在隧道入口和出口点（封装器和解封器）过滤数据包，以确保内部和外部地址都是可接受的，并且隧道未被用于承载不适当的流量。[RFC3964]主要是关于6to4转换隧道机制的（见第3.1节），包含了关于可能的攻击和对抗这些威胁的方法的有用讨论。
The more complicated the IPv6 transition/coexistence becomes, the greater the danger that security issues will be introduced either
IPv6转换/共存变得越复杂，引入安全问题的危险也就越大
o in the mechanisms themselves,
o 在机制本身,，
o in the interaction between mechanisms, or
o 在机制之间的相互作用中，或
o by introducing unsecured paths through multiple mechanisms.
o 通过多种机制引入不安全路径。
These issues may or may not be readily apparent. Hence, it would be desirable to keep the mechanisms simple (as few in number as possible and built from pieces as small as possible) to simplify analysis.
这些问题可能显而易见，也可能不显而易见。因此，希望保持机构简单（数量尽可能少，并且由尽可能小的部件构建），以简化分析。
One case where such security issues have been analyzed in detail is the 6to4 tunneling mechanism [RFC3964].
详细分析此类安全问题的一个案例是6to4隧道机制[RFC3964]。
As tunneling has been proposed as a model for several more cases than are currently being used, its security properties should be analyzed in more detail. There are some generic dangers to tunneling:
由于隧道作为一种模型已被提议用于比目前使用的更多的情况，因此应更详细地分析其安全特性。隧道施工有一些常见的危险：
o It may be easier to avoid ingress filtering checks.
o 避免进入过滤检查可能更容易。
o It is possible to attack the tunnel interface: several IPv6 security mechanisms depend on checking that Hop Limit equals 255 on receipt and that link-local addresses are used. Sending such packets to the tunnel interface is much easier than gaining access to a physical segment and sending them there.
o 有可能攻击隧道接口：几个IPv6安全机制依赖于检查接收时的跃点限制是否等于255，以及是否使用了链路本地地址。将此类数据包发送到隧道接口要比访问物理段并将其发送到那里容易得多。
o Automatic tunneling mechanisms are typically particularly dangerous as there is no pre-configured association between end points. Accordingly, at the receiving end of the tunnel, packets have to be accepted and decapsulated from any source. Consequently, special care should be taken when specifying automatic tunneling techniques.
o 自动隧道机制通常特别危险，因为端点之间没有预先配置的关联。因此，在隧道的接收端，必须接受来自任何源的分组并将其解除封装。因此，在指定自动隧道技术时应特别小心。
Two mechanisms have been specified that use automatic tunneling and are intended for use outside a single domain. These mechanisms encapsulate the IPv6 packet directly in an IPv4 packet in the case of 6to4 [RFC3056] or in an IPv4 UDP packet in the case of Teredo [RFC4380]. In each case, packets can be sent and received by any similarly equipped nodes in the IPv4 Internet.
已经指定了两种机制，它们使用自动隧道，并打算在单个域之外使用。对于6to4[RFC3056]或Teredo[RFC4380]而言，这些机制将IPv6数据包直接封装在IPv4数据包中。在每种情况下，数据包都可以由IPv4互联网中任何装备类似的节点发送和接收。
As mentioned in Section 3.1, a major vulnerability in such approaches is that receiving nodes must allow decapsulation of traffic sourced from anywhere in the Internet. This kind of decapsulation function must be extremely well secured because of the wide range of potential sources.
如第3.1节所述，此类方法中的一个主要漏洞是接收节点必须允许对来自互联网任何地方的流量进行解除封装。由于潜在来源的广泛性，这种脱封功能必须非常安全。
An even more difficult problem is how these mechanisms are able to establish communication with native IPv6 nodes or between the automatic tunneling mechanisms: such connectivity requires the use of some kind of "relay". These relays could be deployed in various locations such as:
更困难的问题是，这些机制如何能够与本机IPv6节点或自动隧道机制之间建立通信：这种连接需要使用某种“中继”。这些继电器可以部署在不同的位置，例如：
o all native IPv6 nodes,
o 所有本机IPv6节点，
o native IPv6 sites,
o 本机IPv6站点，
o in IPv6-enabled ISPs, or
o 在支持IPv6的ISP中，或
o just somewhere in the Internet.
o 就在互联网的某个地方。
Given that a relay needs to trust all the sources (e.g., in the 6to4 case, all 6to4 routers) that are sending it traffic, there are issues in achieving this trust and at the same time scaling the relay system to avoid overloading a small number of relays.
考虑到中继器需要信任发送其流量的所有源（例如，在6to4情况下，所有6to4路由器），在实现这种信任的同时扩展中继器系统以避免少量中继器过载方面存在问题。
As authentication of such a relay service is very difficult to achieve, and particularly so in some of the possible deployment models, relays provide a potential vehicle for address spoofing, (reflected) denial-of-service attacks, and other threats.
由于此类中继服务的身份验证非常难以实现，尤其是在某些可能的部署模型中，中继为地址欺骗、（反映的）拒绝服务攻击和其他威胁提供了潜在的工具。
Threats related to 6to4 and measures to combat them are discussed in [RFC3964]. [RFC4380] incorporates extensive discussion of the threats to Teredo and measures to combat them.
[RFC3964]中讨论了与6to4相关的威胁和应对措施。[RFC4380]广泛讨论了Teredo面临的威胁以及应对这些威胁的措施。
3.3. Tunneling IPv6 through IPv4 Networks May Break IPv4 Network Security Assumptions
3.3. 通过IPv4网络传输IPv6可能会破坏IPv4网络安全假设
NATs and firewalls have been deployed extensively in the IPv4 Internet, as discussed in Section 2.3. Operators who deploy them typically have some security/operational requirements in mind (e.g., a desire to block inbound connection attempts), which may or may not be misguided.
如第2.3节所述，NAT和防火墙已广泛部署在IPv4 Internet中。部署它们的运营商通常会考虑一些安全/操作要求（例如，想要阻止入站连接尝试），这些要求可能会被误导，也可能不会被误导。
The addition of tunneling can change the security model that such deployments are seeking to enforce. IPv6-over-IPv4 tunneling using protocol 41 is typically either explicitly allowed, or disallowed implicitly. Tunneling IPv6 over IPv4 encapsulated in UDP constitutes a more difficult problem as UDP must usually be allowed to pass
隧道的添加可能会改变此类部署试图实施的安全模型。使用协议41的IPv6-over-IPv4隧道通常是显式允许的，或者是隐式不允许的。通过UDP封装的IPv4传输IPv6是一个更困难的问题，因为通常必须允许UDP通过
through NATs and firewalls. Consequently, using UDP implies the ability to punch holes in NATs and firewalls although, depending on the implementation, this ability may be limited or only achieved in a stateful manner. In practice, the mechanisms have been explicitly designed to traverse both NATs and firewalls in a similar fashion.
通过NAT和防火墙。因此，使用UDP意味着能够在NAT和防火墙中穿孔，尽管根据实现情况，这种能力可能会受到限制，或者只能以有状态的方式实现。实际上，这些机制被明确设计为以类似的方式穿越NAT和防火墙。
One possible view is that the use of tunneling is especially questionable in home and SOHO (small office/home office) environments where the level of expertise in network administration is typically not very high; in these environments, the hosts may not be as tightly managed as in others (e.g., network services might be enabled unnecessarily), leading to possible security break-ins or other vulnerabilities.
一种可能的观点是，在家庭和SOHO（小型办公室/家庭办公室）环境中，隧道的使用尤其值得怀疑，因为在这些环境中，网络管理的专业水平通常不是很高；在这些环境中，主机的管理可能不像其他环境中的主机那样严格（例如，可能会不必要地启用网络服务），从而导致可能的安全入侵或其他漏洞。
Holes allowing tunneled traffic through NATs and firewalls can be punched both intentionally and unintentionally. In cases where the administrator or user makes an explicit decision to create the hole, this is less of a problem, although (for example) some enterprises might want to block IPv6 tunneling explicitly if employees were able to create such holes without reference to administrators. On the other hand, if a hole is punched transparently, it is likely that a proportion of users will not understand the consequences: this will very probably result in a serious threat sooner or later.
允许隧道流量通过NAT和防火墙的漏洞可以有意或无意地穿孔。在管理员或用户明确决定创建洞的情况下，问题就不那么严重了，不过（例如）如果员工能够在不咨询管理员的情况下创建此类洞，一些企业可能希望明确阻止IPv6隧道。另一方面，如果穿孔是透明的，很可能有一部分用户不了解其后果：这很可能迟早会造成严重威胁。
When deploying tunneling solutions, especially tunneling solutions that are automatic and/or can be enabled easily by users who do not understand the consequences, care should be taken not to compromise the security assumptions held by the users.
在部署隧道解决方案时，尤其是自动和/或不了解后果的用户可以轻松启用的隧道解决方案，应注意不要损害用户持有的安全假设。
For example, NAT traversal should not be performed by default unless there is a firewall producing a similar by-default security policy to that provided by IPv4 NAT. IPv6-in-IPv4 (protocol 41) tunneling is less of a problem, as it is easier to block if necessary; however, if the host is protected in IPv4, the IPv6 side should be protected as well.
例如，默认情况下不应执行NAT遍历，除非有防火墙生成与IPv4 NAT提供的默认安全策略类似的安全策略。IPv6-in-IPv4（协议41）隧道问题较少，因为在必要时更容易阻止；但是，如果主机在IPv4中受保护，则IPv6端也应受到保护。
As is shown in Appendix A, it is relatively easy to determine the IPv6 address corresponding to an IPv4 address in tunneling deployments. It is therefore vital NOT to rely on "security by obscurity", i.e., assuming that nobody is able to guess or determine the IPv6 address of the host especially when using automatic tunneling transition mechanisms.
如附录A所示，在隧道部署中确定与IPv4地址相对应的IPv6地址相对容易。因此，重要的是不要依赖“隐蔽性安全”，即假设没有人能够猜测或确定主机的IPv6地址，尤其是在使用自动隧道转换机制时。
The network architecture must provide separate IPv4 and IPv6 firewalls with tunneled IPv6 traffic arriving encapsulated in IPv4 packets routed through the IPv4 firewall before being decapsulated, and then through the IPv6 firewall as shown in Figure 1.
网络体系结构必须提供单独的IPv4和IPv6防火墙，通过隧道传输的IPv6流量在解除封装之前通过IPv4防火墙路由到IPv4数据包，然后通过IPv6防火墙到达，如图1所示。
+--------+ +--------+ +--------+
Site | Native | IPv6 |v6 in v4| IPv4 | Native | Public
Network <--->| IPv6 |<---->| Tunnel |<---->| IPv4 |<---> Internet
|Firewall| |Endpoint| |Firewall|
+--------+ +--------+ +--------+
+--------+ +--------+ +--------+
Site | Native | IPv6 |v6 in v4| IPv4 | Native | Public
Network <--->| IPv6 |<---->| Tunnel |<---->| IPv4 |<---> Internet
|Firewall| |Endpoint| |Firewall|
+--------+ +--------+ +--------+
Figure 1: Tunneled Traffic and Firewalls
图1：隧道流量和防火墙
Because IPv6 is a new service for many networks, network managers will often opt to make a pilot deployment in a part of the network to gain experience and understand the problems as well as the benefits that may result from a full production quality IPv6 service.
由于IPv6是许多网络的一项新服务，网络经理通常会选择在网络的某个部分进行试点部署，以获得经验，了解问题以及全面生产质量IPv6服务可能带来的好处。
Unless IPv6 service piloting is done in a manner that is as secure as possible, there is a risk that if security in the pilot does not match up to what is achievable with current IPv4 production service, the comparison can adversely impact the overall assessment of the IPv6 pilot deployment. This may result in a decision to delay or even avoid deploying an IPv6 production service. For example, hosts and routers might not be protected by IPv6 firewalls, even if the corresponding IPv4 service is fully protected by firewalls. The use of tunneling transition mechanisms (see Section 3.3) and the interaction with virtual private networks also need careful attention to ensure that site security is maintained. This is particularly critical where IPv6 capabilities are turned on by default in new equipment or new releases of operating systems: network managers may not be fully aware of the security exposure that this creates.
除非以尽可能安全的方式进行IPv6服务试点，否则，如果试点中的安全性与当前IPv4生产服务的可实现性不匹配，则比较可能会对IPv6试点部署的总体评估产生不利影响。这可能导致决定延迟甚至避免部署IPv6生产服务。例如，主机和路由器可能不受IPv6防火墙的保护，即使相应的IPv4服务完全受防火墙保护。隧道传输机制的使用（见第3.3节）以及与虚拟专用网络的交互也需要仔细注意，以确保维护站点安全。在新设备或新版本操作系统中默认打开IPv6功能的情况下，这一点尤为重要：网络管理员可能没有完全意识到这会造成安全风险。
In some cases, a perceived lack of availability of IPv6 firewalls and other security capabilities, such as intrusion detection systems may have led network managers to resist any kind of IPv6 service deployment. These problems may be partly due to the relatively slow development and deployment of IPv6-capable security equipment, but the major problems appear to have been a lack of information, and more importantly a lack of documented operational experience on which managers can draw. In actual fact, at the time of writing, there are a significant number of alternative IPv6 packet filters and firewalls already in existence that could be used to provide sufficient access controls.
在某些情况下，IPv6防火墙和其他安全功能（如入侵检测系统）的可用性不足可能会导致网络管理员抵制任何类型的IPv6服务部署。这些问题的部分原因可能是由于具备IPv6功能的安全设备的开发和部署相对缓慢，但主要问题似乎是缺乏信息，更重要的是缺乏可供管理者借鉴的书面操作经验。事实上，在撰写本文时，已有大量可供选择的IPv6数据包过滤器和防火墙可用于提供足够的访问控制。
However, there are a small number of areas where the available equipment and capabilities may still be a barrier to secure deployment as of the time of writing:
然而，截至撰写本文时，在少数地区，可用设备和能力可能仍然是安全部署的障碍：
o 'Personal firewalls' with support for IPv6 and intended for use on hosts are not yet widely available.
o 支持IPv6并打算在主机上使用的“个人防火墙”尚未广泛提供。
o Enterprise firewalls are at an early stage of development and may not provide the full range of capabilities needed to implement the necessary IPv6 filtering rules. Network managers often expect the same devices that support and are used for IPv4 today to also become IPv6-capable -- even though this is not really required and the equipment may not have the requisite hardware capabilities to support fast packet filtering for IPv6. Suggestions for the appropriate deployment of firewalls are given in Section 3.3 -- as will be seen from this section, it is usually desirable that the firewalls are in separate boxes, and there is no necessity for them to be same the model of equipment.
o 企业防火墙处于开发的早期阶段，可能无法提供实现必要的IPv6过滤规则所需的全部功能。网络管理者通常期望今天支持IPv4并用于IPv4的设备也能支持IPv6，尽管这并不是真正需要的，而且设备可能不具备支持IPv6快速数据包过滤所需的硬件能力。第3.3节给出了适当部署防火墙的建议——从本节中可以看出，防火墙通常需要放在单独的盒子中，并且没有必要与设备型号相同。
o A lesser factor may be that some design decisions in the IPv6 protocol make it more difficult for firewalls to be implemented and work in all cases, and to be fully future-proof (e.g., when new extension headers are used) as discussed in Section 2.1.9. It is significantly more difficult for intermediate nodes to process the IPv6 header chains than IPv4 packets.
o 一个较小的因素可能是IPv6协议中的一些设计决策使得防火墙在所有情况下都难以实现和工作，并且更难以完全证明未来（例如，当使用新的扩展头时），如第2.1.9节所述。中间节点处理IPv6报头链比处理IPv4数据包要困难得多。
o Adequate Intrusion Detection Systems (IDS) are more difficult to construct for IPv6. IDSs are now beginning to become available but the pattern-based mechanisms used for IPv4 may not be the most appropriate for long-term development of these systems as end-to-end encryption becomes more prevalent. Future systems may be more reliant on traffic flow pattern recognition.
o 为IPv6构建适当的入侵检测系统（IDS）更为困难。ids现在开始可用，但由于端到端加密变得越来越普遍，用于IPv4的基于模式的机制可能并不适合这些系统的长期开发。未来的系统可能更依赖于交通流模式识别。
o Implementations of high availability capabilities supporting IPv6 are also in short supply. In particular, development of the IPv6 version of the Virtual Router Redundancy Protocol (VRRP) [VRRP] has lagged the development of the main IPv6 protocol although alternatives may be available for some environments.
o 支持IPv6的高可用性功能的实现也供不应求。特别是，虚拟路由器冗余协议（VRRP）[VRRP]的IPv6版本的开发滞后于主要IPv6协议的开发，尽管在某些环境中可能有替代方案。
In all these areas, developments are ongoing and they should not be considered a long-term bar to the deployment of IPv6 either as a pilot or production service. The necessary tools are now available to make a secure IPv6 deployment, and with careful selection of components and design of the network architecture, a successful pilot or production IPv6 service can be deployed. Recommendations for secure deployment and appropriate management of IPv6 networks can be found in the documentation archives of the European Union 6net project [SIXNET] and in the Deployment Guide published by the IPv6 Promotion Council of Japan [JpIPv6DC].
在所有这些领域，发展都在进行中，不应将其视为IPv6作为试点或生产服务部署的长期障碍。现在可以使用必要的工具来进行安全的IPv6部署，通过仔细选择组件和设计网络体系结构，可以部署成功的试点或生产IPv6服务。有关IPv6网络的安全部署和适当管理的建议，请参见欧盟6net项目[SIXNET]的文档档案和日本IPv6促进委员会[JpIPv6DC]发布的部署指南。
Some DNS server implementations have flaws that severely affect DNS queries for IPv6 addresses as discussed in [RFC4074]. These flaws can be used for DoS attacks affecting both IPv4 and IPv6 by inducing caching DNS servers to believe that a domain is broken and causing the server to block access to all requests for the domain for a precautionary period.
某些DNS服务器实现存在严重影响IPv6地址DNS查询的缺陷，如[RFC4074]中所述。这些缺陷可用于影响IPv4和IPv6的DoS攻击，通过诱导缓存DNS服务器相信域已断开，并导致服务器在预防期内阻止对域的所有请求的访问。
Whilst in general terms brute force scanning of IPv6 subnets is essentially impossible due to the enormously larger address space of IPv6 and the 64-bit interface identifiers (see Appendix A), this will be obviated if administrators do not take advantage of the large space to use unguessable interface identifiers.
虽然一般而言，由于IPv6的地址空间和64位接口标识符（见附录A）大得多，IPv6子网的暴力扫描基本上是不可能的，但如果管理员不利用大空间使用不可用的接口标识符，则可以避免这种情况。
Because of the unmemorability of complete IPv6 addresses, there is a temptation for administrators to use small integers as interface identifiers when manually configuring them, as might happen on point-to-point links or when provisioning complete addresses from a DHCPv6 server. Such allocations make it easy for an attacker to find active nodes that they can then port scan.
由于完整IPv6地址的不可维护性，管理员在手动配置时可能会使用小整数作为接口标识符，这可能发生在点到点链接上或从DHCPv6服务器提供完整地址时。这样的分配使得攻击者很容易找到活动节点，然后进行端口扫描。
To make use of the larger address space properly, administrators should be very careful when entering IPv6 addresses in their configurations (e.g., access control lists), since numerical IPv6 addresses are more prone to human error than IPv4 due to their length and unmemorability.
为了正确利用较大的地址空间，管理员在其配置（例如访问控制列表）中输入IPv6地址时应非常小心，因为数字IPv6地址由于其长度和不可维护性比IPv4更容易出现人为错误。
It is also essential to ensure that the management interfaces of routers are well secured (e.g., allowing remote access using Secure Shell (SSH) only and ensuring that local craft interfaces have non-default passwords) as the router will usually contain a significant cache of neighbor addresses in its neighbor cache.
还必须确保路由器的管理接口具有良好的安全性（例如，仅允许使用Secure Shell（SSH）进行远程访问，并确保本地craft接口具有非默认密码），因为路由器通常在其邻居缓存中包含大量的邻居地址缓存。
One positive consequence of IPv6 is that nodes that do not require global access can communicate locally just by the use of a link-local address (if very local access is sufficient) or across the site by using a Unique Local Address (ULA). In either case it is easy to ensure that access outside the assigned domain of activity can be controlled by simple filters (which should be the default for link-locals). However, the security hazards of using link-local addresses for general purposes, as documented in Section 2.1.12, should be borne in mind.
IPv6的一个积极结果是，不需要全局访问的节点可以仅通过使用链路本地地址（如果非常本地访问足够）进行本地通信，或者通过使用唯一本地地址（ULA）跨站点进行通信。在任何一种情况下，都可以很容易地确保在指定的活动域之外的访问可以由简单的过滤器控制（这应该是链接局部变量的默认设置）。但是，如第2.1.12节所述，应牢记为一般目的使用链路本地地址的安全危害。
On the other hand, the possibility that a node or interface can have multiple global scope addresses makes access control filtering (both on ingress and egress) more complex and requires higher maintenance levels. Vendors and network administrators need to be aware that multiple addresses are the norm rather than the exception in IPv6: when building and selecting tools for security and management, a highly desirable feature is the ability to be able to 'tokenize' access control lists and configurations in general to cater for multiple addresses and/or address prefixes.
另一方面，节点或接口可能具有多个全局作用域地址，这使得访问控制过滤（入口和出口）更加复杂，需要更高的维护级别。供应商和网络管理员需要意识到，在IPv6中，多个地址是常态而不是例外：在构建和选择安全和管理工具时，一个非常理想的功能是能够“标记化”访问控制列表和配置，以满足多个地址和/或地址前缀的需要。
The addresses could be from the same network prefix (for example, privacy mechanisms [RFC4941] will periodically create new addresses taken from the same prefix, and two or more of these may be active at the same time), or from different prefixes (for example, when a network is multihomed, when for management purposes a node belongs to several subnets on the same link or is implementing anycast services). In all these cases, it is possible that a single host could be using several different addresses with different prefixes and/or different interface identifiers. It is desirable that the security administrator be able to identify that the same host is behind all these addresses.
地址可以来自相同的网络前缀（例如，隐私机制[RFC4941]将定期创建来自相同前缀的新地址，其中两个或多个地址可能同时处于活动状态），也可以来自不同的前缀（例如，当一个网络是多址的，出于管理目的，一个节点属于同一链路上的多个子网，或者正在实施选播服务时）。在所有这些情况下，一台主机可能使用多个不同的地址，具有不同的前缀和/或不同的接口标识符。安全管理员最好能够识别出同一台主机位于所有这些地址的后面。
Some network administrators may find the mutability of addresses when privacy mechanisms are used in their network to be undesirable because of the current difficulties in maintaining access control lists and knowing the origin of traffic. In general, disabling the use of privacy addresses is only possible if the full stateful DHCPv6 mechanism [RFC3315] is used to allocate IPv6 addresses and DHCPv6 requests for privacy addresses are not honored.
由于当前在维护访问控制列表和了解流量来源方面的困难，一些网络管理员可能会发现，在其网络中使用隐私机制时，地址的可变性是不可取的。通常，只有在使用完全有状态的DHCPv6机制[RFC3315]分配IPv6地址并且DHCPv6对隐私地址的请求不被接受时，才可能禁用隐私地址的使用。
In IPv4 it is commonly accepted that some filtering of ICMP packets by firewalls is essential to maintain security. Because of the extended use that is made of ICMPv6 [RFC2461] with a multitude of functions, the simple set of dropping rules that are usually applied in IPv4 need to be significantly developed for IPv6. The blanket dropping of all ICMP messages that is used in some very strict environments is simply not possible for IPv6.
在IPv4中，人们普遍认为防火墙对ICMP数据包的某些过滤对于维护安全至关重要。由于ICMPv6[RFC2461]具有多种功能，因此需要为IPv6开发一组通常应用于IPv4的简单删除规则。在某些非常严格的环境中使用的所有ICMP消息的全面丢弃对于IPv6来说是不可能的。
In an IPv6 firewall, policy needs to allow some messages through the firewall but also has to permit certain messages to and from the firewall, especially those with link-local sources on links to which the firewall is attached. These messages must be permitted to ensure that Neighbor Discovery [RFC2462], Multicast Listener Discovery ([RFC2710], [RFC3810]), and Stateless Address Configuration [RFC4443] work as expected.
在IPv6防火墙中，策略需要允许某些消息通过防火墙，但也必须允许某些消息进出防火墙，特别是那些在连接防火墙的链路上具有链路本地源的消息。必须允许这些消息，以确保邻居发现[RFC2462]、多播侦听器发现（[RFC2710]、[RFC3810]）和无状态地址配置[RFC4443]按预期工作。
Recommendations for filtering ICMPv6 messages can be found in [RFC4890].
有关过滤ICMPv6消息的建议，请参见[RFC4890]。
As described in Section 4.5, certain ICMPv6 error packets need to be passed through a firewall in both directions. This means that some ICMPv6 error packets can be exchanged between inside and outside without any filtering.
如第4.5节所述，某些ICMPv6错误数据包需要在两个方向上通过防火墙。这意味着一些ICMPv6错误数据包可以在内部和外部之间交换，而无需任何过滤。
Using this feature, malicious users can communicate between the inside and outside of a firewall, thus bypassing the administrator's inspection (proxy, firewall, etc.). For example, it might be possible to carry out a covert conversation through the payload of ICMPv6 error messages or to tunnel inappropriate encapsulated IP packets in ICMPv6 error messages. This problem can be alleviated by filtering ICMPv6 errors using a stateful 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错误消息中通过隧道传输不适当的封装IP数据包。通过使用有状态数据包检查机制过滤ICMPv6错误，以确保作为有效负载携带的数据包与进出受保护网络的合法流量相关联，可以缓解此问题。
IPsec provides security to end-to-end communications at the network layer (layer 3). The security features available include access control, connectionless integrity, data origin authentication, protection against replay attacks, confidentiality, and limited traffic flow confidentiality (see [RFC4301] Section 2.1). IPv6 mandates the implementation of IPsec in all conforming nodes, making the usage of IPsec to secure end-to-end communication possible in a way that is generally not available to IPv4.
IPsec在网络层（第3层）为端到端通信提供安全性。可用的安全功能包括访问控制、无连接完整性、数据源身份验证、防止重播攻击、保密性和有限流量保密性（请参见[RFC4301]第2.1节）。IPv6要求在所有一致性节点中实施IPsec，从而使IPsec的使用能够以IPv4通常不可用的方式确保端到端通信的安全。
To secure IPv6 end-to-end communications, IPsec transport mode would generally be the solution of choice. However, use of these IPsec security features can result in novel problems for network administrators and decrease the effectiveness of perimeter firewalls because of the increased prevalence of encrypted packets on which the firewalls cannot perform deep packet inspection and filtering.
为了保护IPv6端到端通信的安全，通常会选择IPsec传输模式。但是，使用这些IPsec安全功能可能会给网络管理员带来新的问题，并降低外围防火墙的有效性，因为加密数据包越来越普遍，防火墙无法对这些数据包执行深度数据包检查和过滤。
One example of such problems is the lack of security solutions in the middlebox, including effective content-filtering, ability to provide DoS prevention based on the expected TCP protocol behavior, and intrusion detection. Future solutions to this problem are discussed in Section 2.3.2. Another example is an IPsec-based DoS (e.g., sending malformed ESP/AH packets) that can be especially detrimental to software-based IPsec implementations.
此类问题的一个例子是，在中间包中缺乏安全解决方案，包括有效的内容过滤、基于预期TCP协议行为提供DoS预防的能力，以及入侵检测。第2.3.2节讨论了该问题的未来解决方案。另一个例子是基于IPsec的DoS（例如，发送格式错误的ESP/AH数据包），这可能对基于软件的IPsec实现特别有害。
With the deployment of IPv6 we can expect the attachment of a very large number of new IPv6-enabled devices with scarce resources and low computing capacity. The resource limitations are generally because of a market requirement for cost reduction. Although the [RFC4294] specifies some mandatory security capabilities for every conformant node, these do not include functions required for a node to be able to protect itself. Accordingly, some such devices may not be able even to perform the minimum set of functions required to protect themselves (e.g., 'personal' firewall, automatic firmware update, enough CPU power to endure DoS attacks). This means a different security scheme may be necessary for such reduced functionality devices.
随着IPv6的部署，我们可以预期将有大量新的支持IPv6的设备连接在一起，这些设备资源稀少，计算能力低。资源限制通常是因为市场需要降低成本。尽管[RFC4294]为每个一致性节点指定了一些强制性的安全功能，但这些功能不包括节点能够自我保护所需的功能。因此，一些此类设备甚至可能无法执行保护自身所需的最低功能集（例如，“个人”防火墙、自动固件更新、足够的CPU能力以承受DoS攻击）。这意味着对于这种功能性降低的设备可能需要不同的安全方案。
There are a number of reasons that make it essential to take particular care when enabling IPv6 in the network equipment:
有许多原因使得在网络设备中启用IPv6时必须特别小心：
Initially, IPv6-enabled router software may be less mature than current IPv4-only implementations, and there is less experience with configuring IPv6 routing, which can result in disruptions to the IPv6 routing environment and (IPv6) network outages.
最初，支持IPv6的路由器软件可能不如当前仅支持IPv4的实现成熟，配置IPv6路由的经验也较少，这可能会导致IPv6路由环境中断和（IPv6）网络中断。
IPv6 processing may not happen at (near) line speed (or at a comparable performance level to IPv4 in the same equipment). A high level of IPv6 traffic (even legitimate, e.g., Network News Transport Protocol, NNTP) could easily overload IPv6 processing especially when it is software-based without the hardware support typical in high-end routers. This may potentially have deleterious knock-on effects on IPv4 processing, affecting availability of both services. Accordingly, if people don't feel confident enough in the IPv6 capabilities of their equipment, they will be reluctant to enable it in their "production" networks.
IPv6处理可能不会以（接近）线路速度（或在同一设备中以与IPv4相当的性能级别）进行。高水平的IPv6通信量（即使是合法的，例如网络新闻传输协议，NNTP）可能很容易使IPv6处理过载，特别是当它是基于软件的，而没有高端路由器中典型的硬件支持时。这可能会对IPv4处理产生有害的连锁反应，影响这两种服务的可用性。因此，如果人们对设备的IPv6功能没有足够的信心，他们将不愿意在“生产”网络中启用它。
Sometimes essential features may be missing from early releases of vendors' software; an example is provision of software enabling IPv6 telnet/SSH access (e.g., to the configuration application of a router), but without the ability to turn it off or limit access to it!
有时，供应商软件的早期版本可能缺少基本功能；例如，提供支持IPv6 telnet/SSH访问的软件（例如，到路由器的配置应用程序），但无法关闭或限制对它的访问！
Sometimes the default IPv6 configuration is insecure. For example, in one vendor's implementation, if you have restricted IPv4 telnet to only a few hosts in the configuration, you need to be aware that IPv6 telnet will be automatically enabled, that the configuration commands
有时默认的IPv6配置是不安全的。例如，在一家供应商的实施中，如果您已将IPv4 telnet限制为配置中的少数主机，则需要注意IPv6 telnet将自动启用，配置命令
used previously do not block IPv6 telnet, that IPv6 telnet is open to the world by default, and that you have to use a separate command to also lock down the IPv6 telnet access.
以前使用的“不阻止IPv6 telnet”，默认情况下IPv6 telnet对世界开放，并且您必须使用单独的命令来锁定IPv6 telnet访问。
Many operator networks have to run interior routing protocols for both IPv4 and IPv6. It is possible to run them both in one routing protocol, or have two separate routing protocols; either approach has its tradeoffs [RFC4029]. If multiple routing protocols are used, one should note that this causes double the amount of processing when links flap or recalculation is otherwise needed -- which might more easily overload the router's CPU, causing slightly slower convergence time.
许多运营商网络必须为IPv4和IPv6运行内部路由协议。可以在一个路由协议中运行它们，或者有两个单独的路由协议；这两种方法都有各自的优缺点[RFC4029]。如果使用多个路由协议，应该注意的是，当需要链路翻转或重新计算时，这会导致处理量加倍——这可能更容易使路由器的CPU过载，导致收敛时间稍慢。
In order to span a single subnet over multiple physical links, a new experimental capability is being trialed in IPv6 to proxy Neighbor Discovery messages. A node with this capability will be called an NDProxy (see [RFC4389]). NDProxies are susceptible to the same security issues as those faced by hosts using unsecured Neighbor Discovery or ARP. These proxies may process unsecured messages, and update the neighbor cache as a result of such processing, thus allowing a malicious node to divert or hijack traffic. This may undermine the advantages of using SEND [RFC3971].
为了在多个物理链路上跨越单个子网，IPv6中正在试用一种新的实验性功能，以代理邻居发现消息。具有此功能的节点称为NDProxy（请参见[RFC4389]）。NDProxy容易受到与使用不安全邻居发现或ARP的主机相同的安全问题的影响。这些代理可能会处理不安全的消息，并作为此类处理的结果更新邻居缓存，从而允许恶意节点转移或劫持流量。这可能会破坏使用SEND[RFC3971]的优势。
If a form of NDProxy is standardized, SEND will need to be extended to support this capability.
如果NDProxy的形式是标准化的，则需要扩展SEND以支持此功能。
This memo attempts to give an overview of security considerations of the different aspects of IPv6, particularly as they relate to the transition to a network in which IPv4- and IPv6-based communications need to coexist.
本备忘录试图概述IPv6不同方面的安全注意事项，特别是与向基于IPv4和IPv6的通信需要共存的网络过渡有关的安全注意事项。
This document draws together the work of many people who have contributed security-related documents to the IPV6 and V6OPS working groups. Alain Durand, Alain Baudot, Luc Beloeil, Sharon Chisholm, Tim Chown, Lars Eggert, Andras Kis-Szabo, Vishwas Manral, Janos Mohacsi, Mark Smith, Alvaro Vives, and Margaret Wassermann provided feedback to improve this document. Satoshi Kondo, Shinsuke Suzuki, and Alvaro Vives provided additional inputs in cooperation with the Deployment Working Group of the Japanese IPv6 Promotion Council and the Euro6IX IST co-funded project, together with inputs from Jordi Palet, Brian Carpenter, and Peter Bieringer. Michael Wittsend and Michael Cole discussed issues relating to probing/mapping and
本文档汇集了许多向IPV6和V6OPS工作组提供安全相关文档的人员的工作。Alain Durand、Alain Baudot、Luc Beloil、Sharon Chisholm、Tim Chown、Lars Eggert、Andras Kis Szabo、Vishwas Manral、Janos Mohacsi、Mark Smith、Alvaro Vives和Margaret Wassermann提供了改进本文件的反馈。Satoshi Kondo、Shinsuke Suzuki和Alvaro Vives与日本IPv6促进委员会部署工作组和Euro6IX IST共同资助项目合作，提供了额外的投入，以及Jordi Palet、Brian Carpenter和Peter Bieringer的投入。Michael Wittsend和Michael Cole讨论了与探测/绘图和
privacy. Craig Metz and Jun-ichiro itojun Hagino did the original work identifying the problems of using IPv4-mapped IPv6 addresses on the wire. Vishwas Manral made further investigations of the impact of tiny fragments on IPv6 security. Francis Dupont raised the issues relating to IPv6 Privacy Addresses. Finally, Pekka Savola wrote a number of documents on aspects IPv6 security which have been subsumed into this work. His document on "Firewalling Considerations for IPv6" (October 2003) originally identified many of the issues with the base IPv6 specification which are documented here.
隐私Craig Metz和Jun ichiro itojun Hagino完成了最初的工作，确定了在线路上使用IPv4映射IPv6地址的问题。Vishwas Manral进一步调查了微小碎片对IPv6安全性的影响。弗朗西斯·杜邦提出了与IPv6隐私地址相关的问题。最后，Pekka Savola编写了许多关于IPv6安全方面的文档，这些文档已经包含在这项工作中。他关于“IPv6的防火墙注意事项”的文档（2003年10月）最初确定了基本IPv6规范的许多问题，本文对此进行了说明。
[RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122]Braden，R.，“互联网主机的要求-通信层”，标准3，RFC 1122，1989年10月。
[RFC2375] Hinden, R. and S. Deering, "IPv6 Multicast Address Assignments", RFC 2375, July 1998.
[RFC2375]Hinden，R.和S.Deering，“IPv6多播地址分配”，RFC 23751998年7月。
[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月。
[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月。
[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月。
[RFC3964] Savola, P. and C. Patel, "Security Considerations for 6to4", RFC 3964, December 2004.
[RFC3964]Savola，P.和C.Patel，“6to4的安全考虑”，RFC 3964，2004年12月。
[RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and B. Zill, "IPv6 Scoped Address Architecture", RFC 4007, March 2005.
[RFC4007]Deering，S.，Haberman，B.，Jinmei，T.，Nordmark，E.，和B.Zill，“IPv6作用域地址体系结构”，RFC 4007，2005年3月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291]Hinden，R.和S.Deering，“IP版本6寻址体系结构”，RFC 42912006年2月。
[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月。
[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月。
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, September 2007.
[RFC4941]Narten，T.，Draves，R.，和S.Krishnan，“IPv6中无状态地址自动配置的隐私扩展”，RFC 49412007年9月。
[FNAT] Bellovin, S., "Technique for Counting NATted Hosts", Proc. Second Internet Measurement Workshop , November 2002, <http://www.research.att.com/~smb/papers/fnat.pdf>.
[FNAT]Bellovin，S.，“计算NATED主机的技术”，Proc。第二次互联网测量研讨会，2002年11月<http://www.research.att.com/~smb/papers/fnat.pdf>。
[ICMP-ATT] Gont, F., "ICMP attacks against TCP", Work in Progress, May 2007.
[ICMP-ATT]Gont，F.，“针对TCP的ICMP攻击”，正在进行的工作，2007年5月。
[IEEE.802-1X] Institute of Electrical and Electronics Engineers, "Port-Based Network Access Control", IEEE Standard for Local and Metropolitan Area Networks 802.1X-2004, December 2004.
[IEEE.802-1X]电气和电子工程师协会，“基于端口的网络访问控制”，IEEE局域网和城域网标准802.1X-2004，2004年12月。
[JpIPv6DC] Deployment WG, "IPv6 Deployment Guideline (2005 Edition)", IPv6 Promotion Council (Japan) Deployment Working Group, 2005, <http://www.v6pc.jp/>.
[JpIPv6DC]部署工作组，“IPv6部署指南（2005年版）”，IPv6促进委员会（日本）部署工作组，2005年<http://www.v6pc.jp/>.
[RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security Considerations for IP Fragment Filtering", RFC 1858, October 1995.
[RFC1858]Ziemba，G.，Reed，D.，和P.Trana，“IP片段过滤的安全考虑”，RFC 1858，1995年10月。
[RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm (SIIT)", RFC 2765, February 2000.
[RFC2765]Nordmark，E.“无状态IP/ICMP转换算法（SIIT）”，RFC2765，2000年2月。
[RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address Translation - Protocol Translation (NAT-PT)", RFC 2766, February 2000.
[RFC2766]Tsirtsis，G.和P.Srisuresh，“网络地址转换-协议转换（NAT-PT）”，RFC 2766，2000年2月。
[RFC3128] Miller, I., "Protection Against a Variant of the Tiny Fragment Attack (RFC 1858)", RFC 3128, June 2001.
[RFC3128]Miller，I.，“防止微小碎片攻击的变体（RFC 1858）”，RFC 31281001年6月。
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3315]Droms，R.，Bound，J.，Volz，B.，Lemon，T.，Perkins，C.，和M.Carney，“IPv6的动态主机配置协议（DHCPv6）”，RFC3315，2003年7月。
[RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. Stevens, "Basic Socket Interface Extensions for IPv6", RFC 3493, February 2003.
[RFC3493]Gilligan，R.，Thomson，S.，Bound，J.，McCann，J.，和W.Stevens，“IPv6的基本套接字接口扩展”，RFC 3493，2003年2月。
[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月。
[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月。
[RFC4025] Richardson, M., "A Method for Storing IPsec Keying Material in DNS", RFC 4025, March 2005.
[RFC4025]Richardson，M.，“在DNS中存储IPsec密钥材料的方法”，RFC 4025，2005年3月。
[RFC4029] Lind, M., Ksinant, V., Park, S., Baudot, A., and P. Savola, "Scenarios and Analysis for Introducing IPv6 into ISP Networks", RFC 4029, March 2005.
[RFC4029]Lind，M.，Ksinant，V.，Park，S.，Baudot，A.，和P.Savola，“将IPv6引入ISP网络的场景和分析”，RFC 40292005年3月。
[RFC4038] Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E. Castro, "Application Aspects of IPv6 Transition", RFC 4038, March 2005.
[RFC4038]Shin，M-K.，Hong，Y-G.，Hagino，J.，Savola，P.，和E.Castro，“IPv6过渡的应用方面”，RFC 4038，2005年3月。
[RFC4074] Morishita, Y. and T. Jinmei, "Common Misbehavior Against DNS Queries for IPv6 Addresses", RFC 4074, May 2005.
[RFC4074]Morishita，Y.和T.Jinmei，“针对IPv6地址的DNS查询的常见错误行为”，RFC 4074，2005年5月。
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and More-Specific Routes", RFC 4191, November 2005.
[RFC4191]Draves，R.和D.Thaler，“默认路由器首选项和更具体的路由”，RFC 41912005年11月。
[RFC4225] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E. Nordmark, "Mobile IP Version 6 Route Optimization Security Design Background", RFC 4225, December 2005.
[RFC4225]Nikander，P.，Arkko，J.，Aura，T.，黑山，G.，和E.Nordmark，“移动IP版本6路由优化安全设计背景”，RFC 42252005年12月。
[RFC4294] Loughney, J., "IPv6 Node Requirements", RFC 4294, April 2006.
[RFC4294]Loughney，J.，“IPv6节点要求”，RFC 42942006年4月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[RFC4311] Hinden, R. and D. Thaler, "IPv6 Host-to-Router Load Sharing", RFC 4311, November 2005.
[RFC4311]Hinden，R.和D.Thaler，“IPv6主机到路由器负载共享”，RFC 4311，2005年11月。
[RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery Proxies (ND Proxy)", RFC 4389, April 2006.
[RFC4389]Thaler，D.，Talwar，M.，和C.Patel，“邻居发现代理（ND代理）”，RFC 4389，2006年4月。
[RFC4472] Durand, A., Ihren, J., and P. Savola, "Operational Considerations and Issues with IPv6 DNS", RFC 4472, April 2006.
[RFC4472]Durand，A.，Ihren，J.，和P.Savola，“IPv6 DNS的操作注意事项和问题”，RFC 4472，2006年4月。
[RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and E. Klein, "Local Network Protection for IPv6", RFC 4864, May 2007.
[RFC4864]Van de Velde，G.，Hain，T.，Droms，R.，Carpenter，B.，和E.Klein，“IPv6的本地网络保护”，RFC 4864，2007年5月。
[RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering ICMPv6 Messages in Firewalls", RFC 4890, May 2007.
[RFC4890]Davies，E.和J.Mohacsi，“防火墙中过滤ICMPv6消息的建议”，RFC 48902007年5月。
[RFC4966] Aoun, C. and E. Davies, "Reasons to Move NAT-PT to Historic Status", RFC 4966, July 2007.
[RFC4966]Aoun，C.和E.Davies，“将NAT-PT移至历史地位的原因”，RFC 4966，2007年7月。
[SCAN-IMP] Chown, T., "IPv6 Implications for Network Scanning", Work in Progress, March 2007.
[SCAN-IMP]Chown，T.，“IPv6对网络扫描的影响”，正在进行的工作，2007年3月。
[SIXNET] 6Net, "Large Scale International IPv6 Pilot Network", EU Information Society Technologies Project , 2005, <http://www.6net.org/>.
[SIXNET]6Net，“大规模国际IPv6试点网络”，欧盟信息社会技术项目，2005年<http://www.6net.org/>.
[TCGARCH] The Trusted Computing Group, "TCG Specification Architecture Overview", April 2004, <https:// www.trustedcomputinggroup.org/groups/ TCG_1_0_Architecture_Overview.pdf>.
[TCGARCH]可信计算小组，“TCG规范体系结构概述”，2004年4月，<https://www.trustedcomputinggroup.org/groups/TCG\u 1\u 0\u Architecture\u Overview.pdf>。
[VRRP] Hinden, R. and J. Cruz, "Virtual Router Redundancy Protocol for IPv6", Work in Progress, March 2007.
[VRRP]Hinden，R.和J.Cruz，“IPv6虚拟路由器冗余协议”，正在进行的工作，2007年3月。
Appendix A. IPv6 Probing/Mapping Considerations
附录A.IPv6探测/映射注意事项
One school of thought wanted the IPv6 numbering topology (either at network or node level) to match IPv4 as exactly as possible, whereas others see IPv6 as giving more flexibility to the address plans, not wanting to constrain the design of IPv6 addressing. Mirroring the address plans is now generally seen as a security threat because an IPv6 deployment may have different security properties from IPv4.
一个学派希望IPv6编号拓扑（在网络或节点级别）尽可能精确地匹配IPv4，而另一些学派则认为IPv6为地址计划提供了更大的灵活性，不希望限制IPv6寻址的设计。镜像地址计划现在通常被视为一种安全威胁，因为IPv6部署可能具有与IPv4不同的安全属性。
Given the relatively immature state of IPv6 network security, if an attacker knows the IPv4 address of the node and believes it to be dual-stacked with IPv4 and IPv6, he might want to try to probe the corresponding IPv6 address, based on the assumption that the security defenses might be lower. This might be the case particularly for nodes which are behind a NAT in IPv4, but globally addressable in IPv6. Naturally, this is not a concern if similar and adequate security policies are in place.
鉴于IPv6网络安全的相对不成熟状态，如果攻击者知道节点的IPv4地址，并认为它与IPv4和IPv6是双重堆叠的，他可能会基于安全防御可能较低的假设，尝试探测相应的IPv6地址。对于IPv4中位于NAT后面但在IPv6中可全局寻址的节点，情况可能尤其如此。当然，如果有类似和充分的安全政策，这就不成问题。
On the other hand, brute-force scanning or probing of addresses is computationally infeasible due to the large search space of interface identifiers on most IPv6 subnets (somewhat less than 64 bits wide, depending on how identifiers are chosen), always provided that identifiers are chosen at random out of the available space, as discussed in [SCAN-IMP].
另一方面，由于大多数IPv6子网上接口标识符的搜索空间很大（根据标识符的选择方式，宽度略小于64位），因此地址的强力扫描或探测在计算上是不可行的，前提是标识符总是从可用空间中随机选择的，如中所述[SCAN-IMP]。
For example, automatic tunneling mechanisms typically use deterministic methods for generating IPv6 addresses, so probing/ port-scanning an IPv6 node is simplified. The IPv4 address is embedded at least in 6to4, Teredo, and ISATAP addresses. Additionally, it is possible (in the case of 6to4 in particular) to learn the address behind the prefix; for example, Microsoft 6to4 implementation uses the address 2002:V4ADDR::V4ADDR while older Linux and FreeBSD implementations default to 2002:V4ADDR::1. This could also be used as one way to identify an implementation and hence target any specific weaknesses.
例如，自动隧道机制通常使用确定性方法生成IPv6地址，因此简化了IPv6节点的探测/端口扫描。IPv4地址至少嵌入在6to4、Teredo和ISATAP地址中。此外，可以（特别是在6to4的情况下）学习前缀后面的地址；例如，Microsoft 6to4实现使用地址2002:V4ADDR:：V4ADDR，而较旧的Linux和FreeBSD实现默认为2002:V4ADDR:：1。这也可以作为一种确定实现的方法，从而针对任何特定的弱点。
One proposal has been to randomize the addresses or subnet identifier in the address of the 6to4 router. This does not really help, as the 6to4 router (whether a host or a router) will return an ICMPv6 Hop Limit Exceeded message, revealing the IP address. Hosts behind the 6to4 router can use methods such as privacy addresses [RFC4941] to conceal themselves, provided that they are not meant to be reachable by sessions started from elsewhere; they would still require a globally accessible static address if they wish to receive communications initiated elsewhere.
其中一项建议是将6to4路由器地址中的地址或子网标识符随机化。这并没有真正的帮助，因为6to4路由器（无论是主机还是路由器）将返回ICMPv6 Hop Limit Excelled消息，显示IP地址。6to4路由器后面的主机可以使用诸如隐私地址[RFC4941]之类的方法来隐藏自己，前提是这些地址不能被从其他地方启动的会话访问；如果他们希望接收从别处发起的通信，他们仍然需要一个全球可访问的静态地址。
To conclude, it seems that when an automatic tunneling mechanism is being used, given an IPv4 address, the corresponding IPv6 address could possibly be guessed with relative ease. This has significant implications if the IPv6 security policy is less adequate than that for IPv4.
综上所述，当使用自动隧道机制时，如果给定IPv4地址，可以相对轻松地猜测相应的IPv6地址。如果IPv6安全策略不如IPv4安全策略充分，这将产生重大影响。
The generation of IPv6 addresses from MAC addresses potentially allows the behavior of users to be tracked in a way which may infringe their privacy. [RFC4941] specifies mechanisms which can be used to reduce the risk of infringement. It has also been claimed that IPv6 harms the privacy of the user, either by exposing the MAC address, or by exposing the number of nodes connected to a site.
从MAC地址生成IPv6地址可能允许以可能侵犯用户隐私的方式跟踪用户的行为。[RFC4941]规定了可用于降低侵权风险的机制。有人还声称，IPv6通过公开MAC地址或公开连接到站点的节点数量，损害了用户的隐私。
Additional discussion of privacy issues can be found in [RFC4864].
有关隐私问题的更多讨论，请参见[RFC4864]。
Using stateless address autoconfiguration results in the MAC address being incorporated in an EUI64 that exposes the model of network card. The concern has been that a user might not want to expose the details of the system to outsiders, e.g., fearing a resulting burglary if a thief identifies expensive equipment from the vendor identifier embedded in MAC addresses, or allowing the type of equipment in use to be identified, thus facilitating an attack on specific security weaknesses.
使用无状态地址自动配置会导致MAC地址合并到公开网卡型号的EUI64中。问题在于，用户可能不想将系统的细节暴露给外界，例如，如果窃贼从嵌入MAC地址的供应商标识符中识别出昂贵的设备，担心会导致盗窃，或者允许识别正在使用的设备类型，从而促进对特定安全弱点的攻击。
In most cases, this seems completely unfounded. First, such an address must be learned somehow -- this is a non-trivial process; the addresses are visible, e.g., in Web site access logs, but the chances that a random Web site owner is collecting this kind of information (or whether it would be of any use) are quite slim. Being able to eavesdrop the traffic to learn such addresses (e.g., by the compromise of DSL (Digital Subscriber Line) or Cable modem physical media) seems also quite far-fetched. Further, using statically configured interface identifiers or privacy addresses [RFC4941] for such purposes is straightforward if worried about the risk. Second, the burglar would have to be able to map the IP address to the physical location; typically this would only be possible with information from the private customer database of the Internet Service Provider (ISP) and, for large sites, the administrative records of the site, although some physical address information may be available from the WHOIS database of Internet registries.
在大多数情况下，这似乎完全没有根据。首先，必须以某种方式学习这样的地址——这是一个不平凡的过程；地址是可见的，例如在网站访问日志中，但随机网站所有者收集此类信息（或是否有用）的可能性非常小。能够窃听通信量以了解此类地址（例如，通过DSL（数字用户线）或有线调制解调器物理媒体的妥协）似乎也很牵强。此外，如果担心风险，那么使用静态配置的接口标识符或隐私地址[RFC4941]进行此类用途是很简单的。其次，窃贼必须能够将IP地址映射到物理位置；通常，这只能通过互联网服务提供商（ISP）的私人客户数据库中的信息以及大型站点的管理记录来实现，尽管一些物理地址信息可以从WHOIS的互联网注册数据库中获得。
Another concern that has been aired involves the user wanting to conceal the presence of a large number of computers or other devices connected to a network; NAT can "hide" all this equipment behind a single address, but it is not perfect either [FNAT].
另一个已经播出的担忧涉及用户想要隐藏大量计算机或其他连接到网络的设备的存在；NAT可以在一个地址后“隐藏”所有这些设备，但它也不是完美的[FNAT]。
One practical reason why some administrators may find this desirable is being able to thwart certain ISPs' business models. These models require payment based on the number of connected computers, rather than the connectivity as a whole.
一些管理者可能会认为这是可取的一个实际原因，那就是能够挫败某些ISP的商业模式。这些模型要求根据连接计算机的数量而不是整个连接进行支付。
Similar feasibility issues as described above apply. To a degree, the number of machines present could be obscured by the sufficiently frequent reuse of privacy addresses [RFC4941] -- that is, if during a short period, dozens of generated addresses seem to be in use, it's difficult to estimate whether they are generated by just one host or multiple hosts.
上述类似的可行性问题也适用。在某种程度上，存在的计算机数量可能会被足够频繁地重用隐私地址[RFC4941]所掩盖——也就是说，如果在短时间内，生成的几十个地址似乎正在使用，那么很难估计它们是由一台主机还是多台主机生成的。
When an ISP provides IPv6 connectivity to its customers, including home or consumer users, it delegates a fixed global routing prefix (usually a /48) to them. This is in contrast to the typical IPv4 situation where home users typically receive a dynamically allocated address that may be stable only for a period of hours.
当ISP向其客户（包括家庭用户或消费者用户）提供IPv6连接时，它会将固定的全局路由前缀（通常为a/48）委托给他们。这与典型的IPv4情况相反，在IPv4情况下，家庭用户通常会收到一个动态分配的地址，该地址可能仅在数小时内保持稳定。
Due to this fixed allocation, it is easier to correlate the global routing prefix to a network site. With consumer users, this correlation leads to a privacy issue, since a site is often equivalent to an individual or a family in such a case. Consequently some users might be concerned about being able to be tracked based on their /48 allocation if it is static [RFC4941]. On the other hand, many users may find having a static allocation desirable as it allows them to offer services hosted in their network more easily.
由于这种固定分配，更容易将全局路由前缀与网络站点相关联。对于消费者用户，这种关联会导致隐私问题，因为在这种情况下，网站通常相当于个人或家庭。因此，如果是静态的，一些用户可能会担心能够根据他们的/48分配进行跟踪[RFC4941]。另一方面，许多用户可能会发现静态分配是可取的，因为它允许他们更容易地提供托管在其网络中的服务。
This situation is not affected even if a user changes his/her interface ID or subnet ID, because malicious users can still discover this binding. On larger sites, the situation can be mitigated by using "untraceable" IPv6 addresses as described in [RFC4864], and it is possible that in the future ISPs might be prepared to offer untraceable addresses to their consumer customers to minimize the privacy issues.
即使用户更改其接口ID或子网ID，此情况也不会受到影响，因为恶意用户仍然可以发现此绑定。在较大的站点上，可以通过使用[RFC4864]中所述的“不可追踪”IPv6地址来缓解这种情况，并且未来ISP可能准备向其消费者客户提供不可追踪的地址，以最大限度地减少隐私问题。
This privacy issue is common to both IPv4 and IPv6 and is inherent in the use of IP addresses as both identifiers for node interfaces and locators for the nodes.
此隐私问题在IPv4和IPv6中都很常见，并且在使用IP地址作为节点接口的标识符和节点的定位器时是固有的。
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
Suresh Krishnan Ericsson 8400 Decarie Blvd. Town of Mount Royal, QC H4P 2N2 Canada
苏雷什·克里希南·爱立信德卡里大道8400号。加拿大QC H4P 2N2皇家山镇
Phone: +1 514-345-7900
EMail: suresh.krishnan@ericsson.com
Phone: +1 514-345-7900
EMail: suresh.krishnan@ericsson.com
Pekka Savola CSC/Funet
佩卡·萨沃拉CSC/Funet
EMail: psavola@funet.fi
EMail: psavola@funet.fi
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.