DMM Working Group S. Jeon Internet-Draft Sungkyunkwan University Intended status: Standards Track S. Figueiredo Expires: May 4, 2017 Altran Research Y. Kim Soongsil University J. Kaippallimalil Huawei October 31, 2016 Use Cases and API Extension for Source IP Address Selection draft-sijeon-dmm-use-cases-api-source-05.txt Abstract This draft specifies and analyzes the expected cases regarding the selection of a proper source IP address and address type by an application in a distributed mobility management (DMM) network. It also proposes a new Socket API to address further selection issues with three source IP address types defined in the on-demand mobility API draft. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on May 4, 2017. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of Jeon, et al. Expires May 4, 2017 [Page 1] Internet-Draft Use Cases and API Extension October 2016 publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Use Cases and Analysis . . . . . . . . . . . . . . . . . . . 3 2.1. Application has no specific IP address type requirement or address preference . . . . . . . . . . . . . . . . . . 3 2.2. Application has specific IP address type requirement and address preference . . . . . . . . . . . . . . . . . . . 3 2.2.1. Case 1: there is no configured IP address based on a requested type in the IP stack, but there is a further selection preference by the application . . . 3 2.2.2. Case 2: there are one or more IP addresses configured with a requested type in the IP stack, and no selection preference by the application . . . . . . . 4 2.2.3. Case 3: there are one or more IP addresses with a requested type configured in the IP stack, but there is a further selection preference by the application 4 2.3. Gaps in the consistency with the default address selection . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Indications for expressing address preference requirement . . 5 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 7.2. Informative References . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction Applications to select source IP address type in a mobile node (MN) need to consider IP session continuity and/or IP address reachability. [I-D.ietf-dmm-ondemand-mobility], defines three types of source IP addresses based on mobility management capabilities: fixed IP address, session-lasting IP address, and non-persistent IP address. Based on the address type requested by the application, the MN configures a proper source IP address. However, the source IP address type itself in a socket request may not be enough to convey all the requirements of an application. For example, more than one IP address of the same type requested may be available. It may be that as a result of mobility the MN can potentially obtain new IP Jeon, et al. Expires May 4, 2017 [Page 2] Internet-Draft Use Cases and API Extension October 2016 prefixes from different serving networks belonging to different subnets. This draft categorizes and analyzes use cases that an MN is likely to encounter. In addition, this draft proposes an extension that allows the application to express its preferences when more than one source address of a type is present. 2. Use Cases and Analysis This section outlines use cases where an application on the MN tries to obtain a source IP address. 2.1. Application has no specific IP address type requirement or address preference Applications such as text-based web browsing or information service, e.g. weather and stock information, as well as legacy applications belong to this category. Many applications use short-lived Internet connections with no requirements for session continuity or IP address reachability. Assigning a non-persistent IP address can be thus considered as default for MNs. However, it is subject to address assignment policy of a network operator. The suggested flag, IPV6_REQUIRE_NON-PERSISTENT_IP, defined in [I-D.ietf-dmm-ondemand-mobility] can used for expressing its preference to the IP stack. 2.2. Application has specific IP address type requirement and address preference This category is for an application requiring IP session continuity with different granularity of IP address reachability. This case may be further divided in three sub-cases with regard to IP address type availability and/or address selection. 2.2.1. Case 1: there is no configured IP address based on a requested type in the IP stack, but there is a further selection preference by the application Once an IP address is requested by an application regardless of any source IP address type defined in [I-D.ietf-dmm-ondemand-mobility], the network stack will configure an IP address after obtaining an IP prefix based on the requested source IP address type from the current serving gateway. Jeon, et al. Expires May 4, 2017 [Page 3] Internet-Draft Use Cases and API Extension October 2016 2.2.2. Case 2: there are one or more IP addresses configured with a requested type in the IP stack, and no selection preference by the application This is the same as Case 1 described above, except the existence of more than one configured IP addresses belonging to the requested IP address type in the IP stack, e.g. due to different address assignment policy by an operator. When a non-persistent IP address is requested, if an application requests a non-persistent IP address to the IP stack, the IP address is obtained from the serving IP gateway as the previous one is not maintained across gateway changes. When a session-lasting IP address is requested, an expected sequence can be described as follows; 1. The MN has one or more session-lasting IP addresses configured in the IP stack. 2. If an application requests a session-lasting IP address to the IP stack, it will try to use an existing session-lasting IP address as it is already configured in the IP stack. If there are multiple available session-lasting IP addresses, the default address selection rules will be applied [RFC6724], e.g. with scope preference, longest prefix matching, and/or so on. The best-matched IP address among them will be selected and assigned to the application. 3. Subsequently, the MN moves to another serving network, and the previous (mobile) sessions are still in use. A new application requests a session-lasting IP address with flag, IPV6_REQUIRE_SESSION_LASTING_IP to the IP stack. The selection of the session-lasting IP address follows the same procedure as described in Step 2. When a fixed IP address is requested, it will follow the same procedure with session-lasting IP address request as described. 2.2.3. Case 3: there are one or more IP addresses with a requested type configured in the IP stack, but there is a further selection preference by the application Assume that there are one or multiple applications with session- lasting IP address running. A newly initiated application might get one of the session-lasting IP addresses being used, not initiating a protocol procedure, i.e. DHCP or SLAAC for a new session-lasting IP address to the network. On the contrary, the IP stack might try to get a new session-lasting IP address from the current serving gateway Jeon, et al. Expires May 4, 2017 [Page 4] Internet-Draft Use Cases and API Extension October 2016 by default. Acquiring a new session-lasting IP address may take some time (due to the exchange with the network) while using an existing one is instantaneous. On the other hand, using the existing one might yield less optimal routing. For example, the use of the IP address with an existing one configured might provide a suboptimal routing path as a result of a handover. This situation might not be preferred by newly initiated applications because the application incurs the costs of IP mobility even though the MN has not moved from the current serving network. Eventually, the new session is served by a remote IP mobility anchor with mobility management functions, though the MN has not moved yet. If the application is allowed to further define its preference for an optimally routed, this situation can be avoided. See Section 3 for the proposed flag. 2.3. Gaps in the consistency with the default address selection The need of an indication mechanism can be sought in the consistency with the former IETF standards. For example, in [RFC6724] where default behavior for IPv6 is specified, without a proper indication mechanism, following conflicts are expected to happen. In Rule 6 in [RFC6724], it is said that the matching label between source address of an IPv6 host and destination address is preferred among the combinations between other source addresses and destination address, where the label is a numeric value representing policies that prefer a particular source address prefix for use with a destination address prefix in [RFC6724]. In Rule 8 in [RFC6724], it is said that the longest matching prefix between source address of an IPv6 host and destination address is preferred among the combinations between other source addresses and destination address. Following Rules 6 and 8 may result in the selection of a source IP address with which packets that are sub-optimally routed. 3. Indications for expressing address preference requirement When an application prefers a new IP address of the requested IP address type, additional indication flags should be delivered through the socket API interface. To obtain an address that supports dynamic mobility using session- lasting IP address, a new address preference flag needs to be defined. The flag should be simple and useful while aligned with the three types of IP addresses. The objective of the hereby presented address preference flag is letting the IP stack check whether it has an available IP address assigned from the current serving network when the flag is received by an initiated application. If not, it Jeon, et al. Expires May 4, 2017 [Page 5] Internet-Draft Use Cases and API Extension October 2016 will trigger the IP stack to get a new IP address from the current serving network. We call it "ON_NET" property. If the application requests an IP address with ON_NET flag set in the socket request, the IP address returned by the stack should conform to the address preference requirement. This should be the case even though other session-lasting IP addresses, not belonging to the current serving network are available. If there are multiple session-lasting IP addresses matched with ON_NET property, the default source address selection rules will be applied. IPV6_XX_SRC_ON_NET /* Require (or Prefer) an IP address based on a requested IP address type as source, assigned from the current serving network, whatever it has been assigned or should be assigned */ This flag aims to express the preference to check an IP address, being used by an application, previously assigned from the current serving network and to use it or to get an IP address from the current serving network, as well as enabling differentiated per-flow anchoring where an obtained session-lasting IP address might be used for all initiated session-lasting IP applications. The use of the flag can be combined together with the three types of IP address defined in [I-D.ietf-dmm-ondemand-mobility]. In [I-D.mccann-dmm-prefixcost], it proposes that the Router Advertisement signaling messages communicate the cost of maintaining a given prefix at the MN's current point of attachment. The objective is to make a dynamic and optimal decision of address assignment and release, i.e. when to release old addresses and assign new ones. The proposed ON_NET property may present a way to deliver a prefix decision for an application, specifically from a routing distance point of view, to the IP stack. 4. IANA Considerations This document makes no request of IANA. 5. Security Considerations T.B.D. 6. Acknowledgements We would like to thank Danny Moses, Marco Liebsch, Brian Haberman, Sri Gundavelli, Alexandru Petrescu for their valueable comments and suggestions on this work. Jeon, et al. Expires May 4, 2017 [Page 6] Internet-Draft Use Cases and API Extension October 2016 7. References 7.1. Normative References [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, "Default Address Selection for Internet Protocol Version 6 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, . 7.2. Informative References [I-D.ietf-dmm-ondemand-mobility] Yegin, A., Moses, D., Kweon, K., Lee, J., and J. Park, "On Demand Mobility Management", draft-ietf-dmm-ondemand- mobility-07 (work in progress), July 2016. [I-D.mccann-dmm-prefixcost] McCann, P. and J. Kaippallimalil, "Communicating Prefix Cost to Mobile Nodes", draft-mccann-dmm-prefixcost-03 (work in progress), April 2016. Authors' Addresses Seil Jeon Sungkyunkwan University 2066 Seobu-ro, Jangan-gu Suwon, Gyeonggi-do Korea Email: seiljeon@skku.edu Sergio Figueiredo Altran Research 2, Rue Paul Dautier Velizy-Villacoublay 78140 France Email: sergio.figueiredo@altran.com Younghan Kim Soongsil University 369, Sangdo-ro, Dongjak-gu Seoul 156-743 Korea Email: younghak@ssu.ac.kr Jeon, et al. Expires May 4, 2017 [Page 7] Internet-Draft Use Cases and API Extension October 2016 John Kaippallimalil Huawei 5340 Legacy Dr., Suite 175 Plano, TX 75024 U.S Email: john.kaippallimalil@huawei.com Jeon, et al. Expires May 4, 2017 [Page 8]