draft-ietf-dmm-ondemand-mobility-01.txt   draft-ietf-dmm-ondemand-mobility-02.txt 
DMM Working Group A. Yegin DMM Working Group A. Yegin
Internet-Draft Unaffiliated Internet-Draft Unaffiliated
Intended status: Standards Track K. Kweon Intended status: Standards Track K. Kweon
Expires: May 7, 2016 J. Lee Expires: August 21, 2016 J. Lee
J. Park J. Park
Samsung Samsung
D. Moses D. Moses
Intel Intel
November 4, 2015 February 18, 2016
On Demand Mobility Management On Demand Mobility Management
draft-ietf-dmm-ondemand-mobility-01 draft-ietf-dmm-ondemand-mobility-02
Abstract Abstract
Applications differ with respect to whether they need IP session Applications differ with respect to whether they need IP session
continuity and/or IP address reachability. The network providing the continuity and/or IP address reachability. The network providing the
same type of service to any mobile host and any application running same type of service to any mobile host and any application running
on the host yields inefficiencies. This document describes a on the host yields inefficiencies. This document describes a
solution for taking the application needs into account in selectively solution for taking the application needs into account in selectively
providing IP session continuity and IP address reachability on a per- providing IP session continuity and IP address reachability on a per-
socket basis. socket basis.
skipping to change at page 1, line 41 skipping to change at page 1, line 41
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." 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 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. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 21 skipping to change at page 2, line 21
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Notational Conventions . . . . . . . . . . . . . . . . . . . 4 2. Notational Conventions . . . . . . . . . . . . . . . . . . . 4
3. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Types of IP Addresses . . . . . . . . . . . . . . . . . . 4 3.1. Types of IP Addresses . . . . . . . . . . . . . . . . . . 4
3.2. Granularity of Selection . . . . . . . . . . . . . . . . 5 3.2. Granularity of Selection . . . . . . . . . . . . . . . . 5
3.3. On Demand Nature . . . . . . . . . . . . . . . . . . . . 5 3.3. On Demand Nature . . . . . . . . . . . . . . . . . . . . 5
3.4. Conveying the Selection . . . . . . . . . . . . . . . . . 6 3.4. Conveying the Selection . . . . . . . . . . . . . . . . . 6
4. Backwards Compatibility Considerations . . . . . . . . . . . 7 4. Backwards Compatibility Considerations . . . . . . . . . . . 8
4.1. Applications . . . . . . . . . . . . . . . . . . . . . . 8 4.1. Applications . . . . . . . . . . . . . . . . . . . . . . 8
4.2. IP Stack in the Mobile Host . . . . . . . . . . . . . . . 8 4.2. IP Stack in the Mobile Host . . . . . . . . . . . . . . . 8
4.3. Network Infrastructure . . . . . . . . . . . . . . . . . 8 4.3. Network Infrastructure . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . 9 8.1. Normative References . . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . 9 8.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction 1. Introduction
In the context of Mobile IP [RFC5563][RFC6275][RFC5213][RFC5944], In the context of Mobile IP [RFC5563][RFC6275][RFC5213][RFC5944],
skipping to change at page 7, line 18 skipping to change at page 7, line 18
addresses. The new flags force the IP stack to configure a compliant addresses. The new flags force the IP stack to configure a compliant
IP address if none is available at the time of the request. IP address if none is available at the time of the request.
- The Home vs. Care-of Address distinction is not sufficient to - The Home vs. Care-of Address distinction is not sufficient to
capture the three different types of IP addresses described in capture the three different types of IP addresses described in
Section 2.1. Section 2.1.
The following new flags are defined in this document and they shall The following new flags are defined in this document and they shall
be used with Socket API in compliance with the [RFC5014]: 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 Only one of these flags may be set on the same socket. If an
case, an IP address compliant with any one of them shall be selected. application attempts to set more than one flag, the most recent
TBD: Disallow this case? setting will be the one in effect.
When any of these new flags is used, then the IPV6_PREFER_SRC_HOME 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. and IPV6_PREFER_SRC_COA flags, if used, shall be ignored.
These new flags are used with setsockopt()/getsockopt(), These new flags are used with setsockopt()/getsockopt(),
getaddrinfo(), and inet6_is_srcaddr() functions [RFC5014]. Similar getaddrinfo(), and inet6_is_srcaddr() functions [RFC5014]. Similar
with the setsockopt()/getsockopt() calls, getaddrinfo() call shall with the setsockopt()/getsockopt() calls, getaddrinfo() call shall
also trigger configuration of the required type IP address, if one is also trigger configuration of the required type IP address, if one is
not already available. When the new flags are used with not already available. When the new flags are used with
getaddrinfo() and the triggered configuration fails, the getaddrinfo() and the triggered configuration fails, the
getaddrinfo() call shall ignore that failure (i.e., not return an getaddrinfo() call shall ignore that failure (i.e., not return an
error code to indicate that failure). Only the setsockopt() shall error code to indicate that failure). Only the setsockopt() shall
return an error when configuration of the requested type IP address return an error when configuration of the requested type IP address
fails. 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 4. Backwards Compatibility Considerations
Backwards compatibility support is required by the following 3 types Backwards compatibility support is required by the following 3 types
of entities: of entities:
- The Applications on the mobile host - The Applications on the mobile host
- The IP stack in the mobile host - The IP stack in the mobile host
- The network infrastructure - The network infrastructure
4.1. Applications 4.1. Applications
Legacy applications that do not support the new flags will use the 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 legacy API to the IP stack and will not enjoy On-Demand Mobility
feature. feature.
Applications using the new flags must be aware that they may be Applications using the new flags must be aware that they may be
executed in environments that do not support On-Demand Mobility executed in environments that do not support On-Demand Mobility
skipping to change at page 9, line 11 skipping to change at page 9, line 19
Address may be provided as a premium service and only certain Address may be provided as a premium service and only certain
applications may be allowed to use them. Setting and enforcement of applications may be allowed to use them. Setting and enforcement of
such privileges are outside the scope of this document. such privileges are outside the scope of this document.
6. IANA Considerations 6. IANA Considerations
TBD TBD
7. Acknowledgements 7. Acknowledgements
We would like to thank Alexandru Petrescu, Dapeng Liu, John We would like to thank Alexandru Petrescu, John Kaippallimalil, Jouni
Kaippallimalil, Jouni Korhonen, Seil Jeon, Sri Gundavelli, and Korhonen, Seil Jeon, and Sri Gundavelli for their valuable comments
Xinpeng Wei for their valuable comments and suggestions on this work. and suggestions on this work.
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
 End of changes. 14 change blocks. 
17 lines changed or deleted 26 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/