diff options
Diffstat (limited to 'doc/rfc/rfc6674.txt')
| -rw-r--r-- | doc/rfc/rfc6674.txt | 843 |
1 files changed, 843 insertions, 0 deletions
diff --git a/doc/rfc/rfc6674.txt b/doc/rfc/rfc6674.txt new file mode 100644 index 0000000..9da6189 --- /dev/null +++ b/doc/rfc/rfc6674.txt @@ -0,0 +1,843 @@ + + + + + + +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. + + + + + + + + + + + + + + + +Brockners, et al. Standards Track [Page 1] + +RFC 6674 Gateway-Initiated DS-Lite July 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 + (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 + + + + + + + + + + + + + + + + + + + + +Brockners, et al. Standards Track [Page 2] + +RFC 6674 Gateway-Initiated DS-Lite July 2012 + + +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]. + + + + + + + +Brockners, et al. Standards Track [Page 3] + +RFC 6674 Gateway-Initiated DS-Lite July 2012 + + + 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 + + + +Brockners, et al. Standards Track [Page 4] + +RFC 6674 Gateway-Initiated DS-Lite July 2012 + + + 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 + + + +Brockners, et al. Standards Track [Page 5] + +RFC 6674 Gateway-Initiated DS-Lite July 2012 + + + 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. + + + + + +Brockners, et al. Standards Track [Page 6] + +RFC 6674 Gateway-Initiated DS-Lite July 2012 + + + 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. + + + + + + +Brockners, et al. Standards Track [Page 7] + +RFC 6674 Gateway-Initiated DS-Lite July 2012 + + + 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. + + + + + + + + +Brockners, et al. Standards Track [Page 8] + +RFC 6674 Gateway-Initiated DS-Lite July 2012 + + + 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 + + + + + + + +Brockners, et al. Standards Track [Page 9] + +RFC 6674 Gateway-Initiated DS-Lite July 2012 + + +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. + + + + + + + + + + +Brockners, et al. Standards Track [Page 10] + +RFC 6674 Gateway-Initiated DS-Lite July 2012 + + +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. + + + + + +Brockners, et al. Standards Track [Page 11] + +RFC 6674 Gateway-Initiated DS-Lite July 2012 + + +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. + + + + + + + + + + + + + + + + + + + + + + +Brockners, et al. Standards Track [Page 12] + +RFC 6674 Gateway-Initiated DS-Lite July 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. + + + +Brockners, et al. Standards Track [Page 13] + +RFC 6674 Gateway-Initiated DS-Lite July 2012 + + + 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. + + + + + + + + + + + +Brockners, et al. Standards Track [Page 14] + +RFC 6674 Gateway-Initiated DS-Lite July 2012 + + +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. Standards Track [Page 15] + |