One document matched: draft-gundavelli-softwire-gateway-init-ds-lite-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY RFC3022 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3022.xml">
<!ENTITY RFC3552 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3552.xml">
<!ENTITY RFC1918 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1918.xml">
<!ENTITY RFC2473 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2473.xml">
<!ENTITY RFC2784 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2784.xml">
<!ENTITY RFC2890 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2890.xml">
<!ENTITY RFC3775 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3775.xml">
<!ENTITY RFC3931 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3931.xml">
<!ENTITY RFC5213 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5213.xml">
<!ENTITY RFC5555 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5555.xml">
<!ENTITY RFC5565 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5565.xml">
<!ENTITY RFC5641 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5641.xml">
<!ENTITY I-D.draft-ietf-netlmm-pmip6-ipv4-support SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-netlmm-pmip6-ipv4-support-17.xml">
<!ENTITY I-D.draft-ietf-softwire-dual-stack-lite SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-softwire-dual-stack-lite-01.xml">
<!ENTITY I-D.draft-ietf-netlmm-grekey-option SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-netlmm-grekey-option-09.xml">
<!ENTITY I-D.draft-ietf-behave-v6v4-framework SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-behave-v6v4-framework-03.xml">
<!ENTITY I-D.draft-ietf-behave-v6v4-xlate-stateful SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-behave-v6v4-xlate-stateful-02.xml">
<!ENTITY I-D.draft-ietf-behave-v6v4-xlate SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-behave-v6v4-xlate-03.xml">
<!ENTITY I-D.draft-ietf-behave-address-format SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-behave-address-format-00.xml">
<!ENTITY I-D.draft-sarikaya-softwire-dslitemobility SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-sarikaya-softwire-dslitemobility-00.xml">
<!ENTITY I-D.draft-miles-behave-l2nat SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-miles-behave-l2nat-00.xml">
<!ENTITY I-D.draft-boucadair-dslite-interco-v4v6 SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-boucadair-dslite-interco-v4v6-02.xml">
<!ENTITY I-D.draft-baker-behave-ivi SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-baker-behave-ivi-01.xml">
<!ENTITY RFC5226 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5226.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std"
docName="draft-gundavelli-softwire-gateway-init-ds-lite-01"
ipr="trust200902">
<!-- ipr="full3978"-->
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="Gateway-Initiated DS-Lite">Gateway Initiated Dual-Stack
Lite Deployment</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Frank Brockners" initials="F." surname="Brockners">
<organization>Cisco</organization>
<address>
<postal>
<street>Hansaallee 249, 3rd Floor</street>
<!-- Reorder these if your country does things differently -->
<city>DUESSELDORF</city>
<region>NORDRHEIN-WESTFALEN</region>
<code>40549</code>
<country>Germany</country>
</postal>
<email>fbrockne@cisco.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Sri Gundavelli" initials="S." surname="Gundavelli">
<organization>Cisco</organization>
<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>USA</country>
</postal>
<email>sgundave@cisco.com</email>
</address>
</author>
<date month="October" year="2009" />
<!-- If the month and year are both specified and are the current ones, xml2rfc will fill
in the current day for you. If only the current year is specified, xml2rfc will fill
in the current day and month for you. If the year is not the current one, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
purpose of calculating the expiry date). With drafts it is normally sufficient to
specify just the year. -->
<!-- Meta-data Declarations -->
<area>General</area>
<workgroup>Internet Engineering Task Force</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<keyword>ds-lite</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>Dual-Stack lite (DS-lite) has been proposed as an IPv4 to IPv6
transition technique. Dual-stack lite allows a service provider to
migrate his network to IPv6, while still offering IPv4 services to the
customer. The dual-stack lite solution uses an IPv4-over-IPv6 tunnel
between a host (or access device) and a dual-stack lite Carrier Grade
NAT (CGN). Several existing network architectures (e.g. 3GPP, WiMAX, or
PPP based broadband networks) already specify dual-stack deployment and
leverage tunneling schemes between the access device and an access
gateway in the provider network. Applying the dual-stack lite concept to
these networks will result in changes to the end-system and unnecessary
tunneling overhead. This draft describes a modified implementation of
dual-stack lite where existing access tunnels are extended beyond the
access gateway to the dual-stack lite CGN using softwires. This evolved
approach not only applies to IPv6 networks but also includes support for
IPv4 networks.</t>
</abstract>
</front>
<middle>
<section title="Overview" toc="default">
<t>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.</t>
<t>The "Dual-Stack lite" (DS-lite) architecture approach <xref
target="I-D.ietf-softwire-dual-stack-lite"></xref>) 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 <xref
target="I-D.boucadair-dslite-interco-v4v6"></xref>). 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.</t>
<t>Several network architectures which support dual-stack end-systems
already leverage some form of tunneling technology. Mobile architectures
based on Mobile IPv6 <xref target="RFC3775"></xref>, Proxy Mobile IPv6
<xref target="RFC5213"></xref>, or GTP <xref target="TS29060"></xref>
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:</t>
<t><list style="symbols">
<t>The end-systems are required to change in order to add support
for DS-lite. While easily done for some deployments (e.g. in case of
managed end-systems, support can be achieved through a software
upgrade), large scale change of end-systems can require replacing
the installed base with devices which support DS-lite. End-system
replacement could incur significant cost for the service provider
and could also take time to be completed - potentially slowing down
the migration to IPv6 in the service provider network. Until
completion, DS-lite cannot be used as the only means to provide IPv4
connectivity.</t>
<t>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.</t>
<t>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).</t>
</list>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:</t>
<t><list style="symbols">
<t>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.</t>
<t>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).</t>
<t>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 <xref
target="I-D.ietf-softwire-dual-stack-lite"></xref> 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.</t>
</list></t>
</section>
<section anchor="Conventions" title="Conventions">
<t>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 <xref
target="RFC2119"></xref>.</t>
<t>The following abbreviations are used within this document:</t>
<t><list style="empty">
<t>AD: Access Device</t>
<t>CGN: Carrier Grade NAT (also known as "Large Scale NAT (LSN)" or
"Dual-Stack lite Tunnel Concentrator")</t>
<t>DS-lite: Dual-stack lite</t>
<t>GI-DS-lite: Gateway-initiated DS-lite</t>
<t>GW: Gateway</t>
<t>SID: Softwire Identifier</t>
<t>TID: Tunnel Identifier</t>
</list></t>
</section>
<section anchor="GI-DS-lite" title="Gateway Initiated DS-Lite">
<t><xref target="fig-generic"></xref> 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 <xref target="example_deployments"></xref>. 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 <xref target="RFC2784"></xref> or L2TPv3 <xref
target="RFC3931"></xref>, <xref target="RFC5641"></xref> 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.</t>
<section title="Generic deployment scenario of GI-DS-lite">
<figure anchor="fig-generic"
title="Gateway-initiated dual-stack lite reference architecture">
<artwork><![CDATA[
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
]]></artwork>
</figure>
</section>
<section title="Considerations for the gateway">
<t>The gateway (GW) terminates access tunnels and associates them with
a softwire tunnel connecting to the CGN.</t>
<t><list style="symbols">
<t>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
<xref target="RFC5555"></xref>. 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.</t>
<t>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.</t>
<t>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" <xref
target="RFC2890"></xref>. The sequence number field is not
required to be set for this purpose. For L2TPv3, the SID is
carried as L2TPv3 Session ID (<xref target="RFC3931">see</xref>,
section 4.1).</t>
<t>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 <xref
target="RFC2890"></xref> 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 <xref
target="RFC3931"></xref>, <xref target="RFC5641"></xref>.</t>
<t>The gateway uses locally available policy and filtering to
determine the traffic destined for the CGN. In its simplest form,
there could be a 1:1 relationship between access and
softwire-tunnel, i.e., all traffic received from an access tunnel
will be forwarded onto the softwire tunnel and vice versa.</t>
<t>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.</t>
<t>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.</t>
</list></t>
<t><xref target="fig-binding-entries"></xref> 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.</t>
<figure align="center" anchor="fig-binding-entries"
title="Example forwarding association at the gateway ">
<artwork><![CDATA[
+========+===================+=================+
| AD | Softwire-Id | Tunnel ID |
+========+===================+=================+
| AD-1 | SID-1 | TID-1 |
| | | |
| AD-2 | SID-2 | TID-2 |
+----------------------------+-----------------+
]]></artwork>
</figure>
</section>
<section title="Considerations for the softwire tunnel">
<t>GI-DS-lite requires GW and CGN to implement GRE encapsulation (see
<xref target="RFC2784"></xref>) with GRE key and sequence number
extensions (see <xref target="RFC2890"></xref>) over IPv6 or IPv4
(depending on the transport network between GW and CGN). The GRE key
MUST be included for GRE encapsulation. AlAlternatively, L2TPv3 <xref
target="RFC3931"></xref>, <xref target="RFC5641"></xref> 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. <xref target="fig-encap"></xref>
shows the encapsulations for IPv4 and IPv6 transport. Service
providers who deploy an IPv6 only transport network will leverage the
IPv4-over-GRE-IPv6 (or IPv4-over-L2TPv3-IPv6) option, whereas
IPv4-over-GRE-IPv4 (or IPv4-over-L2TPv3-IPv4) could for example be
used by operators who desire to introduce IPv4-to-IPv4 NAT into their
network (e.g. because of the exhaustion of their global IPv4 address
space), but want to avoid the use of distinct private IPv4 addresses
for the access devices.</t>
<figure anchor="fig-encap" title="Softwire tunnel encapsulation">
<artwork><![CDATA[
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 |
+-----------------------+ +-----------------------+
]]></artwork>
</figure>
</section>
<section title="Considerations for the CGN">
<t>As specified in Section 4.7 of <xref
target="I-D.ietf-softwire-dual-stack-lite"></xref>, 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.</t>
<t><list style="symbols">
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
</list></t>
<t><xref target="fig-translation_table"></xref> 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.</t>
<figure anchor="fig-translation_table"
title="Example translation table on the CGN">
<artwork><![CDATA[
+============================+=========================+
| 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 |
+----------------------------+-------------------------+
]]></artwork>
</figure>
</section>
<section title="Connectivity establishment: Example call flow">
<t><xref target="fig-callflow"></xref> 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.</t>
<figure align="center" anchor="fig-callflow"
title="Example call flow for session establishment">
<artwork><![CDATA[
AD GW AAA/Policy CGN
| | | |
|----(1)-------->| | |
| (2)<-------------->| |
| (3) | |
| |<------(4)------------------->|
| (5) | |
|<---(6)-------->| | |
| | | |
]]></artwork>
</figure>
<t><list style="numbers">
<t>Gateway (GW) receives a request to create an access tunnel
endpoint.</t>
<t>The GW authenticates and authorizes the access tunnel. Based on
local policy or through interaction with the AAA/Policy system the
gateway recognizes that IPv4 service should be provided using
DS-lite.</t>
<t>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.</t>
<t>(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 <xref
target="I-D.draft-ietf-dime-nat-control"></xref> could for example
be used for this purpose.</t>
<t>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.</t>
<t>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).</t>
</list></t>
</section>
</section>
<section anchor="example_deployments" title="Example Deployment Scenarios">
<t></t>
<section anchor="Scenario_MIP"
title="Mobile IP based access architectures">
<t>The Mobile IPv6 protocol with the extensions specified in <xref
target="RFC5555"></xref> 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.</t>
<section title="MIPv6 deployment overview for GI-DS-lite">
<figure anchor="fig-mip"
title="Home Agent Initiated Dual-stack lite Mode">
<artwork><![CDATA[
+---+
| |
+------+ 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 |
+---+
]]></artwork>
</figure>
</section>
<section title="MIPv6 deployment considerations for GI-DS-lite">
<t><list style="symbols">
<t>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.</t>
<t>GI-DS-lite offers a solution for those operators who desire
to assign the same IPv4 private address from the <xref
target="RFC1918"></xref> 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.<list style="symbols">
<t>The IPv4 address that the home agent assigns to a mobile
node has to be unique within its scope, as per <xref
target="RFC5555"></xref>, even when these assigned addresses
are from a private IPv4 address space <xref
target="RFC1918"></xref>.</t>
<t>When multiple home agents managed by a mobile operator is
sharing an overlapping private IPv4 address space, there is
a need for NAT <xref target="RFC3022"></xref> 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.</t>
<t>In case of Proxy Mobile IPv6, the GRE Key support <xref
target="I-D.ietf-netlmm-grekey-option"></xref> 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.</t>
</list></t>
</list></t>
</section>
</section>
<section anchor="Scenario_PMIP"
title="Proxy Mobile IP based access architectures">
<t>In this scenario the local mobility anchor (LMA) will implement the
gateway function along with the PMIPv6 IPv4 support functionality.</t>
<section title="PMIPv6 deployment overview for GI-DS-lite">
<figure anchor="fig-pmip"
title="Local Mobility Anchor Initiated Dual-stack lite Mode">
<artwork><![CDATA[
+------+
| MN-1 |
+------+
|
+------+ +-----+ +---+
| M | PMIPv6 Tunnel | L | Dual-stack Lite Tunnel | C |
| A |=================| M |==========================| G |
| G | | A | IPv4-over-GRE-IPv6/4 | N |
+------+ +-----+ +---+
|
+------+
| MN-2 |
+------+
]]></artwork>
</figure>
</section>
<section title="PMIPv6 deployment considerations for GI-DS-lite">
<t></t>
<t><list style="symbols">
<t>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.</t>
</list></t>
</section>
</section>
<section anchor="Scenario_GTP" title="GTP based access architectures">
<t>3GPP TS 23.401 <xref target="TS23401"></xref> 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.</t>
<section title="GTP deployment overview for GI-DS-lite">
<figure anchor="fig-gtp"
title="3GPP PDN Gateway Initiated Dual-stack lite Mode (GTP)">
<artwork><![CDATA[
+------+
| MN-1 |
+------+
|
+------+ +-----+ +---+
| S | GTP Tunnel | P | Dual-stack Lite Tunnel | C |
| G |=================| G |==========================| G |
| W | | W | IPv4-over-GRE-IPv6/4 | N |
+------+ +-----+ +---+
|
+------+
| MN-2 |
+------+
]]></artwork>
</figure>
</section>
<section title="GTP deployment considerations for GI-DS-lite">
<t><list style="symbols">
<t>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.</t>
<t>Tunnel Endpoint Identifier (TEID) for GTPv1 or the Tunnel
Identifier (TID) for GTPv0 can be used as TID.</t>
<t>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.</t>
</list></t>
</section>
</section>
<section title="Fixed WiMAX access architecture">
<t>In this scenario the ASN-gateway will implement the gateway
function.</t>
<section title="Fixed-WiMAX deployment overview for GI-DS-lite">
<figure anchor="fig-wimax"
title="Fixed-WiMAX Gateway Initiated Dual-stack lite Mode">
<artwork><![CDATA[
+---+
| |
+------+ R1 | |
| MS-1 |--------------------| A |
+------+ | S | +---+
| N | DS-Lite Tunnel | C |
| |========================| G |
| G | IPv4-over-GRE-IPv6/4 | N |
+------+ | W | +---+
| MS-2 |--------------------| |
+------+ R1 | |
| |
+---+
]]></artwork>
</figure>
</section>
<section title="Fixed-WiMAX deployment considerations for GI-DS-lite">
<t><list style="symbols">
<t>The ASN-gateway will register a unique softwire-id (SID) with
the CGN for any of the flows associated with a given mobile
station.</t>
</list></t>
</section>
</section>
<section title="Mobile WiMAX access architecture">
<t>In this scenario the home agent will implement the gateway
function.</t>
<section title="Mobile-WiMAX deployment overview for GI-DS-lite">
<figure anchor="fig-mob-wimax"
title="Fixed-WiMAX Gateway Initiated Dual-stack lite Mode (PMIPv6)">
<artwork><![CDATA[
+------+
| MN-1 |
+------+
|
|
+------+
| |
| A | +-----+ +---+
| S | R3 | | DS Lite Tunnel | C |
| N |=================| H |==========================| G |
| | | A | IPv4-over-GRE-IPv6/4 | N |
| G | | | +---+
| W | +-----+
| |
+------+
|
|
+------+
| MN-2 |
+------+
]]></artwork>
</figure>
</section>
<section title="Mobile-WiMAX deployment considerations for GI-DS-lite">
<t><list style="symbols">
<t>The home agent will register a unique softwire-id (SID) with
the CGN for any of the flows associated with a given mobile
system.</t>
</list></t>
</section>
</section>
<section anchor="Scenario_PPP" title="PPP-based access architectures">
<t>The technical report TR-059 of the Broadband Forum (BBF) (see <xref
target="TR59"></xref> 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
<xref target="TR101">)</xref>). PPP is used to establish a point to
point connection between the end-system (a.k.a., routing gateway,
"RG") and the access gateway (a.k.a. broadband remote access server,
"BRAS"; or broadband network gateway, "BNG"). This means that for
PPP-based access architectures, the device which terminates the
PPP-session (e.g. the Broadband Remote Access Server, BRAS) assumes
the role of the gateway. The PPP connection represents the access
tunnel. The PPP connection can either be identified through the
virtual interface created on the BRAS/BNG or (in case of PPPoE),
through the PPPoE Session-Identifier. Deployment dependent, the
operator will choose to either use a single PPP connection to provide
connectivity for both, IPv4 and IPv6, or the operator deploys a PPP
connection per IP protocol version. The later option results in the
establishment of two PPP connections per AD. An alternate approach for
NAT44 deployment in PPP-based access architectures, which places the
NAT44 function into the gateway, can be found in <xref
target="I-D.miles-behave-l2nat"></xref>.</t>
<section title="PPP deployment overview for GI-DS-lite">
<figure anchor="fig-ppp" title="PPP Broadband Access">
<artwork><![CDATA[
+------+ PPP connection +---+
| RG-1 |====================| |
+------+ | | +---+
| B | DS-Lite Tunnel | C |
| R |========================| G |
| A | IPv4-over-GRE-IPv6/4 | N |
+------+ | S | +---+
| RG-2 |====================| |
+------+ PPP connection +---+]]></artwork>
</figure>
</section>
<section title="PPP deployment considerations for GI-DS-lite">
<t><list style="symbols">
<t>The BRAS will typically register a unique TID with the CGN
for any PPP access session</t>
<t>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.</t>
<t>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).</t>
<t>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.</t>
</list></t>
</section>
</section>
<section anchor="Scenario_Ethernet"
title="Ethernet VLAN based access architectures">
<t>The TR-101 technical report of the Broadband Forum (BBF)<xref
target="TR101"> </xref> outlines multiple architecture options for
Ethernet-based DSL aggregation networks. <xref
target="fig-ethernet"></xref> shows an example: End-systems (a.k.a.
routing gateway, "RG") are connected through access nodes ("AN") to
the gateways (a.k.a. broadband network gateway, "BNG"). One
architectural option uses point to point VLANs between the AD
(typically referred to as RG - routing gateway - in BBF terms) and the
GW (typically referred to as BNG - broadband network gateway - in BBF
terms). The point to point VLAN assumes the role of the generic, per
end-system access tunnel. The combination of S-VLAN and C-VLAN
uniquely identify the connection between AD and GW on the gateway.</t>
<section title="Ethernet access deployment overview for GI-DS-lite">
<t></t>
<figure anchor="fig-ethernet"
title="Ethernet Broadband Access, P2P VLANs">
<artwork><![CDATA[
+------+ 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 +---+]]></artwork>
</figure>
</section>
<section title="Ethernet access deployment considerations for GI-DS-lite">
<t><list style="symbols">
<t>The BNG will typically register a unique TID with the CGN for
any access session.</t>
<t>Access sessions can be identified by the S-VLAN and C-VLAN
tags.</t>
<t>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.</t>
<t>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.</t>
</list></t>
</section>
</section>
</section>
<!-- -->
<section anchor="Acknowledgements" title="Acknowledgements">
<t>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.</t>
</section>
<!-- Possibly a 'Contributors' section ... -->
<section anchor="IANA" title="IANA Considerations">
<t>This memo includes no request to IANA.</t>
<t>All drafts are required to have an IANA considerations section (see
<xref target="RFC5226">the update of RFC 2434</xref> 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.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>All the security considerations from the Mobile IPv6 <xref
target="RFC3775"></xref>, Proxy Mobile IPv6 <xref
target="RFC5213"></xref>, and Dual-Stack lite <xref
target="I-D.ietf-softwire-dual-stack-lite"></xref> apply to this
specification as well.</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation libraries:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included files in the same
directory as the including file. You can also define the XML_LIBRARY environment variable
with a value containing a set of directories to search. These can be either in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references title="Normative References">
<!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
&RFC2119;
&RFC1918;
&RFC2890;
&RFC3775;
&RFC3931;
&RFC5213;
&RFC5555;
&RFC2784;
&RFC5641;
&I-D.draft-ietf-softwire-dual-stack-lite;
</references>
<references title="Informative References">
&I-D.draft-ietf-netlmm-grekey-option;
&I-D.draft-ietf-netlmm-pmip6-ipv4-support;
&I-D.draft-ietf-behave-v6v4-framework;
&I-D.draft-ietf-behave-v6v4-xlate-stateful;
&I-D.draft-ietf-behave-v6v4-xlate;
&I-D.draft-ietf-behave-address-format;
&I-D.draft-miles-behave-l2nat;
&I-D.draft-boucadair-dslite-interco-v4v6;
<reference anchor="I-D.draft-ietf-dime-nat-control">
<front>
<title>Diameter NAT Control Application</title>
<author fullname="Frank Brockners" initials="F." surname="Brockners">
<organization></organization>
</author>
<author fullname="Shwetha Bhandari" initials="S." surname="Bhandari">
<organization></organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email></email>
<uri></uri>
</address>
</author>
<author fullname="Vaneeta Singh" initials="V." surname="Singh">
<organization></organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email></email>
<uri></uri>
</address>
</author>
<author fullname="Victor Fajardo" initials="V." surname="Fajardo">
<organization></organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email></email>
<uri></uri>
</address>
</author>
<date day="24" month="August" year="2009" />
</front>
</reference>
<reference anchor="TR59">
<front>
<title>TR-059: DSL Evolution - Architecture Requirements for the
Support of QoS-Enabled IP Services</title>
<author fullname="Broadband Forum" surname="Broadband Forum">
<organization></organization>
</author>
<date month="September" year="2003" />
</front>
</reference>
<reference anchor="TR101">
<front>
<title>TR-101: Migration to Ethernet-Based DSL Aggregation</title>
<author fullname="Broadband Forum" surname="Broadband Forum">
<organization></organization>
</author>
<date month="April" year="2006" />
</front>
</reference>
<reference anchor="TS23401">
<front>
<title>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.</title>
<author fullname="3GPP TS 23.401">
<organization></organization>
</author>
<date year="2009" />
</front>
</reference>
<reference anchor="TS29060">
<front>
<title>3rd Generation Partnership Project; Technical Specification
Group Core Network and Terminals; General Packet Radio Service
(GPRS); GPRS Tunnelling Protocol (GTP), V6.9.0</title>
<author fullname="3GPP TS 29.060">
<organization></organization>
</author>
<date year="2006" />
</front>
</reference>
&RFC2473;
&RFC5565;
&RFC3022;
&RFC5226;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 02:55:17 |