idnits 2.17.1 draft-gundavelli-netext-multiple-apn-pmipv6-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (February 22, 2012) is 4437 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETEXT WG S. Gundavelli 3 Internet-Draft M. Grayson 4 Intended status: Informational Cisco 5 Expires: August 25, 2012 Y. Lee 6 Comcast 7 H. Deng 8 China Mobile 9 H. Yokota 10 KDDI Lab 11 February 22, 2012 13 Multiple APN Support for Trusted Wireless LAN Access 14 draft-gundavelli-netext-multiple-apn-pmipv6-01.txt 16 Abstract 18 This specification defines a mechanism for extending multiple APN/ 19 home-network support for a mobile node. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on August 25, 2012. 38 Copyright Notice 40 Copyright (c) 2012 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 57 2.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4 58 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 5 60 3.1. Potential Limitations and Workarounds . . . . . . . . . . 6 61 4. Operational Details . . . . . . . . . . . . . . . . . . . . . 7 62 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 63 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 64 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 65 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 66 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 67 8.2. Informative References . . . . . . . . . . . . . . . . . . 11 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 70 1. Introduction 72 Mobile Operators are expanding their network coverage by integrating 73 various access technology domains. Proxy Mobile IPv6 [RFC5213] is 74 one of the key protocol interface for integrating these access 75 networks and building a common IP mobility architecture. For 76 example, the Trusted non-3GPP Access interface based on Proxy Mobile 77 IPv6 [TS23402] interface, 3GPP S2a PMIPv6, specified by the 3GPP 78 system architecture, provides the needed protocol glue across 79 different access systems. 81 The 3GPP system architecture supports the concept of an Access Point 82 Name (APN). An APN can identify a particular routing domain and can 83 be used by 3GPP operators to segment user traffic. APNs are included 84 in the session establishment signaling sent by 3GPP User Equipments 85 (UEs), identifying which routing domain they want to be connected to. 86 Furthermore, 3GPP has defined a system architecture which supports 87 the ability of a single UE to have simultaneous connectivity to a 88 plurality of APNs, and be allocated multiple IPv4 addresses and/or 89 IPv6 prefixes from the network. 91 When the S2a protocol interface based on Proxy Mobile IPv6 is used, 92 the system architecture is restricted in that the mobile access 93 gateway can establish bindings with a single APN/home network at any 94 point of time. There is a limitation with respect to simultaneous, 95 multiple APN access. This limitation is due to the lack of semantics 96 for allowing multiple IPv4 address assignment over DHCP to a given 97 interface of a mobile node. In IEEE 802.11-based Wireless LAN 98 networks, the mobile node can only be assigned a single IPv4 address 99 to the Wireless LAN interface. This essentially forces the mobile 100 access gateway to establish only a single mobility session with any 101 one home network/APN and assign a single IPv4 address to the mobile 102 node. 104 This limitation of single, simultaneous, APN/home-network access from 105 WLAN network, at any point of time, is proving to be a major 106 hindrance. Mobile operators have deployed application specific APN's 107 for many years and those networks are operational. For example, APNs 108 have been defined to specifically support IP Multimedia Subsystem 109 (IMS) based SIP services. It is critical for the mobile operator to 110 ensure access to these APN's/home networks in a consistent way, 111 irrespective of the access technology domain to which they are 112 connected. It is in the interest of the operator to enable the 113 mobile user to activate multiple applications hosted in different 114 APN's and allow access from the WLAN access network. Therefore, 115 there is a need to allow multiple APN access from WLAN access 116 network. The proper approach to solving this problem is to force the 117 mobile operator to move away from the model of building application 118 specific APN's/home-networks and consolidate them into a single home- 119 network. There is also the other approach of building virtualized 120 connection model (PDN Connection) on the Wireless LAN interface and 121 make it appear like a 3G interface and enable similar access 122 semantics. However, this has a huge impact on the mobile terminal 123 and is not easy to achieve such radical change any time in the 124 foreseeable future. 126 This document specifies an alternative approach for addressing this 127 limitation. The mobile access gateway by supporting this approach 128 can enable access to multiple APN/home networks, simultaneously. The 129 specified approach does not require any changes to the mobile node, 130 or to the Proxy Mobile IPv6 protocol interface. This approach is 131 specific to IPv4 sessions. For IPv6, the mobile access gateway has 132 the ability to project multiple IPv6 prefixes obtained from different 133 home networks, and carry them in the Router Advertisement messages 134 that it sends to the mobile node. The mobile node can potentially 135 use Stateless Auto-configuration approaches for obtaining multiple IP 136 addresses for the interface. This capability in conjunction with 137 Prefix Coloring scheme, allows the mobile node to use the source 138 address based on the application type, and hence has a solution for 139 multiple APN access. There are clearly better ways to solve this 140 problem for IPv6 and with the goal not to create NAT66 requirement, 141 this specification therefore limits the scope of this document to 142 IPv4-only sessions. 144 2. Conventions and Terminology 146 2.1. Conventions 148 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 149 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 150 document are to be interpreted as described in RFC 2119 [RFC2119]. 152 2.2. Terminology 154 All the mobility related terms used in this document are to be 155 interpreted as defined in the base Proxy Mobile IPv6 specifications 156 [RFC5213] , [RFC5844], [RFC6459], [RFC5149] and [RFC6089]. 157 Additionally, this document uses the following abbreviations: 159 Access Point Name (APN) 160 Its the name of a packet data network. This APN concept was first 161 introduced in GPRS by 3GPP to enable legacy Intelligent Networking 162 (IN) approaches to be applied to the newly deployed IP packet data 163 services. In roaming deployments, the APN construct was visible 164 to the visited network and allowed legacy IN charging solutions to 165 be supported. Defining an application specific APN then allowed 166 application charging to be supported. 168 3. Solution Overview 170 Figure 2 illustrates the scenario where the mobile access gateway in 171 the access network has established PMIPv6 bindings for the attached 172 mobile node on multiple local mobility anchors, simultaneously. 174 (DEFAULT APN) 175 MN-1 BCE: HoA-1 176 . +-----+ _----_ 177 . | | _( )_ 178 . /-====| LMA |--( Default ) 179 . // | | (_ APN-1_) 180 Assigned IP . // +-----+ '----' 181 Address: (HoA-1) . // 182 . . // MN-1 BCE: HoA-2 183 . /- All other flows -\ +----+-+ .// +-----+ _----_ 184 . / \| |N| // | | _( )_ 185 MN- - - APN-2 flows - -|MAG |A|--===========| LMA |--( APN-2 ) 186 \ /| |T| \\ | | (_ _) 187 \- APN-3 flows -/ +----+-+ .\\ +-----+ '----' 188 . \\ 189 . \\ MN-1 BCE: HoA-3 190 . \\ +-----+ _----_ 191 . \\ | | _( )_ 192 . \-====| LMA |--( APN-3 ) 193 . | | (_ _) 194 . +-----+ '----' 195 . 196 . 197 [Trusted WLAN Access Network] . [Mobile Packet Core] 198 .................................................................... 200 Figure 1: Multiple APN Support for Trusted WLAN Access 202 The mobile access gateway on detecting a new mobile node on its 203 access link establishes bindings with the mobile node's home network 204 (default APN). The obtained IP address from this default APN is 205 assigned to the WLAN interface of the mobile node over DHCP. The 206 mobile access gateway also obtains the mobile node's policy profile, 207 which identifies all the home networks/APN's to which the mobile node 208 belongs. It also has knowledge on the applications hosted in the 209 home network and the associated IP flow selectors. 211 The mobile node after obtaining the IPv4 address on the WLAN 212 interface, activates all the applications and starts sending IP 213 packets using the obtained IPv4 address. The IP flow selectors 214 installed on the mobile access gateway identifies those application 215 and initiates the Proxy Mobile IPv6 signaling with the respective 216 local mobility anchor. The mobile access gateway can also choose to 217 establish connections to all the APN's allowed for that mobile node 218 prior to detecting any application specific flows. It maintains BUL 219 entries for each of the sessions. However, except for the IPv4 220 address and the related configuration from the default APN/home 221 network, the mobile node is not delivered any other IPv4 address from 222 the other APN's. 224 The mobile access gateway installs the NAT translation rules on an 225 APN basis. This essentially allows the mobile node's IP flows using 226 the source address assigned by the default-APN/home network to an 227 address assigned by the home network to which the application flows 228 are associated to. For example, an RTP/SIP packet from the mobile 229 node with the source address from the default APN, will get 230 translated to the source address assigned by the LMA in the SIP APN. 232 IP packets from the mobile node and from the correspondent node, will 233 be translated to use the IP address assigned by the respective APN. 234 The translated packets are forwarded through the home network. 236 3.1. Potential Limitations and Workarounds 238 The approach specified in this document have some known limitations 239 and can only be enabled when some assumptions are met. These 240 limitations and the related considerations are specified in this 241 section. 243 1. The mobile node is assigned a DNS server from the default-APN and 244 all the DNS traffic will be routed to the DNS server in the 245 default home-network. DNS is a global name space and generally 246 there should not be any issues with DNS name resolutions for 247 services in the other home networks. However, if a given APN/ 248 home-network (other than the default home-network) is hosting 249 private DNS name space, the DNS resolution requests initiated by 250 the mobile node will always end up in the default home-network 251 and those resolutions will be incorrect. There are clearly 252 approaches to deal with this problem. 254 * There are two potential approaches to deal with this problem. 255 These approaches are outside the scope of this document, but 256 few points related to those approaches are presented for 257 further study. In both the cases, the mobile access gateway 258 has the assumed capability to recover DNS information 259 provisioned for that home network (or obtained using Protocol 260 Configuration options related to primary and secondary DNS 261 server addresses, when using 3GPP S2a interface). 263 * In one approach, the mobile access gateway can maintain the 264 different DNS server configurations for the different home- 265 networks, and create a single ordered list of DNS servers and 266 provide it to the mobile node as part of the DHCP 267 configuration message. Such an approach assumes that the 268 mobile access gateway has chosen to establish connections to 269 all the APN's allowed for that mobile node prior to detecting 270 any application specific flows. 272 * Alternatively, the mobile access gateway can store the 273 recovered DNS server information and only provide its own IP 274 address as DNS server to the client. The MAG is then operable 275 to receive DNS requests from clients and to determine to which 276 DNS server to proxy the request. The mobile access gateway 277 may use preference information or requested realm to select a 278 DNS server. If the selected DNS server returns an error with 279 unknown realm, the mobile access gateway may subsequently 280 select an alternative DNS server. 282 2. If the configured APN's/home-networks are hosting a set of 283 applications and if those applications have no unique traffic 284 selectors that the mobile access gateway can apply and identify 285 the IP packets in an unambiguous way, this approach will not 286 work. 288 * There is no workaround for this limitation. In such 289 deployments, those APN's/home-networks hosting applications 290 with no unique traffic selectors have to be excluded from 291 multiple home network support. 293 4. Operational Details 295 Figure 2 explains the operational sequence of the Proxy Mobile IPv6 296 signaling message exchange between the mobile access gateway and the 297 local mobility anchor when supporting multiple IPv4 home address 298 support. 300 MN MAG AAA LMA-1 LMA-2 LMA-3 301 (Default-APN) (SIP-APN) (Internet-APN) 302 | | | | | 303 | (1) MN Attachment + Access Authentication | 304 |--------->| | | 305 | | | | 306 | | (2) Access Request/Access Accept | 307 | |<-------->| | 308 | | | 309 | + (3) APN Flow Selector Insertion | 311 | | | | 312 | | (4) PBU/PBA (MN-1, Internet-APN, HoA-1) | 313 | |<-------------------->| | 314 | | | | 315 | | (5) PMIP Tunnel | | 316 | |<====================>| | 317 | | | | 318 | (6) DHCPDISCOVER/OFFER/REQUEST/ACK (HoA-1) | 319 |<-------->| | | 320 | | | 321 | (7) Default IP flow (Source=HoA-1) | 322 |----------*--=================-->| | 324 | (8) SIP/RTP flow (Source=HoA-1) | 325 |--------->| | 326 | | (9) PBU/PBA (MN-1, SIP-APN, HoA-2) | 327 | |<--------------------------------->| | 328 | | | | 329 | |(10) PMIP Tunnel | | 330 | |<=================================>| | 331 | | 332 | (11) SIP/RTP flow (Source=HoA-2 after translation at MAG | 333 |----------*-===============================-->| | 334 | | 335 | | 337 | (12) HTTP Flow (Source=HoA-1) | 338 |--------->| | 339 | | (13) PBU/PBA (MN-1, Internet-APN, HoA-3) | 340 | |<---------------------------------------------->| 341 | | | 342 | | (14) PMIP Tunnel | 343 | |<==============================================>| 344 | | 345 | (15) HTTP Flow (Source=HoA-3 after translation at MAG) | 346 |----------*-=============================================->| 348 Figure 2: Exchange of IP Traffic Offload Selectors 350 o Step-1: The mobile node (MN1) attaches to the access link and 351 completes the access authentication. Based on the interworking 352 between the access authentication function (such as EAP 353 Authenticator, or by virtue of being in the AAA path), the mobile 354 access gateway learns the authenticated identity and the link- 355 layer address of the mobile node. 357 o Step-2: The mobile access gateway obtains the mobile node's policy 358 profile, which includes the list of home networks (APN's/Local 359 mobility anchors that that the mobile node is allowed to access). 360 It also includes the IP flow selectors for identifying the 361 application traffic associated with each of those home networks. 363 o Step-3: The mobile access gateway installs the Policy Based 364 Routing rules for detecting the application traffic associated 365 with different home networks. For example, HTTP packets will be 366 associated with the home network serving the Internet APN (LMA-3), 367 SIP/RTP packets will be associated with the home network serving 368 SIP APN (LMA-2), and all other IP flows will be associated with 369 the default home APN (LMA-1). The mobile access gateway can 370 complete the Proxy Mobile IPv6 signaling with different home 371 networks based on the traffic detect function, or it may complete 372 the signaling with all the home networks right after the mobile 373 node's attachment to the access link. 375 o Step-4 to Step-7: The mobile access gateway completes the Proxy 376 Mobile IPv6 signaling with the local mobility anchor (LMA-1) 377 serving the default home APN. This is as specified in [RFC5213] 378 and [RFC5844]. The obtained IPv4 address (HoA-1) is delivered to 379 the mobile node over DHCPv4. This is the only IPv4 address from 380 the home network that is assigned to the mobile node. The mobile 381 node uses this IPv4 address as the source address with all of its 382 applications when using the attached access technology. The 383 mobile access gateway tunnels all the application traffic, except 384 the application traffic associated with the other home networks, 385 through the established Proxy Mobile IPv6 tunnel. These IP flows 386 will not be subjected to any NAT translation treatment. 388 o Step-8 to Step-11: The mobile node launches a SIP application and 389 initiates the SIP signaling. The traffic detect function on the 390 mobile access gateway identifies this application traffic and 391 determines that this application traffic needs to be routed to the 392 home network serving the SIP APN. The mobile access gateway 393 completes the needed Proxy Mobile IPv6 signaling with the local 394 mobility anchor (LMA-2) and obtains an IPv4 address (HoA-2) for 395 the mobile node. It also inserts a NAT translation rule, which 396 essentially identifies the application traffic associated with SIP 397 and translates it to use the IP address assigned by that home 398 network. "Application Traffic: SIP/RTP, NAT Internal IPv4 399 Address: HoA-1, NAT External IPv4 Address: HoA-2. 401 o Step-12 to Step-15: The mobile node launches a Web browser 402 application and opens a URL link. The traffic detect function on 403 the mobile access gateway identifies this HTTP application traffic 404 and determines that this application traffic needs to be routed to 405 the home network serving the Internet APN. The mobile access 406 gateway completes the needed Proxy Mobile IPv6 signaling with the 407 local mobility anchor (LMA-2) and obtains an IPv4 address for the 408 mobile node. It also inserts a NAT translation rule, which 409 essentially identifies the application traffic associated with 410 HTTP and translates it to use the IP address assigned by that home 411 network. "Application Traffic: Internet, NAT Internal IPv4 412 Address: HoA-1, NAT External IPv4 Address: HoA-3. 414 o The IP traffic from the mobile node belonging to different 415 applications will now get NAT translated to use the IPv4 address 416 assigned by the respective home network and will be routed through 417 that network correctly. However, the application traffic 418 belonging to the default home network (APN) does not require any 419 NAT translation. The home network can correctly apply application 420 specific charging, or other policy functions on the mobile node's 421 IP traffic. 423 5. IANA Considerations 425 This document does not require any IANA actions. 427 6. Security Considerations 429 This specification does not define any new protocol extensions and 430 therefore does not identify any specific issues on the protocol 431 security. 433 When multiple APN (home network) support is enabled, per this 434 specification, the mobile node's IP flows belonging to different 435 applications selectively get NAT translated and it essentially 436 introduces certain vulnerabilities which are common to any NAT 437 deployment. These vulnerabilities and the related considerations 438 have been well documented in the NAT specification [RFC2663]. There 439 are no additional considerations above and beyond what is already 440 documented by the NAT specifications and which are unique to the 441 approach specified in this document. 443 7. Acknowledgements 445 The authors would like to first thank 3GPP body for creating the APN 446 concept and the associated issues for WLAN access, thus making this 447 technical work relevant, without which the document would not have 448 existed. 450 The authors would also like to thank Ivan Centeno on the importance 451 of this use-case and the need to address this issue. Finally, the 452 authors would like to thank Kent Leung, Rajesh Pazhyannur, Eric 453 Hamel, Sanjay Kumar and Radhakrishna C, on the reviews related to 454 this approach and specifically the discussions related to Split DNS, 455 importance of requiring home-networks with non-overlapping 456 applications. 458 8. References 460 8.1. Normative References 462 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 463 Requirement Levels", BCP 14, RFC 2119, March 1997. 465 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 466 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 468 [RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy 469 Mobile IPv6", RFC 5844, May 2010. 471 [RFC6089] Tsirtsis, G., Soliman, H., Montavont, N., Giaretta, G., 472 and K. Kuladinithi, "Flow Bindings in Mobile IPv6 and 473 Network Mobility (NEMO) Basic Support", RFC 6089, 474 January 2011. 476 8.2. Informative References 478 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 479 Translator (NAT) Terminology and Considerations", 480 RFC 2663, August 1999. 482 [RFC5149] Korhonen, J., Nilsson, U., and V. Devarapalli, "Service 483 Selection for Mobile IPv6", RFC 5149, February 2008. 485 [RFC6459] Korhonen, J., Soininen, J., Patil, B., Savolainen, T., 486 Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation 487 Partnership Project (3GPP) Evolved Packet System (EPS)", 488 RFC 6459, January 2012. 490 [TS23402] 3GPP, "Architecture enhancements for non-3GPP accesses", 491 2010. 493 Authors' Addresses 495 Sri Gundavelli 496 Cisco 497 170 West Tasman Drive 498 San Jose, CA 95134 499 USA 501 Email: sgundave@cisco.com 503 Mark Grayson 504 Cisco 505 11 New Square Park 506 Bedfont Lakes, FELTHAM TW14 8HA 507 ENGLAND 509 Email: mgrayson@cisco.com 511 Yiu L. Lee 512 Comcast 513 One Comcast Center 514 Philadelphia, PA 19103 515 U.S.A. 517 Email: yiu_lee@cable.comcast.com 518 URI: http://www.comcast.com 520 Hui Deng 521 China Mobile 522 53A,Xibianmennei Ave. 523 Xuanwu District, Beijing 100053 524 China 526 Email: denghui02@gmail.com 527 Hidetoshi Yokota 528 KDDI Lab 529 2-1-15 Ohara 530 Saitama, Fujimino 356-8502 531 Japan 533 Email: yokota@kddilabs.jp