idnits 2.17.1 draft-yan-dmm-man-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 21, 2016) is 2682 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: 3 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: June 24, 2017 Sangmyung University 6 December 21, 2016 8 Mobility Ability Negotiation 9 draft-yan-dmm-man-00 11 Abstract 13 Based on IPv6, multiple mobility management protocols have been 14 developed and generally they can be classified into two types: 15 network-based and host-based. Different protocols have different 16 functional requirements on the network element or the terminal and 17 then a scheme should be used in order to support the negotiation and 18 selection of adopted mobility management protocol when a terminal 19 accesses to a new network. In this draft, this issue is considered 20 and analyzed. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on June 24, 2017. 39 Copyright Notice 41 Copyright (c) 2016 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 4. Possible solutions . . . . . . . . . . . . . . . . . . . . . 4 60 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 61 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 62 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 65 1. Introduction 67 As the Mobile IPv6 (MIPv6) [RFC6275] protocol standardization suite, 68 there are multiple extension protocols have been standardized. These 69 protocols can be classified into two types: protocols for the 70 function extension and protocols for the performance enhancement. 71 The protocols for the function extension is proposed to support some 72 specific scenarios or functions, such as: Dual-stack Mobile IPv6 73 (DSMIPv6) [RFC5555] for mobility of the dual-stack nodes, Multiple 74 Care-of-address (MCoA) [RFC5648] for mobile nodes of multi-interface 75 and Network Mobility (NEMO) [RFC3963] for mobility of sub-network. 76 The other type is proposed to enhance the performance of the mobility 77 management, such as Fast Mobile IPv6 (FMIP6) [RFC5268] for fast 78 handover, Hierarchical Mobile IPv6 (HMIPv6) [RFC5380] for 79 hierarchical mobility optimization. MIPv6 and these extensions are 80 called host-based mobility management protocols because the location 81 update is initiated by the terminal and the tunnel is terminated at 82 the terminal. 84 In order to reduce the protocol cost and enhance the handover 85 performance further, the network-based mobility management schemes 86 were proposed and Proxy Mobile IPv6 (PMIPv6) [RFC5213] was 87 standardized as a basis. Based on PMIPv6, a series of its extensions 88 were proposed, such as Dual-stack Proxy Mobile IPv6 (DS-PMIPv6) 89 [RFC5844], Distributed Mobility Management Proxy Mobile IPv6 (DMM- 90 PMIPv6) [RFC7333] and so on. Be different from the host-based 91 schemes, the location update in PMIPv6 is triggered by the network 92 entity and the tunnel is established between network entities. And 93 the terminal needs to do nothing about the signaling exchange during 94 the movement, particularly, the mobility is transparent to the IP 95 layer of the terminal. 97 In reality, these protocols will be co-existing and multiple protocol 98 daemons will be configured on the network entities or terminal. That 99 means a scheme is needed to support the negotiation and selection of 100 mobility management protocol when the terminal accesses into a new 101 network initially or handover happens. 103 This document tries to analyze this problem with the possible 104 scenarios should be supported by the further solution. 106 2. Motivation 108 As illustrated above, these protocols may co-exist in reality and 109 simultaneously used in an access network or even the same entity. 110 Due to their different requirements on the network entity or 111 terminal, a scheme is needed to support the negotiation and selection 112 of adopted mobility management protocol when the terminal accesses to 113 a new network. 115 Generally, two problems should be solved: 117 o Which entity (network or terminal) will initiate the protocol 118 negotiation and selection? 119 o What principles should be followed for the protocol negotiation 120 and selection? 122 This scheme is needed because different entity and terminal will have 123 different abilities and preferences (may be decided by the ability 124 and mobility pattern of the mobile node). This scheme can guarantee 125 that the optimum and most suitable protocol will be used. 127 3. Scenarios 129 In order to illustrate the necessity of the mobility ability 130 negotiation and protocol selection, the following scenarios are taken 131 as typical examples: 133 1) Network supports MIPv6, host supports only PMIPv6 135 In this case, the network supports only host-based scheme, while the 136 host does not have any mobility management function. Then only the 137 PMIPv6 can be used to support the mobility management of the host, 138 but the network does not deploy the PMIPv6 protocols and this will 139 cause the mobility failure because no available protocol can be used. 141 2) Network supports both MIPv6 and PMIPv6, host supports only PMIPv6 143 In this case, the network deploys both host-based and network-based 144 schemes, while the host supports only PMIPv6. When the host accesses 145 to the network, PMIPv6 will be used. Actually, PMIPv6 should be 146 adopted as a default mobility management scheme considering its 147 optimized performance. Once the PMIPv6 can be supported by the 148 network, it will be adopted as the default scheme. 150 3) Network supports both MIPv6 and PMIPv6, host supports MIPv6 152 In this case, the network deploys both host-based and network-based 153 schemes, and the host also supports MIPv6. Because PMIPv6 has no 154 requirement on the host, both PMIPv6 and MIPv6 can be used in this 155 case. Then the host can use PMIPv6 as default, and use MIPv6 for the 156 global mobility. 158 4) Network and host support all the extention protocols 160 In this case, the network has deployed multiple extensions to support 161 more complex requirements, so does the host. And then the host and 162 network can negotiate a protocol for the optimized performance or 163 special requirement, for example, FMIPv6 may be selected in order to 164 support fast handover, HMIPv6 may be selected in order to reduce the 165 signaling cost, NEMO may be selected in order to support the subnet 166 mobility. 168 4. Possible solutions 170 Two different schemes may be used for the protocol negotiation and 171 selection: MN-initiated and Network-initiated. Within the MIP/PMIP 172 protocols, the priority of the function-extension protocols should be 173 higher than the performance-enhancement protocols. Generally, the 174 following principles and general procedure may be followed: 176 o During initiation, PMIPv6 may be used as a default mobility 177 management protocol once the network supports it. 178 o If the host prefers host-based scheme, a negotiation is executed 179 to handover from PMIPv6 to MIPv6 style. 180 o After initial attachment, a profile will be generated in the 181 management store to record the selected protocol of this host. 182 o When the handover happens, the network will check the selected 183 protocol during the authentication process. But the network also 184 needs to notify the host if the selected protocol cannot be 185 supported herein. 187 In order to fulfill the above principles, some extensions should be 188 supported, for example: 190 1) Extended negotiation messages 191 In order to negotiate the mobility management protocol between host 192 and network, a new signaling message or an extended message (e.g., 193 ICMPv6, Diameter, and RADIUS) should be used. Except these, some 194 other protocols may also be used in some specified scenarios, such as 195 extended IEEE 802.21 primitives. 197 2) Extended management store 199 When the terminal accesses to the network, an authentication should 200 be executed before the mobility management service is provided. In 201 order to support the mobility management protocol selection, a new 202 information should be recorded by the network after the successful 203 authentication during the initial attachment. The newly introduced 204 information shows the selected mobility management protocol and 205 should be updated when the used protocol changes. 207 5. Security Considerations 209 Generally, this function will not incur additional security issues. 210 The detailed influence should be analyzed in the future. 212 6. IANA Considerations 214 A new ICMP option or authentication option or other signaling message 215 may be used with a new code number. 217 7. References 219 [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 220 Thubert, "Network Mobility (NEMO) Basic Support Protocol", 221 RFC 3963, DOI 10.17487/RFC3963, January 2005, 222 . 224 [RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., 225 Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", 226 RFC 5213, DOI 10.17487/RFC5213, August 2008, 227 . 229 [RFC5268] Koodli, R., Ed., "Mobile IPv6 Fast Handovers", RFC 5268, 230 DOI 10.17487/RFC5268, June 2008, 231 . 233 [RFC5380] Soliman, H., Castelluccia, C., ElMalki, K., and L. 234 Bellier, "Hierarchical Mobile IPv6 (HMIPv6) Mobility 235 Management", RFC 5380, DOI 10.17487/RFC5380, October 2008, 236 . 238 [RFC5555] Soliman, H., Ed., "Mobile IPv6 Support for Dual Stack 239 Hosts and Routers", RFC 5555, DOI 10.17487/RFC5555, June 240 2009, . 242 [RFC5648] Wakikawa, R., Ed., Devarapalli, V., Tsirtsis, G., Ernst, 243 T., and K. Nagami, "Multiple Care-of Addresses 244 Registration", RFC 5648, DOI 10.17487/RFC5648, October 245 2009, . 247 [RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy 248 Mobile IPv6", RFC 5844, DOI 10.17487/RFC5844, May 2010, 249 . 251 [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility 252 Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 253 2011, . 255 [RFC7333] Chan, H., Ed., Liu, D., Seite, P., Yokota, H., and J. 256 Korhonen, "Requirements for Distributed Mobility 257 Management", RFC 7333, DOI 10.17487/RFC7333, August 2014, 258 . 260 Authors' Addresses 262 Zhiwei Yan 263 CNNIC 264 No.4 South 4th Street, Zhongguancun 265 Beijing 100190 266 China 268 Email: yan@cnnic.cn 270 Jong-Hyouk Lee 271 Sangmyung University 272 31, Sangmyeongdae-gil, Dongnam-gu 273 Cheonan 274 Republic of Korea 276 Email: jonghyouk@smu.ac.kr