<?xml version="1.0" encoding="US-ASCII"?>
<!-- Convert to HTML and Text with xml2rfc: http://xml2rfc.ietf.org. --> version='1.0' encoding='utf-8'?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
  <!ENTITY RFC5533 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5533.xml">
  <!ENTITY RFC5062 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5062.xml">
  <!ENTITY RFC5061 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5061.xml">
  <!ENTITY RFC4960 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4960.xml">
  <!ENTITY RFC4987 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4987.xml">
  <!ENTITY RFC6234 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6234.xml">
  <!ENTITY RFC4086 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4086.xml">
  <!ENTITY RFC5681 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5681.xml">
  <!ENTITY RFC2119 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
  <!ENTITY RFC2992 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2992.xml">
  <!ENTITY RFC2979 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2979.xml">
  <!ENTITY RFC2104 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2104.xml">
  <!ENTITY RFC2018 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2018.xml">
  <!ENTITY RFC1918 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1918.xml">
  <!ENTITY RFC0793 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.0793.xml">
  <!ENTITY RFC7323 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7323.xml">
  <!ENTITY RFC1122 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1122.xml">
  <!ENTITY RFC3135 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3135.xml">
  <!ENTITY RFC3022 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3022.xml">
  <!ENTITY RFC6181 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6181.xml">
  <!ENTITY RFC6182 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6182.xml">
  <!ENTITY RFC6356 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6356.xml">
  <!ENTITY RFC6555 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6555.xml">
  <!ENTITY RFC8126 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml">
  <!ENTITY RFC6897 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6897.xml">
  <!ENTITY RFC6528 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6528.xml">
  <!ENTITY RFC5961 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5961.xml">
  <!ENTITY RFC7413 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7413.xml">
  <!ENTITY RFC7430 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7430.xml">
  <!ENTITY RFC8174 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
  <!ENTITY RFC8041 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8041.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="no" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<?rfc rfcedstyle="yes"?> "rfc2629-xhtml.ent">
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF"
     category="std" consensus="true" docName="draft-ietf-mptcp-rfc6824bis-18" number="8684" ipr="trust200902" obsoletes="6824"> obsoletes="6824" updates="" xml:lang="en" tocInclude="true" symRefs="true" sortRefs="true" version="3">

<!-- xml2rfc v2v3 conversion 2.27.0 -->

  <front>
    <title abbrev="Multipath TCP">TCP Extensions for Multipath Operation with Multiple Addresses</title>
    <seriesInfo name="RFC" value="8684"/>

    <author fullname="Alan Ford" initials="A." surname="Ford">
      <organization>Pexip</organization>
      <address>
      <!--  <postal>
          <street>Beech Court</street>
          <city>Hurst</city>
          <region>Berkshire</region>
          <code>RG10 0RQ</code>
          <country>UK</country>
        </postal> -->
        <email>alan.ford@gmail.com</email>
      </address>
    </author>
    <author fullname="Costin Raiciu" initials="C." surname="Raiciu">
      <organization abbrev="U. Politechnica Politehnica of Bucharest">University Politehnica of Bucharest</organization>
      <address>
        <postal>
          <street>Splaiul Independentei 313</street>
          <city>Bucharest</city>
          <country>Romania</country>
        </postal>
        <email>costin.raiciu@cs.pub.ro</email>
      </address>
    </author>
    <author fullname="Mark Handley" initials="M." surname="Handley">
      <organization abbrev="U. College London">University College London</organization>
      <address>
        <postal>
          <street>Gower Street</street>
          <city>London</city>
          <code>WC1E 6BT</code>
          <country>UK</country>
          <country>United Kingdom</country>
        </postal>
        <email>m.handley@cs.ucl.ac.uk</email>
      </address>
    </author>
    <author fullname="Olivier Bonaventure" initials="O." surname="Bonaventure">
<organization abbrev="U. catholique de Louvain">Universit&eacute; Louvain" ascii="Universite catholique
  de Louvain">Universit├ę catholique de Louvain</organization>
      <address>
        <postal>
          <street>Pl. Ste Barbe, 2</street>
          <code>1348</code>
          <city>Louvain-la-Neuve</city>
          <country>Belgium</country>
        </postal>
        <email>olivier.bonaventure@uclouvain.be</email>
      </address>
    </author>
    <author fullname="Christoph Paasch" initials="C." surname="Paasch">
      <organization abbrev="Apple, Inc.">Apple, Inc.</organization>
      <address>
        <postal>
          <street></street>
          <street/>
          <city>Cupertino</city>
          <country>US</country>
          <region>CA</region>
          <country>United States of America</country>
        </postal>
        <email>cpaasch@apple.com</email>
      </address>
    </author>
    <date year="2019" />

    <area>General</area>
    <workgroup>Internet Engineering Task Force</workgroup> year="2020" month="January"/>

    <keyword>tcp extensions multipath multihomed subflow</keyword>

    <abstract>
      <t>TCP/IP communication is currently restricted to a single path per connection, yet multiple paths often exist between peers. The simultaneous use of these multiple paths for a TCP/IP session would improve resource usage within the network and, thus, and thus improve user experience through higher throughput and improved resilience to network failure.</t>
      <t>Multipath TCP provides the ability to simultaneously use multiple
      paths between peers. This document presents a set of extensions to
      traditional TCP to support multipath operation. The protocol offers the
      same type of service to applications as TCP (i.e., a reliable bytestream), and it provides the components necessary to establish and use multiple TCP flows across potentially disjoint paths.</t>
      <t>This document specifies v1 of Multipath TCP, obsoleting v0 as
      specified in RFC6824, RFC 6824, through clarifications and modifications primarily driven by deployment experience.</t>
    </abstract>
  </front>
  <middle>
    <section title="Introduction" anchor="sec_intro"> anchor="sec_intro" numbered="true" toc="default">
      <name>Introduction</name>
      <t>Multipath TCP (MPTCP) is a set of extensions to regular TCP <xref target="RFC0793"/>
      target="RFC0793" format="default"/> to provide a Multipath TCP service <xref target="RFC6182"/> service, target="RFC6182" format="default"/>, which enables a transport connection to operate across multiple paths
simultaneously. This document presents the protocol changes required to add
multipath capability to TCP; TCP -- specifically, those for signaling and setting
up multiple paths ("subflows"), managing these subflows, reassembly of data,
and termination of sessions. This is not the only information required to create a Multipath TCP implementation, however. This document is complemented by three others:
        <list style="symbols">
          <t>Architecture <xref target="RFC6182"/>,
      </t>
      <ul spacing="normal">
        <li><xref target="RFC6182" format="default"/> (MPTCP architecture), which
        explains the motivations behind Multipath TCP, contains a discussion
        of high-level design decisions on which this design is based, and provides an explanation of a functional separation through which an extensible MPTCP implementation can be developed.</t>
          <t>Congestion control <xref target="RFC6356"/> developed.</li>
        <li><xref target="RFC6356" format="default"/> (congestion control), which presents a safe congestion control algorithm for coupling the behavior of the multiple paths in order to "do no harm" to other network users.</t>
          <t>Application considerations <xref target="RFC6897"/> users.</li>
        <li><xref target="RFC6897"
        format="default"/> (application considerations), which discusses what impact MPTCP will have on applications, what applications will want to do with MPTCP, and as a consequence of these factors, what API extensions an MPTCP implementation should present.</t>
        </list> present.</li>
      </ul>
      <t>
      This document is an update to, and obsoletes, obsoletes the v0 specification of
      Multipath TCP (RFC6824). <xref target="RFC6824"/>. This document specifies MPTCP v1, which is not backward compatible with MPTCP v0. This document additionally defines version negotiation procedures for implementations that support both versions.
      </t>
      <section title="Design Assumptions" anchor="sec_assum"> anchor="sec_assum" numbered="true" toc="default">
        <name>Design Assumptions</name>
        <t>In order to limit the potentially huge design space, the mptcp working group
        MPTCP Working Group imposed two key constraints on the Multipath TCP design presented in this document:
          <list style="symbols">
            <t>It
        </t>
        <ul spacing="normal">
          <li>It must be backwards-compatible backward compatible with current, regular TCP, to increase its chances of deployment.</t>
            <t>It deployment.</li>
          <li>It can be assumed that one or both hosts are multihomed and multiaddressed.</t>
          </list>
        </t> multiaddressed.</li>
        </ul>
        <t>To simplify the design, we assume that the presence of multiple
        addresses at a host is sufficient to indicate the existence of
        multiple paths. These paths need not be entirely disjoint: they may
        share one or many routers between them. Even in such a situation,
        making use of multiple paths is beneficial, improving resource
        utilization and resilience to a subset of node failures. The
        congestion control algorithms algorithm defined in <xref target="RFC6356"/> ensure this target="RFC6356"
        format="default"/> ensures that the use of multiple paths does not act detrimentally.
 Furthermore, there may be some scenarios where different TCP ports on a
single host can provide disjoint paths (such as through certain
Equal-Cost Multipath (ECMP) implementations <xref target="RFC2992"/>), target="RFC2992"
format="default"/>), and so the MPTCP design also supports the use of
ports in path identifiers.</t>
        <t>There are three aspects to the backwards-compatibility backward compatibility listed above (discussed in more detail in <xref target="RFC6182"/>):
          <list style="hanging">
            <t hangText="External Constraints:"> target="RFC6182" format="default"/>):
        </t>
        <dl newline="false" spacing="normal" indent="3">
          <dt>External Constraints:</dt>
          <dd> The protocol must function through the vast majority of existing
middleboxes such as NATs, firewalls, and proxies, and as such must resemble existing TCP as far as possible on the
wire. Furthermore, the protocol must not assume that the segments it sends on the wire arrive unmodified at the destination:
they may be split or coalesced; TCP options may be removed or duplicated. </t>
            <t hangText="Application Constraints:"> </dd>
          <dt>Application Constraints:</dt>
          <dd> The protocol must be usable with no change to existing applications that use the common TCP API (although it is reasonable that not all features would be available to such legacy applications). Furthermore, the protocol must provide the same service model as regular TCP to the application.</t>
            <t hangText="Fallback:"> application.</dd>
          <dt>Fallback:</dt>
          <dd> The protocol should be able to fall back to standard TCP with no interference from the user, to be able to communicate with legacy hosts.</t>
          </list>
        </t> hosts.</dd>
        </dl>
        <t>The complementary application considerations document <xref target="RFC6897"/>
        target="RFC6897" format="default"/> discusses the necessary features
        of an API to provide backwards-compatibility, backward compatibility, as well as API extensions to convey the behavior of MPTCP at a level of control and information equivalent to that available with regular, single-path TCP.</t>
        <t>Further discussion of the design constraints and associated design decisions are is given in the MPTCP Architecture architecture document <xref target="RFC6182"/> target="RFC6182" format="default"/> and in <xref target="howhard"/>.</t> target="howhard" format="default"/>.</t>
      </section>
      <section title="Multipath anchor="sec_layers" numbered="true" toc="default">
        <name>Multipath TCP in the Networking Stack" anchor="sec_layers"> Stack</name>
        <t>MPTCP operates at the transport layer and aims to be transparent to both higher and lower
