<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" ipr="trust200902" docName="draft-ietf-tsvwg-multipath-dccp-24" number="9897" updates="" obsoletes="" category="std" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true" tocDepth="3" xml:lang="en" prepTime="2026-01-07T16:25:05" indexInclude="true" scripts="Common,Latin">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-tsvwg-multipath-dccp-24" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc9897" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="Multipath DCCP">Datagram Congestion Control Protocol (DCCP) Extensions for Multipath Operation with Multiple Addresses</title>
    <seriesInfo name="RFC" value="9897" stream="IETF"/>
    <author initials="M." surname="Amend" fullname="Markus Amend" role="editor">
      <organization abbrev="DT" showOnFrontPage="true">Deutsche Telekom</organization>
      <address>
        <postal>
          <street>Deutsche-Telekom-Allee 9</street>
          <city>Darmstadt</city>
          <code>64295</code>
          <country>Germany</country>
        </postal>
        <email>Markus.Amend@telekom.de</email>
      </address>
    </author>
    <author initials="A." surname="Brunstrom" fullname="Anna Brunstrom">
      <organization showOnFrontPage="true">Karlstad University</organization>
      <address>
        <postal>
          <street>Universitetsgatan 2</street>
          <city>Karlstad</city>
          <code>651 88</code>
          <country>Sweden</country>
        </postal>
        <email>anna.brunstrom@kau.se</email>
      </address>
    </author>
    <author initials="A." surname="Kassler" fullname="Andreas Kassler">
      <organization showOnFrontPage="true">Karlstad University</organization>
      <address>
        <postal>
          <street>Universitetsgatan 2</street>
          <city>Karlstad</city>
          <code>651 88</code>
          <country>Sweden</country>
        </postal>
        <email>andreas.kassler@kau.se</email>
      </address>
    </author>
    <author initials="V." surname="Rakocevic" fullname="Veselin Rakocevic">
      <organization showOnFrontPage="true">City St George's, University of London</organization>
      <address>
        <postal>
          <street>Northampton Square</street>
          <city>London</city>
          <country>United Kingdom</country>
        </postal>
        <email>veselin.rakocevic.1@city.ac.uk</email>
      </address>
    </author>
    <author initials="S." surname="Johnson" fullname="Stephen Johnson">
      <organization showOnFrontPage="true">BT</organization>
      <address>
        <postal>
          <street>Adastral Park</street>
          <city>Martlesham Heath</city>
          <code>IP5 3RE</code>
          <country>United Kingdom</country>
        </postal>
        <email>stephen.h.johnson@bt.com</email>
      </address>
    </author>
    <date month="01" year="2026"/>
    <area>WIT</area>
    <workgroup>tsvwg</workgroup>
    <keyword>dccp</keyword>
    <keyword>extensions</keyword>
    <keyword>multipath</keyword>
    <keyword>multihomed</keyword>
    <keyword>subflow</keyword>
    <keyword>concurrent</keyword>
    <keyword>simultaneous</keyword>
    <keyword>mobility</keyword>
    <keyword>mpdccp</keyword>
    <keyword>mp-dccp</keyword>
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">Datagram Congestion Control Protocol (DCCP) communications, as defined in RFC 4340, are inherently restricted to a single path per connection, despite the availability of multiple network paths between peers. The ability to utilize multiple paths simultaneously for a DCCP session can enhance network resource utilization, improve throughput, and increase resilience to network failures, ultimately enhancing the user experience.</t>
      <t indent="0" pn="section-abstract-2">Use cases for Multipath DCCP (MP-DCCP) include mobile devices (e.g., handsets and vehicles) and residential home gateways that maintain simultaneous connections to distinct network types such as cellular and Wireless Local Area Networks (WLANs) or cellular and fixed access networks. Compared to existing multipath transport protocols, such as Multipath TCP (MPTCP), MP-DCCP is particularly suited for latency-sensitive applications with varying requirements for reliability and in-order delivery.</t>
      <t indent="0" pn="section-abstract-3">This document specifies a set of protocol extensions to DCCP that enable multipath operations. These extensions maintain the same service model as DCCP while introducing mechanisms to establish and utilize multiple concurrent DCCP flows across different network paths.</t>
    </abstract>
    <boilerplate>
      <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1">
        <name slugifiedName="name-status-of-this-memo">Status of This Memo</name>
        <t indent="0" pn="section-boilerplate.1-1">
            This is an Internet Standards Track document.
        </t>
        <t indent="0" pn="section-boilerplate.1-2">
            This document is a product of the Internet Engineering Task Force
            (IETF).  It represents the consensus of the IETF community.  It has
            received public review and has been approved for publication by
            the Internet Engineering Steering Group (IESG).  Further
            information on Internet Standards is available in Section 2 of 
            RFC 7841.
        </t>
        <t indent="0" pn="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <eref target="https://www.rfc-editor.org/info/rfc9897" brackets="none"/>.
        </t>
      </section>
      <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2">
        <name slugifiedName="name-copyright-notice">Copyright Notice</name>
        <t indent="0" pn="section-boilerplate.2-1">
            Copyright (c) 2026 IETF Trust and the persons identified as the
            document authors. All rights reserved.
        </t>
        <t indent="0" pn="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) in effect on the date of
            publication of this document. Please review these documents
            carefully, as they describe your rights and restrictions with
            respect to this document. Code Components extracted from this
            document must include Revised BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Revised BSD License.
        </t>
      </section>
    </boilerplate>
    <toc>
      <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1">
        <name slugifiedName="name-table-of-contents">Table of Contents</name>
        <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1">
          <li pn="section-toc.1-1.1">
            <t indent="0" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.1.2">
              <li pn="section-toc.1-1.1.2.1">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.1.1"><xref derivedContent="1.1" format="counter" sectionFormat="of" target="section-1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-multipath-dccp-in-the-netwo">Multipath DCCP in the Networking Stack</xref></t>
              </li>
              <li pn="section-toc.1-1.1.2.2">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.2.1"><xref derivedContent="1.2" format="counter" sectionFormat="of" target="section-1.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-terminology">Terminology</xref></t>
              </li>
              <li pn="section-toc.1-1.1.2.3">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.3.1"><xref derivedContent="1.3" format="counter" sectionFormat="of" target="section-1.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-requirements-language">Requirements Language</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.2">
            <t indent="0" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-operation-overview">Operation Overview</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.2.2">
              <li pn="section-toc.1-1.2.2.1">
                <t indent="0" pn="section-toc.1-1.2.2.1.1"><xref derivedContent="2.1" format="counter" sectionFormat="of" target="section-2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-mp-dccp-concept">MP-DCCP Concept</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.3">
            <t indent="0" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-mp-dccp-protocol">MP-DCCP Protocol</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.3.2">
              <li pn="section-toc.1-1.3.2.1">
                <t indent="0" pn="section-toc.1-1.3.2.1.1"><xref derivedContent="3.1" format="counter" sectionFormat="of" target="section-3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-multipath-capable-feature">Multipath Capable Feature</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.2">
                <t indent="0" pn="section-toc.1-1.3.2.2.1"><xref derivedContent="3.2" format="counter" sectionFormat="of" target="section-3.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-multipath-option">Multipath Option</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.3.2.2.2">
                  <li pn="section-toc.1-1.3.2.2.2.1">
                    <t indent="0" pn="section-toc.1-1.3.2.2.2.1.1"><xref derivedContent="3.2.1" format="counter" sectionFormat="of" target="section-3.2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-mp_confirm">MP_CONFIRM</xref></t>
                  </li>
                  <li pn="section-toc.1-1.3.2.2.2.2">
                    <t indent="0" pn="section-toc.1-1.3.2.2.2.2.1"><xref derivedContent="3.2.2" format="counter" sectionFormat="of" target="section-3.2.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-mp_join">MP_JOIN</xref></t>
                  </li>
                  <li pn="section-toc.1-1.3.2.2.2.3">
                    <t indent="0" pn="section-toc.1-1.3.2.2.2.3.1"><xref derivedContent="3.2.3" format="counter" sectionFormat="of" target="section-3.2.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-mp_fast_close">MP_FAST_CLOSE</xref></t>
                  </li>
                  <li pn="section-toc.1-1.3.2.2.2.4">
                    <t indent="0" pn="section-toc.1-1.3.2.2.2.4.1"><xref derivedContent="3.2.4" format="counter" sectionFormat="of" target="section-3.2.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-mp_key">MP_KEY</xref></t>
                  </li>
                  <li pn="section-toc.1-1.3.2.2.2.5">
                    <t indent="0" pn="section-toc.1-1.3.2.2.2.5.1"><xref derivedContent="3.2.5" format="counter" sectionFormat="of" target="section-3.2.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-mp_seq">MP_SEQ</xref></t>
                  </li>
                  <li pn="section-toc.1-1.3.2.2.2.6">
                    <t indent="0" pn="section-toc.1-1.3.2.2.2.6.1"><xref derivedContent="3.2.6" format="counter" sectionFormat="of" target="section-3.2.6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-mp_hmac">MP_HMAC</xref></t>
                  </li>
                  <li pn="section-toc.1-1.3.2.2.2.7">
                    <t indent="0" pn="section-toc.1-1.3.2.2.2.7.1"><xref derivedContent="3.2.7" format="counter" sectionFormat="of" target="section-3.2.7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-mp_rtt">MP_RTT</xref></t>
                  </li>
                  <li pn="section-toc.1-1.3.2.2.2.8">
                    <t indent="0" pn="section-toc.1-1.3.2.2.2.8.1"><xref derivedContent="3.2.8" format="counter" sectionFormat="of" target="section-3.2.8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-mp_addaddr">MP_ADDADDR</xref></t>
                  </li>
                  <li pn="section-toc.1-1.3.2.2.2.9">
                    <t indent="0" pn="section-toc.1-1.3.2.2.2.9.1"><xref derivedContent="3.2.9" format="counter" sectionFormat="of" target="section-3.2.9"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-mp_removeaddr">MP_REMOVEADDR</xref></t>
                  </li>
                  <li pn="section-toc.1-1.3.2.2.2.10">
                    <t indent="0" pn="section-toc.1-1.3.2.2.2.10.1"><xref derivedContent="3.2.10" format="counter" sectionFormat="of" target="section-3.2.10"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-mp_prio">MP_PRIO</xref></t>
                  </li>
                  <li pn="section-toc.1-1.3.2.2.2.11">
                    <t indent="0" pn="section-toc.1-1.3.2.2.2.11.1"><xref derivedContent="3.2.11" format="counter" sectionFormat="of" target="section-3.2.11"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-mp_close">MP_CLOSE</xref></t>
                  </li>
                  <li pn="section-toc.1-1.3.2.2.2.12">
                    <t indent="0" pn="section-toc.1-1.3.2.2.2.12.1"><xref derivedContent="3.2.12" format="counter" sectionFormat="of" target="section-3.2.12"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-experimental-multipath-opti">Experimental Multipath Option MP_EXP for Private Use</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.3.2.3">
                <t indent="0" pn="section-toc.1-1.3.2.3.1"><xref derivedContent="3.3" format="counter" sectionFormat="of" target="section-3.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-mp-dccp-handshake-procedure">MP-DCCP Handshake Procedure</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.4">
                <t indent="0" pn="section-toc.1-1.3.2.4.1"><xref derivedContent="3.4" format="counter" sectionFormat="of" target="section-3.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-address-knowledge-exchange">Address Knowledge Exchange</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.3.2.4.2">
                  <li pn="section-toc.1-1.3.2.4.2.1">
                    <t indent="0" pn="section-toc.1-1.3.2.4.2.1.1"><xref derivedContent="3.4.1" format="counter" sectionFormat="of" target="section-3.4.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-advertising-a-new-path-mp_a">Advertising a New Path (MP_ADDADDR)</xref></t>
                  </li>
                  <li pn="section-toc.1-1.3.2.4.2.2">
                    <t indent="0" pn="section-toc.1-1.3.2.4.2.2.1"><xref derivedContent="3.4.2" format="counter" sectionFormat="of" target="section-3.4.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-removing-a-path-mp_removead">Removing a Path (MP_REMOVEADDR)</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.3.2.5">
                <t indent="0" pn="section-toc.1-1.3.2.5.1"><xref derivedContent="3.5" format="counter" sectionFormat="of" target="section-3.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-closing-an-mp-dccp-connecti">Closing an MP-DCCP Connection</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.6">
                <t indent="0" pn="section-toc.1-1.3.2.6.1"><xref derivedContent="3.6" format="counter" sectionFormat="of" target="section-3.6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-fallback">Fallback</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.7">
                <t indent="0" pn="section-toc.1-1.3.2.7.1"><xref derivedContent="3.7" format="counter" sectionFormat="of" target="section-3.7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-state-diagram">State Diagram</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.8">
                <t indent="0" pn="section-toc.1-1.3.2.8.1"><xref derivedContent="3.8" format="counter" sectionFormat="of" target="section-3.8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-congestion-control-consider">Congestion Control Considerations</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.9">
                <t indent="0" pn="section-toc.1-1.3.2.9.1"><xref derivedContent="3.9" format="counter" sectionFormat="of" target="section-3.9"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-maximum-packet-size-conside">Maximum Packet Size Considerations</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.10">
                <t indent="0" pn="section-toc.1-1.3.2.10.1"><xref derivedContent="3.10" format="counter" sectionFormat="of" target="section-3.10"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-maximum-number-of-subflow-c">Maximum Number of Subflow Considerations</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.11">
                <t indent="0" pn="section-toc.1-1.3.2.11.1"><xref derivedContent="3.11" format="counter" sectionFormat="of" target="section-3.11"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-path-usage-strategies">Path Usage Strategies</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.3.2.11.2">
                  <li pn="section-toc.1-1.3.2.11.2.1">
                    <t indent="0" pn="section-toc.1-1.3.2.11.2.1.1"><xref derivedContent="3.11.1" format="counter" sectionFormat="of" target="section-3.11.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-path-mobility">Path Mobility</xref></t>
                  </li>
                  <li pn="section-toc.1-1.3.2.11.2.2">
                    <t indent="0" pn="section-toc.1-1.3.2.11.2.2.1"><xref derivedContent="3.11.2" format="counter" sectionFormat="of" target="section-3.11.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-concurrent-path-usage">Concurrent Path Usage</xref></t>
                  </li>
                </ul>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.4">
            <t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.5">
            <t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-interactions-with-middlebox">Interactions with Middleboxes</xref></t>
          </li>
          <li pn="section-toc.1-1.6">
            <t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-implementation">Implementation</xref></t>
          </li>
          <li pn="section-toc.1-1.7">
            <t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" format="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.7.2">
              <li pn="section-toc.1-1.7.2.1">
                <t indent="0" pn="section-toc.1-1.7.2.1.1"><xref derivedContent="7.1" format="counter" sectionFormat="of" target="section-7.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-new-multipath-capable-dccp-">New Multipath Capable DCCP Feature</xref></t>
              </li>
              <li pn="section-toc.1-1.7.2.2">
                <t indent="0" pn="section-toc.1-1.7.2.2.1"><xref derivedContent="7.2" format="counter" sectionFormat="of" target="section-7.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-new-mp-dccp-versions-regist">New MP-DCCP Versions Registry</xref></t>
              </li>
              <li pn="section-toc.1-1.7.2.3">
                <t indent="0" pn="section-toc.1-1.7.2.3.1"><xref derivedContent="7.3" format="counter" sectionFormat="of" target="section-7.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-new-multipath-option-type-a">New Multipath Option Type and Registry</xref></t>
              </li>
              <li pn="section-toc.1-1.7.2.4">
                <t indent="0" pn="section-toc.1-1.7.2.4.1"><xref derivedContent="7.4" format="counter" sectionFormat="of" target="section-7.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-new-dccp-reset-code">New DCCP-Reset Code</xref></t>
              </li>
              <li pn="section-toc.1-1.7.2.5">
                <t indent="0" pn="section-toc.1-1.7.2.5.1"><xref derivedContent="7.5" format="counter" sectionFormat="of" target="section-7.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-new-multipath-key-type-regi">New Multipath Key Type Registry</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.8">
            <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" format="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-references">References</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.8.2">
              <li pn="section-toc.1-1.8.2.1">
                <t indent="0" pn="section-toc.1-1.8.2.1.1"><xref derivedContent="8.1" format="counter" sectionFormat="of" target="section-8.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.8.2.2">
                <t indent="0" pn="section-toc.1-1.8.2.2.1"><xref derivedContent="8.2" format="counter" sectionFormat="of" target="section-8.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.9">
            <t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="Appendix A" format="default" sectionFormat="of" target="section-appendix.a"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-differences-from-multipath-">Differences from Multipath TCP</xref></t>
          </li>
          <li pn="section-toc.1-1.10">
            <t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgments">Acknowledgments</xref></t>
          </li>
          <li pn="section-toc.1-1.11">
            <t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.c"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section anchor="intro" numbered="true" removeInRFC="false" toc="include" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t indent="0" pn="section-1-1">The Datagram Congestion Control Protocol (DCCP) <xref target="RFC4340" format="default" sectionFormat="of" derivedContent="RFC4340"/>
      is a transport protocol that provides bidirectional unicast connections
      of congestion-controlled unreliable datagrams. DCCP communications are
      restricted to one single path. Other fundamentals of the DCCP protocol
      are summarized in <xref target="RFC4340" sectionFormat="of" section="1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc4340#section-1" derivedContent="RFC4340"/> such as the reliable handshake process in <xref target="RFC4340" sectionFormat="of" section="4.7" format="default" derivedLink="https://rfc-editor.org/rfc/rfc4340#section-4.7" derivedContent="RFC4340"/> and the reliable
      negotiation of features in <xref target="RFC4340" sectionFormat="of" section="4.5" format="default" derivedLink="https://rfc-editor.org/rfc/rfc4340#section-4.5" derivedContent="RFC4340"/>. These are an important basis for
      this document. These fundamentals also apply to the DCCP sequencing scheme, which is
      packet-based (<xref target="RFC4340" sectionFormat="of" section="4.2" format="default" derivedLink="https://rfc-editor.org/rfc/rfc4340#section-4.2" derivedContent="RFC4340"/>), and the principles for loss and retransmission of
      features as described in more detail in <xref target="RFC4340" sectionFormat="of" section="6.6.3" format="default" derivedLink="https://rfc-editor.org/rfc/rfc4340#section-6.6.3" derivedContent="RFC4340"/>.  This document specifies a set
      of protocol changes that add multipath support to DCCP, specifically
      support for signaling and setting up multiple paths (a.k.a., "subflows"),
      managing these subflows, the reordering of data, and the termination of
      sessions.</t>
      <t indent="0" pn="section-1-2">Multipath DCCP (MP-DCCP) 
enables a DCCP connection to simultaneously establish a flow across multiple paths. This can be  beneficial to applications that transfer
large amounts of data, by utilizing the capacity/connectivity offered by 
multiple paths. In addition, the multipath extensions enable the trade-off of timeliness and reliability, which is important for low-latency applications that do not require
      guaranteed delivery services such as Audio/Video streaming.</t>
      <t indent="0" pn="section-1-3">In addition to the integration into DCCP services, implementers or future specifications could choose MP-DCCP for other use cases such as
3GPP 5G multi-access solutions (e.g., Access Traffic Steering, Switching, and Splitting (ATSSS) specified in <xref target="TS23.501" format="default" sectionFormat="of" derivedContent="TS23.501"/>) or hybrid access networks. ATSSS combines 3GPP and non-3GPP access between the user equipment and an operator network, while hybrid access combines fixed and cellular access between a residential gateway and an operator network. MP-DCCP can be used in these scenarios for load balancing, seamless session handover, and bandwidth aggregation when non-DCCP traffic such as IP, UDP, or TCP is encapsulated into MP-DCCP. More details on potential use cases for MP-DCCP are provided in <xref target="MP-DCCP.Site" format="default" sectionFormat="of" derivedContent="MP-DCCP.Site"/>, <xref target="IETF105.Slides" format="default" sectionFormat="of" derivedContent="IETF105.Slides"/>, and <xref target="MP-DCCP.Paper" format="default" sectionFormat="of" derivedContent="MP-DCCP.Paper"/>.
All of these use cases profit from an Open Source Linux reference implementation provided under <xref target="MP-DCCP.Site" format="default" sectionFormat="of" derivedContent="MP-DCCP.Site"/>.</t>
      <t indent="0" pn="section-1-4">The encapsulation of non-DCCP traffic (e.g., UDP or IP) in MP-DCCP to enable the above-mentioned use cases is not considered in this specification.
Also out of scope is the encapsulation of DCCP traffic in UDP to pass middleboxes (e.g., NATs, firewalls, proxies, intrusion detection systems (IDSs), etc.) that do not support DCCP. However, a possible method is defined in <xref target="RFC6773" format="default" sectionFormat="of" derivedContent="RFC6773"/> and considered in <xref target="I-D.amend-tsvwg-dccp-udp-header-conversion" format="default" sectionFormat="of" derivedContent="U-DCCP"/> to achieve the same with less overhead.</t>
      <t indent="0" pn="section-1-5">MP-DCCP is based exclusively on the lean concept of DCCP. For traffic that is already encrypted or does not need encryption, MP-DCCP is an efficient choice as it does not apply its own encryption mechanisms. Also, the procedures defined by MP-DCCP, which allow subsequent reordering of traffic and efficient traffic scheduling, improve performance, as shown in <xref target="MP-DCCP.Paper" format="default" sectionFormat="of" derivedContent="MP-DCCP.Paper"/>, and take into account the interaction of the protocol with the further elements required for multipath transport.</t>
      <section anchor="mpdccp_network_stack" numbered="true" removeInRFC="false" toc="include" pn="section-1.1">
        <name slugifiedName="name-multipath-dccp-in-the-netwo">Multipath DCCP in the Networking Stack</name>
        <t indent="0" pn="section-1.1-1">MP-DCCP provides a set of features to DCCP; <xref target="ref-comparison-of-standard-dccp-and-mp-dccp-protocol-stacks" format="default" sectionFormat="of" derivedContent="Figure 1"/> illustrates this layering. 
MP-DCCP is
designed to be used by applications in the same way as DCCP with no
changes to the application itself.</t>
        <figure anchor="ref-comparison-of-standard-dccp-and-mp-dccp-protocol-stacks" align="left" suppress-title="false" pn="figure-1">
          <name slugifiedName="name-comparison-of-standard-dccp">Comparison of Standard DCCP and MP-DCCP Protocol Stacks</name>
          <artwork align="left" pn="section-1.1-2.1">
                             +-------------------------------+
                             |           Application         |
+---------------+            +-------------------------------+
|  Application  |            |            MP-DCCP            |
+---------------+            + - - - - - - - + - - - - - - - +
|      DCCP     |            |Subflow (DCCP) |Subflow (DCCP) |
+---------------+            +-------------------------------+
|      IP       |            |       IP      |      IP       |
+---------------+            +-------------------------------+</artwork>
        </figure>
        <t indent="0" pn="section-1.1-3">A command-line interface (CLI) at the endpoint (or another method) could be used to configure and manage the DCCP connections. This could be extended to also support MP-DCCP, but this specification does not define it.</t>
      </section>
      <section anchor="terminology" numbered="true" removeInRFC="false" toc="include" pn="section-1.2">
        <name slugifiedName="name-terminology">Terminology</name>
        <t indent="0" pn="section-1.2-1">This document uses terms that are either specific for multipath
        transport as defined in <xref target="RFC8684" format="default" sectionFormat="of" derivedContent="RFC8684"/> or defined in the
        context of MP-DCCP, as follows:</t>
        <dl spacing="normal" newline="false" indent="3" pn="section-1.2-2">
          <dt pn="section-1.2-2.1">Path:</dt>
          <dd pn="section-1.2-2.2">
            <t indent="0" pn="section-1.2-2.2.1">A sequence of links between a sender and a
          receiver, defined in this context by a 4-tuple of the source and
          destination address and the source and destination ports. This
          definition follows <xref target="RFC8684" format="default" sectionFormat="of" derivedContent="RFC8684"/> and is illustrated in
          the following two examples for IPv6 and IPv4, which each show a pair
          of sender IP-address:port and a pair of receiver IP-address:port,
          which together form the 4-tuple:</t>
            <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-1.2-2.2.2">
              <li pn="section-1.2-2.2.2.1">IPv6: [2001:db8:3333:4444:5555:6666:7777:8888]:1234, [2001:db8:3333:4444:cccc:dddd:eeee:ffff]:4321</li>
              <li pn="section-1.2-2.2.2.2">IPv4: 203.0.113.1:1234, 203.0.113.2:4321</li>
            </ul>
          </dd>
          <dt pn="section-1.2-2.3">Subflow:</dt>
          <dd pn="section-1.2-2.4">A DCCP flow that is transmitted
          by using a specific path (4-tuple of source and destination
          address/port pairs) that forms one of the multipath flows used by a
          single connection.</dd>
          <dt pn="section-1.2-2.5">(MP-DCCP) Connection:</dt>
          <dd pn="section-1.2-2.6">A set of one or more subflows,
          over which an application can communicate between two hosts. The
          MP-DCCP connection is exposed as a single DCCP socket to the
          application.</dd>
          <dt pn="section-1.2-2.7">Connection Identifier (CI):</dt>
          <dd pn="section-1.2-2.8">A unique identifier that is
          assigned to a multipath connection by the host to distinguish
          several multipath connections locally. The CIs must therefore be
          locally unique per host and do not have to be the same across the
          peers.</dd>
          <dt pn="section-1.2-2.9">Host:</dt>
          <dd pn="section-1.2-2.10">An end host that operates an MP-DCCP implementation
          and either initiates or accepts an MP-DCCP connection.</dd>
          <dt pn="section-1.2-2.11">'+':</dt>
          <dd pn="section-1.2-2.12">The plus symbol means the concatenation of values.</dd>
        </dl>
        <t indent="0" pn="section-1.2-3">In addition to these terms, within the framework of MP-DCCP, the
        interpretation of, and effect on, regular single-path DCCP semantics
        is discussed in <xref target="protocol" format="default" sectionFormat="of" derivedContent="Section 3"/>.</t>
      </section>
      <section anchor="requirements-language" numbered="true" removeInRFC="false" toc="include" pn="section-1.3">
        <name slugifiedName="name-requirements-language">Requirements Language</name>
        <t indent="0" pn="section-1.3-1">
    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 14 <xref target="RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/> 
    when, and only when, they appear in all capitals, as shown here.
        </t>
      </section>
    </section>
    <section anchor="op_overview" numbered="true" removeInRFC="false" toc="include" pn="section-2">
      <name slugifiedName="name-operation-overview">Operation Overview</name>
      <t indent="0" pn="section-2-1">DCCP transmits congestion-controlled unreliable datagrams over a single path.
