Internet Engineering Task Force F. Brockners Internet-Draft S. Gundavelli Intended status: Standards Track Cisco Expires: April 16, 2010 October 13, 2009 Gateway Initiated Dual-Stack Lite Deployment draft-gundavelli-softwire-gateway-init-ds-lite-00 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 16, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract Dual-Stack lite has been proposed as a IPv4 to IPv6 transition technology. Dual-stack lite allows a service provider to migrate his network to IPv6, while still offering IPv4 services to the end Brockners & Gundavelli Expires April 16, 2010 [Page 1] Internet-Draft Gateway-Initiated DS-Lite October 2009 customer. The dual-stack lite solution uses an IPv4 over IPv6 tunnel between a host (or access device) and a dual-stack lite large scale NAT. Several existing network architectures (e.g. 3GPP, WiMAX, or PPP based broadband networks) already specify dual-stack deployment and leverage tunneling technology between the access device and an access gateway in the provider network. Applying the existing dual- stack lite concept to these networks will result in changes to the end-system and unnecessary tunneling overhead. This draft describes a modified implementation of dual-stack lite where existing access tunnels are extended beyond the access gateway to the dual-stack lite large scale NAT using softwires. This evolved approach applies to IPv4 as well as IPv6 networks. Brockners & Gundavelli Expires April 16, 2010 [Page 2] Internet-Draft Gateway-Initiated DS-Lite October 2009 Table of Contents 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Gateway Initiated DS-Lite . . . . . . . . . . . . . . . . . . 6 3.1. Generic deployment scenario of GI-DS-lite . . . . . . . . 7 3.2. Considerations for the gateway . . . . . . . . . . . . . . 7 3.3. Considerations for the softwire tunnel . . . . . . . . . . 9 3.4. Considerations for the tunnel concentrator . . . . . . . . 9 3.5. Connectivity establishment: Example call flow . . . . . . 10 4. Example Deployment Scenarios . . . . . . . . . . . . . . . . . 11 4.1. Mobile IP based access architectures . . . . . . . . . . . 11 4.1.1. MIPv6 deployment overview for GI-DS-lite . . . . . . . 12 4.1.2. MIPv6 deployment considerations for GI-DS-lite . . . . 12 4.2. Proxy Mobile IP based access architectures . . . . . . . . 13 4.2.1. PMIPv6 deployment overview for GI-DS-lite . . . . . . 13 4.2.2. PMIPv6 deployment considerations for GI-DS-lite . . . 13 4.3. GTP based access architectures . . . . . . . . . . . . . . 13 4.3.1. GTP deployment overview for GI-DS-lite . . . . . . . . 14 4.3.2. GTP deployment considerations for GI-DS-lite . . . . . 14 4.4. Fixed WiMAX access architecture . . . . . . . . . . . . . 14 4.4.1. Fixed-WiMAX deployment overview for GI-DS-lite . . . . 15 4.4.2. Fixed-WiMAX deployment considerations for GI-DS-lite . . . . . . . . . . . . . . . . . . . . . . 15 4.5. Mobile WiMAX access architecture . . . . . . . . . . . . . 15 4.5.1. Mobile-WiMAX deployment overview for GI-DS-lite . . . 16 4.5.2. Mobile-WiMAX deployment considerations for GI-DS-lite . . . . . . . . . . . . . . . . . . . . . . 16 4.6. PPP based access architectures . . . . . . . . . . . . . . 16 4.6.1. PPP deployment overview for GI-DS-lite . . . . . . . . 17 4.6.2. PPP deployment considerations for GI-DS-lite . . . . . 17 4.7. Ethernet VLAN based access architectures . . . . . . . . . 17 4.7.1. Ethernet access deployment overview for GI-DS-lite . . 18 4.7.2. Ethernet access deployment considerations for GI-DS-lite . . . . . . . . . . . . . . . . . . . . . . 18 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 8.1. Normative References . . . . . . . . . . . . . . . . . . . 19 8.2. Informative References . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 Brockners & Gundavelli Expires April 16, 2010 [Page 3] Internet-Draft Gateway-Initiated DS-Lite October 2009 1. Overview The dual-stack model for long was considered as an approach for transitioning from IPv4 to IPv6. Architecture specifications for fixed and mobile networks for e.g. 3GPP, 3GPP2, WiMax-Forum, or ETSI TISPAN adopted support for dual stack. Dual-stack connectivity allows an end-system to choose the appropriate IP version for its application. The way dual-stack connectivity is provided to the end- system depends on the network architecture and the deployment model of the service provider. It can either be provided natively, in which case the operator network supports IPv4 and IPv6 in parallel, or through some form of tunneling. The "dual-stack lite" (DS-lite for short) architecture approach (for details see [I-D.ietf-softwire-dual-stack-lite]) is aimed at operators who have migrated their network to solely support IPv6 but still desire to provide IPv4 service access to their customers. In addition, the provider deploying DS-lite desires to avoid a dedicated IPv4 addressing infrastructure (e.g. avoid the continued use of DHCPv4 for end-system addressing etc.). DS-lite involves an IPv4 over IPv6 tunnel between the end-system (i.e. host or access device, such as a mobile handset or broadband router) and the dual-stack lite large scale NAT. Several network architectures which support dual-stack end-systems already leverage some form of tunneling technology. Mobile architectures based on Mobile IPv6, Proxy Mobile IPv6, or GTP for example already leverage tunnels to connect the end-system or access device to a mobile gateway providing the mobility anchor point. These architectures use IPv4 over IPv6 tunneling between the mobility entities for carrying the mobile node's IPv4 packets in case of a IPv6 transport network. Additionally, these architectures also support IPv4 over IPv4 tunneling mode when using an IPv4 transport network between the network elements. Several broadband architectures deploy layer 2 tunnels (e.g. using Ethernet VLANs or PPP) between the end-system or access device and a network access server. The following can be observed when applying the dual-stack lite concept to architectures which support dual-stack end-systems and employ tunneling to establish IPv4 connectivity: o The end-systems are required to change in order to add support for DS-lite. While easily done for some deployments (e.g. in case of managed end-systems, support can be achieved through a software upgrade), large scale change of end-systems can require replacing the installed base with devices which support DS-lite. End-system replacement could incur significant cost for the service provider and could also take time to be completed - potentially slowing down the migration to IPv6 in the service provider network. Until Brockners & Gundavelli Expires April 16, 2010 [Page 4] Internet-Draft Gateway-Initiated DS-Lite October 2009 completion, DS-lite cannot be used as the only means to provide IPv4 connectivity. o The dual-stack end-systems (i.e. hosts, routing-gateways, handsets etc.) would have two options for IPv4 connectivity to choose from: One would be DS-lite which would involve tunneling of IPv4 over IPv6, where IPv6 connectivity would be provided by the means already specified in the corresponding architecture; the other option would be to leverage the already existing method defined within the architecture supporting dual-stack to establish IPv4 connectivity. This means that the end-system needs to have appropriate policies in place to take a decision between the two connectivity options for IPv4. o The DS-lite IPv4-over-IPv6 softwire would be stacked on top of an already existing tunnel providing IPv6 connectivity to the end- system. If, for example, the service provider deploys an architecture which uses IPv6-over-IPv6 tunneling (e.g. like with MIPv6, PMIPv6, or GTP), DS-lite would result in IPv4-over-IPv6- over-IPv6. This presents additional overhead when compared to using IPv4-over-IPv6 tunneling, as offered by the existing methods for providing IPv4 connectivity (again using MIPv6, PMIPv6 or GTP based architectures as examples here). The additional tunnel overhead caused by DS-lite could be less advantageous for deployments with bandwidth constraints (e.g. radio links). This draft defines a modified implementation of DS-lite: Gateway- initiated DS-lite ("GI-DS-lite" for short). GI-DS-lite leverages the tunneling architecture already in place between the end-system and the access gateway. GI-DS-lite leverages softwire IPv4-over-IPv6 tunnels only between the access gateway and the DSLTC. It complements existing tunnel-based access architectures by extending the access tunnels on the gateway terminating the access tunnels to the DS-lite large scale NAT (a.k.a DS-lite tunnel concentrator) using softwires. The access gateway installs a unique softwire identifier for all the end-system flows and uses this softwire identifier to stitch the access tunnel and the softwire tunnel together. The benefits of gateway-initiated DS-lite include: o There are no changes to the end-systems required. A GI-DS-lite deployment only requires appropriate changes to the gateway which represents the tunnel-endpoint of the access tunnel as well as the DSLTC. o GI-DS-lite does not introduce additional overhead on air-link and on the transport network between base station and access gateway when providing IPv4 connectivity to the end-system. Brockners & Gundavelli Expires April 16, 2010 [Page 5] Internet-Draft Gateway-Initiated DS-Lite October 2009 o GI-DS-lite approach allows the network operator to deploy either IPv4 or IPv6 in the network core. 2. Conventions 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]. Abbreviations are used in this document: AD: Access Device DSLTC: Dual-stack lite tunnel concentrator (a.k.a. dual-stack lite large scale NAT) DS-lite: Dual-stack lite GI-DS-lite: Gateway-initiated DS-lite GW: Gateway SID: Softwire Identifier TID: Tunnel Identifier 3. Gateway Initiated DS-Lite Figure 1 outlines the generic deployment scenario for gateway- initiated dual-stack lite. This generic scenario can be mapped to multiple different access architectures, some of which are described in Section 4. Access devices (e.g. AD-1, AD-2) connect to the gateway using some form of tunnel technology which carry IPv4, IPv6 or both. Tunnels can be identified by some form of tunnel identifier, here described as "tunnel identifier (TID)". Gateway and DSLTC are connected using a softwire tunnel to allow for IPv4 packet transport between Gateway and DSLTC over IPv6. Different from the original DS-lite approach, in GI-DS-lite, the gateway takes the role of the softwire initiator. The gateway associates access tunnels with softwire to the DSLTC to facilitate IPv4 forwarding. Different from the original DS-lite approach, all the IPv4 traffic from all access devices attached to a single gateway is forwarded over a single softwire. IPv4-GRE or IPv6-GRE encapsulation is used to differentiate flows from different access devices within the softwire tunnel. Brockners & Gundavelli Expires April 16, 2010 [Page 6] Internet-Draft Gateway-Initiated DS-Lite October 2009 3.1. Generic deployment scenario of GI-DS-lite Access Tunnel: TID-1 Softwire Id: SID-1 NAT Mappings: IPv4: a.b.c.d +---+ (key1: a.b.c.d, TCP port1; +------+ Tunnel (TID-1) | | e.f.g.h, TCP port2) | AD-1 |====================| G | +---+ +------+ | A | | D | | T | Softwire tunnel | S | | E |========================| L | IPv4: a.b.c.d | W | IPv4-over-IPv6-GRE | T | +------+ | A | | C | | AD-2 |====================| Y | +---+ +------+ Tunnel (TID-2) | | (key2: a.b.c.d, TCP port3; | | e.f.g.h, TCP port4) +---+ Access Tunnel: TID-2 Softwire Id: SID-2 Figure 1: Gateway-initiated dual-stack lite reference architecture 3.2. Considerations for the gateway The gateway (GW) terminates access tunnels and stitches them together with softwire tunnel connecting to the DSLTC. o For architectures which leverage dynamic addresses on the access devices, the gateway facilitates IPv4 address assignment to the access devices. IPv4 address assignment will follow the procedures defined for the respective access architectures and protocols (e.g. in case of MIPv6 the gateway, taking the role of the home agent assigns the IPv4 home address to the mobile node (i.e. the access device) following the procedures specified in [RFC5555]. Similar to the original DS-lite concept, the IPv4 address assigned to the access device has no significance, neither for forwarding decisions nor for tunnel identification, i.e. the gateway will not setup any tunnel route for the IPv4 address as the forwarding decision will be based on the binding table. The gateway can choose to assign the same IPv4 address to all access devices it connects to. Static address assignment, using for example out-of-band mechanisms, could be leveraged as well, in case the underlying access architecture supports it. o The gateway maintains a unique softwire-id (SID) for each access session that requires GI-DS-lite function. This identifier can be generated locally by the gateway or it can be obtained from a Brockners & Gundavelli Expires April 16, 2010 [Page 7] Internet-Draft Gateway-Initiated DS-Lite October 2009 policy store. The identifier is stored in the gateway's binding table. o The gateway will use the softwire-id (SID) when tunneling the access device's IPv4 packets to the DSLTC. It will also use the SID for identifying the AD's IPv4 packets received from the DSLTC. The softwire-id is carried in the GRE Key and Sequence Number Extension [RFC2890]. The sequence number field is not required to be set for this purpose. o Any IPv4 packet received from the access device will be tunneled to the DSLTC. The gateway will encapsulate the IPv4 datagram inside the IPv4-over-IPv6-GRE softwire, or IPv4-over-IPv4-GRE softwire, and will forward the resulting IPv6 datagram to the DSLTC. The GRE key encapsulation is performed as specified in [RFC2890] and the key field in the Key and Sequence Number extension of the GRE header will be set to the softwire-id assigned for that access device. o The gateway will decapsulate any IPv4 packets received inside the softwire tunnel established between the gateway and the DSLTC. It will use the softwire-id from the GRE key field of the GRE key extension for identifying the access device, to which the packet needs to be forwarded. o The IP address (which, depending on the transport network between the GW and the DSLTC, will either be and IPv6 or and IPv4 address) of the DSLTC can be configured on the gateway using a variety of methods, including out-of-band mechanisms, or manual configuration. Figure 2 shows the binding entries maintained by the gateway linking the access tunnel and the softwire for the example above. A unique tunnel identifier (TID) key is associated with each access device, and the same is passed as the Softwire-Id GRE key to the to the DSLTC. +========+===========================+=================+ | AD | Softwire-Id/GRE Key | Tunnel ID | +========+===========================+=================+ | AD-1 | SID-1 (=key1) | TID-1 | | | | | | AD-2 | SID-2 (=key2) | TID-2 | +------------------------------------+-----------------+ Figure 2: Binding table of the gateway Brockners & Gundavelli Expires April 16, 2010 [Page 8] Internet-Draft Gateway-Initiated DS-Lite October 2009 3.3. Considerations for the softwire tunnel GI-DS-lite requires GW and DSLTC to implement GRE encapsulation (see [RFC2784]) with GRE key and sequence number extensions (see [RFC2890]) over IPv6 or IPv4 (depending on the transport network between GW and DSLTC). The GRE key MUST be included for GRE encapsulation. The GRE key represents the unique softwire-ID (SID) which is used by the gateway and DSLTC to differentiate flows from and to different access devices. Figure 3 shows a the encapsulations for IPv4 and IPv6 transport. Service providers who deploy an IPv6 only transport network will leverage the IPv4-over-GRE-IPv6 option, whereas IPv4-over-GRE-IPv4 could for example be used by operators who desire to introduce IPv4-to-IPv4 NAT into their network (e.g. because of the exhaustion of their global IPv4 address space), but want to avoid the use of distinct private IPv4 addresses for the access devices. IPv4 transport network: IPv6 transport network: +-----------------------+ +-----------------------+ | IPv4 transport header | | IPv6 transport header | +-----------------------+ +-----------------------+ | GRE header | | GRE header | | (with key = SID ) | | (with key = SID ) | +-----------------------+ +-----------------------+ | IPv4 header & payload | | IPv4 header & payload | +-----------------------+ +-----------------------+ Figure 3: Softwire tunnel encapsulation 3.4. Considerations for the tunnel concentrator As specified in Section 4.7 of [I-D.ietf-softwire-dual-stack-lite], the DSLTC is a special IPv4 to IPv4 NAT deployed in the edge of the service provider network. This is reachable by the gateway through IPv4 or IPv6 transport network and exchanges user traffic with the gateway using a IPv4-in-GRE-IPv6, or IPv4-over-GRE-IPv4 tunneling. o When creating a IPv4 to IPv4 NAT binding for an IPv4 packet flow forwarded by the gateway over the IPv4-over-IPv6-GRE tunnel, the DSLTC will associate the GRE key (within the GRE Key and Sequence number extension) of the GRE header with that NAT binding. It will use this key as the unique softwire-id (SID). o When forwarding the packets through the softwire tunnel to the gateway, the softwire-id associated with that NAT binding will be added to the key field in the GRE Key and Sequence number Brockners & Gundavelli Expires April 16, 2010 [Page 9] Internet-Draft Gateway-Initiated DS-Lite October 2009 extension of the GRE header. o The DSLTC will decapsulate any IPv4 packets received inside the softwire tunnel established between the gateway and the DSLTC. It will use the softwire-id from the GRE key field of the GRE key extension for identifying the NAT binding, for performing the translation. o This specification does not introduce any new considerations for dealing with flows that are not sent with the tunnel header containing the GRE key, default considerations should apply in such scenario. Figure 4 shows the translation table at the DSLTC for the example above. Both access devices are assigned the same IPv4 address, a.b.c.d. A unique softwire id is associated with each access device, which is used for distinguishing the access device flows when sending and receiving IPv4 datagrams over the same softwire tunnel. +============================+=========================+ | Softwire-Id/IPv4/Port | Public IPv4/Port | +============================+=========================+ | key1/a.b.c.d/TCP port1 | e.f.g.h/TCP port2 | | | | | key2/a.b.c.d/TCP port3 | e.f.g.h/TCP port4 | +----------------------------+-------------------------+ Figure 4: Translation table on the DSLTC 3.5. Connectivity establishment: Example call flow Figure 5 shows an example call flow - linking access session establishment on the gateway with softwire tunneling to the DSLTC. AD GW AAA/Policy DSLTC | | | | |----(1)-------->| | | | (2)<-------------->| | | (3) | | | |<------(4)------------------->| | (5)<===========================>| |<---(6)-------->| | | | | | | Figure 5: Example call flow for session establishment Brockners & Gundavelli Expires April 16, 2010 [Page 10] Internet-Draft Gateway-Initiated DS-Lite October 2009 1. Gateway (GW) receives a request to create an access session. 2. The GW authenticates and authorizes the access session. Based on local policy or through interaction with the AAA/Policy system the gateway recognizes that IPv4 service should be provided using DS-lite. 3. The GW creates an access session. It is assumed that the access session is associated with a tunnel linking AD and GW. The tunnel is uniquely identified by Tunnel Identifier (TID) on the GW. 4. (Optional): The GW and the DSLTC establish a control session between each other. This session is to for example exchange accounting or NAT-configuration information. Accounting information could be supplied to the GW, AAA/Policy, or other network entities which require information about the externally visible address/port pairs of a particular access device. The Diameter NAT Control Application (see [I-D.draft-ietf-dime-nat-control] could for example be used for this purpose. 5. The GW allocates a unique softwire-id and binds the access session (identified by the TID) to the softwire linking GW and DSLTC. 6. GW and AD complete the access session establishment (could include assignment of a (dummy) IPv4 address using the procedures and mechanisms of the corresponding access network architecture). 4. Example Deployment Scenarios 4.1. Mobile IP based access architectures The Mobile IPv6 protocol with the extensions specified in [RFC5555] allow support dual stack mobile nodes. In the MIPv6 scenario, the Mobile IPv6 home agent will implement the gateway function along with the dual-stack Mobile IPv6 functionality. Brockners & Gundavelli Expires April 16, 2010 [Page 11] Internet-Draft Gateway-Initiated DS-Lite October 2009 4.1.1. MIPv6 deployment overview for GI-DS-lite +---+ | | +------+ DSMIP Tunnel | H | | MN-1 |====================| O | +---+ +------+ | M | | D | | E | DS-Lite Tunnel | S | | |========================| L | | A | IPv4-over-GRE-IPv6/4 | T | +------+ | G | | C | | MN-2 |====================| E | +---+ +------+ DSMIP Tunnel | N | | T | +---+ Figure 6: Home Agent Initiated Dual-stack lite Mode 4.1.2. MIPv6 deployment considerations for GI-DS-lite o The Mobile IPv6 home agent will register a unique softwire-id (SID) with the DSLTC for any of the flows associated with a given mobile node. o GI-DS-lite offers a solution for those operators who desire to assign the same IPv4 private address from the [RFC1918] address space to multiple mobile node's within the scope of a single home agent. This requirement is simply due to the lack of availability of public or private IPv4 address space. * The IPv4 address that the home agent assigns to a mobile node has to be unique within its scope, as per [RFC5555], even when these assigned addresses are from a private IPv4 address space [RFC1918]. * When multiple home agents managed by a mobile operator is sharing an overlapping private IPv4 address space, there is a need for NAT [RFC3022] translation device between those home agents bringing the NAT from the edge of the network to deep inside the operator network. Additionally, these introduces the NAT444 issues which the operators do not want to deal with. * In case of Proxy Mobile IPv6, the GRE Key support [I-D.ietf-netlmm-grekey-option] allows the assignment of overlapping private IPv4 addresses to mobile nodes in the hosted LMA model, but such assignment is not possible within a single operator domain and without having to eliminate the NAT444 issues. Brockners & Gundavelli Expires April 16, 2010 [Page 12] Internet-Draft Gateway-Initiated DS-Lite October 2009 4.2. Proxy Mobile IP based access architectures In this scenario the local mobility anchor (LMA) will implement the gateway function along with the PMIPv6 IPv4 support functionality. 4.2.1. PMIPv6 deployment overview for GI-DS-lite +------+ | MN-1 | +------+ | +---+ +------+ +-----+ | D | | M | PMIPv6 Tunnel | L | Dual-stack Lite Tunnel | S | | A |=================| M |==========================| L | | G | | A | IPv4-over-GRE-IPv6/4 | T | +------+ +-----+ | C | | +---+ +------+ | MN-2 | +------+ Figure 7: Local Mobility Anchor Initiated Dual-stack lite Mode 4.2.2. PMIPv6 deployment considerations for GI-DS-lite o The LMA will register a unique softwire-id with the DSLTC for any of the flows associated with a given mobile node. It will use the softwire-id as the key identifier for stitching the two tunnels, the tunnel between the mobile access gateway and the local mobility anchor and the tunnel between the local mobility anchor and the DSLTC. 4.3. GTP based access architectures 3GPP TS 23.401 (see [TS23401]) defines a mobile access architecture using GTP. For GI-DS-lite, the PDN-gateway will also assume the GW function. The approach of registering of MN specific softwire-id with the large scale NAT is identical. Brockners & Gundavelli Expires April 16, 2010 [Page 13] Internet-Draft Gateway-Initiated DS-Lite October 2009 4.3.1. GTP deployment overview for GI-DS-lite +------+ | MN-1 | +------+ | +---+ +------+ +-----+ | D | | S | GTP Tunnel | P | Dual-stack Lite Tunnel | S | | G |=================| G |==========================| L | | W | | W | IPv4-over-GRE-IPv6/4 | T | +------+ +-----+ | C | | +---+ +------+ | MN-2 | +------+ Figure 8: 3GPP PDN Gateway Initiated Dual-stack lite Mode (GTP) 4.3.2. GTP deployment considerations for GI-DS-lite o The PDN-gateway will register a unique softwire-id (SID) with the DSLTC for any of the flows associated with a given mobile node. It will use the softwire-id as the key identifier for stitching the two tunnels, the tunnel between the Serving-gateway (SGW) and the PDN-gateway and the tunnel between the PDN-gateway and the DSLTC. o The GTP Tunnel Endpoint Identifier (TEID) could be leveraged as SID. o In case of an IP-version agnostic access session (i.e. EPC- bearer, as introduced with 3GPP release 8), the PDN-gateway will differentiate IPv4 and IPv6 traffic. Only IPv4 traffic will be forwarded to (and received from) the softwire tunnel. IPv6 will be routed normally. 4.4. Fixed WiMAX access architecture In this scenario the ASN-gateway will implement the gateway function. Brockners & Gundavelli Expires April 16, 2010 [Page 14] Internet-Draft Gateway-Initiated DS-Lite October 2009 4.4.1. Fixed-WiMAX deployment overview for GI-DS-lite +---+ | | +------+ R1 | | | MS-1 |--------------------| A | +---+ +------+ | S | | D | | N | DS-Lite Tunnel | S | | |========================| L | | G | IPv4-over-GRE-IPv6/4 | T | +------+ | W | | C | | MS-2 |--------------------| | +---+ +------+ R1 | | | | +---+ Figure 9: Fixed-WiMAX Gateway Initiated Dual-stack lite Mode 4.4.2. Fixed-WiMAX deployment considerations for GI-DS-lite o The ASN-gateway will register a unique softwire-id (SID) with the DSLTC for any of the flows associated with a given mobile station. 4.5. Mobile WiMAX access architecture In this scenario the home agent will implement the gateway function. Brockners & Gundavelli Expires April 16, 2010 [Page 15] Internet-Draft Gateway-Initiated DS-Lite October 2009 4.5.1. Mobile-WiMAX deployment overview for GI-DS-lite +------+ | MN-1 | +------+ | | R1 +------+ | | +---+ | A | +-----+ | D | | S | PMIPv6 Tunnel | | DS Lite Tunnel | S | | N |=================| H |==========================| L | | | | A | IPv4-over-GRE-IPv6/4 | T | | G | | | | C | | W | +-----+ +---+ | | +------+ | | R1 +------+ | MN-2 | +------+ Figure 10: Fixed-WiMAX Gateway Initiated Dual-stack lite Mode (PMIPv6) 4.5.2. Mobile-WiMAX deployment considerations for GI-DS-lite o The home agent will register a unique softwire-id (SID) with the DSLTC for any of the flows associated with a given mobile system. 4.6. PPP based access architectures The technical report TR-059 of the Broadband Forum (BBF) (see [TR59] outlines a broadband access architecture which leverages the Point- to-Protocol PPP. TR-059 has been evolved to include Ethernet-based access and aggregation networks in TR-101 (see ) [TR101]). PPP is used to establish a point to point connection between the end-system (a.k.a. routing gateway, "RG") and the access gateway (a.k.a. broadband remote access server, "BRAS"; or broadband network gateway, "BNG"). This means that for PPP based access architectures, the device which terminates the PPP-session (e.g. the Broadband Remote Access Server, BRAS) assumes the role of the gateway. The PPP connection represents the access tunnel. The PPP connection can either be identified through the virtual interface created on the BRAS/BNG or (in case of PPPoE), through the PPPoE Session-Identifier. Deployment dependent, the operator will chose to either use a single PPP connection to provide connectivity for both, IPv4 and IPv6, or Brockners & Gundavelli Expires April 16, 2010 [Page 16] Internet-Draft Gateway-Initiated DS-Lite October 2009 the operator deploys a PPP connection per IP protocol version. The later option results in the establishment of two PPP connections per AD. 4.6.1. PPP deployment overview for GI-DS-lite +------+ PPP connection +---+ | RG-1 |====================| | +---+ +------+ | | | D | | B | DS-Lite Tunnel | S | | R |========================| L | | A | IPv4-over-GRE-IPv6/4 | T | +------+ | S | | C | | RG-2 |====================| | +---+ +------+ PPP connection +---+ Figure 11: PPP Broadband Access 4.6.2. PPP deployment considerations for GI-DS-lite o The BRAS will register a unique softwire-id (SID) with the DSLTC for any PPP access session o For deployments which use a single PPP session between gateway (i.e. BRAS) and access device (i.e. RG) the BRAS will differentiate IPv4 and IPv6 traffic. Only IPv4 traffic will be forwarded to (and received from) the softwire tunnel. IPv6 will be routed normally. o PPP access sessions can either be identified through the virtual access interface created for each individual PPP session on the gateway, or (in case of PPPoE) through the PPPoE Session ID (along with the source and destination MAC address). o Assignment of the dummy IPv4 address to the RGs could continue to use IPCP. Alternatively, the IPCP phase could be omitted and dummy IPv4 addresses could be configured through an out-of-band process. 4.7. Ethernet VLAN based access architectures The TR-101 technical report of the Broadband Forum (BBF)[TR101] outlines multiple architecture options for Ethernet-based DSL aggregation networks. Figure 12 shows an example: End-systems (a.k.a. routing gateway, "RG") are connected through access nodes ("AN") to the gateways (a.k.a. broadband network gateway, "BNG"). One architectural option uses point to point VLANs between the AD (typically referred to as RG - routing gateway - in BBF terms) and Brockners & Gundavelli Expires April 16, 2010 [Page 17] Internet-Draft Gateway-Initiated DS-Lite October 2009 the GW (typically referred to as BNG - broadband network gateway - in BBF terms). The point to point VLAN assumes the role of the generic, per end-system access tunnel. The combination of S-VLAN and C-VLAN uniquely identify the connection between AD and GW on the gateway. 4.7.1. Ethernet access deployment overview for GI-DS-lite +------+ C-VLAN +---+ C-VLAN/S-VLAN +---+ | RG-1 |========| |===============| | +---+ +------+ | | | | | D | | A | | B | DS-Lite Tunnel | S | | N | | N |==================| L | | | | G |IPv4-o-GRE-IPv6/4 | T | +------+ | | | | | C | | RG-2 |========| |===============| | +---+ +------+ C-VLAN +---+ C-VLAN/S-VLAN +---+ Figure 12: Ethernet Broadband Access, P2P VLANs 4.7.2. Ethernet access deployment considerations for GI-DS-lite o The BNG will register a unique softwire-id (SID) with the DSLTC for any access session. o Access sessions can be identified by the S-VLAN and C-VLAN tags. o For deployments which use a single VLAN between gateway (i.e. BRAS) and access device (i.e. RG) carrying both, IPv4 and IPv6 traffic, the BNG will differentiate IPv4 and IPv6 traffic (e.g. based on Ethertype). Only IPv4 traffic will be forwarded to (and received from) the softwire tunnel. IPv6 will be routed normally. o Assignment of the dummy IPv4 address to the RGs could use DHCP. Alternatively, the dummy IPv4 address could be configured through an out-of-band process. If DHCP is used, the DHCP server needs to differentiate between requests from GW-DS-lite connected clients (for which only a dummy IPv4 address would be assigned) normal clients. 5. Acknowledgements The authors would like to acknowledge the prior discussions on this topic with Mark Grayson, Jay Iyer, Kent Leung, Vojislav Vucetic, Flemming Andreasen, and Eric Voit. Brockners & Gundavelli Expires April 16, 2010 [Page 18] Internet-Draft Gateway-Initiated DS-Lite October 2009 6. IANA Considerations This memo includes no request to IANA. All drafts are required to have an IANA considerations section (see the update of RFC 2434 [RFC5226] for a guide). If the draft does not require IANA to do anything, the section contains an explicit statement that this is the case (as above). If there are no requirements for IANA, the section will be removed during conversion into an RFC by the RFC Editor. 7. Security Considerations All the security considerations from the Mobile IPv6 [RFC3775], Proxy Mobile IPv6 [RFC5213], and Dual-Stack lite [I-D.ietf-softwire-dual-stack-lite] apply to this specification as well. 8. References 8.1. Normative References [I-D.ietf-softwire-dual-stack-lite] Durand, A., Droms, R., Haberman, B., Woodyatt, J., Lee, Y., and R. Bush, "Dual-stack lite broadband deployments post IPv4 exhaustion", draft-ietf-softwire-dual-stack-lite-01 (work in progress), July 2009. [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000. [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", RFC 2890, September 2000. [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. Brockners & Gundavelli Expires April 16, 2010 [Page 19] Internet-Draft Gateway-Initiated DS-Lite October 2009 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. [RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and Routers", RFC 5555, June 2009. 8.2. Informative References [I-D.draft-ietf-dime-nat-control] Brockners, F., Bhandari, S., Singh, V., and V. Fajardo, "Diameter NAT Control Application", August 2009. [I-D.ietf-netlmm-grekey-option] Muhanna, A., Khalil, M., Gundavelli, S., and K. Leung, "GRE Key Option for Proxy Mobile IPv6", draft-ietf-netlmm-grekey-option-09 (work in progress), May 2009. [I-D.ietf-netlmm-pmip6-ipv4-support] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-17 (work in progress), September 2009. [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998. [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [TR101] Broadband Forum, "TR-101: Migration to Ethernet-Based DSL Aggregation", April 2006. [TR59] Broadband Forum, "TR-059: DSL Evolution - Architecture Requirements for the Support of QoS-Enabled IP Services", September 2003. [TS23401] "3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access.", 2009. Brockners & Gundavelli Expires April 16, 2010 [Page 20] Internet-Draft Gateway-Initiated DS-Lite October 2009 Authors' Addresses Frank Brockners Cisco Hansaallee 249, 3rd Floor DUESSELDORF, NORDRHEIN-WESTFALEN 40549 Germany Email: fbrockne@cisco.com Sri Gundavelli Cisco 170 West Tasman Drive San Jose, CA 95134 USA Email: sgundave@cisco.com Brockners & Gundavelli Expires April 16, 2010 [Page 21]