draft-ietf-dmm-ondemand-mobility-07.txt		draft-ietf-dmm-ondemand-mobility-08.txt
	DMM Working Group A. Yegin		DMM Working Group A. Yegin
	Internet-Draft Actility		Internet-Draft Actility
	Intended status: Informational D. Moses		Intended status: Informational D. Moses
	Expires: January 7, 2017 Intel		Expires: June 1, 2017 Intel
	K. Kweon		K. Kweon
	J. Lee		J. Lee
	J. Park		J. Park
	Samsung		Samsung
	July 6, 2016		S. Jeon
			Sungkyunkwan University
			November 28, 2016
	On Demand Mobility Management		On Demand Mobility Management
	draft-ietf-dmm-ondemand-mobility-07		draft-ietf-dmm-ondemand-mobility-08
	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 43 ¶
	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 January 7, 2017.		This Internet-Draft will expire on June 1, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 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
	skipping to change at page 2, line 21 ¶		skipping to change at page 2, line 24 ¶
	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 . . . . . . . . . . . 8		4. Backwards Compatibility Considerations . . . . . . . . . . . 9
	4.1. Applications . . . . . . . . . . . . . . . . . . . . . . 8		4.1. Applications . . . . . . . . . . . . . . . . . . . . . . 9
	4.2. IP Stack in the Mobile Host . . . . . . . . . . . . . . . 9		4.2. IP Stack in the Mobile Host . . . . . . . . . . . . . . . 9
	4.3. Network Infrastructure . . . . . . . . . . . . . . . . . 9		4.3. Network Infrastructure . . . . . . . . . . . . . . . . . 10
	5. Summary of New Definitions . . . . . . . . . . . . . . . . . 9		5. Summary of New Definitions . . . . . . . . . . . . . . . . . 10
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 9		6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10		8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10		9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
	9.1. Normative References . . . . . . . . . . . . . . . . . . 10		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
	9.2. Informative References . . . . . . . . . . . . . . . . . 10		10.1. Normative References . . . . . . . . . . . . . . . . . . 11
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11		10.2. Informative References . . . . . . . . . . . . . . . . . 11
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
	1. Introduction		1. Introduction
	In the context of Mobile IP [RFC5563][RFC6275][RFC5213][RFC5944],		In the context of Mobile IP [RFC5563][RFC6275][RFC5213][RFC5944],
	following two attributes are defined for the IP service provided to		following two attributes are defined for the IP service provided to
	the mobile hosts:		the mobile hosts:
	IP session continuity: The ability to maintain an ongoing IP session		IP session continuity: The ability to maintain an ongoing IP session
	by keeping the same local end-point IP address throughout the session		by keeping the same local end-point IP address throughout the session
	despite the mobile host chaging its point of attachment within the IP		despite the mobile host changing its point of attachment within the
	network topology. The IP address of the host may change between two		IP network topology. The IP address of the host may change between
	independent IP sessions, but that does not jeopardize the IP session		two independent IP sessions, but that does not jeopardize the IP
	continuity. IP session continuity is essential for mobile hosts to		session continuity. IP session continuity is essential for mobile
	maintain ongoing flows without any interruption.		hosts to maintain ongoing flows without any interruption.
	IP address reachability: The ability to maintain the same IP address		IP address reachability: The ability to maintain the same IP address
	for an extended period of time. The IP address stays the same across		for an extended period of time. The IP address stays the same across
	independent IP sessions, and even in the absence of any IP session.		independent IP sessions, and even in the absence of any IP session.
	The IP address may be published in a long-term registry (e.g., DNS),		The IP address may be published in a long-term registry (e.g., DNS),
	and it is made available for serving incoming (e.g., TCP)		and it is made available for serving incoming (e.g., TCP)
	connections. IP address reachability is essential for mobile hosts		connections. IP address reachability is essential for mobile hosts
	to use specific/published IP addresses.		to use specific/published IP addresses.
	Mobile IP is designed to provide both IP session continuity and IP		Mobile IP is designed to provide both IP session continuity and IP
	skipping to change at page 3, line 31 ¶		skipping to change at page 3, line 36 ¶
	continuity is not required for all types of applications either.		continuity is not required for all types of applications either.
	Applications performing brief communication (e.g., DNS client) can		Applications performing brief communication (e.g., DNS client) can
	survive without having IP session continuity support.		survive without having IP session continuity support.
	Achieving IP session continuity and IP address reachability by using		Achieving IP session continuity and IP address reachability by using
	Mobile IP incurs some cost. Mobile IP protocol forces the mobile		Mobile IP incurs some cost. Mobile IP protocol forces the mobile
	host's IP traffic to traverse a centrally-located router (Home Agent,		host's IP traffic to traverse a centrally-located router (Home Agent,
	HA), which incurs additional transmission latency and use of		HA), which incurs additional transmission latency and use of
	additional network resources, adds to the network CAPEX and OPEX, and		additional network resources, adds to the network CAPEX and OPEX, and
	decreases the reliability of the network due to the introduction of a		decreases the reliability of the network due to the introduction of a
	single point of failure [I-D.ietf-dmm-requirements]. Therefore, IP		single point of failure [RFC7333]. Therefore, IP session continuity
	session continuity and IP address reachability should be be provided		and IP address reachability should be be provided only when needed.
	only when needed.
	Furthermore, when an application needs session continuity, it may be		Furthermore, when an application needs session continuity, it may be
	able to satisfy that need by using a solution above the IP layer,		able to satisfy that need by using a solution above the IP layer,
	such as MPTCP [RFC6824], SIP mobility [RFC3261], or an application-		such as MPTCP [RFC6824], SIP mobility [RFC3261], or an application-
	layer mobility solution. Those higher-layer solutions are not		layer mobility solution. Those higher-layer solutions are not
	subject to the same issues that arise with the use of Mobile IP since		subject to the same issues that arise with the use of Mobile IP since
	they can utilize the most direct data path between the end-points.		they can utilize the most direct data path between the end-points.
	But, if Mobile IP is being applied to the mobile host, those higher-		But, if Mobile IP is being applied to the mobile host, those higher-
	layer protocols are rendered useless because their operation is		layer protocols are rendered useless because their operation is
	inhibited by the Mobile IP. Since Mobile IP ensures the IP address		inhibited by the Mobile IP. Since Mobile IP ensures the IP address
	skipping to change at page 8, line 16 ¶		skipping to change at page 8, line 22 ¶
	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.
			When the IP stack is required to assign a source IP address of a
			specified type, it can perform one of the following: It can assigned
			a preconfigured address (if one exists) or request a new one from the
			network. Using an existing address is instantaneous but might yield
			a less optimal route (if a hand-off event occurred since its
			configuration), on the other hand, acquiring a new IP address from
			the network may take some time (due to signaling exchange with the
			network).
			An additional new flag - ON_NET flag - enables the application to
			direct the IP stack whether to use a preconfigured source IP address
			(if exists) or to request a new one from the current serving network:
			IPV6_REQUIRE_SRC_ON_NET /* Set IP stack address allocation behavior
			*/
			If set, the IP stack will request a new IP address of the desired
			type from the current serving network. If reset, the IP stack will
			use a preconfigured one if exists. If there is no preconfigured IP
			address of the desired type, the IP stack will request a new one from
			the current serving network (regardless of whether this flag is set
			or reset).
			The ON_NET flag must be used together with one of the 3 flags defined
			above. If ON_NET flag is used without any of these flags, it must be
			ignored. If the ON_NET flag is not used, the IP stack is free to
			either use an existing IP address (if preconfigured) or access the
			network to configure a new one (the decision is left to
			implementation).
	The following new error codes are also defined in the document and		The following new error codes are also defined in the document and
	will be used in the Socket API in compliance with [RFC5014].		will be used in the Socket API in compliance with [RFC5014].
	EAI_REQUIREDIPNOTSUPPORTED /* The network does not support the		EAI_REQUIREDIPNOTSUPPORTED /* The network does not support the
	ability to request that specific IP address type */		ability to request that specific IP address type */
	EAI_REQUIREDIPFAILED /* The network could not assign that specific IP		EAI_REQUIREDIPFAILED /* The network could not assign that specific IP
	address type */		address type */
	4. Backwards Compatibility Considerations		4. Backwards Compatibility Considerations
	skipping to change at page 9, line 36 ¶		skipping to change at page 10, line 20 ¶
	scope of this API specification.		scope of this API specification.
	5. Summary of New Definitions		5. Summary of New Definitions
	The following list summarizes the new constants definitions discussed		The following list summarizes the new constants definitions discussed
	in this memo:		in this memo:
	<netdb.h> IPV6_REQUIRE_FIXED_IP		<netdb.h> IPV6_REQUIRE_FIXED_IP
	<netdb.h> IPV6_REQUIRE_SESSION_LASTING_IP		<netdb.h> IPV6_REQUIRE_SESSION_LASTING_IP
	<netdb.h> IPV6_REQUIRE_NON_PERSISTENT_IP		<netdb.h> IPV6_REQUIRE_NON_PERSISTENT_IP
			<netdb.h> IPV6_REQUIRE_SRC_ON_NET
	<netdb.h> EAI_REQUIREDIPNOTSUPPORTED		<netdb.h> EAI_REQUIREDIPNOTSUPPORTED
	<netdb.h> EAI_REQUIREDIPFAILED		<netdb.h> EAI_REQUIREDIPFAILED
	<netinet/in.h> IPV6_REQUIRE_FIXED_IP		<netinet/in.h> IPV6_REQUIRE_FIXED_IP
	<netinet/in.h> IPV6_REQUIRE_SESSION_LASTING_IP		<netinet/in.h> IPV6_REQUIRE_SESSION_LASTING_IP
	<netinet/in.h> IPV6_REQUIRE_NON_PERSISTENT_IP		<netinet/in.h> IPV6_REQUIRE_NON_PERSISTENT_IP
			<netinet/in.h> IPV6_REQUIRE_SRC_ON_NET
	<netinet/in.h> EAI_REQUIREDIPNOTSUPPORTED		<netinet/in.h> EAI_REQUIREDIPNOTSUPPORTED
	<netinet/in.h> EAI_REQUIREDIPFAILED		<netinet/in.h> EAI_REQUIREDIPFAILED
	6. Security Considerations		6. Security Considerations
	The setting of certain IP address type on a given socket may be		The setting of certain IP address type on a given socket may be
	restricted to privileged applications. For example, a Fixed IP		restricted to privileged applications. For example, a Fixed IP
	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.
	7. IANA Considerations		7. IANA Considerations
	This document has no IANA considerations.		This document has no IANA considerations.
	8. Acknowledgements		8. Contributors
	We would like to thank Alexandru Petrescu, John Kaippallimalil, Jouni		This document was merged with [I-D.sijeon-dmm-use-cases-api-source].
	Korhonen, Seil Jeon, and Sri Gundavelli for their valuable comments		We would like to acknowledge the contribution of the following people
	and suggestions on this work.		to that document as well:
	9. References		Sergio Figueiredo
			Altran Research, France
			Email: sergio.figueiredo@altran.com
	9.1. Normative References		Younghan Kim
			Soongsil University, Korea
			Email: younghak@ssu.ac.kr
			John Kaippallimalil
			Huawei, USA
			Email: john.kaippallimalil@huawei.com
			9. Acknowledgements
			We would like to thank Alexandru Petrescu, Jouni Korhonen, and Sri
			Gundavelli for their valuable comments and suggestions on this work.
			10. References
			10.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>.
	[RFC5014] Nordmark, E., Chakrabarti, S., and J. Laganier, "IPv6		[RFC5014] Nordmark, E., Chakrabarti, S., and J. Laganier, "IPv6
	Socket API for Source Address Selection", RFC 5014,		Socket API for Source Address Selection", RFC 5014,
	DOI 10.17487/RFC5014, September 2007,		DOI 10.17487/RFC5014, September 2007,
	<http://www.rfc-editor.org/info/rfc5014>.		<http://www.rfc-editor.org/info/rfc5014>.
	[RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown,		[RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown,
	"Default Address Selection for Internet Protocol Version 6		"Default Address Selection for Internet Protocol Version 6
	(IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012,		(IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012,
	<http://www.rfc-editor.org/info/rfc6724>.		<http://www.rfc-editor.org/info/rfc6724>.
	9.2. Informative References		10.2. Informative References
	[I-D.ietf-dmm-requirements]		[I-D.sijeon-dmm-use-cases-api-source]
	Chan, A., Liu, D., Seite, P., Yokota, H., and J. Korhonen,		Jeon, S., Figueiredo, S., Kim, Y., and J. Kaippallimalil,
	"Requirements for Distributed Mobility Management", draft-		"Use Cases and API Extension for Source IP Address
	ietf-dmm-requirements-17 (work in progress), June 2014.		Selection", draft-sijeon-dmm-use-cases-api-source-05 (work
			in progress), October 2016.
	[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,		[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
	A., Peterson, J., Sparks, R., Handley, M., and E.		A., Peterson, J., Sparks, R., Handley, M., and E.
	Schooler, "SIP: Session Initiation Protocol", RFC 3261,		Schooler, "SIP: Session Initiation Protocol", RFC 3261,
	DOI 10.17487/RFC3261, June 2002,		DOI 10.17487/RFC3261, June 2002,
	<http://www.rfc-editor.org/info/rfc3261>.		<http://www.rfc-editor.org/info/rfc3261>.
	[RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V.,		[RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V.,
	Chowdhury, K., and B. Patil, "Proxy Mobile IPv6",		Chowdhury, K., and B. Patil, "Proxy Mobile IPv6",
	RFC 5213, DOI 10.17487/RFC5213, August 2008,		RFC 5213, DOI 10.17487/RFC5213, August 2008,
	skipping to change at page 11, line 28 ¶		skipping to change at page 12, line 34 ¶
	[RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility		[RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility
	Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July		Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July
	2011, <http://www.rfc-editor.org/info/rfc6275>.		2011, <http://www.rfc-editor.org/info/rfc6275>.
	[RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure,		[RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure,
	"TCP Extensions for Multipath Operation with Multiple		"TCP Extensions for Multipath Operation with Multiple
	Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013,		Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013,
	<http://www.rfc-editor.org/info/rfc6824>.		<http://www.rfc-editor.org/info/rfc6824>.
			[RFC7333] Chan, H., Ed., Liu, D., Seite, P., Yokota, H., and J.
			Korhonen, "Requirements for Distributed Mobility
			Management", RFC 7333, DOI 10.17487/RFC7333, August 2014,
			<http://www.rfc-editor.org/info/rfc7333>.
	Authors' Addresses		Authors' Addresses
	Alper Yegin		Alper Yegin
	Actility		Actility
	Istanbul		Istanbul
	Turkey		Turkey
	Email: alper.yegin@actility.com		Email: alper.yegin@actility.com
	Danny Moses		Danny Moses
	Intel Corporation		Intel Corporation
	Petah Tikva		Petah Tikva
	Israel		Israel
	Email: danny.moses@intel.com		Email: danny.moses@intel.com
	Kisuk Kweon		Kisuk Kweon
	Samsung		Samsung
	Suwon		Suwon
	skipping to change at line 530 ¶		skipping to change at page 13, line 31 ¶
	South Korea		South Korea
	Email: js81.lee@samsung.com		Email: js81.lee@samsung.com
	Jungshin Park		Jungshin Park
	Samsung		Samsung
	Suwon		Suwon
	South Korea		South Korea
	Email: shin02.park@samsung.com		Email: shin02.park@samsung.com
			Seil Jeon
			Sungkyunkwan University
			Suwon
			South Korea
			Email: seiljeon@skku.edu
End of changes. 21 change blocks.
	34 lines changed or deleted		90 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/