layers. It is a set of additional features on top of standard TCP; <xref target="fig_arch" /> format="default"/> illustrates
this layering. MPTCP is designed to be usable by legacy applications with no changes; detailed discussion
of its interactions with applications is given in <xref target="RFC6897"/>.</t> target="RFC6897" format="default"/>.</t>
        <figure align="center" anchor="fig_arch" title="Comparison anchor="fig_arch">
          <name>Comparison of Standard TCP and MPTCP Protocol Stacks"> Stacks</name>
          <artwork align="left"><![CDATA[ align="left" name="" type="" alt=""><![CDATA[
                                +-------------------------------+
                                |           Application         |
   +---------------+            +-------------------------------+
   |  Application  |            |             MPTCP             |
   +---------------+            + - - - - - - - + - - - - - - - +
   |      TCP      |            | Subflow (TCP) | Subflow (TCP) |
   +---------------+            +-------------------------------+
   |      IP       |            |       IP      |      IP       |
   +---------------+            +-------------------------------+ ]]></artwork>
        </figure>
      </section>
      <section title="Terminology"> numbered="true" toc="default">
        <name>Terminology</name>
        <t>This document makes use of a number of terms that are either MPTCP-specific MPTCP specific or have defined meaning in the context of MPTCP, as follows:
        <list style="hanging">
          <t hangText="Path:">
        </t>
        <dl newline="false" spacing="normal" indent="3">
          <dt>Path:</dt>
          <dd> A sequence of links between a sender and a receiver, defined in this context by a 4-tuple of source and destination address/port pairs.</t>
          <t hangText="Subflow:"> address&wj;/port pairs.</dd>
          <dt>Subflow:</dt>
          <dd> A flow of TCP segments operating over an individual path, which forms part of a larger MPTCP connection. A subflow is started and terminated similar similarly to a regular TCP connection.</t>
          <t hangText="(MPTCP) Connection:"> connection.</dd>
          <dt>(MPTCP) Connection:</dt>
          <dd> A set of one or more subflows, over which an application can communicate between two hosts. There is a one-to-one one&#8209;to&#8209;one mapping between a connection and an application socket.</t>
          <t hangText="Data-level:"> socket.</dd>
          <dt>Data-level:</dt>
          <dd> The payload data is nominally transferred over a connection, which in turn is transported over subflows.  Thus, the term "data-level" is synonymous with "connection level", "connection-level", in contrast to "subflow-level", which refers to properties of an individual subflow.</t>
          <t hangText="Token:"> subflow.</dd>
          <dt>Token:</dt>
          <dd> A locally unique identifier given to a multipath connection by a host. May also be referred to as a "Connection ID".</t>
          <t hangText="Host:"> ID".</dd>
          <dt>Host:</dt>
          <dd> An end host operating an MPTCP implementation, and either initiating or accepting an MPTCP connection.</t>
        </list> connection.</dd>
        </dl>
        <t>
        In addition to these terms, note that MPTCP's interpretation of, and effect on, regular single-path TCP semantics are discussed in <xref target="sec_semantics"/>.</t> target="sec_semantics" format="default"/>.</t>
      </section>
      <section title="MPTCP Concept" anchor="sec_operation"> anchor="sec_operation" numbered="true" toc="default">
        <name>MPTCP Concept</name>
        <t>This section provides a high-level summary of normal
operation of MPTCP, and MPTCP; this type of scenario is illustrated by the scenario shown in
<xref target="fig_scenario"/>. target="fig_scenario" format="default"/>. A detailed description of operation how
MPTCP operates is given in <xref target="sec_protocol"/>.
          <list style="symbols">
            <t>To target="sec_protocol" format="default"/>.
        </t>
        <figure anchor="fig_scenario">
          <name>Example MPTCP Usage Scenario</name>
          <artwork align="left" name="" type="" alt=""><![CDATA[
            Host A                               Host B
   ------------------------             ------------------------
   Address A1    Address A2             Address B1    Address B2
   ----------    ----------             ----------    ----------
       |             |                      |             |
       |     (initial connection setup)     |             |
       |----------------------------------->|             |
       |<-----------------------------------|             |
       |             |                      |             |
       |            (additional subflow setup)            |
       |             |--------------------->|             |
       |             |<---------------------|             |
       |             |                      |             |
       |             |                      |             | ]]></artwork>
        </figure>
        <ul spacing="normal">
          <li>To a non-MPTCP-aware application, MPTCP will behave the same as normal TCP. Extended APIs could provide
additional control to MPTCP-aware applications <xref target="RFC6897"/>. target="RFC6897" format="default"/>.
An application begins by opening a TCP socket in the normal way.
MPTCP signaling and operation are handled by the MPTCP implementation.
</t>
            <t>An
</li>
          <li>An MPTCP connection begins similarly to a regular TCP connection. This is
illustrated in <xref target="fig_scenario"/> target="fig_scenario" format="default"/>, where an MPTCP connection is established between
addresses A1 and B1 on Hosts A and B, respectively.</t>
            <t>If respectively.</li>
          <li>If extra paths are available, additional TCP sessions (termed MPTCP "subflows")
are created on these paths, paths and are combined with the existing session, which continues
to appear as a single connection to the applications at both ends. The creation of the
additional TCP session is illustrated between Address A2 on Host A and Address B1 on
Host B.</t>
            <t>MPTCP B.</li>
          <li>MPTCP identifies multiple paths by the presence of multiple addresses
at hosts. Combinations of these multiple addresses equate to the additional paths.
In the example, other potential paths that could be set up are A1&lt;-&gt;B2 and A2&lt;-&gt;B2.
Although this additional session is shown as being initiated from A2, it could equally have
been initiated from B1 or B2.</t>
            <t>The B2.</li>
          <li>The discovery and setup of additional subflows
will be achieved through a path management method; this document describes a mechanism
by which a host can initiate new subflows by using its own additional addresses, addresses or by
signaling its available addresses to the other host.</t>
            <t>MPTCP host.</li>
          <li>MPTCP adds connection-level sequence numbers to allow the reassembly of
segments arriving on multiple subflows with differing network delays. </t>
            <t>Subflows </li>
          <li>Subflows are terminated as regular TCP connections, with a four-way four&#8209;way FIN
handshake. The MPTCP connection is terminated by a connection-level FIN.</t>
          </list> FIN.</li>
        </ul>
      </section>
      <section numbered="true" toc="default">
        <name>Requirements Language</name>

        <t>
    The key words "<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 "<bcp14>OPTIONAL</bcp14>" in this document are to be
    interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/> <xref
    target="RFC8174"/> when, and only when, they appear in all capitals, as
    shown here.
        </t>
          <?rfc needLines='17'?>
          <figure align="center" anchor="fig_scenario" title="Example MPTCP Usage Scenario">
            <artwork align="left"><![CDATA[
            Host A                               Host B
   ------------------------             ------------------------
   Address A1    Address A2             Address B1    Address B2
   ----------    ----------             ----------    ----------
       |             |                      |             |
       |     (initial connection setup)     |             |
       |----------------------------------->|             |
       |<-----------------------------------|             |
       |             |                      |             |
       |            (additional subflow setup)            |
       |             |--------------------->|             |
       |             |<---------------------|             |
       |             |                      |             |
       |             |                      |             |
              ]]></artwork>
          </figure>
      </section>

      <section title="Requirements Language">
	<t>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&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
	when, and only when, they appear in all capitals, as shown here.</t>

      </section>
    </section>

    <section title="Operation Overview" anchor="sec_overview">
      <t>This section presents a single description of common

      </section>
    </section>
    <section anchor="sec_overview" numbered="true" toc="default">
      <name>Operation Overview</name>
      <t>This section presents a single description of common MPTCP operation, with reference to the protocol operation. This is a high-level overview of the key functions; the full specification follows in <xref target="sec_protocol"/>. target="sec_protocol" format="default"/>. Extensibility and negotiated features are not discussed here. Considerable reference is made to symbolic names of MPTCP options throughout this section -- these are subtypes of the IANA-assigned IANA&#8209;assigned MPTCP option (see <xref target="IANA"/>), target="IANA" format="default"/>), and their formats are defined in the detailed protocol specification that follows provided in <xref target="sec_protocol"/>.</t> target="sec_protocol" format="default"/>.</t>
      <t>A Multipath TCP connection provides a bidirectional bytestream between two hosts communicating like normal TCP and, thus, and thus does not require any change to the applications. However, Multipath TCP enables the hosts to use different paths with different IP addresses to exchange packets belonging to the MPTCP connection. A Multipath TCP connection appears like a normal TCP connection to an application. However, to the network layer, each MPTCP subflow looks like a regular TCP flow whose segments carry a new TCP option type. Multipath TCP manages the creation, removal, and utilization of these subflows to send data. The number of subflows that are managed within a Multipath TCP connection is not fixed fixed, and it can fluctuate during the lifetime of the Multipath TCP connection.</t>
      <t>All MPTCP operations are signaled with a TCP option -- a single numerical type for MPTCP, with "sub-types" "subtypes" for each MPTCP message. What follows is a summary of the purpose and rationale of these messages.</t>
      <section title="Initiating numbered="true" toc="default">
        <name>Initiating an MPTCP Connection"> Connection</name>
        <t>This is the same signaling as for initiating a normal TCP connection, but the SYN, SYN/ACK, and initial ACK (and data) packets also carry the MP_CAPABLE option. This option has a variable length and serves multiple purposes. Firstly, it verifies whether the remote host supports Multipath TCP; secondly, this option allows the hosts to exchange some information to authenticate the establishment of additional subflows. Further details are given in <xref target="sec_init"/>.</t>

<figure><artwork align="left"><![CDATA[ target="sec_init" format="default"/>.</t>
        <artwork align="left" name="" type="" alt=""><![CDATA[
   Host A                                  Host B
   ------                                  ------
   MP_CAPABLE                ->
   [flags]
                             <-            MP_CAPABLE
                                           [B's key, flags]
   ACK + MP_CAPABLE (+ data) ->
   [A's key, B's key, flags, (data-level details)]
]]></artwork></figure>  ]]></artwork>
        <t>Retransmission of the ACK + MP_CAPABLE can occur if it is not known if it has been received. The following diagrams show all possible exchanges for the initial subflow setup to ensure this reliability.</t>

<figure><artwork align="left"><![CDATA[
        <artwork align="left" name="" type="" alt=""><![CDATA[
   Host A (with data to send immediately)  Host B
   ------                                  ------
   MP_CAPABLE                ->
   [flags]
                             <-            MP_CAPABLE
                                           [B's key, flags]
   ACK + MP_CAPABLE + data   ->
   [A's key, B's key, flags, data-level details]

   Host A (with data to send later)        Host B
   ------                                  ------
   MP_CAPABLE                ->
   [flags]
                             <-            MP_CAPABLE
                                           [B's key, flags]
   ACK + MP_CAPABLE          ->
   [A's key, B's key, flags]

   ACK + MP_CAPABLE + data   ->
   [A's key, B's key, flags, data-level details]

   Host A                                  Host B (sending first)
   ------                                  ------
   MP_CAPABLE                ->
   [flags]
                             <-            MP_CAPABLE
                                           [B's key, flags]
   ACK + MP_CAPABLE          ->
   [A's key, B's key, flags]

                             <-            ACK + DSS + data
                                           [data-level details]
]]></artwork></figure> ]]></artwork>
      </section>
      <section title="Associating numbered="true" toc="default">
        <name>Associating a New Subflow with an Existing MPTCP Connection"> Connection</name>
        <t>The exchange of keys in the MP_CAPABLE handshake provides material that can be used to authenticate the endpoints when new subflows will be set up.
Additional subflows begin in the same way as initiating a normal TCP connection, but the SYN, SYN/ACK, and ACK packets also carry the MP_JOIN option. </t>
        <t>Host A initiates a new subflow between one of its addresses and one
        of Host B's addresses. The token -- generated from the key -- is used
        to identify which MPTCP connection it is joining, and the HMAC Hash&#8209;based
        Message Authentication Code (HMAC) is used for authentication. The Hash-based Message Authentication Code (HMAC) HMAC uses the keys exchanged in the MP_CAPABLE handshake, handshake and the random numbers (nonces) exchanged in these MP_JOIN options. MP_JOIN also contains flags and an Address ID that can be used to refer to the source address without the sender needing to know if it has been changed by a NAT. Further details are given in <xref target="sec_join"/>.</t>

<figure><artwork align="left"><![CDATA[ target="sec_join" format="default"/>.</t>
        <artwork align="left" name="" type="" alt=""><![CDATA[
   Host A                                  Host B
   ------                                  ------
   MP_JOIN               ->
   [B's token, A's nonce,
    A's Address ID, flags]
                         <-                MP_JOIN
                                           [B's HMAC, B's nonce,
                                            B's Address ID, flags]
   ACK + MP_JOIN         ->
   [A's HMAC]

                         <-                ACK
]]></artwork></figure> ]]></artwork>
      </section>
      <section title="Informing numbered="true" toc="default">
        <name>Informing the Other Host about Another Potential Address"> Address</name>
        <t>The set of IP addresses associated to a multihomed host may change during the lifetime of an MPTCP connection. MPTCP supports the addition and removal of addresses on a host both implicitly and explicitly. If Host A has established a subflow starting at address/port address&wj;/port pair IP#-A1 and wants to open a second subflow starting at address/port address&wj;/port pair IP#-A2, it simply initiates the establishment of the subflow as explained above. The remote host will then be implicitly informed about the new address.</t>
        <t>In some circumstances, a host may want to advertise to the remote
        host the availability of an address without establishing a new subflow, subflow
 -- for example, when a NAT prevents setup in one direction.  In the  In&nbsp;the example below, Host A informs Host B about its alternative IP address/port IP&nbsp;address&wj;/port pair (IP#-A2). Host B may later send an MP_JOIN to this new address. The ADD_ADDR option contains a an HMAC to authenticate the address as having been sent from the originator of the connection. The receiver of this option echoes it back to the client to indicate successful receipt. Further details are given in <xref target="sec_add_address"/>.</t>

<figure><artwork align="left"><![CDATA[ target="sec_add_address" format="default"/>.</t>
        <artwork align="left" name="" type="" alt=""><![CDATA[
   Host A                                 Host B
   ------                                 ------
   ADD_ADDR                  ->
   [Echo-flag=0,
    IP#-A2,
    IP#-A2's Address ID,
    HMAC of IP#-A2]

                             <-          ADD_ADDR
                                         [Echo-flag=1,
                                          IP#-A2,
                                          IP#-A2's Address ID,
                                          HMAC of IP#-A2]
]]></artwork></figure> ]]></artwork>
        <t>There is a corresponding signal for address removal, making use of
        the Address ID that is signaled in the add address ADD_ADDR handshake.

 Further details are given in <xref target="sec_remove_addr"/>.</t>

<figure><artwork align="left"><![CDATA[ target="sec_remove_addr" format="default"/>.</t>
        <artwork align="left" name="" type="" alt=""><![CDATA[
   Host A                                 Host B
   ------                                 ------
   REMOVE_ADDR               ->
   [IP#-A2's Address ID]
]]></artwork></figure> ]]></artwork>
      </section>
      <section title="Data numbered="true" toc="default">
        <name>Data Transfer Using MPTCP"> MPTCP</name>
        <t>To ensure reliable, in-order delivery of data over subflows that may appear and disappear at any time, MPTCP uses a 64-bit data sequence number Data Sequence Number (DSN) to number all data sent over the MPTCP connection. Each subflow has its own 32-bit sequence number space, utilising utilizing the regular TCP sequence number header, and an MPTCP option maps the subflow sequence space to the data sequence space. In this way, data can be retransmitted on different subflows (mapped to the same DSN) in the event of failure.</t>
        <t>The Data Sequence Signal (DSS) carries the Data Sequence Mapping. The Data Sequence Mapping consists of the subflow sequence number, data sequence number, and length for which this mapping is valid. This option can also carry a connection-level acknowledgment (the "Data ACK") for the received DSN.</t>
        <t>With MPTCP, all subflows share the same receive buffer and advertise the same receive window. There are two levels of acknowledgment in MPTCP. Regular TCP acknowledgments are used on each subflow to acknowledge the reception of the segments sent over the subflow independently of their DSN. In addition, there are connection-level acknowledgments for the data sequence space. These acknowledgments track the advancement of the bytestream and slide the receiving receive window.</t>
        <t>Further details are given in <xref target="sec_generalop"/>.</t>

<figure><artwork align="left"><![CDATA[ target="sec_generalop" format="default"/>.</t>
        <artwork align="left" name="" type="" alt=""><![CDATA[
   Host A                                 Host B
   ------                                 ------
   DSS                       ->
   [Data Sequence Mapping]
   [Data ACK]
   [Checksum]
]]></artwork></figure> ]]></artwork>
      </section>
      <section title="Requesting numbered="true" toc="default">
        <name>Requesting a Change in a Path's Priority"> Priority</name>
        <t>Hosts can indicate at initial subflow setup whether they wish the subflow to be used as a regular or backup path -- a backup path only being used if there are no regular paths available. During a connection, Host A can request a change in the priority of a subflow through the MP_PRIO signal to Host B. Further details are given in <xref target="sec_policy"/>.</t>

<figure><artwork align="left"><![CDATA[ target="sec_policy" format="default"/>.</t>
        <artwork align="left" name="" type="" alt=""><![CDATA[
   Host A                                 Host B
   ------                                 ------
   MP_PRIO                   ->
]]></artwork></figure>                 ]]></artwork>
      </section>
      <section title="Closing numbered="true" toc="default">
        <name>Closing an MPTCP Connection"> Connection</name>
        <t>When a host wants to close an existing subflow, subflow but not the whole connection, it can initiate a regular TCP FIN/ACK exchange.</t>
        <t>When Host A wants to inform Host B that it has no more data to send, it signals this "Data FIN" as part of the Data Sequence Signal DSS (see above). It has the same semantics and behavior as a regular TCP FIN, but at the connection level. Once all the data on the MPTCP connection has been successfully received, then this message is acknowledged at the connection level with a Data ACK. Further details are given in <xref target="sec_close"/>.</t>

<figure><artwork align="left"><![CDATA[ target="sec_close" format="default"/>.</t>
        <artwork align="left" name="" type="" alt=""><![CDATA[
   Host A                                 Host B
   ------                                 ------
   DSS                       ->
   [Data FIN]
                             <-           DSS
                                          [Data ACK]
]]></artwork></figure> ]]></artwork>
        <t>There is an additional method of connection closure, referred to as
        "Fast Close", which is analogous to closing a single-path TCP
        connection with a RST signal. The MP_FASTCLOSE signal is used to
        indicate to the peer that the connection will be abruptly closed and
        no data will be accepted anymore. This can be used on an ACK (ensuring (which
        ensures reliability of the signal), signal) or a RST (which is does not).
 Both examples are shown in the following diagrams. Further details are given in <xref target="sec_fastclose"/>.</t>

<figure><artwork align="left"><![CDATA[ target="sec_fastclose" format="default"/>.</t>
        <artwork align="left" name="" type="" alt=""><![CDATA[
   Host A                                 Host B
   ------                                 ------
   ACK + MP_FASTCLOSE          ->
   [B's key]

   [RST on all other subflows] ->

                               <-         [RST on all subflows]

   Host A                                 Host B
   ------                                 ------
   RST + MP_FASTCLOSE          ->
   [B's key] [on all subflows]

                               <-         [RST on all subflows]
]]></artwork></figure> ]]></artwork>
      </section>
      <section title="Notable Features"> numbered="true" toc="default">
        <name>Notable Features</name>
        <t>It is worth highlighting that MPTCP's signaling has been designed with several key requirements in mind:

<list style="symbols">
<t>To

</t>
        <ul spacing="normal">
          <li>To cope with NATs on the path, addresses are referred to by Address IDs, in case the IP packet's source
address gets changed by a NAT. Setting up a new TCP flow is not possible if the receiver of the SYN is behind a NAT;
to allow subflows to be created when either end is behind a NAT, MPTCP uses the ADD_ADDR message. </t>

<t>MPTCP </li>
          <li>MPTCP falls back to ordinary TCP if MPTCP operation is not possible,
 possible -- for example, if one host is not MPTCP capable or if a middlebox alters the payload. This is discussed in <xref target="sec_fallback"/>.</t>

<t>To target="sec_fallback" format="default"/>.</li>
          <li>To address the threats identified in <xref target="RFC6181"/>, target="RFC6181"
          format="default"/>, the following steps are taken: keys are sent in
          the clear in the MP_CAPABLE messages; MP_JOIN messages are secured
          with HMAC-SHA256 (<xref target="RFC2104"/>, target="RFC2104" format="default"/> using
          the algorithm in <xref target="RFC6234"/>) target="RFC6234" format="default"/>) using those keys; and standard
          TCP validity checks are made on the other messages (ensuring that
          sequence numbers are in-window in&#8209;window <xref target="RFC5961"/>). target="RFC5961"
          format="default"/>).
 Residual threats to MPTCP v0 were identified in <xref target="RFC7430"/>, target="RFC7430"
 format="default"/>, and those affecting the protocol (i.e. modification (i.e., modifications to
 ADD_ADDR) have been incorporated in this document.
 Further discussion of security can be found in <xref target="sec_security"/>.</t>
</list></t> target="sec_security" format="default"/>.</li>
        </ul>
      </section>
    </section>
    <section title="MPTCP Protocol" anchor="sec_protocol"> anchor="sec_protocol" numbered="true" toc="default">
      <name>MPTCP Operations: An Overview</name>
      <t>This section describes the operation of the MPTCP protocol, and is subdivided into sections for MPTCP. The
      subsections below discuss each key part of the protocol operation.</t>
      <t>All MPTCP operations are signaled using optional TCP header fields. A single TCP option number ("Kind") has been assigned by IANA for MPTCP (see <xref target="IANA"/>), target="IANA" format="default"/>), and then individual messages will be determined by a "subtype", the values of which are also stored in an IANA registry (and are also listed in <xref target="IANA"/>). target="IANA" format="default"/>). As with all TCP options, the Length field is specified in bytes, bytes and includes the 2 bytes 2&nbsp;bytes of Kind and Length.</t>
      <t>Throughout this document, when reference is made to an MPTCP option by symbolic name, such as "MP_CAPABLE", this refers to a TCP option with the single MPTCP option type, and with the subtype value of the symbolic name as defined in <xref target="IANA"/>. target="IANA" format="default"/>. This subtype is a 4-bit field -- the first 4 bits of the option payload, as shown in <xref target="fig_option"/>. target="fig_option" format="default"/>. The MPTCP messages are defined in the following sections.</t>

      <?rfc needLines='8'?>
      <figure align="center" anchor="fig_option" title="MPTCP anchor="fig_option">
        <name>MPTCP Option Format"> Format</name>
        <artwork align="left"><![CDATA[ align="left" name="" type="" alt=""><![CDATA[
                       1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +---------------+---------------+-------+-----------------------+
  |     Kind      |    Length     |Subtype|                       |
  +---------------+---------------+-------+                       |
  |                     Subtype-specific data                     |
  |                       (variable length)                       |
  +---------------------------------------------------------------+ ]]></artwork>
      </figure>
      <t>Those MPTCP options associated with subflow initiation are used on
      packets with the SYN flag set. Additionally, there is one MPTCP option
      for signaling metadata to ensure that segmented data can be recombined for delivery to the application.</t>
      <t>The remaining options, however, are signals that do not need to be on
      a specific packet, such as those for signaling additional
      addresses. Whilst While an implementation may desire to send MPTCP options as
      soon as possible, it may not be possible to combine all desired options
      (both those for MPTCP and for regular TCP, such as SACK (selective
      acknowledgment) <xref target="RFC2018"/>) target="RFC2018" format="default"/>) on a single
      packet. Therefore, an implementation may choose to send duplicate ACKs
      containing the additional signaling information. This changes the
      semantics of a duplicate ACK; these are usually only sent as a signal of
      a lost segment <xref target="RFC5681"/> target="RFC5681" format="default"/> in regular
      TCP. Therefore, an MPTCP implementation receiving a duplicate ACK that
      contains an MPTCP option MUST NOT <bcp14>MUST NOT</bcp14> treat it as a signal of
      congestion. Additionally, an MPTCP implementation SHOULD NOT <bcp14>SHOULD
      NOT</bcp14> send more than two duplicate ACKs in a row for the purposes
      of sending MPTCP options alone, in order to ensure that no middleboxes misinterpret this as a sign of congestion.</t>
      <t>Furthermore, standard TCP validity checks (such as ensuring that the
      sequence number and acknowledgment number are within the window) MUST <bcp14>MUST</bcp14> be undertaken before processing any MPTCP signals, as described in <xref target="RFC5961"/>, target="RFC5961" format="default"/>, and initial subflow sequence numbers SHOULD <bcp14>SHOULD</bcp14> be generated according to the recommendations in <xref target="RFC6528"/>.</t> target="RFC6528" format="default"/>.</t>
      <section title="Connection Initiation" anchor="sec_init"> anchor="sec_init" numbered="true" toc="default">
        <name>Connection Initiation</name>
        <t>Connection initiation begins with a SYN, SYN/ACK, ACK exchange
        on a single path. Each packet
        contains the Multipath Capable (MP_CAPABLE) MPTCP option
        (<xref target="tcpm_capable"/>). target="tcpm_capable" format="default"/>). This option declares its
        sender is capable of performing Multipath TCP and wishes to do
        so on this particular connection.</t>

        <t>The MP_CAPABLE exchange in this specification (v1) is different to
        that specified in v0.  If a host supports multiple versions
        of MPTCP, the sender of the MP_CAPABLE option SHOULD signal the
        highest version number it supports.  In return, in its MP_CAPABLE option,
        the receiver will signal the version
        <figure anchor="tcpm_capable">
          <name>Multipath Capable (MP_CAPABLE) Option</name>
          <artwork align="left" name="" type="" alt=""><![CDATA[
                       1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +---------------+---------------+-------+-------+---------------+
  |     Kind      |    Length     |Subtype|Version|A|B|C|D|E|F|G|H|
  +---------------+---------------+-------+-------+---------------+
  |                   Option Sender's Key (64 bits)               |
  |                      (if option Length > 4)                   |
  |                                                               |
  +---------------------------------------------------------------+
  |                  Option Receiver's Key (64 bits)              |
  |                      (if option Length > 12)                  |
  |                                                               |
  +-------------------------------+-------------------------------+
  |  Data-Level Length (16 bits)  |  Checksum (16 bits, optional) |
  +-------------------------------+-------------------------------+ ]]></artwork>
        </figure>
        <t>The MP_CAPABLE exchange in this specification (v1) is different than
        that specified in v0.  If a host supports multiple versions
        of MPTCP, the sender of the MP_CAPABLE option <bcp14>SHOULD</bcp14> signal the
        highest version number it supports.  In return, in its MP_CAPABLE option,
        the receiver will signal the version number it wishes to use, which MUST <bcp14>MUST</bcp14>
        be equal to or lower than the version number indicated in the initial
        MP_CAPABLE.
        There is a caveat though caveat, though, with respect to this version negotiation with
        old listeners that only support v0. A listener that supports v0 expects that
        the MP_CAPABLE option in the SYN-segment includes SYN segment will include the initiator's
        key. If If, however,
        the initiator however already upgraded to v1, it won't include the key in the
        SYN-segment.
        SYN segment. Thus, the listener will ignore the MP_CAPABLE of this SYN-segment SYN segment
        and reply with a SYN/ACK that does not include an MP_CAPABLE. The initiator MAY <bcp14>MAY</bcp14>
        choose to immediately fall back to TCP or MAY <bcp14>MAY</bcp14> choose to attempt a connection
        using MPTCP v0 (if the initiator supports v0), in order to discover whether the
        listener supports the earlier version of MPTCP. In general a general, an MPTCP v0 connection
        is
        will likely to be preferred to over a TCP one, however connection; however, in a particular deployment scenario scenario,
        it may be known that the listener is unlikely to support MPTCPv0 MPTCP v0 and so the
        initiator may prefer not to attempt a v0 connection. An initiator MAY <bcp14>MAY</bcp14> cache
        information for a peer about what version of MPTCP it supports supports, if any, and use
        this information for future connection attempts.</t>
        <t>The MP_CAPABLE option is variable-length, of variable length, with different fields
        included
        included, depending on which packet the option is used on. The full
        MP_CAPABLE option is shown in <xref target="tcpm_capable"/>.</t>

        <?rfc needLines='10'?>
        <figure align="center" anchor="tcpm_capable" title="Multipath Capable (MP_CAPABLE) Option">
          <artwork align="left"><![CDATA[
                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +---------------+---------------+-------+-------+---------------+
   |     Kind      |    Length     |Subtype|Version|A|B|C|D|E|F|G|H|
   +---------------+---------------+-------+-------+---------------+
   |                   Option Sender's Key (64 bits)               |
   |                      (if option Length > 4)                   |
   |                                                               |
   +---------------------------------------------------------------+
   |                  Option Receiver's Key (64 bits)              |
   |                      (if option Length > 12)                  |
   |                                                               |
   +-------------------------------+-------------------------------+
   |  Data-Level Length (16 bits)  |  Checksum (16 bits, optional) |
   +-------------------------------+-------------------------------+
            ]]></artwork>
        </figure> target="tcpm_capable" format="default"/>.</t>
        <t>The MP_CAPABLE option is carried on the SYN, SYN/ACK, and ACK packets that start the first subflow of an MPTCP connection, as well as the first packet that carries data, if the initiator wishes to send first. The data carried by each option is as follows, where A = initiator A&nbsp;=&nbsp;initiator and B = listener.
          <list style="symbols">
            <t>SYN
        </t>
        <ul spacing="normal">
          <li>SYN (A-&gt;B): only the first four 4 octets (Length = 4).</t>
            <t>SYN/ACK 4).</li>
          <li>SYN/ACK (B-&gt;A): B's Key key for this connection (Length = 12).</t>
            <t>ACK 12).</li>
          <li>ACK (no data) (A-&gt;B): A's Key key followed by B's Key key (Length = 20).</t>
            <t>ACK 20).</li>
          <li>ACK (with first data) (A-&gt;B): A's Key key followed by B's Key key followed by Data-Level Length, and optional Checksum (Length = 22 or 24).</t>
          </list> 24).</li>
        </ul>
        <t>
        The contents of the option is are determined by the SYN and ACK flags of the packet, along with the option's length Length field. For the diagram shown in In <xref target="tcpm_capable"/>, "sender" target="tcpm_capable" format="default"/>, "Sender" and "receiver" "Receiver" refer to the sender or receiver of the TCP packet (which can be either host).</t>
        <t>The initial SYN, containing just the MP_CAPABLE header, is used
        to define the version of MPTCP being requested, as well as exchanging requested and also to exchange
        flags to negotiate connection features, as described later.</t>
        <t>This option is used to declare the 64-bit keys that the end hosts
        have generated for this MPTCP connection. These keys are used to
        authenticate the addition of future subflows to this connection. This
        is the only time the key will be sent in the clear on the wire (unless "fast close", <xref target="sec_fastclose"/>, "Fast Close" (<xref target="sec_fastclose" format="default"/>) is used); all future subflows will identify the connection using a 32-bit "token". This token is a cryptographic hash of this key. The algorithm for this process is dependent on the authentication algorithm selected; the method of selection is defined later in this section.</t>
        <t>Upon reception of the initial SYN-segment, SYN segment, a stateful server generates a random key and replies with a SYN/ACK. The key's method of generation is implementation specific. The key MUST <bcp14>MUST</bcp14> be hard to guess, and it MUST <bcp14>MUST</bcp14> be unique for the sending host across all its current MPTCP connections. Recommendations for generating random numbers for use in keys are given in <xref target="RFC4086"/>. target="RFC4086" format="default"/>. Connections will be indexed at each host by the token (a one-way hash of the key). Therefore, an implementation will require a mapping from each token to the corresponding connection, and in turn to the keys for the connection.</t>
        <t>There is a risk that two different keys will hash to the same
        token. The risk of hash collisions is usually small, unless the host
        is handling many tens of thousands of connections. Therefore, an
        implementation SHOULD <bcp14>SHOULD</bcp14> check its list of connection
        tokens to ensure that there is no collision before sending its key,
        and if there is, then it should generate a new key. This would,
        however, be costly for a server with thousands of connections. The
        subflow handshake mechanism (<xref target="sec_join"/>) target="sec_join"
        format="default"/>) will ensure that new subflows only join the
        correct connection, however, through the cryptographic handshake, as
        well as checking the connection tokens in both directions, and
        ensuring that sequence numbers are in-window. So So, in the worst case case, if there was a token collision, the new subflow would not succeed, but the MPTCP connection would continue to provide a regular TCP service.</t>
        <t>Since key generation is implementation-specific, implementation specific, there is no
        requirement that they be simply be random numbers. An implementation is
        free to exchange cryptographic material out-of-band out of band and generate these
        keys from this, this material, in order to provide additional mechanisms by which to verify the identity of the communicating entities. For example, an implementation could choose to link its MPTCP keys to those used in higher-layer TLS or SSH connections.</t>
        <t>If the server behaves in a
        stateless manner, it has to generate its own key in a verifiable
        fashion.  This verifiable way of generating the key can be done by
        using a hash of the 4-tuple, sequence number number, and a local secret
        (similar to what is done for the TCP-sequence TCP sequence number <xref target="RFC4987"/>). target="RFC4987" format="default"/>).
        It will thus be able to verify whether it is indeed the originator of
        the key echoed back in the later subsequent MP_CAPABLE option.
        As for a stateful server, the tokens SHOULD <bcp14>SHOULD</bcp14> be checked for uniqueness, however uniqueness; however,
        if uniqueness is not met, met and there is no way to generate an alternative verifiable
        key, then the connection MUST <bcp14>MUST</bcp14> fall back to using regular TCP by not sending a an
        MP_CAPABLE in the SYN/ACK.</t> SYN&wj;/ACK.</t>
        <t>The ACK carries both A's key and B's key. This is the first time that A's key is seen on the wire, although it is expected that A will have generated a key locally before the initial SYN. The echoing of B's key allows B to operate statelessly, as described above. Therefore, A's key must be delivered reliably to B, and in order to do this, the transmission of this packet must be made reliable.</t>
        <t>If B has data to send first, then the reliable delivery of the ACK+MP_CAPABLE
        ACK&nbsp;+&nbsp;MP_CAPABLE can be inferred by the receipt of this data with a an
        MPTCP Data Sequence Signal (DSS) option (<xref target="sec_generalop"/>). target="sec_generalop"
        format="default"/>). If, however, A wishes to send data first, it has
        two options to ensure the reliable delivery of the ACK+MP_CAPABLE. ACK + MP_CAPABLE. If
        it immediately has data to send, then the third first ACK (with data) would
        also contain an MP_CAPABLE option with additional data parameters (the
        Data-Level Length and optional Checksum as shown in <xref target="tcpm_capable"/>).
        target="tcpm_capable" format="default"/>). If A does not immediately
        have data to send, it MUST <bcp14>MUST</bcp14> include the MP_CAPABLE on
        the third first ACK, but without the additional data parameters. When A does
        have data to send, it must repeat the sending of the MP_CAPABLE option
        from the third first ACK, with additional data parameters. This MP_CAPABLE
        option is used in place of the DSS, DSS and simply specifies the data-level length (1)&nbsp;the Data-Level
        Length of the payload, payload and the (2)&nbsp;the checksum (if the use of checksums is
        negotiated). This is the minimal data required to establish a an MPTCP
        connection - -- it allows validation of the payload, and given that it is the
        first data, the Initial Data Sequence Number (IDSN) is also known (as
        it is generated from the key, as described below). Conveying the keys
        on the first data packet allows the TCP reliability mechanisms to
        ensure that the packet is successfully delivered. The receiver will acknowledge this data at the connection level with a Data ACK, as if a DSS option has been received.</t>
        <t>There could be situations where both A and B attempt to transmit
        initial data at the same time. For example, if A did not initially
        have data to send, send but then needed to transmit data before it had
        received anything from B, it would use a an MP_CAPABLE option with data
        parameters (since it would not know if the MP_CAPABLE on the ACK was
        received). In such a situation, B may also have transmitted data with
        a DSS option, but it had not yet been received at A. Therefore, B has
        received data with a an MP_CAPABLE mapping after it has sent data with a
        DSS option. To ensure that these situations can be handled, it follows that the data parameters in a an MP_CAPABLE are semantically equivalent to those in a DSS option and can be used interchangeably. Similar situations could occur when the MP_CAPABLE with data is lost and retransmitted. Furthermore, in the case of TCP Segmentation Offloading, segmentation offloading, the MP_CAPABLE with data parameters may be duplicated across multiple packets, and implementations must also be able to cope with duplicate MP_CAPABLE mappings as well as duplicate DSS mappings.</t>
        <t>Additionally, the MP_CAPABLE exchange allows the safe passage of
        MPTCP options on SYN packets to be determined. If any of these options
        are dropped, MPTCP will gracefully fall back to regular single-path
        TCP, as documented in <xref target="sec_fallback"/>. target="sec_fallback" format="default"/>.
        If at any point in the handshake either party thinks the MPTCP
        negotiation is compromised, compromised -- for example example, by a middlebox corrupting
        the TCP options, options or by unexpected ACK numbers being present, present -- the host MUST <bcp14>MUST</bcp14> stop using MPTCP and no longer include MPTCP options in future TCP packets. The other host will then also fall back to regular TCP using the fall back fallback mechanism.  Note that new subflows MUST NOT <bcp14>MUST NOT</bcp14> be established (using the process documented in <xref target="sec_join"/>) target="sec_join" format="default"/>) until a Data Sequence Signal (DSS) DSS option has been successfully received across the path (as documented in <xref target="sec_generalop"/>).</t> target="sec_generalop" format="default"/>).</t>
        <t>Like all MPTCP options, the MP_CAPABLE option starts with the Kind
        and Length to specify the TCP-option TCP option's kind and its length. Followed by that This
        information is followed by the MP_CAPABLE option. The first 4 bits of
        the first octet in the MP_CAPABLE option (<xref target="tcpm_capable"/>) target="tcpm_capable"
        format="default"/>) define the MPTCP option subtype Option Subtype (see <xref target="IANA"/>;
        target="IANA" format="default"/>; for MP_CAPABLE, this value is
        0x0), and the remaining 4 bits 4&nbsp;bits of this octet specify the MPTCP
        version in use (for this specification, this is 1).</t> value is&nbsp;1).</t>
        <t>The second octet is reserved for flags, allocated as follows:

        <list style="hanging">
          <t hangText="A:">

        </t>
        <dl newline="false" spacing="normal" indent="14">
          <dt>A:</dt>
          <dd> The leftmost bit, labeled "A", SHOULD <bcp14>SHOULD</bcp14> be set to 1 to indicate "Checksum Required", required", unless the system administrator has decided that checksums are not required (for example, if the environment is controlled and no middleboxes exist that might adjust the payload).</t>
          <t hangText="B:"> payload).</dd>
          <dt>B:</dt>
          <dd> The second bit, labeled "B", is an extensibility flag, and MUST flag. It
          <bcp14>MUST</bcp14> be set to 0 for current implementations. This
          flag will be used for an extensibility mechanism in a future specification, and the impact of this flag will be defined at a later date. It is expected, but not mandated, that this flag would be used as part of an alternative security mechanism that does not require a full version upgrade of the protocol, protocol but does require redefining some elements of the handshake. If receiving a message with the 'B' "B" flag set to 1, 1 and this is not understood, then the MP_CAPABLE in this SYN MUST <bcp14>MUST</bcp14> be silently ignored, which triggers a fallback to regular TCP; the sender is expected to retry with a format compatible with this legacy specification. Note that the length of the MP_CAPABLE option, and the meanings of bits "D" through "H", may be altered by setting B=1.</t>
          <t hangText="C:"> B=1.</dd>
          <dt>C:</dt>
          <dd> The third bit, labeled "C", is set to "1" 1 to indicate that the
          sender of this option will not accept additional MPTCP subflows to
          the source address and port, and therefore the receiver MUST NOT <bcp14>MUST
          NOT</bcp14> try to open any additional subflows towards toward this address
          and port. This is an improves efficiency improvement for in situations where the
          sender knows a restriction is in place, place -- for example example, if the sender is behind a strict NAT, NAT or operating behind a legacy Layer 4 load balancer.</t>
          <t hangText="D balancer.</dd>
          <dt>D through H:"> H:</dt>
          <dd> The remaining bits, labeled "D" through "H", are used for
          crypto algorithm negotiation.  In this specification specification, only the
          rightmost bit, labeled "H", is assigned.  Bit "H" indicates the use
          of HMAC-SHA256 (as defined in <xref target="sec_join"/>). target="sec_join"
          format="default"/>).  An implementation that only supports this
          method MUST <bcp14>MUST</bcp14> set bit "H" to 1, 1 and bits "D"
          through "G" to 0.</t>
        </list>

        A 0.</dd>

        </dl>
        <t>A crypto algorithm MUST <bcp14>MUST</bcp14> be specified.  If flag bits D "D" through H "H" are all 0, the MP_CAPABLE option MUST <bcp14>MUST</bcp14> be treated as invalid and ignored (that is, it must be treated as a regular TCP handshake).</t>
        <t>The selection of the authentication algorithm also impacts the algorithm used to generate the token and the Initial Data Sequence Number (IDSN). IDSN. In this specification, with only the SHA-256 algorithm (bit "H") specified and selected, the token MUST <bcp14>MUST</bcp14> be a truncated (most significant 32 bits) 32&nbsp;bits) SHA-256 hash (<xref target="RFC6234"/>) <xref target="RFC6234" format="default"/> of the key. A different, 64-bit truncation (the least significant 64 bits) of the SHA-256 hash of the key MUST <bcp14>MUST</bcp14> be used as the IDSN. Note that the key MUST <bcp14>MUST</bcp14> be hashed in network byte order. Also note that the "least significant" bits MUST <bcp14>MUST</bcp14> be the rightmost bits of the SHA-256 digest, as per <xref target="RFC6234"/>. target="RFC6234" format="default"/>. Future specifications of the use of the crypto bits may choose to specify different algorithms for token and IDSN generation.</t>
        <t>Both the crypto and checksum bits negotiate capabilities in similar
        ways. For the Checksum Required "Checksum required" bit (labeled "A"), if either host
        requires the use of checksums, checksums MUST <bcp14>MUST</bcp14> be
        used. In other words, the only way for checksums not to be used is if
        both hosts in their SYNs set A=0. This decision is confirmed by the
        setting of the "A" bit in the third packet (the ACK) of the
        handshake. For example, if the initiator sets A=0 in the SYN, SYN but the
        responder sets A=1 in the SYN/ACK, checksums MUST <bcp14>MUST</bcp14> be
        used in both directions, and the initiator will set A=1 in the
        ACK. The decision regarding whether to use checksums will be stored by an implementation in a per-connection binary state variable. If A=1 is received by a host that does not want to use checksums, it MUST <bcp14>MUST</bcp14> fall back to regular TCP by ignoring the MP_CAPABLE option as if it was invalid.</t>
        <t>For crypto negotiation, the responder has the choice. The initiator
        creates a proposal setting a bit for each algorithm it supports to 1
        (in this version of the specification, there is only one proposal, so
        bit "H" will be always be set to 1). The responder responds with only 1 bit 1&nbsp;bit set -- this is the chosen algorithm. The rationale for this behavior is that the responder will typically be a server with potentially many thousands of connections, so it may wish to choose an algorithm with minimal computational complexity, depending on the load. If a responder does not support (or does not want to support) any of the initiator's proposals, it MUST <bcp14>MUST</bcp14> respond without an MP_CAPABLE option, thus forcing a fallback to regular TCP.</t>
        <t>The MP_CAPABLE option is only used in the first subflow of a
        connection, in order to identify the connection; all following subsequent
        subflows will use the "Join" MP_JOIN option (see <xref target="sec_join"/>) target="sec_join"
        format="default"/>) to join the existing connection.</t>
        <t>If a SYN contains an MP_CAPABLE option but the
        SYN/ACK does not, it is assumed that the sender of the SYN/ACK is not
        multipath capable; thus, the MPTCP session MUST <bcp14>MUST</bcp14> operate as
        a regular, single-path TCP. TCP session. If a SYN does not contain a an
        MP_CAPABLE option, the SYN/ACK MUST NOT <bcp14>MUST NOT</bcp14> contain one
        in response. If the third packet (the ACK) does not contain
        the MP_CAPABLE option, then the session MUST <bcp14>MUST</bcp14> fall back to
        operating as a regular, single-path TCP. TCP session. This is done to maintain
        compatibility with middleboxes on the path that drop some
        or all TCP options. Note that an implementation MAY <bcp14>MAY</bcp14> choose
        to attempt sending MPTCP options more than one time before
        making this decision to operate as regular TCP (see
        <xref target="heuristics"/>).</t> target="heuristics" format="default"/>).</t>
        <t>If the SYN packets are unacknowledged, it is up to local
        policy to decide how to respond. It is expected that a sender
        will eventually fall back to single-path TCP (i.e., without the
        MP_CAPABLE option) in order to work around middleboxes that
        may drop packets with unknown options; however, the number of
        multipath-capable attempts that are made first will be up to
        local policy.
        It is possible that MPTCP and non-MPTCP SYNs could get reordered
        in the network. Therefore, the final state is inferred from the
        presence or absence of the MP_CAPABLE option in the third packet
        of the TCP handshake.  If this option is not present, the
        connection SHOULD <bcp14>SHOULD</bcp14> fall back to regular TCP, as documented in
        <xref target="sec_fallback"/>.</t> target="sec_fallback" format="default"/>.</t>
        <t>The initial data sequence number IDSN on an MPTCP connection
        is generated from the key. The algorithm for IDSN generation is
        also determined from the negotiated authentication algorithm.
        In this specification, with only the SHA-256 algorithm specified and
        selected, the IDSN of a host MUST <bcp14>MUST</bcp14> be the least significant 64 bits 64&nbsp;bits of the
        SHA-256 hash of its key, i.e., IDSN-A = Hash(Key-A) and IDSN-B = Hash(Key-B).
        This deterministic generation of the IDSN allows a receiver to ensure
        that there are no gaps in sequence space at the start of the connection.
        The SYN with MP_CAPABLE occupies the first octet of data sequence space,
        although this does not need to be acknowledged at the connection level
        until the first data is sent (see <xref target="sec_generalop"/>).</t> target="sec_generalop" format="default"/>).</t>
      </section>
      <section title="Starting anchor="sec_join" numbered="true" toc="default">
        <name>Starting a New Subflow" anchor="sec_join"> Subflow</name>
        <t>Once an MPTCP connection has begun with the MP_CAPABLE
        exchange, further subflows can be added to the connection.
        Hosts have knowledge of their own address(es), address(es) and can
        become aware of the other host's addresses through
        signaling exchanges as described in
        <xref target="sec_pm"/>. target="sec_pm" format="default"/>. Using this knowledge, a host
        can initiate a new subflow over a currently unused pair of
        addresses. It is permitted permissible for either host in a connection
        to initiate the creation of a new subflow, but it is expected
        that this will normally be the original connection initiator
        (see <xref target="heuristics"/> target="heuristics" format="default"/> for heuristics).</t>
        <t>A new subflow is started as a normal TCP SYN/ACK
        exchange. The Join Connection (MP_JOIN) MPTCP option
        is used to identify the connection to be joined by the new subflow.
        It uses keying material that was exchanged in the initial MP_CAPABLE
        handshake (<xref target="sec_init"/>), target="sec_init" format="default"/>), and that handshake also
        negotiates the crypto algorithm in use for the MP_JOIN handshake.</t>
        <t>This section specifies the behavior of MP_JOIN using the HMAC-SHA256
        algorithm. An MP_JOIN option is present in the SYN, SYN/ACK,
        and ACK of the three-way handshake, although in each case with a
        different format.</t>
        <t>In the first MP_JOIN on the SYN packet, illustrated in
        <xref target="tcpm_join"/>, target="tcpm_join" format="default"/>, the initiator sends a token, random
        number, and address Address ID.</t>
        <figure anchor="tcpm_join">
          <name>Join Connection (MP_JOIN) Option (for Initial SYN)</name>
          <artwork align="left" name="" type="" alt=""><![CDATA[
                       1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +---------------+---------------+-------+-----+-+---------------+
  |     Kind      |  Length = 12  |Subtype|(rsv)|B|   Address ID  |
  +---------------+---------------+-------+-----+-+---------------+
  |                   Receiver's Token (32 bits)                  |
  +---------------------------------------------------------------+
  |                Sender's Random Number (32 bits)               |
  +---------------------------------------------------------------+ ]]></artwork>
        </figure>
        <t>The token is used to identify the MPTCP connection and is a
        cryptographic hash of the receiver's key, as exchanged
        in the initial MP_CAPABLE handshake (<xref target="sec_init"/>). target="sec_init" format="default"/>).
        In this specification, the tokens presented in this
        option are generated by the SHA-256 algorithm <xref target="RFC6234"/>
        algorithm, target="RFC6234" format="default"/>, truncated to the most significant 32 bits.  The token
        included in the MP_JOIN option is the token that the receiver
        of the packet uses to identify this connection; i.e., Host A
        will send Token-B (which is generated from Key-B). Note that the
        hash generation algorithm can be overridden by the choice of
        cryptographic handshake algorithm, as defined in <xref target="sec_init"/>.</t> target="sec_init" format="default"/>.</t>
        <t>The MP_JOIN SYN sends not only the token (which is static for a
        connection) but also random numbers (nonces) that are used to prevent
        replay attacks on the authentication method. Recommendations for the
        generation of random numbers for this purpose are given in <xref target="RFC4086"/>.</t> target="RFC4086" format="default"/>.</t>
        <t>The MP_JOIN option includes an "Address ID".  This is an identifier
        generated by the sender of the option, used to identify the source address
        of this packet, even if the IP header has been changed in transit by a middlebox.
        The numeric value of this field is generated by the sender and must map uniquely
        to a source IP address for the sending host.
        The Address ID allows address removal (<xref target="sec_remove_addr"/>) target="sec_remove_addr" format="default"/>)
        without needing to know what the source address at the
        receiver is, thus allowing address removal through NATs.
        The Address ID also allows correlation between new subflow setup attempts
        and address signaling (<xref target="sec_add_address"/>), target="sec_add_address" format="default"/>),
        to prevent setting up duplicate subflows on the same path, if an MP_JOIN
        and ADD_ADDR are sent at the same time.</t>
        <t>The Address IDs of the subflow used in the initial SYN
        exchange of the first subflow in the connection are implicit, implicit
        and have the value zero. A host MUST <bcp14>MUST</bcp14> store the mappings between
        Address IDs and addresses both for itself and the remote host.
        An implementation will also need to know which local and remote
        Address IDs are associated with which established subflows, for
        when addresses are removed from a local or remote host.</t>
        <t>The MP_JOIN option on packets with the SYN flag set also includes 4 bits
        4&nbsp;bits of flags, 3 of which are currently reserved and MUST
        <bcp14>MUST</bcp14> be set to zero 0 by the sender. The final bit, labeled
        "B", indicates whether the sender of this option wishes (1)&nbsp;wishes this
        subflow to be used as a backup path (B=1) in the event of failure of
        other paths, paths or whether it wants it (2)&nbsp;wants the subflow to be used as part of the
        connection immediately. By setting B=1, the sender of the option is
        requesting that the other host to only send data on this subflow if there
 are no available subflows where B=0. Subflow policy is discussed in more
 detail in <xref target="sec_policy"/>.</t>

        <?rfc needLines='10'?>
        <figure align="center" anchor="tcpm_join" title="Join Connection (MP_JOIN) Option (for Initial SYN)">
          <artwork align="left"><![CDATA[
                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +---------------+---------------+-------+-----+-+---------------+
   |     Kind      |  Length = 12  |Subtype|(rsv)|B|   Address ID  |
   +---------------+---------------+-------+-----+-+---------------+
   |                   Receiver's Token (32 bits)                  |
   +---------------------------------------------------------------+
   |                Sender's Random Number (32 bits)               |
   +---------------------------------------------------------------+
            ]]></artwork>
        </figure> target="sec_policy" format="default"/>.</t>
        <t>When receiving a SYN with an MP_JOIN option that contains
        a valid token for an existing MPTCP connection, the recipient
        SHOULD
        <bcp14>SHOULD</bcp14> respond with a SYN/ACK also containing an MP_JOIN
        option containing a random number and a truncated (leftmost 64
        bits) Hash-based Message Authentication Code (HMAC). 64&nbsp;bits) HMAC. This
        version of the option is shown in <xref target="tcpm_join2"/>. target="tcpm_join2" format="default"/>. If the token is unknown, unknown or the host wants to refuse subflow
        establishment (for example, due to a limit on the number of
        subflows it will permit), the receiver will send back a reset
        (RST) signal, analogous to an unknown port in TCP, containing a an
        MP_TCPRST option (<xref target="sec_reset"/>) target="sec_reset" format="default"/>) with a an "MPTCP
        specific error" reason code. Although calculating an HMAC
        requires cryptographic operations, it is believed that the
        32-bit token in the MP_JOIN SYN gives sufficient protection against blind state
        exhaustion attacks; therefore, there is no need to provide
        mechanisms to allow a responder to operate statelessly at the
        MP_JOIN stage.</t>
        <figure anchor="tcpm_join2">
          <name>Join Connection (MP_JOIN) Option (for Responding SYN/ACK)</name>
          <artwork align="left" name="" type="" alt=""><![CDATA[
                       1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +---------------+---------------+-------+-----+-+---------------+
  |     Kind      |  Length = 16  |Subtype|(rsv)|B|   Address ID  |
  +---------------+---------------+-------+-----+-+---------------+
  |                                                               |
  |                Sender's Truncated HMAC (64 bits)              |
  |                                                               |
  +---------------------------------------------------------------+
  |                Sender's Random Number (32 bits)               |
  +---------------------------------------------------------------+ ]]></artwork>
        </figure>
        <t>An HMAC is sent by both hosts -- by the initiator (Host A)
        in the third packet (the ACK) and by the responder (Host B) in
        the second packet (the SYN/ACK). Doing the HMAC exchange at this
        stage allows both hosts to have first exchanged random data (in the
        first two SYN packets) that is used as the "message". This
        specification defines that HMAC as defined in <xref target="RFC2104"/> target="RFC2104" format="default"/>
        is used, along with the SHA-256 hash algorithm <xref target="RFC6234"/>, target="RFC6234" format="default"/>,
        and that the output is truncated to the leftmost 160 bits (20 octets).
        Due to option space limitations, the HMAC included in
        the SYN/ACK is truncated to the leftmost 64 bits, but this is
        acceptable
        acceptable, since random numbers are used; thus, an attacker
        only has one chance to correctly guess the HMAC that matches the random
        number previously sent by the peer (if the HMAC is
        incorrect, the TCP connection is closed, so a new MP_JOIN negotiation
        with a new random number is required).</t>
        <t>The initiator's authentication information is sent in its
        first ACK (the third packet of the handshake), as shown in
        <xref target="tcpm_join3"/>. target="tcpm_join3" format="default"/>. This data needs to be sent reliably,
        since it is the only time this HMAC is sent;
        therefore, receipt of this packet MUST <bcp14>MUST</bcp14> trigger a regular TCP ACK
        in response, and the packet MUST <bcp14>MUST</bcp14> be retransmitted if this
        ACK is not received. In other words, sending the ACK/MP_JOIN
        packet places the subflow in the PRE_ESTABLISHED state, and it
        moves to the ESTABLISHED state only on receipt of an ACK from
        the receiver. It is not permitted permissible to send data while in the
        PRE_ESTABLISHED state. The reserved bits in this option MUST <bcp14>MUST</bcp14> be set
        to zero 0 by the sender.</t>
        <figure anchor="tcpm_join3">
          <name>Join Connection (MP_JOIN) Option (for&nbsp;Initiator's&nbsp;First&nbsp;ACK)</name>
          <artwork align="left" name="" type="" alt=""><![CDATA[
                       1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +---------------+---------------+-------+-----------------------+
  |     Kind      |  Length = 24  |Subtype|      (reserved)       |
  +---------------+---------------+-------+-----------------------+
  |                                                               |
  |                                                               |
  |              Sender's Truncated HMAC (160 bits)               |
  |                                                               |
  |                                                               |
  +---------------------------------------------------------------+ ]]></artwork>
        </figure>
        <t>The key for the HMAC algorithm, in the case of the message
        transmitted by Host A, will be Key-A followed by Key-B, Key-B; and in the
        case of Host B, Key-B followed by Key-A. These are the keys that were
        exchanged in the original MP_CAPABLE handshake. The "message" for the
        HMAC algorithm in each case is the concatenations of random number numbers for
        each host (denoted by R): for Host A, R-A followed by R-B; and for
        Host B, R-B followed by R-A.</t>

        <?rfc needLines='10'?>
        <figure align="center" anchor="tcpm_join2" title="Join Connection (MP_JOIN) Option (for Responding SYN/ACK)">
          <artwork align="left"><![CDATA[
                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +---------------+---------------+-------+-----+-+---------------+
   |     Kind      |  Length = 16  |Subtype|(rsv)|B|   Address ID  |
   +---------------+---------------+-------+-----+-+---------------+
   |                                                               |
   |                Sender's Truncated HMAC (64 bits)              |
   |                                                               |
   +---------------------------------------------------------------+
   |                Sender's Random Number (32 bits)               |
   +---------------------------------------------------------------+
            ]]></artwork>
        </figure>

        <?rfc needLines='12'?>
        <figure align="center" anchor="tcpm_join3" title="Join Connection (MP_JOIN) Option (for Third ACK)">
          <artwork align="left"><![CDATA[
                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +---------------+---------------+-------+-----------------------+
   |     Kind      |  Length = 24  |Subtype|      (reserved)       |
   +---------------+---------------+-------+-----------------------+
   |                                                               |
   |                                                               |
   |              Sender's Truncated HMAC (160 bits)               |
   |                                                               |
   |                                                               |
   +---------------------------------------------------------------+
            ]]></artwork>
        </figure>
        <t>These various MPTCP options fit together to enable authenticated subflow setup as illustrated in <xref target="fig_tokens"/>.</t>

        <?rfc needLines='24'?> target="fig_tokens" format="default"/>.</t>
        <figure align="center" anchor="fig_tokens" title="Example anchor="fig_tokens">
          <name>Example Use of MPTCP Authentication"> Authentication</name>
          <artwork align="left"><![CDATA[ align="left" name="" type="" alt=""><![CDATA[
                Host A                                  Host B
       ------------------------                       ----------
       Address A1    Address A2                       Address B1
       ----------    ----------                       ----------
           |             |                                |
           |             |  SYN + MP_CAPABLE              |
           |--------------------------------------------->|
           |<---------------------------------------------|
           |          SYN/ACK + MP_CAPABLE(Key-B)         |
           |             |                                |
           |        ACK + MP_CAPABLE(Key-A, Key-B)        |
           |--------------------------------------------->|
           |             |                                |
           |             |   SYN + MP_JOIN(Token-B, R-A)  |
           |             |------------------------------->|
           |             |<-------------------------------|
           |             | SYN/ACK + MP_JOIN(HMAC-B, R-B) |
           |             |                                |
           |             |     ACK + MP_JOIN(HMAC-A)      |
           |             |------------------------------->|
           |             |<-------------------------------|
           |             |             ACK                |

       HMAC-A = HMAC(Key=(Key-A+Key-B), Msg=(R-A+R-B)) HMAC(Key=(Key-A + Key-B), Msg=(R-A + R-B))
       HMAC-B = HMAC(Key=(Key-B+Key-A), Msg=(R-B+R-A)) HMAC(Key=(Key-B + Key-A), Msg=(R-B + R-A)) ]]></artwork>
        </figure>
        <t>If the token received at Host B is unknown or local policy
        prohibits the acceptance of the new subflow, the recipient MUST <bcp14>MUST</bcp14>
        respond with a TCP RST for the subflow. If appropriate, a an MP_TCPRST
        option with a an "Administratively prohibited" reason code
        (<xref target="sec_reset"/>) target="sec_reset" format="default"/>) should be included.</t>
        <t>If the token is accepted at Host B, B but the HMAC returned to
        Host A does not match the one expected, Host A MUST <bcp14>MUST</bcp14> close the
        subflow with a TCP RST. In this, this and all following subsequent cases of sending
        a RST as described in this section, the sender SHOULD <bcp14>SHOULD</bcp14> send a an MP_TCPRST option
        (<xref target="sec_reset"/>) target="sec_reset" format="default"/>) on this RST packet with the reason
        code for a "MPTCP specific an "MPTCP-specific error".</t>
        <t>If Host B does not receive the expected HMAC, HMAC or the MP_JOIN
        option is missing from the ACK, it MUST <bcp14>MUST</bcp14> close the subflow with a
        TCP RST.</t>
        <t>If the HMACs are verified as correct, then both hosts have
        verified each other as being the same peers as those that existed at
        the start of the connection, and they have agreed of which
        connection this subflow will become a part.</t>
        <t>If the SYN/ACK as received at Host A does not have an MP_JOIN
        option, Host A MUST <bcp14>MUST</bcp14> close the subflow with a TCP RST.</t>
        <t>This covers all cases of the loss of an MP_JOIN. In more detail,
        if an MP_JOIN is stripped from the SYN on the path from A to
        B, and Host
        B and Host&nbsp;B does not have a listener on the relevant
        port, it will respond with a RST in the normal way.  If in
        response to a SYN with an MP_JOIN option, option a SYN/ACK is
        received without the MP_JOIN option (either since (because it was either
        stripped on the return path, or it was stripped on the
        outgoing path but leading to Host B responded responding as if
        it were was a new regular TCP session), then the subflow is
        unusable and Host A MUST <bcp14>MUST</bcp14> close it with a RST.</t>
        <t>Note that additional subflows can be created
        between any pair of ports (but see <xref target="heuristics"/> target="heuristics" format="default"/> for
        heuristics); no explicit application-level accept calls or
        bind calls are required to open additional subflows. To
        associate a new subflow with an existing connection, the token
        supplied in the subflow's SYN exchange is used for
        demultiplexing.  This then binds the 5-tuple of the TCP
        subflow to the local token of the connection. A One consequence is
        that it is possible to allow any port pairs to be used for a
        connection. </t>
        <t>Demultiplexing subflow SYNs MUST <bcp14>MUST</bcp14> be done using the token;
        this is unlike traditional TCP, where the destination port is
        used for demultiplexing SYN packets.  Once a subflow is set up,
        demultiplexing packets is done using the 5-tuple, as in
        traditional TCP. The 5-tuples will be mapped to the local
        connection identifier (token). Note that Host A will know its
        local token for the subflow even though it is not sent on the
        wire -- only the responder's token is sent.</t>
      </section>
      <section title="General MPTCP Operation" anchor="sec_generalop"> anchor="sec_generalop" numbered="true" toc="default">
        <name>MPTCP Operation and Data Transfer</name>
        <t>This section discusses the operation of MPTCP for data transfer. At a high level, an MPTCP implementation will take one input data stream from an application, application and split it into one or more subflows, with sufficient control information to allow it to be reassembled and delivered reliably and in order to the recipient application. The following subsections define this behavior in detail.</t>
        <t>The data sequence mapping Data Sequence Mapping and the Data ACK are signaled in the Data Sequence Signal (DSS) DSS option (<xref target="tcpm_dsn"/>). target="tcpm_dsn" format="default"/>). Either or both can be signaled in one DSS, depending on the flags set. The data sequence mapping Data Sequence Mapping defines how the sequence space on the subflow maps to the connection level, and the Data ACK acknowledges receipt of data at the connection level. These functions are described in more detail in the following two subsections.</t>

        <?rfc needLines='18'?>
        <figure align="center" anchor="tcpm_dsn" title="Data anchor="tcpm_dsn">
          <name>Data Sequence Signal (DSS) Option"> Option</name>
          <artwork align="left"><![CDATA[ align="left" name="" type="" alt=""><![CDATA[
                       1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +---------------+---------------+-------+----------------------+
  |     Kind      |    Length     |Subtype| (reserved) |F|m|M|a|A|
  +---------------+---------------+-------+----------------------+
  |           Data ACK (4 or 8 octets, depending on flags)       |
  +--------------------------------------------------------------+
  |   Data sequence number Sequence Number (4 or 8 octets, depending on flags)   |
  +--------------------------------------------------------------+
  |              Subflow Sequence Number (4 octets)              |
  +-------------------------------+------------------------------+
  |  Data-Level Length (2 octets) |      Checksum (2 octets)     |
  +-------------------------------+------------------------------+ ]]></artwork>
        </figure>
        <t>The flags, when set, define the contents of this option, as follows:

          <list style="symbols">
            <t>A

        </t>
        <ul spacing="normal">
          <li>A = Data ACK present</t>
            <t>a present</li>
          <li>a = Data ACK is 8 octets (if not set, Data ACK is 4 octets)</t>
            <t>M octets)</li>
          <li>M = Data Sequence Number (DSN), Subflow Sequence Number (SSN), Data-Level Length, and Checksum (if negotiated) present</t>
            <t>m present</li>
          <li>m = Data sequence number Sequence Number is 8 octets (if not set, DSN is 4 octets)</t>
          </list> octets)</li>
        </ul>
        <t>

        The flags 'a' "a" and 'm' "m" only have meaning if the corresponding 'A' "A" or 'M' "M" flags are set; otherwise, they will be ignored. The maximum length of this option, with all flags set, is 28 octets.</t>
        <t>The 'F' "F" flag indicates "Data FIN". If present, this means that this
        mapping covers the final data from the sender. This is the
        connection-level equivalent to of the FIN flag in single-path TCP. A connection is not closed unless there has been a Data FIN exchange, a an MP_FASTCLOSE (<xref target="sec_fastclose"/>) target="sec_fastclose" format="default"/>) message, or an implementation-specific, implementation-specific connection-level send timeout. The purpose of the Data FIN and the interactions between this flag, the subflow-level FIN flag, and the data sequence mapping Data Sequence Mapping are described in <xref target="sec_close"/>. target="sec_close" format="default"/>.
        The remaining reserved bits MUST <bcp14>MUST</bcp14> be set to zero 0 by an implementation of this specification.</t>
        <t>Note that the checksum is only present in this option if the use of
        MPTCP checksumming has been negotiated at the MP_CAPABLE handshake
        (see <xref target="sec_init"/>). target="sec_init" format="default"/>). The presence of the
        checksum can be inferred from the length of the option. If a checksum
        is present, present but its use had not been negotiated in the MP_CAPABLE
        handshake, the receiver MUST <bcp14>MUST</bcp14> close the subflow with a RST
        RST, as it is not behaving as negotiated. If a checksum is not present when its use has been negotiated, the receiver MUST <bcp14>MUST</bcp14> close the subflow with a RST RST, as it is considered broken. In both cases, this RST SHOULD <bcp14>SHOULD</bcp14> be accompanied with a by an MP_TCPRST option (<xref target="sec_reset"/>) target="sec_reset" format="default"/>) with the reason code for a "MPTCP specific an "MPTCP-specific error".</t>
        <section title="Data anchor="sec_dsn" numbered="true" toc="default">
          <name>Data Sequence Mapping" anchor="sec_dsn"> Mapping</name>
          <t>The data stream as a whole can be reassembled through the use of the data sequence mapping Data Sequence Mapping components of the DSS option (<xref target="tcpm_dsn"/>), target="tcpm_dsn" format="default"/>), which define the
