Internet Engineering Task Force (IETF) F. Brockners
Request for Comments: 6674 S. Gundavelli
Category: Standards Track Cisco
ISSN: 2070-1721 S. Speicher
Deutsche Telekom AG
D. Ward
Cisco
July 2012
Internet Engineering Task Force (IETF) F. Brockners
Request for Comments: 6674 S. Gundavelli
Category: Standards Track Cisco
ISSN: 2070-1721 S. Speicher
Deutsche Telekom AG
D. Ward
Cisco
July 2012
Gateway-Initiated Dual-Stack Lite Deployment
网关启动的双栈Lite部署
Abstract
摘要
Gateway-Initiated Dual-Stack Lite (GI-DS-Lite) is a variant of Dual-Stack Lite (DS-Lite) applicable to certain tunnel-based access architectures. GI-DS-Lite extends existing access tunnels beyond the access gateway to an IPv4-IPv4 NAT using softwires with an embedded Context Identifier that uniquely identifies the end-system to which the tunneled packets belong. The access gateway determines which portion of the traffic requires NAT using local policies and sends/ receives this portion to/from this softwire.
网关启动的双栈Lite（GI DS Lite）是双栈Lite（DS Lite）的一种变体，适用于某些基于隧道的访问体系结构。GI DS Lite使用具有嵌入式上下文标识符的软线将现有访问隧道扩展到访问网关之外的IPv4-IPv4 NAT，该标识符可唯一标识隧道数据包所属的终端系统。接入网关使用本地策略确定通信量的哪一部分需要NAT，并向该软线发送/从该软线接收该部分。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
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 Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（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/rfc6674.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6674.
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. 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. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Gateway-Initiated DS-Lite . . . . . . . . . . . . . . . . . . 4
4. Protocol and Related Considerations . . . . . . . . . . . . . 6
5. Softwire Management and Related Considerations . . . . . . . . 7
6. Softwire Embodiments . . . . . . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . . 12
Appendix A. GI-DS-Lite Deployment . . . . . . . . . . . . . . . . 13
A.1. Connectivity Establishment: Example Call Flow . . . . . . 13
A.2. GI-DS-Lite Applicability: Examples . . . . . . . . . . . . 14
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Gateway-Initiated DS-Lite . . . . . . . . . . . . . . . . . . 4
4. Protocol and Related Considerations . . . . . . . . . . . . . 6
5. Softwire Management and Related Considerations . . . . . . . . 7
6. Softwire Embodiments . . . . . . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . . 12
Appendix A. GI-DS-Lite Deployment . . . . . . . . . . . . . . . . 13
A.1. Connectivity Establishment: Example Call Flow . . . . . . 13
A.2. GI-DS-Lite Applicability: Examples . . . . . . . . . . . . 14
Gateway-Initiated Dual-Stack Lite (GI-DS-Lite) is a variant of Dual-Stack Lite (DS-Lite) [RFC6333], applicable to network architectures that use point-to-point tunnels between the access device and the access gateway. The access gateway in these models is designed to serve large numbers of access devices. Mobile architectures based on Mobile IPv6 [RFC6275], Proxy Mobile IPv6 [RFC5213], or GPRS Tunnelling Protocol (GTP) [TS29060], as well as broadband architectures based on PPP or point-to-point VLANs as defined by the Broadband Forum [TR59][TR101], are examples of this type of architecture.
网关启动的双栈Lite（GI DS Lite）是双栈Lite（DS Lite）[RFC6333]的一种变体，适用于在接入设备和接入网关之间使用点对点隧道的网络体系结构。这些模型中的接入网关设计用于为大量接入设备服务。基于移动IPv6[RFC6275]、代理移动IPv6[RFC5213]或GPRS隧道协议（GTP）[TS29060]的移动架构，以及基于PPP或宽带论坛[TR59][TR101]定义的点对点VLAN的宽带架构，都是此类架构的示例。
The DS-Lite approach leverages IPv4-in-IPv6 tunnels (or other tunneling modes) for carrying the IPv4 traffic from the customer network to the Address Family Transition Router (AFTR). An established softwire between the AFTR and the access device is used for traffic-forwarding purposes. This makes the inner IPv4 address irrelevant for traffic routing and allows sharing private IPv4 addresses [RFC1918] between customer sites within the service provider network.
DS-Lite方法利用IPv4-in-IPv6隧道（或其他隧道模式）将IPv4流量从客户网络传输到地址族转换路由器（AFTR）。AFTR和接入设备之间建立的软线用于业务转发目的。这使得内部IPv4地址与流量路由无关，并允许在服务提供商网络内的客户站点之间共享专用IPv4地址[RFC1918]。
Similarly to DS-Lite, GI-DS-Lite enables the service provider to share public IPv4 addresses among different customers by combining tunneling and NAT. It allows multiple access devices behind the access gateway to share the same private IPv4 address [RFC1918]. Rather than initiating the tunnel right on the access device, GI-DS-Lite logically extends the already existing access tunnels beyond the access gateway towards the AFTR using a tunneling mechanism with semantics for carrying context state related to the encapsulated traffic. This approach results in supporting overlapping IPv4 addresses in the access network, requiring no changes to either the access device or the access architecture. Additional tunneling overhead in the access network is also omitted. If, for example, an encapsulation mechanism based on Generic Routing Encapsulation (GRE) is chosen, it allows the network between the access gateway and the AFTR to be either IPv4 or IPv6 and allows the operator to migrate to IPv6 in incremental steps.
与DS Lite类似，GI DS Lite通过结合隧道和NAT，使服务提供商能够在不同的客户之间共享公共IPv4地址。它允许接入网关后面的多个接入设备共享相同的专用IPv4地址[RFC1918]。GI DS Lite没有直接在接入设备上启动隧道，而是使用一种隧道机制（具有承载与封装流量相关的上下文状态的语义），将已经存在的接入隧道从接入网关逻辑上扩展到AFTR。这种方法导致在接入网络中支持重叠的IPv4地址，不需要对接入设备或接入架构进行更改。还省略了接入网络中的额外隧道开销。例如，如果选择基于通用路由封装（GRE）的封装机制，则它允许接入网关和AFTR之间的网络为IPv4或IPv6，并允许运营商以增量步骤迁移到IPv6。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
The following abbreviations are used within this document:
本文件中使用了以下缩写：
AFTR: Address Family Transition Router. An AFTR combines IP-in-IP tunnel termination and IPv4-IPv4 NAT.
AFTR：地址族转换路由器。AFTR结合了IP-in-IP隧道终止和IPv4-IPv4 NAT。
AD: Access Device. It is the end host, also known as the mobile node in mobile architectures.
AD：接入设备。它是终端主机，在移动架构中也称为移动节点。
AG: Access Gateway. A gateway in the access network, such as LMA, Home Agent (HA), GGSN, or PDN-GW in mobile architectures.
AG：接入网关。接入网络中的网关，如移动架构中的LMA、归属代理（HA）、GGSN或PDN-GW。
CID: Context Identifier
上下文标识符
DS-Lite: Dual-Stack Lite
DS-Lite：双栈Lite
GGSN: Gateway GPRS Support Node
GGSN：网关GPRS支持节点
GI-DS-Lite: Gateway-Initiated DS-Lite
GI DS Lite：网关启动的DS Lite
NAT: Network Address Translator
网络地址转换器
PDN-GW: Packet Data Network Gateway
分组数据网络网关
SW: Softwire [RFC4925]
软件：软线[RFC4925]
SWID: Softwire Identifier
SWID：软线标识符
This section provides an overview of Gateway-Initiated DS-Lite (GI-DS-Lite). Figure 1 outlines the generic deployment scenario for GI-DS-Lite. This generic scenario can be mapped to multiple different access architectures, some of which are described in Appendix A.
本节概述网关启动的DS Lite（GI DS Lite）。图1概述了GI DS Lite的通用部署场景。这种通用场景可以映射到多个不同的访问体系结构，其中一些在附录A中描述。
In Figure 1, access devices (AD-1 and AD-2) are connected to the access gateway using some form of tunnel technology and the same is used for carrying IPv4 (and optionally IPv6) traffic of the access device. These access devices may also be connected to the access gateway over point-to-point links. The details on how the network delivers the IPv4 address configuration to the access devices are specific to the access architecture and are outside the scope of this document. With GI-DS-Lite, the access gateway and AFTR are connected by a softwire [RFC4925]. The softwire is identified by a softwire identifier (SWID). The SWID does not need to be globally unique, i.e., different SWIDs could be used to identify a softwire at the different ends of a softwire. The form of the SWID depends on the tunneling technology used for the softwire. The SWID could, for
在图1中，接入设备（AD-1和AD-2）使用某种形式的隧道技术连接到接入网关，并用于承载接入设备的IPv4（和可选IPv6）流量。这些接入设备还可以通过点到点链路连接到接入网关。有关网络如何向接入设备提供IPv4地址配置的详细信息特定于接入体系结构，不在本文档的范围内。使用GI DS Lite，接入网关和AFTR通过软线连接[RFC4925]。软线由软线标识符（SWID）标识。SWID不需要是全局唯一的，即，可以使用不同的SWID来识别软线不同端的软线。SWID的形式取决于软电线使用的隧道技术。例如，SWID可以
example, be the endpoints of a GRE tunnel or a VPN-ID. See Section 6 for details. A Context Identifier (CID) is used to multiplex flows associated with the individual access devices onto the softwire. It is deployment dependent whether the flows from a particular AD are identified using the source IP address or an access tunnel identifier. Local policies at the access gateway determine which part of the traffic received from an access device is tunneled over the softwire to the AFTR. The combination of CID and SWID must be unique between the access gateway and AFTR to identify the flows associated with an AD. The CID is typically a 32-bit-wide identifier and is assigned by the access gateway. It is retrieved either from a local or remote (e.g., Authentication, Authorization, and Accounting (AAA)) repository. Like the SWID, the embodiment of the CID depends on the tunnel mode used and the type of the network connecting the access gateway and AFTR. If, for example, GRE [RFC2784] with GRE Key and Sequence Number extensions [RFC2890] is used as the softwire technology, the network connecting the access gateway and AFTR could be a IPv4-only, IPv6-only, or dual-stack IP network. The CID would be carried within the GRE Key field. Section 6 details the different softwire types supported with GI-DS-Lite.
例如，可以是GRE隧道或VPN-ID的端点。有关详细信息，请参阅第6节。上下文标识符（CID）用于将与各个接入设备相关联的流多路复用到软线上。是否使用源IP地址或访问隧道标识符标识来自特定AD的流取决于部署。接入网关处的本地策略确定从接入设备接收的通信量的哪一部分通过软线隧道传输到AFTR。CID和SWID的组合在接入网关和AFTR之间必须是唯一的，以识别与AD相关联的流。CID通常是一个32位宽的标识符，由接入网关分配。它可以从本地或远程（例如，身份验证、授权和记帐（AAA））存储库中检索。与SWID一样，CID的实施例取决于所使用的隧道模式以及连接接入网关和AFTR的网络类型。例如，如果将具有GRE密钥和序列号扩展名[RFC2890]的GRE[RFC2784]用作软线技术，则连接接入网关和AFTR的网络可以是仅IPv4、仅IPv6或双栈IP网络。CID将携带在GRE密钥字段中。第6节详细介绍了GI DS Lite支持的不同软线类型。
Access Device: AD-1
Context ID: CID-1
NAT Mappings:
IPv4: a.b.c.d +---+ (CID-1, TCP port1 <->
+------+ access tunnel | | e.f.g.h, TCP port2)
| AD-1 |=================| | +---+
+------+ | | | A |
| | Softwire SWID-1 | F |
| A |==========================| T |
IPv4: a.b.c.d | G | (e.g., IPv4-over-GRE | R |
+------+ | | over IPv4 or IPv6) +---+
| AD-2 |=================| |
+------+ access tunnel | | (CID-2, TCP port3 <->
| | e.f.g.h, TCP port4)
+---+
Access Device: AD-1
Context ID: CID-1
NAT Mappings:
IPv4: a.b.c.d +---+ (CID-1, TCP port1 <->
+------+ access tunnel | | e.f.g.h, TCP port2)
| AD-1 |=================| | +---+
+------+ | | | A |
| | Softwire SWID-1 | F |
| A |==========================| T |
IPv4: a.b.c.d | G | (e.g., IPv4-over-GRE | R |
+------+ | | over IPv4 or IPv6) +---+
| AD-2 |=================| |
+------+ access tunnel | | (CID-2, TCP port3 <->
| | e.f.g.h, TCP port4)
+---+
Access Device: AD-2 Context ID: CID-2
访问设备：AD-2上下文ID:CID-2
Figure 1: Gateway-Initiated Dual-Stack Lite Reference Architecture
图1：网关启动的双栈Lite参考体系结构
The AFTR combines softwire termination and IPv4-IPv4 NAT. The NAT binding of the AD's address could be assigned autonomously by the AFTR from a local address pool, configured on a per-binding basis (either by a remote control entity through a NAT control protocol or through manual configuration), or derived from the CID (e.g., the CID, if 32 bits wide, could be mapped 1:1 to an external IPv4
AFTR结合了软线终端和IPv4-IPv4 NAT。AD地址的NAT绑定可以由AFTR从本地地址池自主分配，在每个绑定的基础上进行配置（由远程控制实体通过NAT控制协议或手动配置），或者从CID派生（例如，如果CID为32位宽，则可以1:1映射到外部IPv4）
address). A simple example of a translation table at the AFTR is shown in Figure 2. The choice of the appropriate translation scheme for a traffic flow can take into account parameters such as destination IP address, incoming interface, etc. The IP address of the AFTR, which will either be an IPv6 or an IPv4 address depending on the transport network between the access gateway and the AFTR, is configured on the access gateway. A variety of methods, such as out-of-band mechanisms or manual configuration, apply.
地址）。图2显示了AFTR的翻译表的一个简单示例。为业务流选择适当的转换方案时，可以考虑目标IP地址、传入接口等参数。访问网关上配置了AFTR的IP地址，该地址将是IPv6或IPv4地址，具体取决于访问网关和AFTR之间的传输网络。应用多种方法，例如带外机制或手动配置。
+=====================================+======================+
| Softwire-ID/Context-ID/IPv4/Port | Public IPv4/Port |
+=====================================+======================+
| SWID-1/CID-1/a.b.c.d/TCP-port1 | e.f.g.h/TCP-port2 |
| | |
| SWID-1/CID-2/a.b.c.d/TCP-port3 | e.f.g.h/TCP-port4 |
+-------------------------------------+----------------------+
+=====================================+======================+
| Softwire-ID/Context-ID/IPv4/Port | Public IPv4/Port |
+=====================================+======================+
| SWID-1/CID-1/a.b.c.d/TCP-port1 | e.f.g.h/TCP-port2 |
| | |
| SWID-1/CID-2/a.b.c.d/TCP-port3 | e.f.g.h/TCP-port4 |
+-------------------------------------+----------------------+
Figure 2: Example Translation Table at the AFTR
图2:AFTR的翻译表示例
GI-DS-Lite does not require a 1:1 relationship between an access gateway and AFTR, but more generally applies to (M:N) scenarios, where M access gateways are connected to N AFTRs. Multiple access gateways could be served by a single AFTR. AFTRs could be dedicated to specific groups of access-devices, groups of access gateways, or geographic regions. An AFTR could be, but does not have to be, co-located with an access gateway.
GI DS Lite不需要访问网关和AFTR之间的1:1关系，但更一般地适用于（M:N）场景，其中M个访问网关连接到N个AFTR。多址网关可由单个AFTR提供服务。AFTR可以专用于特定的接入设备组、接入网关组或地理区域。AFTR可以（但不必）与接入网关位于同一位置。
o Depending on the embodiment of the CID (e.g., for GRE encapsulation with GRE Key), the NAT binding entry maintained at the AFTR, which reflects an active flow between an access device inside the network and a node in the Internet, SHOULD be extended to include the CID and the identifier of the softwire (SWID).
o 根据CID的实施例（例如，对于使用GRE密钥的GRE封装），在AFTR处维护的NAT绑定条目（其反映了网络内部的接入设备和因特网中的节点之间的活动流）应扩展以包括CID和软线（SWID）的标识符。
o When creating an IPv4-to-IPv4 NAT binding for an IPv4 packet flow received from the access gateway over the softwire, the AFTR SHOULD associate the CID with that NAT binding. It SHOULD use the combination of CID and SWID as the unique identifier and use those parameters in the NAT binding entry.
o 当为通过软线从接入网关接收的IPv4数据包流创建IPv4到IPv4 NAT绑定时，AFTR应将CID与该NAT绑定相关联。它应该使用CID和SWID的组合作为唯一标识符，并在NAT绑定条目中使用这些参数。
o When forwarding a packet to the access device, the AFTR SHOULD obtain the CID from the NAT binding associated with that flow. For example, in case of GRE encapsulation, it SHOULD add the CID to the GRE Key and Sequence Number extension of the GRE header and tunnel it to the access gateway.
o 当向接入设备转发数据包时，AFTR应从与该流相关联的NAT绑定中获取CID。例如，在GRE封装的情况下，应该将CID添加到GRE头的GRE密钥和序列号扩展，并通过隧道将其传输到访问网关。
o On receiving any packet from the softwire, the AFTR SHOULD obtain the CID from the incoming packet and use it for performing NAT binding lookup and packet translation before forwarding the packet.
o 在从软线接收到任何数据包时，AFTR应从传入数据包中获取CID，并在转发数据包之前将其用于执行NAT绑定查找和数据包转换。
o The access gateway, on receiving any IPv4 packet from the access device, SHOULD lookup the CID for that access device. In case of GRE encapsulation, it can, for example, add the CID to the GRE Key and Sequence Number extension of the GRE header and tunnel it to the AFTR.
o 接入网关从接入设备接收任何IPv4数据包时，应查找该接入设备的CID。例如，在GRE封装的情况下，它可以将CID添加到GRE头的GRE密钥和序列号扩展，并通过隧道将其传输到AFTR。
o On receiving any packet from the softwire, the access gateway SHOULD obtain the CID from the packet and use it for making the forwarding decision.
o 在从软线接收到任何数据包时，接入网关应从该数据包中获取CID，并将其用于做出转发决策。
o When encapsulating an IPv4 packet, the access gateway and AFTR SHOULD use its Diffserv Codepoint (DSCP) to derive the DSCP (or MPLS Traffic-Class Field in the case of MPLS) of the softwire.
o 当封装IPv4数据包时，接入网关和AFTR应使用其Diffserv代码点（DSCP）来导出软线的DSCP（或MPLS情况下的MPLS流量类别字段）。
The following are the considerations related to the operational management of the softwire between the AFTR and access gateway.
以下是与AFTR和接入网关之间的软线的操作管理相关的注意事项。
o The softwire between the access gateway and the AFTR MAY be created at system startup time OR dynamically established on-demand. It is deployment dependent which Operations, Administration, and Maintenance (OAM) mechanisms (such as ICMP, Bidirectional Forwarding Detection (BFD) [RFC5880], or Label Switched Path (LSP) ping [RFC4379]) are employed by the access gateway and AFTR for softwire health management and corresponding protection strategies.
o 接入网关和AFTR之间的软线可在系统启动时创建或按需动态建立。接入网关和AFTR使用哪些操作、管理和维护（OAM）机制（如ICMP、双向转发检测（BFD）[RFC5880]或标签交换路径（LSP）ping[RFC4379]）进行软线健康管理和相应的保护策略取决于部署。
o The softwire peers MAY be provisioned to perform policy enforcement, such as for determining the protocol type or overall portion of traffic that gets tunneled or for any other settings related to quality of service. The specific details on how this is achieved or the types of policies that can be applied are outside the scope for this document.
o 软线对等点可以被设置为执行策略实施，例如用于确定协议类型或被隧道化的业务的整体部分，或者用于与服务质量相关的任何其他设置。关于如何实现这一点或可应用的策略类型的具体细节不在本文档的范围内。
o The softwire peers SHOULD use the correct path MTU value for the tunnel path between the access gateway and the AFTR. This value MAY be statically configured at softwire creation time or dynamically discovered using the standard path MTU discovery techniques.
o 软线对等方应为接入网关和AFTR之间的隧道路径使用正确的路径MTU值。该值可以在软线创建时静态配置，也可以使用标准路径MTU发现技术动态发现。
o An access gateway and an AFTR can have multiple softwires established between them (e.g., to separate address domains, provide for load-sharing, etc.).
o 接入网关和AFTR之间可以建立多条软线（例如，用于分离地址域、提供负载共享等）。
Which tunnel technologies can be applied for the softwire connecting an access gateway and AFTR are dependent on the deployment and the requirements. GRE encapsulation with GRE Key extension, MPLS VPNs [RFC4364], or plain IP-in-IP encapsulation can be used. Softwire identification and CID depend on the tunneling technology employed:
哪些隧道技术可用于连接接入网关和AFTR的软线取决于部署和需求。可以使用带有GRE密钥扩展的GRE封装、MPLS VPN[RFC4364]或IP封装中的普通IP。软线识别和CID取决于采用的隧道技术：
o GRE with GRE Key: SWID is the tunnel identifier of the GRE tunnel between the access gateway and the AFTR. The CID is the GRE Key associated with the AD.
o GRE with GRE Key:SWID是接入网关和AFTR之间GRE隧道的隧道标识符。CID是与AD关联的GRE密钥。
o MPLS VPN: The SWID is a generic identifier that uniquely identifies the VPN at either the access gateway or AFTR. Depending on whether the access gateway or AFTR is acting as customer edge (CE) or provider edge (PE), the SWID could, for example, be an attachment circuit identifier, an identifier representing the set of VPN route labels pointing to the routes within the VPN, etc. The AD's IPv4 address is the CID. For a given VPN, the AD's IPv4 address must be unique.
o MPLS VPN：SWID是一个通用标识符，在访问网关或AFTR上唯一标识VPN。根据接入网关或AFTR是充当客户边缘（CE）还是提供商边缘（PE），例如，SWID可以是连接电路标识符、表示指向VPN内路由的VPN路由标签集的标识符等。AD的IPv4地址是CID。对于给定的VPN，AD的IPv4地址必须是唯一的。
o IPv4/IPv6-in-MPLS: The SWID is the top MPLS label. CID might be the next MPLS label in the stack, if present, or the IP address of the AD.
o MPLS中的IPv4/IPv6：SWID是顶级MPLS标签。CID可能是堆栈中的下一个MPLS标签（如果存在），也可能是AD的IP地址。
o IPv4-in-IPv4: SWID is the outer IPv4 source address. The AD's IPv4 address is the CID. For a given outer IPv4 source address, the AD's IPv4 address must be unique.
o IPv4中的IPv4:SWID是外部IPv4源地址。AD的IPv4地址是CID。对于给定的外部IPv4源地址，AD的IPv4地址必须是唯一的。
o IPv4-in-IPv6: SWID is the outer IPv6 source address. If the AD's IPv4 address is used as CID, the AD's IPv4 address must be unique. If the IPv6 Flow Label [RFC6437] is used as CID, the IPv4 addresses of the ADs may overlap. Given that the IPv6 Flow Label is 20 bits wide, which is shorter than the recommended 32-bit CID, large-scale deployments may require additional scaling considerations. In addition, one should ensure sufficient randomization of the IP Flow Label to avoid possible interference with other uses of the IP Flow Label, such as Equal Cost Multipath (ECMP) support.
o IPv6中的IPv4:SWID是外部IPv6源地址。如果AD的IPv4地址用作CID，则AD的IPv4地址必须唯一。如果IPv6流标签[RFC6437]用作CID，则ADs的IPv4地址可能重叠。考虑到IPv6流标签的宽度为20位，比推荐的32位CID短，因此大规模部署可能需要额外的扩展考虑。此外，应确保IP流标签的充分随机化，以避免可能干扰IP流标签的其他用途，例如等成本多路径（ECMP）支持。
Figure 3 gives an overview of the different tunnel modes as they apply to different deployment scenarios. "x" indicates that a certain deployment scenario is supported. The following abbreviations are used:
图3给出了适用于不同部署场景的不同隧道模式的概述。“x”表示支持某个部署方案。使用以下缩写：
o IPv4 address
o IPv4地址
* "up": Deployments with "unique private IPv4 addresses" assigned to the access devices are supported.
* “up”：支持将“唯一专用IPv4地址”分配给接入设备的部署。
* "op": Deployments with "overlapping private IPv4 addresses" assigned to the access devices are supported.
* “op”：支持将“重叠的专用IPv4地址”分配给接入设备的部署。
* "s": Deployments where all access devices are assigned the same IPv4 address are supported.
* “s”：支持所有接入设备分配相同IPv4地址的部署。
o Network-type
o 网络类型
* "v4": The access gateway and AFTR are connected by an IPv4-only network.
* “v4”：接入网关和AFTR通过仅IPv4网络连接。
* "v6": The access gateway and AFTR are connected by an IPv6-only network.
* “v6”：接入网关和AFTR通过仅限IPv6的网络连接。
* "v4v6": The access gateway and AFTR are connected by a dual-stack network, supporting IPv4 and IPv6.
* “v4v6”：接入网关和AFTR通过双栈网络连接，支持IPv4和IPv6。
* "MPLS": The access gateway and AFTR are connected by an MPLS network
* “MPLS”：接入网关和AFTR通过MPLS网络连接
+===================+==============+=======================+
| | IPv4 address| Network-type |
| Softwire +----+----+---+----+----+------+------+
| | up | op | s | v4 | v6 | v4v6 | MPLS |
+====================+====+====+===+====+====+======+======+
| GRE with GRE Key | x | x | x | x | x | x | |
| MPLS VPN | x | x | | | | | x |
| IPv4/IPv6-in-MPLS | x | x | x | | | | x |
| IPv4-in-IPv4 | x | | | x | | | |
| IPv4-in-IPv6 | x | | | | x | | |
| IPv4-in-IPv6 w/ FL | x | x | x | | x | | |
+====================+====+====+===+====+====+======+======+
+===================+==============+=======================+
| | IPv4 address| Network-type |
| Softwire +----+----+---+----+----+------+------+
| | up | op | s | v4 | v6 | v4v6 | MPLS |
+====================+====+====+===+====+====+======+======+
| GRE with GRE Key | x | x | x | x | x | x | |
| MPLS VPN | x | x | | | | | x |
| IPv4/IPv6-in-MPLS | x | x | x | | | | x |
| IPv4-in-IPv4 | x | | | x | | | |
| IPv4-in-IPv6 | x | | | | x | | |
| IPv4-in-IPv6 w/ FL | x | x | x | | x | | |
+====================+====+====+===+====+====+======+======+
Figure 3: Tunnel Modes and Their Applicability
图3：隧道模式及其适用性
The approach specified in this document allows the use of Dual-Stack Lite for tunnel-based access architectures. Rather than initiating the tunnel from the access device, GI-DS-Lite logically extends the already existing access tunnel beyond the access gateway towards the AFTR and builds a virtual softwire between the AFTR and the access device. This approach requires the use of an additional Context Identifier in the AFTR and at the access gateway, which is required for making IP packet-forwarding decisions.
本文档中指定的方法允许在基于隧道的访问架构中使用双堆栈Lite。GI DS Lite没有从接入设备启动隧道，而是从逻辑上将已经存在的接入隧道扩展到接入网关之外的AFTR，并在AFTR和接入设备之间构建虚拟软线。这种方法需要在AFTR和接入网关中使用额外的上下文标识符，这是做出IP数据包转发决策所必需的。
If a packet is received with an incorrect Context Identifier at the access gateway/AFTR, it will be associated with an incorrect access device. Therefore, care must be taken to ensure an IP packet tunneled between the access gateway and the AFTR is carried with the Context Identifier of the access device associated with that IP packet. The Context Identifier is not carried from the access device, and it is not possible for one access device to claim the Context Identifier of some other access device. However, it is possible that an on-path attacker between the access gateway and the AFTR can potentially modify the Context Identifier in the packet, resulting in association of the packet to an incorrect access device. This threat is no different from an on-path attacker modifying the source/destination address of an IP packet. However, this threat can be prevented by enabling IPsec security with integrity protection turned on, between the access gateway and the AFTR, that will ensure the correct binding of the Context Identifier and the inner packet. This specification does not require any new security considerations other than those specified in the Dual-Stack Lite specification [RFC6333] and in the security considerations specified for the given access architecture, such as Proxy Mobile IPv6, leveraging this transitioning scheme.
如果在接入网关/AFTR处接收到具有不正确上下文标识符的数据包，则该数据包将与不正确的接入设备相关联。因此，必须注意确保在接入网关和AFTR之间通过隧道传输的IP分组带有与该IP分组相关联的接入设备的上下文标识符。上下文标识符不是从接入设备携带的，并且一个接入设备不可能声明某个其他接入设备的上下文标识符。但是，访问网关和AFTR之间的路径上攻击者可能会修改数据包中的上下文标识符，从而导致数据包与不正确的访问设备关联。此威胁与路径上攻击者修改IP数据包的源/目标地址没有区别。但是，可以通过在访问网关和AFTR之间启用完整性保护的IPsec安全来防止这种威胁，这将确保上下文标识符和内部数据包的正确绑定。除了双栈Lite规范[RFC6333]和为给定访问架构（如代理移动IPv6）指定的安全注意事项外，本规范不需要任何新的安全注意事项，利用此转换方案。
The authors would like to acknowledge the discussions on this topic with Mark Grayson, Jay Iyer, Kent Leung, Vojislav Vucetic, Flemming Andreasen, Dan Wing, Jouni Korhonen, Teemu Savolainen, Parviz Yegani, Farooq Bari, Mohamed Boucadair, Vinod Pandey, Jari Arkko, Eric Voit, Yiu L. Lee, Tina Tsou, Guo-Liang Yang, Cathy Zhou, Olaf Bonness, Paco Cortes, Jim Guichard, Stephen Farrell, Pete Resnik, and Ralph Droms.
作者感谢与马克·格雷森、杰伊·艾耶、梁肯特、沃伊斯拉夫·武塞蒂奇、弗莱明·安德里亚森、丹·荣、朱尼·科霍宁、蒂姆·萨沃莱宁、帕维兹·耶加尼、法鲁克·巴里、穆罕默德·布卡达尔、维诺德·潘迪、贾里·阿尔科、埃里克·沃伊特、姚·李、蒂娜·邹、郭亮阳、凯西·周、奥拉夫·邦内斯就这一主题进行的讨论，帕科·科尔特斯、吉姆·吉查德、斯蒂芬·法雷尔、皮特·雷斯尼克和拉尔夫·德罗姆斯。
[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月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
[RFC2784]Farinaci，D.，Li，T.，Hanks，S.，Meyer，D.，和P.Traina，“通用路由封装（GRE）”，RFC 27842000年3月。
[RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", RFC 2890, September 2000.
[RFC2890]Dommety，G.“GRE的密钥和序列号扩展”，RFC 28902000年9月。
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006.
[RFC4364]Rosen，E.和Y.Rekhter，“BGP/MPLS IP虚拟专用网络（VPN）”，RFC 4364，2006年2月。
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006.
[RFC4379]Kompella，K.和G.Swallow，“检测多协议标签交换（MPLS）数据平面故障”，RFC 4379，2006年2月。
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[RFC5213]Gundavelli，S.，Leung，K.，Devarapalli，V.，Chowdhury，K.，和B.Patil，“代理移动IPv6”，RFC 5213，2008年8月。
[RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and Routers", RFC 5555, June 2009.
[RFC5555]Soliman，H.，“双栈主机和路由器的移动IPv6支持”，RFC 55552009年6月。
[RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy Mobile IPv6", RFC 5844, May 2010.
[RFC5844]Wakikawa，R.和S.Gundavelli，“代理移动IPv6的IPv4支持”，RFC 5844，2010年5月。
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, June 2010.
[RFC5880]Katz，D.和D.Ward，“双向转发检测（BFD）”，RFC 58802010年6月。
[RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, July 2011.
[RFC6275]Perkins，C.，Johnson，D.，和J.Arkko，“IPv6中的移动支持”，RFC 62752011年7月。
[RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion", RFC 6333, August 2011.
[RFC6333]Durand，A.，Droms，R.，Woodyatt，J.，和Y.Lee，“IPv4耗尽后的双栈Lite宽带部署”，RFC 63332011年8月。
[RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, "IPv6 Flow Label Specification", RFC 6437, November 2011.
[RFC6437]Amante，S.，Carpenter，B.，Jiang，S.，和J.Rajahalme，“IPv6流标签规范”，RFC 6437，2011年11月。
[NAT-CONTROL] Brockners, F., Bhandari, S., Singh, V., and V. Fajardo, "Diameter Network Address and Port Translation Control Application", Work in Progress, April 2012.
[NAT-CONTROL]Brockners，F.，Bhandari，S.，Singh，V.，和V.Fajardo，“直径网络地址和端口转换控制应用”，正在进行的工作，2012年4月。
[RFC4925] Li, X., Dawkins, S., Ward, D., and A. Durand, "Softwire Problem Statement", RFC 4925, July 2007.
[RFC4925]Li，X.，Dawkins，S.，Ward，D.，和A.Durand，“软线问题声明”，RFC 49252007年7月。
[TR101] Broadband Forum, "TR-101: Migration to Ethernet-Based DSL Aggregation", April 2006.
[TR101]宽带论坛，“TR-101：迁移到基于以太网的DSL聚合”，2006年4月。
[TR59] Broadband Forum, "TR-059: DSL Evolution - Architecture Requirements for the Support of QoS-Enabled IP Services", September 2003.
[TR59]宽带论坛，“TR-059:DSL演进-支持QoS支持IP服务的架构要求”，2003年9月。
[TS23060] 3GPP, "Technical Specification Group Services and System Aspects; General Packet Radio Service (GPRS); Service description; Stage 2, V11.2.0", TS 23.060, 2012.
[TS23060]3GPP，“技术规范组业务和系统方面；通用分组无线业务（GPRS）；业务描述；第2阶段，V11.2.0”，TS 23.06012。
[TS23401] 3GPP, "Technical Specification Group Services and System Aspects; General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access, V11.1.0", TS 23.401, 2012.
[TS23401]3GPP，“技术规范组服务和系统方面；通用分组无线服务（GPRS）增强，用于演进通用地面无线接入网（E-UTRAN）接入，V11.1.0”，TS 23.401，2012年。
[TS29060] 3GPP, "Technical Specification Group Core Network and Terminals; General Packet Radio Service (GPRS); GPRS Tunnelling Protocol (GTP), V11.3.0", TS 29.060, 2012.
[TS29060]3GPP，“技术规范组核心网络和终端；通用分组无线业务（GPRS）；GPRS隧道协议（GTP），V11.3.0”，TS 29.06012。
Figure 4 shows an example call flow - linking access tunnel establishment on the access gateway with the softwire to the AFTR. This simple example assumes that traffic from the AD uses a single access tunnel and that the access gateway will use local policies to decide which portion of the traffic received over this access tunnel needs to be forwarded to the AFTR.
图4显示了一个示例呼叫流——在接入网关上建立连接到AFTR的软线的接入隧道。此简单示例假设来自AD的流量使用单个接入隧道，并且接入网关将使用本地策略来决定通过该接入隧道接收的流量的哪一部分需要转发到AFTR。
AD Access Gateway AAA/Policy AFTR
| | | |
|----(1)-------->| | |
| (2)<-------------->| |
| (3) | |
| |<------(4)------------------->|
| (5) | |
|<---(6)-------->| | |
| | | |
AD Access Gateway AAA/Policy AFTR
| | | |
|----(1)-------->| | |
| (2)<-------------->| |
| (3) | |
| |<------(4)------------------->|
| (5) | |
|<---(6)-------->| | |
| | | |
Figure 4: Example Call Flow for Session Establishment
图4：会话建立的调用流示例
1. The access gateway receives a request to create an access tunnel endpoint.
1. 接入网关接收创建接入隧道端点的请求。
2. The access gateway authenticates and authorizes the access tunnel. Based on local policy or through interaction with the AAA/Policy system, the access gateway recognizes that IPv4 service should be provided using GI-DS-Lite.
2. 接入网关对接入隧道进行身份验证和授权。基于本地策略或通过与AAA/policy系统的交互，访问网关认识到应使用GI DS Lite提供IPv4服务。
3. The access gateway creates an access tunnel endpoint. The access tunnel links AD and access gateway.
3. 访问网关创建一个访问隧道端点。接入隧道连接AD和接入网关。
4. (Optional): The access gateway and the AFTR establish a control session between themselves. This session can, for example, be used to exchange accounting or NAT-configuration information. Accounting information could be supplied to the access gateway, AAA/Policy, or other network entities that require information about the externally visible address/port pairs of a particular access device. The Diameter NAT Control Application [NAT-CONTROL] could, for example, be used for this purpose.
4. （可选）：访问网关和AFTR在它们之间建立控制会话。例如，此会话可用于交换记帐或NAT配置信息。记帐信息可以提供给接入网关、AAA/策略或其他需要特定接入设备的外部可见地址/端口对信息的网络实体。例如，直径NAT控制应用程序[NAT-Control]可用于此目的。
5. The access gateway allocates a unique CID and associates those flows received from the access tunnel that need to be tunneled towards the AFTR with the softwire linking the access gateway and AFTR. Local forwarding policy on the access gateway determines which traffic will need to be tunneled towards the AFTR.
5. 接入网关分配一个唯一的CID，并将从接入隧道接收到的那些需要通过隧道传输到AFTR的流与连接接入网关和AFTR的软线相关联。接入网关上的本地转发策略确定哪些流量需要通过隧道传输到AFTR。
6. The access gateway and AD complete the access tunnel establishment. Depending on the procedures and mechanisms of the corresponding access network architecture, this step can include the assignment of an IPv4 address to the AD.
6. 接入网关和AD完成接入隧道的建立。根据相应接入网络体系结构的过程和机制，此步骤可包括将IPv4地址分配给AD。
The section outlines deployment examples of the generic GI-DS-Lite architecture described in Section 3.
本节概述了第3节中描述的通用GI DS Lite体系结构的部署示例。
o Access architectures based on Mobile-IP: In a network scenario based on Dual-Stack Mobile IPv6 (DSMIPv6) [RFC5555], the Mobile IPv6 home agent will implement the GI-DS-Lite access gateway function along with the dual-stack Mobile IPv6 functionality.
o 基于移动IP的访问架构：在基于双栈移动IPv6（DSMIV6）[RFC5555]的网络场景中，移动IPv6 home agent将实现GI DS Lite访问网关功能以及双栈移动IPv6功能。
o Access architectures based on Proxy Mobile IPv6 (PMIPv6): In a PMIPv6 [RFC5213] scenario, the local mobility anchor (LMA) will implement the GI-DS-Lite access gateway function along with the PMIPv6 IPv4 support [RFC5844] functionality.
o 基于代理移动IPv6（PMIPv6）的访问架构：在PMIPv6[RFC5213]场景中，本地移动锚（LMA）将实现GI DS Lite访问网关功能以及PMIPv6 IPv4支持[RFC5844]功能。
o GTP-based access architectures: Third Generation Partnership Project (3GPP) TS 23.401 [TS23401] and 3GPP TS 23.060 [TS23060] define mobile access architectures using GTP. For GI-DS-Lite, the PDN-GW or GGSN will also assume the access gateway function.
o 基于GTP的接入架构：第三代合作伙伴计划（3GPP）TS 23.401[TS23401]和3GPP TS 23.060[TS23060]使用GTP定义移动接入架构。对于GI DS Lite，PDN-GW或GGSN也将承担接入网关功能。
o Fixed Worldwide Interoperability for Microwave Access (WiMAX) architecture: If GI-DS-Lite is applied to fixed WiMAX, the Access Service Network Gateway (ASN-GW) will implement the GI-DS-Lite access gateway function.
o 固定全球微波接入互操作性（WiMAX）架构：如果GI DS Lite应用于固定WiMAX，接入服务网络网关（ASN-GW）将实现GI DS Lite接入网关功能。
o Mobile WiMAX: If GI-DS-Lite is applied to mobile WiMAX, the home agent will implement the access gateway function.
o 移动WiMAX：如果GI-DS-Lite应用于移动WiMAX，则归属代理将实现接入网关功能。
o PPP-based broadband access architectures: If GI-DS-Lite is applied to PPP-based access architectures, the Broadband Remote Access Server (BRAS) or Broadband Network Gateway (BNG) will implement the GI-DS-Lite access gateway function.
o 基于PPP的宽带接入架构：如果GI DS Lite应用于基于PPP的接入架构，则宽带远程接入服务器（BRAS）或宽带网络网关（BNG）将实现GI DS Lite接入网关功能。
o In broadband access architectures using per-subscriber VLANs, the BNG will implement the GI-DS-Lite access gateway function.
o 在使用每用户VLAN的宽带接入架构中，BNG将实现GI DS Lite接入网关功能。
Authors' Addresses
作者地址
Frank Brockners Cisco Hansaallee 249, 3rd Floor Duesseldorf, Nordrhein-Westfalen 40549 Germany
德国北莱茵威斯特法伦40549杜塞尔多夫3楼Frank Brockners Cisco Hansaallee 249
EMail: fbrockne@cisco.com
EMail: fbrockne@cisco.com
Sri Gundavelli Cisco 170 West Tasman Drive San Jose, CA 95134 USA
美国加利福尼亚州圣何塞市西塔斯曼大道170号，邮编95134
EMail: sgundave@cisco.com
EMail: sgundave@cisco.com
Sebastian Speicher Deutsche Telekom AG Landgrabenweg 151 Bonn, Nordrhein-Westfalen 53277 Germany
Sebastian Speicher德意志电信股份有限公司Landgrabenweg 151波恩，北莱茵威斯特法伦53277德国
EMail: sebastian.speicher@telekom.de
EMail: sebastian.speicher@telekom.de
David Ward Cisco 170 West Tasman Drive San Jose, CA 95134 USA
美国加利福尼亚州圣何塞西塔斯曼大道170号，邮编95134
EMail: wardd@cisco.com
EMail: wardd@cisco.com