Internet Engineering Task Force                             F. Brockners
Internet-Draft                                             S. Gundavelli
Intended status: Standards Track                                   Cisco
Expires: April 28, 2011                                      S. Speicher
                                                     Deutsche Telekom AG
                                                                 D. Ward
                                                        Juniper Networks
                                                        October 25, 2010


              Gateway Initiated Dual-Stack Lite Deployment
              draft-ietf-softwire-gateway-init-ds-lite-02

Abstract

   Gateway-Initiated Dual-Stack lite (GI-DS-lite) is a variant of Dual-
   Stack lite (DS-lite) applicable to certain tunnel-based access
   architectures.  GI-DS-lite extends existing access tunnels beyond the
   access gateway to an IPv4-IPv4 NAT using softwires with an embedded
   context identifier that uniquely identifies the end-system the
   tunneled packets belong to.  The access gateway determines which
   portion of the traffic requires NAT using local policies and sends/
   receives this portion to/from this softwire.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

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

   This Internet-Draft will expire on April 28, 2011.

Copyright Notice

   Copyright (c) 2010 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



Brockners, et al.        Expires April 28, 2011                 [Page 1]


Internet-Draft          Gateway-Initiated DS-Lite           October 2010


   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Conventions  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Gateway Initiated DS-Lite  . . . . . . . . . . . . . . . . . .  4
   4.  Protocol and related Considerations  . . . . . . . . . . . . .  6
   5.  Softwire Management and related Considerations . . . . . . . .  7
   6.  Softwire Embodiments . . . . . . . . . . . . . . . . . . . . .  7
   7.  GI-DS-lite deployment  . . . . . . . . . . . . . . . . . . . .  9
     7.1.  Connectivity establishment: Example call flow  . . . . . .  9
     7.2.  GI-DS-lite applicability: Examples . . . . . . . . . . . . 10
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
   10. Security Considerations  . . . . . . . . . . . . . . . . . . . 11
   11. Change History (to be removed prior to publication as an
       RFC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     12.1. Normative References . . . . . . . . . . . . . . . . . . . 12
     12.2. Informative References . . . . . . . . . . . . . . . . . . 13
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14






















Brockners, et al.        Expires April 28, 2011                 [Page 2]


Internet-Draft          Gateway-Initiated DS-Lite           October 2010


1.  Overview

   Gateway-Initiated Dual-Stack lite (GI-DS-lite) is a variant of the
   Dual-Stack lite (DS-lite) [I-D.ietf-softwire-dual-stack-lite],
   applicable to network architectures which use point to point tunnels
   between the access device and the access gateway.  The access gateway
   in these models is designed to serve large numbers of access devices.
   Mobile architectures based on Mobile IPv6 [RFC3775], Proxy Mobile
   IPv6 [RFC5213], or GTP [TS29060], as well as broadband architectures
   based on PPP or point-to-point VLANs as defined by the Broadband
   Forum (see [TR59] and [TR101]) are examples for this type of
   architecture.

   The DS-lite approach leverages IPv4-in-IPv6 tunnels (or other
   tunneling modes) for carrying the IPv4 traffic from the customer
   network to the Address Family Transition Router (AFTR).  An
   established softwire between the AFTR and the access device is used
   for traffic forwarding purposes.  This turns the inner IPv4 address
   irrelevant for traffic routing and allows sharing private IPv4
   addresses [RFC1918] between customer sites within the service
   provider network.

   Similar to DS-lite, GI-DS-lite enables the service provider to share
   public IPv4 addresses among different customers by combining
   tunneling and NAT.  It allows multiple access devices behind the
   access gateway to share the same private IPv4 address [RFC1918].
   Rather than initiating the tunnel right on the access device, GI-DS-
   lite logically extends the already existing access tunnels beyond the
   access gateway towards the IPv4-IPv4 NAT using a tunneling mechanism
   with semantics for carrying context state related to the encapsulated
   traffic.  This approach results in supporting overlapping IPv4
   addresses in the access network, requiring no changes to either the
   access device, or to the access architecture.  Additional tunneling
   overhead in the access network is also omitted.  If e.g., a GRE based
   encapsulation mechanisms is chosen, it allows the network between the
   access gateway and the NAT to be either IPv4 or IPv6 and provides the
   operator to migrate to IPv6 in incremental steps.


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:





Brockners, et al.        Expires April 28, 2011                 [Page 3]


Internet-Draft          Gateway-Initiated DS-Lite           October 2010


      AFTR: Address Family Transition Router (also known as "Large Scale
      NAT (LSN)" or "Dual-Stack lite Tunnel Concentrator", or "Carrier
      Grade NAT").  An AFTR combines IP-in-IP tunnel termination and
      IPv4-IPv4 NAT.

      AD: Access Device.  It is the end host, also known as the mobile
      node in mobile architectures.

      CID: Context Identifier

      DS-lite: Dual-stack lite

      GI-DS-lite: Gateway-initiated DS-lite

      NAT: Network Address Translator

      SW: Softwire (see [RFC4925])

      SWID: Softwire Identifier

      TID: Access Tunnel Identifier.  The interface identifier of the
      point-to-point access tunnel.


3.  Gateway Initiated DS-Lite

   The section provides an overview of Gateway Initiated DS-Lite (GI-DS-
   lite).  Figure 1 outlines the generic deployment scenario for GI-DS-
   lite.  This generic scenario can be mapped to multiple different
   access architectures, some of which are described in Section 7.

   In Figure 1, access devices (AD-1 and AD-2) are connected to the
   Gateway using some form of tunnel technology and the same is used for
   carrying IPv4 (and optionally IPv6) traffic of the access device.
   These access devices may also be connected to the Gateway over point-
   to-point links.  The details on how the network delivers the IPv4
   address configuration to the access devices are specific to the
   access architecture and are outside the scope of this document.  With
   GI-DS-lite, Gateway and AFTR are connected by a softwire [RFC4925].
   The softwire is identified by a softwire identifier (SWID).  The form
   of the SWID depends on the tunneling technology used for the
   softwire.  The SWID could e.g. be the endpoints of a GRE-tunnel or a
   VPN-ID, see Section 6 for details.  A Context-Identifier (CID) is
   used to multiplex flows associated with the individual access devices
   onto the softwire.  Local policies at the Gateway determine which
   part of the traffic received from an access device is tunneled over
   the softwire to the AFTR.  The combination of CID and SWID
   (potentially along with other traffic identifiers such as e.g.



Brockners, et al.        Expires April 28, 2011                 [Page 4]


Internet-Draft          Gateway-Initiated DS-Lite           October 2010


   interface, VLAN, port, etc.) serves as common context between Gateway
   and AFTR to uniquely identify flows associated with an access device.
   The CID is typically a 32-bit wide identifier and is assigned by the
   Gateway.  It is retrieved either from a local or remote (e.g.  AAA)
   repository.  Like the SWID, the embodiment of the CID depends on the
   tunnel mode used and the type of the network connecting Gateway and
   AFTR.  If, for example GRE [RFC2784] with "GRE Key and Sequence
   Number Extensions" [RFC2890] is used as softwire technology, the
   network connecting Gateway and AFTR could be either IPv4-only, IPv6-
   only, or a dual-stack IP network.  The CID would be carried within
   the GRE-key field.  See Section 6 for details on different softwire
   types supported with GI-DS-lite.

                        Access Device: AD-1
                        Context Id: CID-1
                                             NAT Mappings:
      IPv4: a.b.c.d            +---+         (CID-1, TCP port1 <->
      +------+ Tunnel (TID-1)  |   |                 e.f.g.h, TCP port2)
      | AD-1 |=================| G |                          +---+
      +------+                 | A |                          | A |
                               | T |    Softwire SWID-1       | F |
                               | E |==========================| T |
      IPv4: a.b.c.d            | W |  (e.g. IPv4-over-GRE     | R |
      +------+                 | A |   over IPv4 or IPv6)     +---+
      | AD-2 |=================| Y |
      +------+ Tunnel (TID-2)  |   |         (CID-2, TCP port3 <->
                               |   |                 e.f.g.h, TCP port4)
                               +---+

                        Access Device: AD-2
                        Context Id: CID-2


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

   The AFTR combines softwire termination and IPv4-IPv4 NAT.  The outer/
   external IPv4 address of a NAT-binding at the AFTR is either assigned
   autonomously by the AFTR from a local address pool, configured on a
   per-binding basis (either by a remote control entity through a NAT
   control protocol or through manual configuration), or derived from
   the CID (e.g., the CID, in case 32-bit wide, could be mapped 1:1 to
   an external IPv4-address).  A simple example of a translation table
   at the AFTR is shown in Figure 2.  The choice of the appropriate
   translation scheme for a traffic flow can take parameters such as
   destination IP-address, incoming interface, etc. into account.  The
   IP-address of the AFTR, which, depending on the transport network
   between the Gateway and the AFTR, will either be an IPv6 or an IPv4
   address, is configured on the Gateway.  A variety of methods, such as



Brockners, et al.        Expires April 28, 2011                 [Page 5]


Internet-Draft          Gateway-Initiated DS-Lite           October 2010


   out-of-band mechanisms, or manual configuration apply.


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


              Figure 2: Example translation table on the AFTR

   GI-DS-lite does not require a 1:1 relationship between Gateway and
   AFTR, but more generally applies to (M:N) scenarios, where M Gateways
   are connected to N AFTRs.  Multiple Gateways could be served by a
   single AFTR.  AFTRs could be dedicated to specifc groups of access-
   devices, groups of Gateways, or geographic regions.  An AFTR could,
   but does not have to be co-located with a Gateway.


4.  Protocol and related Considerations

   o  The NAT binding entry maintained at the AFTR, which reflects an
      active flow between an access device inside the network and a node
      in the Internet, needs to be extended to include two other
      parameters, the CID and the identifier of the softwire (SWID).

   o  When creating an IPv4 to IPv4 NAT binding for an IPv4 packet flow
      received from the Gateway over the softwire, the AFTR will
      associate the CID with that NAT binding.  It will use the
      combination of CID and SWID as the unique identifier and will
      store it in the NAT binding entry.

   o  When forwarding a packet to the access device, the AFTR will
      obtain the CID from the NAT binding associated with that flow.
      E.g., in case of GRE-encapsulation, it will add the CID to the GRE
      Key and Sequence number extension of the GRE header and tunnel it
      to the Gateway.

   o  On receiving any packet from the softwire, the AFTR will obtain
      the CID from the incoming packet and will use it for performing
      the NAT binding look up and for performing the packet translation
      before forwarding the packet.

   o  The Gateway, on receiving any IPv4 packet from the access device
      will lookup the CID for that access device.  In case of GRE



Brockners, et al.        Expires April 28, 2011                 [Page 6]


Internet-Draft          Gateway-Initiated DS-Lite           October 2010


      encapsulation it will for example add the CID to the GRE Key and
      Sequence number extension of the GRE header and tunnel it to the
      AFTR.

   o  On receiving any packet from the softwire, the Gateway will obtain
      the CID from the packet and will use it for making the forwarding
      decision.  There will be an association between the CID and the
      forwarding state.

   o  When encapsulating and IPv4 packet, Gateway and AFTR can its
      Diffserv Codepoint (DSCP) to derive the DSCP (or MPLS Traffic-
      Class Field in case of MPLS) of the softwire.


5.  Softwire Management and related Considerations

   The following are the considerations related to the operational
   management of the softwire between AFTR and Gateway.

   o  The softwire between the Gateway and the AFTR is created at system
      startup time and stays up active all time.  Deployment dependent,
      Gateway and AFTR can employ OAM mechanisms such as ICMP, BFD
      [RFC5880], or LSP ping [RFC4379] for softwire health management
      and corresponding protection strategies.

   o  The softwire peers may be provisioned to perform policy
      enforcement, such as for determining the protocol-type or overall
      portion of traffic that gets tunneled, or for any other quality of
      service related settings.  The specific details on how this is
      achieved or the types of policies that can be applied are outside
      the scope for this document.

   o  The softwire peers must have a proper understanding of the path
      MTU value.  This can be statically configured at softwire creation
      time.

   o  A Gateway and an AFTR can have multiple softwires established
      between them (e.g. to separate address domains, provide for load-
      sharing etc.).


6.  Softwire Embodiments

   Deployment and requirements dependent, different tunnel technologies
   apply for the softwire connecting Gateway and AFTR.  GRE
   encapsulation with GRE-key extensions, MPLS VPNs, or plain IP-in-IP
   encapsulation can be used.  Softwire identification and Context-ID
   depend on the tunneling technology employed:



Brockners, et al.        Expires April 28, 2011                 [Page 7]


Internet-Draft          Gateway-Initiated DS-Lite           October 2010


   o  GRE with GRE-key extensions: Softwire identification is supplied
      by the endpoints of the GRE tunnel.  The GRE-key serves as CID.

   o  MPLS VPN: Softwire identification is supplied by the VPN
      identifier of the MPLS VPN.  The IPv4-address serves as CID.  The
      IPv4-address within a VPN has to be unique.

   o  Plain IP-in-IP: Softwire identification is supplied by the
      endpoints of the IP-in-IP tunnel.  Either the inner IPv4-address
      serves as CID (in which case the IPv4-address has to be unique) or
      the IPv6-Flow-Label serves as CID (which obviously only applies to
      cases where IPv6 transport is used).  Note that when using the IP-
      Flow-Label as CID additional scaling considerations might apply
      given that the CID is to only 20 bits wide in this case.  Also one
      should ensure sufficient randomization in this case to for example
      avoid interference with other uses of the IP-Flow-Label, such as
      ECMP.

   Figure 3 gives an overview of the different tunnel modes as they
   apply to different deployment scenarios. "x" indicates that a certain
   deployment scenario is supported.  The following abbreviations are
   used:

   o  IPv4 address

      *  "up": Deployments with "unique private IPv4 addresses" assigned
         to the access devices are supported.

      *  "op": Deployments with "overlapping private IPv4 addresses"
         assigned to the access devices are supported.

      *  "nm": Deployments with "non-meaningful/dummy but unique IPv4
         addresses" assigned to the access devices are supported.

      *  "s": Deployments where all access devices are assigned the same
         IPv4 address are supported.

   o  Network-type

      *  "v4": Gateway and AFTR are connected by an IPv4-only network

      *  "v6": Gateway and AFTR are connected by an IPv6-only network

      *  "v4v6": Gateway and AFTR are connected by a dual stack network,
         supporting IPv4 and IPv4.

      *  "MPLS": Gateway and AFTR are connected by a MPLS network




Brockners, et al.        Expires April 28, 2011                 [Page 8]


Internet-Draft          Gateway-Initiated DS-Lite           October 2010


      +==================+==================+=======================+
      |                  | IPv4 address     |      Network-type     |
      |    Softwire      +----+----+----+---+----+----+------+------+
      |                  | up | op | nm | s | v4 | v6 | v4v6 | MPLS |
      +==================+====+====+====+===+====+====+======+======+
      | GRE with GRE-key |  x |  x |  x | x |  x |  x |   x  |      |
      | MPLS VPN         |  x |  x |  x |   |    |    |      |   x  |
      | Plain IP-in-IP   |  x |  x |  x | x |  x |  x |   x  |      |
      +==================+====+====+====+===+====+====+======+======+


              Figure 3: Tunnel modes and their applicability

   Note: For "Plain IP-in-IP", support for 'op' and 's' requires the use
   of IPv6-transport with the IPv6-Flow-Label serving as CID.


7.  GI-DS-lite deployment

7.1.  Connectivity establishment: Example call flow

   Figure 4 shows an example call flow - linking access tunnel
   establishment on the Gateway with the softwire to the AFTR.  This
   simple example assumes that traffic from the AD uses a single access
   tunnel and that the Gateway will use local polices to decide which
   portion of the traffic received over this access tunnel needs to be
   forwarded to the AFTR.

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


           Figure 4: Example call flow for session establishment

   1.  Gateway receives a request to create an access tunnel endpoint.

   2.  The Gateway 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 GI-DS-lite.




Brockners, et al.        Expires April 28, 2011                 [Page 9]


Internet-Draft          Gateway-Initiated DS-Lite           October 2010


   3.  The Gateway creates an access tunnel endpoint.  The access tunnel
       links AD and Gateway and is uniquely identified by Tunnel
       Identifier (TID) on the Gateway.

   4.  (Optional): The Gateway and the AFTR establish a control session
       between each other.  This session can for example be used to
       exchange accounting or NAT-configuration information.  Accounting
       information could be supplied to the Gateway, 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 Gateway allocates a unique CID and associates those flows
       received from the access tunnel (identified by the TID) that need
       to be tunneled towards the AFTR with the softwire linking Gateway
       and AFTR.  Local forwarding policy on the Gateway determines
       which traffic will need to be tunneled towards the AFTR.

   6.  Gateway and AD complete the access tunnel establishment
       (depending on the procedures and mechanisms of the corresponding
       access network architecture this step can include the assignment
       of an IPv4 address to the AD).

7.2.  GI-DS-lite applicability: Examples

   The section outlines deployment examples of the generic GI-DS-lite
   architecture described in Section 3.

   o  Mobile IP based access architectures: In a MIPv6 [RFC5555] based
      network scenario, the Mobile IPv6 home agent will implement the
      GI-DS-lite Gateway function along with the dual-stack Mobile IPv6
      functionality.

   o  Proxy Mobile IP based access architectures: In a PMIPv6 [RFC5213]
      scenario the local mobility anchor (LMA) will implement the GI-DS-
      lite Gateway function along with the PMIPv6 IPv4 support
      functionality.

   o  GTP based access architectures: 3GPP TS 23.401 [TS23401] and 3GPP
      TS 23.060 [TS23060] define mobile access architectures using GTP.
      For GI-DS-lite, the PDN-Gateway/GGSN will also assume the Gateway
      function.

   o  Fixed WiMAX architecture: If GI-DS-lite is applied to fixed WiMAX,
      the ASN-Gateway will implement the GI-DS-lite Gateway function.




Brockners, et al.        Expires April 28, 2011                [Page 10]


Internet-Draft          Gateway-Initiated DS-Lite           October 2010


   o  Mobile WiMAX: If GI-DS-lite is applied to mobile WiMAX, the home
      agent will implement the Gateway function.

   o  PPP-based broadband access architectures: If GI-DS-lite is applied
      to PPP-based access architectures the Broadband Remote Access
      Server (BRAS) or Broadband Network Gateway (BNG) will implement
      the GI-DS-lite Gateway function.

   o  In broadband access architectures using per-subscriber VLANs the
      BNG will implement the GI-DS-lite Gateway function.


8.  Acknowledgements

   The authors would like to acknowledge the discussions on this topic
   with Mark Grayson, Jay Iyer, Kent Leung, Vojislav Vucetic, Flemming
   Andreasen, Dan Wing, Jouni Korhonen, Teemu Savolainen, Parviz Yegani,
   Farooq Bari, Mohamed Boucadair, Vinod Pandey, Jari Arkko, Eric Voit,
   Yiu L. Lee, Tina Tsou, Guo-Liang Yang, and Cathy Zhou.


9.  IANA Considerations

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


10.  Security Considerations

   All the security considerations from GTP [TS29060], Mobile IPv6
   [RFC3775], Proxy Mobile IPv6 [RFC5213], and Dual-Stack lite
   [I-D.ietf-softwire-dual-stack-lite] apply to this specification as
   well.


11.  Change History (to be removed prior to publication as an RFC)

   Changes from -00 to -01

   a.  clarified the applicability of GI-DS-lite to scenarios with M
       Gateways and N AFTRs.




Brockners, et al.        Expires April 28, 2011                [Page 11]


Internet-Draft          Gateway-Initiated DS-Lite           October 2010


   b.  clarification of the nomenclature and use of the identifier of
       the softwire connecting Gateway and AFTR: Introduced softwire
       identifier (SWID), updated figure 2 accordingly.

   c.  cleanup of editorial nits.

   d.  added IP-Flow-Label as CID.

   Changes from -00 to -02

   a.  added considerations for the use of the IP-Flow-Label as CID.

   b.  editorial edits (additional acknowledgements).


12.  References

12.1.  Normative References

   [I-D.ietf-softwire-dual-stack-lite]
              Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
              Stack Lite Broadband Deployments Following IPv4
              Exhaustion", draft-ietf-softwire-dual-stack-lite-06 (work
              in progress), August 2010.

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

   [RFC4379]  Kompella, K. and G. Swallow, "Detecting Multi-Protocol
              Label Switched (MPLS) Data Plane Failures", RFC 4379,
              February 2006.

   [RFC5213]  Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
              and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.



Brockners, et al.        Expires April 28, 2011                [Page 12]


Internet-Draft          Gateway-Initiated DS-Lite           October 2010


   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.

   [RFC5555]  Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and
              Routers", RFC 5555, June 2009.

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

   [RFC5880]  Katz, D. and D. Ward, "Bidirectional Forwarding Detection
              (BFD)", RFC 5880, June 2010.

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

   [RFC3031]  Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
              Label Switching Architecture", RFC 3031, January 2001.

   [RFC3032]  Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
              Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
              Encoding", RFC 3032, January 2001.

   [RFC4925]  Li, X., Dawkins, S., Ward, D., and A. Durand, "Softwire
              Problem Statement", RFC 4925, July 2007.

   [RFC5036]  Andersson, L., Minei, I., and B. Thomas, "LDP
              Specification", RFC 5036, October 2007.

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

   [TS23060]  "3rd Generation Partnership Project; Technical
              Specification Group Services and System Aspects; General
              Packet Radio Service (GPRS); Service description; Stage
              2.", 2009.

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



Brockners, et al.        Expires April 28, 2011                [Page 13]


Internet-Draft          Gateway-Initiated DS-Lite           October 2010


              access.", 2009.

   [TS29060]  "3rd Generation Partnership Project; Technical
              Specification Group Core Network and Terminals; General
              Packet Radio Service (GPRS); GPRS Tunnelling Protocol
              (GTP), V9.1.0", 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


   Sebastian Speicher
   Deutsche Telekom AG
   Landgrabenweg 151
   BONN, NORDRHEIN-WESTFALEN  53277
   Germany

   Email: sebastian.speicher@telekom.de


   David Ward
   Juniper Networks
   1194 N. Mathilda Ave.
   Sunnyvale, California  94089-1206
   USA

   Email: dward@juniper.net







Brockners, et al.        Expires April 28, 2011                [Page 14]