mapping from the subflow sequence number to the data sequence number. This is
          used by the receiver to ensure in-order delivery to the application
          layer. Meanwhile, the subflow-level sequence numbers (i.e., the
          regular sequence numbers in the TCP header) have subflow-only relevance. are only relevant to the subflow. It is expected (but not mandated) that SACK <xref target='RFC2018'/> is
          target="RFC2018" format="default"/> will be used at the subflow level to improve efficiency.</t>
          <t>The data sequence mapping Data Sequence Mapping specifies a mapping from the subflow
          sequence space to the data sequence space. This is expressed in terms of starting sequence numbers for the subflow and the data level, and a length of bytes for which this mapping is valid.
This explicit mapping for a range of data was chosen data, rather than per-packet signaling per&#8209;packet signaling, was chosen to assist with compatibility with
          situations where TCP/IP segmentation or coalescing is undertaken
          separately from the stack that is generating the data flow (e.g.,
          through the use of TCP segmentation offloading on network interface
          cards, or by middleboxes such as performance enhancing proxies). Performance Enhancing Proxies
          (PEPs) <xref target="RFC3135" format="default"/>). It
          also allows a single mapping to cover many packets, which packets; this may be useful in bulk transfer bulk&#8209;transfer situations.</t>
          <t>A mapping is fixed, in that the subflow sequence number is bound to the data sequence number after the mapping has been processed. A sender MUST NOT <bcp14>MUST NOT</bcp14> change this mapping
after it has been declared; however, the same data sequence number can be
          mapped to by different subflows for retransmission purposes (see
          <xref target="sec_retransmit"/>). target="sec_retransmit" format="default"/>). This would also
          permit the same data to be sent simultaneously on multiple subflows
          for resilience or efficiency purposes, especially in the case of
          lossy links. Although the detailed specification of such operation
          is outside the scope of this document, an implementation SHOULD
          <bcp14>SHOULD</bcp14> treat the first data that is received at a
          subflow for the data sequence space as the data that which should be delivered to the application, and any later subsequent data for that sequence space SHOULD <bcp14>SHOULD</bcp14> be ignored.</t>
          <t>The data sequence number is specified as an absolute value,
          whereas the subflow sequence numbering is relative (the SYN at the
          start of the subflow has a relative subflow sequence number of
          0). This is done to allow middleboxes to change the initial sequence number Initial Sequence
          Number (ISN) of a subflow, such as firewalls that undertake Initial Sequence Number (ISN) ISN randomization.</t>
          <t>The data sequence mapping Data Sequence Mapping also contains a checksum of the data
          that this mapping covers, if the use of checksums has been negotiated at
          the MP_CAPABLE exchange. Checksums are used to detect if the payload
          has been adjusted in any way by a non-MPTCP-aware middlebox. If this
          checksum fails, it will trigger a failure of the subflow, or a
          fallback to regular TCP, as documented in <xref target="sec_fallback"/>,
          target="sec_fallback" format="default"/>, since MPTCP can no longer
          reliably know the subflow sequence space at the receiver to build data sequence mappings.
          Data Sequence Mappings. Without checksumming enabled, corrupt data
          may be delivered to the application if a middlebox alters segment
          boundaries, alters content, or does not deliver all segments covered
          by a data sequence mapping. Data Sequence Mapping. It is therefore RECOMMENDED to use
          <bcp14>RECOMMENDED</bcp14> that checksumming be used, unless it is known
          that the network path contains no such devices.</t>
          <t>The checksum algorithm used is the standard TCP checksum <xref target="RFC0793"/>, target="RFC0793" format="default"/>, operating over the data covered by this mapping, along with a pseudo-header pseudo&#8209;header as shown in <xref target="fig_pseudo"/>.</t>

        <?rfc needLines='18'?> target="fig_pseudo" format="default"/>.</t>
          <figure align="center" anchor="fig_pseudo" title="Pseudo-Header anchor="fig_pseudo">
            <name>Pseudo-Header for DSS Checksum"> Checksum</name>
            <artwork align="left"><![CDATA[ align="left" name="" type="" alt=""><![CDATA[
                       1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +--------------------------------------------------------------+
  |                                                              |
  |                Data Sequence Number (8 octets)               |
  |                                                              |
  +--------------------------------------------------------------+
  |              Subflow Sequence Number (4 octets)              |
  +-------------------------------+------------------------------+
  |  Data-Level Length (2 octets) |        Zeros (2 octets)      |
  +-------------------------------+------------------------------+ ]]></artwork>
          </figure>
          <t>Note that the data sequence number used in the pseudo-header is always the 64-bit value, irrespective of what length is used in the DSS option itself. The standard TCP checksum algorithm has been chosen chosen, since it will be calculated anyway for the TCP subflow, and if calculated first over the data before adding the pseudo-headers, it only needs to be calculated once. Furthermore, since the TCP checksum is additive, the checksum for a DSN_MAP can be constructed by simply adding together the checksums for the data of each constituent TCP segment, segment and adding the checksum for the DSS pseudo-header.</t> pseudo&#8209;header.</t>
          <t>Note that checksumming relies on the TCP subflow containing contiguous data; therefore, a TCP subflow MUST NOT <bcp14>MUST NOT</bcp14> use the Urgent Pointer to interrupt an existing mapping. Further note, however, that if Urgent data is received on a subflow, it SHOULD <bcp14>SHOULD</bcp14> be mapped to the data sequence space and delivered to the application application, analogous to Urgent data in regular TCP.</t>
          <t>To avoid possible deadlock scenarios, subflow-level
        processing should be undertaken separately from that processing at the
        connection level. Therefore, even if a mapping does not exist
        from the subflow space to the data-level data&#8209;level space, the data
        SHOULD
        <bcp14>SHOULD</bcp14> still be ACKed at the subflow (if it is in-window).
        This data cannot, however, be acknowledged at the data level
        (<xref target="sec_dataack"/>) target="sec_dataack" format="default"/>) because its data sequence
        numbers are unknown. Implementations MAY <bcp14>MAY</bcp14> hold onto such
        unmapped data for a short while while, in the expectation that a
        mapping will arrive shortly.  Such unmapped data cannot be
        counted as being within the connection level connection-level receive window because this is
        relative to the data sequence numbers, so if the receiver runs
        out of memory to hold this data, it will have to be discarded.
        If a mapping for that subflow-level sequence space does not
        arrive within a receive window of data, that subflow SHOULD <bcp14>SHOULD</bcp14> be
        treated as broken, closed with a RST, and any unmapped data
        silently discarded.</t>
          <t>Data sequence numbers are always 64-bit quantities, quantities and
        MUST
        <bcp14>MUST</bcp14> be maintained as such in implementations.  If a
        connection is progressing at a slow rate, so protection
        against wrapped sequence numbers is not required,
        then an implementation MAY <bcp14>MAY</bcp14> include just the lower 32
        bits of the data sequence number in the data sequence mapping and/or Data Sequence Mapping and&wj;/or
        Data ACK as an optimization, and an implementation can make this choice
        independently for each packet. An implementation MUST <bcp14>MUST</bcp14> be able to receive
        and process both 64-bit or and 32-bit sequence number values, but it is not
        required that an implementation is be able to send both.</t>
          <t>An implementation MUST <bcp14>MUST</bcp14> send the full 64-bit data sequence number
        if it is transmitting at a sufficiently high rate that the 32-bit value
        could wrap within the Maximum Segment Lifetime
        (MSL) <xref target="RFC7323"/>. target="RFC7323" format="default"/>. The lengths of the DSNs used in these
        values (which may be different) are declared with flags in the
        DSS option.  Implementations MUST <bcp14>MUST</bcp14> accept a 32-bit DSN and implicitly
        promote it to a 64-bit quantity by incrementing the upper 32
        bits of the sequence number each time the lower 32
        bits wrap. A sanity check MUST <bcp14>MUST</bcp14> be implemented to ensure that
        a wrap occurs at an expected time (e.g., the sequence number jumps
        from a very high number to a very low number) and is not triggered
        by out-of-order out&#8209;of-order packets.</t>
          <t>As with the standard TCP sequence number, the data sequence
        number should not start at zero, but at a random value to make
        blind session hijacking harder. This specification requires
        setting the initial data sequence number (IDSN) IDSN of each host to the
        least significant 64 bits 64&nbsp;bits of the SHA-256 hash of the host's key, as
        described in <xref target="sec_init"/>. target="sec_init" format="default"/>. This is required also required in
        order for the receiver to know what the expected IDSN is, is and thus
        determine if any initial connection-level packets are missing; this
        is particularly relevant if two subflows start transmitting simultaneously.</t>
          <t>A data sequence mapping Data Sequence Mapping does not need to be included in
        every MPTCP packet, as long as the subflow sequence space in
        that packet is covered by a mapping known at the receiver. This
        can be used to reduce overhead in cases where the mapping is
        known in advance; one advance. One such case is when there is a single
        subflow between the hosts, and another is when segments of
        data are scheduled in larger than packet-sized larger-than-packet-sized chunks.</t>
          <t>An "infinite" mapping can be used to fall back to regular TCP by
        mapping the subflow-level data to the connection-level data
        for the remainder of the connection (see
        <xref target="sec_fallback"/>). target="sec_fallback" format="default"/>). This is achieved by setting
        the Data-Level Length field of the DSS option to the reserved value of 0. The
        checksum, in such a case, will also be set to zero.</t> 0.</t>
        </section>
        <section title="Data Acknowledgments" anchor="sec_dataack"> anchor="sec_dataack" numbered="true" toc="default">
          <name>Data Acknowledgments</name>
          <t>To provide full end-to-end resilience, MPTCP provides a
        connection-level acknowledgment, to act as a cumulative ACK for
        the connection as a whole. This is done via the "Data ACK" field of
        the DSS option (<xref target="tcpm_dsn"/>). target="tcpm_dsn" format="default"/>). The Data ACK
        is analogous to the behavior
        of the standard TCP cumulative ACK -- indicating
        how much data has been successfully received (with no
        holes). This is in comparison can be compared to the subflow-level ACK, which
        acts in a fashion analogous to TCP SACK, given that there may still be
        holes in the data stream at the connection level.
        The Data ACK specifies the next data sequence number
        it expects to receive.</t>
          <t>The Data ACK, as for the DSN, can be sent as the full 64-bit
        value,
        value or as the lower 32 bits.  If data is received with a 64-bit DSN,
        it MUST <bcp14>MUST</bcp14> be acknowledged with a 64-bit Data ACK.  If the DSN received
        is 32 bits, 32&nbsp;bits, an implementation can choose whether to send a 32-bit or
        64-bit Data ACK, and an implementation MUST <bcp14>MUST</bcp14> accept either in this situation.</t>
          <t>The Data ACK proves that the data, and all required MPTCP
        signaling, has have been received and accepted by the remote end.
        One key use of the Data ACK signal is that it is used to indicate
        the left edge of the advertised receive window. As explained in
        <xref target="sec_rwin"/>, target="sec_rwin" format="default"/>, the receive window is shared by all
        subflows and is relative to the Data ACK. Because of this, an
        implementation MUST NOT <bcp14>MUST NOT</bcp14> use the RCV.WND field of a TCP segment
        at the connection level if it does not also carry a DSS option with
        a Data ACK field. Furthermore,
        separating the connection-level acknowledgments from the
        subflow level allows processing to be done separately, and
        a receiver has the freedom to drop segments after acknowledgment
        at the subflow level, level -- for example, due to memory constraints
        when many segments arrive out of order.</t>
          <t>An MPTCP sender MUST NOT <bcp14>MUST NOT</bcp14> free data from the send buffer until
        it has been acknowledged by both a Data ACK received on any subflow
        and at the subflow level by all subflows on which the data was sent.
        The former condition ensures liveness of the
        connection
        connection, and the latter condition ensures liveness and
        self-consistence of a subflow when data needs to be
        retransmitted.
        Note, however, that if some data needs to be retransmitted multiple
        times over a subflow, there is a risk of blocking the sending send
        window. In this case, the MPTCP sender can decide to terminate the
        subflow that is behaving badly by sending a RST, using an appropriate
        MP_TCPRST (<xref target="sec_reset"/>) target="sec_reset" format="default"/>) error code.</t>
          <t>The Data ACK MAY <bcp14>MAY</bcp14> be included in all segments; however, optimizations
        SHOULD
        <bcp14>SHOULD</bcp14> be considered in more advanced implementations, where the
        Data ACK is present in segments
        only when the Data ACK value advances, and this behavior MUST <bcp14>MUST</bcp14>
        be treated as valid. This behavior ensures that the sender send buffer
        is freed, while reducing overhead when the data transfer is
        unidirectional.</t>
        </section>
        <section title="Closing anchor="sec_close" numbered="true" toc="default">
          <name>Closing a Connection" anchor="sec_close"> Connection</name>
          <t>In regular TCP, a FIN announces to the receiver that the sender has no more data to send.
