idnits 2.17.1 draft-gundavelli-netext-pmipv6-wlan-applicability-06.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 == Line 517 has weird spacing: '... xx xxx...' == Line 528 has weird spacing: '... xxxx xxx...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 21, 2013) is 3830 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'I-D.draft-ietf-netext-radius-pmip6' is mentioned on line 126, but not defined == Missing Reference: 'I-D.draft-ietf-netlmm-pmipv6-mib' is mentioned on line 127, but not defined == Unused Reference: 'RFC6085' is defined on line 726, but no explicit reference was found in the text == Unused Reference: 'I-D.liebsch-netext-pmip6-authiwk' is defined on line 732, but no explicit reference was found in the text == Unused Reference: 'RFC4861' is defined on line 738, but no explicit reference was found in the text == Unused Reference: 'RFC5415' is defined on line 742, but no explicit reference was found in the text == Unused Reference: 'RFC6224' is defined on line 754, but no explicit reference was found in the text == Unused Reference: 'RFC6475' is defined on line 758, but no explicit reference was found in the text == Unused Reference: 'RFC6572' is defined on line 762, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 13 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 B. Pularikkal 4 Intended status: Standards Track R. Koodli 5 Expires: April 24, 2014 Cisco 6 October 21, 2013 8 Applicability of Proxy Mobile IPv6 for Service Provider Wi-Fi 9 Deployments 10 draft-gundavelli-netext-pmipv6-wlan-applicability-06.txt 12 Abstract 14 Proxy Mobile IPv6 is a network-based mobility management protocol. 15 The protocol is designed for providing mobility management support to 16 a mobile node, without requiring its participation in any IP mobility 17 related signaling. The base protocol is defined in an access 18 technology independent manner, it identifies the general requirements 19 from the link-layer for supporting the protocol operation. However, 20 it does not provide any specific details on how it can be supported 21 on a specific access technology. This specification identifies the 22 key considerations for supporting Proxy Mobile IPv6 protocol on the 23 widely deployed wireless LAN access architectures, based on IEEE 24 802.11 standards. It explores the current dominant wireless LAN 25 deployment models and provides the needed interworking details. 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on April 24, 2014. 44 Copyright Notice 46 Copyright (c) 2013 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 2. Conventions & Terminology . . . . . . . . . . . . . . . . . . 5 64 2.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 5 65 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 67 3. WLAN as an access technology and the related considerations . 6 68 3.1. Controller based WLAN Access Network - Central Switched . 6 69 3.2. Controller based WLAN Access Network - Local Switched . . 7 70 3.3. WLAN Access Network with Autonomous APs . . . . . . . . . 7 71 3.4. Comparison between WLAN Access Network Models . . . . . . 8 73 4. Deployment Models . . . . . . . . . . . . . . . . . . . . . . 9 74 4.1. Flat Model Deployments (Single PMPv6 Domains) . . . . . . 9 75 4.1.1. Flat Model with LMA on WAG . . . . . . . . . . . . . . 9 76 4.1.2. Flat Model with LMA on P-GW . . . . . . . . . . . . . 10 77 4.2. Hierarchical Deployments with Domain Chaining . . . . . . 11 78 4.2.1. PMIPv6 to PMIPv6 chaining with RFC compatible 79 Level-1 and Level-2 MAG and LMA functions . . . . . . 12 80 4.2.2. PMIPv6 to S2a Chaining with RFC compatible Level-1 81 LMA & s2a (PMIPv6 or GTPv2) towards 3GPP EPC . . . . . 13 83 5. Deployment Considerations . . . . . . . . . . . . . . . . . . 15 84 5.1. IP addressing Considerations . . . . . . . . . . . . . . . 15 85 5.2. Access Authentication & User Identity . . . . . . . . . . 15 86 5.3. Policy Provisioning & Enforcement . . . . . . . . . . . . 16 87 5.4. Charging Considerations . . . . . . . . . . . . . . . . . 16 88 5.5. Legal Intercept . . . . . . . . . . . . . . . . . . . . . 17 89 5.6. SIPTO Considerations . . . . . . . . . . . . . . . . . . . 17 91 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 93 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20 95 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 96 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 97 9.1. Normative References . . . . . . . . . . . . . . . . . . . 22 98 9.2. Informative References . . . . . . . . . . . . . . . . . . 22 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 102 1. Introduction 104 Proxy Mobile IPv6 is a network-based mobility management protocol 105 specified in [RFC5213]. The protocol can be used for providing 106 mobility management support to a mobile node within a localized 107 domain, without requiring its participation in any IP mobility 108 related signaling. 110 The core functional entities in the Proxy Mobile IPv6 domain are the 111 local mobility anchor (LMA) and the mobile access gateway (MAG). The 112 local mobility anchor is responsible for maintaining the mobile 113 node's reachability state and is the topological anchor point for the 114 mobile node's home network. The mobile access gateway is the entity 115 that performs the mobility management on behalf of a mobile node, and 116 it resides on the access link where the mobile node is anchored. The 117 mobile access gateway is responsible for detecting the mobile node's 118 movements to and from the access link and for initiating binding 119 registrations to the mobile node's local mobility anchor. 121 There are numerous protocol extensions defined to Proxy Mobile IPv6 122 protocol, for supporting various features. These features include 123 support for IPv4 transport and addressing support [RFC5844], GRE Key 124 negotiation support [RFC5845], Binding Revocation support [RFC5846]. 125 Diameter support [RFC5779], RADIUS support 126 [I-D.draft-ietf-netext-radius-pmip6] and Proxy Mobile IPv6 MIB 127 [I-D.draft-ietf-netlmm-pmipv6-mib]. All of these features give the 128 protocol a completeness for being adopted as a network-based mobility 129 management protocol within a micro-mobility domains, based on WLAN 130 access architectures. 132 This specification identifies the key considerations for supporting 133 Proxy Mobile IPv6 protocol in micro-mobility domains, such as in 134 wireless LAN access architectures, based on IEEE 802.11 standards. 136 2. Conventions & Terminology 138 2.1. Conventions 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 142 document are to be interpreted as described in RFC 2119 [RFC2119]. 144 2.2. Terminology 146 All the mobility related terms used in this document are to be 147 interpreted as defined in the Proxy Mobile IPv6 specifications 148 [RFC5213], [RFC5844], [RFC5845] and [RFC5846]. Additionally, this 149 document uses the following abbreviations: 151 o WLAN (Wireless Local Area Network) - A wireless network. 153 o WTP (Wireless Termination Point): The entity that functions as the 154 termination point for the network-end of the IEEE 802.11 based air 155 interface from the mobile node. It is also knows as the Wireless 156 Access Point. 158 o WLC (Wireless LAN Controller): The entity that provides the 159 centralized forwarding, routing function for the user traffic. 160 All the user traffic from the mobile nodes attached to the WTP's 161 is typically tunneled to this centralized WLAN access controller. 163 3. WLAN as an access technology and the related considerations 165 WLAN as wireless access technology has experienced significant 166 adoption in both Enterprise and Service Provider Deployments. 167 Enterprises leverage WLAN networks to provide Mobile access to their 168 employees and partners to the enterprise network resources. Service 169 Providers leverage WLAN for providing wireless Access to their 170 subscribers by deploying indoor and outdoor Wi-Fi hotspots. These 171 PWLAN deployments allow the service providers with additional revenue 172 generation opportunities through the deployment of various use cases, 173 which leverage the WLAN access. PWLAN networks typically deploy two 174 types of SSIDs, Open and Secured. Open SSIDs are typically used 175 along with some web portal based authentication and provides 176 complimentary, pre-paid or subscription based Wi-Fi access to 177 Internet. Secure SSIDs are typically used for Mobile Data Offload 178 scenarios, which will use SIM card based authentication for the 179 Mobile subscribers. 181 For the WLAN access network deployment, three models are available- 182 a) Controller based WLAN Access Network with Converged CP-DP, b) 183 Controller based WLAN Access Network with Split CP-DP & c) WLAN 184 Access Network with Autonomous APs. Since these two options can be 185 applied to various models, the Access Network section will be covered 186 first followed by the detailed overview of various Deployment Models. 188 3.1. Controller based WLAN Access Network - Central Switched 190 This is a split MAC model with CAPWAP where 802.11 control plane 191 functions are divided between AP and the WLC. WLC also handles AP 192 provisioning, management and RRM. In this model, end user data 193 traffic is always switched through the WLC via a CAPWAP data plane 194 tunnel. From the PMIPv6 implementation perspective, the MAG 195 functionality resides on the controller. This WLAN access network 196 model is illustrated in Figure 1 below. 198 +-------+ CAPWAP CNTRL +-------------+ 199 | +---------------------+ | PMIPv6 towards LMA 200 | AP | | WLC + MAG |+------------------> 201 | +---------------------+ | 202 +-------+ CAPWAP DATA +-------------+ 204 Figure 1: WLAN Access - Central Switched 206 3.2. Controller based WLAN Access Network - Local Switched 208 This is a split MAC model with CAPWAP where 802.11 control plane 209 functions are divided between AP and the WLC. WLC also handles AP 210 provisioning, management and RRM. In this model, end user data 211 traffic locally switched by the AP and does not reach the WLC. From 212 the PMIPv6 implementation perspective, the MAG functionality resides 213 on the AP. WLC does not play a role in the end user data traffic 214 forwarding. This WLAN access network model is illustrated in Figure 215 2 below. 217 +----------+ 218 CAPWAP CNTRL | | 219 +-----------------------+ WLC | 220 | | | 221 | +----------+ 222 | 223 | 224 | 225 +----+------+ 226 | | PMIPv6 towards LMA 227 | AP + MAG +---------------------------> 228 | | 229 +-----------+ 231 Figure 2: WLAN Access - Local Switched 233 3.3. WLAN Access Network with Autonomous APs 235 In this Access network model, WLCs will not be used. APs will 236 perform all aspects of the 802.11 control plane and signaling. From 237 the PMIPv6 implementation perspective, the MAG functionality will 238 reside on the AP. This WLAN access model is illustrated in Figure 3 239 below. 241 +------------+ 242 | | PMIPv6 towards LMA 243 | AP + MAG |-------------------------> 244 | | 245 +------------+ 246 Figure 3: WLAN Access - with Autonomous APs 248 3.4. Comparison between WLAN Access Network Models 250 In general a controller-based architecture brings several advantages 251 over autonomous AP deployments. The standards based split-mac model 252 where many 802.11 functions are offloaded to the controller from the 253 AP allows more lightweight and hence cost effective access point 254 implementation. Also controller based architecture offers more 255 flexible and scalable provisioning and operational management of the 256 APs. Controllers may also support sophisticated Wi-Fi Radio Resource 257 Management. No effective RRM implementation options are available in 258 autonomous AP deployments. Another advantage of the controller based 259 implementation model is the ability to localize the mobility events 260 between the APs at the controller. 262 For the controller-based models, whether to use central switched or 263 local switched depends up on the particular deployment models and the 264 AP, Controller capabilities. In the central switched model, the 265 mobility events between the APs are masked from the Wi-Fi aggregation 266 gateway. However it will require the controller to handle all the 267 end user data traffic, which may not scale in some cases. This will 268 also put restrictions on the location of the controllers in a 269 network, since the controllers will always need to be installed 270 closer to the APs to ensure optimized forwarding path for the Wi-Fi 271 end user traffic. Local switched mode may be suited in deployments 272 where Wi-Fi gateways can handle high rate of mobility events and it 273 is desirable to place controllers in a centralized location. 275 4. Deployment Models 277 There are numerous "field of use" cases around Service Provider Wi-Fi 278 deployments; some of the key use cases are listed below: 280 Metro Wi-Fi model indoor and outdoor Wi-Fi deployments 282 Mobile Data Offload 284 Hospitality Wi-Fi 286 Community Wi-Fi 288 Whole Sale Deployment Model 290 Municipal Wi-Fi 292 PMIPv6 can be leveraged as the underlying architecture for any of 293 these deployment use cases. The built in Network Based Mobility 294 Management support available on PMIPv6 along with the rich set of 295 protocol extensions make it a well suited standards based protocol of 296 choice for SP Wi-Fi deployments. 298 Various "field of use cases" in Service Provider Wi-Fi can be mapped 299 to one of the deployment models described in the section. For all of 300 these deployment models, any of the WLAN access network 301 implementation options described earlier in section 3 can be 302 leveraged. For the sake of simplicity, discussions in this section 303 will use the Controller based central switched option on the access 304 network side for illustrative purposes. 306 4.1. Flat Model Deployments (Single PMPv6 Domains) 308 In this deployment model, PMIPv6 MAG functionality resides on the 309 access network element (typically on AP or WLC) and the PMIPv6 LMA 310 functionality resides either on a Wi-Fi Subscriber Aggregation 311 Gateway (WAG) or a PDN Gateway. LMA on WAG will be used for the 312 deployment scenarios, which does not require Mobile data offload. 313 LMA function on PDN Gateway will be used for the packet core 314 integration use cases where one or more SSIDs on the WLAN access 315 network side are enabled for Mobile Data Offload. Flat model 316 deployments are described in detail in the next two sub-sections. 318 4.1.1. Flat Model with LMA on WAG 320 This model is illustrated below in Figure 4. In this model, the 321 Wi-Fi access network may leverage open SSIDs or secured SSIDs. If 322 the open SSID is in use, subscriber access will always be controlled 323 by some sort of Web portal based authentication or MAC address based 324 automatic login or a combination of both. Secured SSID may leverage 325 non-SIM based authentication scenarios such as EAP-TLS or EAP-TTLS. 326 WAG is the subscriber management element, which acts as the policy 327 enforcement point for the Wi-Fi subscribers. WAG works in 328 conjunction with an external PCRF. Interconnect between the PCRF and 329 WAG in this model use either RADIUS or Diameter and in some cases may 330 rely on some proprietary protocol. WAG uses either a RADIUS or 331 diameter interface to forward the billing related information to an 332 external billing entity. Two common subscriber billing options are 333 pre-paid and post paid. 335 +-------+ +-----+ 336 |BILLING+----+ |PCRF | 337 +-------+ | +--+--+ 338 | | 339 RADIUS/ RADIUS/ 340 DIAMETER DIAMETER 341 | | 342 | | 343 + | 344 +----+ +------+ | 345 +---+ CAPWAP|WLC | PMIPv6| LMA | | 346 |AP |+------+ + +-------+ + +-------+ 347 +---+ |MAG | | WAG | 348 +----+ +--+---+ 349 | 350 | 351 | 352 _----_ 353 _( )_ 354 ( Internet ) 355 (_ _) 356 '----' 358 Figure 4: Flat Model with LMA on WAG 360 4.1.2. Flat Model with LMA on P-GW 362 This model is illustrated below in figure 5. In this model, LMA 363 resides on a P-GW, which is part of a 3GPP Evolved Packet Core. S2a 364 Mobility over PMIPv6 is part of 3GPP standard and allows trusted WLAN 365 to EPC integration. Since the Wi-Fi access network is considered 366 trusted, the solution always assumes the SSID is secured. SSID will 367 be typically enabled for one of the SIM based authentication options 368 such as EAP-SIM, EAP-AKA or EAP-AKA'. In this model, P-GW handles 369 the subscriber policy enforcement. P-GW acts as a PCEF and talks to 370 an external PCRF over diameter interface. P-GW supports diameter 371 based billing interface for offline and or online charging. Two 372 common subscriber-billing options are pre-paid and post paid. 374 From an authentication perspective the WLAN will have a diameter or 375 RADIUS interface to a 3GPP AAA server. This interface may be 376 directly between the AP/WLC or in some cases with a proxy AAA server 377 in the WLAN network side. 379 + +--------+ 380 WLAN Access NW | Packet Core +--+BILLING | 381 | | +--------+ 382 | +------+ | 383 | | 3GPP | | +----+ 384 ++-----+ AAA | DIAMETER |PCRF| 385 | | +------+ | +-+--+ 386 DIAMETER/ | | 387 RADIUS| | | 388 | | + | 389 +--+--+| +--------+ DIAMETER 390 +---+ CAPWAP| WLC || PMIPv6 | LMA | | 391 |AP +-------+ + +------------+ + +-------+ 392 +---+ | MAG || | P-GW | 393 +-----+| +----+---+ 394 | | 395 | | 396 _----_ 397 _( )_ 398 ( Internet ) 399 (_ _) 400 '----' 402 Figure 5: Flat Model with LMA on P-GW 404 4.2. Hierarchical Deployments with Domain Chaining 406 Domain chaining may be suited for some large scale SP Wi-Fi 407 deployments and hybrid solutions which supports which supports open 408 and secured SSIDs with or without Seamless Data Offload for Mobile 409 operators. Domain chaining allows localization of mobility events at 410 the chaining point for the first level domain. This is model is 411 suited for inter-operator roaming scenarios as well. 413 There are two types of chaining models, both of which are described 414 in the following sub-sections. 416 4.2.1. PMIPv6 to PMIPv6 chaining with RFC compatible Level-1 and 417 Level-2 MAG and LMA functions 419 This model assumes that there are no requirements for packet core 420 integration. The primary motivation behind chaining would be to 421 introduce simplicity and scalability though the two level domain 422 hierarchy. The chaining point not only allows for the localization 423 of mobility events in a particular region, but can act as the SIPTO 424 offload point for traffic which need to be selectively offloaded. 425 SIPTO may happen at per subscriber level or per traffic flow level 426 for a given subscriber. Another advantage, the chaining model 427 introduces is the reduced scaling requirements around data plane 428 tunnels. For example, with hierarchical model, simultaneous number 429 of data plane tunnels need to be supported at a level LMA or level 2 430 LMA would be significantly lower compared the requirements on the LMA 431 function in a flat deployment model. This model is illustrated in 432 Figure 6. 434 +------+ +---------+ 435 |PCRF | |BILLING | 436 +---+--+ +-----+---+ 437 | | 438 | | 439 | | 440 +----------+ | 441 | | x xxxxx 442 | | xx xxx 443 | | xx xx 444 +----+ +------+ ++----+-+ x xx 445 +--+ CAPWAP |WLC |PMIPv6|L1-LMA|PMIPv6 | | xx x 446 |AP+--------+ + +------| + +-------+L2-LMA +---+x CENTRALIZED xx 447 +--+ |MAG | |L2-MAG| | | x x 448 +----+ +---+--+ +---+---+ x SERVICES x 449 SIPTO | x x 450 xxx+xxxxx x x 451 xx xx xx x 452 xx x xxxxxx 453 x xx 454 xx x 455 x LOCALIZED xx 456 x SERVICES xx 457 x x 458 xx x 459 xxx xxx 460 xxxxxxxxx 462 Figure 6: PMIPv6 to PMIPv6 Chaining 464 In this model per subscriber policy enforcement is expected to happen 465 at level-1 LMA and level-2 LMA. Depending up on the deployment use 466 case, interaction between PCRF may be done either just at the level-2 467 LMA or at both the chaining point as well as level-2 LMA. Charging 468 support may or may not be a requirement at the chaining point and 469 will depend up on whether SIPTO is enabled. 471 4.2.2. PMIPv6 to S2a Chaining with RFC compatible Level-1 LMA & s2a 472 (PMIPv6 or GTPv2) towards 3GPP EPC 474 In this model, the chaining point provides a 3GPP complaint S2a 475 interface towards the packet core for trusted WLAN to EPC 476 integration. S2a interface may use either PMIPv6 or GTPv2 protocol. 477 In the model, for the secured WLANs (SSIDs), which are configured for 478 SIM, based authentication for Mobile offload, the level-1 gateway, 479 which performs the chaining, may act as the 3GPP AAA proxy as well. 480 Alternatively some deployments may use an out of band authentication 481 model and the intermediate gateway does not perform and AAA proxy 482 functions. The ability for the intermediate gateway to perform AAA 483 proxy functions are more relevant when diameter based authentication 484 support is required for packet core integration. For this scenario, 485 the WLC will be forwarding EAP messages over RADIUS and the 486 intermediate gateway will provide a diameter AAA interface towards a 487 3GPP AAA server. This model is illustrated in Figure 7. This model 488 can simultaneously support a combination of mobile data offload and 489 non-offload scenarios as described below: 491 Open SSID and Web Portal based authentication: Intermediate gateway, 492 which will also be the WAG, will have an interface towards a local 493 PCRF and may use RADIUS or DIAMETER interface. IP address assignment 494 will be managed by the intermediate gateway. 496 Secured SSID and NSWO: For this use case, Mobile operator's 497 subscribers will get authenticated using one of the SIM based 498 authentication methods, but UE data will not be offloaded to the 499 packet core. Instead the intermediate gateway will perform SIPTO of 500 all the subscriber traffic. UE address assignment will be managed by 501 the intermediate gateway. 503 Secured SSID and Packet Core Integration: For this use case, Mobile 504 operator's subscribers will get authenticated using one of the SIM 505 based authentication methods and S2a (over PMIPv6 or GTPv2) will be 506 used to tunnel the UE traffic towards a P-GW in the packet core. 507 Some deployments also may implement flow based SIPTO for the UE 508 traffic at the intermediate gateway. UE address assignment will be 509 managed by the P-GW. 511 +----+ +-------+ 512 |PCRF| |BILLING| 513 +-+--+ +--+----+ 514 | | 515 | | 516 | | xxx 517 +---------+ | xx xxx 518 | | xx xx 519 | | xx xx 520 | | x xx 521 +------+ +---+ ++++-+ x x 522 +--+ CAPWAP | WLC |PMIPv6|LMA| S2a | | xx MOBILE x 523 |AP+--------+ + +------+ + +---------+|P-GW+----+ NW x 524 +--+ | MAG | |MAG| PMIPv6 / | | xx x 525 +------+ +-+-+ GTPv2 +----+ x RESOURCES x 526 | xx x 527 NSWO/ xxx x 528 SIPTO xxxx xxx 529 | xxx 530 xxx+xxxxx 531 xx xxx 532 xx x 533 x xx 534 x LOCALIZED x 535 x SERVICES x 536 x x 537 xx xx 538 xxxx xxx 539 xxxxxxx 541 Figure 7: PMIPv6 to S2a Chaining 543 5. Deployment Considerations 545 This section covers deployment considerations for PMIPv6 based SP 546 Wi-Fi Architecture Models. Key areas are covered in the following 547 sub-sections. 549 5.1. IP addressing Considerations 551 PMIPv6 supports IPv4, IPv6 and dual stack addressing for UEs. For 552 all deployment models, LMA manages the address assignment for the 553 UEs. For the chaining scenarios, depending up on the deployment use 554 cases, the address assignment may be handled by the intermediate 555 gateways (level 1 LMAs) or the level-2 gateway (LMA and or P-GW). 556 LMA may either use a locally defined pool or it works with an 557 external DHCP server for address assignment. 559 For IPv4 addressing, the MAG acts as a DHCP server and completes the 560 LMA assigned IP address to the UE via DHCP messages. It is important 561 to provide protocol configuration options (PCOs) such as domain name, 562 DNS server address etc. to the UE. LMA can provide these PCOs in the 563 PBA message and MAG in turn can pass the same to the UE via DHCP 564 message along with the client IP address. 566 For IPv6 addressing, it is a general practice in SP Wi-Fi deployments 567 to assign a dedicated prefix per UE. In order for this dedicated 568 prefix assignment to work, MAG must support unicast RA as defined in 569 RFC 6085. MAG may use either DHCPv6 or SLAAC for prefix assignment. 570 SLAAC is the preferred option since it is universally supported by 571 various UEs compared to DHCPv6. If SLAAC is the option used for 572 prefix assignment, MAG should use "Recursive DNS Server" Option and 573 "DNS Search List" Options, specified in RFC 6106 for providing the 574 DNS configuration using IPv6 messages. 576 5.2. Access Authentication & User Identity 578 As briefly mentioned in the previous section, the access 579 authentication mechanisms depend up on the particular deployment use 580 case. For metro Wi-Fi model deployments and other indoor / outdoor 581 Wi-Fi deployments, web portal based authentication is very commonly 582 used. A common web portal based authentication scenario is an 583 existing subscriber presenting the user id and the password 584 credential to a web login page before he can access the Internet. 585 There are various to this model out there such as new user accessing 586 the network and signing up for subscription based or one time usage 587 services, or users leveraging vouchers for access which will impose 588 time and or quota limit etc. 590 Another common user authentication scenario implemented in many metro 591 Wi-Fi deployments is automatic authentication based up on mac 592 address. This model allows an existing subscriber to register one or 593 more mac-addresses for automatic access When the subscriber tries 594 access the Wi-Fi network for the first time from a UE device 595 subscriber will have to go through a portal based authentication and 596 the system captures the mac-address of the device at that time so 597 that the subsequent access will allow automatic access from that UE 598 device. 600 For secured SSIDs an 802.1X based authentication mechanism will be in 601 place. Even though most of the Wi-Fi deployments out there rely on 602 open SSIDs except for Mobile data offload use cases, it is the intent 603 of the industry to move towards secured SSIDs and implement some EAP 604 based authentication mechanisms. 802.1x based authentication will be 605 requirement for Hotspot 2.0 compliance. For mobile data offload 606 scenarios, secure SSIDs with SIM card based authentication will be in 607 use. 609 PMIPv6 protocol allows the access network to pass the user identity 610 such as mac-address, NAI, IMSI etc. towards the network side GW (LMA/ 611 WAG or LMA/P-GW) through the PMIPv6 control messages. With this 612 standardized user identity presentation, there is no need to rely on 613 alternative proprietary options. 615 5.3. Policy Provisioning & Enforcement 617 Policy provisioning systems referred to as PCRF in the 3GPP 618 terminology is the entity which decides what kind of services a 619 specific subscriber can get and for what duration, what kind of 620 charging polices are applicable to the subscriber etc. Depending up 621 on the deployment model, the gateways talk to the PCRF entity either 622 using diameter interface (typically Gx) or RADIUS interface. RADIUS 623 interface is more common in WAG deployments, which do not handle 3GPP 624 packet core integration, and diameter is typically used in 3GPP 625 packet core elements such as P-GW. Use of diameter for PCRF 626 integration in non-3GPP deployments is also possible even though not 627 common. WAG/LMA or P-GW acts as the policy enforcement point and 628 works in conjunction with PCRF. 630 5.4. Charging Considerations 632 Accounting and Charging in service provider Wi-Fi deployments fall 633 under two broad categories a) Diameter based and b) RADIUS based. 634 Diameter based charging will be leveraged for Architecture models, 635 which use one or more 3GPP, network elements. RADIUS based charging 636 will be leveraged for the deployment models, which typically does not 637 involve packet core integration. 639 Diameter based charging leverages diameter protocol for the charging 640 interfaces. Diameter based charging architecture and the associated 641 interfaces are defined in 3GPP standards. Charging in 3GPP can be 642 broadly classified into two categories a) Offline Charging and b) 643 Online Charging. In offline charging, resource usage is reported by 644 the network element to the billing system after the resource usage 645 has occurred. For online charging, authorization for the network 646 resource usage, must be obtained by the network prior to the actual 647 resource usage will be allowed. 649 Online charging maps to pre-paid charging use cases and offline 650 charging maps to post-paid charging use cases. Pre-paid and post- 651 paid charging is supported by RADIUS based charging models as well. 652 Charging information can be collected from various points in the 653 Wi-Fi network such as WLAN access network, MAG, chaining point LMA/ 654 P-GW etc. The type of charging and the required charging interfaces 655 will depend up on the particular use case model. 657 5.5. Legal Intercept 659 Legal Intercept stands for legally authorized capture & delivery of 660 subscriber communications data by a communications provider to a law 661 enforcement agency (LEA). The communications data, which the LEA 662 will intercept as part of the target subscriber surveillance, is 663 classified into two types, Communication Content (CC) and Intercept 664 Related Information (IRI). CC is the bearer data exchanged to and 665 from the subscriber. IRI provides the relevant context information 666 for the CC. IRI is a loosely defined term and the scope varies for 667 different end user applications. 669 In most of the countries, there are legal obligations for Service 670 Providers to facilitate the intercept of any subscriber's 671 communication, if requested by law enforcement agencies. 672 Communications Assistance for Law Enforcement Act (CALEA), the United 673 States wiretapping law passed in 1994 is an example for such legal 674 mandates. 676 For various SP Wi-Fi deployment models covered in this document, 677 legal intercept will be a requirement and one or more network 678 elements in the system should support the Intercept and forwarding or 679 IRI, CC or both to the LI mediation systems which in turn will 680 provide the intercepted information to law enforcement agencies 682 5.6. SIPTO Considerations 684 Depending up on the deployment use case, SIPTO may be desirable use 685 case for flat as well as hierarchical models. For the flat models, 686 SIPTO can be implemented at the MAG itself. With chaining model 687 SIPTO can be done either at the level-1MAG or the intermediate 688 gateway doing the chaining. 690 6. IANA Considerations 692 This specification does not require any IANA actions. 694 7. Security Considerations 696 All the security considerations from the base Proxy Mobile IPv6 697 specifications, [RFC5213] and [RFC5844], apply equally well to Proxy 698 Mobile IPv6 domains supporting IEEE 802.11-based access networks. 699 The support for IEEE 802.11-based access networks does not require 700 any new security considerations and does not introduce any new 701 security vulnerabilities known at this time. 703 8. Acknowledgements 705 The author of this document thanks the members of the NETLMM working 706 group for all the discussions related to this topic. 708 9. References 710 9.1. Normative References 712 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 713 Requirement Levels", BCP 14, RFC 2119, March 1997. 715 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 716 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 718 [RFC5779] Korhonen, J., Bournelle, J., Chowdhury, K., Muhanna, A., 719 and U. Meyer, "Diameter Proxy Mobile IPv6: Mobile Access 720 Gateway and Local Mobility Anchor Interaction with 721 Diameter Server", RFC 5779, February 2010. 723 [RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy 724 Mobile IPv6", RFC 5844, May 2010. 726 [RFC6085] Gundavelli, S., Townsley, M., Troan, O., and W. Dec, 727 "Address Mapping of IPv6 Multicast Packets on Ethernet", 728 RFC 6085, January 2011. 730 9.2. Informative References 732 [I-D.liebsch-netext-pmip6-authiwk] 733 Gundavelli, S., Liebsch, M., and P. Seite, "PMIPv6 inter- 734 working with WiFi access authentication", 735 draft-liebsch-netext-pmip6-authiwk-05 (work in progress), 736 September 2012. 738 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 739 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 740 September 2007. 742 [RFC5415] Calhoun, P., Montemurro, M., and D. Stanley, "Control And 743 Provisioning of Wireless Access Points (CAPWAP) Protocol 744 Specification", RFC 5415, March 2009. 746 [RFC5845] Muhanna, A., Khalil, M., Gundavelli, S., and K. Leung, 747 "Generic Routing Encapsulation (GRE) Key Option for Proxy 748 Mobile IPv6", RFC 5845, June 2010. 750 [RFC5846] Muhanna, A., Khalil, M., Gundavelli, S., Chowdhury, K., 751 and P. Yegani, "Binding Revocation for IPv6 Mobility", 752 RFC 5846, June 2010. 754 [RFC6224] Schmidt, T., Waehlisch, M., and S. Krishnan, "Base 755 Deployment for Multicast Listener Support in Proxy Mobile 756 IPv6 (PMIPv6) Domains", RFC 6224, April 2011. 758 [RFC6475] Keeni, G., Koide, K., Gundavelli, S., and R. Wakikawa, 759 "Proxy Mobile IPv6 Management Information Base", RFC 6475, 760 May 2012. 762 [RFC6572] Xia, F., Sarikaya, B., Korhonen, J., Gundavelli, S., and 763 D. Damic, "RADIUS Support for Proxy Mobile IPv6", 764 RFC 6572, June 2012. 766 Authors' Addresses 768 Sri Gundavelli 769 Cisco 770 170 West Tasman Drive 771 San Jose, CA 95134 772 USA 774 Email: sgundave@cisco.com 776 Byju Pularikkal 777 Cisco 778 170 West Tasman Drive 779 San Jose, CA 95134 780 USA 782 Email: byjupg@cisco.com 784 Rajeev Koodli 785 Cisco 786 170 West Tasman Drive 787 San Jose, CA 95134 788 USA 790 Email: rcoodli@cisco.com