idnits 2.17.1 draft-yan-dmm-man-06.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 (March 23, 2020) is 1495 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5268 (Obsoleted by RFC 5568) Summary: 1 error (**), 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: Informational CNNIC 5 Expires: September 24, 2020 J. Lee 6 Sangmyung University 7 T. Huang 8 BUPT 9 March 23, 2020 11 Mobility Capability Negotiation and Protocol Selection 12 draft-yan-dmm-man-06 14 Abstract 16 Based on different requirements, multiple mobility management 17 protocols have been developed. Different protocols have different 18 functional requirements on the network element or the host and then a 19 scheme should be used in order to support the negotiation and 20 selection of adopted mobility management protocol when a host 21 accesses to a new network. In this draft, this issue is analyzed. 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 September 24, 2020. 40 Copyright Notice 42 Copyright (c) 2020 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. Protocol Selection Principles . . . . . . . . . . . . . . . . 9 61 5. General Procedure . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . 11 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 69 1. Introduction 71 In order to clearly analyze the possible cases and actual 72 requirement, the following category labels of the mobility management 73 protocols are defined: 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 suit protocols: based on MIPv6, there are multiple extension 80 protocols have been standardized. These protocols can be 81 classified into two types: protocols for the function extension 82 and protocols for the performance enhancement. The protocols for 83 the function 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 the performance of the 89 mobility management, such as Fast Mobile IPv6 (FMIP6) [RFC5268] 90 for fast handover, Hierarchical Mobile IPv6 (HMIPv6) [RFC5380] for 91 hierarchical mobility optimization. In the MIPv6 suit protocols, 92 location update is initiated by the host and the tunnel is also 93 terminated at the host. 94 o PMIPv6 suit 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 basis. 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]. Be different from the MIPv6 101 suit protocols, the location update in PMIPv6 suit protocols is 102 triggered by the network entity and the tunnel is established 103 between network entities. Then the host needs to do nothing about 104 the signaling exchange during the movement, particularly, the 105 mobility is transparent to the IP layer of the host. 106 o Network-based protocols: generally, it means the mobility 107 management protocols which do not require the involvement of the 108 mobile node in order to accomplish mobility. It includes PMIPv6 109 suit protocols and other network-based solutions, such as GPRS 110 Tunnelling Protocol (GTP) [TS.29274][TS.29281]. 111 o Host-based protocols: generally, the mobility management protocols 112 which require the involvement of the mobile node in order to 113 accomplish mobility. It includes MIPv6 suit protocols and other 114 host-based solutions, such as Host Identity Protocol (HIP) 115 [RFC7401] and IKEv2 Mobility and Multihoming Protocol (MOBIKE) 116 [RFC4555]. 118 Figure 1 illustrates the scopes of the above different category 119 labels. 121 +----------------+ +----------------+ 122 | Network-based | | Host-based | 123 |+--------------+| |+--------------+| 124 ||PMIPv6 suit || ||MIPv6 suit || 125 ||+------------+|| ||+------------+|| 126 |||PMIPv6 ||| |||MIPv6 ||| 127 ||+------------+|| ||+------------+|| 128 |+--------------+| |+--------------+| 129 +----------------+ +----------------+ 131 Figure 1: Scopes of different protocol category labels 133 In reality, the host-based protocols and network-based protocols will 134 be co-existing and multiple protocol deamons will be configured on 135 the network entities and host. That means a scheme is needed to 136 support the negotiation and selection of mobility management protocol 137 when the host accesses into a new access network initially or 138 handover happens [Paper-CombiningMobilityStandards]. 140 This document tries to present the principles for the protocol 141 selection and analyze the possible scenarios which should be 142 supported by the further solution. 144 2. Motivations 146 As illustrated above, these protocols may co-exist in reality and 147 simultaneously be used in an access network or even the same entity. 148 Due to their different requirements on the network entity or host, a 149 scheme is needed to support the negotiation and selection of adopted 150 mobility management protocol when the host accesses to a new network. 151 Generally, two problems should be solved: 153 o What principles should be followed for the protocol negotiation 154 and selection? 155 o What procedure should be adopted for the protocol negotiation and 156 selection? 158 This scheme is needed because network entity and host may have 159 different capabilities and preferences (may be decided by the 160 capability and mobility pattern of the host). This scheme aims to 161 guarantee that the optimum and most suitable protocol will be used, 162 although the selection procedure and notification scheme can be 163 implementation-dependent. 165 3. Possible Cases 167 From both host and network aspects, their capabilities of mobility 168 management may have multiple cases as shown in Figure 2. We mainly 169 analyze that host and network support single protocol for clear 170 description, if multiple protocols are supported simultaneously by 171 the host or network side, multiple cases exist at the same time but 172 the logic is same as that in the case with single protocol supported. 173 Specifically, the following cases should be considered. 175 1) Network supports network-based protocol, host supports network- 176 based protocol 178 In this case, there are the following sub-cases: 180 a) Host supports PMIPv6 suit protocol, Network supports PMIPv6 suit 181 protocol 183 o if host supports PMIPv6 and network supports PMIPv6, PMIPv6 is 184 selected. 185 o if host supports PMIPv6 and network supports extended PMIPv6 186 protocol, extended PMIPv6 protocol is selected if no host 187 involvement is needed, otherwise the plain PMIPv6 is selected (we 188 assume that the extension protocols are backward-compatible with 189 the related plain protocol). 191 o if host supports extended PMIPv6 protocol and network supports 192 PMIPv6, PMIPv6 is selected (we assume that the extension protocols 193 are backward-compatible with the related plain protocol). 194 o if host supports extended PMIPv6 protocol and network supports 195 extended PMIPv6 protocol, the identical extension protocol is 196 selected, otherwise, PMIPv6 is selected (we assume that the 197 extension protocols are backward-compatible with the related plain 198 protocol). 200 +-------------+-----------+--------------------------- + 201 | | |PMIPv6 | 202 | | |-----------------+----------+ 203 |Network-based|PMIPv6 suit| |DS-PMIPv6 | 204 | | | +----------+ 205 | | |PMIPv6 extensions|FPMIPv6 | 206 | | | +----------+ 207 | | | |DMM-PMIPv6| 208 | | | +----------+ 209 | | | |... | 210 | |-----------+-----------------+----------+ 211 | | Others |GTP | 212 | | |----------------------------+ 213 | | |... | 214 +-------------+-----------+----------------------------+ 215 | | |MIPv6 | 216 | | |-----------------+----------+ 217 |Host-based |MIPv6 suit | |DS-MIPv6 | 218 | | | +----------+ 219 | | | |FMIPv6 | 220 | | | +----------+ 221 | | |MIPv6 extensions |HMIPv6 | 222 | | | +----------+ 223 | | | |NEMO | 224 | | | +----------+ 225 | | | |DMM-MIPv6 | 226 | | | +----------+ 227 | | | |... | 228 | |-----------+-----------------+----------+ 229 | | Others |HIP | 230 | | |----------------------------+ 231 | | |MOBIKE | 232 | | |----------------------------+ 233 | | |... | 234 +-------------+-----------+----------------------------+ 236 Figure 2: Possible capacities of host and network 238 b) Host supports PMIPv6 suit protocol, Network supports other 239 network-based protocol 241 o if host supports PMIPv6 and network supports other network-based 242 protocol, other network-based protocol is selected if no host 243 involvement is needed, otherwise failure. 244 o if host supports extended PMIPv6 protocol and network supports 245 other network-based protocol, other network-based protocol is 246 selected if no host involvement is needed, otherwise failure. 248 c) Host supports other network-based protocol, Network supports 249 PMIPv6 suit protocol 251 o if host supports other network-based protocol and network supports 252 PMIPv6, PMIPv6 is selected. 253 o if host supports other network-based protocol and network supports 254 extended PMIPv6 protocol, extended PMIPv6 protocol is selected if 255 no host involvement is needed, otherwise failure. 257 d) Host supports other network-based protocol, Network supports other 258 network-based protocol 260 o the identical protocol is selected, otherwise follow network 261 capability if the protocols are different. 263 2) Network supports network-based protocol, host supports host-based 264 protocol 266 In this case, there are the following sub-cases: 268 a) Host supports PMIPv6 suit protocol, Network supports MIPv6 suit 269 protocol 271 o if host supports PMIPv6 and network supports MIPv6, failure. 272 o if host supports PMIPv6 and network supports extended MIPv6 273 protocol, failure. 274 o if host supports extended PMIPv6 protocol and network supports 275 MIPv6, failure. 276 o if host supports extended PMIPv6 protocol and network supports 277 extended MIPv6 protocol, failure. 279 b) Host supports PMIPv6 suit protocol, Network supports other host- 280 based protocol 282 o if host supports PMIPv6 and network supports other host-based 283 protocol, failure. 284 o if host supports extended PMIPv6 protocol and network supports 285 other host-based protocol, failure. 287 c) Host supports other network-based protocol, Network supports MIPv6 288 suit protocol 290 o if host supports other network-based protocol and network supports 291 MIPv6, failure. 292 o if host supports other network-based protocol and network supports 293 extended MIPv6 protocol, failure. 295 d) Host supports other network-based protocol, Network supports other 296 host-based protocol 298 o failure. 300 3) Network supports host-based protocol, host supports network-based 301 protocol 303 In this case, there are the following sub-cases: 305 a) Host supports MIPv6 suit protocol, Network supports PMIPv6 suit 306 protocol 308 o if host supports MIPv6 and network supports PMIPv6, PMIPv6 is 309 selected in default and MIPv6 is selected if host prefers it. 310 o if host supports MIPv6 and network supports extended PMIPv6 311 protocol, extended PMIPv6 is selected in default, then PMIPv6 is 312 selected with the lower priority and MIPv6 is selected if host 313 prefers it. 314 o if host supports extended MIPv6 protocol and network supports 315 PMIPv6, PMIPv6 is selected in default, then extended MIPv6 316 protocol is selected if host prefers it and network also supports, 317 otherwise MIPv6 is selected with the lowest priority. 318 o if host supports extended MIPv6 protocol and network supports 319 extended PMIPv6 protocol, extended PMIPv6 protocol is selected in 320 default, then PMIPv6 is selected, then extended MIPv6 protocol is 321 selected if host prefers and network also supports, otherwise 322 MIPv6 is selected with the lowest priority. 324 b) Host supports MIPv6 suit protocol, Network supports other network- 325 based protocol 327 o if host supports MIPv6 and network supports other network-based 328 protocol, other network-based protocol is selected if no host 329 involvement is needed, otherwise failure. 330 o if host supports extended MIPv6 protocol and network supports 331 other network-based protocol, other network-based protocol is 332 selected if no host involvement is needed, otherwise failure. 334 c) Host supports other host-based protocol, Network supports PMIPv6 335 suit protocol 337 o if host supports other host-based protocol and network supports 338 PMIPv6, PMIPv6 is selected in default, otherwise failure. 339 o if host supports other host-based protocol and network supports 340 extended PMIPv6 protocol, extended PMIPv6 protocol is selected if 341 no host involvement is needed, otherwise failure. 343 d) Host supports other host-based protocol, Network supports other 344 network-based protocol 346 o other network-based protocol is selected if no host involvement is 347 needed, otherwise failure. 349 4) Network supports host-based protocol, host supports host-based 350 protocol 352 In this case, there are the following sub-cases: 354 a) Host supports MIPv6 suit protocol, Network supports MIPv6 suit 355 protocol 357 o if host supports MIPv6 and network supports MIPv6, MIPv6 is 358 selected. 359 o if host supports MIPv6 and network supports extended MIPv6 360 protocol, MIPv6 is selected. 361 o if host supports extended MIPv6 protocol and network supports 362 MIPv6, MIPv6 is selected. 363 o if host supports extended MIPv6 protocol and network supports 364 extended MIPv6 protocol, the identical protocol is selected, 365 otherwise MIPv6 is selected. 367 b) Host supports MIPv6 suit protocol, Network supports other host- 368 based protocol 370 o if host supports MIPv6 and network supports other host-based 371 protocol, failure. 372 o if host supports extended MIPv6 protocol and network supports 373 other host-based protocol, failure. 375 c) Host supports other host-based protocol, Network supports MIPv6 376 suit protocol 378 o if host supports other host-based protocol and network supports 379 MIPv6, failure. 380 o if host supports other host-based protocol and network supports 381 extended MIPv6 protocol, failure. 383 d) Host supports other host-based protocol, Network supports other 384 host-based protocol 386 o the identical other host-based protocol is selected, otherwise 387 failure. 389 5) Network supports host-based protocol and network-based protocol, 390 host supports host-based protocol and network-based protocol 392 o follow the network based protocol in default if the host can 393 support, otherwise select the protocol both network and host can 394 support if host prefers. 396 4. Protocol Selection Principles 398 Two different schemes may be used for the protocol negotiation and 399 selection: host-initiated and network-initiated. Within the MIPv6/ 400 PMIPv6 protocols, the priority of the function-extension protocols 401 should be higher than the performance-enhancement protocols. 402 Generally, the following principles should be followed: 404 o In default: Network based scheme if it can be supported 405 o Priority 1: Follow network capability 406 o Priority 2: Follow host preference 407 o Priority 3: Support the functional extensions 408 o Priority 4: Support the performance enhancements 410 5. General Procedure 412 The protocol negotiation may be included in the MN_ATTACH Function 413 [MN-AR.IF] and the implementation may be based on a new signaling 414 message or extended messages (e.g., ICMPv6, Diameter, and RADIUS). 415 Besides these, some other protocols may also be used in some 416 specified scenarios, such as extended IEEE 802.21 primitives. 418 The general procedure for the protocol selection should be: 420 o During initiation, network-based protocol may be used as a default 421 mobility management protocol once the network supports it. 422 o If the host prefers host-based protocols, a negotiation is 423 executed to handover from network-based protocol to host-based 424 protocol. 425 o After initial attachment, a profile will be generated in the 426 management store to record the selected or preferred protocol of 427 this host. 428 o When the handover happens, the network will check the selected or 429 preferred protocol during the authentication process. But the 430 network also needs to notify the host if the selected protocol 431 cannot be supported herein. 433 When the host accesses to the network, an authentication should be 434 executed before the mobility management service is provided. In 435 order to support the mobility management protocol selection, a new 436 information should be recorded by the network after the successful 437 authentication during the initial attachment. The newly introduced 438 information shows the selected mobility management protocol and 439 should be updated when the used protocol changes. 441 6. Security Considerations 443 Generally, this function will not incur additional security issues. 444 The detailed influence should be analyzed in the future. 446 7. IANA Considerations 448 A new authentication option or other signaling message option may be 449 used based on the specific implementation. 451 8. References 453 8.1. Normative References 455 [MN-AR.IF] 456 Laganier, J., Narayanan, S., and P. McCann, "Interface 457 between a Proxy MIPv6 Mobility Access Gateway and a Mobile 458 Node", draft-ietf-netlmm-mn-ar-if-03, February 2008. 460 [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 461 Thubert, "Network Mobility (NEMO) Basic Support Protocol", 462 RFC 3963, DOI 10.17487/RFC3963, January 2005, 463 . 465 [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol 466 (MOBIKE)", RFC 4555, DOI 10.17487/RFC4555, June 2006, 467 . 469 [RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., 470 Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", 471 RFC 5213, DOI 10.17487/RFC5213, August 2008, 472 . 474 [RFC5268] Koodli, R., Ed., "Mobile IPv6 Fast Handovers", RFC 5268, 475 DOI 10.17487/RFC5268, June 2008, 476 . 478 [RFC5380] Soliman, H., Castelluccia, C., ElMalki, K., and L. 479 Bellier, "Hierarchical Mobile IPv6 (HMIPv6) Mobility 480 Management", RFC 5380, DOI 10.17487/RFC5380, October 2008, 481 . 483 [RFC5555] Soliman, H., Ed., "Mobile IPv6 Support for Dual Stack 484 Hosts and Routers", RFC 5555, DOI 10.17487/RFC5555, June 485 2009, . 487 [RFC5648] Wakikawa, R., Ed., Devarapalli, V., Tsirtsis, G., Ernst, 488 T., and K. Nagami, "Multiple Care-of Addresses 489 Registration", RFC 5648, DOI 10.17487/RFC5648, October 490 2009, . 492 [RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy 493 Mobile IPv6", RFC 5844, DOI 10.17487/RFC5844, May 2010, 494 . 496 [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility 497 Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 498 2011, . 500 [RFC7333] Chan, H., Ed., Liu, D., Seite, P., Yokota, H., and J. 501 Korhonen, "Requirements for Distributed Mobility 502 Management", RFC 7333, DOI 10.17487/RFC7333, August 2014, 503 . 505 [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. 506 Henderson, "Host Identity Protocol Version 2 (HIPv2)", 507 RFC 7401, DOI 10.17487/RFC7401, April 2015, 508 . 510 [TS.29274] 511 "3GPP Evolved Packet System (EPS); Evolved General Packet 512 Radio Service (GPRS) Tunnelling Protocol for Control plane 513 (GTPv2-C); Stage 3", 3GPP TS 29.274 8.10.0, June 2011. 515 [TS.29281] 516 "General Packet Radio System (GPRS) Tunnelling Protocol 517 User Plane (GTPv1-U)", 3GPP TS 29.281 10.3.0, September 518 2011. 520 8.2. Informative References 522 [Paper-CombiningMobilityStandards] 523 Oliva, A., Soto, I., Calderon, M., Bernardos, C., and M. 524 Sanchez, "The costs and benefits of combining different IP 525 mobility standards", Computer Standards and Interfaces, 526 February 2013. 528 Authors' Addresses 530 Zhiwei Yan 531 CNNIC 532 No.4 South 4th Street, Zhongguancun 533 Beijing 100190 534 China 536 Email: yan@cnnic.cn 538 Guanggang Geng 539 CNNIC 540 No.4 South 4th Street, Zhongguancun 541 Beijing 100190 542 China 544 Email: ggg@cnnic.cn 546 Jong-Hyouk Lee 547 Sangmyung University 548 31, Sangmyeongdae-gil, Dongnam-gu 549 Cheonan 550 Republic of Korea 552 Email: jonghyouk@smu.ac.kr 554 Tao Huang 555 BUPT 556 No.10 Xitucheng Road, Haidian District 557 Beijing 100876 558 China 560 Email: htao@bupt.edu.cn