doc: Add RFC documents

1 files changed, 581 insertions, 0 deletions

diff --git a/doc/rfc/rfc8653.txt b/doc/rfc/rfc8653.txt
new file mode 100644
index 0000000..6052fb9
--- /dev/null
+++ b/doc/rfc/rfc8653.txt
@@ -0,0 +1,581 @@
+
+
+
+
+Internet Engineering Task Force (IETF)                          A. Yegin
+Request for Comments: 8653                                      Actility
+Category: Informational                                         D. Moses
+ISSN: 2070-1721                                                    Intel
+                                                                 S. Jeon
+                                                 Sungkyunkwan University
+                                                            October 2019
+
+
+                     On-Demand Mobility Management
+
+Abstract
+
+   Applications differ with respect to whether they need 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, as described in RFC 7333.  This
+   document defines a new concept of enabling applications to influence
+   the network's mobility services (session continuity and/or IP address
+   reachability) on a per-socket basis, and suggests extensions to the
+   networking stack's API to accommodate this concept.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Not all documents
+   approved by the IESG are candidates for any level of Internet
+   Standard; see Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   https://www.rfc-editor.org/info/rfc8653.
+
+Copyright Notice
+
+   Copyright (c) 2019 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
+   (https://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are 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
+
+   In the context of Mobile IP [RFC5563] [RFC6275] [RFC5213] [RFC5944],
+   the following two attributes are defined for IP service provided to
+   mobile hosts:
+
+   Session Continuity
+      The ability to maintain an ongoing transport interaction by
+      keeping the same local endpoint IP address throughout the lifetime
+      of the IP socket despite the mobile host changing its point of
+      attachment within the IP network topology.  The IP address of the
+      host may change after closing the IP socket and before opening a
+      new one, but that does not jeopardize the ability of applications
+      using these IP sockets to work flawlessly.  Session continuity is
+      essential for mobile hosts to maintain ongoing flows without any
+      interruption.
+
+   IP Address Reachability
+      The ability to maintain the same IP address for an extended period
+      of time.  The IP address stays the same across independent
+      sessions, even in the absence of any session.  The IP address may
+      be published in a long-term registry (e.g., DNS) and is made
+      available for serving incoming (e.g., TCP) connections.  IP
+      address reachability is essential for mobile hosts to use
+      specific/published IP addresses.
+
+   Mobile IP is designed to provide both session continuity and IP
+   address reachability to mobile hosts.  Architectures using these
+   protocols (e.g., 3GPP, 3GPP2, WiMAX) ensure that any mobile host
+   attached to a compliant network can enjoy these benefits.  Any
+   application running on these mobile hosts is subjected to the same
+   treatment with respect to session continuity and IP address
+   reachability.
+
+   Achieving session continuity and IP address reachability with Mobile
+   IP incurs some cost.  Mobile IP forces the mobile host's IP traffic
+   to traverse a centrally located router (Home Agent, HA), which incurs
+   additional transmission latency and use of additional network
+   resources, adds to the network's operating and capital expenditures,
+   and decreases the reliability of the network due to the introduction
+   of a single point of failure [RFC7333].  Therefore, session
+   continuity and IP 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
+   able to satisfy that need by using a solution above the IP layer,
+   such as Multipath TCP [RFC6824], SIP mobility [RFC3261], or an
+   application-layer mobility solution.  These higher-layer solutions
+   are not subject to the same issues that arise with the use of Mobile
+   IP since they can use the most direct data path between the
+   endpoints.  But, if Mobile IP is being applied to the mobile host,
+   the higher-layer protocols are rendered useless because their
+   operation is 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), the higher-layer protocols never
+   detect the IP-layer change and never engage in mobility management.
+
+   This document proposes a solution for applications running on mobile
+   hosts to indicate when establishing the network connection ('on
+   demand') whether they need session continuity or IP address
+   reachability.  The network protocol stack on the mobile host, in
+   conjunction with the network infrastructure, provides the required
+   type of service.  It is for the benefit of both the users and the
+   network operators not to engage an extra level of service unless it
+   is absolutely necessary.  It is expected that applications and
+   networks compliant with this specification will utilize this solution
+   to use network resources more efficiently.
+
+2.  Notational Conventions
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+   "OPTIONAL" in this document are to be interpreted as described in
+   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
+   capitals, as shown here.
+
+3.  Solution
+
+3.1.  High-Level Description
+
+   Enabling applications to indicate their mobility service requirements
+   (e.g., session continuity and/or IP address reachability) comprises
+   the following steps:
+
+   1.  The application indicates to the network stack (local to the
+       mobile host) the desired mobility service.
+
+   2.  The network stack assigns a source IP address based on an IP
+       prefix with the desired services that was previously provided by
+       the network.  If such an IP prefix is not available, the network
+       stack performs the additional steps below.
+
+   3.  The network stack sends a request to the network for a new source
+       IP prefix that is associated with the desired mobility service.
+
+   4.  The network responds with the suitable allocated source IP prefix
+       (or responds with a failure indication).
+
+   5.  If the suitable source IP prefix was allocated, the network stack
+       constructs a source IP address and provides it to the
+       application.
+
+   This document specifies the new address types associated with
+   mobility services and details the interaction between the
+   applications and the network stack steps.  It uses the socket
+   interface as an example for an API between applications and the
+   network stack.  Other steps are outside the scope of this document.
+
+3.2.  Types of IP Addresses
+
+   Four types of IP addresses are defined with respect to mobility
+   management:
+
+   Fixed IP address
+      A Fixed IP address is an address guaranteed to be valid for a very
+      long time, regardless of whether it is being used in any packet
+      to/from the mobile host, or whether or not the mobile host is
+      connected to the network, or whether it moves from one point of
+      attachment to another (with a different IP prefix) while it is
+      connected.
+
+      Fixed IP addresses are required by applications that need both
+      session continuity and IP address reachability.
+
+   Session-Lasting IP address
+      A Session-Lasting IP address is an address guaranteed to be valid
+      for the lifetime of the socket(s) for which it was requested.  It
+      is guaranteed to be valid even after the mobile host has moved
+      from one point of attachment to another (with a different IP
+      prefix).
+
+      Session-Lasting IP addresses are required by applications that
+      need session continuity but do not need IP address reachability.
+
+   Nonpersistent IP address
+      This type of IP address is not guaranteed to exist after a mobile
+      host moves from one point of attachment to another; therefore, no
+      session continuity nor IP address reachability are provided.  The
+      IP address is created from an IP prefix that is obtained from the
+      serving IP gateway and is not maintained across gateway changes.
+      In other words, the IP prefix may be released and replaced by a
+      new one when the IP gateway changes due to the movement of the
+      mobile host forcing the creation of a new source IP address with
+      the updated allocated IP prefix.
+
+   Graceful-Replacement IP address
+      In some cases, the network cannot guarantee the validity of the
+      provided IP prefix throughout the duration of the opened socket,
+      but can provide a limited graceful period of time in which both
+      the original IP prefix and a new one are valid.  This enables the
+      application some flexibility in the transition from the existing
+      source IP address to the new one.
+
+      This gracefulness is still better than the nonpersistence type of
+      address for applications that can handle a change in their source
+      IP address but require 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.  Even though
+   they could very well use Fixed or Session-Lasting IP addresses, the
+   transmission latency would be minimized when a Nonpersistent IP
+   address is used.
+
+   Applications that can tolerate a short interruption in connectivity
+   can use the Graceful-Replacement IP addresses, for example, a
+   streaming client that has buffering capabilities.
+
+3.3.  Granularity of Selection
+
+   IP address type selection is made on a per-socket granularity.
+   Different parts of the same application may have different needs.
+   For example, the control plane of an application may require a Fixed
+   IP address in order to stay reachable, whereas the data plane of the
+   same application may be satisfied 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 may be a result of the host policy,
+   application demand, or a mix of the two.
+
+   When an application requires a specific type of IP address, and such
+   an address is not 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 issuing a
+   request to the network.  If the operation fails, the IP stack SHALL
+   fail the associated socket request and return an error.  If
+   successful, a Session-Lasting IP address is configured on the mobile
+   host.  If another socket requests a Session-Lasting IP address at a
+   later time, the same IP address may be served to that socket as well.
+   When the last socket using the same configured IP address is closed,
+   the IP address may be released, or it may be kept for applications
+   requiring a Session-Lasting IP address that may be launched in the
+   future.
+
+   In some cases, it might be preferable for the mobile host to request
+   a new Session-Lasting IP address for a new opening of an IP socket
+   (even though one was already assigned to the mobile host by the
+   network and might be in use in a different, already active IP
+   socket).  It is outside the scope of this specification to define
+   criteria for choosing to use available addresses or choosing to
+   request new ones.  It supports both alternatives (and any
+   combination).
+
+   It is 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 do not support the On-Demand functionality
+   will use the legacy API and will not 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 do not support
+   it.  Such environments may include a legacy IP stack on the mobile
+   host, legacy network infrastructure, or both.  In either case, the
+   API will return 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 (that implement On-Demand functionality) MUST continue
+   to support all legacy operations.  If an application does not 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 this
+   request to the network.  If the application does not request an
+   address type, the IP stack MUST NOT request an address type.
+   Instead, the network will choose the type of allocated IP prefix.
+   How the network selects the type of allocated IP prefix 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 include the following: 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 performs a combination of (1)
+   using setsockopt() to set a specific option (using one of the flags
+   specified in [RFC5014]) and (2) selecting a source IP address type,
+   the IP stack will fulfill the request specified by (2) and ignore the
+   flags set by (1).
+
+5.  Security Considerations
+
+   The different service types (session continuity types and address
+   reachability) associated with the allocated IP address types may be
+   associated with different costs: the cost to the operator for
+   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,
+   preventing other applications on the same mobile host from being able
+   to use them.
+
+   Mobile hosts that enable such service options should provide
+   capabilities for ensuring that only authorized applications can use
+   the expensive (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 addresses is encrypted.
+
+   To avoid profiling an application according to the type of IP
+   address, it is expected that prefixes provided by the mobile operator
+   are associated with various types of addresses over time.  As a
+   result, the type of address cannot be associated with the prefix,
+   making application profiling based on the type of address more
+   difficult.
+
+   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 associate 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 nonpersistent 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.
+
+6.  IANA Considerations
+
+   This document has no IANA actions.
+
+7.  References
+
+7.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <https://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC5014]  Nordmark, E., Chakrabarti, S., and J. Laganier, "IPv6
+              Socket API for Source Address Selection", RFC 5014,
+              DOI 10.17487/RFC5014, September 2007,
+              <https://www.rfc-editor.org/info/rfc5014>.
+
+   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+              May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+7.2.  Informative References
+
+   [API-EXT]  Jeon, S., Figueiredo, S., Kim, Y., and J. Kaippallimalil,
+              "Use Cases and API Extension for Source IP Address
+              Selection", Work in Progress, Internet-Draft, draft-
+              sijeon-dmm-use-cases-api-source-07, 10 September 2017,
+              <https://tools.ietf.org/html/draft-sijeon-dmm-use-cases-
+              api-source-07>.
+
+   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
+              A., Peterson, J., Sparks, R., Handley, M., and E.
+              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
+              DOI 10.17487/RFC3261, June 2002,
+              <https://www.rfc-editor.org/info/rfc3261>.
+
+   [RFC5213]  Gundavelli, S., Ed., Leung, K., Devarapalli, V.,
+              Chowdhury, K., and B. Patil, "Proxy Mobile IPv6",
+              RFC 5213, DOI 10.17487/RFC5213, August 2008,
+              <https://www.rfc-editor.org/info/rfc5213>.
+
+   [RFC5563]  Leung, K., Dommety, G., Yegani, P., and K. Chowdhury,
+              "WiMAX Forum / 3GPP2 Proxy Mobile IPv4", RFC 5563,
+              DOI 10.17487/RFC5563, February 2010,
+              <https://www.rfc-editor.org/info/rfc5563>.
+
+   [RFC5944]  Perkins, C., Ed., "IP Mobility Support for IPv4, Revised",
+              RFC 5944, DOI 10.17487/RFC5944, November 2010,
+              <https://www.rfc-editor.org/info/rfc5944>.
+
+   [RFC6275]  Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility
+              Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July
+              2011, <https://www.rfc-editor.org/info/rfc6275>.
+
+   [RFC6824]  Ford, A., Raiciu, C., Handley, M., and O. Bonaventure,
+              "TCP Extensions for Multipath Operation with Multiple
+              Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013,
+              <https://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,
+              <https://www.rfc-editor.org/info/rfc7333>.
+
+Appendix A.  Conveying the Desired Address Type
+
+   The following are some suggestions of possible extensions to the
+   socket API for enabling applications to convey their session
+   continuity and address reachability requirements.
+
+   [RFC5014] introduced the ability of applications to influence the
+   source address selection with the IPV6_ADDR_PREFERENCE option at the
+   IPPROTO_IPV6 level.  This option is used with setsockopt() and
+   getsockopt() calls to set/get address selection preferences.
+
+   One alternative is to extend the definition of the
+   IPV6_ADDR_REFERENCE option with flags that express the invoker's
+   desire.  An "OnDemand" field could contain one of the following
+   values: FIXED_IP_ADDRESS, SESSION_LASTING_IP_ADDRESS,
+   NON_PERSISTENT_IP_ADDRESS, or GRACEFUL_REPLACEMENT_IP_ADDRESS.
+
+   Another alternative is to define a new socket function used by the
+   invoker to convey its desire.  This enables the implementation of two
+   behaviors of socket functions: the existing setsockopt() is a
+   function that returns after executing, and the new setsc() (Set
+   Service Continuity) is a function that may initiate a request for the
+   desired service, and wait until the network responds with the
+   allocated resources, before returning to the invoker.
+
+   After obtaining an IP address with the desired behavior, the
+   application can call the bind() socket function to associate that
+   received IP address with 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.
+
+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