Various congestion control mechanisms have been specified to optimize
DCCP performance for specific traffic types in terms of profiles denoted
by a Congestion Control IDentifier (CCID).
However, DCCP does not provide built-in
support for managing multiple subflows within one DCCP connection. The
extension of DCCP for Multipath DCCP (MP-DCCP) is described in detail
in <xref target="protocol" format="default" sectionFormat="of" derivedContent="Section 3"/>.</t>
      <t indent="0" pn="section-2-2">At a high level of MP-DCCP operation, the data
stream from a DCCP application is split
by the MP-DCCP operation into one or more subflows that can be
transmitted via different paths, for example, using paths via different links.
The corresponding control information allows the receiver to optionally
reassemble and deliver the received data in the originally transmitted order to the
recipient application. This may be necessary because DCCP does not guarantee in-order delivery.
The details of the transmission scheduling mechanism and
optional reordering mechanism are up to the sender and receiver, respectively,
and are outside the scope of this document.</t>
      <t indent="0" pn="section-2-3">An MP-DCCP connection provides a bidirectional connection of datagrams
between two hosts exchanging data using DCCP. It does not require
any change to the applications. MP-DCCP enables the
hosts to use multiple paths with different 4-tuples to transport
the packets of an MP-DCCP connection. MP-DCCP manages the request,
set-up, authentication, prioritization, modification, and removal of
the DCCP subflows on different paths as well as the exchange of performance
      parameters.</t>
      <t indent="0" pn="section-2-4">The number of DCCP subflows can vary during the 
lifetime of an MP-DCCP connection. The details of the path management decisions for
when to add or remove subflows are outside the scope of this document.</t>
      <t indent="0" pn="section-2-5">The multipath capability for MP-DCCP is negotiated with a new DCCP 
feature, as specified in <xref target="mp_capable" format="default" sectionFormat="of" derivedContent="Section 3.1"/>. Once 
negotiated, all subsequent MP-DCCP operations for that connection are signaled with a 
variable length multipath-related option, as described in <xref target="protocol" format="default" sectionFormat="of" derivedContent="Section 3"/>.
All MP-DCCP operations are signaled by Multipath Options described in <xref target="MP_OPT" format="default" sectionFormat="of" derivedContent="Section 3.2"/>. Options that 
require confirmation from the remote peer are retransmitted by the sender until confirmed or until 
confirmation is no longer considered relevant.</t>
      <t indent="0" pn="section-2-6">The sections that follow define MP-DCCP behavior in detail.</t>
      <section anchor="concept" numbered="true" removeInRFC="false" toc="include" pn="section-2.1">
        <name slugifiedName="name-mp-dccp-concept">MP-DCCP Concept</name>
        <t indent="0" pn="section-2.1-1"><xref target="ref-example-mp-dccp-usage-scenario" format="default" sectionFormat="of" derivedContent="Figure 2"/> provides a general overview of the MP-DCCP working mode, whose main 
characteristics are summarized in this section.</t>
        <figure anchor="ref-example-mp-dccp-usage-scenario" align="left" suppress-title="false" pn="figure-2">
          <name slugifiedName="name-example-mp-dccp-usage-scena">Example MP-DCCP Usage Scenario</name>
          <artwork align="left" pn="section-2.1-2.1">
           Host A                               Host B
------------------------             ------------------------
Address A1    Address A2             Address B1    Address B2
----------    ----------             ----------    ----------
  |             |                      |             |
  |         (DCCP subflow setup)       |             |
  |-----------------------------------&gt;|             |
  |&lt;-----------------------------------|             |
  |             |                      |             |
  |             |  (DCCP subflow setup)|             |
  |             |---------------------&gt;|             |
  |             |&lt;---------------------|             |
  | merge individual DCCP subflows to one MP-DCCP connection
  |             |                      |             |</artwork>
        </figure>
        <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-2.1-3">
          <li pn="section-2.1-3.1">
            <t indent="0" pn="section-2.1-3.1.1">An MP-DCCP connection begins with a 4-way handshake between 
two hosts. In <xref target="ref-example-mp-dccp-usage-scenario" format="default" sectionFormat="of" derivedContent="Figure 2"/>,
an MP-DCCP connection is established between addresses A1 and B1 on Hosts
A and B. In the handshake, a Multipath Capable Feature is used to negotiate multipath support for the connection. Host-specific keys are also exchanged between Host A and Host B during the handshake. The details of the MP-DCCP handshake procedure is described in <xref target="handshaking" format="default" sectionFormat="of" derivedContent="Section 3.3"/>. MP-DCCP does not require both peers to have 
more than one address.</t>
          </li>
          <li pn="section-2.1-3.2">
            <t indent="0" pn="section-2.1-3.2.1">When additional paths and corresponding addresses/ports are available, additional DCCP subflows can be created on 
these paths and attached to the existing MP-DCCP connection. An MP_JOIN option is used to connect a new DCCP subflow to an existing MP-DCCP connection. It contains a Connection Identifier (CI) during the setup of the initial subflow and is exchanged in the 4-way handshake for the subflow together with the Multipath Capable Feature. The example in <xref target="ref-example-mp-dccp-usage-scenario" format="default" sectionFormat="of" derivedContent="Figure 2"/> illustrates the creation of an additional DCCP subflow between Address A2 on Host A and Address B1 on Host B. The two subflows
continue to provide a single connection to the applications at both
endpoints.</t>
          </li>
          <li pn="section-2.1-3.3">
            <t indent="0" pn="section-2.1-3.3.1">MP-DCCP identifies multiple paths by the presence of multiple
addresses/ports at hosts.  Combinations of these multiple addresses/ports
indicate 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 the
additional subflow in the example is shown as being initiated from A2, an additional subflow could
alternatively have been initiated from B1 or B2.</t>
          </li>
          <li pn="section-2.1-3.4">
            <t indent="0" pn="section-2.1-3.4.1">The discovery and setup of additional subflows is achieved
