NETEXT WG S. Gundavelli Internet-Draft M. Grayson Intended status: Informational Cisco Expires: August 25, 2012 Y. Lee Comcast H. Deng China Mobile H. Yokota KDDI Lab February 22, 2012 Multiple APN Support for Trusted Wireless LAN Access draft-gundavelli-netext-multiple-apn-pmipv6-01.txt Abstract This specification defines a mechanism for extending multiple APN/ home-network support for a mobile node. 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 August 25, 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 Gundavelli, et al. Expires August 25, 2012 [Page 1] Internet-Draft Multiple APN Support for PMIPv6 February 2012 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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 2.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Potential Limitations and Workarounds . . . . . . . . . . 6 4. Operational Details . . . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 8.2. Informative References . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Gundavelli, et al. Expires August 25, 2012 [Page 2] Internet-Draft Multiple APN Support for PMIPv6 February 2012 1. Introduction Mobile Operators are expanding their network coverage by integrating various access technology domains. Proxy Mobile IPv6 [RFC5213] is one of the key protocol interface for integrating these access networks and building a common IP mobility architecture. For example, the Trusted non-3GPP Access interface based on Proxy Mobile IPv6 [TS23402] interface, 3GPP S2a PMIPv6, specified by the 3GPP system architecture, provides the needed protocol glue across different access systems. The 3GPP system architecture supports the concept of an Access Point Name (APN). An APN can identify a particular routing domain and can be used by 3GPP operators to segment user traffic. APNs are included in the session establishment signaling sent by 3GPP User Equipments (UEs), identifying which routing domain they want to be connected to. Furthermore, 3GPP has defined a system architecture which supports the ability of a single UE to have simultaneous connectivity to a plurality of APNs, and be allocated multiple IPv4 addresses and/or IPv6 prefixes from the network. When the S2a protocol interface based on Proxy Mobile IPv6 is used, the system architecture is restricted in that the mobile access gateway can establish bindings with a single APN/home network at any point of time. There is a limitation with respect to simultaneous, multiple APN access. This limitation is due to the lack of semantics for allowing multiple IPv4 address assignment over DHCP to a given interface of a mobile node. In IEEE 802.11-based Wireless LAN networks, the mobile node can only be assigned a single IPv4 address to the Wireless LAN interface. This essentially forces the mobile access gateway to establish only a single mobility session with any one home network/APN and assign a single IPv4 address to the mobile node. This limitation of single, simultaneous, APN/home-network access from WLAN network, at any point of time, is proving to be a major hindrance. Mobile operators have deployed application specific APN's for many years and those networks are operational. For example, APNs have been defined to specifically support IP Multimedia Subsystem (IMS) based SIP services. It is critical for the mobile operator to ensure access to these APN's/home networks in a consistent way, irrespective of the access technology domain to which they are connected. It is in the interest of the operator to enable the mobile user to activate multiple applications hosted in different APN's and allow access from the WLAN access network. Therefore, there is a need to allow multiple APN access from WLAN access network. The proper approach to solving this problem is to force the mobile operator to move away from the model of building application Gundavelli, et al. Expires August 25, 2012 [Page 3] Internet-Draft Multiple APN Support for PMIPv6 February 2012 specific APN's/home-networks and consolidate them into a single home- network. There is also the other approach of building virtualized connection model (PDN Connection) on the Wireless LAN interface and make it appear like a 3G interface and enable similar access semantics. However, this has a huge impact on the mobile terminal and is not easy to achieve such radical change any time in the foreseeable future. This document specifies an alternative approach for addressing this limitation. The mobile access gateway by supporting this approach can enable access to multiple APN/home networks, simultaneously. The specified approach does not require any changes to the mobile node, or to the Proxy Mobile IPv6 protocol interface. This approach is specific to IPv4 sessions. For IPv6, the mobile access gateway has the ability to project multiple IPv6 prefixes obtained from different home networks, and carry them in the Router Advertisement messages that it sends to the mobile node. The mobile node can potentially use Stateless Auto-configuration approaches for obtaining multiple IP addresses for the interface. This capability in conjunction with Prefix Coloring scheme, allows the mobile node to use the source address based on the application type, and hence has a solution for multiple APN access. There are clearly better ways to solve this problem for IPv6 and with the goal not to create NAT66 requirement, this specification therefore limits the scope of this document to IPv4-only sessions. 2. Conventions and Terminology 2.1. 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 RFC 2119 [RFC2119]. 2.2. Terminology All the mobility related terms used in this document are to be interpreted as defined in the base Proxy Mobile IPv6 specifications [RFC5213] , [RFC5844], [RFC6459], [RFC5149] and [RFC6089]. Additionally, this document uses the following abbreviations: Access Point Name (APN) Gundavelli, et al. Expires August 25, 2012 [Page 4] Internet-Draft Multiple APN Support for PMIPv6 February 2012 Its the name of a packet data network. This APN concept was first introduced in GPRS by 3GPP to enable legacy Intelligent Networking (IN) approaches to be applied to the newly deployed IP packet data services. In roaming deployments, the APN construct was visible to the visited network and allowed legacy IN charging solutions to be supported. Defining an application specific APN then allowed application charging to be supported. 3. Solution Overview Figure 2 illustrates the scenario where the mobile access gateway in the access network has established PMIPv6 bindings for the attached mobile node on multiple local mobility anchors, simultaneously. (DEFAULT APN) MN-1 BCE: HoA-1 . +-----+ _----_ . | | _( )_ . /-====| LMA |--( Default ) . // | | (_ APN-1_) Assigned IP . // +-----+ '----' Address: (HoA-1) . // . . // MN-1 BCE: HoA-2 . /- All other flows -\ +----+-+ .// +-----+ _----_ . / \| |N| // | | _( )_ MN- - - APN-2 flows - -|MAG |A|--===========| LMA |--( APN-2 ) \ /| |T| \\ | | (_ _) \- APN-3 flows -/ +----+-+ .\\ +-----+ '----' . \\ . \\ MN-1 BCE: HoA-3 . \\ +-----+ _----_ . \\ | | _( )_ . \-====| LMA |--( APN-3 ) . | | (_ _) . +-----+ '----' . . [Trusted WLAN Access Network] . [Mobile Packet Core] .................................................................... Figure 1: Multiple APN Support for Trusted WLAN Access The mobile access gateway on detecting a new mobile node on its access link establishes bindings with the mobile node's home network Gundavelli, et al. Expires August 25, 2012 [Page 5] Internet-Draft Multiple APN Support for PMIPv6 February 2012 (default APN). The obtained IP address from this default APN is assigned to the WLAN interface of the mobile node over DHCP. The mobile access gateway also obtains the mobile node's policy profile, which identifies all the home networks/APN's to which the mobile node belongs. It also has knowledge on the applications hosted in the home network and the associated IP flow selectors. The mobile node after obtaining the IPv4 address on the WLAN interface, activates all the applications and starts sending IP packets using the obtained IPv4 address. The IP flow selectors installed on the mobile access gateway identifies those application and initiates the Proxy Mobile IPv6 signaling with the respective local mobility anchor. The mobile access gateway can also choose to establish connections to all the APN's allowed for that mobile node prior to detecting any application specific flows. It maintains BUL entries for each of the sessions. However, except for the IPv4 address and the related configuration from the default APN/home network, the mobile node is not delivered any other IPv4 address from the other APN's. The mobile access gateway installs the NAT translation rules on an APN basis. This essentially allows the mobile node's IP flows using the source address assigned by the default-APN/home network to an address assigned by the home network to which the application flows are associated to. For example, an RTP/SIP packet from the mobile node with the source address from the default APN, will get translated to the source address assigned by the LMA in the SIP APN. IP packets from the mobile node and from the correspondent node, will be translated to use the IP address assigned by the respective APN. The translated packets are forwarded through the home network. 3.1. Potential Limitations and Workarounds The approach specified in this document have some known limitations and can only be enabled when some assumptions are met. These limitations and the related considerations are specified in this section. 1. The mobile node is assigned a DNS server from the default-APN and all the DNS traffic will be routed to the DNS server in the default home-network. DNS is a global name space and generally there should not be any issues with DNS name resolutions for services in the other home networks. However, if a given APN/ home-network (other than the default home-network) is hosting private DNS name space, the DNS resolution requests initiated by the mobile node will always end up in the default home-network and those resolutions will be incorrect. There are clearly Gundavelli, et al. Expires August 25, 2012 [Page 6] Internet-Draft Multiple APN Support for PMIPv6 February 2012 approaches to deal with this problem. * There are two potential approaches to deal with this problem. These approaches are outside the scope of this document, but few points related to those approaches are presented for further study. In both the cases, the mobile access gateway has the assumed capability to recover DNS information provisioned for that home network (or obtained using Protocol Configuration options related to primary and secondary DNS server addresses, when using 3GPP S2a interface). * In one approach, the mobile access gateway can maintain the different DNS server configurations for the different home- networks, and create a single ordered list of DNS servers and provide it to the mobile node as part of the DHCP configuration message. Such an approach assumes that the mobile access gateway has chosen to establish connections to all the APN's allowed for that mobile node prior to detecting any application specific flows. * Alternatively, the mobile access gateway can store the recovered DNS server information and only provide its own IP address as DNS server to the client. The MAG is then operable to receive DNS requests from clients and to determine to which DNS server to proxy the request. The mobile access gateway may use preference information or requested realm to select a DNS server. If the selected DNS server returns an error with unknown realm, the mobile access gateway may subsequently select an alternative DNS server. 2. If the configured APN's/home-networks are hosting a set of applications and if those applications have no unique traffic selectors that the mobile access gateway can apply and identify the IP packets in an unambiguous way, this approach will not work. * There is no workaround for this limitation. In such deployments, those APN's/home-networks hosting applications with no unique traffic selectors have to be excluded from multiple home network support. 4. Operational Details Figure 2 explains the operational sequence of the Proxy Mobile IPv6 signaling message exchange between the mobile access gateway and the local mobility anchor when supporting multiple IPv4 home address support. Gundavelli, et al. Expires August 25, 2012 [Page 7] Internet-Draft Multiple APN Support for PMIPv6 February 2012 MN MAG AAA LMA-1 LMA-2 LMA-3 (Default-APN) (SIP-APN) (Internet-APN) | | | | | | (1) MN Attachment + Access Authentication | |--------->| | | | | | | | | (2) Access Request/Access Accept | | |<-------->| | | | | | + (3) APN Flow Selector Insertion | | | | | | | (4) PBU/PBA (MN-1, Internet-APN, HoA-1) | | |<-------------------->| | | | | | | | (5) PMIP Tunnel | | | |<====================>| | | | | | | (6) DHCPDISCOVER/OFFER/REQUEST/ACK (HoA-1) | |<-------->| | | | | | | (7) Default IP flow (Source=HoA-1) | |----------*--=================-->| | | (8) SIP/RTP flow (Source=HoA-1) | |--------->| | | | (9) PBU/PBA (MN-1, SIP-APN, HoA-2) | | |<--------------------------------->| | | | | | | |(10) PMIP Tunnel | | | |<=================================>| | | | | (11) SIP/RTP flow (Source=HoA-2 after translation at MAG | |----------*-===============================-->| | | | | | | (12) HTTP Flow (Source=HoA-1) | |--------->| | | | (13) PBU/PBA (MN-1, Internet-APN, HoA-3) | | |<---------------------------------------------->| | | | | | (14) PMIP Tunnel | | |<==============================================>| | | Gundavelli, et al. Expires August 25, 2012 [Page 8] Internet-Draft Multiple APN Support for PMIPv6 February 2012 | (15) HTTP Flow (Source=HoA-3 after translation at MAG) | |----------*-=============================================->| Figure 2: Exchange of IP Traffic Offload Selectors o Step-1: The mobile node (MN1) attaches to the access link and completes the access authentication. Based on the interworking between the access authentication function (such as EAP Authenticator, or by virtue of being in the AAA path), the mobile access gateway learns the authenticated identity and the link- layer address of the mobile node. o Step-2: The mobile access gateway obtains the mobile node's policy profile, which includes the list of home networks (APN's/Local mobility anchors that that the mobile node is allowed to access). It also includes the IP flow selectors for identifying the application traffic associated with each of those home networks. o Step-3: The mobile access gateway installs the Policy Based Routing rules for detecting the application traffic associated with different home networks. For example, HTTP packets will be associated with the home network serving the Internet APN (LMA-3), SIP/RTP packets will be associated with the home network serving SIP APN (LMA-2), and all other IP flows will be associated with the default home APN (LMA-1). The mobile access gateway can complete the Proxy Mobile IPv6 signaling with different home networks based on the traffic detect function, or it may complete the signaling with all the home networks right after the mobile node's attachment to the access link. o Step-4 to Step-7: The mobile access gateway completes the Proxy Mobile IPv6 signaling with the local mobility anchor (LMA-1) serving the default home APN. This is as specified in [RFC5213] and [RFC5844]. The obtained IPv4 address (HoA-1) is delivered to the mobile node over DHCPv4. This is the only IPv4 address from the home network that is assigned to the mobile node. The mobile node uses this IPv4 address as the source address with all of its applications when using the attached access technology. The mobile access gateway tunnels all the application traffic, except the application traffic associated with the other home networks, through the established Proxy Mobile IPv6 tunnel. These IP flows will not be subjected to any NAT translation treatment. o Step-8 to Step-11: The mobile node launches a SIP application and initiates the SIP signaling. The traffic detect function on the mobile access gateway identifies this application traffic and determines that this application traffic needs to be routed to the Gundavelli, et al. Expires August 25, 2012 [Page 9] Internet-Draft Multiple APN Support for PMIPv6 February 2012 home network serving the SIP APN. The mobile access gateway completes the needed Proxy Mobile IPv6 signaling with the local mobility anchor (LMA-2) and obtains an IPv4 address (HoA-2) for the mobile node. It also inserts a NAT translation rule, which essentially identifies the application traffic associated with SIP and translates it to use the IP address assigned by that home network. "Application Traffic: SIP/RTP, NAT Internal IPv4 Address: HoA-1, NAT External IPv4 Address: HoA-2. o Step-12 to Step-15: The mobile node launches a Web browser application and opens a URL link. The traffic detect function on the mobile access gateway identifies this HTTP application traffic and determines that this application traffic needs to be routed to the home network serving the Internet APN. The mobile access gateway completes the needed Proxy Mobile IPv6 signaling with the local mobility anchor (LMA-2) and obtains an IPv4 address for the mobile node. It also inserts a NAT translation rule, which essentially identifies the application traffic associated with HTTP and translates it to use the IP address assigned by that home network. "Application Traffic: Internet, NAT Internal IPv4 Address: HoA-1, NAT External IPv4 Address: HoA-3. o The IP traffic from the mobile node belonging to different applications will now get NAT translated to use the IPv4 address assigned by the respective home network and will be routed through that network correctly. However, the application traffic belonging to the default home network (APN) does not require any NAT translation. The home network can correctly apply application specific charging, or other policy functions on the mobile node's IP traffic. 5. IANA Considerations This document does not require any IANA actions. 6. Security Considerations This specification does not define any new protocol extensions and therefore does not identify any specific issues on the protocol security. When multiple APN (home network) support is enabled, per this specification, the mobile node's IP flows belonging to different applications selectively get NAT translated and it essentially introduces certain vulnerabilities which are common to any NAT deployment. These vulnerabilities and the related considerations Gundavelli, et al. Expires August 25, 2012 [Page 10] Internet-Draft Multiple APN Support for PMIPv6 February 2012 have been well documented in the NAT specification [RFC2663]. There are no additional considerations above and beyond what is already documented by the NAT specifications and which are unique to the approach specified in this document. 7. Acknowledgements The authors would like to first thank 3GPP body for creating the APN concept and the associated issues for WLAN access, thus making this technical work relevant, without which the document would not have existed. The authors would also like to thank Ivan Centeno on the importance of this use-case and the need to address this issue. Finally, the authors would like to thank Kent Leung, Rajesh Pazhyannur, Eric Hamel, Sanjay Kumar and Radhakrishna C, on the reviews related to this approach and specifically the discussions related to Split DNS, importance of requiring home-networks with non-overlapping applications. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. [RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy Mobile IPv6", RFC 5844, May 2010. [RFC6089] Tsirtsis, G., Soliman, H., Montavont, N., Giaretta, G., and K. Kuladinithi, "Flow Bindings in Mobile IPv6 and Network Mobility (NEMO) Basic Support", RFC 6089, January 2011. 8.2. Informative References [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999. [RFC5149] Korhonen, J., Nilsson, U., and V. Devarapalli, "Service Selection for Mobile IPv6", RFC 5149, February 2008. Gundavelli, et al. Expires August 25, 2012 [Page 11] Internet-Draft Multiple APN Support for PMIPv6 February 2012 [RFC6459] Korhonen, J., Soininen, J., Patil, B., Savolainen, T., Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation Partnership Project (3GPP) Evolved Packet System (EPS)", RFC 6459, January 2012. [TS23402] 3GPP, "Architecture enhancements for non-3GPP accesses", 2010. Authors' Addresses Sri Gundavelli Cisco 170 West Tasman Drive San Jose, CA 95134 USA Email: sgundave@cisco.com Mark Grayson Cisco 11 New Square Park Bedfont Lakes, FELTHAM TW14 8HA ENGLAND Email: mgrayson@cisco.com Yiu L. Lee Comcast One Comcast Center Philadelphia, PA 19103 U.S.A. Email: yiu_lee@cable.comcast.com URI: http://www.comcast.com Hui Deng China Mobile 53A,Xibianmennei Ave. Xuanwu District, Beijing 100053 China Email: denghui02@gmail.com Gundavelli, et al. Expires August 25, 2012 [Page 12] Internet-Draft Multiple APN Support for PMIPv6 February 2012 Hidetoshi Yokota KDDI Lab 2-1-15 Ohara Saitama, Fujimino 356-8502 Japan Email: yokota@kddilabs.jp Gundavelli, et al. Expires August 25, 2012 [Page 13]