Gateway Initiated Dual-Stack Lite Deployment
draft-gundavelli-softwire-gateway-init-ds-lite-01

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 29, 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 (DS-lite) has been proposed as an IPv4 to IPv6 transition technique. Dual-stack lite allows a service provider to migrate his network to IPv6, while still offering IPv4 services to the customer. The dual-stack lite solution uses an IPv4-over-IPv6 tunnel between a host (or access device) and a dual-stack lite Carrier Grade NAT (CGN). Several existing network architectures (e.g. 3GPP, WiMAX, or PPP based broadband networks) already specify dual-stack deployment and leverage tunneling schemes between the access device and an access gateway in the provider network. Applying the 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 CGN using softwires. This evolved approach not only applies to IPv6 networks but also includes support for IPv4 networks.

Table of Contents

1.  Overview
2.  Conventions
3.  Gateway Initiated DS-Lite
    3.1.  Generic deployment scenario of GI-DS-lite
    3.2.  Considerations for the gateway
    3.3.  Considerations for the softwire tunnel
    3.4.  Considerations for the CGN
    3.5.  Connectivity establishment: Example call flow
4.  Example Deployment Scenarios
    4.1.  Mobile IP based access architectures
        4.1.1.  MIPv6 deployment overview for GI-DS-lite
        4.1.2.  MIPv6 deployment considerations for GI-DS-lite
    4.2.  Proxy Mobile IP based access architectures
        4.2.1.  PMIPv6 deployment overview for GI-DS-lite
        4.2.2.  PMIPv6 deployment considerations for GI-DS-lite
    4.3.  GTP based access architectures
        4.3.1.  GTP deployment overview for GI-DS-lite
        4.3.2.  GTP deployment considerations for GI-DS-lite
    4.4.  Fixed WiMAX access architecture
        4.4.1.  Fixed-WiMAX deployment overview for GI-DS-lite
        4.4.2.  Fixed-WiMAX deployment considerations for GI-DS-lite
    4.5.  Mobile WiMAX access architecture
        4.5.1.  Mobile-WiMAX deployment overview for GI-DS-lite
        4.5.2.  Mobile-WiMAX deployment considerations for GI-DS-lite
    4.6.  PPP-based access architectures
        4.6.1.  PPP deployment overview for GI-DS-lite
        4.6.2.  PPP deployment considerations for GI-DS-lite
    4.7.  Ethernet VLAN based access architectures
        4.7.1.  Ethernet access deployment overview for GI-DS-lite
        4.7.2.  Ethernet access deployment considerations for GI-DS-lite
5.  Acknowledgements
6.  IANA Considerations
7.  Security Considerations
8.  References
    8.1.  Normative References
    8.2.  Informative References
§  Authors' Addresses

1.  Overview

The dual-stack model is a method for transitioning from IPv4 to IPv6. Architecture specifications for fixed and mobile networks (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) architecture approach [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,” July 2009.)) aims at operators that look for a solution to public IPv4-address exhaustion and have migrated their network to solely support IPv6 but still desire to provide IPv4 service access to their customers (this scenario assumes that the CGN function is placed at the boundary to the IPv4-Internet - alternate approaches are discussed in [I‑D.boucadair‑dslite‑interco‑v4v6] (Boucadair, M., Jacquenet, C., Grimault, J., Kassi-Lahlou, M., Levis, P., Cheng, D., and Y. Lee, “Deploying Dual-Stack lite in IPv6-only Network,” October 2009.)). DS-lite allows for operational models where the IPv4 addresses assigned to the end-systems are non-unique with the service provider network. Network deployments without an IPv4 addressing infrastructure become feasible, because all end-systems could use the same IPv4 address (if so desired). 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 CGN.

Several network architectures which support dual-stack end-systems already leverage some form of tunneling technology. Mobile architectures based on Mobile IPv6 [RFC3775] (Johnson, D., Perkins, C., and J. Arkko, “Mobility Support in IPv6,” June 2004.), Proxy Mobile IPv6 [RFC5213] (Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, “Proxy Mobile IPv6,” August 2008.), or GTP [TS29060] (, “3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; General Packet Radio Service (GPRS); GPRS Tunnelling Protocol (GTP), V6.9.0,” 2006.) 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 an 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 DS-lite concept to architectures which support dual-stack end-systems and employ tunneling to offer IPv4 connectivity:

• 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 completion, DS-lite cannot be used as the only means to provide IPv4 connectivity.
• 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: One example policy could be to use DS-lite only if IPv4 address allocation via the normal procedures failed.
• Additional overhead: 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. air-link in mobile networks).

This draft defines a modified implementation of DS-lite: Gateway-initiated DS-lite (GI-DS-lite). 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 CGN. It complements existing tunnel-based access architectures by extending the access tunnels on the gateway terminating the access tunnels to the DS-lite CGN 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:

• 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 CGN.
• GI-DS-lite does not introduce additional connection overhead (e.g. overhead on the air-link and on the transport network between base station and access gateway when providing IPv4 connectivity to the end-system in a mobile network).
• GI-DS-lite approach allows the network operator to deploy either IPv4 or IPv6 in the network core. GI-DS-lite thus expands the original DS-lite concept [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,” July 2009.) to also support IPv4 transport networks. GI-DS-lite with IPv4 transport enables a provider to use overlapping or bogus IPv4 addresses for the end-systems when deploying NAT44, because the IPv4 address of the end-system is no longer used for forwarding operations.

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] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

The following abbreviations are used within this document:

AD: Access Device

CGN: Carrier Grade NAT (also known as "Large Scale NAT (LSN)" or "Dual-Stack lite Tunnel Concentrator")

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 (Gateway-initiated dual-stack lite reference architecture) 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 (Example Deployment Scenarios). Access devices (e.g. AD-1, AD-2) connect to the gateway using some form of tunnel technology to carry IPv4, IPv6 or both. Tunnels can be identified by some form of tunnel identifier, here described as "tunnel identifier (TID)". Gateway and CGN are connected using a softwire tunnel to allow for IPv4 packet transport between Gateway and CGN over IPv6 or IPv4. 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 the softwire tunnel to the CGN to facilitate IPv4 forwarding. Different from the original DS-lite approach, a single softwire with GRE [RFC2784] (Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, “Generic Routing Encapsulation (GRE),” March 2000.) or L2TPv3 [RFC3931] (Lau, J., Townsley, M., and I. Goyret, “Layer Two Tunneling Protocol - Version 3 (L2TPv3),” March 2005.), [RFC5641] (McGill, N. and C. Pignataro, “Layer 2 Tunneling Protocol Version 3 (L2TPv3) Extended Circuit Status Values,” August 2009.) encapsulation is used to carry all IPv4 traffic destined for the CGN from all ADs. IPv4-over-GRE (or IPv4-over-L2TPv3) or IPv6-over-GRE (or IPv6-over-L2TPv3) encapsulation is used to differentiate flows from different access devices within the softwire tunnel.

3.1.  Generic deployment scenario of GI-DS-lite

                     Access Tunnel: TID-1
                     Softwire Id: SID-1
                                          NAT Mappings:
IPv4: a.b.c.d               +---+         (SID-1: a.b.c.d, TCP port1;
+------+    Tunnel (TID-1)  |   |                 e.f.g.h, TCP port2)
| AD-1 |====================| G |
+------+                    | A |                          +---+
                            | T |    Softwire tunnel       | C |
                            | E |==========================| G |
IPv4: a.b.c.d               | W |  IPv4-over-GRE/L2TPv3    | N |
+------+                    | A |   over IPv4 or IPv6      +---+
| AD-2 |====================| Y |
+------+    Tunnel (TID-2)  |   |         (SID-2: a.b.c.d, TCP port3;
                            |   |                 e.f.g.h, TCP port4)
                            +---+
                       Access Tunnel: TID-2
                       Softwire Id: SID-2

3.2.  Considerations for the gateway

The gateway (GW) terminates access tunnels and associates them with a softwire tunnel connecting to the CGN.

