RFC 8653

On-Demand Mobility Management

📅 published October 2019, from ietf

RFC 8653: On-Demand Mobility Management 🦋

okay bestie, this is RFC 8653, On-Demand Mobility Management, an Informational doc from October 2019 💖 It was written by A. Yegin (Actility), D. Moses (Intel), and S. Jeon (Sungkyunkwan University). It's ISSN 2070-1721, and its header doesn't list any Obsoletes or Updates entries, so it isn't replacing or changing anything else 💅

Abstract 🌸

okay so applications don't all need the same stuff. some need session continuity and/or IP address reachability, and some don't. if the network gives every mobile host and every app on it the same type of service, things get inefficient, as described in RFC 7333 😭 this document introduces a new concept where applications can influence the network's mobility services (session continuity and/or IP address reachability) on a per-socket basis, and it suggests extensions to the networking stack's API so this can actually happen 🧚

Status of This Memo ✨

this is not an Internet Standards Track spec. it's published for informational purposes 📝

this doc is a product of the Internet Engineering Task Force (IETF). it represents the consensus of the IETF community, and it got public review and was approved for publication by the Internet Engineering Steering Group (IESG). not every IESG-approved doc is a candidate for any level of Internet Standard, so check Section 2 of RFC 7841 for the details 🙈

if you want the current status, any errata, or a way to send feedback, go to https://www.rfc-editor.org/info/rfc8653 🔥

Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.

this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they're in effect on the publication date. please read them carefully because they describe your rights and restrictions for this doc. code components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they're provided without warranty as described in the Simplified BSD License 🎀

Table of Contents 🍓

1.  Introduction
2.  Notational Conventions
3.  Solution
  3.1.  High-Level Description
  3.2.  Types of IP Addresses
  3.3.  Granularity of Selection
  3.4.  On-Demand Nature
4.  Backwards Compatibility Considerations
  4.1.  Applications
  4.2.  IP Stack in the Mobile Host
  4.3.  Network Infrastructure
  4.4.  Merging this work with RFC 5014
5.  Security Considerations
6.  IANA Considerations
7.  References
  7.1.  Normative References
  7.2.  Informative References
Appendix A.  Conveying the Desired Address Type
Acknowledgements
Contributors
Authors' Addresses

1. Introduction 🎀

okay so in the world of Mobile IP [RFC5563] [RFC6275] [RFC5213] [RFC5944], there are two attributes for IP service given to mobile hosts. they're literally the main character attributes 👑

Session Continuity 🦋 this is the ability to keep an ongoing transport interaction going by holding on to the same local endpoint IP address for the whole lifetime of the IP socket, even when the mobile host switches its point of attachment in the IP network topology. the host's IP address is allowed to change after the socket is closed and before a new one opens, and that doesn't mess up apps using these sockets, they still work flawlessly ✨ session continuity is essential for mobile hosts that need ongoing flows with zero interruption 😭

IP Address Reachability 🌈 this is the ability to keep the same IP address for a long time. the address stays the same across independent sessions, even when there's no session at all. the address may get published in a long-term registry (e.g., DNS) and made available for serving incoming (e.g., TCP) connections. IP address reachability is essential for mobile hosts that use specific or published IP addresses 💅

Mobile IP is built to give mobile hosts both session continuity and IP address reachability. architectures that use these protocols (e.g., 3GPP, 3GPP2, WiMAX) make sure that any mobile host attached to a compliant network can enjoy these benefits. every app running on these mobile hosts gets the same treatment when it comes to session continuity and IP address reachability 🧚

but here's the tea ☕ getting both with Mobile IP has a cost. Mobile IP forces the mobile host's IP traffic to go through a centrally located router (Home Agent, HA). that adds extra transmission latency and uses extra network resources, it bumps up the network's operating and capital expenditures, and it lowers reliability because it creates a single point of failure [RFC7333]. so session continuity and IP address reachability SHOULD be provided only when necessary 🙈

not every app is going to need these benefits, though. IP address reachability is required for applications running as servers (e.g., a web server running on the mobile host), but a typical client app (e.g., a web browser) doesn't necessarily need IP address reachability. session continuity isn't required for every type of app either. apps doing brief communication (e.g., text messaging) can survive without session continuity support 💀

