idnits 2.17.1 draft-ietf-dmm-best-practices-gap-analysis-08.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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 73 has weird spacing: '...s/hosts and...' -- The document date (September 29, 2014) is 3490 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) -- Obsolete informational reference (is this intentional?): RFC 5996 (Obsoleted by RFC 7296) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DMM D. Liu, Ed. 3 Internet-Draft China Mobile 4 Intended status: Informational JC. Zuniga, Ed. 5 Expires: April 2, 2015 InterDigital 6 P. Seite 7 Orange 8 H. Chan 9 Huawei Technologies 10 CJ. Bernardos 11 UC3M 12 September 29, 2014 14 Distributed Mobility Management: Current practices and gap analysis 15 draft-ietf-dmm-best-practices-gap-analysis-08 17 Abstract 19 This document analyzes deployment practices of existing IP mobility 20 protocols in a distributed mobility management environment. It then 21 identifies existing limitations when compared to the requirements 22 defined for a distributed mobility management solution. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on April 2, 2015. 41 Copyright Notice 43 Copyright (c) 2014 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Functions of existing mobility protocols . . . . . . . . . . 3 61 4. DMM practices . . . . . . . . . . . . . . . . . . . . . . . . 5 62 4.1. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 5 63 4.2. IP flat wireless network . . . . . . . . . . . . . . . . 6 64 4.2.1. Host-based IP DMM practices . . . . . . . . . . . . . 7 65 4.2.2. Network-based IP DMM practices . . . . . . . . . . . 11 66 4.3. Flattening 3GPP mobile network approaches . . . . . . . . 13 67 5. Gap analysis . . . . . . . . . . . . . . . . . . . . . . . . 16 68 5.1. Distributed mobility management - REQ1 . . . . . . . . . 16 69 5.2. Bypassable network-layer mobility support for each 70 application session - REQ2 . . . . . . . . . . . . . . . 19 71 5.3. IPv6 deployment - REQ3 . . . . . . . . . . . . . . . . . 20 72 5.4. Considering existing mobility protocols - REQ4 . . . . . 20 73 5.5. Coexistence with deployed networks/hosts and 74 operability across different networks - REQ5 . . . . . . 21 75 5.6. Operation and management considerations - REQ6 . . . . . 21 76 5.7. Security considerations - REQ7 . . . . . . . . . . . . . 22 77 5.8. Multicast - REQ8 . . . . . . . . . . . . . . . . . . . . 22 78 5.9. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 23 79 6. Security Considerations . . . . . . . . . . . . . . . . . . . 25 80 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 25 81 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 82 8.1. Normative References . . . . . . . . . . . . . . . . . . 26 83 8.2. Informative References . . . . . . . . . . . . . . . . . 26 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 86 1. Introduction 88 Existing network-layer mobility management protocols have primarily 89 employed a mobility anchor to ensure connectivity of a mobile node by 90 forwarding packets destined to, or sent from, the mobile node after 91 the node has moved to a different network. The mobility anchor has 92 been centrally deployed in the sense that the traffic of millions of 93 mobile nodes in an operator network is typically managed by the same 94 anchor. This centralized deployment of mobility anchors to manage IP 95 sessions poses several problems. In order to address these problems, 96 a distributed mobility management (DMM) architecture has been 97 proposed. This document investigates whether it is feasible to 98 deploy current IP mobility protocols in a DMM scenario in a way that 99 can fulfill the requirements as defined in [RFC7333]. It discusses 100 current deployment practices of existing mobility protocols and 101 identifies the limitations (gaps) in these practices from the 102 standpoint of satisfying DMM requirements. The analysis is primarily 103 towards IPv6 deployment, but can be seen to also apply to IPv4 104 whenever there are IPv4 counterparts equivalent to the IPv6 mobility 105 protocols. 107 The rest of this document is organized as follows. Section 3 108 analyzes existing IP mobility protocols by examining their functions 109 and how these functions can be configured and used to work in a DMM 110 environment. Section 4 presents the current practices of IP wireless 111 networks and 3GPP architectures. Both network- and host-based 112 mobility protocols are considered. Section 5 presents the gap 113 analysis with respect to the current practices. 115 2. Terminology 117 All general mobility-related terms and their acronyms used in this 118 document are to be interpreted as defined in the Mobile IPv6 base 119 specification [RFC6275], in the Proxy Mobile IPv6 specification 120 [RFC5213], and in the Distributed Mobility Management Requirements 121 [RFC7333]. These terms include mobile node (MN), correspondent node 122 (CN), home agent (HA), Local Mobility Anchor (LMA), Mobile Access 123 Gateway (MAG), centrally depoyed mobility anchors, distributed 124 mobility management, hierarchical mobile network, flatter mobile 125 network, and flattening mobile network. 127 In addition, this document also introduces some definitions of IP 128 mobility functions in Section 3. 130 In this document there are also references to a "distributed mobility 131 management environment." By this term, we refer to a scenario in 132 which the IP mobility, access network and routing solutions allow for 133 setting up IP networks so that traffic is distributed in an optimal 134 way, without relying on centrally deployed mobility anchors to manage 135 IP mobility sessions. 137 3. Functions of existing mobility protocols 139 The host-based Mobile IPv6 (MIPv6) [RFC6275] and its network-based 140 extension, Proxy Mobile IPv6 (PMIPv6) [RFC5213], as well as 141 Hierarchical Mobile IPv6 (HMIPv6) [RFC5380] are logically centralized 142 mobility management approaches addressing primarily hierarchical 143 mobile networks. Although these approaches are centralized, they 144 have important mobility management functions resulting from years of 145 extensive work to develop and to extend these functions. It is 146 therefore useful to take these existing functions and examine them in 147 a DMM scenario in order to understand how to deploy the existing 148 mobility protocols to provide distributed mobility management. 150 The main mobility management functions of MIPv6, PMIPv6, and HMIPv6 151 are the following: 153 1. Anchoring Function (AF): allocation to a mobile node of an IP 154 address, i.e., Home Address (HoA), or prefix, i.e., Home Network 155 Prefix (HNP) topologically anchored by the advertising node. 156 That is, the anchor node is able to advertise a connected route 157 into the routing infrastructure for the allocated IP prefixes. 158 This function is a control plane function. 160 2. Internetwork Location Information (LI) function: managing and 161 keeping track of the internetwork location of an MN. The 162 location information may be a binding of the IP advertised 163 address/prefix, e.g., HoA or HNP, to the IP routing address of 164 the MN or of a node that can forward packets destined to the MN. 165 It is a control plane function. 167 In a client-server protocol model, location query and update 168 messages may be exchanged between a location information client 169 (LIc) and a location information server (LIs). 171 3. Forwarding Management (FM) function: packet interception and 172 forwarding to/from the IP address/prefix assigned to the MN, 173 based on the internetwork location information, either to the 174 destination or to some other network element that knows how to 175 forward the packets to their destination. 177 FM may optionally be split into the control plane (FM-CP) and 178 data plane (FM-DP). 180 In Mobile IPv6, the home agent (HA) typically provides the anchoring 181 function (AF); the location information server (LIs) is at the HA 182 whereas the location information client (LIc) is at the MN; the 183 Forwarding Management (FM) function resides in both ends of the 184 tunnel at the HA and the MN. 186 In Proxy Mobile IPv6, the Local Mobility Anchor (LMA) provides the 187 anchoring function (AF); the location information server (LIs) is at 188 the LMA whereas the location information client (LIc) is at the 189 mobile access gateway (MAG); the Forwarding Management (FM) function 190 resides in both ends of the tunnel at the HA and the MAG. 192 In Hierarchical Mobile IPv6 (HMIPv6) [RFC5380], the Mobility Anchor 193 Point (MAP) serves as a location information aggregator between the 194 LIs at the HA and the LIc at the MN. The MAP also provides the FM 195 function to enable tunneling between HA and itself as well as 196 tunneling between MN and itself. 198 4. DMM practices 200 This section documents deployment practices of existing mobility 201 protocols to satisfy distributed mobility management requirements. 202 This description considers both IP wireless, e.g., evolved Wi-Fi 203 hotspots, and 3GPP flattening mobile network. 205 While describing the current DMM practices, the section provides 206 references to the generic mobility management functions described in 207 Section 3 as well as some initial hints on the identified gaps with 208 respect to the DMM requirements documented in [RFC7333]. 210 4.1. Assumptions 212 There are many different approaches that can be considered to 213 implement and deploy a distributed anchoring and mobility solution. 214 The focus of the gap analysis is on certain current mobile network 215 architectures and standardized IP mobility solutions, considering any 216 kind of deployment options which do not violate the original protocol 217 specifications. In order to limit the scope of our analysis of DMM 218 practices, we consider the following list of technical assumptions: 220 1. Both host- and network-based solutions are considered. 222 2. Solutions should allow selecting and using the most appropriate 223 IP anchor among a set of available candidates. 225 3. Mobility management should be realized by the preservation of the 226 IP address across the different points of attachment (i.e., 227 provision of IP address continuity). This is in contrast to 228 certain transport-layer based approaches such as Stream Control 229 Transmission Protocol (SCTP) [RFC4960] or application-layer 230 mobility. 232 Applications which can cope with changes in the MN's IP address do 233 not depend on IP mobility management protocols such as DMM. 234 Typically, a connection manager together with the operating system 235 will configure the source address selection mechanism of the IP 236 stack. This might involve identifying application capabilities and 237 triggering the mobility support accordingly. Further considerations 238 on application management and source address selection are out of the 239 scope of this document, but the reader might consult [RFC6724]. 241 4.2. IP flat wireless network 243 This section focuses on common IP wireless network architectures and 244 how they can be flattened from an IP mobility and anchoring point of 245 view using common and standardized protocols. We take Wi-Fi as an 246 useful wireless technology, since it is widely known and deployed 247 nowadays. Some representative examples of Wi-Fi deployment 248 architectures are depicted in Figure 1. 250 +-------------+ _----_ 251 +---+ | Access | _( )_ 252 |AAA|. . . . . . | Aggregation |----------( Internet ) 253 +---+ | Gateway | (_ _) 254 +-------------+ '----' 255 | | | 256 | | +-------------+ 257 | | | 258 | | +-----+ 259 +---------------+ | | AR | 260 | | +--+--+ 261 +-----+ +-----+ *----+----* 262 | RG | | WLC | ( LAN ) 263 +-----+ +-----+ *---------* 264 . / \ / \ 265 / \ +-----+ +-----+ +-----+ +-----+ 266 / \ |Wi-Fi| |Wi-Fi| |Wi-Fi| |Wi-Fi| 267 MN1 MN2 | AP1 | | AP2 | | AP3 | | AP4 | 268 +-----+ +-----+ +-----+ +-----+ 269 . . 270 / \ / \ 271 / \ / \ 272 MN3 MN4 MN5 MN6 274 Figure 1: IP Wi-Fi network architectures 276 In Figure 1, three typical deployment options are shown 277 [I-D.gundavelli-v6ops-community-wifi-svcs]. On the left hand side of 278 the figure, mobile nodes MN1 and MN2 directly connect to a 279 Residential Gateway (RG) at the customer premises. The RG hosts the 280 802.11 Access Point (AP) function to enable wireless layer-2 access 281 connectivity and also provides layer-3 routing functions. In the 282 middle of the figure, mobile nodes MN3 and MN4 connect to Wi-Fi 283 Access Points (APs) AP1 and AP2 that are managed by a Wireless LAN 284 Controller (WLC), which performs radio resource management on the 285 APs, domain-wide mobility policy enforcement and centralized 286 forwarding function for the user traffic. The WLC could also 287 implement layer-3 routing functions, or attach to an access router 288 (AR). Last, on the right-hand side of the figure, access points AP3 289 and AP4 are directly connected to an access router. This can also be 290 used as a generic connectivity model. 292 IP mobility protocols can be used to provide heterogeneous network 293 mobility support to users, e.g., handover from Wi-Fi to cellular 294 access. Two kind of protocols can be used: Proxy Mobile IPv6 295 [RFC5213] or Mobile IPv6 [RFC5555], with the role of mobility anchor, 296 e.g., Local Mobility Anchor or home agent, typically being played by 297 the edge router of the mobile network [SDO-3GPP.23.402]. 299 Although this section has made use of the example of Wi-Fi networks, 300 there are other flattening mobile network architectures specified, 301 such as WiMAX [IEEE.802-16.2009], which integrates both host- and 302 network-based IP mobility functions. 304 Existing IP mobility protocols can also be deployed in a flatter 305 manner, so that the anchoring and access aggregation functions are 306 distributed. We next describe several practices for the deployment 307 of existing mobility protocols in a distributed mobility management 308 environment. The analysis in this section is limited to protocol 309 solutions based on existing IP mobility protocols, either host- or 310 network-based, such as Mobile IPv6 [RFC6275], [RFC5555], Proxy Mobile 311 IPv6 (PMIPv6) [RFC5213], [RFC5844] and Network Mobility Basic Support 312 protocol (NEMO) [RFC3963]. Extensions to these base protocol 313 solutions are also considered. The analysis is divided into two 314 parts: host- and network-based practices. 316 4.2.1. Host-based IP DMM practices 318 Mobile IPv6 (MIPv6) [RFC6275] and its extension to support mobile 319 networks, the NEMO Basic Support protocol (hereafter, simply referred 320 to as NEMO) [RFC3963] are well-known host-based IP mobility 321 protocols. They depend on the function of the Home Agent (HA), a 322 centralized anchor, to provide mobile nodes (hosts and routers) with 323 mobility support. In these approaches, the Home Agent typically 324 provides the Anchoring Function (AF), Forwarding Management (FM), and 325 Internetwork Location Information server (LIs) functions. The mobile 326 node possesses the Location Information client (LIc) function and the 327 FM function to enable tunneling between HA and itself. We next 328 describe some practices that show how MIPv6/NEMO and several other 329 protocol extensions can be deployed in a distributed mobility 330 management environment. 332 One approach to distribute the anchors can be to deploy several HAs 333 (as shown in Figure 2), and assign the topologically closest anchor 334 to each MN [RFC4640], [RFC5026], [RFC6611]. In the example shown in 335 Figure 2, the mobile node MN1 is assigned to the home agent HA1 and 336 uses a home address anchored by HA1 to communicate with the 337 correspondent node CN1. Similarly, the mobile node MN2 is assigned 338 to the home agent HA2 and uses a home address anchored by HA2 to 339 communicate with the correspondent node CN2. Note that MIPv6/NEMO 340 specifications do not prevent the simultaneous use of multiple home 341 agents by a single mobile node. In this deployment model, the mobile 342 node can use several anchors at the same time, each of them anchoring 343 IP flows initiated at a different point of attachment. However, 344 there is currently no mechanism specified in IETF to enable an 345 efficient dynamic discovery of available anchors and the selection of 346 the most suitable one. 348 <-INTERNET-> <- HOME NETWORK -> <------- ACCESS NETWORK -------> 349 +-----+ +-----+ +--------+ 350 | CN1 |--- ===| AR1 |=======| MN1 | 351 +-----+ \ +-----------+ // +-----+ |(FM,LMc)| 352 ---| HA1 |=== +--------+ 353 |(AF,FM,LMs)| +-----+ (anchored 354 +-----------+ | AR2 | at HA1) 355 +-----+ +-----+ 356 | CN2 |-------------- 357 +-----+ \ +-----+ +--------+ 358 -------------| AR3 |-------| MN2 | 359 +-----------+ +-----+ |(FM,LMc)| 360 | HA2 | +--------+ 361 |(AF,FM,LMs)| +-----+ (anchored 362 +-----------+ | AR4 | at HA2) 363 +-----+ 365 CN1 CN2 HA1 HA2 AR1 AR3 MN1 MN2 366 | | | | | | | | 367 |<-------------->|<================+=============>| | BT mode 368 | | | | | | | | 369 | |<---------------------------------+-------------->| RO mode 370 | | | | | | | | 372 Figure 2: Distributed operation of Mobile IPv6 (BT and RO) / NEMO 374 One goal of the deployment of mobility protocols in a distributed 375 mobility management environment is to avoid the suboptimal routing 376 caused by centralized anchoring. Here, the Route Optimization (RO) 377 support provided by Mobile IPv6 can be used to achieve a flatter IP 378 data forwarding. By default, Mobile IPv6 and NEMO use the so-called 379 Bidirectional Tunnel (BT) mode, in which data traffic is always 380 encapsulated between the MN and its HA before being directed to any 381 other destination. The RO mode allows the MN to update its current 382 location on the CNs, and then use the direct path between them. 383 Using the example shown in Figure 2, MN1 is using BT mode with CN1, 384 while MN2 is in RO mode with CN2. However, the RO mode has several 385 drawbacks: 387 o The RO mode is only supported by Mobile IPv6. There is no route 388 optimization support standardized for the NEMO protocol because of 389 the security problems posed by extending return routability tests 390 for prefixes, although many different solutions have been proposed 391 [RFC4889]. 393 o The RO mode requires signaling that adds some protocol overhead. 395 o The signaling required to enable RO involves the home agent and is 396 repeated periodically for security reasons [RFC4225]. Therefore 397 the HA remains a single point of failure. 399 o The RO mode requires support from the CN. 401 Notwithstanding these considerations, the RO mode does offer the 402 possibility of substantially reducing traffic through the Home Agent, 403 in cases when it can be supported by the relevant correspondent 404 nodes. Note that a mobile node can also use its care-of-address 405 (CoA) directly [RFC5014] when communicating with CNs on the same link 406 or anywhere in the Internet, although no session continuity support 407 would be provided by the IP stack in this case. 409 Hierarchical Mobile IPv6 (HMIPv6) [RFC5380] (as shown in Figure 3), 410 is another host-based IP mobility extension which can be considered 411 as a complement to provide a less centralized mobility deployment. 412 It allows the reduction of the amount of mobility signaling as well 413 as improving the overall handover performance of Mobile IPv6 by 414 introducing a new hierarchy level to handle local mobility. The 415 Mobility Anchor Point (MAP) entity is introduced as a local mobility 416 handling node deployed closer to the mobile node. It provides LI 417 intermediary function between the LI server (LIs) at the HA and the 418 LI client (LIc) at the MN. It also performs the FM function to 419 tunnel with the HA and also with the MN. 421 <- HOME NETWORK -> <---------- ACCESS NETWORK ----------> 422 LCoA anchored 423 at AR1 424 +---+ +--------+ 425 ===|AR1|==| MN1 | 426 +-----+ +-----------+ +----------+ // +---+ |(FM,LMc)| 427 | CN1 |----| HA1 |======| MAP1 |=== +--------+ 428 +-----+ |(AF,FM,LMs)| /|(AF,FM,LM)| +---+ HoA, 429 +-----------+ / +----------+ |AR2| RCoA, 430 HoA anchored / RCoA anchored +---+ LCoA 431 at HA1 / at MAP1 432 / +---+ 433 / |AR3| 434 +-----+ / +----------+ +---+ 435 | CN2 |---------------- | MAP2 | 436 +-----+ |(AF,FM,LM)| +---+ 437 +----------+ |AR4| 438 +---+ 439 CN1 CN2 HA1 MAP1 AR1 MN1 440 | | | | | | 441 |<-------------->|<===============>|<======================>| HoA 442 | | | | | | 443 | |<-------------------------->|<======================>| RCoA 444 | | | | | | 446 Figure 3: Hierarchical Mobile IPv6 448 When HMIPv6 is used, the MN has two different temporary addresses: 449 the Regional Care-of Address (RCoA) and the Local Care-of Address 450 (LCoA). The RCoA is anchored at one MAP, which plays the role of 451 local home agent, while the LCoA is anchored at the access router 452 level. The mobile node uses the RCoA as the CoA signaled to its home 453 agent. Therefore, while roaming within a local domain handled by the 454 same MAP, the mobile node does not need to update its home agent, 455 i.e., the mobile node does not change its RCoA. 457 The use of HMIPv6 enables some form of route optimization, since a 458 mobile node may decide to directly use the RCoA as source address for 459 a communication with a given correspondent node, particularly if the 460 MN does not expect to move outside the local domain during the 461 lifetime of the communication. This can be seen as a potential DMM 462 mode of operation, though it fails to provide session continuity if 463 and when the MN moves outside the local domain. In the example shown 464 in Figure 3, MN1 is using its global HoA to communicate with CN1, 465 while it is using its RCoA to communicate with CN2. 467 Furthermore, a local domain might have several MAPs deployed, 468 enabling therefore a different kind of HMIPv6 deployments which are 469 flattening and distributed. The HMIPv6 specification supports a 470 flexible selection of the MAP, including those based on the distance 471 between the MN and the MAP, or taking into consideration the expected 472 mobility pattern of the MN. 474 Another extension that can be used to help distributing mobility 475 management functions is the Home Agent switch specification 476 [RFC5142], which defines a new mobility header for signaling a mobile 477 node that it should acquire a new home agent. [RFC5142] does not 478 specify the case of changing the mobile node's home address, as that 479 might imply loss of connectivity for ongoing persistent connections. 480 Nevertheless, that specification could be used to force the change of 481 home agent in those situations where there are no active persistent 482 data sessions that cannot cope with a change of home address. 484 There are other host-based approaches standardized that can be used 485 to provide mobility support. For example MOBIKE [RFC4555] allows a 486 mobile node encrypting traffic through IKEv2 [RFC5996] to change its 487 point of attachment while maintaining a Virtual Private Network (VPN) 488 session. The MOBIKE protocol allows updating the VPN Security 489 Associations (SAs) in cases where the base connection initially used 490 is lost and needs to be re-established. The use of the MOBIKE 491 protocol avoids having to perform an IKEv2 re-negotiation. Similar 492 considerations to those made for Mobile IPv6 can be applied to 493 MOBIKE; though MOBIKE is best suited for situations where the address 494 of at least one endpoint is relatively stable and can be discovered 495 using existing mechanisms such as DNS. 497 Extensions have been defined to the mobility protocol to optimize the 498 handover performance. Mobile IPv6 Fast Handovers (FMIPv6) [RFC5568] 499 is the extension to optimize handover latency. It defines new access 500 router discovery mechanism before handover to reduce the new network 501 discovery latency. It also defines a tunnel between the previous 502 access router and the new access router to reduce the packet loss 503 during handover. The Candidate Access Router Discovery (CARD) 504 [RFC4066] and Context Transfer Protocol (CXTP) [RFC4067] protocols 505 were standardized to improve the handover performance. The DMM 506 deployment practice discussed in this section can also use those 507 extensions to improve the handover performance. 509 4.2.2. Network-based IP DMM practices 511 Proxy Mobile IPv6 (PMIPv6) [RFC5213] is the main network-based IP 512 mobility protocol specified for IPv6. Proxy Mobile IPv4 [RFC5844] 513 defines some IPv4 extensions. With network-based IP mobility 514 protocols, the Local Mobility Anchor (LMA) typically provides the 515 Anchoring Function (AF), Forwarding Management (FM) function, and 516 Internetwork Location Information server (LIs) function. The mobile 517 access gateway (MAG) provides the Location Information client (LIc) 518 function and Forwarding Management (FM) function to tunnel with LMA. 519 PMIPv6 is architecturally almost identical to MIPv6, as the mobility 520 signaling and routing between LMA and MAG in PMIPv6 is similar to 521 those between HA and MN in MIPv6. The required mobility 522 functionality at the MN is provided by the MAG so that the 523 involvement in mobility support by the MN is not required. 525 We next describe some practices that show how network-based mobility 526 protocols and several other protocol extensions can be deployed in a 527 distributed mobility management environment. 529 One way to decentralize Proxy Mobile IPv6 operation can be to deploy 530 several Local Mobility Anchors and use some selection criteria to 531 assign LMAs to attaching mobile nodes. An example of this type of 532 assignment is shown in Figure 4. As with the client based approach, 533 a mobile node may use several anchors at the same time, each of them 534 anchoring IP flows initiated at a different point of attachment. 535 This assignment can be static or dynamic. The main advantage of this 536 simple approach is that the IP address anchor, i.e., the LMA, could 537 be placed closer to the mobile node. Therefore the resulting paths 538 are close-to-optimal. On the other hand, as soon as the mobile node 539 moves, the resulting path will start deviating from the optimal one. 541 <--- HOME NETWORK ---> <------ ACCESS NETWORK -------> 542 +--------+ +---+ 543 =======| MAG1 |------|MN1| 544 +-----+ +-----------+ // |(FM,LMc)| +---+ 545 | CN1 |-------| LMA1 |======= +--------+ 546 +-----+ |(AF,FM,LMs)| 547 +-----------+ +--------+ 548 +-----+ | MAG2 | 549 | CN2 |--- |(FM,LMc)| 550 +-----+ \ +-----------+ +--------+ 551 ---| LMA2 |======= 552 +-----+ |(AF,FM,LMs)| \\ +--------+ +---+ 553 | CN3 | +-----------+ =======| MAG3 |------|MN2| 554 +-----+ |(FM,LMs)| +---+ 555 +--------+ 556 CN1 CN2 LMA1 LMA2 MAG1 MAG3 MN1 MN2 557 | | | | | | | | 558 |<-------------->|<=========================>|<----------->| | 559 | | | | | | | | 560 | |<-------------->|<========================>|<----------->| 561 | | | | | | | | 563 Figure 4: Distributed operation of Proxy Mobile IPv6 565 In a similar way to the host-based IP mobility case, network-based IP 566 mobility has some extensions defined to mitigate the suboptimal 567 routing issues that may arise due to the use of a centralized anchor. 568 The Local Routing extensions [RFC6705] enable optimal routing in 569 Proxy Mobile IPv6 in three cases: i) when two communicating MNs are 570 attached to the same MAG and LMA, ii) when two communicating MNs are 571 attached to different MAGs but to the same LMA, and iii) when two 572 communicating MNs are attached to the same MAG but have different 573 LMAs. In these three cases, data traffic between the two mobile 574 nodes does not traverse the LMA(s), thus providing some form of path 575 optimization since the traffic is locally routed at the edge. The 576 main disadvantage of this approach is that it only tackles the MN-to- 577 MN communication scenario, and only under certain circumstances. 579 An interesting extension that can also be used to facilitate the 580 deployment of network-based mobility protocols in a distributed 581 mobility management environment is the support of LMA runtime 582 assignment described in [RFC6463]. This extension specifies a 583 runtime Local Mobility Anchor assignment functionality and 584 corresponding mobility options for Proxy Mobile IPv6. This runtime 585 Local Mobility Anchor assignment takes place during the Proxy Binding 586 Update / Proxy Binding Acknowledgment message exchange between a 587 mobile access gateway and a local mobility anchor. While this 588 mechanism is mainly aimed for load-balancing purposes, it can also be 589 used to select an optimal LMA from the routing point of view. A 590 runtime LMA assignment can be used to change the assigned LMA of an 591 MN, for example, in cases when the mobile node does not have any 592 active session, or when the running sessions can survive an IP 593 address change. Note that several possible dynamic Local Mobility 594 Anchor discovery solutions can be used, as described in [RFC6097]. 596 4.3. Flattening 3GPP mobile network approaches 598 The 3rd Generation Partnership Project (3GPP) is the standards 599 development organization that specifies the 3rd generation mobile 600 network and the Evolved Packet System (EPS) [SDO-3GPP.23.402], which 601 mainly comprises the Evolved Packet Core (EPC) and a new radio access 602 network, usually referred to as LTE (Long Term Evolution). 604 Architecturally, the 3GPP Evolved Packet Core (EPC) network is 605 similar to an IP wireless network running PMIPv6 or MIPv6, as it 606 relies on the Packet Data Network Gateway (PGW) anchoring services to 607 provide mobile nodes with mobility support (see Figure 5). There are 608 client-based and network-based mobility solutions in 3GPP, which for 609 simplicity will be analyzed together. We next describe how 3GPP 610 mobility protocols and several other completed or ongoing extensions 611 can be deployed to meet some of the DMM requirements [RFC7333]. 613 +---------------------------------------------------------+ 614 | PCRF | 615 +-----------+--------------------------+----------------+-+ 616 | | | 617 +----+ +-----------+------------+ +--------+-----------+ +-+-+ 618 | | | +-+ | | Core Network | | | 619 | | | +------+ |S|__ | | +--------+ +---+ | | | 620 | | | |GERAN/|_|G| \ | | | HSS | | | | | | 621 | +-----+ UTRAN| |S| \ | | +---+----+ | | | | E | 622 | | | +------+ |N| +-+-+ | | | | | | | x | 623 | | | +-+ /|MME| | | +---+----+ | | | | t | 624 | | | +---------+ / +---+ | | | 3GPP | | | | | e | 625 | +-----+ E-UTRAN |/ | | | AAA | | | | | r | 626 | | | +---------+\ | | | SERVER | | | | | n | 627 | | | \ +---+ | | +--------+ | | | | a | 628 | | | 3GPP AN \|SGW+----- S5---------------+ P | | | l | 629 | | | +---+ | | | G | | | | 630 | | +------------------------+ | | W | | | I | 631 | UE | | | | | | P | 632 | | +------------------------+ | | +-----+ | 633 | | |+-------------+ +------+| | | | | | n | 634 | | || Untrusted +-+ ePDG +-S2b---------------+ | | | e | 635 | +---+| non-3GPP AN | +------+| | | | | | t | 636 | | |+-------------+ | | | | | | w | 637 | | +------------------------+ | | | | | o | 638 | | | | | | | r | 639 | | +------------------------+ | | | | | k | 640 | +---+ Trusted non-3GPP AN +-S2a--------------+ | | | s | 641 | | +------------------------+ | | | | | | 642 | | | +-+-+ | | | 643 | +--------------------------S2c--------------------| | | | 644 | | | | | | 645 +----+ +--------------------+ +---+ 647 Figure 5: EPS (non-roaming) architecture overview 649 The GPRS Tunneling Protocol (GTP) [SDO-3GPP.29.060] [SDO-3GPP.29.281] 650 [SDO-3GPP.29.274] is a network-based mobility protocol specified for 651 3GPP networks (S2a, S2b, S5 and S8 interfaces). In a similar way to 652 PMIPv6, it can handle mobility without requiring the involvement of 653 the mobile nodes. In this case, the mobile node functionality is 654 provided in a proxy manner by the Serving Data Gateway (SGW), Evolved 655 Packet Data Gateway (ePDG), or Trusted Wireless Access Gateway (TWAG 656 [SDO-3GPP.23.402]) . 658 3GPP specifications also include client-based mobility support, based 659 on adopting the use of Dual-Stack Mobile IPv6 (DSMIPv6) [RFC5555] for 660 the S2c interface [SDO-3GPP.24.303]. In this case, the User 661 Equipment (UE) implements the binding update functionality, while the 662 home agent role is played by the PGW. 664 A Local IP Access (LIPA) and Selected IP Traffic Offload (SIPTO) 665 enabled network [SDO-3GPP.23.401] allows offloading some IP services 666 at the local access network above the Radio Access Network (RAN) 667 without the need to travel back to the PGW (see Figure 6). 669 +---------+ IP traffic to mobile operator's CN 670 | User |....................................(Operator's CN) 671 | Equipm. |.................. 672 +---------+ . Local IP traffic 673 . 674 +-----------+ 675 |Residential| 676 |enterprise | 677 |IP network | 678 +-----------+ 680 Figure 6: LIPA scenario 682 SIPTO enables an operator to offload certain types of traffic at a 683 network node close to the UE's point of attachment to the access 684 network, by selecting a set of GWs (SGW and PGW) that are 685 geographically/topologically close to the UE's point of attachment. 687 SIPTO Traffic 688 | 689 . 690 . 691 +-------+ +------+ 692 | L-PGW | ---- | MME | 693 +-------+ / +------+ 694 | / 695 +------+ +-----+ +-----+/ +-----+ 696 | UE |.....| eNB |....| SGW |........| PGW |.... CN Traffic 697 +------+ +-----+ +-----+ +-----+ 699 Figure 7: SIPTO architecture 701 LIPA, on the other hand, enables an IP addressable UE connected via a 702 Home eNB (HeNB) to access other IP addressable entities in the same 703 residential/enterprise IP network without traversing the mobile 704 operator's network core in the user plane. In order to achieve this, 705 a Local GW (LGW) collocated with the HeNB is used. LIPA is 706 established by the UE requesting a new Public Data Network (PDN) 707 connection to an access point name for which LIPA is permitted, and 708 the network selecting the Local GW associated with the HeNB and 709 enabling a direct user plane path between the Local GW and the HeNB. 711 +---------------+------+ +----------+ +-------------+ ===== 712 |Residential | | HeNB | | Backhaul | |Mobile | ( IP ) 713 |Enterprise |..|------|..| |..|Operator |..(Network) 714 |Network | | LGW | | | |Core network | ======= 715 +---------------+------+ +----------+ +-------------+ 716 / 717 | 718 / 719 +-----+ 720 | UE | 721 +-----+ 723 Figure 8: LIPA architecture 725 The 3GPP architecture specifications also provide mechanisms to allow 726 discovery and selection of gateways [SDO-3GPP.29.303]. These 727 mechanisms enable decisions taking into consideration topological 728 location and gateway collocation aspects, relying upon the DNS as a 729 "location database." 731 Both SIPTO and LIPA have a very limited mobility support, especially 732 in 3GPP specifications up to Rel-12. Briefly, LIPA mobility support 733 is limited to handovers between HeNBs that are managed by the same 734 LGW (i.e., mobility within the local domain). There is no guarantee 735 of IP session continuity for SIPTO. 737 5. Gap analysis 739 This section identifies the limitations in the current practices, 740 described in Section 4, with respect to the DMM requirements listed 741 in [RFC7333]. 743 5.1. Distributed mobility management - REQ1 745 According to requirement REQ1 stated in [RFC7333], IP mobility, 746 network access and forwarding solutions provided by DMM must make it 747 possible for traffic to avoid traversing a single mobility anchor far 748 from the optimal route. 750 From the analysis performed in Section 4, a DMM deployment can meet 751 the requirement "REQ1 Distributed mobility management" usually 752 relying on the 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 provide improved routing, some anchors might need to be placed 757 closer to the mobile node or the corresponding node. 759 o Dynamic anchor assignment/re-location: ability to i) assign the 760 initial anchor, and ii) dynamically change the initially assigned 761 anchor and/or assign a new one (this may also require the transfer 762 of mobility context between anchors). This can be achieved either 763 by changing anchor for all ongoing sessions or by assigning new 764 anchors just for new sessions. 766 GAP1-1: Both the main client- and network-based IP mobility 767 protocols, namely (DS)MIPv6 and PMIPv6 allow deploying 768 multiple anchors (i.e., home agents and localized mobility 769 anchors), thereby providing the multiple anchoring function. 770 However, existing solutions only provide an initial anchor 771 assignment, thus the lack of dynamic anchor change/new 772 anchor assignment is a gap. Neither the HA switch nor the 773 LMA runtime assignment allows changing the anchor during an 774 ongoing session. This actually comprises several gaps: 775 ability to perform anchor assignment at any time (not only 776 at the initial MN's attachment), ability of the current 777 anchor to initiate/trigger the relocation, and ability to 778 transfer registration context between anchors. 780 GAP1-2: Dynamic anchor assignment may lead the MN to manage 781 different mobility sessions served by different mobility 782 anchors. This is not an issue with client based mobility 783 management where the mobility client natively knows the 784 anchor associated with each of its mobility sessions. 785 However, there is one gap, as the MN should be capable of 786 handling IP addresses in a DMM-friendly way, meaning that 787 the MN can perform smart source address selection (i.e., 788 deprecating IP addresses from previous mobility anchors, so 789 they are not used for new sessions). Besides, managing 790 different mobility sessions served by different mobility 791 anchors may raise issues with network based mobility 792 management. In this case, the mobile client located in the 793 network, e.g., MAG, usually retrieves the MN's anchor from 794 the MN's policy profile as described in Section 6.2 of 795 [RFC5213]. Currently, the MN's policy profile implicitly 796 assumes a single serving anchor and thus does not maintain 797 the association between home network prefix and anchor. 799 GAP1-3: The consequence of the distribution of the mobility anchors 800 is that there might be more than one available anchor for a 801 mobile node to use, which leads to an anchor discovery and 802 selection issue. Currently, there is no efficient mechanism 803 specified to allow the dynamic discovery of the presence of 804 nodes that can play the anchor role, discovering their 805 capabilities and selecting the most suitable one. There is 806 also no mechanism to allow selecting a node that is 807 currently anchoring a given home address/prefix (capability 808 sometimes required to meet REQ#2). However, there are some 809 mechanisms that could help to discover anchors, such as the 810 Dynamic Home Agent Address Discovery (DHAAD) [RFC6275], the 811 use of the home agent flag (H) in Router Advertisements 812 (which indicates that the router sending the Router 813 Advertisement is also functioning as a Mobile IPv6 home 814 agent on the link) or the MAP option in Router 815 Advertisements defined by HMIPv6. Note that there are 3GPP 816 mechanisms providing that functionality defined in 817 [SDO-3GPP.29.303]. 819 Regarding the ability to transfer registration context between 820 anchors, there are already some solutions that could be reused or 821 adapted to fill that gap, such as Fast Handovers for Mobile IPv6 822 [RFC5568] -- to enable traffic redirection from the old to the new 823 anchor --, the Context Transfer protocol [RFC4067] -- to enable the 824 required transfer of registration information between anchors --, or 825 the Handover Keying architecture solutions [RFC6697], to speed up the 826 re-authentication process after a change of anchor. Note that some 827 extensions might be needed in the context of DMM, as these protocols 828 were designed in the context of centralized client IP mobility, 829 focusing on the access re-attachment and authentication. 831 GAP1-4: Also note that REQ1 is intended to prevent the data plane 832 traffic from taking a suboptimal route. Distributed 833 processing of the traffic may then be needed only in the 834 data plane. Provision of this capability for distributed 835 processing should not conflict with the use of a centralized 836 control plane. Other control plane solutions such as 837 charging, lawful interception, etc. should not be 838 constrained by the DMM solution. On the other hand 839 combining the control plane and data plane forwarding 840 management (FM) function may limit the choice of solutions 841 to those that distribute both data plane and control plane 842 together. In order to enable distribution of only the data 843 plane without distributing the control plane, it would be 844 necessary to split the forwarding management function into 845 the control plane (FM-CP) and data plane (FM-DP) components; 846 there is currently a gap here. 848 5.2. Bypassable network-layer mobility support for each application 849 session - REQ2 851 The requirement REQ2 for "bypassable network-layer mobility support 852 for each application session" introduced in [RFC7333] requires 853 flexibility in determining whether network-layer mobility support is 854 needed. This requirement enables one to choose whether or not to use 855 network-layer mobility support. The following two functions are also 856 needed: 858 o Dynamically assign/relocate anchor: a mobility anchor is assigned 859 only to sessions which use the network-layer mobility support. 860 The MN may thus manage more than one session; some of them may be 861 associated with anchored IP address(es), while the others may be 862 associated with local IP address(es). 864 o Multiple IP address management: this function is related to the 865 preceding and is about the ability of the mobile node to 866 simultaneously use multiple IP addresses and select the best one 867 (from an anchoring point of view) to use on a per- 868 session/application/service basis. This requires MN to acquire 869 information regarding the properties of the available IP 870 addresses. 872 GAP2-1: The dynamic anchor assignment/relocation needs to ensure 873 that IP address continuity is guaranteed for sessions that 874 uses such mobility support (e.g., in some scenarios, the 875 provision of mobility locally within a limited area might be 876 enough from the mobile node or the application point of 877 view) at the relocated anchor. Implicitly, when no 878 applications are using the network-layer mobility support, 879 DMM may release the needed resources. This may imply having 880 the knowledge of which sessions at the mobile node are 881 active and are using the mobility support. This is 882 something typically known only by the MN, e.g., by its 883 connection manager, and would also typically require some 884 signaling support such as socket API extensions from 885 applications to indicate to the IP stack whether mobility 886 support is required or not. Therefore, (part of) this 887 knowledge might need to be transferred to/shared with the 888 network. 890 GAP2-2: Multiple IP address management provides the MN with the 891 choice to pick the correct address, e.g., from those 892 provided or not provided with mobility support, depending on 893 the application requirements. When using client based 894 mobility management, the mobile node is itself aware of the 895 anchoring capabilities of its assigned IP addresses. This 896 is not necessarily the case with network based IP mobility 897 management; current mechanisms do not allow the MN to be 898 aware of the properties of its IP addresses. For example, 899 the MN does not know whether the allocated IP addresses are 900 anchored. However, there are proposals, such as 901 [I-D.bhandari-dhc-class-based-prefix], 902 [I-D.korhonen-6man-prefix-properties] and 903 [I-D.anipko-mif-mpvd-arch] that the network could indicate 904 such IP address properties during assignment procedures. 905 Although these individual efforts exist and they could be 906 considered as attempts to fix the gap, there is no solution 907 adopted as a work item within any IETF working group. 909 GAP2-3: The handling of mobility management to the granularity of an 910 individual session of a user/device needs proper session 911 identification in addition to user/device identification. 913 5.3. IPv6 deployment - REQ3 915 This requirement states that DMM solutions should primarily target 916 IPv6 as the primary deployment environment. IPv4 support is not 917 considered mandatory and solutions should not be tailored 918 specifically to support IPv4. 920 All analyzed DMM practices support IPv6. Some of them, such as 921 MIPv6/NEMO including the support of dynamic HA selection, MOBIKE, 922 SIPTO also have IPv4 support. Some solutions, e.g., PMIPv6, also 923 have some limited IPv4 support. In conclusion, this requirement is 924 met by existing DMM practices. 926 5.4. Considering existing mobility protocols - REQ4 928 A DMM solution must first consider reusing and extending IETF- 929 standardized protocols before specifying new protocols. 931 As stated in [RFC7333], a DMM solution could reuse existing IETF and 932 standardized protocols before specifying new protocols. Besides, 933 Section 4 of this document discusses various ways to flatten and 934 distribute current mobility solutions. Actually, nothing prevents 935 the distribution of mobility functions within IP mobility protocols. 936 However, as discussed in Section 5.1 and Section 5.2, limitations 937 exist. 939 The 3GPP data plane anchoring function, i.e., the PGW, can also be 940 distributed, but with limitations; e.g., no anchoring relocation, no 941 context transfer between anchors and centralized control plane. The 942 3GPP architecture is also going in the direction of flattening with 943 SIPTO and LIPA, though they do not provide full mobility support. 945 For example, mobility support for SIPTO traffic can be rather 946 limited, and offloaded traffic cannot access operator services. 947 Thus, the operator must be very careful in selecting which traffic to 948 offload. 950 5.5. Coexistence with deployed networks/hosts and operability across 951 different networks - REQ5 953 According to [RFC7333], DMM implementations are required to co-exist 954 with existing network deployments, end hosts and routers. 955 Additionally, DMM solutions are expected to work across different 956 networks, possibly operated as separate administrative domains, when 957 the necessary mobility management signaling, forwarding, and network 958 access are allowed by the trust relationship between them. All 959 current mobility protocols can co-exist with existing network 960 deployments and end hosts. There is no gap between existing mobility 961 protocols and this requirement. 963 5.6. Operation and management considerations - REQ6 965 This requirement actually comprises several aspects, as summarized 966 below. 968 o A DMM solution needs to consider configuring a device, monitoring 969 the current operational state of a device, responding to events 970 that impact the device, possibly by modifying the configuration 971 and storing the data in a format that can be analyzed later. 973 o A DMM solution has to describe in what environment and how it can 974 be scalably deployed and managed. 976 o A DMM solution has to support mechanisms to test if the DMM 977 solution is working properly. 979 o A DMM solution is expected to expose the operational state of DMM 980 to the administrators of the DMM entities. 982 o A DMM solution, which supports flow mobility, is also expected to 983 support means to correlate the flow routing policies and the 984 observed forwarding actions. 986 o A DMM solution is expected to support mechanisms to check the 987 liveness of the forwarding path. 989 o A DMM solution has to provide fault management and monitoring 990 mechanisms to manage situations where update of the mobility 991 session or the data path fails. 993 o A DMM solution is expected to be able to monitor the usage of the 994 DMM protocol. 996 o DMM solutions have to support standardized configuration with 997 NETCONF [RFC6241], using YANG [RFC6020] modules, which are 998 expected to be created for DMM when needed for such configuration. 1000 GAP6-1: Existing mobility management protocols have not thoroughly 1001 documented how, or whether, they support the above list of 1002 operation and management considerations. Each of the above 1003 needs to be considered from the beginning in a DMM solution. 1005 GAP6-2: Management information base (MIB) objects are currently 1006 defined in [RFC4295] for MIPv6 and in [RFC6475] for PMIPv6. 1007 Standardized configuration with NETCONF [RFC6241], using 1008 YANG [RFC6020] modules is lacking. 1010 5.7. Security considerations - REQ7 1012 As stated in [RFC7333], a DMM solution has to support any security 1013 protocols and mechanisms needed to secure the network and to make 1014 continuous security improvements. In addition, with security taken 1015 into consideration early in the design, a DMM solution cannot 1016 introduce new security risks, or amplify existing security risks, 1017 that cannot be mitigated by existing security protocols and 1018 mechanisms. 1020 Any solutions that are intended to fill in gaps identified in this 1021 document need to meet this requirement. At present, it does not 1022 appear that using existing solutions to support DMM has introduced 1023 any new security issues. For example, Mobile IPv6 defines security 1024 features to protect binding updates both to home agents and 1025 correspondent nodes. It also defines mechanisms to protect the data 1026 packets transmission for Mobile IPv6 users. Proxy Mobile IPv6 and 1027 other variations of mobile IP also have similar security 1028 considerations. 1030 5.8. Multicast - REQ8 1032 It is stated in [RFC7333] that DMM solutions are expected to allow 1033 the development of multicast solutions to avoid network inefficiency 1034 in multicast traffic delivery. 1036 Current IP mobility solutions address mainly the mobility problem for 1037 unicast traffic. Solutions relying on the use of an anchor point for 1038 tunneling multicast traffic down to the access router, or to the 1039 mobile node, introduce the so-called "tunnel convergence problem." 1040 This means that multiple instances of the same multicast traffic can 1041 converge to the same node, diminishing the advantage of using 1042 multicast protocols. 1044 [RFC6224] documents a baseline solution for the previous issue, and 1045 [RFC7028] a routing optimization solution. The baseline solution 1046 suggests deploying a Multicast Listener Discovery (MLD) proxy 1047 function at the MAG, and either a multicast router or another MLD 1048 proxy function at the LMA. The routing optimization solution 1049 describes an architecture where a dedicated multicast tree mobility 1050 anchor or a direct routing option can be used to avoid the tunnel 1051 convergence problem. 1053 Besides the solutions highlighted before, there are no other 1054 mechanisms for mobility protocols to address the multicast tunnel 1055 convergence problem. 1057 5.9. Summary 1059 We next list the main gaps identified from the analysis performed 1060 above: 1062 GAP1-1: Existing solutions only provide an optimal initial anchor 1063 assignment, a gap being the lack of dynamic anchor change/ 1064 new anchor assignment. Neither the HA switch nor the LMA 1065 runtime assignment allows changing the anchor during an 1066 ongoing session. MOBIKE allows change of GW but its 1067 applicability has been scoped to a very narrow use case. 1069 GAP1-2: The MN needs to be able to perform source address selection. 1070 Proper mechanism to inform the MN is lacking to provide the 1071 basis for the proper selection. 1073 GAP1-3: Currently, there is no efficient mechanism specified by the 1074 IETF that allows the dynamic discovery of the presence of 1075 nodes that can play the role of anchor, discover their 1076 capabilities and allow the selection of the most suitable 1077 one. However, the following mechanisms could help 1078 discovering anchors: 1080 Dynamic Home Agent Address Discovery (DHAAD): the use of the 1081 home agent (H) flag in Router Advertisements (which 1082 indicates that the router sending the Router Advertisement 1083 is also functioning as a Mobile IPv6 home agent on the link) 1084 and the MAP option in Router Advertisements defined by 1085 HMIPv6. 1087 GAP1-4: While existing network-based DMM practices may allow the 1088 deployment of multiple LMAs and dynamically select the best 1089 one, this requires to still keep some centralization in the 1090 control plane, to access the policy database (as defined in 1091 RFC5213). Although [I-D.ietf-netext-pmip-cp-up-separation] 1092 allows a MAG to perform splitting of its control and user 1093 planes, there is a lack of solutions/extensions that support 1094 a clear control and data plane separation for IETF IP 1095 mobility protocols in a DMM context. 1097 GAP2-1: The information of which sessions at the mobile node are 1098 active and are using the mobility support need to be 1099 transferred to or shared with the network. Such mechanism 1100 has not been defined. 1102 GAP2-2: The mobile node needs to simultaneously use multiple IP 1103 addresses with different properties. There is a lack of 1104 mechanism to expose this information to the mobile node 1105 which can then update accordingly its source address 1106 selection mechanism. 1108 GAP2-3: The handling of mobility management has not been to the 1109 granularity of an individual session of a user/device 1110 before. The combination of session identification and user/ 1111 device identification may be lacking. 1113 GAP6-1: Mobility management protocols have not thoroughly documented 1114 how, or whether, they support the following list of 1115 operation and management considerations: 1117 * A DMM solution needs to consider configuring a device, 1118 monitoring the current operational state of a device, 1119 responding to events that impact the device, possibly by 1120 modifying the configuration and storing the data in a 1121 format that can be analyzed later. 1123 * A DMM solution has to describe in what environment and 1124 how it can be scalably deployed and managed. 1126 * A DMM solution has to support mechanisms to test if the 1127 DMM solution is working properly. 1129 * A DMM solution is expected to expose the operational 1130 state of DMM to the administrators of the DMM entities. 1132 * A DMM solution, which supports flow mobility, is also 1133 expected to support means to correlate the flow routing 1134 policies and the observed forwarding actions. 1136 * A DMM solution is expected to support mechanisms to check 1137 the liveness of the forwarding path. 1139 * A DMM solution has to provide fault management and 1140 monitoring mechanisms to manage situations where update 1141 of the mobility session or the data path fails. 1143 * A DMM solution is expected to be able to monitor the 1144 usage of the DMM protocol. 1146 * DMM solutions have to support standardized configuration 1147 with NETCONF [RFC6241], using YANG [RFC6020] modules, 1148 which are expected to be created for DMM when needed for 1149 such configuration. 1151 GAP6-2: Management information base (MIB) objects are currently 1152 defined in [RFC4295] for MIPv6 and in [RFC6475] for PMIPv6. 1153 Standardized configuration with NETCONF [RFC6241], using 1154 YANG [RFC6020] modules is lacking. 1156 6. Security Considerations 1158 The deployment of DMM using existing IP mobility protocols raises 1159 similar security threats as those encountered in centralized mobility 1160 management systems. Without authentication, a malicious node could 1161 forge signaling messages and redirect traffic from its legitimate 1162 path. This would amount to a denial of service attack against the 1163 specific node or nodes for which the traffic is intended. 1164 Distributed mobility anchoring, while keeping current security 1165 mechanisms, might require more security associations to be managed by 1166 the mobility management entities, potentially leading to scalability 1167 and performance issues. Moreover, distributed mobility anchoring 1168 makes mobility security problems more complex, since traffic 1169 redirection requests might come from previously unconsidered origins, 1170 thus leading to distributed points of attack. Consequently, the DMM 1171 security design needs to account for the distribution of security 1172 associations between additional mobility entities. 1174 7. Contributors 1176 This document has benefited to valuable contributions from 1178 Charles E. Perkins 1179 Huawei Technologies 1180 EMail: charliep@computer.org 1182 who had produced a matrix to compare the different mobility protocols 1183 and extensions against a list of desired DMM properties. They were 1184 useful inputs in the early work of gap analysis. He had continued to 1185 give suggestions as well as extensive review comments to this 1186 documents. 1188 8. References 1190 8.1. Normative References 1192 [RFC7333] Chan, H., Liu, D., Seite, P., Yokota, H., and J. Korhonen, 1193 "Requirements for Distributed Mobility Management", RFC 1194 7333, August 2014. 1196 8.2. Informative References 1198 [I-D.anipko-mif-mpvd-arch] 1199 Anipko, D., "Multiple Provisioning Domain Architecture", 1200 draft-anipko-mif-mpvd-arch-05 (work in progress), November 1201 2013. 1203 [I-D.bhandari-dhc-class-based-prefix] 1204 Systems, C., Halwasia, G., Gundavelli, S., Deng, H., 1205 Thiebaut, L., Korhonen, J., and I. Farrer, "DHCPv6 class 1206 based prefix", draft-bhandari-dhc-class-based-prefix-05 1207 (work in progress), July 2013. 1209 [I-D.gundavelli-v6ops-community-wifi-svcs] 1210 Gundavelli, S., Grayson, M., Seite, P., and Y. Lee, 1211 "Service Provider Wi-Fi Services Over Residential 1212 Architectures", draft-gundavelli-v6ops-community-wifi- 1213 svcs-06 (work in progress), April 2013. 1215 [I-D.ietf-netext-pmip-cp-up-separation] 1216 Wakikawa, R., Pazhyannur, R., Gundavelli, S., and C. 1217 Perkins, "Separation of Control and User Plane for Proxy 1218 Mobile IPv6", draft-ietf-netext-pmip-cp-up-separation-07 1219 (work in progress), August 2014. 1221 [I-D.korhonen-6man-prefix-properties] 1222 Korhonen, J., Patil, B., Gundavelli, S., Seite, P., and D. 1223 Liu, "IPv6 Prefix Properties", draft-korhonen-6man-prefix- 1224 properties-02 (work in progress), July 2013. 1226 [IEEE.802-16.2009] 1227 "IEEE Standard for Local and metropolitan area networks 1228 Part 16: Air Interface for Broadband Wireless Access 1229 Systems", IEEE Standard 802.16, 2009, 1230 . 1233 [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 1234 Thubert, "Network Mobility (NEMO) Basic Support Protocol", 1235 RFC 3963, January 2005. 1237 [RFC4066] Liebsch, M., Singh, A., Chaskar, H., Funato, D., and E. 1238 Shim, "Candidate Access Router Discovery (CARD)", RFC 1239 4066, July 2005. 1241 [RFC4067] Loughney, J., Nakhjiri, M., Perkins, C., and R. Koodli, 1242 "Context Transfer Protocol (CXTP)", RFC 4067, July 2005. 1244 [RFC4225] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E. 1245 Nordmark, "Mobile IP Version 6 Route Optimization Security 1246 Design Background", RFC 4225, December 2005. 1248 [RFC4295] Keeni, G., Koide, K., Nagami, K., and S. Gundavelli, 1249 "Mobile IPv6 Management Information Base", RFC 4295, April 1250 2006. 1252 [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol 1253 (MOBIKE)", RFC 4555, June 2006. 1255 [RFC4640] Patel, A. and G. Giaretta, "Problem Statement for 1256 bootstrapping Mobile IPv6 (MIPv6)", RFC 4640, September 1257 2006. 1259 [RFC4889] Ng, C., Zhao, F., Watari, M., and P. Thubert, "Network 1260 Mobility Route Optimization Solution Space Analysis", RFC 1261 4889, July 2007. 1263 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 1264 4960, September 2007. 1266 [RFC5014] Nordmark, E., Chakrabarti, S., and J. Laganier, "IPv6 1267 Socket API for Source Address Selection", RFC 5014, 1268 September 2007. 1270 [RFC5026] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6 1271 Bootstrapping in Split Scenario", RFC 5026, October 2007. 1273 [RFC5142] Haley, B., Devarapalli, V., Deng, H., and J. Kempf, 1274 "Mobility Header Home Agent Switch Message", RFC 5142, 1275 January 2008. 1277 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 1278 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 1280 [RFC5380] Soliman, H., Castelluccia, C., ElMalki, K., and L. 1281 Bellier, "Hierarchical Mobile IPv6 (HMIPv6) Mobility 1282 Management", RFC 5380, October 2008. 1284 [RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and 1285 Routers", RFC 5555, June 2009. 1287 [RFC5568] Koodli, R., "Mobile IPv6 Fast Handovers", RFC 5568, July 1288 2009. 1290 [RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy 1291 Mobile IPv6", RFC 5844, May 2010. 1293 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 1294 "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 1295 5996, September 2010. 1297 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 1298 Network Configuration Protocol (NETCONF)", RFC 6020, 1299 October 2010. 1301 [RFC6097] Korhonen, J. and V. Devarapalli, "Local Mobility Anchor 1302 (LMA) Discovery for Proxy Mobile IPv6", RFC 6097, February 1303 2011. 1305 [RFC6224] Schmidt, T., Waehlisch, M., and S. Krishnan, "Base 1306 Deployment for Multicast Listener Support in Proxy Mobile 1307 IPv6 (PMIPv6) Domains", RFC 6224, April 2011. 1309 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 1310 Bierman, "Network Configuration Protocol (NETCONF)", RFC 1311 6241, June 2011. 1313 [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support 1314 in IPv6", RFC 6275, July 2011. 1316 [RFC6463] Korhonen, J., Gundavelli, S., Yokota, H., and X. Cui, 1317 "Runtime Local Mobility Anchor (LMA) Assignment Support 1318 for Proxy Mobile IPv6", RFC 6463, February 2012. 1320 [RFC6475] Keeni, G., Koide, K., Gundavelli, S., and R. Wakikawa, 1321 "Proxy Mobile IPv6 Management Information Base", RFC 6475, 1322 May 2012. 1324 [RFC6611] Chowdhury, K. and A. Yegin, "Mobile IPv6 (MIPv6) 1325 Bootstrapping for the Integrated Scenario", RFC 6611, May 1326 2012. 1328 [RFC6697] Zorn, G., Wu, Q., Taylor, T., Nir, Y., Hoeper, K., and S. 1329 Decugis, "Handover Keying (HOKEY) Architecture Design", 1330 RFC 6697, July 2012. 1332 [RFC6705] Krishnan, S., Koodli, R., Loureiro, P., Wu, Q., and A. 1333 Dutta, "Localized Routing for Proxy Mobile IPv6", RFC 1334 6705, September 2012. 1336 [RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, 1337 "Default Address Selection for Internet Protocol Version 6 1338 (IPv6)", RFC 6724, September 2012. 1340 [RFC7028] Zuniga, JC., Contreras, LM., Bernardos, CJ., Jeon, S., and 1341 Y. Kim, "Multicast Mobility Routing Optimizations for 1342 Proxy Mobile IPv6", RFC 7028, September 2013. 1344 [SDO-3GPP.23.401] 1345 3GPP, "General Packet Radio Service (GPRS) enhancements 1346 for Evolved Universal Terrestrial Radio Access Network 1347 (E-UTRAN) access", 3GPP TS 23.401 10.10.0, March 2013. 1349 [SDO-3GPP.23.402] 1350 3GPP, "Architecture enhancements for non-3GPP accesses", 1351 3GPP TS 23.402 10.8.0, September 2012. 1353 [SDO-3GPP.24.303] 1354 3GPP, "Mobility management based on Dual-Stack Mobile 1355 IPv6; Stage 3", 3GPP TS 24.303 10.0.0, June 2013. 1357 [SDO-3GPP.29.060] 1358 3GPP, "General Packet Radio Service (GPRS); GPRS 1359 Tunnelling Protocol (GTP) across the Gn and Gp interface", 1360 3GPP TS 29.060 3.19.0, March 2004. 1362 [SDO-3GPP.29.274] 1363 3GPP, "3GPP Evolved Packet System (EPS); Evolved General 1364 Packet Radio Service (GPRS) Tunnelling Protocol for 1365 Control plane (GTPv2-C); Stage 3", 3GPP TS 29.274 10.11.0, 1366 June 2013. 1368 [SDO-3GPP.29.281] 1369 3GPP, "General Packet Radio System (GPRS) Tunnelling 1370 Protocol User Plane (GTPv1-U)", 3GPP TS 29.281 10.3.0, 1371 September 2011. 1373 [SDO-3GPP.29.303] 1374 3GPP, "Domain Name System Procedures; Stage 3", 3GPP TS 1375 29.303 10.4.0, September 2012. 1377 Authors' Addresses 1379 Dapeng Liu (editor) 1380 China Mobile 1381 Unit2, 28 Xuanwumenxi Ave, Xuanwu District 1382 Beijing 100053 1383 China 1385 Email: liudapeng@chinamobile.com 1387 Juan Carlos Zuniga (editor) 1388 InterDigital Communications, LLC 1389 1000 Sherbrooke Street West, 10th floor 1390 Montreal, Quebec H3A 3G4 1391 Canada 1393 Email: JuanCarlos.Zuniga@InterDigital.com 1394 URI: http://www.InterDigital.com/ 1396 Pierrick Seite 1397 Orange 1398 4, rue du Clos Courtel, BP 91226 1399 Cesson-Sevigne 35512 1400 France 1402 Email: pierrick.seite@orange.com 1404 H Anthony Chan 1405 Huawei Technologies 1406 5340 Legacy Dr. Building 3 1407 Plano, TX 75024 1408 USA 1410 Email: h.a.chan@ieee.org 1412 Carlos J. Bernardos 1413 Universidad Carlos III de Madrid 1414 Av. Universidad, 30 1415 Leganes, Madrid 28911 1416 Spain 1418 Phone: +34 91624 6236 1419 Email: cjbc@it.uc3m.es 1420 URI: http://www.it.uc3m.es/cjbc/