Internet Engineering Task Force (IETF) O. Troan
Request for Comments: 7526 Cisco
BCP: 196 B. Carpenter, Ed.
Obsoletes: 3068, 6732 Univ. of Auckland
Category: Best Current Practice May 2015
ISSN: 2070-1721
Internet Engineering Task Force (IETF) O. Troan
Request for Comments: 7526 Cisco
BCP: 196 B. Carpenter, Ed.
Obsoletes: 3068, 6732 Univ. of Auckland
Category: Best Current Practice May 2015
ISSN: 2070-1721
Deprecating the Anycast Prefix for 6to4 Relay Routers
不推荐6to4中继路由器的选播前缀
Abstract
摘要
Experience with the 6to4 transition mechanism defined in RFC 3056 ("Connection of IPv6 Domains via IPv4 Clouds") has shown that the mechanism is unsuitable for widespread deployment and use in the Internet when used in its anycast mode. Therefore, this document requests that RFC 3068 ("An Anycast Prefix for 6to4 Relay Routers") and RFC 6732 ("6to4 Provider Managed Tunnels") be made obsolete and moved to Historic status. It recommends that future products should not support 6to4 anycast and that existing deployments should be reviewed. This complements the guidelines in RFC 6343.
RFC 3056（“通过IPv4云连接IPv6域”）中定义的6to4转换机制的经验表明，当以选播模式使用时，该机制不适合在Internet中广泛部署和使用。因此，本文件要求将RFC 3068（“6to4中继路由器的选播前缀”）和RFC 6732（“6to4提供商管理的隧道”）作废并移至历史状态。它建议未来的产品不支持6to4选播，并且应该检查现有的部署。这补充了RFC 6343中的指南。
Status of This Memo
关于下段备忘
This memo documents an Internet Best Current Practice.
本备忘录记录了互联网最佳实践。
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). Further information on BCPs is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关BCP的更多信息，请参见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/rfc7526.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7526.
Copyright Notice
版权公告
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2015 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 . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Related Work . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. 6to4 Operational Problems . . . . . . . . . . . . . . . . . . 4
4. Deprecation . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Implementation Recommendations . . . . . . . . . . . . . . . 5
6. Operational Recommendations . . . . . . . . . . . . . . . . . 6
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
8. Security Considerations . . . . . . . . . . . . . . . . . . . 7
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
9.1. Normative References . . . . . . . . . . . . . . . . . . 7
9.2. Informative References . . . . . . . . . . . . . . . . . 8
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Related Work . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. 6to4 Operational Problems . . . . . . . . . . . . . . . . . . 4
4. Deprecation . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Implementation Recommendations . . . . . . . . . . . . . . . 5
6. Operational Recommendations . . . . . . . . . . . . . . . . . 6
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
8. Security Considerations . . . . . . . . . . . . . . . . . . . 7
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
9.1. Normative References . . . . . . . . . . . . . . . . . . 7
9.2. Informative References . . . . . . . . . . . . . . . . . 8
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
The original form of the 6to4 transition mechanism [RFC3056] relies on unicast addressing. However, its extension specified in "An Anycast Prefix for 6to4 Relay Routers" [RFC3068] has been shown to have severe practical problems when used in the Internet. This document requests that RFCs 3068 and 6732 be moved to Historic status, as defined in Section 4.2.4 of [RFC2026]. It complements the deployment guidelines in [RFC6343].
6to4转换机制[RFC3056]的原始形式依赖于单播寻址。然而，在“6to4中继路由器的选播前缀”[RFC3068]中指定的扩展已被证明在互联网中使用时存在严重的实际问题。本文件要求按照[RFC2026]第4.2.4节的规定，将RFCs 3068和6732移至历史状态。它补充了[RFC6343]中的部署指南。
6to4 was designed to help transition the Internet from IPv4 to IPv6. It has been a good mechanism for experimenting with IPv6, but because of the high failure rates seen with anycast 6to4 [HUSTON], end users may end up disabling IPv6 on hosts; this has resulted in some content providers being reluctant to make content available over IPv6 in the past.
6to4旨在帮助互联网从IPv4过渡到IPv6。这是一种很好的IPv6实验机制，但由于anycast 6to4[HUSTON]的高故障率，最终用户可能会在主机上禁用IPv6；这导致一些内容提供商过去不愿意通过IPv6提供内容。
[RFC6343] analyzes the known operational issues in detail and describes a set of suggestions to improve 6to4 reliability, given the widespread presence of hosts and customer premises equipment that support it. The advice to disable 6to4 by default has been widely adopted in recent operating systems, and the failure modes have been widely hidden from users by many browsers adopting the "Happy Eyeballs" approach [RFC6555].
[RFC6343]详细分析了已知的操作问题，并描述了一组建议，以提高6to4的可靠性，因为支持6to4的主机和客户场所设备广泛存在。在最近的操作系统中，默认禁用6to4的建议已被广泛采用，而许多浏览器采用“快乐眼球”方法[RFC6555]，对用户广泛隐藏了故障模式。
Nevertheless, a measurable amount of 6to4 traffic is still observed by IPv6 content providers. The remaining successful users of anycast 6to4 are likely to be on hosts using the obsolete policy table [RFC3484] (which prefers 6to4 above IPv4) and running without Happy Eyeballs. Furthermore, they must have a route to an operational anycast relay and they must be accessing an IPv6 host that has a route to an operational return relay.
尽管如此，IPv6内容提供商仍观察到大量6to4流量。anycast 6to4的其余成功用户可能位于使用过时策略表[RFC3484]（它更喜欢6to4而不是IPv4）的主机上，并且运行时没有令人愉快的眼球。此外，它们必须有一个到操作选播中继的路由，并且必须访问一个有到操作返回中继路由的IPv6主机。
However, experience shows that operational failures caused by anycast 6to4 have continued despite the advice in RFC 6343 being available.
然而，经验表明，尽管RFC 6343中的建议可用，但由选播6to4导致的操作故障仍在继续。
"IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification" [RFC5969] explicitly builds on the 6to4 mechanism, using a service provider prefix instead of 2002::/16. However, the deployment model is based on service provider support such that 6rd avoids the problems observed with anycast 6to4.
“IPv4基础架构上的IPv6快速部署（第6条）--协议规范”[RFC5969]明确构建在6to4机制上，使用服务提供商前缀而不是2002:：/16。但是，部署模型基于服务提供商的支持，这样6rd就可以避免使用anycast 6to4观察到的问题。
The framework for "6to4 Provider Managed Tunnels" [RFC6732] is intended to help a service provider manage 6to4 anycast tunnels. This framework only exists because of the problems observed with anycast 6to4.
“6to4提供商管理的隧道”框架[RFC6732]旨在帮助服务提供商管理6to4选播隧道。此框架的存在只是因为anycast 6to4存在问题。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照RFC 2119[RFC2119]中的说明进行解释。
In this document, the word "deprecate" and its derivatives are used only in their generic sense of "criticize or express disapproval" and do not have any specific normative meaning. A deprecated function might exist in the Internet for many years to allow backwards compatibility.
在本文件中，“deprecate”一词及其派生词仅在“批评或表示不赞成”的一般意义下使用，不具有任何特定的规范含义。一个不推荐使用的函数可能在Internet中存在多年，以允许向后兼容。
6to4 is a mechanism designed to allow isolated IPv6 islands to reach each other using IPv6-over-IPv4 automatic tunneling. To reach the native IPv6 Internet, the mechanism uses relay routers in both the forward and reverse direction. The mechanism is supported in many IPv6 implementations. With the increased deployment of IPv6, the mechanism has been shown to have a number of shortcomings.
6to4是一种机制，旨在允许使用IPv6-over-IPv4自动隧道将孤立的IPv6孤岛相互连接。为了到达本机IPv6 Internet，该机制在正向和反向使用中继路由器。许多IPv6实现都支持该机制。随着IPv6部署的增加，该机制已显示出一些缺点。
In the forward direction, a 6to4 node will send IPv4-encapsulated IPv6 traffic to a 6to4 relay that is connected to both the 6to4 cloud and native IPv6. In the reverse direction, a 2002::/16 route is injected into the native IPv6 routing domain to attract traffic from native IPv6 nodes to a 6to4 relay router. It is expected that traffic will use different relays in the forward and reverse direction.
在转发方向上，6to4节点将向连接到6to4云和本机IPv6的6to4中继发送IPv4封装的IPv6流量。在相反方向上，将2002:：/16路由注入本机IPv6路由域，以将流量从本机IPv6节点吸引到6to4中继路由器。预计交通将在正向和反向使用不同的继电器。
One model of 6to4 deployment, described in Section 5.2 of RFC 3056, suggests that a 6to4 router should have a set of managed connections (via BGP connections) to a set of 6to4 relay routers. While this makes the forward path more controlled, it does not guarantee a functional reverse path. In any case, this model has the same operational burden as manually configured tunnels and has seen no deployment in the public Internet.
RFC 3056第5.2节中描述的一种6to4部署模型建议6to4路由器应具有一组到一组6to4中继路由器的受管连接（通过BGP连接）。虽然这使正向路径更受控制，但不能保证反向路径的功能。在任何情况下，该模型都与手动配置的隧道具有相同的操作负担，并且没有在公共互联网上部署。
RFC 3068 adds an extension that allows the use of a well-known IPv4 anycast address to reach the nearest 6to4 relay in the forward direction. However, this anycast mechanism has a number of operational issues and problems, which are described in detail in Section 3 of [RFC6343]. This document is intended to deprecate the anycast mechanism.
RFC3068添加了一个扩展，该扩展允许使用众所周知的IPv4选播地址到达转发方向上最近的6to4中继。然而，该选播机制存在许多操作问题，这些问题在[RFC6343]的第3节中有详细描述。本文档旨在反对选播机制。
Peer-to-peer usage of the 6to4 mechanism exists in the Internet, likely unknown to many operators. This usage is harmless to third parties and is not dependent on the anycast 6to4 mechanism that this document deprecates.
互联网上存在6to4机制的点对点使用，许多运营商可能不知道。这种用法对第三方无害，并且不依赖于本文档不推荐的anycast 6to4机制。
This document formally deprecates the anycast 6to4 transition mechanism defined in [RFC3068] and the associated anycast IPv4 address 192.88.99.1. It is no longer considered to be a useful service of last resort.
本文档正式反对[RFC3068]中定义的选播6to4转换机制以及相关的选播IPv4地址192.88.99.1。它不再被认为是一种有用的最后手段。
The prefix 192.88.99.0/24 MUST NOT be reassigned for other use except by a future IETF Standards Action.
前缀192.88.99.0/24不得重新分配用于其他用途，除非通过未来的IETF标准行动。
The basic unicast 6to4 mechanism defined in [RFC3056] and the associated 6to4 IPv6 prefix 2002::/16 are not deprecated. The default address selection rules specified in [RFC6724] are not modified.
[RFC3056]中定义的基本单播6to4机制和相关的6to4 IPv6前缀2002:：/16未被弃用。[RFC6724]中指定的默认地址选择规则未修改。
In the absence of 6to4 anycast, "6to4 Provider Managed Tunnels" [RFC6732] will no longer be necessary, so they are also deprecated by this document.
在缺少6to4选播的情况下，“6to4提供者管理的隧道”[RFC6732]将不再是必需的，因此本文档也不推荐使用它们。
Incidental references to 6to4 should be reviewed and possibly removed from other IETF documents if and when they are updated. These documents include RFC 3162, RFC 3178, RFC 3790, RFC 4191, RFC 4213, RFC 4389, RFC 4779, RFC 4852, RFC 4891, RFC 4903, RFC 5157, RFC 5245, RFC 5375, RFC 5971, RFC 6071, and RFC 6890.
对6to4的附带引用应进行审查，并可能在更新时从其他IETF文件中删除。这些文件包括RFC 3162、RFC 3178、RFC 3790、RFC 4191、RFC 4213、RFC 4389、RFC 4779、RFC 4852、RFC 4891、RFC 4903、RFC 5157、RFC 5245、RFC 5375、RFC 5971、RFC 6071和RFC 6890。
It is NOT RECOMMENDED to include the anycast 6to4 transition mechanism in new implementations. If included in any implementations, the anycast 6to4 mechanism MUST be disabled by default.
不建议在新的实现中包括anycast 6to4转换机制。如果包含在任何实现中，则默认情况下必须禁用anycast 6to4机制。
In host implementations, unicast 6to4 MUST also be disabled by default. All hosts using 6to4 MUST support the IPv6-address-selection policy described in [RFC6724].
在主机实现中，默认情况下还必须禁用单播6to4。所有使用6to4的主机必须支持[RFC6724]中所述的IPv6地址选择策略。
In router implementations, 6to4 MUST be disabled by default. In particular, enabling IPv6 forwarding on a device MUST NOT automatically enable 6to4.
在路由器实现中，默认情况下必须禁用6to4。特别是，在设备上启用IPv6转发不能自动启用6to4。
This document does not imply a recommendation for the generalized filtering of traffic or routes for 6to4 or even anycast 6to4. It simply recommends against further deployment of the anycast 6to4 mechanism, calls for current 6to4 deployments to evaluate the efficacy of continued use of the anycast 6to4 mechanism, and makes recommendations intended to prevent any use of 6to4 from hampering broader deployment and use of native IPv6 on the Internet as a whole.
本文件并不建议对6to4或甚至选播6to4的流量或路由进行通用过滤。它只是建议不要进一步部署anycast 6to4机制，呼吁当前部署6to4以评估继续使用anycast 6to4机制的有效性，并提出建议，旨在防止6to4的任何使用妨碍在整个互联网上更广泛地部署和使用本机IPv6。
Networks SHOULD NOT filter out packets whose source address is 192.88.99.1, because this is normal 6to4 traffic from a 6to4 return relay somewhere in the Internet. This includes ensuring that traffic from a local 6to4 return relay with a source address of 192.88.99.1 is allowed through anti-spoofing filters (such as those described in [RFC2827] and [RFC3704]) or through Unicast Reverse Path Forwarding (uRPF) checks [RFC5635].
网络不应该过滤掉源地址为192.88.99.1的数据包，因为这是来自互联网某处6to4返回中继的正常6to4流量。这包括确保通过反欺骗过滤器（如[RFC2827]和[RFC3704]中所述）或通过单播反向路径转发（uRPF）检查[RFC5635]允许来自源地址为192.88.99.1的本地6to4返回中继的流量。
The guidelines in Section 4 of [RFC6343] remain valid for those who choose to continue operating anycast 6to4 despite its deprecation.
[RFC6343]第4节中的指南对那些选择继续运营anycast 6to4的人仍然有效，尽管它遭到了反对。
Current operators of an anycast 6to4 relay with the IPv4 address 192.88.99.1 SHOULD review the information in [RFC6343] and the present document, and then consider carefully whether the anycast relay can be discontinued as traffic diminishes. Internet service providers that do not operate an anycast relay but do provide their customers with a route to 192.88.99.1 SHOULD verify that it does in fact lead to an operational anycast relay, as discussed in Section 4.2.1 of [RFC6343]. Furthermore, Internet service providers and other network providers MUST NOT originate a route to 192.88.99.1, unless they actively operate and monitor an anycast 6to4 relay service as detailed in Section 4.2.1 of [RFC6343].
现有的带有IPv4地址192.88991的任意播6to4中继的运营商应审查[RCF633]和本文档中的信息，然后仔细考虑是否随着流量减少而中断了选播中继。如[RFC6343]第4.2.1节所述，不运行选播中继但为其客户提供192.88.99.1路由的互联网服务提供商应验证其是否确实导致运行选播中继。此外，互联网服务提供商和其他网络提供商不得发起到192.88.99.1的路由，除非他们按照[RFC6343]第4.2.1节中的详细说明积极操作和监控选播6to4中继服务。
Operators of a 6to4 return relay responding to the IPv6 prefix 2002::/16 SHOULD review the information in [RFC6343] and the present document, and then consider carefully whether the return relay can be discontinued as traffic diminishes. To avoid confusion, note that nothing in the design of 6to4 assumes or requires that return packets are handled by the same relay as outbound packets. As discussed in Section 4.5 of RFC 6343, content providers might choose to continue operating a return relay for the benefit of their own residual 6to4 clients. Internet service providers SHOULD announce the IPv6 prefix 2002::/16 to their own customers if and only if it leads to a correctly operating return relay as described in RFC 6343. IPv6-only service providers, including those operating a NAT64 service [RFC6146], are advised that their own customers need a route to such a relay in case a residual 6to4 user served by a different service provider attempts to communicate with them.
响应于IPv6前缀2002：：/ 16的6to4返回中继的运营商应该审查[RCF633]和本文档中的信息，然后仔细考虑当流量减少时，中继中继是否可以停止。为避免混淆，请注意，6to4设计中没有任何内容假设或要求返回数据包与出站数据包由同一个中继处理。如RFC 6343第4.5节所述，内容提供商可能会选择继续运营返回中继，以使其自己的剩余6to4客户端受益。互联网服务提供商应向其客户宣布IPv6前缀2002:：/16，如果且仅当其导致RFC 6343中所述的正确运行的返回中继时。建议仅限IPv6的服务提供商，包括运行NAT64服务的服务提供商[RFC6146]，其客户需要到此类中继的路由，以防其他服务提供商服务的剩余6to4用户尝试与他们通信。
Operators of "6to4 Provider Managed Tunnels" [RFC6732] SHOULD carefully consider when this service can be discontinued as traffic diminishes.
“6to4提供商管理隧道”的运营商[RCFC63]应仔细考虑当流量减少时该服务何时停止。
The document creating the "IANA IPv4 Special-Purpose Address Registry" [RFC6890] included the 6to4 Relay Anycast prefix (192.88.99.0/24) as Table 10. Per this document, IANA has marked the 192.88.99.0/24 prefix (originally defined by [RFC3068]) as "Deprecated (6to4 Relay Anycast)" and added a reference to this RFC. The Boolean values for the address block 192.88.99.0/24 have been removed. Redelegation of this prefix for any use requires justification via an IETF Standards Action [RFC5226].
创建“IANA IPv4专用地址注册表”[RFC6890]的文档包括6to4中继选播前缀（192.88.99.0/24），如表10所示。根据本文件，IANA已将192.88.99.0/24前缀（最初由[RFC3068]定义）标记为“已弃用（6to4中继选播）”，并添加了对该RFC的引用。地址块192.88.99.0/24的布尔值已删除。将该前缀重新分配用于任何用途需要通过IETF标准行动[RFC5226]进行证明。
There are no new security considerations pertaining to this document. General security issues with tunnels are listed in [RFC6169] and more specifically to 6to4 in [RFC3964] and [RFC6324].
本文档没有新的安全注意事项。[RFC6169]中列出了隧道的一般安全问题，更具体地说是[RFC3964]和[RFC6324]中的6to4。
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996, <http://www.rfc-editor.org/info/rfc2026>.
[RFC2026]Bradner，S.，“互联网标准过程——第3版”，BCP 9，RFC 2026，DOI 10.17487/RFC2026，1996年10月<http://www.rfc-editor.org/info/rfc2026>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, May 2000, <http://www.rfc-editor.org/info/rfc2827>.
[RFC2827]Ferguson，P.和D.Senie，“网络入口过滤：击败利用IP源地址欺骗的拒绝服务攻击”，BCP 38，RFC 2827，DOI 10.17487/RFC2827，2000年5月<http://www.rfc-editor.org/info/rfc2827>.
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, DOI 10.17487/RFC3056, February 2001, <http://www.rfc-editor.org/info/rfc3056>.
[RFC3056]Carpenter，B.和K.Moore，“通过IPv4云连接IPv6域”，RFC 3056，DOI 10.17487/RFC3056，2001年2月<http://www.rfc-editor.org/info/rfc3056>.
[RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", RFC 3068, DOI 10.17487/RFC3068, June 2001, <http://www.rfc-editor.org/info/rfc3068>.
[RFC3068]Huitema，C.，“6to4中继路由器的选播前缀”，RFC 3068，DOI 10.17487/RFC3068，2001年6月<http://www.rfc-editor.org/info/rfc3068>.
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March 2004, <http://www.rfc-editor.org/info/rfc3704>.
[RFC3704]Baker，F.和P.Savola，“多宿网络的入口过滤”，BCP 84，RFC 3704，DOI 10.17487/RFC3704，2004年3月<http://www.rfc-editor.org/info/rfc3704>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，DOI 10.17487/RFC5226，2008年5月<http://www.rfc-editor.org/info/rfc5226>.
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, April 2011, <http://www.rfc-editor.org/info/rfc6146>.
[RFC6146]Bagnulo，M.，Matthews，P.，和I.van Beijnum，“有状态NAT64：从IPv6客户端到IPv4服务器的网络地址和协议转换”，RFC 6146，DOI 10.17487/RFC6146，2011年4月<http://www.rfc-editor.org/info/rfc6146>.
[RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, "Default Address Selection for Internet Protocol Version 6 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, <http://www.rfc-editor.org/info/rfc6724>.
[RFC6724]Thaler，D.，Ed.，Draves，R.，Matsumoto，A.，和T.Chown，“互联网协议版本6（IPv6）的默认地址选择”，RFC 6724，DOI 10.17487/RFC67242012年9月<http://www.rfc-editor.org/info/rfc6724>.
[RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman, "Special-Purpose IP Address Registries", BCP 153, RFC 6890, DOI 10.17487/RFC6890, April 2013, <http://www.rfc-editor.org/info/rfc6890>.
[RFC6890]Cotton，M.，Vegoda，L.，Bonica，R.，Ed.，和B.Haberman，“特殊用途IP地址注册”，BCP 153，RFC 6890，DOI 10.17487/RFC6890，2013年4月<http://www.rfc-editor.org/info/rfc6890>.
[HUSTON] Huston, G., "Flailing IPv6", The ISP Column, December 2010, <http://www.potaroo.net/ispcol/2010-12/6to4fail.html>.
[HUSTON]HUSTON，G.，“鞭打IPv6”，ISP专栏，2010年12月<http://www.potaroo.net/ispcol/2010-12/6to4fail.html>.
[RFC3484] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, DOI 10.17487/RFC3484, February 2003, <http://www.rfc-editor.org/info/rfc3484>.
[RFC3484]Draves，R.，“互联网协议版本6（IPv6）的默认地址选择”，RFC 3484，DOI 10.17487/RFC3484，2003年2月<http://www.rfc-editor.org/info/rfc3484>.
[RFC3964] Savola, P. and C. Patel, "Security Considerations for 6to4", RFC 3964, DOI 10.17487/RFC3964, December 2004, <http://www.rfc-editor.org/info/rfc3964>.
[RFC3964]Savola，P.和C.Patel，“6to4的安全考虑”，RFC 3964，DOI 10.17487/RFC3964，2004年12月<http://www.rfc-editor.org/info/rfc3964>.
[RFC5635] Kumari, W. and D. McPherson, "Remote Triggered Black Hole Filtering with Unicast Reverse Path Forwarding (uRPF)", RFC 5635, DOI 10.17487/RFC5635, August 2009, <http://www.rfc-editor.org/info/rfc5635>.
[RFC5635]Kumari，W.和D.McPherson，“具有单播反向路径转发（uRPF）的远程触发黑洞滤波”，RFC 5635，DOI 10.17487/RFC5635，2009年8月<http://www.rfc-editor.org/info/rfc5635>.
[RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification", RFC 5969, DOI 10.17487/RFC5969, August 2010, <http://www.rfc-editor.org/info/rfc5969>.
[RFC5969]Townsley，W.和O.Troan，“IPv4基础设施上的IPv6快速部署（第6条）——协议规范”，RFC 5969，DOI 10.17487/RFC5969，2010年8月<http://www.rfc-editor.org/info/rfc5969>.
[RFC6169] Krishnan, S., Thaler, D., and J. Hoagland, "Security Concerns with IP Tunneling", RFC 6169, DOI 10.17487/RFC6169, April 2011, <http://www.rfc-editor.org/info/rfc6169>.
[RFC6169]Krishnan，S.，Thaler，D.，和J.Hoagland，“IP隧道的安全问题”，RFC 6169，DOI 10.17487/RFC6169，2011年4月<http://www.rfc-editor.org/info/rfc6169>.
[RFC6324] Nakibly, G. and F. Templin, "Routing Loop Attack Using IPv6 Automatic Tunnels: Problem Statement and Proposed Mitigations", RFC 6324, DOI 10.17487/RFC6324, August 2011, <http://www.rfc-editor.org/info/rfc6324>.
[RFC6324]Nakbly，G.和F.Templin，“使用IPv6自动隧道的路由循环攻击：问题陈述和建议的缓解措施”，RFC 6324DOI 10.17487/RFC6324，2011年8月<http://www.rfc-editor.org/info/rfc6324>.
[RFC6343] Carpenter, B., "Advisory Guidelines for 6to4 Deployment", RFC 6343, DOI 10.17487/RFC6343, August 2011, <http://www.rfc-editor.org/info/rfc6343>.
[RFC6343]Carpenter，B.，“6to4部署咨询指南”，RFC 6343，DOI 10.17487/RFC6343，2011年8月<http://www.rfc-editor.org/info/rfc6343>.
[RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with Dual-Stack Hosts", RFC 6555, DOI 10.17487/RFC6555, April 2012, <http://www.rfc-editor.org/info/rfc6555>.
[RFC6555]Wing，D.和A.Yourtchenko，“快乐眼球：双堆栈主机的成功”，RFC 6555，DOI 10.17487/RFC65552012年4月<http://www.rfc-editor.org/info/rfc6555>.
[RFC6732] Kuarsingh, V., Ed., Lee, Y., and O. Vautrin, "6to4 Provider Managed Tunnels", RFC 6732, DOI 10.17487/RFC6732, September 2012, <http://www.rfc-editor.org/info/rfc6732>.
[RFC6732]Kuarsingh，V.，Ed.，Lee，Y.，和O.Vautrin，“6to4提供商管理的隧道”，RFC 6732，DOI 10.17487/RFC6732，2012年9月<http://www.rfc-editor.org/info/rfc6732>.
Acknowledgements
致谢
The authors would like to acknowledge Tore Anderson, Mark Andrews, Dmitry Anipko, Jack Bates, Cameron Byrne, Ben Campbell, Lorenzo Colitti, Gert Doering, Nick Hilliard, Philip Homburg, Ray Hunter, Joel Jaeggli, Victor Kuarsingh, Kurt Erik Lindqvist, Jason Livingood, Jeroen Massar, Keith Moore, Tom Petch, Daniel Roesen, Mark Townsley, and James Woodyatt for their contributions and discussions on this topic.
作者要感谢托尔·安德森、马克·安德鲁斯、德米特里·安尼普科、杰克·贝茨、卡梅隆·伯恩、本·坎贝尔、洛伦佐·科利蒂、格特·多林、尼克·希利亚德、菲利普·霍姆伯格、雷·亨特、乔尔·贾格利、维克多·夸辛格、库尔特·埃里克·林克维斯特、杰伦·马萨、基思·摩尔、汤姆·佩奇、丹尼尔·罗森、马克·汤斯利、，和詹姆斯·伍迪亚特，感谢他们在这个话题上的贡献和讨论。
Special thanks go to Fred Baker, David Farmer, Wes George, and Geoff Huston for their significant contributions.
特别感谢Fred Baker、David Farmer、Wes George和Geoff Huston做出的重大贡献。
Many thanks to Gunter Van de Velde for documenting the harm caused by non-managed tunnels and stimulating the creation of this document.
非常感谢Gunter Van de Velde记录了非管理隧道造成的危害，并鼓励了本文件的创建。
Authors' Addresses
作者地址
Ole Troan Cisco Oslo Norway
挪威奥斯陆
EMail: ot@cisco.com
EMail: ot@cisco.com
Brian Carpenter (editor) 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