Independent Submission R. Despres
Request for Comments: 5569 RD-IPtech
Category: Informational January 2010
ISSN: 2070-1721
Independent Submission R. Despres
Request for Comments: 5569 RD-IPtech
Category: Informational January 2010
ISSN: 2070-1721
IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)
IPv4基础架构上的IPv6快速部署（第6次）
Abstract
摘要
IPv6 rapid deployment on IPv4 infrastructures (6rd) builds upon mechanisms of 6to4 to enable a service provider to rapidly deploy IPv6 unicast service to IPv4 sites to which it provides customer premise equipment. Like 6to4, it utilizes stateless IPv6 in IPv4 encapsulation in order to transit IPv4-only network infrastructure. Unlike 6to4, a 6rd service provider uses an IPv6 prefix of its own in place of the fixed 6to4 prefix. A service provider has used this mechanism for its own IPv6 "rapid deployment": five weeks from first exposure to 6rd principles to more than 1,500,000 residential sites being provided native IPv6, under the only condition that they activate it.
IPv4基础设施上的IPv6快速部署（6rd）建立在6to4机制的基础上，使服务提供商能够将IPv6单播服务快速部署到其向客户提供设备的IPv4站点。与6to4一样，它在IPv4封装中使用无状态IPv6，以便传输仅IPv4的网络基础设施。与6to4不同，第六服务提供商使用自己的IPv6前缀代替固定的6to4前缀。一家服务提供商已将此机制用于其自身的IPv6“快速部署”：从首次接触第六条原则到向超过1500000个住宅站点提供本机IPv6的五周时间，前提是他们必须激活本机IPv6。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
这是对RFC系列的贡献，独立于任何其他RFC流。RFC编辑器已选择自行发布此文档，并且未声明其对实现或部署的价值。RFC编辑批准发布的文件不适用于任何级别的互联网标准；见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/rfc5569.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5569.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定（http:truster.IETF.org/license info）的约束，这些法律规定在本文件出版之日生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Table of Contents
目录
1. Introduction ....................................................2
2. Problem Statement and Purpose of 6rd ............................3
3. Specification ...................................................4
4. Applicability to ISPs That Assign Private IPv4 Addresses ........7
5. Security Considerations .........................................8
6. IANA Considerations .............................................8
7. Acknowledgements ................................................9
8. References ......................................................9
8.1. Normative References .......................................9
8.2. Informative References .....................................9
1. Introduction ....................................................2
2. Problem Statement and Purpose of 6rd ............................3
3. Specification ...................................................4
4. Applicability to ISPs That Assign Private IPv4 Addresses ........7
5. Security Considerations .........................................8
6. IANA Considerations .............................................8
7. Acknowledgements ................................................9
8. References ......................................................9
8.1. Normative References .......................................9
8.2. Informative References .....................................9
After having had a succinct presentation of the 6rd idea, a major French Internet service provider (ISP), Free of the Iliad group (hereafter Free), did all of the following in an impressively short delay of only five weeks (November 7th to December 11th 2007):
在简要介绍了第六个想法后，一家主要的法国互联网服务提供商（ISP）在短短五周（2007年11月7日至12月11日）的时间内完成了以下所有工作，该提供商不受伊利亚特集团（以下简称“免费”）的限制：
1. obtained from its regional Internet Registry (RIR) an IPv6 prefix, the length of which was that allocated without a justification and a delay to examine it, namely /32;
1. 从其区域互联网注册处（RIR）获得一个IPv6前缀，其长度是在没有理由和延迟的情况下分配的，即/32；
2. added 6rd support to the software of its Freebox home-gateway (upgrading for this an available 6to4 code);
2. 在Freebox家庭网关的软件中增加了第6条支持（为此升级了可用的6to4代码）；
3. provisioned PC-compatible platform with a 6to4 gateway software;
3. 配备6to4网关软件的PC兼容平台；
4. modified it to support 6rd;
4. 修改为支持第6条；
5. tested IPv6 operation with several operating systems and applications;
5. 使用多个操作系统和应用程序测试IPv6运行情况；
6. finished operational deployment, by means of new version of the downloadable software of their Freeboxes;
6. 通过其Freebox的新版本可下载软件完成操作部署；
7. announced IPv6 Internet connectivity, at no extra charge, for all its customers wishing to activate it.
7. 宣布为所有希望激活IPv6的客户免费提供IPv6互联网连接。
More than 1,500,000 residential customers thus became able to use IPv6 if they wished, with all the look and feel of native IPv6 addresses routed in IPv6. The only condition was an activation of IPv6 in their Freeboxes, and of course in their IPv6-capable hosts.
因此，超过1500000个住宅客户可以根据自己的意愿使用IPv6，而所有本机IPv6地址都可以在IPv6中路由。唯一的条件是在他们的免费邮箱中激活IPv6，当然也在他们支持IPv6的主机中。
This story is reported to illustrate that ISPs that provide customer premise equipment (CPE) to their clients, with included routing capability, and that have so far postponed IPv6 deployment can, with the dramatically reduced investment and operational costs that 6rd make possible, decide to wait no longer.
报道这个故事是为了说明，向其客户提供包括路由功能的客户前提设备（CPE）的ISP，以及到目前为止推迟IPv6部署的ISP，可以在第六次世界大战使投资和运营成本大幅降低的情况下，决定不再等待。
To complete the story, Free announced, on March 6th 2008, that provided two of its customer sites had IPv6 activated, its Telesites application (Web sites published on TV) could now be used remotely between them.
为了完成这个故事，Free于2008年3月6日宣布，如果其两个客户站点已激活IPv6，其Telesite应用程序（在电视上发布的网站）现在可以在它们之间远程使用。
While IPv6 availability was limited in December 2007 to only one IPv6 link per customer site (with /64 site-prefix assignments). A few months later, after Free had detailed its achievement and plans to its RIR, and then obtained from it a /26 prefix, up to 16 IPv6 links per customer became possible (with /60 site-prefix assignments).
而IPv6的可用性在2007年12月被限制为每个客户站点只有一个IPv6链路（使用/64站点前缀分配）。几个月后，Free向其RIR详细说明了其成就和计划，然后从中获得了A/26前缀，每个客户最多可以建立16条IPv6链路（使用/60站点前缀分配）。
Readers are supposed to be familiar with 6to4 [RFC3056].
读者应该熟悉6to4[RFC3056]。
Having ISPs to rapidly bring IPv6 to customers' sites, in addition to IPv4 and without extra charge, is a way to break the existing vicious circle that has delayed IPv6 deployment: ISPs wait for customer demand before deploying IPv6; customers don't demand IPv6 as long as application vendors announce that their products work on existing infrastructures (that are IPv4 with NATs); application vendors focus their investments on NAT traversal compatibility as long as ISPs don't deploy IPv6.
除了IPv4之外，让ISP在不收取额外费用的情况下将IPv6快速带到客户的站点，是打破延迟IPv6部署的现有恶性循环的一种方式：ISP在部署IPv6之前等待客户需求；只要应用程序供应商宣布其产品在现有基础设施（即使用NAT的IPv4）上工作，客户就不会要求IPv6；只要ISP不部署IPv6，应用程序供应商就将投资重点放在NAT穿越兼容性上。
But most ISPs are not willing to add IPv6 to their current offer at no charge unless incurred investment and operational costs are extremely limited. For this, ISPs that provide router CPEs to their customers have the most favorable conditions: they can upgrade their router CPEs and can operate gateways between their IPv4 infrastructures and the global IPv6 Internet to support IPv6 encapsulation in IPv4. They then need no more routing plans than those that exist on these IPv4 infrastructures.
但大多数ISP都不愿意免费将IPv6添加到当前的服务中，除非所产生的投资和运营成本极其有限。为此，向其客户提供路由器CPE的ISP拥有最有利的条件：他们可以升级其路由器CPE，并可以操作其IPv4基础设施和全球IPv6 Internet之间的网关，以支持IPv4中的IPv6封装。然后，它们不需要比这些IPv4基础架构上存在的路由计划更多的路由计划。
Encapsulation a la 6to4, as specified in [RFC3056], is very close to being sufficient for this: it is simple; it is supported on many platforms including PC-compatible appliances; open-source portable code is available; its stateless nature ensures good scalability.
按照[RFC3056]中的规定，封装la 6to4非常接近于满足这一要求：它很简单；它支持多种平台，包括PC兼容设备；开源可移植代码可用；它的无状态特性确保了良好的可伸缩性。
There is however a limitation of 6to4 that prevents ISPs from using it to offer full IPv6 unicast connectivity to their customers. While an ISP that deploys 6to4 can guarantee that IPv6 packets outgoing from its customer sites will reach the IPv6 Internet, and also guarantee that packets coming from other 6to4 sites will reach its customer sites, it cannot guarantee that packets from native IPv6 sites will reach them. The problem is that a packet coming from a native IPv6 address needs to traverse, somewhere on its way, a 6to4 relay router to do the required IPv6/IPv4 encapsulation. There is no guarantee that routes toward such a relay exist from everywhere, nor is there a guarantee that all such relays do forward packets toward the complete IPv4 Internet.
然而，6to4的限制阻止了ISP使用它向其客户提供完整的IPv6单播连接。虽然部署6to4的ISP可以保证从其客户站点传出的IPv6数据包将到达IPv6 Internet，也可以保证来自其他6to4站点的数据包将到达其客户站点，但它不能保证来自本机IPv6站点的数据包将到达它们。问题在于，来自本机IPv6地址的数据包需要在途中的某个地方穿过6to4中继路由器，以完成所需的IPv6/IPv4封装。无法保证通向此类中继的路由无处不在，也无法保证所有此类中继都会将数据包转发到完整的IPv4互联网。
Also, if an ISP operates one or several 6to4 relay routers and opens IPv6 routes toward them in the IPv6 Internet, for the 6to4 prefix 2002::/16, it may receive in these relays packets destined to an unknown number of other 6to4 ISPs. If it doesn't forward these packets, it creates a black hole in which packets may be systematically lost, breaking some of the IPv6 connectivity. If it does forward them, it can no longer dimension its 6to4 relay routers in proportion to the traffic of its own customers. Quality of service, at least for customers of other 6to4 ISPs, will then hardly be guaranteed.
此外，如果ISP操作一个或多个6to4中继路由器，并在IPv6 Internet中打开指向它们的IPv6路由，则对于6to4前缀2002:：/16，它可能会在这些中继中接收发送给未知数量的其他6to4 ISP的数据包。如果它不转发这些数据包，就会造成一个黑洞，数据包可能会在其中系统性地丢失，从而破坏一些IPv6连接。如果它真的转发它们，它就不能再根据自己客户的流量按比例调整其6to4中继路由器的规模。服务质量，至少对其他6to4 ISP的客户来说，将很难得到保证。
The purpose of 6rd is to slightly modify 6to4 so that:
6rd的目的是稍微修改6to4，以便：
1. Packets that, coming from the global Internet, enter 6rd gateways of an ISP are only packets destined to customer sites of this ISP.
1. 从全球互联网进入ISP第六网关的数据包仅是发送到此ISP客户站点的数据包。
2. All IPv6 packets destined to 6rd customer sites of an ISP, and coming from anywhere else on the IPv6 Internet, traverse a 6rd gateway of this ISP.
2. 所有发往ISP第6个客户站点的IPv6数据包，以及来自IPv6 Internet上任何其他位置的数据包，都会通过该ISP的第6个网关。
The principle of 6rd is that, to build on 6to4 and suppress its limitation, it is sufficient that:
6rd的原则是，要在6to4的基础上发展并抑制其局限性，只要：
1. 6to4 functions are modified to replace the standard 6to4 prefix 2002::/16 by an IPv6 prefix that belongs to the ISP-assigned address space, and to replace the 6to4 anycast address by another anycast address chosen by the ISP.
1. 修改6to4函数，将标准6to4前缀2002:：/16替换为属于ISP分配的地址空间的IPv6前缀，并将6to4选播地址替换为ISP选择的另一个选播地址。
2. The ISP operates one or several 6rd gateways (upgraded 6to4 routers) at its border between its IPv4 infrastructure and the IPv6 Internet.
2. ISP在其IPv4基础设施和IPv6 Internet之间的边界上运行一个或多个第六网关（升级的6to4路由器）。
3. CPEs support IPv6 on their customer-site side and support 6rd (upgraded 6to4 function) on their provider side.
3. CPE在其客户站点端支持IPv6，在其提供商端支持6rd（升级的6to4功能）。
Figure 1 shows how the IPv6 prefix of a customer site is derived from its IPv4 address.
图1显示了客户站点的IPv6前缀如何从其IPv4地址派生。
+---------------//-------.------------------------------+
| 6rd-relays IPv6 prefix | IPv4 address |
| of the ISP | of the customer site |
+---------------//-------'------------------------------+
<-- less or equal to 32 -><------------ 32 ------------->
<-- less or equal to 64 ------------------------------->
+---------------//-------.------------------------------+
| 6rd-relays IPv6 prefix | IPv4 address |
| of the ISP | of the customer site |
+---------------//-------'------------------------------+
<-- less or equal to 32 -><------------ 32 ------------->
<-- less or equal to 64 ------------------------------->
Figure 1: Format of the IPv6 Prefix Assigned to a 6rd Customer Site
图1：分配给第六个客户站点的IPv6前缀的格式
Figure 2 shows which nodes have to be upgraded from 6to4 to 6rd, and which addresses or prefixes have to be routed to them.
图2显示了哪些节点必须从6to4升级到6rd，以及哪些地址或前缀必须路由到它们。
IPv4 AND IPv6 customer site
|
| 6rd CPEs 6rd relays
| (modified 6to4) (modified 6to4)
| | |
| | __________________________ |
| | | | |
| | | ISP IPV4 INFRASTRUCTURE | V GLOBAL
V V | | ___ IPV6
___ | | | | INTERNET
| | | | .-----------------|--| |---
|--| |--|-. / | |___|
| |___| | \ / |
| \ / IPv4 | IPv6 Prefix
| O anycast address => | <= of 6rd relays
| ___ | / \ of 6rd relays | of the ISP
| | | | / \ | ___
|--| |--|-' \ | | |
| |___| | '-----------------|--| |---
| | | |___|
| IPv4 addresses |
| <= of customer sites |
|__________________________|
IPv4 AND IPv6 customer site
|
| 6rd CPEs 6rd relays
| (modified 6to4) (modified 6to4)
| | |
| | __________________________ |
| | | | |
| | | ISP IPV4 INFRASTRUCTURE | V GLOBAL
V V | | ___ IPV6
___ | | | | INTERNET
| | | | .-----------------|--| |---
|--| |--|-. / | |___|
| |___| | \ / |
| \ / IPv4 | IPv6 Prefix
| O anycast address => | <= of 6rd relays
| ___ | / \ of 6rd relays | of the ISP
| | | | / \ | ___
|--| |--|-' \ | | |
| |___| | '-----------------|--| |---
| | | |___|
| IPv4 addresses |
| <= of customer sites |
|__________________________|
Figure 2: ISP Architecture to Deploy IPv6 with 6rd
图2:ISP体系结构使用6rd部署IPv6
NOTE: The chosen address format uses 32 bits of IPv4 addresses in IPv6 addresses for reasons of simplicity and of compatibility with the existing 6to4 code. Limiting initially Free's customer sites to one IPv6 subnet per site, a consequence of Free's initial prefix being a /32, was not a significant restriction: since Free's customers are essentially residential, most of them would have been unable to use several subnets anyway, and as soon as Free would get a prefix shorter than /32, this restriction would be relaxed. If it had been important to immediately use less than 32 bits of IPv4 addresses in IPv6 prefixes, this would have been possible. Since Free, like many ISPs, had several RIR-allocated IPv4 prefixes (6 of them, having lengths from /10 to /16 in the particular case), 6rd gateways and 6rd CPEs could for this have implemented variable-length mapping table. But some of the IPv4 addressing entropy would thus have been extended to 6rd gateways and CPEs. Complexity being then significantly higher, this would have defeated the objective of extreme simplicity to favor actual and rapid deployment.
注意：出于简单性和与现有6to4代码兼容的原因，所选地址格式在IPv6地址中使用32位IPv4地址。最初将Free的客户站点限制为每个站点一个IPv6子网（Free的初始前缀为a/32）并不是一个重要的限制：因为Free的客户基本上是住宅用户，他们中的大多数人无论如何都无法使用多个子网，而且一旦Free获得的前缀短于/32，这项限制将会放宽。如果立即在IPv6前缀中使用少于32位的IPv4地址是很重要的，那么这是可能的。由于Free和许多ISP一样，有几个RIR分配的IPv4前缀（其中6个前缀的长度在特定情况下为/10到/16），因此第六代网关和第六代CPE可以为此实现可变长度映射表。但是一些IPv4地址熵因此会扩展到第六网关和CPE。如果复杂性大大提高，那么这将无法实现支持实际快速部署的极端简单的目标。
IPv6 communication between customer sites of a same ISP is direct across the ISP IPv4 infrastructure: when a CPE sees that the IPv6 destination address of an outgoing packet starts with its own 6rd relay ISPv6 prefix, it takes the 32 bits that follow this prefix as IPv4 destination of the encapsulating packet. (Sending and decapsulation rules of 6to4, duly adapted to the 6rd prefix in place of the 6to4 prefix, apply as described in Section 5.3 of [RFC3056].)
同一ISP的客户站点之间的IPv6通信直接通过ISP IPv4基础设施进行：当CPE看到传出数据包的IPv6目标地址以其自己的第6个中继ISPv6前缀开始时，它将该前缀后面的32位作为封装数据包的IPv4目标。（如[RFC3056]第5.3节所述，适当调整6to4的发送和解除封装规则，以取代6to4前缀，适用于6rdprefix。）
The IPv4 anycast address of 6rd relays may be chosen independently by each ISP. The only constraint is that routes toward the ISP that are advertised must not include this address. For example, Free took a 192.88.99.201 address, routed with the same /24 prefix as 6to4 but with 201 instead of 1 to avoid confusion with 192.88.99.1, the 6to4 anycast address of [RFC3068]. Another possibility, not retained, would have been to use the anycast address of 6to4 and to add, in relays, a test on the IPv6 prefix of the ISP-side address. If it starts with 2002::/16, the packet is 6to4, not 6rd.
第6个中继的IPv4选播地址可由每个ISP独立选择。唯一的限制是，发送到ISP的路由不得包含此地址。例如，Free采用192.88.99.201地址，路由时使用与6to4相同的/24前缀，但使用201而不是1，以避免与[RFC3068]的6to4选播地址192.88.99.1混淆。另一种可能性（未保留）是使用选播地址6to4，并在中继中对ISP端地址的IPv6前缀进行测试。如果以2002:：/16开头，则数据包是6to4，而不是6rd。
______________________________
| |
| 10.x.x.x/8 private addresses |
| <== |
<-----| IPv4 anycast address |----->
| of 6rd relays |
6rd-CPEs | ==> | 6rd-relays
| |
<-----| 0.0.0.0/0 |----->
| : |
|______________V_______________|
__|__
ISP-supported NAT(s) | |
|_____|
|
V
IPv4 public addresses
______________________________
| |
| 10.x.x.x/8 private addresses |
| <== |
<-----| IPv4 anycast address |----->
| of 6rd relays |
6rd-CPEs | ==> | 6rd-relays
| |
<-----| 0.0.0.0/0 |----->
| : |
|______________V_______________|
__|__
ISP-supported NAT(s) | |
|_____|
|
V
IPv4 public addresses
Figure 3: 6rd Applicability to ISPs That Assign IPv4 Private Addresses
图3:6rd对分配IPv4专用地址的ISP的适用性
Free currently offers a global IPv4 address to each of its subscribers, which ensures that all IPv4-derived prefixes using 6rd are unique. Service providers may no longer have this luxury as available global IPv4 addresses become more and more scarce. This section describes how 6rd could be used by a service provider who cannot provide global IPv4 addresses to each subscriber.
Free目前为其每个订户提供一个全局IPv4地址，这确保所有使用6rd的IPv4派生前缀都是唯一的。随着可用的全球IPv4地址变得越来越稀少，服务提供商可能不再拥有这种奢侈。本节介绍无法为每个订户提供全局IPv4地址的服务提供商如何使用6rd。
If an ISP has assigned to customer sites addresses of an IPv4 private space of [RFC1918], typically 10.x.x.x addresses, it can also use 6rd to offer IPv6 to these sites.
如果ISP已将IPv4专用空间的地址分配给客户站点[RFC1918]，通常为10.x.x.x地址，它还可以使用6rd向这些站点提供IPv6。
IPv4 packets that contain IPv6 packets don't go to NATs that this ISP needs to operate in its infrastructure: they go directly to 6rd relays because their destination is the 6rd relay anycast address.
包含IPv6数据包的IPv4数据包不会发送到ISP需要在其基础设施中运行的NAT：它们直接发送到第六中继，因为它们的目的地是第六中继选播地址。
It can be noted that in this case, the 10.0.0.0/8 prefix is common to all IPv4 addresses of the addressing domain in which 6rd is used. Knowing it, gateways and CPEs could avoid including this constant IPv4 prefix in IPv6 prefixes, and thus reduce to 24 the number of bits of IPv4 addresses that are included in IPv6 prefixes (but this was not applicable to Free).
可以注意到，在这种情况下，10.0.0.0/8前缀对于使用6rd的寻址域的所有IPv4地址都是通用的。知道了这一点，网关和CPE可以避免在IPv6前缀中包含此恒定的IPv4前缀，从而将包含在IPv6前缀中的IPv4地址位数减少到24位（但这不适用于免费）。
It can also be noted that, if an ISP is large enough to provide service to more IPv4 endpoints than will fit inside a single 10.0.0.0/8 addressing domain, it can configure several such domains, with 6rd-relay IPv6 prefixes specific of each one. Each of these prefixes is then the RIR-allocated ISP prefix followed by a domain identifier chosen by the ISP.
还可以注意到，如果一个ISP足够大，可以向更多的IPv4端点提供服务，而不是在单个10.0.0.0/8寻址域中提供服务，那么它可以配置多个这样的域，每个域都有特定的第6中继IPv6前缀。然后，每个前缀都是RIR分配的ISP前缀，后跟ISP选择的域标识符。
Security considerations for 6to4 are documented in [RFC3964]. With the restriction imposed by 6rd that relays of an ISP deal only with traffic that belongs to that ISP, checks that have to be done become the following:
6to4的安全注意事项记录在[RFC3964]中。根据第六条的规定，ISP的中继只处理属于该ISP的流量，必须进行的检查如下：
o CPE PACKETS TOWARD THE INTERNET: The IPv6 source must be, and the IPv6 destination must not be, a 6rd address of the site.
o 指向INTERNET的CPE数据包：IPv6源必须是站点的第6个地址，而IPv6目标不能是站点的第6个地址。
o RELAY PACKETS TOWARD THE INTERNET: The IPv6 source must be a 6rd address that matches the IPv4 source. The IPv6 destination must not start with the ISP 6rd prefix.
o 向INTERNET中继数据包：IPv6源必须是与IPv4源匹配的第6个地址。IPv6目标不能以ISP 6rd前缀开头。
o CPE PACKETS FROM THE INTERNET: If the IPv4 source is the 6rd-relay's anycast address of the local ISP, the IPv6 source must not be a 6rd address of this ISP. Otherwise, the IPv6 source must be the 6rd address that matches the IPv4 source (is the IPv6 prefix of 6rd relays of the ISP followed by the IPv4 address).
o 来自INTERNET的CPE数据包：如果IPv4源是本地ISP的第6个中继的选播地址，则IPv6源不得是该ISP的第6个地址。否则，IPv6源必须是与IPv4源匹配的第6个地址（是ISP第6个中继的IPv6前缀，后跟IPv4地址）。
o RELAY PACKETS FROM THE INTERNET: The IPv6 source must not be a 6rd address of the ISP. The IPv4 destination must not be multicast, i.e., must not start with 224/3. The fact that the IPv6 destination starts with the IPv6 prefix of the ISP 6rd relays is ensured by the routing configuration, but may be double-checked.
o 从INTERNET中继数据包：IPv6源不能是ISP的第6个地址。IPv4目标不能是多播，即不能以224/3开头。IPv6目的地以ISP 6rd中继的IPv6前缀开始这一事实由路由配置确保，但可能会进行双重检查。
It remains that where IPv4 address spoofing is possible (IPv4 sites placing unauthorized source addresses in some packets they send), IPv6 address spoofing is also possible, independently of the above precautions.
在IPv4地址欺骗是可能的情况下（IPv4站点在其发送的某些数据包中放置未经授权的源地址），IPv6地址欺骗也是可能的，与上述预防措施无关。
ISPs that provide CPEs to all their customers need no new number assignment by IANA. Their being allocated an IPv6 prefix by their RIR, /32 or shorter, is sufficient.
向所有客户提供CPE的ISP不需要IANA分配新的号码。他们的RIR为他们分配一个IPv6前缀，/32或更短，就足够了。
For 6rd to be also used in the future by ISPs that let customers have their own CPEs, means to communicate 6rd parameters to these CPEs would be needed. If the IETF specifies such means for this, some number assignment by IANA is likely to be solicited, in a registry to be then defined.
为了让客户拥有自己的CPE的ISP将来也使用第6rd，需要向这些CPE传递第6rd参数的方法。如果IETF为此指定了这样的方法，IANA可能会在随后定义的注册中心请求一些号码分配。
The author warmly acknowledges the major contribution of Rani Assaf to 6rd's proven credibility. He readily appreciated 6rd's potential, and made the daring decision to immediately implement it for a very rapid deployment on Free's operational network.
作者热烈感谢拉尼·阿萨夫对第六届世界杯的信誉所作的重大贡献。他欣然意识到6rd的潜力，并做出大胆的决定，立即将其实施，以便在Free的运营网络上进行快速部署。
Mark Townsley, Brian Carpenter and Patrick Grossetete have to be thanked for their encouragements, and for their suggestions on how to proceed for 6rd to be known in the IETF.
必须感谢马克·汤斯利、布赖恩·卡彭特和帕特里克·格罗塞特的鼓励，以及他们关于如何在IETF中获得第六名的建议。
Acknowledgments are also due to some IPv6 old timers, in particular Laurent Toutain, Francis Dupont, and Alain Durand, who, when the author came as a late novice on IPV6, taught him a few subtleties of the subject. Without them, designing 6rd would probably not have been possible.
也要感谢一些IPv6老手，特别是劳伦特·图坦、弗朗西斯·杜邦和阿兰·杜兰德，当作者作为IPv6的后期新手来到这里时，他们教会了他一些关于IPv6的微妙之处。如果没有他们，设计第六条可能是不可能的。
[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月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291]Hinden，R.和S.Deering，“IP版本6寻址体系结构”，RFC 42912006年2月。
[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月。
[RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", RFC 3068, June 2001.
[RFC3068]Huitema，C.，“6to4中继路由器的选播前缀”，RFC3068，2001年6月。
[RFC3964] Savola, P. and C. Patel, "Security Considerations for 6to4", RFC 3964, December 2004.
[RFC3964]Savola，P.和C.Patel，“6to4的安全考虑”，RFC 3964，2004年12月。
Author's Address
作者地址
Remi Despres RD-IPtech 3 rue du President Wilson Levallois, France
法国威尔逊·莱瓦洛伊斯总统街3号雷米·德斯普雷斯路IPtech
Phone: +33 6 72 74 94 88
EMail: remi.despres@free.fr
Phone: +33 6 72 74 94 88
EMail: remi.despres@free.fr