One document matched: draft-ietf-softwire-gateway-init-ds-lite-05.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 RFC3031 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3031.xml">
<!ENTITY RFC3032 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3032.xml">
<!ENTITY RFC5036 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5036.xml">
<!ENTITY RFC3552 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3552.xml">
<!ENTITY RFC3697 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3697.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 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 RFC4379 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4379.xml">
<!ENTITY RFC4364 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4364.xml">
<!ENTITY RFC4925 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4925.xml">
<!ENTITY RFC5880 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5880.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-11.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-ietf-softwire-gateway-init-ds-lite-05"
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>
<author fullname="Sebastian Speicher" initials="S." surname="Speicher">
<organization>Deutsche Telekom AG</organization>
<address>
<postal>
<street>Landgrabenweg 151</street>
<city>BONN</city>
<region>NORDRHEIN-WESTFALEN</region>
<code>53277</code>
<country>Germany</country>
</postal>
<email>sebastian.speicher@telekom.de</email>
</address>
</author>
<author fullname="David Ward" initials="D." surname="Ward">
<organization>Juniper Networks</organization>
<address>
<postal>
<street>1194 N. Mathilda Ave.</street>
<city>Sunnyvale</city>
<region>California</region>
<code>94089-1206</code>
<country>USA</country>
</postal>
<email>dward@juniper.net</email>
</address>
</author>
<date month="July" year="2011" />
<!-- 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>Gateway-Initiated Dual-Stack lite (GI-DS-lite) is a variant of
Dual-Stack lite (DS-lite) applicable to certain tunnel-based access
architectures. GI-DS-lite extends existing access tunnels beyond the
access gateway to an IPv4-IPv4 NAT using softwires with an embedded
context identifier that uniquely identifies the end-system the tunneled
packets belong to. The access gateway determines which portion of the
traffic requires NAT using local policies and sends/receives this
portion to/from this softwire.</t>
</abstract>
</front>
<middle>
<section title="Overview" toc="default">
<t>Gateway-Initiated Dual-Stack lite (GI-DS-lite) is a variant of the
Dual-Stack lite (DS-lite) <xref
target="I-D.ietf-softwire-dual-stack-lite"> </xref>, applicable to
network architectures which use point to point tunnels between the
access device and the access gateway. The access gateway in these models
is designed to serve large numbers of access devices. Mobile
architectures based on Mobile IPv6 <xref target="RFC3775"></xref>, Proxy
Mobile IPv6 <xref target="RFC5213"></xref>, or GTP <xref
target="TS29060"></xref>, as well as broadband architectures based on
PPP or point-to-point VLANs as defined by the Broadband Forum (see <xref
target="TR59"></xref> and <xref target="TR101"></xref>) are examples for
this type of architecture.</t>
<t>The DS-lite approach leverages IPv4-in-IPv6 tunnels (or other
tunneling modes) for carrying the IPv4 traffic from the customer network
to the Address Family Transition Router (AFTR). An established softwire
between the AFTR and the access device is used for traffic forwarding
purposes. This turns the inner IPv4 address irrelevant for traffic
routing and allows sharing private IPv4 addresses <xref
target="RFC1918"></xref> between customer sites within the service
provider network.</t>
<t>Similar to DS-lite, GI-DS-lite enables the service provider to share
public IPv4 addresses among different customers by combining tunneling
and NAT. It allows multiple access devices behind the access gateway to
share the same private IPv4 address <xref target="RFC1918"></xref>.
Rather than initiating the tunnel right on the access device, GI-DS-lite
logically extends the already existing access tunnels beyond the access
gateway towards the Address Family Transition Router (AFTR) using a
tunneling mechanism with semantics for carrying context state related to
the encapsulated traffic. This approach results in supporting
overlapping IPv4 addresses in the access network, requiring no changes
to either the access device, or to the access architecture. Additional
tunneling overhead in the access network is also omitted. If e.g., a GRE
based encapsulation mechanisms is chosen, it allows the network between
the access gateway and the AFTR to be either IPv4 or IPv6 and provides
the operator to migrate to IPv6 in incremental steps.</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>AFTR: Address Family Transition Router. An AFTR combines IP-in-IP
tunnel termination and IPv4-IPv4 NAT.</t>
<t>AD: Access Device. It is the end host, also known as the mobile
node in mobile architectures.</t>
<t>CID: Context Identifier</t>
<t>DS-lite: Dual-stack lite</t>
<t>GI-DS-lite: Gateway-initiated DS-lite</t>
<t>NAT: Network Address Translator</t>
<t>SW: Softwire (see <xref target="RFC4925"></xref>)</t>
<t>SWID: Softwire Identifier</t>
</list></t>
</section>
<section anchor="GI-DS-lite" title="Gateway Initiated DS-Lite">
<t>The section provides an overview of Gateway Initiated DS-Lite
(GI-DS-lite). <xref target="fig-generic"></xref> outlines the generic
deployment scenario for GI-DS-lite. This generic scenario can be mapped
to multiple different access architectures, some of which are described
in <xref target="example_deployments"></xref>.</t>
<t>In <xref target="fig-generic"></xref>, access devices (AD-1 and AD-2)
are connected to the Gateway using some form of tunnel technology and
the same is used for carrying IPv4 (and optionally IPv6) traffic of the
access device. These access devices may also be connected to the Gateway
over point-to-point links. The details on how the network delivers the
IPv4 address configuration to the access devices are specific to the
access architecture and are outside the scope of this document. With
GI-DS-lite, Gateway and AFTR are connected by a softwire <xref
target="RFC4925"></xref>. The softwire is identified by a softwire
identifier (SWID). The SWID does not need to be globally unique, i.e.
different SWIDs could be used to identify a softwire at the different
ends of a softwire. The form of the SWID depends on the tunneling
technology used for the softwire. The SWID could e.g. be the endpoints
of a GRE-tunnel or a VPN-ID, see <xref target="Alt-Tunnels"></xref> for
details. A Context-Identifier (CID) is used to multiplex flows
associated with the individual access devices onto the softwire.
Deployment dependent, the flows from a particular AD can be identified
using either the source IP-address or an access tunnel identifier. Local
policies at the Gateway determine which part of the traffic received
from an access device is tunneled over the softwire to the AFTR. The
combination of CID and SWID must be unique between gateway and AFTR to
identify the flows associated with an AD. The CID is typically a 32-bit
wide identifier and is assigned by the Gateway. It is retrieved either
from a local or remote (e.g. AAA) repository. Like the SWID, the
embodiment of the CID depends on the tunnel mode used and the type of
the network connecting Gateway and AFTR. If, for example GRE <xref
target="RFC2784"></xref> with “GRE Key and Sequence Number
Extensions” <xref target="RFC2890"></xref> is used as softwire
technology, the network connecting Gateway and AFTR could be either
IPv4-only, IPv6-only, or a dual-stack IP network. The CID would be
carried within the GRE-key field. See <xref target="Alt-Tunnels"></xref>
for details on different softwire types supported with GI-DS-lite.</t>
<figure anchor="fig-generic"
title="Gateway-initiated dual-stack lite reference architecture">
<artwork><![CDATA[
Access Device: AD-1
Context Id: CID-1
NAT Mappings:
IPv4: a.b.c.d +---+ (CID-1, TCP port1 <->
+------+ access tunnel | | e.f.g.h, TCP port2)
| AD-1 |=================| G | +---+
+------+ | A | | A |
| T | Softwire SWID-1 | F |
| E |==========================| T |
IPv4: a.b.c.d | W | (e.g. IPv4-over-GRE | R |
+------+ | A | over IPv4 or IPv6) +---+
| AD-2 |=================| Y |
+------+ access tunnel | | (CID-2, TCP port3 <->
| | e.f.g.h, TCP port4)
+---+
Access Device: AD-2
Context Id: CID-2
]]></artwork>
</figure>
<t>The AFTR combines softwire termination and IPv4-IPv4 NAT. The NAT
binding of the AD's address could be assigned autonomously by the AFTR
from a local address pool, configured on a per-binding basis (either by
a remote control entity through a NAT control protocol or through manual
configuration), or derived from the CID (e.g., the CID, in case 32-bit
wide, could be mapped 1:1 to an external IPv4-address). A simple example
of a translation table at the AFTR is shown in <xref
target="fig-translation_table"></xref>. The choice of the appropriate
translation scheme for a traffic flow can take parameters such as
destination IP-address, incoming interface, etc. into account. The
IP-address of the AFTR, which, depending on the transport network
between the Gateway and the AFTR, will either be an IPv6 or an IPv4
address, is configured on the Gateway. A variety of methods, such as
out-of-band mechanisms, or manual configuration apply.</t>
<figure align="center" anchor="fig-translation_table"
title="Example translation table on the AFTR">
<artwork><![CDATA[
+=====================================+======================+
| Softwire-Id/Context-Id/IPv4/Port | Public IPv4/Port |
+=====================================+======================+
| SWID-1/CID-1/a.b.c.d/TCP-port1 | e.f.g.h/TCP-port2 |
| | |
| SWID-1/CID-2/a.b.c.d/TCP-port3 | e.f.g.h/TCP-port4 |
+-------------------------------------+----------------------+
]]></artwork>
</figure>
<t>GI-DS-lite does not require a 1:1 relationship between Gateway and
AFTR, but more generally applies to (M:N) scenarios, where M Gateways
are connected to N AFTRs. Multiple Gateways could be served by a single
AFTR. AFTRs could be dedicated to specifc groups of access-devices,
groups of Gateways, or geographic regions. An AFTR could, but does not
have to be co-located with a Gateway.</t>
</section>
<section anchor="AFTR-Cons" title="Protocol and related Considerations">
<t><list style="symbols">
<t>Depending on the embodiment of the CID (e.g. for
GRE-encapsulation with GRE-key), the NAT binding entry maintained at
the AFTR, which reflects an active flow between an access device
inside the network and a node in the Internet, needs to be extended
to include the CID and the identifier of the softwire (SWID).</t>
<t>When creating an IPv4 to IPv4 NAT binding for an IPv4 packet flow
received from the Gateway over the softwire, the AFTR will associate
the CID with that NAT binding. It will use the combination of CID
and SWID as the unique identifier and will store it in the NAT
binding entry.</t>
<t>When forwarding a packet to the access device, the AFTR will
obtain the CID from the NAT binding associated with that flow. E.g.,
in case of GRE-encapsulation, it will add the CID to the GRE Key and
Sequence number extension of the GRE header and tunnel it to the
Gateway.</t>
<t>On receiving any packet from the softwire, the AFTR will obtain
the CID from the incoming packet and will use it for performing the
NAT binding look up and for performing the packet translation before
forwarding the packet.</t>
<t>The Gateway, on receiving any IPv4 packet from the access device
will lookup the CID for that access device. In case of GRE
encapsulation it will for example add the CID to the GRE Key and
Sequence number extension of the GRE header and tunnel it to the
AFTR.</t>
<t>On receiving any packet from the softwire, the Gateway will
obtain the CID from the packet and will use it for making the
forwarding decision. There will be an association between the CID
and the forwarding state.</t>
<t>When encapsulating an IPv4 packet, Gateway and AFTR can use its
Diffserv Codepoint (DSCP) to derive the DSCP (or MPLS Traffic-Class
Field in case of MPLS) of the softwire.</t>
</list></t>
</section>
<section anchor="Tunnel-Mgmt"
title="Softwire Management and related Considerations">
<t>The following are the considerations related to the operational
management of the softwire between AFTR and Gateway.</t>
<t><list style="symbols">
<t>The softwire between the Gateway and the AFTR MAY be created at
system startup time OR dynamically established on-demand. Deployment
dependent, Gateway and AFTR can employ OAM mechanisms such as ICMP,
BFD <xref target="RFC5880"></xref>, or LSP ping <xref
target="RFC4379"></xref> for softwire health management and
corresponding protection strategies.</t>
<t>The softwire peers may be provisioned to perform policy
enforcement, such as for determining the protocol-type or overall
portion of traffic that gets tunneled, or for any other quality of
service related settings. The specific details on how this is
achieved or the types of policies that can be applied are outside
the scope for this document.</t>
<t>The softwire peers must have a proper understanding of the path
MTU value. This can be statically configured at softwire creation
time.</t>
<t>A Gateway and an AFTR can have multiple softwires established
between them (e.g. to separate address domains, provide for
load-sharing etc.).</t>
</list></t>
</section>
<section anchor="Alt-Tunnels" title="Softwire Embodiments">
<t>Deployment and requirements dependent, different tunnel technologies
apply for the softwire connecting Gateway and AFTR. GRE encapsulation
with GRE-key extensions, MPLS VPNs <xref target="RFC4364"></xref>, or
plain IP-in-IP encapsulation can be used. Softwire identification and
Context-ID depend on the tunneling technology employed:<list
style="symbols">
<t>SWID is the source address of the GRE tunnel from the GW. The CID
is the GRE-key associated with the AD.</t>
<t>MPLS VPN: The SWID is a generic identifier which uniquely
identifies the VPN at either the Gateway or AFTR. Depending on
whether the Gateway or AFTR are acting as CE or PE, the SWID could
e.g. be an attachment circuit identifier, an identifier representing
the set of VPN route labels pointing to the routes within the VPN,
etc. The AD's IPv4-address is the CID. For a given VPN, the AD's
IPv4 address must be unique.</t>
<t>IPv4/IPv6-in-MPLS: The SWID is the top MPLS label. CID might be
the next MPLS label in the stack, if present, or the IP address of
the AD. </t>
<t>IPv4-in-IPv4: SWID is the outer IPv4 source address. The AD's
IPv4 address is the CID. For a given outer IPv4 source address, the
AD's IPv4 address must be unique.</t>
<t>IPv4-in-IPv6: SWID is the outer IPv6 source address. If the AD's
IPv4 address is used as CID, the AD's IPv4 address must be unique.
If the IPv6-Flow-Label <xref target="RFC3697"></xref> is used as
CID, the IPv4 addresses of the ADs may overlap. Given that the
IPv6-Flow-Label is 20-bit wide, which is shorter than the
recommended 32-bit CID, large scale deployments may require
additional scaling considerations. In addition, one should ensure
sufficient randomization of the IP-Flow-Label to avoid possible
interference with other uses of the IP-Flow-Label, such as ECMP.</t>
</list></t>
<t><xref target="fig-encapsulations"></xref> gives an overview of the
different tunnel modes as they apply to different deployment scenarios.
"x" indicates that a certain deployment scenario is supported. The
following abbreviations are used:</t>
<t><list style="symbols">
<t>IPv4 address<list style="symbols">
<t>"up": Deployments with "unique private IPv4 addresses"
assigned to the access devices are supported.</t>
<t>"op": Deployments with "overlapping private IPv4 addresses"
assigned to the access devices are supported.</t>
<t>"nm": Deployments with "non-meaningful/dummy but unique IPv4
addresses" assigned to the access devices are supported.</t>
<t>"s": Deployments where all access devices are assigned the
same IPv4 address are supported.</t>
</list></t>
<t>Network-type<list style="symbols">
<t>"v4": Gateway and AFTR are connected by an IPv4-only
network</t>
<t>"v6": Gateway and AFTR are connected by an IPv6-only
network</t>
<t>"v4v6": Gateway and AFTR are connected by a dual stack
network, supporting IPv4 and IPv4.</t>
<t>"MPLS": Gateway and AFTR are connected by a MPLS network</t>
</list></t>
</list></t>
<figure align="center" anchor="fig-encapsulations"
title="Tunnel modes and their applicability">
<artwork><![CDATA[+====================+==================+=======================+
| | IPv4 address | Network-type |
| Softwire +----+----+----+---+----+----+------+------+
| | up | op | nm | s | v4 | v6 | v4v6 | MPLS |
+====================+====+====+====+===+====+====+======+======+
| GRE with GRE-key | x | x | x | x | x | x | x | |
| MPLS VPN | x | x | x | | | | | x |
| IPv4/IPv6-in-MPLS | x | x | x | x | | | | x |
| IPv4-in-IPv4 | x | | x | | x | | | |
| IPv4-in-IPv6 | x | | x | | | x | | |
| IPv4-in-IPv6 w/ FL | x | x | x | x | | x | | |
+====================+====+====+====+===+====+====+======+======+
]]></artwork>
</figure>
<t></t>
</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, Dan Wing, Jouni Korhonen, Teemu Savolainen, Parviz Yegani,
Farooq Bari, Mohamed Boucadair, Vinod Pandey, Jari Arkko, Eric Voit, Yiu
L. Lee, Tina Tsou, Guo-Liang Yang, Cathy Zhou, Olaf Bonness, Paco
Cortes, and Jim Guichard.</t>
</section>
<!-- Possibly a 'Contributors' section ... -->
<section anchor="IANA" title="IANA Considerations">
<t>This document 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 GTP <xref
target="TS29060"></xref>, 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>
<section title="Change History (to be removed prior to publication as an RFC)">
<t>Changes from -00 to -01</t>
<t><list style="letters">
<t>clarified the applicability of GI-DS-lite to scenarios with M
Gateways and N AFTRs.</t>
<t>clarification of the nomenclature and use of the identifier of
the softwire connecting Gateway and AFTR: Introduced softwire
identifier (SWID), updated figure 2 accordingly.</t>
<t>cleanup of editorial nits.</t>
<t>added IP-Flow-Label as CID.</t>
</list>Changes from -00 to -02</t>
<t><list style="letters">
<t>added considerations for the use of the IP-Flow-Label as CID.</t>
<t>editorial edits (additional acknowledgements).</t>
</list>Changes from -02 to -03</t>
<t><list style="letters">
<t>editorial edits (following WG reviews)</t>
<t>moved section on GI-DS-lite to the annex</t>
</list>Changes from -03 to -04</t>
<t><list style="letters">
<t>clarified the use of MPLS VPN encapsulation</t>
</list><list style="letters">
<t>added plain IPv4/IPv6-in-MPLS</t>
<t>allow for the softwire between Gateway and AFTR to be established
at any point in time (not just at startup)</t>
</list></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;
&RFC3697;
&RFC3775;
&RFC5213;
&RFC5555;
&RFC2784;
&RFC5226;
&RFC4364;
&RFC4379;
&RFC5880;
&I-D.draft-ietf-softwire-dual-stack-lite;
</references>
<references title="Informative References">
&RFC4925;
<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="TS23060">
<front>
<title>3rd Generation Partnership Project; Technical Specification
Group Services and System Aspects; General Packet Radio Service
(GPRS); Service description; Stage 2.</title>
<author fullname="3GPP TS 23.060">
<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), V9.1.0</title>
<author fullname="3GPP TS 29.060">
<organization></organization>
</author>
<date year="2009" />
</front>
</reference>
</references>
<section anchor="example_deployments" title="GI-DS-lite deployment">
<t></t>
<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 the softwire
to the AFTR. This simple example assumes that traffic from the AD uses
a single access tunnel and that the Gateway will use local polices to
decide which portion of the traffic received over this access tunnel
needs to be forwarded to the AFTR.</t>
<figure align="center" anchor="fig-callflow"
title="Example call flow for session establishment">
<artwork><![CDATA[
AD Gateway AAA/Policy AFTR
| | | |
|----(1)-------->| | |
| (2)<-------------->| |
| (3) | |
| |<------(4)------------------->|
| (5) | |
|<---(6)-------->| | |
| | | |
]]></artwork>
</figure>
<t><list style="numbers">
<t>Gateway receives a request to create an access tunnel
endpoint.</t>
<t>The Gateway authenticates and authorizes the access tunnel.
Based on local policy or through interaction with the AAA/Policy
system the Gateway recognizes that IPv4 service should be provided
using GI-DS-lite.</t>
<t>The Gateway creates an access tunnel endpoint. The access
tunnel links AD and Gateway.</t>
<t>(Optional): The Gateway and the AFTR establish a control
session between each other. This session can for example be used
to exchange accounting or NAT-configuration information.
Accounting information could be supplied to the Gateway,
AAA/Policy, or other network entities which require information
about the externally visible address/port pairs of a particular
access device. The Diameter NAT Control Application (see <xref
target="I-D.draft-ietf-dime-nat-control"></xref> could for example
be used for this purpose.</t>
<t>The Gateway allocates a unique CID and associates those flows
received from the access tunnel that need to be tunneled towards
the AFTR with the softwire linking Gateway and AFTR. Local
forwarding policy on the Gateway determines which traffic will
need to be tunneled towards the AFTR.</t>
<t>Gateway and AD complete the access tunnel establishment
(depending on the procedures and mechanisms of the corresponding
access network architecture this step can include the assignment
of an IPv4 address to the AD).</t>
</list></t>
</section>
<section title="GI-DS-lite applicability: Examples">
<t>The section outlines deployment examples of the generic GI-DS-lite
architecture described in <xref target="GI-DS-lite"></xref>.</t>
<t><list style="symbols">
<t>Mobile IP based access architectures: In a MIPv6 <xref
target="RFC5555"></xref> based network scenario, the Mobile IPv6
home agent will implement the GI-DS-lite Gateway function along
with the dual-stack Mobile IPv6 functionality.</t>
<t>Proxy Mobile IP based access architectures: In a PMIPv6 <xref
target="RFC5213"></xref> scenario the local mobility anchor (LMA)
will implement the GI-DS-lite Gateway function along with the
PMIPv6 IPv4 support functionality.</t>
<t>GTP based access architectures: 3GPP TS 23.401 <xref
target="TS23401"></xref> and 3GPP TS 23.060 <xref
target="TS23060"></xref> define mobile access architectures using
GTP. For GI-DS-lite, the PDN-Gateway/GGSN will also assume the
Gateway function.</t>
<t>Fixed WiMAX architecture: If GI-DS-lite is applied to fixed
WiMAX, the ASN-Gateway will implement the GI-DS-lite Gateway
function.</t>
<t>Mobile WiMAX: If GI-DS-lite is applied to mobile WiMAX, the
home agent will implement the Gateway function.</t>
<t>PPP-based broadband access architectures: If GI-DS-lite is
applied to PPP-based access architectures the Broadband Remote
Access Server (BRAS) or Broadband Network Gateway (BNG) will
implement the GI-DS-lite Gateway function.</t>
<t>In broadband access architectures using per-subscriber VLANs
the BNG will implement the GI-DS-lite Gateway function.</t>
</list></t>
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 04:21:36 |