through a path management method including the logic and details of the procedures for adding/removing subflows.
This document describes the procedures that enable a host to initiate new subflows or to signal available IP addresses between peers. However, the definition of a path management method, in which sequence and when subflows are created, is outside the scope of this document. This method is subject to a 
corresponding policy and the specifics of the implementation. If an MP-DCCP peer host wishes to limit the maximum number of paths that can be maintained (e.g., similar to that discussed in <xref target="RFC8041" sectionFormat="of" section="3.4" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8041#section-3.4" derivedContent="RFC8041"/>), the creation of new subflows from that peer host is omitted when the threshold of maximum paths is exceeded and incoming subflow requests <bcp14>MUST</bcp14> be rejected.</t>
          </li>
          <li pn="section-2.1-3.5">
            <t indent="0" pn="section-2.1-3.5.1">Through the use of Multipath Options, MP-DCCP adds connection-level sequence numbers and the exchange of
Round-Trip Time (RTT) information to enable optional reordering features. As a hint for scheduling decisions, a Multipath Option that allows a peer to indicate its priorities for which path to use is also defined.</t>
          </li>
          <li pn="section-2.1-3.6">
            <t indent="0" pn="section-2.1-3.6.1">Subflows are terminated in the same way as regular DCCP connections, as described
in <xref target="RFC4340" sectionFormat="of" section="8.3" format="default" derivedLink="https://rfc-editor.org/rfc/rfc4340#section-8.3" derivedContent="RFC4340"/>. MP-DCCP connections are closed by including an MP_CLOSE option in subflow DCCP-CloseReq or DCCP-Close messages. An MP-DCCP connection may also be reset through the use of an MP_FAST_CLOSE option. Key Data from the initial handshake is included in MP_CLOSE and MP_FAST_CLOSE to protect from an unauthorized shutdown of MP-DCCP connections.</t>
          </li>
        </ul>
      </section>
    </section>
    <section anchor="protocol" numbered="true" removeInRFC="false" toc="include" pn="section-3">
      <name slugifiedName="name-mp-dccp-protocol">MP-DCCP Protocol</name>
      <t indent="0" pn="section-3-1">The DCCP protocol feature list (<xref section="6.4" target="RFC4340" format="default" sectionFormat="of" derivedLink="https://rfc-editor.org/rfc/rfc4340#section-6.4" derivedContent="RFC4340"/>) is
extended in this document by adding a new Multipath Feature with Feature Number 10, as
shown in <xref target="ref-feature-list" format="default" sectionFormat="of" derivedContent="Table 1"/>.</t>
      <table anchor="ref-feature-list" align="center" pn="table-1">
        <name slugifiedName="name-multipath-feature">Multipath Feature</name>
        <thead>
          <tr>
            <th align="left" colspan="1" rowspan="1">Number</th>
            <th align="left" colspan="1" rowspan="1">Meaning</th>
            <th align="left" colspan="1" rowspan="1">Rec'n Rule</th>
            <th align="left" colspan="1" rowspan="1">Initial Value</th>
            <th align="left" colspan="1" rowspan="1">Req'd</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left" colspan="1" rowspan="1">10</td>
            <td align="left" colspan="1" rowspan="1">Multipath Capable</td>
            <td align="left" colspan="1" rowspan="1">SP</td>
            <td align="left" colspan="1" rowspan="1">0</td>
            <td align="left" colspan="1" rowspan="1">N</td>
          </tr>
        </tbody>
      </table>
      <dl indent="3" newline="false" spacing="normal" pn="section-3-3">
        <dt pn="section-3-3.1">Rec'n Rule:</dt>
        <dd pn="section-3-3.2">
          <t indent="0" pn="section-3-3.2.1">The reconciliation rule used for the feature. SP indicates the server-priority as defined in <xref target="RFC4340" sectionFormat="of" section="6.3" format="default" derivedLink="https://rfc-editor.org/rfc/rfc4340#section-6.3" derivedContent="RFC4340"/>.</t>
        </dd>
        <dt pn="section-3-3.3">Initial Value:</dt>
        <dd pn="section-3-3.4">
          <t indent="0" pn="section-3-3.4.1">The initial value for the feature. Every feature has a known initial value.</t>
        </dd>
        <dt pn="section-3-3.5">Req'd:</dt>
        <dd pn="section-3-3.6">
          <t indent="0" pn="section-3-3.6.1">This column is "Y" if and only if every DCCP implementation <bcp14>MUST</bcp14>
understand the feature. If it is "N", then the feature behaves like an extension, and it is safe to respond to Change options for the feature
with empty Confirm options.</t>
        </dd>
      </dl>
      <t indent="0" pn="section-3-4">This specification adds a DCCP protocol option as defined in <xref target="RFC4340" sectionFormat="of" section="5.8" format="default" derivedLink="https://rfc-editor.org/rfc/rfc4340#section-5.8" derivedContent="RFC4340"/>, providing
a new multipath-related variable-length option with option type 46, as
shown in <xref target="ref-option-list" format="default" sectionFormat="of" derivedContent="Table 2"/>.</t>
      <table anchor="ref-option-list" align="center" pn="table-2">
        <name slugifiedName="name-multipath-option-set">Multipath Option Set</name>
        <thead>
          <tr>
            <th align="left" colspan="1" rowspan="1">Type</th>
            <th align="left" colspan="1" rowspan="1">Option Length</th>
            <th align="left" colspan="1" rowspan="1">Meaning</th>
            <th align="left" colspan="1" rowspan="1">DCCP-Data?</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left" colspan="1" rowspan="1">46</td>
            <td align="left" colspan="1" rowspan="1">variable</td>
            <td align="left" colspan="1" rowspan="1">Multipath</td>
            <td align="left" colspan="1" rowspan="1">Y</td>
          </tr>
        </tbody>
      </table>
      <section anchor="mp_capable" numbered="true" removeInRFC="false" toc="include" pn="section-3.1">
        <name slugifiedName="name-multipath-capable-feature">Multipath Capable Feature</name>
        <t indent="0" pn="section-3.1-1">A DCCP endpoint negotiates the Multipath Capable Feature to determine whether multipath extensions can be enabled for a DCCP connection.</t>
        <t indent="0" pn="section-3.1-2">The Multipath Capable Feature (MP_CAPABLE) has Feature Number 10 and follows the structure for features given in <xref target="RFC4340" sectionFormat="of" section="6" format="default" derivedLink="https://rfc-editor.org/rfc/rfc4340#section-6" derivedContent="RFC4340"/>. Beside the negotiation of the feature itself, one or several values can also be exchanged. The value field specified here for the Multipath Capable Feature has a Length of one byte and can be repeated several times within the DCCP option for feature negotiation. This can be, for example, required to announce support of different versions of the protocol. For that, the leftmost four bits in <xref target="ref-mp-capable-format" format="default" sectionFormat="of" derivedContent="Figure 3"/> specify the compatible version of the
MP-DCCP implementation and <bcp14>MUST</bcp14> be set to 0 following this specification. The four bits following the Version field are unassigned in version 0 and <bcp14>MUST</bcp14> be set to zero by the sender and <bcp14>MUST</bcp14> be ignored by the receiver.</t>
        <figure anchor="ref-mp-capable-format" align="left" suppress-title="false" pn="figure-3">
          <name slugifiedName="name-format-of-the-multipath-cap">Format of the Multipath Capable Feature Value Field</name>
          <artwork align="left" pn="section-3.1-3.1">
 0  1  2  3   4  5  6  7
+-----------+------------+
|  Version  | Unassigned |
+-----------+------------+</artwork>
        </figure>
        <t indent="0" pn="section-3.1-4">The setting of the Multipath Capable Feature <bcp14>MUST</bcp14> follow the server-priority reconciliation rule described
in <xref target="RFC4340" sectionFormat="of" section="6.3.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc4340#section-6.3.1" derivedContent="RFC4340"/>. This allows multiple versions to be
specified in order of priority.</t>
        <t indent="0" pn="section-3.1-5">The negotiation <bcp14>MUST</bcp14> be a part of the initial handshake procedure
 described in <xref target="handshaking" format="default" sectionFormat="of" derivedContent="Section 3.3"/>. No subsequent renegotiation of
the Multipath Capable Feature is allowed for the same MP-DCCP connection.</t>
        <t indent="0" pn="section-3.1-6">Clients <bcp14>MUST</bcp14> include a Change R option (<xref section="6" sectionFormat="of" target="RFC4340" format="default" derivedLink="https://rfc-editor.org/rfc/rfc4340#section-6" derivedContent="RFC4340"/>) during the initial handshake request to
supply a list of supported MP-DCCP protocol versions, ordered by preference.</t>
        <t indent="0" pn="section-3.1-7">Servers <bcp14>MUST</bcp14> include a Confirm L option (<xref section="6" sectionFormat="of" target="RFC4340" format="default" derivedLink="https://rfc-editor.org/rfc/rfc4340#section-6" derivedContent="RFC4340"/>) in the subsequent response to agree on
an MP-DCCP version to be used from the Client list, followed by its own
supported version(s), ordered by preference. Any subflow added to an existing MP-DCCP connection <bcp14>MUST</bcp14> use the
version negotiated for the first subflow.</t>
        <t indent="0" pn="section-3.1-8">If no agreement is found, the Server <bcp14>MUST</bcp14> reply with an empty Confirm L option
with Feature Number 10 and no values.</t>
        <t indent="0" pn="section-3.1-9">An example of successful version negotiation is shown hereafter and follows the negotiation example shown in <xref target="RFC4340" sectionFormat="of" section="6.5" format="default" derivedLink="https://rfc-editor.org/rfc/rfc4340#section-6.5" derivedContent="RFC4340"/>. For better understanding, this example uses the unspecified MP-DCCP versions 1 and 2 in addition to the MP-DCCP version 0 specified in this document:</t>
        <figure anchor="ref-mp-capable-example" align="left" suppress-title="false" pn="figure-4">
          <name slugifiedName="name-example-of-mp-dccp-support-">Example of MP-DCCP Support Negotiation Using MP_CAPABLE</name>
          <artwork align="left" pn="section-3.1-10.1">
Client                                             Server
------                                             ------
DCCP-Req + Change R(MP_CAPABLE, 1 0)
               -----------------------------------&gt;

                DCCP-Resp + Confirm L(MP_CAPABLE, 1, 2 1 0)
      &lt;-----------------------------------

           * agreement on version = 1 *</artwork>
        </figure>
        <t indent="0" pn="section-3.1-11">This example illustrates the following:
</t>
        <ol indent="adaptive" spacing="normal" start="1" type="1" pn="section-3.1-12"><li pn="section-3.1-12.1" derivedCounter="1.">
            <t indent="0" pn="section-3.1-12.1.1">The Client indicates support for both MP-DCCP versions 1 and 0, with a preference for version 1.</t>
          </li>
          <li pn="section-3.1-12.2" derivedCounter="2.">
            <t indent="0" pn="section-3.1-12.2.1">The Server agrees on using MP-DCCP version 1 indicated by the first value and supplies its own preference list with the subsequent values.</t>
          </li>
          <li pn="section-3.1-12.3" derivedCounter="3.">
            <t indent="0" pn="section-3.1-12.3.1">MP-DCCP is then enabled between the Client and Server with version 1.</t>
          </li>
        </ol>
        <t indent="0" pn="section-3.1-13">Unlike the example in <xref target="ref-mp-capable-example" format="default" sectionFormat="of" derivedContent="Figure 4"/>, this document only allows the
negotiation of MP-DCCP version 0.  Therefore, per successful
negotiation of MP-DCCP as defined in this document, the Client
and the Server <bcp14>MUST</bcp14> both support MP-DCCP version 0.</t>
        <t indent="0" pn="section-3.1-14">If the version negotiation fails or the Multipath Capable Feature is not present in the DCCP-Request or DCCP-Response packets of the initial handshake procedure, the MP-DCCP connection  either <bcp14>MUST</bcp14> fall back to regular DCCP or <bcp14>MUST</bcp14> close the connection. Further details are specified in <xref target="fallback" format="default" sectionFormat="of" derivedContent="Section 3.6"/>.</t>
      </section>
      <section anchor="MP_OPT" numbered="true" removeInRFC="false" toc="include" pn="section-3.2">
        <name slugifiedName="name-multipath-option">Multipath Option</name>
        <t indent="0" pn="section-3.2-1">MP-DCCP uses one single option to signal various multipath-related operations. The format of this Multipath Option is shown in <xref target="ref-mp-option-format" format="default" sectionFormat="of" derivedContent="Figure 5"/>.</t>
        <figure anchor="ref-mp-option-format" align="left" suppress-title="false" pn="figure-5">
          <name slugifiedName="name-multipath-option-format">Multipath Option Format</name>
          <artwork align="left" pn="section-3.2-2.1">
            1          2          3
 01234567 89012345 67890123 45678901 23456789
+--------+--------+--------+--------+--------+
|00101110| Length | MP_OPT | Value(s) ...
+--------+--------+--------+--------+--------+
 Type=46</artwork>
        </figure>
        <t indent="0" pn="section-3.2-3">The fields used by the Multipath Option are described in <xref target="ref-mp-option-list" format="default" sectionFormat="of" derivedContent="Table 3"/>. MP_OPT refers to a Multipath Option.</t>
        <table anchor="ref-mp-option-list" align="center" pn="table-3">
          <name slugifiedName="name-mp_opt-option-types">MP_OPT Option Types</name>
          <thead>
            <tr>
              <th align="left" colspan="1" rowspan="1">Type</th>
              <th align="left" colspan="1" rowspan="1">Option Length</th>
              <th align="left" colspan="1" rowspan="1">MP_OPT</th>
              <th align="left" colspan="1" rowspan="1">Meaning</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left" colspan="1" rowspan="1">46</td>
              <td align="left" colspan="1" rowspan="1">var</td>
              <td align="left" colspan="1" rowspan="1">0 =MP_CONFIRM</td>
              <td align="left" colspan="1" rowspan="1">Confirm reception and processing of an MP_OPT option</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">46</td>
              <td align="left" colspan="1" rowspan="1">12</td>
              <td align="left" colspan="1" rowspan="1">1 =MP_JOIN</td>
              <td align="left" colspan="1" rowspan="1">Join subflow to an existing MP-DCCP connection</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">46</td>
              <td align="left" colspan="1" rowspan="1">var</td>
              <td align="left" colspan="1" rowspan="1">2 =MP_FAST_CLOSE</td>
              <td align="left" colspan="1" rowspan="1">Close an MP-DCCP connection unconditionally</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">46</td>
              <td align="left" colspan="1" rowspan="1">var</td>
              <td align="left" colspan="1" rowspan="1">3 =MP_KEY</td>
              <td align="left" colspan="1" rowspan="1">Exchange key material for MP_HMAC</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">46</td>
              <td align="left" colspan="1" rowspan="1">9</td>
              <td align="left" colspan="1" rowspan="1">4 =MP_SEQ</td>
              <td align="left" colspan="1" rowspan="1">Multipath sequence number</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">46</td>
              <td align="left" colspan="1" rowspan="1">23</td>
              <td align="left" colspan="1" rowspan="1">5 =MP_HMAC</td>
              <td align="left" colspan="1" rowspan="1">Hash-based message authentication code for MP-DCCP</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">46</td>
              <td align="left" colspan="1" rowspan="1">12</td>
              <td align="left" colspan="1" rowspan="1">6 =MP_RTT</td>
              <td align="left" colspan="1" rowspan="1">Transmit RTT values and calculation parameters</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">46</td>
              <td align="left" colspan="1" rowspan="1">var</td>
              <td align="left" colspan="1" rowspan="1">7 =MP_ADDADDR</td>
              <td align="left" colspan="1" rowspan="1">Advertise one or more additional addresses/ports</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">46</td>
              <td align="left" colspan="1" rowspan="1">8</td>
              <td align="left" colspan="1" rowspan="1">8 =MP_REMOVEADDR</td>
              <td align="left" colspan="1" rowspan="1">Remove one or more addresses/ports</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">46</td>
              <td align="left" colspan="1" rowspan="1">4</td>
              <td align="left" colspan="1" rowspan="1">9 =MP_PRIO</td>
              <td align="left" colspan="1" rowspan="1">Change subflow priority</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">46</td>
              <td align="left" colspan="1" rowspan="1">var</td>
              <td align="left" colspan="1" rowspan="1">10 =MP_CLOSE</td>
              <td align="left" colspan="1" rowspan="1">Close an MP-DCCP connection</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">46</td>
              <td align="left" colspan="1" rowspan="1">var</td>
              <td align="left" colspan="1" rowspan="1">11 =MP_EXP</td>
              <td align="left" colspan="1" rowspan="1">Experimental option for private use</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">46</td>
              <td align="left" colspan="1" rowspan="1">TBD</td>
              <td align="left" colspan="1" rowspan="1">&gt;11</td>
              <td align="left" colspan="1" rowspan="1">(available for future Multipath Options)</td>
            </tr>
          </tbody>
        </table>
        <t indent="0" pn="section-3.2-5">Future Multipath Options could be defined in a later version of or extension to this specification.</t>
        <t indent="0" pn="section-3.2-6">These operations are largely inspired by the signals defined in <xref target="RFC8684" format="default" sectionFormat="of" derivedContent="RFC8684"/>. The procedures for handling faulty or unknown Multipath Options are described in <xref target="fallback" format="default" sectionFormat="of" derivedContent="Section 3.6"/>.</t>
        <section anchor="MP_CONFIRM" numbered="true" removeInRFC="false" toc="include" pn="section-3.2.1">
          <name slugifiedName="name-mp_confirm">MP_CONFIRM</name>
          <t indent="0" pn="section-3.2.1-1">Some Multipath Options require confirmation from the remote peer (see <xref target="ref-mp-option-confirm" format="default" sectionFormat="of" derivedContent="Table 4"/>) for which MP_CONFIRM is specified.
          </t>
          <figure anchor="ref-mp-confirm-format" align="left" suppress-title="false" pn="figure-6">
            <name slugifiedName="name-format-of-the-mp_confirm-op">Format of the MP_CONFIRM Option</name>
            <artwork align="left" pn="section-3.2.1-2.1">
            1          2          3           4          5
 01234567 89012345 67890123 45678901 23456789 01234567 89012345
+--------+--------+--------+--------+--------+--------+--------+
|00101110|  var   |00000000| List of confirmations ...
+--------+--------+--------+--------+--------+--------+--------+
 Type=46   Length  MP_OPT=0</artwork>
          </figure>
          <t indent="0" pn="section-3.2.1-3">
Multipath Options that require confirmation will be retransmitted by the sender until an MP_CONFIRM is received or the confirmation of options is considered irrelevant because the data contained in the options has already been replaced by newer information.
          </t>
          <t indent="0" pn="section-3.2.1-4"> This can happen, for example, with an MP_PRIO option if the path prioritization
is changed while the previous prioritization has not yet been confirmed. The further processing
of the Multipath Options in the receiving host is not the subject of MP_CONFIRM.</t>
          <t indent="0" pn="section-3.2.1-5">Multipath Options could arrive out of order; therefore, Multipath Options defined in <xref target="ref-mp-option-confirm" format="default" sectionFormat="of" derivedContent="Table 4"/>
            <bcp14>MUST</bcp14> be sent in a DCCP datagram with MP_SEQ (see <xref target="MP_SEQ" format="default" sectionFormat="of" derivedContent="Section 3.2.5"/>). This allows a receiver to identify whether
Multipath Options are associated with obsolete datasets (information carried in the option header) that would otherwise conflict with newer datasets. In the case of MP_ADDADDR or MP_REMOVEADDR, the same dataset is identified based on AddressID, whereas the same dataset for MP_PRIO is identified by the subflow in use. An outdated
multipath Option is detected at the receiver if a previous Multipath Option referring to the same dataset contained a higher sequence number
in the MP_SEQ. An MP_CONFIRM <bcp14>MAY</bcp14> be generated for Multipath Options that are identified as outdated.</t>
          <t indent="0" pn="section-3.2.1-6">Similarly, an MP_CONFIRM could arrive out of order. The associated
MP_SEQ received <bcp14>MUST</bcp14> be echoed to ensure that the most recent Multipath Option is confirmed. This protects from inconsistencies that could occur, e.g., if three MP_PRIO options are sent one after
the other on one path in order to first set the path priority to 0, then to 1, and finally to 0 again. Without an associated
MP_SEQ, a loss of the third MP_PRIO option and a loss of the MP_CONFIRM of the second update and the third update would
cause the sender to incorrectly interpret that the priority value was set to 0 without recognizing that the receiver has applied
priority value 1.</t>
          <t indent="0" pn="section-3.2.1-7">The length of the MP_CONFIRM option and the path over which the option is sent depend on the confirmed Multipath Options and the received
MP_SEQ, which are both copied verbatim and appended as a list of confirmations. The list is structured by first listing the received
MP_SEQ followed by the related Multipath Option or options to confirm. The same rules apply when Multipath Options with different MP_SEQs are confirmed at once.
This could happen if the following are received in short succession: a datagram with MP_PRIO and a first MP_SEQ_1 and another datagram with MP_ADDADDR and a second MP_SEQ_2. In this case, the structure described above is concatenated resulting in MP_SEQ_2 + MP_ADDADDR + MP_SEQ_1 + MP_PRIO.
The order of the confirmed Multipath Options in the list of confirmations <bcp14>MUST</bcp14> reflect the incoming order at the host who sends the MP_CONFIRM, with the most
recent suboption received listed first. This could allow the host receiving the MP_CONFIRM to verify that the options were applied in the correct order
and to take countermeasures if they were not, e.g., if an MP_REMOVEADDR overtakes an MP_ADDADDR that refers to the same dataset.</t>
          <table anchor="ref-mp-option-confirm" align="center" pn="table-4">
            <name slugifiedName="name-multipath-options-requiring">Multipath Options Requiring Confirmation</name>
            <thead>
              <tr>
                <th align="left" colspan="1" rowspan="1">Type</th>
                <th align="left" colspan="1" rowspan="1">Option Length</th>
                <th align="left" colspan="1" rowspan="1">MP_OPT</th>
                <th align="left" colspan="1" rowspan="1">MP_CONFIRM Sending Path</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td align="left" colspan="1" rowspan="1">46</td>
                <td align="left" colspan="1" rowspan="1">var</td>
                <td align="left" colspan="1" rowspan="1">7 =MP_ADDADDR</td>
                <td align="left" colspan="1" rowspan="1">Any available</td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">46</td>
                <td align="left" colspan="1" rowspan="1">4</td>
                <td align="left" colspan="1" rowspan="1">8 =MP_REMOVEADDR</td>
                <td align="left" colspan="1" rowspan="1">Any available</td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">46</td>
                <td align="left" colspan="1" rowspan="1">4</td>
                <td align="left" colspan="1" rowspan="1">9 =MP_PRIO</td>
                <td align="left" colspan="1" rowspan="1">Any available</td>
              </tr>
            </tbody>
          </table>
          <t indent="0" pn="section-3.2.1-9">An example to illustrate the MP-DCCP confirm procedure for the MP_PRIO option is shown in <xref target="ref-mp-dccp-confirm-good" format="default" sectionFormat="of" derivedContent="Figure 7"/>. Host A sends a 
DCCP-Request on path A2-B2 with an MP_PRIO option with value 1 and an associated sequence number of 1. Host B replies on the same path in 
this instance (any path can be used) with a DCCP-Response containing the MP_CONFIRM option and a list containing the original sequence number (1)
	  together with the associated option (MP_PRIO).</t>
          <figure anchor="ref-mp-dccp-confirm-good" align="left" suppress-title="false" pn="figure-7">
            <name slugifiedName="name-example-mp_confirm-procedur">Example MP_CONFIRM Procedure</name>
            <artwork align="left" pn="section-3.2.1-10.1">
          Host A                                     Host B
------------------------                     ------------------------
Address A1    Address A2                     Address B1    Address B2
----------    ----------                     ----------    ----------
     |             |                                   |       |
     |             | DCCP-Request(seqno 1) + MP_PRIO(1)|       |
     |             |------------------------------------------&gt;|
     |             |                                   |       |
     |             | DCCP-Response +                   |       |
     |             |&lt;---- MP_CONFIRM(seqno 1, MP_PRIO) --------|
     |             |                                   |       |</artwork>
          </figure>
          <t indent="0" pn="section-3.2.1-11">A second example that illustrates the same MP-DCCP confirm procedure but where an out-of-date option is also delivered is shown in <xref target="ref-mp-dccp-confirm-outdated" format="default" sectionFormat="of" derivedContent="Figure 8"/>.
Here, the first DCCP-Data is sent from Host A to Host B with option MP_PRIO set to 4. Host A subsequently sends the second DCCP-Data with option MP_PRIO
set to 1. In this case, the delivery of the first MP_PRIO is delayed in the network between Host A and Host B and arrives after the second MP_PRIO. Host B
ignores this second MP_PRIO as the associated sequence number is earlier than the first. Host B sends a DCCP-Ack with sequence number 2 to confirm the receipt of the MP_PRIO(1).</t>
          <figure anchor="ref-mp-dccp-confirm-outdated" align="left" suppress-title="false" pn="figure-8">
            <name slugifiedName="name-example-mp_confirm-procedure">Example MP_CONFIRM Procedure with an Outdated Suboption</name>
            <artwork align="left" pn="section-3.2.1-12.1">
          Host A                                     Host B
------------------------                     ------------------------
Address A1    Address A2                     Address B1    Address B2
----------    ----------                     ----------    ----------
     |             |                                   |       |
     |             | DCCP-Data(seqno 1) +  MP_PRIO(4)  |       |
     |             |------------                       |       |
     |             |            \                      |       |
     |             | DCCP-Data(seqno 2) +  MP_PRIO(1)  |       |
     |             |--------------\---------------------------&gt;|
     |             |               \                   |       |
     |             |                --------------------------&gt;|
     |             |                                   |       |
     |             | DCCP-Ack +                        |       |
     |             |&lt;---- MP_CONFIRM(seqno 2, MP_PRIO) --------|
     |             |                                   |       |</artwork>
          </figure>
        </section>
        <section anchor="MP_JOIN" numbered="true" removeInRFC="false" toc="include" pn="section-3.2.2">
          <name slugifiedName="name-mp_join">MP_JOIN</name>
          <t indent="0" pn="section-3.2.2-1">
The MP_JOIN option is used to add a new subflow to an existing MP-DCCP
connection, and a successful establishment of the first subflow using MP_KEY is <bcp14>REQUIRED</bcp14>.
</t>
          <figure anchor="ref-MP_JOIN" align="left" suppress-title="false" pn="figure-9">
            <name slugifiedName="name-format-of-the-mp_join-subop">Format of the MP_JOIN Suboption</name>
            <artwork align="left" pn="section-3.2.2-2.1">
            1          2          3
 01234567 89012345 67890123 45678901
+--------+--------+--------+--------+
|00101110|00001100|00000001| Addr ID|
+--------+--------+--------+--------+
| Connection Identifier             |
+--------+--------+--------+--------+
| Nonce                             |
+--------+--------+--------+--------+
 Type=46  Length=12 MP_OPT=1</artwork>
          </figure>
          <t indent="0" pn="section-3.2.2-3">
The CI is the one from the peer host,
which was previously exchanged with the MP_KEY option.
MP_HMAC <bcp14>MUST</bcp14> be set when using MP_JOIN within a DCCP-Response packet; see
<xref target="MP_HMAC" format="default" sectionFormat="of" derivedContent="Section 3.2.6"/> for details. Similar to the setup of the first subflow, MP_JOIN also exchanges the Multipath Capable Feature MP_CAPABLE as described in <xref target="mp_capable" format="default" sectionFormat="of" derivedContent="Section 3.1"/>. This procedure includes the DCCP Confirm principle and thus ensures a reliable exchange of the MP_JOIN in accordance with <xref target="RFC4340" sectionFormat="of" section="6.6.4" format="default" derivedLink="https://rfc-editor.org/rfc/rfc4340#section-6.6.4" derivedContent="RFC4340"/>.</t>
          <t indent="0" pn="section-3.2.2-4">The MP_JOIN option includes an "Addr ID" (Address ID) generated by the sender of the option, which is used to identify the source
address of this packet, even if the IP header was changed in
transit by a middlebox.  The value of this field is generated
by the sender and <bcp14>MUST</bcp14> map uniquely to a source IP address for the
sending host.  The Address ID allows address removal (<xref target="MP_REMOVEADDR" format="default" sectionFormat="of" derivedContent="Section 3.2.9"/>)
without the need to know the source address at the receiver,
thus allowing address removal through NATs.  The Address ID also
allows correlation between new subflow setup attempts and address
signaling (<xref target="MP_ADDADDR" format="default" sectionFormat="of" derivedContent="Section 3.2.8"/>), to prevent setting up duplicate subflows
on the same path, if an MP_JOIN and MP_ADDADDR are sent at the same
time.</t>
          <t indent="0" pn="section-3.2.2-5">The Address IDs of the subflow used in the initial DCCP Request/Response exchange of
the first subflow in the connection are implicit and have the value
zero.  A host <bcp14>MUST</bcp14> store the mappings between Address IDs and
addresses for both 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. An Address ID <bcp14>MUST</bcp14> always be unique
over the lifetime of a subflow and can only be reassigned if sender and
receiver no longer have them in use.</t>
          <t indent="0" pn="section-3.2.2-6">The Nonce is a 32-bit random value locally generated for every MP_JOIN option.

Together with the derived key from both hosts' Key Data (as described in <xref target="MP_KEY" format="default" sectionFormat="of" derivedContent="Section 3.2.4"/>), the Nonce value builds the basis to calculate the Hash-based Message Authentication Code (HMAC) used in the handshake process (as described in <xref target="handshaking" format="default" sectionFormat="of" derivedContent="Section 3.3"/>) to avoid replay attacks.</t>
          <t indent="0" pn="section-3.2.2-7">If the CI cannot be verified by the receiving host during a handshake negotiation, 
the new subflow <bcp14>MUST</bcp14> be closed, as specified in <xref target="fallback" format="default" sectionFormat="of" derivedContent="Section 3.6"/>.</t>
        </section>
        <section anchor="MP_FAST_CLOSE" numbered="true" removeInRFC="false" toc="include" pn="section-3.2.3">
          <name slugifiedName="name-mp_fast_close">MP_FAST_CLOSE</name>
          <t indent="0" pn="section-3.2.3-1">DCCP can send a Close or Reset signal to abruptly close a
connection.  Using MP-DCCP, a regular Close or Reset only has the scope of the
subflow over which a signal was received. 
As such, it will only close the subflow and does not
affect other remaining subflows or the MP-DCCP connection (unless it is the last
subflow).
This permits break-before-make handover between
subflows.</t>
          <t indent="0" pn="section-3.2.3-2">In order to provide an MP-DCCP-level
"reset" and thus allow the abrupt closure of the MP-DCCP connection, the MP_FAST_CLOSE suboption can be used.</t>
          <figure anchor="ref-MP_FAST_CLOSE" align="left" suppress-title="false" pn="figure-10">
            <name slugifiedName="name-format-of-the-mp_fast_close">Format of the MP_FAST_CLOSE Suboption</name>
            <artwork align="left" pn="section-3.2.3-3.1">
            1          2          3
 01234567 89012345 67890123 45678901 23456789
+--------+--------+--------+--------+--------+
|00101110|  var   |00000010| Key Data ...
+--------+--------+--------+--------+--------+
 Type=46   Length  MP_OPT=2</artwork>
          </figure>
          <t indent="0" pn="section-3.2.3-4">When Host A wants to abruptly close an MP-DCCP connection with Host B, it will send out the MP_FAST_CLOSE. The MP_FAST_CLOSE suboption <bcp14>MUST</bcp14> be sent from Host A on all subflows 
using a DCCP-Reset packet with Reset Code 13. The requirement to send the MP_FAST_CLOSE on all subflows increases the probability that Host B will receive the MP_FAST_CLOSE to take the same action. To protect from an unauthorized shutdown of an MP-DCCP connection, 
the selected Key Data of the peer host during the handshake procedure 
is carried by the MP_FAST_CLOSE option.</t>
          <t indent="0" pn="section-3.2.3-5">After sending the MP_FAST_CLOSE on all subflows, Host A <bcp14>MUST</bcp14> tear down all subflows, 
and the MP-DCCP connection immediately terminates.</t>
          <t indent="0" pn="section-3.2.3-6">Upon reception of the first MP_FAST_CLOSE with successfully validated 
Key Data, Host B will send a DCCP-Reset packet response on all subflows to 
Host A with Reset Code 13 to clean potential middlebox states. 
Host B <bcp14>MUST</bcp14> then tear down all subflows and terminate the MP-DCCP connection.</t>
        </section>
        <section anchor="MP_KEY" numbered="true" removeInRFC="false" toc="include" pn="section-3.2.4">
          <name slugifiedName="name-mp_key">MP_KEY</name>
          <t indent="0" pn="section-3.2.4-1">
MP-DCCP protects against some on-path attacker as further outlined in <xref target="security" format="default" sectionFormat="of" derivedContent="Section 4"/>. The basis of this protection is laid by an initial exchange of keys during the MP-DCCP connection setup, for which MP_KEY is introduced. The basis of this protection is laid by an initial exchange of keys during the MP-DCCP connection setup, for which MP_KEY is introduced.
</t>
          <figure anchor="ref-MP_KEY" align="left" suppress-title="false" pn="figure-11">
            <name slugifiedName="name-format-of-the-mp_key-subopt">Format of the MP_KEY Suboption</name>
            <artwork align="left" pn="section-3.2.4-2.1">
                     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
+---------------+---------------+---------------+---------------+
|0 0 1 0 1 1 1 0|      var      |0 0 0 0 0 0 1 1|     resvd     |
+---------------+---------------+---------------+---------------+
|                     Connection Identifier                     |
+---------------+---------------+---------------+---------------+
|  Key Type (1) |  Key Data (1) |  Key Type (2) |  Key Data (2) |
+---------------+---------------+---------------+---------------+
|  Key Type (3) | ...
+---------------+---------------+
    Type=46          Length         MP_OPT=3</artwork>
          </figure>
          <t indent="0" pn="section-3.2.4-3">The MP_KEY suboption is used to exchange a CI and key material between
hosts (Host A and Host B) for a given connection.
The CI is a unique number in the host for each multipath connection and is generated for inclusion in the first exchange of a connection with MP_KEY.  With the CI, it is possible to connect other DCCP subflows to an MP-DCCP connection with MP_JOIN (<xref target="MP_JOIN" format="default" sectionFormat="of" derivedContent="Section 3.2.2"/>). Its size of 32 bits also defines the maximum number of simultaneous MP-DCCP connections in a host to 2<sup>32</sup>.
According to the Key-related elements of the MP_KEY suboption, the Length varies between 17 and 73 bytes for a single-key message and up to
82 bytes when all specified Key Types 0 and 255 are provided. The Key Type field 
specifies the type of the following Key Data. 
	  The set of Key Types are shown in <xref target="ref-key-type-list" format="default" sectionFormat="of" derivedContent="Table 5"/>.</t>
          <table anchor="ref-key-type-list" align="center" pn="table-5">
            <name slugifiedName="name-mp_key-key-types">MP_KEY Key Types</name>
            <thead>
              <tr>
                <th align="left" colspan="1" rowspan="1">Key Type</th>
                <th align="left" colspan="1" rowspan="1">Key Length (bytes)</th>
                <th align="left" colspan="1" rowspan="1">Meaning</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td align="left" colspan="1" rowspan="1">0 =Plain Text</td>
                <td align="left" colspan="1" rowspan="1">8</td>
                <td align="left" colspan="1" rowspan="1">Plain text Key</td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">1-254</td>
                <td align="left" colspan="1" rowspan="1"> </td>
                <td align="left" colspan="1" rowspan="1">(available for future Key Types)</td>
              </tr>
              <tr>
                <td align="left" colspan="1" rowspan="1">255 =Experimental</td>
                <td align="left" colspan="1" rowspan="1">64</td>
                <td align="left" colspan="1" rowspan="1">For private use only</td>
              </tr>
            </tbody>
          </table>
          <dl newline="true" spacing="normal" indent="3" pn="section-3.2.4-5">
            <dt pn="section-3.2.4-5.1">Plain Text:</dt>
            <dd pn="section-3.2.4-5.2">
              <t indent="0" pn="section-3.2.4-5.2.1">Key Data is exchanged in plain text between hosts (Host A and
            Host B), and the respective key parts (KeyA and KeyB) are used by
            each host to generate the derived key (d-key) by concatenating the
            two parts with the local key in front. That is,</t>
              <dl spacing="normal" indent="3" newline="false" pn="section-3.2.4-5.2.2">
                <dt pn="section-3.2.4-5.2.2.1">Host A:</dt>
                <dd pn="section-3.2.4-5.2.2.2">d-keyA=(KeyA+KeyB)</dd>
                <dt pn="section-3.2.4-5.2.2.3">Host B:</dt>
                <dd pn="section-3.2.4-5.2.2.4">d-keyB=(KeyB+KeyA)</dd>
              </dl>
            </dd>
            <dt pn="section-3.2.4-5.3">Experimental:</dt>
            <dd pn="section-3.2.4-5.4">
              <t indent="0" pn="section-3.2.4-5.4.1">This Key Type allows the use of other Key Data and can be used
            to validate other key exchange mechanisms for a possible future
            specification.</t>
            </dd>
          </dl>
          <t indent="0" pn="section-3.2.4-6">Multiple keys are only permitted in the DCCP-Request message
of the handshake procedure for the first subflow. This allows the hosts to agree
on a single Key Type to be used, as described in <xref target="handshaking" format="default" sectionFormat="of" derivedContent="Section 3.3"/></t>
          <t indent="0" pn="section-3.2.4-7">It is possible that not all hosts will support all Key Types, and this specification does not
recommend or enforce the announcement of any particular Key Type within the MP_KEY option as this could have security
implications. However, at least Key Type 0 (Plain Text) <bcp14>MUST</bcp14> be supported for interoperability tests
in implementations of MP-DCCP. If the Key Type cannot be agreed in the handshake procedure, the MP-DCCP connection
<bcp14>MUST</bcp14> fall back to not using MP-DCCP, as indicated in <xref target="fallback" format="default" sectionFormat="of" derivedContent="Section 3.6"/>.</t>
        </section>
        <section anchor="MP_SEQ" numbered="true" removeInRFC="false" toc="include" pn="section-3.2.5">
          <name slugifiedName="name-mp_seq">MP_SEQ</name>
          <t indent="0" pn="section-3.2.5-1">
DCCP <xref target="RFC4340" format="default" sectionFormat="of" derivedContent="RFC4340"/> defines a packet sequencing scheme that continues to apply to the individual DCCP subflows within an MP-DCCP connection. However, for the operation of MP-DCPP, the order of packets within an MP-DCCP connection <bcp14>MUST</bcp14> be known before assigning packets to subflows to apply the received Multipath Options in the correct order or to recognize whether delayed Multipath Options are obsolete. Therefore, MP_SEQ is introduced and can also be used to reorder data packets on the receiver side.
          </t>
          <figure anchor="ref-MP_SEQ" align="left" suppress-title="false" pn="figure-12">
            <name slugifiedName="name-format-of-the-mp_seq-subopt">Format of the MP_SEQ Suboption</name>
            <artwork align="left" pn="section-3.2.5-2.1">
            1          2          3           4          5
 01234567 89012345 67890123 45678901 23456789 01234567 89012345
+--------+--------+--------+--------+--------+--------+--------+
|00101110|00001001|00000100| Multipath Sequence Number
+--------+--------+--------+--------+--------+--------+--------+
                  |
+--------+--------+
 Type=46  Length=9 MP_OPT=4</artwork>
          </figure>
          <t indent="0" pn="section-3.2.5-3">The MP_SEQ suboption is used for end-to-end 48-bit datagram-based sequence
numbers of an MP-DCCP connection. The initial data sequence
number (IDSN) <bcp14>SHOULD</bcp14> be set randomly <xref target="RFC4086" format="default" sectionFormat="of" derivedContent="RFC4086"/>. As with the standard DCCP
sequence number, the data sequence number should not start at zero but at
a random value to make blind session hijacking more difficult; see also
<xref target="RFC4340" sectionFormat="of" section="7.2" format="default" derivedLink="https://rfc-editor.org/rfc/rfc4340#section-7.2" derivedContent="RFC4340"/>.</t>
          <t indent="0" pn="section-3.2.5-4">The MP_SEQ number space is
independent of the path individual sequence number space and <bcp14>MUST</bcp14> be
sent with all DCCP-Data and DCCP-DataACK packets.</t>
          <t indent="0" pn="section-3.2.5-5">When the sequence number space is exhausted, the sequence number <bcp14>MUST</bcp14>
be wrapped. <xref target="RFC7323" format="default" sectionFormat="of" derivedContent="RFC7323"/> provides guidance on selecting an appropriately
sized sequence number space according to the Maximum Segment Lifetime (MSL) of
TCP. 64 bits is the recommended size for TCP to avoid the sequence number
space going through within the segment lifetime. For DCCP, the MSL is the same as that of TCP as specified in <xref section="3.4" target="RFC4340" format="default" sectionFormat="of" derivedLink="https://rfc-editor.org/rfc/rfc4340#section-3.4" derivedContent="RFC4340"/>.
Compared to TCP, the sequence number for DCCP is incremented
per packet rather than per byte transmitted. For this reason, the 48 bits
chosen in MP_SEQ are considered sufficiently large per the current
globally routable maximum packet size (MPS) of 1500 bytes, which corresponds to
roughly 375 pebibytes (PiBs) of data within the sequence number space.</t>
        </section>
        <section anchor="MP_HMAC" numbered="true" removeInRFC="false" toc="include" pn="section-3.2.6">
          <name slugifiedName="name-mp_hmac">MP_HMAC</name>
          <t indent="0" pn="section-3.2.6-1">
 MP-DCCP protects against some on-path attacker as further outlined in <xref target="security" format="default" sectionFormat="of" derivedContent="Section 4"/>. Once an MP-DCCP connection has been established, the MP_HMAC option introduced here provides further protection based on the key material exchanged with MP_KEY when the connection is established.
          </t>
          <figure anchor="ref-MP_HMAC" align="left" suppress-title="false" pn="figure-13">
            <name slugifiedName="name-format-of-the-mp_hmac-subop">Format of the MP_HMAC Suboption</name>
            <artwork align="left" pn="section-3.2.6-2.1">
            1          2          3           4
 01234567 89012345 67890123 45678901 23456789 01234567
+--------+--------+--------+--------+--------+--------+
|00101110|00010111|00000101| HMAC-SHA256 (20 bytes) ...
+--------+--------+--------+--------+--------+--------+
 Type=46  Length=23 MP_OPT=5</artwork>
          </figure>
          <t indent="0" pn="section-3.2.6-3">The MP_HMAC suboption is used to provide authentication for the
	  MP_ADDADDR and MP_REMOVEADDR suboptions. In addition, it provides
authentication for subflows joining an existing MP_DCCP connection,
as described in the second and third step of the handshake of a
subsequent subflow in <xref target="handshaking" format="default" sectionFormat="of" derivedContent="Section 3.3"/>. For this specification of MP-DCCP,
the HMAC code is generated according to <xref target="RFC2104" format="default" sectionFormat="of" derivedContent="RFC2104"/> in combination
with the SHA-256 hash algorithm described in <xref target="RFC6234" format="default" sectionFormat="of" derivedContent="RFC6234"/>, with the
output in big-endian format truncated to the leftmost 160 bits (20 bytes). It is possible
that other versions of MP-DCCP will define other hash algorithms in the future.</t>
          <t indent="0" pn="section-3.2.6-4">The "Key" used for the HMAC computation is the derived key (d-keyA for Host A or d-KeyB for Host B)
described in <xref target="MP_KEY" format="default" sectionFormat="of" derivedContent="Section 3.2.4"/>, while the HMAC "Message" for MP_JOIN, MP_ADDADDR, and MP_REMOVEADDR must be calculated in both hosts in order to protect the Multipath Option when sending and to validate the Multipath Option when receiving; it is a concatenation of:</t>
          <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-3.2.6-5">
            <li pn="section-3.2.6-5.1">
              <t indent="0" pn="section-3.2.6-5.1.1">For MP_JOIN: The Nonces of the MP_JOIN messages for which
              authentication shall be performed. Depending on whether Host A
              or Host B performs the HMAC-SHA256 calculation, it is carried
              out as follows: </t>
              <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-3.2.6-5.1.2">
                <li pn="section-3.2.6-5.1.2.1">
                  <t indent="0" pn="section-3.2.6-5.1.2.1.1">MP_HMAC(A) = HMAC-SHA256(Key=d-keyA, Msg=RA+RB)</t>
                </li>
                <li pn="section-3.2.6-5.1.2.2">
                  <t indent="0" pn="section-3.2.6-5.1.2.2.1">MP_HMAC(B) = HMAC-SHA256(Key=d-keyB, Msg=RB+RA)</t>
                </li>
              </ul>
            </li>
          </ul>
          <t indent="0" pn="section-3.2.6-6">A usage example is shown in <xref target="ref-mp-dccp-handshaking" format="default" sectionFormat="of" derivedContent="Figure 21"/>.</t>
          <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-3.2.6-7">
            <li pn="section-3.2.6-7.1">
              <t indent="0" pn="section-3.2.6-7.1.1">For MP_ADDADDR: The Address ID and Nonce with an associated IP
              address and a port, if defined; otherwise, 2 bytes of value 0. The IP
              address and port <bcp14>MUST</bcp14> be used in network byte
              order (NBO). Depending on whether Host A or Host B performs the
              HMAC-SHA256 calculation, it is carried out as follows: </t>
              <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-3.2.6-7.1.2">
                <li pn="section-3.2.6-7.1.2.1">
                  <t indent="0" pn="section-3.2.6-7.1.2.1.1">MP_HMAC(A) = HMAC-SHA256(Key=d-keyA, Msg=Address
                  ID+Nonce+NBO(IP)+NBO(Port))</t>
                </li>
                <li pn="section-3.2.6-7.1.2.2">
                  <t indent="0" pn="section-3.2.6-7.1.2.2.1">MP_HMAC(B) = HMAC-SHA256(Key=d-keyB, Msg=Address
                  ID+Nonce+NBO(IP)+NBO(Port))</t>
                </li>
              </ul>
            </li>
            <li pn="section-3.2.6-7.2">
              <t indent="0" pn="section-3.2.6-7.2.1">For MP_REMOVEADDR: Solely the Address ID.  Depending on
              whether Host A or Host B performs the HMAC-SHA256 calculation,
              it is carried out as follows: </t>
              <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-3.2.6-7.2.2">
                <li pn="section-3.2.6-7.2.2.1">
                  <t indent="0" pn="section-3.2.6-7.2.2.1.1">MP_HMAC(A) = HMAC-SHA256(Key=d-keyA, Msg=Address ID+Nonce)</t>
                </li>
                <li pn="section-3.2.6-7.2.2.2">
                  <t indent="0" pn="section-3.2.6-7.2.2.2.1">MP_HMAC(B) = HMAC-SHA256(Key=d-keyB, Msg=Address ID+Nonce)</t>
                </li>
              </ul>
            </li>
          </ul>
          <t indent="0" pn="section-3.2.6-8">MP_JOIN, MP_ADDADDR, and MP_REMOVEADDR can coexist or be used multiple times
within a single DCCP packet. All these Multipath Options require an individual
MP_HMAC option. This ensures that the MP_HMAC is correctly associated.
Otherwise, the receiver cannot validate multiple MP_JOIN, MP_ADDADDR, or
MP_REMOVEADDR options. Therefore, an MP_HMAC <bcp14>MUST</bcp14> directly follow its associated Multipath
Option. In the likely case of sending an MP_JOIN together with an MP_ADDADDR, this
results in concatenating MP_JOIN + MP_HMAC_1 + MP_ADDADDR + MP_HMAC_2, whereas the
first MP_HMAC_1 is associated with the MP_JOIN and the second MP_HMAC_2 is associated with the
MP_ADDADDR suboption.</t>
          <t indent="0" pn="section-3.2.6-9">On the receiver side, the HMAC validation of the suboptions <bcp14>MUST</bcp14> be carried out according to
the sending sequence in which the associated MP_HMAC follows a suboption. If the suboption
cannot be validated by a receiving host because the HMAC validation fails (HMAC is wrong or missing), the subsequent handling depends
on which suboption was being verified. If the suboption to be authenticated was either
MP_ADDADDR or MP_REMOVEADDR, the receiving host <bcp14>MUST</bcp14> silently ignore it (see Sections <xref target="MP_ADDADDR" format="counter" sectionFormat="of" derivedContent="3.2.8"/> and <xref target="MP_REMOVEADDR" format="counter" sectionFormat="of" derivedContent="3.2.9"/>). 
If the suboption to be authenticated was MP_JOIN, the subflow <bcp14>MUST</bcp14> be closed (see <xref target="fallback" format="default" sectionFormat="of" derivedContent="Section 3.6"/>).</t>
          <t indent="0" pn="section-3.2.6-10">In the event that an MP_HMAC cannot be associated with a suboption, this MP_HMAC <bcp14>MUST</bcp14> be ignored, unless
it is a single MP_HMAC that was sent in a DCCP-Ack corresponding to a DCCP response packet with MP_JOIN (see the penultimate arrow in <xref target="ref-mp-dccp-handshaking" format="default" sectionFormat="of" derivedContent="Figure 21"/>).</t>
        </section>
        <section anchor="MP_RTT" numbered="true" removeInRFC="false" toc="include" pn="section-3.2.7">
          <name slugifiedName="name-mp_rtt">MP_RTT</name>
          <t indent="0" pn="section-3.2.7-1">The MP_RTT suboption is used to transmit RTT values and Age (represented in milliseconds) that belong to the path over which this information is transmitted. This information is useful for the receiving host to calculate the RTT difference between the subflows and to estimate whether missing data has been lost.</t>
          <figure anchor="ref-MP_RTT" align="left" suppress-title="false" pn="figure-14">
            <name slugifiedName="name-format-of-the-mp_rtt-subopt">Format of the MP_RTT Suboption</name>
            <artwork align="left" pn="section-3.2.7-2.1">
            1          2          3           4          5
 01234567 89012345 67890123 45678901 23456789 01234567 89012345
+--------+--------+--------+--------+--------+--------+--------+
|00101110|00001100|00000110|RTT Type| RTT
+--------+--------+--------+--------+--------+--------+--------+
         | Age                               |
+--------+--------+--------+--------+--------+
 Type=46  Length=12 MP_OPT=6</artwork>
          </figure>
          <t indent="0" pn="section-3.2.7-3">The RTT and Age information is a 32-bit integer. This covers a period of
approximately 1193 hours.</t>
          <t indent="0" pn="section-3.2.7-4">The Field RTT type indicates the type of RTT estimation, according to the following description:</t>
          <dl newline="true" indent="3" spacing="normal" pn="section-3.2.7-5">
            <dt pn="section-3.2.7-5.1">Raw RTT (=0)</dt>
            <dd pn="section-3.2.7-5.2">
              <t indent="0" pn="section-3.2.7-5.2.1">Raw RTT value of the last Datagram round trip.</t>
            </dd>
            <dt pn="section-3.2.7-5.3">Min RTT (=1)</dt>
            <dd pn="section-3.2.7-5.4">
              <t indent="0" pn="section-3.2.7-5.4.1">Min RTT value over a given period.</t>
            </dd>
            <dt pn="section-3.2.7-5.5">Max RTT (=2)</dt>
            <dd pn="section-3.2.7-5.6">
              <t indent="0" pn="section-3.2.7-5.6.1">Max RTT value over a given period.</t>
            </dd>
            <dt pn="section-3.2.7-5.7">Smooth RTT (=3)</dt>
            <dd pn="section-3.2.7-5.8">
              <t indent="0" pn="section-3.2.7-5.8.1">Averaged RTT value over a given period.</t>
            </dd>
          </dl>
          <t indent="0" pn="section-3.2.7-6">Each CCID specifies the algorithms and period applied for their corresponding RTT estimations. The availability of the above-described types, to be used in the MP_RTT option, depends on the CCID implementation in place.</t>
          <dl newline="false" indent="3" spacing="normal" pn="section-3.2.7-7">
            <dt pn="section-3.2.7-7.1">Age:</dt>
            <dd pn="section-3.2.7-7.2">
              <t indent="0" pn="section-3.2.7-7.2.1">The Age parameter defines the time difference between now --
              the creation of the MP_RTT option -- and the conducted RTT
              measurement in milliseconds. If no previous measurement exists,
              e.g., when initialized, the value is 0.</t>
            </dd>
          </dl>
          <t indent="0" pn="section-3.2.7-8">An example of a flow showing  the exchange of path individual 
RTT information is provided in
<xref target="ref-MP_RTT_example" format="default" sectionFormat="of" derivedContent="Figure 15"/>. 
RTT1 refers to the first path and RTT2 to the second path. The
RTT values could be extracted from the sender's congestion control algorithm and are conveyed to the receiving host using the MP_RTT suboption. With the reception of RTT1
and RTT2, the receiver is able to calculate the path_delta that corresponds to
the absolute difference of both values.
In the case where the path individual RTTs are symmetric in the down-link and up-link directions and there is no jitter, packets with missing sequence number MP_SEQ, e.g., in a reordering process, can be assumed lost after path_delta/2.</t>
          <figure anchor="ref-MP_RTT_example" align="left" suppress-title="false" pn="figure-15">
            <name slugifiedName="name-exemplary-flow-of-mp_rtt-ex">Exemplary Flow of MP_RTT Exchange and Usage</name>
            <artwork align="left" pn="section-3.2.7-9.1">
MP-DCCP                   MP-DCCP
Sender                    Receiver
+--------+  MP_RTT(RTT1)  +-------------+
|   RTT1 |----------------|             |
|        |                | path_delta= |
|        |  MP_RTT(RTT2)  | |RTT1-RTT2| |
|   RTT2 |----------------|             |
+--------+                +-------------+</artwork>
          </figure>
        </section>
        <section anchor="MP_ADDADDR" numbered="true" removeInRFC="false" toc="include" pn="section-3.2.8">
          <name slugifiedName="name-mp_addaddr">MP_ADDADDR</name>
          <t indent="0" pn="section-3.2.8-1">The MP_ADDADDR suboption announces additional addresses (and, optionally,
port numbers) by which a host can be reached. This can be sent at any
time during an existing MP-DCCP connection, when the sender wishes to
enable multiple paths and/or when additional paths become available.
Multiple instances of this suboption within a packet 
can simultaneously advertise new addresses.</t>
          <t indent="0" pn="section-3.2.8-2">The Length is variable depending on the address family (IPv4 or IPv6) and whether a port number is
used. This field is in the range between 12 and 26 bytes.</t>
          <t indent="0" pn="section-3.2.8-3">The Nonce is a 32-bit random value that is generated locally for
each MP_ADDADDR option and is used in the HMAC calculation process
to prevent replay attacks.</t>
          <t indent="0" pn="section-3.2.8-4">The final 2 bytes optionally specify the DCCP port number to
use, 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 used for the initial subflow (e.g., port 80
remains port 80 on all subflows, as does the ephemeral port at the
client), there could be cases (such as port-based load balancing) where
the explicit specification of a different port is required.  If no
port is specified, the receiving host <bcp14>MUST</bcp14> assume that any attempt to
connect to the specified address uses the port already used by the
subflow on which the MP_ADDADDR signal was sent.</t>
          <t indent="0" pn="section-3.2.8-5">Along with the MP_ADDADDR option, an MP_HMAC option <bcp14>MUST</bcp14> be sent for
authentication. The truncated HMAC parameter present in this MP_HMAC
option is the leftmost 20 bytes of an HMAC, negotiated and calculated
as described in <xref target="MP_HMAC" format="default" sectionFormat="of" derivedContent="Section 3.2.6"/>. Similar to MP_JOIN,
the key for the HMAC algorithm will be d-KeyA when the message is transmitted
by Host A and d-KeyB when transmitted by Host B.  These are the keys that were exchanged and
selected in the original MP_KEY handshake. The message for the HMAC is
the Address ID, Nonce, IP address, and port number that precede the HMAC in the
MP_ADDADDR option.  If the port number is not present in the MP_ADDADDR option,
the HMAC message will include 2 bytes of value zero.
The rationale for the HMAC is to prevent unauthorized entities from
injecting MP_ADDADDR signals in an attempt to hijack a connection.
Additionally, note that 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 MP_ADDADDR option for which it
cannot validate the HMAC, it <bcp14>MUST</bcp14> silently ignore the option.</t>
          <t indent="0" pn="section-3.2.8-6">The presence of an MP_SEQ (<xref target="MP_SEQ" format="default" sectionFormat="of" derivedContent="Section 3.2.5"/>) <bcp14>MUST</bcp14> be ensured in a DCCP datagram
in which MP_ADDADDR is sent, as described in <xref target="MP_CONFIRM" format="default" sectionFormat="of" derivedContent="Section 3.2.1"/>.</t>
          <figure anchor="ref-MP_ADDADDR" align="left" suppress-title="false" pn="figure-16">
            <name slugifiedName="name-format-of-the-mp_addaddr-su">Format of the MP_ADDADDR Suboption</name>
            <artwork align="left" pn="section-3.2.8-7.1">
                     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
+---------------+---------------+-------+-------+---------------+
|0 0 1 0 1 1 1 0|      var      |0 0 0 0 0 1 1 1|  Address ID   |
+---------------+---------------+-------+-------+---------------+
|                             Nonce                             |
+-------------------------------+-------------------------------+
|          Address (IPv4 - 4 bytes / IPv6 - 16 bytes)           |
+-------------------------------+-------------------------------+
|   Port (2 bytes, optional)    | + MP_HMAC option
+-------------------------------+
     Type=46         Length         MP_OPT=7</artwork>
          </figure>
          <t indent="0" pn="section-3.2.8-8">Each address has an Address ID that could be used for uniquely
identifying the address within a connection for address removal.
Each host maintains a list of unique Address IDs, and it manages these as it wishes. The
Address ID is also used to identify MP_JOIN options (see <xref target="MP_JOIN" format="default" sectionFormat="of" derivedContent="Section 3.2.2"/>)
relating to the same address, even when address translators are in use.
The Address ID <bcp14>MUST</bcp14> uniquely identify the address for the sender of the
option (within the scope of the connection); the mechanism for
allocating such IDs is implementation specific.</t>
          <t indent="0" pn="section-3.2.8-9">All Address IDs learned via either MP_JOIN or MP_ADDADDR can be stored
by the receiver in a data structure that gathers all the
Address-ID-to-address mappings for a connection (identified by a CI
pair). In this way, there is a stored mapping between the Address ID,
the observed source address, and the CI pair for future processing of control
information for a connection. Note that an implementation
<bcp14>MAY</bcp14> discard incoming address advertisements. Reasons for this are, for example:</t>
          <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-3.2.8-10">
            <li pn="section-3.2.8-10.1">
              <t indent="0" pn="section-3.2.8-10.1.1">to avoid the required mapping state, or</t>
            </li>
            <li pn="section-3.2.8-10.2">
              <t indent="0" pn="section-3.2.8-10.2.1">because advertised addresses are of no use to it.</t>
            </li>
          </ul>
          <t indent="0" pn="section-3.2.8-11">Possible scenarios in which this applies are the lack of resources to store
a mapping or when IPv6 addresses are advertised even though the host only
supports IPv4. Therefore, a host <bcp14>MUST</bcp14> treat address announcements as soft state.
However, a sender <bcp14>MAY</bcp14> choose to update the announcements periodically to
overcome temporary limitations.</t>
          <t indent="0" pn="section-3.2.8-12">A host
<bcp14>MAY</bcp14> advertise private addresses, e.g., because there is a 
NAT on the path.  It is
desirable to allow this as there could be cases where both hosts
have additional interfaces on the same private network. The advertisement
of broadcast or multicast IP addresses <bcp14>MUST</bcp14> be ignored by the recipient of
this option, as it is not permitted according to the unicast principle of the
basic DCCP.</t>
          <t indent="0" pn="section-3.2.8-13">The MP_JOIN handshake used to
create a new subflow (<xref target="MP_JOIN" format="default" sectionFormat="of" derivedContent="Section 3.2.2"/>) provides mechanisms to minimize
security risks.  The MP_JOIN message contains a 32-bit CI that
uniquely identifies a connection to the receiving host. If the
CI is unknown, the host <bcp14>MUST</bcp14> send a DCCP-Reset.</t>
          <t indent="0" pn="section-3.2.8-14">Further security considerations around the issue of
MP_ADDADDR messages that accidentally misdirect, or maliciously direct,
new MP_JOIN attempts are discussed in <xref target="security" format="default" sectionFormat="of" derivedContent="Section 4"/>.
If a sending host of an MP_ADDADDR knows that no incoming subflows can
be established at a particular address, an MP_ADDADDR <bcp14>MUST NOT</bcp14>
announce that address unless the sending host has new knowledge about
the possibility to do so. This information can be obtained from local
firewall or routing settings, knowledge about availability of an external
NAT or a firewall, or connectivity checks performed by the
host/application.</t>
          <t indent="0" pn="section-3.2.8-15">The reception of an MP_ADDADDR message is acknowledged using MP_CONFIRM
(<xref target="MP_CONFIRM" format="default" sectionFormat="of" derivedContent="Section 3.2.1"/>). This ensures a reliable exchange of address
information.</t>
          <t indent="0" pn="section-3.2.8-16">A host that receives an MP_ADDADDR but finds
that the IP address and port number is unsuccessful at connection setup <bcp14>SHOULD NOT</bcp14> perform
further connection attempts to this address/port combination for this
connection to save resources. However, if a sender wishes to trigger a new incoming
connection attempt on a previously advertised address/port combination, they 
can refresh the MP_ADDADDR information by sending the option again.</t>
          <t indent="0" pn="section-3.2.8-17">A host <bcp14>MAY</bcp14> send an MP_ADDADDR message with an already-assigned Address
ID using the IP address previously assigned to this Address ID. The new
MP_ADDADDR could have the same port number or a different port number. The
receiver <bcp14>MUST</bcp14> silently ignore the MP_ADDADDR if the IP address is not the
same as that previously assigned to this Address ID. A host wishing to
replace an existing Address ID <bcp14>MUST</bcp14> first remove the existing one
(<xref target="MP_REMOVEADDR" format="default" sectionFormat="of" derivedContent="Section 3.2.9"/>).</t>
        </section>
        <section anchor="MP_REMOVEADDR" numbered="true" removeInRFC="false" toc="include" pn="section-3.2.9">
          <name slugifiedName="name-mp_removeaddr">MP_REMOVEADDR</name>
          <t indent="0" pn="section-3.2.9-1">If, during the lifetime of an MP-DCCP connection, a previously announced
address becomes invalid (e.g., if an interface disappears), the
affected host <bcp14>SHOULD</bcp14> announce this. The peer can remove a previously 
added address with an Address ID from a connection
using the Remove Address (MP_REMOVEADDR) suboption. This
will terminate any subflows currently using that address.</t>
          <t indent="0" pn="section-3.2.9-2">MP_REMOVEADDR is only used to close already-established subflows that
have an invalid address. Functional flows with a valid address <bcp14>MUST</bcp14> be
closed with a DCCP Close exchange (as with regular DCCP) instead of
using MP_REMOVEADDR. For more information see <xref target="closing" format="default" sectionFormat="of" derivedContent="Section 3.5"/>.</t>
          <t indent="0" pn="section-3.2.9-3">The Nonce is a 32-bit random value that is generated locally for
each MP_REMOVEADDR option and is used in the HMAC calculation process
to prevent replay attacks.</t>
          <t indent="0" pn="section-3.2.9-4">Along with the MP_REMOVEADDR suboption, an MP_HMAC option <bcp14>MUST</bcp14> be sent for
authentication. The truncated HMAC parameter present in this MP_HMAC
option is the leftmost 20 bytes of an HMAC, negotiated and calculated
as described in <xref target="MP_HMAC" format="default" sectionFormat="of" derivedContent="Section 3.2.6"/>. Similar to MP_JOIN,
the key for the HMAC algorithm will be d-KeyA when the message is transmitted by Host A and
d-KeyB when transmitted by Host B.  These are the keys that were exchanged and
selected in the original MP_KEY handshake. The message for the HMAC is
the Address ID.</t>
          <t indent="0" pn="section-3.2.9-5">The rationale for using an HMAC is to prevent unauthorized entities from
injecting MP_REMOVEADDR signals in an attempt to hijack a connection.
Additionally, note that the presence of this HMAC prevents the
address from being modified in flight unless the key is known by an
intermediary.  If a host receives an MP_REMOVEADDR option for which it
cannot validate the HMAC, it <bcp14>MUST</bcp14> silently ignore the option.</t>
          <t indent="0" pn="section-3.2.9-6">A receiver <bcp14>MUST</bcp14> include an MP_SEQ (<xref target="MP_SEQ" format="default" sectionFormat="of" derivedContent="Section 3.2.5"/>) in a DCCP datagram that sends
an MP_REMOVEADDR. Further details are given in <xref target="MP_CONFIRM" format="default" sectionFormat="of" derivedContent="Section 3.2.1"/>.</t>
          <t indent="0" pn="section-3.2.9-7">The reception of an MP_REMOVEADDR message is acknowledged using MP_CONFIRM
(<xref target="MP_CONFIRM" format="default" sectionFormat="of" derivedContent="Section 3.2.1"/>). This ensures a reliable exchange of address
information. To avoid inconsistent states, the sender releases 
the Address ID only after MP_REMOVEADDR has been confirmed.</t>
          <t indent="0" pn="section-3.2.9-8">The sending and receiving of this message <bcp14>SHOULD</bcp14> trigger the closing procedure
described in <xref target="RFC4340" format="default" sectionFormat="of" derivedContent="RFC4340"/> between the client and the server on the affected
subflow(s), if possible. This helps remove middlebox state before
removing any local state.</t>
          <t indent="0" pn="section-3.2.9-9">Address removal is done by the Address ID to allow the use of NATs and other
middleboxes that rewrite source addresses.  If there is no address
at the requested Address ID, the receiver will silently ignore the request.</t>
          <figure anchor="refMP_REMOVEADDR" align="left" suppress-title="false" pn="figure-17">
            <name slugifiedName="name-format-of-the-mp_removeaddr">Format of the MP_REMOVEADDR Suboption</name>
            <artwork align="left" pn="section-3.2.9-10.1">
                     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
+---------------+---------------+---------------+---------------+
|0 0 1 0 1 1 1 0|0 0 0 0 0 1 0 0|0 0 0 0 1 0 0 0|   Address ID  |
+---------------+---------------+---------------+---------------+
|                             Nonce                             |
+-------------------------------+-------------------------------+
     Type=46        Length=8         MP_OPT=8

-&gt; followed by the MP_HMAC option</artwork>
          </figure>
        </section>
        <section anchor="MP_PRIO" numbered="true" removeInRFC="false" toc="include" pn="section-3.2.10">
          <name slugifiedName="name-mp_prio">MP_PRIO</name>
          <t indent="0" pn="section-3.2.10-1">The path priority signaled with the MP_PRIO option provides hints 
for the packet scheduler when making decisions about which path to use for 
payload traffic.
When a single specific path from the set of available
paths is treated with higher priority compared to the others
when making scheduling decisions for payload traffic, a host can 
signal such change in priority to the peer.
This could be used when there are different costs for
using different paths (e.g., Wi-Fi is free while cellular has a limit on
volume, and 5G has higher energy consumption). The priority of a path
could also change, for example, when a mobile host runs out
of battery, and the usage of only a single path may be the preferred choice
of the user.</t>
          <t indent="0" pn="section-3.2.10-2">The MP_PRIO suboption, shown below, can be used to set a priority value
for the subflow over which the suboption is received.</t>
          <figure anchor="ref-MP_PRIO" align="left" suppress-title="false" pn="figure-18">
            <name slugifiedName="name-format-of-the-mp_prio-subop">Format of the MP_PRIO Suboption</name>
            <artwork align="left" pn="section-3.2.10-3.1">
                     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
+---------------+---------------+---------------+---------------+
|0 0 1 0 1 1 1 0|0 0 0 0 0 1 0 0|0 0 0 0 1 0 0 1|(resvd)| prio  |
+---------------+---------------+---------------+---------------+
    Type=46         Length=4        MP_OPT=9</artwork>
          </figure>
          <t indent="0" pn="section-3.2.10-4">The following values are available for the Prio field:</t>
          <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-3.2.10-5">
            <li pn="section-3.2.10-5.1">
              <t indent="0" pn="section-3.2.10-5.1.1">0: Do not use. The path is not available.</t>
            </li>
            <li pn="section-3.2.10-5.2">
              <t indent="0" pn="section-3.2.10-5.2.1">1: Standby: Do not use this path for traffic scheduling if another
   path (secondary or primary) is available. The path will only be used if 
   other secondary or primary paths are not established.</t>
            </li>
            <li pn="section-3.2.10-5.3">
              <t indent="0" pn="section-3.2.10-5.3.1">2: Secondary: Do not use this path for traffic scheduling if the other
   paths are good enough. The path will be used occasionally for increasing 
   the available capacity temporarily, e.g., when primary paths are 
   congested or are not available. This is the recommended setting for
   paths that have costs or data caps as these paths will be used less
   frequently then primary paths.</t>
            </li>
            <li pn="section-3.2.10-5.4">
              <t indent="0" pn="section-3.2.10-5.4.1">3 - 15: Primary: The path can be used for packet scheduling decisions. The 
   priority number indicates the relative priority of one path over the 
   other for primary paths. Higher numbers indicate higher priority. 
   The peer should consider sending traffic first over higher priority paths. 
   This is the recommended setting for paths that do not have a cost or 
   data caps associated with them as these paths will be frequently used.</t>
            </li>
          </ul>
          <t indent="0" pn="section-3.2.10-6">Example use cases include:</t>
          <ol indent="adaptive" spacing="normal" start="1" type="1" pn="section-3.2.10-7"><li pn="section-3.2.10-7.1" derivedCounter="1.">
              <t indent="0" pn="section-3.2.10-7.1.1">Setting the Wi-Fi path to Primary and Cellular path to Secondary. In this case,
   Wi-Fi will be used and Cellular will be used only if the Wi-Fi path is congested or not
   available. Such setting results in using the Cellular path only temporally, 
   if more capacity is needed than the Wi-Fi path can provide, indicating a 
   clear priority of the Wi-Fi path over the Cellular due to, e.g., cost reasons.</t>
            </li>
            <li pn="section-3.2.10-7.2" derivedCounter="2.">
              <t indent="0" pn="section-3.2.10-7.2.1">Setting the Wi-Fi path to Primary and Cellular path to Standby. In this case, Wi-Fi
   will be used and Cellular will be used only if the Wi-Fi path is not available.</t>
            </li>
            <li pn="section-3.2.10-7.3" derivedCounter="3.">
              <t indent="0" pn="section-3.2.10-7.3.1">Setting the Wi-Fi path to Primary and Cellular path to Primary. In this case,
   both paths can be used when making packet scheduling decisions.</t>
            </li>
          </ol>
          <t indent="0" pn="section-3.2.10-8">If not specified, the default behavior is to always use a path for 
packet scheduling decisions (MP_PRIO=3), when the path has been established and 
added to an existing MP-DCCP connection. At least one path ought to have an 
MP_PRIO value greater than or equal to one for it to be allowed to send on the 
connection. It is <bcp14>RECOMMENDED</bcp14> to update at least one path to a non-zero MP_PRIO
value when an MP-DCCP connection enters a state where all paths remain with an
MP_PRIO value of zero. This helps an MP-DCCP connection to 
schedule when the multipath scheduler strictly respects MP_PRIO value 0.
To ensure reliable transmission, the MP_PRIO suboption <bcp14>MUST</bcp14> be acknowledged via an MP_CONFIRM 
(see <xref target="ref-mp-option-confirm" format="default" sectionFormat="of" derivedContent="Table 4"/>).</t>
          <t indent="0" pn="section-3.2.10-9">The relative ratio of the primary path values 3-15 depends on the path usage strategy, which is described in more detail in <xref target="path_usage_strategy" format="default" sectionFormat="of" derivedContent="Section 3.11"/>.
In the case of path mobility (<xref target="path_mobility" format="default" sectionFormat="of" derivedContent="Section 3.11.1"/>), only one path can be used at a time and <bcp14>MUST</bcp14> have the highest available priority value. That also includes the prio numbers 1 and 2. In the other case of concurrent path usage (<xref target="concurrent_usage" format="default" sectionFormat="of" derivedContent="Section 3.11.2"/>), the definition is up to the multipath scheduler logic.</t>
          <t indent="0" pn="section-3.2.10-10">An MP_SEQ (<xref target="MP_SEQ" format="default" sectionFormat="of" derivedContent="Section 3.2.5"/>) <bcp14>MUST</bcp14> be present in a DCCP datagram
in which the MP_PRIO suboption is sent. Further details are given in <xref target="MP_CONFIRM" format="default" sectionFormat="of" derivedContent="Section 3.2.1"/>.</t>
        </section>
        <section anchor="MP_CLOSE" numbered="true" removeInRFC="false" toc="include" pn="section-3.2.11">
          <name slugifiedName="name-mp_close">MP_CLOSE</name>
          <t indent="0" pn="section-3.2.11-1">
	    The mechanism available in DCCP <xref target="RFC4340" format="default" sectionFormat="of" derivedContent="RFC4340"/> for closing a connection cannot give an indication for closing an MP-DCCP connection, which typically contains several DCCP subflows; therefore, one cannot conclude from the closing of a subflow to the closing of an MP-DCCP connection. This is solved by introducing MP_CLOSE.
          </t>
          <figure anchor="ref-MP_CLOSE" align="left" suppress-title="false" pn="figure-19">
            <name slugifiedName="name-format-of-the-mp_close-subo">Format of the MP_CLOSE Suboption</name>
            <artwork align="left" pn="section-3.2.11-2.1">
            1          2          3
 01234567 89012345 67890123 45678901 23456789
+--------+--------+--------+--------+--------+
|00101110|  var   |00001010| Key Data ...
+--------+--------+--------+--------+--------+
 Type=46   Length  MP_OPT=10</artwork>
          </figure>
          <t indent="0" pn="section-3.2.11-3">An MP-DCCP connection can be gracefully closed by sending an MP_CLOSE to the peer host. 
On all subflows, the regular termination procedure described in <xref target="RFC4340" format="default" sectionFormat="of" derivedContent="RFC4340"/>
            <bcp14>MUST</bcp14> be initiated using MP_CLOSE in the initial packet (either a DCCP-CloseReq or a DCCP-Close). 
When  a DCCP-CloseReq is used, the following DCCP-Close <bcp14>MUST</bcp14> also carry the MP_CLOSE 
to avoid keeping a state in the sender of the DCCP-CloseReq. 
At the initiator of the DCCP-CloseReq, all sockets, including the MP-DCCP connection socket,
transition to CLOSEREQ state. To protect from unauthorized shutdown of a multipath connection, the selected Key Data of 
the peer host <bcp14>MUST</bcp14> be included in the MP_CLOSE option during the handshake procedure and <bcp14>MUST</bcp14> be validated by the peer host. 
Please note that the Key Data sent in DCCP-CloseReq will not be the same as the Key Data sent in DCCP-Close as these originate from different ends of the connection.</t>
          <t indent="0" pn="section-3.2.11-4">On reception of the first DCCP-CloseReq carrying an MP_CLOSE with valid Key Data, 
or due to a local decision, all subflows transition to the CLOSING state 
before transmitting a DCCP-Close carrying MP_CLOSE. 
The MP-DCCP connection socket on the host sending the DCCP-Close reflects the state of 
the initial subflow during the handshake with MP_KEY option. 
If the initial subflow no longer exists, the state moves immediately to CLOSED.</t>
          <t indent="0" pn="section-3.2.11-5">Upon reception of the first DCCP-Close carrying an MP_CLOSE with valid Key Data 
at the peer host, all subflows, as well as the MP-DCCP connection socket, 
move to the CLOSED state. After this, a DCCP-Reset with Reset Code 1 
<bcp14>MUST</bcp14> be sent on any subflow in response to a received DCCP-Close containing a valid MP_CLOSE option.</t>
          <t indent="0" pn="section-3.2.11-6">When the MP-DCCP connection socket is in CLOSEREQ or CLOSED state, new subflow requests using MP_JOIN <bcp14>MUST</bcp14> be ignored.</t>
          <t indent="0" pn="section-3.2.11-7">Contrary to an MP_FAST_CLOSE (<xref target="MP_FAST_CLOSE" format="default" sectionFormat="of" derivedContent="Section 3.2.3"/>), no single-sided abrupt termination is applied.</t>
        </section>
        <section anchor="MP_EXP" numbered="true" removeInRFC="false" toc="include" pn="section-3.2.12">
          <name slugifiedName="name-experimental-multipath-opti">Experimental Multipath Option MP_EXP for Private Use</name>
          <t indent="0" pn="section-3.2.12-1">This section reserves a Multipath Option to define and specify any experimental additional feature for improving and optimizing the MP-DCCP protocol. This
option could be applicable to specific environments or scenarios according to potential new requirements and is meant for private use only. MP_OPT 
Feature Number 11 is specified with an exemplary description as below:</t>
          <figure anchor="ref-MP_EXP" align="left" suppress-title="false" pn="figure-20">
            <name slugifiedName="name-format-of-the-mp_exp-subopt">Format of the MP_EXP Suboption</name>
            <artwork align="left" pn="section-3.2.12-2.1">
                     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
+---------------+---------------+---------------+---------------+
|0 0 1 0 1 1 1 0|      var      |0 0 0 0 1 0 1 1|     Data      |
+---------------+---------------+---------------+---------------+
|   ...
+---------------------------------------------------------------+
     Type=46         Length         MP_OPT=11</artwork>
          </figure>
          <t indent="0" pn="section-3.2.12-3">The Data field can carry any data according to the foreseen use by the experimenters with a maximum Length of 252 bytes.</t>
        </section>
      </section>
      <section anchor="handshaking" numbered="true" removeInRFC="false" toc="include" pn="section-3.3">
        <name slugifiedName="name-mp-dccp-handshake-procedure">MP-DCCP Handshake Procedure</name>
        <t indent="0" pn="section-3.3-1">An example MP-DCCP handshake procedure is shown in <xref target="ref-mp-dccp-handshaking" format="default" sectionFormat="of" derivedContent="Figure 21"/>.</t>
        <figure anchor="ref-mp-dccp-handshaking" align="left" suppress-title="false" pn="figure-21">
          <name slugifiedName="name-example-mp-dccp-handshake">Example MP-DCCP Handshake</name>
          <artwork align="left" pn="section-3.3-2.1">
          Host A                                         Host B
------------------------                              ----------
Address A1    Address A2                              Address B1
----------    ----------                              ----------
     |             |                                       |
     |           DCCP-Request + Change R (MP_CAPABLE,...)  |
     |----- MP_KEY(CI-A + KeyA(1), KeyA(2),...) ----------&gt;|
     |&lt;------------------- MP_KEY(CI-B + KeyB) ------------|
     |       DCCP-Response +  Confirm L (MP_CAPABLE, ...)  |
     |             |                                       |
     |   DCCP-Ack  |                                       |
     |----------------------------------------------------&gt;|
     |&lt;----------------------------------------------------|
     |   DCCP-Ack  |                                       |
     |             |                                       |
     |             |DCCP-Request + Change R(MP_CAPABLE,...)|
     |             |--- MP_JOIN(CI-B,RA) -----------------&gt;|
     |             |&lt;------MP_JOIN(CI-A,RB) + MP_HMAC(B)---|
     |             |DCCP-Response+Confirm L(MP_CAPABLE,...)|
     |             |                                       |
     |             |DCCP-Ack                               |
     |             |-------- MP_HMAC(A) ------------------&gt;|
     |             |&lt;--------------------------------------|
     |             |DCCP-Ack                               |</artwork>
        </figure>
        <t indent="0" pn="section-3.3-3">The basic initial handshake for the first subflow is as follows:</t>
        <ol indent="adaptive" spacing="normal" start="1" type="1" pn="section-3.3-4">
          <li pn="section-3.3-4.1" derivedCounter="1.">
            <t indent="0" pn="section-3.3-4.1.1">Host A sends a DCCP-Request with the Multipath Capable Feature change
request and the MP_KEY option with a Host-specific CI-A and a KeyA for
each of the supported Key Types as described in <xref target="MP_KEY" format="default" sectionFormat="of" derivedContent="Section 3.2.4"/>. CI-A is a unique identifier during the
lifetime of an MP-DCCP connection.</t>
          </li>
          <li pn="section-3.3-4.2" derivedCounter="2.">
            <t indent="0" pn="section-3.3-4.2.1">Host B sends a DCCP-Response with a Confirm feature for
MP-Capable and the MP_Key option with a unique Host-specific CI-B and a single Host-specific KeyB.
The type of the key is chosen from the list of supported types
from the previous request.</t>
          </li>
          <li pn="section-3.3-4.3" derivedCounter="3.">
            <t indent="0" pn="section-3.3-4.3.1">Host A sends a DCCP-Ack to confirm the proper key exchange.</t>
          </li>
          <li pn="section-3.3-4.4" derivedCounter="4.">
            <t indent="0" pn="section-3.3-4.4.1">Host B sends a DCCP-Ack to complete the handshake and set both connection ends to the OPEN state.</t>
          </li>
        </ol>
        <t indent="0" pn="section-3.3-5">It should be noted that DCCP is protected against corruption of DCCP header data (<xref target="RFC4340" sectionFormat="of" section="9" format="default" derivedLink="https://rfc-editor.org/rfc/rfc4340#section-9" derivedContent="RFC4340"/>), so no additional mechanisms beyond the general confirmation are required to ensure that the header data has been properly received.</t>
        <t indent="0" pn="section-3.3-6">Host A waits for the final DCCP-Ack from Host B before starting any
establishment of additional subflow connections.</t>
        <t indent="0" pn="section-3.3-7">The handshake for subsequent subflows, based on a successful initial
handshake, is as follows:</t>
        <ol indent="adaptive" spacing="normal" start="1" type="1" pn="section-3.3-8">
          <li pn="section-3.3-8.1" derivedCounter="1.">
            <t indent="0" pn="section-3.3-8.1.1">Host A sends a DCCP-Request with the Multipath Capable Feature change
            request and the MP_JOIN option with Host B's CI-B, obtained during
            the initial handshake. Additionally, a random Nonce RA is
            transmitted with the MP_JOIN.</t>
          </li>
          <li pn="section-3.3-8.2" derivedCounter="2.">
            <t indent="0" pn="section-3.3-8.2.1">Host B computes the HMAC of the DCCP-Request and sends a
            DCCP-Response with a Confirm feature option for MP-Capable and the
            MP_JOIN option with the CI-A and a random Nonce RB together with
            the computed MP_HMAC.
	    As specified in <xref target="MP_HMAC" format="default" sectionFormat="of" derivedContent="Section 3.2.6"/>,
            the HMAC is calculated by taking the leftmost 20 bytes from the
            SHA-256 hash of an HMAC code that is created by using the Nonce received
            with MP_JOIN(A) and the local Nonce RB as the Message and the derived
            key as the Key, as described in <xref target="MP_KEY" format="default" sectionFormat="of" derivedContent="Section 3.2.4"/>: </t>
            <t indent="0" pn="section-3.3-8.2.2">MP_HMAC(B) = HMAC-SHA256(Key=d-keyB, Msg=RB+RA)</t>
          </li>
          <li pn="section-3.3-8.3" derivedCounter="3.">
            <t indent="0" pn="section-3.3-8.3.1">Host A sends a DCCP-Ack with the HMAC computed for the
            DCCP-Response.  As specified in <xref target="MP_HMAC" format="default" sectionFormat="of" derivedContent="Section 3.2.6"/>, the HMAC
            is calculated by taking the leftmost 20 bytes from the SHA-256 hash
            of an HMAC code created by using the local Nonce RA and the Nonce
            received with MP_JOIN(B) as message and the derived key described
            in <xref target="MP_KEY" format="default" sectionFormat="of" derivedContent="Section 3.2.4"/> as key: </t>
            <t indent="0" pn="section-3.3-8.3.2">MP_HMAC(A) = HMAC-SHA256(Key=d-keyA, Msg=RA+RB)</t>
          </li>
          <li pn="section-3.3-8.4" derivedCounter="4.">
            <t indent="0" pn="section-3.3-8.4.1">Host B sends a DCCP-Ack to confirm the HMAC and to conclude the
            handshake.</t>
          </li>
        </ol>
      </section>
      <section anchor="address-knowledge-exchange" numbered="true" removeInRFC="false" toc="include" pn="section-3.4">
        <name slugifiedName="name-address-knowledge-exchange">Address Knowledge Exchange</name>
        <section anchor="advertising-a-new-path-mpaddaddr" numbered="true" removeInRFC="false" toc="include" pn="section-3.4.1">
          <name slugifiedName="name-advertising-a-new-path-mp_a">Advertising a New Path (MP_ADDADDR)</name>
          <t indent="0" pn="section-3.4.1-1">When a host (Host A) wants to advertise the availability of a new path, it should use the MP_ADDADDR option (<xref target="MP_ADDADDR" format="default" sectionFormat="of" derivedContent="Section 3.2.8"/>) as
shown in the example in <xref target="ref-mp-dccp-add-address" format="default" sectionFormat="of" derivedContent="Figure 22"/>. The MP_ADDADDR option passed in the DCCP-Data contains the following parameters:</t>
          <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-3.4.1-2">
            <li pn="section-3.4.1-2.1">
              <t indent="0" pn="section-3.4.1-2.1.1">an identifier (id 2) for the new IP address, which is used as a reference in subsequent control exchanges</t>
            </li>
            <li pn="section-3.4.1-2.2">
              <t indent="0" pn="section-3.4.1-2.2.1">a Nonce value to prevent replay attacks</t>
            </li>
            <li pn="section-3.4.1-2.3">
              <t indent="0" pn="section-3.4.1-2.3.1">the IP address of the new path (A2_IP)</t>
            </li>
            <li pn="section-3.4.1-2.4">
              <t indent="0" pn="section-3.4.1-2.4.1">a pair of bytes specifying the port number associated with this IP address. The value of 00 here indicates that the port number is the same
as that used for the initial subflow address A1_IP.</t>
            </li>
          </ul>
          <t indent="0" pn="section-3.4.1-3">According to <xref target="MP_ADDADDR" format="default" sectionFormat="of" derivedContent="Section 3.2.8"/>, the following options are required in a packet carrying MP_ADDADDR:</t>
          <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-3.4.1-4">
            <li pn="section-3.4.1-4.1">
              <t indent="0" pn="section-3.4.1-4.1.1">the leftmost 20 bytes of the HMAC(A) generated during the initial handshake procedure described in Sections <xref target="handshaking" format="counter" sectionFormat="of" derivedContent="3.3"/> and <xref target="MP_HMAC" format="counter" sectionFormat="of" derivedContent="3.2.6"/></t>
            </li>
            <li pn="section-3.4.1-4.2">
              <t indent="0" pn="section-3.4.1-4.2.1">the MP_SEQ option with the sequence number (seqno 12) for this message, according to <xref target="MP_SEQ" format="default" sectionFormat="of" derivedContent="Section 3.2.5"/></t>
            </li>
          </ul>
          <t indent="0" pn="section-3.4.1-5">Host B acknowledges receipt of the MP_ADDADDR message with a DCCP-Ack containing the MP_CONFIRM option. The parameters supplied in this
response are as follows:</t>
          <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-3.4.1-6">
            <li pn="section-3.4.1-6.1">
              <t indent="0" pn="section-3.4.1-6.1.1">an MP_CONFIRM containing the MP_SEQ number (seqno 12) of the packet carrying the option that we are confirming together with the MP_ADDADDR option</t>
            </li>
            <li pn="section-3.4.1-6.2">
              <t indent="0" pn="section-3.4.1-6.2.1">the leftmost 20 bytes of the HMAC(B) generated during the initial handshake procedure (<xref target="handshaking" format="default" sectionFormat="of" derivedContent="Section 3.3"/>)</t>
            </li>
          </ul>
          <figure anchor="ref-mp-dccp-add-address" align="left" suppress-title="false" pn="figure-22">
            <name slugifiedName="name-example-mp_addaddr-procedur">Example MP_ADDADDR Procedure</name>
            <artwork align="left" pn="section-3.4.1-7.1">
          Host A                                         Host B
------------------------                              -----------
Address A1    Address A2                               Address B1
----------    ----------                              -----------
     |             |                                       |
     |   DCCP-Data +  MP_ADDADDR(id 2, Nonce, A2_IP, 00) + |
     |------- MP_HMAC(A) + MP_SEQ(seqno 12) --------------&gt;|
     |             |                                       |
     |   DCCP-Ack + MP_HMAC(B) +                           |
     |&lt;----- MP_CONFIRM(seqno 12, MP_ADDADDR) -------------|</artwork>
          </figure>
        </section>
        <section anchor="removing-a-path-mpremoveaddr" numbered="true" removeInRFC="false" toc="include" pn="section-3.4.2">
          <name slugifiedName="name-removing-a-path-mp_removead">Removing a Path (MP_REMOVEADDR)</name>
          <t indent="0" pn="section-3.4.2-1">When a host (Host A) wants to indicate that a path is no longer available, it should use the MP_REMOVEADDR option (<xref target="MP_REMOVEADDR" format="default" sectionFormat="of" derivedContent="Section 3.2.9"/>) as
shown in the example in <xref target="ref-mp-dccp-remove-address" format="default" sectionFormat="of" derivedContent="Figure 23"/>. The MP_REMOVEADDR option passed in the DCCP-Data contains the following parameters:</t>
          <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-3.4.2-2">
            <li pn="section-3.4.2-2.1">
              <t indent="0" pn="section-3.4.2-2.1.1">an identifier (id 2) for the IP address to remove (A2_IP) and that was specified in a previous MP_ADDADDR message</t>
            </li>
            <li pn="section-3.4.2-2.2">
              <t indent="0" pn="section-3.4.2-2.2.1">a Nonce value to prevent replay attacks</t>
            </li>
          </ul>
          <t indent="0" pn="section-3.4.2-3">According to <xref target="MP_REMOVEADDR" format="default" sectionFormat="of" derivedContent="Section 3.2.9"/>, the following options are required in a packet carrying MP_REMOVEADDR:</t>
          <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-3.4.2-4">
            <li pn="section-3.4.2-4.1">
              <t indent="0" pn="section-3.4.2-4.1.1">the leftmost 20 bytes of the HMAC(A) generated during the initial handshake procedure described in Sections <xref target="handshaking" format="counter" sectionFormat="of" derivedContent="3.3"/> and <xref target="MP_HMAC" format="counter" sectionFormat="of" derivedContent="3.2.6"/></t>
            </li>
            <li pn="section-3.4.2-4.2">
              <t indent="0" pn="section-3.4.2-4.2.1">the MP_SEQ option with the sequence number (seqno 33) for this message, according to <xref target="MP_SEQ" format="default" sectionFormat="of" derivedContent="Section 3.2.5"/></t>
            </li>
          </ul>
          <t indent="0" pn="section-3.4.2-5">Host B acknowledges receipt of the MP_REMOVEADDR message with a DCCP-Ack containing the MP_CONFIRM option. The parameters supplied in this
response are as follows:</t>
          <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-3.4.2-6">
            <li pn="section-3.4.2-6.1">
              <t indent="0" pn="section-3.4.2-6.1.1">an MP_CONFIRM containing the MP_SEQ number (seqno 33) of the packet carrying the option that we are confirming, together with the MP_REMOVEADDR option</t>
            </li>
            <li pn="section-3.4.2-6.2">
              <t indent="0" pn="section-3.4.2-6.2.1">the leftmost 20 bytes of the HMAC(B) generated during the initial handshake procedure (<xref target="handshaking" format="default" sectionFormat="of" derivedContent="Section 3.3"/>)</t>
            </li>
          </ul>
          <figure anchor="ref-mp-dccp-remove-address" align="left" suppress-title="false" pn="figure-23">
            <name slugifiedName="name-example-mp_removeaddr-proce">Example MP_REMOVEADDR Procedure</name>
            <artwork align="left" pn="section-3.4.2-7.1">
          Host A                                         Host B
------------------------                              -----------
Address A1    Address A2                               Address B1
----------    ----------                              -----------
     |             |                                       |
     |   DCCP-Data +  MP_REMOVEADDR(id 2, Nonce) +         |
     |------- MP_HMAC(A) + MP_SEQ(seqno 33) --------------&gt;|
     |             |                                       |
     |   DCCP-Ack + MP_HMAC(B) +                           |
     |&lt;----- MP_CONFIRM(seqno 33, MP_REMOVEADDR) ----------|</artwork>
          </figure>
        </section>
      </section>
      <section anchor="closing" numbered="true" removeInRFC="false" toc="include" pn="section-3.5">
        <name slugifiedName="name-closing-an-mp-dccp-connecti">Closing an MP-DCCP Connection</name>
        <t indent="0" pn="section-3.5-1">When a host wants to close an existing subflow but not the whole MP-DCCP
connection, it <bcp14>MUST</bcp14> initiate the regular DCCP connection termination procedure 
as described in <xref target="RFC4340" sectionFormat="of" section="5.6" format="default" derivedLink="https://rfc-editor.org/rfc/rfc4340#section-5.6" derivedContent="RFC4340"/>, i.e., it sends a DCCP-Close/DCCP-Reset on the subflow. This
may be preceded by a DCCP-CloseReq. In the event of an irregular termination of a subflow,
e.g., during subflow establishment, it <bcp14>MUST</bcp14> use an appropriate DCCP-Reset Code as specified by IANA <xref target="DCCP-PARAMETERS" format="default" sectionFormat="of" derivedContent="DCCP-PARAMETERS"/> for DCCP operations. This could be, for example, sending Reset Code 5 (Option Error) when an MP-DCCP
option provides invalid data or Reset Code 9 (Too Busy) when the maximum number of maintainable paths
is reached. Note that receiving a Reset Code 9 for secondary subflows <bcp14>MUST NOT</bcp14> impact already existing active
subflows. If necessary, these subflows are terminated in a subsequent step using the procedures described in
this section.</t>
        <t indent="0" pn="section-3.5-2">A host terminates an MP-DCCP connection using the DCCP connection termination specified in
<xref target="RFC4340" sectionFormat="of" section="5.5" format="default" derivedLink="https://rfc-editor.org/rfc/rfc4340#section-5.5" derivedContent="RFC4340"/> on each subflow with the first packet on each subflow carrying MP_CLOSE (see <xref target="MP_CLOSE" format="default" sectionFormat="of" derivedContent="Section 3.2.11"/>).</t>
        <artwork align="left" pn="section-3.5-3">
Host A                                   Host B
------                                   ------
                                 &lt;-      Optional DCCP-CloseReq +
                                         MP_CLOSE [A's key]
                                         [on all subflows]
DCCP-Close + MP_CLOSE            -&gt;
[B's key] [on all subflows]
                                 &lt;-      DCCP-Reset
                                         [on all subflows]</artwork>
        <t indent="0" pn="section-3.5-4">Additionally, an MP-DCCP connection may be closed abruptly using the "fast close"
procedure described in <xref target="MP_FAST_CLOSE" format="default" sectionFormat="of" derivedContent="Section 3.2.3"/>, where a DCCP-Reset is sent on all
subflows, each carrying the MP_FAST_CLOSE option.</t>
        <artwork align="left" pn="section-3.5-5">
Host A                                   Host B
------                                   ------
DCCP-Reset + MP_FAST_CLOSE       -&gt;
[B's key] [on all subflows]
                                 &lt;-      DCCP-Reset
                                         [on all subflows]</artwork>
      </section>
      <section anchor="fallback" numbered="true" removeInRFC="false" toc="include" pn="section-3.6">
        <name slugifiedName="name-fallback">Fallback</name>
        <t indent="0" pn="section-3.6-1">When a subflow fails to operate following the intended behavior of the MP-DCCP, it is 
necessary to proceed with a fallback. This may be either falling back 
to regular DCCP <xref target="RFC4340" format="default" sectionFormat="of" derivedContent="RFC4340"/> or removing a problematic subflow. The main reasons for 
a subflow failing include: no MP support at the peer host, failure to negotiate the protocol
version, loss of Multipath Options, faulty/non-supported MP-DCCP options, or modification
of payload data.</t>
        <t indent="0" pn="section-3.6-2">At the start of an MP-DCCP connection, the handshake ensures the exchange of the MP-DCCP feature and options and thus ensures that the path is fully MP-DCCP capable. If during the
handshake procedure it appears that DCCP-Request or DCCP-Response
messages do not carry the Multipath Capable Feature, the MP-DCCP connection will not be 
established and the handshake <bcp14>SHOULD</bcp14> fall back to regular DCCP. If this is not 
possible, the connection <bcp14>MUST</bcp14> be closed.</t>
        <t indent="0" pn="section-3.6-3">If the endpoints fail to agree on the protocol version to use during the Multipath
Capable Feature negotiation, the connection <bcp14>MUST</bcp14> either be closed or fall back
to regular DCCP. This is described in <xref target="mp_capable" format="default" sectionFormat="of" derivedContent="Section 3.1"/>. The protocol version negotiation
distinguishes between negotiation for the initial connection establishment and
the addition of subsequent subflows. If protocol version negotiation is not successful
during the initial connection establishment, the MP-DCCP connection will fall back to regular DCCP.</t>
        <t indent="0" pn="section-3.6-4">The fallback procedure for regular DCCP <bcp14>MUST</bcp14> also be applied if the MP_KEY (<xref target="MP_KEY" format="default" sectionFormat="of" derivedContent="Section 3.2.4"/>) Key Type cannot be negotiated.</t>
        <t indent="0" pn="section-3.6-5">If a subflow attempts to join an existing MP-DCCP connection but MP-DCCP options or the Multipath Capable Feature are not present or are faulty in the handshake procedure, that subflow <bcp14>MUST</bcp14> be closed.
This is the case especially if a different MP_CAPABLE version than the originally negotiated
version is used. Reception of a non-verifiable MP_HMAC (<xref target="MP_HMAC" format="default" sectionFormat="of" derivedContent="Section 3.2.6"/>) or an invalid
CI used in MP_JOIN (<xref target="MP_JOIN" format="default" sectionFormat="of" derivedContent="Section 3.2.2"/>) during flow establishment <bcp14>MUST</bcp14> cause the
subflow to be closed.</t>
        <t indent="0" pn="section-3.6-6">The subflow closing procedure <bcp14>MUST</bcp14> also be applied if a final ACK carrying MP_KEY with the wrong KeyA/KeyB is
received or the MP_KEY option is malformed.</t>
        <t indent="0" pn="section-3.6-7">Another relevant case is when payload data is modified by middleboxes. DCCP uses 
a checksum to protect the data, as described in <xref target="RFC4340" sectionFormat="of" section="9" format="default" derivedLink="https://rfc-editor.org/rfc/rfc4340#section-9" derivedContent="RFC4340"/>. A checksum will 
fail if the data has been changed in any way. All data from the start of the segment that
failed the checksum onwards cannot be considered trustworthy. As defined by DCCP, if the checksum fails, the receiving endpoint <bcp14>MUST</bcp14> drop the application data and report 
that data as dropped due to corruption using a Data Dropped option (Drop Code 3, 
Corrupt). If data is dropped due to corruption for an MP-DCCP connection, the affected
subflow <bcp14>MAY</bcp14> be closed. The same procedure applies if the Multipath Option is unknown.</t>
      </section>
      <section anchor="state-diagram" numbered="true" removeInRFC="false" toc="include" pn="section-3.7">
        <name slugifiedName="name-state-diagram">State Diagram</name>
        <t indent="0" pn="section-3.7-1">The MP-DCCP per subflow state transitions follow the
state transitions defined for DCCP in <xref target="RFC4340" format="default" sectionFormat="of" derivedContent="RFC4340"/> to a large extent, with some modifications 
due to the MP-DCCP 4-way handshake and fast close procedures. The state diagram below
shows the most common state transitions.  The diagram is illustrative.
For example, there are arcs (not shown) from several additional states 
	to TIMEWAIT, contingent on the receipt of a valid DCCP-Reset.</t>
        <t indent="0" pn="section-3.7-2">When the state moves from CLOSED to OPEN during the 4-way handshake, the transitioned states remain the same as for DCCP, but it is no longer possible to transmit
application data while in the REQUEST state. The fast close procedure
can be triggered by either the client or the server and results in the transmission
of a Reset packet. The fast close procedure moves the state of the Client and Server
directly to TIMEWAIT and CLOSED, respectively.</t>
        <figure anchor="ref-mp-dccp-state-transition" align="left" suppress-title="false" pn="figure-24">
          <name slugifiedName="name-most-common-state-transitio">Most Common State Transitions of an MP-DCCP Subflow</name>
          <artwork align="left" pn="section-3.7-3.1">
+----------------------------+    +------------------------------+
|                            v    v                              |
|                         +----------+                           |
|           +-------------+  CLOSED  +-------------+             |
|           | passive     +----------+   active    |             |
|           |  open                       open     |             |
|           |                          snd Request |             |
|           v                                      v             |
|     +-----------+                           +----------+       |
|     |  LISTEN   |                           | REQUEST  |       |
|     +-----+-----+                           +----+-----+       |
|           | rcv Request             rcv Response |             |
|           | snd Response              snd Ack    |             |
|           v                                      v             |
|     +-----------+                           +----------+       |
|     |  RESPOND  |                           | PARTOPEN |       |
|     +-----+-----+                           +----+-----+       |
|           | rcv Ack             rcv Ack/DataAck  |             |
|           | snd Ack                              |             |
|           |             +-----------+            |             |
|           +------------&gt;|   OPEN    |&lt;-----------+             |
|                         +--+-+-+-+--+                          |
|        server active close | | | |   active close              |
|            snd CloseReq    | | | | or rcv CloseReq             |
|                            | | | |    snd Close                |
|                            | | | |                             |
|     +-----------+          | | | |            +----------+     |
|     | CLOSEREQ  |&lt;---------+ | | +-----------&gt;| CLOSING  |     |
|     +-----+-----+            | |              +----+-----+     |
|           | rcv Close        | |         rcv Reset |           |
|           | snd Reset        | |                   |           |
|           |                  | | active FastClose  |           |
|&lt;----------+        rcv Close | | or rcv FastClose  v           |
|   or server active FastClose | | snd Reset    +----+-----+     |
|      or server rcv FastClose | +-------------&gt;| TIMEWAIT |     |
|                    snd Reset |                +----+-----+     |
+------------------------------+                     |           |
                                                     +-----------+
                                                 2MSL timer expires</artwork>
        </figure>
      </section>
      <section anchor="congestion-control-considerations" numbered="true" removeInRFC="false" toc="include" pn="section-3.8">
        <name slugifiedName="name-congestion-control-consider">Congestion Control Considerations</name>
        <t indent="0" pn="section-3.8-1">Senders <bcp14>MUST</bcp14> manage per-path congestion status and avoid 
sending more data on a given path than congestion control allows for each path.</t>
      </section>
      <section anchor="mps" numbered="true" removeInRFC="false" toc="include" pn="section-3.9">
        <name slugifiedName="name-maximum-packet-size-conside">Maximum Packet Size Considerations</name>
        <t indent="0" pn="section-3.9-1">A DCCP implementation maintains the maximum packet size (MPS) during operation of a DCCP session. This procedure is specified for single-path DCCP in <xref target="RFC4340" sectionFormat="of" section="14" format="default" derivedLink="https://rfc-editor.org/rfc/rfc4340#section-14" derivedContent="RFC4340"/>. Without any restrictions, this is adopted for MP-DCCP operations, in particular the Path MTU (PMTU) measurement and the Sender Behavior. The DCCP application interface <bcp14>SHOULD</bcp14> allow the application to discover the current MPS. This reflects the current largest size supported for the data stream that can be used across the set of all active MP-DCCP subflows.</t>
      </section>
      <section anchor="maximum-number-of-subflows-considerations" numbered="true" removeInRFC="false" toc="include" pn="section-3.10">
        <name slugifiedName="name-maximum-number-of-subflow-c">Maximum Number of Subflow Considerations</name>
        <t indent="0" pn="section-3.10-1">MP-DCCP does not support any explicit procedure to negotiate
the maximum number of subflows between endpoints. However, in practical
scenarios, there will be resource limitations on the host
or use cases that do not benefit from additional subflows.</t>
        <t indent="0" pn="section-3.10-2">It is <bcp14>RECOMMENDED</bcp14> to limit the number of subflows in implementations and to reject incoming subflow requests with a DCCP-Reset using the Reset Code "too busy" according to <xref target="RFC4340" format="default" sectionFormat="of" derivedContent="RFC4340"/> if the resource limit is exceeded or it is known that the multipath connection will not benefit from further subflows. Likewise, it is <bcp14>RECOMMENDED</bcp14> that the host that wants to create the subflows  considers the available resources and possible gains.</t>
        <t indent="0" pn="section-3.10-3">To avoid further inefficiencies with subflows due to short-lived connections, it <bcp14>MAY</bcp14> be useful to delay the start of additional subflows. The decision on the initial number of subflows can be based on the occupancy of the socket buffer and/or the timing.</t>
        <t indent="0" pn="section-3.10-4">While in the socket-buffer-based approach the number of initial subflows can be derived by opening new subflows until their initial windows cover the amount of buffered application data, the timing-based approach delays the start of additional subflows based on a certain time period, load, or knowledge of traffic and path properties. The delay-based approach also provides resilience for low-bandwidth but long-lived applications. All this could also be supported by advanced APIs that signal application traffic requests to the MP-DCCP.</t>
      </section>
      <section anchor="path_usage_strategy" numbered="true" removeInRFC="false" toc="include" pn="section-3.11">
        <name slugifiedName="name-path-usage-strategies">Path Usage Strategies</name>
        <t indent="0" pn="section-3.11-1">MP-DCCP can be configured to realize one of several strategies for path usage via selecting one DCCP subflow out of the multiple DCCP subflows within an MP-DCCP connection for data transmission. This can be a dynamic process further facilitated by the means of DCCP and MP-DCCP-defined options such as path preference using MP-PRIO; adding or removing DCCP subflows using MP_REMOVEADDR, MP_ADDADDR, or DCCP-Close/DCCP-Reset; and path metrics such as packet loss rate, congestion window (CWND), or RTT provided by the congestion control algorithm.
Selecting an appropriate method can allow MP-DCCP to realize different path utilization strategies that make MP-DCCP suitable for end-to-end implementation over the Internet or in controlled environments such as Hybrid Access or 5G ATSSS.</t>
        <section anchor="path_mobility" numbered="true" removeInRFC="false" toc="include" pn="section-3.11.1">
          <name slugifiedName="name-path-mobility">Path Mobility</name>
          <t indent="0" pn="section-3.11.1-1">The path mobility strategy provides the use of a single path with a seamless handover function to continue the connection when the currently used path is deemed unsuitable for service delivery.
Some of the DCCP subflows of an MP-DCCP connection might become inactive due to either the occurrence of certain error conditions (e.g., DCCP timeout, packet loss threshold, RTT threshold, and closed/removed) or adjustments from the MP-DCCP user.
When there is outbound data to send and the primary path becomes inactive (e.g., due to failures) or deprioritized, the MP-DCCP endpoint <bcp14>SHOULD</bcp14> try to send the data through an alternate path with a different source or destination address (depending on the point of failure), if one exists. This process <bcp14>SHOULD</bcp14> respect the path priority configured by the MP_PRIO suboption; otherwise, if the path priority is not available, pick the most divergent source-destination pair from the originally used source-destination pair.</t>
          <aside pn="section-3.11.1-2">
            <t indent="0" pn="section-3.11.1-2.1">Note: Rules for picking the most appropriate source-destination pair
are an implementation decision and are not specified within this document.
Path mobility is supported in the current Linux reference implementation <xref target="MP-DCCP.Site" format="default" sectionFormat="of" derivedContent="MP-DCCP.Site"/>.</t>
          </aside>
        </section>
        <section anchor="concurrent_usage" numbered="true" removeInRFC="false" toc="include" pn="section-3.11.2">
          <name slugifiedName="name-concurrent-path-usage">Concurrent Path Usage</name>
          <t indent="0" pn="section-3.11.2-1">Different from a path mobility strategy, the selection between MP-DCCP
subflows is a per-packet decision that is a part of the multipath
scheduling process. This method would allow multiple subflows to be
simultaneously used to aggregate the path resources to obtain higher
connection throughput.</t>
          <t indent="0" pn="section-3.11.2-2">In this scenario, the selection of congestion control, per-packet scheduling,
and a potential reordering method determines a concurrent path utilization
strategy and result in a particular transport characteristic.
A concurrent path usage method uses a scheduling design that could seek to
maximize reliability, maximize throughput, minimize latency, etc.</t>
          <t indent="0" pn="section-3.11.2-3">Concurrent path usage over the Internet can have implications. When an 
MP-DCCP connection uses two or more paths, there is no guarantee 
that these paths are fully disjoint.  When two (or more) subflows share 
the same bottleneck, using a standard congestion control algorithm could 
result in an unfair distribution of the capacity with the multipath 
connection using more capacity than competing single-path connections.</t>
          <t indent="0" pn="section-3.11.2-4">Multipath TCP uses the coupled congestion control Linked Increases 
Algorithm (LIA) specified in an experimental specification <xref target="RFC6356" format="default" sectionFormat="of" derivedContent="RFC6356"/> to solve this problem.  This 
scheme could also be specified for MP-DCCP.  The same applies to 
other coupled congestion control algorithms that have been proposed for 
Multipath TCP such as the Opportunistic Linked Increases Algorithm <xref target="OLIA" format="default" sectionFormat="of" derivedContent="OLIA"/>.</t>
          <t indent="0" pn="section-3.11.2-5">The specification of scheduling for concurrent multipath and related 
congestion control algorithms and reordering methods for use in the general
Internet are outside the scope of this document. If, and when, the IETF
specifies a method for concurrent usage of multiple paths for the
general Internet, the framework specified in this document could be used to 
provide an IETF-recommended method for MP-DCCP.
          </t>
        </section>
      </section>
    </section>
    <section anchor="security" numbered="true" removeInRFC="false" toc="include" pn="section-4">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-4-1">Similar to DCCP, MP-DCCP does not provide cryptographic security
guarantees inherently. Thus, if applications need cryptographic security
(integrity, authentication, confidentiality, access control, and
anti-replay protection), the use of IPsec, DTLS over DCCP <xref target="RFC5238" format="default" sectionFormat="of" derivedContent="RFC5238"/>, or other
end-to-end security is recommended;
the Secure Real-time Transport Protocol (SRTP) <xref target="RFC3711" format="default" sectionFormat="of" derivedContent="RFC3711"/> is one candidate
protocol for authentication. Integrity would be provided if using SRTP together with the encryption of header extensions described in <xref target="RFC6904" format="default" sectionFormat="of" derivedContent="RFC6904"/>.</t>
      <t indent="0" pn="section-4-2">DCCP <xref target="RFC4340" format="default" sectionFormat="of" derivedContent="RFC4340"/> provides protection against hijacking
and limits the potential impact of some denial-of-service attacks, but
DCCP provides no inherent protection against an on-path attacker snooping on data
packets. Regarding the security of MP-DCCP compared to regular DCCP, no additional risks should be introduced. The security objectives for MP-DCCP are:</t>
      <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-4-3">
        <li pn="section-4-3.1">
          <t indent="0" pn="section-4-3.1.1">Provide assurance that the parties involved in an
MP-DCCP handshake procedure are identical to those in the original DCCP connection.</t>
        </li>
        <li pn="section-4-3.2">
          <t indent="0" pn="section-4-3.2.1">Before a path is used, verify that the new advertised path is valid for receiving traffic.</t>
        </li>
        <li pn="section-4-3.3">
          <t indent="0" pn="section-4-3.3.1">Provide replay protection, i.e., ensure that a request to add/remove a
subflow is 'fresh'.</t>
        </li>
        <li pn="section-4-3.4">
          <t indent="0" pn="section-4-3.4.1">Allow a party to limit the number of subflows that it allows.</t>
        </li>
      </ul>
      <t indent="0" pn="section-4-4">To achieve these goals, MP-DCCP includes a hash-based handshake
algorithm documented in Sections <xref target="MP_KEY" format="counter" sectionFormat="of" derivedContent="3.2.4"/>, <xref target="MP_HMAC" format="counter" sectionFormat="of" derivedContent="3.2.6"/>, and <xref target="handshaking" format="counter" sectionFormat="of" derivedContent="3.3"/>. The
security of the MP-DCCP connection depends on the use of keys that are
shared once at the start of the first subflow and are never sent again
over the network. Depending on the security requirements, different Key Types can
be negotiated in the handshake procedure or must follow the fallback scenario
described in <xref target="fallback" format="default" sectionFormat="of" derivedContent="Section 3.6"/>. If there are security requirements that go beyond the
capabilities of Key Type 0, then it is <bcp14>RECOMMENDED</bcp14> that Key Type 0 not be enabled
to avoid downgrade attacks that result in the key being exchanged as plain text.
To ease demultiplexing while not revealing
cryptographic material, subsequent subflows use the initially exchanged
CI information. The keys exchanged once at the beginning are
concatenated and used as keys for creating HMACs used on subflow setup, in order to verify
that the parties in the handshake of subsequent subflows are the same as in the original
connection setup. This 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) for both
parties -- 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" format="default" sectionFormat="of" derivedContent="RFC4086"/>. During normal operation, regular DCCP protection
mechanisms (such as the header checksum to protect DCCP headers against
corruption) is designed to provide the same level of protection against attacks on
individual DCCP subflows as exists for regular DCCP.</t>
      <t indent="0" pn="section-4-5">As discussed in <xref target="MP_ADDADDR" format="default" sectionFormat="of" derivedContent="Section 3.2.8"/>, 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="MP_JOIN" format="default" sectionFormat="of" derivedContent="Section 3.2.2"/>) is designed to ensure that this
does not set up a subflow to the incorrect host.
However, it could still create unwanted DCCP handshake traffic.  This
feature of MP-DCCP could be a target for denial-of-service exploits,
with malicious participants in MP-DCCP connections encouraging the
recipient to target other hosts in the network.  Therefore,
implementations should consider heuristics at both the
sender and receiver to reduce the impact of this.</t>
      <t indent="0" pn="section-4-6">As described in <xref target="mps" format="default" sectionFormat="of" derivedContent="Section 3.9"/>, an MPS is maintained for an MP-DCCP connection.
If MP-DCCP exposes a minimum MPS across all paths,
any change to one path impacts the sender for all paths.
To mitigate attacks that seek to force a low MPS, MP-DCCP
could detect an attempt to reduce the MPS to less than a minimum MPS and then
stop using these paths.</t>
    </section>
    <section anchor="middlebox" numbered="true" removeInRFC="false" toc="include" pn="section-5">
      <name slugifiedName="name-interactions-with-middlebox">Interactions with Middleboxes</name>
      <t indent="0" pn="section-5-1">Issues from interaction with on-path middleboxes such as NATs, firewalls, proxies,
IDSs, and others have to be considered for all
extensions to standard protocols; otherwise, unexpected reactions of
middleboxes may hinder its deployment. DCCP already provides means to
mitigate the potential impact of middleboxes, in comparison to TCP (see
<xref target="RFC4340" sectionFormat="of" section="16" format="default" derivedLink="https://rfc-editor.org/rfc/rfc4340#section-16" derivedContent="RFC4340"/>). When both hosts are located behind a NAT or
firewall entity, specific measures have to be applied such as the 
simultaneous-open technique specified in <xref target="RFC5596" format="default" sectionFormat="of" derivedContent="RFC5596"/> that updates the asymmetric connection-establishment procedures for DCCP.  Further standardized technologies
addressing middleboxes operating as NATs are provided in <xref target="RFC5597" format="default" sectionFormat="of" derivedContent="RFC5597"/>.</t>
      <t indent="0" pn="section-5-2"><xref target="RFC6773" format="default" sectionFormat="of" derivedContent="RFC6773"/> specifies UDP encapsulation for NAT traversal of DCCP sessions,
similar to other UDP encapsulations such as the Stream Control Transmission Protocol (SCTP) <xref target="RFC6951" format="default" sectionFormat="of" derivedContent="RFC6951"/>. Future
specifications by the IETF could specify other methods for DCCP encapsulation.</t>
      <t indent="0" pn="section-5-3">The security impact of MP-DCCP-aware middleboxes is discussed in <xref target="security" format="default" sectionFormat="of" derivedContent="Section 4"/>.</t>
    </section>
    <section anchor="implementation" numbered="true" removeInRFC="false" toc="include" pn="section-6">
      <name slugifiedName="name-implementation">Implementation</name>
      <t indent="0" pn="section-6-1">The approach described above has been implemented in open source across different testbeds, and a new scheduling algorithm has been extensively tested. Also, 
demonstrations of a laboratory setup have been executed and published; see <xref target="MP-DCCP.Site" format="default" sectionFormat="of" derivedContent="MP-DCCP.Site"/>.</t>
    </section>
    <section anchor="iana-considerations" numbered="true" removeInRFC="false" toc="include" pn="section-7">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <t indent="0" pn="section-7-1">This section provides guidance to the Internet Assigned Numbers Authority (IANA) regarding the registration of values related to the MP extension of the DCCP protocol 
in accordance with the RFC Required policy in <xref target="RFC8126" sectionFormat="of" section="4.7" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8126#section-4.7" derivedContent="RFC8126"/>.  This document defines one new value that has been allocated in the IANA "DCCP Feature Numbers" registry and creates three new registries that have been added in the "Datagram Congestion Control Protocol (DCCP) Parameters" registry group.</t>
      <section anchor="new-multipath-capable-dccp-feature" numbered="true" removeInRFC="false" toc="include" pn="section-7.1">
        <name slugifiedName="name-new-multipath-capable-dccp-">New Multipath Capable DCCP Feature</name>
        <t indent="0" pn="section-7.1-1">Per this document, IANA has assigned a new DCCP feature parameter for negotiating
the support of multipath capability for DCCP sessions between hosts
as described in <xref target="protocol" format="default" sectionFormat="of" derivedContent="Section 3"/>. The following entry in <xref target="ref-add-feature-list" format="default" sectionFormat="of" derivedContent="Table 6"/> has been 
	added to the "Feature Numbers" registry in the DCCP registry group according to <xref target="RFC4340" sectionFormat="of" section="19.4" format="default" derivedLink="https://rfc-editor.org/rfc/rfc4340#section-19.4" derivedContent="RFC4340"/>.</t>
        <table anchor="ref-add-feature-list" align="center" pn="table-6">
          <name slugifiedName="name-addition-to-dccp-feature-nu">Addition to DCCP Feature Numbers Registry</name>
          <thead>
            <tr>
              <th align="left" colspan="1" rowspan="1">Number</th>
              <th align="left" colspan="1" rowspan="1">Description/Meaning</th>
              <th align="left" colspan="1" rowspan="1">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left" colspan="1" rowspan="1">10</td>
              <td align="left" colspan="1" rowspan="1">Multipath Capable</td>
              <td align="left" colspan="1" rowspan="1">RFC 9897</td>
            </tr>
          </tbody>
        </table>
      </section>
      <section anchor="new-mp-dccp-version-registry" numbered="true" removeInRFC="false" toc="include" pn="section-7.2">
        <name slugifiedName="name-new-mp-dccp-versions-regist">New MP-DCCP Versions Registry</name>
        <t indent="0" pn="section-7.2-1"><xref target="mp_capable" format="default" sectionFormat="of" derivedContent="Section 3.1"/> specifies the new 1-byte entry above that includes a 4-bit part to specify the version of the used MP-DCCP implementation. IANA has created a new "MP-DCCP Versions" registry in the DCCP registry group to track the MP-DCCP version. The initial content of this registry is as follows:</t>
        <table anchor="ref-add-version-list" align="center" pn="table-7">
          <name slugifiedName="name-mp-dccp-versions-registry">MP-DCCP Versions Registry</name>
          <thead>
            <tr>
              <th align="left" colspan="1" rowspan="1">Version</th>
              <th align="left" colspan="1" rowspan="1">Value</th>
              <th align="left" colspan="1" rowspan="1">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left" colspan="1" rowspan="1">0</td>
              <td align="left" colspan="1" rowspan="1">0000</td>
              <td align="left" colspan="1" rowspan="1">RFC 9897</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">1-15</td>
              <td align="left" colspan="1" rowspan="1">Unassigned</td>
              <td align="left" colspan="1" rowspan="1"> </td>
            </tr>
          </tbody>
        </table>
        <t indent="0" pn="section-7.2-3">Future MP-DCCP versions 1 to 15 will be assigned from this registry using the RFC Required policy (<xref target="RFC8126" sectionFormat="of" section="4.7" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8126#section-4.7" derivedContent="RFC8126"/>).</t>
      </section>
      <section anchor="new-multipath-option-and-registry" numbered="true" removeInRFC="false" toc="include" pn="section-7.3">
        <name slugifiedName="name-new-multipath-option-type-a">New Multipath Option Type and Registry</name>
        <t indent="0" pn="section-7.3-1">IANA has assigned value 46 in the DCCP "Option Types" registry, as described in <xref target="MP_OPT" format="default" sectionFormat="of" derivedContent="Section 3.2"/>.</t>
        <t indent="0" pn="section-7.3-2">IANA has created a new "Multipath Options" registry within the DCCP registry group. The following entries in <xref target="ref-add-proto-opt-list" format="default" sectionFormat="of" derivedContent="Table 8"/> have been added to the new "Multipath Options" registry. The registry has an upper boundary of 255 in the numeric value field.</t>
        <table anchor="ref-add-proto-opt-list" align="center" pn="table-8">
          <name slugifiedName="name-multipath-options-registry">Multipath Options Registry</name>
          <thead>
            <tr>
              <th align="left" colspan="1" rowspan="1">Multipath Option</th>
              <th align="left" colspan="1" rowspan="1">Name</th>
              <th align="left" colspan="1" rowspan="1">Description</th>
              <th align="left" colspan="1" rowspan="1">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left" colspan="1" rowspan="1">MP_OPT=0</td>
              <td align="left" colspan="1" rowspan="1">MP_CONFIRM</td>
              <td align="left" colspan="1" rowspan="1">Confirm reception/processing of an MP_OPT option</td>
              <td align="left" colspan="1" rowspan="1">
                <xref target="MP_CONFIRM" format="default" sectionFormat="of" derivedContent="Section 3.2.1"/></td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">MP_OPT=1</td>
              <td align="left" colspan="1" rowspan="1">MP_JOIN</td>
              <td align="left" colspan="1" rowspan="1">Join subflow to an existing MP-DCCP connection</td>
              <td align="left" colspan="1" rowspan="1">
                <xref target="MP_JOIN" format="default" sectionFormat="of" derivedContent="Section 3.2.2"/></td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">MP_OPT=2</td>
              <td align="left" colspan="1" rowspan="1">MP_FAST_CLOSE</td>
              <td align="left" colspan="1" rowspan="1">Close an MP-DCCP connection unconditionally</td>
              <td align="left" colspan="1" rowspan="1">
                <xref target="MP_FAST_CLOSE" format="default" sectionFormat="of" derivedContent="Section 3.2.3"/></td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">MP_OPT=3</td>
              <td align="left" colspan="1" rowspan="1">MP_KEY</td>
              <td align="left" colspan="1" rowspan="1">Exchange key material for MP_HMAC</td>
              <td align="left" colspan="1" rowspan="1">
                <xref target="MP_KEY" format="default" sectionFormat="of" derivedContent="Section 3.2.4"/></td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">MP_OPT=4</td>
              <td align="left" colspan="1" rowspan="1">MP_SEQ</td>
              <td align="left" colspan="1" rowspan="1">Multipath sequence number</td>
              <td align="left" colspan="1" rowspan="1">
                <xref target="MP_SEQ" format="default" sectionFormat="of" derivedContent="Section 3.2.5"/></td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">MP_OPT=5</td>
              <td align="left" colspan="1" rowspan="1">MP_HMAC</td>
              <td align="left" colspan="1" rowspan="1">Hash-based message authentication code for MP-DCCP</td>
              <td align="left" colspan="1" rowspan="1">
                <xref target="MP_HMAC" format="default" sectionFormat="of" derivedContent="Section 3.2.6"/></td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">MP_OPT=6</td>
              <td align="left" colspan="1" rowspan="1">MP_RTT</td>
              <td align="left" colspan="1" rowspan="1">Transmit RTT values and calculation parameters</td>
              <td align="left" colspan="1" rowspan="1">
                <xref target="MP_RTT" format="default" sectionFormat="of" derivedContent="Section 3.2.7"/></td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">MP_OPT=7</td>
              <td align="left" colspan="1" rowspan="1">MP_ADDADDR</td>
              <td align="left" colspan="1" rowspan="1">Advertise one or more additional addresses/ports</td>
              <td align="left" colspan="1" rowspan="1">
                <xref target="MP_ADDADDR" format="default" sectionFormat="of" derivedContent="Section 3.2.8"/></td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">MP_OPT=8</td>
              <td align="left" colspan="1" rowspan="1">MP_REMOVEADDR</td>
              <td align="left" colspan="1" rowspan="1">Remove one or more addresses/ports</td>
              <td align="left" colspan="1" rowspan="1">
                <xref target="MP_REMOVEADDR" format="default" sectionFormat="of" derivedContent="Section 3.2.9"/></td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">MP_OPT=9</td>
              <td align="left" colspan="1" rowspan="1">MP_PRIO</td>
              <td align="left" colspan="1" rowspan="1">Change subflow priority</td>
              <td align="left" colspan="1" rowspan="1">
                <xref target="MP_PRIO" format="default" sectionFormat="of" derivedContent="Section 3.2.10"/></td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">MP_OPT=10</td>
              <td align="left" colspan="1" rowspan="1">MP_CLOSE</td>
              <td align="left" colspan="1" rowspan="1">Close an MP-DCCP connection</td>
              <td align="left" colspan="1" rowspan="1">
                <xref target="MP_CLOSE" format="default" sectionFormat="of" derivedContent="Section 3.2.11"/></td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">MP_OPT=11</td>
              <td align="left" colspan="1" rowspan="1">MP_EXP</td>
              <td align="left" colspan="1" rowspan="1">Experimental option for private use</td>
              <td align="left" colspan="1" rowspan="1">
                <xref target="MP_EXP" format="default" sectionFormat="of" derivedContent="Section 3.2.12"/></td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">MP_OPT=12-255</td>
              <td align="left" colspan="1" rowspan="1">Unassigned</td>
              <td align="left" colspan="1" rowspan="1"/>
              <td align="left" colspan="1" rowspan="1"> </td>
            </tr>
          </tbody>
        </table>
        <t indent="0" pn="section-7.3-4">Future Multipath Options with MP_OPT&gt;11 will be assigned from this registry using the RFC Required policy (<xref target="RFC8126" sectionFormat="of" section="4.7" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8126#section-4.7" derivedContent="RFC8126"/>).</t>
      </section>
      <section anchor="new-dccp-reset-code" numbered="true" removeInRFC="false" toc="include" pn="section-7.4">
        <name slugifiedName="name-new-dccp-reset-code">New DCCP-Reset Code</name>
        <t indent="0" pn="section-7.4-1">IANA has assigned a new DCCP-Reset Code, value 13, in the "Reset Codes" registry, with the description "Abrupt MP termination".  Use of this Reset Code is defined in <xref target="MP_FAST_CLOSE" format="default" sectionFormat="of" derivedContent="Section 3.2.3"/>.</t>
      </section>
      <section anchor="new-multipath-key-type-registry" numbered="true" removeInRFC="false" toc="include" pn="section-7.5">
        <name slugifiedName="name-new-multipath-key-type-regi">New Multipath Key Type Registry</name>
        <t indent="0" pn="section-7.5-1">IANA has created a new "Multipath Key Type" registry for this version of the MP-DCCP protocol that contains two different suboptions to the MP_KEY option to identify the MP_KEY Key types in terms of 8-bit values as specified in <xref target="MP_KEY" format="default" sectionFormat="of" derivedContent="Section 3.2.4"/>. See the initial  entries in <xref target="ref-mp_key-sub-opt-list" format="default" sectionFormat="of" derivedContent="Table 9"/> below. Values in the range 1-254 (decimal) inclusive remain unassigned in this specified version 0 of the protocol and will be assigned via the RFC Required policy <xref target="RFC8126" format="default" sectionFormat="of" derivedContent="RFC8126"/> in potential future versions of the MP-DCCP protocol.</t>
        <table anchor="ref-mp_key-sub-opt-list" align="center" pn="table-9">
          <name slugifiedName="name-multipath-key-type-registry">Multipath Key Type Registry with the MP_KEY Key Types for Key Data Exchange on Different Paths</name>
          <thead>
            <tr>
              <th align="left" colspan="1" rowspan="1">Type</th>
              <th align="left" colspan="1" rowspan="1">Name</th>
              <th align="left" colspan="1" rowspan="1">Meaning</th>
              <th align="left" colspan="1" rowspan="1">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left" colspan="1" rowspan="1">0</td>
              <td align="left" colspan="1" rowspan="1">Plain Text</td>
              <td align="left" colspan="1" rowspan="1">Plain text Key</td>
              <td align="left" colspan="1" rowspan="1">
                <xref target="MP_KEY" format="default" sectionFormat="of" derivedContent="Section 3.2.4"/></td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">1-254</td>
              <td align="left" colspan="1" rowspan="1">Unassigned</td>
              <td align="left" colspan="1" rowspan="1"/>
              <td align="left" colspan="1" rowspan="1">
               </td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">255</td>
              <td align="left" colspan="1" rowspan="1">Experimental</td>
              <td align="left" colspan="1" rowspan="1">For private use only</td>
              <td align="left" colspan="1" rowspan="1">
                <xref target="MP_KEY" format="default" sectionFormat="of" derivedContent="Section 3.2.4"/></td>
            </tr>
          </tbody>
        </table>
      </section>
    </section>
  </middle>
  <back>
    <displayreference target="I-D.amend-iccrg-multipath-reordering" to="MULTIPATH-REORDERING"/>
    <displayreference target="I-D.amend-tsvwg-dccp-udp-header-conversion" to="U-DCCP"/>
    <references anchor="sec-combined-references" pn="section-8">
      <name slugifiedName="name-references">References</name>
      <references anchor="sec-normative-references" pn="section-8.1">
        <name slugifiedName="name-normative-references">Normative References</name>
        <reference anchor="DCCP-PARAMETERS" target="https://www.iana.org/assignments/dccp-parameters" quoteTitle="true" derivedAnchor="DCCP-PARAMETERS">
          <front>
            <title>Datagram Congestion Control Protocol (DCCP) Parameters</title>
            <author>
              <organization showOnFrontPage="true">IANA</organization>
            </author>
          </front>
        </reference>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" quoteTitle="true" derivedAnchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
            <abstract>
              <t indent="0">In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC4086" target="https://www.rfc-editor.org/info/rfc4086" quoteTitle="true" derivedAnchor="RFC4086">
          <front>
            <title>Randomness Requirements for Security</title>
            <author fullname="D. Eastlake 3rd" initials="D." surname="Eastlake 3rd"/>
            <author fullname="J. Schiller" initials="J." surname="Schiller"/>
            <author fullname="S. Crocker" initials="S." surname="Crocker"/>
            <date month="June" year="2005"/>
            <abstract>
              <t indent="0">Security systems are built on strong cryptographic algorithms that foil pattern analysis attempts. However, the security of these systems is dependent on generating secret quantities for passwords, cryptographic keys, and similar quantities. The use of pseudo-random processes to generate secret quantities can result in pseudo-security. A sophisticated attacker may find it easier to reproduce the environment that produced the secret quantities and to search the resulting small set of possibilities than to locate the quantities in the whole of the potential number space.</t>
              <t indent="0">Choosing random quantities to foil a resourceful and motivated adversary is surprisingly difficult. This document points out many pitfalls in using poor entropy sources or traditional pseudo-random number generation techniques for generating such quantities. It recommends the use of truly random hardware techniques and shows that the existing hardware on many systems can be used for this purpose. It provides suggestions to ameliorate the problem when a hardware solution is not available, and it gives examples of how large such quantities need to be for some applications. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="106"/>
          <seriesInfo name="RFC" value="4086"/>
          <seriesInfo name="DOI" value="10.17487/RFC4086"/>
        </reference>
        <reference anchor="RFC4340" target="https://www.rfc-editor.org/info/rfc4340" quoteTitle="true" derivedAnchor="RFC4340">
          <front>
            <title>Datagram Congestion Control Protocol (DCCP)</title>
            <author fullname="E. Kohler" initials="E." surname="Kohler"/>
            <author fullname="M. Handley" initials="M." surname="Handley"/>
            <author fullname="S. Floyd" initials="S." surname="Floyd"/>
            <date month="March" year="2006"/>
            <abstract>
              <t indent="0">The Datagram Congestion Control Protocol (DCCP) is a transport protocol that provides bidirectional unicast connections of congestion-controlled unreliable datagrams. DCCP is suitable for applications that transfer fairly large amounts of data and that can benefit from control over the tradeoff between timeliness and reliability. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4340"/>
          <seriesInfo name="DOI" value="10.17487/RFC4340"/>
        </reference>
        <reference anchor="RFC6234" target="https://www.rfc-editor.org/info/rfc6234" quoteTitle="true" derivedAnchor="RFC6234">
          <front>
            <title>US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)</title>
            <author fullname="D. Eastlake 3rd" initials="D." surname="Eastlake 3rd"/>
            <author fullname="T. Hansen" initials="T." surname="Hansen"/>
            <date month="May" year="2011"/>
            <abstract>
              <t indent="0">Federal Information Processing Standard, FIPS</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6234"/>
          <seriesInfo name="DOI" value="10.17487/RFC6234"/>
        </reference>
        <reference anchor="RFC8126" target="https://www.rfc-editor.org/info/rfc8126" quoteTitle="true" derivedAnchor="RFC8126">
          <front>
            <title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
            <author fullname="M. Cotton" initials="M." surname="Cotton"/>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <author fullname="T. Narten" initials="T." surname="Narten"/>
            <date month="June" year="2017"/>
            <abstract>
              <t indent="0">Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA).</t>
              <t indent="0">To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry.</t>
              <t indent="0">This is the third edition of this document; it obsoletes RFC 5226.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="26"/>
          <seriesInfo name="RFC" value="8126"/>
          <seriesInfo name="DOI" value="10.17487/RFC8126"/>
        </reference>
        <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" quoteTitle="true" derivedAnchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <date month="May" year="2017"/>
            <abstract>
              <t indent="0">RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
      </references>
      <references anchor="sec-informative-references" pn="section-8.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="IETF105.Slides" target="https://datatracker.ietf.org/meeting/105/materials/slides-105-tsvwg-sessa-62-dccp-extensions-for-multipath-operation-00" quoteTitle="true" derivedAnchor="IETF105.Slides">
          <front>
            <title>MP-DCCP for enabling transfer of UDP/IP traffic over multiple data paths in multi-connectivity networks</title>
            <author initials="M." surname="Amend" fullname="Markus Amend">
              <organization showOnFrontPage="true"/>
            </author>
            <date month="July" year="2019"/>
          </front>
          <refcontent>IETF 105 Proceedings</refcontent>
        </reference>
        <reference anchor="MP-DCCP.Paper" target="https://doi.org/10.1109/LCN44214.2019.8990746" quoteTitle="true" derivedAnchor="MP-DCCP.Paper">
          <front>
            <title>A Framework for Multiaccess Support for Unreliable Internet Traffic using Multipath DCCP</title>
            <author initials="M." surname="Amend" fullname="Markus Amend">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="E." surname="Bogenfeld" fullname="Eckard Bogenfeld">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M." surname="Cvjetkovic" fullname="Milan Cvjetkovic">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="V." surname="Rakocevic" fullname="Veselin Rakocevic">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M." surname="Pieska" fullname="Marcus Pieska">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="A." surname="Kassler" fullname="Andreas Kassler">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="A." surname="Brunstrom" fullname="Anna Brunstrom">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2019" month="October"/>
          </front>
          <refcontent>2019 IEEE 44th Conference on Local Computer Networks (LCN), pp. 316-323</refcontent>
          <seriesInfo name="DOI" value="10.1109/LCN44214.2019.8990746"/>
        </reference>
        <reference anchor="MP-DCCP.Site" target="https://multipath-dccp.org/" quoteTitle="true" derivedAnchor="MP-DCCP.Site">
          <front>
            <title>Multipath extension for DCCP</title>
            <author>
              <organization showOnFrontPage="true"/>
            </author>
          </front>
        </reference>
        <reference anchor="I-D.amend-iccrg-multipath-reordering" target="https://datatracker.ietf.org/doc/html/draft-amend-iccrg-multipath-reordering-03" quoteTitle="true" derivedAnchor="MULTIPATH-REORDERING">
          <front>
            <title>Multipath sequence maintenance</title>
            <author fullname="Markus Amend" initials="M." surname="Amend">
              <organization showOnFrontPage="true">Deutsche Telekom</organization>
            </author>
            <author fullname="Dirk Von Hugo" initials="D." surname="Von Hugo">
              <organization showOnFrontPage="true">Deutsche Telekom</organization>
            </author>
            <date day="25" month="October" year="2021"/>
            <abstract>
              <t indent="0">This document discusses the issue of packet reordering which occurs as a specific problem in multi-path connections without reliable transport protocols such as TCP. The topic is relevant for devices connected via multiple accesses technologies towards the network as is foreseen, e.g., within Access Traffic Selection, Switching, and Splitting (ATSSS) service of 3rd Generation Partnership Project (3GPP) enabling fixed mobile converged (FMC) scenario.</t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-amend-iccrg-multipath-reordering-03"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="OLIA" target="https://dl.acm.org/doi/10.1145/2413176.2413178" quoteTitle="true" derivedAnchor="OLIA">
          <front>
            <title>MPTCP is not pareto-optimal: performance issues and a possible solution</title>
            <author initials="R." surname="Khalili">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="N." surname="Gast">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M." surname="Popovic">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="U." surname="Upadhyay">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="J." surname="Le Boudec">
              <organization showOnFrontPage="true"/>
            </author>
            <date month="December" year="2012"/>
          </front>
          <refcontent>CoNEXT '12: Proceedings of the 8th international
          conference on Emerging networking experiments and
          technologies, pp. 1-12</refcontent>
          <seriesInfo name="DOI" value="10.1145/2413176.2413178"/>
        </reference>
        <reference anchor="RFC2104" target="https://www.rfc-editor.org/info/rfc2104" quoteTitle="true" derivedAnchor="RFC2104">
          <front>
            <title>HMAC: Keyed-Hashing for Message Authentication</title>
            <author fullname="H. Krawczyk" initials="H." surname="Krawczyk"/>
            <author fullname="M. Bellare" initials="M." surname="Bellare"/>
            <author fullname="R. Canetti" initials="R." surname="Canetti"/>
            <date month="February" year="1997"/>
            <abstract>
              <t indent="0">This document describes HMAC, a mechanism for message authentication using cryptographic hash functions. HMAC can be used with any iterative cryptographic hash function, e.g., MD5, SHA-1, in combination with a secret shared key. The cryptographic strength of HMAC depends on the properties of the underlying hash function. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="2104"/>
          <seriesInfo name="DOI" value="10.17487/RFC2104"/>
        </reference>
        <reference anchor="RFC3711" target="https://www.rfc-editor.org/info/rfc3711" quoteTitle="true" derivedAnchor="RFC3711">
          <front>
            <title>The Secure Real-time Transport Protocol (SRTP)</title>
            <author fullname="M. Baugher" initials="M." surname="Baugher"/>
            <author fullname="D. McGrew" initials="D." surname="McGrew"/>
            <author fullname="M. Naslund" initials="M." surname="Naslund"/>
            <author fullname="E. Carrara" initials="E." surname="Carrara"/>
            <author fullname="K. Norrman" initials="K." surname="Norrman"/>
            <date month="March" year="2004"/>
            <abstract>
              <t indent="0">This document describes the Secure Real-time Transport Protocol (SRTP), a profile of the Real-time Transport Protocol (RTP), which can provide confidentiality, message authentication, and replay protection to the RTP traffic and to the control traffic for RTP, the Real-time Transport Control Protocol (RTCP). [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3711"/>
          <seriesInfo name="DOI" value="10.17487/RFC3711"/>
        </reference>
        <reference anchor="RFC5238" target="https://www.rfc-editor.org/info/rfc5238" quoteTitle="true" derivedAnchor="RFC5238">
          <front>
            <title>Datagram Transport Layer Security (DTLS) over the Datagram Congestion Control Protocol (DCCP)</title>
            <author fullname="T. Phelan" initials="T." surname="Phelan"/>
            <date month="May" year="2008"/>
            <abstract>
              <t indent="0">This document specifies the use of Datagram Transport Layer Security (DTLS) over the Datagram Congestion Control Protocol (DCCP). DTLS provides communications privacy for applications that use datagram transport protocols and allows client/server applications to communicate in a way that is designed to prevent eavesdropping and detect tampering or message forgery. DCCP is a transport protocol that provides a congestion-controlled unreliable datagram service. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5238"/>
          <seriesInfo name="DOI" value="10.17487/RFC5238"/>
        </reference>
        <reference anchor="RFC5596" target="https://www.rfc-editor.org/info/rfc5596" quoteTitle="true" derivedAnchor="RFC5596">
          <front>
            <title>Datagram Congestion Control Protocol (DCCP) Simultaneous-Open Technique to Facilitate NAT/Middlebox Traversal</title>
            <author fullname="G. Fairhurst" initials="G." surname="Fairhurst"/>
            <date month="September" year="2009"/>
            <abstract>
              <t indent="0">This document specifies an update to the Datagram Congestion Control Protocol (DCCP), a connection-oriented and datagram-based transport protocol. The update adds support for the DCCP-Listen packet. This assists DCCP applications to communicate through middleboxes (e.g., a Network Address Port Translator or a DCCP server behind a firewall), where peering endpoints need to initiate communication in a near- simultaneous manner to establish necessary middlebox state. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5596"/>
          <seriesInfo name="DOI" value="10.17487/RFC5596"/>
        </reference>
        <reference anchor="RFC5597" target="https://www.rfc-editor.org/info/rfc5597" quoteTitle="true" derivedAnchor="RFC5597">
          <front>
            <title>Network Address Translation (NAT) Behavioral Requirements for the Datagram Congestion Control Protocol</title>
            <author fullname="R. Denis-Courmont" initials="R." surname="Denis-Courmont"/>
            <date month="September" year="2009"/>
            <abstract>
              <t indent="0">This document defines a set of requirements for NATs handling the Datagram Congestion Control Protocol (DCCP). These requirements allow DCCP applications, such as streaming applications, to operate consistently, and they are very similar to the TCP requirements for NATs, which have already been published by the IETF. Ensuring that NATs meet this set of requirements will greatly increase the likelihood that applications using DCCP will function properly. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="150"/>
          <seriesInfo name="RFC" value="5597"/>
          <seriesInfo name="DOI" value="10.17487/RFC5597"/>
        </reference>
        <reference anchor="RFC6356" target="https://www.rfc-editor.org/info/rfc6356" quoteTitle="true" derivedAnchor="RFC6356">
          <front>
            <title>Coupled Congestion Control for Multipath Transport Protocols</title>
            <author fullname="C. Raiciu" initials="C." surname="Raiciu"/>
            <author fullname="M. Handley" initials="M." surname="Handley"/>
            <author fullname="D. Wischik" initials="D." surname="Wischik"/>
            <date month="October" year="2011"/>
            <abstract>
              <t indent="0">Often endpoints are connected by multiple paths, but communications are usually restricted to a single path per connection. Resource usage within the network would be more efficient were it possible for these multiple paths to be used concurrently. Multipath TCP is a proposal to achieve multipath transport in TCP.</t>
              <t indent="0">New congestion control algorithms are needed for multipath transport protocols such as Multipath TCP, as single path algorithms have a series of issues in the multipath context. One of the prominent problems is that running existing algorithms such as standard TCP independently on each path would give the multipath flow more than its fair share at a bottleneck link traversed by more than one of its subflows. Further, it is desirable that a source with multiple paths available will transfer more traffic using the least congested of the paths, achieving a property called "resource pooling" where a bundle of links effectively behaves like one shared link with bigger capacity. This would increase the overall efficiency of the network and also its robustness to failure.</t>
              <t indent="0">This document presents a congestion control algorithm that couples the congestion control algorithms running on different subflows by linking their increase functions, and dynamically controls the overall aggressiveness of the multipath flow. The result is a practical algorithm that is fair to TCP at bottlenecks while moving traffic away from congested links. This document defines an Experimental Protocol for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6356"/>
          <seriesInfo name="DOI" value="10.17487/RFC6356"/>
        </reference>
        <reference anchor="RFC6773" target="https://www.rfc-editor.org/info/rfc6773" quoteTitle="true" derivedAnchor="RFC6773">
          <front>
            <title>DCCP-UDP: A Datagram Congestion Control Protocol UDP Encapsulation for NAT Traversal</title>
            <author fullname="T. Phelan" initials="T." surname="Phelan"/>
            <author fullname="G. Fairhurst" initials="G." surname="Fairhurst"/>
            <author fullname="C. Perkins" initials="C." surname="Perkins"/>
            <date month="November" year="2012"/>
            <abstract>
              <t indent="0">This document specifies an alternative encapsulation of the Datagram Congestion Control Protocol (DCCP), referred to as DCCP-UDP. This encapsulation allows DCCP to be carried through the current generation of Network Address Translation (NAT) middleboxes without modification of those middleboxes. This document also updates the Session Description Protocol (SDP) information for DCCP defined in RFC 5762. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6773"/>
          <seriesInfo name="DOI" value="10.17487/RFC6773"/>
        </reference>
        <reference anchor="RFC6904" target="https://www.rfc-editor.org/info/rfc6904" quoteTitle="true" derivedAnchor="RFC6904">
          <front>
            <title>Encryption of Header Extensions in the Secure Real-time Transport Protocol (SRTP)</title>
            <author fullname="J. Lennox" initials="J." surname="Lennox"/>
            <date month="April" year="2013"/>
            <abstract>
              <t indent="0">The Secure Real-time Transport Protocol (SRTP) provides authentication, but not encryption, of the headers of Real-time Transport Protocol (RTP) packets. However, RTP header extensions may carry sensitive information for which participants in multimedia sessions want confidentiality. This document provides a mechanism, extending the mechanisms of SRTP, to selectively encrypt RTP header extensions in SRTP.</t>
              <t indent="0">This document updates RFC 3711, the Secure Real-time Transport Protocol specification, to require that all future SRTP encryption transforms specify how RTP header extensions are to be encrypted.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6904"/>
          <seriesInfo name="DOI" value="10.17487/RFC6904"/>
        </reference>
        <reference anchor="RFC6951" target="https://www.rfc-editor.org/info/rfc6951" quoteTitle="true" derivedAnchor="RFC6951">
          <front>
            <title>UDP Encapsulation of Stream Control Transmission Protocol (SCTP) Packets for End-Host to End-Host Communication</title>
            <author fullname="M. Tuexen" initials="M." surname="Tuexen"/>
            <author fullname="R. Stewart" initials="R." surname="Stewart"/>
            <date month="May" year="2013"/>
            <abstract>
              <t indent="0">This document describes a simple method of encapsulating Stream Control Transmission Protocol (SCTP) packets into UDP packets and its limitations. This allows the usage of SCTP in networks with legacy NATs that do not support SCTP. It can also be used to implement SCTP on hosts without directly accessing the IP layer, for example, implementing it as part of the application without requiring special privileges.</t>
              <t indent="0">Please note that this document only describes the functionality required within an SCTP stack to add on UDP encapsulation, providing only those mechanisms for two end-hosts to communicate with each other over UDP ports. In particular, it does not provide mechanisms to determine whether UDP encapsulation is being used by the peer, nor the mechanisms for determining which remote UDP port number can be used. These functions are out of scope for this document.</t>
              <t indent="0">This document covers only end-hosts and not tunneling (egress or ingress) endpoints.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6951"/>
          <seriesInfo name="DOI" value="10.17487/RFC6951"/>
        </reference>
        <reference anchor="RFC7323" target="https://www.rfc-editor.org/info/rfc7323" quoteTitle="true" derivedAnchor="RFC7323">
          <front>
            <title>TCP Extensions for High Performance</title>
            <author fullname="D. Borman" initials="D." surname="Borman"/>
            <author fullname="B. Braden" initials="B." surname="Braden"/>
            <author fullname="V. Jacobson" initials="V." surname="Jacobson"/>
            <author fullname="R. Scheffenegger" initials="R." role="editor" surname="Scheffenegger"/>
            <date month="September" year="2014"/>
            <abstract>
              <t indent="0">This document specifies a set of TCP extensions to improve performance over paths with a large bandwidth * delay product and to provide reliable operation over very high-speed paths. It defines the TCP Window Scale (WS) option and the TCP Timestamps (TS) option and their semantics. The Window Scale option is used to support larger receive windows, while the Timestamps option can be used for at least two distinct mechanisms, Protection Against Wrapped Sequences (PAWS) and Round-Trip Time Measurement (RTTM), that are also described herein.</t>
              <t indent="0">This document obsoletes RFC 1323 and describes changes from it.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7323"/>
          <seriesInfo name="DOI" value="10.17487/RFC7323"/>
        </reference>
        <reference anchor="RFC8041" target="https://www.rfc-editor.org/info/rfc8041" quoteTitle="true" derivedAnchor="RFC8041">
          <front>
            <title>Use Cases and Operational Experience with Multipath TCP</title>
            <author fullname="O. Bonaventure" initials="O." surname="Bonaventure"/>
            <author fullname="C. Paasch" initials="C." surname="Paasch"/>
            <author fullname="G. Detal" initials="G." surname="Detal"/>
            <date month="January" year="2017"/>
            <abstract>
              <t indent="0">This document discusses both use cases and operational experience with Multipath TCP (MPTCP) in real networks. It lists several prominent use cases where Multipath TCP has been considered and is being used. It also gives insight to some heuristics and decisions that have helped to realize these use cases and suggests possible improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8041"/>
          <seriesInfo name="DOI" value="10.17487/RFC8041"/>
        </reference>
        <reference anchor="RFC8684" target="https://www.rfc-editor.org/info/rfc8684" quoteTitle="true" derivedAnchor="RFC8684">
          <front>
            <title>TCP Extensions for Multipath Operation with Multiple Addresses</title>
            <author fullname="A. Ford" initials="A." surname="Ford"/>
            <author fullname="C. Raiciu" initials="C." surname="Raiciu"/>
            <author fullname="M. Handley" initials="M." surname="Handley"/>
            <author fullname="O. Bonaventure" initials="O." surname="Bonaventure"/>
            <author fullname="C. Paasch" initials="C." surname="Paasch"/>
            <date month="March" year="2020"/>
            <abstract>
              <t indent="0">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 improve user experience through higher throughput and improved resilience to network failure.</t>
              <t indent="0">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 indent="0">This document specifies v1 of Multipath TCP, obsoleting v0 as specified in RFC 6824, through clarifications and modifications primarily driven by deployment experience.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8684"/>
          <seriesInfo name="DOI" value="10.17487/RFC8684"/>
        </reference>
        <reference anchor="RFC9293" target="https://www.rfc-editor.org/info/rfc9293" quoteTitle="true" derivedAnchor="RFC9293">
          <front>
            <title>Transmission Control Protocol (TCP)</title>
            <author fullname="W. Eddy" initials="W." role="editor" surname="Eddy"/>
            <date month="August" year="2022"/>
            <abstract>
              <t indent="0">This document specifies the Transmission Control Protocol (TCP). TCP is an important transport-layer protocol in the Internet protocol stack, and it has continuously evolved over decades of use and growth of the Internet. Over this time, a number of changes have been made to TCP as it was specified in RFC 793, though these have only been documented in a piecemeal fashion. This document collects and brings those changes together with the protocol specification from RFC 793. This document obsoletes RFC 793, as well as RFCs 879, 2873, 6093, 6429, 6528, and 6691 that updated parts of RFC 793. It updates RFCs 1011 and 1122, and it should be considered as a replacement for the portions of those documents dealing with TCP requirements. It also updates RFC 5961 by adding a small clarification in reset handling while in the SYN-RECEIVED state. The TCP header control bits from RFC 793 have also been updated based on RFC 3168.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="7"/>
          <seriesInfo name="RFC" value="9293"/>
          <seriesInfo name="DOI" value="10.17487/RFC9293"/>
        </reference>
        <reference anchor="TS23.501" target="https://www.3gpp.org/ftp//Specs/archive/23_series/23.501/23501-g70.zip" quoteTitle="true" derivedAnchor="TS23.501">
          <front>
            <title>System architecture for the 5G System; Stage 2; Release 16</title>
            <author>
              <organization showOnFrontPage="true">3GPP</organization>
            </author>
            <date year="2020" month="December"/>
          </front>
          <refcontent>Version 16.7.0, Release 16</refcontent>
        </reference>
        <reference anchor="I-D.amend-tsvwg-dccp-udp-header-conversion" target="https://datatracker.ietf.org/doc/html/draft-amend-tsvwg-dccp-udp-header-conversion-01" quoteTitle="true" derivedAnchor="U-DCCP">
          <front>
            <title>Lossless and overhead free DCCP - UDP header conversion (U-DCCP)</title>
            <author fullname="Markus Amend" initials="M." surname="Amend">
              <organization showOnFrontPage="true">Deutsche Telekom</organization>
            </author>
            <author fullname="Anna Brunstrom" initials="A." surname="Brunstrom">
              <organization showOnFrontPage="true">Karlstad University</organization>
            </author>
            <author fullname="Andreas Kassler" initials="A." surname="Kassler">
              <organization showOnFrontPage="true">Karlstad University</organization>
            </author>
            <author fullname="Veselin Rakocevic" initials="V." surname="Rakocevic">
              <organization showOnFrontPage="true">City University of London</organization>
            </author>
            <date day="8" month="July" year="2019"/>
            <abstract>
              <t indent="0">The Datagram Congestion Control Protocol (DCCP) is a transport-layer protocol that provides upper layers with the ability to use non- reliable congestion-controlled flows. DCCP is not widely deployed in the Internet, and the reason for that can be defined as a typical example of a chicken-egg problem. Even if an application developer decided to use DCCP, the middle-boxes like firewalls and NATs would prevent DCCP end-to-end since they lack support for DCCP. Moreover, as long as the protocol penetration of DCCP does not increase, the middle-boxes will not handle DCCP properly. To overcome this challenge, NAT/NATP traversal and UDP encapsulation for DCCP is already defined. However, the former requires special middle-box support and the latter introduces overhead. The recent proposal of a multipath extension for DCCP further underlines the challenge of efficient middle-box passing as its main goal is to be applied over the Internet, traversing numerous uncontrolled middle-boxes. This document introduces a new solution which disguises DCCP during transmission as UDP without requiring middle-box modification or introducing any overhead.</t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-amend-tsvwg-dccp-udp-header-conversion-01"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
      </references>
    </references>
    <section anchor="diff_mptcp" numbered="true" removeInRFC="false" toc="include" pn="section-appendix.a">
      <name slugifiedName="name-differences-from-multipath-">Differences from Multipath TCP</name>
      <t indent="0" pn="section-appendix.a-1">This appendix is informative.</t>
      <t indent="0" pn="section-appendix.a-2">MP-DCCP is similar to Multipath TCP <xref target="RFC8684" format="default" sectionFormat="of" derivedContent="RFC8684"/> in that it
extends the related basic DCCP transport protocol <xref target="RFC4340" format="default" sectionFormat="of" derivedContent="RFC4340"/> with
multipath capabilities in the same way as Multipath TCP extends TCP
<xref target="RFC9293" format="default" sectionFormat="of" derivedContent="RFC9293"/>.
However, because of the differences between the underlying TCP and DCCP
protocols, the transport characteristics of MPTCP and MP-DCCP are
different.</t>
      <t indent="0" pn="section-appendix.a-3"><xref target="table_tcp_dccp_comp" format="default" sectionFormat="of" derivedContent="Table 10"/> compares the protocol characteristics of TCP
and DCCP, which are by nature inherited by their respective multipath
extensions.  A major difference lies in the delivery of the payload, which
for TCP is an exact copy of the generated byte stream. DCCP behaves
differently and does not guarantee the delivery of any payload nor the
order of delivery.
Since this is mainly affecting the receiving endpoint of a TCP or
DCCP communication, many similarities on the sender side can be identified.
Both transport protocols share the 3-way initiation of a
communication and both employ congestion control to adapt the sending
rate to the path characteristics.</t>
      <table anchor="table_tcp_dccp_comp" align="center" pn="table-10">
        <name slugifiedName="name-tcp-and-dccp-protocol-compa">TCP and DCCP Protocol Comparison</name>
        <thead>
          <tr>
            <th align="left" colspan="1" rowspan="1">Feature</th>
            <th align="left" colspan="1" rowspan="1">TCP</th>
            <th align="left" colspan="1" rowspan="1">DCCP</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left" colspan="1" rowspan="1">Full-Duplex</td>
            <td align="left" colspan="1" rowspan="1">yes</td>
            <td align="left" colspan="1" rowspan="1">yes</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">Connection-Oriented</td>
            <td align="left" colspan="1" rowspan="1">yes</td>
            <td align="left" colspan="1" rowspan="1">yes</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">Header option space</td>
            <td align="left" colspan="1" rowspan="1">40 bytes</td>
            <td align="left" colspan="1" rowspan="1">&lt; 1008 bytes or PMTU</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">Data transfer</td>
            <td align="left" colspan="1" rowspan="1">reliable</td>
            <td align="left" colspan="1" rowspan="1">unreliable</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">Packet-loss handling</td>
            <td align="left" colspan="1" rowspan="1">retransmission</td>
            <td align="left" colspan="1" rowspan="1">report only</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">Ordered data delivery</td>
            <td align="left" colspan="1" rowspan="1">yes</td>
            <td align="left" colspan="1" rowspan="1">no</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">Sequence numbers</td>
            <td align="left" colspan="1" rowspan="1">one per byte</td>
            <td align="left" colspan="1" rowspan="1">one per PDU</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">Flow control</td>
            <td align="left" colspan="1" rowspan="1">yes</td>
            <td align="left" colspan="1" rowspan="1">no</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">Congestion control</td>
            <td align="left" colspan="1" rowspan="1">yes</td>
            <td align="left" colspan="1" rowspan="1">yes</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">ECN support</td>
            <td align="left" colspan="1" rowspan="1">yes</td>
            <td align="left" colspan="1" rowspan="1">yes</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">Selective ACK</td>
            <td align="left" colspan="1" rowspan="1">yes</td>
            <td align="left" colspan="1" rowspan="1">depends on congestion control</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">Fix message boundaries</td>
            <td align="left" colspan="1" rowspan="1">no</td>
            <td align="left" colspan="1" rowspan="1">yes</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">Path MTU discovery</td>
            <td align="left" colspan="1" rowspan="1">yes</td>
            <td align="left" colspan="1" rowspan="1">yes</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">Fragmentation</td>
            <td align="left" colspan="1" rowspan="1">yes</td>
            <td align="left" colspan="1" rowspan="1">no</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">SYN flood protection</td>
            <td align="left" colspan="1" rowspan="1">yes</td>
            <td align="left" colspan="1" rowspan="1">no</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">Half-open connections</td>
            <td align="left" colspan="1" rowspan="1">yes</td>
            <td align="left" colspan="1" rowspan="1">no</td>
          </tr>
        </tbody>
      </table>
      <t indent="0" pn="section-appendix.a-5">Consequently, the multipath characteristics shown in
<xref target="table_mptcp_mpdccp_comp" format="default" sectionFormat="of" derivedContent="Table 11"/> are the same, supporting volatile paths
that have varying capacities and latency, session handovers, and path
aggregation capabilities. All of these features profit by the existence of
congestion control.</t>
      <table anchor="table_mptcp_mpdccp_comp" align="center" pn="table-11">
        <name slugifiedName="name-mptcp-and-mp-dccp-protocol-">MPTCP and MP-DCCP Protocol Comparison</name>
        <thead>
          <tr>
            <th align="left" colspan="1" rowspan="1">Feature</th>
            <th align="left" colspan="1" rowspan="1">MPTCP</th>
            <th align="left" colspan="1" rowspan="1">MP-DCCP</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left" colspan="1" rowspan="1">Volatile paths</td>
            <td align="left" colspan="1" rowspan="1">yes</td>
            <td align="left" colspan="1" rowspan="1">yes</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">Session handover</td>
            <td align="left" colspan="1" rowspan="1">yes</td>
            <td align="left" colspan="1" rowspan="1">yes</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">Path aggregation</td>
            <td align="left" colspan="1" rowspan="1">yes</td>
            <td align="left" colspan="1" rowspan="1">yes</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">Data reordering</td>
            <td align="left" colspan="1" rowspan="1">yes</td>
            <td align="left" colspan="1" rowspan="1">optional</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">Expandability</td>
            <td align="left" colspan="1" rowspan="1">limited by TCP header</td>
            <td align="left" colspan="1" rowspan="1">flexible</td>
          </tr>
        </tbody>
      </table>
      <t indent="0" pn="section-appendix.a-7">Therefore, the sender logic is not much different between MP-DCCP and
MPTCP.</t>
      <t indent="0" pn="section-appendix.a-8">The receiver side for MP-DCCP has to deal with the unreliable delivery provided by 
DCCP. The multipath sequence numbers included in MP-DCCP (see <xref target="MP_SEQ" format="default" sectionFormat="of" derivedContent="Section 3.2.5"/>) facilitates
adding optional mechanisms for data stream packet reordering 
at the receiver.  Information from the MP_RTT Multipath Option (<xref target="MP_RTT" format="default" sectionFormat="of" derivedContent="Section 3.2.7"/>), 
DCCP path sequencing, and the DCCP Timestamp Option provide further means 
for advanced reordering approaches, e.g., as proposed in <xref target="I-D.amend-iccrg-multipath-reordering" format="default" sectionFormat="of" derivedContent="MULTIPATH-REORDERING"/>.
However, such mechanisms do not affect interoperability
and are not part of the MP-DCCP protocol.  Many 
applications that use unreliable transport protocols can also inherently process 
out-of-sequence data (e.g., through adaptive audio and video buffers), 
so additional reordering support might not be necessary. The addition of optional 
reordering mechanisms are likely to be needed when the 
different DCCP subflows are routed across paths with different latencies. 
In theory, applications using DCCP are aware that packet reordering could 
occur, because DCCP does not provide mechanisms to restore the original packet order.</t>
      <t indent="0" pn="section-appendix.a-9">In contrast to TCP, the receiver processing for MPTCP adopted a rigid
"just wait" approach, because TCP guarantees reliable in-order delivery.</t>
    </section>
    <section anchor="acknowledgments" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.b">
      <name slugifiedName="name-acknowledgments">Acknowledgments</name>
      <t indent="0" pn="section-appendix.b-1"><xref target="RFC8684" format="default" sectionFormat="of" derivedContent="RFC8684"/> defines Multipath TCP and provides important
      inputs for this specification.</t>
      <t indent="0" pn="section-appendix.b-2">The authors gratefully acknowledge significant input into this
      document from <contact fullname="Dirk von Hugo"/>, <contact fullname="Nathalie Romo Moreno"/>, <contact fullname="Omar Nassef"/>,
      <contact fullname="Mohamed Boucadair"/>, <contact fullname="Simone       Ferlin"/>, <contact fullname="Olivier Bonaventure"/>, <contact fullname="Gorry Fairhurst"/>, and <contact fullname="Behcet       Sarikaya"/>.</t>
    </section>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.c">
      <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
      <author initials="M." surname="Amend" fullname="Markus Amend" role="editor">
        <organization abbrev="DT" showOnFrontPage="true">Deutsche Telekom</organization>
        <address>
          <postal>
            <street>Deutsche-Telekom-Allee 9</street>
            <city>Darmstadt</city>
            <code>64295</code>
            <country>Germany</country>
          </postal>
          <email>Markus.Amend@telekom.de</email>
        </address>
      </author>
      <author initials="A." surname="Brunstrom" fullname="Anna Brunstrom">
        <organization showOnFrontPage="true">Karlstad University</organization>
        <address>
          <postal>
            <street>Universitetsgatan 2</street>
            <city>Karlstad</city>
            <code>651 88</code>
            <country>Sweden</country>
          </postal>
          <email>anna.brunstrom@kau.se</email>
        </address>
      </author>
      <author initials="A." surname="Kassler" fullname="Andreas Kassler">
        <organization showOnFrontPage="true">Karlstad University</organization>
        <address>
          <postal>
            <street>Universitetsgatan 2</street>
            <city>Karlstad</city>
            <code>651 88</code>
            <country>Sweden</country>
          </postal>
          <email>andreas.kassler@kau.se</email>
        </address>
      </author>
      <author initials="V." surname="Rakocevic" fullname="Veselin Rakocevic">
        <organization showOnFrontPage="true">City St George's, University of London</organization>
        <address>
          <postal>
            <street>Northampton Square</street>
            <city>London</city>
            <country>United Kingdom</country>
          </postal>
          <email>veselin.rakocevic.1@city.ac.uk</email>
        </address>
      </author>
      <author initials="S." surname="Johnson" fullname="Stephen Johnson">
        <organization showOnFrontPage="true">BT</organization>
        <address>
          <postal>
            <street>Adastral Park</street>
            <city>Martlesham Heath</city>
            <code>IP5 3RE</code>
            <country>United Kingdom</country>
          </postal>
          <email>stephen.h.johnson@bt.com</email>
        </address>
      </author>
    </section>
  </back>
</rfc>
