<?xml version="1.0" encoding="US-ASCII"?> version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?> "rfc2629-xhtml.ent">
<rfc category="info" xmlns:xi="http://www.w3.org/2001/XInclude"
docName="draft-ietf-dmm-ondemand-mobility-18"
     ipr="trust200902">
number="8653"
updates=""
obsoletes=""
category="info"
submissionType="IETF"
consensus="true"
ipr="trust200902"
sortRefs="true"
symRefs="true"
tocInclude="true"
xml:lang="en"
version="3">
  <!--
 This is a comment xml2rfc v2v3 conversion 2.25.0 -->
  <front>
    <title abbrev="On Demand Mobility">On Demand abbrev="On-Demand Mobility">On-Demand Mobility Management</title>
    <seriesInfo name="RFC" value="8653"/>
    <author fullname="Alper Yegin" initials="A." surname="Yegin">
      <organization abbrev="Actility">Actility</organization>
      <address>
        <postal>
          <street/>
          <city>Istanbul</city>
          <region/>
          <code/>
          <country>Turkey</country>
        </postal>
        <email>alper.yegin@actility.com</email>
      </address>
    </author>
    <author fullname="Danny Moses" initials="D." surname="Moses">
      <organization abbrev="Intel">Intel Corporation</organization>
      <address>
        <postal>
          <street/>
          <city>Petah Tikva</city>
          <region/>
          <code/>
          <country>Israel</country>
        </postal>
        <email>danny.moses@intel.com</email>
      </address>
    </author>
    <author fullname="Seil Jeon" initials="S." surname="Jeon">
      <organization>Sungkyunkwan University</organization>
      <address>
        <postal>
          <street/>
          <city>Suwon</city>
          <region/>
          <code/>
          <country>South
          <country>Republic of Korea</country>
        </postal>
        <email>seiljeon@skku.edu</email>
        <email>seiljeon.ietf@gmail.com</email>
      </address>
    </author>
    <date/>
    <date month="October" year="2019"/>
    <workgroup>DMM Working Group</workgroup>
    <abstract>
      <t>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 <xref target="RFC7333"></xref>. RFC 7333.

	  This document defines a new concep concept of enabling applications to influence the
	  network's mobility services (session continuity and/or IP address reachability)
	  on a per-Socket per-socket basis, and suggests extensions to the networking stack's API
	  to accomodate accommodate this concept.
      </t>
    </abstract>
  </front>
  <middle>
    <section anchor="introduction" title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t>In the context of Mobile IP <xref target="RFC5563"></xref><xref
            target="RFC6275"></xref><xref target="RFC5213"></xref><xref target="RFC5944"></xref>, target="RFC5563" format="default"/> <xref target="RFC6275" format="default"/>
