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]