--- 1/draft-ietf-dmm-ondemand-mobility-01.txt 2016-02-18 08:15:06.163396090 -0800 +++ 2/draft-ietf-dmm-ondemand-mobility-02.txt 2016-02-18 08:15:06.199397008 -0800 @@ -1,23 +1,23 @@ DMM Working Group A. Yegin Internet-Draft Unaffiliated Intended status: Standards Track K. Kweon -Expires: May 7, 2016 J. Lee +Expires: August 21, 2016 J. Lee J. Park Samsung D. Moses Intel - November 4, 2015 + February 18, 2016 On Demand Mobility Management - draft-ietf-dmm-ondemand-mobility-01 + draft-ietf-dmm-ondemand-mobility-02 Abstract Applications differ with respect to whether they need IP session continuity and/or IP address reachability. The network providing the same type of service to any mobile host and any application running on the host yields inefficiencies. This document describes a solution for taking the application needs into account in selectively providing IP session continuity and IP address reachability on a per- socket basis. @@ -30,25 +30,25 @@ 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 7, 2016. + This Internet-Draft will expire on August 21, 2016. Copyright Notice - Copyright (c) 2015 IETF Trust and the persons identified as the + 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 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 @@ -56,25 +56,25 @@ Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Notational Conventions . . . . . . . . . . . . . . . . . . . 4 3. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Types of IP Addresses . . . . . . . . . . . . . . . . . . 4 3.2. Granularity of Selection . . . . . . . . . . . . . . . . 5 3.3. On Demand Nature . . . . . . . . . . . . . . . . . . . . 5 3.4. Conveying the Selection . . . . . . . . . . . . . . . . . 6 - 4. Backwards Compatibility Considerations . . . . . . . . . . . 7 + 4. Backwards Compatibility Considerations . . . . . . . . . . . 8 4.1. Applications . . . . . . . . . . . . . . . . . . . . . . 8 4.2. IP Stack in the Mobile Host . . . . . . . . . . . . . . . 8 4.3. Network Infrastructure . . . . . . . . . . . . . . . . . 8 - 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 8.2. Informative References . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction In the context of Mobile IP [RFC5563][RFC6275][RFC5213][RFC5944], @@ -294,54 +294,63 @@ addresses. The new flags force the IP stack to configure a compliant IP address if none is available at the time of the request. - The Home vs. Care-of Address distinction is not sufficient to capture the three different types of IP addresses described in Section 2.1. The following new flags are defined in this document and they shall be used with Socket API in compliance with the [RFC5014]: - IPV6_REQ_FIXED_IP /* Require a Fixed IP address as source */ + IPV6_REQUIRE_FIXED_IP /* Require a Fixed IP address as source */ - IPV6_REQ_SUSTAINED_IP /* Require a Sustained IP addr. as source */ + IPV6_REQUIRE_SUSTAINED_IP /* Require a Sustained IP address as source + */ - IPV6_REQ_NOMADIC_IP /* Require a Nomadic IP address as source */ + IPV6_REQUIRE_NOMADIC_IP /* Require a Nomadic IP address as source */ - More than one of these flags may be set on the same socket. In that - case, an IP address compliant with any one of them shall be selected. - TBD: Disallow this case? + Only one of these flags may be set on the same socket. If an + application attempts to set more than one flag, the most recent + setting will be the one in effect. When any of these new flags is used, then the IPV6_PREFER_SRC_HOME and IPV6_PREFER_SRC_COA flags, if used, shall be ignored. These new flags are used with setsockopt()/getsockopt(), getaddrinfo(), and inet6_is_srcaddr() functions [RFC5014]. Similar with the setsockopt()/getsockopt() calls, getaddrinfo() call shall also trigger configuration of the required type IP address, if one is not already available. When the new flags are used with getaddrinfo() and the triggered configuration fails, the getaddrinfo() call shall ignore that failure (i.e., not return an error code to indicate that failure). Only the setsockopt() shall return an error when configuration of the requested type IP address fails. - Application of this solution to IPv4 is TBD. + The following new error codes are also defined in the document and + will be used in the Socket API in compliance with [RFC5014]. + + EAI_REQUIREDIPNOTSUPPORTED /* The network does not support the + ability to request that specific IP address type */ + + EAI_REQUIREDIPFAILED /* The network could not assign that specific IP + address type */ 4. Backwards Compatibility Considerations Backwards compatibility support is required by the following 3 types of entities: - The Applications on the mobile host - The IP stack in the mobile host + - The network infrastructure 4.1. Applications Legacy applications that do not support the new flags will use the legacy API to the IP stack and will not enjoy On-Demand Mobility feature. Applications using the new flags must be aware that they may be executed in environments that do not support On-Demand Mobility @@ -379,23 +388,23 @@ Address may be provided as a premium service and only certain applications may be allowed to use them. Setting and enforcement of such privileges are outside the scope of this document. 6. IANA Considerations TBD 7. Acknowledgements - We would like to thank Alexandru Petrescu, Dapeng Liu, John - Kaippallimalil, Jouni Korhonen, Seil Jeon, Sri Gundavelli, and - Xinpeng Wei for their valuable comments and suggestions on this work. + We would like to thank Alexandru Petrescu, John Kaippallimalil, Jouni + Korhonen, Seil Jeon, and Sri Gundavelli for their valuable comments + and suggestions on this work. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, .