idnits 2.17.1 draft-sijeon-dmm-use-cases-api-source-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 13, 2017) is 2601 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-18) exists of draft-ietf-dmm-ondemand-mobility-10 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DMM Working Group S. Jeon 3 Internet-Draft Sungkyunkwan University 4 Intended status: Standards Track S. Figueiredo 5 Expires: September 14, 2017 Altran Research 6 Y. Kim 7 Soongsil University 8 J. Kaippallimalil 9 Huawei 10 March 13, 2017 12 Use Cases and API Extension for Source IP Address Selection 13 draft-sijeon-dmm-use-cases-api-source-06.txt 15 Abstract 17 This draft specifies and analyzes the expected cases regarding the 18 selection of a proper source IP address and address type by an 19 application in a distributed mobility management (DMM) network. It 20 also proposes a new Socket API to address further selection issues 21 with three source IP address types defined in the on-demand mobility 22 API draft. 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 September 14, 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. Use Cases and Analysis . . . . . . . . . . . . . . . . . . . 3 60 2.1. Application has no specific IP address type requirement 61 or address preference . . . . . . . . . . . . . . . . . . 3 62 2.2. Application has specific IP address type requirement and 63 address preference . . . . . . . . . . . . . . . . . . . 3 64 2.2.1. Case 1: there is no configured IP address based on a 65 requested type in the IP stack, but there is a 66 further selection preference by the application . . . 3 67 2.2.2. Case 2: there are one or more IP addresses configured 68 with a requested type in the IP stack, and no 69 selection preference by the application . . . . . . . 4 70 2.2.3. Case 3: there are one or more IP addresses with a 71 requested type configured in the IP stack, but there 72 is a further selection preference by the application 4 73 2.3. Gaps in the consistency with the default address 74 selection . . . . . . . . . . . . . . . . . . . . . . . . 5 75 3. Indications for expressing address preference requirement . . 5 76 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 77 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 78 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 79 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 80 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 81 7.2. Informative References . . . . . . . . . . . . . . . . . 7 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 84 1. Introduction 86 Applications to select source IP address type in a mobile node (MN) 87 need to consider IP session continuity and/or IP address 88 reachability. [I-D.ietf-dmm-ondemand-mobility], defines three types 89 of source IP addresses based on mobility management capabilities: 90 fixed IP address, session-lasting IP address, and non-persistent IP 91 address. Based on the address type requested by the application, the 92 MN configures a proper source IP address. However, the source IP 93 address type itself in a socket request may not be enough to convey 94 all the requirements of an application. For example, more than one 95 IP address of the same type requested may be available. It may be 96 that as a result of mobility the MN can potentially obtain new IP 97 prefixes from different serving networks belonging to different 98 subnets. This draft categorizes and analyzes use cases that an MN is 99 likely to encounter. In addition, this draft proposes an extension 100 that allows the application to express its preferences when more than 101 one source address of a type is present. 103 2. Use Cases and Analysis 105 This section outlines use cases where an application on the MN tries 106 to obtain a source IP address. 108 2.1. Application has no specific IP address type requirement or address 109 preference 111 Applications such as text-based web browsing or information service, 112 e.g. weather and stock information, as well as legacy applications 113 belong to this category. Many applications use short-lived Internet 114 connections with no requirements for session continuity or IP address 115 reachability. Assigning a non-persistent IP address can be thus 116 considered as default for MNs. However, it is subject to address 117 assignment policy of a network operator. The suggested flag, 118 IPV6_REQUIRE_NON-PERSISTENT_IP, defined in 119 [I-D.ietf-dmm-ondemand-mobility] can used for expressing its 120 preference to the IP stack. 122 2.2. Application has specific IP address type requirement and address 123 preference 125 This category is for an application requiring IP session continuity 126 with different granularity of IP address reachability. This case may 127 be further divided in three sub-cases with regard to IP address type 128 availability and/or address selection. 130 2.2.1. Case 1: there is no configured IP address based on a requested 131 type in the IP stack, but there is a further selection 132 preference by the application 134 Once an IP address is requested by an application regardless of any 135 source IP address type defined in [I-D.ietf-dmm-ondemand-mobility], 136 the network stack will configure an IP address after obtaining an IP 137 prefix based on the requested source IP address type from the current 138 serving gateway. 140 2.2.2. Case 2: there are one or more IP addresses configured with a 141 requested type in the IP stack, and no selection preference by 142 the application 144 This is the same as Case 1 described above, except the existence of 145 more than one configured IP addresses belonging to the requested IP 146 address type in the IP stack, e.g. due to different address 147 assignment policy by an operator. 149 When a non-persistent IP address is requested, if an application 150 requests a non-persistent IP address to the IP stack, the IP address 151 is obtained from the serving IP gateway as the previous one is not 152 maintained across gateway changes. 154 When a session-lasting IP address is requested, an expected sequence 155 can be described as follows; 157 1. The MN has one or more session-lasting IP addresses configured in 158 the IP stack. 160 2. If an application requests a session-lasting IP address to the IP 161 stack, it will try to use an existing session-lasting IP address as 162 it is already configured in the IP stack. If there are multiple 163 available session-lasting IP addresses, the default address selection 164 rules will be applied [RFC6724], e.g. with scope preference, longest 165 prefix matching, and/or so on. The best-matched IP address among 166 them will be selected and assigned to the application. 168 3. Subsequently, the MN moves to another serving network, and the 169 previous (mobile) sessions are still in use. A new application 170 requests a session-lasting IP address with flag, 171 IPV6_REQUIRE_SESSION_LASTING_IP to the IP stack. The selection of 172 the session-lasting IP address follows the same procedure as 173 described in Step 2. 175 When a fixed IP address is requested, it will follow the same 176 procedure with session-lasting IP address request as described. 178 2.2.3. Case 3: there are one or more IP addresses with a requested type 179 configured in the IP stack, but there is a further selection 180 preference by the application 182 Assume that there are one or multiple applications with session- 183 lasting IP address running. A newly initiated application might get 184 one of the session-lasting IP addresses being used, not initiating a 185 protocol procedure, i.e. DHCP or SLAAC for a new session-lasting IP 186 address to the network. On the contrary, the IP stack might try to 187 get a new session-lasting IP address from the current serving gateway 188 by default. Acquiring a new session-lasting IP address may take some 189 time (due to the exchange with the network) while using an existing 190 one is instantaneous. On the other hand, using the existing one 191 might yield less optimal routing. For example, the use of the IP 192 address with an existing one configured might provide a suboptimal 193 routing path as a result of a handover. This situation might not be 194 preferred by newly initiated applications because the application 195 incurs the costs of IP mobility even though the MN has not moved from 196 the current serving network. Eventually, the new session is served 197 by a remote IP mobility anchor with mobility management functions, 198 though the MN has not moved yet. 200 If the application is allowed to further define its preference for an 201 optimally routed, this situation can be avoided. See Section 3 for 202 the proposed flag. 204 2.3. Gaps in the consistency with the default address selection 206 The need of an indication mechanism can be sought in the consistency 207 with the former IETF standards. For example, in [RFC6724] where 208 default behavior for IPv6 is specified, without a proper indication 209 mechanism, following conflicts are expected to happen. In Rule 6 in 210 [RFC6724], it is said that the matching label between source address 211 of an IPv6 host and destination address is preferred among the 212 combinations between other source addresses and destination address, 213 where the label is a numeric value representing policies that prefer 214 a particular source address prefix for use with a destination address 215 prefix in [RFC6724]. In Rule 8 in [RFC6724], it is said that the 216 longest matching prefix between source address of an IPv6 host and 217 destination address is preferred among the combinations between other 218 source addresses and destination address. Following Rules 6 and 8 219 may result in the selection of a source IP address with which packets 220 that are sub-optimally routed. 222 3. Indications for expressing address preference requirement 224 When an application prefers a new IP address of the requested IP 225 address type, additional indication flags should be delivered through 226 the socket API interface. 228 To obtain an address that supports dynamic mobility using session- 229 lasting IP address, a new address preference flag needs to be 230 defined. The flag should be simple and useful while aligned with the 231 three types of IP addresses. The objective of the hereby presented 232 address preference flag is letting the IP stack check whether it has 233 an available IP address assigned from the current serving network 234 when the flag is received by an initiated application. If not, it 235 will trigger the IP stack to get a new IP address from the current 236 serving network. We call it "ON_NET" property. 238 If the application requests an IP address with ON_NET flag set in the 239 socket request, the IP address returned by the stack should conform 240 to the address preference requirement. This should be the case even 241 though other session-lasting IP addresses, not belonging to the 242 current serving network are available. If there are multiple 243 session-lasting IP addresses matched with ON_NET property, the 244 default source address selection rules will be applied. 246 IPV6_XX_SRC_ON_NET 248 /* Require (or Prefer) an IP address based on a requested IP address 249 type as source, assigned from the current serving network, whatever 250 it has been assigned or should be assigned */ 252 This flag aims to express the preference to check an IP address, 253 being used by an application, previously assigned from the current 254 serving network and to use it or to get an IP address from the 255 current serving network, as well as enabling differentiated per-flow 256 anchoring where an obtained session-lasting IP address might be used 257 for all initiated session-lasting IP applications. The use of the 258 flag can be combined together with the three types of IP address 259 defined in [I-D.ietf-dmm-ondemand-mobility]. 261 In [I-D.mccann-dmm-prefixcost], it proposes that the Router 262 Advertisement signaling messages communicate the cost of maintaining 263 a given prefix at the MN's current point of attachment. The 264 objective is to make a dynamic and optimal decision of address 265 assignment and release, i.e. when to release old addresses and assign 266 new ones. The proposed ON_NET property may present a way to deliver 267 a prefix decision for an application, specifically from a routing 268 distance point of view, to the IP stack. 270 4. IANA Considerations 272 This document makes no request of IANA. 274 5. Security Considerations 276 T.B.D. 278 6. Acknowledgements 280 We would like to thank Danny Moses, Marco Liebsch, Brian Haberman, 281 Sri Gundavelli, Alexandru Petrescu for their valueable comments and 282 suggestions on this work. 284 7. References 286 7.1. Normative References 288 [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, 289 "Default Address Selection for Internet Protocol Version 6 290 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, 291 . 293 7.2. Informative References 295 [I-D.ietf-dmm-ondemand-mobility] 296 Yegin, A., Moses, D., Kweon, K., Lee, J., Park, J., and S. 297 Jeon, "On Demand Mobility Management", draft-ietf-dmm- 298 ondemand-mobility-10 (work in progress), January 2017. 300 [I-D.mccann-dmm-prefixcost] 301 McCann, P. and J. Kaippallimalil, "Communicating Prefix 302 Cost to Mobile Nodes", draft-mccann-dmm-prefixcost-03 303 (work in progress), April 2016. 305 Authors' Addresses 307 Seil Jeon 308 Sungkyunkwan University 309 2066 Seobu-ro, Jangan-gu 310 Suwon, Gyeonggi-do 311 Korea 313 Email: seiljeon@skku.edu 315 Sergio Figueiredo 316 Altran Research 317 2, Rue Paul Dautier 318 Velizy-Villacoublay 78140 319 France 321 Email: sergio.figueiredo@altran.com 323 Younghan Kim 324 Soongsil University 325 369, Sangdo-ro, Dongjak-gu 326 Seoul 156-743 327 Korea 329 Email: younghak@ssu.ac.kr 330 John Kaippallimalil 331 Huawei 332 5340 Legacy Dr., Suite 175 333 Plano, TX 75024 334 USA 336 Email: john.kaippallimalil@huawei.com