In order to allow subflows to operate independently and to keep the appearance of TCP over the wire,
a FIN in MPTCP only affects the subflow on which it is sent. This
allows nodes to exercise considerable freedom over which paths are in use at any one time.
The semantics of a FIN remain as for regular TCP; i.e., it is not until both sides have ACKed
each other's FINs that the subflow is fully closed.</t>
          <t>When an application calls close() on a socket, this indicates that it has no more
data to send; for regular TCP, this would result in a FIN on the connection. For MPTCP, an
equivalent mechanism is needed, and needed; this is referred to as the DATA_FIN.</t>
          <t>A DATA_FIN is an indication that the sender has no more data to send, and
        as such it can be used to verify that all data has been successfully received. A DATA_FIN,
        as with the FIN on a regular TCP connection, is a unidirectional signal.</t>
          <t>The DATA_FIN is signaled by setting the 'F' "F" flag in the Data Sequence Signal DSS
          option (<xref target="tcpm_dsn"/>) target="tcpm_dsn" format="default"/>)
          to 1. A DATA_FIN occupies 1 octet (the final octet) of the
          connection-level sequence space. Note that the
 DATA_FIN is included in the Data-Level Length, Length but not at the subflow
 level: for example, a segment with a DSN 80, value of 80 and a
 Data-Level Length of 11, with DATA_FIN set, would map 10 octets from
 the subflow into data sequence space 80-89, and the DATA_FIN is would
 be DSN 90; therefore, this segment segment, including DATA_FIN DATA_FIN, would be
 acknowledged with a DATA_ACK of 91.</t> of&nbsp;91.</t>
          <t>Note that when the DATA_FIN is not attached to a TCP segment containing data, the Data Sequence Signal MUST DSS <bcp14>MUST</bcp14> have a subflow sequence number of 0, a Data-Level Length of 1, and the data sequence number that corresponds with the DATA_FIN itself. The checksum in this case will only cover the pseudo-header.</t>
          <t>A DATA_FIN has the same semantics and behavior as a regular TCP FIN, but at the connection level. Notably, it is only DATA_ACKed once all data has been successfully received at the connection level. Note, therefore, that a DATA_FIN is decoupled from a subflow FIN. It is only permissible to combine these signals on one subflow if there is no data outstanding on other subflows. Otherwise, it may be necessary to retransmit data on different subflows. Essentially, a host MUST NOT <bcp14>MUST NOT</bcp14> close all functioning subflows unless it is safe to do so, i.e., until all outstanding data has been DATA_ACKed, DATA_ACKed or until the segment with the DATA_FIN flag set is the only outstanding segment.</t>
          <t>Once a DATA_FIN has been acknowledged, all remaining subflows MUST
          <bcp14>MUST</bcp14> be closed with standard FIN exchanges. Both
          hosts SHOULD <bcp14>SHOULD</bcp14> send FINs on all subflows, as a courtesy courtesy,
          to allow middleboxes to clean up state even if an individual subflow
          has failed. It is also encouraged to reduce Reducing the timeouts (Maximum Segment Lifetime) (MSL) on subflows at end hosts after receiving a DATA_FIN.
          DATA_FIN is also encouraged. In particular, any subflows where there is still
          outstanding data queued (which has been retransmitted on other
          subflows in order to get the DATA_FIN acknowledged) MAY
          <bcp14>MAY</bcp14> be closed with a RST with an MP_TCPRST (<xref target="sec_reset"/>) target="sec_reset" format="default"/>) error code for "too much outstanding data".</t>
          <t>A connection is considered closed once both hosts' DATA_FINs have been acknowledged by DATA_ACKs.</t>
          <t>As specified above, a standard TCP FIN on an individual subflow
          only shuts down the subflow on which it was sent. If all subflows
          have been closed with a FIN exchange, exchange but no DATA_FIN has been
          received and acknowledged, the MPTCP connection is treated as closed
          only after a timeout. This implies that an implementation will have
          TIME_WAIT states at both the subflow level and the connection levels level (see <xref target="app_fsm"/>). target="app_fsm" format="default"/>). This permits "break-before-make" scenarios where connectivity is lost on all subflows before a new one can be re-established.</t> re&#8209;established.</t>
        </section>
        <section title="Receiver Considerations" anchor="sec_rwin"> anchor="sec_rwin" numbered="true" toc="default">
          <name>Receiver Considerations</name>
          <t>Regular TCP advertises a receive window in each packet, telling the sender how much data the receiver
is willing to accept past the cumulative ack. ACK. The receive window is used to implement flow control, throttling
down fast senders when receivers cannot keep up. </t>
          <t>MPTCP also uses a unique receive window, shared between the subflows. The idea is to allow any
subflow to send data as long as the receiver is willing to accept it. The alternative,
alternative -- maintaining per subflow per-subflow
receive windows, windows -- could end up stalling some subflows while others would not use up their window.</t>
          <t>The receive window is relative to the DATA_ACK. As in TCP, a receiver MUST NOT <bcp14>MUST NOT</bcp14> shrink the right edge of the receive window (i.e., DATA_ACK + receive window). The receiver will
use the data sequence number to tell if a packet should be accepted at the connection level.</t>
          <t>When deciding to accept packets at the subflow level, regular TCP checks
the sequence number in the packet against the allowed receive window.
With multipath, MPTCP, such a check is done using only the connection-level window. A sanity
check SHOULD <bcp14>SHOULD</bcp14> be performed at the subflow level to ensure that the subflow and mapped sequence
numbers meet the following test: SSN - SUBFLOW_ACK &lt;= DSN - DATA_ACK, where SSN is the subflow sequence number of the received packet and SUBFLOW_ACK is the RCV.NXT (next expected sequence number) of the subflow (with the equivalent connection-level definitions for DSN and DATA_ACK).</t>
          <t>In regular TCP, once a segment is deemed in-window, it is put either in either
the in-order receive queue or in the out-of-order queue.
In Multipath TCP, the same happens thing happens, but at the connection level: a segment
is placed in the connection level connection-level in-order or out-of-order queue if
it is in-window at both the connection level and the subflow levels. level.
The stack still has to remember, for each subflow, which segments were
received successfully so that it can ACK them at the subflow level appropriately.
Typically, this will be implemented by keeping per subflow per-subflow out-of-order
queues (containing only message headers, headers -- not the payloads) and remembering
the value of the cumulative ACK.
</t>
          <t>It is important for implementers to understand how large
          a receiver receive buffer is appropriate. The lower bound for full
          network utilization is the maximum bandwidth-delay product
          of any one of the paths.  However, this might be insufficient
          when a packet is lost on a slower subflow and needs to be
          retransmitted (see <xref target="sec_retransmit"/>). target="sec_retransmit" format="default"/>). A tight
          upper bound would be the maximum round-trip time (RTT) of any path multiplied
          by the total bandwidth available across all paths. This
          permits all subflows to continue at full speed while a
          packet is fast-retransmitted on the maximum RTT path. Even
          this might be insufficient to maintain full performance in
          the event of a retransmit timeout on the maximum RTT path.
          It is for future study to determine
          Determining the relationship between
          retransmission strategies and receive buffer sizing.</t> sizing is left for future study.</t>
        </section>
        <section title="Sender Considerations" anchor="sec_sender"> anchor="sec_sender" numbered="true" toc="default">
          <name>Sender Considerations</name>
          <t>The sender remembers receiver receive window advertisements from the
          receiver. It should only update its local receive window values when
          the largest sequence number allowed (i.e., DATA_ACK + receive
          window) increases, increases on the receipt of a DATA_ACK. This is important to allow using
          for allowing the use of paths with different RTTs, RTTs and thus different feedback loops. </t>
          <t>MPTCP uses a single receive window across all subflows, and if
          the receive window was guaranteed to be unchanged end-to-end, end to end, a host could always read the most recent receive window value. However, some classes of middleboxes may alter the TCP-level receive window. Typically, these will
shrink the offered window, although for short periods of time it may be possible for the window to be larger (however,
note that this would not continue for long periods periods, since ultimately the middlebox must keep up with
delivering data to the receiver). Therefore, if receive window sizes differ on multiple subflows,
when sending data MPTCP SHOULD <bcp14>SHOULD</bcp14> take the largest of the most recent window sizes as the one to use in calculations.
This rule is implicit in the requirement not to reduce the right edge of the window.</t>
          <t>The sender MUST <bcp14>MUST</bcp14> also remember the receive windows advertised by each subflow.
The allowed window for subflow i is (ack_i, ack_i + rcv_wnd_i), where ack_i is the
subflow-level cumulative ACK of subflow i. This ensures that data will not be sent to a middlebox
unless there is enough buffering for the data. </t>
          <t>Putting the two rules together, we get the following: a sender is allowed to send
data segments with data-level sequence numbers between (DATA_ACK, DATA_ACK + receive_window).
Each of these segments will be mapped onto subflows, as long as subflow sequence numbers
are in the allowed windows for those subflows. Note that subflow sequence numbers do not
generally affect flow control if the same receive window is advertised across all subflows.
They will perform flow control for those subflows with a smaller advertised receive window.
          </t>
          <t>The send buffer MUST, <bcp14>MUST</bcp14>, at a minimum, be as big as the receive buffer, to enable the sender to reach maximum throughput.</t>
        </section>
        <section title="Reliability anchor="sec_retransmit" numbered="true" toc="default">
          <name>Reliability and Retransmissions" anchor="sec_retransmit"> Retransmissions</name>
          <t>The data sequence mapping Data Sequence Mapping allows senders to resend data with the
          same data sequence number on a different subflow. When doing this, a
          host MUST <bcp14>MUST</bcp14> still retransmit the original data on the
          original subflow, in order to preserve the subflow subflow's integrity
          (middleboxes could replay old data, and/or data and&wj;/or could reject holes in
          subflows), and a receiver will ignore these retransmissions. While
          this is clearly suboptimal, for compatibility reasons this is
          sensible behavior. Optimizations could be negotiated in future
          versions of this protocol. Note also that this property would also permit a sender to always send the same data, with the same data sequence number, on multiple subflows, if desired for reliability reasons.</t>
          <t>This protocol specification does not mandate any mechanisms for handling retransmissions, and much will be dependent upon local policy
(as discussed in <xref target="sec_policy"/>). target="sec_policy" format="default"/>). One can imagine aggressive connection-level retransmissions retransmission policies where every packet lost at the subflow level is retransmitted on
a different subflow (hence, (hence wasting bandwidth but possibly reducing application-to-application delays), delays) or conservative retransmission policies where connection-level retransmits retransmissions
are only used after a few subflow-level retransmission timeouts occur.</t>
          <t>It is envisaged that a standard connection-level retransmission mechanism
would be implemented around a connection-level data queue: all segments that haven't
been DATA_ACKed are stored. A timer is set when
the head of the connection-level connection level is ACKed at the subflow level but its corresponding data is not ACKed DATA_ACKed at the data level. This timer will guard against failures in retransmission failures
by middleboxes that proactively ACK data.</t>
          <t>The sender MUST <bcp14>MUST</bcp14> keep data in its send buffer as
          long as the data has not been acknowledged at both (1)&nbsp;at the
          connection level and on (2)&nbsp;on all subflows on which it
has been sent. In this way, the sender can always retransmit the data if needed, on the same subflow or on a different one. A special case is when a subflow fails: the sender
will typically resend the data on other working subflows after a timeout, timeout and will keep trying to retransmit the data
on the failed subflow too. The sender will declare the subflow failed after a predefined upper bound on retransmissions is reached (which MAY <bcp14>MAY</bcp14> be lower than the usual TCP limits of the Maximum Segment Life), MSL) or on the receipt of an ICMP error, and only then delete the outstanding data segments. </t>
          <t>If multiple retransmissions are triggered that indicate that a
          subflow performs badly, is performing badly are triggered, this MAY <bcp14>MAY</bcp14> lead to a host resetting the subflow with a RST. However, additional research is required to understand the heuristics of how and when to reset underperforming subflows. For example, a highly asymmetric path may be misdiagnosed as underperforming. A RST for this purpose SHOULD <bcp14>SHOULD</bcp14> be accompanied with by an "Unacceptable performance" MP_TCPRST option (<xref target="sec_reset"/>).</t> target="sec_reset" format="default"/>).</t>
        </section>
        <section title="Congestion anchor="sec_cc" numbered="true" toc="default">
          <name>Congestion Control Considerations" anchor="sec_cc"> Considerations</name>
          <t>Different subflows in an MPTCP connection have different congestion windows.
To achieve fairness at bottlenecks and resource pooling, it is necessary to couple the
congestion windows in use on each subflow, in order to push most traffic to uncongested links.
One algorithm for achieving this is presented in <xref target="RFC6356"/>; target="RFC6356" format="default"/>;
the algorithm does not achieve perfect resource pooling but is "safe" in that it is readily
deployable in the current Internet. By this, this we mean that it does not take up more capacity
on any one path than if it was a single path flow using only that route, so this ensures
fair coexistence with single-path TCP at shared bottlenecks.</t>
          <t>It is foreseeable that different congestion controllers will be
          implemented for MPTCP, each aiming to achieve different properties
          in the resource pooling/fairness/stability pooling / fairness / stability design space, as well as those for achieving different properties in quality of service, reliability, and resilience.</t>
          <t>Regardless of the algorithm used,
the design of the MPTCP protocol aims to provide the congestion control
implementations with sufficient information
to take make the right decisions; this information includes, for each subflow, which packets were lost and when. </t>
        </section>
        <section title="Subflow Policy" anchor="sec_policy"> anchor="sec_policy" numbered="true" toc="default">
          <name>Subflow Policy</name>
          <t>Within a local MPTCP implementation, a host may use any local policy it wishes to decide how to share the traffic to be sent over the available paths.</t>
          <t>In the typical use case, where the goal is to maximize throughput, all available paths will be used simultaneously for data transfer, using coupled congestion control as described in <xref target="RFC6356"/>. target="RFC6356" format="default"/>. It is expected, however, that other use cases will appear.</t>
          <t>For instance, a one possibility is an 'all-or-nothing' "all-or-nothing" approach, i.e., have a second path ready for use in the event of
failure of the first path, but alternatives could include entirely saturating one path before using an additional
path (the 'overflow' "overflow" case). Such choices would be most likely based on the monetary cost of links, links but may also be
based on properties such as the delay or jitter of links, where stability (of delay or bandwidth) is more important than throughput. Application
requirements such as these are discussed in detail in <xref target="RFC6897"/>.</t> target="RFC6897" format="default"/>.</t>
          <t>The ability to make effective choices at the sender requires full knowledge of the path "cost", which
is unlikely to be the case. It would be desirable for a receiver to be able to signal their own preferences for paths,
since they will often be the multihomed party, party and may have to pay for metered incoming bandwidth.</t>
          <t>To enable this, this behavior, the MP_JOIN option (see <xref target="sec_join"/>)
          target="sec_join" format="default"/>) contains the 'B' bit, "B"&nbsp;bit,
          which allows a host to indicate to its peer that this path should be
          treated as a backup path to use only in the event of failure of
          other working subflows (i.e., a subflow where the receiver has
          indicated that B=1 SHOULD NOT <bcp14>SHOULD NOT</bcp14> be used to send data unless there are no usable subflows where B=0).</t>
          <t>In the event that the available set of paths changes, a host may
          wish to signal a change in priority of subflows to the peer (e.g., a
          subflow that was previously set as a backup should now take priority
          over all remaining subflows). Therefore, the MP_PRIO option, shown
          in <xref target="tcpm_prio"/>, target="tcpm_prio" format="default"/>, can be used to
          change the 'B' "B" flag of the subflow on which it is sent.</t>
          <t>Another use of the MP_PRIO option is to set the 'B' flag on a subflow to cleanly retire its use before closing it and removing it with REMOVE_ADDR <xref target="sec_remove_addr"/>, for example to support make-before-break session continuity, where new subflows are added before the previously used ones are closed.</t>
          <?rfc needLines='8'?>
          <figure align="center" anchor="tcpm_prio" title="Change anchor="tcpm_prio">
            <name>Change Subflow Priority (MP_PRIO) Option"> Option</name>
            <artwork align="left"><![CDATA[ align="left" name="" type="" alt=""><![CDATA[
                       1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +---------------+---------------+-------+-----+-+
  |     Kind      |     Length    |Subtype|(rsv)|B|
  +---------------+---------------+-------+-----+-+ ]]></artwork>
          </figure>
          <t>Another use of the MP_PRIO option is to set the "B" flag on a
          subflow to cleanly "retire" its use before closing it and removing it
          with REMOVE_ADDR (<xref target="sec_remove_addr" format="default"/>) -- for example, to support make-before-break session continuity, where new subflows are added before the previously used subflows are closed.</t>
          <t>It should be noted that the backup flag is a request from a data receiver to a data sender only, and the data sender SHOULD <bcp14>SHOULD</bcp14> adhere to these requests. A host cannot assume that the data sender will do so, however, since local policies -- or technical difficulties -- may override MP_PRIO requests. Note also that this signal applies to a single direction, and so the sender of this option could choose to continue using the subflow to send data even if it has signaled B=1 to the other host.</t>
        </section>
      </section>
      <section title="Address anchor="sec_pm" numbered="true" toc="default">
        <name>Address Knowledge Exchange (Path Management)" anchor="sec_pm"> Management)</name>
        <t>We use the term "path management" to refer to the exchange of information about additional paths between hosts, which in this design is managed by multiple addresses at hosts. For more detail of details regarding the architectural thinking behind this design, see the MPTCP Architecture architecture document <xref target="RFC6182"/>.</t> target="RFC6182" format="default"/>.</t>
        <t>This design makes use of two methods of sharing such
        information, and both can be used on a connection.
        The first is the direct
        setup of new subflows, already described subflows (described in
        <xref target="sec_join"/>, target="sec_join" format="default"/>), where the initiator has an
        additional address. The second method, described method (described in the
        following subsections, subsections) signals addresses explicitly to the
        other host to allow it to initiate new subflows. The
        two mechanisms are complementary: the first is implicit and
        simple, while the explicit second (explicit) is more complex but is more
        robust. Together, the these mechanisms allow addresses to change in
        flight (and thus support operation through NATs, since the
        source address need not be known), and known); they also allow the
        signaling of previously unknown addresses, addresses and of addresses
        belonging to other address families (e.g., both IPv4 and IPv6).</t>
        <t>Here is an example of typical operation of the protocol:
          <list style="symbols">
            <t>An
        </t>
        <ul spacing="normal">
          <li>An MPTCP connection is initially set up between address/port address&wj;/port A1 of Host A
              and address/port address&wj;/port B1 of Host B.&nbsp; B.  If Host A is multihomed and
              multiaddressed, it can start an additional subflow from
              its address A2 to B1, by sending a SYN with a Join an MP_JOIN
              option from A2 to B1, using B's previously declared
              token for this connection.  Alternatively, if B is
              multihomed, it can try to set up a new subflow from B2 to
              A1, using A's previously declared token.  In either
              case, the SYN will be sent to the port already in use
              for the original subflow on the receiving host.</t>

            <t>Simultaneously host.</li>
          <li>Simultaneously (or after a timeout), an ADD_ADDR option
(<xref target="sec_add_address"/>) target="sec_add_address" format="default"/>) is sent on an existing subflow, informing
the receiver of the sender's alternative address(es). The recipient can use
this information to open a new subflow to the sender's additional address. address(es).
In our example, A will send the ADD_ADDR option informing B of address/port address&wj;/port A2.
The mix of using the SYN-based SYN&#8209;based option and the ADD_ADDR option, including
timeouts, is implementation specific and can be tailored to agree with local policy.</t>

            <t>If policy.</li>
          <li>If subflow A2-B1 is successfully set up, Host B can use the Address ID in
the Join MP_JOIN option to correlate this source address with the ADD_ADDR option that will also arrive on
an existing subflow; now B knows not to open A2-B1, ignoring the ADD_ADDR.
Otherwise, if B has not received the A2-B1 MP_JOIN SYN but received the ADD_ADDR,
it can try to initiate a new subflow from one or more of its addresses to address
A2. This permits new sessions to be opened if one host is behind a NAT.</t>
          </list> NAT.</li>
        </ul>
        <t>
       Other ways of using the two signaling mechanisms are possible; for instance,
signaling addresses in other address families can only be done explicitly
using the Add Address (ADD_ADDR) option.
        </t>
        <section title="Address Advertisement" anchor="sec_add_address"> anchor="sec_add_address" numbered="true" toc="default">
          <name>Address Advertisement</name>
          <t>The Add Address (ADD_ADDR) ADD_ADDR MPTCP option announces additional addresses (and (and, optionally, ports) on which a
host can be reached (<xref target="tcpm_address"/>). target="tcpm_address" format="default"/>).
This option can be used at any time during a connection, depending on when the
sender wishes to enable multiple paths and/or and&wj;/or when paths become available. As with all MPTCP
signals, the receiver MUST <bcp14>MUST</bcp14> undertake standard TCP validity
          checks, e.g. e.g., per <xref target="RFC5961"/>, target="RFC5961" format="default"/>, before
          acting upon it.</t> upon&nbsp;it.</t>

          <figure anchor="tcpm_address">
            <name>Add Address (ADD_ADDR) Option</name>
            <artwork align="left" name="" type="" alt=""><![CDATA[
                       1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +---------------+---------------+-------+-------+---------------+
  |     Kind      |     Length    |Subtype|(rsv)|E|  Address ID   |
  +---------------+---------------+-------+-------+---------------+
  |           Address (IPv4: 4 octets / IPv6: 16 octets)          |
  +-------------------------------+-------------------------------+
  |   Port (2 octets, optional)   |                               |
  +-------------------------------+                               |
  |                Truncated HMAC (8 octets, if E=0)              |
  |                               +-------------------------------+
  |                               |
  +-------------------------------+ ]]></artwork>
          </figure>

          <t>Every address has an Address ID that can be used for uniquely identifying the address within a connection for address removal. The Address ID is also
