Independent Submission T. Tsou
Request for Comments: 6654 Huawei Technologies (USA)
Category: Informational C. Zhou
ISSN: 2070-1721 T. Taylor
Huawei Technologies
Q. Chen
China Telecom
July 2012
Independent Submission T. Tsou
Request for Comments: 6654 Huawei Technologies (USA)
Category: Informational C. Zhou
ISSN: 2070-1721 T. Taylor
Huawei Technologies
Q. Chen
China Telecom
July 2012
Gateway-Initiated IPv6 Rapid Deployment on IPv4 Infrastructures (GI 6rd)
网关启动的IPv4基础架构上的IPv6快速部署（GI 6rd）
Abstract
摘要
This document proposes an alternative IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) deployment model to that of RFC 5969. The basic 6rd model allows IPv6 hosts to gain access to IPv6 networks across an IPv4 access network using 6-in-4 tunnels. 6rd requires support by a device (the 6rd customer edge, or 6rd-CE) on the customer site, which must also be assigned an IPv4 address. The alternative model described in this document initiates the 6-in-4 tunnels from an operator-owned Gateway collocated with the operator's IPv4 network edge rather than from customer equipment, and hence is termed "Gateway-initiated 6rd" (GI 6rd). The advantages of this approach are that it requires no modification to customer equipment and avoids assignment of IPv4 addresses to customer equipment. The latter point means less pressure on IPv4 addresses in a high-growth environment.
本文档提出了一种替代RFC 5969的IPv4基础设施上IPv6快速部署（第6rd）部署模型。基本的第六种模式允许IPv6主机通过IPv4接入网络使用四合六隧道访问IPv6网络。第6rd需要客户站点上的设备（第6rd客户边缘或第6rd CE）的支持，还必须为其分配IPv4地址。本文档中描述的替代模型从与运营商IPv4网络边缘并置的运营商自有网关而不是从客户设备启动六合四隧道，因此被称为“网关启动的6rd”（GI 6rd）。这种方法的优点是，它不需要修改客户设备，并避免将IPv4地址分配给客户设备。后一点意味着在高增长环境中，IPv4地址的压力更小。
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/rfc6654.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6654.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 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://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Table of Contents
目录
1. Introduction ....................................................2
2. Problem Statement ...............................................3
3. Proposed Solution ...............................................4
3.1. Prefix Delegation ..........................................5
3.2. Relevant Differences from Basic 6rd ........................6
4. Security Considerations .........................................7
5. Acknowledgements ................................................7
6. References ......................................................7
6.1. Normative References .......................................7
6.2. Informative References .....................................7
1. Introduction ....................................................2
2. Problem Statement ...............................................3
3. Proposed Solution ...............................................4
3.1. Prefix Delegation ..........................................5
3.2. Relevant Differences from Basic 6rd ........................6
4. Security Considerations .........................................7
5. Acknowledgements ................................................7
6. References ......................................................7
6.1. Normative References .......................................7
6.2. Informative References .....................................7
6rd [RFC5969] provides a transition tool for connecting IPv6 devices across an IPv4 network to an IPv6 network, at which point the packets can be routed natively. The network topology is shown in Figure 1.
第6rd[RFC5969]提供了一种过渡工具，用于将IPv4网络上的IPv6设备连接到IPv6网络，在该网络上，数据包可以本机路由。网络拓扑如图1所示。
+--------------+ +-----------------+ +---------+
| | | | | |
+-----+ +-----+ | Provider +--------+ | |
|IPv6 | | 6rd |__| IPv4 | Border |__| IPv6 |
|Host | | CE | | Network | Router | | Network |
+-----+ +-----+ | +--------+ | |
| Customer LAN | | | | |
+--------------+ +-----------------+ +---------+
+--------------+ +-----------------+ +---------+
| | | | | |
+-----+ +-----+ | Provider +--------+ | |
|IPv6 | | 6rd |__| IPv4 | Border |__| IPv6 |
|Host | | CE | | Network | Router | | Network |
+-----+ +-----+ | +--------+ | |
| Customer LAN | | | | |
+--------------+ +-----------------+ +---------+
Figure 1: 6rd Deployment Topology
图1:6rd部署拓扑
In Figure 1, the CE is the customer edge router. It is provisioned with a delegated IPv6 prefix, but it is also configured with an IPv4 address so that it is reachable through the IPv4 network. If a public IPv4 address is provisioned to every customer, it will aggravate the pressure due to the IPv4 address shortage for operators
在图1中，CE是客户边缘路由器。它配置了委派的IPv6前缀，但也配置了IPv4地址，以便可以通过IPv4网络访问。如果向每个客户提供一个公共IPv4地址，这将加剧运营商IPv4地址短缺带来的压力
faced with a high rate of growth in the number of broadband subscribers to their network. The use of private addresses with 6rd avoids this particular difficulty but brings other complications.
面对其网络宽带用户数量的高速增长。在6rd中使用私有地址可以避免这一特殊困难，但也会带来其他复杂性。
Consider an operator facing a high subscriber growth rate. As a result of this growth rate, the operator faces pressure on its stock of available public IPv4 addresses. For this reason, the operator is motivated to offer IPv6 access as quickly as possible. Figure 2 shows the sort of network situation envisioned in the present document.
考虑一个面临高用户增长率的运营商。由于这种增长率，运营商面临可用公共IPv4地址存量的压力。因此，运营商希望尽快提供IPv6接入。图2显示了本文档中设想的网络状况。
+----+ +-------------------+ +----------------+
|Host|\ | | | |
+----+ \_+---+ +----+ Metro +----+ | Backbone |
_|CPE|----| GW | Network | BR |--| Network |
+----+ / +---+ +----+ (IPv4) +----+ | (IPv6) |
|Host|/ | | | |
+----+ +-------------------+ +----------------+
+----+ +-------------------+ +----------------+
|Host|\ | | | |
+----+ \_+---+ +----+ Metro +----+ | Backbone |
_|CPE|----| GW | Network | BR |--| Network |
+----+ / +---+ +----+ (IPv4) +----+ | (IPv6) |
|Host|/ | | | |
+----+ +-------------------+ +----------------+
Host = IPv6 customer host device CPE = customer edge device (customer-provided) GW = provider edge device (Gateway) BR = border router (dual stack)
主机=IPv6客户主机设备CPE=客户边缘设备（客户提供）GW=提供商边缘设备（网关）BR=边界路由器（双堆栈）
Specialized GW and BR functions are described in the next section.
下一节将介绍专用GW和BR功能。
Figure 2: Typical Network Scenario for IPv6 Transition
图2:IPv6过渡的典型网络场景
The backbone network will be the first part of the operator's network to support IPv6. The metro network is not so easily upgraded to support IPv6, since many devices need to be modified and there may be some impact to existing services. Thus, any means of providing IPv6 access has to minimize the changes required to devices in the metro network.
主干网将是运营商网络支持IPv6的第一部分。城域网不太容易升级以支持IPv6，因为许多设备需要修改，并且可能会对现有服务产生一些影响。因此，提供IPv6访问的任何方法都必须尽量减少对城域网络中的设备所需的更改。
In contrast to the situation described for basic 6rd [RFC5569], the operator is assumed to have no control over the capabilities of the IP devices on the customer premises. As a result, the operator cannot assume that any of these devices are capable of supporting 6rd.
与基本第6条[RFC5569]中描述的情况相反，假定运营商对客户场所的IP设备的能力没有控制权。因此，操作员不能假设这些设备中的任何一个能够支持6rd。
If the customer equipment is in bridged mode and IPv6 is deployed to sites via a Service Provider's (SP's) IPv4 network, the IPv6-only host needs an IPv6 address to visit the IPv6 service. In this scenario, 6to4 [RFC3056] or 6rd can be used. However, each IPv6-only
如果客户设备处于桥接模式，并且IPv6通过服务提供商（SP）的IPv4网络部署到站点，则仅IPv6主机需要IPv6地址才能访问IPv6服务。在这种情况下，可以使用6to4[RFC3056]或6rd。然而，每一个IPv6都只支持IPv6
host may need one corresponding IPv4 address when using a public IPv4 address in 6to4 or 6rd, which puts great address pressure on the operators.
在6to4或6rd中使用公共IPv4地址时，主机可能需要一个相应的IPv4地址，这给运营商带来了巨大的地址压力。
If the CPE in the above figure is acting in bridging mode, each host behind it needs to be directly assigned an IPv6 prefix so it can access IPv6 services. If the CPE is acting in routing mode, only the CPE needs to be assigned an IPv6 prefix, and it delegates prefixes to the hosts behind it.
如果上图中的CPE处于桥接模式，则需要直接为其后面的每个主机分配一个IPv6前缀，以便其能够访问IPv6服务。如果CPE在路由模式下工作，则仅需要为CPE分配IPv6前缀，并且它将前缀委托给其后面的主机。
If the Gateway supports IPv4 only, then an IPv4 address must also be assigned to each host (bridging mode) or to the CPE (routing mode). Both of these cases, but the bridging mode in particular, put pressure on the provider's stock of IPv4 addresses.
如果网关仅支持IPv4，则还必须将IPv4地址分配给每个主机（桥接模式）或CPE（路由模式）。这两种情况，尤其是桥接模式，都会对提供商的IPv4地址存量造成压力。
If the Gateway is dual stack, an arrangement may be possible whereby all communication between the Gateway and the customer site uses IPv6 and the need to assign IPv4 addresses to customer devices is avoided. A possible solution is presented in the next section.
如果网关是双栈的，则可能存在这样的安排，即网关和客户站点之间的所有通信都使用IPv6，并且不需要将IPv4地址分配给客户设备。下一节将介绍一种可能的解决方案。
For basic 6rd [RFC5969], the 6rd CE initiates the 6-in-4 tunnel to the dual-stack border router (i.e., the 6rd Border Relay in 6rd terminology) to carry its IPv6 traffic. To avoid the requirement for customer premises equipment to fulfill this role, it is necessary to move the tunneling function to a network device. This document identifies a functional element, termed the 6rd Gateway, to perform this task. In what follows, the 6rd Gateway and 6rd Border Relay are referred to simply as the Gateway and Border Relay, respectively.
对于基本的6rd[RFC5969]，6rd CE启动到双栈边界路由器（即，6rd术语中的第6rd边界中继）的六合四隧道，以承载其IPv6流量。为避免要求客户场所设备履行此职责，有必要将隧道功能移动到网络设备。本文档确定了一个功能元素，称为第六网关，用于执行此任务。在下文中，第六网关和第六边界中继分别简称为网关和边界中继。
The functions of the Gateway are as follows:
网关的功能如下：
o to generate and allocate Gateway-initiated 6rd delegated prefixes for IPv6-capable customer devices, as described in Section 3.1;
o 如第3.1节所述，为支持IPv6的客户设备生成和分配网关启动的第6个委派前缀；
o to forward outgoing IPv6 packets through a tunnel to a Border Relay, which extracts and forwards them to an IPv6 network as for 6rd;
o 通过隧道将传出的IPv6数据包转发至边界中继，边界中继提取并转发至IPv6网络，如第6条；
o to extract incoming IPv6 packets tunneled from the Border Relay and forward them to the correct user device.
o 提取从边界中继通过隧道传输的传入IPv6数据包，并将其转发到正确的用户设备。
In the proposed solution, there is only one tunnel initiated from each Gateway to the Border Relay, which greatly reduces the number of tunnels the Border Relay has to handle. The deployment scenario consistent with the problem statement in Section 2 collocates the Gateway with the IP edge of the access network. This is shown in
在所提出的解决方案中，从每个网关到边界中继只有一个隧道启动，这大大减少了边界中继必须处理的隧道数量。与第2节中的问题陈述一致的部署场景将网关与接入网络的IP边缘配置在一起。如图所示
Figure 2 and is the typical placement of the Broadband Network Gateway (BNG) in a fixed broadband network. By assumption, the metro network beyond the BNG is IPv4. Transport between the customer site and the Gateway is over Layer 2.
图2和是固定宽带网络中宽带网络网关（BNG）的典型布局。根据假设，BNG之外的城域网络是IPv4。客户站点和网关之间的传输通过第2层进行。
The elements of the proposed solution are as follows:
拟议解决方案的要素如下：
o The IPv6 prefix assigned to the customer site contains the compressed IPv4 address of the network-facing side of the Gateway, plus a manually provisioned or Gateway-generated customer site identifier. This is illustrated in Figure 3.
o 分配给客户站点的IPv6前缀包含网关面向网络一侧的压缩IPv4地址，以及手动配置或网关生成的客户站点标识符。这如图3所示。
o The Border Relay is able to route incoming IPv6 packets to the correct Gateway by extracting the compressed Gateway address from the IPv6 destination address of the incoming packet, expanding it to a full 32-bit IPv4 address, and setting it as the destination address of the encapsulated packet.
o 通过从传入数据包的IPv6目标地址提取压缩网关地址，将其扩展为完整的32位IPv4地址，并将其设置为封装数据包的目标地址，边界中继能够将传入IPv6数据包路由到正确的网关。
o The Gateway can route incoming packets to the correct link after decapsulation using a mapping from either the full IPv6 prefix or the customer site identifier extracted from that prefix to the appropriate link.
o 网关可以使用从完整IPv6前缀或从该前缀提取的客户站点标识符到适当链路的映射，在解除封装后将传入数据包路由到正确链路。
Referring back to Figure 2, prefix assignment to the customer equipment occurs in the normal fashion through the Gateway/IP edge, using either DHCPv6 or Stateless Address Autoconfiguration (SLAAC). Figure 3 illustrates the structure of the assigned prefix, and how the components are derived, within the context of a complete address.
回到图2，使用DHCPv6或无状态地址自动配置（SLAAC），通过网关/IP边缘以正常方式向客户设备分配前缀。图3说明了分配前缀的结构，以及在完整地址的上下文中如何派生组件。
+--------------------+-----------+
| 32-bit Gateway IPv4 address |
+--------------------+-----------+
|<---IPv4MaskLen --->| o bits | Gateway or manually
/ / generated value, unique
Configured / / / for the Gateway
| / / |
| / / V
| V p bits | o bits | n bits |m bits | 64 bits |
+----------------+------------+---------+-------+----------------+
| | Gateway |Customer | | |
| Common prefix | Identifier | Site |subnet | interface ID |
| | | Index | ID | |
+----------------+------------+---------+-------+----------------+
|<------ GI 6rd delegated prefix ------>|
+--------------------+-----------+
| 32-bit Gateway IPv4 address |
+--------------------+-----------+
|<---IPv4MaskLen --->| o bits | Gateway or manually
/ / generated value, unique
Configured / / / for the Gateway
| / / |
| / / V
| V p bits | o bits | n bits |m bits | 64 bits |
+----------------+------------+---------+-------+----------------+
| | Gateway |Customer | | |
| Common prefix | Identifier | Site |subnet | interface ID |
| | | Index | ID | |
+----------------+------------+---------+-------+----------------+
|<------ GI 6rd delegated prefix ------>|
Figure 3: Gateway-Initiated 6rd Address Format for a Customer Site
图3：客户站点的网关启动的第6个地址格式
The common prefix, i.e., the first p bits of the GI 6rd delegated prefix, is configured in the Gateway. This part of the prefix is common across multiple customers and multiple Gateways. Multiple common prefix values may be used in a network either for service separation or for scalability.
在网关中配置公共前缀，即GI 6rd委托前缀的前p位。前缀的这一部分在多个客户和多个网关中很常见。多个公共前缀值可在网络中用于服务分离或可伸缩性。
The Gateway Identifier is equal to the o low-order bits of the Gateway IPv4 address on the virtual link to the Border Relay. The number of bits o is equal to (32 - IPv4MaskLen), where the latter is the length of the IPv4 prefix from which the Gateway IPv4 addresses are derived. The value of IPv4MaskLen is configured in both the Gateways and the Border Relays.
网关标识符等于到边界中继的虚拟链路上网关IPv4地址的o低位。位o的数量等于（32-IPv4MaskLen），其中后者是从中派生网关IPv4地址的IPv4前缀的长度。在网关和边界继电器中配置IPv4MaskLen的值。
The Customer Site Index is effectively a sequence number assigned to an individual customer site served by the Gateway. The value of the index for a given customer site must be unique across the Gateway. The length n of the Customer Site Index is provisioned in the Gateway and must be large enough to accommodate the number of customer sites that the Gateway is expected to serve.
客户站点索引实际上是分配给网关服务的单个客户站点的序列号。给定客户站点的索引值在网关中必须是唯一的。客户站点索引的长度n在网关中设置，并且必须足够大，以容纳网关预期服务的客户站点的数量。
To give a numerical example, consider a 6rd domain containing ten million IPv6-capable customer devices (a rather high number given that 6rd is meant for the early stages of IPv6 deployment). The estimated number of 6rd Gateways needed to serve this domain would be on the order of 3,300, each serving 30,000 customer devices. Assuming best-case compression for the Gateway addresses, the Gateway Identifier field has length o = 12 bits. If 6-in-4 tunneling is being used, this best case is more likely to be achievable than it would be if the IPv4 addresses belonged to the customer devices. The customer device index, which is a more controllable parameter, has length n = 15 bits.
为了给出一个数值例子，考虑第六个域，包含一千万个IPv6能力的客户设备（相当高的数字，假设第六是IPv6部署的早期阶段）。服务于该域所需的第6个网关的估计数量约为3300个，每个网关服务于30000个客户设备。假设对网关地址进行最佳压缩，网关标识符字段的长度为o=12位。如果使用四取六隧道，则与IPv4地址属于客户设备相比，这种最佳情况更有可能实现。客户设备索引是一个更可控的参数，其长度n=15位。
Overall, these figures suggest that the length p of the common prefix can be 29 bits for a /56 delegated prefix, or 21 bits if /48 delegated prefixes need to be allocated.
总的来说，这些数字表明公共前缀的长度p对于/56委托前缀可以是29位，或者如果需要分配/48委托前缀，则可以是21位。
A number of the points in [RFC5969] apply, with the simple substitution of the Gateway for the 6rd CE. When it comes to configuration, the definition of IPv4MaskLen changes, and there are other differences as indicated in the previous section. Since special configuration of customer equipment is not required, the 6rd DHCPv6 option is inapplicable.
[RFC5969]中的许多要点适用，只是将网关替换为第六代CE。当涉及到配置时，IPv4MaskLen的定义会发生变化，并且如前一节所述，还有其他差异。由于不需要客户设备的特殊配置，因此第六代DHCPv6选件不适用。
Since the link for the customer site to the network now extends only as far as the Gateway, Neighbor Unreachability Detection on the part of customer devices is similarly limited in scope.
由于客户站点到网络的链路现在仅延伸到网关，因此客户设备上的邻居不可达性检测在范围上也同样受到限制。
No further security considerations are raised in this document to those described in the Security Considerations section of [RFC5969].
除[RFC5969]的安全注意事项部分所述的安全注意事项外，本文件中未提出其他安全注意事项。
Thanks to Ole Troan for his technical comments on an early version of this document.
感谢Ole Troan对本文档早期版本的技术评论。
[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月。
[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月。
[RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)", RFC 5569, January 2010.
[RFC5569]Despres，R.，“IPv4基础设施上的IPv6快速部署（第6次）”，RFC 5569，2010年1月。
Authors' Addresses
作者地址
Tina Tsou Huawei Technologies (USA) 2330 Central Expressway Santa Clara, CA 95050 USA
Tina Tsou Huawei Technologies（美国）美国加利福尼亚州圣克拉拉中央高速公路2330号，邮编95050
EMail: Tina.Tsou.Zouting@huawei.com
EMail: Tina.Tsou.Zouting@huawei.com
Cathy Zhou Huawei Technologies Bantian, Longgang District Shenzhen 518129 P.R. China
中国深圳市龙岗区华为技术银行周凯茜518129
EMail: cathy.zhou@huawei.com
EMail: cathy.zhou@huawei.com
Tom Taylor Huawei Technologies Ottawa, Ontario Canada
汤姆泰勒华为技术公司加拿大安大略省渥太华
EMail: tom.taylor.stds@gmail.com
EMail: tom.taylor.stds@gmail.com
Qi Chen China Telecom 109 Zhongshan Ave. West Tianhe District, Guangzhou 510630 P.R. China
中国电信广州市天河区中山大道西109号，邮编：510630
EMail: chenqi.0819@gmail.com
EMail: chenqi.0819@gmail.com