<xref target="RFC5213" format="default"/> <xref target="RFC5944" format="default"/>,
			the following two attributes are defined for IP service provided to
			mobile hosts:</t>

			<t>- Session Continuity</t>

            <t>The
      <dl newline="true">
         <dt>Session Continuity</dt>
            <dd>The ability to maintain an ongoing transport interaction
			by keeping the same local end-point endpoint IP address throughout the life-time 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.</t>

			<t>- IP interruption.</dd>
         <dt>IP Address Reachability</t>

            <t>The Reachability</dt>
           <dd>The ability to maintain the same IP address
			for an extended period of time. The IP address stays the same across
			independent sessions, and even in the absence of any session. The
			IP address may be published in a long-term registry (e.g., DNS), 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.</t> addresses.</dd>
      </dl>

      <t>Mobile IP is designed to provide both session continuity and IP
			address reachability to mobile hosts. Architectures utilizing using these
			protocols (e.g., 3GPP, 3GPP2, WIMAX) WiMAX) ensure that any mobile host
			attached to the a compliant networks 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.</t>
      <t>Achieving session continuity and IP address reachability with
			Mobile IP incurs some cost. Mobile IP protocol forces the mobile host's
			IP traffic to traverse a centrally-located centrally located router (Home Agent,  HA),
			which incurs additional transmission latency and use of additional
			network resources, adds to the network CAPEX network's operating and OPEX, capital expenditures, and decreases the
			reliability of the network due to the introduction of a single point of
			failure <xref target="RFC7333"></xref>. target="RFC7333" format="default"/>. Therefore, session continuity
			and IP address reachability SHOULD <bcp14>SHOULD</bcp14> be provided only when necessary.</t>
      <t>In reality 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, 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.</t>

      <t>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 MPTCP Multipath TCP <xref target="RFC6824"></xref>, target="RFC6824" format="default"/>, SIP mobility <xref
			target="RFC3261"></xref>, target="RFC3261" format="default"/>, 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 utilize use the most direct data
			path between the end-points. 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.</t>
      <t>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.</t>
    </section>
    <!-- Introduction -->
    <section anchor="notation" title="Notational Conventions">
      <t>The numbered="true" toc="default">
    <name>Notational Conventions</name>
       <t>
       The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
      "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
       "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>",
       "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
       "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
       "<bcp14>MAY</bcp14>", and "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be
       interpreted as described in BCP 14 , BCP&nbsp;14 <xref
      target="RFC2119"></xref> target="RFC2119"/> <xref target="RFC8174"></xref>
       target="RFC8174"/> when, and only when, they appear in all capitals, as
       shown here.</t> here.
      </t>
    </section>
    <!-- Notational Conventions -->
    <section anchor="solution" title="Solution"> numbered="true" toc="default">
      <name>Solution</name>
      <section anchor="hldescription" title="High-level Description"> numbered="true" toc="default">
        <name>High-Level Description</name>
        <t> Enabling applications to indicate their mobility service requirements
		e.g.
		(e.g., session continuity and/or IP address reachability, reachability) comprises the
		following steps:</t>

        <t>- The
<ol>
        <li>The application indicates to the network stack (local to the
		mobile host) the desired mobility service.</t>

        <t>- The service.</li>
        <li>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.</t>

        <t>- The below.</li>
        <li>The network stack sends a request to the network for a new source
		IP prefix that is associated with the desired mobility service.</t>

        <t>- The service.</li>
        <li>The network responds with the suitable allocated source IP prefix
		(or responds with a failure indication).</t>

        <t>- If indication).</li>
        <li>If the suitable source IP prefix was allocates, allocated, the network stack
		constructs a source IP address and provides it to the application.</t> application.</li>