and when an app does need session continuity, it might be able to get it from a solution above the IP layer, like Multipath TCP [RFC6824], SIP mobility [RFC3261], or an application-layer mobility solution 🫶 these higher-layer solutions don't have the same issues as Mobile IP because they can use the most direct data path between the endpoints. but if Mobile IP is applied to the mobile host, the higher-layer protocols become useless because Mobile IP inhibits their operation. since Mobile IP keeps the mobile host's IP address fixed (no matter where the host is or how it moves), the higher-layer protocols never detect the IP-layer change and never get to do any mobility management 😭

this document proposes a solution so applications running on mobile hosts can say, when they set up the network connection ('on demand'), whether they need session continuity or IP address reachability. the network protocol stack on the mobile host works together with the network infrastructure to provide the required type of service. it's good for both users and network operators not to turn on an extra level of service unless it's absolutely necessary. applications and networks that follow this spec are expected to use this solution to use network resources more efficiently 🌸

2. Notational Conventions 📝

okay so the BCP 14 key words are these, and they're interpreted as described in BCP 14 [RFC2119] [RFC8174]: "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL". they only count as key words when they show up in all caps, like in that list. 🔥

3. Solution 🧚

3.1. High-Level Description 💅

enabling apps to say what their mobility service requirements are (e.g., session continuity and/or IP address reachability) involves these steps:

  1. the application tells the network stack (local to the mobile host) which mobility service it wants.
  2. the network stack assigns a source IP address based on an IP prefix that has the desired services and was already provided by the network. if there's no such IP prefix available, the network stack does the additional steps below.
  3. the network stack sends a request to the network for a new source IP prefix that's associated with the desired mobility service.
  4. the network responds with the suitable allocated source IP prefix (or with a failure indication).
  5. if the suitable source IP prefix was allocated, the network stack builds a source IP address and gives it to the application.

this document specifies the new address types associated with mobility services and details how apps and the network stack interact during these steps. it uses the socket interface as an example of an API between applications and the network stack. other steps are outside the scope of this document ✨

3.2. Types of IP Addresses ✨

okay so, mobility management has four types of IP addresses bestie, and they each have their own vibe 💅

  • Fixed IP address: this one is guaranteed to stay valid for a very long time 🔒. It doesn't matter if it's being used in any packet to or from the mobile host, if the mobile host is connected to the network or not, or if it moves to a new point of attachment (with a different IP prefix) while it's connected. Fixed IP addresses are required by applications that need both session continuity and IP address reachability 👑
  • Session-Lasting IP address: this one is guaranteed to stay valid for the lifetime of the socket(s) it was requested for 🧚 It's still valid even after the mobile host moves to a new point of attachment (with a different IP prefix). Session-Lasting IP addresses are required by applications that need session continuity but don't need IP address reachability 🦋
  • Nonpersistent IP address: not gonna lie, this one is lowkey unreliable 💀 It's not guaranteed to exist after the mobile host moves to a new point of attachment, so there's no session continuity and no IP address reachability. The IP address is created from an IP prefix obtained from the serving IP gateway, and that prefix isn't maintained across gateway changes. In other words, the IP prefix may get released and replaced with a new one when the IP gateway changes because the mobile host moved. That forces the creation of a new source IP address using the updated allocated IP prefix 🍓
  • Graceful-Replacement IP address: in some cases the network can't guarantee that the IP prefix stays valid for the whole time the socket is open, but it can give a limited grace period where both the original IP prefix and a new one are valid 🌈 That gives the application some flexibility to switch from the existing source IP address to the new one. This gracefulness is still better than the nonpersistent type for applications that can handle a change in their source IP address but still want that extra flexibility 🫶

Applications running as servers at a published IP address require a Fixed IP address. Long-standing applications (e.g., an SSH session) may also require this type of address. Enterprise applications that connect to an enterprise network via virtual LAN require a Fixed IP address 🎀

Applications with short-lived transient sessions (e.g., web browsers) can use Session-Lasting IP addresses 🌸

