<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-boucadair-mptcp-plain-mode-10"
     ipr="trust200902">
  <front>
    <title abbrev="Plain MPTCP Transport Mode">Extensions for Network-Assisted
    MPTCP Deployment Models</title>

    <author fullname="Mohamed Boucadair" initials="M." role="editor"
            surname="Boucadair">
      <organization>Orange</organization>

      <address>
        <postal>
          <street></street>

          <city>Rennes</city>

          <region></region>

          <code>35000</code>

          <country>France</country>
        </postal>

        <email>mohamed.boucadair@orange.com</email>
      </address>
    </author>

    <author fullname="Christian Jacquenet" initials="C." role="editor"
            surname="Jacquenet">
      <organization>Orange</organization>

      <address>
        <postal>
          <street></street>

          <city>Rennes</city>

          <region></region>

          <country>France</country>
        </postal>

        <email>christian.jacquenet@orange.com</email>
      </address>
    </author>

    <author fullname="Olivier Bonaventure" initials="O." role="editor"
            surname="Bonaventure">
      <organization>Tessares</organization>

      <address>
        <postal>
          <street></street>

          <city></city>

          <region></region>

          <code></code>

          <country>Belgium</country>
        </postal>

        <phone></phone>

        <email>olivier.bonaventure@tessares.net</email>
      </address>
    </author>

    <author fullname="Denis Behaghel" initials="D." surname="Behaghel">
      <organization>OneAccess</organization>

      <address>
        <postal>
          <street></street>

          <city></city>

          <region></region>

          <code></code>

          <country></country>
        </postal>

        <phone></phone>

        <email>Denis.Behaghel@oneaccess-net.com</email>
      </address>
    </author>

    <author fullname="Stefano Secci" initials="S." surname="Secci">
      <organization>UPMC</organization>

      <address>
        <postal>
          <street></street>

          <city></city>

          <region></region>

          <code></code>

          <country></country>
        </postal>

        <phone></phone>

        <facsimile></facsimile>

        <email>stefano.secci@lip6.fr</email>

        <uri></uri>
      </address>
    </author>

    <author fullname="Wim Henderickx" initials="W." role="editor"
            surname="Henderickx">
      <organization>Nokia/Alcatel-Lucent</organization>

      <address>
        <postal>
          <street></street>

          <city></city>

          <region></region>

          <country>Belgium</country>
        </postal>

        <email>wim.henderickx@alcatel-lucent.com</email>
      </address>
    </author>

    <author fullname="Robert Skog" initials="R." role="editor" surname="Skog">
      <organization>Ericsson</organization>

      <address>
        <postal>
          <street></street>

          <city></city>

          <region></region>

          <code></code>

          <country></country>
        </postal>

        <email>robert.skog@ericsson.com</email>
      </address>
    </author>

    <author fullname="Suresh Vinapamula " initials="S." surname="Vinapamula">
      <organization>Juniper</organization>

      <address>
        <postal>
          <street>1137 Innovation Way</street>

          <city>Sunnyvale</city>

          <region>CA</region>

          <code>94089</code>

          <country>USA</country>
        </postal>

        <phone></phone>

        <facsimile></facsimile>

        <email>Sureshk@juniper.net</email>

        <uri></uri>
      </address>
    </author>

    <author fullname="SungHoon Seo" initials="S." surname="Seo">
      <organization>Korea Telecom</organization>

      <address>
        <postal>
          <street></street>

          <city>Seoul</city>

          <region></region>

          <code></code>

          <country>Korea</country>
        </postal>

        <phone></phone>

        <email>sh.seo@kt.com</email>
      </address>
    </author>

    <author fullname="Wouter Cloetens" initials="W." surname="Cloetens">
      <organization>SoftAtHome</organization>

      <address>
        <postal>
          <street>Vaartdijk 3 701</street>

          <city>3018 Wijgmaal</city>

          <region></region>

          <code></code>

          <country>Belgium</country>
        </postal>

        <email>wouter.cloetens@softathome.com</email>
      </address>
    </author>

    <author fullname="Ullrich Meyer" initials="U." surname="Meyer">
      <organization>Vodafone</organization>

      <address>
        <postal>
          <street></street>

          <city></city>

          <region></region>

          <code></code>

          <country>Germany</country>
        </postal>

        <phone></phone>

        <facsimile></facsimile>

        <email>ullrich.meyer@vodafone.com</email>

        <uri></uri>
      </address>
    </author>

    <author fullname="Luis M. Contreras" initials="LM." surname="Contreras">
      <organization>Telefonica</organization>

      <address>
        <postal>
          <street></street>

          <city></city>

          <region></region>

          <code></code>

          <country>Spain</country>
        </postal>

        <phone></phone>

        <facsimile></facsimile>

        <email>luismiguel.contrerasmurillo@telefonica.com</email>

        <uri></uri>
      </address>
    </author>

    <author fullname="Bart Peirens" initials="B." surname="Peirens">
      <organization>Proximus</organization>

      <address>
        <postal>
          <street></street>

          <city></city>

          <region></region>

          <code></code>

          <country></country>
        </postal>

        <phone></phone>

        <facsimile></facsimile>

        <email>bart.peirens@proximus.com</email>

        <uri></uri>
      </address>
    </author>

    <date />

    <abstract>
      <t>Because of the lack of Multipath TCP (MPTCP) support at the server
      side, some service providers now consider a network-assisted model that
      relies upon the activation of a dedicated function called MPTCP
      Conversion Point (MCP). Network-Assisted MPTCP deployment models are
      designed to facilitate the adoption of MPTCP for the establishment of
      multi-path communications without making any assumption about the
      support of MPTCP by the communicating peers. MCPs located in the network
      are responsible for establishing multi-path communications on behalf of
      endpoints, thereby taking advantage of MPTCP capabilities to achieve
      different goals that include (but are not limited to) optimization of
      resource usage (e.g., bandwidth aggregation), of resiliency (e.g.,
      primary/backup communication paths), and traffic offload management.</t>

      <t>This document specifies extensions for Network-Assisted MPTCP
      deployment models.</t>
    </abstract>

    <note title="Requirements Language">
      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
      "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
      document are to be interpreted as described in <xref
      target="RFC2119">RFC 2119</xref>.</t>
    </note>
  </front>

  <middle>
    <section title="Introduction">
      <t>The overall quality of connectivity services can be enhanced by
      combining several access network links for various purposes - resource
      optimization, better resiliency, etc. Some transport protocols, such as
      Multipath TCP <xref target="RFC6824"></xref>, can help achieve such
      better quality, but failed to be massively deployed so far.</t>

      <t>The support of multipath transport capabilities by communicating
      hosts remains a privileged target design so that such hosts can directly
      use the available resources provided by a variety of access networks
      they can connect to. Nevertheless, network operators do not control end
      hosts while the support of MPTCP by content servers remains close to
      zero.</t>

      <t>Network-Assisted MPTCP deployment models are designed to facilitate
      the adoption of MPTCP for the establishment of multi-path communications
      without making any assumption about the support of MPTCP capabilities by
      communicating peers. Network-Assisted MPTCP deployment models rely upon
      MPTCP Conversion Points (MCPs) that act on behalf of hosts so that they
      can take advantage of establishing communications over multiple paths.
      MCPs can be deployed in CPEs (Customer Premises Equipment), as well as
      in the provider's network. MCPs are responsible for establishing
      multi-path communications on behalf of endpoints. Further details about
      the target use cases are provided in <xref target="tuc"></xref>.</t>

      <t>Most of the current operational deployments that take advantage of
      multi-interfaced devices rely upon the use of an encapsulation scheme
      (such as <xref target="I-D.zhang-gre-tunnel-bonding"></xref><xref
      target="TR-348">, </xref>). The use of encapsulation is motivated by the
      need to steer traffic towards the concentrator and also to allow the
      distribution of any kind of traffic besides TCP (e.g., UDP) among the
      available paths without requiring any advanced traffic engineering
      tweaking technique in the network to intercept traffic and redirect it
      towards the appropriate MCP.</t>

      <t>Current operational MPTCP deployments by network operators are
      focused on the forwarding of TCP traffic. The design of such deployments
      sometimes assumes the use of extra signalling provided by SOCKS <xref
      target="RFC1928"></xref>, at the cost of additional management
      complexity and possible service degradation (e.g., up to 6 SOCKS
      messages may have to be exchanged between two MCPs before actual payload
      data to be transferred, thereby yielding several tens of milliseconds of
      extra delay before the connection is established) .</t>

      <t>To avoid the burden of encapsulation and additional signalling
      between MCPs, this document explains how a plain transport mode is
      enabled, so that packets are exchanged between a device and its upstream
      MCP without requiring the activation of any encapsulation scheme (e.g.,
      IP-in-IP <xref target="RFC2473"></xref>, GRE <xref
      target="RFC1701"></xref>). This plain transport mode also avoids the
      need for out-of-band signalling, unlike the aforementioned SOCKS
      context.</t>

      <t>The solution described in this document also works properly when NATs
      are present in the communication path between a device and its upstream
      MCP. In particular, the solution in this document accommodates
      deployments that involve CGN (Carrier Grade NAT) upstream the MCP.</t>

      <t>Network-Assisted MPTCP deployment and operational considerations are
      discussed in <xref
      target="I-D.nam-mptcp-deployment-considerations"></xref>.</t>

      <t>The plain transport mode is characterized as follows:<?rfc subcompact="yes" ?></t>

      <t><list style="symbols">
          <t>0-RTT proxy.</t>

          <t>No encapsulation required (no tunnels, whatsoever).</t>

          <t>No out-of-band signaling for each MPTCP subflow is required.</t>

          <t>Targets both on-path and off-path MCPs.</t>

          <t>Avoids interference with native MPTCP connections.</t>

          <t>Assists MPTCP connections even if endpoints are MPTCP-capable.
          </t>

          <t>Accommodates various deployment contexts, such as those that
          require the preservation of the source IP address and others
          characterized by an address sharing design. In particular:<list
              style="symbols">
              <t>This solution is compatible with IPv4/IPv6.</t>

              <t>This solution does not impose any constraint on the
              addressing scheme to be used by the client.</t>

              <t>This solution does not require nor exclude the use of
              distinct IP prefix pools for network-assisted MPTCP
              deployments.</t>

              <t>This solution supports both transparent and non-transparent
              operations.</t>
            </list><?rfc subcompact="no" ?></t>
        </list></t>
    </section>

    <section title="Terminology">
      <t>The reader should be familiar with the terminology defined in <xref
      target="RFC6824"></xref>.</t>

      <t>This document makes use of the following terms:<list style="symbols">
          <t>Client: an endhost that initiates transport flows forwarded along
          a single path. Such endhost is not assumed to support multipath
          transport capabilities.</t>

          <t>Server: an endhost that communicates with a client. Such endhost
          is not assumed to support multipath transport capabilities.</t>

          <t>Multipath Client: a Client that supports multipath transport
          capabilities.</t>

          <t>Multipath Server: a Server that supports multipath transport
          capabilities. Both the client and the server can be single-homed or
          multi-homed. However, for the use cases discussed in this document,
          the number of interfaces available at the endhosts is not
          relevant.</t>

          <t>Transport flow: a sequence of packets that belong to a
          unidirectional transport flow and which share at least one common
          characteristic (e.g., the same destination address). TCP and SCTP
          flows are composed of packets that have the same source and
          destination addresses, the same protocol number and the same source
          and destination ports.</t>

          <t>Multipath Conversion Point (MCP): a function that terminates a
          transport flow and relays all data carried in the flow into another
          transport flow. <vspace blankLines="1" />MCP is a function that
          converts a multipath transport flow and relays it over a single path
          transport flow and vice versa.</t>
        </list></t>
    </section>

    <section anchor="tuc" title="Target Use Cases">
      <t>We consider two important use cases in this document. We briefly
      introduce them in this section and leave the details to <xref
      target="uc1"></xref> and <xref target="uc2"></xref>. The first use case
      is a Multipath Client that interacts with a remote Server through a MCP
      (<xref target="mpc"></xref>). The second use case is a multi-homed CPE
      that includes a MCP and interacts with a remote Server through a
      downstream MCP (<xref target="mcpe"></xref>).</t>

      <section anchor="mpc" title="Multipath Client">
        <t>In this use case, the Multipath Client would like to take advantage
        of MPTCP even if the Server does not support MPTCP. A typical example
        is a smartphone that could use both WLAN and LTE access networks to
        reach a server in order to achieve higher bandwidth or better
        resilience.</t>

        <t><figure align="center" anchor="legs2"
            title="Network-assisted MPTCP (Host-based Model)">
            <artwork><![CDATA[+--+                                      +-----+      +--+
|C |                                      | MCP |      |S |
+--+                                      +-----+      +--+
 |                                           |           |
 |<==================MPTCP Leg==============>|<---TCP -->|
 |                                           |           |

Legend:
    C: Client
  MCP: Multipath Conversion Point
    S: Server
]]></artwork>
          </figure>In reference to <xref target="legs2"></xref>, the MCP
        terminates the MPTCP connection established by the client and binds it
        to a TCP connection towards the remote server. Two deployments of this
        use case are possible.</t>

        <t>A first deployment is when the MCP is on the path between the
        Multipath Client and the Server. In this case, the MCP can terminate
        the MPTCP connection initiated by the Client and binds it to a TCP
        connection that the MCP establishes with the Server. When the MCP is
        not located on all default forwarding paths, the MPTCP connection must
        be initiated by using the path where the MCP is located.</t>

        <t>A second deployment is when the MCP is not on the path between the
        Multipath Client and the Server. In this case, the Client must first
        initiate a connection towards the MCP and request it to initiate a TCP
        connection towards the Server. This is what the SOCKS protocol
        performs by exchanging control messages to create appropriate mappings
        to handle the connection. Unfortunately, this requires additional
        round-trip-time that affects the performance of the end-to-end data
        transfer, in particular for short-lived connections.</t>

        <t>This document specifies the MP_CONVERT Information Element that is
        carried in the SYN segment of the initial subflow. This SYN segment is
        sent towards the MCP. The MP_CONVERT Information Element contains the
        destination address (and optionally a port number) of the Server.
        Thanks to this information, the MCP can immediately establish the TCP
        connection with the Server without any additional round-trip-time,
        unlike a SOCKS-based MPTCP design.</t>
      </section>

      <section anchor="mcpe" title="Multipath CPE">
        <t>In this use case, neither the Client nor the Server support MPTCP.
        Two MCPs are used as illustrated in <xref target="legs"></xref>. The
        upstream MCP is embedded in the CPE while the downstream MCP is
        located in the provider's network. The CPE is attached to multiple
        access networks (e.g., xDSL and LTE). The upstream MCP transparently
        terminates the TCP connections initiated by the Client and converts
        them into MPTCP connections.</t>

        <t><figure align="center" anchor="legs"
            title="Network-assisted MPTCP (CPE-based Model)">
            <artwork align="center"><![CDATA[          Upstream                      Downstream
+--+      +-----+                         +-----+      +--+
|H1|      | MCP |                         | MCP |      |RM|
+--+      +-----+                         +-----+      +--+
 |           |                              |           |
 |<---TCP--->|<========MPTCP Leg===========>|<---TCP--->|
 |           |                              |           |
]]></artwork>
          </figure></t>

        <t>The same considerations detailed in <xref target="mpc"></xref>
        apply for the insertion of the downstream MCP in an MPTCP
        connection.</t>
      </section>
    </section>

    <section title="The MP_PREFER_PROXY MPTCP Option">
      <t>The implicit mode assumes that the MCP is located on a default
      forwarding path (Section 5.2.2 of <xref
      target="I-D.nam-mptcp-deployment-considerations"></xref>). In such mode,
      the first subflow must always be placed over that primary path so that
      the MCP can intercept MPTCP flows. Once intercepted, the MCP advertises
      its reachability information by means of MPTCP signals (MP_JOIN or
      ADD_ADDR).</t>

      <t>In order to distinguish native MPTCP connections from proxied ones, a
      new MPTCP option, called MP_PREFER_PROXY, is defined. This option is
      meant to inform an on-path MCP that the connection should be proxied.
      The absence of the MP_PREFER_PROXY option is an indication that the
      corresponding MPTCP connection is native: an on-path MCP must not be
      involved in such connection. If no explicit signal is included in the
      initial SYN message, the MCP cannot distinguish "native" MPTCP
      connections from "proxied" ones.</t>

      <section title="Option Format">
        <t>The format of the MP_PREFER_PROXY is shown in <xref
        target="pp"></xref>.</t>

        <t><figure align="center" anchor="pp"
            title="MP_PREFER_PROXY MPTCP Option">
            <artwork><![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      |
      +---------------+---------------+-------+-----------------------+

]]></artwork>
          </figure><list style="symbols">
            <t>Kind and Length: are the same as those defined in Section 3 of
            <xref target="RFC6824"></xref>. The size of this option is 4
            bytes.</t>

            <t>Subtype: must be allocated by IANA (<xref
            target="IANA"></xref>).</t>

            <t>"Reserved" bits: are reserved bits for future assignment as
            additional flag bits. These additional flag bits MUST each be set
            to zero and MUST be ignored upon receipt.</t>
          </list></t>
      </section>

      <section title="Option Processing">
        <t>The MP_PREFER_PROXY option MUST only appear in the SYN message used
        to create the initial subflow of a Multipath TCP connection.</t>

        <t>If the MP_PREFER_PROXY appears in either a SYN segment that does
        not include the MP_CAPABLE option or a segment whose SYN flag is
        unset, it MUST be ignored. An implementation MAY log this event since
        it likely indicates an operational issue.</t>

        <t>The sender inserts the MP_PREFER_PROXY option for MPTCP connections
        that it wants to be proxied by an on-path MCP. Such insertion is
        possible only when there is enough space left in the dedicated TCP
        option space.</t>

        <t>Upon receipt of a SYN message with an MP_CAPABLE, the MCP MUST
        check whether an MP_PREFER_PROXY option is present:<list
            style="symbols">
            <t>If no such option is included, the MCP MUST NOT interfere with
            that MPTCP connection (that is, it must not track this MPTCP
            connection). Processing subsequent subflows of this connection
            will be handled directly by the endpoints.</t>

            <t>If the MP_PREFER_PROXY option is present, the MCP MUST track
            the establishment of the connection. That means that the MCP must
            be prepared to insert itself for the establishment of subsequent
            subflows, in particular.</t>
          </list> Section 5.2.2.1 of <xref
        target="I-D.nam-mptcp-deployment-considerations"></xref> details the
        use of the MP_PREFER_PROXY option.</t>
      </section>
    </section>

    <section anchor="plain" title="Supplying Data to MCPs">
      <t>This section focuses mainly on th explicit mode (Section 5.2.1 of
      <xref target="I-D.nam-mptcp-deployment-considerations"></xref>) which
      assumes that the IP reachability information of an MCP is explicitly
      configured on a device, e.g., by means of a specific DHCP option <xref
      target="I-D.boucadair-mptcp-dhc"></xref>.</t>

      <section title="The MP_CONVERT Information Element">
        <t>In order to avoid extra delays when establishing a proxied MPTCP
        connection, specific information are provided to an MCP during the
        3WHS. Such information is meant to help the MCP instantiate the
        required states to process the connection upstream. The supply of such
        information is achieved by means of an object called the MP_CONVERT
        (MC) Information Element (IE). This information element typically
        carries the source/destination IP addresses and/or port numbers of the
        used by the source and destination endpoints. Other information may
        also be supplied to an MCP; future extensions may be defined.</t>

        <t>The format of the MP_CONVERT Information Element is shown in <xref
        target="pm"></xref>.</t>

        <t><figure align="center" anchor="pm"
            title="MP_CONVERT  Information Element">
            <artwork><![CDATA[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
+---------------------------------------------------------------+
|                        Magic Number                           |
+---------------+---------------+---------------------------+-+-+
|     Type      |     Length    |         Reserved          |D|M|
+---------------+---------------+---------------------------+-+-+
|          Address (IPv4 - 4 octets / IPv6 - 16 octets)         |
+-------------------------------+-------------------------------+
|   Port (2 octets, optional)   |
+-------------------------------+

]]></artwork>
          </figure>The description of the fields is as follows:</t>

        <t><list style="symbols">
            <t>Magic Number: This field MUST be set to "0xFAA8 0xFAA8" to
            indicate this is an MP_CONVERT Information Element. This field is
            meant to unambiguously distinguish any data supplied by an
            application from the one injected by an MCP. Other magic numbers
            are considered by the authors (e.g., 64 bits that include in
            addition to "0xFAA8 0xFAA8" 32 bits to enclose the RFC number).
            </t>

            <t>Type: This field indicates the type of the MP_CONVERT
            Information Element. It MUST be set to 0 to indicate this element
            includes an IP address and, eventually, a port number. Other type
            values MAY be defined in the future.</t>

            <t>Length: Indicates, in bytes, the length of MP_CONVERT
            Information Element. The minimum size of this option is 4
            bytes.</t>

            <t>"Reserved" bits: are reserved bits for future assignment as
            additional flag bits. These additional flag bits MUST each be set
            to zero and MUST be ignored upon receipt.</t>

            <t>D-bit (Direction bit): this flag indicates whether the enclosed
            IP address (and port number) reflects the source or the
            destination IP address (and port number). When the D-bit is set,
            the enclosed IP address must be interpreted as the source IP
            address. When the D-bit is unset, the enclosed IP address must be
            interpreted as the destination IP address.</t>

            <t>M-bit (More bit): When the M-bit is unset, it indicates that
            another MP_CONVERT IE is included. When the M-bit is set, it
            indicates this is the last MP_CONVERT IE included in the payload;
            if any data is placed right after this MP_CONVERT IE, it is
            application data.</t>

            <t>Address: includes a source or destination IP address. The
            address family is determined by the "Length" field. Concretely, a
            MP_CONVERT Information Element that carries an IPv4 address has a
            Length field of 8 bytes (or 10, if a port number is included). A
            MP_CONVERT Information Element that carries an IPv6 address has a
            Length of 20 bytes (or 22, if a port number is included).</t>

            <t>Port: If the D-bit is set (resp. unset), a source (resp.
            destination) port number may be associated with the IP address.
            This field is valid for protocols that use a 16 bit port number
            (e.g., UDP, TCP, SCTP). This field is optional.</t>
          </list></t>

        <t>If the length of MP_CONVERT Information Element is not a multiple
        of 4 bytes, padding MUST be added to preserve 32 bits boundaries.</t>
      </section>

      <section anchor="mpcp"
               title="Processing an MP_CONVERT Information Element">
        <t>The MP_CONVERT Information Element is a variable length object that
        MUST NOT be used in TCP segments whose SYN flag is unset. This IE can
        only appear in the TCP control messages with SYN flag set. The
        information carried in the MP_CONVERT IE is used by an MCP to create
        the initial subflow of a Multipath TCP connection (see the example in
        <xref target="pmf"></xref>).</t>

        <t>Up to two MP_CONVERT Information Elements with type set to zero can
        appear inside a SYN segment. If two MP_CONVERT Information Elements
        with type zero are included, these options MUST NOT have the same
        D-bit value.</t>

        <t><figure align="center" anchor="pmf"
            title="Carrying the MP_CONVERT  Information Element">
            <artwork align="center"><![CDATA[+----+                              +-----+       +--+
|  C |                              | MCP |       |S |
+----+                              +-----+       +--+
 |  | ________________________________|             |
 |  /       Initial subflow           \             |
 |  |========SYN(MP_CAPABLE+MC(S))===>|             |
 |  |                                 |--SYN------->|
 |  |                                 |<--SYN/ACK---|
 |  |<====SYN/ACK(MP_CAPABLE)=========|             |
 |  |             ...                 |             |
 |  \ ________________________________/             |
                 ....                      ....
 |  | ________________________________|             |
 |  /       Additional subflow        \             |
 |  \ ________________________________/             |

Legend:
     <===>: MPTCP leg
     <--->: TCP leg
      MC(): MP_CONVERT Information Element]]></artwork>
          </figure>The MP_CONVERT Information Element MUST be included in the
        payload of a TCP segment whose SYN flag is set.</t>

        <t>If the MP_CONVERT Information Element appears in either a SYN
        segment that does not include the MP_CAPABLE option or a segment whose
        SYN flag is reset, it MUST be ignored. An implementation MAY log this
        event since it likely indicates an operational issue.</t>

        <t>If the original SYN message contains data in its payload (e.g.,
        <xref target="RFC7413"></xref>), that data MUST be placed right after
        the MP_CONVERT IEs when generating the SYN in the MPTCP leg.</t>

        <t><!--When an MCP establishes an MPTCP connection triggered by an incoming packet, it MUST copy the value of the 'Protocol' field (resp. type of the transport header) of the IPv4 (resp. IPv6) header of this incoming packet in the 'Protocol' field of the MP_CONVERT Information Element. The MCP may be configured to enable traffic aggregation for some transport protocols because of the nature of the service they relate to. By default, the 'Protocol' field MUST be set to 6 (TCP).-->An
        implementation MUST ignore MP_CONVERT Information Elements that
        include multicast, broadcast, and host loopback addresses <xref
        target="RFC6890"></xref>. Concretely, an implementation that receives
        an MP_CONVERT Information Element with such addresses MUST silently
        tear down the MPTCP connection.</t>

        <t>An implementation that supports the MP_CONVERT Information Element
        with type zero MUST echo in the SYN/ACK the instances of the
        MP_CONVERT Information Elements included in a SYN received from the
        sender. A sender that does not receive in a SYN/ACK a copy of the
        MP_CONVERT Information Elements it included in a SYN message MUST
        terminate the MPTCP connection and falls back to TCP or native MPTCP
        connection. Furthermore, the sender MUST add an entry to its local
        cache to record the MCPs that do not support the MP_CONVERT
        Information Element. This cache MUST be flushed out under the
        following conditions: a new network attachment is detected by the
        host, a new MCP is configured, the host gets a new IP address/prefix,
        or a TTL has expired. Subsequent connections to an MCP in the cache
        MUST NOT be placed using the explicit proxy mode. This procedure is
        denoted as MCP capability discovery.</t>

        <t>In the following sections, MP_CONVERT Information Element is used
        to refer to the MP_CONVERT Information Element with the type field set
        to zero. Future documents will specify the exact behavior of
        processing MP_CONVERT Information Elements with a non zero type
        field.</t>
      </section>
    </section>

    <section anchor="uc1"
             title="MPTCP Connections from a Multipath TCP Client">
      <t></t>

      <section title="Description">
        <t>The simplest usage of the MP_CONVERT Information Element is when a
        Multipath TCP Client wants to use MPTCP to efficiently utilise
        different network paths (e.g., WLAN and LTE from a smartphone) to
        reach a server that does not support Multipath TCP. The basic
        operation is illustrated in <xref target="ex1"></xref>.</t>

        <t>To use its multipath capabilities to establish an MPTCP connection
        over the available networks, the Client splits its end-to-end
        connection towards the TCP Server into two:<list style="format (%d)">
            <t>An MPTCP connection, that typically relies upon the
            establishment of one subflow per network path, is established
            between the client and the MCP.</t>

            <t>A TCP connection that is established by the MCP with the
            server.</t>
          </list></t>

        <t>Any data that is eligible to be transported over the MPTCP
        connection is sent by the Client towards the MCP over the MPTCP
        connection. The MCP then forwards these data over the regular TCP
        connection until they reach the server. The same forwarding principle
        applies for the data sent by the Server over the TCP connection with
        the MCP.</t>

        <t><figure align="center" anchor="ex1"
            title="A Multipath TCP Client interacts with a Server through a Multipath Conversion Point">
            <artwork><![CDATA[     C <===========>MCP <------------> S
     +<============>+

Legend:
  <===>: subflows of the upstream MPTCP connection
  <--->: downstream TCP connection
]]></artwork>
          </figure></t>
      </section>

      <section anchor="oneproxy" title="Theory of Operation">
        <t>We assume in this section that the Multipath TCP Client has been
        configured with the IP address of one or more MCPs which convert the
        Multipath TCP connection into a regular TCP connection. The address of
        such MCPs can be statically configured on the Client, dynamically
        provisioned to the MPTCP Client by means of a DHCP option <xref
        target="I-D.boucadair-mptcp-dhc"></xref>, or by any other means that
        are outside the scope of this document.</t>

        <t>Conceptually, the MCP acts as a relay between an upstream MPTCP
        connection and a downstream TCP connection. The MCP has at least a
        single IP address that is reachable from the Multipath TCP Client. It
        may be assigned other IP addresses. For the sake of simplicity, we
        assume in this section that the MCP has a single IP address denoted
        MCP@. Similarly, we assume that the client has two addresses C@1 and
        C@2 while address S@ is assigned to the server.</t>

        <t>The MCP maps an upstream MPTCP connection (and its associated
        subflows) onto a downstream TCP connection. On the MCP, an established
        Multipath TCP connection can be identified by the local Token that was
        assigned upon reception of the SYN segment.</t>

        <t>This Token is guaranteed to be unique on the MCP (provided that it
        has a single IP address) during the entire lifetime of the MPTCP
        connection. The 4-tuple (IP src, IP dst, Port src, Port dst) is used
        to identify the downstream TCP connection.</t>

        <t>To initiate a connection to a remote server S, the Multipath TCP
        Client sends a SYN segment towards the MCP that includes the
        MP_CONVERT Information Element described in <xref target="pm"></xref>.
        The destination address of the SYN segment is the IP address of the
        MCP. The MP_CONVERT Information Element included in the SYN contains
        the IP address and optionally the destination port of the Server (see
        <xref target="fe1"></xref>).</t>

        <t><figure align="center" anchor="fe1"
            title="Single-ended MCP Flow Example">
            <artwork align="center"><![CDATA[+----+                              +-----+    +--+
|  C |                              | MCP |    |S |
+----+                              +-----+    +--+
C@1 C@2                              MCP@       S@
 |  | ________________________________|          |
 |  /       Initial subflow           \          |
 |  |=======SYN(MP_CAPABLE+MC(S@))===>|          |
 |  |                                 |--SYN---->|
 |  |                                 |<-SYN/ACK-|
 |  |<====SYN/ACK(MP_CAPABLE)=========|          |
 |  |             ...                 |          |
 |  \ ________________________________/          |
                 ....                    ....
 |  |________________________________ |          |
 | /       Additional subflow        \|          |
 | \ ________________________________/           |

Legend:
     <===>: MPTCP leg
     <--->: TCP leg ]]></artwork>
          </figure></t>

        <t>The MCP processes this SYN segment as follows. First, it generates
        the local key and a unique Token for the Multipath TCP connection.
        This Token identifies the MPTCP connection. It is passed to the MCP
        together with the contents of the MP_CONVERT Information Element
        (i.e., the address of the destination server) and the destination
        port.</t>

        <t>The MCP then establishes a TCP connection with the destination
        server. If the received MP_CONVERT Information Element contains a port
        number, it is used as the destination port of the outgoing TCP
        connection that is being established by the MCP. Otherwise, the
        destination port of the upstream MPTCP connection is used as the
        destination port of the downstream TCP connection. The MCP creates a
        flow entry for the downstream TCP connection and maps the upstream
        MPTCP connection onto the downstream TCP connection.</t>

        <t>The downstream TCP connection is considered to be active upon
        reception of the SYN/ACK segment sent by the destination server. The
        reception of this segment triggers the MCP that confirms the
        establishment of the upstream MPTCP connection by sending a SYN/ACK
        segment towards the Multipath TCP Client (including MP_Convert).</t>

        <t>At this point, there are two established connections. The endpoints
        of the upstream Multipath TCP connection are the Multipath TCP Client
        and the MCP. The endpoints of the downstream TCP connection are the
        MCP and the Server. These two connections are bound by the MCP.</t>

        <t>All the techniques defined in <xref target="RFC6824"></xref> can be
        used by the upstream Multipath TCP connection. In particular, the
        subflows established over the different network paths can be
        controlled by either the Multipath TCP Client or the MCP. It is likely
        that the network operators that deploy MCPs will define policies for
        the utilisation of the MCP. These policies are discussed in Section
        5.6 of <xref
        target="I-D.nam-mptcp-deployment-considerations"></xref>.</t>

        <t>Any data received by the MCP on the upstream Multipath TCP
        connection will be forwarded by the MCP over the bound downstream TCP
        connection. The same applies for data received over the downstream TCP
        connection which will be forwarded by the MCP over the upstream
        Multipath TCP connection.</t>

        <t>One of the functions of the MCP is to maintain the binding between
        the upstream Multipath TCP connection and the downstream TCP
        connection. If the downstream TCP connection fails for some reason
        (excessive retransmissions, reception of a RST segment, etc.), then
        the MCP SHOULD force the teardown of the upstream Multipath TCP
        connection by transmitting a FASTCLOSE. Similarly, if the upstream
        Multipath TCP connection fails for some reason (e.g., reception of a
        FASTCLOSE), the MCP SHOULD tear the downstream TCP connection down and
        remove the flow entries.</t>

        <t>The same reasoning applies when the upstream Multipath TCP
        connection ends with the transmission of DATA_FINs. In this case, the
        MCP SHOULD also terminate the bound downstream TCP connection by using
        FIN segments. If the downstream TCP connection terminates with the
        exchange of FIN segments, the MCP SHOULD initiate a graceful
        termination of the bound upstream Multipath TCP connection.</t>

        <t>An MCP SHOULD associate a lifetime with the Multipath TCP and TCP
        flow entries. In this case, it SHOULD use the same lifetime for each
        pair of bounded connections.</t>
      </section>
    </section>

    <section anchor="uc2"
             title="MPTCP Connections Between Single Path Client and Server">
      <t></t>

      <section title="Description">
        <t>There are situations where neither the client nor the server can
        use multipath transport protocols albeit network providers would want
        to optimize network resource usage by means of multi-path
        communication techniques. Hybrid access service offerings are typical
        business incentives for such situations, where network operators
        combine a fixed network (e.g., xDSL) with a wireless network (e.g.,
        LTE). In this case, as illustrated in <xref target="ex2"></xref>, two
        MCPs are used for each flow. The first MCP, located downstream of the
        client, converts the single path TCP connection originated from the
        client into a Multipath TCP connection established with a second MCP.
        The latter will then establish a TCP connection with the destination
        server.</t>

        <t><figure align="center" anchor="ex2"
            title="A Client interacts with a Server through an upstream and a downstream Multipath Conversion Points">
            <artwork><![CDATA[          Upstream        Downstream
     C <---> MCP <===========> MCP <------------> S
               +<=============>+

Legend:
     <===>: MPTCP leg
     <--->: TCP leg ]]></artwork>
          </figure></t>
      </section>

      <section title="Theory of Operation">
        <t></t>

        <section title="Downstream MCP">
          <t>The downstream MCP can be deployed on-path or off-path. If the
          downstream MCP is deployed off-path, its behavior is described in
          <xref target="oneproxy"></xref>.</t>

          <t>If the downstream MCP is deployed on-path, it only terminates
          MPTCP connections that carry an empty MP_PREFER_PROXY option inside
          their SYN (i.e., no address is conveyed). If the MCP receives a SYN
          segment that contains the MP_CAPABLE option but no MP_PREFER_PROXY,
          it MUST forward the SYN to its final destination without any
          modification.</t>
        </section>

        <section title="Upstream MCP">
          <t>The upstream and downstream MCPs cooperate. The upstream MCP may
          be configured with the addresses of downstream MCPs. If the
          downstream MCP is deployed on-path, the upstream MCP inserts an
          MP_PREFER_PROXY option.</t>

          <t>In this section, we assume that the upstream MCP has been
          configured with one address of the downstream MCP. This address can
          be configured statically, dynamically distributed by means of a DHCP
          option <xref target="I-D.boucadair-mptcp-dhc"></xref>, or by any
          other means that are outside the scope of this document.</t>

          <t>We assume that the upstream MCP has two addresses uMCP@1 and
          uMCP@2 while the downstream MCP is assigned a single IP address
          dMCP@.</t>

          <t>The upstream MCP maps an upstream TCP connection onto a
          downstream MPTCP connection (and its associated subflows) . On the
          upstream MCP, an established MPTCP connection can be identified by
          the local Token that was assigned upon reception of the SYN segment
          from the Client.</t>

          <t>The Client sends a SYN segment addressed to the Server and it is
          intercepted by the upstream MCP which in turns initiates an MPTCP
          connection towards its downstream MCP that includes the MP_CONVERT
          Information Element described in <xref target="pm"></xref>. The
          destination address of the SYN segment is the IP address of the
          downstream MCP. The MP_CONVERT Information Element included in the
          SYN contains the IP address and optionally the destination port of
          the Server; this information is extracted from the SYN message
          received over the upstream TCP connection.</t>

          <t>Concretely, the upstream MCP processes the SYN segment received
          from the Client as follows.</t>

          <t>First, it generates the local key and a unique Token for the
          Multipath TCP connection to identify the MPTCP connection. It
          extracts the destination IP address and, optionally, the destination
          port that will then be carried in a MP_CONVERT Information Element.
          The upstream MCP establishes an MPTCP connection with the downstream
          MCP. The upstream MCP creates a flow entry for the downstream MPTCP
          connection and maps the upstream TCP connection onto the downstream
          MPTCP connection.</t>

          <t>The downstream MPTCP connection is considered to be active upon
          reception of the SYN+ACK segment from the downstream MCP. The
          reception of this segment triggers the upstream MCP that confirms
          the establishment of the upstream TCP connection by sending a
          SYN+ACK segment towards the TCP Client.</t>

          <t>At this point, there are two established connections maintained
          by the upstream MCP:<list style="format (%d)">
              <t>The endpoints of the upstream TCP connection are the Client
              and the upstream MCP.</t>

              <t>The endpoints of the downstream MPTCP connection are the
              upstream MCP and the downstream MCP.</t>
            </list></t>

          <t>These two connections are bound by the upstream MCP. An example
          is shown in <xref target="fe2"></xref>.</t>

          <t><figure align="center" anchor="fe2"
              title="Dual-Ended MCP Flow Example">
              <artwork><![CDATA[          Upstream                     Downstream
+--+      +-----+                        +-----+      +--+
|C1|      | MCP |                        | MCP |      |S1|
+--+      +-----+                        +-----+      +--+
 C@1   uMCP@1 uMCP@2                       dMCP@       S@
  |         | |______________________________|          |
  |--SYN--->|/       Initial subflow         \          |
  |         |=======SYN(MP_CAPABLE+MC(S@))==>|          |
  |         |                                |--SYN---->|
  |         |                                |<-SYN/ACK-|
  |         |<====SYN/ACK(MP_CAPABLE)========|          |
  |<SYN/ACK-|              ...               |          |
  |          \ ______________________________/          |
                         ....                    ....
  |         | | ____________________________ |          |
  |         | |/       Additional subflow   \|          |
  |         | |\ ___________________________/|          |
                             ....
]]></artwork>
            </figure>All the techniques defined in <xref
          target="RFC6824"></xref> can be used by the MPTCP connection. In
          particular, the utilisation of the different network paths can be
          controlled by one MCP or the other.</t>

          <t>Any data received by the upstream MCP over the upstream TCP
          connection will be forwarded by the MCP over the bound downstream
          MPTCP connection, assuming such data are eligible to MPTCP
          transport. The same applies for data received over the downstream
          MPTCP connection which will be forwarded by the upstream MCP over
          the upstream TCP connection.</t>

          <t>The same considerations as in <xref target="oneproxy"></xref>
          apply for the maintenance of the connections by the upstream
          MCP.</t>
        </section>
      </section>
    </section>

    <section title="Interaction with TFO">
      <t>This section discusses the implications of using MP_CONVERT
      Information Elements with TCP Fast Open (TFO). We distinguish between
      TFO negotiation (i.e., a Fast Open option with an empty cookie field to
      request a cookie) and TFO data (i.e., SYN with data and the cookie in
      the Fast Open option). </t>

      <t>This section focuses on the implications of using MP_CONVERT
      Information Element on TFO efficiency. Implications related to MPTCP
      options and TFO negotiation are not specific to this document; the
      reader may refer to <xref target="I-D.barre-mptcp-tfo"></xref>. </t>

      <t>Distinct implications are assessed depending whether TFO negotiation
      and usage occurs before MCP capability discovery phase is completed or
      not (<xref target="mpcp"></xref>). Concretely, the following cases are
      discussed:</t>

      <t><list style="numbers">
          <t>MCP capability discovery was already completed prior to receiving
          a message with TFO negotiation or TFO data: For this case, the host
          has already contacted its MCP in the context of a prior connection.
          The outcome of such connections is used to determine the
          capabilities of its MCP (<xref target="mpcp"></xref>). <list
              style="letters">
              <t>The MCP supports MP_CONVERT Information Element: Any
              information provided to an MCP to facilitate MPTCP operation is
              unambiguously distinguished from TFO data that are also included
              in the SYN payload. An upstream MCP will remove the MP_CONVERT
              Information Elements before relaying the SYN message (with TFO
              data) to the next hop.</t>

              <t>The MCP does not support MP_CONVERT Information Element: No
              additional issue is raised for obvious reasons.</t>
            </list></t>

          <t>MCP capability discovery is not completed prior to receiving a
          message with TFO negotiation or TFO data.<list style="letters">
              <t>If the same message is used to negotiate TFO and to retrieve
              the capabilities of the MCP, extra delay may be observed before
              negotiating TFO if the MCP does not support the MP_CONVERT
              Information Element. Obviously, no concern is raised when the
              MCP supports the MP_CONVERT Information Element.</t>

              <t>If the same message includes TFO data and is used to retrieve
              the capabilities of the MCP, extra delay may be observed before
              negotiating TFO if the MCP does not support the MP_CONVERT
              Information Element. Obviously, no concern is raised when the
              MCP supports the MP_CONVERT Information Element.</t>
            </list></t>
        </list></t>

      <t>To mitigate cases where extra delays are experienced when TFO is
      present, it is RECOMMENDED to not proxy connections with TFO before the
      MCP capability discovery procedure is completed.</t>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>This document requests an MPTCP subtype code for this option: <list
          style="symbols">
          <t>MP_PREFER_PROXY</t>
        </list></t>

      <t></t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>MPTCP-related security threats are discussed in <xref
      target="RFC6181"></xref> and <xref target="RFC6824"></xref>. Additional
      considerations are discussed in the following sub-sections.</t>

      <section title="Privacy">
        <t>The MCP may have access to privacy-related information (e.g., IMSI,
        link identifier, subscriber credentials, etc.). The MCP MUST NOT leak
        such sensitive information outside a local domain.</t>
      </section>

      <section title="Denial-of-Service (DoS) ">
        <t>Means to protect the MCP against Denial-of-Service (DoS) attacks
        MUST be enabled. Such means include the enforcement of ingress
        filtering policies at the network boundaries <xref
        target="RFC2827"></xref>.</t>

        <t>In order to prevent the exhaustion of MCP resources by establishing
        a great number of simultaneous subflows for each MPTCP connection, the
        MCP administrator SHOULD limit the number of allowed subflows per CPE
        for a given connection. Means to protect against SYN flooding attacks
        MUST also be enabled (<xref target="RFC4987"></xref>).</t>

        <t>Attacks that originate outside of the domain can be prevented if
        ingress filtering policies are enforced. Nevertheless, attacks from
        within the network between a host and an MCP instance are yet another
        actual threat. Means to ensure that illegitimate nodes cannot connect
        to a network should be implemented.</t>
      </section>

      <section title="Illegitimate MCP">
        <t>Traffic theft is a risk if an illegitimate MCP is inserted in the
        path. Indeed, inserting an illegitimate MCP in the forwarding path
        allows traffic intercept and can therefore provide access to sensitive
        data issued by or destined to a host. To mitigate this threat, secure
        means to discover an MCP should be enabled.</t>
      </section>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>Many thanks to Chi Dung Phung, Mingui Zhang, Rao Shoaib, Yoshifumi
      Nishida, and Christoph Paasch for their valuable comments.</t>

      <t>Thanks to Ian Farrer, Mikael Abrahamsson, Alan Ford, Dan Wing, and
      Sri Gundavelli for the fruitful discussions in IETF#95 (Buenos
      Aires).</t>

      <t>Special thanks to Pierrick Seite, Yannick Le Goff, Fred Klamm, and
      Xavier Grall for their inputs.</t>

      <t>Thanks also to Olaf Schleusing, Martin Gysi, Thomas Zasowski, Andreas
      Burkhard, Silka Simmen, Sandro Berger, Michael Melloul, Jean-Yves
      Flahaut, Adrien Desportes, Gregory Detal, Benjamin David, Arun
      Srinivasan, and Raghavendra Mallya for the discussion.</t>

      <t>The design approach adopted in -10 is the outcome of fruitful
      discussions with Alan Ford. Many thanks Alan.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include='reference.RFC.6824'?>

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

      <?rfc include='reference.RFC.6890'?>
    </references>

    <references title="Informative References">
      <?rfc include='reference.I-D.zhang-gre-tunnel-bonding'?>

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

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

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

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

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

      <?rfc include='reference.I-D.boucadair-mptcp-dhc'?>

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

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

      <?rfc include='reference.I-D.nam-mptcp-deployment-considerations'?>

      <?rfc include='reference.I-D.barre-mptcp-tfo'?>

      <reference anchor="TR-348">
        <front>
          <title>Hybrid Access Broadband Network Architecture</title>

          <author fullname="BBF">
            <organization>BBF</organization>
          </author>

          <date month="July" year="2016" />
        </front>
      </reference>
    </references>
  </back>
</rfc>
