RFC 6674 PROPOSED STANDARD IPV6 TRANSITION · TUNNELING · NAT
GI-DS-Lite: Gateway-Initiated Dual-Stack Lite Deployment
Reuse the tunnels an access network already has to reach a carrier NAT, tagging each device's traffic with a Context Identifier.
RFC EDITOR
Brockners, F., Gundavelli, S., Speicher, S., and D. Ward, "Gateway-Initiated Dual-Stack Lite Deployment", RFC 6674, DOI 10.17487/RFC6674, July 2012, <https://www.rfc-editor.org/info/rfc6674>.
BIBTEX
@misc{rfc6674,
series = {Request for Comments},
number = 6674,
howpublished = {RFC 6674},
publisher = {RFC Editor},
doi = {10.17487/RFC6674},
url = {https://www.rfc-editor.org/info/rfc6674},
author = {F. Brockners and S. Gundavelli and S. Speicher and D. Ward},
title = {{Gateway-Initiated Dual-Stack Lite Deployment}},
pagetotal = 15,
year = 2012,
month = jul,
} RFC text
Contents
Internet Engineering Task Force (IETF) F. Brockners
Request for Comments: 6674 S. Gundavelli
Category: Standards Track Cisco
ISSN: 2070-1721 S. Speicher
Deutsche Telekom AG
D. Ward
Cisco
July 2012
Gateway-Initiated Dual-Stack Lite Deployment
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 to which
the tunneled packets belong. 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 is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6674.
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
(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 . . . . . . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . . 12
Appendix A. GI-DS-Lite Deployment . . . . . . . . . . . . . . . . 13
A.1. Connectivity Establishment: Example Call Flow . . . . . . 13
A.2. GI-DS-Lite Applicability: Examples . . . . . . . . . . . . 14
1. Overview
Gateway-Initiated Dual-Stack Lite (GI-DS-Lite) is a variant of Dual-
Stack Lite (DS-Lite) [RFC6333], applicable to network architectures
that 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 GPRS
Tunnelling Protocol (GTP) [TS29060], as well as broadband
architectures based on PPP or point-to-point VLANs as defined by the
Broadband Forum [TR59][TR101], are examples of 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 makes the inner IPv4 address
irrelevant for traffic routing and allows sharing private IPv4
addresses [RFC1918] between customer sites within the service
provider network.
Similarly 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 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 the access architecture.
Additional tunneling overhead in the access network is also omitted.
If, for example, an encapsulation mechanism based on Generic Routing
Encapsulation (GRE) is chosen, it allows the network between the
access gateway and the AFTR to be either IPv4 or IPv6 and allows 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:
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.
AG: Access Gateway. A gateway in the access network, such as LMA,
Home Agent (HA), GGSN, or PDN-GW in mobile architectures.
CID: Context Identifier
DS-Lite: Dual-Stack Lite
GGSN: Gateway GPRS Support Node
GI-DS-Lite: Gateway-Initiated DS-Lite
NAT: Network Address Translator
PDN-GW: Packet Data Network Gateway
SW: Softwire [RFC4925]
SWID: Softwire Identifier
3. Gateway-Initiated DS-Lite
This 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
access 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 access
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, the access 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, for
example, be the endpoints of a GRE tunnel or a VPN-ID. See Section 6
for details. A Context Identifier (CID) is used to multiplex flows
associated with the individual access devices onto the softwire. It
is deployment dependent whether the flows from a particular AD are
identified using the source IP address or an access tunnel
identifier. Local policies at the access 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 the access 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 access gateway. It is retrieved either from a
local or remote (e.g., Authentication, Authorization, and Accounting
(AAA)) repository. Like the SWID, the embodiment of the CID depends
on the tunnel mode used and the type of the network connecting the
access gateway and AFTR. If, for example, GRE [RFC2784] with GRE Key
and Sequence Number extensions [RFC2890] is used as the softwire
technology, the network connecting the access gateway and AFTR could
be a IPv4-only, IPv6-only, or dual-stack IP network. The CID would
be carried within the GRE Key field. Section 6 details the 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 |=================| | +---+
+------+ | | | A |
| | Softwire SWID-1 | F |
| A |==========================| T |
IPv4: a.b.c.d | G | (e.g., IPv4-over-GRE | R |
+------+ | | over IPv4 or IPv6) +---+
| AD-2 |=================| |
+------+ 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, if 32 bits 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 into account parameters such as
destination IP address, incoming interface, etc. The IP address of
the AFTR, which will either be an IPv6 or an IPv4 address depending
on the transport network between the access gateway and the AFTR, is
configured on the access gateway. A variety of methods, such as out-
of-band mechanisms or manual configuration, apply.
+=====================================+======================+
| 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 at the AFTR
GI-DS-Lite does not require a 1:1 relationship between an access
gateway and AFTR, but more generally applies to (M:N) scenarios,
where M access gateways are connected to N AFTRs. Multiple access
gateways could be served by a single AFTR. AFTRs could be dedicated
to specific groups of access-devices, groups of access gateways, or
geographic regions. An AFTR could be, but does not have to be, co-
located with an access 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 access 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.
For example, 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 access gateway.
o On receiving any packet from the softwire, the AFTR SHOULD obtain
the CID from the incoming packet and use it for performing NAT
binding lookup and packet translation before forwarding the
packet.
o The access 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 AFTR.
o On receiving any packet from the softwire, the access gateway
SHOULD obtain the CID from the packet and use it for making the
forwarding decision.
o When encapsulating an IPv4 packet, the access gateway and AFTR
SHOULD use its Diffserv Codepoint (DSCP) to derive the DSCP (or
MPLS Traffic-Class Field in the 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 the AFTR and access gateway.
o The softwire between the access gateway and the AFTR MAY be
created at system startup time OR dynamically established on-
demand. It is deployment dependent which Operations,
Administration, and Maintenance (OAM) mechanisms (such as ICMP,
Bidirectional Forwarding Detection (BFD) [RFC5880], or Label
Switched Path (LSP) ping [RFC4379]) are employed by the access
gateway and AFTR 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 settings
related to quality of service. 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 An access 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
Which tunnel technologies can be applied for the softwire connecting
an access gateway and AFTR are dependent on the deployment and the
requirements. GRE encapsulation with GRE Key extension, MPLS VPNs
[RFC4364], or plain IP-in-IP encapsulation can be used. Softwire
identification and CID depend on the tunneling technology employed:
o GRE with GRE Key: SWID is the tunnel identifier of the GRE tunnel
between the access gateway and the AFTR. The CID is the GRE Key
associated with the AD.
o MPLS VPN: The SWID is a generic identifier that uniquely
identifies the VPN at either the access gateway or AFTR.
Depending on whether the access gateway or AFTR is acting as
customer edge (CE) or provider edge (PE), the SWID could, for
example, 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 bits 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.
o Network-type
* "v4": The access gateway and AFTR are connected by an IPv4-only
network.
* "v6": The access gateway and AFTR are connected by an IPv6-only
network.
* "v4v6": The access gateway and AFTR are connected by a dual-
stack network, supporting IPv4 and IPv6.
* "MPLS": The access gateway and AFTR are connected by an 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. 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
AFTR 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.
If a packet is received with an incorrect Context Identifier at the
access gateway/AFTR, it will be associated with an incorrect access
device. Therefore, care must be taken to ensure an IP packet
tunneled between the access gateway and the AFTR is carried 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 that 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 new security considerations
other than those specified in the 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.
8. 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, and Ralph Droms.
9. References
9.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
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.
9.2. Informative References
[NAT-CONTROL]
Brockners, F., Bhandari, S., Singh, V., and V. Fajardo,
"Diameter Network Address and Port Translation Control
Application", Work in Progress, April 2012.
[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] 3GPP, "Technical Specification Group Services and System
Aspects; General Packet Radio Service (GPRS); Service
description; Stage 2, V11.2.0", TS 23.060, 2012.
[TS23401] 3GPP, "Technical Specification Group Services and System
Aspects; General Packet Radio Service (GPRS) enhancements
for Evolved Universal Terrestrial Radio Access Network
(E-UTRAN) access, V11.1.0", TS 23.401, 2012.
[TS29060] 3GPP, "Technical Specification Group Core Network and
Terminals; General Packet Radio Service (GPRS); GPRS
Tunnelling Protocol (GTP), V11.3.0", TS 29.060, 2012.
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 access gateway with the softwire to the AFTR.
This simple example assumes that traffic from the AD uses a single
access tunnel and that the access gateway will use local policies to
decide which portion of the traffic received over this access tunnel
needs to be forwarded to the AFTR.
AD Access Gateway AAA/Policy AFTR
| | | |
|----(1)-------->| | |
| (2)<-------------->| |
| (3) | |
| |<------(4)------------------->|
| (5) | |
|<---(6)-------->| | |
| | | |
Figure 4: Example Call Flow for Session Establishment
1. The access gateway receives a request to create an access tunnel
endpoint.
2. The access gateway authenticates and authorizes the access
tunnel. Based on local policy or through interaction with the
AAA/Policy system, the access gateway recognizes that IPv4
service should be provided using GI-DS-Lite.
3. The access gateway creates an access tunnel endpoint. The access
tunnel links AD and access gateway.
4. (Optional): The access gateway and the AFTR establish a control
session between themselves. This session can, for example, be
used to exchange accounting or NAT-configuration information.
Accounting information could be supplied to the access gateway,
AAA/Policy, or other network entities that require information
about the externally visible address/port pairs of a particular
access device. The Diameter NAT Control Application
[NAT-CONTROL] could, for example, be used for this purpose.
5. The access 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 the access gateway and
AFTR. Local forwarding policy on the access gateway determines
which traffic will need to be tunneled towards the AFTR.
6. The access 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 Access architectures based on Mobile-IP: In a network scenario
based on Dual-Stack Mobile IPv6 (DSMIPv6) [RFC5555], the Mobile
IPv6 home agent will implement the GI-DS-Lite access gateway
function along with the dual-stack Mobile IPv6 functionality.
o Access architectures based on Proxy Mobile IPv6 (PMIPv6): In a
PMIPv6 [RFC5213] scenario, the local mobility anchor (LMA) will
implement the GI-DS-Lite access gateway function along with the
PMIPv6 IPv4 support [RFC5844] functionality.
o GTP-based access architectures: Third Generation Partnership
Project (3GPP) TS 23.401 [TS23401] and 3GPP TS 23.060 [TS23060]
define mobile access architectures using GTP. For GI-DS-Lite, the
PDN-GW or GGSN will also assume the access gateway function.
o Fixed Worldwide Interoperability for Microwave Access (WiMAX)
architecture: If GI-DS-Lite is applied to fixed WiMAX, the Access
Service Network Gateway (ASN-GW) will implement the GI-DS-Lite
access gateway function.
o Mobile WiMAX: If GI-DS-Lite is applied to mobile WiMAX, the home
agent will implement the access 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
the GI-DS-Lite access gateway function.
o In broadband access architectures using per-subscriber VLANs, the
BNG will implement the GI-DS-Lite access 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
AI ELI5
On this page
PROBLEMDual-Stack Lite normally builds a tunnel from each customer device to a carrier NAT, but tunnel-based access networks already have a tunnel from each device to an access gateway that serves large numbers of devices.
MECHANISMThe access gateway extends service to the carrier NAT (the AFTR) over a shared softwire, and a Context Identifier carried with each packet tells the AFTR which access device the traffic belongs to.
WHY IT MATTERSService providers can share public IPv4 addresses among customers, even when devices use overlapping private IPv4 addresses, without changing the access device or the access architecture.
§1Overview and Motivation
Gateway-Initiated Dual-Stack Lite (GI-DS-Lite) is a variant of Dual-Stack Lite (DS-Lite, RFC 6333). It targets network architectures that use point-to-point tunnels between the access device and an access gateway built to serve large numbers of devices. The RFC names Mobile IPv6, Proxy Mobile IPv6 and GPRS Tunnelling Protocol (GTP) in mobile networks, and PPP or point-to-point VLANs in broadband networks, as examples.
DS-Lite carries IPv4 traffic in IPv4-in-IPv6 tunnels from the customer network to an Address Family Transition Router (AFTR), so the inner IPv4 address does not matter for routing and private addresses can be shared between customer sites. GI-DS-Lite keeps that sharing of public IPv4 addresses, but instead of starting a new tunnel on the access device, it logically extends the existing access tunnel past the access gateway toward the AFTR.
The RFC lists the benefits: overlapping IPv4 addresses in the access network are supported, no change is needed to the access device or the access architecture, and no extra tunneling overhead is added in the access network.
Homes already have a road to the local depot. Instead of paving a second road from each home to the far-away sorting office, the depot forwards the parcels and labels each one with whose it is.
§3The Reference Architecture
Access devices (AD) connect to the access gateway (AG) over access tunnels, or over point-to-point links. How the devices get their IPv4 configuration depends on the access architecture and is outside the scope of the RFC. The access gateway and the AFTR are joined by a softwire, which is identified by a softwire identifier (SWID). The SWID need not be globally unique, and its form depends on the tunnel technology.
A Context Identifier (CID) multiplexes the flows of the individual access devices onto the softwire. The combination of CID and SWID must be unique between the access gateway and the AFTR. The CID is typically 32 bits wide and is assigned by the access gateway, taken from a local or remote repository such as an Authentication, Authorization, and Accounting (AAA) server. Local policy on the access gateway decides which part of an access device's traffic is tunneled to the AFTR.
The AFTR combines softwire termination with IPv4-to-IPv4 NAT. Its address is configured on the access gateway and is IPv6 or IPv4 depending on the network between them. The relationship is not 1:1: M access gateways can be connected to N AFTRs, and an AFTR may or may not be co-located with an access gateway.
Each home's parcels go to the depot. The depot puts a numbered sticker on each one and sends them in a shared truck to the sorting office, which reads the sticker to know whose parcel it is.
§4How the AFTR and Gateway Handle Packets
The AFTR builds its NAT bindings with the CID and SWID included. When it creates an IPv4-to-IPv4 binding for a flow arriving over the softwire, it SHOULD associate the CID with that binding and use the CID and SWID together as the unique identifier. For traffic going back toward the device, it SHOULD take the CID from the binding. With GRE, that means adding the CID to the GRE Key and Sequence Number extension. On any packet from the softwire it SHOULD read the CID and use it for the NAT lookup.
The NAT binding itself can be chosen by the AFTR from a local address pool, configured per binding (through a NAT control protocol or by hand), or derived from the CID. As an example, a 32-bit CID could map 1:1 to an external IPv4 address.
The access gateway looks up the CID for an access device when it receives an IPv4 packet from it, and uses the CID in packets coming from the softwire to choose where to forward them. When encapsulating, the gateway and AFTR SHOULD use the inner packet's DSCP to derive the DSCP of the softwire (or the MPLS Traffic-Class field).
When a parcel comes in, the sorting office notes the sticker number next to the return address it made up. When a reply comes back, it looks up that sticker and sends it down the right branch.
§5Softwire Management
The softwire between the access gateway and the AFTR MAY be created at system startup or established dynamically on demand. Which Operations, Administration, and Maintenance (OAM) mechanisms watch its health, such as ICMP, Bidirectional Forwarding Detection (BFD) or LSP ping, is deployment dependent.
The peers MAY be provisioned to enforce policy, for example which protocol types or what share of traffic gets tunneled. The RFC leaves the details out of scope. They SHOULD use the correct path MTU for the tunnel path, either configured statically when the softwire is created or found dynamically with path MTU discovery. A gateway and an AFTR can also have several softwires between them, for example to separate address domains or to share load.
The shared truck route can be set up in advance or when needed. The two offices check it is still working, and make sure parcels are not too big for the truck.
§6Softwire Embodiments
The softwire can use GRE encapsulation with the GRE Key extension, MPLS VPNs, or plain IP-in-IP encapsulation. What the SWID and CID are depends on the choice:
- GRE with GRE Key: the SWID is the GRE tunnel identifier and the CID is the GRE Key for the access device.
- MPLS VPN: the SWID identifies the VPN and the device's IPv4 address is the CID, so it must be unique within the VPN.
- IPv4/IPv6-in-MPLS: the SWID is the top MPLS label; the CID may be the next label, or the device's IP address.
- IPv4-in-IPv4: the SWID is the outer IPv4 source address and the device's IPv4 address is the CID, which must be unique for that outer address.
- IPv4-in-IPv6: the SWID is the outer IPv6 source address. With the device's IPv4 address as CID it must be unique. With the IPv6 Flow Label as CID, addresses may overlap, but the flow label is 20 bits wide, shorter than the recommended 32-bit CID, so large deployments may need extra scaling thought. The flow label should also be randomized enough to avoid interfering with uses such as Equal Cost Multipath.
A table in the RFC shows which modes support unique, overlapping or identical device addresses, and which network types (IPv4-only, IPv6-only, dual-stack or MPLS) they run over.
There are several kinds of truck and labelling schemes. Some need every house to have a different number, and others let two houses share a number because the sticker tells them apart.
| Softwire | SWID | CID |
|---|---|---|
| GRE with GRE Key | GRE tunnel identifier | GRE Key for the device |
| MPLS VPN | VPN identifier | Device IPv4 address |
| IPv4/IPv6-in-MPLS | Top MPLS label | Next MPLS label or device IP address |
| IPv4-in-IPv4 | Outer IPv4 source address | Device IPv4 address |
| IPv4-in-IPv6 | Outer IPv6 source address | Device IPv4 address or IPv6 Flow Label |
§7Security Considerations
If a packet arrives with the wrong CID, it is associated with the wrong access device, so the gateway and AFTR must carry each packet with the CID of the device it belongs to. The CID is not carried from the access device, so one device cannot claim another's CID.
An on-path attacker between the gateway and the AFTR could change the CID in a packet. The RFC says this threat is no different from an on-path attacker modifying the source or destination address of an IP packet, and that it can be prevented with IPsec with integrity protection between the gateway and the AFTR. The specification adds no new security considerations beyond those of DS-Lite (RFC 6333) and of the access architecture in use, such as Proxy Mobile IPv6.
If someone swapped the stickers on the truck, parcels would go to the wrong house. A tamper-proof seal on the truck stops that.
§7Call Flow and Deployment Examples
Appendix A gives an example of connectivity establishment. The gateway receives a request to create an access tunnel endpoint, authenticates and authorizes it, and learns from local policy or the AAA/Policy system that IPv4 service should use GI-DS-Lite. It creates the tunnel endpoint, optionally opens a control session with the AFTR (for accounting or NAT configuration, for example with the Diameter NAT Control Application), allocates a unique CID, and finally completes tunnel setup with the device, which may include assigning it an IPv4 address.
The appendix also maps the generic design to real architectures. With Dual-Stack Mobile IPv6 the home agent implements the access gateway function. With Proxy Mobile IPv6 the local mobility anchor does. In GTP-based networks the PDN-GW or GGSN does.
When a new home connects, the depot checks who they are, picks a sticker number for them, and then finishes setting up their road.
Access DeviceAccess GatewayAAA/PolicyAFTR
- Request access tunnelThe gateway receives a request to create an access tunnel endpoint.
- Authenticate and authorizePolicy shows IPv4 service should use GI-DS-Lite.
- Optional control sessionCan exchange accounting or NAT configuration information.
- Complete access tunnelMay include assigning an IPv4 address to the device.
§8References
[RFC6333]RFC 6333Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion", RFC 6333, August 2011.August 2011[RFC4925]RFC 4925Li, X., Dawkins, S., Ward, D., and A. Durand, "Softwire Problem Statement", RFC 4925, July 2007.July 2007[RFC2784]RFC 2784Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.March 2000[RFC2890]RFC 2890Dommety, G., "Key and Sequence Number Extensions to GRE", RFC 2890, September 2000.September 2000[RFC5213]RFC 5213Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.August 2008[RFC6437]RFC 6437Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, "IPv6 Flow Label Specification", RFC 6437, November 2011.November 2011[RFC4364]RFC 4364Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006.February 2006