<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="3"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="yes"?>
<rfc category="exp" docName="draft-boucadair-tcpm-capability-option-01"
     ipr="trust200902">
  <!-- ***** FRONT MATTER ***** -->

  <front>
    <title abbrev="TCP Capability Option">TCP Capability Option</title>

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

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

          <city>Rennes</city>

          <code>35000</code>

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

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

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

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

          <city>Rennes</city>

          <region></region>

          <code>35000</code>

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

        <phone></phone>

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

    <date day="" month="" year="" />

    <abstract>
      <t>This document defines an experimental TCP option that can be used to
      negotiate a set of options that are supported by two TCP endpoints. The
      main motivation for designing this option is the optimization of the
      option space for SYN segments.</t>
    </abstract>
  </front>

  <!-- ***** MIDDLE MATTER ***** -->

  <middle>
    <section title="Introduction">
      <t>TCP (<xref target="RFC0793"></xref>) can be extended by defining new
      options. Because of the presence of NATs, firewalls, and other types of
      flow-aware service functions between two TCP endpoints, means to ensure
      that both endpoints support a given option, and that the paths used to
      forward traffic between them do not involve nodes that strip or alter
      the content of the options. This is actually achieved by negotiating the
      support of a given option during the 3WHS stage.</t>

      <t>Typically, an option is included in the SYN message to inform the
      remote TCP peer that the originating TCP peer is "X"-capable (that is,
      it supports feature "X"). Upon receipt of the SYN message, and if no
      intermediary node has stripped that option, the remote peer will echo
      that option in a SYN/ACK if and only if it is also "X"-capable. Feature
      "X" can then be used if the SYN/ACK message that is received by the
      originating peer still carries the "X"-capable; the option must then be
      included in the ACK.</t>

      <t>For example, several TCP extensions have been designed with this
      design rationale in mind, e.g., SYN-EOS <xref
      target="I-D.touch-tcpm-tcp-syn-ext-opt"></xref>, EDO <xref
      target="I-D.ietf-tcpm-tcp-edo"></xref>, SACK Permitted <xref
      target="RFC2018"></xref>, MP_CAPABLE <xref target="RFC6824"></xref>,
      etc. In the meantime, and given the limited TCP option space, it becomes
      more challenging to include all options in a single SYN message.</t>

      <t>Several solutions have been proposed to solve that problem (e.g.,
      <xref target="I-D.touch-tcpm-tcp-syn-ext-opt"></xref>) by means of
      generating a companion TCP message. This document proposes a solution
      that aims to optimize the required option space to facilitate the
      insertion of several "X"-capable options.</t>

      <section title="Applicability">
        <t>The option is primarily designed for network configurations where
        the path between the TCP endpoints is managed (e.g., an MPTCP endpoint
        embedded in the CPE and the remote MPTCP endpoint is located in the
        network side; the paths between these endpoints are managed by the
        same administrative entity such as in <xref
        target="I-D.boucadair-mptcp-natfwfree-profile"></xref>).</t>

        <t>A flow-aware device that removes the option will disable all the
        options that were included in the TCP Capability option. This is not
        supposed in the target deployment context for this option.</t>

        <t>Some middleboxes may allow the TCP Capability option to pass
        through, but the individual options may be blocked. This is not
        supposed in the target deployment context for this option as those
        flow-aware functions are managed.</t>
      </section>

      <section 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>
      </section>
    </section>

    <section title="TCP Capability Option">
      <t>The format of the TCP Capability option is shown in <xref
      target="cap"></xref>. The option follows the format defined in <xref
      target="RFC0793"></xref>.</t>

      <t><figure anchor="cap">
          <artwork><![CDATA[ +--------+--------+--------+--------+
 |  Kind  | Length |  Kind 1| Kind 2 |
 +--------+--------+--------+--------+
 :       ....      |Kind n-1| Kind n | 
 +-------....------+--------+--------+
]]></artwork>
        </figure>"Kind" is to be assigned by IANA (see <xref
      target="IANA"></xref>).</t>

      <t>In order to conduct experiments with this option, a format that
      adheres to <xref target="RFC6994"></xref> is used (see <xref
      target="capex"></xref>). ExID MUST be set to 0x0CA0 (3232).</t>

      <t><figure anchor="capex">
          <artwork><![CDATA[ +--------+--------+--------+--------+
 |  Kind  | Length |       ExID      |
 +--------+--------+--------+--------+
 : Kind 1 | Kind 2 |       ...       : 
 +-------....------+-----------------+
]]></artwork>
        </figure></t>

      <t>"Kindi" carries the code point of an option that a TCP endpoint
      supports and which it would like to negotiate with the remote peer. One
      or multiple "Kindi" fields may be included.</t>

      <t>An endpoint that wishes to enable the capabilities associated with
      one or multiple TCP options must include the corresponding "Kind" codes
      in a TCP Capability option, which is included in the initial SYN. If the
      remote peer supports at least one of the options carried in the TCP
      Capability option, it replies with a SYN/ACK that includes the TCP
      Capability option and which only carries the code points of the options
      it supports. These values are then echoed in the ACK message the
      originating peer sends back to the remote peer.</t>

      <t>When replying to a SYN message that includes a TCP Capability option,
      the remote peer should preserve the same order of the "Kindi" fields (of
      course, those that are not supported won't be included).</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>The security considerations are to be completed.</t>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>IANA is requested to record the following identifier in the "TCP
      Experimental Option Experiment Identifiers (TCP ExIDs)" registry:</t>

      <t><figure>
          <artwork><![CDATA[Value         Description               Reference 
0x0CA0    TCP Capability Option      [This document]]]></artwork>
        </figure></t>
    </section>
  </middle>

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

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

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

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

    <references title="Informative References">
      <?rfc include='reference.RFC.2018'?>

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

      <?rfc include='reference.I-D.ietf-tcpm-tcp-edo'?>

      <?rfc include='reference.I-D.touch-tcpm-tcp-syn-ext-opt'?>

      <?rfc include='reference.I-D.boucadair-mptcp-natfwfree-profile'?>
    </references>
  </back>
</rfc>
