One document matched: draft-ietf-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 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 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 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-06.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-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>
<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="October" year="2010" />
<!-- 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 IPv4-IPv4 NAT using a tunneling mechanism with
semantics for carrying context state related to the encapsulated
traffic. This approach results in supporting overlapping IPv4 addresses
in the access network, requiring no changes to either the access device,
or to the access architecture. Additional tunneling overhead in the
access network is also omitted. If e.g., a GRE based encapsulation
mechanisms is chosen, it allows the network between the access gateway
and the NAT to be either IPv4 or IPv6 and provides the operator to
migrate to IPv6 in incremental steps.</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 (also known as "Large
Scale NAT (LSN)" or "Dual-Stack lite Tunnel Concentrator", or
"Carrier Grade NAT"). An AFTR combines IP-in-IP tunnel termination
and IPv4-IPv4 NAT.</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>
<t>TID: Access Tunnel Identifier. The interface identifier of the
point-to-point access tunnel.</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 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. Local
policies at the Gateway determine which part of the traffic received
from an access device is tunneled over the softwire to the AFTR. The
combination of CID and SWID (potentially along with other traffic
identifiers such as e.g. interface, VLAN, port, etc.) serves as common
context between Gateway and AFTR to uniquely identify flows associated
with an access device. The CID is 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 <->
+------+ Tunnel (TID-1) | | e.f.g.h, TCP port2)
| AD-1 |=================| G | +---+
+------+ | A | | A |
| T | Softwire SWID-1 | F |
| E |==========================| T |
IPv4: a.b.c.d | W | (e.g. IPv4-over-GRE | R |
+------+ | A | over IPv4 or IPv6) +---+
| AD-2 |=================| Y |
+------+ Tunnel (TID-2) | | (CID-2, TCP port3 <->
| | e.f.g.h, TCP port4)
+---+
Access Device: AD-2
Context Id: CID-2
]]></artwork>
</figure>
<t>The AFTR combines softwire termination and IPv4-IPv4 NAT. The
outer/external IPv4 address of a NAT-binding at the AFTR is either
assigned autonomously by the AFTR from a local address pool, configured
on a per-binding basis (either by a remote control entity through a NAT
control protocol or through manual configuration), or derived from the
CID (e.g., the 32-bit CID 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>
<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>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>The NAT binding entry maintained at the AFTR, which reflects an
active flow between an access device inside the network and a node
in the Internet, needs to be extended to include two other
parameters, the CID and the identifier of the softwire (SWID).</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 and IPv4 packet, Gateway and AFTR can its
Diffserv Codepoint (DSCP) to derive the DSCP (or MPLS Traffic-Class
Field in case of MPLS) of the softwire.</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 is created at
system startup time and stays up active all time. Deployment
dependent, Gateway and AFTR can employ OAM mechanisms such as ICMP,
BFD <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, or plain IP-in-IP encapsulation can
be used. Softwire identification and Context-ID depend on the tunneling
technology employed:<list style="symbols">
<t>GRE with GRE-key extensions: Softwire identification is supplied
by the endpoints of the GRE tunnel. The GRE-key serves as CID.</t>
<t>MPLS VPN: Softwire identification is supplied by the VPN
identifier of the MPLS VPN. The IPv4-address serves as CID. The
IPv4-address within a VPN has to be unique.</t>
<t>Plain IP-in-IP: Softwire identification is supplied by the
endpoints of the IP-in-IP tunnel. Either the inner IPv4-address
serves as CID (in which case the IPv4-address has to be unique) or
the IPv6-Flow-Label serves as CID (which obviously only applies to
cases where IPv6 transport is used).</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 |
| Plain IP-in-IP | x | x | x | x | x | x | x | |
+==================+====+====+====+===+====+====+======+======+
]]></artwork>
</figure>
<t>Note: For "Plain IP-in-IP", support for 'op' and 's' requires the use
of IPv6-transport with the IPv6-Flow-Label serving as CID.</t>
</section>
<section title="new section">
<t></t>
</section>
<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 and is uniquely identified by Tunnel
Identifier (TID) on the 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 (identified by the TID) that need
to be tunneled towards the AFTR with the softwire linking Gateway
and AFTR. Local forwarding policy on the Gateway determines which
traffic will need to be tunneled towards the AFTR.</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>
<!-- -->
<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 and
Yiu L. Lee.</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>
</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;
&RFC3775;
&RFC5213;
&RFC5555;
&RFC2784;
&RFC5226;
&RFC5565;
&RFC4379;
&RFC5880;
&I-D.draft-ietf-softwire-dual-stack-lite;
</references>
<references title="Informative References">
&RFC3031;
&RFC3032;
&RFC4925;
&RFC5036;
<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>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 04:21:40 |