used to identify MP_JOIN options (see <xref target="sec_join"/>) target="sec_join" format="default"/>) relating to
the same address, even when address translators are in use. The Address ID MUST <bcp14>MUST</bcp14> uniquely
identify the address for the sender of the option (within the scope of the connection), but connection); the mechanism for
allocating such IDs is implementation specific.</t>
          <t>All address Address IDs learned via either MP_JOIN or ADD_ADDR
        SHOULD
        <bcp14>SHOULD</bcp14> be stored by the receiver in a data structure
        that gathers all the Address ID
        to address Address-ID-to-address mappings for a connection
        (identified by a token pair). In this way, there is
        a stored mapping between the Address ID, observed source address, and token pair for
        future processing of control information for a connection. Note that an implementation
        MAY
        <bcp14>MAY</bcp14> discard incoming address advertisements at will, will -- for example, for avoiding to avoid updating
        mapping state, state or because advertised addresses are of no use to it (for
        example, IPv6 addresses when it has IPv4 only). Therefore, a host MUST <bcp14>MUST</bcp14> treat address
        advertisements as soft state, and it MAY <bcp14>MAY</bcp14> choose to refresh advertisements periodically.
        Note also that an implementation MAY <bcp14>MAY</bcp14> choose to cache these address advertisements even
        if they are not currently relevant but may be relevant in the future, such as IPv4
        addresses when IPv6 connectivity is available but IPv4 is awaiting DHCP.</t>
          <t>This option is shown in <xref target="tcpm_address"/>. target="tcpm_address" format="default"/>. The illustration is sized for
        IPv4 addresses. For IPv6, the length of the address will be 16 octets 16&nbsp;octets (instead of 4).</t>
          <t>The 2 octets that specify the TCP port number to use are optional optional, and their presence
        can be inferred from the length of the option. Although it is expected that the majority of
        use cases will use the same port pairs as those used for the initial subflow (e.g., port
        80 remains port 80 on all subflows, as does the ephemeral port at the client), there
        may be cases (such as port-based load balancing) where the explicit specification of
        a different port is required. If no port is specified, MPTCP SHOULD <bcp14>SHOULD</bcp14> attempt to
        connect to the specified address on the same port as the port that is already in use by the subflow
        on which the ADD_ADDR signal was sent; this is discussed in more detail in <xref target="heuristics"/>.</t> target="heuristics" format="default"/>.</t>
          <t>The Truncated HMAC parameter present in this Option option is the rightmost 64 bits of an HMAC, negotiated and
        calculated in the same way as for MP_JOIN as described in <xref target="sec_join"/>. target="sec_join" format="default"/>. For this
        specification of MPTCP, as there is only one hash algorithm option specified, this will be HMAC as
        defined in <xref target="RFC2104"/>, target="RFC2104" format="default"/>, using the SHA-256 hash algorithm <xref target="RFC6234"/>. target="RFC6234" format="default"/>.
        In the same way as for MP_JOIN, the key for the HMAC
        algorithm, in the case of the message transmitted by Host A, will be Key-A followed by Key-B, and in
        the case of Host B, Key-B followed by Key-A.  These are the keys that were exchanged in the original
        MP_CAPABLE handshake. The message for the HMAC is the Address ID, IP Address, address, and Port which port that precede
        the HMAC in the ADD_ADDR option. If the port is not present in the ADD_ADDR option, the HMAC message
        will nevertheless include two 2 octets of value zero. The rationale for the HMAC is to
        prevent unauthorized entities from injecting ADD_ADDR signals in an attempt to hijack a connection.
        Note that additionally that, additionally, the presence of this HMAC prevents the
        address from being changed in flight unless
        the key is known by an intermediary. If a host receives an ADD_ADDR option for which it cannot
        validate the HMAC, it SHOULD <bcp14>SHOULD</bcp14> silently ignore the option.</t>
          <t>A set of four flags are is present after the subtype and before the Address ID. Only the rightmost
        bit - labelled 'E' - -- labeled "E" -- is assigned in this specification. The other
        bits are currently unassigned and MUST unassigned; they <bcp14>MUST</bcp14>
        be set to zero 0 by a sender and MUST <bcp14>MUST</bcp14> be ignored by the receiver.</t>
          <t>The 'E' "E" flag exists to provide reliability for this option. Because this option will often be sent
        on pure ACKs, there is no guarantee of reliability. Therefore, a receiver receiving a fresh ADD_ADDR
        option (where E=0), E=0) will send the same option back to the sender, but not including the HMAC, HMAC and
        with E=1, to indicate receipt. The According to local policy, the lack of
        this echo type of "echo" can be used by indicate to the initial ADD_ADDR sender to
        retransmit that the
        ADD_ADDR according needs to local policy.</t>

        <?rfc needLines='11'?>
        <figure align="center" anchor="tcpm_address" title="Add Address (ADD_ADDR) Option">
          <artwork align="left"><![CDATA[
                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +---------------+---------------+-------+-------+---------------+
   |     Kind      |     Length    |Subtype|(rsv)|E|  Address ID   |
   +---------------+---------------+-------+-------+---------------+
   |          Address (IPv4 - 4 octets / IPv6 - 16 octets)         |
   +-------------------------------+-------------------------------+
   |   Port (2 octets, optional)   |                               |
   +-------------------------------+                               |
   |                Truncated HMAC (8 octets, if E=0)              |
   |                               +-------------------------------+
   |                               |
   +-------------------------------+
            ]]></artwork>
        </figure> be retransmitted.</t>

          <t>Due to the proliferation of NATs, it is reasonably likely that
          one host may attempt to advertise private addresses <xref target="RFC1918"/>.
          target="RFC1918" format="default"/>. It is not desirable to prohibit this,
 this behavior, since there may be cases where both hosts have additional
          interfaces on the same private network, and a host MAY
          <bcp14>MAY</bcp14> advertise such addresses. The MP_JOIN handshake
          to create a new subflow (<xref target="sec_join"/>) target="sec_join" format="default"/>)
          provides mechanisms to minimize security risks. The MP_JOIN message
          contains a 32-bit token that uniquely identifies the connection to
          the receiving host. If the token is unknown, the host will return respond
          with a RST. In the unlikely event that the token is valid at the
          receiving host, subflow setup will continue, but the HMAC exchange
          must occur for authentication. This The HMAC exchange
 will fail, fail and will provide
          sufficient protection against two unconnected hosts accidentally
          setting up a new subflow upon the signal of a private address.
 Further security considerations around the issue of ADD_ADDR messages that accidentally misdirect, or maliciously direct, new MP_JOIN attempts are discussed in <xref target="sec_security"/>.</t> target="sec_security" format="default"/>.</t>
          <t>A host that receives an ADD_ADDR but finds that a connection set up to that IP address and port number is unsuccessful SHOULD NOT <bcp14>SHOULD NOT</bcp14> perform further connection attempts to this address/port address&wj;/port combination for this connection. A sender that wants to trigger a new incoming connection attempt on a previously advertised address/port address&wj;/port combination can therefore refresh ADD_ADDR information by sending the option again.</t>
          <t>A host can therefore send an ADD_ADDR message with an already assigned
          already-assigned Address ID, but the Address MUST address <bcp14>MUST</bcp14> be
          the same as the address previously assigned to this Address ID. A
          new ADD_ADDR may have the same, same port number or different, a different port number. If the port number is different, the receiving host SHOULD <bcp14>SHOULD</bcp14> try to set up a new subflow to this new address/port address&wj;/port combination.</t>
          <t>A host wishing to replace an existing Address ID MUST <bcp14>MUST</bcp14> first remove the existing one (<xref target="sec_remove_addr"/>).</t> target="sec_remove_addr" format="default"/>).</t>
          <t>During normal MPTCP operation, it is unlikely that there will be sufficient TCP option space for ADD_ADDR to be included along with those for data sequence numbering (<xref target="sec_dsn"/>). target="sec_dsn" format="default"/>). Therefore, it is expected that an MPTCP implementation will send the ADD_ADDR option on separate ACKs. As discussed earlier, however, an MPTCP implementation MUST NOT <bcp14>MUST NOT</bcp14> treat duplicate ACKs with any MPTCP option, with the exception of the DSS option, as indications of congestion <xref target="RFC5681"/>, target="RFC5681" format="default"/>, and an MPTCP implementation SHOULD NOT <bcp14>SHOULD NOT</bcp14> send more than two duplicate ACKs in a row for signaling purposes.</t>
        </section>
        <section title="Remove Address" anchor="sec_remove_addr"> anchor="sec_remove_addr" numbered="true" toc="default">
          <name>Remove Address</name>
          <t>If, during the lifetime of an MPTCP connection, a previously
          announced address becomes invalid (e.g., if the interface disappears,
          disappears or an IPv6 address is no longer preferred), the affected
          host SHOULD <bcp14>SHOULD</bcp14> announce this situation so that the peer can remove
          subflows related to this address. Even if an address is not in use
          by a an MPTCP connection, if it has been previously announced, an
          implementation SHOULD <bcp14>SHOULD</bcp14> announce its removal. A host MAY
          <bcp14>MAY</bcp14> also choose to announce that a valid IP address
          should not be used any longer, longer -- for example example, for make-before-break make&#8209;before-break session continuity.</t>
          <t>This is achieved through the Remove Address (REMOVE_ADDR) option
          (<xref target="tcpm_remove"/>), target="tcpm_remove" format="default"/>), which will remove a
          previously added address (or list of addresses) from a connection
          and terminate any subflows currently using that address.</t>

          <figure anchor="tcpm_remove">
            <name>Remove Address (REMOVE_ADDR) Option</name>
            <artwork align="left" name="" type="" alt=""><![CDATA[
                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+-------+-------+---------------+
|     Kind      |Length = 3 + n |Subtype|(resvd)|   Address ID  | ...
+---------------+---------------+-------+-------+---------------+
                           (followed by n-1 Address IDs, if required) ]]></artwork>
          </figure>

          <t>For security purposes, if a host receives a REMOVE_ADDR option,
          it must ensure that the affected path(s) path or paths are no longer in use
          before it instigates closure. The receipt of REMOVE_ADDR SHOULD
          <bcp14>SHOULD</bcp14> first trigger the sending of a TCP keepalive
          <xref target="RFC1122"/> target="RFC1122" format="default"/> on the path, and if a
          response is received received, the path SHOULD NOT <bcp14>SHOULD NOT</bcp14> be
          removed. If the path is found to still be alive, the receiving host SHOULD
          <bcp14>SHOULD</bcp14> no longer use the specified address for future
          connections, but it is the responsibility of the host which that sent the
          REMOVE_ADDR to shut down the subflow. The Before the address is removed,
          the requesting host MAY
          <bcp14>MAY</bcp14> also use MP_PRIO (<xref target="sec_policy"/>) target="sec_policy"
          format="default"/>) to request that a path is no longer used, before removal. be used. Typical TCP validity tests on the subflow (e.g., ensuring
          that sequence and ACK numbers are correct) MUST <bcp14>MUST</bcp14> also be undertaken. An implementation can use indications of these test failures as part of intrusion detection or error logging.</t>
          <t>The sending and receipt (if no keepalive response was received)
          of this message SHOULD <bcp14>SHOULD</bcp14> trigger the sending of RSTs by
          both hosts on the affected subflow(s) (if possible), as a courtesy courtesy,
          to cleaning up allow the cleanup of middlebox state, state before cleaning up any local state.</t>
          <t>Address removal is undertaken by according to the Address ID, so as to
 permit the use of NATs and other middleboxes that rewrite source
 addresses.  If there an Address ID is no address at the requested ID, not known, the receiver will
 silently ignore the request.</t>
          <t>A subflow that is still functioning MUST <bcp14>MUST</bcp14> be closed with a FIN exchange as in regular TCP, rather than using this option. For more information, see <xref target="sec_close"/>.</t>
        <?rfc needLines='8'?>
        <figure align="center" anchor="tcpm_remove" title="Remove Address (REMOVE_ADDR) Option">
          <artwork align="left"><![CDATA[
                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +---------------+---------------+-------+-------+---------------+
   |     Kind      |  Length = 3+n |Subtype|(resvd)|   Address ID  | ...
   +---------------+---------------+-------+-------+---------------+
                              (followed by n-1 Address IDs, if required)
            ]]></artwork>
        </figure> target="sec_close" format="default"/>.</t>
        </section>
      </section>
      <section title="Fast Close" anchor="sec_fastclose"> anchor="sec_fastclose" numbered="true" toc="default">
        <name>Fast Close</name>
        <t>Regular TCP has the means of sending a reset (RST) RST signal to abruptly
        close a connection. With MPTCP, a regular RST only has the scope of
        the subflow
        and subflow; it
        will only close the concerned applicable subflow but and will not affect the remaining
        subflows. MPTCP's connection will stay alive at the data level, in order
        to permit break-before-make handover between subflows. It is therefore
        necessary to provide an MPTCP-level "reset" to allow the abrupt closure
        of the whole MPTCP connection, and connection; this is done via the MP_FASTCLOSE option.</t>
        <t>MP_FASTCLOSE is used to indicate to the peer that the connection will be
        abruptly closed and no data will be accepted anymore. The reasons for
        triggering an MP_FASTCLOSE are implementation specific. Regular TCP does
        not allow the sending of a RST while the connection is in a synchronized
        state <xref target="RFC0793"/>. target="RFC0793" format="default"/>. Nevertheless, implementations allow
        the sending of a RST in this state, state if, for example, the operating
        system is running out of resources. In these cases, MPTCP should send
        the MP_FASTCLOSE. This option is illustrated in <xref target="tcpm_fastclose"/>.</t>

        <?rfc needLines='12'?> target="tcpm_fastclose" format="default"/>.</t>
        <figure align="center" anchor="tcpm_fastclose" title="Fast anchor="tcpm_fastclose">
          <name>Fast Close (MP_FASTCLOSE) Option"> Option</name>
          <artwork align="left"><![CDATA[ align="left" name="" type="" alt=""><![CDATA[
                       1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +---------------+---------------+-------+-----------------------+
  |     Kind      |    Length     |Subtype|      (reserved)       |
  +---------------+---------------+-------+-----------------------+
  |                      Option Receiver's Key                    |
  |                            (64 bits)                          |
  |                                                               |
  +---------------------------------------------------------------+ ]]></artwork>
        </figure>
        <t>If Host A wants to force the closure of an MPTCP connection, it has can
        do so via two
	different
        options:
	  <list style="symbols">
	    <t>Option
        </t>
        <ul spacing="normal">
          <li>Option A (ACK) : (ACK): Host A sends an ACK containing the MP_FASTCLOSE
            option on one subflow, containing the key of Host B as declared in
            the initial connection handshake.  On all the other subflows, Host A Host&nbsp;A
            sends a regular TCP RST to close these subflows, subflows and tears them down.
            Host A now enters FASTCLOSE_WAIT state.</t>

            <t>Option state.</li>
          <li>Option R (RST) : (RST): Host A sends a RST containing the MP_FASTCLOSE
            option on all subflows, containing the key of Host B as declared in
            the initial connection handshake.  Host A can tear down the subflows and
            the connection down immediately.</t>
	  </list>
	</t> immediately.</li>
        </ul>
        <t>If host Host A decides to force the closure by using Option A and sending
        an ACK with the MP_FASTCLOSE option, the connection shall proceed as follows:
          <list style="symbols">
            <t>Upon
        </t>
        <ul spacing="normal">
          <li>Upon receipt of an ACK with MP_FASTCLOSE by Host B, containing the valid key, Host B answers
            on the same subflow with a TCP RST and tears down all subflows
            also through sending TCP RST signals. Host B can
            now close the whole MPTCP connection (it transitions directly to CLOSED state).</t>

            <t>As state).</li>
          <li>As soon as Host A has received the TCP RST on the remaining subflow, it
            can close this subflow and tear down the whole connection (transition from
            FASTCLOSE_WAIT state to CLOSED states). state). If Host A receives an MP_FASTCLOSE instead
            of a TCP RST, both hosts attempted fast closure simultaneously. Host A should
            reply with a TCP RST and tear down the connection.</t>

            <t>If connection.</li>
          <li>If Host A does not receive a TCP RST in reply to its MP_FASTCLOSE after one
            retransmission timeout (RTO) (the RTO of the subflow where the MP_FASTCLOSE has been sent), it SHOULD <bcp14>SHOULD</bcp14>
            retransmit the MP_FASTCLOSE. The number of retransmissions SHOULD be
            limited to avoid To keep this connection from being
            retained for a long time, but the number of retransmissions <bcp14>SHOULD</bcp14> be
            limited;
            this limit is implementation specific. A RECOMMENDED <bcp14>RECOMMENDED</bcp14> number is 3. If no TCP RST
            is received in response, Host A SHOULD <bcp14>SHOULD</bcp14> send a TCP RST with the MP_FASTCLOSE option
            itself when it releases state in order to clear any remaining state at middleboxes.</t>
          </list>
        </t>

	<t>If however host middleboxes.</li>
        </ul>
        <t>If, however, Host A decides to force the closure by using Option R and
        sending a RST with the MP_FASTCLOSE option, Host B will act as follows:
	Upon
        upon receipt of a RST with MP_FASTCLOSE, containing the valid key,
        Host B tears down all subflows by sending a TCP RST. Host B Host&nbsp;B can now close the whole MPTCP
        connection (it transitions directly to CLOSED state).</t>
      </section>
      <section title="Subflow Reset" anchor="sec_reset"> anchor="sec_reset" numbered="true" toc="default">
        <name>Subflow Reset</name>
        <t>An implementation of MPTCP may also need to send a regular TCP RST to force
        the closure of a subflow. A host sends a TCP RST in order to close a subflow
        or reject an attempt to open a subflow (MP_JOIN). In order to inform let the
        receiving host know why a subflow is being closed or rejected, the TCP RST packet
	MAY
        <bcp14>MAY</bcp14> include the MP_TCPRST Option. option (<xref target="tcpm_reset"/>). The host MAY <bcp14>MAY</bcp14> use this information to
        decide, for example, whether it tries to re-establish the subflow
        immediately, later, or never.</t>

        <?rfc needLines='8'?>
        <figure align="center" anchor="tcpm_reset" title="TCP anchor="tcpm_reset">
          <name>TCP RST Reason (MP_TCPRST) Option"> Option</name>
          <artwork align="left"><![CDATA[ align="left" name="" type="" alt=""><![CDATA[
                       1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +---------------+---------------+-------+-----------------------+
  |     Kind      |    Length     |Subtype|U|V|W|T|    Reason     |
  +---------------+---------------+-------+-----------------------+ ]]></artwork>
        </figure>
        <t>The MP_TCPRST option contains a reason code that allows the
        sender of the option to provide more information about the reason for
        the termination of the subflow.  Using 12 bits of option space, the
        first four bits 4&nbsp;bits are reserved for flags (only one of which is currently
        defined), and the remaining octet is used to express a reason code for
        this subflow termination, from which a receiver MAY <bcp14>MAY</bcp14> infer information
        about the usability of this path.</t>
        <t>The "T" flag is used by the sender to indicate whether the error
        condition that is reported is Transient (T ("T" bit set to 1) or Permanent
        (T
        ("T" bit set to 0).  If the error condition is considered to be
        Transient by the sender of the RST segment, the recipient of this
        segment MAY <bcp14>MAY</bcp14> try to reestablish re-establish a subflow for this connection over the
        failed path.  The time at which a receiver may try to re-establish
 re&#8209;establish this subflow
        is implementation-specific, implementation specific but SHOULD <bcp14>SHOULD</bcp14> take into account the properties
        of the failure as defined by the following provided reason code.  If the error condition
        is considered to be permanent, Permanent, the receiver of the RST segment SHOULD NOT <bcp14>SHOULD NOT</bcp14> try
        to reestablish re&#8209;establish a subflow for this connection over this path.  The "U", "V" "V",
        and "W" flags are not defined by this specification and are reserved for
        future use. An implementation of this specification MUST <bcp14>MUST</bcp14> set these flags
        to 0, and a receiver MUST <bcp14>MUST</bcp14> ignore them.</t>

        <t>The "Reason" code
        <t>"Reason" is an 8-bit field that indicates the reason code for
        the termination of the subflow.  The following codes are defined in
        this document:

          <list style="symbols">
            <t>Unspecified

        </t>
        <ul spacing="normal">
          <li>Unspecified error (code 0x0). 0x00).  This is the default error implying error;
 it implies that the
            subflow is no longer available.  The presence of this option shows
            that the RST was generated by a an MPTCP-aware device.</t>

            <t>MPTCP specific device.</li>
          <li>MPTCP-specific error (code 0x01).  An error has been detected in the
            processing of MPTCP options.  This is the usual reason code to return
            in the cases where a RST is being sent to close a subflow for reasons because
            of an invalid response.</t>

            <t>Lack response.</li>
          <li>Lack of resources (code 0x02).  This code indicates that the
            sending host does not have enough resources to support the
            terminated subflow.</t>

            <t>Administratively subflow.</li>
          <li>Administratively prohibited (code 0x03).  This code indicates that
            the requested subflow is prohibited by the policies of the sending
            host.</t>

            <t>Too
            host.</li>
          <li>Too much outstanding data (code 0x04).  This code indicates that
            there is an excessive amount of data that need needs to be transmitted
            over the terminated subflow while having already been acknowledged
            over one or more other subflows. This may occur if a path has been
            unavailable for a short period and it is more efficient to reset and
            start again than it is to retransmit the queued data.</t>

            <t>Unacceptable data.</li>
          <li>Unacceptable performance (code 0x05).  This code indicates that
            the performance of this subflow was too low compared to the other
            subflows of this Multipath TCP connection.</t>

            <t>Middlebox connection.</li>
          <li>Middlebox interference (code 0x06).  Middlebox interference has
            been detected over this subflow subflow, making MPTCP signaling invalid.  For
            example, this may be sent if the checksum does not validate.</t>
          </list>
        </t> validate.</li>
        </ul>
      </section>
      <section title="Fallback" anchor="sec_fallback"> anchor="sec_fallback" numbered="true" toc="default">
        <name>Fallback</name>
        <t>Sometimes, middleboxes will exist on a path that could prevent the
        operation of MPTCP. MPTCP has been designed in order to cope with many
        middlebox modifications (see <xref target="sec_middleboxes"/>), target="sec_middleboxes"
        format="default"/>), but there are still some cases where a subflow
        could fail to operate within the MPTCP requirements. These Notably, these cases are notably the following: the loss of MPTCP options on a path, path and the modification of payload data. If such an event occurs, it is necessary to "fall back" to the previous, safe operation. This may be either falling back to regular TCP or removing a problematic subflow.</t>
        <t>At the start of an MPTCP connection (i.e., the first subflow), it is important to ensure that the path is fully MPTCP capable and the necessary MPTCP options can reach each host. The handshake as described in <xref target="sec_init"/> SHOULD target="sec_init" format="default"/> <bcp14>SHOULD</bcp14> fall back to regular TCP if either of the SYN messages do does not have the MPTCP options: this is the same, and desired, behavior in the case where a host is not MPTCP capable, capable or the path does not support the MPTCP options. When attempting to join an existing MPTCP connection (<xref target="sec_join"/>), target="sec_join" format="default"/>), if a path is not MPTCP capable and the MPTCP options do not get through on the SYNs, the subflow will be closed according to the MP_JOIN logic.</t>
        <t>There is, however, another corner case that should be addressed. That is one of be addressed:
        the case where MPTCP options getting get through on the SYN, SYN but not on regular
        packets. This can be resolved if If the subflow is the first subflow, subflow and thus all data in
        flight is contiguous, this situation can be resolved by using the following rules.</t>

        <t>A rules:</t>
<ul spacing="normal">
<li>A sender MUST <bcp14>MUST</bcp14> include a DSS option with data sequence mapping Data Sequence Mapping in every segment until one of the sent segments has been acknowledged with a DSS option containing a Data ACK. Upon reception of the acknowledgment, the sender has the confirmation that the DSS option passes in both directions and may choose to send fewer DSS options than once per segment.</t>

        <t>If, segment.</li>
        <li>If, however, an ACK is received for data (not just for the SYN)
        without a DSS option containing a Data ACK, the sender determines that the path is not MPTCP capable. In the case of this occurring on an additional subflow (i.e., one started with MP_JOIN), the host MUST <bcp14>MUST</bcp14> close the subflow with a RST, which SHOULD <bcp14>SHOULD</bcp14> contain a an MP_TCPRST option (<xref target="sec_reset"/>) target="sec_reset" format="default"/>) with a "Middlebox interference" reason code.</t>

        <t>In code.</li>
        <li>In the case of such an ACK being received on the first subflow
        (i.e., that started with MP_CAPABLE), before any additional subflows
        are added, the implementation MUST <bcp14>MUST</bcp14> drop out of an MPTCP mode,
        mode and fall back to regular TCP. The sender will send one final data sequence mapping, Data Sequence Mapping, with the Data-Level Length value of 0 indicating an infinite mapping (to inform the other end in case the path drops options in one direction only), and then revert to sending data on the single subflow without any MPTCP options.</t>

        <t>If options.</li>
        <li>If a subflow breaks during operation, e.g. e.g., if it is re-routed rerouted and
        MPTCP options are no longer permitted, then once this is detected (by
        the subflow-level receive buffer filling up, since there is no mapping
        available in order to DATA_ACK this data), the subflow SHOULD
        <bcp14>SHOULD</bcp14> be treated as broken and closed with a RST,
        since no data can be delivered to the application layer, layer and no
        fallback signal can be reliably sent. This RST SHOULD <bcp14>SHOULD</bcp14>
        include the MP_TCPRST option (<xref target="sec_reset"/>) target="sec_reset"
        format="default"/>) with a "Middlebox interference" reason code.</t> code.</li>
