Internet DRAFT - draft-ietf-softwire-gateway-init-ds-lite
draft-ietf-softwire-gateway-init-ds-lite
SOFTWIRE WG F. Brockners
Internet-Draft S. Gundavelli
Intended status: Standards Track Cisco
Expires: October 30, 2012 S. Speicher
Deutsche Telekom AG
D. Ward
Cisco
April 28, 2012
Gateway Initiated Dual-Stack Lite Deployment
draft-ietf-softwire-gateway-init-ds-lite-08
Abstract
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.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 30, 2012.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
Brockners, et al. Expires October 30, 2012 [Page 1]
Internet-Draft Gateway-Initiated DS-Lite April 2012
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Gateway Initiated DS-Lite . . . . . . . . . . . . . . . . . . 4
4. Protocol and related Considerations . . . . . . . . . . . . . 6
5. Softwire Management and related Considerations . . . . . . . . 7
6. Softwire Embodiments . . . . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
10.1. Normative References . . . . . . . . . . . . . . . . . . 10
10.2. Informative References . . . . . . . . . . . . . . . . . 11
Appendix A. GI-DS-lite deployment . . . . . . . . . . . . . . . . 12
A.1. Connectivity establishment: Example call flow . . . . . . 12
A.2. GI-DS-lite applicability: Examples . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
Brockners, et al. Expires October 30, 2012 [Page 2]
Internet-Draft Gateway-Initiated DS-Lite April 2012
1. Overview
Gateway-Initiated Dual-Stack lite (GI-DS-lite) is a variant of the
Dual-Stack lite (DS-lite) [RFC6333], 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 [RFC6275], Proxy Mobile IPv6
[RFC5213], or GTP [TS29060], as well as broadband architectures based
on PPP or point-to-point VLANs as defined by the Broadband Forum
[TR59] and [TR101] are examples for this type of architecture.
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 [RFC1918] between customer sites within the service
provider network.
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 [RFC1918].
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., 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.
2. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
The following abbreviations are used within this document:
Brockners, et al. Expires October 30, 2012 [Page 3]
Internet-Draft Gateway-Initiated DS-Lite April 2012
AFTR: Address Family Transition Router. An AFTR combines IP-in-IP
tunnel termination and IPv4-IPv4 NAT.
AD: Access Device. It is the end host, also known as the mobile
node in mobile architectures.
CID: Context Identifier
DS-lite: Dual-stack lite
GI-DS-lite: Gateway-initiated DS-lite
NAT: Network Address Translator
SW: Softwire [RFC4925]
SWID: Softwire Identifier
3. Gateway Initiated DS-Lite
The section provides an overview of Gateway Initiated DS-Lite (GI-DS-
lite). Figure 1 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 Appendix A.
In Figure 1, 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 [RFC4925].
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, Section 6 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
Brockners, et al. Expires October 30, 2012 [Page 4]
Internet-Draft Gateway-Initiated DS-Lite April 2012
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 [RFC2784] with "GRE Key and Sequence
Number Extensions" [RFC2890] 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. Section 6 for details on different softwire types
supported with GI-DS-lite.
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
Figure 1: Gateway-initiated dual-stack lite reference architecture
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 Figure 2. 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.
Brockners, et al. Expires October 30, 2012 [Page 5]
Internet-Draft Gateway-Initiated DS-Lite April 2012
+=====================================+======================+
| 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 |
+-------------------------------------+----------------------+
Figure 2: Example translation table on the AFTR
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 specific groups of access-
devices, groups of Gateways, or geographic regions. An AFTR could,
but does not have to be co-located with a Gateway.
4. Protocol and related Considerations
o 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, SHOULD be extended to include
the CID and the identifier of the softwire (SWID).
o When creating an IPv4 to IPv4 NAT binding for an IPv4 packet flow
received from the Gateway over the softwire, the AFTR SHOULD
associate the CID with that NAT binding. It SHOULD use the
combination of CID and SWID as the unique identifier and use those
parameters in the NAT binding entry.
o When forwarding a packet to the access device, the AFTR SHOULD
obtain the CID from the NAT binding associated with that flow.
E.g., in case of GRE-encapsulation, it SHOULD add the CID to the
GRE Key and Sequence number extension of the GRE header and tunnel
it to the Gateway.
o On receiving any packet from the softwire, the AFTR SHOULD obtain
the CID from the incoming packet and use it for performing the NAT
binding look up and for performing the packet translation before
forwarding the packet.
o The Gateway, on receiving any IPv4 packet from the access device
SHOULD lookup the CID for that access device. In case of GRE
encapsulation it can for example add the CID to the GRE Key and
Sequence number extension of the GRE header and tunnel it to the
Brockners, et al. Expires October 30, 2012 [Page 6]
Internet-Draft Gateway-Initiated DS-Lite April 2012
AFTR.
o On receiving any packet from the softwire, the Gateway SHOULD
obtain the CID from the packet and use it for making the
forwarding decision.
o When encapsulating an IPv4 packet, Gateway and AFTR SHOULD use its
Diffserv Codepoint (DSCP) to derive the DSCP (or MPLS Traffic-
Class Field in case of MPLS) of the softwire.
5. Softwire Management and related Considerations
The following are the considerations related to the operational
management of the softwire between AFTR and Gateway.
o 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 [RFC5880], or LSP ping [RFC4379] for softwire
health management and corresponding protection strategies.
o 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.
o The softwire peers SHOULD use the correct path MTU value for the
tunnel path between the access gateway and the AFTR. This value
MAY be statically configured at softwire creation time, or
dynamically discovered using the standard path MTU discovery
techniques.
o A Gateway and an AFTR can have multiple softwires established
between them (e.g. to separate address domains, provide for load-
sharing etc.).
6. Softwire Embodiments
Deployment and requirements dependent, different tunnel technologies
apply for the softwire connecting Gateway and AFTR. GRE
encapsulation with GRE-key extensions, MPLS VPNs [RFC4364], or plain
IP-in-IP encapsulation can be used. Softwire identification and
Context-ID depend on the tunneling technology employed:
Brockners, et al. Expires October 30, 2012 [Page 7]
Internet-Draft Gateway-Initiated DS-Lite April 2012
o GRE with GRE-key: SWID is the tunnel identifier of the GRE tunnel
between the GW and the AFTR. The CID is the GRE-key associated
with the AD.
o 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 customer edge (CE) or,
provider edge (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.
o 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.
o 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.
o 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 [RFC6437] 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 Equal Cost Multipath
(ECMP) support.
Figure 3 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:
o IPv4 address
* "up": Deployments with "unique private IPv4 addresses" assigned
to the access devices are supported.
* "op": Deployments with "overlapping private IPv4 addresses"
assigned to the access devices are supported.
* "s": Deployments where all access devices are assigned the same
IPv4 address are supported.
Brockners, et al. Expires October 30, 2012 [Page 8]
Internet-Draft Gateway-Initiated DS-Lite April 2012
o Network-type
* "v4": Gateway and AFTR are connected by an IPv4-only network
* "v6": Gateway and AFTR are connected by an IPv6-only network
* "v4v6": Gateway and AFTR are connected by a dual stack network,
supporting IPv4 and IPv4.
* "MPLS": Gateway and AFTR are connected by a MPLS network
+===================+==============+=======================+
| | IPv4 address| Network-type |
| Softwire +----+----+---+----+----+------+------+
| | up | op | s | v4 | v6 | v4v6 | MPLS |
+====================+====+====+===+====+====+======+======+
| GRE with GRE-key | x | x | x | x | x | x | |
| MPLS VPN | x | x | | | | | x |
| IPv4/IPv6-in-MPLS | x | x | x | | | | x |
| IPv4-in-IPv4 | x | | | x | | | |
| IPv4-in-IPv6 | x | | | | x | | |
| IPv4-in-IPv6 w/ FL | x | x | x | | x | | |
+====================+====+====+===+====+====+======+======+
Figure 3: Tunnel modes and their applicability
7. IANA Considerations
This specification does not require any IANA actions.
8. Security Considerations
The approach specified in this document allows the use of Dual-stack
lite for tunnel-based access architectures. Rather than initiating
the tunnel from the access device, GI-DS-lite logically extends the
already existing access tunnel beyond the access gateway towards the
Address Family Transition Router, and builds a virtual softwire
between the AFTR and the access device. This approach requires the
use of an additional context identifier in the AFTR and at the access
gateway, which is required for making IP packet forwarding decisions.
A packet when received with an Incorrect context identifier at the
access gateway/AFTR will result in associating the packet to an
incorrect access device. Therefore, care must be taken to ensure an
IP packet tunneled between the access gateway and the AFTR is carried
Brockners, et al. Expires October 30, 2012 [Page 9]
Internet-Draft Gateway-Initiated DS-Lite April 2012
with the context identifier of the access device associated with that
IP packet. The context identifier is not carried from the access
device and it is not possible for one access device to claim the
context identifier of some other access device. However, It is
possible an on-path attacker between the access gateway and the AFTR
can potentially modify the context identifier in the packet,
resulting in association of the packet to an incorrect access device.
This threat is no different from an on-path attacker modifying the
source/destination address of an IP packet. However, this threat can
be prevented by enabling IPsec security with integrity protection
turned on, between the access gateway and the AFTR, that will ensure
the correct binding of the context identifier and the inner packet.
This specification does not require any other new security
considerations other than those specified in dual-stack lite
specification [RFC6333], and in the security considerations specified
for the given access architecture, such as Proxy Mobile IPv6,
leveraging this transitioning scheme.
9. Acknowledgements
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, Jim Guichard, Stephen Farrell, Pete Resnik, Ralph Droms.
10. References
10.1. Normative References
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
March 2000.
[RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE",
RFC 2890, September 2000.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Brockners, et al. Expires October 30, 2012 [Page 10]
Internet-Draft Gateway-Initiated DS-Lite April 2012
Networks (VPNs)", RFC 4364, February 2006.
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol
Label Switched (MPLS) Data Plane Failures", RFC 4379,
February 2006.
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and
Routers", RFC 5555, June 2009.
[RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy
Mobile IPv6", RFC 5844, May 2010.
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD)", RFC 5880, June 2010.
[RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support
in IPv6", RFC 6275, July 2011.
[RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
Stack Lite Broadband Deployments Following IPv4
Exhaustion", RFC 6333, August 2011.
[RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme,
"IPv6 Flow Label Specification", RFC 6437, November 2011.
10.2. Informative References
[I-D.draft-ietf-dime-nat-control]
Brockners, F., Bhandari, S., Singh, V., and V. Fajardo,
"Diameter NAT Control Application", August 2009.
[RFC4925] Li, X., Dawkins, S., Ward, D., and A. Durand, "Softwire
Problem Statement", RFC 4925, July 2007.
[TR101] Broadband Forum, "TR-101: Migration to Ethernet-Based DSL
Aggregation", April 2006.
[TR59] Broadband Forum, "TR-059: DSL Evolution - Architecture
Requirements for the Support of QoS-Enabled IP Services",
September 2003.
[TS23060] "3rd Generation Partnership Project; Technical
Specification Group Services and System Aspects; General
Packet Radio Service (GPRS); Service description; Stage
2.", 2009.
Brockners, et al. Expires October 30, 2012 [Page 11]
Internet-Draft Gateway-Initiated DS-Lite April 2012
[TS23401] "3rd Generation Partnership Project; Technical
Specification Group Services and System Aspects; General
Packet Radio Service (GPRS) enhancements for Evolved
Universal Terrestrial Radio Access Network (E-UTRAN)
access.", 2009.
[TS29060] "3rd Generation Partnership Project; Technical
Specification Group Core Network and Terminals; General
Packet Radio Service (GPRS); GPRS Tunnelling Protocol
(GTP), V9.1.0", 2009.
Appendix A. GI-DS-lite deployment
A.1. Connectivity establishment: Example call flow
Figure 4 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.
AD Gateway AAA/Policy AFTR
| | | |
|----(1)-------->| | |
| (2)<-------------->| |
| (3) | |
| |<------(4)------------------->|
| (5) | |
|<---(6)-------->| | |
| | | |
Figure 4: Example call flow for session establishment
1. Gateway receives a request to create an access tunnel endpoint.
2. 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.
3. The Gateway creates an access tunnel endpoint. The access tunnel
links AD and Gateway.
4. (Optional): The Gateway and the AFTR establish a control session
between each other. This session can for example be used to
Brockners, et al. Expires October 30, 2012 [Page 12]
Internet-Draft Gateway-Initiated DS-Lite April 2012
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
[I-D.draft-ietf-dime-nat-control] could for example be used for
this purpose.
5. 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.
6. 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).
A.2. GI-DS-lite applicability: Examples
The section outlines deployment examples of the generic GI-DS-lite
architecture described in Section 3.
o Mobile IP based access architectures: In a DSMIPv6 [RFC5555] based
network scenario, the Mobile IPv6 home agent will implement the
GI-DS-lite Gateway function along with the dual-stack Mobile IPv6
functionality.
o Proxy Mobile IPv6 based access architectures: In a PMIPv6
[RFC5213] scenario the local mobility anchor (LMA) will implement
the GI-DS-lite Gateway function along with the PMIPv6 IPv4 support
[RFC5844] functionality.
o GTP based access architectures: 3GPP TS 23.401 [TS23401] and 3GPP
TS 23.060 [TS23060] define mobile access architectures using GTP.
For GI-DS-lite, the PDN-Gateway/GGSN will also assume the Gateway
function.
o Fixed WiMAX architecture: If GI-DS-lite is applied to fixed WiMAX,
the ASN-Gateway will implement the GI-DS-lite Gateway function.
o Mobile WiMAX: If GI-DS-lite is applied to mobile WiMAX, the home
agent will implement the Gateway function.
o 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
Brockners, et al. Expires October 30, 2012 [Page 13]
Internet-Draft Gateway-Initiated DS-Lite April 2012
the GI-DS-lite Gateway function.
o In broadband access architectures using per-subscriber VLANs the
BNG will implement the GI-DS-lite Gateway function.
Authors' Addresses
Frank Brockners
Cisco
Hansaallee 249, 3rd Floor
DUESSELDORF, NORDRHEIN-WESTFALEN 40549
Germany
Email: fbrockne@cisco.com
Sri Gundavelli
Cisco
170 West Tasman Drive
SAN JOSE, CA 95134
USA
Email: sgundave@cisco.com
Sebastian Speicher
Deutsche Telekom AG
Landgrabenweg 151
BONN, NORDRHEIN-WESTFALEN 53277
Germany
Email: sebastian.speicher@telekom.de
David Ward
Cisco
170 West Tasman Drive
SAN JOSE, CA 95134
USA
Email: wardd@cisco.com
Brockners, et al. Expires October 30, 2012 [Page 14]