Applications with very short sessions, such as DNS clients and instant messengers, can use Nonpersistent IP addresses ⭐ They could totally use Fixed or Session-Lasting IP addresses too, but the transmission latency gets minimized when a Nonpersistent IP address is used. Literally the efficient choice 😭

Applications that can tolerate a short interruption in connectivity can use the Graceful-Replacement IP addresses. A streaming client with buffering capabilities is a good example 🎧

3.3. Granularity of Selection

IP address type selection is made on a per-socket granularity 🔥 Different parts of the same application can have different needs. For example, the control plane of an application may require a Fixed IP address so it stays reachable, while the data plane of that same application may be happy with a Session-Lasting IP address 💜

3.4. On-Demand Nature

At any point in time, a mobile host may have a combination of IP addresses configured 🌈 Zero or more Fixed, zero or more Session-Lasting, zero or more Nonpersistent, and zero or more Graceful-Replacement IP addresses may be configured by the IP stack of the host. The combination can come from host policy, application demand, or a mix of the two ✨

When an application requires a specific type of IP address, and that address isn't already configured on the host, the IP stack SHALL attempt to configure one 💖 For example, a host may not always have a Session-Lasting IP address available. When an application requests one, the IP stack SHALL make an attempt to configure one by sending a request to the network. If the operation fails, the IP stack SHALL fail the associated socket request and return an error 🙈 If it works, a Session-Lasting IP address is configured on the mobile host. If another socket requests a Session-Lasting IP address later, the same IP address may be served to that socket too. When the last socket using the configured IP address is closed, the IP address may be released, or it may be kept for applications that need a Session-Lasting IP address and might launch in the future 🦋

Sometimes it might be better for the mobile host to request a new Session-Lasting IP address for a new opening of an IP socket, even though the network already assigned one to the mobile host that might be in use by a different, already active IP socket 🤔 It's outside the scope of this specification to define criteria for choosing between using available addresses and requesting new ones. It supports both alternatives, and any combination of them 💅

It's also outside the scope of this specification to define how the host requests a specific type of prefix, and how the network indicates the type of prefix in its advertisement or in its reply to a request 🧚

The following are matters of policy, which may be dictated by the host itself, the network operator, or the system architecture standard:

  • The initial set of IP addresses configured on the host at boot time
  • Permission to grant various types of IP addresses to a requesting application
  • Determination of a default address type when an application does not explicitly indicate whether it supports the required API or is a legacy application

4. Backwards Compatibility Considerations ✨

Backwards compatibility support is REQUIRED by the following three 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 don't support the On-Demand functionality will use the legacy API and won't be able to take advantage of the On-Demand Mobility feature 🙈

Applications using the new On-Demand functionality should be aware that they may be executed in legacy environments that don't support it 😭 Those environments may include a legacy IP stack on the mobile host, legacy network infrastructure, or both. In either case the API returns an error code, and the invoking application may just give up and use legacy calls 💀

4.2. IP Stack in the Mobile Host

New IP stacks (the ones that implement On-Demand functionality) MUST continue to support all legacy operations 👑 If an application doesn't use On-Demand functionality, the IP stack MUST respond in a legacy manner 🎀

If the network infrastructure supports On-Demand functionality, the IP stack SHOULD follow the application request. If the application requests a specific address type, the stack SHOULD forward that request to the network 🌸 If the application doesn't request an address type, the IP stack MUST NOT request an address type. Instead, the network chooses the type of allocated IP prefix. How the network selects that type is outside the scope of this document 🧚 If an IP prefix was already allocated to the host, the IP stack uses it and may not request a new one from the network 🍓

4.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 🌈

4.4. Merging this work with RFC 5014

[RFC5014] defines new flags that may be used with setsockopt() to influence source IP address selection for a socket 💅 The list of flags includes: source home address, care-of address, temporary address, public address CGA (Cryptographically Created Address), and non-CGA. When applications require session continuity service, they SHOULD NOT set the flags specified in [RFC5014] 🦋

However, if an application erroneously does both (1) uses setsockopt() to set a specific option (using one of the flags specified in [RFC5014]) and (2) selects a source IP address type, the IP stack fulfills the request in (2) and ignores the flags set in (1) 🙈

5. Security Considerations 💀