</ul>
        <t>These rules should cover all cases where such a failure could happen:
        happen -- whether it's on the forward or reverse path and whether the server or the client first sends data.</t>
        <t>So far far, this section has discussed the loss of MPTCP options,
        either initially, initially or during the course of the connection. As described
        in <xref target="sec_generalop"/>, target="sec_generalop" format="default"/>, each portion of
        data for which there is a mapping is protected by a checksum, if
        checksums have been negotiated. This mechanism is used to detect if
        middleboxes have made any adjustments to the payload (added, removed,
        or changed data). A checksum will fail if the data has been changed in
        any way. This The use of a checksum will also detect if whether the length of data on the subflow is
        increased or decreased, and this means the data sequence mapping Data Sequence Mapping is no
        longer valid. The sender no longer knows what subflow-level sequence
        number the receiver is genuinely operating at (the middlebox will be
        faking ACKs in return), and it cannot signal any further
        mappings. Furthermore, in addition to the possibility of payload
        modifications that are valid at the application layer, there it is the possibility possible that such modifications could be triggered across MPTCP segment boundaries, corrupting the data. Therefore, all data from the start of the segment that failed the checksum onwards onward is not trustworthy.</t>
        <t>Note that if checksum usage has not been negotiated, this fallback mechanism cannot be used unless there is some higher higher-layer or lower layer lower&#8209;layer signal to inform the MPTCP implementation that the payload has been tampered with.</t>
        <t>When multiple subflows are in use, the data in flight on a subflow
        will likely involve data that is not contiguously part of the
        connection-level stream, since segments will be spread across the
        multiple subflows. Due to the problems identified above, it is not
        possible to determine what adjustment has adjustments have been done to the data (notably,
        any changes to the subflow sequence numbering). Therefore, it is not
        possible to recover the subflow, and the affected subflow must be
        immediately closed with a RST, featuring RST that includes an MP_FAIL option (<xref target="tcpm_fallback"/>), target="tcpm_fallback" format="default"/>), which defines the data sequence number at the start of the segment (defined by the data sequence mapping) Data Sequence Mapping) that had the checksum failure. Note that the MP_FAIL option requires the use of the full 64-bit sequence number, even if 32-bit sequence numbers are normally in use in the DSS signals on the path.</t>

        <?rfc needLines='8'?>
        <figure align="center" anchor="tcpm_fallback" title="Fallback anchor="tcpm_fallback">
          <name>Fallback (MP_FAIL) Option"> Option</name>
          <artwork align="left"><![CDATA[ align="left" name="" type="" alt=""><![CDATA[
                       1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +---------------+---------------+-------+----------------------+
  |     Kind      |   Length=12   |Subtype|      (reserved)      |
  +---------------+---------------+-------+----------------------+
  |                                                              |
  |                 Data Sequence Number (8 octets)              |
  |                                                              |
  +--------------------------------------------------------------+ ]]></artwork>
        </figure>
        <t>The receiver of this option MUST <bcp14>MUST</bcp14> discard all data following the data sequence number specified.
        Failed data MUST NOT <bcp14>MUST NOT</bcp14> be DATA_ACKed and so will be retransmitted on other subflows (<xref target="sec_retransmit"/>). target="sec_retransmit" format="default"/>). </t>
        <t>A special case is when there is a single subflow and it fails with a checksum error. If it is known that all unacknowledged data in
 flight is contiguous (which will usually be the case with a single
 subflow), an infinite mapping can be applied to the subflow without
 the need to close it first, and essentially turn turning off all further
 MPTCP signaling.

 In this case, if a receiver identifies a checksum failure
when there is only one path, it will send back an MP_FAIL option on the subflow-level ACK, referring to the data-level sequence number of the start of the
segment on which the checksum error was detected. The sender will receive
this, and
this information and, if all unacknowledged data in flight is contiguous, will signal an infinite mapping.
This infinite mapping will be a DSS option (<xref target="sec_generalop"/>) target="sec_generalop" format="default"/>)
on the first new packet, containing a data sequence mapping Data Sequence Mapping that acts retroactively, referring to the start of the subflow sequence
number of the most recent segment that was known to be delivered intact (i.e. (i.e., was successfully DATA_ACKed). From that point onwards, onward, data can be altered
by a middlebox without affecting MPTCP, as the data stream is equivalent to a regular, legacy TCP session.
Whilst
While in theory paths may only be damaged in one direction, direction -- and the MP_FAIL
signal affects only one direction of traffic, traffic --
for implementation simplicity, simplicity of implementation, the receiver of an MP_FAIL MUST <bcp14>MUST</bcp14> also respond with an MP_FAIL in the reverse direction and entirely revert to a regular TCP session.</t>
        <t>In the rare case that the data is not contiguous (which could happen when there is only one subflow but it is retransmitting data from a subflow
that has recently been uncleanly closed), the receiver MUST <bcp14>MUST</bcp14> close the subflow with a RST with MP_FAIL. The receiver MUST <bcp14>MUST</bcp14> discard all data that follows the
data sequence number specified. The sender MAY <bcp14>MAY</bcp14> attempt to
create a new subflow belonging to the same connection, connection and, if it chooses to do
so, SHOULD <bcp14>SHOULD</bcp14> immediately place
the single subflow immediately in single-path mode by setting an infinite data sequence mapping. Data Sequence Mapping. This mapping will begin from the data-level sequence number
that was declared in the MP_FAIL.</t>
        <t>After a sender signals an infinite mapping, it MUST <bcp14>MUST</bcp14> only use subflow ACKs to clear its send buffer.
This is because Data ACKs may become misaligned with the subflow ACKs when middleboxes insert or delete data.
The receive SHOULD receiver <bcp14>SHOULD</bcp14> stop generating Data ACKs after it receives
an infinite mapping. </t> mapping.</t>
        <t>When a connection has fallen back with an infinite mapping, only one subflow can send data; otherwise, the receiver would not know how to reorder the data. In practice, this means that all MPTCP subflows will have to be terminated except one. Once MPTCP falls back to regular TCP, it MUST NOT <bcp14>MUST NOT</bcp14> revert to MPTCP later in the connection.</t>
        <t>It should be emphasized that MPTCP is not attempting to prevent the use of middleboxes that want to adjust the payload. An MPTCP-aware middlebox could provide such functionality by also rewriting checksums.</t>
      </section>
      <section title="Error Handling" anchor="sec_errors"> anchor="sec_errors" numbered="true" toc="default">
        <name>Error Handling</name>
        <t>In addition to the fallback mechanism as described above, the standard classes of TCP errors may need to be handled in an MPTCP-specific MPTCP&#8209;specific way. Note that changing semantics -- such as the relevance of a RST -- are covered in <xref target="sec_semantics"/>. target="sec_semantics" format="default"/>. Where possible, we do not want to deviate from regular TCP behavior.</t>
        <t>The following list covers possible errors and the appropriate MPTCP behavior:
          <list style="symbols">
            <t>Unknown
        </t>
        <ul spacing="normal">
          <li>Unknown token in MP_JOIN (or HMAC failure in MP_JOIN ACK, or missing MP_JOIN in SYN/ACK response): send RST (analogous to TCP's behavior on an unknown port)</t>
            <t>DSN port)</li>
          <li>DSN out of window (during normal operation): drop the data, data; do not send Data ACKs</t>
            <t>Remove ACKs</li>
          <li>Remove request for unknown address Address ID: silently ignore</t>
          </list>
        </t> ignore</li>
        </ul>
      </section>
      <section title="Heuristics" anchor="heuristics"> anchor="heuristics" numbered="true" toc="default">
        <name>Heuristics</name>
        <t>There are a number of heuristics that are needed for
        performance or deployment but that are not required for
        protocol correctness.  In this section, we detail such
        heuristics. Note that discussion discussions of buffering and certain
        sender and receiver window behaviors are presented in Sections
        <xref target="sec_rwin" format="counter"/> and <xref
        target="sec_sender" format="counter"/>,
        as well as
        and retransmission is discussed in <xref target="sec_retransmit"/>.</t> target="sec_retransmit" format="default"/>.</t>
        <section title="Port Usage"> numbered="true" toc="default">
          <name>Port Usage</name>
          <t>Under typical operation, an MPTCP implementation SHOULD <bcp14>SHOULD</bcp14> use
          the same ports as the ports that are already in use. In other words, the
          destination port of a SYN containing an MP_JOIN option SHOULD <bcp14>SHOULD</bcp14>
          be the same as the remote port of the first subflow in the
          connection.  The local port for such SYNs SHOULD <bcp14>SHOULD</bcp14> also be the
          same as the port for the first subflow (and as such, an
          implementation SHOULD <bcp14>SHOULD</bcp14> reserve ephemeral ports across all
          local IP addresses), although there may be cases where this
          is infeasible.  This strategy is intended to maximize the
          probability of the SYN being permitted by a firewall or NAT
          at the recipient and to avoid confusing any network
          monitoring network-monitoring software.</t>
          <t>There may also be cases, however, where a host wishes to
          signal that a specific port should be used, and used; this facility
          is provided in the ADD_ADDR option as documented in
          <xref target="sec_add_address"/>. target="sec_add_address" format="default"/>.  It is therefore feasible
          to allow multiple subflows between the same two addresses
          but using different port pairs, and
          such a facility could be used to allow load balancing within
          the network based on 5-tuples (e.g., some ECMP implementations <xref target="RFC2992"/>).</t> target="RFC2992" format="default"/>).</t>
        </section>
        <section title="Delayed numbered="true" toc="default">
          <name>Delayed Subflow Start and Subflow Symmetry"> Symmetry</name>
          <t>Many TCP connections are short-lived and consist only of a few
          segments, and so the overheads overhead
          of using MPTCP outweigh outweighs any benefits. A heuristic is required,
          therefore, to decide when to start using additional subflows in
          an MPTCP connection. Experimental deployments have shown that
          MPTCP can be applied in a range of scenarios scenarios, so an implementation
          is
          will likely to need to take into account such factors including as the type of
          traffic being sent and the duration of session, and the session; this information
          MAY
          <bcp14>MAY</bcp14> be signalled signaled by the application layer.</t>
          <t>However, for standard TCP traffic, a suggested general-purpose
          heuristic that an implementation MAY <bcp14>MAY</bcp14> choose to employ is as follows.</t>
          <t>If a host has data buffered for its peer (which implies that the
          application has received a request for data), the host opens one
          subflow for each initial window's worth of data that is buffered.</t>
          <t>Consideration should also be given to limiting the rate of adding
          new subflows, as well as limiting the total number of subflows open
          for a particular connection.  A host may choose to vary these values
          based on its load or knowledge of traffic and path characteristics.</t>
          <t>Note that this heuristic alone is probably insufficient. Traffic
          for many common applications, such as downloads, is highly asymmetric asymmetric, and
          the host that is multihomed may well be the client that will never fill
          its buffers, buffers and thus never use MPTCP according to this heuristic. Advanced APIs that allow an
          application to signal its traffic requirements would aid in these decisions.</t>
          <t>An additional time-based heuristic could be applied, opening additional
          subflows after a given period of time has passed. This would alleviate the
          above issue, issue and also provide resilience for low-bandwidth low&#8209;bandwidth but long-lived
          applications.</t>
          <t>Another issue is that both communicating hosts may simultaneously try to
          set up a subflow between the same pair of addresses. This leads to an
          inefficient use of resources.</t>
          <t>If the same ports are used on all subflows, as recommended above,
          then standard TCP simultaneous open simultaneous-open logic should take care of this situation
          and only one subflow will be established between the address pairs. However,
          this relies on the same ports being used at both end hosts. If a host does
          not support TCP simultaneous open, it is RECOMMENDED <bcp14>RECOMMENDED</bcp14> that some element
          of randomization is be applied to the time to wait before opening new subflows,
          so that only one subflow is created between a given address pair. If, however,
          hosts signal additional ports to use (for example, for leveraging ECMP on-path),
          this heuristic is not appropriate.</t>
          <t>This section has shown some of the considerations factors that an implementer
          should give consider when developing MPTCP heuristics, but it is not intended to be
          prescriptive.</t>
        </section>
        <section title="Failure Handling"> numbered="true" toc="default">
          <name>Failure Handling</name>
          <t>Requirements for MPTCP's handling of unexpected signals have been are
          given in <xref target="sec_errors"/>. target="sec_errors" format="default"/>. There are other failure cases,
          however, where a hosts can choose appropriate behavior.</t>
          <t>For example, <xref target="sec_init"/> target="sec_init" format="default"/> suggests that a host SHOULD <bcp14>SHOULD</bcp14>
          fall back to trying regular TCP SYNs after one or more failures of MPTCP
          SYNs for a connection. A host may keep a system-wide cache of such
          information, so that it can back off from using MPTCP, firstly for that
          particular destination host, and eventually host and, eventually, on a whole interface, if
          MPTCP connections continue failing. to fail. The duration of such a cache would
          be implementation-specific.</t> implementation specific.</t>
          <t>Another failure could occur when the MP_JOIN handshake fails.
          <xref target="sec_errors"/> target="sec_errors" format="default"/> specifies that an incorrect handshake MUST <bcp14>MUST</bcp14>
          lead to the subflow being closed with a RST. A host operating an active
          intrusion detection
          intrusion-detection system may choose to start blocking MP_JOIN packets
          from the source host if multiple failed MP_JOIN attempts are seen. From
          the connection initiator's point of view, if an MP_JOIN fails, it SHOULD
          NOT
          <bcp14>SHOULD NOT</bcp14>
          attempt to connect to the same IP address and port during the lifetime
          of the connection, unless the other host refreshes the information with
          another ADD_ADDR option. Note that the ADD_ADDR option is informational
          only,
          only and does not guarantee that the other host will attempt a connection.</t>
          <t>In addition, an implementation may learn, over a number of connections,
          that certain interfaces or destination addresses consistently fail and
          may default to not trying to use MPTCP for these.  Behavior could also
          be learned for such interfaces or
          addresses.  The behavior of subflows that perform particularly badly performing subflows
          or subflows that regularly fail during use, in order to use could also
          be learned, so that an implementation can temporarily choose not to use
          these paths.</t>
        </section>
      </section>
    </section>
    <section title="Semantic Issues" anchor="sec_semantics"> anchor="sec_semantics" numbered="true" toc="default">
      <name>Semantic Issues</name>
      <t>In order to support multipath operation, the semantics of some TCP
      components have changed. To aid clarity, help clarify, this section collects lists these
      semantic changes as a point of reference.
        <list style="hanging">
          <t hangText="Sequence number:">
      </t>
      <dl newline="false" spacing="normal" indent="3">
        <dt>Sequence number:</dt>
        <dd> The (in-header) TCP sequence
            number is specific to the subflow. To allow the receiver to
            reorder application data, an additional data-level
            sequence space is used. In this data-level data&#8209;level sequence space, the initial SYN and
            the final DATA_FIN occupy 1 octet of sequence space. This is done to
            ensure that these
            signals are acknowledged at the connection level. There is an explicit
            mapping of data sequence space to subflow sequence space,
            which is signaled through TCP options in data
            packets.</t>

          <t hangText="ACK:">
            packets.</dd>
        <dt>ACK:</dt>
        <dd> The ACK field in the TCP header
            acknowledges only the subflow sequence number, number -- not the
            data-level sequence space. Implementations SHOULD NOT <bcp14>SHOULD NOT</bcp14>
            attempt to infer a data-level acknowledgment from the
            subflow ACKs.
            This separates subflow- subflow-level and connection-level processing
            at an end host.</t>

          <t hangText="Duplicate ACK:"> host.</dd>
        <dt>Duplicate ACK:</dt>
        <dd> A duplicate ACK that includes any MPTCP signaling
            (with the exception of the DSS option) MUST NOT <bcp14>MUST NOT</bcp14> be treated as a signal of congestion.
            To limit the chances of non-MPTCP-aware entities mistakenly interpreting duplicate
            ACKs as a signal of congestion, MPTCP SHOULD NOT <bcp14>SHOULD NOT</bcp14> send more than two duplicate ACKs
            containing (non-DSS) MPTCP signals in a row.</t>

          <t hangText="Receive Window:">The row.</dd>
        <dt>Receive Window:</dt>
        <dd>The receive window in the TCP
            header indicates the amount of free buffer space for the
            whole data-level connection (as opposed to the amount of space for this
            subflow) that is available at the receiver.  This is  The
            semantics are the same semantics as for regular TCP, but to maintain these
            semantics the receive window must be interpreted at the
            sender as relative to the sequence number given in the
            DATA_ACK rather than the subflow ACK in the TCP header.
            In this way, the original role of flow control role is preserved.
            Note that some middleboxes may change the receive window,
            and so a host SHOULD <bcp14>SHOULD</bcp14> use the maximum value of those recently
            seen on the constituent subflows for the connection-level
            receive window, window and also needs to maintain a subflow-level
            window for subflow-level processing.</t>

          <t hangText="FIN:"> processing.</dd>
        <dt>FIN:</dt>
        <dd> The FIN flag in the TCP header applies
            only to the subflow it is sent on, on -- not to the whole
            connection. For connection-level FIN semantics, the
            DATA_FIN option is used.</t>

          <t hangText="RST:"> used.</dd>
        <dt>RST:</dt>
        <dd> The RST flag in the TCP header applies
            only to the subflow it is sent on, on -- not to the whole
            connection. The MP_FASTCLOSE option provides the fast close Fast Close
            functionality of a RST at the MPTCP connection level.</t>

          <t hangText="Address List:"> level.</dd>
        <dt>Address List:</dt>
        <dd> Address list management (i.e.,
            knowledge of the local and remote hosts' lists of
            available IP addresses) is handled
            on a per-connection basis (as opposed to per subflow, per
            host, or per pair of communicating hosts).  This permits
            the application of per-connection local policy.  Adding an
            address to one connection (either explicitly through an Add
            Address message,
            ADD_ADDR message or implicitly through a Join) an MP_JOIN) has no implication implications
            for other connections between the same pair of hosts.</t>

          <t hangText="5-tuple:"> hosts.</dd>
        <dt>5-tuple:</dt>
        <dd> The 5-tuple (protocol, local
            address, local port, remote address, remote port)
            presented by kernel APIs to the application layer in a
            non-multipath-aware application is that of the first
            subflow, even if the subflow has since been closed and
            removed from the connection. This decision, and other
            related API issues, are discussed in more detail in
            <xref target="RFC6897"/>.</t>
        </list>
      </t> target="RFC6897" format="default"/>.</dd>
      </dl>
    </section>
    <section title="Security Considerations" anchor="sec_security"> anchor="sec_security" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>As identified in <xref target="RFC6181"/>, target="RFC6181" format="default"/>, the
      addition of multipath capability to TCP will bring with it a number of
      new classes of threat. threats. In order to prevent these, these threats, <xref target="RFC6182"/> target="RFC6182"
      format="default"/> presents a set of requirements for a security
      solution for MPTCP. The fundamental goal is for the security of MPTCP to
      be "no worse" than regular TCP today, and the today. The key security requirements are:
       <list style="symbols">
          <t>Provide
      are as follows:
      </t>
      <ul spacing="normal">
        <li>Provide a mechanism to confirm that the parties in a subflow
        handshake are the same as the parties in the original connection setup.</t>
          <t>Provide setup.</li>
        <li>Provide verification that the peer can receive traffic at a new address before using it as part of a connection.</t>
          <t>Provide connection.</li>
        <li>Provide replay protection, i.e., ensure that a request to add/remove add&wj;/remove a subflow is 'fresh'.</t>
        </list> "fresh".</li>
      </ul>
      <t>
        In order to achieve these goals, MPTCP includes a hash-based handshake algorithm
      algorithm, as documented in Sections <xref target="sec_init" format="counter"/> and <xref target="sec_join" format="counter"/>.</t>
      <t>The security of the MPTCP connection hangs on the use of keys that
      are shared once at the start of the first subflow, subflow and are never sent
      again over the network (unless used in the fast close mechanism, <xref target="sec_fastclose"/>). Fast Close mechanism (<xref
      target="sec_fastclose" format="default"/>)).  To ease demultiplexing
      while not giving away any cryptographic material, future subflows use a
      truncated cryptographic hash of this key as the connection
      identification "token".  The keys are concatenated and used as keys for
      creating Hash-based Message Authentication Codes (HMACs) used on subflow
      setup, in order to verify that the parties in the handshake are the same
      as the parties in the original connection setup.  It also provides verification that
      the peer can receive traffic at this new address.  Replay attacks would
      still be possible when only keys are used; therefore, the handshakes use
      single-use random numbers (nonces) at both ends -- this ensures that the HMAC will never be the same on two handshakes. Guidance on generating random numbers suitable for use as keys is given in <xref target="RFC4086"/> target="RFC4086" format="default"/> and discussed in <xref target="sec_init"/>. target="sec_init" format="default"/>. The nonces are valid for the lifetime of the TCP connection attempt. HMAC is also used to secure the ADD_ADDR option, due to the threats identified in <xref target="RFC7430"/>.</t> target="RFC7430" format="default"/>.</t>
      <t>The use of crypto capability bits in the initial connection handshake
      to negotiate the use of a particular algorithm allows the deployment of additional crypto mechanisms in the future.  This negotiation would nevertheless be susceptible to a bid-down attack by an on-path active attacker who could modify the crypto capability bits in the response from the receiver to use a less secure crypto mechanism. The security mechanism presented in this document should therefore protect against all forms of flooding and hijacking attacks discussed in <xref target="RFC6181"/>.</t> target="RFC6181" format="default"/>.</t>
      <t>The version negotiation specified in <xref target="sec_init"/>, target="sec_init"
      format="default"/>, if differing MPTCP versions shared a common
      negotiation format, would allow an on-path attacker to apply a
      theoretical bid-down attack. Since the v1 and v0 protocols have a
      different handshake, such an attack would require that the client to
      re-establish the connection using v0, v0 and this being supported by that the server. server support v0.
 Note that an on-path attacker would have access to the raw data, negating any other TCP-level security mechanisms.
      Also a change from RFC6824 has removed As also noted in <xref target="app_changelog"/>, this document specifies the subflow identifier from removal of the AddrID field <xref target="RFC6824"/> in the MP_PRIO option (<xref target="sec_policy"/>), to remove target="sec_policy" format="default"/>).
 This change eliminates the possibility of a theoretical attack where
 a subflow could be placed in "backup" mode by an attacker.</t>
      <t>During normal operation, regular TCP protection mechanisms (such as
      ensuring that sequence numbers are in-window) will provide the same
      level of protection against attacks on individual TCP subflows as the
      level of protection that exists for regular TCP today. Implementations will introduce additional buffers compared to regular TCP, to reassemble data at the connection level. The application of window sizing will minimize the risk of denial-of-service attacks consuming resources.</t>
      <t>As discussed in <xref target="sec_add_address"/>, target="sec_add_address" format="default"/>, a host may advertise its private addresses, but these might point to different hosts in the receiver's network. The MP_JOIN handshake (<xref target="sec_join"/>) target="sec_join" format="default"/>) will ensure that this does not succeed in setting up a subflow to the incorrect host. However, it could still create unwanted TCP handshake traffic. This feature of MPTCP could be a target for denial-of-service exploits, with malicious participants in MPTCP connections encouraging the recipient to target other hosts in the network. Therefore, implementations should consider heuristics (<xref target="heuristics"/>) target="heuristics" format="default"/>) at both the sender and receiver to reduce the impact of this.</t>
      <t>To further protect against malicious ADD_ADDR messages sent by an off-path attacker, the ADD_ADDR includes an HMAC using the keys negotiated during the handshake. This effectively prevents an attacker from diverting an MPTCP connection through an off-path ADD_ADDR injection into the stream.</t>
      <t>A small security risk could theoretically exist with key reuse, but in order to accomplish a replay attack, both the sender and receiver keys, and the sender and receiver random numbers, in the MP_JOIN handshake (<xref target="sec_join"/>) target="sec_join" format="default"/>) would have to match.</t>

      <t>Whilst
      <t>While this specification defines a "medium" security solution,
      meeting the criteria specified at the start of this section and in the
      threat analysis (<xref target="RFC6181"/>), document <xref target="RFC6181" format="default"/>, since attacks
      only ever get worse, it is likely that a future version of MPTCP would
      need to be able to support stronger security.
 There are several ways the security of MPTCP could potentially be improved; some of these would be compatible with MPTCP as defined in this document, whilst while others may not be. For now, the best approach is to get gain experience with the current approach, establish what might work, and check that the threat analysis is still accurate.</t>
      <t>Possible ways of improving MPTCP security could include:<list style="symbols">
<t>defining include:</t>
      <ul spacing="normal">
        <li>defining a new MPCTP MPTCP cryptographic algorithm, as negotiated in
        MP_CAPABLE. A sub-case could be to include If an implementation was being deployed in a controlled
        environment where additional deployment assumption, assumptions could be made, such as stateful servers, in order the
        ability for the servers to allow store state during the TCP handshake, then
        it may be possible to use a more powerful stronger cryptographic algorithm to than
        would otherwise be used.</t>
<t>defining possible.</li>
        <li>defining how to secure data transfer with MPTCP, whilst while not changing the signaling part of the protocol.</t>
<t>defining protocol.</li>
        <li>defining security that requires more option space, perhaps in
        conjunction with a "long options" proposal for extending the TCP options
        option space (such as those surveyed in <xref target="TCPLO"/>),
        target="I-D.ananth-tcpm-tcpoptext" format="default"/>), or perhaps
        building on the current approach with a second stage of MPTCP-option-based security.</t>
<t>revisiting
security based on MPTCP options.</li>
        <li>revisiting the working group's decision to exclusively use TCP
    options for MPTCP signaling, signaling and instead look looking at also making use of the
    possibility of using TCP payloads.</t>
</list></t> payloads as well.</li>
      </ul>
      <t>MPTCP has been designed with several methods available to indicate a new security mechanism, including:
<list style="symbols">
<t>available
</t>
      <ul spacing="normal">
        <li>available flags in MP_CAPABLE (<xref target="tcpm_capable"/>);</t>
<t>available target="tcpm_capable" format="default"/>).</li>
        <li>available subtypes in the MPTCP option (<xref target="fig_option"/>);</t>
<t>the version target="fig_option" format="default"/>).</li>
        <li>the Version field in MP_CAPABLE (<xref target="tcpm_capable"/>);</t>
</list></t> target="tcpm_capable" format="default"/>).</li>
      </ul>
    </section>
    <section title="Interactions anchor="sec_middleboxes" numbered="true" toc="default">
      <name>Interactions with Middleboxes" anchor="sec_middleboxes"> Middleboxes</name>
      <t>Multipath TCP was designed to be deployable in the present world. Its design takes into account "reasonable"
existing middlebox behavior. In this section, we outline a few representative middlebox-related failure scenarios and
show how Multipath TCP handles them. Next, we list the design decisions multipath
Multipath TCP has made to accommodate the different
middleboxes.</t>
      <t>A primary concern is our use of a new TCP option. Middleboxes should forward packets
with unknown options unchanged, yet there are some that don't. These we We expect will either these
middleboxes to strip options and pass the data,
drop packets with new options, copy the same option into multiple segments (e.g., when doing segmentation), or drop
options during segment coalescing.</t>
      <t>MPTCP uses a single new TCP option called "Kind", and all message types are defined by "subtype" values (see <xref target="IANA"/>). target="IANA" format="default"/>). This should reduce the chances of only some types of MPTCP options being passed, and instead passed; instead, the key differing characteristics are different paths, paths and the presence of the SYN flag.</t>
      <t>MPTCP SYN packets on the first subflow of a connection contain the MP_CAPABLE option (<xref target="sec_init"/>). target="sec_init" format="default"/>). If this is dropped, MPTCP SHOULD <bcp14>SHOULD</bcp14> fall back to regular TCP. If packets with the MP_JOIN option (<xref target="sec_join"/>) target="sec_join" format="default"/>) are dropped, the paths will simply not be used.</t>
      <t>If a middlebox strips options but otherwise passes the packets
      unchanged, MPTCP will behave safely. If an MP_CAPABLE option is dropped
      on either the outgoing path or the return path, the initiating host can
      fall back to regular TCP, as illustrated in <xref target="fig_syn"/> target="fig_syn"
      format="default"/> and discussed in <xref target="sec_init"/>.</t> target="sec_init"
      format="default"/>.</t>
      <figure anchor="fig_syn">
        <name>Connection Setup with Middleboxes That Strip Options from Packets</name>
        <artwork align="left" name="" type="" alt=""><![CDATA[
             Host A                              Host B
               |              Middlebox M            |
               |                   |                 |
               | SYN (MP_CAPABLE)  |        SYN      |
               |-------------------|---------------->|
               |                SYN/ACK              |
               |<------------------------------------|
           a) MP_CAPABLE option stripped on outgoing path

             Host A                                Host B
               |           SYN (MP_CAPABLE)            |
               |-------------------------------------->|
               |             Middlebox M               |
               |                  |                    |
               |    SYN/ACK       |SYN/ACK (MP_CAPABLE)|
               |<-----------------|--------------------|
           b) MP_CAPABLE option stripped on return path ]]></artwork>
      </figure>
      <t>Subflow SYNs contain the MP_JOIN option. If this option is stripped on the outgoing path,
the SYN will appear to be a regular SYN to Host B.&nbsp; Host&nbsp;B.  Depending on whether there is a listening socket on
the target port, Host B will reply either with either a SYN/ACK or a RST (subflow connection fails). When Host A
receives the SYN/ACK SYN/ACK, it sends a RST because the SYN/ACK does not contain the MP_JOIN option and its token.
Either way, the subflow setup fails, fails but otherwise does not affect the MPTCP connection as a whole.</t>

        <figure align="center" anchor="fig_syn" title="Connection Setup with Middleboxes that Strip Options from Packets">
          <artwork align="left"><![CDATA[
     Host A                             Host B
      |              Middlebox M            |
      |                   |                 |
      |  SYN(MP_CAPABLE)  |        SYN      |
      |-------------------|---------------->|
      |                SYN/ACK              |
      |<------------------------------------|
  a) MP_CAPABLE option stripped on outgoing path

    Host A                               Host B
      |            SYN(MP_CAPABLE)          |
      |------------------------------------>|
      |             Middlebox M             |
      |                 |                   |
      |    SYN/ACK      |SYN/ACK(MP_CAPABLE)|
      |<----------------|-------------------|
  b) MP_CAPABLE option stripped on return path
           ]]></artwork>
        </figure>
      <t>We now examine data flow with MPTCP, assuming that the flow is
      correctly set up, which implies that the options in the SYN
packets were allowed through by the relevant middleboxes. If options are allowed through and there is no resegmentation or
coalescing to TCP segments, Multipath TCP flows can proceed without problems.</t>
      <t>The case when options get stripped on data packets has been is discussed
      in the Fallback section. <xref target="sec_fallback" format="default"/>.
        If only some MPTCP options are stripped, behavior is not deterministic. If some data sequence mappings Data Sequence Mappings are lost, the connection can continue so long as mappings exist for the subflow-level data (e.g., if multiple maps have been sent that reinforce each other). If some subflow-level space is left unmapped, however, the subflow is treated as broken and is closed, through using the process described in <xref target="sec_fallback"/>. target="sec_fallback" format="default"/>. MPTCP should survive with a loss of some Data ACKs, but performance will degrade as the fraction of stripped options increases.
We do not expect such cases to appear in practice, though: most
middleboxes will either strip all options or let them all through.</t>
      <t>We end this section with a list of middlebox classes, their behavior, and the elements in the MPTCP design
that allow operation through such middleboxes. Issues surrounding dropping packets with options
or stripping options were discussed above, above and are not included here:

        <list style="symbols">
          <t>NATs <xref target="RFC3022"/>

      </t>
      <ul spacing="normal">
        <li>NATs (Network Address (and Port) port) Translators) <xref
        target="RFC3022" format="default"/> change the source address (and
        often the source port) of packets. This means that a host will not know its
    public-facing address for signaling in MPTCP. Therefore, MPTCP permits implicit address addition via the MP_JOIN option,
    and the handshake mechanism ensures that connection attempts to private addresses <xref target="RFC1918"/>, target="RFC1918" format="default"/>, since they are authenticated, will only set up subflows to the correct hosts.
    Explicit address removal is undertaken by an Address ID to allow no knowledge of the source address.</t>

          <t>Performance address.</li>
        <li>Performance Enhancing Proxies (PEPs) <xref target="RFC3135"/> target="RFC3135" format="default"/> might proactively ACK data to increase performance. MPTCP, however, relies on accurate congestion control signals from the end host, and non-MPTCP-aware non&#8209;MPTCP-aware PEPs will not be able to provide such signals. MPTCP will, therefore, fall back to single-path TCP, TCP or close the problematic subflow (see <xref target="sec_fallback"/>).</t>

          <t>Traffic Normalizers target="sec_fallback" format="default"/>).</li>
        <li>Traffic normalizers <xref target="norm"/> target="norm" format="default"/> may not
        allow holes in sequence numbers, and they may cache packets and retransmit the same data.
