idnits 2.17.1 draft-ietf-dmm-requirements-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 643 has weird spacing: '...enarios for D...' == Line 656 has weird spacing: '...ference on Ne...' == Line 667 has weird spacing: '...orkshop on Se...' == Line 672 has weird spacing: '...agement in Mo...' == Line 675 has weird spacing: '...orkshop on Se...' == (2 more instances...) == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: A DMM solution MUST not introduce new security risks or amplify existing security risks against which the existing security mechanisms/protocols cannot offer sufficient protection. -- The document date (September 28, 2013) is 3863 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'I-D.wakikawa-netext-pmip-cp-up-separtion' is mentioned on line 325, but not defined == Unused Reference: 'I-D.bhandari-dhc-class-based-prefix' is defined on line 623, but no explicit reference was found in the text == Unused Reference: 'I-D.wakikawa-netext-pmip-cp-up-separation' is defined on line 635, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 11 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Chan (Ed.) 3 Internet-Draft Huawei Technologies (more 4 Intended status: Informational co-authors on P. 17) 5 Expires: April 1, 2014 D. Liu 6 China Mobile 7 P. Seite 8 Orange 9 H. Yokota 10 KDDI Lab 11 J. Korhonen 12 Renesas Mobile 13 September 28, 2013 15 Requirements for Distributed Mobility Management 16 draft-ietf-dmm-requirements-09 18 Abstract 20 This document defines the requirements for Distributed Mobility 21 Management (DMM). The hierarchical structure in traditional wireless 22 networks has led primarily to centralized deployment models. As some 23 wireless networks are evolving away from the hierarchical structure, 24 such as in moving the content delivery servers closer to the users, a 25 distributed model for mobility management can be useful to them. 27 Requirements Language 29 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 30 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 31 document are to be interpreted as described in RFC 2119 RFC 2119 32 [RFC2119]. 34 Status of this Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at http://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on April 1, 2014. 50 Copyright Notice 52 Copyright (c) 2013 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 2. Conventions used in this document . . . . . . . . . . . . . . 6 69 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 70 3. Centralized versus distributed mobility management . . . . . . 7 71 3.1. Centralized mobility management . . . . . . . . . . . . . 7 72 3.2. Distributed mobility management . . . . . . . . . . . . . 8 73 4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 9 74 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 11 75 5.1. Distributed processing . . . . . . . . . . . . . . . . . . 11 76 5.2. Transparency to Upper Layers when needed . . . . . . . . . 11 77 5.3. IPv6 deployment . . . . . . . . . . . . . . . . . . . . . 12 78 5.4. Existing mobility protocols . . . . . . . . . . . . . . . 12 79 5.5. Co-existence . . . . . . . . . . . . . . . . . . . . . . . 13 80 5.6. Security considerations . . . . . . . . . . . . . . . . . 13 81 5.7. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 14 82 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 83 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 84 8. Co-authors and Contributors . . . . . . . . . . . . . . . . . 15 85 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 86 9.1. Normative References . . . . . . . . . . . . . . . . . . . 15 87 9.2. Informative References . . . . . . . . . . . . . . . . . . 15 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 90 1. Introduction 92 In the past decade a fair number of mobility protocols have been 93 standardized [RFC6275] [RFC5944] [RFC5380] [RFC6301] [RFC5213]. 94 Although the protocols differ in terms of functions and associated 95 message formats, they all employ a mobility anchor to allow a mobile 96 node to remain reachable after it has moved to a different network. 97 The anchor point, among other tasks, ensures connectivity by 98 forwarding packets destined to, or sent from, the mobile node. It is 99 a centrally deployed mobility anchor in the sense that the deployed 100 architectures today have a small number of these anchors and the 101 traffic of millions of mobile nodes in an operator network are 102 typically managed by the same anchor. 104 Distributed mobility management (DMM) is an alternative to the above 105 centralized deployment. The background behind the interests to study 106 DMM are primarily in the following. 108 (1) Mobile users are, more than ever, consuming Internet content; 109 such traffic imposes new requirements on mobile core networks 110 for data traffic delivery. The presence of content providers 111 closer to Internet Service Providers (ISP) network requires 112 taking into account local Content Delivery Networks (CDNs) while 113 providing mobility services. Moreover, when the traffic demand 114 exceeds available capacity, service providers need to implement 115 new strategies such as selective IPv4 traffic offload (e.g. 116 [RFC6909], 3GPP work items LIPA/SIPTO [TS.23.401]) through 117 alternative access networks (e.g. WLAN) [Paper- 118 Mobile.Data.Offloading]. A gateway selection mechanism also 119 takes the user proximity into account within EPC [TS.29303]. 120 These mechanisms were not pursued in the past owing to charging 121 and billing reasons. Assigning a gateway anchor node from a 122 visited network in roaming scenario has until recently been done 123 and are limited to voice services only. Charging and billing 124 require solutions beyond the mobility protocol. 126 Both traffic offloading and CDN mechanisms could benefit from 127 the development of mobile architectures with fewer levels of 128 routing hierarchy introduced into the data path by the mobility 129 management system. This trend towards so-called "flat networks" 130 works best for direct communications among peers in the same 131 geographical area. Distributed mobility management in a truly 132 flat mobile architecture would anchor the traffic closer to the 133 point of attachment of the user. 135 (2) Today's mobile networks present service providers with new 136 challenges. Mobility patterns indicate that mobile nodes often 137 remain attached to the same point of attachment for considerable 138 periods of time [Paper-Locating.User]. Specific IP mobility 139 management support is not required for applications that launch 140 and complete their sessions while the mobile node is connected 141 to the same point of attachment. However, currently, IP 142 mobility support is designed for always-on operation, 143 maintaining all parameters of the context for each mobile 144 subscriber for as long as they are connected to the network. 145 This can result in a waste of resources and unnecessary costs 146 for the service provider. Infrequent node mobility coupled with 147 application intelligence suggest that mobility support could be 148 provided selectively such as in [I-D.bhandari-dhc-class-based- 149 prefix] and [I-D.korhonen-6man-prefix-properties], thus reducing 150 the amount of context maintained in the network. 152 In addition, considerations in the study of DMM are in the following. 154 (1) To optimize handovers from the perspective of mobile nodes, the 155 base protocols have been extended to efficiently handle packet 156 forwarding between the previous and new points of attachment. 157 These extensions are necessary when applications have stringent 158 requirements in terms of delay. Notions of localization and 159 distribution of local agents have been introduced to reduce 160 signaling overhead at the centralized routing anchor point 161 [Paper-Distributed.Centralized.Mobility]. Unfortunately, such 162 protocols have not been deployed today. 164 (2) Most existing mobility protocols have not been designed for 165 multiple-interface hosts which are capable to use multiple 166 interfaces simultaneously. Retrofitting the required 167 functionality can result in an unnecessary increase in the 168 protocol complexity. 170 (3) IP multicast support, including optimizations, have been 171 introduced as an effective transport method for multimedia data 172 delivery, but by "patching-up" procedure after completing the 173 design of reference mobility protocol, leading to network 174 inefficiency and non-optimal routing. 176 The distributed mobility management (DMM) charter addresses two 177 complementary aspects of mobility management procedures: the 178 distribution of mobility anchors in the data-plane towards a more 179 flat network and the selective activation/deactivation of mobility 180 protocol support as an enabler to distributed mobility management. 181 The former aims at positioning mobility anchors (e.g., HA, LMA) 182 closer to the user; ideally, mobility agents could be collocated with 183 the first-hop router. The latter, facilitated by the distribution of 184 mobility anchors, identifies when mobility support must be activated 185 and when sessions do not require mobility management support -- thus 186 reducing the amount of state information that must be maintained in 187 various mobility agents of the mobile network. It can then avoid the 188 unnecessary establishment of mechanisms to forward traffic from an 189 old to a new mobility anchor. 191 This document compares distributed mobility management with 192 centralized mobility management in Section 3. The problems that can 193 be addressed with DMM are summarized in Section 4. The mandatory 194 requirements as well as the optional requirements are given in 195 Section 5. Finally, security considerations are discussed in Section 196 6. 198 The problem statement and the use cases [I-D.yokota-dmm-scenario] can 199 be found in [Paper-Distributed.Mobility.Review]. 201 2. Conventions used in this document 203 2.1. Terminology 205 All the general mobility-related terms and their acronyms used in 206 this document are to be interpreted as defined in the Mobile IPv6 207 base specification [RFC6275], in the Proxy mobile IPv6 specification 208 [RFC5213], and in Mobility Related Terminology [RFC3753]. These 209 terms include the following: mobile node (MN), correspondent node 210 (CN), and home agent (HA) as per [RFC6275]; local mobility anchor 211 (LMA) and mobile access gateway (MAG) as per [RFC5213], and context 212 as per [RFC3753]. 214 In addition, this draft introduces the following terms. 216 Centrally deployed mobility anchors 218 refer to the mobility management deployments in which there are 219 very few mobility anchors and the traffic of millions of mobile 220 nodes in an operator network are managed by the same anchor. 222 Centralized mobility management 224 makes use of centrally deployed mobility anchors. 226 Distributed mobility management 228 is not centralized so that traffic does not need to traverse 229 centrally deployed mobility anchors. 231 Flat mobile network 233 has few levels of routing hierarchy introduced into the data path 234 by the mobility management system. 236 Mobility context 238 is the collection of information required to provide mobility 239 management support for a given mobile node. 241 3. Centralized versus distributed mobility management 243 Mobility management functions may be implemented at different layers 244 of the protocol stack. At the IP (network) layer, mobility 245 management can be client-based or network-based. 247 An IP-layer mobility management protocol is typically based on the 248 principle of distinguishing between session identifier and routing 249 address and maintaining a mapping between the two. In Mobile IP, the 250 home address serves as the session identifier whereas the care-of- 251 address (CoA) takes the role of the routing address. The binding 252 between these two is maintained at the home agent (mobility anchor). 253 If packets addressed to the home address of a mobile node can be 254 continuously delivered to the node, then all sessions using that home 255 address are unaffected even though the routing address (CoA) changes. 257 The next two subsections explain centralized and distributed mobility 258 management functions in the network. 260 3.1. Centralized mobility management 262 In centralized mobility management, the mapping information between 263 the session identifier and the locator IP address of a mobile node 264 (MN) is kept at a single mobility anchor. At the same time, packets 265 destined to the MN are routed via this anchor. In other words, such 266 mobility management systems are centralized in both the control plane 267 and the data plane (mobile node IP traffic). 269 Many existing mobility management deployments make use of centralized 270 mobility anchoring in a hierarchical network architecture, as shown 271 in Figure 1. Examples of such centralized mobility anchors are the 272 home agent (HA) and local mobility anchor (LMA) in Mobile IPv6 273 [RFC6275] and Proxy Mobile IPv6 [RFC5213], respectively. Current 274 cellular networks such as the Third Generation Partnership Project 275 (3GPP) GPRS networks, CDMA networks, and 3GPP Evolved Packet System 276 (EPS) networks employ centralized mobility management too. In 277 particular, the Gateway GPRS Support Node (GGSN), Serving GPRS 278 Support Node (SGSN) and Radio Network Controller (RNC) in the 3GPP 279 GPRS hierarchical network, and the Packet Data Network Gateway (P-GW) 280 and Serving Gateway (S-GW) in the 3GPP EPS network all act as anchors 281 in a hierarchy. 283 3G GPRS 3GPP EPS MIP/PMIP 284 +------+ +------+ +------+ 285 | GGSN | | P-GW | |HA/LMA| 286 +------+ +------+ +------+ 287 /\ /\ /\ 288 / \ / \ / \ 289 / \ / \ / \ 290 / \ / \ / \ 291 / \ / \ / \ 292 / \ / \ / \ 293 / \ / \ / \ 294 +------+ +------+ +------+ +------+ +------+ +------+ 295 | SGSN | | SGSN | | S-GW | | S-GW | |MN/MAG| |MN/MAG| 296 +------+ +------+ +------+ +------+ +------+ +------+ 297 /\ /\ 298 / \ / \ 299 / \ / \ 300 +---+ +---+ +---+ +---+ 301 |RNC| |RNC| |RNC| |RNC| 302 +---+ +---+ +---+ +---+ 304 Figure 1. Centralized mobility management. 306 3.2. Distributed mobility management 308 Mobility management functions may also be distributed to multiple 309 networks as shown in Figure 2, so that a mobile node in any of these 310 networks may be served by a nearby mobility function (MF). 312 +------+ +------+ +------+ +------+ 313 | MF | | MF | | MF | | MF | 314 +------+ +------+ +------+ +------+ 315 | 316 +----+ 317 | MN | 318 +----+ 320 Figure 2. Distributed mobility management. 322 Mobility management may be partially or fully distributed 323 [I-D.yokota-dmm-scenario]. In the former case only the data plane is 324 distributed, implicitly assuming separation of data and control 325 planes as described in [I-D.wakikawa-netext-pmip-cp-up-separtion]. 326 Fully distributed mobility management implies that both the data 327 plane and the control plane are distributed. While mobility 328 management can be distributed, it is not necessary for other 329 functions such as subscription management, subscription database, and 330 network access authentication to be similarly distributed. 332 A distributed mobility management scheme for a flat mobile network of 333 access nodes is proposed in [Paper-Distributed.Dynamic.Mobility]. 334 Its benefits over centralized mobility management are shown through 335 simulations in [Paper-Distributed.Centralized.Mobility]. Moreover, 336 the (re)use and extension of existing protocols in the design of both 337 fully distributed mobility management [Paper-Migrating.Home.Agents] 338 [Paper-Distributed.Mobility.SAE] and partially distributed mobility 339 management [Paper-Distributed.Mobility.PMIP] [Paper- 340 Distributed.Mobility.MIP] have been reported in the literature. 341 Therefore, before designing new mobility management protocols for a 342 future distributed architecture, it is recommended to first consider 343 whether existing mobility management protocols can be extended. 345 4. Problem Statement 347 The problems that can be addressed with DMM are summarized in the 348 following: 350 PS1: Non-optimal routes 352 Routing via a centralized anchor often results in non-optimal 353 routes, thereby increasing the end-to-end delay. The problem 354 is manifested, for example, when accessing a nearby server or 355 servers of a Content Delivery Network (CDN), or when receiving 356 locally available IP multicast or sending IP multicast packets. 357 (Existing route optimization is only a host-based solution. On 358 the other hand, localized routing with PMIPv6 [RFC6705] 359 addresses only a part of the problem where both the MN and the 360 CN are located in the PMIP domain and attached to a MAG, and is 361 not applicable when the CN is outside the PMIP domain or does 362 not behave like an MN.) 364 PS2: Divergence from other evolutionary trends in network 365 architectures such as distribution of content delivery. 367 Centralized mobility management can become non-optimal with a 368 flat network architecture. 370 PS3: Low scalability of centralized tunnel management and mobility 371 context maintenance 373 Setting up tunnels through a central anchor and maintaining 374 mobility context for each MN usually requires more concentrated 375 resources in a centralized design, thus reducing scalability. 376 Distributing the tunnel maintenance function and the mobility 377 context maintenance function among different network entities 378 with proper signaling protocol design can increase scalability. 380 PS4: Single point of failure and attack 382 Centralized anchoring designs may be more vulnerable to single 383 points of failures and attacks than a distributed system. The 384 impact of a successful attack on a system with centralized 385 mobility management can be far greater as well. 387 PS5: Unnecessary mobility support to nodes that do not need it 389 IP mobility support is not always required, and not every 390 parameter of mobility context is always used. For example, 391 some applications do not need a stable IP address during a 392 handover to maintain session continuity. Sometimes, the entire 393 application session runs while the terminal does not change the 394 point of attachment. Besides, some sessions, e.g. SIP-based 395 sessions, can handle mobility at the application layer and 396 hence do not need IP mobility support; it is then more 397 efficient to deactivate IP mobility support for such sessions. 399 PS6: (Related problem) Mobility signaling overhead with peer-to-peer 400 communication 402 Wasting resources when mobility signaling (e.g., maintenance of 403 the tunnel, keep alive signaling, etc.) is not turned off for 404 peer-to-peer communication. Peer-to-peer communications have 405 particular traffic patterns that often do not benefit from 406 mobility support from the network. Thus, the associated 407 mobility support signaling (e.g., maintenance of the tunnel, 408 keep alive signaling, etc.) wastes network resources for no 409 application gain. 411 PS7: (Related problem) Deployment with multiple mobility solutions 413 There are already many variants and extensions of MIP. 414 Deployment of new mobility management solutions can be 415 challenging, and debugging difficult, when they must co-exist 416 with solutions already in the field. 418 PS8: Duplicate multicast traffic 420 IP multicast distribution over architectures using IP mobility 421 solutions (e.g., [RFC6224]) may lead to convergence of 422 duplicated multicast subscriptions towards the downstream 423 tunnel entity (e.g. MAG in PMIPv6). Concretely, when 424 multicast subscription for individual mobile nodes is coupled 425 with mobility tunnels (e.g. PMIPv6 tunnel), duplicate 426 multicast subscription(s) is prone to be received through 427 different upstream paths. This problem may also exist or be 428 more severe in a distributed mobility environment. 430 5. Requirements 432 After comparing distributed mobility management against centralized 433 deployment in Section 3, this section identifies the following 434 requirements: 436 5.1. Distributed processing 438 REQ1: Distributed processing 440 IP mobility, network access and routing solutions provided by 441 DMM MUST enable distributed processing for mobility management 442 so that traffic does not need to traverse centrally deployed 443 mobility anchors and thereby avoid non-optimal routes. 445 Motivation: This requirement is motivated by current trends in 446 network evolution: (a) it is cost- and resource-effective to 447 cache and distribute content by combining distributed mobility 448 anchors with caching systems (e.g., CDN); (b) the 449 significantly larger number of mobile nodes and flows call for 450 improved scalability; (c) single points of failure are avoided 451 in a distributed system; (d) threats against centrally 452 deployed anchors, e.g., home agent and local mobility anchor, 453 are mitigated in a distributed system. 455 This requirement addresses the problems PS1, PS2, PS3, and PS4 456 described in Section 4. 458 5.2. Transparency to Upper Layers when needed 460 REQ2: Transparency to Upper Layers when needed 462 DMM solutions MUST provide transparent mobility support above 463 the IP layer when needed. Such transparency is needed, for 464 example, when, upon change of point of attachment to the 465 network, an application flow cannot cope with a change in the 466 IP address. However, it is not always necessary to maintain a 467 stable home IP address or prefix for every application or at 468 all times for a mobile node. 470 Motivation: The motivation of this requirement is to enable 471 more efficient routing and more efficient use of network 472 resources by selecting an IP address or prefix according to 473 whether mobility support is needed and by not maintaining 474 context at the mobility anchor when there is no such need. 476 This requirement addresses the problem PS5 as well as the related 477 problem PS6 stated in Section 4. 479 5.3. IPv6 deployment 481 REQ3: IPv6 deployment 483 DMM solutions SHOULD target IPv6 as the primary deployment 484 environment and SHOULD NOT be tailored specifically to support 485 IPv4, in particular in situations where private IPv4 addresses 486 and/or NATs are used. 488 Motivation: This requirement conforms to the general 489 orientation of IETF work. DMM deployment is foreseen in mid- 490 to long-term horizon, when IPv6 is expected to be far more 491 common than today. 493 This requirement avoids the unnecessarily complexity in solving the 494 problems in Section 4 for IPv4, which will not be able to use some of 495 the IPv6-specific features. 497 5.4. Existing mobility protocols 499 REQ4: Existing mobility protocols 501 A DMM solution SHOULD first consider reusing and extending 502 IETF-standardized protocols before specifying new protocols. 504 Motivation: Reuse of existing IETF work is more efficient and 505 less error-prone. 507 This requirement attempts to avoid the need of new protocols 508 development and therefore their potential problems of being time- 509 consuming and error-prone. 511 5.5. Co-existence 513 REQ5: Co-existence with deployed networks and hosts 515 The DMM solution MUST be able to co-exist with existing 516 network deployments and end hosts. For example, depending on 517 the environment in which DMM is deployed, DMM solutions may 518 need to be compatible with other deployed mobility protocols 519 or may need to co-exist with a network or mobile hosts/routers 520 that do not support DMM protocols. The mobile node may also 521 move between different access networks, where some of them may 522 support neither DMM nor another mobility protocol. 523 Furthermore, a DMM solution SHOULD work across different 524 networks, possibly operated as separate administrative 525 domains, when allowed by the trust relationship between them. 527 Motivation: (a) to preserve backwards compatibility so that 528 existing networks and hosts are not affected and continue to 529 function as usual, and (b) enable inter-domain operation if 530 desired. 532 This requirement addresses the related problem PS7 described in 533 Section 4. 535 5.6. Security considerations 537 REQ6: Security considerations 539 A DMM solution MUST not introduce new security risks or 540 amplify existing security risks against which the existing 541 security mechanisms/protocols cannot offer sufficient 542 protection. 544 Motivation: Various attacks such as impersonation, denial of 545 service, man-in-the-middle attacks, and so on, may be launched 546 in a DMM deployment. For instance, an illegitimate node may 547 attempt to access a network providing DMM. Another example is 548 that a malicious node can forge a number of signaling messages 549 thus redirecting traffic from its legitimate path. 550 Consequently, the specific node is under a denial of service 551 attack, whereas other nodes do not receive their traffic. 552 Accordingly, security mechanisms/protocols providing access 553 control, integrity, authentication, authorization, 554 confidentiality, etc. can be used to protect the DMM entities 555 as they are already used to protect against existing networks 556 and existing mobility protocols defined in IETF. In addition, 557 end-to-end security measures between communicating nodes may 558 already be used when deploying existing mobility protocols 559 where the signaling messages travel over the Internet. For 560 instance, EAP-based authentication can be used for network 561 access security, while IPsec can be used for end-to-end 562 security. When the existing security mechanisms/protocols are 563 applied to protect the DMM entities, the security risks that 564 may be introduced by DMM MUST be considered to be eliminated. 565 Else the security protection would be degraded in the DMM 566 solution versus in existing mobility protocols. 568 This requirement prevents a DMM solution from introducing 569 uncontrollable problems of potentially insecure mobility management 570 protocols which make deployment infeasible because platforms 571 conforming to the protocols are at risk for data loss and numerous 572 other dangers, including financial harm to the users. 574 5.7. Multicast 576 REQ7: Multicast considerations 578 DMM SHOULD consider multicast early so that solutions can be 579 developed not only to provide IP mobility support when it is 580 needed, but also to avoid network inefficiency issues in 581 multicast traffic delivery (such as duplicate multicast 582 subscriptions towards the downstream tunnel entities). The 583 multicast solutions should therefore avoid restricting the 584 management of all IP multicast traffic to a single host 585 through a dedicated (tunnel) interface on multicast-capable 586 access routers. 588 Motivation: Existing multicast deployment have been introduced 589 after completing the design of the reference mobility 590 protocol, then optimization and extensions have been followed 591 by "patching-up" procedure, thus leading to network 592 inefficiency and non-optimal routing. The multicast solutions 593 should therefore be required to consider efficiency nature in 594 multicast traffic delivery. 596 This requirement addresses the problems PS1 and PS8 described in 597 Section 4. 599 6. Security Considerations 601 Please refer to the discussion under Security requirement in Section 602 5.6. 604 7. IANA Considerations 606 None 608 8. Co-authors and Contributors 610 This problem statement document is a joint effort among the numerous 611 participants. Each individual has made significant contributions to 612 this work and have been listed as co-authors. 614 9. References 616 9.1. Normative References 618 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 619 Requirement Levels", BCP 14, RFC 2119, March 1997. 621 9.2. Informative References 623 [I-D.bhandari-dhc-class-based-prefix] 624 Bhandari, S., Halwasia, G., Gundavelli, S., Deng, H., 625 Thiebaut, L., Korhonen, J., and I. Farrer, "DHCPv6 class 626 based prefix", draft-bhandari-dhc-class-based-prefix-05 627 (work in progress), July 2013. 629 [I-D.korhonen-6man-prefix-properties] 630 Korhonen, J., Patil, B., Gundavelli, S., Seite, P., and D. 631 Liu, "IPv6 Prefix Properties", 632 draft-korhonen-6man-prefix-properties-02 (work in 633 progress), July 2013. 635 [I-D.wakikawa-netext-pmip-cp-up-separation] 636 Wakikawa, R., Pazhyannur, R., and S. Gundavelli, 637 "Separation of Control and User Plane for Proxy Mobile 638 IPv6", draft-wakikawa-netext-pmip-cp-up-separation-00 639 (work in progress), July 2013. 641 [I-D.yokota-dmm-scenario] 642 Yokota, H., Seite, P., Demaria, E., and Z. Cao, "Use case 643 scenarios for Distributed Mobility Management", 644 draft-yokota-dmm-scenario-00 (work in progress), 645 October 2010. 647 [Paper-Distributed.Centralized.Mobility] 648 Bertin, P., Bonjour, S., and J-M. Bonnin, "A Distributed 649 or Centralized Mobility", Proceedings of Global 650 Communications Conference (GlobeCom), December 2009. 652 [Paper-Distributed.Dynamic.Mobility] 653 Bertin, P., Bonjour, S., and J-M. Bonnin, "A Distributed 654 Dynamic Mobility Management Scheme Designed for Flat IP 655 Architectures", Proceedings of 3rd International 656 Conference on New Technologies, Mobility and Security 657 (NTMS), 2008. 659 [Paper-Distributed.Mobility.MIP] 660 Chan, H., "Distributed Mobility Management with Mobile 661 IP", Proceedings of IEEE International Communication 662 Conference (ICC) Workshop on Telecommunications: from 663 Research to Standards, June 2012. 665 [Paper-Distributed.Mobility.PMIP] 666 Chan, H., "Proxy Mobile IP with Distributed Mobility 667 Anchors", Proceedings of GlobeCom Workshop on Seamless 668 Wireless Mobility, December 2010. 670 [Paper-Distributed.Mobility.Review] 671 Chan, H., Yokota, H., Xie, J., Seite, P., and D. Liu, 672 "Distributed and Dynamic Mobility Management in Mobile 673 Internet: Current Approaches and Issues, Journal of 674 Communications, vol. 6, no. 1, pp. 4-15, Feb 2011.", 675 Proceedings of GlobeCom Workshop on Seamless Wireless 676 Mobility, February 2011. 678 [Paper-Distributed.Mobility.SAE] 679 Fisher, M., Anderson, F., Kopsel, A., Schafer, G., and M. 680 Schlager, "A Distributed IP Mobility Approach for 3G SAE", 681 Proceedings of the 19th International Symposium on 682 Personal, Indoor and Mobile Radio Communications (PIMRC), 683 2008. 685 [Paper-Locating.User] 686 Kirby, G., "Locating the User", Communication 687 International, 1995. 689 [Paper-Migrating.Home.Agents] 690 Wakikawa, R., Valadon, G., and J. Murai, "Migrating Home 691 Agents Towards Internet-scale Mobility Deployments", 692 Proceedings of the ACM 2nd CoNEXT Conference on Future 693 Networking Technologies, December 2006. 695 [Paper-Mobile.Data.Offloading] 696 Lee, K., Lee, J., Yi, Y., Rhee, I., and S. Chong, "Mobile 697 Data Offloading: How Much Can WiFi Deliver?", SIGCOMM 698 2010, 2010. 700 [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", 701 RFC 3753, June 2004. 703 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 704 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 706 [RFC5380] Soliman, H., Castelluccia, C., ElMalki, K., and L. 707 Bellier, "Hierarchical Mobile IPv6 (HMIPv6) Mobility 708 Management", RFC 5380, October 2008. 710 [RFC5944] Perkins, C., "IP Mobility Support for IPv4, Revised", 711 RFC 5944, November 2010. 713 [RFC6224] Schmidt, T., Waehlisch, M., and S. Krishnan, "Base 714 Deployment for Multicast Listener Support in Proxy Mobile 715 IPv6 (PMIPv6) Domains", RFC 6224, April 2011. 717 [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support 718 in IPv6", RFC 6275, July 2011. 720 [RFC6301] Zhu, Z., Wakikawa, R., and L. Zhang, "A Survey of Mobility 721 Support in the Internet", RFC 6301, July 2011. 723 [RFC6705] Krishnan, S., Koodli, R., Loureiro, P., Wu, Q., and A. 724 Dutta, "Localized Routing for Proxy Mobile IPv6", 725 RFC 6705, September 2012. 727 [RFC6909] Gundavelli, S., Zhou, X., Korhonen, J., Feige, G., and R. 728 Koodli, "IPv4 Traffic Offload Selector Option for Proxy 729 Mobile IPv6", RFC 6909, April 2013. 731 [TS.23.401] 732 3GPP, "General Packet Radio Service (GPRS) enhancements 733 for Evolved Universal Terrestrial Radio Access Network 734 (E-UTRAN) access", 3GPP TR 23.401 10.10.0, March 2013. 736 [TS.29303] 737 3GPP, "Domain Name System Procedures; Stage 3", 3GPP 738 TR 23.303 11.2.0, September 2012. 740 Authors' Addresses 742 H Anthony Chan (editor) 743 Huawei Technologies (more co-authors on P. 17) 744 5340 Legacy Dr. Building 3, Plano, TX 75024, USA 745 Email: h.a.chan@ieee.org 747 Dapeng Liu 748 China Mobile 749 Unit2, 28 Xuanwumenxi Ave, Xuanwu District, Beijing 100053, China 750 Email: liudapeng@chinamobile.com 752 Pierrick Seite 753 Orange 754 4, rue du Clos Courtel, BP 91226, Cesson-Sevigne 35512, France 755 Email: pierrick.seite@orange.com 757 Hidetoshi Yokota 758 KDDI Lab 759 2-1-15 Ohara, Fujimino, Saitama, 356-8502 Japan 760 Email: yokota@kddilabs.jp 762 Jouni Korhonen 763 Renesas Mobile 764 Porkkalankatu 24, FIN-00180 Helsinki, Finland 765 Email: jouni.korhonen@nsn.com 766 - 767 Charles E. Perkins 768 Huawei Technologies 769 Email: charliep@computer.org 770 - 771 Melia Telemaco 772 Alcatel-Lucent Bell Labs 773 Email: telemaco.melia@alcatel-lucent.com 774 - 775 Elena Demaria 776 Telecom Italia 777 via G. Reiss Romoli, 274, TORINO, 10148, Italy 778 Email: elena.demaria@telecomitalia.it 779 - 780 Jong-Hyouk Lee 781 Sangmyung University 782 Email: hurryon@gmail.com 783 - 784 Kostas Pentikousis 785 Huawei Technologies 786 Carnotstr. 4 10587 Berlin, Germany 787 Email: k.pentikousis@huawei.com 788 - 789 Tricci So 790 ZTE 791 Email: tso@zteusa.com 792 - 793 Carlos J. Bernardos 794 Universidad Carlos III de Madrid 795 Av. Universidad, 30, Leganes, Madrid 28911, Spain 796 Email: cjbc@it.uc3m.es 797 - 798 Peter McCann 799 Huawei Technologies 800 Email: PeterMcCann@huawei.com 801 - 802 Seok Joo Koh 803 Kyungpook National University, Korea 804 Email: sjkoh@knu.ac.kr 805 - 806 Wen Luo 807 ZTE 808 No.68, Zijinhua RD,Yuhuatai District, Nanjing, Jiangsu 210012, China 809 Email: luo.wen@zte.com.cn 810 - 811 Sri Gundavelli 812 Cisco 813 sgundave@cisco.com 814 - 815 Marco Liebsch 816 NEC Laboratories Europe 817 Email: liebsch@neclab.eu 818 - 819 Carl Williams 820 MCSR Labs 821 Email: carlw@mcsr-labs.org 822 - 823 Seil Jeon 824 Instituto de Telecomunicacoes, Aveiro 825 Email: seiljeon@av.it.pt 826 - 827 Sergio Figueiredo 828 Universidade de Aveiro 829 Email: sfigueiredo@av.it.pt 830 - 831 Stig Venaas 832 Email: stig@venaas.com 833 - 834 Luis Miguel Contreras Murillo 835 Telefonica I+D 836 Email: lmcm@tid.es 837 - 838 Juan Carlos Zuniga 839 InterDigital 840 Email: JuanCarlos.Zuniga@InterDigital.com 841 - 842 Alexandru Petrescu 843 Email: alexandru.petrescu@gmail.com 844 - 845 Georgios Karagiannis 846 University of Twente 847 Email: g.karagiannis@utwente.nl 848 - 849 Julien Laganier 850 Juniper 851 jlaganier@juniper.net 852 - 853 Wassim Michel Haddad 854 Ericsson 855 Wassam.Haddad@ericsson.com 856 - 857 Dirk von Hugo 858 Deutsche Telekom Laboratories 859 Dirk.von-Hugo@telekom.de 860 - 861 Ahmad Muhanna 862 Award Solutions 863 amuhanna@awardsolutions.com 864 - 865 Byoung-Jo Kim 866 ATT Labs 867 macsbug@research.att.com 868 - 869 Hassan Ali-Ahmad 870 Orange 871 hassan.aliahmad@orange.com 872 -