• 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] (Soliman, H., “Mobile IPv6 Support for Dual Stack Hosts and Routers,” June 2009.). Similar to the original DS-lite concept, the IPv4 address assigned to the access device is not necessarily needed neither for forwarding decisions nor for tunnel identification. Deployment dependent, if so desired, the gateway could 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.
• The gateway maintains a unique softwire-id (SID) for traffic flows received on access tunnels that require the GI-DS-lite function. The SID is used as a context identifier. The SID ensures a unique identification for the various traffic flows at the CGN. It can be used either independently or in conjunction with other traffic identifiers such as e.g. interface, VLAN, etc. The CGN uses the SID, potentially along with these other identifiers to identify the correct entry in the NAT-binding table. The SID can be generated locally by the gateway or it can be obtained from a policy store.
• The gateway uses the SID when tunneling the access device's IPv4 packets to the CGN. It will also use the SID (potentially with other parameters and the use of local filters) to determine the access tunnel that IPv4 packets received from the CGN need to be sent to. If GRE encapsulation is used, the SID is carried in the GRE "Key and Sequence Number Extension" [RFC2890] (Dommety, G., “Key and Sequence Number Extensions to GRE,” September 2000.). The sequence number field is not required to be set for this purpose. For L2TPv3, the SID is carried as L2TPv3 Session ID (see (Lau, J., Townsley, M., and I. Goyret, “Layer Two Tunneling Protocol - Version 3 (L2TPv3),” March 2005.) [RFC3931], section 4.1).
• Traffic forwarding from GW to CGN leverages tunneling. The gateway will encapsulate the IPv4 datagram inside the IPv4-over-GRE-IPv6 (or IPv4-over-L2TPv3-IPv6) softwire, or IPv4-over-GRE-IPv4 (or IPv4-over-L2TPv3-IPv4) softwire, and will forward the resulting IPv6 or IPv4 datagram to the CGN. The GRE key encapsulation is performed as specified in [RFC2890] (Dommety, G., “Key and Sequence Number Extensions to GRE,” September 2000.) and the key field in the Key and Sequence Number extension of the GRE header will be set to the SID of the corresponding traffic flow. L2TPv3 encapsulation follows [RFC3931] (Lau, J., Townsley, M., and I. Goyret, “Layer Two Tunneling Protocol - Version 3 (L2TPv3),” March 2005.), [RFC5641] (McGill, N. and C. Pignataro, “Layer 2 Tunneling Protocol Version 3 (L2TPv3) Extended Circuit Status Values,” August 2009.).
• The gateway uses locally available policy and filtering to determine the traffic destined for the CGN. In its simplest form, there could be a 1:1 relationship between access and softwire-tunnel, i.e., all traffic received from an access tunnel will be forwarded onto the softwire tunnel and vice versa.
• The gateway will de-capsulate any IPv4 packets received from the softwire tunnel established between the gateway and the CGN. It will use the SID derived from the GRE key field (or L2TPv3 Session ID field) for identifying the access tunnel, to which the packet needs to be forwarded.
• The IP address (which, depending on the transport network between the GW and the CGN, will either be and IPv6 or and IPv4 address) of the CGN can be configured on the gateway using a variety of methods, including out-of-band mechanisms, or manual configuration.

Figure 2 (Example forwarding association at the gateway ) shows the binding entries maintained by the gateway linking the access tunnel and the softwire for the simple example shown above. It assumes a single tunnel per access device, identified by a tunnel identifier (TID), and a one to one mapping between access and softwire tunnels. In this case, the gateway simply stitches access tunnels to softwire tunnels.

+========+===================+=================+
|   AD   |   Softwire-Id     |    Tunnel ID    |
+========+===================+=================+
|  AD-1  |     SID-1         |      TID-1      |
|        |                   |                 |
|  AD-2  |     SID-2         |      TID-2      |
+----------------------------+-----------------+

3.3.  Considerations for the softwire tunnel