MPTCP looks like standard TCP on the wire, wire and will not retransmit different data on the same subflow sequence number. In the event of a retransmission, the same data will be retransmitted on the original TCP subflow even if it is additionally retransmitted at the connection level on a different subflow.</t>

          <t>Firewalls subflow.</li>
        <li>Firewalls <xref target="RFC2979"/> target="RFC2979" format="default"/> might perform initial sequence number
        Initial Sequence Number (ISN) randomization on TCP connections. MPTCP uses relative
sequence numbers in data sequence mapping Data Sequence Mappings to cope with this. Like NATs, firewalls will not permit many incoming connections, so
MPTCP supports address signaling (ADD_ADDR) so that a multiaddressed host can invite its peer behind the firewall/NAT to connect
out to its additional interface.</t>

          <t>Intrusion Detection/Prevention interface.</li>
        <li>Intrusion Detection Systems / Intrusion Prevention Systems (IDS/IPS) (IDSs&wj;/IPSs) observe packet streams for patterns and content that could threaten a network. MPTCP may require the
instrumentation of additional paths, and an MPTCP-aware IDS/IPS IDS or IPS would need to read MPTCP tokens to correlate data from mutliple multiple subflows to maintain comparable visibility into all of the traffic between devices. Without such changes, an IDS would get an incomplete view of the traffic, increasing the risk of missing traffic of interest (false negatives), negatives) and increasing the chances of erroneously identifying a subflow as a risk due to only seeing partial data (false positives).</t>

          <t>Application-level positives).</li>
        <li>Application-level middleboxes such as content-aware firewalls may
        alter the payload within a subflow, such as subflow -- for example, rewriting URIs in
        HTTP traffic. MPTCP will detect these such changes using the checksum
and close the affected subflow(s), if there are other subflows that can be used. If all subflows are affected, multipath MPTCP
will fall back to TCP, allowing such middleboxes to change the payload. MPTCP-aware middleboxes should be able to adjust the payload and MPTCP metadata in order not to break the connection.</t>
        </list> connection.</li>
      </ul>
      <t>

        In addition, all classes of middleboxes may affect TCP traffic in the following ways:
        <list style="symbols">
          <t>TCP
      </t>
      <ul spacing="normal">
        <li>TCP options may be removed, or packets with unknown options dropped, by many classes of middleboxes. It is intended
that the initial SYN exchange, with a TCP option, will be sufficient to identify the path path's capabilities. If such a packet does
not get through, MPTCP will end up falling back to regular TCP.</t>

          <t>Segmentation/Coalescing TCP.</li>
        <li>Segmentation/coalescing (e.g., TCP segmentation offloading) might copy options between packets and might
strip some options. MPTCP's data sequence mapping Data Sequence Mapping includes the relative subflow sequence number instead of using the sequence
number in the segment. In this way, the mapping is independent of the packets that carry it.</t>

          <t>The it.</li>
        <li>The receive window may be shrunk by some middleboxes at the
        subflow level. MPTCP will use the maximum window at the data level, level but will also obey
subflow-specific windows.</t>
        </list>
      </t>

    </section>

    <section anchor="Acknowledgments" title="Acknowledgments">
      <!-- <t>The authors were originally supported by Trilogy (http://www.trilogy-project.org), a research project (ICT-216372) partially funded by the European Community under its Seventh Framework Program.</t>
      <t>Alan Ford was originally supported by Roke Manor Research and later Cisco Systems.</t> -->
      <t>The authors gratefully acknowledge significant input into this document from S&eacute;bastien Barr&eacute; and Andrew McDonald.</t>
      <t>The authors also wish to acknowledge reviews and contributions from Iljitsch van Beijnum, Lars Eggert, Marcelo Bagnulo, Robert Hancock, Pasi Sarolahti, Toby Moncaster, Philip Eardley, Sergio Lembo, Lawrence Conroy, Yoshifumi Nishida, Bob Briscoe, Stein Gjessing, Andrew McGregor, Georg Hampel, Anumita Biswas, Wes Eddy, Alexey Melnikov, Francis Dupont, Adrian Farrel, Barry Leiba, Robert Sparks, Sean Turner, Stephen Farrell, Martin Stiemerling, Gregory Detal, Fabien Duchene, Xavier de Foy, Rahul Jadhav, Klemens Schragel, Mirja Kuehlewind, Sheng Jiang, Alissa Cooper, Ines Robles, Roman Danyliw, Adam Roach, Barry Leiba, Alexey Melnikov, Eric Vyncke, and Ben Kaduk.</t> windows.</li>
      </ul>
    </section>

    <section anchor="IANA" title="IANA Considerations"> numbered="true" toc="default">
      <name>IANA Considerations</name>

      <t>This document obsoletes RFC6824 and as such <xref target="RFC6824"/>. As such, IANA is requested has updated
      several registries to update point to this document. In addition, this document
      creates one new registry.  These topics are described in the TCP option space following subsections.</t>

      <section anchor="IANA-TCP-Option-Kind" numbered="true" toc="default">
        <name>TCP Option Kind Numbers</name>
      <t>IANA has
      updated the "TCP Option Kind Numbers" registry to point to this document
      for Multipath TCP, as follows:</t>

      <texttable shown in <xref target="table_tcpo"/>:</t>
      <table anchor="table_tcpo" title="TCP align="center">
        <name>TCP Option Kind Numbers">
        <ttcol align="center">Kind</ttcol>
        <ttcol align="center">Length</ttcol>
        <ttcol align="center">Meaning</ttcol>
        <ttcol align="center">Reference</ttcol>

        <c>30</c>
        <c>N</c>
        <c>Multipath TCP (MPTCP)</c>
        <c>This document</c>
      </texttable> Numbers</name>
        <thead>
          <tr>
            <th align="center">Kind</th>
            <th align="center">Length</th>
            <th align="center">Meaning</th>
            <th align="center">Reference</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="center">30</td>
            <td align="center">N</td>
            <td align="center">Multipath TCP (MPTCP)</td>
            <td align="center">RFC 8684</td>
          </tr>
        </tbody>
      </table>
      </section>
      <section anchor="IANA_subtypes" title="MPTCP numbered="true" toc="default">
        <name>MPTCP Option Subtypes"> Subtypes</name>
        <t>The 4-bit MPTCP subtype sub-registry ("MPTCP in the "MPTCP Option Subtypes"
        subregistry under the "Transmission Control Protocol (TCP) Parameters" registry)
        registry was defined in RFC6824. <xref target="RFC6824"/>. Since RFC6824 was <xref target="RFC6824"/> is an
        Experimental RFC and not a Standards Track RFC, and since no further
        entries have occurred beyond those pointing to RFC6824, <xref target="RFC6824"/>, IANA is requested to replace has
        replaced the existing registry with the contents of
        <xref target="table_iana"/> target="table_iana" format="default"/> and with the following
        explanatory note.</t>

        <t>Note: This registry specifies the MPTCP Option Subtypes for MPTCP v1, which obsoletes the Experimental MPTCP v0. For the MPTCP v0 subtypes, please refer to RFC6824.</t>

      <texttable <xref target="RFC6824"/>.</t>
        <table anchor="table_iana" title="MPTCP align="center">
          <name>MPTCP Option Subtypes">
        <ttcol align="center">Value</ttcol>
        <ttcol align="center">Symbol</ttcol>
        <ttcol align="center">Name</ttcol>
        <ttcol align="center">Reference</ttcol>

        <c>0x0</c>
        <c>MP_CAPABLE</c>
        <c>Multipath Capable</c>
        <c>This document, Subtypes</name>
          <thead>
            <tr>
              <th align="center">Value</th>
              <th align="center">Symbol</th>
              <th align="center">Name</th>
              <th align="center">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="center">0x0</td>
              <td align="center">MP_CAPABLE</td>
              <td align="center">Multipath Capable</td>
              <td align="center">RFC 8684, <xref target="sec_init"/></c>

        <c>0x1</c>
        <c>MP_JOIN</c>
        <c>Join Connection</c>
        <c>This document, target="sec_init" format="default"/></td>
            </tr>
            <tr>
              <td align="center">0x1</td>
              <td align="center">MP_JOIN</td>
              <td align="center">Join Connection</td>
              <td align="center">RFC 8684, <xref target="sec_join"/></c>

        <c>0x2</c>
        <c>DSS</c>
        <c>Data target="sec_join" format="default"/></td>
            </tr>
            <tr>
              <td align="center">0x2</td>
              <td align="center">DSS</td>
              <td align="center">Data Sequence Signal (Data ACK and data sequence mapping)</c>
        <c>This document, <xref target="sec_generalop"/></c>

        <c>0x3</c>
        <c>ADD_ADDR</c>
        <c>Add Address</c>
        <c>This document, <xref target="sec_add_address"/></c>

        <c>0x4</c>
        <c>REMOVE_ADDR</c>
        <c>Remove Address</c>
        <c>This document, <xref target="sec_remove_addr"/></c>

        <c>0x5</c>
        <c>MP_PRIO</c>
        <c>Change Data Sequence Mapping)</td>
              <td align="center">RFC 8684, <xref target="sec_generalop" format="default"/></td>
            </tr>
            <tr>
              <td align="center">0x3</td>
              <td align="center">ADD_ADDR</td>
              <td align="center">Add Address</td>
              <td align="center">RFC 8684, <xref target="sec_add_address" format="default"/></td>
            </tr>
            <tr>
              <td align="center">0x4</td>
              <td align="center">REMOVE_ADDR</td>
              <td align="center">Remove Address</td>
              <td align="center">RFC 8684, <xref target="sec_remove_addr" format="default"/></td>
            </tr>
            <tr>
              <td align="center">0x5</td>
              <td align="center">MP_PRIO</td>
              <td align="center">Change Subflow Priority</c>
        <c>This document, <xref target="sec_policy"/></c>

        <c>0x6</c>
        <c>MP_FAIL</c>
        <c>Fallback</c>
        <c>This document, <xref target="sec_fallback"/></c>

        <c>0x7</c>
        <c>MP_FASTCLOSE</c>
        <c>Fast Close</c>
        <c>This document, <xref target="sec_fastclose"/></c>

        <c>0x8</c>
        <c>MP_TCPRST</c>
        <c>Subflow Reset</c>
        <c>This document, <xref target="sec_reset"/></c>

        <c>0xf</c>
        <c>MP_EXPERIMENTAL</c>
        <c>Reserved for private experiments</c>
        <c></c>

      </texttable> Priority</td>
              <td align="center">RFC 8684, <xref target="sec_policy" format="default"/></td>
            </tr>
            <tr>
              <td align="center">0x6</td>
              <td align="center">MP_FAIL</td>
              <td align="center">Fallback</td>
              <td align="center">RFC 8684, <xref target="sec_fallback" format="default"/></td>
            </tr>
            <tr>
              <td align="center">0x7</td>
              <td align="center">MP_FASTCLOSE</td>
              <td align="center">Fast Close</td>
              <td align="center">RFC 8684, <xref target="sec_fastclose" format="default"/></td>
            </tr>
            <tr>
              <td align="center">0x8</td>
              <td align="center">MP_TCPRST</td>
              <td align="center">Subflow Reset</td>
              <td align="center">RFC 8684, <xref target="sec_reset" format="default"/></td>
            </tr>
            <tr>
              <td align="center">0xf</td>
              <td align="center">MP_EXPERIMENTAL</td>
              <td align="center">Reserved for Private Use</td>
              <td align="center"/>
            </tr>
          </tbody>
        </table>
        <t>Values 0x9 through 0xe are currently unassigned. Option 0xf is reserved for use by private experiments. Its use may be formalized in a future specification. Future assignments in this registry are to be defined by Standards Action as defined by <xref target="RFC8126"/>. target="RFC8126" format="default"/>.  Assignments consist of the MPTCP subtype's symbolic name and name, its associated value, and a reference to its specification.</t>
      </section>
      <section anchor="IANA_handshake" title="MPTCP numbered="true" toc="default">
        <name>MPTCP Handshake Algorithms"> Algorithms</name>
        <t>The "MPTCP Handshake Algorithms" sub-registry subregistry under the
        "Transmission Control Protocol (TCP) Parameters" registry was defined
        in RFC6824. <xref target="RFC6824"/>. Since RFC6824 was <xref target="RFC6824"/> is an Experimental RFC and not
        a Standards Track RFC, and since no further entries have occurred
        beyond those pointing to RFC6824, <xref target="RFC6824"/>, IANA is requested to replace has replaced
        the existing registry with the contents of
 <xref target="table_crypto"/> target="table_crypto" format="default"/> and with the following explanatory note.</t>
        <t>Note: This registry specifies the MPTCP Handshake Algorithms for MPTCP v1, which obsoletes the Experimental MPTCP v0. For the MPTCP v0 subtypes, please refer to RFC6824.</t>

      <texttable <xref target="RFC6824"/>.</t>
        <table anchor="table_crypto" title="MPTCP align="center">
          <name>MPTCP Handshake Algorithms">
        <ttcol Algorithms</name>
          <thead>
            <tr>
              <th align="center">Flag Bit</ttcol>
        <ttcol align="center">Meaning</ttcol>
        <ttcol align="center">Reference</ttcol>

        <c>A</c>
        <c>Checksum required</c>
        <c>This document, Bit</th>
              <th align="center">Meaning</th>
              <th align="center">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="center">A</td>
              <td align="center">Checksum required</td>
              <td align="center">RFC 8684, <xref target="sec_init"/></c>

        <c>B</c>
        <c>Extensibility</c>
        <c>This document, target="sec_init" format="default"/></td>
            </tr>
            <tr>
              <td align="center">B</td>
              <td align="center">Extensibility</td>
              <td align="center">RFC 8684, <xref target="sec_init"/></c>

        <c>C</c>
        <c>Do target="sec_init" format="default"/></td>
            </tr>
            <tr>
              <td align="center">C</td>
              <td align="center">Do not attempt to establish new subflows to the source address.</c>
        <c>This document, address.</td>
              <td align="center">RFC 8684, <xref target="sec_init"/></c>

        <c>D-G</c>
        <c>Unassigned</c>
        <c></c>

        <c>H</c>
        <c>HMAC-SHA256</c>
        <c>This document, target="sec_init" format="default"/></td>
            </tr>
            <tr>
              <td align="center">D-G</td>
              <td align="center">Unassigned</td>
              <td align="center"/>
            </tr>
            <tr>
              <td align="center">H</td>
              <td align="center">HMAC-SHA256</td>
              <td align="center">RFC 8684, <xref target="sec_join"/></c>
      </texttable> target="sec_join" format="default"/></td>
            </tr>
          </tbody>
        </table>

        <t>Note that the meanings of bits D "D" through H "H" can be dependent upon bit B, "B",
      depending on how the Extensibility parameter is defined in future specifications; see
      <xref target="sec_init"/> target="sec_init" format="default"/> for more information.</t>
        <t>Future assignments in this registry are also
      to be defined by Standards Action as defined by <xref target="RFC8126"/>. target="RFC8126" format="default"/>.
      Assignments consist of the value of the flags, a symbolic name for the algorithm,
      and a reference to its specification.</t>
      </section>
      <section anchor="IANA_rst" title="MP_TCPRST numbered="true" toc="default">
        <name>MP_TCPRST Reason Codes"> Codes</name>
        <t>IANA is requested to create has created a further sub-registry, subregistry, "MPTCP MP_TCPRST
        Reason Codes" under the "Transmission Control Protocol (TCP)
        Parameters" registry, based on the reason code in the MP_TCPRST (<xref target="sec_reset"/>) target="sec_reset" format="default"/>) message. Initial values for this registry are given in <xref target="table_rstcodes"/>; target="table_rstcodes" format="default"/>; future assignments are to be defined by Specification Required as defined by <xref target="RFC8126"/>. target="RFC8126" format="default"/>. Assignments consist of the value of the code, a short description of its meaning, and a reference to its specification. The maximum value is 0xff.</t>
        <table anchor="table_rstcodes" align="center">
          <name>MPTCP MP_TCPRST Reason Codes</name>
          <thead>
            <tr>
              <th align="center">Code</th>
              <th align="center">Meaning</th>
              <th align="center">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="center">0x00</td>
              <td align="center">Unspecified error</td>
              <td align="center">RFC 8684, <xref target="sec_reset" format="default"/></td>
            </tr>
            <tr>
              <td align="center">0x01</td>
              <td align="center">MPTCP-specific error</td>
              <td align="center">RFC 8684, <xref target="sec_reset" format="default"/></td>
            </tr>
            <tr>
              <td align="center">0x02</td>
              <td align="center">Lack of resources</td>
              <td align="center">RFC 8684, <xref target="sec_reset" format="default"/></td>
            </tr>
            <tr>
              <td align="center">0x03</td>
              <td align="center">Administratively prohibited</td>
              <td align="center">RFC 8684, <xref target="sec_reset" format="default"/></td>
            </tr>
            <tr>
              <td align="center">0x04</td>
              <td align="center">Too much outstanding data</td>
              <td align="center">RFC 8684, <xref target="sec_reset" format="default"/></td>
            </tr>
            <tr>
              <td align="center">0x05</td>
              <td align="center">Unacceptable performance</td>
              <td align="center">RFC 8684, <xref target="sec_reset" format="default"/></td>
            </tr>
            <tr>
              <td align="center">0x06</td>
              <td align="center">Middlebox interference</td>
              <td align="center">RFC 8684, <xref target="sec_reset" format="default"/></td>
            </tr>
          </tbody>
        </table>
        <t>As guidance to the Designated Expert designated expert <xref target="RFC8126"/>, target="RFC8126"
        format="default"/>, assignments should not normally be refused unless
        codepoint space is becoming scarce, providing provided that there is a clear
        distinction from other, already-existing codes, codes and also providing provided that there is sufficient guidance for implementors implementers both sending and receiving these codes.</t>

      <texttable anchor="table_rstcodes" title="MPTCP MP_TCPRST Reason Codes">
        <ttcol align="center">Code</ttcol>
        <ttcol align="center">Meaning</ttcol>
        <ttcol align="center">Reference</ttcol>

        <c>0x00</c>
        <c>Unspecified TCP error</c>
        <c>This document, <xref target="sec_reset"/></c>

        <c>0x01</c>
        <c>MPTCP specific error</c>
        <c>This document, <xref target="sec_reset"/></c>

        <c>0x02</c>
        <c>Lack of resources</c>
        <c>This document, <xref target="sec_reset"/></c>

        <c>0x03</c>
        <c>Administratively prohibited</c>
        <c>This document, <xref target="sec_reset"/></c>

        <c>0x04</c>
        <c>Too much outstanding data</c>
        <c>This document, <xref target="sec_reset"/></c>

        <c>0x05</c>
        <c>Unacceptable performance</c>
        <c>This document, <xref target="sec_reset"/></c>

        <c>0x06</c>
        <c>Middlebox interference</c>
        <c>This document, <xref target="sec_reset"/></c>
      </texttable>
      </section>
    </section>
  </middle>

  <!--  *****BACK MATTER ***** -->

  <back>

    <references title="Normative References">
      &RFC0793;
      &RFC2104;
      &RFC2119;
      &RFC5961;
      &RFC6234;
      &RFC8174;

<displayreference target="I-D.ananth-tcpm-tcpoptext" to="TCPLO"/>

    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>

<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.0793.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2104.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5961.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6234.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
      </references>

    <references title="Informative References">
      &RFC1122;
      &RFC7323;
      &RFC1918;
      &RFC2018;
      &RFC5681;
      &RFC2979;
      &RFC2992;
      &RFC3022;
      &RFC3135;
      &RFC4086;
      &RFC4987;
      &RFC8126;
      &RFC6181;
      &RFC6356;
      &RFC6897;
      &RFC6182;
      &RFC6528;
      &RFC7413;
      &RFC7430;
      &RFC8041;

      <references>
        <name>Informative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1122.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7323.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1918.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2018.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5681.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2979.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2992.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3022.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3135.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4086.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4987.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6181.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6356.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6897.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6182.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6528.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6824.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7413.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7430.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8041.xml"/>

<!--      &TCPLO; draft-ananth-tcpm-tcpoptext-00; Expired--> draft-ananth-tcpm-tcpoptext (Expired) -->
<xi:include href="https://www.rfc-editor.org/refs/bibxml3/reference.I-D.ananth-tcpm-tcpoptext.xml"/>

        <reference anchor='TCPLO'> anchor="norm" target="https://www.usenix.org/legacy/events/sec01/full_papers/handley/handley.pdf">
          <front>
<title>TCP option space extension</title>

<author initials='A' surname='Ramaiah' fullname='Anantha Ramaiah'>
    <organization />
</author>

<date month='March' day='26' year='2012' />

<abstract><t>The document goals are as follows: Firstly, this document summarizes the motivations for extending TCP option space.  Secondly, It tries to summarize the various known issues that needs to be taken into account while extending the TCP option space.  Thirdly, it briefly provides a short summary of the various TCP option space proposals that has been proposed so far.  Some additional proposals which includes variations to the existing proposals are also presented. The goal of this document is to rejuvenate the discussions on this topic and eventually to converge on a scheme for extending TCP option space.</t></abstract>

</front>

<seriesInfo name='Work in' value='Progress' />

</reference>

<reference anchor='norm' target="http://www.usenix.org/events/sec01/full_papers/handley/handley.pdf"><front><title
            <title abbrev="Network Intrusion Detection: Evasion, Traffic Normalization, and End-to-End Protocol Semantics ">Network Intrusion Detection: Evasion, Traffic
Normalization, and End-to-End Protocol Semantics</title><author initials='M.' surname='Handley' fullname='Mark Handley'><organization>ACIRI</organization></author><author initials='V.' surname='Paxson' fullname='Vern Paxson'><organization>ACIRI</organization></author><author initials='C.' surname='Kreibich' fullname='Christian Kreibich'><organization>Technische Universitat Munchen</organization></author><date year="2001"/></front><seriesInfo Semantics</title>
            <seriesInfo name="Usenix Security" value="2001"/></reference> Security Symposium" value="2001"/>
            <author initials="M." surname="Handley" fullname="Mark Handley">
              <organization>ACIRI</organization>
            </author>
            <author initials="V." surname="Paxson" fullname="Vern Paxson">
              <organization>ACIRI</organization>
            </author>
            <author initials="C." surname="Kreibich" fullname="Christian Kreibich">
              <organization>Technische
Universitat Munchen</organization>
            </author>
            <date month="August" year="2001"/>
          </front>
        </reference>

        <reference anchor='howhard' target="https://www.usenix.org/conference/nsdi12/how-hard-can-it-be-designing-and-implementing-deployable-multipath-tcp">
<front><title anchor="howhard" target="https://www.usenix.org/conference/nsdi12/technical-sessions/presentation/raiciu">
          <front>
            <title abbrev="How Hard Can It Be? Designing and Implementing a Deployable Multipath TCP">How Hard Can It Be? Designing and Implementing a Deployable Multipath TCP</title>
            <seriesInfo name="Usenix Symposium on Networked Systems Design and Implementation" value="2012"/>
            <author initials='C.' surname='Raiciu' fullname='Costin Raiciu'><organization>Universitatea initials="C." surname="Raiciu" fullname="Costin Raiciu">
              <organization>Universitatea Politehnica Bucuresti</organization></author> Bucuresti</organization>
            </author>
            <author initials='C.' surname='Paasch' fullname='Christoph Paasch'><organization>Universite initials="C." surname="Paasch" fullname="Christoph Paasch">
              <organization>Universite Catholique de Louvain</organization></author> Louvain</organization>
            </author>
            <author initials='S.' surname='Barre' fullname='Sebastien Barre'><organization>Universite initials="S." surname="Barre" fullname="Sebastien Barre">
              <organization>Universite Catholique de Louvain</organization></author> Louvain</organization>
            </author>
            <author initials='A.' surname='Ford' fullname='Alan Ford'><organization/></author> initials="A." surname="Ford" fullname="Alan Ford">
              <organization/>
            </author>
            <author initials='M.' surname='Honda' fullname='Michio Honda'><organization>Keio University</organization></author> initials="M." surname="Honda" fullname="Michio Honda">
              <organization>Keio University</organization>
            </author>
            <author initials='F.' surname='Duchene' fullname='Fabien Duchene'><organization>Universite initials="F." surname="Duchene" fullname="Fabien Duchene">
              <organization>Universite Catholique de Louvain</organization></author> Louvain</organization>
            </author>
            <author initials='O.' surname='Bonaventure' fullname='Olivier Bonaventure'><organization>Universite initials="O." surname="Bonaventure" fullname="Olivier Bonaventure">
              <organization>Universite Catholique de Louvain</organization></author> Louvain</organization>
            </author>
            <author initials='M.' surname='Handley' fullname='Mark Handley'><organization>University initials="M." surname="Handley" fullname="Mark Handley">
              <organization>University College London</organization></author> London</organization>
            </author>
            <date year="2012" /> month="April" year="2012"/>
          </front>
<seriesInfo name="Usenix Symposium on Networked Systems Design and Implementation" value="2012"/>
        </reference>

        <reference anchor='deployments' target="https://www.ietfjournal.org/multipath-tcp-deployments/"><front><title anchor="deployments" target="https://www.ietfjournal.org/multipath-tcp-deployments/">
          <front>
            <title abbrev="MPTCP Deployments">Multipath TCP Deployments</title><author initials='O.' surname='Bonaventure' fullname='Olivier Bonaventure'><organization>Universite Deployments</title>
            <seriesInfo name="IETF Journal" value="2016"/>
            <author initials="O." surname="Bonaventure" fullname="Olivier Bonaventure">
              <organization>Universite Catholique de Louvain</organization></author><author initials='S.' surname='Seo' fullname='SungHoon Seo'></author><date day="1" Louvain</organization>
            </author>
            <author initials="S." surname="Seo" fullname="SungHoon Seo"/>
            <date month="November" year="2016"/></front><seriesInfo name="IETF Journal" value="2016"/></reference> year="2016"/>
          </front>
        </reference>
      </references>
    </references>

    <section title="Notes anchor="app_options" numbered="true" toc="default">
      <name>Notes on Use of TCP Options" anchor="app_options"> Options</name>
      <t>The TCP option space is limited due to the length of the Data Offset field in the TCP header (4 bits), which defines the TCP header length in 32-bit words. With the standard TCP header being 20 bytes, this leaves a maximum of 40 bytes for options, and many of these may already be used by options such as timestamp and SACK.</t>
      <t>We have performed a brief study on the commonly used TCP options in SYN,
 data, and pure ACK packets, packets and found that there is enough room
 to fit all the options we propose using discussed in this document.</t>
      <t>SYN packets typically include the following options: Maximum Segment Size (MSS) (4 bytes),
      window scale (3 bytes), SACK permitted (2 bytes), (2&nbsp;bytes), and timestamp (10 bytes) options. Together these
      (10&nbsp;bytes). The sum to 19 bytes. of these options is 19&nbsp;bytes. Some operating
      systems appear to pad each option up to a word boundary, thus using 24
      bytes (a brief survey suggests that Windows XP and Mac OS X do this, whereas Linux does not).

      Optimistically, therefore, we have 21 bytes spare, available, or 16 if it has options have to be
      word-aligned. In either case, however, the SYN versions of Multipath Capable (12 bytes)
      MP_CAPABLE (12&nbsp;bytes) and Join MP_JOIN (12 or 16 bytes) options 16&nbsp;bytes) will fit in this remaining space.</t>
      <t>Note that due to the use of a 64-bit data-level sequence space, it is
      feasible that MPTCP will not require the timestamp option for
      protection against wrapped sequence numbers (PAWS (per the Protection
      Against Wrapped Sequences (PAWS) mechanism, as described in <xref target="RFC7323"/>), target="RFC7323"
      format="default"/>), since the data-level sequence space has far less
      chance of wrapping. Confirmation of the validity of this optimisation optimization is
      left for further study.</t>
      <t>TCP data packets typically carry timestamp options in every packet,
      taking 10 bytes (or 12 12, with padding). That leaves 30 bytes (or 28, if
      word-aligned). The Data Sequence Signal (DSS) DSS option varies in length length, depending on whether (1)&nbsp;whether the data sequence mapping and DATA_ACK
      Data Sequence Mapping, DATA_ACK, or both are included, and whether (2)&nbsp;whether the
      sequence numbers in use are 4 or 8 octets. octets, and (3)&nbsp;whether the
      checksum is present. The maximum size of the DSS option is 28 bytes, so even that will fit in the available space. But unless a connection is both bidirectional and high-bandwidth, it is unlikely that all that option space will be required on each DSS option.</t>
      <t>Within the DSS option, it is not necessary to include the data sequence mapping Data Sequence Mapping and DATA_ACK in each packet, and in many cases it may be possible to alternate their presence (so long as the mapping covers the data being sent in the following subsequent packet). It would also be possible to alternate between 4- 4-byte and 8-byte sequence numbers in each option.</t>
      <t>On subflow and connection setup, an MPTCP option is also set on the third packet (an ACK). These are 20 bytes (for Multipath Capable) MP_CAPABLE) and 24 bytes 24&nbsp;bytes (for Join), MP_JOIN), both of which will fit in the available option space.</t>
      <t>Pure ACKs in TCP typically contain only timestamps (10 bytes). Here, Multipath TCP typically
