idnits 2.17.1 draft-ietf-dmm-best-practices-gap-analysis-02.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 127 has weird spacing: '...ocation is th...' -- The document date (October 20, 2013) is 3842 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-17) exists of draft-ietf-dmm-requirements-09 -- Obsolete informational reference (is this intentional?): RFC 5996 (Obsoleted by RFC 7296) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 DMM D. Liu, Ed. 2 Internet-Draft China Mobile 3 Intended status: Informational JC. Zuniga, Ed. 4 Expires: April 23, 2014 InterDigital 5 P. Seite 6 Orange 7 H. Chan 8 Huawei Technologies 9 CJ. Bernardos 10 UC3M 11 October 20, 2013 13 Distributed Mobility Management: Current practices and gap analysis 14 draft-ietf-dmm-best-practices-gap-analysis-02 16 Abstract 18 The present document analyses deplyment practices of existing 19 mobility protocols in a distributed mobility management environment. 20 It also identifies some limitations compared to the expected 21 functionality of a fully distributed mobility management system. The 22 comparison is made taking into account the identified DMM 23 requirements. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on April 23, 2014. 42 Copyright Notice 44 Copyright (c) 2013 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Functions of existing mobility protocols . . . . . . . . . . . 4 62 4. DMM practices . . . . . . . . . . . . . . . . . . . . . . . . 5 63 4.1. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 6 64 4.2. IP flat wireless network . . . . . . . . . . . . . . . . . 6 65 4.2.1. Host-based IP DMM practices . . . . . . . . . . . . . 8 66 4.2.2. Network-based IP DMM practices . . . . . . . . . . . . 12 67 4.3. 3GPP network flattening approaches . . . . . . . . . . . . 14 68 5. Gap analysis . . . . . . . . . . . . . . . . . . . . . . . . . 17 69 5.1. Distributed processing - REQ1 . . . . . . . . . . . . . . 17 70 5.2. Transparency to Upper Layers - REQ2 . . . . . . . . . . . 19 71 5.3. IPv6 deployment - REQ3 . . . . . . . . . . . . . . . . . . 19 72 5.4. Existing mobility protocols - REQ4 . . . . . . . . . . . . 20 73 5.5. Co-existence - REQ5 . . . . . . . . . . . . . . . . . . . 20 74 5.6. Security considerations - REQ6 . . . . . . . . . . . . . . 20 75 5.7. Multicast - REQ7 . . . . . . . . . . . . . . . . . . . . . 21 76 5.8. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 21 77 6. Security Considerations . . . . . . . . . . . . . . . . . . . 22 78 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 79 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 80 8.1. Normative References . . . . . . . . . . . . . . . . . . . 22 81 8.2. Informative References . . . . . . . . . . . . . . . . . . 23 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 84 1. Introduction 86 The distributed mobility management (DMM) WG has studied the problems 87 of centralized deployment of mobility management protocols and the 88 related requirements [I-D.ietf-dmm-requirements]. In order to guide 89 the deployment and before defining any new DMM protocol, the DMM WG 90 is chartered to investigate first whether it is feasible to deploy 91 current IP mobility protocols in a DMM scenario in a way that can 92 fullfil the requirements of DMM. This document discusses current 93 deployment practices of existing mobility protocols in a distributed 94 mobility management environment and identifies the limitations in 95 these practices with respect to the expected functionality. 97 The rest of this document is organized as follows. Section 3 98 analyzes existing IP mobility protocols by examining their functions 99 and how these functions can be reconfigured to work in a DMM 100 environment. Section 4 presents the current practices of IP flat 101 wireless networks and 3GPP architectures. Both network- and host- 102 based mobility protocols are considered. Section 5 presents the gap 103 analysis with respect to the current practices. 105 2. Terminology 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 109 document are to be interpreted as described in [RFC2119]. 111 All general mobility-related terms and their acronyms used in this 112 document are to be interpreted as defined in the Mobile IPv6 base 113 specification [RFC6275] and in the Proxy mobile IPv6 specification 114 [RFC5213]. These terms include mobile node (MN), correspondent node 115 (CN), home agent (HA), local mobility anchor (LMA), and mobile access 116 gateway (MAG). 118 In addition, this document uses the following terms: 120 Mobility routing (MR) is the logical function that intercepts 121 packets to/from the IP address/prefix delegated to the mobile node 122 and forwards them, based on internetwork location information, 123 either directly towards their destination or to some other network 124 element that knows how to forward the packets to their ultimate 125 destination. 127 Home address allocation is the logical function that allocates the 128 IP address/prefix (e.g., home address or home network prefix) to a 129 mobile node. 131 Location management (LM) is the logical function that manages and 132 keeps track of the internetwork location information of a mobile 133 node, which includes the mapping of the IP address/prefix 134 delegated to the MN to the MN routing address or another network 135 element that knows where to forward packets destined for the MN. 137 Home network of an application session (or an HoA IP address) is the 138 network that has allocated the IP address used as the session 139 identifier (home address) by the application being run in an MN. 140 The MN may be attached to more than one home networks. 142 In the document, several references to a distributed mobility 143 management environment are made. By this term, we refer to an 144 scenario in which the IP mobility, access network and routing 145 solutions allow for setting up IP networks so that traffic is 146 distributed in an optimal way and does not rely on centrally deployed 147 anchors to manage IP mobility sessions. 149 3. Functions of existing mobility protocols 151 The host-based Mobile IPv6 [RFC6275] and its network-based extension, 152 PMIPv6 [RFC5213], are both logically centralized mobility management 153 approaches addressing primarily hierarchical mobile networks. 154 Although they are centralized approaches, they have important 155 mobility management functions resulting from years of extensive work 156 to develop and to extend these functions. It is therefore fruitful 157 to take these existing functions and examine them in a DMM scenario 158 in order to understand how to deploy the existing mobility protocols 159 in a distributed mobility management environment. 161 The existing mobility management functions of MIPv6, PMIPv6, and 162 HMIPv6 are the following: 164 1. Anchoring function (AF): allocation to a mobile node of an IP 165 addres/prefix (e.g., a HoA or HNP) topologically anchored by the 166 delegating node (i.e., the anchor node is able to advertise a 167 connected route into the routing infrastructure for the delegated 168 IP prefixes). 170 2. Mobility Routing (MR) function: packets interception and 171 forwarding to/from the IP address/prefix delegated to the MN, 172 based on the internetwork location information, either to the 173 destination or to some other network element that knows how to 174 forward the packets to their destination; 176 3. Internetwork Location Management (LM) function: managing and 177 keeping track of the internetwork location of an MN, which 178 includes a mapping of the IP delegated address/prefix (e.g., HoA 179 or HNP) to the mobility anchoring point where the MN is anchored 180 to; 182 4. Location Update (LU): provisioning of MN location information to 183 the LM function; 185 In Mobile IPv6 [RFC6275], the home agent typically provides the 186 anchoring function (AF), Mobility Routing (MR), and Internetwork 187 Location Management (LM) functions, while the mobile node provides 188 the Location Update (LU) function. Proxy Mobile IPv6 [RFC5213] 189 relies on the function of the Local Mobility Anchor (LMA) to provide 190 mobile nodes with mobility support, without requiring the involvement 191 of the mobile nodes. The required functionality at the mobile node 192 is provided in a proxy manner by the Mobile Access Gateway (MAG). 193 With network-based IP mobility protocols, the local mobility anchor 194 typically provides the anchoring function (AF), Mobility Routing 195 (MR), and Internetwork Location Management (LM) functions, while the 196 mobile access gateway provides the Location Update (LU) function. 198 4. DMM practices 200 This section documents deployment practices of existing mobility 201 protocols in a distributed mobility management environment. This 202 description is divided into two main families of network 203 architectures: i) IP flat wireless networks (e.g., evolved WiFi 204 hotspots) and, ii) 3GPP network flattening approaches. 206 While describing the current DMM practices, references to the generic 207 mobility management functions described in Section 3 will be 208 provided, as well as some initial hints on the identified gaps with 209 respect to the DMM requirement documented in 210 [I-D.ietf-dmm-requirements]. 212 4.1. Assumptions 214 There are many different approaches that can be considered to 215 implement and deploy a distributed anchoring and mobility solution. 216 Since this document cannot be too exhaustive, the focus is on current 217 mobile network architectures and standardized IP mobility solutions. 218 In order to limit the scope of our analysis of current DMM practices, 219 we consider the following list of technical assumptions: 221 1. Both host- and network-based solutions should be covered. 223 2. Solution should allow selecting and using the most appropriate IP 224 anchor among a set of distributed ones. 226 3. Mobility management should be realized by the preservation of the 227 IP address across the different points of attachment during the 228 mobility (i.e., provision of IP address continuity). IP flows of 229 applications which do not need a constant IP address should not 230 be handled by DMM. Typically, the a connection manager together 231 with the operating system configure the source address selection 232 mechanism of the IP stack. This might involve identifying 233 application capabilities and triggering the mobility support 234 accordingly. Further considerations on application management 235 and source address selection are out of the scope of this 236 document. 238 4. Mobility management and traffic redirection should only be 239 triggered due to IP mobility reasons, that is when the MN moves 240 from the point of attachment where the IP flow was originally 241 initiated. 243 4.2. IP flat wireless network 245 This section focuses on common IP wireless network architectures and 246 how they can be flattened from an IP mobility and anchoring point of 247 view using common and standardized protocols. We take WiFi an 248 exemplary wireless technology, as it is widely known and deployed 249 nowadays. Some representative examples of WiFi deployed 250 architectures are depicted on Figure 1. 252 +-------------+ _----_ 253 +---+ | Access | _( )_ 254 |AAA|. . . . . . | Aggregation |----------( Internet ) 255 +---+ | Gateway | (_ _) 256 +-------------+ '----' 257 | | | 258 | | +-------------+ 259 | | | 260 | | +-----+ 261 +---------------+ | | AR | 262 | | +--+--+ 263 +-----+ +-----+ *----+----* 264 | RG | | WLC | ( LAN ) 265 +-----+ +-----+ *---------* 266 . / \ / \ 267 / \ +----+ +----+ +----+ +----+ 268 MN MN |WiFi| |WiFi| |WiFi| |WiFi| 269 | AP | | AP | | AP | | AP | 270 +----+ +----+ +----+ +----+ 271 . . 272 / \ / \ 273 MN MN MN MN 275 Figure 1: IP WiFi network architectures 277 In the figure, three typical deployment options are shown 278 [I-D.gundavelli-v6ops-community-wifi-svcs]. On the left hand side of 279 the figure, mobile nodes directly connect to a Residential Gateway 280 (RG) which is a network device that is located in the customer 281 premises and provides both wireless layer-2 access connectivity 282 (i.e., it hosts the 802.11 Access Point function) with layer-3 283 routing functions. In the middle, mobile nodes connect to WiFi 284 Access Points (APs) that are managed by a WLAN Controller (WLC), 285 which performs radio resource management on the APs, system-wide 286 mobility policy enforcement and centralized forwarding function for 287 the user traffic. The WLC could also implement layer-3 routing 288 functions, or attach to an access router (AR). Last, on the right- 289 hand side of the figure, access points are directly connected to an 290 access router, which can also be used a generic connectivity model. 292 In some network architectures, such as the evolved Wi-Fi hotspot, 293 operators might make use of IP mobility protocols to provide mobility 294 support to users, for example to allow connecting the IP WiFi network 295 to a mobile operator core and support roaming between WLAN and 3GPP 296 accesses. Two main protocols can be used: Proxy Mobile IPv6 297 [RFC5213] or Mobile IPv6 [RFC6275], [RFC5555], with the anchor role 298 (e.g., local mobility anchor or home agent) typically being played by 299 the Access Aggregation Gateway or even by an entity placed on the 300 mobile operator's core network. 302 Although we have adopted in this section the example of WiFi 303 networks, there are other IP flat wireless network architectures 304 specified, such as WiMAX [IEEE.802-16.2009], which integrates both 305 host and network-based IP mobility functionality. 307 Existing IP mobility protocols can also be deployed in a "flatter" 308 way, so the anchoring and access aggregation functions are 309 distributed. We next describe several practices for the deployment 310 of existing mobility protocols in a distributed mobility management 311 environment. We limit our analysis in this section to protocol 312 solutions based on existing IP mobility protocols, either host- or 313 network-based, such as Mobile IPv6 [RFC6275], [RFC5555], Proxy Mobile 314 IPv6 [RFC5213], [RFC5844] and NEMO [RFC3963]. Extensions to these 315 base protocol solutions are also considered. We pay special 316 attention to the management of the use of care-of-addresses versus 317 home addresses in an efficient manner for different types of 318 communications. Finally, and in order to simplify the analysis, we 319 divide it into two parts: host- and network-based practices. 321 4.2.1. Host-based IP DMM practices 323 Mobile IPv6 (MIPv6) [RFC6275] and its extension to support mobile 324 networks, the NEMO Basic Support protocol (hereafter, simply NEMO) 325 [RFC3963] are well-known host-based IP mobility protocols. They 326 heavily rely on the function of the Home Agent (HA), a centralized 327 anchor, to provide mobile nodes (hosts and routers) with mobility 328 support. In these approaches, the home agent typically provides the 329 anchoring function (AF), Mobility Routing (MR), and Internetwork 330 Location Management (LM) functions, while the mobile node provides 331 the Location Update (LU) function. We next describe some practices 332 on how Mobile IPv6/NEMO and several additional protocol extensions 333 can be deployed in a distributed mobility management environment. 335 One approach to distribute the anchors can be to deploy several HAs 336 (as shown in Figure 2), and assign to each MN the one closest to its 337 topological location [RFC4640], [RFC5026], [RFC6611]. In the example 338 shown in Figure 2, MN1 is assigned HA1 (and a home address anchored 339 by HA1), while MN2 is assigned HA2. Note that Mobile IPv6 / NEMO 340 specifications do not prevent the simultaneous use of multiple home 341 agents by a single mobile node. This deployment model could be 342 exploited by a mobile node to meet assumption #4 and use several 343 anchors at the same time, each of them anchoring IP flows initiated 344 at different point of attachment. However there is no mechanism 345 specified by the IETF to enable an efficient dynamic discovery of 346 available anchors and the selection of the most suitable one. Note 347 that some of these mechanisms have been defined outside the IETF 348 (e.g., 3GPP). 350 <- INTERNET -> <- HOME NETWORK -> <---- ACCESS NETWORK ----> 351 ------- ------- 352 | CN1 | ------- | AR1 |-(o) zzzz (o) 353 ------- | HA1 | ------- | 354 ------- (MN1 anchored at HA1) ------- 355 ------- | MN1 | 356 | AR2 |-(o) ------- 357 ------- 358 ------- 359 | HA2 | ------- 360 ------- | AR3 |-(o) zzzz (o) 361 ------- | 362 ------- (MN2 anchored at HA2) ------- 363 | CN2 | ------- | MN2 | 364 ------- | AR4 |-(o) ------- 365 ------- 367 CN1 CN2 HA1 HA2 AR1 MN1 AR3 MN2 368 | | | | | | | | 369 |<------------>|<=================+=====>| | | BT mode 370 | | | | | | | | 371 | |<----------------------------------------+----->| RO mode 372 | | | | | | | | 374 Figure 2: Distributed operation of Mobile IPv6 (BT and RO) / NEMO 376 Since one of the goals of the deployment of mobility protocols in a 377 distributed mobility management environment is to avoid the 378 suboptimal routing caused by centralized anchoring, the Route 379 Optimization (RO) support provided by Mobile IPv6 can also be used to 380 achieve a flatter IP data forwarding. By default, Mobile IPv6 and 381 NEMO use the so-called Bidirectional Tunnel (BT) mode, in which data 382 traffic is always encapsulated between the MN and its HA before being 383 directed to any other destination. The Route Optimization (RO) mode 384 allows the MN to update its current location on the CNs, and then use 385 the direct path between them. Using the example shown in Figure 2, 386 MN1 is using BT mode with CN2 and MN2 is in RO mode with CN1. 387 However, the RO mode has several drawbacks: 389 o The RO mode is only supported by Mobile IPv6. There is no route 390 optimization support standardized for the NEMO protocol because of 391 the security problems posed by extending return routability tests 392 for prefixes, although many different solutions have been 393 proposed. 395 o The RO mode requires additional signaling, which adds some 396 protocol overhead. 398 o The signaling required to enable RO involves the home agent, and 399 it is repeated periodically because of security reasons [RFC4225]. 400 This basically means that the HA remains as single point of 401 failure, because the Mobile IPv6 RO mode does not mean HA-less 402 operation. 404 o The RO mode requires additional support on the correspondent node 405 (CN). 407 Notwithstanding these considerations, the RO mode does offer the 408 possibility of substantially reducing traffic through the Home Agent, 409 in cases when it can be supported on the relevant correspondent 410 nodes. Note that a mobile node can also use its CoA directly 411 [RFC5014] when communicating with CNs on the same link or anywhere in 412 the Internet, although no session continuity support would be 413 provided by the IP stack in this case. 415 <- INTERNET -> <- HOME NETWORK -> <------- ACCESS NETWORK -------> 416 ----- 417 /|AR1|-(o) zz (o) 418 -------- / ----- | 419 | MAP1 |< ------- 420 -------- \ ----- | MN1 | 421 ------- \|AR2| ------- 422 | CN1 | ----- HoA anchored 423 ------- ----- at HA1 424 ------- /|AR3| RCoA anchored 425 | HA1 | -------- / ----- at MAP1 426 ------- | MAP2 |< LCoA anchored 427 -------- \ ----- at AR1 428 \|AR4| 429 ------- ----- 430 | CN2 | ----- 431 ------- /|AR5| 432 -------- / ----- 433 | MAP3 |< 434 -------- \ ----- 435 \|AR6| 436 ----- 438 CN1 CN2 HA1 MAP1 AR1 MN1 439 | | | | ________|__________ | 440 |<------------------>|<==============>|<________+__________>| HoA 441 | | | | | | 442 | |<-------------------------->|<===================>| RCoA 443 | | | | | | 445 Figure 3: Hierarchical Mobile IPv6 447 Hierarchical Mobile IPv6 (HMIPv6) [RFC5380] is another host-based IP 448 mobility extension that can be considered as a complement to provide 449 a less centralized mobility deployment. It allows reducing the 450 amount of mobility signaling as well as improving the overall 451 handover performance of Mobile IPv6 by introducing a new hierarchy 452 level to handle local mobility. The Mobility Anchor Point (MAP) 453 entity is introduced as a local mobility handling node deployed 454 closer to the mobile node. 456 When HMIPv6 is used, the MN has two different temporal addresses: the 457 Regional Care-of Address (RCoA) and the Local Care-of Address (LCoA). 458 The RCoA is anchored at one MAP, that plays the role of local home 459 agent, while the LCoA is anchored at the access router level. The 460 mobile node uses the RCoA as the CoA signaled to its home agent. 461 Therefore, while roaming within a local domain handled by the same 462 MAP, the mobile node does not need to update its home agent (i.e., 463 the mobile node does not change RCoA). 465 The use of HMIPv6 allows some route optimization, as a mobile node 466 may decide to directly use the RCoA as source address for a 467 communication with a given correspondent node, notably if the MN does 468 not expect to move outside the local domain during the lifetime of 469 the communication. This can be seen as a potential DMM mode of 470 operation. In the example shown in Figure 3, MN1 is using its global 471 HoA to communicate with CN1, while it is using its RCoA to 472 communicate with CN2. 474 Additionally, a local domain might have several MAPs deployed, 475 enabling hence different kind of HMIPv6 deployments (e.g., flat and 476 distributed). The HMIPv6 specification supports a flexible selection 477 of the MAP (e.g., based on the distance between the MN and the MAP, 478 taking into consideration the expected mobility pattern of the MN, 479 etc.). 481 An additional extension that can be used to help deploying a mobility 482 protocol in a distributed mobility management environment is the the 483 Home Agent switch specification [RFC5142], which defines a new 484 mobility header for signaling a mobile node that it should acquire a 485 new home agent. Even though the purposes of this specification do 486 not include the case of changing the mobile node's home address, as 487 that might imply loss of connectivity for ongoing persistent 488 connections, it could be used to force the change of home agent in 489 those situations where there are no active persistent data sessions 490 that cannot cope with a change of home address. 492 There other host-based approaches standardized within the IETF that 493 can be used to provide mobility support. For example MOBIKE 494 [RFC4555] allows a mobile node encrypting traffic through IKEv2 495 [RFC5996] to change its point of attachment while maintaining a 496 Virtual Private Network (VPN) session. The MOBIKE protocol allows 497 updating the VPN Security Associations (SAs) in cases where the base 498 connection initially used is lost and needs to be re-established. 499 The use of the MOBIKE protocol avoids having to perform an IKEv2 re- 500 negotiation. Similar considerations to those made for Mobile IPv6 501 can be applied to MOBIKE; though MOBIKE is best suited for situations 502 where the address of at least one endpoint is relatively stable and 503 can be discovered using existing mechanisms such as DNS. 505 4.2.2. Network-based IP DMM practices 507 Proxy Mobile IPv6 (PMIPv6) [RFC5213] is the main network-based IP 508 mobility protocol specified for IPv6 ([RFC5844] defines some IPv4 509 extensions). Architecturally, PMIPv6 is similar to MIPv6, as it 510 relies on the function of the Local Mobility Anchor (LMA) to provide 511 mobile nodes with mobility support, without requiring the involvement 512 of the mobile nodes. The required functionality at the mobile node 513 is provided in a proxy manner by the Mobile Access Gateway (MAG). 514 With network-based IP mobility protocols, the local mobility anchor 515 typically provides the anchoring function (AF), Mobility Routing 516 (MR), and Internetwork Location Management (LM) functions, while the 517 mobile access gateway provides the Location Update (LU) function. We 518 next describe some practices on how network-based mobility protocols 519 and several additional protocol extensions can be deployed in a 520 distributed mobility management environment. 522 <- INTERNET -><- HOME NET -><----------- ACCESS NETWORK ------------> 523 ------- 524 | CN1 | -------- -------- -------- 525 ------- -------- | MAG1 | | MAG2 | | MAG3 | 526 | LMA1 | ---+---- ---+---- ---+---- 527 ------- -------- | | | 528 | CN2 | (o) (o) (o) 529 ------- -------- x x 530 | LMA2 | x x 531 ------- -------- (o) (o) 532 | CN3 | | | 533 ------- ---+--- ---+--- 534 Anchored | MN1 | Anchored | MN2 | 535 at LMA1 -> ------- at LMA2 -> ------- 537 CN1 CN2 LMA1 LMA2 MAG1 MN1 MAG3 MN2 538 | | | | | | | | 539 |<------------>|<================>|<---->| | | 540 | | | | | | | | 541 | |<------------>|<========================>|<----->| 542 | | | | | | | | 544 Figure 4: Distributed operation of Proxy Mobile IPv6 546 As with Mobile IPv6, plain Proxy Mobile IPv6 operation cannot be 547 easily decentralized, as in this case there also exists a single 548 network anchor point. One simple but still suboptimal approach, can 549 be to deploy several local mobility anchors and use some selection 550 criteria to assign LMAs to attaching mobile nodes (an example of this 551 type of assignment is shown in Figure 4). As per the client based 552 approach, a mobile node may use several anchors at the same time, 553 each of them anchoring IP flows initiated at different point of 554 attachment. This assignment can be static or dynamic (as described 555 later in this document). The main advantage of this simple approach 556 is that the IP address anchor (i.e., the LMA) could be placed closer 557 to the mobile node, and therefore resulting paths are close-to- 558 optimal. On the other hand, as soon as the mobile node moves, the 559 resulting path would start to deviate from the optimal one. 561 As for host-based IP mobility, there are some extensions defined to 562 mitigate the sub-optimal routing issues that might arise due to the 563 use of a centralized anchor. The Local Routing extensions [RFC6705] 564 enable optimal routing in Proxy Mobile IPv6 in three cases: i) when 565 two communicating MNs are attached to the same MAG and LMA, ii) when 566 two communicating MNs are attached to different MAGs but to the same 567 LMA, and iii) when two communicating MNs are attached to the same MAG 568 but have different LMAs. In these three cases, data traffic between 569 the two mobile nodes does not traverse the LMA(s), thus providing 570 some form of path optimization since the traffic is locally routed at 571 the edge. The main disadvantage of this approach is that it only 572 tackles the MN-to-MN communication scenario, and only under certain 573 circumstances. 575 An interesting extension that can also be used to facilitate the 576 deployment of network-based mobility protocols in a distributes 577 mobility management environment is the LMA runtime assignment 578 [RFC6463]. This extension specifies a runtime local mobility anchor 579 assignment functionality and corresponding mobility options for Proxy 580 Mobile IPv6. This runtime local mobility anchor assignment takes 581 place during the Proxy Binding Update / Proxy Binding Acknowledgment 582 message exchange between a mobile access gateway and a local mobility 583 anchor. While this mechanism is mainly aimed for load-balancing 584 purposes, it can also be used to select an optimal LMA from the 585 routing point of view. A runtime LMA assignment can be used to 586 change the assigned LMA of an MN, for example in case when the mobile 587 node does not have any session active, or when running sessions can 588 survive an IP address change. Note that several possible dynamic 589 local mobility anchor discovery solutions can be used, as described 590 in [RFC6097]. 592 4.3. 3GPP network flattening approaches 594 The 3rd Generation Partnership Project (3GPP) is the standard 595 development organization that specifies the 3rd generation mobile 596 network and LTE (Long Term Evolution). 598 Architecturally, the 3GPP Evolved Packet Core (EPC) network is 599 similar to an IP wireless network running PMIPv6 or MIPv6, as it 600 relies on the Packet Data Gateway (PGW) anchoring services to provide 601 mobile nodes with mobility support (see Figure 5). There are client- 602 based and network-based mobility solutions in 3GPP, which for 603 simplicity we will analyze together. We next describe how 3GPP 604 mobility protocols and several additional completed or on-going 605 extensions can be deployed to meet some of the DMM requirements 606 [I-D.ietf-dmm-requirements]. 608 +---------------------------------------------------------+ 609 | PCRF | 610 +-----------+--------------------------+----------------+-+ 611 | | | 612 +----+ +-----------+------------+ +--------+-----------+ +-+-+ 613 | | | +-+ | | Core Network | | | 614 | | | +------+ |S|__ | | +--------+ +---+ | | | 615 | | | |GERAN/|_|G| \ | | | HSS | | | | | | 616 | +-----+ UTRAN| |S| \ | | +---+----+ | | | | E | 617 | | | +------+ |N| +-+-+ | | | | | | | x | 618 | | | +-+ /|MME| | | +---+----+ | | | | t | 619 | | | +---------+ / +---+ | | | 3GPP | | | | | e | 620 | +-----+ E-UTRAN |/ | | | AAA | | | | | r | 621 | | | +---------+\ | | | SERVER | | | | | n | 622 | | | \ +---+ | | +--------+ | | | | a | 623 | | | 3GPP AN \|SGW+----- S5---------------+ P | | | l | 624 | | | +---+ | | | G | | | | 625 | | +------------------------+ | | W | | | I | 626 | UE | | | | | | P | 627 | | +------------------------+ | | +-----+ | 628 | | |+-------------+ +------+| | | | | | n | 629 | | || Untrusted +-+ ePDG +-S2b---------------+ | | | e | 630 | +---+| non-3GPP AN | +------+| | | | | | t | 631 | | |+-------------+ | | | | | | w | 632 | | +------------------------+ | | | | | o | 633 | | | | | | | r | 634 | | +------------------------+ | | | | | k | 635 | +---+ Trusted non-3GPP AN +-S2a--------------+ | | | s | 636 | | +------------------------+ | | | | | | 637 | | | +-+-+ | | | 638 | +--------------------------S2c--------------------| | | | 639 | | | | | | 640 +----+ +--------------------+ +---+ 642 Figure 5: EPS (non-roaming) architecture overview 644 GPRS Tunnelling Protocol (GTP) [3GPP.29.060] [3GPP.29.281] 645 [3GPP.29.274] is a network-based mobility protocol specified for 3GPP 646 networks (S2a, S2b, S5 and S8 interfaces). Similar to PMIPv6, it can 647 handle mobility without requiring the involvement of the mobile 648 nodes. In this case, the mobile node functionality is provided in a 649 proxy manner by the Serving Data Gateway (SGW), Evolved Packet Data 650 Gateway (ePDG), or Trusted Wireless Access Gateway (TWAG). 652 3GPP specifications also include client-based mobility support, based 653 on adopting the use of Dual-Stack Mobile IPv6 (DSMIPv6) [RFC5555] for 654 the S2c interface. In this case, the UE implements the mobile node 655 functionality, while the home agent role is played by the PGW. 657 A Local IP Access (LIPA) and Selected IP Traffic Offload (SIPTO) 658 enabled network [3GPP.23.401] allows offloading some IP services at 659 the local access network, above the Radio Access Network (RAN) or at 660 the macro, without the need to traverse back to the PGW (see 661 Figure 6. 663 +---------+ IP traffic to mobile operator's CN 664 | User |....................................(Operator's CN) 665 | Equipm. |.................. 666 +---------+ . Local IP traffic 667 . 668 +-----------+ 669 |Residential| 670 |enterprise | 671 |IP network | 672 +-----------+ 674 Figure 6: LIPA scenario 676 SIPTO enables an operator to offload certain types of traffic at a 677 network node close to the UE's point of attachment to the access 678 network, by selecting a set of GWs (SGW and PGW) that is 679 geographically/topologically close to the UE's point of attachment. 681 SIPTO Traffic 682 | 683 . 684 . 685 +------+ +------+ 686 |L-PGW | ---- | MME | 687 +------+ / +------+ 688 | / 689 +-------+ +------+ +------+/ +------+ 690 | UE |.....|eNB |....| S-GW |........| P-GW |...> CN Traffic 691 +-------+ +------+ +------+ +------+ 693 Figure 7: SIPTO architecture 695 LIPA, on the other hand, enables an IP capable UE connected via a 696 Home eNB (HeNB) to access other IP capable entities in the same 697 residential/enterprise IP network without the user plane traversing 698 the mobile operator's network core. In order to achieve this, a 699 Local GW (L-GW) collocated with the HeNB is used. LIPA is 700 established by the UE requesting a new PDN connection to an access 701 point name for which LIPA is permitted, and the network selecting the 702 Local GW associated with the HeNB and enabling a direct user plane 703 path between the Local GW and the HeNB. 705 +---------------+-------+ +----------+ +-------------+ ===== 706 |Residential | |H(e)NB | | Backhaul | |Mobile | ( IP ) 707 |Enterprise |..|-------|..| |..|Operator |..(Network) 708 |Network | |L-GW | | | |Core network | ======= 709 +---------------+-------+ +----------+ +-------------+ 710 / 711 | 712 / 713 +-----+ 714 | UE | 715 +-----+ 717 Figure 8: LIPA architecture 719 The 3GPP architecture specifications also provide mechanisms to allow 720 discovery and selection of gateways [3GPP.29.303]. These mechanisms 721 enable taking decisions taking into consideration topological 722 location and gateway collocation aspects, using heavily the DNS as a 723 "location database". 725 Both SIPTO and LIPA have a very limited mobility support, specially 726 in 3GPP specifications up to Rel-10. In Rel-11, there is currently a 727 work item on LIPA Mobility and SIPTO at the Local Network (LIMONET) 728 [3GPP.23.859] that is studying how to provide SIPTO and LIPA 729 mechanisms with some additional, but still limited, mobility support. 730 In a glimpse, LIPA mobility support is limited to handovers between 731 HeNBs that are managed by the same L-GW (i.e., mobility within the 732 local domain), while seamless SIPTO mobility is still limited to the 733 case where the SGW/PGW is at or above Radio Access Network (RAN) 734 level. 736 5. Gap analysis 738 The goal of this section is to identify the limitations in the 739 current practices, described in Section 4, with respect to the 740 expected DMM requirements listed in [I-D.ietf-dmm-requirements]. 742 5.1. Distributed processing - REQ1 744 According to requirement #1 stated in [I-D.ietf-dmm-requirements], IP 745 mobility, network access and routing solutions provided by DMM MUST 746 enable distributed processing for mobility management so that traffic 747 does not need to traverse centrally deployed mobility anchors and 748 thereby avoid non-optimal routes. 750 From the analysis performed in Section 4, a DMM deployment can meet 751 the requirement "REQ#1 Distributed processing" usually relying on the 752 following functions: 754 o Multiple (distributed) anchoring: ability to anchor different 755 sessions of a single mobile node at different anchors. In order 756 to make this feature "DMM-friendly", some anchors might need to be 757 placed closer to the mobile node. 759 o Dynamic anchor assignment/re-location: ability to i) optimally 760 assign initial anchor, and ii) dynamically change the initially 761 assigned anchor and/or assign a new one (this may also require to 762 transfer mobility context between anchors). This can be achieved 763 either by changing anchor for all ongoing sessions, or by 764 assigning new anchors just for new sessions. 766 Both the main client- and network-based IP mobility protocols, namely 767 (DS)MIPv6 and PMIPv6 allows to deploy multiple anchors (i.e., home 768 agents and localized mobility anchors), therefore providing the 769 multiple anchoring function. However, existing solutions do only 770 provide an optimal initial anchor assignment, a gap being the lack of 771 dynamic anchor change/new anchor assignment. Neither the HA switch 772 nor the LMA runtime assignment allow changing the anchor during an 773 ongoing session. This actually comprises several gaps: ability to 774 perform anchor assignment at any time (not only at the initial MN's 775 attachment), ability of the current anchor to initiate/trigger the 776 relocation, and ability of transferring registration context between 777 anchors. 779 Dynamic anchor assignment may lead the MN to manage different 780 mobility sessions served by different mobility anchors. This is not 781 an issue with client based mobility management where the mobility 782 client natively knows each anchor associated to each mobility 783 sessions. However, it may raise issues with network based mobility 784 management. In this case, the mobile client, located in the network 785 (e.g., MAG), usually retrieves the MN's anchor from the MN's policy 786 profile (e.g., Section 6.2 of [RFC5213]). Currently, the MN's policy 787 profile implicitly assumes a single serving anchor and, thus, does 788 not maintain the association between home network prefix and anchor. 790 The consequence of the distribution of the mobility anchors is that 791 there might be more than one available anchor for a mobile node to 792 use, so leading to an anchor discovery and selection issue. 793 Currently, there is no efficient mechanism specified by the IETF that 794 allows to dynamically discover the presence of nodes that can play 795 the role of anchor, discover their capabilities and allow the 796 selection of the most suitable one. Note that there are 3GPP 797 mechanisms providing this functionality defined in [3GPP.29.303]. 799 5.2. Transparency to Upper Layers - REQ2 801 The need for "transparency to upper layer", introduced in 802 [I-D.ietf-dmm-requirements], requires dynamic mobility management, 803 which basically leverages the two following functions: 805 o Dynamically assign/relocate anchor: a mobility anchor is assigned 806 only to sessions which require IP continuity support. The MN may 807 thus manage more than one session; some of them may be associated 808 with anchored IP address(es), while the others may be associated 809 with local IP address(es). 811 o Multiple IP address management: this function is ensued from the 812 preceding and is about the ability of the mobile node to 813 simultaneously use multiple IP addresses and select the best one 814 (from an anchoring point of view) to use on a per-session/ 815 application/service basis. 817 The dynamic anchor assignment/relocation needs to ensure that IP 818 address continuity is guaranteed for sessions that need it and while 819 needed (in some scenarios, the provision of mobility locally within a 820 limited area might be enough from the mobile node or the application 821 point of view) at the relocated anchor. This for example implies 822 having the knowledge of which sessions are active at the mobile node, 823 which is something typically known only by the MN e.g., by its 824 connection manager). Therefore, (part of) this knowledge might need 825 to be transferred to/shared with the network. 827 Multiple IP address management requires the MN to pick-up the correct 828 address (with mobility support or not) depending on the application 829 requirements. When using client based mobility management, the 830 mobile node is natively aware about the anchoring capabilities of its 831 assigned IP addresses. This is not the case with network based IP 832 mobility management and current mechanisms does not allow the MN to 833 be aware of the IP addresses properties (i.e. the MN does not know 834 whether the allocated IP addresses are anchored). However, there are 835 ongoing IETF works that are proposing that the network could indicate 836 the different IP addresses properties during assignment procedures 837 [I-D.bhandari-dhc-class-based-prefix], 838 [I-D.korhonen-6man-prefix-properties]. 840 5.3. IPv6 deployment - REQ3 842 This requirement states that DMM solutions SHOULD primariliy target 843 IPv6 as the primary deployment environment.. IPv4 support is not 844 considered mandatory and SHOULD NOT be tailored specifically to 845 support IPv4, in particular in situations where private IPv4 846 addresses and/or NATs are used. 848 All analyzed DMM practices support IPv6. Some of them, such as 849 MIPv6/NEMO (including the support of dynamic HA selection), MOBIKE, 850 SIPTO have also IPv4 support. Additionally, there are also some 851 solutions that have some limited IPv4 support (e.g., PMIPv6). In 852 conclusion, this requirement is met by existing DMM practices. 854 5.4. Existing mobility protocols - REQ4 856 A DMM solution SHOULD first consider reusing and extending IETF- 857 standardized protocols before specifying new protocols. 859 As stated in [I-D.ietf-dmm-requirements], a DMM solution could reuse 860 existing IETF and standardized protocols before specifying new 861 protocols. Besides, Section 4 of this document discusses various 862 ways to flatten and distribute current mobility solutions. Actually, 863 nothing prevent the distribution of mobility functions with vanilla 864 IP mobility protocols. However, as discussed in Section 5.1 and 865 Section 5.2, limitations exist. The 3GPP data plane anchoring 866 function, i.e., the PGW, can be also be distributed, but with 867 limitations; e.g., no anchoring relocation, no context transfer 868 between anchors, centralized control plane . The 3GPP architecture 869 is also going into the direction of flattening with SIPTO and LIPA 870 where IP anchoring function, however these solutions are supposed to 871 be deployed do and, thus, do not provide mobility support. In 872 conclusion this requirement can be met, DMM can reuse existing 873 mobility solutions, however some limitations exist. 875 5.5. Co-existence - REQ5 877 According to [I-D.ietf-dmm-requirements], DMM solution should be able 878 to co-exist with existing network deployments and end hosts. All of 879 current mobility protocols can co-exist with existing network 880 deployments and end hosts. There is no gap between existing mobility 881 protocols and this requirement. 883 5.6. Security considerations - REQ6 885 As stated in [I-D.ietf-dmm-requirements], a DMM solution MUST NOT 886 introduce new security risks or amplify existing security risks 887 against which the existing security mechanisms/protocols cannot offer 888 sufficient protection. Current mobility protocols all have security 889 mechanisms. For example, Mobile IPv6 defines security features to 890 protect binding updates both to home agents and correspondent nodes. 891 It also defines mechanisms to protect the data packets transmission 892 for Mobile IPv6 users. Proxy Mobile IPv6 and other variation of 893 mobile IP also have similar security considerations. 895 5.7. Multicast - REQ7 897 It is stated in [I-D.ietf-dmm-requirements] that DMM solutions SHOULD 898 consider multicast traffic delivery so that network inefficiency 899 issues, such as duplicate multicast subscriptions towards the 900 downstream tunnel entities, can be avoided. 902 Current IP mobility solutions address mainly the mobility problem for 903 unicast traffic. Solutions relying on the use of an anchor point for 904 tunneling multicast traffic down to the access router, or to the MN, 905 introduce the so-called "tunnel convergence problem". This means 906 that multiple instances of the same multicast traffic can converge to 907 the same node, defeating hence the advantage of using multicast 908 protocols. 910 The MULTIMOB WG in IETF has studied the issue, for the specific case 911 of PMIPv6, and has produced a baseline solution [RFC6224] as well as 912 a routing optimization solution [RFC7028] to address the problem. 913 The baseline solution suggests deploying an MLD proxy function at the 914 MAG, and either a multicast router or another MLD proxy function at 915 the LMA. The routing optimization solution describes an architecture 916 where a dedicated multicast tree mobility anchor (MTMA) or a direct 917 routing option can be used to avoid the tunnel convergence problem. 919 Besides the solutions proposed in MULTIMOB for PMIPv6, there are no 920 solutions for other mobility protocols to address the multicast 921 tunnel convergence problem. 923 5.8. Summary 925 We next list the main gaps identified from the analysis performed 926 above. 928 o Existing solutions do only provide an optimal initial anchor 929 assignment, a gap being the lack of dynamic anchor change/new 930 anchor assignment. Neither the HA switch nor the LMA runtime 931 assignment allow changing the anchor during an ongoing session. 933 o The mobile node needs to simultaneously use multiple IP addresses, 934 which requires additional support which might not be available on 935 the mobile node's stack, especially for the case of network-based 936 solutions. 938 o Currently, there is no efficient mechanism specified by the IETF 939 that allows to dynamically discover the presence of nodes that can 940 play the role of anchor, discover their capabilities and allow the 941 selection of the most suitable one. 943 o While existing network-based DMM practices may allow to deploy 944 multiple LMAs and dynamically select the best one, this requires 945 to still keep some centralization in the control plane, to access 946 on the policy store (as defined in RFC5213). 948 The following table summarizes the previous analysis, indicating the 949 gaps existing DMM solutions have when compared to the requirements 950 listed in [I-D.ietf-dmm-requirements]. 952 +------------+------+------+------+------+------+------+------+ 953 | | REQ1 | REQ2 | REQ3 | REQ4 | REQ5 | REQ6 | REQ7 | 954 +------------+------+------+------+------+------+------+------+ 955 | MIPv6/NEMO | X | X | | | | | X | 956 | MIPv6 RO | X | | | | | | X | 957 | HMIPv6 | X | | | | | | X | 958 | HA sel | X | X | | | | | X | 959 | MOBIKE | X | X | | | | | X | 960 | PMIPv6 | X | X | | | | | * | 961 | LMA sel | X | X | | | | | X | 962 | LIPA | X | X | | | | | X | 963 | SIPTO | X | X | | | | | X | 964 | LIMONET | X | X | | | | | X | 965 +------------+------+------+------+------+------+------+------+ 967 * MULTIMOB optimizations for PMIPv6 can be used to handle multicast 968 traffic. 970 6. Security Considerations 972 This document does not define any protocol, there is no security 973 considerations. 975 7. IANA Considerations 977 None. 979 8. References 981 8.1. Normative References 983 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 984 Requirement Levels", BCP 14, RFC 2119, March 1997. 986 8.2. Informative References 988 [3GPP.23.401] 989 3GPP, "General Packet Radio Service (GPRS) enhancements 990 for Evolved Universal Terrestrial Radio Access Network 991 (E-UTRAN) access", 3GPP TS 23.401 10.10.0, March 2013. 993 [3GPP.23.859] 994 3GPP, "Local IP access (LIPA) mobility and Selected IP 995 Traffic Offload (SIPTO) at the local network", 3GPP 996 TR 23.859 12.0.1, April 2013. 998 [3GPP.29.060] 999 3GPP, "General Packet Radio Service (GPRS); GPRS 1000 Tunnelling Protocol (GTP) across the Gn and Gp interface", 1001 3GPP TS 29.060 3.19.0, March 2004. 1003 [3GPP.29.274] 1004 3GPP, "3GPP Evolved Packet System (EPS); Evolved General 1005 Packet Radio Service (GPRS) Tunnelling Protocol for 1006 Control plane (GTPv2-C); Stage 3", 3GPP TS 29.274 10.11.0, 1007 June 2013. 1009 [3GPP.29.281] 1010 3GPP, "General Packet Radio System (GPRS) Tunnelling 1011 Protocol User Plane (GTPv1-U)", 3GPP TS 29.281 10.3.0, 1012 September 2011. 1014 [3GPP.29.303] 1015 3GPP, "Domain Name System Procedures; Stage 3", 3GPP 1016 TS 29.303 10.4.0, September 2012. 1018 [I-D.bhandari-dhc-class-based-prefix] 1019 Systems, C., Halwasia, G., Gundavelli, S., Deng, H., 1020 Thiebaut, L., Korhonen, J., and I. Farrer, "DHCPv6 class 1021 based prefix", draft-bhandari-dhc-class-based-prefix-05 1022 (work in progress), July 2013. 1024 [I-D.gundavelli-v6ops-community-wifi-svcs] 1025 Gundavelli, S., Grayson, M., Seite, P., and Y. Lee, 1026 "Service Provider Wi-Fi Services Over Residential 1027 Architectures", 1028 draft-gundavelli-v6ops-community-wifi-svcs-06 (work in 1029 progress), April 2013. 1031 [I-D.ietf-dmm-requirements] 1032 Chan, A., Liu, D., Seite, P., Yokota, H., and J. Korhonen, 1033 "Requirements for Distributed Mobility Management", 1034 draft-ietf-dmm-requirements-09 (work in progress), 1035 September 2013. 1037 [I-D.korhonen-6man-prefix-properties] 1038 Korhonen, J., Patil, B., Gundavelli, S., Seite, P., and D. 1039 Liu, "IPv6 Prefix Properties", 1040 draft-korhonen-6man-prefix-properties-02 (work in 1041 progress), July 2013. 1043 [IEEE.802-16.2009] 1044 "IEEE Standard for Local and metropolitan area networks 1045 Part 16: Air Interface for Broadband Wireless Access 1046 Systems", IEEE Standard 802.16, 2009, . 1049 [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 1050 Thubert, "Network Mobility (NEMO) Basic Support Protocol", 1051 RFC 3963, January 2005. 1053 [RFC4225] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E. 1054 Nordmark, "Mobile IP Version 6 Route Optimization Security 1055 Design Background", RFC 4225, December 2005. 1057 [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol 1058 (MOBIKE)", RFC 4555, June 2006. 1060 [RFC4640] Patel, A. and G. Giaretta, "Problem Statement for 1061 bootstrapping Mobile IPv6 (MIPv6)", RFC 4640, 1062 September 2006. 1064 [RFC5014] Nordmark, E., Chakrabarti, S., and J. Laganier, "IPv6 1065 Socket API for Source Address Selection", RFC 5014, 1066 September 2007. 1068 [RFC5026] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6 1069 Bootstrapping in Split Scenario", RFC 5026, October 2007. 1071 [RFC5142] Haley, B., Devarapalli, V., Deng, H., and J. Kempf, 1072 "Mobility Header Home Agent Switch Message", RFC 5142, 1073 January 2008. 1075 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 1076 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 1078 [RFC5380] Soliman, H., Castelluccia, C., ElMalki, K., and L. 1079 Bellier, "Hierarchical Mobile IPv6 (HMIPv6) Mobility 1080 Management", RFC 5380, October 2008. 1082 [RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and 1083 Routers", RFC 5555, June 2009. 1085 [RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy 1086 Mobile IPv6", RFC 5844, May 2010. 1088 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 1089 "Internet Key Exchange Protocol Version 2 (IKEv2)", 1090 RFC 5996, September 2010. 1092 [RFC6097] Korhonen, J. and V. Devarapalli, "Local Mobility Anchor 1093 (LMA) Discovery for Proxy Mobile IPv6", RFC 6097, 1094 February 2011. 1096 [RFC6224] Schmidt, T., Waehlisch, M., and S. Krishnan, "Base 1097 Deployment for Multicast Listener Support in Proxy Mobile 1098 IPv6 (PMIPv6) Domains", RFC 6224, April 2011. 1100 [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support 1101 in IPv6", RFC 6275, July 2011. 1103 [RFC6463] Korhonen, J., Gundavelli, S., Yokota, H., and X. Cui, 1104 "Runtime Local Mobility Anchor (LMA) Assignment Support 1105 for Proxy Mobile IPv6", RFC 6463, February 2012. 1107 [RFC6611] Chowdhury, K. and A. Yegin, "Mobile IPv6 (MIPv6) 1108 Bootstrapping for the Integrated Scenario", RFC 6611, 1109 May 2012. 1111 [RFC6705] Krishnan, S., Koodli, R., Loureiro, P., Wu, Q., and A. 1112 Dutta, "Localized Routing for Proxy Mobile IPv6", 1113 RFC 6705, September 2012. 1115 [RFC7028] Zuniga, JC., Contreras, LM., Bernardos, CJ., Jeon, S., and 1116 Y. Kim, "Multicast Mobility Routing Optimizations for 1117 Proxy Mobile IPv6", RFC 7028, September 2013. 1119 Authors' Addresses 1121 Dapeng Liu (editor) 1122 China Mobile 1123 Unit2, 28 Xuanwumenxi Ave, Xuanwu District 1124 Beijing 100053 1125 China 1127 Email: liudapeng@chinamobile.com 1128 Juan Carlos Zuniga (editor) 1129 InterDigital Communications, LLC 1130 1000 Sherbrooke Street West, 10th floor 1131 Montreal, Quebec H3A 3G4 1132 Canada 1134 Email: JuanCarlos.Zuniga@InterDigital.com 1135 URI: http://www.InterDigital.com/ 1137 Pierrick Seite 1138 Orange 1139 4, rue du Clos Courtel, BP 91226 1140 Cesson-Sevigne 35512 1141 France 1143 Email: pierrick.seite@orange.com 1145 H Anthony Chan 1146 Huawei Technologies 1147 5340 Legacy Dr. Building 3 1148 Plano, TX 75024 1149 USA 1151 Email: h.a.chan@ieee.org 1153 Carlos J. Bernardos 1154 Universidad Carlos III de Madrid 1155 Av. Universidad, 30 1156 Leganes, Madrid 28911 1157 Spain 1159 Phone: +34 91624 6236 1160 Email: cjbc@it.uc3m.es 1161 URI: http://www.it.uc3m.es/cjbc/