GI-DS-lite requires GW and CGN to implement GRE encapsulation (see [RFC2784] (Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, “Generic Routing Encapsulation (GRE),” March 2000.)) with GRE key and sequence number extensions (see [RFC2890] (Dommety, G., “Key and Sequence Number Extensions to GRE,” September 2000.)) over IPv6 or IPv4 (depending on the transport network between GW and CGN). The GRE key MUST be included for GRE encapsulation. AlAlternatively, L2TPv3 [RFC3931] (Lau, J., Townsley, M., and I. Goyret, “Layer Two Tunneling Protocol - Version 3 (L2TPv3),” March 2005.), [RFC5641] (McGill, N. and C. Pignataro, “Layer 2 Tunneling Protocol Version 3 (L2TPv3) Extended Circuit Status Values,” August 2009.) encapsulation can be used. The GRE key or L2TPv3 Session ID represents the unique SID which is used by the gateway and CGN to differentiate flows from and to different access devices. Figure 3 (Softwire tunnel encapsulation) shows the encapsulations for IPv4 and IPv6 transport. Service providers who deploy an IPv6 only transport network will leverage the IPv4-over-GRE-IPv6 (or IPv4-over-L2TPv3-IPv6) option, whereas IPv4-over-GRE-IPv4 (or IPv4-over-L2TPv3-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 |
+-----------------------+     +-----------------------+

3.4.  Considerations for the CGN

As specified in Section 4.7 of [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,” July 2009.), the CGN is a special IPv4 to IPv4 NAT deployed in the edge of the service provider network. For GI-DS-lite it is assumed to be reachable by the gateway through either an IPv4 or an IPv6 transport network. It exchanges user traffic with the gateway using IPv4 over IPv4 or IPv6 encapsulation, either with GRE or L2TPv3 encapsulation.

• When creating a IPv4 to IPv4 NAT binding for an IPv4 packet flow received from the gateway over the IPv4-over-GRE or IPv4-over-L2TPv3 tunnel, the CGN leverages the SID received within the packet, along with other identifiers such as for example interface, VLAN, Port, etc. to define the inner portion of the NAT binding.
• When forwarding the packets through the softwire tunnel to the gateway, the SID associated with that NAT binding will be added to the key field in the GRE Key and Sequence number extension of the GRE header or alternatively, if L2TPv3 is used, into the Session ID field of the L2TPv3 header.
• The CGN decapsulates any IPv4 packets received inside the softwire tunnel established between the gateway and the CGN. It uses the SID from the GRE key field of the GRE key extension (or alternatively the L2TPv3 Session ID) along with other parameters such as interface, VLAN, port etc. to identify the appropriate NAT binding.
• This specification does not introduce any new considerations for dealing with flows that are not sent with the tunnel header containing the GRE key or L2TPv3 Session ID, default considerations should apply in such scenario.

Figure 4 (Example translation table on the CGN) shows a simple translation table at the CGN for the example above. Both access devices are assigned the same IPv4 address, a.b.c.d. The SID (i.e., the GRE key) differentiates flows for the different accesses devices AD-1 and AD-2.

+============================+=========================+
| Softwire-Id/IPv4/Port      |    Public IPv4/Port     |
+============================+=========================+
|  SID-1/a.b.c.d/TCP port1   |    e.f.g.h/TCP port2    |
|                            |                         |
|  SID-2/a.b.c.d/TCP port3   |    e.f.g.h/TCP port4    |
+----------------------------+-------------------------+

3.5.  Connectivity establishment: Example call flow

Figure 5 (Example call flow for session establishment) shows an example call flow - linking access tunnel establishment on the gateway with softwire tunneling to the CGN. This simple example assumes that traffic from the AD uses a single access tunnel and that the gateway will forward all traffic received over this access tunnel to the CGN.

 AD              GW            AAA/Policy       CGN
 |                |                 |            |
 |----(1)-------->|                 |            |
 |               (2)<-------------->|            |
 |               (3)                |            |
 |                |<------(4)------------------->|
 |               (5)                |            |
 |<---(6)-------->|                 |            |
 |                |                 |            |

1. Gateway (GW) receives a request to create an access tunnel endpoint.
2. The GW authenticates and authorizes the access tunnel. 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 tunnel endpoint. The access tunnel links AD and GW and is uniquely identified by Tunnel Identifier (TID) on the GW.
4. (Optional): The GW and the CGN 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] (Brockners, F., Bhandari, S., Singh, V., and V. Fajardo, “Diameter NAT Control Application,” August 2009.) could for example be used for this purpose.
5. The GW allocates a unique SID and associates the access tunnel (identified by the TID) with the softwire linking GW and CGN. Local forwarding policy on the gateway defines that all traffic received on the access tunnel is forwarded onto the softwire tunnel facing the CGN - and vice versa.
6. GW and AD complete the access tunnel 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] (Soliman, H., “Mobile IPv6 Support for Dual Stack Hosts and Routers,” June 2009.) 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.

