[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: 00 01 02 03 draft-ietf-softwire-gateway-init-ds-lite

Internet Engineering Task Force                             F. Brockners
Internet-Draft                                             S. Gundavelli
Intended status: Standards Track                                   Cisco
Expires: April 29, 2010                                 October 26, 2009


              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



Brockners & Gundavelli   Expires April 29, 2010                 [Page 1]


Internet-Draft          Gateway-Initiated DS-Lite           October 2009


   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.







































Brockners & Gundavelli   Expires April 29, 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 CGN . . . . . . . . . . . . . . . . 10
     3.5.  Connectivity establishment: Example call flow  . . . . . . 11
   4.  Example Deployment Scenarios . . . . . . . . . . . . . . . . . 12
     4.1.  Mobile IP based access architectures . . . . . . . . . . . 12
       4.1.1.  MIPv6 deployment overview for GI-DS-lite . . . . . . . 13
       4.1.2.  MIPv6 deployment considerations for GI-DS-lite . . . . 13
     4.2.  Proxy Mobile IP based access architectures . . . . . . . . 14
       4.2.1.  PMIPv6 deployment overview for GI-DS-lite  . . . . . . 14
       4.2.2.  PMIPv6 deployment considerations for GI-DS-lite  . . . 14
     4.3.  GTP based access architectures . . . . . . . . . . . . . . 14
       4.3.1.  GTP deployment overview for GI-DS-lite . . . . . . . . 15
       4.3.2.  GTP deployment considerations for GI-DS-lite . . . . . 15
     4.4.  Fixed WiMAX access architecture  . . . . . . . . . . . . . 15
       4.4.1.  Fixed-WiMAX deployment overview for GI-DS-lite . . . . 16
       4.4.2.  Fixed-WiMAX deployment considerations for
               GI-DS-lite . . . . . . . . . . . . . . . . . . . . . . 16
     4.5.  Mobile WiMAX access architecture . . . . . . . . . . . . . 16
       4.5.1.  Mobile-WiMAX deployment overview for GI-DS-lite  . . . 17
       4.5.2.  Mobile-WiMAX deployment considerations for
               GI-DS-lite . . . . . . . . . . . . . . . . . . . . . . 17
     4.6.  PPP-based access architectures . . . . . . . . . . . . . . 17
       4.6.1.  PPP deployment overview for GI-DS-lite . . . . . . . . 18
       4.6.2.  PPP deployment considerations for GI-DS-lite . . . . . 18
     4.7.  Ethernet VLAN based access architectures . . . . . . . . . 18
       4.7.1.  Ethernet access deployment overview for GI-DS-lite . . 19
       4.7.2.  Ethernet access deployment considerations for
               GI-DS-lite . . . . . . . . . . . . . . . . . . . . . . 19
   5.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 20
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 20
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 20
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 21
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23









Brockners & Gundavelli   Expires April 29, 2010                 [Page 3]


Internet-Draft          Gateway-Initiated DS-Lite           October 2009


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]) 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]).
   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], Proxy Mobile IPv6
   [RFC5213], or GTP [TS29060] 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:

   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



Brockners & Gundavelli   Expires April 29, 2010                 [Page 4]


Internet-Draft          Gateway-Initiated DS-Lite           October 2009


      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.

   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: One example policy could be to use
      DS-lite only if IPv4 address allocation via the normal procedures
      failed.

   o  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:






Brockners & Gundavelli   Expires April 29, 2010                 [Page 5]


Internet-Draft          Gateway-Initiated DS-Lite           October 2009


   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
      CGN.

   o  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).

   o  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] 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].

   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 outlines the generic deployment scenario for gateway-
   initiated dual-stack lite.  This generic scenario can be mapped to



Brockners & Gundavelli   Expires April 29, 2010                 [Page 6]


Internet-Draft          Gateway-Initiated DS-Lite           October 2009


   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 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] or L2TPv3 [RFC3931], [RFC5641] 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


    Figure 1: Gateway-initiated dual-stack lite reference architecture

3.2.  Considerations for the gateway

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

   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



Brockners & Gundavelli   Expires April 29, 2010                 [Page 7]


Internet-Draft          Gateway-Initiated DS-Lite           October 2009


      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 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.

   o  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.

   o  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].  The sequence
      number field is not required to be set for this purpose.  For
      L2TPv3, the SID is carried as L2TPv3 Session ID (see [RFC3931],
      section 4.1).

   o  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] 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], [RFC5641].

   o  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



Brockners & Gundavelli   Expires April 29, 2010                 [Page 8]


Internet-Draft          Gateway-Initiated DS-Lite           October 2009


      forwarded onto the softwire tunnel and vice versa.

   o  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.

   o  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 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      |
              +----------------------------+-----------------+


          Figure 2: Example forwarding association at the gateway

3.3.  Considerations for the softwire tunnel

   GI-DS-lite requires GW and CGN 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 CGN).  The GRE key MUST be included for GRE
   encapsulation.  AlAlternatively, L2TPv3 [RFC3931], [RFC5641]
   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
   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