</ol>
        <t> 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 socket interface as an example
		for an API between applications and the network stack. Other steps are
		outside the scope of this document.</t>
      </section>
      <!-- High-level Description -->
      <section anchor="addresstypes" title="Types numbered="true" toc="default">
        <name>Types of IP Addresses"> Addresses</name>
        <t> Four types of IP addresses are defined with respect to mobility
		management.</t>

        <t>- Fixed
		management:</t>
      <dl newline="true">
        <dt>Fixed IP Address</t> address</dt>
        <dd>
        <t> A Fixed IP address is an address with a guarantee 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
		point of attachment to another (with a different IP prefix) while it is
		connected.</t>
        <t>Fixed IP addresses are required by applications that need both session
		continuity and IP address reachability.</t>

        <t>- Session-lasting
        </dd>
        <dt>Session-Lasting IP Address</t> address</dt>
        <dd>
        <t>A session-lasting Session-Lasting IP address is an address with a guarantee guaranteed to be
		valid throughout for the life-time lifetime of the socket(s) for which it was requested.
		It is guaranteed to be valid even after the mobile host had has moved from one
		point-of-attachment
		point of attachment to another (with a different IP prefix).</t>

        <t>Session-lasting
        <t>Session-Lasting IP addresses are required by applications that need
		session continuity but do not need IP address reachability.</t>

        <t>- Non-persistent
        </dd>
        <dt>Nonpersistent IP Address</t> address</dt>
        <dd>
        <t>This type of IP address has no guarantee is not guaranteed to exist after a mobile host
		moves from one point-of-attachment point of attachment to another, and 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.</t>

        <t>- Graceful Replacement
        </dd>
        <dt>Graceful-Replacement IP Address</t> address</dt>
        <dd>
        <t>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.</t>
        <t>This gracefulness is still better than the non-persistence nonpersistence type of address
		for applications that can handle a change in their source IP address but require
		that extra flexibility.</t>
        </dd>
      </dl>
        <t>Applications running as servers at a published IP address require a
		Fixed IP Address. 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.</t>
	        address.</t>
        <t>Applications with short-lived transient sessions (e.g., web browsers) can use
		Session-lasting
		Session-Lasting IP Addresses. For example: Web browsers.</t> addresses.</t>
        <t>Applications with very short sessions, such as DNS clients and
		instant messengers, can utilize Non-persistent use Nonpersistent IP Addresses. addresses. Even
		though they could very well use Fixed or Session-lasting Session-Lasting IP
		Addresses,
		addresses, the transmission latency would be minimized when a
		Non-persistent
		Nonpersistent IP Addresses are address is used.</t>
        <t>Applications that can tolerate a short interruption in connectivity
		can use the Graceful-replacement Graceful-Replacement IP addresses. For addresses, for example, a streaming
		client that has buffering capabilities.</t>
      </section>
      <!-- Types of IP Addresses -->
      <section anchor="granularity" title="Granularity numbered="true" toc="default">
        <name>Granularity of Selection"> Selection</name>
        <t>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 control plane of an application may require a Fixed IP
		Address
		address in order to stay reachable, whereas the data-plane data plane of the same
		application may be satisfied with a Session-lasting Session-Lasting IP Address.</t> address.</t>
      </section>
      <!-- Granularity of Selection -->
      <section anchor="ondemand" title="On Demand Nature"> numbered="true" toc="default">
        <name>On-Demand Nature</name>
        <t>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, Session-Lasting,
		zero or more Non-persistent Nonpersistent, and zero or more Graceful-Replacement
		IP addresses may be configured by the IP stack of the host. The
		combination may be as a result of the host policy, application demand,
		or a mix of the two.</t>
        <t>When an application requires a specific type of IP address address, and such
		an address is not already configured on the host, the IP stack SHALL <bcp14>SHALL</bcp14>
		attempt to configure one. For example, a host may not always have a
		Session-lasting
		Session-Lasting IP address available. When an application requests
		one, the IP stack SHALL <bcp14>SHALL</bcp14> make an attempt to configure one by issuing a
		request to the network. If the operation fails, the IP stack SHALL <bcp14>SHALL</bcp14>
		fail the associated socket request and return an error. If successful,
		a Session-lasting Session-Lasting IP Address gets address is configured on the mobile host. If
		another socket requests a Session-lasting 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 released, or it may be kept for future applications requiring a Session-Lasting
		IP address that may be launched
		and require a Session-lasting IP address.</t> in the future.</t>
        <t>In some cases cases, it might be preferable for the mobile host to request
		a new Session-lasting 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
		sockets).
		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).</t>
        <t>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.</t>
        <t>The following are matters of policy, which may be dictated by the
		host itself, the network operator, or the system architecture
		standard:</t>

        <t> - The
<ul>
        <li>The initial set of IP addresses configured on the host at boot
		time.</t>
        <t>- Permission
		time</li>
        <li>Permission to grant various types of IP addresses to a requesting
		application.</t>
        <t>- Determination
		application</li>

        <li>Determination of a default address type when an application does
      not make any explicit indication, explicitly indicate whether it already supports the required API or it is just a
      legacy application.</t> application </li>
</ul>
      </section>
      <!-- On Demand On-Demand Nature -->
    </section>
    <!-- Solution -->
    <section anchor="compatibility" title="Backwards numbered="true" toc="default">
      <name>Backwards Compatibility Considerations"> Considerations</name>
      <t> Backwards compatibility support is REQUIRED <bcp14>REQUIRED</bcp14> by the following 3 three types
	of entities: </t>
	<t>- The Applications
<ul>
      <li>The applications on the mobile host</t>
	<t>- The host</li>
      <li>The IP stack in the mobile host</t>
	<t>- The host</li>
      <li>The network infrastructure </t> </li>
