--- 1/draft-ietf-dmm-ondemand-mobility-11.txt 2017-07-30 05:13:11.405653106 -0700 +++ 2/draft-ietf-dmm-ondemand-mobility-12.txt 2017-07-30 05:13:11.437653879 -0700 @@ -1,25 +1,25 @@ DMM Working Group A. Yegin Internet-Draft Actility Intended status: Informational D. Moses -Expires: December 26, 2017 Intel +Expires: January 31, 2018 Intel K. Kweon J. Lee J. Park Samsung S. Jeon Sungkyunkwan University - June 24, 2017 + July 30, 2017 On Demand Mobility Management - draft-ietf-dmm-ondemand-mobility-11 + draft-ietf-dmm-ondemand-mobility-12 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 by selectively providing IP session continuity and IP address reachability on a per- socket basis. @@ -32,21 +32,21 @@ 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, 2017. + This Internet-Draft will expire on January 31, 2018. Copyright Notice Copyright (c) 2017 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 @@ -63,31 +63,32 @@ 3. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Types of IP Addresses . . . . . . . . . . . . . . . . . . 4 3.2. Granularity of Selection . . . . . . . . . . . . . . . . 5 3.3. On Demand Nature . . . . . . . . . . . . . . . . . . . . 6 3.4. Conveying the Desired Address Type . . . . . . . . . . . 7 4. Usage example . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Backwards Compatibility Considerations . . . . . . . . . . . 10 5.1. Applications . . . . . . . . . . . . . . . . . . . . . . 10 5.2. IP Stack in the Mobile Host . . . . . . . . . . . . . . . 10 5.3. Network Infrastructure . . . . . . . . . . . . . . . . . 10 + 5.4. Merging this work with RFC5014 . . . . . . . . . . . . . 11 6. Summary of New Definitions . . . . . . . . . . . . . . . . . 11 6.1. New APIs . . . . . . . . . . . . . . . . . . . . . . . . 11 - 6.2. New Flags . . . . . . . . . . . . . . . . . . . . . . . . 11 - 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 - 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 - 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 12 - 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 - 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 - 11.1. Normative References . . . . . . . . . . . . . . . . . . 12 - 11.2. Informative References . . . . . . . . . . . . . . . . . 13 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 + 6.2. New Flags . . . . . . . . . . . . . . . . . . . . . . . . 12 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 + 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 13 + 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 + 11.1. Normative References . . . . . . . . . . . . . . . . . . 13 + 11.2. Informative References . . . . . . . . . . . . . . . . . 14 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 1. Introduction In the context of Mobile IP [RFC5563][RFC6275][RFC5213][RFC5944], the following two attributes are defined for IP service provided to mobile hosts: IP session continuity: The ability to maintain an ongoing IP session by keeping the same local end-point IP address throughout the session despite the mobile host changing its point of attachment within the @@ -305,21 +306,21 @@ Alternatively a new Socket API is defined - getsc() which allows applications to express their desired type of session continuity service. The new getsc() API will return an IPv6 address that is associated with the desired session continuity service and with status information indicating whether or not the desired service was provided. An application that wishes to secure a desired service will call getsc() with the service type definition and a place to contain the provided IP address, and call bind() to associate that IP address - with the Socket (See code example in Section 4 below). + with the Socket (See pseudo-code example in Section 4 below). When the IP stack is required to use a source IP address of a specified type, it can use an existing address, or request a new IP prefix (of the same type) from the network and create a new one. If the host does not already have an IPv6 prefix of that specific type, it must request one from the network. Using an existing address from an existing prefix is faster but might yield a less optimal route (if a hand-off event occurred after its configuration). On the other hand, acquiring a new IP prefix from @@ -330,21 +331,21 @@ preconfigured source IP address (if exists) or to request a new IPv6 prefix from the current serving network and configure a new IP address. This new flag is added to the set of flags in the IPV6_ADDR_PREFERENCES option at the IPPROTO_IPV6 level. It is used in setsockopt() to set the desired behavior. 4. Usage example - The following example shows the code for creating a Stream socket + The following example shows pseudo-code for creating a Stream socket (TCP) with a Session-Lasting source IP address: #include #include // Socket information int s ; // Socket id // Source information (for secsc() and bind()) sockaddr_in6 sourceInfo // my address and port for bind() @@ -459,20 +460,42 @@ host, the IP stack uses it and may not request a new one from the network. 5.3. Network Infrastructure The network infrastructure may or may not support the On-Demand functionality. How the IP stack on the host and the network infrastructure behave in case of a compatibility issue is outside the scope of this API specification. +5.4. Merging this work with RFC5014 + + [RFC5014] defines new flags that may be used with setsockopt() to + influence source IP address selection for a socket. The list of + flags include: source home address, care-of address, temporary + address, public address CGA (Cryptographically Created Address) and + non-CGA. When applications require session continuity service and + use setsc() and bind(), they should not set the flags specified in + [RFC5014]. + + However, if an application sets a specific option using setsockopt() + with one of the flags specified in [RFC5014] and also selects a + source IP address using setsc() and bind() the IP address that was + generated by setsc() and bound using bind() will be the one used by + traffic generated using that socket and options set by setsockopt() + will be ignored. + + If bind() was not invoked after setsc() by the application, the IP + address generated by setsc() will not be used and traffic generated + by the socket will use a source IP address that complies with the + options selected by setsockopt(). + 6. Summary of New Definitions 6.1. New APIs setsc() enables applications to request a specific type of source IP address in terms of session continuity. Its definition is: int setsc (int sockfd, in6_addr *sourceAddress, sc_type addressType) ; Where: @@ -489,20 +512,29 @@ 2 - SESSION_LASTING_IPV6_ADDRESS 3 - NON_PERSISTENT_IPV6_ADDRESS 4 - GRACEFUL_REPLACEMENT_IPV6_ADDRESS 5-7 - Reserved setsc() returns the status of the operation: - 0 - Address was successfully generated - EAI_REQUIREDIPNOTSUPPORTED - the required service type is not supported - EAI_REQUIREDIPFAILED - the network could not fulfill the desired request + setsc() may block the invoking thread if it triggers the TCP/IP stack + to request a new IP prefix from the network to construct the desired + source IP address. If an IP prefix with the desired session + continuity features already exists (was previously allocated to the + mobile host) and the stack is not required to request a new one as a + result of setting the IPV6_REQUIRE_SRC_ON_NET flag (defined below), + setsc() may return immediately with the constructed IP address and + will not block the thread. + 6.2. New Flags The following flag is added to the list of flags in the IPV6_ADDR_PREFERENCE option at the IPPROTO6 level: IPV6_REQUIRE_SRC_ON_NET - set IP stack address allocation behavior If set, the IP stack will request a new IPv6 prefix of the desired type from the current serving network and configure a new source IP address. If reset, the IP stack will use a preconfigured one if it