4.1.1.  MIPv6 deployment overview for GI-DS-lite

                            +---+
                            |   |
+------+  DSMIP Tunnel      | H |
| MN-1 |====================| O |
+------+                    | M |                        +---+
                            | E |    DS-Lite Tunnel      | C |
                            |   |========================| G |
                            | A |  IPv4-over-GRE-IPv6/4  | N |
+------+                    | G |                        +---+
| MN-2 |====================| E |
+------+  DSMIP Tunnel      | N |
                            | T |
                            +---+

4.1.2.  MIPv6 deployment considerations for GI-DS-lite

• The Mobile IPv6 home agent will register a unique softwire-id (SID) with the CGN for any of the flows associated with a given mobile node.
• GI-DS-lite offers a solution for those operators who desire to assign the same IPv4 private address from the [RFC1918] (Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, “Address Allocation for Private Internets,” February 1996.) 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] (Soliman, H., “Mobile IPv6 Support for Dual Stack Hosts and Routers,” June 2009.), even when these assigned addresses are from a private IPv4 address space [RFC1918] (Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, “Address Allocation for Private Internets,” February 1996.).
  • When multiple home agents managed by a mobile operator is sharing an overlapping private IPv4 address space, there is a need for NAT [RFC3022] (Srisuresh, P. and K. Egevang, “Traditional IP Network Address Translator (Traditional NAT),” January 2001.) 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] (Muhanna, A., Khalil, M., Gundavelli, S., and K. Leung, “GRE Key Option for Proxy Mobile IPv6,” May 2009.) 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.

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 |
+------+
   |
+------+                 +-----+                          +---+
|  M   |  PMIPv6 Tunnel  |  L  |  Dual-stack Lite Tunnel  | C |
|  A   |=================|  M  |==========================| G |
|  G   |                 |  A  |   IPv4-over-GRE-IPv6/4   | N |
+------+                 +-----+                          +---+
   |
+------+
| MN-2 |
+------+

4.2.2.  PMIPv6 deployment considerations for GI-DS-lite

• The LMA will register a unique softwire-id with the CGN for any of the flows associated with a given mobile node. It will use the SID as the key identifier for associating 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 CGN.

4.3.  GTP based access architectures

3GPP TS 23.401 [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.) 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 CGN is identical.

4.3.1.  GTP deployment overview for GI-DS-lite

+------+
| MN-1 |
+------+
   |
+------+                 +-----+                          +---+
|  S   |    GTP Tunnel   |  P  |  Dual-stack Lite Tunnel  | C |
|  G   |=================|  G  |==========================| G |
|  W   |                 |  W  |   IPv4-over-GRE-IPv6/4   | N |
+------+                 +-----+                          +---+
   |
+------+
| MN-2 |
+------+

4.3.2.  GTP deployment considerations for GI-DS-lite