Brockners & Gundavelli   Expires April 29, 2010                 [Page 9]


Internet-Draft          Gateway-Initiated DS-Lite           October 2009


   (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 CGN

   As specified in Section 4.7 of [I-D.ietf-softwire-dual-stack-lite],
   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.

   o  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.

   o  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.

   o  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.





Brockners & Gundavelli   Expires April 29, 2010                [Page 10]


Internet-Draft          Gateway-Initiated DS-Lite           October 2009


   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 or L2TPv3 Session ID, default
      considerations should apply in such scenario.

   Figure 4 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    |
   +----------------------------+-------------------------+


              Figure 4: Example translation table on the CGN

3.5.  Connectivity establishment: Example call flow

   Figure 5 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)-------->|                 |            |
              |                |                 |            |


           Figure 5: Example call flow for session establishment

   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



Brockners & Gundavelli   Expires April 29, 2010                [Page 11]


Internet-Draft          Gateway-Initiated DS-Lite           October 2009


       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] 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]
   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 29, 2010                [Page 12]


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 |                        +---+
                               | E |    DS-Lite Tunnel      | C |
                               |   |========================| G |
                               | A |  IPv4-over-GRE-IPv6/4  | N |
   +------+                    | G |                        +---+
   | 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 CGN 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 29, 2010                [Page 13]


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













Brockners & Gundavelli   Expires April 29, 2010                [Page 14]


Internet-Draft          Gateway-Initiated DS-Lite           October 2009


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 |
   +------+

      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
      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.

   o  Tunnel Endpoint Identifier (TEID) for GTPv1 or the Tunnel
      Identifier (TID) for GTPv0 can be used as TID.

   o  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.














Brockners & Gundavelli   Expires April 29, 2010                [Page 15]


Internet-Draft          Gateway-Initiated DS-Lite           October 2009


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          |   |
                               |   |
                               +---+

       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
      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.

























Brockners & Gundavelli   Expires April 29, 2010                [Page 16]


Internet-Draft          Gateway-Initiated DS-Lite           October 2009


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 |
      +------+

       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
      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]
   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 choose to either use a single
   PPP connection to provide connectivity for both, IPv4 and IPv6, or



Brockners & Gundavelli   Expires April 29, 2010                [Page 17]


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.  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].

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    +---+

                      Figure 11: PPP Broadband Access

4.6.2.  PPP deployment considerations for GI-DS-lite

   o  The BRAS will typically register a unique TID with the CGN 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").



Brockners & Gundavelli   Expires April 29, 2010                [Page 18]


Internet-Draft          Gateway-Initiated DS-Lite           October 2009


   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 +---+

              Figure 12: Ethernet Broadband Access, P2P VLANs

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

   o  The BNG will typically register a unique TID with the CGN 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 discussions on this topic
   with Mark Grayson, Jay Iyer, Kent Leung, Vojislav Vucetic, Flemming
   Andreasen, Eric Voit, and Mohamed Boucadair.



Brockners & Gundavelli   Expires April 29, 2010                [Page 19]


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 29, 2010                [Page 20]


Internet-Draft          Gateway-Initiated DS-Lite           October 2009


   [RFC3931]  Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling
              Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005.

   [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.

   [RFC5641]  McGill, N. and C. Pignataro, "Layer 2 Tunneling Protocol
              Version 3 (L2TPv3) Extended Circuit Status Values",
              RFC 5641, August 2009.

8.2.  Informative References

   [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",
              draft-boucadair-dslite-interco-v4v6-02 (work in progress),
              October 2009.

   [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-behave-address-format]
              Huitema, C., Bao, C., Bagnulo, M., Boucadair, M., and X.
              Li, "IPv6 Addressing of IPv4/IPv6 Translators",
              draft-ietf-behave-address-format-00 (work in progress),
              August 2009.

   [I-D.ietf-behave-v6v4-framework]
              Baker, F., Li, X., Bao, C., and K. Yin, "Framework for
              IPv4/IPv6 Translation",
              draft-ietf-behave-v6v4-framework-03 (work in progress),
              October 2009.

   [I-D.ietf-behave-v6v4-xlate]
              Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
              Algorithm", draft-ietf-behave-v6v4-xlate-03 (work in
              progress), October 2009.

   [I-D.ietf-behave-v6v4-xlate-stateful]
              Bagnulo, M., Matthews, P., and I. Beijnum, "NAT64: Network
              Address and Protocol Translation from IPv6 Clients to IPv4
              Servers", draft-ietf-behave-v6v4-xlate-stateful-02 (work
              in progress), October 2009.



Brockners & Gundavelli   Expires April 29, 2010                [Page 21]


Internet-Draft          Gateway-Initiated DS-Lite           October 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.

   [I-D.miles-behave-l2nat]
              Miles, D. and M. Townsley, "Layer2-Aware NAT",
              draft-miles-behave-l2nat-00 (work in progress),
              March 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.

   [RFC5565]  Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh
              Framework", RFC 5565, June 2009.

   [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.

   [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.




Brockners & Gundavelli   Expires April 29, 2010                [Page 22]


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 29, 2010                [Page 23]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/