idnits 2.17.1 draft-yan-dmm-man-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 29, 2017) is 2370 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 5268 (Obsoleted by RFC 5568) ** Downref: Normative reference to an Informational RFC: RFC 7333 Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DMM Working Group Z. Yan 3 Internet-Draft G. Geng 4 Intended status: Standards Track CNNIC 5 Expires: May 2, 2018 J. Lee 6 Sangmyung University 7 H. Chan 8 Huawei Technologies 9 October 29, 2017 11 Mobility Capability Negotiation and Protocol Selection 12 draft-yan-dmm-man-02 14 Abstract 16 The draft analyzes the issue that multiple mobility management 17 protocols have been developed according to different requirements. 18 These different protocols have different functional requirements on 19 the network element or the host. A scheme is then proposed to 20 support the negotiation and selection of adopted mobility management 21 protocol when a host accesses a new network. 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 https://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 2, 2018. 40 Copyright Notice 42 Copyright (c) 2017 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 (https://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. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. Possible Cases . . . . . . . . . . . . . . . . . . . . . . . 4 60 4. Principles and Possible Procedure . . . . . . . . . . . . . . 9 61 5. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . 9 62 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 63 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 64 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 65 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 66 8.2. Informative References . . . . . . . . . . . . . . . . . 12 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 69 1. Introduction 71 A large number of multiple protocols have been developed. In order 72 to clearly analyze the possible cases, these mobility management 73 protocols can be categorized as follows: 75 o Mobile IPv6 (MIPv6) protocol: the mobility management scheme based 76 on [RFC6275]. 77 o Proxy Mobile IPv6 (PMIPv6) protocol: the mobility management 78 scheme based on [RFC5213]. 79 o MIPv6 suite protocols: based on MIPv6, there are multiple 80 extension protocols have been standardized. These protocols can 81 be classified into two types: protocols for functional extension 82 and protocols for performance enhancement. The protocols for 83 functional extension are proposed to support some specific 84 scenarios or functions, such as Dual-stack Mobile IPv6 (DSMIPv6) 85 [RFC5555] for mobility of the dual-stack nodes, Multiple Care-of- 86 address (MCoA) [RFC5648] for hosts with multiple access interfaces 87 and Network Mobility (NEMO) [RFC3963] for mobility of sub-network. 88 The other type is proposed to enhance performance of the mobility 89 management, such as Fast Mobile IPv6 (FMIP6) [RFC5268] for fast 90 handover, Hierarchical Mobile IPv6 (HMIPv6) [RFC5380] for 91 hierarchical mobility optimization. In the MIPv6 suite protocols, 92 location update is initiated by the host and the tunnel is also 93 terminated at the host. 94 o PMIPv6 suite protocols: in order to reduce the protocol cost and 95 enhance the handover performance further, the network-based 96 mobility management protocols were proposed and PMIPv6 was 97 standardized as a base protocol. Based on PMIPv6, a series of its 98 extensions were proposed, such as Dual-stack Proxy Mobile IPv6 99 (DS-PMIPv6) [RFC5844], and Distributed Mobility Management Proxy 100 Mobile IPv6 (DMM-PMIPv6) [RFC7333]. Being different from the 101 MIPv6 suite protocols, the location update in PMIPv6 suite 102 protocols is triggered by the network entity and the tunnel is 103 established between network entities. Then the host needs to do 104 nothing about signaling exchange during the movement, 105 particularly, the mobility support is transparent to the IP layer 106 of the host. 107 o Network-based protocols: generally, they refer to the mobility 108 management protocols which do not require the involvement of the 109 host to support mobility. They include the PMIPv6 suite protocols 110 and other network-based solutions, such as GPRS Tunnelling 111 Protocol (GTP) [TS.29274][TS.29281]. 112 o Host-based protocols: generally, they refer to the mobility 113 management protocols which require the involvement of the host in 114 order to support mobility. They include the MIPv6 suite protocols 115 and other host-based solutions, such as Host Identity Protocol 116 (HIP) [RFC7401] and IKEv2 Mobility and Multihoming Protocol 117 (MOBIKE) [RFC4555]. 119 Figure 1 illustrates the scopes of the above different categories. 121 +----------------+ +----------------+ 122 | Network-based | | Host-based | 123 |+--------------+| |+--------------+| 124 ||PMIPv6 suite || ||MIPv6 suite || 125 ||+------------+|| ||+------------+|| 126 |||PMIPv6 ||| |||MIPv6 ||| 127 ||+------------+|| ||+------------+|| 128 |+--------------+| |+--------------+| 129 +----------------+ +----------------+ 131 Figure 1: Scopes of different protocol categories 133 In deployment, the host-based protocols and network-based protocols 134 will be co-existing and multiple protocol deamons will be configured 135 on the network entities or host. There is then a gap in how to 136 determine which protocol to use. A scheme is therefore needed to 137 support the negotiation and selection of mobility management protocol 138 when the host initially attaches or hands over to a new network 139 [Paper-CombiningMobilityStandards]. 141 This document tries to present the principles for the protocol 142 selection and analyze the possible scenarios which should be 143 supported by the subsequent mobility solution. 145 2. Motivations 147 As illustrated above, these protocols may co-exist in practice and 148 may simultaneously be used in an access network or even the same 149 entity. Due to their different requirements on the network entity or 150 host, a scheme is needed to support the negotiation and selection of 151 adopted mobility management protocol when the host accesses to a new 152 network. Generally, two problems should be solved: 154 o What principles should be followed for the protocol negotiation 155 and selection? 156 o What procedure should be adopted for the protocol negotiation and 157 selection? 159 This scheme is needed because the network entity and the host may 160 have different capabilities and preferences (may be decided by the 161 capability and mobility pattern of the host). This scheme aims to 162 guarantee that the optimum and most suitable protocol will be used. 164 3. Possible Cases 166 From both host and network aspects, there are multiple cases in their 167 capacities of mobility management as shown in Figure 2. We mainly 168 analyze the cases where that host and network support a single 169 protocol. If multiple protocols are supported simultaneously by the 170 host or network side, multiple cases exist at the same time but the 171 logic is the same as that in the case with single protocol supported. 172 Specifically, the following cases should be considered. 174 1) Network supports network-based protocol, host supports network- 175 based protocol 177 In this case, there are the following sub-cases: 179 a) Host supports PMIPv6 suite protocol, Network supports PMIPv6 suite 180 protocol 182 o if host supports PMIPv6 and network supports PMIPv6, PMIPv6 will 183 be selected. 184 o if host supports PMIPv6 and network supports extended PMIPv6 185 protocol, extended PMIPv6 is selected if no host involvement is 186 needed, otherwise the plain PMIPv6 is selected (we assume that the 187 extension protocols are backward-compatible with the related plain 188 protocol). 189 o if host supports extended PMIPv6 protocol and network supports 190 PMIPv6, PMIPv6 is selected (we assume that the extension protocols 191 are backward-compatible with the related plain protocol). 193 o if host supports extended PMIPv6 protocol and network supports 194 extended PMIPv6 protocol, the identical extension protocol is 195 selected, otherwise, the plain PMIPv6 is selected (we assume that 196 the extension protocols are backward-compatible with the related 197 plain protocol). 199 +----------------+-------------+--------------------------------+ 200 | | |PMIPv6 | 201 | | |-------------------+------------+ 202 | Network-based | PMIPv6 suite| | DS-PMIPv6 | 203 | | | +------------+ 204 | | |PMIPv6 extensions | FPMIPv6 | 205 | | | +------------+ 206 | | | | DMM-PMIPv6 | 207 | | | +------------+ 208 | | | | ... | 209 | |-------------+-------------------+------------+ 210 | | Others |GTP | 211 | | |--------------------------------+ 212 | | |... | 213 +----------------+-------------+--------------------------------+ 214 | | |MIPv6 | 215 | | |-------------------+------------+ 216 | Host-based | MIPv6 suite | | DS-MIPv6 | 217 | | | +------------+ 218 | | | | FMIPv6 | 219 | | | +------------+ 220 | | |MIPv6 extensions | HMIPv6 | 221 | | | +------------+ 222 | | | | NEMO | 223 | | | +------------+ 224 | | | | DMM-MIPv6 | 225 | | | +------------+ 226 | | | | ... | 227 | |-------------+-------------------+------------+ 228 | | Others |HIP | 229 | | |--------------------------------+ 230 | | |MOBIKE | 231 | | |--------------------------------+ 232 | | |... | 233 +----------------+-------------+--------------------------------+ 235 Figure 2: Possible capacities of mobility support by the host and 236 network 238 b) Host supports PMIPv6 suite protocol, Network supports other 239 network-based protocol 240 o if host supports PMIPv6 and network supports other network-based 241 protocol, other network-based protocol is selected if no host 242 involvement is needed, otherwise failure. 243 o if host supports extended PMIPv6 protocol and network supports 244 other network-based protocol, other network-based protocol is 245 selected if no host involvement is needed, otherwise failure. 247 c) Host supports other network-based protocol, Network supports 248 PMIPv6 suite protocol 250 o if host supports other network-based protocol and network supports 251 PMIPv6, PMIPv6 is selected. 252 o if host supports other network-based protocol and network supports 253 extended PMIPv6 protocol, extended PMIPv6 protocol is selected if 254 no host involvement is needed, otherwise failure. 256 d) Host supports other network-based protocol, Network supports other 257 network-based protocol 259 o the identical protocol is selected, otherwise follow network 260 ability if the protocols are different. 262 2) Network supports network-based protocol, host supports host-based 263 protocol 265 In this case, there are the following sub-cases: 267 a) Host supports PMIPv6 suite protocol, Network supports MIPv6 suite 268 protocol 270 o if host supports PMIPv6 and network supports MIPv6, failure. 271 o if host supports PMIPv6 and network supports extended MIPv6 272 protocol, failure. 273 o if host supports extended PMIPv6 protocol and network supports 274 MIPv6, failure. 275 o if host supports extended PMIPv6 protocol and network supports 276 extended MIPv6 protocols, failure. 278 b) Host supports PMIPv6 suite protocol, Network supports other host- 279 based protocol 281 o if host supports PMIPv6 and network supports other host-based 282 protocol, failure. 283 o if host supports extended PMIPv6 protocol and network supports 284 other host-based protocol, failure. 286 c) Host supports other network-based protocol, Network supports MIPv6 287 suite protocol 288 o if host supports other network-based protocol and network supports 289 MIPv6, failure. 290 o if host supports other network-based protocol and network supports 291 extended MIPv6 protocol, failure. 293 d) Host supports other network-based protocol, Network supports other 294 host-based protocol 296 o failure. 298 3) Network supports host-based protocol, host supports network-based 299 protocol 301 In this case, there are the following sub-cases: 303 a) Host supports MIPv6 suite protocol, Network supports PMIPv6 suite 304 protocol 306 o if host supports MIPv6 and network supports PMIPv6, PMIPv6 is 307 selected in default and MIPv6 is selected if host prefers it. 308 o if host supports MIPv6 and network supports extended PMIPv6 309 protocol, extended PMIPv6 is selected in default, then PMIPv6 is 310 selected with the lower priority and MIPv6 is selected if host 311 prefers it. 312 o if host supports extended MIPv6 protocol and network supports 313 PMIPv6, PMIPv6 will be selected in default, then extended MIPv6 is 314 selected if host prefers it and network also supports, otherwise 315 MIPv6 is selected with the lowest priority. 316 o if host supports extended MIPv6 protocol and network supports 317 extended PMIPv6 protocol, extended PMIPv6 is selected in default, 318 then PMIPv6 is selected, then extended MIPv6 is selected if host 319 prefers and network also supports, otherwise MIPv6 is selected 320 with the lowest priority. 322 b) Host supports MIPv6 suite protocol, Network supports other 323 network-based protocol 325 o if host supports MIPv6 and network supports other network-based 326 protocol, other network-based protocol is selected if no host 327 involvement is needed, otherwise failure. 328 o if host supports extended MIPv6 protocol and network supports 329 other network-based protocol, other network-based protocol is 330 selected if no host involvement is needed, otherwise failure. 332 c) Host supports other host-based protocol, Network supports PMIPv6 333 suite protocol 334 o if host supports other host-based protocol and network supports 335 PMIPv6, PMIPv6 is selected in default, otherwise failure. 336 o if host supports other host-based protocol and network supports 337 extended PMIPv6 protocol, extended PMIPv6 protocol is selected if 338 no host involvement is needed, otherwise failure. 340 d) Host supports other host-based protocol, Network supports other 341 network-based protocol 343 o other network-based protocol is selected if no host involvement is 344 needed, otherwise failure. 346 4) Network supports host-based protocol, host supports host-based 347 protocol 349 In this case, there are the following sub-cases: 351 a) Host supports MIPv6 suite protocol, Network supports MIPv6 suite 352 protocol 354 o if host supports MIPv6 and network supports MIPv6, MIPv6 is 355 selected. 356 o if host supports MIPv6 and network supports extended MIPv6 357 protocol, MIPv6 is selected. 358 o if host supports extended MIPv6 protocol and network supports 359 MIPv6, MIPv6 is selected. 360 o if host supports extended MIPv6 protocol and network supports 361 extended MIPv6 protocols, the identical protocol is selected, 362 otherwise MIPv6 is selected. 364 b) Host supports MIPv6 suite protocol, Network supports other host- 365 based protocol 367 o if host supports MIPv6 and network supports other host-based 368 protocol, failure. 369 o if host supports extended MIPv6 protocol and network supports 370 other host-based protocol, failure. 372 c) Host supports other host-based protocol, Network supports MIPv6 373 suite protocol 375 o if host supports other host-based protocol and network supports 376 MIPv6, failure. 377 o if host supports other host-based protocol and network supports 378 extended MIPv6 protocol, failure. 380 d) Host supports other host-based protocol, Network supports other 381 host-based protocol 382 o the identical other host-based protocol is selected, otherwise 383 failure. 385 5) Network supports host-based protocol and network-based protocol, 386 host supports host-based protocol and network-based protocol 388 o follow the network based protocol in default if the host can 389 support, otherwise select the protocol both network and host can 390 support if host prefers. 392 4. Principles and Possible Procedure 394 Two different schemes may be used for the protocol negotiation and 395 selection: host-initiated and network-initiated. Within the MIP/PMIP 396 protocols, the priority of the function-extension protocols should be 397 higher than the performance-enhancement protocols. Generally, the 398 following principles should be followed: 400 o Priority 1: Follow network ability 401 o Priority 2: Follow host preference 402 o Priority 3: Support the functional extensions 403 o Priority 4: Support the performance enhancements 404 o In default: network based scheme if it can be supported 406 And the general procedure for the protocol selection should be: 408 o During initiation, network-based protocol may be used as a default 409 mobility management protocol once the network supports it. 410 o If the host prefers host-based protocols, a negotiation is 411 executed to handover from network-based protocol to host-based 412 protocol. 413 o After initial attachment, a profile will be generated in the 414 management store to record the selected or preferred protocol of 415 this host. 416 o When the handover happens, the network will check the selected or 417 preferred protocol during the authentication process. But the 418 network also needs to notify the host if the selected protocol 419 cannot be supported herein. 421 5. Extensions 423 In order to fulfill the above principles, some extensions should be 424 supported, for example: 426 1) Extended negotiation messages 428 The protocol negotiation may be included in the MN_ATTACH Function 429 [MN-AR.IF] and the implementation may be based on a new signaling 430 message or extended messages (e.g., ICMPv6, Diameter, and RADIUS). 431 Besides these, some other protocols may also be used in some 432 specified scenarios, such as extended IEEE 802.21 primitives. 434 2) Extended management store 436 When the host accesses the network, authentication should be executed 437 before the mobility management service is provided. In order to 438 support the mobility management protocol selection, a new information 439 should be recorded by the network after the successful authentication 440 during the initial attachment. The newly introduced information 441 shows the selected mobility management protocol and should be updated 442 when the used protocol changes. 444 6. Security Considerations 446 Generally, this function will not incur additional security issues. 447 The detailed influence should be analyzed in the future. 449 7. IANA Considerations 451 A new ICMP option or authentication option or other signaling message 452 may be used with a new code number. 454 8. References 456 8.1. Normative References 458 [MN-AR.IF] 459 Laganier, J., Narayanan, S., and P. McCann, "Interface 460 between a Proxy MIPv6 Mobility Access Gateway and a Mobile 461 Node", draft-ietf-netlmm-mn-ar-if-03, February 2008. 463 [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 464 Thubert, "Network Mobility (NEMO) Basic Support Protocol", 465 RFC 3963, DOI 10.17487/RFC3963, January 2005, 466 . 468 [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol 469 (MOBIKE)", RFC 4555, DOI 10.17487/RFC4555, June 2006, 470 . 472 [RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., 473 Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", 474 RFC 5213, DOI 10.17487/RFC5213, August 2008, 475 . 477 [RFC5268] Koodli, R., Ed., "Mobile IPv6 Fast Handovers", RFC 5268, 478 DOI 10.17487/RFC5268, June 2008, 479 . 481 [RFC5380] Soliman, H., Castelluccia, C., ElMalki, K., and L. 482 Bellier, "Hierarchical Mobile IPv6 (HMIPv6) Mobility 483 Management", RFC 5380, DOI 10.17487/RFC5380, October 2008, 484 . 486 [RFC5555] Soliman, H., Ed., "Mobile IPv6 Support for Dual Stack 487 Hosts and Routers", RFC 5555, DOI 10.17487/RFC5555, June 488 2009, . 490 [RFC5648] Wakikawa, R., Ed., Devarapalli, V., Tsirtsis, G., Ernst, 491 T., and K. Nagami, "Multiple Care-of Addresses 492 Registration", RFC 5648, DOI 10.17487/RFC5648, October 493 2009, . 495 [RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy 496 Mobile IPv6", RFC 5844, DOI 10.17487/RFC5844, May 2010, 497 . 499 [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility 500 Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 501 2011, . 503 [RFC7333] Chan, H., Ed., Liu, D., Seite, P., Yokota, H., and J. 504 Korhonen, "Requirements for Distributed Mobility 505 Management", RFC 7333, DOI 10.17487/RFC7333, August 2014, 506 . 508 [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. 509 Henderson, "Host Identity Protocol Version 2 (HIPv2)", 510 RFC 7401, DOI 10.17487/RFC7401, April 2015, 511 . 513 [TS.29274] 514 "3GPP Evolved Packet System (EPS); Evolved General Packet 515 Radio Service (GPRS) Tunnelling Protocol for Control plane 516 (GTPv2-C); Stage 3", 3GPP TS 29.274 8.10.0, June 2011. 518 [TS.29281] 519 "General Packet Radio System (GPRS) Tunnelling Protocol 520 User Plane (GTPv1-U)", 3GPP TS 29.281 10.3.0, September 521 2011. 523 8.2. Informative References 525 [Paper-CombiningMobilityStandards] 526 Oliva, A., Soto, I., Calderon, M., Bernardos, C., and M. 527 Sanchez, "The costs and benefits of combining different IP 528 mobility standards", Computer Standards and Interfaces, 529 February 2013. 531 Authors' Addresses 533 Zhiwei Yan 534 CNNIC 535 No.4 South 4th Street, Zhongguancun 536 Beijing 100190 537 China 539 Email: yan@cnnic.cn 541 Guanggang Geng 542 CNNIC 543 No.4 South 4th Street, Zhongguancun 544 Beijing 100190 545 China 547 Email: ggg@cnnic.cn 549 Jong-Hyouk Lee 550 Sangmyung University 551 31, Sangmyeongdae-gil, Dongnam-gu 552 Cheonan 553 Republic of Korea 555 Email: jonghyouk@smu.ac.kr 557 H. Anthony Chan 558 Huawei Technologies 559 5340 Legacy Dr. Building 3 560 Plano, TX 75024 561 USA 563 Email: h.a.chan@ieee.org