</ul>
      <section anchor="applications" title="Applications"> numbered="true" toc="default">
        <name>Applications</name>
        <t>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. </t>
        <t> 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 code, and
	the invoking applications application may just give up and use legacy calls. </t>
      </section>
      <!-- Applications -->
      <section anchor="stack" title="IP numbered="true" toc="default">
        <name>IP Stack in the Mobile Host"> Host</name>
        <t>New IP stacks (that implement On Demand On-Demand functionality) MUST <bcp14>MUST</bcp14> continue to support
	all legacy operations. If an application does not use On-Demand functionality, the
	IP stack MUST <bcp14>MUST</bcp14> respond in a legacy manner.</t>
        <t> If the network infrastructure supports On-Demand functionality,
	the IP stack SHOULD <bcp14>SHOULD</bcp14> follow the application request: If the application
	requests a specific address type, the stack SHOULD <bcp14>SHOULD</bcp14> forward this
        request to the network.
If the application does not request an address type, the IP stack MUST NOT <bcp14>MUST NOT</bcp14>
request an address type and leave it to type. Instead, the network's default behavior to network will choose the type of the
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.</t>
      </section>
      <!-- IP Stack in the Mobile Host -->
      <section anchor="network" title="Network Infrastructure"> numbered="true" toc="default">
        <name>Network Infrastructure</name>
        <t> 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. </t>
      </section>
      <!-- Network Infrastructure -->
      <section anchor="RFC5014ref" title="Merging numbered="true" toc="default">
        <name>Merging this work with RFC5014"> RFC 5014</name>
        <t><xref target="RFC5014"></xref> target="RFC5014" format="default"/> defines new flags that may be used with
	setsockopt() to influence source IP address selection for a socket. The list of
	flags include: include the following: source home address, care-of address, temporary address, public
	address CGA (Cryptographically Created Address) Address), and non-CGA. When applications
	require session continuity service, they SHOULD NOT <bcp14>SHOULD NOT</bcp14> set the flags specified
	in <xref target="RFC5014"></xref>.</t> target="RFC5014" format="default"/>.</t>
        <t>However, if an application erroneously performs a combination of (1) Use using
	setsockopt() to set a specific option (using one of the flags specified in
	<xref target="RFC5014"></xref>) target="RFC5014" format="default"/>) and (2) Selects selecting a source IP address type, the
	IP stack will fulfill the request specified by (2) and ignore the flags set
	by (1).</t>
      </section>
      <!-- Merging this work This Work with RFC5014 -->
    </section>
    <!-- Backwards Compatibility Considerations -->
    <section anchor="security" title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t> The different service types (session continuity types and address reachability) associated
	with the allocated IP address types, types may be associated with different costs. The 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 costly expensive
	services are limited, malicious applications may exhaust them, preventing other
	applications on the same mobile host from being able to use them.</t>
      <t> Mobile hosts that enables enable such service options, options should provide capabilities for
	ensuring that only authorized applications can use the costly expensive (or limited) service
	types.</t>
      <t> 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 addresses is encrypted.</t>

	<t>	To
      <t>To avoid profiling an application according to the type of IP addresses, address,
	it is expected that prefixes provided by the mobile operator are associated to with
	various type types of addresses over time. As a result, the type of address
	could not
	cannot be associated to with the prefix, making application profiling based on the
	type of address harder. more difficult. </t>

	<t>	The
      <t>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 On-Demand flag. The application should be able to ensure that session
	lasting Session-Lasting
        IP addresses are regularly changed by setting a lifetime lifetime, for example example,
	handled by the application. In addition, the application should consider the use
	of graceful replacement Graceful-Replacement IP addresses. </t>
      <t> Similarly, the OS may also associated 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 Graceful-Replacement or non persistent nonpersistent should be
	regularly renewed by the OS.</t>
      <t> The lifetime of an IP address may be expressed in number of seconds or
	in number of bytes sent through this IP address. </t>
    </section>
    <!-- Security Considerations -->
    <section anchor="iana" title="IANA Considerations"> numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>This document has no IANA considerations.</t> actions.</t>
    </section>
    <!-- IANA Considerations -->

    <section anchor="contributor" title="Contributors">
	  <t>This document was merged with <xref target="I-D.sijeon-dmm-use-cases-api-source"></xref>.
	  We would like to acknowledge the contribution of the following people to that document as
	  well:</t>

	  <figure>
