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