Network Working Group P. Savola
Request for Comments: 3964 CSC/FUNET
Category: Informational C. Patel
All Play, No Work
December 2004
Network Working Group P. Savola
Request for Comments: 3964 CSC/FUNET
Category: Informational C. Patel
All Play, No Work
December 2004
Security Considerations for 6to4
6to4的安全注意事项
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2004).
版权所有（C）互联网协会（2004年）。
Abstract
摘要
The IPv6 interim mechanism 6to4 (RFC3056) uses automatic IPv6-over-IPv4 tunneling to interconnect IPv6 networks. The architecture includes 6to4 routers and 6to4 relay routers, which accept and decapsulate IPv4 protocol-41 ("IPv6-in-IPv4") traffic from any node in the IPv4 internet. This characteristic enables a number of security threats, mainly Denial of Service. It also makes it easier for nodes to spoof IPv6 addresses. This document discusses these issues in more detail and suggests enhancements to alleviate the problems.
IPv6临时机制6to4（RFC3056）使用自动IPv6-over-IPv4隧道来互连IPv6网络。该体系结构包括6to4路由器和6to4中继路由器，它们接受并解除来自IPv4 internet中任何节点的IPv4协议41（“IPv6-in-IPv4”）流量的封装。此特性导致了许多安全威胁，主要是拒绝服务。它还使节点更容易伪造IPv6地址。本文档将更详细地讨论这些问题，并建议改进以缓解这些问题。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Different 6to4 Forwarding Scenarios . . . . . . . . . . . . . 4
2.1. From 6to4 to 6to4 . . . . . . . . . . . . . . . . . . . 4
2.2. From Native to 6to4 . . . . . . . . . . . . . . . . . . 5
2.3. From 6to4 to Native . . . . . . . . . . . . . . . . . . 5
2.4. Other Models . . . . . . . . . . . . . . . . . . . . . . 6
2.4.1. BGP between 6to4 Routers and Relays . . . . . . 6
2.4.2. 6to4 as an Optimization Method . . . . . . . . . 7
2.4.3. 6to4 as Tunnel End-Point Addressing Mechanism . . 8
3. Functionalities of 6to4 Network Components . . . . . . . . . . 9
3.1. 6to4 Routers . . . . . . . . . . . . . . . . . . . . . . 9
3.2. 6to4 Relay Routers . . . . . . . . . . . . . . . . . . . 10
4. Threat Analysis . . . . . . . . . . . . . . . . . . . . . . . 11
4.1. Attacks on 6to4 Networks . . . . . . . . . . . . . . . . 12
4.1.1. Attacks with ND Messages . . . . . . . . . . . . 13
4.1.2. Spoofing Traffic to 6to4 Nodes . . . . . . . . . 14
4.1.3. Reflecting Traffic to 6to4 Nodes . . . . . . . . 17
4.1.4. Local IPv4 Broadcast Attack . . . . . . . . . . 19
4.2. Attacks on Native IPv6 Internet . . . . . . . . . . . . 20
4.2.1. Attacks with ND Messages . . . . . . . . . . . . 21
4.2.2. Spoofing Traffic to Native IPv6 Nodes. . . . . . 21
4.2.3. Reflecting Traffic to Native IPv6 Nodes . . . . 23
4.2.4. Local IPv4 Broadcast Attack . . . . . . . . . . 24
4.2.5. Theft of Service . . . . . . . . . . . . . . . . 25
4.2.6. Relay Operators Seen as Source of Abuse . . . . 26
4.3. Attacks on IPv4 Internet . . . . . . . . . . . . . . . . 28
4.4. Summary of the Attacks . . . . . . . . . . . . . . . . . 28
5. Implementing Proper Security Checks in 6to4 . . . . . . . . . 30
5.1. Encapsulating IPv6 into IPv4 . . . . . . . . . . . . . . 31
5.2. Decapsulating IPv4 into IPv6 . . . . . . . . . . . . . . 31
5.3. IPv4 and IPv6 Sanity Checks . . . . . . . . . . . . . . 32
5.3.1. IPv4 . . . . . . . . . . . . . . . . . . . . . . 32
5.3.2. IPv6 . . . . . . . . . . . . . . . . . . . . . . 33
5.3.3. Optional Ingress Filtering . . . . . . . . . . . 33
5.3.4. Notes about the Checks . . . . . . . . . . . . . 33
6. Issues in 6to4 Implementation and Use . . . . . . . . . . . . 34
6.1. Implementation Considerations with Automatic Tunnels . . 34
6.2. A Different Model for 6to4 Deployment . . . . . . . . . 35
7. Security Considerations . . . . . . . . . . . . . . . . . . . 36
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 36
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37
A. Some Trivial Attack Scenarios Outlined . . . . . . . . . . . . 39
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 41
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Different 6to4 Forwarding Scenarios . . . . . . . . . . . . . 4
2.1. From 6to4 to 6to4 . . . . . . . . . . . . . . . . . . . 4
2.2. From Native to 6to4 . . . . . . . . . . . . . . . . . . 5
2.3. From 6to4 to Native . . . . . . . . . . . . . . . . . . 5
2.4. Other Models . . . . . . . . . . . . . . . . . . . . . . 6
2.4.1. BGP between 6to4 Routers and Relays . . . . . . 6
2.4.2. 6to4 as an Optimization Method . . . . . . . . . 7
2.4.3. 6to4 as Tunnel End-Point Addressing Mechanism . . 8
3. Functionalities of 6to4 Network Components . . . . . . . . . . 9
3.1. 6to4 Routers . . . . . . . . . . . . . . . . . . . . . . 9
3.2. 6to4 Relay Routers . . . . . . . . . . . . . . . . . . . 10
4. Threat Analysis . . . . . . . . . . . . . . . . . . . . . . . 11
4.1. Attacks on 6to4 Networks . . . . . . . . . . . . . . . . 12
4.1.1. Attacks with ND Messages . . . . . . . . . . . . 13
4.1.2. Spoofing Traffic to 6to4 Nodes . . . . . . . . . 14
4.1.3. Reflecting Traffic to 6to4 Nodes . . . . . . . . 17
4.1.4. Local IPv4 Broadcast Attack . . . . . . . . . . 19
4.2. Attacks on Native IPv6 Internet . . . . . . . . . . . . 20
4.2.1. Attacks with ND Messages . . . . . . . . . . . . 21
4.2.2. Spoofing Traffic to Native IPv6 Nodes. . . . . . 21
4.2.3. Reflecting Traffic to Native IPv6 Nodes . . . . 23
4.2.4. Local IPv4 Broadcast Attack . . . . . . . . . . 24
4.2.5. Theft of Service . . . . . . . . . . . . . . . . 25
4.2.6. Relay Operators Seen as Source of Abuse . . . . 26
4.3. Attacks on IPv4 Internet . . . . . . . . . . . . . . . . 28
4.4. Summary of the Attacks . . . . . . . . . . . . . . . . . 28
5. Implementing Proper Security Checks in 6to4 . . . . . . . . . 30
5.1. Encapsulating IPv6 into IPv4 . . . . . . . . . . . . . . 31
5.2. Decapsulating IPv4 into IPv6 . . . . . . . . . . . . . . 31
5.3. IPv4 and IPv6 Sanity Checks . . . . . . . . . . . . . . 32
5.3.1. IPv4 . . . . . . . . . . . . . . . . . . . . . . 32
5.3.2. IPv6 . . . . . . . . . . . . . . . . . . . . . . 33
5.3.3. Optional Ingress Filtering . . . . . . . . . . . 33
5.3.4. Notes about the Checks . . . . . . . . . . . . . 33
6. Issues in 6to4 Implementation and Use . . . . . . . . . . . . 34
6.1. Implementation Considerations with Automatic Tunnels . . 34
6.2. A Different Model for 6to4 Deployment . . . . . . . . . 35
7. Security Considerations . . . . . . . . . . . . . . . . . . . 36
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 36
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37
A. Some Trivial Attack Scenarios Outlined . . . . . . . . . . . . 39
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 41
The IPv6 interim mechanism "6to4" [1] specifies automatic IPv6-over-IPv4 tunneling to interconnect isolated IPv6 clouds by embedding the tunnel IPv4 address in the IPv6 6to4 prefix.
IPv6临时机制“6to4”[1]通过在IPv6 6to4前缀中嵌入隧道IPv4地址，指定自动IPv6-over-IPv4隧道以互连孤立的IPv6云。
Two characteristics of the 6to4 mechanism introduce most of the security considerations:
6to4机制的两个特点介绍了大多数安全注意事项：
1. All 6to4 routers must accept and decapsulate IPv4 packets from every other 6to4 router, and from 6to4 relays.
1. 所有6to4路由器必须接受并解除来自其他6to4路由器和6to4中继的IPv4数据包的封装。
2. 6to4 relay routers must accept traffic from any native IPv6 node.
2. 6to4中继路由器必须接受来自任何本机IPv6节点的流量。
As the 6to4 router must accept traffic from any other 6to4 router or relay, a certain requirement for trust is implied, and there are no strict constraints on what the IPv6 packet may contain. Thus, addresses within the IPv4 and IPv6 headers may be spoofed, and this leads to various types of threats, including different flavors of Denial of Service attacks.
由于6to4路由器必须接受来自任何其他6to4路由器或中继的流量，因此隐含了一定的信任要求，并且对IPv6数据包可能包含的内容没有严格的限制。因此，IPv4和IPv6报头中的地址可能被欺骗，这会导致各种类型的威胁，包括不同类型的拒绝服务攻击。
The 6to4 specification outlined a few security considerations and rules but was ambiguous as to their exact requirement level. Moreover, the description of the considerations was rather short, and some of them have proven difficult to understand or impossible to implement.
6to4规范概述了一些安全注意事项和规则，但对于它们的确切需求级别却不明确。此外，对这些考虑因素的描述相当简短，其中一些已证明难以理解或无法实施。
This document analyzes the 6to4 security issues in more detail and outlines some enhancements and caveats.
本文档更详细地分析了6to4安全问题，并概述了一些增强功能和注意事项。
Sections 2 and 3 are more or less introductory, rehashing how 6to4 is used today based on the 6to4 specification, so that it is easier to understand how security could be affected. Section 4 provides a threat analysis for implementations that already implement most of the security checks. Section 5 describes the optimal decapsulation/encapsulation rules for 6to4 implementations, and Section 6 provides further discussion on a few issues that have proven difficult to implement. Appendix A outlines a few possible trivial attack scenarios in which very little or no security has been implemented.
第2节和第3节或多或少是介绍性的，在6to4规范的基础上重新讨论了6to4目前的使用方式，以便更容易理解安全性可能受到的影响。第4节为已经实施大多数安全检查的实现提供了威胁分析。第5节描述了6to4实现的最佳去封装/封装规则，第6节进一步讨论了一些难以实现的问题。附录A概述了一些可能的轻微攻击场景，在这些场景中很少或根本没有实现安全性。
For the sake of simplicity, in this document, the native Internet is assumed to encompass IPv6 networks formed by using other transition mechanisms (e.g., RFC 2893 [4]), as these mechanisms cannot talk directly to the 6to4 network.
为了简单起见，使用IPv6到IPv6的转换（例如，在本文档286t中，使用IPv6到IPv6的转换）不能包含其他机制。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [2].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[2]中的描述进行解释。
Throughout this memo, IPv4 addresses from blocks 7.0.0.0/24, 8.0.0.0/24, and 9.0.0.0/24 are used for demonstrative purposes, to represent global IPv4 addresses that have no relation to each other. This approach was chosen instead of just using addresses from 192.0.2.0/24 [5] for two reasons: to use addresses whose 6to4 mapping is glaringly obvious, and to make it obvious that the IPv4 addresses of different 6to4 gateways need not have any relation to each other.
在本备忘录中，块7.0.0.0/24、8.0.0.0/24和9.0.0.0/24中的IPv4地址用于说明目的，以表示彼此无关的全局IPv4地址。选择这种方法，而不是仅仅使用192.0.2.0/24[5]中的地址，原因有二：使用6to4映射非常明显的地址，以及使不同6to4网关的IPv4地址不必彼此有任何关系。
Note that when one communicates between 6to4 and native domains, the 6to4 relays that will be used in the two directions are very likely different; routing is highly asymmetric. Because of this, it is not feasible to limit relays from which 6to4 routers may accept traffic.
注意，当一个人在6to4和本机域之间通信时，将在两个方向上使用的6to4中继很可能不同；路由是高度不对称的。因此，限制6to4路由器可以接受流量的中继是不可行的。
The first three subsections introduce the most common forms of 6to4 operation. Other models are presented in the fourth subsection.
前三小节介绍了6to4操作的最常见形式。第四小节介绍了其他模型。
6to4 domains always exchange 6to4 traffic directly via IPv4 tunneling; the endpoint address V4ADDR is derived from 6to4 prefix 2002:V4ADDR::/48 of the destination.
6to4域始终通过IPv4隧道直接交换6to4流量；端点地址V4ADDR派生自目标的6to4前缀2002:V4ADDR:：/48。
.--------. _----_ .--------.
| 6to4 | _( IPv4 )_ | 6to4 |
| router | <====> ( Internet ) <===> | router |
'--------' (_ _) '--------'
^ '----' ^
| Direct tunneling over IPv4 |
V V
.--------. .-------.
| 6to4 | | 6to4 |
| host | | host |
'--------' '--------'
.--------. _----_ .--------.
| 6to4 | _( IPv4 )_ | 6to4 |
| router | <====> ( Internet ) <===> | router |
'--------' (_ _) '--------'
^ '----' ^
| Direct tunneling over IPv4 |
V V
.--------. .-------.
| 6to4 | | 6to4 |
| host | | host |
'--------' '--------'
Figure 1
图1
It is required that every 6to4 router consider every other 6to4 router it wants to talk to be "on-link" (with IPv4 as the link-layer).
要求每6to4个路由器考虑其他6to4个路由器，它想要说的是“在链路上”（以IPv4作为链路层）。
When native domains send traffic to 6to4 prefix 2002:V4ADDR::/48, it will be routed to the topologically nearest advertising 6to4 relay (advertising route to 2002::/16). The 6to4 relay will tunnel the traffic over IPv4 to the corresponding IPv4 address V4ADDR.
当本机域将流量发送到6to4前缀2002:V4ADDR:：/48时，它将被路由到拓扑上最近的广告6to4中继（广告路由到2002:：/16）。6to4中继将通过IPv4将流量隧道到相应的IPv4地址V4ADDR。
Note that IPv4 address 9.0.0.1 here is just an example of a global IPv4 address, and it is assigned to the 6to4 router's pseudo-interface.
请注意，这里的IPv4地址9.0.0.1只是全局IPv4地址的一个示例，它被分配给6to4路由器的伪接口。
Closest to
"Native IPv6 node"
.--------. _----_ .------------. .--------.
| Native | _( IPv6 )_ | 6to4 relay | Tunneled | 6to4 |
| IPv6 | -> ( Internet ) --> | router | =========> | router |
| node | (_ _) '------------' 9.0.0.1 '--------'
'--------' '----' dst_v6=2002:0900:0001::1 |
V
.-------.
| 6to4 |
| host |
'--------'
Closest to
"Native IPv6 node"
.--------. _----_ .------------. .--------.
| Native | _( IPv6 )_ | 6to4 relay | Tunneled | 6to4 |
| IPv6 | -> ( Internet ) --> | router | =========> | router |
| node | (_ _) '------------' 9.0.0.1 '--------'
'--------' '----' dst_v6=2002:0900:0001::1 |
V
.-------.
| 6to4 |
| host |
'--------'
Figure 2
图2
6to4 domains send traffic to native domains by tunneling it over IPv4 to their configured 6to4 relay router, or the closest one found by using 6to4 IPv4 Anycast [3]. The relay will decapsulate the packet and forward it to native IPv6 Internet, as would any other IPv6 packet.
6to4域通过IPv4隧道将流量发送到其配置的6to4中继路由器，或使用6to4 IPv4选播找到的最近的路由，从而将流量发送到本机域[3]。中继将解除数据包的封装并将其转发到本机IPv6 Internet，就像任何其他IPv6数据包一样。
Note that the destination IPv6 address in the packet is a non-6to4 address and is assumed to be 2001:db8::1 in the example.
请注意，包中的目标IPv6地址是非6to4地址，在本例中假定为2001:db8:：1。
Configured
-or-
found by IPv4 Anycast
.--------. _----_ .------------. .--------.
| Native | _( IPv6 )_ | 6to4 relay | Tunneled | 6to4 |
| Client | <- ( Internet ) <-- | router | <========= | router |
'--------' (_ _) '------------' 192.88.99.1'--------'
2001:db8::1 '----' (or configured) ^
|
.-------.
| 6to4 |
| client |
'--------'
Configured
-or-
found by IPv4 Anycast
.--------. _----_ .------------. .--------.
| Native | _( IPv6 )_ | 6to4 relay | Tunneled | 6to4 |
| Client | <- ( Internet ) <-- | router | <========= | router |
'--------' (_ _) '------------' 192.88.99.1'--------'
2001:db8::1 '----' (or configured) ^
|
.-------.
| 6to4 |
| client |
'--------'
Figure 3
图3
These are more or less special cases of 6to4 operations. In later chapters, unless otherwise stated, only the most generally used models (above) will be considered.
这些或多或少都是6to4操作的特殊情况。在后面的章节中，除非另有说明，否则仅考虑最常用的模型（如上）。
Section 5.2.2.2 in [1] presents a model where, instead of static configuration, BGP [6] is used between 6to4 relay routers and 6to4 routers (for outgoing relay selection only).
[1]中的第5.2.2.2节介绍了一个模型，其中，在6to4中继路由器和6to4路由器之间使用BGP[6]，而不是静态配置（仅用于传出中继选择）。
Going further than [1], if the 6to4 router established a BGP session between all the possible 6to4 relays and advertised its /48 prefix to them, the traffic from non-6to4 sites would always come from a "known" relay. Alternatively, the 6to4 relays might advertise the more specific 6to4 routes between 6to4 relays.
除[1]之外，如果6to4路由器在所有可能的6to4中继之间建立BGP会话并向它们公布其/48前缀，则来自非6to4站点的流量将始终来自“已知”中继。或者，6to4中继器可以在6to4中继器之间宣传更具体的6to4路由。
Both of these approaches are obviously infeasible due to scalability issues.
由于可伸缩性问题，这两种方法显然都不可行。
Neither of these models are known to be used at the time of writing; this is probably because parties that need 6to4 are not able to run BGP, and because setting up these sessions would be much more work for relay operators.
在撰写本文时，这两种模型均未被使用；这可能是因为需要6to4的各方无法运行BGP，而且对于中继运营商来说，设置这些会话需要做更多的工作。
Some sites seem to use 6to4 as an IPv6 connectivity "optimization method"; that is, they also have non-6to4 addresses on their nodes and border routers but also employ 6to4 to reach 6to4 sites.
一些站点似乎使用6to4作为IPv6连接的“优化方法”；也就是说，它们的节点和边界路由器上也有非6to4地址，但也使用6to4到达6to4站点。
This is typically done to be able to reach 6to4 destinations by direct tunneling without using relays at all.
这通常是为了能够通过直接隧道到达6到4个目的地，而根本不使用继电器。
These sites also publish both 6to4 and non-6to4 addresses in DNS to affect inbound connections. If the source host's default address selection [7] works properly, 6to4 sources will use 6to4 addresses to reach the site and non-6to4 nodes use non-6to4 addresses. If this behavior of foreign nodes can be assumed, the security threats to such sites can be significantly simplified.
这些站点还在DNS中发布6to4和非6to4地址，以影响入站连接。如果源主机的默认地址选择[7]工作正常，6to4源将使用6to4地址到达站点，而非6to4节点使用非6to4地址。如果可以假设外部节点的这种行为，那么对此类站点的安全威胁可以大大简化。
6to4 addresses can also be used only as an IPv6-in-IPv4 tunnel endpoint addressing and routing mechanism.
6to4地址也只能用作IPv6-in-IPv4隧道端点寻址和路由机制。
An example of this is interconnecting 10 branch offices where nodes use non-6to4 addresses. Only the offices' border routers need to be aware of 6to4, and use 6to4 addresses solely for addressing the tunnels between different branch offices. An example is provided in the figure below.
这方面的一个例子是互连10个分支办公室，其中节点使用非6to4地址。只有办公室的边界路由器需要知道6to4，并且只使用6to4地址来寻址不同分支办公室之间的隧道。下图提供了一个示例。
2001:db8:0:10::/60 2001:db8:0:20::/60
.--------. .--------.
( Branch 1 ) ( Branch 2 )
'--------' '--------'
| |
.--------. _----_ .--------.
| 6to4 | _( IPv4 )_ | 6to4 |
| router | <====> ( Internet ) <===> | router |
'--------' (_ _) '--------'
9.0.0.1 '----' 8.0.0.2
^^
||
vv
.--------.
| 6to4 | 7.0.0.3
| router |
'--------'
| 2001:db8::/48
.-----------.
( Main Office )
'-----------'
^
|
v
_----_
_( IPv6 )_
( Internet )
(_ _)
'----'
2001:db8:0:10::/60 2001:db8:0:20::/60
.--------. .--------.
( Branch 1 ) ( Branch 2 )
'--------' '--------'
| |
.--------. _----_ .--------.
| 6to4 | _( IPv4 )_ | 6to4 |
| router | <====> ( Internet ) <===> | router |
'--------' (_ _) '--------'
9.0.0.1 '----' 8.0.0.2
^^
||
vv
.--------.
| 6to4 | 7.0.0.3
| router |
'--------'
| 2001:db8::/48
.-----------.
( Main Office )
'-----------'
^
|
v
_----_
_( IPv6 )_
( Internet )
(_ _)
'----'
Figure 4
图4
In the figure, the main office sets up two routes:
在图中，主办公室设置了两条路线：
2001:db8:0:10::/60 -> 2002:0900:0001::1
2001:db8:0:10::/60 -> 2002:0900:0001::1
2001:db8:0:20::/60 -> 2002:0800:0002::1
2001:db8:0:20::/60 -> 2002:0800:0002::1
And a branch office sets up two routes as well:
分支机构还设立了两条路线：
2001:db8:0:20::/60 -> 2002:0800:0002::1
2001:db8:0:20::/60 -> 2002:0800:0002::1
default -> 2002:0700:0003::1
default -> 2002:0700:0003::1
Thus, the IPv4 Internet is treated as an NBMA link-layer for interconnecting 6to4-enabled sites; with explicit routes, 6to4 addressing need not be used in routers other than the 6to4 edge routers. However, note that if a branch office sends a packet to any 6to4 destination, it will not go through the main office, as the 6to4 2002::/16 route overrides the default route.
因此，IPv4互联网被视为用于互连支持6to4的站点的NBMA链路层；对于显式路由，6to4寻址不需要在除6to4边缘路由器之外的路由器中使用。但是，请注意，如果分支机构向任何6to4目的地发送数据包，它将不会通过主办公室，因为6to4 2002:：/16路由将覆盖默认路由。
This approach may make addressing and routing slightly easier in some circumstances.
在某些情况下，这种方法可能会使寻址和路由稍微容易一些。
This section summarizes the main functionalities of the 6to4 network components (6to4 routers, and 6to4 relays) and the security checks they must do. The pseudo-code for the security checks is provided in Section 5.
本节总结了6to4网络组件（6to4路由器和6to4中继）的主要功能及其必须进行的安全检查。第5节提供了安全检查的伪代码。
This section summarizes the main functions of the various components of a 6to4 network: 6to4 relay routers and 6to4 routers. Refer to Section 1.1 of RFC 3056 [1] for 6to4-related definitions.
本节总结了6to4网络各个组件的主要功能：6to4中继路由器和6to4路由器。有关6to4的相关定义，请参阅RFC 3056[1]第1.1节。
The 6to4 routers act as the border routers of a 6to4 domain. It does not have a native global IPv6 address except in certain special cases. Since the specification [1] uses the term "6to4 router", this memo does the same; however, note that in this definition, we also include a single host with a 6to4 pseudo-interface, which doesn't otherwise act as a router. The main functions of the 6to4 router are as follows:
6to4路由器充当6to4域的边界路由器。除某些特殊情况外，它没有本机全局IPv6地址。由于规范[1]使用了术语“6to4路由器”，本备忘录也使用了相同的术语；但是，请注意，在这个定义中，我们还包括一个带有6to4伪接口的主机，否则它不会充当路由器。6to4路由器的主要功能如下：
o Provide IPv6 connectivity to local clients and routers.
o 提供到本地客户端和路由器的IPv6连接。
o Tunnel packets sent to foreign 6to4 addresses to the destination 6to4 router using IPv4.
o 使用IPv4将发送到外部6to4地址的隧道数据包发送到目标6to4路由器。
o Forward packets sent to locally configured 6to4 addresses to the 6to4 network.
o 将发送到本地配置的6to4地址的数据包转发到6to4网络。
o Tunnel packets sent to non-6to4 addresses to the configured/ closest-by-anycast 6to4 relay router.
o 通过任意广播6to4中继路由器将发送到非6to4地址的隧道数据包发送到已配置/最近的地址。
o Decapsulate directly received IPv4 packets from foreign 6to4 addresses.
o 对从外部6to4地址直接接收到的IPv4数据包解除封装。
o Decapsulate IPv4 packets received via the relay closest to the native IPv6 sources. Note that it is not easily distinguishable whether the packet was received from a 6to4 relay router or from a spoofing third party.
o 解除通过最接近本机IPv6源的中继接收的IPv4数据包的封装。注意，不容易区分数据包是从6to4中继路由器还是从欺骗的第三方接收的。
The 6to4 router should also perform security checks on traffic that it receives from other 6to4 relays, or 6to4 routers, or from within the 6to4 site. These checks include the following:
6to4路由器还应对从其他6to4中继或6to4路由器或从6to4站点内接收的流量执行安全检查。这些检查包括以下内容：
o Disallow traffic that has private, broadcast or certain specific reserved IPv4 addresses (see Section 5.3.1 for details) in tunnels, or the matching 6to4 prefixes.
o 禁止隧道中具有专用、广播或某些特定保留IPv4地址（详见第5.3.1节）或匹配6to4前缀的流量。
o Disallow traffic from 6to4 routers in which the IPv4 tunnel source address does not match the 6to4 prefix. (Note that the pseudo-interface must pick the IPv4 address corresponding to the prefix when encapsulating, or problems may ensue, e.g., on multi-interface routers.)
o 不允许来自IPv4隧道源地址与6to4前缀不匹配的6to4路由器的流量。（请注意，封装时，伪接口必须选择与前缀对应的IPv4地址，否则可能会出现问题，例如在多接口路由器上。）
o Disallow traffic in which the destination IPv6 address is not a global address; in particular, link-local addresses, mapped addresses, and such should not be used.
o 不允许目标IPv6地址不是全局地址的通信量；特别是，不应使用链接本地地址、映射地址等。
o Disallow traffic transmission to other 6to4 domains through 6to4 relay router or via some third party 6to4 router. (To avoid transmission to the relay router, the pseudo-interface prefix length must be configured correctly to /16. Further, to avoid the traffic being discarded, 6to4 source addresses must always correspond to the IPv4 address encapsulating the traffic.)
o 禁止通过6to4中继路由器或某些第三方6to4路由器向其他6to4域传输流量。（为了避免传输到中继路由器，必须将伪接口前缀长度正确配置为/16。此外，为了避免丢弃通信，6to4源地址必须始终对应于封装通信的IPv4地址。）
o Discard traffic received from other 6to4 domains via a 6to4 relay router.
o 丢弃通过6to4中继路由器从其他6to4域接收的流量。
o Discard traffic received for prefixes other than one's own 6to4 prefix(es).
o 放弃接收到的除自己的6to4前缀以外的前缀的流量。
The 6to4 relay router acts as a relay between all 6to4 domains and native IPv6 networks; more specifically, it
6to4中继路由器充当所有6to4域和本机IPv6网络之间的中继；更具体地说，它
o advertises the reachability of the 2002::/16 prefix to native IPv6 routing, thus receiving traffic to all 6to4 addresses from the closest native IPv6 nodes,
o 播发本机IPv6路由的2002:：/16前缀的可达性，从而从最近的本机IPv6节点接收到所有6to4地址的流量，
o advertises (if RFC 3068 [3] is implemented) the reachability of IPv4 "6to4 relay anycast prefix" (192.88.99.0/24) to IPv4 routing, thus receiving some tunneled traffic to native IPv6 nodes from 6to4 routers.
o 公布（如果实现了RFC 3068[3]）IPv4“6to4中继选播前缀”（192.88.99.0/24）对IPv4路由的可达性，从而从6to4路由器接收到一些到本机IPv6节点的隧道流量。
o decapsulates and forwards packets received from 6to4 addresses through tunneling, by using normal IPv6 routing, and
o 使用正常IPv6路由，通过隧道对从6to4地址接收的数据包进行解密和转发，以及
o tunnels packets received through normal IPv6 routing from native addresses that are destined for 2002::/16 to the corresponding 6to4 router.
o 将通过正常IPv6路由从本机地址（目的地为2002:：/16）接收的数据包传输到相应的6to4路由器。
The 6to4 relay should also perform security checks on traffic that it receives from 6to4 routers, or from native IPv6 nodes. These checks are as follows:
6to4中继还应该对从6to4路由器或本机IPv6节点接收的流量执行安全检查。这些检查如下：
o Disallow traffic that has private, broadcast, or certain specific reserved IPv4 addresses in tunnels, or in the matching 6to4 prefixes.
o 禁止在隧道中或在匹配的6to4前缀中具有专用、广播或某些特定保留IPv4地址的流量。
o Disallow traffic from 6to4 routers in which the IPv4 tunnel source address does not match the 6to4 prefix. (Note that the pseudo-interface must pick the IPv4 address corresponding to the prefix when encapsulating, or problems may ensue, e.g., on multi-interface routers.)
o 不允许来自IPv4隧道源地址与6to4前缀不匹配的6to4路由器的流量。（请注意，封装时，伪接口必须选择与前缀对应的IPv4地址，否则可能会出现问题，例如在多接口路由器上。）
o Disallow traffic in which the destination IPv6 address is not a global address; in particular, link-local addresses, mapped addresses, and such should not be used.
o 不允许目标IPv6地址不是全局地址的通信量；特别是，不应使用链接本地地址、映射地址等。
o Discard traffic received from 6to4 routers with the destination as a 6to4 prefix.
o 丢弃从目标为6to4前缀的6to4路由器接收的流量。
This section discusses attacks against the 6to4 network or attacks caused by the 6to4 network. The threats are discussed in light of the 6to4 deployment models defined in Section 2.
本节讨论针对6to4网络的攻击或由6to4网络引起的攻击。这些威胁将根据第2节中定义的6to4部署模型进行讨论。
There are three general types of threats:
威胁一般有三种类型：
1. Denial-of-Service (DoS) attacks, in which a malicious node prevents communication between the node under attack and other nodes.
1. 拒绝服务（DoS）攻击，其中恶意节点阻止受攻击节点与其他节点之间的通信。
2. Reflection Denial-of-Service (DoS) attacks, in which a malicious node reflects the traffic off unsuspecting nodes to a particular node (node under attack) in order to prevent communication between the node under attack and other nodes.
2. 反射拒绝服务（DoS）攻击，在这种攻击中，恶意节点将不知情节点的流量反射到特定节点（受攻击节点），以阻止受攻击节点与其他节点之间的通信。
3. Service theft, in which a malicious node/site/operator may make unauthorized use of service.
3. 服务盗窃，恶意节点/站点/操作员可能未经授权使用服务。
6to4 also provides a means for a "meta-threat", traffic laundering, in which some other attack is channeled through the third parties to make tracing the real origin of the attack more difficult. This is used in conjunction with other threats, whether specific to 6to4 or not.
6to4还提供了一种“元威胁”的手段，即流量洗钱，其中一些其他攻击通过第三方进行，使得追踪攻击的真正来源更加困难。这与其他威胁（无论是否针对6to4）一起使用。
At this point it is important to reiterate that the attacks are possible because
在这一点上，有必要重申袭击是可能的，因为
1. 6to4 routers have to consider all 6to4 relays, and other 6to4 routers, as "on-link",
1. 6to4路由器必须考虑所有6to4继电器，以及其他6to4路由器，如“在链路上”，
2. 6to4 relays have to consider all 6to4 routers as "on-link", and
2. 6to4继电器必须考虑所有6to4路由器作为“链路上”，以及
3. it has been discovered that at least a couple of major 6to4 implementations do not implement all the security checks.
3. 已经发现，至少有两个主要的6to4实现没有实现所有的安全检查。
The attacks' descriptions are classified based on the target of the attack:
攻击的描述根据攻击目标进行分类：
1. Attacks on 6to4 networks.
1. 对6to4网络的攻击。
2. Attacks on IPv6 networks.
2. 对IPv6网络的攻击。
3. Attacks on IPv4 networks.
3. 对IPv4网络的攻击。
Note that one of the mitigation methods listed for various attacks is based on the premise that 6to4 relays could have a feature limiting traffic to/from specific 6to4 sites. At the time of this writing, this feature is speculative, and more work needs to be done to determine the logistics.
请注意，针对各种攻击列出的缓解方法之一是基于6to4中继可能具有限制特定6to4站点的通信量的功能这一前提。在撰写本文时，这一特征是推测性的，需要做更多的工作来确定物流。
This section describes attacks against 6to4 networks. Attacks that leverage 6to4 networks, but for which the ultimate victim is elsewhere (e.g., a native IPv6 user, an IPv4 user), are described later in the memo.
本节介绍针对6to4网络的攻击。备忘录稍后将介绍利用6to4网络但最终受害者在其他地方（例如，本机IPv6用户、IPv4用户）的攻击。
6to4 relays and routers are IPv4 nodes, and there is no way for any 6to4 router to confirm the identity of the IPv4 node from which it receives traffic -- whether from a legitimate 6to4 relay or some other node. A 6to4 router has to process traffic from all IPv4 nodes. Malicious IPv4 nodes can exploit this property and attack nodes within the 6to4 network.
6to4中继和路由器都是IPv4节点，任何6to4路由器都无法确认接收流量的IPv4节点的身份——无论是来自合法的6to4中继还是其他节点。6to4路由器必须处理来自所有IPv4节点的流量。恶意IPv4节点可以利用此属性攻击6to4网络中的节点。
It is possible to conduct a variety of attacks on the 6to4 nodes. These attacks are as follows:
可以对6to4节点进行各种攻击。这些攻击如下：
1. Attacks with Neighbor Discovery (ND) Messages
1. 使用邻居发现（ND）消息的攻击
2. Spoofing traffic to 6to4 nodes
2. 欺骗到6to4节点的流量
3. Reflecting traffic from 6to4 nodes
3. 反映来自6to4节点的流量
4. Local IPv4 broadcast attack
4. 本地IPv4广播攻击
ATTACK DESCRIPTION
攻击描述
Since the 6to4 router assumes that all the other 6to4 routers and 6to4 relays are "on-link", it is possible to attack the 6to4 router by using ND messages from any node in the IPv4 network, unless a prior trust relationship has been established.
由于6to4路由器假定所有其他6to4路由器和6to4中继处于“链路上”，因此有可能通过使用来自IPv4网络中任何节点的ND消息来攻击6to4路由器，除非已建立先前的信任关系。
The attacks target the 6to4 pseudo-interface. As long as the 6to4 addresses are not used in the source or destination address, the security checks specified by 6to4 take no stance on these packets. Typically they use link-local addresses.
攻击的目标是6to4伪接口。只要源地址或目标地址中没有使用6to4地址，6to4指定的安全检查就不会对这些数据包采取任何立场。通常，它们使用链接本地地址。
For example, an attack could be a Route Advertisement or Neighbor Advertisement message crafted specifically to cause havoc; the addresses in such a packet could resemble to the following:
例如，攻击可以是路由广告或邻居广告消息，这些消息是专门为造成破坏而设计的；此类数据包中的地址可能类似于以下内容：
src_v6 = fe80::2 (forged address)
dst_v6 = fe80::1 (valid or invalid address)
src_v4 = 8.0.0.1 (valid or forged address)
dst_v4 = 9.0.0.2 (valid address, matches dst_v6)
src_v6 = fe80::2 (forged address)
dst_v6 = fe80::1 (valid or invalid address)
src_v4 = 8.0.0.1 (valid or forged address)
dst_v4 = 9.0.0.2 (valid address, matches dst_v6)
These attacks are exacerbated if the implementation supports more tunneling mechanisms than 6to4 (or configured tunneling) because it is impossible to disambiguate such mechanisms, making it difficult to enable strict security checks (see Section 6.1).
如果实现支持比6to4（或配置的隧道）更多的隧道机制，则这些攻击会加剧，因为无法消除此类机制的歧义，从而难以启用严格的安全检查（请参见第6.1节）。
The Neighbor Discovery threats (Redirect DoS, or DoS) are described in [8]. Note that all attacks may not be applicable, as the 6to4
[8]中描述了邻居发现威胁（重定向DoS或DoS）。请注意，并非所有攻击都适用，因为6to4
pseudo-interface is assumed not to have a link-layer address (Section 3.8 RFC 2893 [4]). However, note that the 6to4 router can be either a router or host from the Neighbor Discovery perspective.
假定伪接口没有链路层地址（第3.8节RFC 2893[4]）。但是，请注意，从邻居发现的角度来看，6to4路由器可以是路由器或主机。
THREAT ANALYSIS AND MITIGATION METHODS
威胁分析和缓解方法
The attacks can be mitigated by using any of the following methods:
可以使用以下任一方法减轻攻击：
o The usage of ND messages could be prohibited. This implies that all packets using addresses of scope link-local will be silently discarded. Section 3.1 of RFC 3056 [1] leaves scope for future uses of link-local address. This method has its pitfalls: It would prohibit any sort of ND message and thus close the doors on development and use of other ND options. Whether this is a significant problem is another thing.
o 可以禁止使用ND消息。这意味着使用作用域链接本地地址的所有数据包都将被静默丢弃。RFC 3056[1]第3.1节为链路本地地址的未来使用留下了余地。这种方法有其缺陷：它将禁止任何类型的ND消息，从而关闭开发和使用其他ND选项的大门。这是否是一个重大问题是另一回事。
o The 6to4 pseudo-interface could be insulated from the other interfaces, particularly the other tunnel interfaces (if any), for example by using a separate neighbor cache.
o 6to4伪接口可以与其他接口隔离，特别是其他隧道接口（如果有），例如通过使用单独的邻居缓存。
o If ND messages are needed, either IPsec [4] or an extension of SEND could be used [9] to secure packet exchange using the link-local address; vanilla SEND would not work, as the link-layer does not have an address -- and IPsec would be rather complex.
o 如果需要ND消息，可以使用IPsec[4]或SEND的扩展[9]来使用链路本地地址保护数据包交换；香草发送将不起作用，因为链路层没有地址——而IPsec将相当复杂。
COMPARISON TO SITUATION WITHOUT 6to4
与没有6to4的情况进行比较
Even though rather simply fixed, this attack is not new as such; the same is possible by using automatic tunneling [4] or configured tunneling (if one is able to spoof source IPv4 address to that of the tunnel end-point).
即使只是简单地修复了，这种攻击也不是什么新鲜事；通过使用自动隧道[4]或配置的隧道（如果能够将源IPv4地址欺骗到隧道端点的地址），也可以实现同样的效果。
However, as 6to4 provides open decapsulation, and automatic tunneling is being deprecated [10], 6to4 provides an easy means, which would not exist without it.
然而，由于6to4提供开放式去封装，并且自动隧道正在被弃用[10]，因此6to4提供了一种简单的方法，没有它是不可能存在的。
ATTACK DESCRIPTION
攻击描述
The attacker - a malicious IPv4 or IPv6 node - can send packets that are difficult to trace (e.g., due to spoofing or going through a relay) to a 6to4 node. This can be used e.g., to accomplish a DoS attack.
攻击者（恶意IPv4或IPv6节点）可以向6to4节点发送难以跟踪的数据包（例如，由于欺骗或通过中继）。例如，这可用于完成DoS攻击。
The IPv6 and IPv4 addresses of the packets will be similar to the following:
数据包的IPv6和IPv4地址将类似于以下内容：
src_v6 = 2001:db8::1 (forged address)
dst_v6 = 2002:0900:0002::1 (valid address)
src_v4 = 8.0.0.1 (valid or forged address)
dst_v4 = 9.0.0.2 (valid address, matches dst_v6)
src_v6 = 2001:db8::1 (forged address)
dst_v6 = 2002:0900:0002::1 (valid address)
src_v4 = 8.0.0.1 (valid or forged address)
dst_v4 = 9.0.0.2 (valid address, matches dst_v6)
For attacks launched from a native IPv6 node, the src_v4 will be the address of the relay through which the traffic will reach the 6to4 node. From IPv4 nodes, src_v4 can be either a spoofed source address or the real one.
对于从本机IPv6节点发起的攻击，src_v4将是通信量将通过其到达6to4节点的中继地址。从IPv4节点来看，src_v4可以是伪造的源地址，也可以是真实的源地址。
The 6to4 router receives these packets from 8.0.0.1, decapsulates them, discards the IPv4 header containing the source address 8.0.0.1, and processes them as normal (the attacker has guessed or obtained "dst_v6" by using one of a number of techniques).
6to4路由器从8.0.0.1接收这些数据包，将其解封，丢弃包含源地址8.0.0.1的IPv4报头，并正常处理它们（攻击者通过使用多种技术之一猜测或获得“dst_v6”）。
This is a DoS attack on 6to4 nodes.
这是对6to4节点的DoS攻击。
This attack is similar to those shown in [11].
此攻击类似于[11]中所示的攻击。
EXTENSIONS
扩展
Replies to the traffic will be directed to the src_v6 address, resulting in 6to4 nodes participating in a reflection DoS. This attack is described in more detail in Section 4.2.3. The replies (e.g., TCP SYN ACK, TCP RST, ICMPv6 Echo Reply, input sent to UDP echo service, ICMPv6 Destination Unreachable) are sent to the victim (src_v6), above. All the traces from the original attacker (src_v4) have been discarded. These return packets will go through a relay.
对流量的回复将被定向到src_v6地址，从而导致6to4个节点参与反射DoS。第4.2.3节详细描述了这种攻击。回复（例如，TCP SYN ACK、TCP RST、ICMPv6回显回复、发送到UDP回显服务的输入、ICMPv6目标不可访问）被发送到上述受害者（src_v6）。原始攻击者（src_v4）的所有跟踪都已被丢弃。这些返回数据包将通过一个中继。
Certain 6to4 networks may have a trivial ACL (Access Control List) based firewall that allows traffic to pass through if it comes from particular source(s). Such a firewalling mechanism can be bypassed by address spoofing. This attack can therefore be used for trivial ACL avoidance as well. These attacks might be hampered because the replies from the 6to4 node to the spoofed address will be lost.
某些6to4网络可能有一个基于ACL（访问控制列表）的防火墙，如果流量来自特定来源，它允许流量通过。地址欺骗可以绕过这种防火墙机制。因此，此攻击也可用于避免琐碎的ACL。这些攻击可能会受到阻碍，因为6to4节点对伪造地址的回复将丢失。
THREAT ANALYSIS AND SOLUTIONS/MITIGATION METHODS
威胁分析和解决方案/缓解方法
The Denial-of-Service attack based on traffic spoofing is not new; the only twists come from the fact that traces of an attack are more easily lost, and that spoofing the IPv6 address is possible even to those who are unable to do so in their current networks. The 6to4 router typically does not log IPv4 addresses (as they would be treated as L2 addresses), and thus the source of the attack (if launched from an IPv4 node) is lost. Because traces to the src_v4 address are easily lost, these attacks can also be launched from IPv4 nodes whose connections are ingress-filtered.
基于流量欺骗的拒绝服务攻击并不新鲜；唯一的曲折来自这样一个事实，即攻击痕迹更容易丢失，而且欺骗IPv6地址甚至对那些在当前网络中无法做到这一点的人也是可能的。6to4路由器通常不记录IPv4地址（因为它们将被视为L2地址），因此攻击源（如果从IPv4节点发起）丢失。由于src_v4地址的跟踪很容易丢失，因此这些攻击也可以从连接经过入口过滤的IPv4节点发起。
However, often this is not a real factor, as usually the attackers are just zombies and real attackers may not even care whether the unspoofed source address is discovered.
然而，这通常不是一个真正的因素，因为攻击者通常只是僵尸，真正的攻击者甚至可能不关心是否发现了未录制的源地址。
Malicious native IPv6 nodes could be caught easily if ingress filtering was enabled everywhere in the IPv6 Internet.
如果在IPv6 Internet中的任何位置都启用了入口过滤，则恶意的本机IPv6节点可能很容易被捕获。
These attacks are easy to perform, but the extent of harm is limited:
这些攻击很容易执行，但危害程度有限：
o For every packet sent, at most one reply packet is generated: there is no amplification factor.
o 对于每个发送的数据包，最多生成一个应答数据包：没有放大因子。
o Attack packets, if initiated from an IPv6 node, will pass through choke point(s), namely a 6to4 relay; in addition to physical limitations, these could implement some form of 6to4-site-specific traffic limiting.
o 如果从IPv6节点发起攻击，攻击数据包将通过阻塞点，即6to4中继；除了物理限制外，还可以实施某种形式的6to4站点特定流量限制。
On the other hand, a variety of factors can make the attacks serious:
另一方面，多种因素可能导致攻击严重：
o The attacker may have the ability to choose the relay, and he might employ the ones best suited for the attacks. Also, many relays use 192.88.99.1 [3] as the source address, making tracing even more difficult (also see Section 4.2.6).
o 攻击者可能有能力选择中继，并且可能会使用最适合攻击的中继。此外，许多继电器使用192.88.99.1[3]作为源地址，使得跟踪更加困难（另见第4.2.6节）。
o The relay's IPv4 address may be used as a source address for these attacks, potentially causing a lot of complaints or other actions, as the relay might seem to be the source of the attack (see Section 4.2.6 for more).
o 中继的IPv4地址可能被用作这些攻击的源地址，可能会导致大量投诉或其他行为，因为中继可能是攻击的来源（有关更多信息，请参阅第4.2.6节）。
Some of the mitigation methods for such attacks are as follows:
针对此类攻击的一些缓解方法如下：
1. Ingress filtering in the native IPv6 networks to prevent packets with spoofed IPv6 sources from being transmitted. This would, thus, make it easy to identify the source of the attack. Unfortunately, it would depend on significant (or even complete) ingress filtering everywhere in other networks; while this is highly desirable, it may not be feasible.
1. 在本机IPv6网络中进行入口过滤，以防止传输带有伪造IPv6源的数据包。因此，这将使识别攻击源变得容易。不幸的是，它将依赖于在其他网络中无处不在的重要（甚至完全）入口过滤；虽然这是非常可取的，但可能不可行。
2. Security checks in the 6to4 relay. The 6to4 relay must drop traffic (from the IPv6 Internet) that has 6to4 addresses as source address; see Section 5 for more detail. This has very little cost.
2. 对6to4继电器进行安全检查。6to4中继必须丢弃具有6to4地址作为源地址的流量（来自IPv6 Internet）；详见第5节。这成本很低。
However, these mitigation methods do not address the case of an IPv4 node sending encapsulated IPv6 packets.
但是，这些缓解方法不能解决IPv4节点发送封装的IPv6数据包的情况。
No simple way to prevent such attacks exists, and longer-term solutions, such as ingress filtering [12] or itrace [13], would have
不存在防止此类攻击的简单方法，更长期的解决方案，如入口过滤[12]或itrace[13]可能已经存在
to be deployed in both IPv6 and IPv4 networks to help identify the source of the attacks. A total penetration is likely impossible. (Note that itrace work has been discontinued, as of this writing in July 2004.)
将部署在IPv6和IPv4网络中，以帮助识别攻击源。完全渗透可能是不可能的。（请注意，截至2004年7月撰写本文时，itrace工作已停止。）
COMPARISON TO SITUATION WITHOUT 6to4
与没有6to4的情况进行比较
Traffic spoofing is not a new phenomenon in IPv4 or IPv6. 6to4 just makes it easier: Anyone can, regardless of ingress filtering, spoof a native IPv6 address to a 6to4 node, even if "maximal security" would be implemented and deployed. Losing trails is also easier.
流量欺骗不是IPv4或IPv6中的新现象。6to4只是让它变得更简单：任何人都可以，不管入口过滤如何，将本机IPv6地址欺骗到6to4节点，即使实现并部署了“最大安全性”。失去踪迹也更容易。
Therefore, depending on how much one assumes ingress filtering is deployed for IPv4 and IPv6, this could be considered either a very serious issue or close to irrelevant compared to the IP spoofing capabilities without 6to4.
因此，根据对IPv4和IPv6部署入口过滤的假设程度，这可能被认为是一个非常严重的问题，或者与不使用6to4的IP欺骗功能相比几乎不相关。
ATTACK DESCRIPTION
攻击描述
Spoofed traffic (as described in Section 4.2.2) may be sent to native IPv6 nodes to perform a reflection attack against 6to4 nodes.
伪造流量（如第4.2.2节所述）可发送至本机IPv6节点，以对6to4节点执行反射攻击。
The spoofed traffic is sent to a native IPv6 node, either from an IPv4 node (through a 6to4 relay) or from a native IPv6 node (unless ingress filtering has been deployed). With the former, the sent packets would resemble the following:
伪造的流量从IPv4节点（通过6to4中继）或本机IPv6节点（除非已部署入口过滤）发送到本机IPv6节点。对于前者，发送的数据包类似于以下内容：
src_v6 = 2002:1234:1234::1 (forged address of the target 6to4 node)
dst_v6 = 2002:0900:0002::1 (valid address)
src_v4 = 8.0.0.1 (valid or invalid address)
dst_v4 = 9.0.0.2 (valid address, matches dst_v6)
src_v6 = 2002:1234:1234::1 (forged address of the target 6to4 node)
dst_v6 = 2002:0900:0002::1 (valid address)
src_v4 = 8.0.0.1 (valid or invalid address)
dst_v4 = 9.0.0.2 (valid address, matches dst_v6)
Note that an attack through the relay is prevented if the relay implements proper decapsulation security checks (see Section 5 for details) unless the IPv4 node can spoof the source address to match src_v6. Similarly, the attack from native IPv6 nodes could be prevented by global ingress filtering deployment.
请注意，如果中继执行正确的解除封装安全检查（有关详细信息，请参阅第5节），则可以防止通过中继的攻击，除非IPv4节点可以伪造源地址以匹配src_v6。类似地，可以通过部署全局入口过滤来防止来自本机IPv6节点的攻击。
These attacks can be initiated by native IPv6, IPv4, or 6to4 nodes.
这些攻击可以由本机IPv6、IPv4或6to4节点发起。
EXTENSIONS
扩展
A distributed Reflection DoS can be performed if a large number of nodes are involved in sending spoofed traffic with the same src_v6.
如果大量节点参与发送具有相同src_v6的伪造流量，则可以执行分布式反射DoS。
Malicious 6to4 nodes can also (try to) initiate this attack by bouncing traffic off 6to4 nodes in other 6to4 sites. However, this attack may not be possible, as the 6to4 router (in the site from which the attack is launched) will filter packets with forged source addresses (with security checks mentioned in Section 5).
恶意6to4节点还可以（尝试）通过从其他6to4站点的6to4节点反弹流量来发起此攻击。但是，这种攻击可能不可能发生，因为6to4路由器（在发起攻击的站点中）将过滤具有伪造源地址的数据包（使用第5节中提到的安全检查）。
THREAT ANALYSIS AND SOLUTIONS/MITIGATION METHODS
威胁分析和解决方案/缓解方法
In this case, the reverse traffic comprises replies to the messages received by the 6to4 nodes. The attacker has less control on the packet type, and this would inhibit certain types of attacks. For example, flooding a 6to4 node with TCP SYN packets will not be possible (but e.g., a SYN-ACK or RST would be).
在这种情况下，反向业务包括对6to4节点接收的消息的回复。攻击者对数据包类型的控制较少，这将抑制某些类型的攻击。例如，不可能用TCP SYN数据包淹没6to4节点（但例如，SYN-ACK或RST将是可能的）。
These attacks may be mitigated in various ways:
这些攻击可以通过多种方式减轻：
o Implementation of ingress filtering by the IPv4 service providers. This would prevent forging of the src_v4 address and help in closing down on the culprit IPv4 nodes. Note that it will be difficult to shut down the attack if a large number of IPv4 nodes are involved.
o IPv4服务提供商实施入口过滤。这将防止伪造src_v4地址，并有助于关闭罪魁祸首IPv4节点。请注意，如果涉及大量IPv4节点，则很难关闭攻击。
These attacks may be also be stopped at the 6to4 sites if the culprit src_v4 address is identified, and if it is constant, by filtering traffic from this address. Note that it would be difficult to implement this method if appropriate logging were not done by the 6to4 router or if a large number of 6to4 nodes, and/or a large number of IPv4 nodes were participating in the attack.
如果确定了肇事者src_v4地址，并且该地址是恒定的，则还可以通过过滤来自该地址的流量，在6to4站点上停止这些攻击。请注意，如果6to4路由器没有执行适当的日志记录，或者如果大量6to4节点和/或大量IPv4节点参与攻击，则很难实现此方法。
Unfortunately, because many IPv4 service providers don't implement ingress filtering, for whatever reasons, this may not be a satisfactory solution.
不幸的是，由于许多IPv4服务提供商不实施入口过滤，无论出于何种原因，这可能不是一个令人满意的解决方案。
o Implementation of ingress filtering by all IPv6 service providers would eliminate this attack, because src_v6 could not be spoofed as a 6to4 address. However, expecting this to happen may not be practical.
o 所有IPv6服务提供商实施入口过滤将消除此攻击，因为src_v6不能被欺骗为6to4地址。然而，期望这种情况发生可能并不现实。
o Proper implementation of security checks (see Section 5) both at the 6to4 relays and routers would eliminate an attack launched from an IPv4 node, except when the IPv4 source address was also spoofed -- but then the attacker would have been able to attack the ultimate destination directly.
o 在6to4中继器和路由器上正确实施安全检查（见第5节）将消除从IPv4节点发起的攻击，除非IPv4源地址也被欺骗，但攻击者将能够直接攻击最终目的地。
o Rate limiting traffic at the 6to4 relays. In a scenario where most of the traffic is passing through few 6to4 relays, these relays can implement traffic rate-limiting features and rate-limit the traffic from 6to4 sites.
o 6to4中继的速率限制通信量。在大多数流量通过少数6to4中继的场景中，这些中继可以实现流量速率限制功能，并对来自6to4站点的流量进行速率限制。
COMPARISON TO SITUATION WITHOUT 6to4
与没有6to4的情况进行比较
This particular attack can be mitigated by proper implementation of security checks (which is quite straightforward) and ingress filtering; when ingress filtering is not implemented, it is typically easier to attack directly than through reflection -- unless "traffic laundering" is an explicit goal of the attack. Therefore, this attack does not seem very serious.
通过适当实施安全检查（非常简单）和入口过滤，可以缓解这种特殊攻击；当未实现入口过滤时，直接攻击通常比通过反射更容易——除非“流量清洗”是攻击的明确目标。因此，这次袭击似乎并不十分严重。
ATTACK DESCRIPTION
攻击描述
This threat is applicable if the 6to4 router does not check whether the IPv4 address to which it tries to send encapsulated IPv6 packets is a local broadcast address or a multicast address.
如果6to4路由器未检查其尝试向其发送封装IPv6数据包的IPv4地址是本地广播地址还是多播地址，则此威胁适用。
This threat is described in the specification [1], and implementing the checks eliminates this threat. However, as checks have not been widely implemented, the threat is included here for completeness.
规范[1]中描述了此威胁，实施检查可消除此威胁。但是，由于检查尚未广泛实施，因此为了完整性，此处包含了威胁。
There practically two kinds of attacks: when a local 6to4 user tries to send packets to the address corresponding to the broadcast address, and when someone is able to do so remotely.
实际上有两种攻击：当本地6to4用户试图向广播地址对应的地址发送数据包时，以及当有人能够远程发送数据包时。
In the first option, assume that 9.0.0.255 is the 6to4 router's broadcast address. After receiving the packet with a destination address like "2002:0900:00ff::bbbb" from a local 6to4 node, if the router doesn't check the destination address for subnet broadcast, it would send the encapsulated protocol-41 packet to 9.0.0.255. This would be received by all nodes in the subnet, and the responses would be directed to the 6to4 router.
在第一个选项中，假设9.0.0.255是6to4路由器的广播地址。从本地6to4节点接收到目标地址为“2002:0900:00ff:：bbbb”的数据包后，如果路由器没有检查子网广播的目标地址，它会将封装的协议-41数据包发送到9.0.0.255。这将由子网中的所有节点接收，并且响应将被定向到6to4路由器。
Malicious sites may also embed forged 6to4 addresses in the DNS, use of which by a 6to4 node would result in a local broadcast by the 6to4 router. One way to perform this attack would be to send an HTML mail containing a link to an invalid URL (for example, http://[2002:0900:00ff::bbbb]/index.html) to all users in a 6to4 technology based network. Opening of the mail simultaneously would result in a broadcast storm.
恶意站点还可能在DNS中嵌入伪造的6to4地址，6to4节点使用该地址将导致6to4路由器进行本地广播。执行此攻击的一种方法是向基于6to4技术的网络中的所有用户发送包含指向无效URL（例如http://[2002:0900:00ff:：bbbb]/index.HTML）链接的HTML邮件。同时打开邮件将导致广播风暴。
The second kind of attack is more complex: The attack can be initiated by IPv4 nodes not belonging to the local network as long as they can send traffic with invalid (for example 2002:0900:00ff::bbbb) source address. The 6to4 router has to respond to the traffic by sending ICMPv6 packets back to the source, (e.g., Hop Limit Exceeded or Destination Unreachable). The packet would be as follows:
第二种攻击更为复杂：攻击可以由不属于本地网络的IPv4节点发起，只要它们可以发送具有无效（例如2002:0900:00ff:：bbbb）源地址的流量。6to4路由器必须通过将ICMPv6数据包发送回源来响应通信量（例如，超出跃点限制或无法到达目的地）。资料包如下：
src_v6 = 2002:0800:00ff::bbbb (broadcast address of the router)
dst_v6 = 2002:0800:0001::0001 (valid non-existent address)
src_v6 = 2002:0800:00ff::bbbb (broadcast address of the router)
dst_v6 = 2002:0800:0001::0001 (valid non-existent address)
This is a DoS attack.
这是DoS攻击。
EXTENSIONS
扩展
The attacks could also be directed at non-local broadcast addresses, but these would be so-called "IPv4 directed broadcasts", which have (luckily enough) already been extensively blocked in the Internet.
这些攻击也可能针对非本地广播地址，但这些将是所谓的“IPv4定向广播”，它们（幸运的是）已经在互联网上被广泛阻止。
THREAT ANALYSIS AND SOLUTIONS/MITIGATION METHODS
威胁分析和解决方案/缓解方法
The attack is based on the premise that the 6to4 router has to send a packet that embeds an invalid IPv4 address to an IPv6 address. Such an attack is easily thwarted by ensuring that the 6to4 router does not transmit packets to invalid IPv4 addresses. Specifically, traffic should not be sent to broadcast or multicast IPv4 addresses.
攻击的前提是6to4路由器必须发送将无效IPv4地址嵌入IPv6地址的数据包。通过确保6to4路由器不会将数据包传输到无效的IPv4地址，可以轻松阻止此类攻击。具体而言，不应将通信量发送到广播或多播IPv4地址。
COMPARISON TO SITUATION WITHOUT 6to4
与没有6to4的情况进行比较
The first threat is similar to what is already possible with IPv4, but IPv6 does not have broadcast addresses.
第一个威胁类似于IPv4已经存在的威胁，但IPv6没有广播地址。
The second, a more complex threat, is, similarly, also available in IPv4.
第二种更为复杂的威胁同样也存在于IPv4中。
In consequence, the security does not seem to be significantly worse than with IPv4, and even that is restricted to the site(s) with 6to4 implementations that haven't been secured as described in Section 5.
因此，安全性似乎并不明显比IPv4差，甚至仅限于使用第5节中所述的6to4实现的站点。
This section describes attacks against native IPv6 Internet that somehow leverage 6to4 architecture. Attacks against 6to4 nodes were described in the previous section.
本节介绍对本机IPv6 Internet的攻击，这些攻击以某种方式利用6to4体系结构。针对6to4节点的攻击已在上一节中描述。
6to4 and IPv4 nodes can access native IPv6 nodes through the 6to4 relay routers. Thus, the 6to4 relays play a crucial role in any attack on native IPv6 nodes by IPv4 nodes or 6to4 nodes.
6to4和IPv4节点可以通过6to4中继路由器访问本机IPv6节点。因此，6to4中继在IPv4节点或6to4节点对本机IPv6节点的任何攻击中起着至关重要的作用。
6to4 relays have only one significant security check they must perform for general safety: When decapsulating IPv4 packets, they check that 2002:V4ADDR::/48 and V4ADDR match in the source address. If this is not done, several threats become more serious; in the following analysis, it is assumed that such checks are implemented.
6to4中继器只有一个重要的安全检查，它们必须执行一般安全检查：在解除IPv4数据包的封装时，它们检查源地址中的2002:V4ADDR:：/48和V4ADDR是否匹配。如果不这样做，一些威胁将变得更加严重；在以下分析中，假设已实施此类检查。
6to4 relay should not relay packets between 6to4 addresses. In particular, packets decapsulated from 6to4 routers should not be encapsulated toward 6to4 routers, as described in Section 5. Similarly, packets with 6to4 source and destination addresses sent from IPv6 nodes should not be relayed. It is not clear whether this kind of check is typically implemented. The attacks described below assume that such checks are not implemented.
6to4中继不应在6to4地址之间中继数据包。特别是，如第5节所述，从6to4路由器解封的数据包不应封装到6to4路由器。同样，从IPv6节点发送的具有6to4源地址和目标地址的数据包也不应中继。目前尚不清楚这种检查是否通常实施。下面描述的攻击假设未执行此类检查。
These attacks are the same as those employed against 6to4 routers, as described in Section 4.1.1.
这些攻击与针对6to4路由器的攻击相同，如第4.1.1节所述。
ATTACK DESCRIPTION
攻击描述
The attacker - a malicious IPv4 or 6to4 node - can send packets with a spoofed (or not spoofed) 6to4 source address to a native IPv6 node to accomplish a DoS attack.
攻击者（恶意IPv4或6to4节点）可以向本机IPv6节点发送带有伪造（或未伪造）6to4源地址的数据包，以完成DoS攻击。
The threat is similar to that involving 6to4 routers, as described in Section 4.1.2.
如第4.1.2节所述，该威胁类似于涉及6to4路由器的威胁。
The difference here is that the attack is initiated by IPv4 or 6to4 nodes. The source IPv6 address may or may not be spoofed. Note that, as mentioned above, the relay is assumed to correlate the source IPv4 address with the address embedded in the source IPv6 address during decapsulation. A side effect is that all spoofed traffic will have a 6to4 source address.
这里的区别在于攻击是由IPv4或6to4节点发起的。源IPv6地址可能是伪造的，也可能不是伪造的。注意，如上所述，在解除封装期间，假定中继将源IPv4地址与嵌入在源IPv6地址中的地址相关联。一个副作用是，所有被欺骗的流量都将有一个6to4源地址。
EXTENSIONS
扩展
Spoofed traffic may also be sent to native IPv6 nodes either by other native IPv6 nodes, by 6to4 nodes, or by malicious IPv4 nodes to conduct Reflection DoS on either native IPv6 nodes or 6to4 nodes.
其他本机IPv6节点、6to4节点或恶意IPv4节点也可以将伪造流量发送到本机IPv6节点，以在本机IPv6节点或6to4节点上执行反射DoS。
Certain native IPv6 networks may have a trivial ACL (Access Control List) based firewall that allows traffic to pass through if it comes from particular source(s). Such a firewalling mechanism can be bypassed by address spoofing. This attack can therefore be used for trivial ACL avoidance as well. These attacks might be hampered by lost replies from the 6to4 node to the spoofed address.
某些本机IPv6网络可能有一个基于ACL（访问控制列表）的防火墙，该防火墙允许来自特定来源的流量通过。地址欺骗可以绕过这种防火墙机制。因此，此攻击也可用于避免琐碎的ACL。这些攻击可能会因6to4节点丢失对伪造地址的回复而受阻。
THREAT ANALYSIS AND SOLUTIONS/MITIGATION METHODS
威胁分析和解决方案/缓解方法
The Denial-of-Service attack based on traffic spoofing is not new; the only twist is that traces of an attack are more easily lost. The 6to4 relay typically does not log IPv4 addresses (as they would be treated as L2 addresses), and thus the source of the attack (if launched from an IPv4 node) is lost. Because traces to the src_v4 address are easily lost, these attacks can also be launched from IPv4 nodes whose connections are ingress-filtered.
基于流量欺骗的拒绝服务攻击并不新鲜；唯一的问题是，攻击痕迹更容易丢失。6to4中继通常不记录IPv4地址（因为它们将被视为L2地址），因此攻击源（如果从IPv4节点发起）丢失。由于src_v4地址的跟踪很容易丢失，因此这些攻击也可以从连接经过入口过滤的IPv4节点发起。
These attacks might not be easy to perform and might be hampered because of the following:
这些攻击可能不容易执行，并且可能由于以下原因而受到阻碍：
o It might be difficult to launch such attacks from 6to4 nodes because even if the 6to4 routers allow spoofing of the source IPv6 address, the 6to4 relay would check whether the source V4ADDR is the same as the one embedded in the source IPv6 address. Thus, 6to4 nodes will be forced to use the correct IPv6 prefix while launching an attack, making it easy to close such attacks.
o 可能很难从6to4节点发起此类攻击，因为即使6to4路由器允许对源IPv6地址进行欺骗，6to4中继也会检查源V4ADDR是否与嵌入源IPv6地址的V4ADDR相同。因此，在发起攻击时，6to4节点将被迫使用正确的IPv6前缀，从而很容易关闭此类攻击。
o Packets may pass through choke point(s), namely a 6to4 relay. In addition to physical limitations, there could be some sort of traffic rate limiting mechanisms that may be implemented, and these could tone down the attack.
o 数据包可以通过阻塞点，即6to4中继。除了物理限制之外，还可能实施某种流量速率限制机制，这些机制可以降低攻击。
o For every packet sent, at most one reply packet is generated: There is no amplification factor.
o 对于每个发送的数据包，最多生成一个应答数据包：没有放大因子。
Some of the mitigation methods for such attacks are as follows:
针对此类攻击的一些缓解方法如下：
1. Ingress filtering in the IPv4 Internet to prevent packets with a spoofed IPv4 source from being transmitted. As the relay checks that the 6to4 address embeds the IPv4 address, no spoofing can be achieved unless IPv4 addresses can be spoofed. However, this would probably be an unfeasible requirement.
1. IPv4 Internet中的入口过滤，以防止传输带有伪造IPv4源的数据包。当中继检查6to4地址是否嵌入IPv4地址时，除非可以欺骗IPv4地址，否则无法实现欺骗。然而，这可能是一项不可行的要求。
2. Security checks in the 6to4 relay. The 6to4 relay must drop traffic (from 6to4 nodes, or IPv4 nodes) with non-6to4 addresses as the source address, or for which the source IPv4 address does not match the address embedded in the source IPv6 address.
2. 对6to4继电器进行安全检查。6to4中继必须丢弃（来自6to4节点或IPv4节点的）以非6to4地址作为源地址的通信量，或者源IPv4地址与源IPv6地址中嵌入的地址不匹配的通信量。
COMPARISON TO SITUATION WITHOUT 6to4
与没有6to4的情况进行比较
Compared to Section 4.1.2, which describes more serious threats, this threat appears to be slightly more manageable. If the relays perform proper decapsulation checks, the spoofing can only be achieved, to a 6to4 source address, when the IPv4 address is spoofable as well.
与描述更严重威胁的第4.1.2节相比，该威胁似乎更易于管理。如果中继器执行正确的解除封装检查，则只有在IPv4地址也是可欺骗的情况下，才能实现对6to4源地址的欺骗。
ATTACK DESCRIPTION
攻击描述
These reflection attacks are similar to that involving 6to4 routers, as described in Section 4.1.3. Traffic may be reflected off native IPv6 nodes, or off 6to4 nodes. The attack can be initiated by one of the following:
如第4.1.3节所述，这些反射攻击类似于涉及6to4路由器的攻击。流量可能会从本机IPv6节点或从6to4节点反射。该攻击可由以下方式之一发起：
o Native IPv6 nodes. These nodes can send invalid traffic with spoofed native IPv6 addresses to valid 6to4 nodes. Replies from the 6to4 nodes are part of a reflection attack.
o 本机IPv6节点。这些节点可以使用伪造的本机IPv6地址将无效通信发送到有效的6to4节点。来自6to4节点的回复是反射攻击的一部分。
o IPv4 nodes. These nodes can send traffic with native IPv6 source addresses (encapsulated by the IPv4 node itself into a protocol-41 packet) to 6to4 nodes. Replies from the 6to4 nodes are part of a reflection attack.
o IPv4节点。这些节点可以向6to4节点发送具有本机IPv6源地址（由IPv4节点本身封装为协议-41数据包）的流量。来自6to4节点的回复是反射攻击的一部分。
o 6to4 nodes. These nodes can perform attacks similar to those by IPv4 nodes, but this would require spoofing of the source address at the 6to4 site before encapsulation, which is likely to be difficult.
o 6到4个节点。这些节点可以执行与IPv4节点类似的攻击，但这需要在封装之前欺骗6to4站点的源地址，这可能很困难。
When launched from a native IPv6 node, the traffic goes through 6to4 relays twice, both before and after the reflection; when launched from a 6to4/IPv4 node, the traffic goes through a relay only after the reflection.
当从本机IPv6节点启动时，流量在反射之前和之后通过6to4中继两次；当从6to4/IPv4节点启动时，流量仅在反射后通过中继。
EXTENSIONS
扩展
A distributed reflection DoS can be performed if a large number of native IPv6 nodes or IPv4/6to4 nodes are involved in sending spoofed traffic with the same source IPv6 address.
如果大量本机IPv6节点或IPv4/6to4节点参与发送具有相同源IPv6地址的伪造流量，则可以执行分布式反射DoS。
THREAT ANALYSIS AND SOLUTIONS/MITIGATION METHODS
威胁分析和解决方案/缓解方法
Some of the mitigation methods for such attacks are as follows:
针对此类攻击的一些缓解方法如下：
1. Attacks from the native IPv6 nodes could be stopped by implementing ingress filtering in the IPv6 Internet; hopefully this will become commonplace, but past experience of IPv4 ingress filtering deployment (or lack thereof) does not promise much.
1. 通过在IPv6 Internet中实施入口过滤，可以阻止来自本机IPv6节点的攻击；希望这会变得司空见惯，但过去IPv4入口过滤部署的经验（或缺乏）并不能带来太多希望。
2. Two measures are needed to stop or mitigate the attacks from IPv4 nodes: 1) Implementing ingress filtering in the IPv4 internet, and 2) logging IPv4 source addresses in the 6to4 router.
2. 需要采取两种措施来阻止或减轻来自IPv4节点的攻击：1）在IPv4 internet中实施入口过滤，2）在6to4路由器中记录IPv4源地址。
3. Attacks from 6to4 nodes in other sites can be stopped if the 6to4 routers in those sites implement egress filtering. This could be done by those sites, but the sites that are most likely to be abused are typically also those most likely to neglect installing appropriate filtering at their edges.
3. 如果其他站点中的6to4路由器实施出口过滤，则可以阻止来自这些站点中6to4节点的攻击。这些网站可以做到这一点，但最有可能被滥用的网站通常也是那些最有可能忽视在其边缘安装适当过滤的网站。
4. The traffic passes through one or two relays, and traffic rate limiting in the 6to4 relays might help tone down the reflection attack.
4. 流量通过一个或两个中继，6to4中继中的流量速率限制可能有助于降低反射攻击。
COMPARISON TO SITUATION WITHOUT 6to4
与没有6to4的情况进行比较
Even though there are means to mitigate it, the attack is still rather efficient, especially when used by native IPv6 nodes with spoofed addresses. Using 6to4 relays and routers could easily take down the 6to4 relay system and/or provide an easy means for traffic laundering. However, if the attack is intended to DoS the victim, this can be achieved more smoothly by doing it directly (as the source address spoofing was available as well).
尽管有办法减轻这种攻击，但这种攻击仍然相当有效，特别是当本机IPv6节点使用伪造地址时。使用6to4中继和路由器可以很容易地关闭6to4中继系统和/或提供一种简单的流量清洗方法。但是，如果攻击的目的是对受害者进行DoS攻击，则可以通过直接进行DoS攻击来更顺利地实现（因为源地址欺骗也可用）。
Therefore, the threat to the availability and stability of the 6to4 relay system itself seems to be higher than to the native IPv6 Internet.
因此，对6to4中继系统本身的可用性和稳定性的威胁似乎高于对本机IPv6互联网的威胁。
This attack is similar to the ones employed against 6to4 routers, as described in Section 4.1.4. There are slight differences with regard to the source of the attacks. This attack can be initiated by:
如第4.1.4节所述，该攻击类似于针对6to4路由器的攻击。攻击的来源略有不同。此攻击可通过以下方式发起：
o native IPv6 nodes that may send traffic to the relay's subnet broadcast address, and
o 可能向中继的子网广播地址发送流量的本机IPv6节点，以及
o IPv4 nodes that may send traffic with a spoofed source IP address (to be the relay's broadcast address) to elicit replies (e.g., ICMPv6 Hop Limit Exceeded) from the 6to4 relay to its local nodes.
o IPv4节点，可使用伪造的源IP地址（作为中继的广播地址）发送通信量，以从6to4中继获取对其本地节点的回复（例如，超出了ICMPv6跃点限制）。
The first approach is more dangerous than those in Section 4.1.4 because it can be initiated by any IPv6 node (allowed to use the relay); the approach is not limited to local users.
第一种方法比第4.1.4节中的方法更危险，因为它可以由任何IPv6节点启动（允许使用中继）；这种方法不仅限于本地用户。
The second approach is trickier and not really useful. For it to succeed, the relay would have to accept native source addresses over the 6to4 pseudo-interface (we did not assume this check was implemented), as if coming from another relay, triggering an ICMPv6 message to the relay's local IPv4 subnet. The former method is more lucrative.
第二种方法比较棘手，也不是很有用。要使其成功，中继必须通过6to4伪接口接受本机源地址（我们不认为执行了此检查），就像来自另一个中继一样，触发到中继本地IPv4子网的ICMPv6消息。前者利润更高。
EXTENSIONS
扩展
None.
没有一个
THREAT ANALYSIS AND SOLUTIONS/MITIGATION METHODS
威胁分析和解决方案/缓解方法
The threat is restricted to the relay's local subnet and is fixed by tightening the 6to4 security checks.
该威胁仅限于中继的本地子网，并通过加强6to4安全检查来修复。
COMPARISON TO SITUATION WITHOUT 6to4
与没有6to4的情况进行比较
This scenario is caused by 6to4, but fortunately the issue is not serious.
这种情况是由6to4引起的，但幸运的是问题并不严重。
ATTACK DESCRIPTION
攻击描述
The 6to4 relay administrators would often want to use some policy to limit the use of the relay to specific 6to4 sites and/or specific IPv6 sites.
6to4中继管理员通常希望使用某些策略将中继的使用限制到特定6to4站点和/或特定IPv6站点。
The policy control is usually enacted by applying restrictions to where the routing information for 2002::/16 and/or 192.188.99.0/24 (if the anycast address used [3]) will spread.
策略控制通常通过将限制应用于2002年的路由信息：/16和/或192.188.99.0/24（如果使用了选播地址[3]）将传播的位置来实施。
Some users may be able to use the service regardless of these controls, by
有些用户可以通过以下方式使用该服务，而不必考虑这些控件：
o configuring the address of the relay using its IPv4 address instead of 192.88.99.1, or
o 使用其IPv4地址（而不是192.88.99.1）配置中继的地址，或
o using the routing header to route IPv6 packets to reach specific 6to4 relays. (Other routing tricks, such as using static routes, may also be used.)
o 使用路由报头将IPv6数据包路由到特定的6to4中继。（也可以使用其他路由技巧，例如使用静态路由。）
EXTENSIONS
扩展
None.
没有一个
THREAT ANALYSIS AND SOLUTIONS/MITIGATION METHODS
威胁分析和解决方案/缓解方法
Attempts to use the relay's IPv4 address instead of 192.88.99.1 can be mitigated in the following ways:
尝试使用中继的IPv4地址而不是192.88.99.1可以通过以下方式缓解：
1. IPv4 domains should prevent use of the actual IPv4 address of the relay instead of 192.88.99.1.
1. IPv4域应阻止使用中继的实际IPv4地址，而不是192.88.99.1。
2. Usage of access lists in the 6to4 relay to limit access. This is only feasible if the number of IP networks the relay is supposed to serve is relatively low.
2. 在6to4中继中使用访问列表来限制访问。只有当中继应该服务的IP网络数量相对较低时，这才是可行的。
3. The 6to4 relay should filter out arriving tunneled packets with protocol 41 (IPv6) that do not have 192.88.99.1 as the destination address.
3. 6to4中继应过滤掉使用协议41（IPv6）的到达隧道包，该协议没有192.88.99.1作为目标地址。
The other threat, of using routing tricks in the IPv6 networks to reach the 6to4 relay, has similar solutions:
另一个威胁是在IPv6网络中使用路由技巧到达6to4中继，其解决方案类似：
1. Usage of access lists in the relay to limit access.
1. 在中继中使用访问列表来限制访问。
2. Filtering out the packets with a routing header (although this may have other implications).
2. 使用路由报头过滤出数据包（尽管这可能有其他影响）。
3. Monitoring the source addresses going through the relay to detect, e.g., peers setting up static routes.
3. 监控通过中继的源地址，以检测（例如）设置静态路由的对等方。
Routing Header is not specific to 6to4. The main thing one could do with it here would be to select the relay. Some generic threats about routing header use are described in [11].
路由标头不是特定于6to4的。在这里，人们可以做的主要事情是选择继电器。[11]中描述了有关路由头使用的一些常见威胁。
As this threat does not have implications for anything other than the organization providing 6to4 relay, it is not analyzed any further.
由于该威胁对提供6to4中继的组织以外的任何其他组织都没有影响，因此不会对其进行进一步分析。
COMPARISON TO SITUATION WITHOUT 6to4
与没有6to4的情况进行比较
These threats are specific to 6to4 relays (or in general anycast services) and do not exist in networks without 6to4.
这些威胁特定于6to4中继（或一般选播服务），在没有6to4的网络中不存在。
ATTACK DESCRIPTION
攻击描述
Several attacks use 6to4 relays to anonymize the traffic; this often results in packets being tunneled from the relay to a supposedly-6to4 site.
一些攻击使用6to4中继来匿名流量；这通常会导致数据包从中继器通过隧道传输到假定的-6to4站点。
However, as was pointed out in Section 4.2, the IPv4 source address used by the relay could, on a cursory look, be seen as the source of these "protocol-41" attacks.
然而，正如第4.2节所指出的，粗略地看，中继使用的IPv4源地址可能被视为这些“协议-41”攻击的来源。
This could cause a number of concerns for the operators deploying 6to4 relay service, including the following:
这可能会给部署6to4中继服务的运营商带来许多问题，包括：
o being contacted a lot (via email, phone, fax, or lawyers) on suspected "abuse",
o 因涉嫌“虐待”而经常联系（通过电子邮件、电话、传真或律师），
o having the whole IPv4 address range rejected as a source of abuse or spam, causing outage to other operations as well, or
o 将整个IPv4地址范围作为滥用或垃圾邮件源拒绝，从而导致其他操作中断，或
o causing the whole IPv4 address range to be blacklisted in some "spammer databases", if the relay were used for those purposes.
o 导致整个IPv4地址范围在某些“垃圾邮件发送者数据库”中被列入黑名单，如果中继用于这些目的。
This threat seems slightly similar to the outburst of SMTP abuse caused by open relays but is more generic.
这一威胁似乎与开放式中继导致的SMTP滥用爆发略有相似，但更为普遍。
EXTENSIONS
扩展
None.
没有一个
THREAT ANALYSIS AND SOLUTIONS/MITIGATION METHODS
威胁分析和解决方案/缓解方法
This problem can be avoided (or, really, "made someone else's problem") by using the 6to4 anycast address in 192.88.99.0/24 as the source address. Blacklisting or rejecting this should not cause problems to the other operations.
通过使用192.88.99.0/24中的6to4选播地址作为源地址，可以避免这个问题（或者说，实际上是“制造了其他人的问题”）。将其列入黑名单或拒绝不应给其他操作带来问题。
Further, when someone files complaints to the owner of 192.88.99.0/24, depending on which registry they are querying, they might get, for example:
此外，当有人向192.88.99.0/24的所有者投诉时，根据他们查询的注册表，他们可能会得到，例如：
o knowledge that this is a special IANA address block, with no real contact person,
o IANA这个人没有特别的联系地址，
o knowledge that this is a special address block for RFC 3068, or
o 知道这是RFC 3068的特殊地址块，或
o knowledge that this is a special address block for RFC 3068, and that there are multiple entries by relay operators in the database.
o 知道这是RFC 3068的一个特殊地址块，并且数据库中有多个中继运算符的条目。
Any of these, at least when processed by a human, should show that the 6to4 relay is in fact innocent. Of course, this could result in reports going to the closest anycast 6to4 relay as well, which had nothing to do with the incident.
其中任何一个，至少在人工处理的情况下，都应该表明6to4继电器实际上是无辜的。当然，这也可能导致报道传到最近的选播6to4转播，而这与事件无关。
However, the widespread usage of 192.88.99.1 as the source address may make it more difficult to disambiguate the relays, which might be a useful feature for debugging purposes.
然而，192.88.99.1作为源地址的广泛使用可能会使消除继电器歧义变得更加困难，这可能是调试目的的一个有用特性。
COMPARISON TO SITUATION WITHOUT 6to4
与没有6to4的情况进行比较
This threat is caused by 6to4 deployment but can be avoided, at least in the short-term, by using 192.88.99.1 as the source address.
这种威胁是由6to4部署造成的，但至少在短期内可以通过使用192.88.99.1作为源地址来避免。
There are two types of attacks on the IPv4 internet - spoofed traffic, and reflection. These can be initiated by native IPv6 nodes, 6to4 nodes, and IPv4 nodes.
IPv4互联网上存在两种类型的攻击—欺骗流量和反射。这些可以由本机IPv6节点、6to4节点和IPv4节点启动。
Attacks initiated by IPv4 nodes that send spoofed traffic, which would not use the 6to4 infrastructure, are considered out of the scope of this document. 6to4 infrastructure may be used in reflection attacks initiated by IPv4 nodes.
由发送伪造流量的IPv4节点发起的攻击（不使用6to4基础设施）不在本文档范围内。6to4基础设施可用于IPv4节点发起的反射攻击。
It is difficult for these attacks to be effective, as the traffic sent out will be IPv6-in-IPv4. Such traffic will be rejected by most IPv4 nodes unless they have implemented some sort of IPv6-in-IPv4 tunneling.
这些攻击很难有效，因为发送的流量将是IPv4中的IPv6。大多数IPv4节点都会拒绝此类流量，除非它们实现了某种IPv6-in-IPv4隧道。
Columns:
柱：
o Section number. The section that describes the attack.
o 章节号。描述攻击的部分。
o Attack name.
o 攻击名。
o Initiator. The node that initiates the attack.
o 发起者。发起攻击的节点。
* I_4 - IPv4 node
* I_4-IPv4节点
* I_6 - native IPv6 node
* I_6-本机IPv6节点
* 6to4 - 6to4 node
* 6to4-6to4节点
* * - All of the above
* * - All of the above
o Victim. The victim node
o 受害者受害者节点
* I_4 - IPv4 node
* I_4-IPv4节点
* I_6 - native IPv6 node
* I_6-本机IPv6节点
* 6to4 - 6to4 node
* 6to4-6to4节点
* Relay - 6to4 relay
* 继电器-6to4继电器
* Router - 6to4 router
* 路由器-6to4路由器
o ToA. Type of Attack
o 托亚。攻击类型
* D - DoS
* D-DoS
* R - Reflection DoS
* R反射DoS
* T - Theft of Service
* T-服务盗窃
o Fix. Specified who is responsible for fixing the attack.
o 修理指定谁负责修复攻击。
* 6 - The 6to4 developer and/or operator can completely mitigate this attack.
* 6-6to4开发人员和/或运营商可以完全缓解此攻击。
* 6* - The 6to4 developer and/or operator can partially mitigate this attack.
* 6*-6to4开发人员和/或运营商可以部分缓解此攻击。
* E - This threat cannot be fixed by the 6to4 developer or the 6to4 operator.
* E-此威胁无法由6to4开发人员或6to4运营商修复。
Summary of attacks on a 6to4 network:
对6to4网络的攻击摘要：
+-------+----------------------+---------+----------+-----+-----+
| Sec | Attack name |Initiator| Victim | ToA | Fix |
+-------+----------------------+---------+----------+-----+-----+
| 4.1.1 | Attacks with ND | I_4 | Router | D | 6 |
+-------+----------------------+---------+----------+-----+-----+
| 4.1.2 | Spoofing Traffic | I_4,I_6 | 6to4 | D | E |
+-------+----------------------+---------+----------+-----+-----+
| 4.1.3 | Reflection Attacks | * | 6to4 | R | 6* |
+-------+----------------------+---------+----------+-----+-----+
| 4.1.4 | Local IPv4 Broadcast | * | Router | D | 6 |
+-------+----------------------+---------+----------+-----+-----+
+-------+----------------------+---------+----------+-----+-----+
| Sec | Attack name |Initiator| Victim | ToA | Fix |
+-------+----------------------+---------+----------+-----+-----+
| 4.1.1 | Attacks with ND | I_4 | Router | D | 6 |
+-------+----------------------+---------+----------+-----+-----+
| 4.1.2 | Spoofing Traffic | I_4,I_6 | 6to4 | D | E |
+-------+----------------------+---------+----------+-----+-----+
| 4.1.3 | Reflection Attacks | * | 6to4 | R | 6* |
+-------+----------------------+---------+----------+-----+-----+
| 4.1.4 | Local IPv4 Broadcast | * | Router | D | 6 |
+-------+----------------------+---------+----------+-----+-----+
Figure 9
图9
Summary of attacks on the native IPv6 internet:
对本机IPv6 internet的攻击摘要：
+-------+----------------------+---------+----------+-----+-----+
| Sec | Attack name |Initiator| Victim | ToA | Fix |
+-------+----------------------+---------+----------+-----+-----+
| 4.2.1 | Attacks with ND | I_4 | Relay | D | 6 |
+-------+----------------------+---------+----------+-----+-----+
| 4.2.2 | Spoofing Traffic | I_4,6to4| I_6 | D | 6* |
+-------+----------------------+---------+----------+-----+-----+
| 4.2.3 | Reflection Attacks | * | I_6 | R | 6* |
+-------+----------------------+---------+----------+-----+-----+
| 4.2.4 | Local IPv4 Broadcast | * | Relay | D | 6 |
+-------+----------------------+---------+----------+-----+-----+
| 4.2.5 | Theft of Service | 6to4 | Relay | T | 6 |
+-------+----------------------+---------+----------+-----+-----+
| 4.2.6 | Relay Operators ... | - | - | D | 1) |
+-------+----------------------+---------+----------+-----+-----+
+-------+----------------------+---------+----------+-----+-----+
| Sec | Attack name |Initiator| Victim | ToA | Fix |
+-------+----------------------+---------+----------+-----+-----+
| 4.2.1 | Attacks with ND | I_4 | Relay | D | 6 |
+-------+----------------------+---------+----------+-----+-----+
| 4.2.2 | Spoofing Traffic | I_4,6to4| I_6 | D | 6* |
+-------+----------------------+---------+----------+-----+-----+
| 4.2.3 | Reflection Attacks | * | I_6 | R | 6* |
+-------+----------------------+---------+----------+-----+-----+
| 4.2.4 | Local IPv4 Broadcast | * | Relay | D | 6 |
+-------+----------------------+---------+----------+-----+-----+
| 4.2.5 | Theft of Service | 6to4 | Relay | T | 6 |
+-------+----------------------+---------+----------+-----+-----+
| 4.2.6 | Relay Operators ... | - | - | D | 1) |
+-------+----------------------+---------+----------+-----+-----+
Figure 10
图10
Notes:
笔记：
1) This attack is a side-effect of the other attacks and thus does not have any Initiator, Victim, and Fix. It is a Denial of Service attack not on the network but on the organization in-charge of the relay.
1) 此攻击是其他攻击的副作用，因此没有任何启动器、受害者和修复程序。这是一种拒绝服务攻击，不是针对网络，而是针对负责中继的组织。
Summary of attacks on IPv4 internet:
对IPv4 internet的攻击摘要：
+-------+----------------------+---------+----------+-----+-----+
| Sec | Attack name |Initiator| Victim | ToA | Fix |
+-------+----------------------+---------+----------+-----+-----+
| 4.3 | Spoofing Traffic | * | I_4 | D | 6* |
+-------+----------------------+---------+----------+-----+-----+
| 4.3 | Reflection Attacks | * | I_4 | R | 6* |
+-------+----------------------+---------+----------+-----+-----+
+-------+----------------------+---------+----------+-----+-----+
| Sec | Attack name |Initiator| Victim | ToA | Fix |
+-------+----------------------+---------+----------+-----+-----+
| 4.3 | Spoofing Traffic | * | I_4 | D | 6* |
+-------+----------------------+---------+----------+-----+-----+
| 4.3 | Reflection Attacks | * | I_4 | R | 6* |
+-------+----------------------+---------+----------+-----+-----+
Figure 11
图11
This section describes several ways to implement the security checks required or implied by the specification [1] or augmented by this memo. These do not, in general, protect against most of the threats listed above in the "Threat Analysis" section. They are only prerequisites for a relatively safe and simple 6to4 implementation.
本节描述了实施规范[1]要求或暗示的或本备忘录补充的安全检查的几种方法。一般来说，这些都不能抵御上述“威胁分析”部分中列出的大多数威胁。它们只是相对安全和简单的6to4实现的先决条件。
Note that, in general, the 6to4 router or relay does not know whether it is acting as a router or relay. It would be possible to include a toggle to specify the behaviour, to be used when, e.g., the interface is brought up, but as of February 2004, no implementations were known to do that. Therefore, the checks are described as that which works independently of whether the node is a router or relay.
请注意，一般情况下，6to4路由器或中继器不知道它是否充当路由器或中继器。可以包括一个开关来指定行为，例如，在打开接口时使用，但截至2004年2月，还没有已知的实现可以这样做。因此，检查被描述为独立于节点是路由器还是中继而工作的检查。
The checks described in this section are to be performed when encapsulating IPv6 into IPv4.
将IPv6封装到IPv4时，将执行本节中描述的检查。
The encapsulation rules are mainly designed to keep implementors from "shooting themselves in the foot." For example, the source address check would verify that the packet will be acceptable to the decapsulator, or the sanity checks would ensure that addresses derived from private addresses are not used (which would be equally unacceptable).
封装规则主要是为了防止实现者“自食其果”。例如，源地址检查将验证数据包是否可被解封器接受，或者健全性检查将确保不使用从私有地址派生的地址（这同样是不可接受的）。
src_v6 and dst_v6 MUST pass ipv6-sanity checks (see below) else drop
if prefix (src_v6) == 2002::/16
ipv4 address embedded in src_v6 MUST match src_v4
else if prefix (dst_v6) == 2002::/16
dst_v4 SHOULD NOT be assigned to the router
else
drop
/* we somehow got a native-native ipv6 packet */
fi
accept
src_v6 and dst_v6 MUST pass ipv6-sanity checks (see below) else drop
if prefix (src_v6) == 2002::/16
ipv4 address embedded in src_v6 MUST match src_v4
else if prefix (dst_v6) == 2002::/16
dst_v4 SHOULD NOT be assigned to the router
else
drop
/* we somehow got a native-native ipv6 packet */
fi
accept
The checks described in this section are to be performed when decapsulating IPv4 into IPv6. They will be performed in both the 6to4 router and relay.
将IPv4解封为IPv6时，将执行本节中描述的检查。它们将在6to4路由器和中继中执行。
src_v4 and dst_v4 MUST pass ipv4-sanity checks, else drop
src_v6 and dst_v6 MUST pass ipv6-sanity checks, else drop
if prefix (dst_v6) == 2002::/16
ipv4 address embedded in dst_v6 MUST match dst_v4
if prefix (src_v6) == 2002::/16
ipv4 address embedded in src_v6 MUST match src_v4
dst_v4 SHOULD be assigned to the router
fi
elif prefix (src_v6) == 2002::/16
ipv4 address embedded in src_v6 MUST match src_v4
dst_v4 SHOULD be assigned to the router (see notes below)
src_v4 and dst_v4 MUST pass ipv4-sanity checks, else drop
src_v6 and dst_v6 MUST pass ipv6-sanity checks, else drop
if prefix (dst_v6) == 2002::/16
ipv4 address embedded in dst_v6 MUST match dst_v4
if prefix (src_v6) == 2002::/16
ipv4 address embedded in src_v6 MUST match src_v4
dst_v4 SHOULD be assigned to the router
fi
elif prefix (src_v6) == 2002::/16
ipv4 address embedded in src_v6 MUST match src_v4
dst_v4 SHOULD be assigned to the router (see notes below)
else
drop
/* the we somehow got a native-native ipv6 packet */
fi
accept
else
drop
/* the we somehow got a native-native ipv6 packet */
fi
accept
The encapsulation and decapsulation checks include certain sanity checks for both IPv4 and IPv6. These are described here in detail.
封装和解除封装检查包括IPv4和IPv6的某些健全性检查。这里详细描述了这些。
IPv4 address MUST be a global unicast address, as required by the 6to4 specification. The disallowed addresses include those defined in [14], and others widely used and known not to be global. These are
IPv4地址必须是6to4规范要求的全局单播地址。不允许的地址包括[14]中定义的地址，以及其他广泛使用且已知不是全局地址的地址。这些是
o 0.0.0.0/8 (the system has no address assigned yet)
o 0.0.0.0/8（系统尚未分配地址）
o 10.0.0.0/8 (private)
o 10.0.0.0/8（私人）
o 127.0.0.0/8 (loopback)
o 127.0.0.0/8（环回）
o 172.16.0.0/12 (private)
o 172.16.0.0/12（私人）
o 192.168.0.0/16 (private)
o 192.168.0.0/16（私人）
o 169.254.0.0/16 (IANA Assigned DHCP link-local)
o 169.254.0.0/16（IANA分配的DHCP链路本地）
o 224.0.0.0/4 (multicast)
o 224.0.0.0/4（多播）
o 240.0.0.0/4 (reserved and broadcast)
o 240.0.0.0/4（保留和广播）
In addition, the address MUST NOT be any of the system's broadcast addresses. This is especially important if the implementation is made so that it can
此外，地址不得为系统的任何广播地址。如果实施是为了能够
o receive and process encapsulated IPv4 packets arriving at its broadcast addresses, or
o 接收并处理到达其广播地址的封装IPv4数据包，或
o send encapsulated IPv4 packets to one of its broadcast addresses.
o 将封装的IPv4数据包发送到其广播地址之一。
IPv6 address MUST NOT be
IPv6地址不能为空
o 0::/16 (compatible, mapped addresses, loopback, unspecified, ...)
o 0:：/16（兼容、映射地址、环回、未指定等）
o fe80::/10 (link-local)
o fe80:：/10（链路本地）
o fec0::/10 (site-local)
o fec0:：/10（现场本地）
o ff00::/8 (any multicast)
o ff00:：/8（任意多播）
Note: Only link-local multicast would be strictly required, but it is believed that multicast with 6to4 will not be feasible, so it has been disallowed as well.
注意：严格要求只进行链路本地多播，但认为使用6to4的多播是不可行的，因此也被禁止。
In addition, it MUST be checked that equivalent 2002:V4ADDR::/48 checks, where V4ADDR is any of the above IPv4 addresses, will not be passed.
此外，必须检查是否不会通过等效的2002:V4ADDR:：/48检查，其中V4ADDR是上述任何IPv4地址。
In addition, the implementation in the 6to4 router may perform some form of ingress filtering (e.g., Unicast Reverse Path Forwarding checks). For example, if the 6to4 router has multiple interfaces, of which some are "internal", receiving either IPv4 or IPv6 packets with source address belonging to any of these internal networks from the Internet might be disallowed.
此外，6to4路由器中的实现可以执行某种形式的入口过滤（例如，单播反向路径转发检查）。例如，如果6to4路由器有多个接口，其中一些是“内部”接口，则可能不允许从Internet接收源地址属于这些内部网络中任何一个的IPv4或IPv6数据包。
If these checks are implemented and enabled by default, it's recommended that there be a toggle to disable them if needed.
如果默认情况下实现并启用了这些检查，建议在需要时使用切换来禁用它们。
The rule "dst_v4 SHOULD be assigned to the router" is not needed if the 6to4 router implementation only accepts and processes encapsulated IPv4 packets arriving to its unicast IPv4 addresses, and when the destination address is known to be a local broadcast address, it does not try to encapsulate and send packets to it. (See Sections 4.1.4 and 4.2.4 about this threat.)
如果6to4路由器实现仅接受和处理到达其单播IPv4地址的封装IPv4数据包，并且当已知目标地址是本地广播地址时，它不会尝试封装和向其发送数据包，则不需要规则“dst_v4应分配给路由器”。（关于此威胁，请参见第4.1.4节和第4.2.4节。）
Some checks, especially the IPv4/IPv6 Sanity Checks, could be at least partially implementable with system-level access lists, if one would like to avoid placing too many restrictions in the 6to4 implementation itself. This depends on how many hooks are in place for the access lists. In practice, it seems that this could not be done effectively enough unless the access list mechanism is able to parse the encapsulated packets.
如果希望避免在6to4实现本身中设置太多限制，则某些检查，特别是IPv4/IPv6健全性检查，至少可以通过系统级访问列表部分实现。这取决于访问列表有多少挂钩。实际上，除非访问列表机制能够解析封装的数据包，否则这似乎无法足够有效地完成。
This section tries to give an overview of some of the problems 6to4 implementations face, and the kind of generic problems the 6to4 users could come up with.
本节试图概述6to4实现面临的一些问题，以及6to4用户可能遇到的一般问题。
There is a problem with multiple transition mechanisms if strict security checks are implemented. This may vary a bit from implementation to implementation.
如果实施严格的安全检查，则多个转换机制存在问题。这可能因实现而异。
Consider three mechanisms using automatic tunneling: 6to4, ISATAP [15], and Automatic Tunneling using Compatible Addresses [4] (currently removed [10] but typically still supported). All of these use IP-IP (protocol 41) [16] IPv4 encapsulation with, more or less, a pseudo-interface.
考虑使用自动隧道的三种机制：6to4、ISATAP（15）和使用兼容地址[4 ]的自动隧穿（当前移除（10），但通常仍然支持）。所有这些都使用IP-IP（协议41）[16]IPv4封装，或多或少带有一个伪接口。
When a router, which has any two of these enabled, receives an IPv4 encapsulated IPv6 packet
当启用了其中任意两个的路由器接收到IPv4封装的IPv6数据包时
src_v6 = 2001:db8::1
dst_v6 = 2002:1010:1010::2
src_v4 = 10.0.0.1
dst_v4 = 20.20.20.20
src_v6 = 2001:db8::1
dst_v6 = 2002:1010:1010::2
src_v4 = 10.0.0.1
dst_v4 = 20.20.20.20
What can it do? How should it decide which transition mechanism this belongs to; there is no "transition mechanism number" in the IPv6 or IPv4 header to signify this. (This can also be viewed as a flexibility benefit.)
它能做什么？如何确定这属于哪种过渡机制;；IPv6或IPv4标头中没有表示这一点的“转换机制编号”。（这也可以视为灵活性优势。）
Without any kind of security checks (in any of the implemented methods), these often just "work", as the mechanisms aren't differentiated but handled in "one big lump".
没有任何类型的安全检查（在任何实现的方法中），这些通常只是“工作”，因为这些机制没有区别，而是在“一大块”中处理。
Configured tunneling [4] does not suffer from this, as it is point-to-point and based on src_v6/dst_v6 pairs of both IPv4 and IPv6 addresses, so the tunnel interface can be logically deduced.
配置的隧道[4]不受此影响，因为它是点对点的，并且基于IPv4和IPv6地址的src_v6/dst_v6对，因此可以从逻辑上推断隧道接口。
Solutions for this include 1) not using more than one automatic tunneling mechanism in a node and 2) binding different mechanisms to different IPv4 addresses.
解决方案包括：1）在一个节点中不使用多个自动隧道机制；2）将不同的机制绑定到不同的IPv4地址。
Even though this was already discussed in Section 4.1.2, it bears some additional elaboration, as it was the only problem that cannot be even partially solved using the current deployment model. There are some mitigation methods.
尽管这已经在第4.1.2节中讨论过，但它还需要一些额外的阐述，因为这是使用当前部署模型无法部分解决的唯一问题。有一些缓解方法。
6to4 routers receive traffic from non-6to4 ("native") sources via 6to4 relays. 6to4 routers have no way of matching the IPv4 source address of the relay with the non-6to4 IPv6 address of the source. Consequently, anyone can spoof any non-6to4 IPv6 address by sending traffic, encapsulated, directly to 6to4 routers.
6to4路由器通过6to4中继接收来自非6to4（“本机”）源的流量。6to4路由器无法将中继的IPv4源地址与源的非6to4 IPv6地址匹配。因此，任何人都可以通过将封装的通信量直接发送到6to4路由器来欺骗任何非6to4 IPv6地址。
It could be possible to turn the deployment assumptions of 6to4 around a bit to eliminate some threats caused by untrusted 6to4 relays:
可以稍微改变6to4的部署假设，以消除不受信任的6to4中继造成的一些威胁：
o Every dual-stack site (or even ISP) would be required to have its own 6to4 relay. (This assumes that IPv6-only is so far away that 6to4 would be retired by that point.) That is, there would not be third-party relays, and 2002::/16 and 192.88.99.0/24 routes would not need to be advertised globally.
o 每个双栈站点（甚至ISP）都需要有自己的6to4中继。（这假设IPv6离6to4只有这么远，到那时6to4将退役。）也就是说，将不会有第三方中继，并且2002:：/16和192.88.99.0/24路由将不需要在全球发布。
o The security implications of 6to4 use could be pushed back to the level of trust inside the site or ISP (or their acceptable use policies). This is something that the sites and ISPs should already be familiar with already.
o 6to4使用的安全影响可能会被推回到站点或ISP内部的信任级别（或其可接受的使用策略）。这是网站和ISP应该已经熟悉的东西。
However, this presents a number of problems:
然而，这带来了一些问题：
This model would shift most of the burden of supporting 6to4 to IPv6 sites that don't employ or use 6to4 at all, i.e., "those who deploy proper native dual-stack." It could be argued that the deployment pain should be borne by 6to4 users, not by the others.
这种模式将把支持6to4的大部分负担转移到根本不采用或使用6to4的IPv6站点，即“那些部署适当本机双堆栈的站点”。可以说，部署的痛苦应由6to4用户承担，而不是其他用户。
The main advantage of 6to4 is easy deployment and free relays. This would require that everyone the 6to4 sites wish to communicate with implement these measures.
6to4的主要优点是易于部署和自由继电器。这将要求6to4站点希望与之沟通的每个人实施这些措施。
The model would not fix the "relay spoofing problem", unless everybody also deployed 6to4 addresses on the nodes (alongside with native addresses, if necessary), which would in turn change 6to4 to operate without relays completely.
该模型不会解决“中继欺骗问题”，除非每个人都在节点上部署了6to4地址（必要时还部署了本机地址），这将反过来改变6to4，使其完全不使用中继。
This document discusses security considerations of 6to4.
本文档讨论6to4的安全注意事项。
Even if proper checks are implemented, there are a large number of different security threats; these threats are analyzed in Section 4.
即使实施了适当的检查，也存在大量不同的安全威胁；第4节对这些威胁进行了分析。
There are mainly four classes of potential problem sources:
主要有四类潜在问题源：
1. 6to4 routers not being able to identify whether relays are legitimate
1. 6to4路由器无法识别中继是否合法
2. Wrong or impartially implemented 6to4 router or relay security checks
2. 错误或公正地执行6到4路由器或中继安全检查
3. 6to4 architecture used to participate in DoS or reflected DoS attacks or made to participate in "packet laundering", i.e., making another attack harder to trace
3. 6to4体系结构用于参与DoS或反射DoS攻击，或参与“数据包清洗”，即使另一种攻击更难跟踪
4. 6to4 relays being subject to "administrative abuse" e.g., theft of service or being seen as a source of abuse.
4. 6to4继电器受到“行政滥用”的影响，例如，服务失窃或被视为滥用的来源。
The first is the toughest problem, still under research. The second can be fixed by ensuring the correctness of implementations; this is important. The third is also a very difficult problem, impossible to solve completely; therefore it is important to be able to analyze whether this results in a significant increase of threats. The fourth problem seems to have feasible solutions.
第一个是最棘手的问题，仍在研究中。第二个问题可以通过确保实现的正确性来解决；这很重要。第三也是一个很难的问题，不可能完全解决；因此，重要的是能够分析这是否会导致威胁的显著增加。第四个问题似乎有可行的解决办法。
These are analyzed in detail in "Threat Analysis", in Section 4.
第4节中的“威胁分析”详细分析了这些问题。
Some issues were first brought up by Itojun Hagino in [17], and Alain Durand introduced one specific problem at IETF51 in August 2001 (though there was some discussion on the list prior to that); these two gave the authors the push to start looking into the details of securing 6to4.
伊藤俊哈吉诺在[17]中首次提出了一些问题，阿兰·杜兰德在2001年8月的IETF51会议上提出了一个具体问题（尽管在此之前对列表进行了一些讨论）；这两位作者促使他们开始研究保护6to4的细节。
Alexey Kuznetsov brought up the implementation problem with IPv6 martian checks. Christian Huitema formulated the rules that rely on 6to4 relays using only anycast. Keith Moore brought up the point about reduced flexibility. Brian Carpenter, Tony Hain, and Vladislav Yasevich are acknowledged for lengthy discussions. Alain Durand reminded the authors about relay spoofing problems. Brian Carpenter reminded the authors about the BGP-based 6to4 router model. Christian Huitema gave a push for a more complete threat analysis. Itojun Hagino spelled out the operators' fears about 6to4 relay
Alexey Kuznetsov提出了IPv6火星检查的实施问题。Christian Huitema制定了只使用选播的6到4继电器规则。基思·摩尔提出了灵活性降低的观点。Brian Carpenter、Tony Hain和Vladislav Yasevich因长时间的讨论而受到认可。Alain Durand提醒作者注意中继欺骗问题。Brian Carpenter提醒作者基于BGP的6to4路由器模型。克里斯蒂安·惠特马（Christian Huitema）推动进行更全面的威胁分析。伊藤俊海野解释了运营商对6to4接力的担忧
abuse. Rob Austein brought up the idea of a different 6to4 deployment model.
滥用Rob Austein提出了一种不同的6to4部署模型。
In the latter phase, discussions with Christian Huitema, Brian Carpenter, and Alain Durand were helpful when improving the document.
在后一阶段，与Christian Huitema、Brian Carpenter和Alain Durand的讨论有助于改进文档。
David Malone, Iljitsch van Beijnum, and Tim Chown gave feedback on the document.
David Malone、Iljitsch van Beijnum和Tim Chown对该文件给出了反馈。
[1] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001.
[1] Carpenter，B.和K.Moore，“通过IPv4云连接IPv6域”，RFC 3056，2001年2月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[3] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", RFC 3068, June 2001.
[3] Huitema，C.，“6to4中继路由器的选播前缀”，RFC 3068，2001年6月。
[4] Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6 Hosts and Routers", RFC 2893, August 2000.
[4] Gilligan，R.和E.Nordmark，“IPv6主机和路由器的过渡机制”，RFC 28932000年8月。
[5] IANA, "Special-Use IPv4 Addresses", RFC 3330, September 2002.
[5] IANA，“特殊用途IPv4地址”，RFC 3330，2002年9月。
[6] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995.
[6] Rekhter，Y.和T.Li，“边境网关协议4（BGP-4）”，RFC 17711995年3月。
[7] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003.
[7] Draves，R.，“因特网协议版本6（IPv6）的默认地址选择”，RFC 3484，2003年2月。
[8] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor Discovery (ND) Trust Models and Threats", RFC 3756, May 2004.
[8] Nikander，P.，Kempf，J.和E.Nordmark，“IPv6邻居发现（ND）信任模型和威胁”，RFC 3756，2004年5月。
[9] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", Work in Progress, July 2004.
[9] Arkko，J.，Kempf，J.，Sommerfeld，B.，Zill，B.，和P.Nikander，“安全邻居发现（SEND）”，正在进行的工作，2004年7月。
[10] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", Work in Progress, September 2004.
[10] Nordmark，E.和R.Gilligan，“IPv6主机和路由器的基本转换机制”，正在进行的工作，2004年9月。
[11] Savola, P., "Security of IPv6 Routing Header and Home Address Options", Work in Progress, March 2002.
[11] Savola，P.，“IPv6路由头和家庭地址选项的安全”，正在进行的工作，2002年3月。
[12] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000.
[12] Ferguson，P.和D.Senie，“网络入口过滤：击败利用IP源地址欺骗的拒绝服务攻击”，BCP 38，RFC 2827，2000年5月。
[13] Bellovin, S., Leech, M. and T. Taylor, "ICMP Traceback Messages", Work in Progress, February 2003.
[13] Bellovin，S.，Leech，M.和T.Taylor，“ICMP回溯信息”，正在进行的工作，2003年2月。
[14] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[14] Baker，F.，“IP版本4路由器的要求”，RFC 1812，1995年6月。
[15] Templin, F., Gleeson, T., Talwar, M. and D. Thaler, "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", Work in Progress, May 2004.
[15] Templin，F.，Gleeson，T.，Talwar，M.和D.Thaler，“站点内自动隧道寻址协议（ISATAP）”，正在进行的工作，2004年5月。
[16] Simpson, W., "IP in IP Tunneling", RFC 1853, October 1995.
[16] 辛普森，W.，“IP隧道中的IP”，RFC 1853，1995年10月。
[17] Hagino, J., "Possible abuse against IPv6 transition technologies", Work in Progress, July 2000.
[17] Hagino，J.，“可能滥用IPv6过渡技术”，正在进行的工作，2000年7月。
Here, a few trivial attack scenarios are outlined -- ones that are prevented by implementing checks listed in [1] or in section 6.
这里概述了一些常见的攻击场景——通过实施[1]或第6节中列出的检查可以防止这些场景。
When two 6to4 routers send traffic to each others' domains, the packet sent by RA to RB resembles the following:
当两个6to4路由器向彼此的域发送流量时，RA向RB发送的数据包类似于以下内容：
src_v6 = 2002:0800:0001::aaaa
dst_v6 = 2002:0800:0002::bbbb
src_v4 = 8.0.0.1 (added when encapsulated to IPv4)
dst_v4 = 8.0.0.2 (added when encapsulated to IPv4)
src_v6 = 2002:0800:0001::aaaa
dst_v6 = 2002:0800:0002::bbbb
src_v4 = 8.0.0.1 (added when encapsulated to IPv4)
dst_v4 = 8.0.0.2 (added when encapsulated to IPv4)
When the packet is received by IPv4 stack on RB, it will be decapsulated so that only src_v6 and dst_v6 remain, as originally sent by RA:
当数据包由RB上的IPv4堆栈接收时，它将被解除封装，以便只保留src_v6和dst_v6，如RA最初发送的：
src_v6 = 2002:0800:0001::aaaa
dst_v6 = 2002:0800:0002::bbbb
src_v6 = 2002:0800:0001::aaaa
dst_v6 = 2002:0800:0002::bbbb
As every other node is just one hop away (IPv6-wise) and the link-layer (IPv4) addresses are lost, this may open many possibilities for misuse.
由于每一个其他节点都只有一个跃点（IPv6）距离，并且链路层（IPv4）地址丢失，这可能导致许多误用。
As an example, unidirectional IPv6 spoofing is made trivial because nobody can check (without delving into IP-IP packets) whether the encapsulated IPv6 addresses were authentic. (With native IPv6, this can be done by, e.g., RPF-like mechanisms or access lists in upstream routers.)
例如，单向IPv6欺骗变得微不足道，因为没有人能够检查（不深入研究IP-IP数据包）封装的IPv6地址是否真实。（对于本机IPv6，这可以通过上游路由器中类似RPF的机制或访问列表来实现。）
src_v6 = 2002:1234:5678::aaaa (forged)
dst_v6 = 2002:0800:0002::bbbb
src_v4 = 8.0.0.1 (added when encapsulated to IPv4)
dst_v4 = 8.0.0.2 (added when encapsulated to IPv4)
src_v6 = 2002:1234:5678::aaaa (forged)
dst_v6 = 2002:0800:0002::bbbb
src_v4 = 8.0.0.1 (added when encapsulated to IPv4)
dst_v4 = 8.0.0.2 (added when encapsulated to IPv4)
A similar attack with "src" being the native address is made possible, even with the security checks, by having the sender node pretend to be a 6to4 relay router.
通过让发送方节点假装为6to4中继路由器，即使在进行安全检查的情况下，“src”作为本机地址的类似攻击也是可能的。
More worries come into the picture if, e.g.,
如果，例如：。，
src_v6 = ::ffff:[some trusted IPv4 in a private network] src_v6/dst_v6 = ::ffff:127.0.0.1 src_v6/dst_v6 = ::1 src_v6/dst_v6 = ...
src_v6=：：ffff:[私人网络中的某些受信任IPv4]src_v6/dst_v6=：：ffff:127.0.0.1 src_v6/dst_v6=：：1 src_v6/dst_v6=。。。
Some implementations might have been careful enough to design the stack so as to avoid the incoming (or reply) packets going to IPv4 packet processing through special addresses (e.g., IPv4-mapped addresses), but who can say for all ...
一些实现可能已经足够小心地设计了堆栈，以避免传入（或应答）数据包通过特殊地址（例如，IPv4映射地址）进入IPv4数据包处理，但谁能说全部。。。
Authors' Addresses
作者地址
Pekka Savola CSC/FUNET Espoo Finland
佩卡·萨沃拉CSC/芬兰福内·埃斯波
EMail: psavola@funet.fi
EMail: psavola@funet.fi
Chirayu Patel All Play, No Work 185, Defence Colony Bangalore, Karnataka 560038 India
奇拉尤·帕特尔全场发挥，无功185，印度卡纳塔克邦邦加罗尔防御殖民地560038
Phone: +91-98452-88078
EMail: chirayu@chirayu.org
URI: http://www.chirayu.org
Phone: +91-98452-88078
EMail: chirayu@chirayu.org
URI: http://www.chirayu.org
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2004).
版权所有（C）互联网协会（2004年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关IETF文件中权利的IETF程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。