One document matched: draft-softwire-gateway-init-ds-lite-00.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 I-D.draft-ietf-bfd-base SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-bfd-base-11.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-03.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-softwire-gateway-init-ds-lite-00"
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="May" 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 modified approach
to the original 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 tunnel.</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 number 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>, or 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 tunnel
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>DS-lite: Dual-stack lite</t>
<t>GI-DS-lite: Gateway-initiated DS-lite</t>
<t>NAT: Network Address Translator</t>
<t>CID: Context Identifier</t>
<t>TID: Tunnel Identifier. It is the interface identifier of the
point-to-point 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 tunnel. A
Context-Identifier (CID) is used to multiplex flows associated with the
individual access devices onto the softwire tunnel. Local policies at
the Gateway determine which part of the traffic received from an access
device is tunneled to the AFTR. The combination of CID and softwire
tunnel serves as common context between Gateway and AFTR to 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. The CID ensures a unique
identification (potentially along with other traffic identifiers such as
e.g. interface, VLAN, port, etc.) of traffic flows at the Gateway and
AFTR. The embodiment of the CID and tunnel identifier 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 tunneling 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 tunnel modes
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 tunnel | 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 tunnel 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. The AFTR can, but
does not have to be co-located with the Gateway.</t>
<figure align="center" anchor="fig-translation_table"
title="Example translation table on the AFTR">
<artwork><![CDATA[
+============================+=========================+
| Context-Id/IPv4/Port | Public IPv4/Port |
+============================+=========================+
| CID-1/a.b.c.d/TCP port1 | e.f.g.h/TCP port2 |
| | |
| CID-2/a.b.c.d/TCP port3 | e.f.g.h/TCP port4 |
+----------------------------+-------------------------+
]]></artwork>
</figure>
</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 tunnel.</t>
<t>When creating an IPv4 to IPv4 NAT binding for an IPv4 packet flow
received from the Gateway over the softwire tunnel, the AFTR will
associate the CID with that NAT binding. It will use the combination
of CID and tunnel identifier 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 tunnel, 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 tunnel, 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 tunnel.</t>
</list></t>
</section>
<section anchor="Tunnel-Mgmt"
title="Tunnel Management and related Considerations">
<t>The following are the considerations related to the operational
management of the tunnel between AFTR and Gateway.</t>
<t><list style="symbols">
<t>The tunnel 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="I-D.ietf-bfd-base"></xref>, or LSP ping <xref
target="RFC4379"></xref> for tunnel health management and
corresponding protection stretegies.</t>
<t>The tunnel 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 tunnel peers must have a proper understanding of the path MTU
value. This can be statically configured at the tunnel creation
time.</t>
<t>A Gateway and an AFTR can have multiple softwire tunnels
established between them (e.g. to separate address domains, provide
for load-sharing etc.).</t>
</list></t>
</section>
<section anchor="Alt-Tunnels" title="Tunnel Modes">
<t>Deployment and requirements dependent, different tunnel technologies
apply for connecting Gateway and AFTR. GRE encapsulation with GRE-key
extensions, MPLS VPNs, or plain IP-in-IP encapsulation can be used.
Tunnel identification and Context-ID depend on the tunneling technology
employed:<list style="symbols">
<t>GRE with GRE-key extensions: Tunnel identification is supplied by
the endpoints of the GRE tunnel. The GRE-key serves as CID.</t>
<t>MPLS VPN: Tunnel 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: Tunnel identification is supplied by the
endpoints of the IP-in-IP tunnel. The inner IPv4-address serves as
CID. The IPv4-address has to be unique.</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 |
| Tunnel mode +----+----+----+---+----+----+------+------+
| | 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 | |
+==================+====+====+====+===+====+====+======+======+
]]></artwork>
</figure>
<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 softwire
tunneling 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 and Eric
Voit.</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>
</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;
&I-D.draft-ietf-softwire-dual-stack-lite;
&I-D.draft-ietf-bfd-base;
</references>
<references title="Informative References">
&RFC3031;
&RFC3032;
&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 13:53:53 |