needs to encode only the DATA_ACK (maximum of 12 bytes). Occasionally, ACKs will contain SACK information. Depending
on the number of lost packets, SACK may utilize the entire option space. If a DATA_ACK had to be
included, then it is probably necessary to reduce the number of SACK blocks to accommodate the
DATA_ACK. However, the presence of the DATA_ACK is unlikely to be necessary in a case where SACK is
in use, since until at least some of the SACK blocks have been retransmitted, the cumulative
data-level ACK will not be moving forward (or if it does, due to retransmissions on another path,
then that path can also be used to transmit the new DATA_ACK).</t>
      <t>The ADD_ADDR option can be between 16 and 30 bytes, depending on whether
      (1)&nbsp;whether IPv4 or IPv6 is used, used and whether (2)&nbsp;whether or not the port number is
      present. It is unlikely that such signaling would fit in a data packet
      (although if there is space, it is fine to include it). It is
      recommended to use that duplicate ACKs not be used with no any other payload or options options, in
      order to transmit these rare signals. Note that this is the reason for
      mandating that duplicate ACKs with MPTCP options are not be taken as a signal of congestion.</t>
    </section>
    <section title="TCP anchor="app_tfo" numbered="true" toc="default">
      <name>TCP Fast Open and MPTCP" anchor="app_tfo"> MPTCP</name>
      <t>TCP Fast Open (TFO) is an experimental TCP extension, described in
      <xref target="RFC7413"/>, target="RFC7413" format="default"/>, which has been introduced to
      allow the sending of data
      one RTT earlier than with regular TCP. This is
      considered a valuable gain gain, as very short connections are very common,
      especially for HTTP request/response schemes. It achieves this by sending
      the SYN-segment SYN segment together with the application's data and allowing the listener to reply
      immediately with data after the SYN/ACK. <xref target="RFC7413"/> target="RFC7413" format="default"/> secures
      this mechanism, mechanism by using a new TCP option that includes a cookie which that
      is negotiated in a preceding connection.</t>
      <t>When using TCP Fast Open TFO in conjunction with MPTCP, there are two key
        points to take into account, as detailed hereafter.</t> below.</t>
      <section title="TFO cookie request anchor="tfocookie" numbered="true" toc="default">
        <name>TFO Cookie Request with MPTCP" anchor="tfocookie"> MPTCP</name>
        <t>When a TFO initiator first connects to a listener, it cannot immediately
          include data in the SYN for security reasons <xref target="RFC7413"/>. target="RFC7413" format="default"/>.
          Instead, it requests a cookie that will be used in subsequent
          connections. This is done with the TCP cookie request/response options,
          of respectively 2 bytes and 6-18 bytes bytes, respectively (depending on the chosen cookie length).</t>
        <t>TFO and MPTCP can be combined combined, provided that the total length of all the
          options does not exceed the maximum 40 bytes possible in TCP:

	  <list style="symbols">
	  <t>In

        </t>
        <ul spacing="normal">
          <li>In the SYN: MPTCP uses a 4-bytes long 4-byte MP_CAPABLE option. The sum
          of the MPTCP and TFO options sum up to is 6 bytes. With typical TCP-options TCP options using up
          to 19 bytes in the SYN (24 bytes if options are padded at a word boundary),
          there is enough space to combine the MP_CAPABLE with the TFO Cookie Request.</t>

	  <t>In cookie request.</li>
          <li>In the SYN+ACK: SYN + ACK: MPTCP uses a 12-bytes long 12-byte MP_CAPABLE option, but
          now the TFO option can be as long as 18 bytes. Since the maximum option length
          may be exceeded, it is up to the listener to solve avoid this problem by using a
          shorter cookie.
          As an example, if we consider that 19 bytes are used for classical
          TCP options, the maximum possible cookie length would be
	  of
          7 bytes. Note that that, for the SYN packet, the same limitation applies to subsequent
	  connections, for the SYN packet
          connections (because the initiator then echoes back
          the cookie back to the listener). Finally, if the security impact of reducing
          the cookie size is not deemed acceptable, the listener can reduce the
          amount of space used by other TCP-options TCP options by omitting the TCP timestamps (as
          outlined in <xref target="app_options"/>).</t>
	  </list></t> target="app_options" format="default"/>).</li>
        </ul>
      </section>
      <section title="Data sequence mapping anchor="tfodata" numbered="true" toc="default">
        <name>Data Sequence Mapping under TFO" anchor="tfodata">
	  <t>MPTCP uses, in TFO</name>
        <t>In the TCP establishment phase, MPTCP uses a key exchange that is
          used to generate the Initial Data Sequence Numbers (IDSNs). In particular,
          the SYN with MP_CAPABLE occupies the first octet of the data sequence
          space. With TFO, one way to handle the data sent together with the SYN
          would be to consider an implicit DSS mapping that covers that SYN segment
          (since there is not enough space in the SYN to include a DSS option).
          The problem with that approach is that if a middlebox modifies the TFO
          data, this will not be noticed by MPTCP because of the absence of a
	  DSS-checksum.
          DSS checksum. For example, a TCP TCP&#8209;aware (but not MPTCP)-aware MPTCP-aware) middlebox could
          insert bytes at the beginning of the stream and adapt the TCP checksum
          and sequence numbers accordingly. With an implicit mapping, this information would
          give to the initiator and listener a different view on of the DSS-mapping, with DSS
          mapping; there would be no
          way to detect this inconsistency as inconsistency, because the DSS checksum is not present.</t>
        <t>To solve this, this issue, the TFO data must not be considered part of the
	  Data Sequence Number
          data sequence number space: the SYN with MP_CAPABLE still occupies
          the first octet of data sequence space, but then the first non-TFO
          data byte occupies the second octet. This guarantees that, if the
          use of DSS-checksum the DSS checksum is negotiated, all data in the data sequence
          number space is checksummed. We also note that this does not entail
          a loss of functionality, because TFO-data TFO data is always only sent on the
          initial subflow subflow, before any attempt to create additional subflows.</t>
      </section>
      <section title="Connection establishment examples" anchor="tfoexamples">
          <t>The following shows a anchor="tfoexamples" numbered="true" toc="default">
        <name>Connection Establishment Examples</name>
        <t>A few examples of possible TFO+MPTCP "TFO + MPTCP"
          establishment scenarios.</t> scenarios are shown below.</t>
        <t>Before an initiator can send data together with the SYN, it must request
          a cookie to from the listener, as shown in <xref target="fig_tfocookie"/>.
	  This is done by simply combining the TFO and MPTCP options.</t>

          <figure align="center" anchor="fig_tfocookie" title="Cookie request - target="fig_tfocookie"
          format="default"/>.  (Note:  The sequence number
and length are annotated in <xref target="fig_tfocookie" format="default"/> as
Seq(Length) (e.g., "S. 0(0)") and used hereafter as such in the subsequent figures
        (e.g., "S &nbsp;0(20)" in <xref target="fig_tfodata"/>).) This is done by simply combining the figures."> TFO and MPTCP options.</t>
        <figure anchor="fig_tfocookie">
          <name>Cookie Request</name>
          <artwork align="left"><![CDATA[ align="left" name="" type="" alt=""><![CDATA[
initiator                                                    listener
    |                                                           |
    |   S Seq=0(Length=0) <MP_CAPABLE>, <TFO cookie request>    |
    | -----------------------------------------------------------> --------------------------------------------------------> |
    |                                                           |
    |   S. 0(0) ack 1 <MP_CAPABLE>, <TFO cookie>                |
    | <----------------------------------------------------------- <-------------------------------------------------------- |
    |                                                           |
    |   .  0(0) ack 1 <MP_CAPABLE>                              |
    | -----------------------------------------------------------> --------------------------------------------------------> |
    |                                                           | ]]></artwork>
        </figure>
        <t>Once this is done, the received cookie can be used for TFO, as shown
          in <xref target="fig_tfodata"/>. target="fig_tfodata" format="default"/>. In this example, the initiator first
          sends 20 bytes in the SYN. The listener immediately replies with 100 bytes
          following the SYN-ACK upon SYN-ACK, to which the initiator replies with 20 more bytes.
          Note that the last segment in the figure
          has a TCP sequence number of 21, while the DSS subflow sequence
          number is 1 (because the TFO data is not part of the data sequence
          number space, as explained in Section <xref target="tfodata"/>.</t> target="tfodata" format="default"/>.</t>

        <figure align="center" anchor="fig_tfodata" title="The listener supports TFO"> anchor="fig_tfodata">
          <name>The Listener Supports TFO</name>
          <artwork align="left"><![CDATA[ align="left" name="" type="" alt=""><![CDATA[
initiator                                                    listener
    |                                                           |
    |    S  0(20) <MP_CAPABLE>, <TFO cookie>                    |
    | -----------------------------------------------------------> --------------------------------------------------------> |
    |                                                           |
    |    S. 0(0) ack 21 <MP_CAPABLE>                            |
    | <----------------------------------------------------------- <-------------------------------------------------------- |
    |                                                           |
    |    .  1(100) ack 21 <DSS ack=1 seq=1 ssn=1 dlen=100>      |
    | <----------------------------------------------------------- <-------------------------------------------------------- |
    |                                                           |
    |    .  21(0) ack 1 <MP_CAPABLE>                            |
    | -----------------------------------------------------------> --------------------------------------------------------> |
    |                                                           |
    |    .  21(20) ack 101 <DSS ack=101 seq=1 ssn=1 dlen=20>    |
    | -----------------------------------------------------------> --------------------------------------------------------> |
    |                                                           | ]]></artwork>
        </figure>
        <t>In <xref target="fig_tfofallback"/>, target="fig_tfofallback" format="default"/>, the listener does not support TFO.  The initiator detects
          that no state is created in the listener (as no data is acked), ACKed) and now
          sends the MP_CAPABLE in the third ack, packet, in order for the listener to
          build its MPTCP context at then the end of the establishment.  Now, the
          tfo
          TFO data, when retransmitted, becomes part of the data sequence mapping Data Sequence Mapping
          because it is effectively sent (in fact re-sent) re&#8209;sent) after the
          establishment.</t>
        <figure align="center" anchor="fig_tfofallback" title="The listener does not support TFO"> anchor="fig_tfofallback">
          <name>The Listener Does Not Support TFO</name>
          <artwork align="left"><![CDATA[ align="left" name="" type="" alt=""><![CDATA[
initiator                                                    listener
    |                                                           |
    |    S  0(20) <MP_CAPABLE>, <TFO cookie>                    |
    | -----------------------------------------------------------> --------------------------------------------------------> |
    |                                                           |
    |    S. 0(0) ack 1 <MP_CAPABLE>                             |
    | <----------------------------------------------------------- <-------------------------------------------------------- |
    |                                                           |
    |    .  1(0) ack 1 <MP_CAPABLE>                             |
    | -----------------------------------------------------------> --------------------------------------------------------> |
    |                                                           |
    |    .  1(20) ack 1 <DSS ack=1 seq=1 ssn=1 dlen=20>         |
    | -----------------------------------------------------------> --------------------------------------------------------> |
    |                                                           |
    |    .  0(0) ack 21 <DSS ack=21 seq=1 ssn=1 dlen=0>         |
    | <----------------------------------------------------------- <-------------------------------------------------------- |
    |                                                           | ]]></artwork>
        </figure>
        <t>It is also possible that the listener acknowledges only part of the TFO
          data, as illustrated in <xref target="fig_tfopartial"/>. target="fig_tfopartial" format="default"/>. The
          initiator will simply retransmit the missing data together with a DSS-mapping.</t>
 DSS mapping.</t>
        <figure align="center" anchor="fig_tfopartial" title="Partial data acknowledgement"> anchor="fig_tfopartial">
          <name>Partial Data Acknowledgment</name>
          <artwork align="left"><![CDATA[ align="left" name="" type="" alt=""><![CDATA[
initiator                                                    listener
    |                                                           |
    |    S  0(1000) <MP_CAPABLE>, <TFO cookie>                  |
    | -----------------------------------------------------------> --------------------------------------------------------> |
    |                                                           |
    |    S. 0(0) ack 501 <MP_CAPABLE>                           |
    | <----------------------------------------------------------- <-------------------------------------------------------- |
    |                                                           |
    |    .  501(0) ack 1 <MP_CAPABLE>                           |
    | -----------------------------------------------------------> --------------------------------------------------------> |
    |                                                           |
    |    .  501(500) ack 1 <DSS ack=1 seq=1 ssn=1 dlen=500>     |
    | -----------------------------------------------------------> --------------------------------------------------------> |
    |                                                           | ]]></artwork>
        </figure>
      </section>
    </section>
    <section title="Control Blocks" anchor="app_tcb"> anchor="app_tcb" numbered="true" toc="default">
      <name>Control Blocks</name>
      <t>Conceptually, an MPTCP connection can be represented as an MPTCP protocol control
block (PCB) that contains several variables that track the progress and the
state of the MPTCP connection and a set of linked TCP control blocks
that correspond to the subflows that have been established.</t>
      <t>RFC 793 <xref target="RFC0793"/> target="RFC0793" format="default"/> specifies several state variables. Whenever possible, we reuse
the same terminology as RFC 793 RFC&nbsp;793 to describe the state variables that are
maintained by MPTCP.</t>
      <section title="MPTCP numbered="true" toc="default">
        <name>MPTCP Control Block"> Block</name>
        <t>The MPTCP control block contains the following variable variables per connection.</t>
        <section title="Authentication and Metadata">
<t><list style="hanging">
<t hangText="Local.Token numbered="true" toc="default">
          <name>Authentication and Metadata</name>
          <dl newline="false" spacing="normal" indent="3">
            <dt>Local.Token (32 bits):"> bits):</dt>
            <dd> This is the token chosen by the local host on
this MPTCP connection. The token must be unique among all established
MPTCP connections, connections and is generated from the local key.</t>
<t hangText="Local.Key key.</dd>
            <dt>Local.Key (64 bits):"> bits):</dt>
            <dd> This is the key sent by the local host on this
MPTCP connection.</t>
<t hangText="Remote.Token connection.</dd>
            <dt>Remote.Token (32 bits):"> bits):</dt>
            <dd> This is the token chosen by the remote host on
this MPTCP connection, generated from the remote key.</t>
<t hangText="Remote.Key key.</dd>
            <dt>Remote.Key (64 bits):"> bits):</dt>
            <dd> This is the key chosen by the remote host on
this MPTCP connection</t>
<t hangText="MPTCP.Checksum (flag):"> connection.</dd>
            <dt>MPTCP.Checksum (flag):</dt>
            <dd> This flag is set to true if at least one of the
hosts has set the A "A" bit in the MP_CAPABLE options exchanged during
connection establishment,
and establishment; otherwise,
it is set to false otherwise. false.  If this flag is set, the checksum must be computed in
all DSS options.</t>
</list></t> options.</dd>
          </dl>
        </section>
        <section title="Sending Side">
<t><list style="hanging">
<t hangText="SND.UNA numbered="true" toc="default">
          <name>Sending Side</name>
          <dl newline="false" spacing="normal" indent="3">
            <dt>SND.UNA (64 bits):"> bits):</dt>
            <dd> This is the data sequence number of the next byte to be
acknowledged, at the MPTCP connection level. This variable is updated
upon reception of a DSS option containing a DATA_ACK.</t>
<t hangText="SND.NXT DATA_ACK.</dd>
            <dt>SND.NXT (64 bits):"> bits):</dt>
            <dd> This is the data sequence number of the next byte to be
sent. SND.NXT is used to determine the value of the DSN in the DSS option.</t>
<t hangText="SND.WND option.</dd>
            <dt>SND.WND (32 bits with RFC 7323, 16 bits otherwise):"> bits):</dt>
            <dd> This is the sending send window. &nbsp;32 bits if the features in RFC
            7323 are used; 16 bits otherwise. MPTCP maintains the sending send window at the MPTCP connection level level, and the same
window is shared by all subflows. All subflows use the MPTCP connection
level connection-level
SND.WND to compute the SEQ.WND value that is sent in each
transmitted segment.</t>
</list></t> segment.</dd>
          </dl>
        </section>
        <section title="Receiving Side">
<t><list style="hanging">
<t hangText="RCV.NXT numbered="true" toc="default">
          <name>Receiving Side</name>
          <dl newline="false" spacing="normal" indent="3">
            <dt>RCV.NXT (64 bits):"> bits):</dt>
            <dd> This is the data sequence number of the next byte that
is expected on the MPTCP connection. This state variable is modified
upon reception of in-order data. The value of RCV.NXT is used to specify
the DATA_ACK that is sent in the DSS option on all subflows.</t>
<t hangText="RCV.WND subflows.</dd>
            <dt>RCV.WND (32 bits with RFC 7323, 16 bits otherwise):"> bits):</dt>
            <dd> This is the connection-level receive window, which is the
            maximum of the RCV.WND on all the subflows.</t>
</list></t> subflows. &nbsp;32 bits if the features in RFC 7323 are used; 16 bits otherwise.</dd>
          </dl>
        </section>
      </section>
      <section title="TCP numbered="true" toc="default">
        <name>TCP Control Blocks"> Blocks</name>
        <t>The MPTCP control block also contains a list of the TCP control blocks
that are associated with the MPTCP connection.</t>
        <t>Note that the TCP control block on the TCP subflows does not contain the
RCV.WND and SND.WND state variables variables, as these are maintained at the MPTCP
connection level and not at the subflow level.</t>
        <t>Inside each TCP control block, the following state variables are defined.</t>
        <section title="Sending Side">
<t><list style="hanging">
<t hangText="SND.UNA numbered="true" toc="default">
          <name>Sending Side</name>
          <dl newline="false" spacing="normal" indent="3">
            <dt>SND.UNA (32 bits):"> bits):</dt>
            <dd> This is the sequence number of the next byte to be
acknowledged on the subflow. This variable is updated upon reception of
each TCP acknowledgment on the subflow.</t>
<t hangText="SND.NXT subflow.</dd>
            <dt>SND.NXT (32 bits):"> bits):</dt>
            <dd> This is the sequence number of the next byte to be
sent on the subflow. SND.NXT is used to set the value of SEG.SEQ upon
transmission of the next segment.</t>
</list></t> segment.</dd>
          </dl>
        </section>
        <section title="Receiving Side">
<t><list style="hanging">
<t hangText="RCV.NXT numbered="true" toc="default">
          <name>Receiving Side</name>
          <dl newline="false" spacing="normal" indent="3">
            <dt>RCV.NXT (32 bits):"> bits):</dt>
            <dd> This is the sequence number of the next byte that
is expected on the subflow. This state variable is modified upon
reception of in-order segments. The value of RCV.NXT is copied to the
SEG.ACK field of the next segments transmitted on the subflow.</t>
<t hangText="RCV.WND subflow.</dd>
            <dt>RCV.WND (32 bits with RFC 7323, 16 bits otherwise):"> This bits):</dt>
            <dd>This is the subflow-level receive window that is updated with
            the window field from the segments received on this subflow.</t>
</list></t> subflow. &nbsp;32
            bits if the features in RFC 7323 are used; 16 bits otherwise.</dd>
          </dl>
        </section>
      </section>
    </section>
    <section title="Finite anchor="app_fsm" numbered="true" toc="default">
      <name>Finite State Machine" anchor="app_fsm"> Machine</name>
      <t>The diagram in <xref target="fig_fsm"/> target="fig_fsm" format="default"/> shows the
      Finite State Machine for connection-level closure.  This illustrates how
      the DATA_FIN connection-level signal (indicated in the diagram as the
      DFIN flag on a DATA_ACK) (1) interacts with subflow-level FINs, FINs and (2) permits "break-before-make" break-before-make handover between subflows.</t>
      <figure align="center" anchor="fig_fsm" title="Finite anchor="fig_fsm">
        <name>Finite State Machine for Connection Closure"> Closure</name>
        <artwork align="left"><![CDATA[ align="left" name="" type="" alt=""><![CDATA[
                             +---------+
                             | M_ESTAB |
                             +---------+
                    M_CLOSE    |     |    rcv DATA_FIN
                     -------   |     |    -------
+---------+       snd DATA_FIN /       \ snd DATA_ACK[DFIN] +---------+ +-------+
|  M_FIN  |<-----------------           ------------------->| M_CLOSE |           ------------------->|M_CLOSE|
| WAIT-1  |---------------------------                      |  WAIT |
+---------+               rcv DATA_FIN \                    +---------+                    +-------+
  | rcv DATA_ACK[DFIN]         ------- |                   M_CLOSE |
  | --------------        snd DATA_ACK |                   ------- |
  | CLOSE all subflows                 |              snd DATA_FIN |
  V                                    V                           V
+-----------+              +-----------+                  +-----------+                 +----------+
|M_FINWAIT-2|              | M_CLOSING |                  | M_LAST-ACK|
 +-----------+                 |M_LAST-ACK|
+-----------+              +-----------+                 +----------+
  |              rcv DATA_ACK[DFIN] |           rcv DATA_ACK[DFIN] |
  | rcv DATA_FIN     -------------- |               -------------- |
  |  -------     CLOSE all subflows |           CLOSE all subflows |
  | snd DATA_ACK[DFIN]              V            delete MPTCP PCB  V
  \                          +-----------+                  +---------+                 +--------+
    ------------------------>|M_TIME WAIT|----------------->| M_CLOSED| WAIT|---------------->|M_CLOSED|
                             +-----------+                  +---------+                 +--------+
                                        All subflows in CLOSED
                                            ------------
                                        delete MPTCP PCB ]]></artwork>
      </figure>
    </section>
    <section title="Changes anchor="app_changelog" numbered="true" toc="default">
      <name>Changes from RFC6824" anchor="app_changelog"> RFC 6824</name>
      <t>This section appendix lists the key technical changes between RFC6824, specifying <xref target="RFC6824"/>,
      which specifies MPTCP v0, v0; and this document, which obsoletes RFC6824 <xref target="RFC6824"/> and specifies MPTCP v1. Note that this specification is not backwards backward compatible with RFC6824.

      <list style="symbols">
        <t>The <xref target="RFC6824"/>.

      </t>
      <ul spacing="normal">
        <li>This document incorporates lessons learnt learned from the various implementations, deployments deployments, and experiments gathered in the documents "Use Cases and Operational Experience with Multipath TCP" <xref target="RFC8041"/> target="RFC8041" format="default"/> and the IETF Journal article "Multipath TCP Deployments" <xref target="deployments"/>.</t>
        <t>Connection target="deployments" format="default"/>.</li>
        <li>Connection initiation, through the exchange of the MP_CAPABLE
        MPTCP option, is different from RFC6824. <xref target="RFC6824"/>. The SYN no longer
        includes the initiator's key, allowing to allow the MP_CAPABLE option on the SYN to be shorter in length, length and to avoid duplicating the sending of keying material.</t>
        <t>This material.</li>
        <li>This also ensures reliable delivery of the key on the MP_CAPABLE
        option by allowing its transmission to be combined with data and thus
        using TCP's in-built built-in reliability mechanism. If the initiator does not
        immediately have data to send, the MP_CAPABLE option with the keys
        will be repeated on the first data packet. If the other end is the first to send, then the presence of the DSS option implicitly confirms the receipt of the MP_CAPABLE.</t>
        <t>In MP_CAPABLE.</li>
        <li>In the Flags field of MP_CAPABLE, C "C" is now assigned to mean that
        the sender of this option will not accept additional MPTCP subflows to
        the source address and port. This is an improves efficiency improvement, -- for example example,
        in cases where the sender is behind a strict NAT.</t>
        <t>In NAT.</li>
        <li>In the Flags field of MP_CAPABLE, H "H" now indicates the use of HMAC-SHA256 (rather than HMAC-SHA1).</t>
        <t>Connection HMAC-SHA1).</li>
        <li>Connection initiation also defines the procedure for version negotiation, for implementations that support both v0 (RFC6824) <xref target="RFC6824"/> and v1 (this document).</t>
        <t>The document).</li>
        <li>The HMAC-SHA256 (rather than HMAC-SHA1) algorithm is used, as the algorithm it provides better security. It is used to generate the token in the MP_JOIN and ADD_ADDR messages, messages and to set the initial data sequence number.</t>
        <t>A IDSN.</li>
        <li>A new subflow-level option exists to signal reasons for sending a
        RST on a subflow (MP_TCPRST <xref target="sec_reset"/>), which (<xref target="sec_reset"
        format="default"/>)); this can help an implementation decide whether to attempt later re-connection.</t>
        <t>The reconnection.</li>
        <li>The MP_PRIO option (<xref target="sec_policy"/>), target="sec_policy" format="default"/>),
        which is used to signal a change of priority for a subflow, no longer
        includes the AddrID field. Its purpose was to allow the changed
        priority to be applied on a subflow other than the one it was sent
        on. However, it has been realised was determined that this could be used by a
        man-in-the-middle to divert all traffic on to onto its own path, and MP_PRIO
        does not include a token or other type of security mechanism.</t>
        <t>The mechanism.</li>
        <li>The ADD_ADDR option (<xref target="sec_add_address"/>), target="sec_add_address" format="default"/>), which is used to inform the other host about another potential address, is different in several ways. It now includes an HMAC of the added address, for enhanced security. In addition, reliability for the ADD_ADDR option has been added: the IPVer field is replaced with a flag field, and one flag is assigned (E) which ("E") that is used as an 'Echo' "echo" so a host can indicate that it has received the option.</t>
        <t>An option.</li>
        <li>This document describes an additional way of performing a Fast
        Close is described, -- by sending a an MP_FASTCLOSE option on a RST on all subflows. This allows the host to tear down the subflows and the connection immediately.</t>
        <t>In immediately.</li>
        <li>IANA has reserved the IANA registry a new MPTCP option subtype option, MP_EXPERIMENTAL, is reserved of value 0xf for private experiments. However, the
        Private Use (<xref target="IANA_subtypes"/>). This document doesn't define how to use the subtype option.</t>
        <t>A that value.</li>
        <li>This document adds a new Appendix appendix (<xref target="app_tfo"
        format="default"/>), which discusses the usage of both the MPTCP options
        and TCP Fast Open TFO options on the same packet (<xref target="app_tfo"/>).</t>
      </list></t> packet.</li>
      </ul>
    </section>
    <section anchor="Acknowledgments" numbered="false" toc="default">
      <name>Acknowledgments</name>
      <t>The authors gratefully acknowledge significant input into this
      document from <contact fullname="Sebastien Barre"/> and <contact fullname="Andrew McDonald"/>.</t>
      <t>The authors also wish to acknowledge reviews and contributions from
      <contact fullname="Iljitsch van Beijnum"/>, <contact fullname="Lars
      Eggert"/>, <contact fullname="Marcelo Bagnulo"/>, <contact
      fullname="Robert Hancock"/>, <contact fullname="Pasi Sarolahti"/>,
      <contact fullname="Toby Moncaster"/>, <contact fullname="Philip
      Eardley"/>, <contact fullname="Sergio Lembo"/>, <contact
      fullname="Lawrence Conroy"/>, <contact fullname="Yoshifumi Nishida"/>,
      <contact fullname="Bob Briscoe"/>, <contact fullname="Stein Gjessing"/>,
      <contact fullname="Andrew McGregor"/>, <contact fullname="Georg
      Hampel"/>, <contact fullname="Anumita Biswas"/>, <contact fullname="Wes
      Eddy"/>, <contact fullname="Alexey Melnikov"/>, <contact
      fullname="Francis Dupont"/>, <contact fullname="Adrian Farrel"/>,
      <contact fullname="Barry Leiba"/>, <contact fullname="Robert Sparks"/>,
      <contact fullname="Sean Turner"/>, <contact fullname="Stephen
      Farrell"/>, <contact fullname="Martin Stiemerling"/>, <contact
      fullname="Gregory Detal"/>, <contact fullname="Fabien Duchene"/>,
      <contact fullname="Xavier de Foy"/>, <contact fullname="Rahul Jadhav"/>,
      <contact fullname="Klemens Schragel"/>, <contact fullname="Mirja
      K├╝hlewind"/>, <contact fullname="Sheng Jiang"/>, <contact
      fullname="Alissa Cooper"/>, <contact fullname="Ines Robles"/>, <contact
      fullname="Roman Danyliw"/>, <contact fullname="Adam Roach"/>,
      <contact fullname="Eric Vyncke"/>, and <contact fullname="Ben Kaduk"/>.</t>
    </section>
  </back>
</rfc>