<artwork><![CDATA[
Sergio Figueiredo
Altran Research, France
Email: sergio.figueiredo@altran.com

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

John Kaippallimalil
Huawei, USA
Email: john.kaippallimalil@huawei.com
]]></artwork>
	</figure>

	</section> <!-- Contributors -->

	<section anchor="ack" title="Acknowledgements">
      <t>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.</t>
    </section> <!-- Acknowledgements -->
  </middle>
  <back>

    <references title="Normative References">
      <?rfc include="reference.RFC.2119"?>
	  <?rfc include="reference.RFC.8174"?>

        <?rfc include='reference.RFC.5014'?>
<displayreference target="I-D.sijeon-dmm-use-cases-api-source" to="API-EXT"/>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.5014.xml"/>
      </references>

    <references title="Informative References">

        <?rfc include='reference.RFC.6275'?>

        <?rfc include='reference.RFC.5944'?>
        <?rfc include='reference.RFC.7333'?>
        <?rfc include='reference.RFC.5563'?>
        <?rfc include='reference.RFC.5213'?>
        <?rfc include='reference.RFC.6824'?>
        <?rfc include='reference.RFC.3261'?>
        <?rfc include='reference.I-D.sijeon-dmm-use-cases-api-source'?>
      <references>
        <name>Informative References</name>
        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.6275.xml"/>
        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.5944.xml"/>
        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.7333.xml"/>
        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.5563.xml"/>
        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.5213.xml"/>
        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.6824.xml"/>
        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.3261.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.draft-sijeon-dmm-use-cases-api-source-07.xml"/>
        <!---->
      </references>
    </references>
    <section anchor="appendix" title="Conveying numbered="true" toc="default">
      <name>Conveying the Desired Address Type">

		<t>Following Type</name>
      <t>The following are some suggestions of possible extensions to the Socket socket API
		for enabling applications to convey their session continuity and address
		reachability requirements.</t>
      <t><xref target="RFC5014"></xref> target="RFC5014" format="default"/> 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.</t>
      <t>One alternative is to extend the defintion definition of the IPV6_ADDR_REFERENCE
		opion
		option with flags that express the invoker's desire. An "OnDeman" "OnDemand" field could
		contains
		contain one of the following values: FIXED_IP_ADDRESS, SESSION_LASTING_IP_ADDRESS,
		NON_PERSISTENT_IP_ADDRESS
		NON_PERSISTENT_IP_ADDRESS, or GRACEFUL_REPLACEMENT_IP_ADDRESS.</t>
      <t>Another alternative is to define a new Socket socket function used by the invoker
		to convey its desire. This enables the implementation of two behaviors of
		Socket
		socket functions: The the existing "setsockotp()" setsockopt() is a function that returns after
		executing, and the new "setsc()" setsc() (Set Service Contionuity) Continuity) is a function that may
		initaite
		initiate a request for the desired service, and wait until the network responds
		with the allocated resources, before returning to the invoker.</t>
      <t>After obtaining an IP address with the desired behavior behavior, the application can
		call the bind() Socket socket function to associate that received IP address with the
		socket.</t>
    </section>

    <!-- Conveying the Desired Address Type -->
    <section anchor="ack" numbered="false" toc="default">
      <name>Acknowledgements</name>
      <t>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.</t>
    </section>
    <!-- Acknowledgements -->
    <section anchor="contributor" numbered="false" toc="default">
      <name>Contributors</name>
      <t>This document was merged with "Use Cases and API Extension for Source IP Address
         Selection" <xref target="I-D.sijeon-dmm-use-cases-api-source" format="default"/>.
         We would like to acknowledge the contribution of the following people to that document as
	  well:</t>
      <artwork name="" type="" align="left" alt=""><![CDATA[
Sergio Figueiredo
Altran Research
France
Email: sergio.figueiredo@altran.com
]]></artwork>
      <artwork name="" type="" align="left" alt=""><![CDATA[
Younghan Kim
Soongsil University
Republic of Korea
Email: younghak@ssu.ac.kr
]]></artwork>
     <artwork name="" type="" align="left" alt=""><![CDATA[
John Kaippallimalil
Huawei
United States of America
Email: john.kaippallimalil@huawei.com
]]></artwork>
    </section>
    <!-- Contributors -->
  </back>
</rfc>