Internet Engineering Task Force (IETF) B. Carpenter
Request for Comments: 6343 Univ. of Auckland
Category: Informational August 2011
ISSN: 2070-1721
Internet Engineering Task Force (IETF) B. Carpenter
Request for Comments: 6343 Univ. of Auckland
Category: Informational August 2011
ISSN: 2070-1721
Advisory Guidelines for 6to4 Deployment
6to4部署咨询指南
Abstract
摘要
This document provides advice to network operators about deployment of the 6to4 technique for automatic tunneling of IPv6 over IPv4. It is principally addressed to Internet Service Providers (ISPs), including those that do not yet support IPv6, and to Content Providers. Some advice to implementers is also included. The intention of the advice is to minimize both user dissatisfaction and help-desk calls.
本文档向网络运营商提供有关部署6to4技术以通过IPv4自动隧道IPv6的建议。它主要面向互联网服务提供商（ISP），包括尚未支持IPv6的ISP，以及内容提供商。还包括对实施者的一些建议。建议的目的是尽量减少用户不满和服务台电话。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6343.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6343.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................2
2. Principles of Operation .........................................3
2.1. Router 6to4 ................................................3
2.2. Anycast 6to4 ...............................................4
3. Problems Observed ...............................................5
4. Advisory Guidelines ............................................10
4.1. Vendor Issues .............................................10
4.2. Consumer ISPs, and Enterprise Networks, That Do
Not Support IPv6 in Any Way ...............................11
4.2.1. Anycast Address Availability .......................11
4.2.2. Protocol 41 ........................................11
4.2.3. IPv4 Prefix Issues .................................12
4.2.4. DNS Issues .........................................12
4.2.5. Rogue Router Advertisements ........................12
4.2.6. Planning for IPv6 Deployment .......................13
4.3. Consumer ISPs, and Enterprise Networks, That Do
Support IPv6 ..............................................13
4.4. Transit ISPs and Internet Exchange Points .................14
4.5. Content Providers and Their ISPs ..........................15
5. Tunnels Managed by ISPs ........................................17
6. Security Considerations ........................................17
7. Acknowledgements ...............................................18
8. References .....................................................18
8.1. Normative References ......................................18
8.2. Informative References ....................................18
1. Introduction ....................................................2
2. Principles of Operation .........................................3
2.1. Router 6to4 ................................................3
2.2. Anycast 6to4 ...............................................4
3. Problems Observed ...............................................5
4. Advisory Guidelines ............................................10
4.1. Vendor Issues .............................................10
4.2. Consumer ISPs, and Enterprise Networks, That Do
Not Support IPv6 in Any Way ...............................11
4.2.1. Anycast Address Availability .......................11
4.2.2. Protocol 41 ........................................11
4.2.3. IPv4 Prefix Issues .................................12
4.2.4. DNS Issues .........................................12
4.2.5. Rogue Router Advertisements ........................12
4.2.6. Planning for IPv6 Deployment .......................13
4.3. Consumer ISPs, and Enterprise Networks, That Do
Support IPv6 ..............................................13
4.4. Transit ISPs and Internet Exchange Points .................14
4.5. Content Providers and Their ISPs ..........................15
5. Tunnels Managed by ISPs ........................................17
6. Security Considerations ........................................17
7. Acknowledgements ...............................................18
8. References .....................................................18
8.1. Normative References ......................................18
8.2. Informative References ....................................18
A technique for automatic tunneling of IPv6 over IPv4, intended for situations where a user may wish to access IPv6-based services via a network that does not support IPv6, was defined a number of years ago. It is known as 6to4 [RFC3056] [RFC3068] and is quite widely deployed in end systems, especially desktop and laptop computers. Also, 6to4 is supported in a number of popular models of CPE routers, some of which have it enabled by default, leading to quite widespread unintentional deployment by end users.
多年前定义了一种通过IPv4自动隧道IPv6的技术，用于用户可能希望通过不支持IPv6的网络访问基于IPv6的服务的情况。它被称为6to4[RFC3056][RFC3068]，广泛部署在终端系统中，尤其是台式机和笔记本电脑中。此外，6to4在许多流行的CPE路由器型号中都受支持，其中一些型号在默认情况下启用了6to4，这导致最终用户的非故意部署非常普遍。
Unfortunately, experience shows that the method has some problems in current deployments that can lead to connectivity failures. These failures cause either long retry delays or complete failures for users trying to connect to services. In many cases, the user may be quite unaware that 6to4 is in use; when the user contacts a help desk, in all probability the help desk is unable to correctly diagnose the problem. Anecdotally, many help desks simply advise users to disable IPv6, thus defeating the whole purpose of the mechanism, which was to encourage early adoption of IPv6.
不幸的是，经验表明，该方法在当前部署中存在一些问题，可能导致连接失败。这些故障会导致尝试连接到服务的用户出现长时间重试延迟或完全失败。在许多情况下，用户可能完全不知道6to4正在使用中；当用户联系服务台时，服务台很可能无法正确诊断问题。有趣的是，许多服务台只是建议用户禁用IPv6，从而破坏了该机制的全部目的，即鼓励尽早采用IPv6。
The main goal of the present document is to offer advice to network operators on how to deal with this situation more constructively than by disabling 6to4. It briefly describes the principle of operation, then describes the problems observed, and finally offers specific advice on the available methods of avoiding the problems. Note that some of this advice applies to ISPs that do not yet support IPv6, since their customers and help desks are significantly affected in any case.
本文件的主要目的是向网络运营商提供建议，说明如何以比禁用6to4更具建设性的方式应对这种情况。它简要描述了操作原理，然后描述了观察到的问题，最后就避免问题的可用方法提供了具体建议。请注意，其中一些建议适用于尚未支持IPv6的ISP，因为他们的客户和服务台在任何情况下都会受到重大影响。
Other advice applies to content providers and implementers, but this document does not discuss aspects that are mainly outside the scope of network operators:
其他建议适用于内容提供商和实施者，但本文件不讨论主要超出网络运营商范围的方面：
1. Operating system preferences between IPv4 and IPv6 when both appear to be available [RFC3484-REVISE].
1. IPv4和IPv6之间的操作系统首选项（当两者都可用时）[RFC3484-REVIEW]。
2. Ensuring that application software deals gracefully with connectivity problems [EYEBALLS-IPV6].
2. 确保应用软件优雅地处理连接问题[EYEBALLS-IPV6]。
3. Some content providers have chosen to avoid the problem by hiding their IPv6 address except from customers of pre-qualified networks [DNSWHITE].
3. 一些内容提供商已选择通过隐藏其IPv6地址来避免问题的发生，除非是对通过资格预审的网络[DNSWITE]的客户。
A companion document [HISTORIC] proposes to reclassify 6to4 as Historic. However, this will not remove the millions of existing hosts and CPEs that implement 6to4. Hence, the advice in this document remains necessary.
附带文件[历史]建议将6to4重新分类为历史文件。但是，这不会删除实现6to4的数百万现有主机和CPE。因此，本文件中的建议仍然是必要的。
There are two variants of 6to4 that are referred to here as "Router 6to4" and "Anycast 6to4". To understand Anycast 6to4, it is necessary first to understand Router 6to4.
6to4有两种变体，这里称为“路由器6to4”和“选播6to4”。要理解Anycast 6to4，首先需要理解路由器6to4。
Router 6to4 is the original version, documented in [RFC3056]. The model assumes that a user site operates native IPv6, but that its ISP provides no IPv6 service. The site border router acts as a 6to4 router. If its external global 32-bit IPv4 address is V4ADDR, the site automatically inherits the IPv6 prefix 2002:V4ADDR::/48. (The explanation in RFC 3056 is somewhat confusing, as it refers to the obsolete "Top Level Aggregator" terminology.) The prefix 2002: V4ADDR::/48 will be used and delegated for IPv6 service within the user site.
路由器6to4是原始版本，记录在[RFC3056]中。该模型假设用户站点运行本机IPv6，但其ISP不提供IPv6服务。站点边界路由器充当6to4路由器。如果其外部全局32位IPv4地址为V4ADDR，则站点将自动继承IPv6前缀2002:V4ADDR:：/48。（RFC 3056中的解释有些混乱，因为它引用了过时的“顶级聚合器”术语。）前缀2002:V4ADDR:：/48将用于用户站点内的IPv6服务。
Consider two such site border routers, with global IPv4 addresses 192.0.2.170 and 192.0.2.187, and that therefore inherit the IPv6 prefixes 2002:c000:2aa::/48 and 2002:c000:2bb::/48, respectively. The routers can exchange IPv6 packets by encapsulating them in IPv4 using protocol number 41, and sending them to each other at their respective IPv4 addresses. In fact, any number of 6to4 routers connected to the IPv4 network can directly exchange IPv6 packets in this way.
考虑两个这样的站点边界路由器，具有全局IPv4地址192.0.2.170和192.0.2.187，因此继承了IPv6前缀2002：C000 0:2AA:：/ 48和2002：C000 0:2BB:：/ 48。路由器可以通过使用协议编号41将IPv6数据包封装在IPv4中，并在各自的IPv4地址处相互发送来交换IPv6数据包。事实上，连接到IPv4网络的任何数量的6to4路由器都可以通过这种方式直接交换IPv6数据包。
Some 6to4 routers are also configured as "relay routers". They behave as just described, but, in addition, they obtain native IPv6 connectivity with a normal IPv6 prefix. They announce an IPv6 route to 2002::/16. For example, assume that the 6to4 router at 192.0.2.187 is a relay router, whose address on the 6to4 side is 2002:c000:2bb::1. Suppose that a host with the 6to4 address 2002: c000:2aa::123 sends an IPv6 packet to a native IPv6 destination such as 2001:db8:123:456::321. Assume that the 6to4 router at 192.0.2.170 has its IPv6 default route set to 2002:c000:2bb::1, i.e., the relay. The packet will be delivered to the relay, encapsulated in IPv4. The relay will decapsulate the packet and forward it into native IPv6 for delivery. When the remote host replies, the packet (source 2001:db8: 123:456::321, destination 2002:c000:2aa::123) will find a route to 2002::/16, and hence be delivered to a 6to4 relay. The process will be reversed and the packet will be encapsulated and forwarded to the 6to4 router at 192.0.2.170 for final delivery.
一些6to4路由器也被配置为“中继路由器”。它们的行为与刚才描述的一样，但是，除此之外，它们还使用正常的IPv6前缀获得本机IPv6连接。他们宣布了到2002年的IPv6路由：：/16。例如，假设192.0.2.187处的6to4路由器是中继路由器，其6to4侧的地址为2002:c000:2bb:：1。假设具有6to4地址2002:c000:2aa:：123的主机将IPv6数据包发送到本机IPv6目标，如2001:db8:123:456:：321。假设192.0.2.170处的6to4路由器的IPv6默认路由设置为2002:c000:2bb:：1，即中继。数据包将被发送到中继，并封装在IPv4中。中继将解除数据包的封装，并将其转发到本机IPv6以进行传递。当远程主机应答时，数据包（源2001:db8:123:456:：321，目的地2002:c000:2aa:：123）将找到到2002:：/16的路由，并因此被传送到6to4中继。该过程将被逆转，数据包将被封装并转发到位于192.0.2.170的6to4路由器进行最终交付。
Note that this process does not require the same relay to be used in both directions. The outbound packet will go to whichever relay is configured as the default IPv6 router at the source router, and the return packet will go to whichever relay is announcing a route to 2002::/16 in the vicinity of the remote IPv6 host.
注意，此过程不要求在两个方向上使用相同的继电器。出站数据包将发送到源路由器上配置为默认IPv6路由器的中继，返回数据包将发送到远程IPv6主机附近宣布路由到2002:：/16的中继。
Of course, there are many further details in RFC 3056, most of which are irrelevant to current operational problems.
当然，RFC3056中还有许多进一步的细节，其中大部分与当前的操作问题无关。
Router 6to4 assumes that 6to4 routers and relays will be managed and configured cooperatively. In particular, 6to4 sites need to configure a relay router willing to carry their outbound traffic, which becomes their default IPv6 router (except for 2002::/16). The objective of the anycast variant, defined in [RFC3068], is to avoid any need for such configuration. The intention was to make the solution available for small or domestic users, even those with a single host or simple home gateway rather than a border router. This is achieved quite simply, by defining 192.88.99.1 as the default IPv4 address for a 6to4 relay, and therefore 2002:c058:6301:: as the default IPv6 router address for a 6to4 site.
路由器6to4假定6to4路由器和中继将被协同管理和配置。特别是，6to4站点需要配置一个愿意承载其出站流量的中继路由器，该路由器将成为其默认IPv6路由器（除了2002:：/16）。[RFC3068]中定义的选播变体的目标是避免对此类配置的任何需要。其目的是为小型或家庭用户提供该解决方案，即使是那些拥有单一主机或简单家庭网关而不是边界路由器的用户。通过定义192.88.99.1作为6to4中继的默认IPv4地址，从而定义2002:c058:6301:：作为6to4站点的默认IPv6路由器地址，可以非常简单地实现这一点。
Since Anycast 6to4 implies a default configuration for the user site, it does not require any particular user action. It does require an IPv4 anycast route to be in place to a relay at 192.88.99.1. As with Router 6to4, there is no requirement that the return path goes through the same relay.
由于Anycast 6to4意味着用户站点的默认配置，因此它不需要任何特定的用户操作。它确实需要一个IPv4选播路由来连接192.88.99.1的中继。与路由器6to4一样，不要求返回路径通过相同的中继。
It should be noted that Router 6to4 was not designed to be an unmanaged solution. Quite the contrary: RFC 3056 contains a number of operational recommendations intended to avoid routing issues. In practice, there are few if any deployments of Router 6to4 following these recommendations. Mostly, Anycast 6to4 has been deployed. In this case, the user site (either a single host or a small broadband gateway) discovers that it doesn't have native IPv6 connectivity, but that it does have a global IPv4 address and can resolve AAAA queries. Therefore, it assumes that it can send 6to4 packets to 192.88.99.1.
应该注意的是，路由器6to4并非设计为非托管解决方案。恰恰相反：RFC 3056包含许多旨在避免路由问题的操作建议。实际上，很少有路由器6to4按照这些建议部署。大多数情况下，已经部署了Anycast 6to4。在这种情况下，用户站点（单个主机或小型宽带网关）发现它没有本机IPv6连接，但它有一个全局IPv4地址，可以解析AAAA查询。因此，它假设它可以向192.88.99.1发送6到4个数据包。
Empirically, 6to4 appears to suffer from a significant level of connection failure; see [Aben] and [Huston-a]. In experiments conducted on a number of dual-stack web servers, the TCP connection failure rate has been measured. In these experiments, the client's connection attempt to a server was considered to have failed when the server received a TCP SYN packet and sent a SYN/ACK packet in response, but received no ACK packet to complete the initial TCP three-way handshake. The experiment conducted by Aben recorded a failure rate of between 9% and 20% of all 6to4 connection attempts. The experiment conducted by Huston has recorded a failure rate of between 9% and 19% of all 6to4 clients. In this latter experiment, it was further noted that between 65% to 80% of all 6to4 clients who failed to connect using 6to4 were able to make a successful connection using IPv4, while the remainder did not make any form of IPv4 connection attempt, successful or otherwise, using the mapped IPv4 address as a source address. No connection attempts using embedded RFC 1918 IPv4 addresses were recorded by the server.
从经验上看，6to4似乎遭受了严重的连接故障；参见[Aben]和[Huston-a]。在一些双栈web服务器上进行的实验中，测量了TCP连接失败率。在这些实验中，当服务器收到TCP SYN数据包并发送SYN/ACK数据包作为响应，但没有收到ACK数据包以完成初始TCP三方握手时，客户端与服务器的连接尝试被视为失败。Aben进行的实验记录了所有6to4连接尝试的失败率在9%到20%之间。Huston进行的实验记录了所有6to4客户端的故障率在9%到19%之间。在后一个实验中，进一步注意到，使用6to4连接失败的所有6to4客户端中，有65%到80%能够使用IPv4成功连接，而其余的客户端则没有使用映射的IPv4地址作为源地址进行任何形式的IPv4连接尝试，无论成功与否。服务器未记录使用嵌入式RFC 1918 IPv4地址的连接尝试。
There have been several possible reasons offered for this form of 6to4 connection failure. One is the use of private IPv4 addresses embedded in the 6to4 address, making the return path for the 6to4 tunnel infeasible, and the second is the use of local filters and firewalls that drop incoming IP packets that use IP protocol 41. If the former case were prevalent, it would be reasonable to expect that a significant proportion of failed 6to4 connections would use embedded IPv4 addresses that are either drawn from the private use (RFC 1918) address ranges, contrary to RFC 3056, or from addresses that are not announced in the Internet's IPv4 inter-domain routing table. Neither case was observed to any significant volume in the experiments conducted by Huston. Furthermore, the experimental
对于这种形式的6to4连接故障，有几种可能的原因。一个是使用嵌入在6to4地址中的专用IPv4地址，使得6to4隧道的返回路径不可行，第二个是使用本地筛选器和防火墙丢弃使用IP协议41的传入IP数据包。如果前一种情况很普遍，那么可以合理地预期，大部分失败的6to4连接将使用嵌入式IPv4地址，这些地址要么来自专用（RFC 1918）地址范围，要么来自Internet的IPv4域间路由表中未公布的地址，而非RFC 3056。在休斯顿进行的实验中，两种情况都没有观察到任何显著的体积。此外，还进行了实验研究
conditions were varied to use a return 6to4 tunnel with either the native IPv4 source address of the dual-stack server or an IPv4 source address of 192.88.99.1. No change in the 6to4 connection failure rate was observed between these two configurations; however, other operators have reported significant problems when replying from the native address, caused by stateful firewalls at the user site. Given that the server used its own 6to4 relay for the return path, the only difference in the IP packet itself between the successful IPv4 connections and the failed 6to4 connections was the IP protocol number, which was 6 (TCP) for the successful IPv4 connections and 41 (IPv6 payload) for the failed 6to4 connections. The inference from these experiments is that one likely reason for the high connection failure rate for 6to4 connections is the use of local filters close to the end user that block incoming packets with protocol 41, in some cases made worse by stateful firewalls if the source address is not 192.88.99.1.
条件有所不同，以使用双堆栈服务器的本机IPv4源地址或192.88.99.1的IPv4源地址的返回6to4隧道。在这两种配置之间未观察到6to4连接故障率的变化；但是，其他运营商报告说，从本机地址应答时出现了严重问题，这是由用户站点上的有状态防火墙造成的。考虑到服务器使用自己的6to4中继作为返回路径，成功的IPv4连接和失败的6to4连接之间的IP数据包本身的唯一区别是IP协议号，对于成功的IPv4连接为6（TCP），对于失败的6to4连接为41（IPv6有效负载）。从这些实验得出的结论是，6to4连接的高连接失败率的一个可能原因是使用靠近最终用户的本地过滤器，阻止协议41的传入数据包，在某些情况下，如果源地址不是192.88.99.1，有状态防火墙会使情况变得更糟。
In a dual-stack context, this connection failure rate was effectively masked by the ability of the client system to recover from the failure and make a successful connection using IPv4. In this case, the only effect on the client system was a delay in making the connection of between 7 and 20 seconds as the client's system timed out on the 6to4 connection attempts (see [EYEBALLS-IPV6]).
在双堆栈上下文中，客户端系统能够从故障中恢复并使用IPv4成功连接，从而有效掩盖了此连接失败率。在这种情况下，对客户端系统的唯一影响是连接延迟7到20秒，因为客户端系统在尝试6to4连接时超时（请参见[EYEBALLS-IPV6]）。
This experience, and further analysis, shows that specific operational problems with Anycast 6to4 include:
这一经验以及进一步的分析表明，Anycast 6to4的具体操作问题包括：
1. Outbound Black Hole: 192.88.99.1 does not generate 'destination unreachable' but in fact packets sent to that address are dropped. This can happen due to routing or firewall configuration, or even because the relay that the packets happen to reach contains an ACL such that they are discarded.
1. 出站黑洞：192.88.99.1不会生成“目的地不可到达”，但事实上发送到该地址的数据包会被丢弃。这可能是由于路由或防火墙配置，或者甚至是因为数据包碰巧到达的中继包含ACL，因此它们被丢弃。
This class of problem arises because the user's ISP is accepting a route to 192.88.99.0/24 despite the fact that it doesn't go anywhere useful. Either the user site or its ISP is dropping outbound protocol 41 traffic, or the upstream operator is unwilling to accept incoming 6to4 packets from the user's ISP. The latter is superficially compatible with the design of Router 6to4 (referred to as "unwilling to relay" in RFC 3056). However, the simple fact of announcing a route to 192.88.99.0/24 in IPv4, coupled with the behavior described in RFC 3068, amounts to announcing a default route for IPv6 to all 6to4 sites that receive the IPv4 route. This violates the assumptions of RFC 3056.
这类问题的出现是因为用户的ISP正在接受到192.88.99.0/24的路由，尽管它在任何地方都没有用处。用户站点或其ISP正在丢弃出站协议41通信量，或者上游运营商不愿意接受来自用户ISP的6到4数据包。后者表面上与路由器6to4的设计兼容（在RFC3056中称为“不愿意中继”）。然而，在IPv4中宣布到192.88.99.0/24的路由的简单事实，加上RFC 3068中描述的行为，等于宣布到所有接收IPv4路由的6to4站点的IPv6默认路由。这违反了RFC 3056的假设。
The effect of this problem on users is that their IPv6 stack believes that it has 6to4 connectivity, but in fact all outgoing IPv6 packets are black-holed. The prevalence of this problem is hard to measure, since the resulting IPv6 packets can never be observed from the outside.
这个问题对用户的影响是，他们的IPv6协议栈认为它具有6to4连接，但事实上所有传出的IPv6数据包都是黑洞。这个问题的普遍程度很难衡量，因为由此产生的IPv6数据包永远无法从外部观察到。
2. Inbound Black Hole: In this case, 6to4 packets sent to 192.88.99.1 are correctly delivered to a 6to4 relay, and reply packets are returned, but they are dropped by an inbound protocol 41 filter. As far as the user is concerned, the effect is the same as the previous case: IPv6 is a black hole. Many enterprise networks are believed to be set up in this way. Connection attempts due to this case can be observed by IPv6 server operators, in the form of SYN packets from addresses in 2002::/16 followed by no response to the resulting SYN/ACK. From the experiments cited above, this appears to be a significant problem in practice.
2. 入站黑洞：在这种情况下，发送到192.88.99.1的6to4数据包被正确地传递到6to4中继，回复数据包被返回，但它们被入站协议41过滤器丢弃。就用户而言，其效果与前一种情况相同：IPv6是一个黑洞。许多企业网络被认为是以这种方式建立的。IPv6服务器运营商可以观察到由于这种情况而导致的连接尝试，其形式为来自2002年地址的SYN数据包：：/16，随后对生成的SYN/ACK没有响应。从上面引用的实验来看，这在实践中似乎是一个重大问题。
This problem is complicated by three variables: the firewall applying the protocol 41 filter may be stateless or stateful; the relay may source its packets from its native IPv4 address or from 192.88.99.1; packets from the relay may be subject to IPv4 ingress filtering. If the protocol 41 filter is stateless, 6to4 will never succeed. If it is stateful, the firewall will drop inbound packets from addresses that have not been seen in outbound traffic on the same port. In this case, 6to4 will only succeed if the packets are sourced from 192.88.99.1. If the relay is subject to ingress filtering, only packets from its native IPv4 address can be transmitted. Therefore, there are only three combinations that can succeed:
这个问题因三个变量而变得复杂：应用协议41过滤器的防火墙可能是无状态的或有状态的；中继可从其本机IPv4地址或192.88.99.1获取其数据包的来源；来自中继的数据包可能受到IPv4入口过滤的影响。如果协议41筛选器是无状态的，6to4将永远不会成功。如果是有状态的，防火墙将从同一端口的出站流量中未看到的地址丢弃入站数据包。在这种情况下，只有当数据包来自192.88.99.1时，6to4才会成功。如果中继受到入口过滤，则只能传输来自其本机IPv4地址的数据包。因此，只有三种组合可以成功：
1. No protocol 41 filter, with the relay using its native IPv4 source address.
1. 没有协议41筛选器，中继使用其本机IPv4源地址。
2. No protocol 41 filter, with the relay using the anycast IPv4 source address and with no ingress filter.
2. 没有协议41筛选器，中继使用选播IPv4源地址，没有入口筛选器。
3. A stateful protocol 41 firewall, with the relay using the anycast IPv4 source address and with no ingress filter.
3. 有状态协议41防火墙，中继使用选播IPv4源地址，没有入口过滤器。
3. No Return Relay: If the Outbound Black Hole problem does not occur, i.e., the outgoing packet does reach the intended native IPv6 destination, the target system will send a reply packet, to 2002:c000:2aa::123 in our example above. Then, 2002::/16 may or may not be successfully routed. If it is not routed, the packet will be dropped (hopefully, with 'destination unreachable'). According to RFC 3056, an unwilling relay "MUST NOT advertise any 2002:: routing prefix into the native IPv6 domain"; therefore,
3. 无返回中继：如果出站黑洞问题没有发生，即出站数据包确实到达了预期的本机IPv6目的地，目标系统将发送一个回复数据包，发送到上面示例中的2002:c000:2aa:：123。然后，2002:：/16可能会成功路由，也可能不会成功路由。如果没有路由，数据包将被丢弃（希望是“无法到达目的地”）。根据RFC3056，不情愿的中继“不得向本机IPv6域播发任何2002:：路由前缀”；因此
conversely, if this prefix is advertised the relay must relay packets regardless of source and destination. However, in practice, the problem arises that some relays reject packets that they should relay, based on their IPv6 source address.
相反，如果播发此前缀，则中继必须中继数据包，而不考虑源和目的地。然而，在实践中，出现的问题是，一些中继根据其IPv6源地址拒绝它们应该中继的数据包。
Whether the native IPv6 destination has no route to 2002::/16 or it turns out to have a route to an unwilling relay, the effect is the same: all return IPv6 packets are black-holed. While there is no direct evidence of the prevalence of this problem, it certainly exists in practice.
无论本机IPv6目的地是否没有到2002:：/16的路由，或者结果是有到不愿意的中继的路由，其效果都是相同的：所有返回的IPv6数据包都是黑色的。虽然没有直接证据表明这一问题普遍存在，但在实践中确实存在。
4. Large RTT: In the event that none of the above three problems applies, and a two-way path does in fact exist between a 6to4 host and a native host, the round-trip time may be quite large and variable since the paths to the two relays are unmanaged and may be complex. Overloaded relays might also cause highly variable RTT.
4. 大型RTT：如果上述三个问题均不适用，并且6to4主机和本机主机之间确实存在双向路径，则往返时间可能非常大且多变，因为到两个继电器的路径是非托管的且可能很复杂。过载继电器也可能导致RTT高度可变。
5. PMTUD Failure: A common link MTU size observed on the Internet today is 1500 bytes. However, when using 6to4, the path MTU is less than this due to the encapsulation header. Thus, a 6to4 client will normally see a link MTU that is less than 1500, but a native IPv6 server will see 1500. It has been observed that Path MTU Discovery (PMTUD) does not always work, and this can lead to connectivity failures. Even if a TCP SYN/ACK exchange works, TCP packets with full-size payloads may simply be lost. This problem is apparently exacerbated in some cases by failure of the TCP Maximum Segment Size (MSS) negotiation mechanism [RFC2923]. These failures are disconcerting even to an informed user, since a standard 'ping' from the client to the server will succeed, because it generates small packets, and the successful SYN/ACK exchange can be traced. Also, the failure may occur on some paths but not others, so a user may be able to fetch web pages from one site, but only ping another.
5. PMTUD故障：目前在Internet上观察到的常见链路MTU大小为1500字节。但是，当使用6to4时，由于封装头，路径MTU小于此值。因此，6to4客户端通常会看到链路MTU小于1500，但本机IPv6服务器会看到1500。据观察，路径MTU发现（PMTUD）并不总是有效，这可能导致连接故障。即使TCP SYN/ACK交换工作，具有全尺寸有效负载的TCP数据包也可能会丢失。在某些情况下，TCP最大段大小（MSS）协商机制[RFC2923]的失败明显加剧了该问题。这些故障甚至会让知情用户感到不安，因为从客户端到服务器的标准“ping”会成功，因为它会生成小数据包，并且可以跟踪成功的SYN/ACK交换。此外，故障可能发生在某些路径上，但不会发生在其他路径上，因此用户可以从一个站点获取网页，但只能ping另一个站点。
Additionally, there is a problem if 6to4 is enabled on a router and it advertises the resulting prefix on a LAN, but does not also advertise a smaller MTU; in this case, TCP MSS negotiation will definitely fail.
此外，如果在路由器上启用6to4，并且它在局域网上公布结果前缀，但不公布较小的MTU，则存在问题；在这种情况下，TCP MSS协商肯定会失败。
6. Reverse DNS Failure: Typically, a 6to4-addressed host will not have a reverse DNS delegation. If reverse DNS is used as a pseudo-security check, it will fail.
6. 反向DNS失败：通常情况下，6to4寻址主机不会有反向DNS委派。如果将反向DNS用作伪安全检查，它将失败。
7. Bogus Address Failure: By design, 6to4 does not work and will not activate itself if the available V4ADDR is a private address [RFC1918]. However, it will also not work if the available V4ADDR is a "bogon", i.e., a global address that is being used by
7. 伪地址故障：根据设计，如果可用的V4ADDR是一个专用地址，6to4将不工作，并且不会自动激活[RFC1918]。但是，如果可用的V4ADDR是一个“bogon”，即一个正在被使用的全局地址，那么它也将不起作用
the operator as a private address. A common case of this is a legacy wireless network using 1.1.1.0/24 as if it was a private address. In this case, 6to4 will assume it is connected to the global Internet, but there is certainly no working return path.
作为私人地址的操作员。这种情况的一种常见情况是使用1.1.1.0/24的传统无线网络，就像它是一个专用地址一样。在这种情况下，6to4将假定它已连接到全球互联网，但肯定没有工作返回路径。
This failure mode will also occur if an ISP is operating a Carrier Grade NAT [CGN] between its customers and the Internet, and is using global public address space as if it were private space to do so.
如果ISP在其客户和Internet之间运行运营商级NAT[CGN]，并且使用全局公共地址空间，如同使用私有空间一样，也会出现这种故障模式。
8. Faulty 6to4 Implementations: It has been reported that some 6to4 implementations attempt to activate themselves even when the available IPv4 address is an RFC 1918 address. This is in direct contradiction to RFC 3056, and will produce exactly the same failure mode as Bogus Address Failure. It is of course outside the ISP's control.
8. 错误的6to4实现：据报道，即使可用的IPv4地址是RFC1918地址，某些6to4实现也会尝试自行激活。这与RFC3056直接矛盾，并将产生与伪地址故障完全相同的故障模式。当然，这不在ISP的控制范围之内。
9. Difficult Fault Diagnosis: The existence of all the above failure modes creates a problem of its own: very difficult fault diagnosis, especially if the only symptom reported by a user is slow access to web pages, caused by a long timeout before fallback to IPv4. Tracking down anycast routing problems and PMTUD failures is particularly hard.
9. 故障诊断困难：上述所有故障模式的存在本身就产生了一个问题：非常困难的故障诊断，特别是当用户报告的唯一症状是网页访问缓慢时，这是由于回退到IPv4之前的长时间超时造成的。追踪选播路由问题和PMTUD故障尤其困难。
The practical impact of the above problems, which are by no means universal as there is considerable successful use of Anycast 6to4, has been measured at a fraction of 1% loss of attempted connections to dual-stack content servers [Anderson]. This is because a small fraction of client hosts attempt to connect using 6to4, and up to 20% of these experience one of the above failure modes. While this seems low, it amounts to a significant financial impact for content providers. Also, end users frustrated by the poor response times caused by fallback to IPv4 connectivity [EYEBALLS-IPV6] are considered likely to generate help-desk calls with their attendant costs.
上述问题的实际影响并不具有普遍性，因为Anycast 6to4的使用相当成功，已在尝试连接到双堆栈内容服务器时损失1%的一小部分进行了测量[Anderson]。这是因为一小部分客户机主机尝试使用6to4进行连接，其中高达20%的主机会遇到上述故障模式之一。虽然这似乎很低，但对内容提供商而言，这相当于一个重大的财务影响。此外，最终用户因IPv4连接回退[EYEBALLS-IPV6]导致响应时间差而感到沮丧，他们可能会以相应的成本拨打服务台电话。
A rather different operational problem caused incidentally by 6to4 is that, according to observations made at the University of Southampton by Tim Chown and James Morse, and at other sites, rogue Router Advertisements [RFC6104] often convey a 2002::/16 prefix. This appears to be due to misbehavior by devices acting as local IPv6 routers or connection-sharing devices but issuing Router Advertisement (RA) messages on the wrong interface. Such a device, if it obtains IPv6 connectivity via an upstream link to the Internet, should only issue the corresponding RA messages on its downstream link to the nodes intended to share its Internet connection. Issuing RA messages on the upstream link will perturb any other IPv6 hosts on
6to4附带的一个相当不同的操作问题是，根据Tim Chown和James Morse在南安普敦大学所做的观察，以及在其他站点，流氓路由器广告[RFC6104]经常传达2002：：/ 16前缀。这似乎是由于作为本地IPv6路由器或连接共享设备的设备行为不当，但在错误的接口上发出路由器广告（RA）消息。如果这样的设备通过到Internet的上游链路获得IPv6连接，则只应在其下游链路上向打算共享其Internet连接的节点发出相应的RA消息。在上行链路上发出RA消息将干扰上的任何其他IPv6主机
that link. If 6to4 routing is enabled by default on a device that exhibits this faulty behavior, the resulting rogue RA messages will indeed convey a 2002::/16 prefix.
这一联系。如果在显示此错误行为的设备上默认启用6to4路由，则生成的rogue RA消息将确实传递一个2002:：/16前缀。
There are several types of operator involved, willingly or unwillingly, in the Anycast 6to4 scenario and they will all suffer if things work badly. To avoid operational problems and customer dissatisfaction, there is a clear incentive for each of them to take appropriate action, as described below.
在Anycast 6to4场景中，有几种类型的操作员参与其中，不管是自愿的还是不自愿的，如果情况不好，他们都会受到影响。为了避免运营问题和客户不满，他们每个人都有明确的动机采取适当的行动，如下所述。
This document avoids formal normative language, because it is highly unlikely that the guidelines apply universally. Each operator will make its own decisions about which of the following guidelines are useful in its specific scenario.
本文件避免使用正式的规范性语言，因为指南不太可能普遍适用。每个运营商将自行决定以下哪项准则在其特定场景中有用。
Although this document is aimed principally at operators, there are some steps that implementers and vendors of 6to4 should take.
尽管本文档主要针对运营商，但6to4的实施者和供应商应该采取一些步骤。
1. Some vendors of routers, including customer premises equipment, have not only included support for 6to4 in their products, but have enabled it by default. This is bad practice - it should always be a conscious decision by a user to enable 6to4. Many of the above problems only occur due to unintentional deployment of 6to4.
1. 一些路由器供应商，包括客户场所设备，不仅在其产品中包含对6to4的支持，而且在默认情况下启用了6to4。这是一种糟糕的做法-启用6to4应该始终是用户有意识的决定。上述许多问题都是由于无意中部署了6to4造成的。
2. Similarly, host operating systems should not enable Anycast 6to4 by default; it should always be left to the user to switch it on.
2. 类似地，主机操作系统默认情况下不应启用Anycast 6to4；它应该总是留给用户来打开。
3. Any 6to4 implementation that attempts to activate itself when the available IPv4 address is an RFC 1918 address is faulty and needs to be updated.
3. 当可用IPv4地址为RFC 1918地址时，任何尝试自行激活的6to4实现都有故障，需要更新。
4. 6to4 implementations should adopt updated IETF recommendations on address selection [RFC3484-REVISE].
4. 6to4实施应采用更新的IETF地址选择建议[RFC3484-REVIDE]。
5. 6to4 relay implementations must carefully follow Section 3.2 of [RFC4213] to ensure correct handling of MTU issues.
5. 6to4继电器的实施必须仔细遵守[RFC4213]第3.2节，以确保正确处理MTU问题。
6. 6to4 router or connection-sharing implementations must avoid issuing rogue RAs [RFC6104]. Additionally, where 6to4 is being enabled by a node for Internet-connection-sharing purposes, and the node supports [RFC4191], then it should set the Router Advertisement router preference bits to 11 (low preference).
6. 6to4路由器或连接共享实现必须避免发出恶意RAs[RFC6104]。此外，如果节点出于互联网连接共享目的启用6to4，并且该节点支持[RFC4191]，则应将路由器广告路由器首选项位设置为11（低首选项）。
4.2. Consumer ISPs, and Enterprise Networks, That Do Not Support IPv6 in Any Way
4.2. 以任何方式不支持IPv6的消费者ISP和企业网络
To reduce the negative impact of Anycast 6to4 deployed (probably unknowingly) by users, and consequent user dissatisfaction and help-desk calls, such ISPs should check in sequence:
为了减少用户（可能是无意中）部署的Anycast 6to4的负面影响，以及由此产生的用户不满和服务台呼叫，此类ISP应按顺序检查：
1. Does the ISP have a route to 192.88.99.1? (This means an explicit route, or knowledge that the default upstream provider has an explicit route. A default route doesn't count!)
1. ISP是否有到192.88.99.1的路由？（这意味着一个显式路由，或者知道默认上游提供程序有一个显式路由。默认路由不算数！）
2. If so, is it functional and stable?
2. 如果是的话，它的功能是否稳定？
3. If so, is the ping time reasonably short?
3. 如果是，ping时间是否合理地短？
4. If so, does the relay willingly accept 6to4 traffic from the ISP's IPv4 prefixes? (Note that this is an administrative as well as a technical question -- is the relay's operator willing to accept the traffic?)
4. 如果是这样，中继是否愿意接受来自ISP IPv4前缀的6to4流量？（注意，这既是一个管理问题，也是一个技术问题——继电器的操作员是否愿意接受流量？）
Unless the answer to all these questions is 'yes', the operator should consider blocking the route to 192.88.99.1 and generating an IPv4 'destination unreachable' message. This may cause some 6to4 implementations to fall back to IPv4 more quickly. There is little operational experience with this, however.
除非所有这些问题的答案是“是”，否则操作员应该考虑将路由阻塞到192.88991，并生成IPv4“目的地不可达”消息。这可能会导致一些6to4实现更快地退回到IPv4。然而，这方面的操作经验很少。
Some implementations also perform some form of 6to4 relay qualification. For example, one host implementation (Windows) tests the protocol 41 reachability by sending an ICMPv6 echo request with Hop Limit = 1 to the relay, expecting a response or Hop Limit exceeded error back. Lack of any response indicates that the 6to4 relay does not work so 6to4 is turned off [Savola].
一些实现还执行某种形式的6to4中继鉴定。例如，一个主机实现（Windows）通过向中继器发送跃点限制为1的ICMPv6回显请求来测试协议41的可达性，期望返回响应或跃点限制超出错误。没有任何响应表明6to4继电器不工作，因此6to4关闭[Savola]。
A more constructive approach for such an ISP is to seek out a transit provider who is indeed willing to offer outbound 6to4 relay service, so that the answer to each of the questions above is positive.
对于这样的ISP来说，一个更具建设性的方法是寻找一个确实愿意提供出站6to4中继服务的公交服务提供商，这样上述每个问题的答案都是肯定的。
ISPs in this class should always allow protocol 41 through their network and firewalls. Not only is this a necessary condition for 6to4 to work, but it also allows users who want to use a configured IPv6 tunnel service to do so.
此类ISP应始终允许协议41通过其网络和防火墙。这不仅是6to4工作的必要条件，而且还允许希望使用已配置IPv6隧道服务的用户这样做。
Some operators, particularly enterprise networks, silently block protocol 41 on security grounds. Doing this on its own is bad practice, since it contributes to the problem and harms any users who are knowingly or unknowingly attempting to run 6to4. The strategic solution is to deploy native IPv6, making protocol 41 redundant. In the short term, experimentation could be encouraged by allowing protocol 41 for certain users, while returning appropriate ICMP responses as mentioned above. Unfortunately, if this is not done, the 6to4 problem cannot be solved.
一些运营商，特别是企业网络，出于安全考虑，悄悄地阻止了协议41。单独这样做是不好的做法，因为这会导致问题的出现，并且会伤害任何有意或无意尝试运行6to4的用户。战略解决方案是部署本机IPv6，使协议41冗余。在短期内，可以通过允许某些用户使用协议41来鼓励实验，同时返回上述适当的ICMP响应。不幸的是，如果不这样做，6to4问题就无法解决。
Operators should never use "bogon" address space such as the example of 1.1.1.0/24 for customers, since IPv4 exhaustion means that all such addresses are likely to be in real use in the near future. (Also, see [RFC6269].) An operator that is unable to immediately drop this practice should ensure that 192.88.99.1 generates IPv4 'destination unreachable'. It has been suggested that they could also run a dummy 6to4 relay at that address which always returns ICMPv6 'destination unreachable' as a 6to4 packet. However, these techniques are not very effective, since most current end-user 6to4 implementations will ignore them.
运营商不应使用“bogon”地址空间，如客户使用的1.1.1.0/24示例，因为IPv4耗尽意味着所有此类地址都可能在不久的将来实际使用。（另请参见[RFC6269]）无法立即放弃此做法的运营商应确保192.88.99.1生成IPv4“目标不可访问”。有人建议，他们也可以在该地址运行一个虚拟6to4中继，该地址总是以6to4数据包的形式返回ICMPv6“destination unreachable”。然而，这些技术不是很有效，因为大多数当前的终端用户6to4实现都会忽略它们。
If an operator is providing legitimate global addresses to customers (neither RFC 1918 nor bogon addresses), and also running Carrier Grade NAT (Large Scale NAT) between this address space and the global address space of the Internet, then 6to4 cannot work properly. Such an operator should also take care to return 'destination unreachable' for 6to4 traffic. Alternatively, they could offer untranslated address space to the customers concerned.
如果运营商向客户提供合法的全局地址（既不是RFC 1918也不是bogon地址），并且在该地址空间和Internet的全局地址空间之间运行运营商级NAT（大规模NAT），则6to4无法正常工作。此类运营商还应注意返回6to4流量的“无法到达目的地”。或者，他们可以向相关客户提供未翻译的地址空间。
A customer who is intentionally using 6to4 may also need to create AAAA records, and the operator should be able to support this, even if the DNS service itself runs exclusively over IPv4. However, customers should be advised to consider carefully whether their 6to4 service is sufficiently reliable for this.
有意使用6to4的客户可能还需要创建AAAA记录，即使DNS服务本身专门通过IPv4运行，运营商也应该能够支持这一点。然而，应该建议客户仔细考虑他们的6to4服务是否足够可靠。
Operators could, in principle, offer reverse DNS support for 6to4 users [RFC5158], although this is not straightforward for domestic customers.
原则上，运营商可以为6to4用户提供反向DNS支持[RFC5158]，尽管这对于国内客户来说并不简单。
Paradoxically, operators in this category should consider whether they need to defend themselves against rogue IPv6 RA messages [RFC6105], since such messages may appear from devices seeking to
自相矛盾的是，在这一类中的操作员应该考虑他们是否需要保护自己免受盗取IPv6 RA消息[RCF6105]，因为这样的消息可能出现于寻求
operate as 6to4 routers and confuse any user devices with IPv6 enabled by default. Eventually, the measures being designed by the IETF Source Address Validation Improvement (SAVI) working group will assist with this problem. In the short term, IPv4-only operators may choose to filter out packets with the IPv6 Ethertype (0x86DD) in their access equipment; this will definitively remove rogue RA packets.
作为6to4路由器运行，并将默认启用IPv6的任何用户设备混淆。最终，IETF源地址验证改进（SAVI）工作组正在设计的措施将有助于解决这个问题。在短期内，仅IPv4的运营商可以选择在其接入设备中过滤出具有IPv6以太网类型（0x86DD）的数据包；这将最终删除恶意RA数据包。
Enterprise operators who have complete administrative control of all end systems may choose to disable 6to4 in those systems as an integral part of their plan to deploy IPv6.
对所有终端系统具有完全管理控制权的企业运营商可以选择在这些系统中禁用6to4，作为其部署IPv6计划的一个组成部分。
Some IPv4 operators have chosen to install a 6to4 relay, connected via an IPv6-in-IPv4 tunnel to an IPv6 operator, as a first step before native IPv6 deployment. The routing guidelines in Section 4.4 would apply. However, offering genuine IPv6 service to interested customers, even if tunneled, would generally be a better first step.
一些IPv4运营商选择安装6to4中继，通过IPv4中的IPv6隧道连接到IPv6运营商，作为部署本机IPv6之前的第一步。第4.4节中的路线指南将适用。然而，向感兴趣的客户提供真正的IPv6服务（即使是隧道式的），通常是更好的第一步。
Once an operator does support IPv6 service, whether experimentally or in production, it is almost certain that users will get better results using this service than by continuing to use 6to4. Therefore, these operators are encouraged to advise their users to disable 6to4 and they should not create DNS records for any 6to4 addresses.
一旦运营商确实支持IPv6服务，无论是实验性的还是生产性的，几乎可以肯定的是，用户使用该服务将比继续使用6to4获得更好的结果。因此，鼓励这些运营商建议其用户禁用6to4，并且不应为任何6to4地址创建DNS记录。
Such an operator may automatically fall into one of the following two categories (transit provider or content provider), so the guidelines in Sections 4.4 or 4.5 will apply instead.
此类运营商可能自动分为以下两类（运输提供商或内容提供商），因此第4.4节或第4.5节中的指南将适用。
Operators in this category should make sure that no routers are unintentionally or by default set up as active 6to4 relays. Unmanaged 6to4 relays will be a source of problems.
该类别的操作员应确保没有无意中或默认情况下将路由器设置为活动6to4中继。未管理的6to4继电器将是问题的根源。
Operators in this category should consider whether they need to defend themselves against rogue RA messages with an RA Guard solution [RFC6105]. If RA Guard is not available, it may help in some cases if at least one legitimate IPv6 router per LAN supports [RFC4191] and sets the Router Advertisement router preference bits to 01 (high preference). Eventually, the measures being designed by the IETF Source Address Validation Improvement (SAVI) working group will assist with this problem.
在这一类中的操作员应该考虑他们是否需要用RA防护解决方案[RCF6105]来保护自己免受恶意RA消息的攻击。如果RA Guard不可用，则在某些情况下，如果每个LAN至少有一个合法IPv6路由器支持[RFC4191]，并将路由器广告路由器首选项位设置为01（高首选项），可能会有所帮助。最终，IETF源地址验证改进（SAVI）工作组正在设计的措施将有助于解决这个问题。
We assume that transit ISPs have IPv6 connectivity. To reduce the negative impact of Anycast 6to4 on all their client networks, it is strongly recommended that they each run an Anycast 6to4 relay service. This will have the additional advantage that they will terminate the 6to4 IPv4 packets and can then forward the decapsulated IPv6 traffic according to their own policy. Otherwise, they will blindly forward all the encapsulated IPv6 traffic to a competitor who does run a relay.
我们假设中转ISP具有IPv6连接。为了减少Anycast 6to4对其所有客户端网络的负面影响，强烈建议他们各自运行Anycast 6to4中继服务。这将具有额外的优势，即他们将终止6to4 IPv4数据包，然后可以根据自己的策略转发解除封装的IPv6流量。否则，他们将盲目地将所有封装的IPv6流量转发给运行中继的竞争对手。
Although most modern Internet Exchange Points do not offer IP layer services, an Internet exchange point (IXP) could choose to operate an Anycast 6to4 relay service for the benefit of its customers. If so, it should follow the recommendations in this section.
尽管大多数现代互联网交换点不提供IP层服务，但互联网交换点（IXP）可以选择运营选播6to4中继服务，以造福其客户。如果是，则应遵循本节中的建议。
It is of critical importance that routing to this service is carefully managed:
仔细管理到此服务的路由至关重要：
1. The IPv4 prefix 192.88.99.0/24 must be announced only towards client IPv4 networks whose outbound 6to4 packets will be accepted.
1. IPv4前缀192.88.99.0/24必须仅向其出站6to4数据包将被接受的客户端IPv4网络宣布。
2. The IPv6 prefix 2002::/16 must be announced towards native IPv6. The relay must accept all traffic towards 2002::/16 that reaches it, so the scope reached by this announcement should be carefully planned. It must reach all client IPv6 networks of the transit ISP. If it reaches a wider scope, the relay will be offering a free ride to non-clients.
2. IPv6前缀2002:：/16必须向本机IPv6宣布。中继必须接受2002:：/16之前到达它的所有通信量，因此应仔细规划此公告达到的范围。它必须到达传输ISP的所有客户端IPv6网络。如果范围更广，中继将为非客户提供免费服务。
3. As discussed in item 2 of Section 3, the choice of IPv4 source address used when the relay sends 6to4 packets back towards a 6to4 user is important. The best choice is likely to be 192.88.99.1, not the relay's unicast IPv4 address, unless ingress filtering is an issue. This is to avoid failure if the user is behind a stateful firewall.
3. 如第3节第2项所述，中继向6to4用户发送6to4数据包时使用的IPv4源地址的选择非常重要。最好的选择可能是192.88.99.1，而不是中继的单播IPv4地址，除非存在入口过滤问题。这是为了避免用户位于有状态防火墙后面时发生故障。
4. The relay should be capable of responding correctly to ICMPv6 echo requests encapsulated in IPv4 protocol 41, typically with outer destination address 192.88.99.1 and inner destination address 2002:c058:6301::. (As noted previously, some 6to4 hosts are known to send echo requests with Hop Limit = 1, which allows them to rapidly detect the presence or absence of a relay in any case, but operators cannot rely on this behavior.)
4. 中继应该能够正确响应IPv4协议41中封装的ICMPv6回显请求，通常外部目标地址为192.88.99.1，内部目标地址为2002:c058:6301:：。（如前所述，已知一些6to4主机发送跃点限制为1的回显请求，这允许它们在任何情况下快速检测是否存在中继，但运营商不能依赖此行为。）
5. Protocol 41 must not be filtered in any IPv4 network or firewalls.
5. 不得在任何IPv4网络或防火墙中过滤协议41。
6. As a matter of general practice, which is essential for 6to4 to work well, IPv6 PMTUD must be possible, which means that ICMPv6 must not be blocked anywhere [RFC4890]. This also requires that the relay has a sufficiently high ICMP error generation threshold. For a busy relay, a typical default rate limit of 100 packets per second is too slow. On a busy relay, 1000 pps or more might be needed. If ICMPv6 "Packet Too Big" error messages are rate limited, users will experience PMTUD failure.
6. 作为一种常规做法，这对于6to4的正常运行至关重要，IPv6 PMTUD必须是可能的，这意味着ICMPv6不能在任何地方被阻止[RFC4890]。这还要求中继器具有足够高的ICMP错误生成阈值。对于忙中继，每秒100个数据包的典型默认速率限制太慢。在忙中继上，可能需要1000 pps或更多。如果ICMPv6“数据包太大”错误消息的速率受限，用户将遇到PMTUD故障。
7. The relay must have adequate performance, and since load prediction is extremely hard, it must be possible to scale it up or, perhaps better, to replicate it as needed. Since the relay process is stateless, any reasonable method of load sharing between multiple relays will do.
7. 继电器必须具有足够的性能，并且由于负载预测非常困难，因此必须能够扩大其规模，或者根据需要更好地复制它。由于中继过程是无状态的，因此在多个中继之间采用任何合理的负载共享方法都可以。
8. Of course, the relay must be connected directly to global IPv4 space, with no NAT.
8. 当然，中继必须直接连接到全局IPv4空间，而不使用NAT。
Operators in this category should make sure that no routers are unintentionally or by default set up as active 6to4 relays. Unmanaged 6to4 relays will be a source of problems.
该类别的操作员应确保没有无意中或默认情况下将路由器设置为活动6to4中继。未管理的6to4继电器将是问题的根源。
We assume that content providers and their ISPs have IPv6 connectivity, and that the servers are dual stacked. The following applies to content servers as such, but equally to web hosting servers, servers that form part of a content distribution network, load balancers in front of a server farm, and HTTP caches. There is a need to avoid the situation where a client host, configured with Anycast 6to4, succeeds in sending an IPv6 packet to the server, but the 6to4 return path fails as described above. To avoid this, there must be a locally positioned 6to4 relay. Large content providers are advised to operate their own relays, and ISPs should do so in any case. There must be a 2002::/16 route from the content server to the relay. As noted in the previous section, the corresponding route advertisement must be carefully scoped, since any traffic that arrives for 2002::/16 must be relayed.
我们假设内容提供商及其ISP具有IPv6连接，并且服务器是双重堆叠的。以下内容同样适用于内容服务器，但同样适用于web托管服务器、构成内容分发网络一部分的服务器、服务器场前面的负载平衡器和HTTP缓存。需要避免配置了Anycast 6to4的客户端主机成功地向服务器发送IPv6数据包，但6to4返回路径如上所述失败的情况。为了避免这种情况，必须有一个本地定位的6to4继电器。建议大型内容提供商运营自己的中继，ISP在任何情况下都应该这样做。从content server到中继必须有一个2002:：/16路由。如前一节所述，必须仔细确定相应的路线广告的范围，因为2002年到达的任何流量都必须中继：：/16。
Such a relay may be dedicated entirely to return traffic, in which case, it need not respond to the 6to4 anycast address.
这种中继可以完全专用于返回业务，在这种情况下，它不需要响应6to4选播地址。
Nevertheless, it seems wisest to ensure that when the relay sends 6to4 packets back towards a 6to4 user, they should have 192.88.99.1 as their IPv4 source address (not the relay's unicast IPv4 address). As noted above, this is to avoid problems if the user is behind a stateful firewall that drops UDP packets from addresses that have not
然而，最明智的做法似乎是确保当中继将6to4数据包发送回6to4用户时，他们的IPv4源地址应该是192.88.99.1（而不是中继的单播IPv4地址）。如上所述，这是为了避免在用户位于有状态防火墙后面时出现问题，该防火墙会从没有连接的地址丢弃UDP数据包
been seen in outbound traffic. However, it is also necessary that 192.88.99.1 is not blocked by upstream ingress filtering -- this needs to be tested.
在出境交通中可以看到。然而，192.88.99.1也必须不被上游入口过滤阻塞——这需要测试。
Without careful engineering, there is nothing to make the return path as short as possible. It is highly desirable to arrange the scope of advertisements for 2002::/16 such that content providers have a short path to the relay, and the relay should have a short path to the ISP border. Care should be taken about shooting off advertisements for 2002::/16 into BGP4; they will become traffic magnets. If every ISP with content provider customers operates a relay, there will be no need for any of them to be advertised beyond each ISP's own customers.
如果没有仔细的设计，就无法使返回路径尽可能短。非常希望安排2002年的广告范围：：/16，以便内容提供商具有到中继的短路径，并且中继应具有到ISP边界的短路径。应注意拍摄2002年的广告：：/16进入BGP4；它们将成为交通磁石。如果每一个拥有内容提供商客户的ISP都运行一个中继，那么就不需要在每个ISP自己的客户之外宣传任何内容提供商。
Protocol 41 must not be filtered in the ISP's IPv4 network or firewalls. If the relays are placed outside the content provider's firewall, the latter may filter protocol 41 if desired.
不得在ISP的IPv4网络或防火墙中过滤协议41。如果中继被放置在内容提供商的防火墙之外，后者可以根据需要过滤协议41。
The relay must have adequate performance, and since load prediction is extremely hard, it must be possible to scale it up or, perhaps better, to replicate it as needed. Since the relay process is stateless, any reasonable method of load sharing between multiple relays will do.
继电器必须具有足够的性能，并且由于负载预测非常困难，因此必须能够扩大其规模，或者根据需要更好地复制它。由于中继过程是无状态的，因此在多个中继之间采用任何合理的负载共享方法都可以。
The relay must of course be connected directly to global IPv4 space, with no NAT.
当然，中继必须直接连接到全局IPv4空间，而不使用NAT。
An option is to embed the relay function directly in the content server or first hop router. This is straightforward, since it can be achieved by enabling a local 6to4 interface, and using it to route 2002::/16 for outbound packets. (This might not allow use of 192.88.99.1 as the source address.) Further details are to be found at [Huston-b]. However, in this case protocol 41 must be allowed by the firewalls.
一个选项是将中继功能直接嵌入content server或第一跳路由器中。这很简单，因为可以通过启用本地6to4接口并使用它路由出站数据包的2002:：/16来实现。（这可能不允许使用192.88.99.1作为源地址。）更多详细信息请参见[Huston-b]。然而，在这种情况下，防火墙必须允许协议41。
Content providers who do embed the relay function in this way could, in theory, accept inbound 6to4 traffic as well. This is highly unadvisable since, according to the rules of 6to4, they would then have to relay traffic for other IPv6 destinations, too. So they should not be reachable via 192.88.99.1. Also, they should certainly not create an AAAA record for their 6to4 address -- their inbound IPv6 access should be native, and advertising a 6to4 address might well lead to unicast reverse path forwarding (uRPF) [RFC3704] ingress filtering problems.
理论上，以这种方式嵌入中继功能的内容提供商也可以接受入站6to4流量。这是非常不明智的，因为根据6to4的规则，它们还必须将流量中继到其他IPv6目的地。因此，不能通过192.88.99.1访问它们。此外，他们当然不应该为他们的6to4地址创建AAAA记录——他们的入站IPv6访问应该是本机的，公布6to4地址很可能会导致单播反向路径转发（uRPF）[RFC3704]入口过滤问题。
To avoid the path MTU problem described above, content servers should also set their IPv6 MTU to a safe value. From experience, 1280 bytes (the minimum allowed for IPv6) is recommended; again, see [Huston-b].
为避免上述路径MTU问题，内容服务器还应将其IPv6 MTU设置为安全值。根据经验，建议使用1280字节（IPv6允许的最小值）；再次参见[Huston-b]。
Of course, ICMPv6 "Packet Too Big" must not be blocked or rate-limited anywhere [RFC4890].
当然，ICMPv6“数据包太大”不能在任何地方被阻止或限制速率[RFC4890]。
Reverse DNS delegations are highly unlikely to exist for 6to4 clients, and are by no means universal for other IPv6 clients. Content providers (and, in fact, all service providers) should not rely on them as a pseudo-security check for IPv6 clients.
对于6to4客户机，反向DNS委托不太可能存在，对于其他IPv6客户机，反向DNS委托绝不通用。内容提供商（事实上，所有服务提供商）不应依赖它们作为IPv6客户端的伪安全检查。
Operators and content providers should make sure that no routers are unintentionally or by default set up as active 6to4 relays. Unmanaged 6to4 relays will be a source of problems.
运营商和内容提供商应确保没有路由器被无意或默认设置为活动6to4中继。未管理的6to4继电器将是问题的根源。
There are various ways, such as tunnel brokers [RFC3053], 6rd [RFC5969], and Layer 2 Tunneling Protocol version 2 (L2TPv2) hub-and-spoke [RFC5571], by which Internet Service Providers can provide tunneled IPv6 service to subscribers in a managed way, in which the subscriber will acquire an IPv6 prefix under a normal provider-based global IPv6 prefix. Most of the issues described for 6to4 do not arise in these scenarios. However, for IPv6-in-IPv4 tunnels used by clients behind a firewall, it is essential that IPv4 protocol 41 is not blocked.
有多种方式，如隧道代理[RFC3053]、第6rd[RFC5969]和第2层隧道协议版本2（L2TPv2）集线器和分支[RFC5571]，通过这些方式，Internet服务提供商可以以托管方式向订户提供隧道IPv6服务，其中，订户将在基于普通提供商的全局IPv6前缀下获取IPv6前缀。6to4中描述的大多数问题在这些场景中不会出现。但是，对于防火墙后面的客户端使用的IPv6-in-IPv4隧道，IPv4协议41必须不被阻止。
As a matter of general practice, IPv6 PMTUD must be possible, which means that ICMPv6 "Packet Too Big" must not be blocked or rate-limited anywhere [RFC4890].
一般来说，IPv6 PMTUD必须是可能的，这意味着ICMPv6“数据包太大”不能在任何地方被阻止或限制速率[RFC4890]。
There is a general discussion of security issues for IPv6-in-IPv4 tunnels in [RFC6169], and [TUNNEL-LOOPS] discusses possible malicious loops. [RFC3964] specifically discusses 6to4 security. In summary, tunnels create a challenge for many common security mechanisms, simply because a potentially suspect packet is encapsulated inside a harmless outer packet. All these considerations apply to the automatic mechanisms discussed in this document. However, it should be noted that if an operator provides well-managed servers and relays for 6to4, non-encapsulated IPv6 packets will pass through well-defined points (the native IPv6 interfaces of those servers and relays) at which security mechanisms may be applied.
[RFC6169]中对IPv4隧道中IPv6的安全问题进行了一般性讨论，[TUNNEL-LOOPS]讨论了可能的恶意循环。[RFC3964]专门讨论6to4安全性。总之，隧道为许多常见的安全机制带来了挑战，这仅仅是因为潜在的可疑数据包被封装在无害的外部数据包中。所有这些注意事项都适用于本文档中讨论的自动机制。但是，应该注意的是，如果运营商为6to4提供管理良好的服务器和中继，非封装IPv6数据包将通过定义良好的点（这些服务器和中继的本机IPv6接口），在这些点上可以应用安全机制。
A blanket recommendation to block protocol 41 is not compatible with mitigating the 6to4 problems described in this document.
阻止协议41的总体建议与缓解本文件中描述的6to4问题不兼容。
Useful comments and contributions were made by Emile Aben, Mikael Abrahamsson, Tore Anderson, Hermin Anggawijaya, Jack Bates, Cameron Byrne, Tim Chown, Remi Despres, Jason Fesler, Wes George, Philip Homburg, Ray Hunter, Geoff Huston, Eric Kline, Victor Kuarsingh, Martin Levy, David Malone, Alexey Melnikov, Martin Millnert, Keith Moore, Gabi Nakibly, Michael Newbery, Phil Pennock, Pekka Savola, Mark Smith, Nathan Ward, James Woodyatt, and others.
埃米尔·阿本、米凯尔·阿布拉罕松、托尔·安德森、赫敏·安加维贾亚、杰克·贝茨、卡梅隆·伯恩、蒂姆·乔恩、雷米·德斯普雷斯、杰森·费斯勒、韦斯·乔治、菲利普·霍姆伯格、雷·亨特、杰夫·休斯顿、埃里克·克莱恩、维克多·夸辛格、马丁·利维、大卫·马龙、阿列克西·梅尔尼科夫、马丁·米尔内特、基思·摩尔、，Gabi Nakbly、Michael Newbery、Phil Pennock、Pekka Savola、Mark Smith、Nathan Ward、James Woodyatt和其他人。
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001.
[RFC3056]Carpenter，B.和K.Moore，“通过IPv4云连接IPv6域”，RFC 3056，2001年2月。
[RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", RFC 3068, June 2001.
[RFC3068]Huitema，C.，“6to4中继路由器的选播前缀”，RFC3068，2001年6月。
[Aben] Aben, E., "6to4 - How Bad is it Really?", 2010, <ht tps://labs.ripe.net/Members/emileaben/ 6to4-how-bad-is-it-really>.
[Aben]Aben，E.，“6to4-到底有多糟？”，2010，<https://labs.ripe.net/Members/emileaben/ 6到4它到底有多糟糕>。
[Anderson] Anderson, T., "IPv6 dual-stack client loss in Norway", 2010, <http://www.fud.no/ipv6/>.
[Anderson]Anderson，T.，“挪威的IPv6双栈客户端丢失”，2010年<http://www.fud.no/ipv6/>.
[CGN] Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A., and H. Ashida, "Common requirements for Carrier Grade NAT (CGN)", Work in Progress, July 2011.
[CGN]Perreault，S.，Yamagata，I.，Miyakawa，S.，Nakagawa，A.，和H.Ashida，“载体级NAT（CGN）的通用要求”，在建工程，2011年7月。
[DNSWHITE] Livingood, J., "IPv6 AAAA DNS Whitelisting Implications", Work in Progress, June 2011.
[DNSWHITE]Livingood，J.，“IPv6 AAAA DNS白名单的影响”，正在进行的工作，2011年6月。
[EYEBALLS-IPV6] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Trending Towards Success with Dual-Stack Hosts", Work in Progress, October 2010.
[EYEBALLS-IPV6]Wing，D.和A.Yourtchenko，“快乐眼球：双堆栈主机走向成功”，正在进行的工作，2010年10月。
[HISTORIC] Troan, O., "Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status", Work in Progress, June 2011.
[历史]Troan，O.，“请求通过IPv4云（6to4）将IPv6域的连接移动到历史状态”，正在进行的工作，2011年6月。
[Huston-a] Huston, G., "Flailing IPv6", 2010, <http:// www.potaroo.net/ispcol/2010-12/6to4fail.html>.
[Huston-a]Huston，G.，“鞭打IPv6”，2010年，<http://www.potaroo.net/ispcol/2010-12/6to4fail.html>。
[Huston-b] Huston, G., "Two Simple Hints for Dual Stack Servers", 2010, <http://www.potaroo.net/ispcol/ 2010-05/v6hints.html>.
[Huston-b]Huston，G.，“双堆栈服务器的两个简单提示”，2010年<http://www.potaroo.net/ispcol/ 2010-05/v6hints.html>。
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC1918]Rekhter，Y.，Moskowitz，R.，Karrenberg，D.，Groot，G.，和E.Lear，“私人互联网地址分配”，BCP 5，RFC 1918，1996年2月。
[RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", RFC 2923, September 2000.
[RFC2923]Lahey，K.，“路径MTU发现的TCP问题”，RFC 29232000年9月。
[RFC3053] Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6 Tunnel Broker", RFC 3053, January 2001.
[RFC3053]Durand，A.，Fasano，P.，Guardini，I.，和D.Lento，“IPv6隧道代理”，RFC 3053，2001年1月。
[RFC3484-REVISE] Matsumoto, A., Kato, J., Fujisaki, T., and T. Chown, "Update to RFC 3484 Default Address Selection for IPv6", Work in Progress, July 2011.
[RFC3484-修订]Matsumoto，A.，Kato，J.，Fujisaki，T.，和T.Chown，“更新到IPv6的RFC 3484默认地址选择”，正在进行的工作，2011年7月。
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004.
[RFC3704]Baker，F.和P.Savola，“多宿网络的入口过滤”，BCP 84，RFC 37042004年3月。
[RFC3964] Savola, P. and C. Patel, "Security Considerations for 6to4", RFC 3964, December 2004.
[RFC3964]Savola，P.和C.Patel，“6to4的安全考虑”，RFC 3964，2004年12月。
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and More-Specific Routes", RFC 4191, November 2005.
[RFC4191]Draves，R.和D.Thaler，“默认路由器首选项和更具体的路由”，RFC 41912005年11月。
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005.
[RFC4213]Nordmark，E.和R.Gilligan，“IPv6主机和路由器的基本转换机制”，RFC 4213，2005年10月。
[RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering ICMPv6 Messages in Firewalls", RFC 4890, May 2007.
[RFC4890]Davies，E.和J.Mohacsi，“防火墙中过滤ICMPv6消息的建议”，RFC 48902007年5月。
[RFC5158] Huston, G., "6to4 Reverse DNS Delegation Specification", RFC 5158, March 2008.
[RFC5158]Huston，G.，“6to4反向DNS委托规范”，RFC 5158，2008年3月。
[RFC5571] Storer, B., Pignataro, C., Dos Santos, M., Stevant, B., Toutain, L., and J. Tremblay, "Softwire Hub and Spoke Deployment Framework with Layer Two Tunneling Protocol Version 2 (L2TPv2)", RFC 5571, June 2009.
[RFC5571]Storer，B.，Pignataro，C.，Dos Santos，M.，Stevant，B.，Toutain，L.，和J.Tremblay，“具有第二层隧道协议版本2（L2TPv2）的软线中心辐射部署框架”，RFC 55712009年6月。
[RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification", RFC 5969, August 2010.
[RFC5969]Townsley，W.和O.Troan，“IPv4基础设施上的IPv6快速部署（第6条）——协议规范”，RFC 5969，2010年8月。
[RFC6104] Chown, T. and S. Venaas, "Rogue IPv6 Router Advertisement Problem Statement", RFC 6104, February 2011.
[RFC6104]Chown，T.和S.Venaas，“流氓IPv6路由器广告问题声明”，RFC 61042011年2月。
[RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, February 2011.
[RFC6105]Levy Abegnoli，E.，Van de Velde，G.，Popoviciu，C.，和J.Mohacsi，“IPv6路由器广告保护”，RFC 61052011年2月。
[RFC6169] Krishnan, S., Thaler, D., and J. Hoagland, "Security Concerns with IP Tunneling", RFC 6169, April 2011.
[RFC6169]Krishnan，S.，Thaler，D.，和J.Hoagland，“IP隧道的安全问题”，RFC 61692011年4月。
[RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. Roberts, "Issues with IP Address Sharing", RFC 6269, June 2011.
[RFC6269]福特，M.，布卡达尔，M.，杜兰德，A.，利维斯，P.，和P.罗伯茨，“IP地址共享问题”，RFC 6269，2011年6月。
[Savola] Savola, P., "Observations of IPv6 Traffic on a 6to4 Relay", ACM SIGCOMM CCR 35 (1) 23-28, 2006.
[Savola]Savola，P.，“对6to4中继上IPv6流量的观察”，ACM SIGCOMCCR 35（1）23-282006。
[TUNNEL-LOOPS] Nakibly, G. and F. Templin, "Routing Loop Attack using IPv6 Automatic Tunnels: Problem Statement and Proposed Mitigations", Work in Progress, May 2011.
[TUNNEL-LOOPS]Nakbly，G.和F.Templin，“使用IPv6自动隧道的路由环路攻击：问题陈述和建议的缓解措施”，正在进行的工作，2011年5月。
Author's Address
作者地址
Brian Carpenter Department of Computer Science University of Auckland PB 92019 Auckland, 1142 New Zealand
Brian Carpenter奥克兰大学计算机系，奥克兰92019，新西兰1142
EMail: brian.e.carpenter@gmail.com
EMail: brian.e.carpenter@gmail.com