DMM S. Jeon Internet-Draft Instituto de Telecomunicacoes Intended status: Standards Track S. Figueiredo Expires: December 26, 2015 Altran Research Y. Kim Soongsil University June 24, 2015 Use Cases and API Extension for Source IP Address Selection draft-sijeon-dmm-use-cases-api-source-01.txt Abstract This draft specifies and analyzes the expected cases regarding the selection of a proper source IP address and address type based on the application features over a distributed mobility management (DMM) network. It also provides available selection methods to better achieve DMM goals in the specified scenarios. 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 December 26, 2015. Copyright Notice Copyright (c) 2015 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 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 Jeon, et al. Expires December 26, 2015 [Page 1] Internet-Draft Use Cases and API Extension June 2015 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. When an application does not have specific IP address type requirement and address preferences . . . . . . . . 3 2.2. When an application has specific IP address type requirement and address preference . . . . . . . . . . . 3 2.2.1. Case 1: there is no available IP address based on a requested type in the IP stack . . . . . . . . . . . 3 2.2.2. Case 2: there are one or more IP addresses based on 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 based on a requested type in the IP stack, but there is a further selection preference by the application . . . 4 3. Indications for expressing address preference requirement . . 5 3.1. When an application does not have specific IP address type requirement and address preferences . . . . . . . . 5 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 7.2. Informative References . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction In [I-D.ietf-dmm-ondemand-mobility], it suggests picking up a proper source IP address type for an initiated application in a mobile node (MN), taking into consideration the need of IP session continuity and/or IP address reachability by the application. Therefore, source IP addresses were defined in three types with regard to providing the required mobility management capabilities: fixed IP address, sustained IP address, and nomadic IP address. Following the on- demand mobility approach, the MN obtains a proper IP address corresponding to a specific address type requirement when an application tries to get an IP address, whereas the former approaches [RFC5014][RFC6724] operate on the available set of IP addresses, based on a preference. But even in the specific type of IP address request, there may be a need to indicate further requirements such as which IP address is preferred among the available IP addresses belonging to the same type requested by the application. Such a Jeon, et al. Expires December 26, 2015 [Page 2] Internet-Draft Use Cases and API Extension June 2015 situation may easily be met over a DMM network environment for some reasons such as QoS or Policy, as an MN is supposed to obtain new IP prefixes from the different serving networks to which it attaches. To check and reflect further requirements based on the IP address types defined in the on-demand mobility management, this draft specifies and describes expected use cases where an MN is likely to be encountered and proposes required extensions to fill the gaps found from the use cases study. 2. Use Cases We specify and analyze expected use cases where the MN tries to initiate an application. 2.1. When an application does not have specific IP address type requirement and address preferences Applications such as a text-based web browsing or information-centric service, e.g. weather and stock information may belong to this category. As many applications require simple Internet connectivity without session continuity and IP address reachability, assigning a nomadic IP address can be highly considered by default for MNs. But it is subject to address assignment policy by network operators. The suggested flag, IPV6_REQ_NOMADIC_IP, defined in [I-D.ietf-dmm-ondemand-mobility] is used for expressing its preference to the IP stack. 2.2. When an 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 available IP address based on a requested type in the IP stack For mobility support in terms of IP session continuity and IP address reachability, sustained IP address and fixed IP address are used. When one IP address of one of the two types is requested using flag IPV6_REQ_FIXED_IP or IPV6 REQ SUSTAINED IP, accordingly, a proper address assignment procedure based on DHCP or IP mobility management protocol is expected. Jeon, et al. Expires December 26, 2015 [Page 3] Internet-Draft Use Cases and API Extension June 2015 2.2.2. Case 2: there are one or more IP addresses based on a requested type in the IP stack, and no selection preference by the application In this case, the situation the MN meets is the same as Case 1 described above, except the availability of IP addresses belonging to the requested IP address type in the IP stack, e.g. due to different address assignment policy by an operator. Expected operation can be described as follows: 1. The MN is configured with one or more sustained IP addresses. 2. Once an application requests "sustained IP address" to the IP stack, it will use the existing sustained IP address when there is one sustained IP address available in the IP stack. If there are multiple available sustained 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. The MN moves to another serving network, while the previous (mobile) sessions are still working. A new application requests a sustained IP address with the address flag to the IP stack. The selection of the sustained IP address follows the same procedure as described in Step 2. 2.2.3. Case 3: there are one or more IP addresses based on a requested type in the IP stack, but there is a further selection preference by the application In case of sustained IP address, the procedure to assign and configure sustained IP addresses is the same as the procedure described in Case 2 when following the three types of IP addresses in [I-D.ietf-dmm-ondemand-mobility]. On one hand, the on-demand mobility is meant to enable application to have the desired mobility capability, i.e. IP address session continuity and/or IP address reachability, by proper selection of a source IP address. On the other hand, it needs to be extended to have dynamic mobility management capability, which should be considered when sustained IP address is used. The specified operation based on the definition of address flags in [I-D.ietf-dmm-ondemand-mobility] does not ensure the observation of dynamic mobility principle, where IP mobility is provided only upon an MN's movement. This is because an initiated application may be served with IP mobility even though the MN has not moved from the current serving network where the IP prefix/address was assigned for Jeon, et al. Expires December 26, 2015 [Page 4] Internet-Draft Use Cases and API Extension June 2015 the Application. As a result, IP mobility may be activated before needed, so the new session is served by a remote IP mobility anchor with necessary mobility management functions, though the MN has not moved yet. To make a proper way of delivering further preference of an application, additional definition for address selection preference in address flag level will help fill the requirement. See Section 3 for the proposed flag. 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. 3.1. When an application does not have specific IP address type requirement and address preferences To support dynamic mobility of an initiated application using sustained IP address, a new address preference flag needs to be defined. Definition of additional flag should be simple and useful while going along with the three types of IP addresses. But careful consideration may be needed in defining the level of address preference flag among "requirement" or "preference". 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 will trigger the IP stack to get a new IP address from the current serving network. We call it "ON_NET" property. If it is defined in the requirement level, the IP address confirmed to the address preference requirement should be used, though other sustained IP addresses, not assigned from the current serving network, are available. If there are multiple sustained IP addresses matched with ON_NET property, the default source address selection rules will be applied. If it is defined in the preference level, priority value for ON_NET flag should be determined among the other address preference flags defined in [RFC5014]. 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 */ Jeon, et al. Expires December 26, 2015 [Page 5] Internet-Draft Use Cases and API Extension June 2015 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 sustained IP address might be used for all initiated sustained 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]. 4. IANA Considerations This document makes no request of IANA. 5. Security Considerations T.B.D. 6. Acknowledgements 7. References 7.1. Normative References [I-D.ietf-dmm-ondemand-mobility] Yegin, A., Kweon, K., Lee, J., Park, J., and D. Moses, "On Demand Mobility Management", draft-ietf-dmm-ondemand- mobility-00 (work in progress), May 2015. [RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, "Default Address Selection for Internet Protocol Version 6 (IPv6)", RFC 6724, September 2012. 7.2. Informative References [RFC5014] Nordmark, E., Chakrabarti, S., and J. Laganier, "IPv6 Socket API for Source Address Selection", RFC 5014, September 2007. Authors' Addresses Seil Jeon Instituto de Telecomunicacoes Campus Universitario de Santiago Aveiro 3810-193 Portugal Email: seiljeon@av.it.pt Jeon, et al. Expires December 26, 2015 [Page 6] Internet-Draft Use Cases and API Extension June 2015 Sergio Figueiredo Altran Research 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 December 26, 2015 [Page 7]