Okay bestie, this part is serious 😭 The different service types (session continuity types and address reachability) tied to the allocated IP address types may come with different costs: the cost to the operator of enabling a type of service, and the cost to applications using a selected service. A malicious application may use these to indirectly generate extra billing of a mobile subscriber, and/or impose costly services on the mobile operator. When expensive services are limited, malicious applications may exhaust them, which stops other applications on the same mobile host from using them 🚨

Mobile hosts that enable these service options should provide capabilities to make sure only authorized applications can use the expensive (or limited) service types 🔐

The ability to select service types requires exchanging the association between source IP prefixes and their corresponding service types, between the mobile host and the mobile network. Exposing these associations may give information to passive attackers, even if the traffic using these addresses is encrypted 👀

To avoid profiling an application by its type of IP address, it's expected that prefixes provided by the mobile operator get associated with various types of addresses over time 🌈 As a result, the type of address can't be tied to the prefix, which makes application profiling based on the type of address harder 💅

The application or the OS should make sure IP addresses change regularly to limit IP tracking by a passive observer 🕵️‍♀️ The application should regularly set the On-Demand flag. The application should be able to make sure Session-Lasting IP addresses are changed regularly by setting a lifetime, for example one handled by the application. Also, the application should consider using Graceful-Replacement IP addresses ✨

Similarly, the OS may also associate IP addresses with a lifetime. After receiving a request for a given type of IP address, the OS should, after some time, request a new address from the network even if it already has an available IP address of the requested type. This includes any type of IP address. IP addresses of type Graceful-Replacement or nonpersistent should be renewed regularly by the OS 🔄

The lifetime of an IP address may be expressed in seconds or in the number of bytes sent through that IP address ⏳

6. IANA Considerations 🎀

This document has no IANA actions 🌸

7. References 📚

7.1. Normative References

7.2. Informative References

Appendix A. Conveying the Desired Address Type 🎀

Okay, bestie, this appendix is basically a wishlist of suggestions for how apps could tell the socket API what kind of address they need for session continuity and reachability. Nothing here is mandatory, just ideas. 💡

[RFC5014] is the one that first let apps influence source address selection, using the IPV6_ADDR_PREFERENCE option at the IPPROTO_IPV6 level. You use it with setsockopt() and getsockopt() to set or get those address selection preferences. Iconic foundation, no notes. 👑

Option one: extend IPV6_ADDR_REFERENCE with flags that show what the caller actually wants. An OnDemand field could hold one of these values: FIXED_IP_ADDRESS, SESSION_LASTING_IP_ADDRESS, NON_PERSISTENT_IP_ADDRESS, or GRACEFUL_REPLACEMENT_IP_ADDRESS. Main character energy in the flag department. ✨

Option two: make a brand-new socket function so the caller can state its desire. This makes two behaviours of socket functions possible. The existing setsockopt() returns as soon as it runs. The new setsc() (Set Service Continuity) may kick off a request for the desired service and then wait until the network answers with the allocated resources before it returns to the caller. 🦋

Once the application has an IP address with the behaviour it asked for, it can call the bind() socket function to attach that address to the socket. 🫶

Acknowledgements 🌸

We would like to thank Wu-chi Feng, Alexandru Petrescu, Jouni Korhonen, Sri Gundavelli, Dave Dolson, Lorenzo Colitti, and Daniel Migault for their valuable comments and suggestions on this work. You all are literally the best. 💖

Contributors 🧚

This document was merged with "Use Cases and API Extension for Source IP Address Selection" [API-EXT]. We would like to acknowledge the contribution of the following people to that document as well:

Sergio Figueiredo
Altran Research
France
Email: sergio.figueiredo@altran.com

Younghan Kim
Soongsil University
Republic of Korea
Email: younghak@ssu.ac.kr

John Kaippallimalil
Huawei
United States of America
Email: john.kaippallimalil@huawei.com

Authors' Addresses 💜

Alper Yegin
Actility
Istanbul/
Turkey

Email: alper.yegin@actility.com


Danny Moses
Intel Corporation
Petah Tikva
Israel

Email: danny.moses@intel.com


Seil Jeon
Republic of Korea
Suwon
Sungkyunkwan University

Email: seiljeon.ietf@gmail.com
📦 where this page comes from