draft-ietf-dmm-ondemand-mobility-16.txt   draft-ietf-dmm-ondemand-mobility-17.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: August 12, 2019 Intel Expires: August 26, 2019 Intel
K. Kweon
J. Lee
J. Park
Samsung
S. Jeon S. Jeon
Sungkyunkwan University Sungkyunkwan University
February 8, 2019 February 22, 2019
On Demand Mobility Management On Demand Mobility Management
draft-ietf-dmm-ondemand-mobility-16 draft-ietf-dmm-ondemand-mobility-17
Abstract Abstract
Applications differ with respect to whether they need session Applications differ with respect to whether they need 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, as described in section 4 of on the host yields inefficiencies, as described in [RFC7333]. This
[RFC7333]. This document defines a new concep of enabling document defines a new concep of enabling applications to influence
applications to influence the network's mobility services (session the network's mobility services (session continuity and/or IP address
continuity and/or IP address reachability) on a per-Socket basis, and reachability) on a per-Socket basis, and suggests extensions to the
suggests extensions to the networking stack's API to accomodate this networking stack's API to accomodate this concept.
concept.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 August 12, 2019. This Internet-Draft will expire on August 26, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Notational Conventions . . . . . . . . . . . . . . . . . . . 4 2. Notational Conventions . . . . . . . . . . . . . . . . . . . 4
3. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. High-level Description . . . . . . . . . . . . . . . . . 4 3.1. High-level Description . . . . . . . . . . . . . . . . . 4
3.2. Types of IP Addresses . . . . . . . . . . . . . . . . . . 5 3.2. Types of IP Addresses . . . . . . . . . . . . . . . . . . 5
3.3. Granularity of Selection . . . . . . . . . . . . . . . . 7 3.3. Granularity of Selection . . . . . . . . . . . . . . . . 6
3.4. On Demand Nature . . . . . . . . . . . . . . . . . . . . 7 3.4. On Demand Nature . . . . . . . . . . . . . . . . . . . . 6
3.5. Conveying the Desired Address Type . . . . . . . . . . . 8 3.5. Conveying the Desired Address Type . . . . . . . . . . . 7
4. Usage example . . . . . . . . . . . . . . . . . . . . . . . . 9 4. Usage example . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Pseudo-code example . . . . . . . . . . . . . . . . . . . 9 4.1. Pseudo-code example . . . . . . . . . . . . . . . . . . . 8
4.2. Message Flow example . . . . . . . . . . . . . . . . . . 11 4.2. Message Flow example . . . . . . . . . . . . . . . . . . 10
5. Backwards Compatibility Considerations . . . . . . . . . . . 12 5. Backwards Compatibility Considerations . . . . . . . . . . . 12
5.1. Applications . . . . . . . . . . . . . . . . . . . . . . 12 5.1. Applications . . . . . . . . . . . . . . . . . . . . . . 12
5.2. IP Stack in the Mobile Host . . . . . . . . . . . . . . . 13 5.2. IP Stack in the Mobile Host . . . . . . . . . . . . . . . 12
5.3. Network Infrastructure . . . . . . . . . . . . . . . . . 13 5.3. Network Infrastructure . . . . . . . . . . . . . . . . . 13
5.4. Merging this work with RFC5014 . . . . . . . . . . . . . 13 5.4. Merging this work with RFC5014 . . . . . . . . . . . . . 13
6. Summary of New Definitions . . . . . . . . . . . . . . . . . 14 6. Summary of New Definitions . . . . . . . . . . . . . . . . . 13
6.1. New APIs . . . . . . . . . . . . . . . . . . . . . . . . 14 6.1. New APIs . . . . . . . . . . . . . . . . . . . . . . . . 13
6.2. New Flags . . . . . . . . . . . . . . . . . . . . . . . . 14 6.2. New Flags . . . . . . . . . . . . . . . . . . . . . . . . 14
7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 16
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
11.1. Normative References . . . . . . . . . . . . . . . . . . 16 11.1. Normative References . . . . . . . . . . . . . . . . . . 16
11.2. Informative References . . . . . . . . . . . . . . . . . 16 11.2. Informative References . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
In the context of Mobile IP [RFC5563][RFC6275][RFC5213][RFC5944], the In the context of Mobile IP [RFC5563][RFC6275][RFC5213][RFC5944], the
following two attributes are defined for IP service provided to following two attributes are defined for IP service provided to
mobile hosts: mobile hosts:
- Session Continuity - Session Continuity
skipping to change at page 3, line 39 skipping to change at page 3, line 27
essential for mobile hosts to use specific/published IP addresses. essential for mobile hosts to use specific/published IP addresses.
Mobile IP is designed to provide both session continuity and IP Mobile IP is designed to provide both session continuity and IP
address reachability to mobile hosts. Architectures utilizing these address reachability to mobile hosts. Architectures utilizing these
protocols (e.g., 3GPP, 3GPP2, WIMAX) ensure that any mobile host protocols (e.g., 3GPP, 3GPP2, WIMAX) ensure that any mobile host
attached to the compliant networks can enjoy these benefits. Any attached to the compliant networks can enjoy these benefits. Any
application running on these mobile hosts is subjected to the same application running on these mobile hosts is subjected to the same
treatment with respect to session continuity and IP address treatment with respect to session continuity and IP address
reachability. reachability.
In reality not every application may need these benefits. IP address
reachability is required for applications running as servers (e.g., a
web server running on the mobile host). But, a typical client
application (e.g., web browser) does not necessarily require IP
address reachability. Similarly, session continuity is not required
for all types of applications either. Applications performing brief
communication (e.g., text messaging) can survive without having
session continuity support.
Achieving session continuity and IP address reachability with Mobile Achieving session continuity and IP address reachability with Mobile
IP incurs some cost. Mobile IP protocol forces the mobile host's IP IP incurs some cost. Mobile IP protocol forces the mobile host's IP
traffic to traverse a centrally-located router (Home Agent, HA), traffic to traverse a centrally-located router (Home Agent, HA),
which incurs additional transmission latency and use of additional which incurs additional transmission latency and use of additional
network resources, adds to the network CAPEX and OPEX, and decreases network resources, adds to the network CAPEX and OPEX, and decreases
the reliability of the network due to the introduction of a single the reliability of the network due to the introduction of a single
point of failure [RFC7333]. Therefore, session continuity and IP point of failure [RFC7333]. Therefore, session continuity and IP
address reachability SHOULD be provided only when necessary. address reachability SHOULD be provided only when necessary.
In reality not every application may need these benefits. IP address
reachability is required for applications running as servers (e.g., a
web server running on the mobile host). But, a typical client
application (e.g., web browser) does not necessarily require IP
address reachability. Similarly, session continuity is not required
for all types of applications either. Applications performing brief
communication (e.g., text messaging) can survive without having
session continuity support.
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. These higher-layer solutions are not layer mobility solution. These 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, the higher- But, if Mobile IP is being applied to the mobile host, the higher-
layer protocols are rendered useless because their operation is layer protocols are rendered useless because their operation is
inhibited by Mobile IP. Since Mobile IP ensures that the IP address inhibited by Mobile IP. Since Mobile IP ensures that the IP address
of the mobile host remains fixed (despite the location and movement of the mobile host remains fixed (despite the location and movement
skipping to change at page 5, line 19 skipping to change at page 5, line 8
- The network stack sends a request to the network for a new source - The network stack sends a request to the network for a new source
IP prefix that is associated with the desired mobility service. IP prefix that is associated with the desired mobility service.
- The network responds with the suitable allocated source IP prefix - The network responds with the suitable allocated source IP prefix
(or responds with a failure indication). (or responds with a failure indication).
- If the suitable source IP prefix was allocates, the network stack - If the suitable source IP prefix was allocates, the network stack
constructs a source IP address and provides it to the application. constructs a source IP address and provides it to the application.
This document specifies the new address types (associated with This document specifies the new address types associated with
mobility services) and details the interaction between the mobility services and details the interaction between the
applications and the network stack steps. It uses the Socket applications and the network stack steps. It uses the Socket
interface as an example for an API between applications and the interface as an example for an API between applications and the
network stack. Other steps are outside the scope of this document. network stack. Other steps are outside the scope of this document.
3.2. Types of IP Addresses 3.2. Types of IP Addresses
Four types of IP addresses are defined with respect to mobility Four types of IP addresses are defined with respect to mobility
management. management.
- Fixed IP Address - Fixed IP Address
skipping to change at page 9, line 50 skipping to change at page 9, line 34
// ... // ...
} // if socket creation failed } // if socket creation failed
else { else {
// Socket creation is successful // Socket creation is successful
// The application cannot connect yet, since it wants to use // The application cannot connect yet, since it wants to use
// a Session-Lasting source IP address It needs to request // a Session-Lasting source IP address It needs to request
// the Session-Lasting source IP before connecting // the Session-Lasting source IP before connecting
if (setsc(s, &sourceAddress, &sc_type)) == 0){ if (setsc(s, &sourceAddress, &sc_type)) == 0){
// setting session continuity to Session Lasting is // setting session continuity to Session Lasting is
// Successful. sourceAddress now contains the Session- // Successful. sourceAddress now contains the Session-
// LAsting source IP address // Lasting source IP address
// Bind to that source IP address // Bind to that source IP address
sourceInfo.sin6_family = AF_INET6 ; sourceInfo.sin6_family = AF_INET6 ;
sourceInfo.sin6_port = 0 // let the stack choose the port sourceInfo.sin6_port = 0 // let the stack choose the port
sourceInfo.sin6_address = sourceAddress ; sourceInfo.sin6_address = sourceAddress ;
// Use the source address that was // Use the source address that was
// generated by the setsc() call // generated by the setsc() call
if (bind(s, &sourceInfo, sizeof(sourceInfo))==0){ if (bind(s, &sourceInfo, sizeof(sourceInfo))==0){
// Set the desired server's information for connect() // Set the desired server's information for connect()
serverInfo.sin6_family = AF_INET6 ; serverInfo.sin6_family = AF_INET6 ;
serverInfo.sin6_port = SERVER_PORT_NUM ; serverInfo.sin6_port = SERVER_PORT_NUM ;
skipping to change at page 12, line 47 skipping to change at page 12, line 33
- The IP stack in the mobile host - The IP stack in the mobile host
- The network infrastructure - The network infrastructure
5.1. Applications 5.1. Applications
Legacy applications that do not support the On-Demand functionality Legacy applications that do not support the On-Demand functionality
will use the legacy API and will not be able to take advantage of the will use the legacy API and will not be able to take advantage of the
On-Demand Mobility feature. On-Demand Mobility feature.
Applications using the new On-Demand functionality MUST be aware that Applications using the new On-Demand functionality should be aware
they may be executed in legacy environments that do not support it. that they may be executed in legacy environments that do not support
Such environments may include a legacy IP stack on the mobile host, it. Such environments may include a legacy IP stack on the mobile
legacy network infrastructure, or both. In either case, the API will host, legacy network infrastructure, or both. In either case, the
return an error code and the invoking applications may just give up API will return an error code and the invoking applications may just
and use legacy calls. give up and use legacy calls.
5.2. IP Stack in the Mobile Host 5.2. IP Stack in the Mobile Host
New IP stacks MUST continue to support all legacy operations. If an New IP stacks (that implement On Demand functionality) MUST continue
application does not use On-Demand functionality, the IP stack MUST to support all legacy operations. If an application does not use On-
respond in a legacy manner. Demand functionality, the IP stack MUST respond in a legacy manner.
If the network infrastructure supports On-Demand functionality, the If the network infrastructure supports On-Demand functionality, the
IP stack SHOULD follow the application request: If the application IP stack SHOULD follow the application request: If the application
requests a specific address type, the stack SHOULD forward this requests a specific address type, the stack SHOULD forward this
request to the network. If the application does not request an request to the network. If the application does not request an
address type, the IP stack MUST NOT request an address type and leave address type, the IP stack MUST NOT request an address type and leave
it to the network's default behavior to choose the type of the it to the network's default behavior to choose the type of the
allocated IP prefix. If an IP prefix was already allocated to the allocated IP prefix. If an IP prefix was already allocated to the
host, the IP stack uses it and may not request a new one from the host, the IP stack uses it and may not request a new one from the
network. network.
skipping to change at page 15, line 4 skipping to change at page 14, line 45
result of setting the IPV6_REQUIRE_SRC_ON_NET flag (defined below), result of setting the IPV6_REQUIRE_SRC_ON_NET flag (defined below),
setsc() MAY return immediately with the constructed IP address and setsc() MAY return immediately with the constructed IP address and
will not block the thread. will not block the thread.
6.2. New Flags 6.2. New Flags
The following flag is added to the list of flags in the The following flag is added to the list of flags in the
IPV6_ADDR_PREFERENCE option at the IPPROTO6 level: IPV6_ADDR_PREFERENCE option at the IPPROTO6 level:
IPV6_REQUIRE_SRC_ON_NET - set IP stack address allocation behavior 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 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 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 address. If reset, the IP stack will use a preconfigured one if it
exists. If there is no preconfigured IP address of the desired type, exists. If there is no preconfigured IP address of the desired type,
a new prefix will be requested and used for creating the IP address. a new prefix will be requested and used for creating the IP address.
7. Security Considerations 7. Security Considerations
The setting of certain IP address type on a given socket may be The different service types (session continuity types and address
restricted to privileged applications. For example, a Fixed IP reachability) associated with the allocated IP address types, may be
Address may be provided as a premium service and only certain associated with different costs. The cost to the operator for
applications may be allowed to use them. Setting and enforcement of enabling a type of service, and the cost to applications using a
such privileges are outside the scope of this document. selected service. A malicious application may use these to generate
extra billing of a mobile subscriber, and/or impose costly services
on the mobile operator. When costly services are limited, malicious
applications may exhaust them, preventing other applications on the
same mobile host from being able to use them.
Mobile hosts that enables such service options, should provide
capabilities for ensuring that only authorized applications can use
the costly (or limited) service types.
The ability to select service types requires the exchange of the
association of source IP prefixes and their corresponding service
types, between the mobile host and mobile network. Exposing these
associations may provide information to passive attackers even if the
traffic that is used with these addressed is encrypted.
To avoid profiling an application according to the type of IP
addresses, it is expected that prefixes provided by the mobile
operator are associated to various type of addresses over time. As a
result, the type of address could not be associated to the prefix,
making application profiling based on the type of address harder.
The application or the OS should ensure that IP addresses regularly
change to limit IP tracking by a passive observer. The application
should regularly set the On Demand flag. The application should be
able to ensure that session lasting IP addresses are regularly
changed by setting a lifetime for example handled by the application.
In addition, the application should consider the use of graceful
replacement IP addresses.
Similarly, the OS may also associated IP addresses with a lifetime.
Upon receiving a request for a given type of IP address, after some
time, the OS should request a new address to the network even if it
already has one IP address available with the requested type. This
includes any type of IP address. IP addresses of type graceful
replacement or non persistent should be regularly renewed by the OS.
The lifetime of an IP address may be expressed in number of seconds
or in number of bytes sent through this IP address.
8. IANA Considerations 8. IANA Considerations
This document has no IANA considerations. This document has no IANA considerations.
9. Contributors 9. Contributors
This document was merged with [I-D.sijeon-dmm-use-cases-api-source]. This document was merged with [I-D.sijeon-dmm-use-cases-api-source].
We would like to acknowledge the contribution of the following people We would like to acknowledge the contribution of the following people
to that document as well: to that document as well:
skipping to change at page 15, line 43 skipping to change at page 16, line 30
Soongsil University, Korea Soongsil University, Korea
Email: younghak@ssu.ac.kr Email: younghak@ssu.ac.kr
John Kaippallimalil John Kaippallimalil
Huawei, USA Huawei, USA
Email: john.kaippallimalil@huawei.com Email: john.kaippallimalil@huawei.com
10. Acknowledgements 10. Acknowledgements
We would like to thank Wu-chi Feng, Alexandru Petrescu, Jouni We would like to thank Wu-chi Feng, Alexandru Petrescu, Jouni
Korhonen, Sri Gundavelli, Dave Dolson and Lorenzo Colitti for their Korhonen, Sri Gundavelli, Dave Dolson Lorenzo Colitti and Daniel
valuable comments and suggestions on this work. Migault for their valuable comments and suggestions on this work.
11. References 11. References
11.1. Normative References 11.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,
<https://www.rfc-editor.org/info/rfc2119>. <https://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,
skipping to change at page 17, line 31 skipping to change at page 18, line 18
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
Samsung
Suwon
South Korea
Email: kisuk.kweon@samsung.com
Jinsung Lee
Samsung
Suwon
South Korea
Email: js81.lee@samsung.com
Jungshin Park
Samsung
Suwon
South Korea
Email: shin02.park@samsung.com
Seil Jeon Seil Jeon
Sungkyunkwan University Sungkyunkwan University
Suwon Suwon
South Korea South Korea
Email: seiljeon@skku.edu Email: seiljeon@skku.edu
 End of changes. 22 change blocks. 
77 lines changed or deleted 93 lines changed or added

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