idnits 2.17.1 draft-ietf-dmm-ondemand-mobility-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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (November 4, 2015) is 3067 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) ** Downref: Normative reference to an Informational RFC: RFC 5014 -- Obsolete informational reference (is this intentional?): RFC 6824 (Obsoleted by RFC 8684) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DMM Working Group A. Yegin 3 Internet-Draft Unaffiliated 4 Intended status: Standards Track K. Kweon 5 Expires: May 7, 2016 J. Lee 6 J. Park 7 Samsung 8 D. Moses 9 Intel 10 November 4, 2015 12 On Demand Mobility Management 13 draft-ietf-dmm-ondemand-mobility-01 15 Abstract 17 Applications differ with respect to whether they need IP session 18 continuity and/or IP address reachability. The network providing the 19 same type of service to any mobile host and any application running 20 on the host yields inefficiencies. This document describes a 21 solution for taking the application needs into account in selectively 22 providing IP session continuity and IP address reachability on a per- 23 socket basis. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on May 7, 2016. 42 Copyright Notice 44 Copyright (c) 2015 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Notational Conventions . . . . . . . . . . . . . . . . . . . 4 61 3. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3.1. Types of IP Addresses . . . . . . . . . . . . . . . . . . 4 63 3.2. Granularity of Selection . . . . . . . . . . . . . . . . 5 64 3.3. On Demand Nature . . . . . . . . . . . . . . . . . . . . 5 65 3.4. Conveying the Selection . . . . . . . . . . . . . . . . . 6 66 4. Backwards Compatibility Considerations . . . . . . . . . . . 7 67 4.1. Applications . . . . . . . . . . . . . . . . . . . . . . 8 68 4.2. IP Stack in the Mobile Host . . . . . . . . . . . . . . . 8 69 4.3. Network Infrastructure . . . . . . . . . . . . . . . . . 8 70 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 71 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 72 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 73 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 74 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 75 8.2. Informative References . . . . . . . . . . . . . . . . . 9 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 78 1. Introduction 80 In the context of Mobile IP [RFC5563][RFC6275][RFC5213][RFC5944], 81 following two attributes are defined for the IP service provided to 82 the mobile hosts: 84 IP session continuity: The ability to maintain an ongoing IP session 85 by keeping the same local end-point IP address throughout the session 86 despite the mobile host chaging its point of attachment within the IP 87 network topology. The IP address of the host may change between two 88 independent IP sessions, but that does not jeopardize the IP session 89 continuity. IP session continuity is essential for mobile hosts to 90 maintain ongoing flows without any interruption. 92 IP address reachability: The ability to maintain the same IP address 93 for an extended period of time. The IP address stays the same across 94 independent IP sessions, and even in the absence of any IP session. 95 The IP address may be published in a long-term registry (e.g., DNS), 96 and it is made available for serving incoming (e.g., TCP) 97 connections. IP address reachability is essential for mobile hosts 98 to use specific/published IP addresses. 100 Mobile IP is designed to provide both IP session continuity and IP 101 address reachability to mobile hosts. Architectures utilizing these 102 protocols (e.g., 3GPP, 3GPP2, WIMAX) ensure that any mobile host 103 attached to the compliant networks can enjoy these benefits. Any 104 application running on these mobile hosts is subjected to the same 105 treatment with respect to the IP session continuity and IP address 106 reachability. 108 It should be noted that in reality not every application may need 109 those benefits. IP address reachability is required for applications 110 running as servers (e.g., a web server running on the mobile host). 111 But, a typical client application (e.g., web browser) does not 112 necessarily require IP address reachability. Similarly, IP session 113 continuity is not required for all types of applications either. 114 Applications performing brief communication (e.g., DNS client) can 115 survive without having IP session continuity support. 117 Achieving IP session continuity and IP address reachability by using 118 Mobile IP incurs some cost. Mobile IP protocol forces the mobile 119 host's IP traffic to traverse a centrally-located router (Home Agent, 120 HA), which incurs additional transmission latency and use of 121 additional network resources, adds to the network CAPEX and OPEX, and 122 decreases the reliability of the network due to the introduction of a 123 single point of failure [I-D.ietf-dmm-requirements]. Therefore, IP 124 session continuity and IP address reachability should be be provided 125 only when needed. 127 Furthermore, when an application needs session continuity, it may be 128 able to satisfy that need by using a solution above the IP layer, 129 such as MPTCP [RFC6824], SIP mobility [RFC3261], or an application- 130 layer mobility solution. Those higher-layer solutions are not 131 subject to the same issues that arise with the use of Mobile IP since 132 they can utilize the most direct data path between the end-points. 133 But, if Mobile IP is being applied to the mobile host, those higher- 134 layer protocols are rendered useless because their operation is 135 inhibited by the Mobile IP. Since Mobile IP ensures the IP address 136 of the mobile host remains fixed (despite the location and movement 137 of the mobile host), the higher-layer protocols never detect the IP- 138 layer change and never engage in mobility management. 140 This document proposes a solution for the applications running on the 141 mobile host to indicate whether they need IP session continuity or IP 142 address reachability. The network protocol stack on the mobile host, 143 in conjunction with the network infrastructure, would provide the 144 required type of IP service. It is for the benefit of both the users 145 and the network operators not to engage an extra level of service 146 unless it is absolutely necessary. So it is expected that 147 applications and networks compliant with this specification would 148 utilize this solution to use network resources more efficiently. 150 2. Notational Conventions 152 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 153 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 154 document are to be interpreted as described in [RFC2119]. 156 3. Solution 158 3.1. Types of IP Addresses 160 Three types of IP addresses are defined with respect to the mobility 161 management. 163 - Fixed IP Address 165 This is what standard Mobile IP provides with a Home Address (HoA). 166 The mobile host is configures a HoA from a centrally-located Home 167 Network. Both IP session continuity and IP address reachability are 168 provided to the mobile host with the help of a router in the Home 169 Network (Home Agent, HA). This router acts as an anchor for the IP 170 address of the mobile host. 172 - Sustained IP Address 174 This type of IP address provides IP session continuity but not IP 175 address reachability. It is achieved by ensuring that the IP address 176 used at the beginning of the session remains usable despite the 177 movement of the mobile host. The IP address may change after the 178 termination of the IP session(s), therefore it does not exhibit 179 persistence. 181 A sustained IP address may be configured and maintained by using 182 access network anchoring, corresponding network anchoring, or some 183 other solution. 185 - Nomadic IP Address 187 This type of IP address provides neither IP session continuity nor IP 188 address reachability. The IP address is obtained from the serving IP 189 gateway and it is not maintained across gateway changes. In other 190 words, the IP address may be released and replaced by a new IP 191 address when the IP gateway changes due to the movement of the mobile 192 host. 194 Applications running as servers at a published IP address require a 195 Fixed IP Address. Long-standing applications (e.g., an SSH session) 196 may also require this type of address. Those applications could use 197 a Sustained IP Address, but that can produce sub-optimal results if 198 the mobile host ends up far from the anchor gateway. Enterprise 199 applications that connect to an enterprise network via virtual LAN 200 require a Fixed IP Address. 202 Applications with short-lived transient IP sessions can use Sustained 203 IP Addresses. For example: Web browsers. 205 Applications with very short IP sessions, such as DNS client and 206 instant messengers, can utilize Nomadic IP Addresses. Even though 207 they could very well use a Fixed of Sustained IP Addresses, the 208 transmission latency would be minimized when a Nomadic IP Address is 209 used. 211 3.2. Granularity of Selection 213 The IP address type selection is made on a per-socket granularity. 214 Different parts of the same application may have different needs. 215 For example, control-plane of an application may require a Fixed IP 216 Address in order to stay reachable, whereas data-plane of the same 217 application may be satisfied with a Sustained IP Address. 219 3.3. On Demand Nature 221 At any point in time, a mobile host may have a combination of IP 222 addresses configured. Zero or more Nomadic, zero or more Sustained, 223 and zero or more Fixed IP addresses may be configured on the IP stack 224 of the host. The combination may be as a result of the host policy, 225 application demand, or a mix of the two. 227 When the application requires a specific type of IP address and such 228 an IP address is not already configured on the host, then the IP 229 stack shall attempt to configure one. For example, a host may not 230 always have a Fixed IP address available as such an address is rarely 231 used. In case an application requests one, then the IP stack shall 232 make an attempt to configure one using Mobile IP. If Mobile IP 233 protocol is not available on the stack, or if its operation fails, 234 then the IP stack shall fail the associated socket request. In case 235 of successful Mobile IP operation, a Fixed IP Address gets configured 236 on the mobile host. If another socket requests a Fixed IP address at 237 a later time, then the same IP address may be served to that socket 238 as well. When the last socket using the requested IP address is 239 closed, the IP address may be released or kept for future 240 applications that may be launched and require a Fixed IP address. 242 The following are matters of policy, which may be dictated by the 243 host itself, the network operator, or the system architecture 244 standard: 246 - The initial set of IP addresses configured on the host at the boot 247 time. 249 - Permission to grant various types of IP addresses to a requesting 250 application. 252 - Determination of a default address type when an application does 253 not make any explicit indication, whether it already supports the 254 required API or it is just a legacy application. 256 3.4. Conveying the Selection 258 The selection of the address type is conveyed from the applications 259 to the IP stack in a way to influence the source address selection 260 algorithm [RFC6724]. 262 The current source address selection algorithm operates on the 263 available set of IP addresses when selecting an address. According 264 to the proposed solution, if the requested type IP address is not 265 available at the time of the request, then the IP stack shall make an 266 attempt to configure one such IP address. The selected IP address 267 shall be compliant with the requested IP address type, whether it is 268 selected among available addresses or dynamically configured. In the 269 absence of a matching type (because it is not available and not 270 configurable on demand), the source address selection algorithm shall 271 return an empty set. 273 A Socket API-based interface for enabling applications to influence 274 the source address selection algorithm is described in [RFC5014]. 275 That specification defines IPV6_ADDR_PREFERENCES option at the 276 IPPROTO_IPV6 level. That option can be used with setsockopt() and 277 getsockopt() calls to set and get address selection preferences. 279 Furthermore, that RFC also specifies two flags that relate to IP 280 mobility management: IPV6_PREFER_SRC_HOME and IPV6_PREFER_SRC_COA. 281 These flags are used for influencing the source address selection to 282 prefer either a Home Address or a Care-of Address. 284 Unfortunately, these flags do not satisfy the aforementioned needs 285 due to the following reasons, therefore new flags are proposed in 286 this document: 288 - Current flags indicate a "preference" whereas there is a need for 289 indicating "requirement". Source address selection algorithm does 290 not have to produce an IP address compliant with the "preference" , 291 but it has to produce an IP address compliant with the "requirement". 293 - Current flags influence the selection made among available IP 294 addresses. The new flags force the IP stack to configure a compliant 295 IP address if none is available at the time of the request. 297 - The Home vs. Care-of Address distinction is not sufficient to 298 capture the three different types of IP addresses described in 299 Section 2.1. 301 The following new flags are defined in this document and they shall 302 be used with Socket API in compliance with the [RFC5014]: 304 IPV6_REQ_FIXED_IP /* Require a Fixed IP address as source */ 306 IPV6_REQ_SUSTAINED_IP /* Require a Sustained IP addr. as source */ 308 IPV6_REQ_NOMADIC_IP /* Require a Nomadic IP address as source */ 310 More than one of these flags may be set on the same socket. In that 311 case, an IP address compliant with any one of them shall be selected. 312 TBD: Disallow this case? 314 When any of these new flags is used, then the IPV6_PREFER_SRC_HOME 315 and IPV6_PREFER_SRC_COA flags, if used, shall be ignored. 317 These new flags are used with setsockopt()/getsockopt(), 318 getaddrinfo(), and inet6_is_srcaddr() functions [RFC5014]. Similar 319 with the setsockopt()/getsockopt() calls, getaddrinfo() call shall 320 also trigger configuration of the required type IP address, if one is 321 not already available. When the new flags are used with 322 getaddrinfo() and the triggered configuration fails, the 323 getaddrinfo() call shall ignore that failure (i.e., not return an 324 error code to indicate that failure). Only the setsockopt() shall 325 return an error when configuration of the requested type IP address 326 fails. 328 Application of this solution to IPv4 is TBD. 330 4. Backwards Compatibility Considerations 332 Backwards compatibility support is required by the following 3 types 333 of entities: 335 - The Applications on the mobile host 337 - The IP stack in the mobile host 338 - The network infrastructure 340 4.1. Applications 342 Legacy applications that do not support the new flags will use the 343 legacy API to the IP stack and will not enjoy On-Demand Mobility 344 feature. 346 Applications using the new flags must be aware that they may be 347 executed in environments that do not support On-Demand Mobility 348 feature. Such environments may include legacy IP stack in the mobile 349 host, legacy network infrastructure, or both. In either case, the 350 API will return an error code and the invoking applications must 351 respond with using legacy calls without On-Demand Mobility feature. 353 4.2. IP Stack in the Mobile Host 355 New IP stacks must continue to support all legacy operations. If an 356 application does not use On-Demand Mobility feature, the IP stack 357 must respond in a legacy manner. 359 If the network infrastructure supports On-Demand Mobility feature, 360 the IP stack may still request specific types of source IP address 361 transparently to legacy applications. This may be useful for 362 environments in which both legacy and new applications are executed. 364 The definition of what type of addresses to request and how they are 365 assigned to legacy applications are outside of the scope of this 366 specification. 368 4.3. Network Infrastructure 370 The network infrastructure may or may not support the On-Demand 371 Mobility feature. How the IP stack on the host and the network 372 infrastructure behave in case of a compatibility issue is outside the 373 scope of this API specification. 375 5. Security Considerations 377 The setting of certain IP address type on a given socket may be 378 restricted to privileged applications. For example, a Fixed IP 379 Address may be provided as a premium service and only certain 380 applications may be allowed to use them. Setting and enforcement of 381 such privileges are outside the scope of this document. 383 6. IANA Considerations 385 TBD 387 7. Acknowledgements 389 We would like to thank Alexandru Petrescu, Dapeng Liu, John 390 Kaippallimalil, Jouni Korhonen, Seil Jeon, Sri Gundavelli, and 391 Xinpeng Wei for their valuable comments and suggestions on this work. 393 8. References 395 8.1. Normative References 397 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 398 Requirement Levels", BCP 14, RFC 2119, 399 DOI 10.17487/RFC2119, March 1997, 400 . 402 [RFC5014] Nordmark, E., Chakrabarti, S., and J. Laganier, "IPv6 403 Socket API for Source Address Selection", RFC 5014, 404 DOI 10.17487/RFC5014, September 2007, 405 . 407 [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, 408 "Default Address Selection for Internet Protocol Version 6 409 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, 410 . 412 8.2. Informative References 414 [I-D.ietf-dmm-requirements] 415 Chan, A., Liu, D., Seite, P., Yokota, H., and J. Korhonen, 416 "Requirements for Distributed Mobility Management", draft- 417 ietf-dmm-requirements-17 (work in progress), June 2014. 419 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 420 A., Peterson, J., Sparks, R., Handley, M., and E. 421 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 422 DOI 10.17487/RFC3261, June 2002, 423 . 425 [RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., 426 Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", 427 RFC 5213, DOI 10.17487/RFC5213, August 2008, 428 . 430 [RFC5563] Leung, K., Dommety, G., Yegani, P., and K. Chowdhury, 431 "WiMAX Forum / 3GPP2 Proxy Mobile IPv4", RFC 5563, 432 DOI 10.17487/RFC5563, February 2010, 433 . 435 [RFC5944] Perkins, C., Ed., "IP Mobility Support for IPv4, Revised", 436 RFC 5944, DOI 10.17487/RFC5944, November 2010, 437 . 439 [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility 440 Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 441 2011, . 443 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 444 "TCP Extensions for Multipath Operation with Multiple 445 Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, 446 . 448 Authors' Addresses 450 Alper Yegin 451 Unaffiliated 452 Istanbul 453 Turkey 455 Email: alper.yegin@yegin.org 457 Kisuk Kweon 458 Samsung 459 Suwon 460 South Korea 462 Email: kisuk.kweon@samsung.com 464 Jinsung Lee 465 Samsung 466 Suwon 467 South Korea 469 Email: js81.lee@samsung.com 470 Jungshin Park 471 Samsung 472 Suwon 473 South Korea 475 Email: shin02.park@samsung.com 477 Danny Moses 478 Intel Corporation 479 Petah Tikva 480 Israel 482 Email: danny.moses@intel.com