idnits 2.17.1 draft-yan-dmm-man-01.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 (June 20, 2017) is 2496 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 CNNIC 4 Intended status: Standards Track J. Lee 5 Expires: December 22, 2017 Sangmyung University 6 H. Chan 7 Huawei Technologies 8 June 20, 2017 10 Mobility Capability Negotiation and Protocol Selection 11 draft-yan-dmm-man-01 13 Abstract 15 Based on IPv6, multiple mobility management protocols have been 16 developed and generally they can be classified into two types: 17 network-based and host-based. Different protocols have different 18 functional requirements on the network element or the terminal and 19 then a scheme should be used in order to support the negotiation and 20 selection of adopted mobility management protocol when a terminal 21 accesses to a new network. In this draft, this issue is considered 22 and analyzed. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on December 22, 2017. 41 Copyright Notice 43 Copyright (c) 2017 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 4. Principles and possible solution . . . . . . . . . . . . . . 4 62 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 63 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 64 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 66 7.2. Informative References . . . . . . . . . . . . . . . . . 7 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 69 1. Introduction 71 Based on Mobile IPv6 (MIPv6) [RFC6275], there are multiple extension 72 protocols have been standardized. These protocols can be classified 73 into two categories: protocols for the function extension and 74 protocols for the performance enhancement. The protocols for the 75 function extension are proposed to support some specific scenarios or 76 functions, such as Dual-stack Mobile IPv6 (DSMIPv6) [RFC5555] for 77 mobility of the dual-stack nodes, Multiple Care-of-address (MCoA) 78 [RFC5648] for mobile nodes with multiple access interfaces and 79 Network Mobility (NEMO) [RFC3963] for mobility of sub-network. The 80 other category is proposed to enhance the performance of the mobility 81 management, such as Fast Mobile IPv6 (FMIP6) [RFC5268] for fast 82 handover, Hierarchical Mobile IPv6 (HMIPv6) [RFC5380] for 83 hierarchical mobility optimization. MIPv6 and these extensions are 84 classified in the host-based mobility management protocol suite 85 because the location update is initiated by the terminal and the 86 tunnel is also terminated at the terminal. 88 In order to reduce the protocol cost and enhance the handover 89 performance further, the network-based mobility management protocols 90 were proposed and Proxy Mobile IPv6 (PMIPv6) [RFC5213] was 91 standardized as a basis. Based on PMIPv6, a series of its extensions 92 were proposed, such as Dual-stack Proxy Mobile IPv6 (DS-PMIPv6) 93 [RFC5844], Distributed Mobility Management Proxy Mobile IPv6 (DMM- 94 PMIPv6) [RFC7333] as the network-based mobility management protocol 95 suite. Be different from the host-based suite, the location update 96 in network-based suite is triggered by the network entity and the 97 tunnel is established between network entities. Then the terminal 98 needs to do nothing about the signaling exchange during the movement, 99 particularly, the mobility is transparent to the IP layer of the 100 terminal. 102 In reality, these protocols will be co-existing and multiple protocol 103 daemons will be configured on the network entities or terminal. That 104 means a scheme is needed to support the negotiation and selection of 105 mobility management protocol when the terminal accesses into a new 106 access network initially or handover happens 107 [Paper-CombiningMobilityStandards]. 109 This document tries to present the principles for the protocol 110 selection and analyze the possible scenarios which should be 111 supported by the further solution. 113 2. Motivations 115 As illustrated above, these protocols may co-exist in reality and 116 simultaneously be used in an access network or even the same entity. 117 Due to their different requirements on the network entity or 118 terminal, a scheme is needed to support the negotiation and selection 119 of adopted mobility management protocol when the terminal accesses to 120 a new network. 122 Generally, two problems should be solved: 124 o What principles should be followed for the protocol negotiation 125 and selection? 126 o What procedure shoud be adopted for the protocol negotiation and 127 selection? 129 This scheme is needed because different entity and terminal will have 130 different capabilities and preferences (may be decided by the 131 capability and mobility pattern of the mobile node). This scheme can 132 guarantee that the optimum and most suitable protocol will be used. 134 3. Scenarios 136 In order to illustrate the necessity of the mobility capability 137 negotiation and protocol selection, the following scenarios are taken 138 as typical examples: 140 1) Network supports MIPv6, host supports only PMIPv6 142 In this case, the network supports only host-based protocol, while 143 the host does not have any mobility management function. Then only 144 the PMIPv6 can be used to support the mobility management of the 145 host, but the network does not deploy the PMIPv6 protocol and this 146 will cause the mobility failure because no available protocol can be 147 used. 149 2) Network supports both MIPv6 and PMIPv6, host supports only PMIPv6 151 In this case, the network deploys both host-based and network-based 152 protocols, while the host supports only PMIPv6. When the host 153 accesses to the network, PMIPv6 will be used. Actually, PMIPv6 154 should be adopted as a default mobility management scheme considering 155 its optimized performance. Once the PMIPv6 can be supported by the 156 network, it will be adopted as the default one. 158 3) Network supports both MIPv6 and PMIPv6, host supports MIPv6 160 In this case, the network deploys both host-based and network-based 161 protocols, and the host also supports MIPv6. Because PMIPv6 has no 162 requirement on the host, both PMIPv6 and MIPv6 can be used in this 163 case. Then the host can use PMIPv6 as default, and use MIPv6 for the 164 global mobility. 166 4) Network and host support multiple extension protocols 168 In this case, the network has deployed multiple extensions to support 169 more complex requirements, so does the host. And then the host and 170 network can negotiate a protocol for the optimized performance or 171 other special requirement, for example, FMIPv6 may be selected in 172 order to support fast handover, HMIPv6 may be selected in order to 173 reduce the signaling cost, NEMO may be selected in order to support 174 the subnet mobility. 176 However, there are more complex scenarios considering the different 177 abilities of network entities and terminal. 179 4. Principles and possible solution 181 Two different schemes may be used for the protocol negotiation and 182 selection: MN-initiated and Network-initiated. Within the MIP/PMIP 183 protocols, the priority of the function-extension protocols should be 184 higher than the performance-enhancement protocols. Generally, the 185 following principles should be followed: 187 o Priority 1: Follow network ability 188 o Priority 2: Follow host preference 189 o Priority 3: Support the functional extensions 190 o Priority 4: Support the performance enhancements 191 o In default: network based scheme if it can be supported 192 And the general procedure for the protocol selection should be: 194 o During initiation, network-based protocol may be used as a default 195 mobility management protocol once the network supports it. 196 o If the host prefers host-based protocols, a negotiation is 197 executed to handover from network-based protocol to host-based 198 protocol. 199 o After initial attachment, a profile will be generated in the 200 management store to record the selected or preferred protocol of 201 this host. 202 o When the handover happens, the network will check the selected or 203 preferred protocol during the authentication process. But the 204 network also needs to notify the host if the selected protocol 205 cannot be supported herein. 207 In order to fulfill the above principles, some extensions should be 208 supported, for example: 210 1) Extended negotiation messages 212 The protocol negotiation may be included in the MN_ATTACH Function 213 [MN-AR.IF] and the implementation may be based on a new signaling 214 message or extended messages (e.g., ICMPv6, Diameter, and RADIUS). 215 Besides these, some other protocols may also be used in some 216 specified scenarios, such as extended IEEE 802.21 primitives. 218 2) Extended management store 220 When the terminal accesses to the network, an authentication should 221 be executed before the mobility management service is provided. In 222 order to support the mobility management protocol selection, a new 223 information should be recorded by the network after the successful 224 authentication during the initial attachment. The newly introduced 225 information shows the selected mobility management protocol and 226 should be updated when the used protocol changes. 228 5. Security Considerations 230 Generally, this function will not incur additional security issues. 231 The detailed influence should be analyzed in the future. 233 6. IANA Considerations 235 A new ICMP option or authentication option or other signaling message 236 may be used with a new code number. 238 7. References 240 7.1. Normative References 242 [MN-AR.IF] 243 Laganier, J., Narayanan, S., and P. McCann, "Interface 244 between a Proxy MIPv6 Mobility Access Gateway and a Mobile 245 Node", draft-ietf-netlmm-mn-ar-if-03, February 2008. 247 [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 248 Thubert, "Network Mobility (NEMO) Basic Support Protocol", 249 RFC 3963, DOI 10.17487/RFC3963, January 2005, 250 . 252 [RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., 253 Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", 254 RFC 5213, DOI 10.17487/RFC5213, August 2008, 255 . 257 [RFC5268] Koodli, R., Ed., "Mobile IPv6 Fast Handovers", RFC 5268, 258 DOI 10.17487/RFC5268, June 2008, 259 . 261 [RFC5380] Soliman, H., Castelluccia, C., ElMalki, K., and L. 262 Bellier, "Hierarchical Mobile IPv6 (HMIPv6) Mobility 263 Management", RFC 5380, DOI 10.17487/RFC5380, October 2008, 264 . 266 [RFC5555] Soliman, H., Ed., "Mobile IPv6 Support for Dual Stack 267 Hosts and Routers", RFC 5555, DOI 10.17487/RFC5555, June 268 2009, . 270 [RFC5648] Wakikawa, R., Ed., Devarapalli, V., Tsirtsis, G., Ernst, 271 T., and K. Nagami, "Multiple Care-of Addresses 272 Registration", RFC 5648, DOI 10.17487/RFC5648, October 273 2009, . 275 [RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy 276 Mobile IPv6", RFC 5844, DOI 10.17487/RFC5844, May 2010, 277 . 279 [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility 280 Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 281 2011, . 283 [RFC7333] Chan, H., Ed., Liu, D., Seite, P., Yokota, H., and J. 284 Korhonen, "Requirements for Distributed Mobility 285 Management", RFC 7333, DOI 10.17487/RFC7333, August 2014, 286 . 288 7.2. Informative References 290 [Paper-CombiningMobilityStandards] 291 Oliva, A., Soto, I., Calderon, M., Bernardos, C., and M. 292 Sanchez, "The costs and benefits of combining different IP 293 mobility standards", Computer Standards and Interfaces, 294 February 2013. 296 Authors' Addresses 298 Zhiwei Yan 299 CNNIC 300 No.4 South 4th Street, Zhongguancun 301 Beijing 100190 302 China 304 Email: yan@cnnic.cn 306 Jong-Hyouk Lee 307 Sangmyung University 308 31, Sangmyeongdae-gil, Dongnam-gu 309 Cheonan 310 Republic of Korea 312 Email: jonghyouk@smu.ac.kr 314 H. Anthony Chan 315 Huawei Technologies 316 5340 Legacy Dr. Building 3 317 Plano, TX 75024 318 USA 320 Email: h.a.chan@ieee.org