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