• The PDN-gateway will register a unique softwire-id (SID) with the CGN for any of the flows associated with a given mobile node. It will use the SID as the key identifier for associating the two tunnels, the tunnel between the Serving-gateway (SGW) and the PDN-gateway and the tunnel between the PDN-gateway and the CGN.
• Tunnel Endpoint Identifier (TEID) for GTPv1 or the Tunnel Identifier (TID) for GTPv0 can be used as TID.
• In case of an IP-version agnostic access tunnel (i.e. EPS-bearer, 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.

4.4.1.  Fixed-WiMAX deployment overview for GI-DS-lite

                            +---+
                            |   |
+------+        R1          |   |
| MS-1 |--------------------| A |
+------+                    | S |                        +---+
                            | N |    DS-Lite Tunnel      | C |
                            |   |========================| G |
                            | G |  IPv4-over-GRE-IPv6/4  | N |
+------+                    | W |                        +---+
| MS-2 |--------------------|   |
+------+        R1          |   |
                            |   |
                            +---+

4.4.2.  Fixed-WiMAX deployment considerations for GI-DS-lite

• The ASN-gateway will register a unique softwire-id (SID) with the CGN 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.

4.5.1.  Mobile-WiMAX deployment overview for GI-DS-lite

   +------+
   | MN-1 |
   +------+
      |
      |
   +------+
   |      |
   |  A   |                 +-----+                          +---+
   |  S   |  R3             |     |   DS Lite Tunnel         | C |
   |  N   |=================|  H  |==========================| G |
   |      |                 |  A  |   IPv4-over-GRE-IPv6/4   | N |
   |  G   |                 |     |                          +---+
   |  W   |                 +-----+
   |      |
   +------+
      |
      |
   +------+
   | MN-2 |
   +------+

4.5.2.  Mobile-WiMAX deployment considerations for GI-DS-lite

• The home agent will register a unique softwire-id (SID) with the CGN 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] (Broadband Forum, “TR-059: DSL Evolution - Architecture Requirements for the Support of QoS-Enabled IP Services,” September 2003.) 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 ) (Broadband Forum, “TR-101: Migration to Ethernet-Based DSL Aggregation,” April 2006.) [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 choose to either use a single PPP connection to provide connectivity for both, IPv4 and IPv6, or the operator deploys a PPP connection per IP protocol version. The later option results in the establishment of two PPP connections per AD. An alternate approach for NAT44 deployment in PPP-based access architectures, which places the NAT44 function into the gateway, can be found in [I‑D.miles‑behave‑l2nat] (Miles, D. and M. Townsley, “Layer2-Aware NAT,” March 2009.).

4.6.1.  PPP deployment overview for GI-DS-lite

+------+  PPP connection    +---+
| RG-1 |====================|   |
+------+                    |   |                        +---+
                            | B |   DS-Lite Tunnel       | C |
                            | R |========================| G |
                            | A |  IPv4-over-GRE-IPv6/4  | N |
+------+                    | S |                        +---+
| RG-2 |====================|   |
+------+  PPP connection    +---+

4.6.2.  PPP deployment considerations for GI-DS-lite

• The BRAS will typically register a unique TID with the CGN for any PPP access session
• 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.
• 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).
• 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] (Broadband Forum, “TR-101: Migration to Ethernet-Based DSL Aggregation,” April 2006.) outlines multiple architecture options for Ethernet-based DSL aggregation networks. Figure 12 (Ethernet Broadband Access, P2P VLANs) 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 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 |========|   |===============|   |
+------+        |   |               |   |                  +---+
                | A |               | B | DS-Lite Tunnel   | C |
                | N |               | N |==================| G |
                |   |               | G |IPv4-o-GRE-IPv6/4 | N |
+------+        |   |               |   |                  +---+
| RG-2 |========|   |===============|   |
+------+ C-VLAN +---+ C-VLAN/S-VLAN +---+

4.7.2.  Ethernet access deployment considerations for GI-DS-lite

• The BNG will typically register a unique TID with the CGN for any access session.
• Access sessions can be identified by the S-VLAN and C-VLAN tags.
• 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.
• 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 discussions on this topic with Mark Grayson, Jay Iyer, Kent Leung, Vojislav Vucetic, Flemming Andreasen, Eric Voit, and Mohamed Boucadair.

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 (Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs,” May 2008.) [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] (Johnson, D., Perkins, C., and J. Arkko, “Mobility Support in IPv6,” June 2004.), Proxy Mobile IPv6 [RFC5213] (Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, “Proxy Mobile IPv6,” August 2008.), and Dual-Stack lite [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,” July 2009.) apply to this specification as well.

8.  References

8.1. Normative References

8.2. Informative References

Authors' Addresses