<?xml version='1.0'encoding='utf-8'?>encoding='UTF-8'?> <!DOCTYPE rfc [ <!ENTITY nbsp " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY wj "⁠"> ]> <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"prepTime="2025-04-29T07:56:08" indexInclude="true" scripts="Common,Latin" tocDepth="3"> <!-- xml2rfc v2v3 conversion 3.28.1tocDepth="3" xml:lang="en"> <!--[rfced] Please note that the title has been updated as follows. The abbreviation has been expanded per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review. Original: DCCP Extensions for Multipath Operation with Multiple Addresses Current: Datagram Congestion Control Protocol (DCCP) Extensions for Multipath Operation with Multiple Addresses --> <front> <title abbrev="MultipathDCCP">DCCPDCCP">Datagram Congestion Control Protocol (DCCP) Extensions for Multipath Operation with Multiple Addresses</title> <seriesInfoname="Internet-Draft" value="draft-ietf-tsvwg-multipath-dccp-24" stream="IETF"/>name="RFC" value="9897"/> <author initials="M." surname="Amend" fullname="Markus Amend" role="editor"> <organizationabbrev="DT" showOnFrontPage="true">Deutscheabbrev="DT">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<organization>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<organization>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,<organization>City, 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><organization>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> <datemonth="04" year="2025" day="29"/> <area>transport</area> <workgroup>Transport Area Working Group</workgroup> <keyword>Internet-Draft</keyword> <abstract pn="section-abstract"> <t indent="0" pn="section-abstract-1">Datagrammonth="October" year="2025"/> <area>WIT</area> <workgroup>tsvwg</workgroup> <!-- [rfced] Please insert any keywords (beyond those that appear in the title) for use on https://www.rfc-editor.org/search. --> <abstract> <t>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<t>Use cases for Multipath DCCP (MP-DCCP) include mobile devices (e.g.,handsets,handsets and vehicles) and residential home gateways that maintain simultaneous connections to distinct networktypes,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<t>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 Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. </t> <t indent="0" pn="section-boilerplate.1-2"> Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at <eref target="https://datatracker.ietf.org/drafts/current/" brackets="none"/>. </t> <t indent="0" pn="section-boilerplate.1-3"> Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." </t> <t indent="0" pn="section-boilerplate.1-4"> This Internet-Draft will expire on 31 October 2025. </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) 2025 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-handshaking-procedu">MP-DCCP Handshaking 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-subflows-">Maximum number of Subflows 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-acknowledgments">Acknowledgments</xref></t> </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-iana-considerations">IANA Considerations</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-new-multipath-capable-dccp-">New Multipath Capable DCCP feature</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-new-mp-dccp-version-registr">New MP-DCCP version registry</xref></t> </li> <li pn="section-toc.1-1.8.2.3"> <t indent="0" pn="section-toc.1-1.8.2.3.1"><xref derivedContent="8.3" format="counter" sectionFormat="of" target="section-8.3"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-new-multipath-option-and-re">New Multipath option and registry</xref></t> </li> <li pn="section-toc.1-1.8.2.4"> <t indent="0" pn="section-toc.1-1.8.2.4.1"><xref derivedContent="8.4" format="counter" sectionFormat="of" target="section-8.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.8.2.5"> <t indent="0" pn="section-toc.1-1.8.2.5.1"><xref derivedContent="8.5" format="counter" sectionFormat="of" target="section-8.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.9"> <t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="9" format="counter" sectionFormat="of" target="section-9"/>. <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.9.2"> <li pn="section-toc.1-1.9.2.1"> <t indent="0" pn="section-toc.1-1.9.2.1.1"><xref derivedContent="9.1" format="counter" sectionFormat="of" target="section-9.1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t> </li> <li pn="section-toc.1-1.9.2.2"> <t indent="0" pn="section-toc.1-1.9.2.2.1"><xref derivedContent="9.2" format="counter" sectionFormat="of" target="section-9.2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t> </li> </ul> </li> <li pn="section-toc.1-1.10"> <t indent="0" pn="section-toc.1-1.10.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.11"> <t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t> </li> </ul> </section> </toc></front> <middle> <sectionanchor="intro" numbered="true" removeInRFC="false" toc="include" pn="section-1"> <name slugifiedName="name-introduction">Introduction</name> <t indent="0" pn="section-1-1">Datagramanchor="intro"> <name>Introduction</name> <t>The Datagram Congestion Control Protocol (DCCP) <xreftarget="RFC4340" format="default" sectionFormat="of" derivedContent="RFC4340"/>target="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 insection 1 of<xref target="RFC4340"format="default"sectionFormat="of"derivedContent="RFC4340"/>,section="1"/> such as the reliable handshake process insection 4.7<xref target="RFC4340" sectionFormat="of" section="4.7"/> and the reliable negotiation of features insection 4.5.<xref target="RFC4340" sectionFormat="of" section="4.5"/>. These are an important basis for this document. <!--[rfced] Please clarify what "This" refers to in the following sentence - is it "These fundamentals"? Current: This also applies to the DCCP sequencing scheme, which is packet-based(section 4.2),(Section 4.2 of [RFC4340]) and the principles for loss and retransmission of features as described in more detail insection 6.6.3.Section 6.6.3 of [RFC4340]. Perhaps: These fundamentals also apply to the DCCP sequencing scheme, which is packet-based (Section 4.2 of [RFC4340]), and to the principles for loss and retransmission of features as described in more detail in Section 6.6.3 of [RFC4340]. --> This also applies to the DCCP sequencing scheme, which is packet-based (<xref target="RFC4340" sectionFormat="of" section="4.2"/>), and the principles for loss and retransmission of features as described in more detail in <xref target="RFC4340" sectionFormat="of" section="6.6.3"/>. This document specifies a set of protocol changes that add multipath support toDCCP; specifically,DCCP, specifically support for signaling and setting up multiple paths(a.k.a,(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<t>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 enableto tradeoffthe trade-off of timeliness and reliability, which is important for low-latency applications that do not require guaranteed deliveryservices,services such as Audio/Video streaming.</t><t indent="0" pn="section-1-3">In<!--[rfced] Please clarify the latter part of this sentence, specifically "between" and the slash ("/"). Is the intended meaning that hybrid access networks combine access between the user equipment "or" residential gateway "and" an operator network (option A) or is it between the user equipment "and" a residential gateway within an operator network (option B)? Original: In addition to the integration into DCCP services, implementers or future specification could choose MP-DCCP for other use cases like 3GPP 5G multi-access solutions (e.g., Access Traffic Steering, Switching, and Splitting (ATSSS) specified in [TS23.501]) or hybrid access networks that either combine a 3GPP and a non-3GPP access or a fixed and cellular access between user-equipment/residential gateway and operator network. Perhaps A: 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) as specified in [TS23.501]) or hybrid access networks that combine either 3GPP and non-3GPP access or fixed and cellular access between the user equipment or residential gateway and an operator network. or Perhaps B: 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) as specified in [TS23.501]) or hybrid access networks that combine either 3GPP and non-3GPP access or fixed and cellular access between the user equipment and residential gateway within an operator network. --> <t>In addition to the integration into DCCP services, implementers or future specification could choose MP-DCCP for other use cases like 3GPP 5G multi-access solutions (e.g., Access Traffic Steering, Switching, and Splitting (ATSSS) specified in <xreftarget="TS23.501" format="default" sectionFormat="of" derivedContent="TS23.501"/>)target="TS23.501"/>) or hybrid access networks that either combine a 3GPP and a non-3GPP access or a fixed and cellular access between user-equipment/residential gateway and operator network. MP-DCCP can be used in these scenarios for load balancing, seamless sessionhandoverhandover, and bandwidth aggregation when non-DCCP trafficlikesuch as IP,UDPUDP, or TCP is encapsulated into MP-DCCP. More details on potential use cases for MP-DCCP are provided in <xreftarget="multipath-dccp.org" format="default" sectionFormat="of" derivedContent="multipath-dccp.org"/>,target="MP-DCCP.Site"/>, <xreftarget="IETF105.Slides" format="default" sectionFormat="of" derivedContent="IETF105.Slides"/>,target="IETF105.Slides"/>, and <xreftarget="MP-DCCP.Paper" format="default" sectionFormat="of" derivedContent="MP-DCCP.Paper"/>.target="MP-DCCP.Paper"/>. All of these use cases profit from an Open Source Linux reference implementation provided under <xreftarget="multipath-dccp.org" format="default" sectionFormat="of" derivedContent="multipath-dccp.org"/>.</t> <t indent="0" pn="section-1-4">Thetarget="MP-DCCP.Site"/>.</t> <t>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)etc.) that do not support DCCP.AHowever, a possible method is defined in <xreftarget="RFC6773" format="default" sectionFormat="of" derivedContent="RFC6773"/> or istarget="RFC6773"/> and considered in <xreftarget="I-D.amend-tsvwg-dccp-udp-header-conversion" format="default" sectionFormat="of" derivedContent="I-D.amend-tsvwg-dccp-udp-header-conversion"/>target="I-D.amend-tsvwg-dccp-udp-header-conversion"/> to achieve the same with less overhead.</t><t indent="0" pn="section-1-5">MP-DCCP<t>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 <xreftarget="MP-DCCP.Paper" format="default" sectionFormat="of" derivedContent="MP-DCCP.Paper"/>,target="MP-DCCP.Paper"/>, and take into account the interaction of the protocol with the further elements required formulti-pathmultipath transport.</t> <sectionanchor="mpdccp_network_stack" numbered="true" removeInRFC="false" toc="include" pn="section-1.1"> <name slugifiedName="name-multipath-dccp-in-the-netwo">Multipathanchor="mpdccp_network_stack"> <name>Multipath DCCP in the Networking Stack</name><t indent="0" pn="section-1.1-1">MP-DCCP<t>MP-DCCP provides a set of features to DCCP; <xreftarget="ref-comparison-of-standard-dccp-and-mp-dccp-protocol-stacks" format="default" sectionFormat="of" derivedContent="Figure 1"/>target="ref-comparison-of-standard-dccp-and-mp-dccp-protocol-stacks"/> 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> <figureanchor="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">Comparisonanchor="ref-comparison-of-standard-dccp-and-mp-dccp-protocol-stacks"> <name>Comparison ofstandardStandard DCCP and MP-DCCPprotocol stacks</name> <artwork align="left" pn="section-1.1-2.1"><![CDATA[Protocol Stacks</name> <artwork><![CDATA[ +-------------------------------+ | Application | +---------------+ +-------------------------------+ | Application | | MP-DCCP | +---------------+ + - - - - - - - + - - - - - - - + | DCCP | |Subflow (DCCP) |Subflow (DCCP) | +---------------+ +-------------------------------+ | IP | | IP | IP | +---------------++-------------------------------+ ]]></artwork>+-------------------------------+]]></artwork> </figure><t indent="0" pn="section-1.1-3">A CLI<t>A command-line interface (CLI) at the endpoint (or another method) could be used to configure and manage the DCCPConnections.connections. This could be extended to also support MP-DCCP, but this specification does not definethis.</t>it.</t> </section> <sectionanchor="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">Thisanchor="terminology"> <name>Terminology</name> <t>This document uses terms that are either specific for multipath transport as defined in <xreftarget="RFC8684" format="default" sectionFormat="of" derivedContent="RFC8684"/>target="RFC8684"/> oraredefined in the context of MP-DCCP, as follows:</t><t indent="0" pn="section-1.2-2">Path: A<dl spacing="normal" newline="false"> <dt>Path:</dt><dd><t>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 <xreftarget="RFC8684" format="default" sectionFormat="of" derivedContent="RFC8684"/>target="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 spacing="normal" bare="false" empty="false" indent="3" pn="section-1.2-3"> <li pn="section-1.2-3.1"> <t indent="0" pn="section-1.2-3.1.1">IPv6:<ul> <li>IPv6: [2001:db8:3333:4444:5555:6666:7777:8888]:1234,[2001:db8:3333:4444:cccc:dddd:eeee:ffff]:4321</t> </li> <li pn="section-1.2-3.2"> <t indent="0" pn="section-1.2-3.2.1">IPv4:[2001:db8:3333:4444:cccc:dddd:eeee:ffff]:4321</li> <li>IPv4: 203.0.113.1:1234,203.0.113.2:4321</t> </li> </ul> <t indent="0" pn="section-1.2-4">Subflow: A subflow refers to a203.0.113.2:4321</li> </ul></dd> <dt>Subflow:</dt><dd>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 singleconnection.</t> <t indent="0" pn="section-1.2-5">(MP-DCCP) Connection: Aconnection.</dd> <dt>(MP-DCCP) Connection:</dt><dd>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 theapplication.</t> <t indent="0" pn="section-1.2-6">Connectionapplication.</dd> <dt>Connection Identifier(CI): A(CI):</dt><dd>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 thepeers.</t> <t indent="0" pn="section-1.2-7">Host: Anpeers.</dd> <dt>Host:</dt><dd>An end hostoperatingthat operates an MP-DCCPimplementation,implementation and eitherinitiatinginitiates oracceptingaccepts an MP-DCCPconnection.</t> <t indent="0" pn="section-1.2-8">'+': Theconnection.</dd> <dt>'+':</dt><dd>The plus symbol means the concatenation ofvalues.</t> <t indent="0" pn="section-1.2-9">Invalues.</dd> </dl> <t>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 <xreftarget="protocol" format="default" sectionFormat="of" derivedContent="Section 3"/>.</t>target="protocol"/>.</t> </section> <sectionanchor="requirements-language" numbered="true" removeInRFC="false" toc="include" pn="section-1.3"> <name slugifiedName="name-requirements-language">Requirementsanchor="requirements-language"> <name>Requirements Language</name><t indent="0" pn="section-1.3-1">The<t> The key words"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY","<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and"OPTIONAL""<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described inBCP 14BCP 14 <xreftarget="RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/>target="RFC2119"/> <xreftarget="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/>target="RFC8174"/> when, and only when, they appear in all capitals, as shownhere.</t>here. </t> </section> </section> <sectionanchor="op_overview" numbered="true" removeInRFC="false" toc="include" pn="section-2"> <name slugifiedName="name-operation-overview">Operationanchor="op_overview"> <name>Operation Overview</name><t indent="0" pn="section-2-1">DCCP<t>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 <xreftarget="protocol" format="default" sectionFormat="of" derivedContent="Section 3"/>.</t> <t indent="0" pn="section-2-2">Attarget="protocol"/>.</t> <t>At a high level oftheMP-DCCP operation, the data stream from a DCCP application is split by the MP-DCCP operation into one or more subflowswhichthat can be transmitted via different paths, forexampleexample, using paths via different links. The corresponding control information allows the receiver to optionallyre-assemblereassemble 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">A<t>A Multipath DCCP connection provides a bidirectional connection of datagrams between two hosts exchanging data using DCCP. It does not require any change to the applications. Multipath 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 performanceparameters.<br/> Theparameters.</t> <t>The number of DCCP subflows can vary during the lifetime of a Multipath 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-4">The<t>The Multipath Capability for MP-DCCP is negotiated with a new DCCP feature, as specified in <xreftarget="mp_capable" format="default" sectionFormat="of" derivedContent="Section 3.1"/>.target="mp_capable"/>. Once negotiated, all subsequent MP-DCCP operations for that connection aresignalledsignaled with a variable length multipath-related option, as described in <xreftarget="protocol" format="default" sectionFormat="of" derivedContent="Section 3"/>.target="protocol"/>. All MP-DCCP operations are signaled by Multipath options described in <xreftarget="MP_OPT" format="default" sectionFormat="of" derivedContent="Section 3.2"/>.target="MP_OPT"/>. 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-5">The following<t>The sections that follow define MP-DCCP behavior in detail.</t> <sectionanchor="concept" numbered="true" removeInRFC="false" toc="include" pn="section-2.1"> <name slugifiedName="name-mp-dccp-concept">MP-DCCPanchor="concept"> <name>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"/><t><xref target="ref-example-mp-dccp-usage-scenario"/> provides a general overview of the MP-DCCP working mode, whose main characteristics are summarized in this section.</t> <figureanchor="ref-example-mp-dccp-usage-scenario" align="left" suppress-title="false" pn="figure-2"> <name slugifiedName="name-example-mp-dccp-usage-scena">Exampleanchor="ref-example-mp-dccp-usage-scenario"> <name>Example MP-DCCPusage scenario</name> <artwork align="left" pn="section-2.1-2.1"><![CDATA[Usage Scenario</name> <artwork><![CDATA[ Host A Host B ------------------------ ------------------------ Address A1 Address A2 Address B1 Address B2 ---------- ---------- ---------- ---------- | | | | | (DCCP subflow setup) | | |----------------------------------->| | |<-----------------------------------| | | | | | | | (DCCP subflow setup)| | | |--------------------->| | | |<---------------------| | | merge individual DCCP subflows to one MP-DCCP connection | | || ]]></artwork>|]]></artwork> </figure><ul spacing="normal" bare="false" empty="false" indent="3" pn="section-2.1-3"> <li pn="section-2.1-3.1"> <t indent="0" pn="section-2.1-3.1.1">An<ul> <li> <t>An MP-DCCP connection begins with a 4-wayhandshake,handshake between two hosts. In <xreftarget="ref-example-mp-dccp-usage-scenario" format="default" sectionFormat="of" derivedContent="Figure 2"/>,target="ref-example-mp-dccp-usage-scenario"/>, 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 specificHost-specific keys are also exchanged between Host A and Host B during the handshake. The details of the MP-DCCP handshaking procedure is described in <xreftarget="handshaking" format="default" sectionFormat="of" derivedContent="Section 3.3"/>.target="handshaking"/>. 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<li> <t>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 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 <xreftarget="ref-example-mp-dccp-usage-scenario" format="default" sectionFormat="of" derivedContent="Figure 2"/>target="ref-example-mp-dccp-usage-scenario"/> 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<li> <t>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<->B2 and A2<->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<li> <t>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 andwhensubflows 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.(e.g., similar to that discussed insection 3.4 of<xref target="RFC8041"format="default"sectionFormat="of"derivedContent="RFC8041"/>),section="3.4"/>), the creation of new subflows from that peer host is omitted when the threshold of maximum paths is exceeded and incoming subflow requestsMUST<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<li> <t>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 forwhatwhich 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<li> <t>Subflows are terminated in the same way as regular DCCP connections, as described in(<xref<xref target="RFC4340"format="default"sectionFormat="of"derivedContent="RFC4340"/>, Section 8.3).section="8.3"/>. 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. KeydataData from the initial handshake is included intheMP_CLOSE and MP_FAST_CLOSE to protect from an unauthorized shutdown of MP-DCCP connections.</t> </li> </ul> </section> </section> <sectionanchor="protocol" numbered="true" removeInRFC="false" toc="include" pn="section-3"> <name slugifiedName="name-mp-dccp-protocol">MP-DCCPanchor="protocol"> <name>MP-DCCP Protocol</name><t indent="0" pn="section-3-1">The<t>The DCCP protocol feature list (<xref section="6.4"sectionFormat="of" target="RFC4340" format="default" derivedLink="https://rfc-editor.org/rfc/rfc4340#section-6.4" derivedContent="RFC4340"/>)target="RFC4340"/>) is extended in this document by adding a new Multipath feature with Feature number 10, as shown in <xreftarget="ref-feature-list" format="default" sectionFormat="of" derivedContent="Table 1"/>.</t>target="ref-feature-list"/>.</t> <tableanchor="ref-feature-list" align="center" pn="table-1"> <name slugifiedName="name-multipath-feature">Multipath feature</name>anchor="ref-feature-list"> <name>Multipath Feature</name> <thead> <tr><th align="center" colspan="1" rowspan="1">Number</th> <th align="left" colspan="1" rowspan="1">Meaning</th> <th align="center" colspan="1" rowspan="1">Rec'n<th>Number</th> <th>Meaning</th> <th>Rec'n Rule</th><th align="center" colspan="1" rowspan="1">Initial<th>Initial Value</th><th align="center" colspan="1" rowspan="1">Req'd</th><th>Req'd</th> </tr> </thead> <tbody> <tr><td align="center" colspan="1" rowspan="1">10</td> <td align="left" colspan="1" rowspan="1">Multipath<td>10</td> <td>Multipath Capable</td><td align="center" colspan="1" rowspan="1">SP</td> <td align="center" colspan="1" rowspan="1">0</td> <td align="center" colspan="1" rowspan="1">N</td><td>SP</td> <td>0</td> <td>N</td> </tr> </tbody> </table><dl indent="3" newline="false" spacing="normal" pn="section-3-3"> <dt pn="section-3-3.1">Rec'n<dl> <dt>Rec'n Rule:</dt><dd pn="section-3-3.2"> <t indent="0" pn="section-3-3.2.1">The<dd> <t>The reconciliation rule used for the feature. SP indicates the server-priority as defined insection 6.3 of<xref target="RFC4340"format="default"sectionFormat="of"derivedContent="RFC4340"/>.</t>section="6.3"/>.</t> </dd><dt pn="section-3-3.3">Initial<dt>Initial Value:</dt><dd pn="section-3-3.4"> <t indent="0" pn="section-3-3.4.1">The<dd> <t>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<dt>Req'd:</dt> <dd> <t>This column is "Y" if and only if every DCCP implementationMUST<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<t>This specification adds a DCCP protocol option as defined in(<xref<xref target="RFC4340"format="default"sectionFormat="of"derivedContent="RFC4340"/>, Section 5.8)section="5.8"/>, providing a newMultipath relatedmultipath-related variable-length option with option type 46, as shown in <xreftarget="ref-option-list" format="default" sectionFormat="of" derivedContent="Table 2"/>.</t>target="ref-option-list"/>.</t> <tableanchor="ref-option-list" align="center" pn="table-2"> <name slugifiedName="name-multipath-option-set">Multipath option set</name>anchor="ref-option-list"> <name>Multipath Option Set</name> <thead> <tr><th align="center" colspan="1" rowspan="1">Type</th> <th align="center" colspan="1" rowspan="1">Option<th>Type</th> <th>Option Length</th><th align="center" colspan="1" rowspan="1">Meaning</th> <th align="center" colspan="1" rowspan="1">DCCP-Data?</th><th>Meaning</th> <th>DCCP-Data?</th> </tr> </thead> <tbody> <tr><td align="center" colspan="1" rowspan="1">46</td> <td align="center" colspan="1" rowspan="1">variable</td> <td align="center" colspan="1" rowspan="1">Multipath</td> <td align="center" colspan="1" rowspan="1">Y</td><td>46</td> <td>variable</td> <td>Multipath</td> <td>Y</td> </tr> </tbody> </table><ul empty="true" bare="false" indent="3" spacing="normal" pn="section-3-6"> <li pn="section-3-6.1"> <t indent="0" pn="section-3-6.1.1">Note to the RFC Editor: The Feature Number and Option Type reflect the temporary assignment by IANA and must be verified once again.</t> </li> </ul><sectionanchor="mp_capable" numbered="true" removeInRFC="false" toc="include" pn="section-3.1"> <name slugifiedName="name-multipath-capable-feature">Multipathanchor="mp_capable"> <name>Multipath Capable Feature</name><t indent="0" pn="section-3.1-1">A<t>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<t>The Multipath Capable feature (MP_CAPABLE) has feature number 10 and follows the structure for features given in <xref target="RFC4340"format="default"sectionFormat="of"derivedContent="RFC4340"/> Section 6.section="6"/>. Beside the negotiation of the feature itself,alsoone or several values can also be exchanged. The value field specified here for the Multipath Capable feature has a length ofone-byteone byte and can be repeated several times within the DCCP option for feature negotiation. This canbebe, forexampleexample, required to announce support of different versions of the protocol. For that, the leftmost four bits in <xreftarget="ref-mp-capable-format" format="default" sectionFormat="of" derivedContent="Figure 3"/>target="ref-mp-capable-format"/> specify the compatible version of the MP-DCCP implementation andMUST<bcp14>MUST</bcp14> be set to 0 following this specification. The four bits following the Version field are unassigned in version 0 andMUST<bcp14>MUST</bcp14> be set to zero by the sender andMUST<bcp14>MUST</bcp14> be ignored by the receiver.</t> <figureanchor="ref-mp-capable-format" align="left" suppress-title="false" pn="figure-3"> <name slugifiedName="name-format-of-the-multipath-cap">Formatanchor="ref-mp-capable-format"> <name>Format of the Multipath Capablefeature value field</name> <artwork align="left" pn="section-3.1-3.1"><![CDATA[Feature Value Field</name> <artwork><![CDATA[ 0 1 2 3 4 5 6 7 +-----------+------------+ | Version | Unassigned |+-----------+------------+ ]]></artwork>+-----------+------------+]]></artwork> </figure><t indent="0" pn="section-3.1-4">The<t>The setting of the MP_CAPABLE featureMUST<bcp14>MUST</bcp14> follow the server-priority reconciliation rule described in(<xref<xref target="RFC4340"format="default"sectionFormat="of"derivedContent="RFC4340"/>, Section 6.3.1).section="6.3.1"/>. This allows multiple versions to be specified in order of priority.</t><t indent="0" pn="section-3.1-5">The<t>The negotiationMUST<bcp14>MUST</bcp14> be a part of the initial handshake procedure described in <xreftarget="handshaking" format="default" sectionFormat="of" derivedContent="Section 3.3"/>.target="handshaking"/>. No subsequentre-negotiationrenegotiation of the MP_CAPABLE feature is allowed for the same MP-DCCP connection.</t><t indent="0" pn="section-3.1-6">Clients MUST<t>Clients <bcp14>MUST</bcp14> include a Change R option (<xref section="6"sectionFormat="comma" target="RFC4340" format="default" derivedLink="https://rfc-editor.org/rfc/rfc4340#section-6" derivedContent="RFC4340"/>) optionsectionFormat="of" target="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 MUST<t>Servers <bcp14>MUST</bcp14> include a Confirm L option (<xref section="6"sectionFormat="comma" target="RFC4340" format="default" derivedLink="https://rfc-editor.org/rfc/rfc4340#section-6" derivedContent="RFC4340"/>) optionsectionFormat="of" target="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 connectionMUST<bcp14>MUST</bcp14> use the version negotiated for the first subflow.</t><t indent="0" pn="section-3.1-8">If<t>If no agreement is found, the ServerMUST<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<t>An example of successful version negotiation is shown hereafter and follows the negotiation example shown in <xref target="RFC4340"format="default"sectionFormat="of"derivedContent="RFC4340"/> Section 6.5.section="6.5"/>. 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> <figureanchor="ref-mp-capable-example" align="left" suppress-title="false" pn="figure-4"> <name slugifiedName="name-example-of-mp-dccp-support-">Exampleanchor="ref-mp-capable-example"> <name>Example of MP-DCCPsupport negotiation usingSupport Negotiation Using MP_CAPABLE</name><artwork align="left" pn="section-3.1-10.1"><![CDATA[<artwork><![CDATA[ Client Server ------ ------ DCCP-Req + Change R(MP_CAPABLE, 1 0) -----------------------------------> DCCP-Resp + Confirm L(MP_CAPABLE, 1, 2 1 0) <----------------------------------- * agreement on version = 1* ]]></artwork>*]]></artwork> </figure><ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-3.1-11"><li pn="section-3.1-11.1" derivedCounter="1."> <t indent="0" pn="section-3.1-11.1.1">The<!--[rfced] Section 3.1: Would you like to add text to introduce the numbered list that immediately follows Figure 4? Original: 1. The Client indicates support for both MP-DCCP versions 1 and 0, with a preference for version1.</t> </li> <li pn="section-3.1-11.2" derivedCounter="2."> <t indent="0" pn="section-3.1-11.2.1">Server1. 2. Server agrees on using MP-DCCP version 1 indicated by the first value, and supplies its own preference list with the following values. 3. MP-DCCP is then enabled between the Client and Server with version 1. Perhaps: This example illustrates the following: 1. The Client indicates support for both MP-DCCP versions 1 and 0, with a preference for version 1. 2. The Server agrees on using MP-DCCP version 1 indicated by the first value and supplies its own preference list with the following values. 3. MP-DCCP is then enabled between the Client and Server with version 1. --> <ol><li> <t>The Client indicates support for both MP-DCCP versions 1 and 0, with a preference for version 1.</t> </li> <li> <t>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-11.3" derivedCounter="3."> <t indent="0" pn="section-3.1-11.3.1">MP-DCCP<li> <t>MP-DCCP is then enabled between the Client and Server with version 1.</t> </li> </ol><t indent="0" pn="section-3.1-12">Unlike<t>Unlike the example in <xreftarget="ref-mp-capable-example" format="default" sectionFormat="of" derivedContent="Figure 4"/>,target="ref-mp-capable-example"/>, 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 serverMUST<bcp14>MUST</bcp14> both support MP-DCCP version 0.</t><t indent="0" pn="section-3.1-13">If<t>If the version negotiation fails or the MP_CAPABLE feature is not present in the DCCP-Request or DCCP-Response packets of the initial handshake procedure, the MP-DCCP connectionMUSTeither <bcp14>MUST</bcp14> fall back to regular DCCP orMUST<bcp14>MUST</bcp14> close the connection. Further details are specified in <xreftarget="fallback" format="default" sectionFormat="of" derivedContent="Section 3.6"/></t>target="fallback"/>.</t> </section> <sectionanchor="MP_OPT" numbered="true" removeInRFC="false" toc="include" pn="section-3.2"> <name slugifiedName="name-multipath-option">Multipathanchor="MP_OPT"> <name>Multipath Option</name><t indent="0" pn="section-3.2-1">MP-DCCP<t>MP-DCCP uses one single option to signal various multipath-related operations. The format of this multipath option is shown in <xreftarget="ref-mp-option-format" format="default" sectionFormat="of" derivedContent="Figure 5"/>.</t>target="ref-mp-option-format"/>.</t> <figureanchor="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"><![CDATA[anchor="ref-mp-option-format"> <name>Multipath Option Format</name> <artwork><![CDATA[ 1 2 3 01234567 89012345 67890123 45678901 23456789 +--------+--------+--------+--------+--------+ |00101110| Length | MP_OPT | Value(s) ... +--------+--------+--------+--------+--------+Type=46 ]]></artwork>Type=46]]></artwork> </figure><t indent="0" pn="section-3.2-3">The<t>The fields used by the multipath option are described in <xreftarget="ref-mp-option-list" format="default" sectionFormat="of" derivedContent="Table 3"/>.target="ref-mp-option-list"/>. MP_OPT refers to a Multipath option.</t> <!--[rfced] Table 4: May we update these IANA-registered descriptions as follows for clarity? If so, we will ask IANA to update the registry accordingly. (Also, they will be updated in Table 8.) Original: MP_OPT=7 MP_ADDADDR Advertise additional address(es)/port(s) MP_OPT=8 MP_REMOVEADDR Remove address(es)/port(s) Perhaps: MP_OPT=7 MP_ADDADDR Advertise one or more additional addresses/ports MP_OPT=8 MP_REMOVEADDR Remove one or more addresses/ports --> <tableanchor="ref-mp-option-list" align="center" pn="table-3"> <name slugifiedName="name-mp_opt-option-types">MP_OPT option types</name>anchor="ref-mp-option-list"> <name>MP_OPT Option Types</name> <thead> <tr><th align="left" colspan="1" rowspan="1">Type</th> <th align="left" colspan="1" rowspan="1">Option<th>Type</th> <th>Option Length</th><th align="left" colspan="1" rowspan="1">MP_OPT</th> <th align="left" colspan="1" rowspan="1">Meaning</th><th>MP_OPT</th> <th>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<td>46</td> <td>var</td> <td>0 =MP_CONFIRM</td><td align="left" colspan="1" rowspan="1">Confirm<td>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<td>46</td> <td>12</td> <td>1 =MP_JOIN</td><td align="left" colspan="1" rowspan="1">Join<td>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<td>46</td> <td>var</td> <td>2 =MP_FAST_CLOSE</td><td align="left" colspan="1" rowspan="1">Close<td>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<td>46</td> <td>var</td> <td>3 =MP_KEY</td><td align="left" colspan="1" rowspan="1">Exchange<td>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<td>46</td> <td>9</td> <td>4 =MP_SEQ</td><td align="left" colspan="1" rowspan="1">Multipath Sequence Number</td><td>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<td>46</td> <td>23</td> <td>5 =MP_HMAC</td><td align="left" colspan="1" rowspan="1">Hash-based<td>Hash-based messageauth.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<td>46</td> <td>12</td> <td>6 =MP_RTT</td><td align="left" colspan="1" rowspan="1">Transmit<td>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<td>46</td> <td>var</td> <td>7 =MP_ADDADDR</td><td align="left" colspan="1" rowspan="1">Advertise<td>Advertise additional address(es)/port(s)</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<td>46</td> <td>8</td> <td>8 =MP_REMOVEADDR</td><td align="left" colspan="1" rowspan="1">Remove address(es)/ port(s)</td><td>Remove address(es)/port(s)</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<td>46</td> <td>4</td> <td>9 =MP_PRIO</td><td align="left" colspan="1" rowspan="1">Change<td>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<td>46</td> <td>var</td> <td>10 =MP_CLOSE</td><td align="left" colspan="1" rowspan="1">Close<td>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<td>46</td> <td>var</td> <td>11 =MP_EXP</td><td align="left" colspan="1" rowspan="1">Experimental<td>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">>11</td> <td align="left" colspan="1" rowspan="1">Reserved<td>46</td> <td>TBD</td> <td>>11</td> <td>Reserved for future Multipath options.</td> </tr> </tbody> </table><t indent="0" pn="section-3.2-5">Future<t>Future MP options could be defined in a later version of or extension to this specification.</t><t indent="0" pn="section-3.2-6">These<t>These operations are largely inspired by the signals defined in <xreftarget="RFC8684" format="default" sectionFormat="of" derivedContent="RFC8684"/>.target="RFC8684"/>. The procedures for handling faulty or unknown MP options are described in <xreftarget="fallback" format="default" sectionFormat="of" derivedContent="Section 3.6"/>.</t>target="fallback"/>.</t> <sectionanchor="MP_CONFIRM" numbered="true" removeInRFC="false" toc="include" pn="section-3.2.1"> <name slugifiedName="name-mp_confirm">MP_CONFIRM</name>anchor="MP_CONFIRM"> <name>MP_CONFIRM</name> <figureanchor="ref-mp-confirm-format" align="left" suppress-title="false" pn="figure-6"> <name slugifiedName="name-format-of-the-mp_confirm-op">Formatanchor="ref-mp-confirm-format"> <name>Format of the MP_CONFIRMoption</name> <artwork align="left" pn="section-3.2.1-1.1"><![CDATA[Option</name> <artwork><![CDATA[ 1 2 3 4 5 01234567 89012345 67890123 45678901 23456789 01234567 89012345 +--------+--------+--------+--------+--------+--------+--------+ |00101110| var |00000000| List of confirmations ... +--------+--------+--------+--------+--------+--------+--------+ Type=46 LengthMP_OPT=0 ]]></artwork>MP_OPT=0]]></artwork> </figure><t indent="0" pn="section-3.2.1-2">Some<t>Some multipath options require confirmation from the remote peer (see <xreftarget="ref-mp-option-confirm" format="default" sectionFormat="of" derivedContent="Table 4"/>).target="ref-mp-option-confirm"/>). Such options 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. 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-3">Multipath<t>Multipath options could arriveout-of-order, thereforeout of order; therefore, multipath options defined in <xreftarget="ref-mp-option-confirm" format="default" sectionFormat="of" derivedContent="Table 4"/> MUSTtarget="ref-mp-option-confirm"/> <bcp14>MUST</bcp14> be sent in a DCCP datagram withMP_SEQ; seeMP_SEQ (see <xreftarget="MP_SEQ" format="default" sectionFormat="of" derivedContent="Section 3.2.5"/>.target="MP_SEQ"/>). 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 orMP_REMOVEADDRMP_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_CONFIRMMAY<bcp14>MAY</bcp14> be generated for multipath options that are identified as outdated.</t><t indent="0" pn="section-3.2.1-4">Similarly,<t>Similarly, an MP_CONFIRM could arrive out of order. The associated MP_SEQ receivedMUST<bcp14>MUST</bcp14> be echoed to ensure that the most recent multipath option is confirmed. This protects from inconsistencies that could occur,e.g.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 to11, 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-5">The<t>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. <!--[rfced] May we rephrase this sentence for improved readability? Original: This could happen if a datagram with MP_PRIO and a first MP_SEQ_1 and another datagram with MP_ADDADDR and a second MP_SEQ_2 are received in short succession. Perhaps: 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. --> This could happen if a datagram with MP_PRIO and a first MP_SEQ_1 and another datagram with MP_ADDADDR and a second MP_SEQ_2 are received in short succession. 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 confirmationsMUST<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> <tableanchor="ref-mp-option-confirm" align="center" pn="table-4"> <name slugifiedName="name-multipath-options-requiring">Multipath options requiring confirmation</name>anchor="ref-mp-option-confirm"> <name>Multipath Options Requiring Confirmation</name> <thead> <tr><th align="left" colspan="1" rowspan="1">Type</th> <th align="left" colspan="1" rowspan="1">Option<th>Type</th> <th>Option Length</th><th align="left" colspan="1" rowspan="1">MP_OPT</th> <th align="left" colspan="1" rowspan="1">MP_CONFIRM<th>MP_OPT</th> <th>MP_CONFIRM Sendingpath</th>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<td>46</td> <td>var</td> <td>7 =MP_ADDADDR</td><td align="left" colspan="1" rowspan="1">Any<td>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<td>46</td> <td>4</td> <td>8 =MP_REMOVEADDR</td><td align="left" colspan="1" rowspan="1">Any<td>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<td>46</td> <td>4</td> <td>9 =MP_PRIO</td><td align="left" colspan="1" rowspan="1">Any<td>Any available</td> </tr> </tbody> </table><t indent="0" pn="section-3.2.1-7">An<t>An example to illustrate the MP-DCCP confirm procedure for the MP_PRIO option is shown in <xreftarget="ref-mp-dccp-confirm-good" format="default" sectionFormat="of" derivedContent="Figure 7"/>. Thetarget="ref-mp-dccp-confirm-good"/>. 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> <!--[rfced] Figure Titles a) Should the titles of Figures 7 and 8 include "MP_CONFIRM" (instead of "MP-DCCP CONFIRM") to match the content in the figures? Note that the running text refers to the procedure as "MP-DCCP confirm" - should the running text be updated as well for consistency? Please let us know if "MP_CONFIRM", "MP-DCCP CONFIRM", or other is preferred. Current (Figure 7): Example MP-DCCP CONFIRM Procedure Perhaps: Example MP_CONFIRM Procedure ... Current (Figure 8) Example MP-DCCP CONFIRM Procedure with an Outdated Suboption Perhaps: Example MP_CONFIRM Procedure with an Outdated Suboption b) Should the title of Figure 22 perhaps be "Example MP_ADDADDR Procedure" rather than "Example MP-DCCP ADDADDR Procedure" to match the content in the figure? We note that "MP-DCCP ADDADDR" is not used in the running text. Current: Example MP-DCCP ADDADDR Procedure Perhaps: Example MP_ADDADDR Procedure c) Should the title of Figure 23 perhaps be "Example MP_ADDADDR Procedure" rather than "Example MP-DCCP REMOVEADDR Procedure" to match the content in the figure? We note that "MP-DCCP REMOVEADDR" is not used in the running text. Current: Example MP-DCCP REMOVEADDR Procedure Perhaps: Example MP_REMOVEADDR Procedure --> <figureanchor="ref-mp-dccp-confirm-good" align="left" suppress-title="false" pn="figure-7"> <name slugifiedName="name-example-mp-dccp-confirm-pro">Exampleanchor="ref-mp-dccp-confirm-good"> <name>Example MP-DCCP CONFIRMprocedure</name> <artwork align="left" pn="section-3.2.1-8.1"><![CDATA[Procedure</name> <artwork><![CDATA[ Host A Host B ------------------------ ------------------------ Address A1 Address A2 Address B1 Address B2 ---------- ---------- ---------- ---------- | | | | | | DCCP-Request(seqno 1) + MP_PRIO(1)| | | |------------------------------------------>| | | | | | | DCCP-Response + | | | |<---- MP_CONFIRM(seqno 1, MP_PRIO) --------| | | || ]]></artwork>|]]></artwork> </figure><t indent="0" pn="section-3.2.1-9">A<t>A second exampleto illustratethat illustrates the same MP-DCCP confirm procedure but where anout of dateout-of-date option is also delivered is shown in(<xref target="ref-mp-dccp-confirm-outdated" format="default" sectionFormat="of" derivedContent="Figure 8"/>.<xref target="ref-mp-dccp-confirm-outdated"/>. 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-Ackconfirming receipt of the MP_PRIO(1)with sequence number2.</t>2 to confirm the receipt of the MP_PRIO(1).</t> <figureanchor="ref-mp-dccp-confirm-outdated" align="left" suppress-title="false" pn="figure-8"> <name slugifiedName="name-example-mp-dccp-confirm-proc">Exampleanchor="ref-mp-dccp-confirm-outdated"> <name>Example MP-DCCP CONFIRMprocedureProcedure withoutdated suboption</name> <artwork align="left" pn="section-3.2.1-10.1"><![CDATA[an Outdated Suboption</name> <artwork><![CDATA[ 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) | | | |--------------\--------------------------->| | | \ | | | | -------------------------->| | | | | | | DCCP-Ack + | | | |<---- MP_CONFIRM(seqno 2, MP_PRIO) --------| | | || ]]></artwork>|]]></artwork> </figure> </section> <sectionanchor="MP_JOIN" numbered="true" removeInRFC="false" toc="include" pn="section-3.2.2"> <name slugifiedName="name-mp_join">MP_JOIN</name>anchor="MP_JOIN"> <name>MP_JOIN</name> <figureanchor="ref-MP_JOIN" align="left" suppress-title="false" pn="figure-9"> <name slugifiedName="name-format-of-the-mp_join-subop">Formatanchor="ref-MP_JOIN"> <name>Format of the MP_JOINsuboption</name> <artwork align="left" pn="section-3.2.2-1.1"><![CDATA[Suboption</name> <!--[rfced] We note that Figures 9, 11, and 19 are listed first within their sections without any lead-in text. Is this intended, or would you like to add a lead-in sentence for consistency with the other sections? --> <artwork><![CDATA[ 1 2 3 01234567 89012345 67890123 45678901 +--------+--------+--------+--------+ |00101110|00001100|00000001| Addr ID| +--------+--------+--------+--------+ | Connection Identifier | +--------+--------+--------+--------+ | Nonce | +--------+--------+--------+--------+ Type=46 Length=12MP_OPT=1 ]]></artwork>MP_OPT=1]]></artwork> </figure><t indent="0" pn="section-3.2.2-2">The<!--[rfced] Per RFCs 2119 and 8174, may we update "REQUIRES" to "REQUIRED" for correctness as shown below? Original: The MP_JOIN option is used to add a new subflow to an existing MP- DCCP connection and REQUIRES a successful establishment of the first subflow using MP_KEY. Perhaps: 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 REQUIRED. --> <t>The MP_JOIN option is used to add a new subflow to an existing MP-DCCP connection and REQUIRES a successful establishment of the first subflow using MP_KEY. The Connection Identifier (CI) is the one from the peer host, which was previously exchanged with the MP_KEY option. MP_HMACMUST<bcp14>MUST</bcp14> be set when using MP_JOIN within a DCCP-Response packet; see <xreftarget="MP_HMAC" format="default" sectionFormat="of" derivedContent="Section 3.2.6"/>target="MP_HMAC"/> for details. Similar to the setup of the first subflow, MP_JOIN also exchanges the Multipath Capable feature MP_CAPABLE as described in <xreftarget="mp_capable" format="default" sectionFormat="of" derivedContent="Section 3.1"/>.target="mp_capable"/>. This procedure includes the DCCP Confirm principle and thus ensures a reliable exchange of the MP_JOIN in accordance withsection 6.6.4 of<xref target="RFC4340"format="default"sectionFormat="of"derivedContent="RFC4340"/>.</t> <t indent="0" pn="section-3.2.2-3">Thesection="6.6.4"/>.</t> <t>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 andMUST<bcp14>MUST</bcp14> map uniquely to a source IP address for the sending host. The Address ID allows address removal (<xreftarget="MP_REMOVEADDR" format="default" sectionFormat="of" derivedContent="Section 3.2.9"/>)target="MP_REMOVEADDR"/>) 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 (<xreftarget="MP_ADDADDR" format="default" sectionFormat="of" derivedContent="Section 3.2.8"/>),target="MP_ADDADDR"/>), 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-4">The<t>The Address IDs of the subflow used in the initial DCCP Request/Response exchange of the first subflow in the connection areimplicit,implicit and have the value zero. A hostMUST<bcp14>MUST</bcp14> store the mappings between Address IDs and addressesbothfor both itself and the remote host. An implementation will also need to know which local and remote Address IDs are associated with which establishedsubflows,subflows for when addresses are removed from a local or remote host. An Address ID <bcp14>MUST</bcp14> alwaysMUSTbe unique over the lifetime of a subflow and can only bere-assignedreassigned if sender and receiver no longer have them in use.</t><t indent="0" pn="section-3.2.2-5">The<t>The Nonce is a 32-bit random value locally generated for every MP_JOIN option. <!--[rfced] Please clarify this sentence, specifically "from the both hosts Key Data". Original: Together with the derived key from the both hosts Key Data described in<xref target="MP_KEY" format="default" sectionFormat="of" derivedContent="Section 3.2.4"/>,Section 3.2.4, the Nonce value builds the basis to calculate the HMAC used in the handshaking process as described in Section 3.3 to avoid replay attacks. Perhaps: Together with the derived key from both hosts that exchange Key Data as described in Section 3.2.4, the Nonce value builds the basis to calculate the Hash-based Message Authentication Code (HMAC) used in the handshaking process described in Section 3.3 to avoid replay attacks. Or: Together with the derived key from both hosts' Key Data (as described in Section 3.2.4), the Nonce value builds the basis to calculate the Hash-based Message Authentication Code (HMAC) used in the handshaking process (as described in Section 3.3) to avoid replay attacks. --> Together with the derived key from the both hosts Key Data described in <xref target="MP_KEY"/>, the Nonce value builds the basis to calculate the Hash-based Message Authentication Code (HMAC) used in the handshaking process as described in <xreftarget="handshaking" format="default" sectionFormat="of" derivedContent="Section 3.3"/>target="handshaking"/> to avoid replay attacks.</t><t indent="0" pn="section-3.2.2-6">If<t>If the CI cannot be verified by the receiving host during a handshake negotiation, the new subflowMUST<bcp14>MUST</bcp14> be closed, as specified in <xreftarget="fallback" format="default" sectionFormat="of" derivedContent="Section 3.6"/>.</t>target="fallback"/>.</t> </section> <sectionanchor="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">DCCPanchor="MP_FAST_CLOSE"> <name>MP_FAST_CLOSE</name> <t>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<t>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> <figureanchor="ref-MP_FAST_CLOSE" align="left" suppress-title="false" pn="figure-10"> <name slugifiedName="name-format-of-the-mp_fast_close">Formatanchor="ref-MP_FAST_CLOSE"> <name>Format of the MP_FAST_CLOSEsuboption</name> <artwork align="left" pn="section-3.2.3-3.1"><![CDATA[Suboption</name> <artwork><![CDATA[ 1 2 3 01234567 89012345 67890123 45678901 23456789 +--------+--------+--------+--------+--------+ |00101110| var |00000010| Key Data ... +--------+--------+--------+--------+--------+ Type=46 LengthMP_OPT=2 ]]></artwork>MP_OPT=2]]></artwork> </figure><t indent="0" pn="section-3.2.3-4">When<t>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 suboptionMUST<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 handshaking procedure is carried by the MP_FAST_CLOSE option.</t><t indent="0" pn="section-3.2.3-5">After<t>After sending the MP_FAST_CLOSE on all subflows, Host AMUST<bcp14>MUST</bcp14> tear down allsubflowssubflows, and themultipathMultipath DCCP connection immediately terminates.</t><t indent="0" pn="section-3.2.3-6">Upon<t>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 BMUST<bcp14>MUST</bcp14> then tear down all subflows and terminate the MP-DCCP connection.</t> </section> <sectionanchor="MP_KEY" numbered="true" removeInRFC="false" toc="include" pn="section-3.2.4"> <name slugifiedName="name-mp_key">MP_KEY</name>anchor="MP_KEY"> <name>MP_KEY</name> <figureanchor="ref-MP_KEY" align="left" suppress-title="false" pn="figure-11"> <name slugifiedName="name-format-of-the-mp_key-subopt">Formatanchor="ref-MP_KEY"> <name>Format of the MP_KEYsuboption</name> <artwork align="left" pn="section-3.2.4-1.1"><![CDATA[Suboption</name> <artwork><![CDATA[ 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------+---------------+---------------+ |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 LengthMP_OPT=3 ]]></artwork>MP_OPT=3]]></artwork> </figure><t indent="0" pn="section-3.2.4-2">The<t>The MP_KEY suboption is used to exchange a Connection Identifier (CI) and key material between hosts(host A, host(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 theCICI, it is possible to connect other DCCP subflows to an MP-DCCP connection with MP_JOIN (<xreftarget="MP_JOIN" format="default" sectionFormat="of" derivedContent="Section 3.2.2"/>).target="MP_JOIN"/>). Its size of32-bits32 bits also defines the maximum number of simultaneous MP-DCCP connections in a host to2^32.2<sup>32</sup>. According to theKey relatedKey-related elements of the MP_KEY suboption, the Length varies between 17 and 73 bytes for a single-keymessage,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 followingkey data.Key Data. The set of key types are shown in <xreftarget="ref-key-type-list" format="default" sectionFormat="of" derivedContent="Table 5"/>.</t>target="ref-key-type-list"/>.</t> <tableanchor="ref-key-type-list" align="center" pn="table-5"> <name slugifiedName="name-mp_key-key-types">MP_KEY key types</name>anchor="ref-key-type-list"> <name>MP_KEY Key Types</name> <thead> <tr><th align="left" colspan="1" rowspan="1">Key<th>Key Type</th><th align="left" colspan="1" rowspan="1">Key<th>Key Length (bytes)</th><th align="left" colspan="1" rowspan="1">Meaning</th><th>Meaning</th> </tr> </thead> <tbody> <tr><td align="left" colspan="1" rowspan="1">0<td>0 =Plain Text</td><td align="left" colspan="1" rowspan="1">8</td> <td align="left" colspan="1" rowspan="1">Plain<td>8</td> <td>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">Reserved<td>1-254</td> <td> </td> <td>Reserved for future Key Types</td> </tr> <tr><td align="left" colspan="1" rowspan="1">255<td>255 =Experimental</td><td align="left" colspan="1" rowspan="1">64</td> <td align="left" colspan="1" rowspan="1">For<td>64</td> <td>For private use only</td> </tr> </tbody> </table> <dl newline="true"indent="3" spacing="normal" pn="section-3.2.4-4"> <dt pn="section-3.2.4-4.1">Plain Text</dt> <dd pn="section-3.2.4-4.2"> <t indent="0" pn="section-3.2.4-4.2.1">Keyspacing="normal"> <dt>Plain Text:</dt> <dd><t>Key Data is exchanged in plain text between hosts (HostA,A and Host B), and the respective key parts(KeyA,(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. Thatis, </t> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3.2.4-4.2.2"> <li pn="section-3.2.4-4.2.2.1"> <t indent="0" pn="section-3.2.4-4.2.2.1.1">Host A: d-keyA=(KeyA+KeyB)</t> </li> <li pn="section-3.2.4-4.2.2.2"> <t indent="0" pn="section-3.2.4-4.2.2.2.1">Host B: d-keyB=(KeyB+KeyA)</t> </li> </ul> </dd> </dl>is,</t> <dlnewline="true" indent="3" spacing="normal" pn="section-3.2.4-5"> <dt pn="section-3.2.4-5.1">Experimental</dt> <dd pn="section-3.2.4-5.2"> <t indent="0" pn="section-3.2.4-5.2.1">Thisspacing="normal"> <dt>Host A:</dt><dd>d-keyA=(KeyA+KeyB)</dd> <dt>Host B:</dt><dd>d-keyB=(KeyB+KeyA)</dd> </dl> </dd> <dt>Experimental:</dt> <dd><t>This Key Type allowstothe 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<t>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 <xreftarget="handshaking" format="default" sectionFormat="of" derivedContent="Section 3.3"/></t> <t indent="0" pn="section-3.2.4-7">Ittarget="handshaking"/></t> <t>It is possible that not all hosts will support all keytypestypes, 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)MUST<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 connectionMUST<bcp14>MUST</bcp14> fall back to not using MP-DCCP, as indicated in <xreftarget="fallback" format="default" sectionFormat="of" derivedContent="Section 3.6"/>.</t>target="fallback"/>.</t> </section> <sectionanchor="MP_SEQ" numbered="true" removeInRFC="false" toc="include" pn="section-3.2.5"> <name slugifiedName="name-mp_seq">MP_SEQ</name>anchor="MP_SEQ"> <name>MP_SEQ</name> <figureanchor="ref-MP_SEQ" align="left" suppress-title="false" pn="figure-12"> <name slugifiedName="name-format-of-the-mp_seq-subopt">Formatanchor="ref-MP_SEQ"> <name>Format of the MP_SEQsuboption</name> <artwork align="left" pn="section-3.2.5-1.1"><![CDATA[Suboption</name> <artwork><![CDATA[ 1 2 3 4 5 01234567 89012345 67890123 45678901 23456789 01234567 89012345 +--------+--------+--------+--------+--------+--------+--------+ |00101110|00001001|00000100| Multipath Sequence Number +--------+--------+--------+--------+--------+--------+--------+ | +--------+--------+ Type=46 Length=9MP_OPT=4 ]]></artwork>MP_OPT=4]]></artwork> </figure><t indent="0" pn="section-3.2.5-2">The<t>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)SHOULD<bcp14>SHOULD</bcp14> be set randomly <xreftarget="RFC4086" format="default" sectionFormat="of" derivedContent="RFC4086"/>.target="RFC4086"/>. As with the standard DCCP sequence number, the data sequence number should not start atzero,zero but at a random value to make blind session hijacking moredifficult,difficult; see alsosection 7.2 in<xref target="RFC4340"format="default"sectionFormat="of"derivedContent="RFC4340"/>.</t> <t indent="0" pn="section-3.2.5-3">Thesection="7.2"/>.</t> <t>The MP_SEQ number space is independent of the path individual sequence number space andMUST<bcp14>MUST</bcp14> be sent with all DCCP-Data and DCCP-DataACK packets.</t><t indent="0" pn="section-3.2.5-4">When<t>When the sequence number space is exhausted, the sequence numberMUST<bcp14>MUST</bcp14> be wrapped. <xreftarget="RFC7323" format="default" sectionFormat="of" derivedContent="RFC7323"/>target="RFC7323"/> provides guidance on selecting an appropriately sized sequence number space according to themaximum segment lifetimeMaximum 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, theMaximum Segment LifetimeMSL is the same as that of TCP as specified in <xref section="3.4"sectionFormat="of" target="RFC4340" format="default" derivedLink="https://rfc-editor.org/rfc/rfc4340#section-3.4" derivedContent="RFC4340"/>.target="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 largeconsideringper the current globally routable maximum packet size (MPS) of 1500 bytes, which corresponds to roughly 375PiBpebibytes (PiBs) of data within the sequence number space.</t> </section> <sectionanchor="MP_HMAC" numbered="true" removeInRFC="false" toc="include" pn="section-3.2.6"> <name slugifiedName="name-mp_hmac">MP_HMAC</name>anchor="MP_HMAC"> <name>MP_HMAC</name> <figureanchor="ref-MP_HMAC" align="left" suppress-title="false" pn="figure-13"> <name slugifiedName="name-format-of-the-mp_hmac-subop">Formatanchor="ref-MP_HMAC"> <name>Format of the MP_HMACsuboption</name> <artwork align="left" pn="section-3.2.6-1.1"><![CDATA[Suboption</name> <artwork><![CDATA[ 1 2 3 4 01234567 89012345 67890123 45678901 23456789 01234567 +--------+--------+--------+--------+--------+--------+ |00101110|00010111|00000101| HMAC-SHA256 (20 bytes) ... +--------+--------+--------+--------+--------+--------+ Type=46 Length=23MP_OPT=5 ]]></artwork>MP_OPT=5]]></artwork> </figure><t indent="0" pn="section-3.2.6-2">The<t>The MP_HMAC suboption is used to provide authentication for theMP_ADDADDR,MP_ADDADDR and MP_REMOVEADDR suboptions. <!--[rfced] In Section 3.2.6, the text refers to the "second and third step" of the handshake, so should the list in Section 3.3 be an ordered list instead of a bulleted list as shown below? Section 3.2.6: 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 Section 3.3. Original (Section 3.3): The basic initial handshake for the first subflow is as follows: * Host A sends a DCCP-Request with the MP-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 Section 3.2.4. CI-A is a unique identifier during the lifetime of an MP-DCCP connection. * Host B sends a DCCP-Response with 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. * Host A sends a DCCP-Ack to confirm the proper key exchange. * Host B sends a DCCP-Ack to complete the handshake and set both connection ends to the OPEN state. Perhaps (Section 3.3): The basic initial handshake for the first subflow is as follows: 1. Host A sends a DCCP-Request with the MP-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 Section 3.2.4. CI-A is a unique identifier during the lifetime of an MP-DCCP connection. 2. 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. 3. Host A sends a DCCP-Ack to confirm the proper key exchange. 4. Host B sends a DCCP-Ack to complete the handshake and set both connection ends to the OPEN state. --> 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 <xreftarget="handshaking" format="default" sectionFormat="of" derivedContent="Section 3.3"/>.target="handshaking"/>. For this specification of MP-DCCP, the HMAC code is generated according to <xreftarget="RFC2104" format="default" sectionFormat="of" derivedContent="RFC2104"/>target="RFC2104"/> in combination with the SHA256 hash algorithm described in <xreftarget="RFC6234" format="default" sectionFormat="of" derivedContent="RFC6234"/>,target="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-3">The<t>The "Key" used for the HMAC computation is the derived key (d-keyA for Host A or d-KeyB for Host B) described in <xreftarget="MP_KEY" format="default" sectionFormat="of" derivedContent="Section 3.2.4"/>,target="MP_KEY"/>, while the HMAC "Message" for MP_JOIN,MP_ADDADDRMP_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 whenreceiving, andreceiving; it is a concatenation of:</t><ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3.2.6-4"> <li pn="section-3.2.6-4.1"> <t indent="0" pn="section-3.2.6-4.1.1">for<ul> <li> <t>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 spacing="normal" bare="false" empty="false" indent="3" pn="section-3.2.6-4.1.2"> <li pn="section-3.2.6-4.1.2.1"> <t indent="0" pn="section-3.2.6-4.1.2.1.1">MP_HMAC(A)<ul> <li> <t>MP_HMAC(A) = HMAC-SHA256(Key=d-keyA, Msg=RA+RB)</t> </li><li pn="section-3.2.6-4.1.2.2"> <t indent="0" pn="section-3.2.6-4.1.2.2.1">MP_HMAC(B)<li> <t>MP_HMAC(B) = HMAC-SHA256(Key=d-keyB, Msg=RB+RA)</t> </li> </ul> </li> </ul><t indent="0" pn="section-3.2.6-5">A<t>A usage example is shown in <xreftarget="ref-mp-dccp-handshaking" format="default" sectionFormat="of" derivedContent="Figure 21"/>.</t> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3.2.6-6"> <li pn="section-3.2.6-6.1"> <t indent="0" pn="section-3.2.6-6.1.1">fortarget="ref-mp-dccp-handshaking"/>.</t> <ul> <li> <t>For MP_ADDADDR: The Address ID and Nonce with an associated IP address andif defineda port,otherwise twoif defined; otherwise, 2 bytes of value 0. The IP address and portMUST<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 spacing="normal" bare="false" empty="false" indent="3" pn="section-3.2.6-6.1.2"> <li pn="section-3.2.6-6.1.2.1"> <t indent="0" pn="section-3.2.6-6.1.2.1.1">MP_HMAC(A)<ul> <li> <t>MP_HMAC(A) = HMAC-SHA256(Key=d-keyA, Msg=Address ID+Nonce+NBO(IP)+NBO(Port))</t> </li><li pn="section-3.2.6-6.1.2.2"> <t indent="0" pn="section-3.2.6-6.1.2.2.1">MP_HMAC(B)<li> <t>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-6.2"> <t indent="0" pn="section-3.2.6-6.2.1">for<li> <t>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 spacing="normal" bare="false" empty="false" indent="3" pn="section-3.2.6-6.2.2"> <li pn="section-3.2.6-6.2.2.1"> <t indent="0" pn="section-3.2.6-6.2.2.1.1">MP_HMAC(A)<ul> <li> <t>MP_HMAC(A) = HMAC-SHA256(Key=d-keyA, Msg=Address ID+Nonce)</t> </li><li pn="section-3.2.6-6.2.2.2"> <t indent="0" pn="section-3.2.6-6.2.2.2.1">MP_HMAC(B)<li> <t>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-7">MP_JOIN, MP_ADDADDR<t>MP_JOIN, MP_ADDADDR, and MP_REMOVEADDR canco-existcoexist 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_ADDADDRMP_ADDADDR, orMP_REMOVEADDR.MP_REMOVEADDR options. Therefore, an MP_HMACMUST<bcp14>MUST</bcp14> directly follow its associated multipath option. In the likely case of sendingaan 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-8">On<t>On the receiver side, the HMAC validation of the suboptionsMUST<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 hostMUST<bcp14>MUST</bcp14> silently ignore it (see Sections <xref target="MP_ADDADDR"format="default" sectionFormat="of" derivedContent="Section 3.2.8"/>format="counter"/> and <xref target="MP_REMOVEADDR"format="default" sectionFormat="of" derivedContent="Section 3.2.9"/>).format="counter"/>). If the suboption to be authenticated was MP_JOIN, the subflowMUST<bcp14>MUST</bcp14> be closed (see <xreftarget="fallback" format="default" sectionFormat="of" derivedContent="Section 3.6"/>).</t> <t indent="0" pn="section-3.2.6-9">Intarget="fallback"/>).</t> <t>In the event that an MP_HMAC cannot be associated with asuboptionsuboption, this MP_HMACMUST<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(penultimate(see the penultimate arrow in <xreftarget="ref-mp-dccp-handshaking" format="default" sectionFormat="of" derivedContent="Figure 21"/>).</t>target="ref-mp-dccp-handshaking"/>).</t> </section> <sectionanchor="MP_RTT" numbered="true" removeInRFC="false" toc="include" pn="section-3.2.7"> <name slugifiedName="name-mp_rtt">MP_RTT</name>anchor="MP_RTT"> <name>MP_RTT</name> <figureanchor="ref-MP_RTT" align="left" suppress-title="false" pn="figure-14"> <name slugifiedName="name-format-of-the-mp_rtt-subopt">Formatanchor="ref-MP_RTT"> <name>Format of the MP_RTTsuboption</name> <artwork align="left" pn="section-3.2.7-1.1"><![CDATA[Suboption</name> <artwork><![CDATA[ 1 2 3 4 5 01234567 89012345 67890123 45678901 23456789 01234567 89012345 +--------+--------+--------+--------+--------+--------+--------+ |00101110|00001100|00000110|RTT Type| RTT +--------+--------+--------+--------+--------+--------+--------+ | Age | +--------+--------+--------+--------+--------+ Type=46 Length=12MP_OPT=6 ]]></artwork>MP_OPT=6]]></artwork> </figure><t indent="0" pn="section-3.2.7-2">The<t>The MP_RTT suboption is used to transmit RTT values andageAge (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><t indent="0" pn="section-3.2.7-3">The<t>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<t>The Field RTT type indicates the type of RTT estimation, according to the following description:</t> <dlnewline="true" indent="3" spacing="normal" pn="section-3.2.7-5"> <dt pn="section-3.2.7-5.1">Rawnewline="true"> <dt>Raw RTT (=0)</dt><dd pn="section-3.2.7-5.2"> <t indent="0" pn="section-3.2.7-5.2.1">Raw<dd> <t>Raw RTT value of the last DatagramRound-Trip</t>round trip.</t> </dd></dl> <dl newline="true" indent="3" spacing="normal" pn="section-3.2.7-6"> <dt pn="section-3.2.7-6.1">Min<dt>Min RTT (=1)</dt><dd pn="section-3.2.7-6.2"> <t indent="0" pn="section-3.2.7-6.2.1">Min<dd> <t>Min RTT value over a givenperiod</t>period.</t> </dd></dl> <dl newline="true" indent="3" spacing="normal" pn="section-3.2.7-7"> <dt pn="section-3.2.7-7.1">Max<dt>Max RTT (=2)</dt><dd pn="section-3.2.7-7.2"> <t indent="0" pn="section-3.2.7-7.2.1">Max<dd> <t>Max RTT value over a givenperiod</t>period.</t> </dd></dl> <dl newline="true" indent="3" spacing="normal" pn="section-3.2.7-8"> <dt pn="section-3.2.7-8.1">Smooth<dt>Smooth RTT (=3)</dt><dd pn="section-3.2.7-8.2"> <t indent="0" pn="section-3.2.7-8.2.1">Averaged<dd> <t>Averaged RTT value over a givenperiod</t>period.</t> </dd> </dl><t indent="0" pn="section-3.2.7-9">Each<t>Each CCID specifies the algorithms and period applied for their corresponding RTTestimations.Theestimations. The availability of theabove describedabove-described types, to be used in the MP_RTT option, depends on the CCID implementation in place.</t> <dlnewline="true" indent="3" spacing="normal" pn="section-3.2.7-10"> <dt pn="section-3.2.7-10.1">Age</dt> <dd pn="section-3.2.7-10.2"> <t indent="0" pn="section-3.2.7-10.2.1">Thenewline="false"> <dt>Age:</dt> <dd> <t>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-11">An<t>An example of a flow showing the exchange of path individual RTT information is provided in <xreftarget="ref-MP_RTT_example" format="default" sectionFormat="of" derivedContent="Figure 15"/>.target="ref-MP_RTT_example"/>. RTT1 refers to the first path and RTT2 to the second path. The RTT values could be extracted from the sender's Congestion Control procedure 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_deltawhichthat corresponds to the absolute difference of both values. In the casethatwhere 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> <figureanchor="ref-MP_RTT_example" align="left" suppress-title="false" pn="figure-15"> <name slugifiedName="name-exemplary-flow-of-mp_rtt-ex">Exemplary flowanchor="ref-MP_RTT_example"> <name>Exemplary Flow of MP_RTTexchangeExchange andusage</name> <artwork align="left" pn="section-3.2.7-12.1"><![CDATA[Usage</name> <artwork><![CDATA[ MP-DCCP MP-DCCP Sender Receiver +--------+ MP_RTT(RTT1) +-------------+ | RTT1 |----------------| | | | | path_delta= | | | MP_RTT(RTT2) | |RTT1-RTT2| | | RTT2 |----------------| | +--------++-------------+ ]]></artwork>+-------------+]]></artwork> </figure> </section> <sectionanchor="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">Theanchor="MP_ADDADDR"> <name>MP_ADDADDR</name> <t>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<t>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<t>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<t>The final 2bytes,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 hostMUST<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<t>Along with the MP_ADDADDRoptionoption, an MP_HMAC optionMUST<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 <xreftarget="MP_HMAC" format="default" sectionFormat="of" derivedContent="Section 3.2.6"/>.target="MP_HMAC"/>. <!--[rfced] May we reword this sentence for better readability as shown below? Note that this sentence appears in Sections 3.2.8 and 3.2.9. Original: In the same way as for MP_JOIN, the key for the HMAC algorithm, in the case of the message transmitted by Host A, will be d-KeyA, and in the case of Host B, d-KeyB. Perhaps: 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. --> In the same way as for MP_JOIN, the key for the HMAC algorithm, in the case of the message transmitted by Host A, will be d-KeyA, and in the case of Host B, d-KeyB. 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.Note that, additionally,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, itMUST<bcp14>MUST</bcp14> silently ignore the option.</t><t indent="0" pn="section-3.2.8-6">The<t>The presence of an MP_SEQ (<xreftarget="MP_SEQ" format="default" sectionFormat="of" derivedContent="Section 3.2.5"/>) MUSTtarget="MP_SEQ"/>) <bcp14>MUST</bcp14> be ensured in a DCCP datagram in which MP_ADDADDR is sent, as described in <xreftarget="MP_CONFIRM" format="default" sectionFormat="of" derivedContent="Section 3.2.1"/>.</t>target="MP_CONFIRM"/>.</t> <figureanchor="ref-MP_ADDADDR" align="left" suppress-title="false" pn="figure-16"> <name slugifiedName="name-format-of-the-mp_addaddr-su">Formatanchor="ref-MP_ADDADDR"> <name>Format of the MP_ADDADDRsuboption</name> <artwork align="left" pn="section-3.2.8-7.1"><![CDATA[Suboption</name> <artwork><![CDATA[ 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------+-------+-------+---------------+ |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 LengthMP_OPT=7 ]]></artwork>MP_OPT=7]]></artwork> </figure><t indent="0" pn="section-3.2.8-8">Each<t>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 AddressIDsIDs, and it manages these as it wishes. The Address ID is also used to identify MP_JOIN options (see <xreftarget="MP_JOIN" format="default" sectionFormat="of" derivedContent="Section 3.2.2"/>)target="MP_JOIN"/>) relating to the same address, even when address translators are in use. The Address IDMUST<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<t>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 implementationMAY<bcp14>MAY</bcp14> discard incoming address advertisements. Reasons for thisareare, for example:</t><ul spacing="normal" bare="false" empty="false" indent="3" 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<ul> <li> <t>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<li> <t>because advertised addresses are of no use to it.</t> </li> </ul><t indent="0" pn="section-3.2.8-11">Possible<t>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 hostMUST<bcp14>MUST</bcp14> treat address announcements as soft state. However, a senderMAY<bcp14>MAY</bcp14> choose to update the announcements periodically to overcome temporary limitations.</t><t indent="0" pn="section-3.2.8-12">A<t>A hostMAY<bcp14>MAY</bcp14> advertise private addresses, e.g., because there is a NAT on the path. It is desirable to allowthis, sincethis as there could be cases where both hosts have additional interfaces on the same private network. The advertisement of broadcast or multicast IP addressesMUST<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<t>The MP_JOIN handshake used to create a new subflow (<xreftarget="MP_JOIN" format="default" sectionFormat="of" derivedContent="Section 3.2.2"/>)target="MP_JOIN"/>) 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 hostMUST<bcp14>MUST</bcp14> send a DCCP-Reset.</t><t indent="0" pn="section-3.2.8-14">Further<t>Further security considerations around the issue of MP_ADDADDR messages that accidentally misdirect, or maliciously direct, new MP_JOIN attempts are discussed in <xreftarget="security" format="default" sectionFormat="of" derivedContent="Section 4"/>.target="security"/>. If a sending host of an MP_ADDADDR knows that no incoming subflows can be established at a particular address, an MP_ADDADDRMUST NOT<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, orfromconnectivity checks performed by the host/application.</t><t indent="0" pn="section-3.2.8-15">The<t>The reception of an MP_ADDADDR message is acknowledged using MP_CONFIRM (<xreftarget="MP_CONFIRM" format="default" sectionFormat="of" derivedContent="Section 3.2.1"/>).target="MP_CONFIRM"/>). This ensures a reliable exchange of address information.</t><t indent="0" pn="section-3.2.8-16">A<t>A host that receives anMP_ADDADDR,MP_ADDADDR but findsat connection set upthat the IP address and port number isunsuccessful, SHOULD NOTunsuccessful at connection setup <bcp14>SHOULD NOT</bcp14> perform further connection attempts to this address/port combination for this connection to save resources.IfHowever, if asender, however,sender wishes to trigger a new incoming connection attempt on a previously advertised address/portcombinationcombination, they canthereforerefresh the MP_ADDADDR information by sending the option again.</t><t indent="0" pn="section-3.2.8-17">A<t>A hostMAY<bcp14>MAY</bcp14> send an MP_ADDADDR message with analready assignedalready-assigned Address ID using the IPAddressaddress previously assigned to this Address ID. The new MP_ADDADDR could have the same port number or a different port number. The receiverMUST<bcp14>MUST</bcp14> silently ignore the MP_ADDADDR if the IPAddressaddress is not the same as that previously assigned to this Address ID. A host wishing to replace an existing Address IDMUST<bcp14>MUST</bcp14> first remove the existing one (<xreftarget="MP_REMOVEADDR" format="default" sectionFormat="of" derivedContent="Section 3.2.9"/>).</t>target="MP_REMOVEADDR"/>).</t> </section> <sectionanchor="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,anchor="MP_REMOVEADDR"> <name>MP_REMOVEADDR</name> <t>If, during the lifetime of an MP-DCCP connection, a previously announced address becomes invalid (e.g., if an interface disappears), the affected hostSHOULD<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<t>MP_REMOVEADDR is only used to closealready establishedalready-established subflows that have an invalid address. Functional flows with a valid addressMUST<bcp14>MUST</bcp14> be closed with a DCCP Close exchange (as with regular DCCP) instead of using MP_REMOVEADDR. For more information see <xreftarget="closing" format="default" sectionFormat="of" derivedContent="Section 3.5"/>.</t> <t indent="0" pn="section-3.2.9-3">Thetarget="closing"/>.</t> <t>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<t>Along with the MP_REMOVEADDRsuboption asuboption, an MP_HMAC optionMUST<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 <xreftarget="MP_HMAC" format="default" sectionFormat="of" derivedContent="Section 3.2.6"/>.target="MP_HMAC"/>. In the same way as for MP_JOIN, the key for the HMAC algorithm, in the case of the message transmitted by Host A, will be d-KeyA, and in the case of Host B, d-KeyB. 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<t>The rationale for usingaan HMAC is to prevent unauthorized entities from injecting MP_REMOVEADDR signals in an attempt to hijack a connection.Note that, additionally,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, itMUST<bcp14>MUST</bcp14> silently ignore the option.</t><t indent="0" pn="section-3.2.9-6">A<t>A receiverMUST<bcp14>MUST</bcp14> include an MP_SEQ (<xreftarget="MP_SEQ" format="default" sectionFormat="of" derivedContent="Section 3.2.5"/>)target="MP_SEQ"/>) in a DCCP datagram that sends an MP_REMOVEADDR. Further details are given in <xreftarget="MP_CONFIRM" format="default" sectionFormat="of" derivedContent="Section 3.2.1"/>.</t> <t indent="0" pn="section-3.2.9-7">Thetarget="MP_CONFIRM"/>.</t> <t>The reception of an MP_REMOVEADDR message is acknowledged using MP_CONFIRM (<xreftarget="MP_CONFIRM" format="default" sectionFormat="of" derivedContent="Section 3.2.1"/>).target="MP_CONFIRM"/>). This ensures a reliable exchange of address information. To avoid inconsistent states, the sender releases theaddressAddress ID only after MP_REMOVEADDR has been confirmed.</t><t indent="0" pn="section-3.2.9-8">The<t>The sending and receiving of this messageSHOULD<bcp14>SHOULD</bcp14> trigger the closing procedure described in <xreftarget="RFC4340" format="default" sectionFormat="of" derivedContent="RFC4340"/>target="RFC4340"/> between the client and the server on the affected subflow(s), if possible. This helps remove middleboxstate,state before removing any local state.</t><t indent="0" pn="section-3.2.9-9">Address<t>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> <figureanchor="refMP_REMOVEADDR" align="left" suppress-title="false" pn="figure-17"> <name slugifiedName="name-format-of-the-mp_removeaddr">Formatanchor="refMP_REMOVEADDR"> <name>Format of the MP_REMOVEADDRsuboption</name> <artwork align="left" pn="section-3.2.9-10.1"><![CDATA[Suboption</name> <artwork><![CDATA[ 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------+---------------+---------------+ |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 -> followed by the MP_HMACoption ]]></artwork>option]]></artwork> </figure> </section> <sectionanchor="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">Theanchor="MP_PRIO"> <name>MP_PRIO</name> <t>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<t>The MP_PRIO suboption, shown below, can be used to set a priority value for the subflow over which the suboption is received.</t> <figureanchor="ref-MP_PRIO" align="left" suppress-title="false" pn="figure-18"> <name slugifiedName="name-format-of-the-mp_prio-subop">Formatanchor="ref-MP_PRIO"> <name>Format of the MP_PRIOsuboption</name> <artwork align="left" pn="section-3.2.10-3.1"><![CDATA[Suboption</name> <!-- [rfced] FYI: For consistency with the other figures, we fixed the bit ruler on Figure 18. (We extended the right side of the box by one space so that the placement of the final "1" is over the minus sign rather than the plus sign.) Please let us know if this is not accurate. --> <artwork><![CDATA[ 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+---------------+---------------+---------------+--------------++---------------+---------------+---------------+---------------+ |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=4MP_OPT=9 ]]></artwork>MP_OPT=9]]></artwork> </figure><t indent="0" pn="section-3.2.10-4">The<t>The following values are available for the Prio field:</t><ul spacing="normal" bare="false" empty="false" indent="3" 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:<ul> <li> <t>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:<li> <t>1: Standby:doDo not use this path for trafficscheduling,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:<li> <t>2: Secondary:doDo not use this path for trafficscheduling,scheduling if the other paths are good enough. The path will be used occasionally for increasingtemporarilythe availablecapacity, e.g.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<li> <t>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<t>Example use cases include:</t><ol spacing="normal" type="1" indent="adaptive" start="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<ol><li> <!--[rfced] Section 3.2.10. Please confirm if "Cellular paths" should be singular in the first sentence below, as we note the singular form in the sentence that follows as well as in use cases #2 and #3. Original: 1. Setting Wi-Fi path to Primary and Cellular paths 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. Perhaps: 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. --> <t>Setting the Wi-Fi path to Primary and Cellular paths 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<li> <t>Setting the Wi-Fi path to Primary and Cellular path to Standby. In thiscasecase, 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<li> <t>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<t>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 isRECOMMENDED<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 suboptionMUST<bcp14>MUST</bcp14> be acknowledged via an MP_CONFIRM (see <xreftarget="ref-mp-option-confirm" format="default" sectionFormat="of" derivedContent="Table 4"/>).</t> <t indent="0" pn="section-3.2.10-9">Thetarget="ref-mp-option-confirm"/>).</t> <t>The relative ratio of the primary path values 3-15dependdepends on the path usage strategy, which is described in more detail in <xreftarget="path_usage_strategy" format="default" sectionFormat="of" derivedContent="Section 3.11"/>.target="path_usage_strategy"/>. <!--[rfced] Please clarify "and MUST be the appropriate one" - is "appropriate one" essential to the sentence, or could it be reworded as "the path MUST have the highest available priority value" as shown below? Original: In the case of path mobility(<xref target="path_mobility" format="default" sectionFormat="of" derivedContent="Section 3.11.1"/>),(Section 3.11.1), only one path can be used at a time and MUST be the appropriate one that has the highest available priority value including also the prio numbers 1 and 2. Perhaps: In the case of path mobility (Section 3.11.1), only one path can be used at a time, and the path MUST have the highest available priority value that includes the prio numbers 1 and 2. --> In the case of path mobility (<xref target="path_mobility"/>), only one path can be used at a time and <bcp14>MUST</bcp14> be the appropriate one that has the highest available priority value including also the prio numbers 1 and 2. In the other case of concurrent path usage (<xreftarget="concurrent_usage" format="default" sectionFormat="of" derivedContent="Section 3.11.2"/>),target="concurrent_usage"/>), the definition is up to the multipath scheduler logic.</t><t indent="0" pn="section-3.2.10-10">An<t>An MP_SEQ (<xreftarget="MP_SEQ" format="default" sectionFormat="of" derivedContent="Section 3.2.5"/>) MUSTtarget="MP_SEQ"/>) <bcp14>MUST</bcp14> be present in a DCCP datagram in which the MP_PRIO suboption is sent. Further details are given in <xreftarget="MP_CONFIRM" format="default" sectionFormat="of" derivedContent="Section 3.2.1"/>.</t>target="MP_CONFIRM"/>.</t> </section> <sectionanchor="MP_CLOSE" numbered="true" removeInRFC="false" toc="include" pn="section-3.2.11"> <name slugifiedName="name-mp_close">MP_CLOSE</name>anchor="MP_CLOSE"> <name>MP_CLOSE</name> <figureanchor="ref-MP_CLOSE" align="left" suppress-title="false" pn="figure-19"> <name slugifiedName="name-format-of-the-mp_close-subo">Formatanchor="ref-MP_CLOSE"> <name>Format of the MP_CLOSEsuboption</name> <artwork align="left" pn="section-3.2.11-1.1"><![CDATA[Suboption</name> <artwork><![CDATA[ 1 2 3 01234567 89012345 67890123 45678901 23456789 +--------+--------+--------+--------+--------+ |00101110| var |00001010| Key Data ... +--------+--------+--------+--------+--------+ Type=46 LengthMP_OPT=10 ]]></artwork>MP_OPT=10]]></artwork> </figure><t indent="0" pn="section-3.2.11-2">An<t>An MP-DCCP connection can be gracefully closed by sendingandan MP_CLOSE to the peer host. On all subflows, the regular termination procedureasdescribed in <xreftarget="RFC4340" format="default" sectionFormat="of" derivedContent="RFC4340"/> MUSTtarget="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-CloseMUST<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, allsocketssockets, including the MP-DCCP connection socket, transition to CLOSEREQ state. <!--[rfced] Please clarify "in by"; is the intended meaning included "in" or "by" the MP_CLOSE option? Also, should the second "must" be "MUST"? Original: To protect from unauthorized shutdown of a multi-path connection, the selected Key Data of the peer host during the handshaking procedure MUST be included in by the MP_CLOSE option and must be validated by the peer host. Perhaps (if "in"): To protect from unauthorized shutdown of a multipath connection, the selected Key Data of the peer host MUST be included in the MP_CLOSE option during the handshaking procedure and MUST be validated by the peer host. --> <!--[rfced] We are having trouble parsing this sentence. Please clarify what items "between" refers to. Original: Note, the Key Data is different between MP_CLOSE option carried by DCCP-CloseReq or DCCP-Close. --> To protect from unauthorized shutdown of a multipath connection, the selected Key Data of the peer host during the handshaking procedure <bcp14>MUST</bcp14> be included in by the MP_CLOSE option and must be validated by the peer host. Note, the Key Data is different between MP_CLOSE option carried by DCCP-CloseReq or DCCP-Close.</t><t indent="0" pn="section-3.2.11-3">On<t>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-4">Upon<t>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 1MUST<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-5">When<t>When the MP-DCCP connection socket is in CLOSEREQ or CLOSE state, new subflow requests using MP_JOINMUST<bcp14>MUST</bcp14> be ignored.</t><t indent="0" pn="section-3.2.11-6">Contrary<t>Contrary to an MP_FAST_CLOSE (<xreftarget="MP_FAST_CLOSE" format="default" sectionFormat="of" derivedContent="Section 3.2.3"/>),target="MP_FAST_CLOSE"/>), no single-sided abrupt termination is applied.</t> </section> <sectionanchor="MP_EXP" numbered="true" removeInRFC="false" toc="include" pn="section-3.2.12"> <name slugifiedName="name-experimental-multipath-opti">Experimentalanchor="MP_EXP"> <name>Experimental MultipathoptionOption MP_EXP forprivate use</name> <t indent="0" pn="section-3.2.12-1">ThisPrivate Use</name> <t>This section reserves a Multipath option to define and specify any experimental additional feature for improving andoptimization ofoptimizing 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> <!--[rfced] Figure 20: May we change "Data TBD" to simply "Data", as shown below? It is already explained directly below the figure: "The Data field can carry any data..." We note that "TBD" is used for a different purpose (in Table 3) to refer to the option length being "TBD" when the option type is >11. Original: |0 0 1 0 1 1 1 0| var |0 0 0 0 1 0 1 1| Data TBD | Perhaps: |0 0 1 0 1 1 1 0| var |0 0 0 0 1 0 1 1| Data | --> <figureanchor="ref-MP_EXP" align="left" suppress-title="false" pn="figure-20"> <name slugifiedName="name-format-of-the-mp_exp-subopt">Formatanchor="ref-MP_EXP"> <name>Format of the MP_EXPsuboption</name> <artwork align="left" pn="section-3.2.12-2.1"><![CDATA[Suboption</name> <artwork><![CDATA[ 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------+---------------+---------------+ |0 0 1 0 1 1 1 0| var |0 0 0 0 1 0 1 1| Data TBD | +---------------+---------------+---------------+---------------+ | ... +---------------------------------------------------------------+ Type=46 LengthMP_OPT=11 ]]></artwork>MP_OPT=11]]></artwork> </figure><t indent="0" pn="section-3.2.12-3">The<t>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> <sectionanchor="handshaking" numbered="true" removeInRFC="false" toc="include" pn="section-3.3"> <name slugifiedName="name-mp-dccp-handshaking-procedu">MP-DCCPanchor="handshaking"> <name>MP-DCCP Handshaking Procedure</name><t indent="0" pn="section-3.3-1">An<t>An exampleto illustrate theMP-DCCP handshake procedure is shown in <xreftarget="ref-mp-dccp-handshaking" format="default" sectionFormat="of" derivedContent="Figure 21"/>.</t>target="ref-mp-dccp-handshaking"/>.</t> <figureanchor="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"><![CDATA[anchor="ref-mp-dccp-handshaking"> <!--[rfced] FYI, in Figure 21, "DCCP-ACK" has been updated to "DCCP-Ack" to match usage in the rest of the document. --> <name>Example MP-DCCP Handshake</name> <artwork><![CDATA[ Host A Host B ------------------------ ---------- Address A1 Address A2 Address B1 ---------- ---------- ---------- | | | | DCCP-Request + Change R (MP_CAPABLE,...) | |----- MP_KEY(CI-A + KeyA(1), KeyA(2),...) ---------->| |<------------------- MP_KEY(CI-B + KeyB) ------------| | DCCP-Response + Confirm L (MP_CAPABLE, ...) | | | | | DCCP-Ack | | |---------------------------------------------------->| |<----------------------------------------------------| | DCCP-Ack | | | | | | |DCCP-Request + Change R(MP_CAPABLE,...)| | |--- MP_JOIN(CI-B,RA) ----------------->| | |<------MP_JOIN(CI-A,RB) + MP_HMAC(B)---| | |DCCP-Response+Confirm L(MP_CAPABLE,...)| | | | | |DCCP-Ack | | |-------- MP_HMAC(A) ------------------>| | |<--------------------------------------| ||DCCP-ACK | ]]></artwork>|DCCP-Ack |]]></artwork> </figure><t indent="0" pn="section-3.3-3">The<t>The basic initial handshake for the first subflow is as follows:</t><ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3.3-4"> <li pn="section-3.3-4.1"> <t indent="0" pn="section-3.3-4.1.1">Host<ul> <li> <t>Host A sends a DCCP-Request with the MP-Capable featureChangechange 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 <xreftarget="MP_KEY" format="default" sectionFormat="of" derivedContent="Section 3.2.4"/>.target="MP_KEY"/>. CI-A is a unique identifier during the lifetime of an MP-DCCP connection.</t> </li><li pn="section-3.3-4.2"> <t indent="0" pn="section-3.3-4.2.1">Host<li> <t>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"> <t indent="0" pn="section-3.3-4.3.1">Host<li> <t>Host A sends a DCCP-Ack to confirm the proper key exchange.</t> </li><li pn="section-3.3-4.4"> <t indent="0" pn="section-3.3-4.4.1">Host<li> <t>Host B sends a DCCP-Ack to complete the handshake and set both connection ends to the OPEN state.</t> </li> </ul><t indent="0" pn="section-3.3-5">It<t>It should be noted that DCCP is protected against corruption of DCCP header data(section 9 of <xref(<xref target="RFC4340"format="default"sectionFormat="of"derivedContent="RFC4340"/>),section="9"/>), 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<t>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<t>The handshake for subsequentsubflowssubflows, based on a successful initialhandshakehandshake, is as follows:</t><ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3.3-8"> <li pn="section-3.3-8.1"> <t indent="0" pn="section-3.3-8.1.1">Host<ul> <li> <t>Host A sends a DCCP-Request with the MP-Capable featureChangechange request and the MP_JOIN option with Host B's CI-B, obtained during the initial handshake. <!--[rfced] What does "own" refer to in "own random nonce RA"? Original: Additionally, an own random nonce RA is transmitted with the MP_JOIN. --> Additionally, an own random nonce RA is transmitted with the MP_JOIN.</t> </li><li pn="section-3.3-8.2"> <t indent="0" pn="section-3.3-8.2.1">Host<li> <t>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. <!--[rfced] In Section 3.3, is "message" the "HMAC Message" and "key" the "Key" described in Section 3.2.6? If so, should these terms be capitalized as shown below? Note that there is similar text in the paragraph that follows (which refers to MP_JOIN(B)"). Original: As specified in<xref target="MP_HMAC" format="default" sectionFormat="of" derivedContent="Section 3.2.6"/>,Section 3.2.6, the HMAC is calculated by taking the leftmost 20 bytes from the SHA256 hash of a HMAC code created by using the nonce received with MP_JOIN(A) and the local nonce RB as message and the derived key described in Section 3.2.4 as key: Perhaps: As specified in Section 3.2.6, the HMAC is calculated by taking the leftmost 20 bytes from the SHA256 hash of an HMAC code that is created by using both 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 Section 3.2.4: --> As specified in <xreftarget="MP_KEY" format="default" sectionFormat="of" derivedContent="Section 3.2.4"/>target="MP_HMAC"/>, the HMAC is calculated by taking the leftmost 20 bytes from the SHA256 hash of an HMAC code created by using the nonce received with MP_JOIN(A) and the local nonce RB as message and the derived key described in <xref target="MP_KEY"/> as key: </t><t indent="0" pn="section-3.3-8.2.2"> MP_HMAC(B)<t>MP_HMAC(B) = HMAC-SHA256(Key=d-keyB, Msg=RB+RA)</t> </li><li pn="section-3.3-8.3"> <t indent="0" pn="section-3.3-8.3.1">Host<li> <t>Host A sends a DCCP-Ack with the HMAC computed for the DCCP-Response. As specified in <xreftarget="MP_HMAC" format="default" sectionFormat="of" derivedContent="Section 3.2.6"/>,target="MP_HMAC"/>, the HMAC is calculated by taking the leftmost 20 bytes from the SHA256 hash ofaan 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 <xreftarget="MP_KEY" format="default" sectionFormat="of" derivedContent="Section 3.2.4"/>target="MP_KEY"/> as key: </t><t indent="0" pn="section-3.3-8.3.2"> MP_HMAC(A)<t>MP_HMAC(A) = HMAC-SHA256(Key=d-keyA, Msg=RA+RB)</t> </li><li pn="section-3.3-8.4"> <t indent="0" pn="section-3.3-8.4.1">Host<li> <t>Host B sends a DCCP-Ack to confirm the HMAC and to conclude the handshaking.</t> </li> </ul> </section> <sectionanchor="address-knowledge-exchange" numbered="true" removeInRFC="false" toc="include" pn="section-3.4"> <name slugifiedName="name-address-knowledge-exchange">Address knowledge exchange</name>anchor="address-knowledge-exchange"> <name>Address Knowledge Exchange</name> <sectionanchor="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">Advertisinganchor="advertising-a-new-path-mpaddaddr"> <name>Advertising anew pathNew Path (MP_ADDADDR)</name><t indent="0" pn="section-3.4.1-1">When<t>When a host (Host A) wants to advertise the availability of a new path, it should use the MP_ADDADDR option (<xreftarget="MP_ADDADDR" format="default" sectionFormat="of" derivedContent="Section 3.2.8"/>)target="MP_ADDADDR"/>) as shown in the example in <xreftarget="ref-mp-dccp-add-address" format="default" sectionFormat="of" derivedContent="Figure 22"/>.target="ref-mp-dccp-add-address"/>. The MP_ADDADDR option passed in the DCCP-Data contains the following parameters:</t><ul spacing="normal" bare="false" empty="false" indent="3" 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<ul> <li> <t>an identifier (id 2) for the new IPaddressaddress, which is used as a reference in subsequent controlexchanges.</t>exchanges</t> </li><li pn="section-3.4.1-2.2"> <t indent="0" pn="section-3.4.1-2.2.1">a<li> <t>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<li> <t>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<li> <t>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 addressA1_IP</t>A1_IP.</t> </li> </ul><t indent="0" pn="section-3.4.1-3">According<t>According to <xreftarget="MP_ADDADDR" format="default" sectionFormat="of" derivedContent="Section 3.2.8"/>,target="MP_ADDADDR"/>, the following options are required in a packet carrying MP_ADDADDR:</t><ul spacing="normal" bare="false" empty="false" indent="3" 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<ul> <li> <t>the leftmost 20 bytes of the HMAC(A) generated during the initial handshaking procedure described in Sections <xref target="handshaking"format="default" sectionFormat="of" derivedContent="Section 3.3"/>format="counter"/> and <xref target="MP_HMAC"format="default" sectionFormat="of" derivedContent="Section 3.2.6"/></t>format="counter"/></t> </li><li pn="section-3.4.1-4.2"> <t indent="0" pn="section-3.4.1-4.2.1">the<li> <t>the MP_SEQ option with the sequence number (seqno 12) for thismessagemessage, according to <xreftarget="MP_SEQ" format="default" sectionFormat="of" derivedContent="Section 3.2.5"/>.</t>target="MP_SEQ"/></t> </li> </ul><t indent="0" pn="section-3.4.1-5">Host<t>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 spacing="normal" bare="false" empty="false" indent="3" 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<ul> <li> <t>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<li> <t>the leftmost 20 bytes of the HMAC(B) generated during the initial handshaking procedure<xref target="handshaking" format="default" sectionFormat="of" derivedContent="Section 3.3"/></t>(<xref target="handshaking"/>)</t> </li> </ul> <figureanchor="ref-mp-dccp-add-address" align="left" suppress-title="false" pn="figure-22"> <name slugifiedName="name-example-mp-dccp-addaddr-pro">Exampleanchor="ref-mp-dccp-add-address"> <name>Example MP-DCCP ADDADDRprocedure</name> <artwork align="left" pn="section-3.4.1-7.1"><![CDATA[Procedure</name> <artwork><![CDATA[ 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) -------------->| | | | | DCCP-Ack + MP_HMAC(B) + | |<----- MP_CONFIRM(seqno 12, MP_ADDADDR)-------------| ]]></artwork>-------------|]]></artwork> </figure> </section> <sectionanchor="removing-a-path-mpremoveaddr" numbered="true" removeInRFC="false" toc="include" pn="section-3.4.2"> <name slugifiedName="name-removing-a-path-mp_removead">Removinganchor="removing-a-path-mpremoveaddr"> <name>Removing apathPath (MP_REMOVEADDR)</name><t indent="0" pn="section-3.4.2-1">When<t>When a host (Host A) wants to indicate that a path is no longer available, it should use the MP_REMOVEADDR option (<xreftarget="MP_REMOVEADDR" format="default" sectionFormat="of" derivedContent="Section 3.2.9"/>)target="MP_REMOVEADDR"/>) as shown in the example in <xreftarget="ref-mp-dccp-remove-address" format="default" sectionFormat="of" derivedContent="Figure 23"/>.target="ref-mp-dccp-remove-address"/>. The MP_REMOVEADDR option passed in the DCCP-Data contains the following parameters:</t><ul spacing="normal" bare="false" empty="false" indent="3" 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<ul> <li> <t>an identifier (id 2) for the IP address to remove (A2_IP) andwhichthat was specified in a previous MP_ADDADDRmessage.</t>message</t> </li><li pn="section-3.4.2-2.2"> <t indent="0" pn="section-3.4.2-2.2.1">a<li> <t>a Nonce value to prevent replay attacks</t> </li> </ul><t indent="0" pn="section-3.4.2-3">According<t>According to <xreftarget="MP_REMOVEADDR" format="default" sectionFormat="of" derivedContent="Section 3.2.9"/>,target="MP_REMOVEADDR"/>, the following options are required in a packet carrying MP_REMOVEADDR:</t><ul spacing="normal" bare="false" empty="false" indent="3" 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<ul> <li> <t>the leftmost 20 bytes of the HMAC(A) generated during the initial handshaking procedure described in Sections <xref target="handshaking"format="default" sectionFormat="of" derivedContent="Section 3.3"/>format="counter"/> and <xref target="MP_HMAC"format="default" sectionFormat="of" derivedContent="Section 3.2.6"/></t>format="counter"/></t> </li><li pn="section-3.4.2-4.2"> <t indent="0" pn="section-3.4.2-4.2.1">the<li> <t>the MP_SEQ option with the sequence number (seqno 33) for thismessagemessage, according to <xreftarget="MP_SEQ" format="default" sectionFormat="of" derivedContent="Section 3.2.5"/>.</t>target="MP_SEQ"/></t> </li> </ul><t indent="0" pn="section-3.4.2-5">Host<t>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 spacing="normal" bare="false" empty="false" indent="3" 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<ul> <li> <t>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<li> <t>the leftmost 20 bytes of the HMAC(B) generated during the initial handshaking procedure<xref target="handshaking" format="default" sectionFormat="of" derivedContent="Section 3.3"/></t>(<xref target="handshaking"/>)</t> </li> </ul> <figureanchor="ref-mp-dccp-remove-address" align="left" suppress-title="false" pn="figure-23"> <name slugifiedName="name-example-mp-dccp-removeaddr-">Exampleanchor="ref-mp-dccp-remove-address"> <name>Example MP-DCCP REMOVEADDRprocedure</name> <artwork align="left" pn="section-3.4.2-7.1"><![CDATA[Procedure</name> <artwork><![CDATA[ Host A Host B ------------------------ ----------- Address A1 Address A2 Address B1 ---------- ---------- ----------- | | | | DCCP-Data + MP_REMOVEADDR(id 2, Nonce) + | |------- MP_HMAC(A) + MP_SEQ(seqno 33) -------------->| | | | | DCCP-Ack + MP_HMAC(B) + | |<----- MP_CONFIRM(seqno 33, MP_REMOVEADDR)----------| ]]></artwork>----------|]]></artwork> </figure> </section> </section> <sectionanchor="closing" numbered="true" removeInRFC="false" toc="include" pn="section-3.5"> <name slugifiedName="name-closing-an-mp-dccp-connecti">Closinganchor="closing"> <name>Closing an MP-DCCPconnection</name> <t indent="0" pn="section-3.5-1">WhenConnection</name> <t>When a host wants to close an existing subflow but not the whole MP-DCCP connection, itMUST<bcp14>MUST</bcp14> initiate the regular DCCP connection termination procedure as described inSection 5.6 of<xref target="RFC4340"format="default"sectionFormat="of"derivedContent="RFC4340"/>,section="5.6"/>, 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, itMUST<bcp14>MUST</bcp14> use an appropriate DCCP-Reset code as specifiedinby IANA <xreftarget="DCCP.Parameter" format="default" sectionFormat="of" derivedContent="DCCP.Parameter"/>target="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 subflowsMUST NOT<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<t>A host terminates an MP-DCCP connection using the DCCP connection termination specified insection 5.5 of<xref target="RFC4340"format="default"sectionFormat="of"derivedContent="RFC4340"/>section="5.5"/> on each subflow with the first packet on each subflow carrying MP_CLOSE (see <xreftarget="MP_CLOSE" format="default" sectionFormat="of" derivedContent="Section 3.2.11"/>).</t> <artwork align="left" pn="section-3.5-3"><![CDATA[target="MP_CLOSE"/>).</t> <artwork><![CDATA[ Host A Host B ------ ------ <- Optional DCCP-CloseReq + MP_CLOSE [A's key] [on all subflows] DCCP-Close + MP_CLOSE -> [B's key] [on all subflows] <- DCCP-Reset [on allsubflows] ]]></artwork> <t indent="0" pn="section-3.5-4">Additionally,subflows]]]></artwork> <t>Additionally, an MP-DCCP connection may be closed abruptly using the "Fast Close" procedure described in <xreftarget="MP_FAST_CLOSE" format="default" sectionFormat="of" derivedContent="Section 3.2.3"/>,target="MP_FAST_CLOSE"/>, 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"><![CDATA[<artwork><![CDATA[ Host A Host B ------ ------ DCCP-Reset + MP_FAST_CLOSE -> [B's key] [on all subflows] <- DCCP-Reset [on allsubflows] ]]></artwork>subflows]]]></artwork> </section> <sectionanchor="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">Whenanchor="fallback"> <name>Fallback</name> <t>When a subflow fails to operate followingMP-DCCPthe intendedbehavior,behavior of the MP-DCCP, it is necessary to proceed with afall back.fallback. This may be either falling back to regular DCCP <xreftarget="RFC4340" format="default" sectionFormat="of" derivedContent="RFC4340"/>target="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-DCCPoptionsoptions, or modification of payload data.</t><t indent="0" pn="section-3.6-2">At<t>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 MP_CAPABLE feature, the MP-DCCP connection will not be established and the handshakeSHOULD<bcp14>SHOULD</bcp14> fall back to regular DCCP. If this is notpossiblepossible, the connectionMUST<bcp14>MUST</bcp14> be closed.</t><t indent="0" pn="section-3.6-3">If<t>If the endpoints fail to agree on the protocol version to use during the Multipath Capable feature negotiation, the connectionMUST<bcp14>MUST</bcp14> either be closed or fall back to regular DCCP. This is described in <xreftarget="mp_capable" format="default" sectionFormat="of" derivedContent="Section 3.1"/>.target="mp_capable"/>. The protocol version negotiation distinguishes between negotiation for the initial connectionestablishment,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 fall back<t>The fallback proceduretofor regular DCCPMUST be<bcp14>MUST</bcp14> also be applied if the MP_KEY<xref target="MP_KEY" format="default" sectionFormat="of" derivedContent="Section 3.2.4"/>(<xref target="MP_KEY"/>) Key Type cannot be negotiated.</t><t indent="0" pn="section-3.6-5">If<t>If a subflow attempts to join an existing MP-DCCPconnection,connection but MP-DCCP options or the MP_CAPABLE feature are not present or are faulty in the handshake procedure, that subflowMUST<bcp14>MUST</bcp14> be closed. This isespeciallythe case especially if a different MP_CAPABLE version than the originally negotiated version is used. Reception of a non-verifiable MP_HMAC (<xreftarget="MP_HMAC" format="default" sectionFormat="of" derivedContent="Section 3.2.6"/>)target="MP_HMAC"/>) or an invalid CI used in MP_JOIN (<xreftarget="MP_JOIN" format="default" sectionFormat="of" derivedContent="Section 3.2.2"/>)target="MP_JOIN"/>) during flow establishmentMUST<bcp14>MUST</bcp14> cause the subflow to be closed.</t><t indent="0" pn="section-3.6-6">The<t>The subflow closing procedureMUST be<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<t>Another relevant case is when payload data is modified by middleboxes. DCCP uses a checksum to protect the data, as described insection 9 of<xref target="RFC4340"format="default"sectionFormat="of"derivedContent="RFC4340"/>.section="9"/>. 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.DCCP defines that ifIf the checksumfails,fails as defined by the DCCP, the receiving endpointMUST<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 subflowMAY<bcp14>MAY</bcp14> be closed. The same procedure applies if the MP option is unknown.</t> </section> <sectionanchor="state-diagram" numbered="true" removeInRFC="false" toc="include" pn="section-3.7"> <name slugifiedName="name-state-diagram">Stateanchor="state-diagram"> <name>State Diagram</name><t indent="0" pn="section-3.7-1">The<t>The MP-DCCP per subflow state transitionsto a large extentfollow the state transitions defined for DCCP in <xreftarget="RFC4340" format="default" sectionFormat="of" derivedContent="RFC4340"/>,target="RFC4340"/> to a large extent, with some modifications due to the MP-DCCPfour-way4-way handshake and fast close procedures. The state diagram belowillustratesshows 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">The<!--[rfced] May we reword this sentence for improved readability? Original: The states transitioned when moving from the CLOSED to OPEN state during the four-way handshake remain the same as for DCCP, but it is no longer possible to transmit application data while in the REQUEST state. Perhaps: 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. --> <t>The states transitioned when moving from the CLOSED to OPEN state during the 4-way handshake 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> <figureanchor="ref-mp-dccp-state-transition" align="left" suppress-title="false" pn="figure-24"> <name slugifiedName="name-most-common-state-transitio">Most common state transitionsanchor="ref-mp-dccp-state-transition"> <name>Most Common State Transitions of an MP-DCCPsubflow</name> <artwork align="left" pn="section-3.7-3.1"><![CDATA[Subflow</name> <artwork><![CDATA[ +----------------------------+ +------------------------------+ | 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 | | | | +-----------+ | | | +------------>| OPEN |<-----------+ | | +--+-+-+-+--+ | | server active close | | | | active close | | snd CloseReq | | | | or rcv CloseReq | | | | | | snd Close | | | | | | | | +-----------+ | | | | +----------+ | | | CLOSEREQ |<---------+ | | +----------->| CLOSING | | | +-----+-----+ | | +----+-----+ | | | rcv Close | | rcv Reset | | | | snd Reset | | | | | | | | active FastClose | | |<----------+ rcv Close | | or rcv FastClose v | | or server active FastClose | | snd Reset +----+-----+ | | or server rcv FastClose | +------------->| TIMEWAIT | | | snd Reset | +----+-----+ | +------------------------------+ | | +-----------+ 2MSL timerexpires ]]></artwork>expires]]></artwork> </figure> </section> <sectionanchor="congestion-control-considerations" numbered="true" removeInRFC="false" toc="include" pn="section-3.8"> <name slugifiedName="name-congestion-control-consider">Congestionanchor="congestion-control-considerations"> <name>Congestion Control Considerations</name><t indent="0" pn="section-3.8-1">Senders MUST<t>Senders <bcp14>MUST</bcp14> manage per-path congestionstatus,status and avoidtosending more data on a given path than congestion control allows for eachpath allows.</t>path.</t> </section> <sectionanchor="mps" numbered="true" removeInRFC="false" toc="include" pn="section-3.9"> <name slugifiedName="name-maximum-packet-size-conside">Maximumanchor="mps"> <name>Maximum Packet Size Considerations</name><t indent="0" pn="section-3.9-1">A<t>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"format="default"sectionFormat="of"derivedContent="RFC4340"/>, Section 14.section="14"/>. Without any restrictions, this is adopted for MP-DCCP operations, in particular thePMTUPath MTU (PMTU) measurement and the SenderBehaviour.Behavior. The DCCP application interfaceSHOULD<bcp14>SHOULD</bcp14> allow the application to discover the current MPS. This reflects the currentsupportedlargest size supported for the data stream that can be used across the set of all active MP-DCCP subflows.</t> </section> <sectionanchor="maximum-number-of-subflows-considerations" numbered="true" removeInRFC="false" toc="include" pn="section-3.10"> <name slugifiedName="name-maximum-number-of-subflows-">Maximum numberanchor="maximum-number-of-subflows-considerations"> <name>Maximum Number ofSubflowsSubflow Considerations</name><t indent="0" pn="section-3.10-1">MP-DCCP<t>MP-DCCP does not support any explicit procedure to negotiate the maximum number of subflows between endpoints.InHowever, in practical scenarios,however,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<t>It isRECOMMENDED<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 <xreftarget="RFC4340" format="default" sectionFormat="of" derivedContent="RFC4340"/>target="RFC4340"/> if the resource limit is exceeded or it is known that the multipath connection will not benefit from further subflows. <!--[rfced] Is "aspect of" essential to this sentence or may it be removed? Original: Likewise, the host that wants to create the subflows is RECOMMENDED to consider the aspect of available resources and the possible gains. Perhaps: Likewise, it is RECOMMENDED that the host that wants to create the subflows considers the available resources and possible gains. --> Likewise, the host that wants to create the subflows is <bcp14>RECOMMENDED</bcp14> to consider the aspect of available resources and the possible gains.</t><t indent="0" pn="section-3.10-3">To<t>To avoid further inefficiencies with subflows due to short-lived connections, itMAY<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<t>While in thesocket buffer basedsocket-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, thetiming basedtiming-based approach delays the start of additional subflows based on a certain time period,loadload, or knowledge of traffic and path properties. Thedelay baseddelay-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> <sectionanchor="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-DCCPanchor="path_usage_strategy"> <name>Path Usage Strategies</name> <t>MP-DCCP can be configured to realize one of several strategies for pathusage,usage via selecting one DCCP subflow out of the multiple DCCP subflows within an MP-DCCP connection for data transmission. <!--[rfced] FYI: We added semicolons to this list for better readability. Please let us know if you prefer otherwise. Original: 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 orDCCP-Close/DCCP-ResetDCCP- Close/DCCP-Reset and also path metrics such as packet-loss-rate, CWND or RTT provided by the Congestion Control Algorithm. Current: 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. --> 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> <sectionanchor="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">Theanchor="path_mobility"> <name>Path Mobility</name> <t>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) orde-prioritized,deprioritized, the MP-DCCP endpointSHOULD<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. <!--[rfced] Does "SHOULD" refer only to the first part of this sentence? And does "if not available" refer to the "path priority"? If so, may we rephrase the text as shown below for clarity? Original: This process SHOULD respect the path priority configured by the MP_PRIO suboption or if not available pick the most divergent source- destination pair from the original used source-destination pair. Perhaps: This process SHOULD 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. --> This process <bcp14>SHOULD</bcp14> respect the path priority configured by the MP_PRIO suboption or, if not available, pick the most divergent source-destination pair from the original used source-destination pair.</t><ul empty="true" bare="false" indent="3" spacing="normal" pn="section-3.11.1-2"> <li pn="section-3.11.1-2.1"> <t indent="0" pn="section-3.11.1-2.1.1">Note:<aside><t>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 <xreftarget="multipath-dccp.org" format="default" sectionFormat="of" derivedContent="multipath-dccp.org"/>.</t> </li> </ul>target="MP-DCCP.Site"/>.</t></aside> </section> <sectionanchor="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 toanchor="concurrent_usage"> <name>Concurrent Path Usage</name> <t>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 connectionthroughput.<br/> Inthroughput.</t> <t>In this scenario, the selection of congestion control, per-packetschedulingscheduling, and a potentialre-orderingreordering 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,minimizingminimize latency, etc.</t><t indent="0" pn="section-3.11.2-2">Concurrent<t>Concurrent path usage over the Internet can have implications. When a Multipath 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 scheme could result in an unfair distribution of the capacity with the multipath connection using more capacity than competingsingle path connections.<br/> Multipathsingle-path connections.</t> <t>Multipath TCP uses the coupled congestion control Linked Increases Algorithm (LIA) specified inthean experimental specification <xreftarget="RFC6356" format="default" sectionFormat="of" derivedContent="RFC6356"/>target="RFC6356"/> to solve this problem. This scheme could also be specified for Multipath DCCP. The same applies to other coupled congestion control schemes that have been proposed for Multipath TCP such as the Opportunistic Linked Increases Algorithm <xreftarget="OLIA" format="default" sectionFormat="of" derivedContent="OLIA"/>.</t> <t indent="0" pn="section-3.11.2-3">Thetarget="OLIA"/>.</t> <t>The specification of scheduling for concurrent multipath and relatedthecongestion control algorithms andre-orderingreordering 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 anIETF recommendedIETF-recommended method for MP-DCCP.</t> <t indent="0" pn="section-3.11.2-4"> </t></t> </section> </section> </section> <sectionanchor="security" numbered="true" removeInRFC="false" toc="include" pn="section-4"> <name slugifiedName="name-security-considerations">Securityanchor="security"> <name>Security Considerations</name><t indent="0" pn="section-4-1">Similar<t>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-replayprotection)protection), the use of IPsec, DTLS over DCCP <xreftarget="RFC5238" format="default" sectionFormat="of" derivedContent="RFC5238"/>target="RFC5238"/>, or other end-to-end security is recommended; the Secure Real-time Transport Protocol (SRTP) <xreftarget="RFC3711" format="default" sectionFormat="of" derivedContent="RFC3711"/>target="RFC3711"/> is one candidate protocol for authentication.TogetherIntegrity would be provided if using SRTP together withEncryptionthe encryption ofHeader Extensionsheader extensions described inSRTP, as provided by<xreftarget="RFC6904" format="default" sectionFormat="of" derivedContent="RFC6904"/>, also integrity would be provided.</t> <t indent="0" pn="section-4-2">DCCPtarget="RFC6904"/>.</t> <t>DCCP <xreftarget="RFC4340" format="default" sectionFormat="of" derivedContent="RFC4340"/>target="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 beintroduced compared to regular DCCP.introduced. The security objectives for MP-DCCP are:</t><ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4-3"> <li pn="section-4-3.1"> <t indent="0" pn="section-4-3.1.1">Provide<ul> <li> <t>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<li> <t>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<li> <t>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<li> <t>Allow a party to limit the number of subflows that it allows.</t> </li> </ul><t indent="0" pn="section-4-4">To<!-- [rfced] Should "Section 4" be "Section 3.6" where the fallback scenario is discussed? Note that this sentence occurs in Section 4. Current: Depending on the security requirements, different Key Types can be negotiated in the handshake procedure or must follow the fallback scenario described in Section 4. Perhaps: Depending on the security requirements, different Key Types can be negotiated in the handshake procedure or must follow the fallback scenario described in Section 3.6. --> <t>To achieve these goals, MP-DCCP includes a hash-based handshake algorithm documented in Sections <xref target="MP_KEY"format="default" sectionFormat="of" derivedContent="Section 3.2.4"/>,format="counter"/>, <xref target="MP_HMAC"format="default" sectionFormat="of" derivedContent="Section 3.2.6"/>format="counter"/>, and <xref target="handshaking"format="default" sectionFormat="of" derivedContent="Section 3.3"/>.format="counter"/>. 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 <xreftarget="security" format="default" sectionFormat="of" derivedContent="Section 4"/>.target="security"/>. If there are security requirements that go beyond the capabilities of Key Type 0, then it isRECOMMENDED<bcp14>RECOMMENDED</bcp14> that Key Type 0isnot 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 creatingHash-based Message Authentication Codes (HMACs)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 <xreftarget="RFC4086" format="default" sectionFormat="of" derivedContent="RFC4086"/>.target="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<t>As discussed in <xreftarget="MP_ADDADDR" format="default" sectionFormat="of" derivedContent="Section 3.2.8"/>,target="MP_ADDADDR"/>, a host may advertise its private addresses, but these might point to different hosts in the receiver's network. The MP_JOIN handshake (<xreftarget="MP_JOIN" format="default" sectionFormat="of" derivedContent="Section 3.2.2"/>)target="MP_JOIN"/>) 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<t>As described in <xreftarget="mps" format="default" sectionFormat="of" derivedContent="Section 3.9"/>, a Maximum Packet Size (MPS)target="mps"/>, 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 minimumMPS,MPS and then stop using these paths.</t> </section> <sectionanchor="middlebox" numbered="true" removeInRFC="false" toc="include" pn="section-5"> <name slugifiedName="name-interactions-with-middlebox">Interactionsanchor="middlebox"> <name>Interactions with Middleboxes</name><t indent="0" pn="section-5-1">Issues<!-- [rfced] We note that RFC 4043 does not contain Section 16. Please confirm which section should be referenced. Current: DCCP already provides means to mitigate the potential impact of middleboxes, in comparison to TCP (see Section 16 of [RFC4043]). --> <t>Issues from interaction with on-path middleboxes such as NATs, firewalls, proxies,intrusion detection systems (IDSs),IDSs, and others have to be considered for all extensions to standardprotocols since otherwiseprotocols; otherwise, unexpected reactions of middleboxes may hinder its deployment. DCCP already provides means to mitigate the potential impact of middleboxes,alsoin comparison to TCP (see <xref target="RFC4043"format="default"sectionFormat="of"derivedContent="RFC4043"/>, Section 16).section="16"/>). When both hosts are located behind a NAT or firewall entity, specific measures have to be applied such as the<xref target="RFC5596" format="default" sectionFormat="of" derivedContent="RFC5596"/> specifiedsimultaneous-open technique specified in <xref target="RFC5596"/> thatupdateupdates the (traditionally asymmetric) connection-establishment procedures for DCCP. Further standardized technologies addressing middleboxes operating as NATs are provided in <xreftarget="RFC5597" format="default" sectionFormat="of" derivedContent="RFC5597"/>.</t> <t indent="0" pn="section-5-2"><xref target="RFC6773" format="default" sectionFormat="of" derivedContent="RFC6773"/>target="RFC5597"/>.</t> <t><xref target="RFC6773"/> specifies UDPEncapsulationencapsulation for NATTraversaltraversal of DCCP sessions, similar to other UDP encapsulations such asfor SCTPthe Stream Control Transmission Protocol (SCTP) <xreftarget="RFC6951" format="default" sectionFormat="of" derivedContent="RFC6951"/>.target="RFC6951"/>. Future specifications by the IETF could specify other methods for DCCP encapsulation.</t><t indent="0" pn="section-5-3">The<t>The security impact ofMP-DCCP awareMP-DCCP-aware middleboxes is discussed in <xreftarget="security" format="default" sectionFormat="of" derivedContent="Section 4"/>.</t>target="security"/>.</t> </section> <sectionanchor="implementation" numbered="true" removeInRFC="false" toc="include" pn="section-6"> <name slugifiedName="name-implementation">Implementation</name> <t indent="0" pn="section-6-1">Theanchor="implementation"> <name>Implementation</name> <t>The approach described above has been implemented in open source across differenttestbedstestbeds, and a new scheduling algorithm has been extensively tested. Also, demonstrations of a laboratory setup have been executed andhave been published atpublished; see <xreftarget="multipath-dccp.org" format="default" sectionFormat="of" derivedContent="multipath-dccp.org"/>.</t> </section> <section anchor="acknowledgments" numbered="true" removeInRFC="false" toc="include" pn="section-7"> <name slugifiedName="name-acknowledgments">Acknowledgments</name> <t indent="0" pn="section-7-1"><xref target="RFC8684" format="default" sectionFormat="of" derivedContent="RFC8684"/> defines Multipath TCP and provided important inputs for this specification.</t> <t indent="0" pn="section-7-2">The authors gratefully acknowledge significant input into this document from Dirk von Hugo, Nathalie Romo Moreno, Omar Nassef, Mohamed Boucadair, Simone Ferlin, Olivier Bonaventure, Gorry Fairhurst and Behcet Sarikaya.</t>target="MP-DCCP.Site"/>.</t> </section> <sectionanchor="iana-considerations" numbered="true" removeInRFC="false" toc="include" pn="section-8"> <name slugifiedName="name-iana-considerations">IANAanchor="iana-considerations"> <name>IANA Considerations</name><t indent="0" pn="section-8-1">This<t>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 policyofin <xref target="RFC8126"format="default"sectionFormat="of"derivedContent="RFC8126"/>, Section 4.7.section="4.7"/>. This document defines one new valuewhich is requested to bethat has been allocated in the IANADCCP"DCCP FeatureNumbersNumbers" registry and creates three new registriesto be allocatedthat have been added in theDCCP"Datagram Congestion Control Protocol (DCCP) Parameters" registry group.</t> <sectionanchor="new-multipath-capable-dccp-feature" numbered="true" removeInRFC="false" toc="include" pn="section-8.1"> <name slugifiedName="name-new-multipath-capable-dccp-">Newanchor="new-multipath-capable-dccp-feature"> <name>New Multipath Capable DCCPfeature</name> <t indent="0" pn="section-8.1-1">This document requestsFeature</name> <t>Per this document, IANAto assignhas assigned a new DCCP feature parameter for negotiating the support of multipath capability for DCCP sessions between hosts as described in <xreftarget="protocol" format="default" sectionFormat="of" derivedContent="Section 3"/>.target="protocol"/>. The following entry in <xreftarget="ref-add-feature-list" format="default" sectionFormat="of" derivedContent="Table 6"/> should betarget="ref-add-feature-list"/> has been added to theFeature Numbers"Feature Numbers" registry in the DCCP registry group according to <xref target="RFC4340"format="default"sectionFormat="of"derivedContent="RFC4340"/>, Section 19.4. undersection="19.4"/>.</t> <!--[rfced] We have included some clarifications about the"DCCP Protocol" heading.</t>IANA text below. In addition, please review all of the IANA-related updates carefully and let us know if any further updates are needed. a) FYI: We updated "auth." to "authentication" in Tables 3 and 8 as there is enough space to write it out. We will ask IANA to update the description in the "Multipath Options" registry accordingly. Original: Hash-based message auth. code for MP-DCCP Current: Hash-based message authentication code for MP-DCCP b) FYI: We have updated the headings in Tables 6 and 7 to match the headings listed in the "Feature Numbers" and "MP-DCCP Versions" registries, respectively <https://www.iana.org/assignments/dccp-parameters/>. --> <tableanchor="ref-add-feature-list" align="center" pn="table-6"> <name slugifiedName="name-addition-to-dccp-feature-nu">Additionanchor="ref-add-feature-list"> <name>Addition to DCCP Feature Numbersregistry</name>Registry</name> <thead> <tr><th align="center" colspan="1" rowspan="1">Value</th> <th align="center" colspan="1" rowspan="1">Feature Name</th> <th align="center" colspan="1" rowspan="1">Specification</th><th>Number</th> <th>Description/Meaning</th> <th>Reference</th> </tr> </thead> <tbody> <tr><td align="center" colspan="1" rowspan="1">10 suggested</td> <td align="center" colspan="1" rowspan="1">Multipath<td>10</td> <td>Multipath Capable</td><td align="center" colspan="1" rowspan="1">[ThisDocument]</td><td>RFC 9897</td> </tr> </tbody> </table><ul empty="true" bare="false" indent="3" spacing="normal" pn="section-8.1-3"> <li pn="section-8.1-3.1"> <t indent="0" pn="section-8.1-3.1.1">Note to RFC Editor: Please replace [ThisDocument] with a reference to the final RFC</t> </li> </ul></section> <sectionanchor="new-mp-dccp-version-registry" numbered="true" removeInRFC="false" toc="include" pn="section-8.2"> <name slugifiedName="name-new-mp-dccp-version-registr">Newanchor="new-mp-dccp-version-registry"> <name>New MP-DCCPversion registry</name> <t indent="0" pn="section-8.2-1"><xref target="mp_capable" format="default" sectionFormat="of" derivedContent="Section 3.1"/>Versions Registry</name> <t><xref target="mp_capable"/> specifies the new 1-byte entry above that includes a 4-bit part to specify the version of the used MP-DCCP implementation.This document requestsIANAto createhas created a new'MP-DCCP Versions'"MP-DCCP Versions" registrywithinin the DCCP registry group to track the MP-DCCP version. The initial content of this registry is as follows:</t> <tableanchor="ref-add-version-list" align="center" pn="table-7"> <name slugifiedName="name-mp-dccp-versions-registry">MP-DCCPanchor="ref-add-version-list"> <name>MP-DCCP Versions Registry</name> <thead> <tr><th align="center" colspan="1" rowspan="1">Version</th> <th align="center" colspan="1" rowspan="1">Value</th> <th align="center" colspan="1" rowspan="1">Specification</th><th>Version</th> <th>Value</th> <th>Reference</th> </tr> </thead> <tbody> <tr><td align="center" colspan="1" rowspan="1">0</td> <td align="center" colspan="1" rowspan="1">0000 suggested</td> <td align="center" colspan="1" rowspan="1">[ThisDocument]</td><td>0</td> <td>0000</td> <td>RFC 9897</td> </tr> <tr><td align="center" colspan="1" rowspan="1">1-15</td> <td align="center" colspan="1" rowspan="1">unassigned</td> <td align="center" colspan="1" rowspan="1"> </td><td>1-15</td> <td>Unassigned</td> <td> </td> </tr> </tbody> </table><ul empty="true" bare="false" indent="3" spacing="normal" pn="section-8.2-3"> <li pn="section-8.2-3.1"> <t indent="0" pn="section-8.2-3.1.1">Note to RFC Editor: Please replace [ThisDocument] with a reference to the final RFC</t> </li> </ul> <t indent="0" pn="section-8.2-4">Future<t>Future MP-DCCP versions 1 to 15arewill be assigned from this registry using the RFC Required policy(Section 4.7 of <xref(<xref target="RFC8126"format="default"sectionFormat="of"derivedContent="RFC8126"/>).</t>section="4.7"/>).</t> </section> <sectionanchor="new-multipath-option-and-registry" numbered="true" removeInRFC="false" toc="include" pn="section-8.3"> <name slugifiedName="name-new-multipath-option-and-re">Newanchor="new-multipath-option-and-registry"> <name>New MultipathoptionOption Type andregistry</name> <t indent="0" pn="section-8.3-1">This document requests IANA to assignRegistry</name> <t>IANA has assigned value 46 in the DCCP "Option Types"registry to "Multipath Options",registry, as described in <xreftarget="MP_OPT" format="default" sectionFormat="of" derivedContent="Section 3.2"/>.</t> <t indent="0" pn="section-8.3-2">IANA is requested to createtarget="MP_OPT"/>.</t> <t>IANA has created a new'Multipath Options'"Multipath Options" registry within the DCCP registry group. The following entries in <xreftarget="ref-add-proto-opt-list" format="default" sectionFormat="of" derivedContent="Table 8"/> should betarget="ref-add-proto-opt-list"/> have been added to the new'Multipath Options'"Multipath Options" registry. The registryin <xref target="ref-add-proto-opt-list" format="default" sectionFormat="of" derivedContent="Table 8"/>has an upper boundary of 255 in the numeric value field.</t> <tableanchor="ref-add-proto-opt-list" align="center" pn="table-8"> <name slugifiedName="name-multipath-options-registry">Multipathanchor="ref-add-proto-opt-list"> <name>Multipath Optionsregistry</name>Registry</name> <thead> <tr><th align="center" colspan="1" rowspan="1">Multipath<th>Multipath Option</th><th align="center" colspan="1" rowspan="1">Name</th> <th align="center" colspan="1" rowspan="1">Description</th> <th align="center" colspan="1" rowspan="1">Reference</th><th>Name</th> <th>Description</th> <th>Reference</th> </tr> </thead> <tbody> <tr><td align="center" colspan="1" rowspan="1">MP_OPT=0</td> <td align="center" colspan="1" rowspan="1">MP_CONFIRM</td> <td align="center" colspan="1" rowspan="1">Confirm<td>MP_OPT=0</td> <td>MP_CONFIRM</td> <td>Confirm reception/processing of an MP_OPT option</td><td align="center" colspan="1" rowspan="1"><td> <xreftarget="MP_CONFIRM" format="default" sectionFormat="of" derivedContent="Section 3.2.1"/></td>target="MP_CONFIRM"/></td> </tr> <tr><td align="center" colspan="1" rowspan="1">MP_OPT=1</td> <td align="center" colspan="1" rowspan="1">MP_JOIN</td> <td align="center" colspan="1" rowspan="1">Join<td>MP_OPT=1</td> <td>MP_JOIN</td> <td>Join subflow to an existing MP-DCCP connection</td><td align="center" colspan="1" rowspan="1"><td> <xreftarget="MP_JOIN" format="default" sectionFormat="of" derivedContent="Section 3.2.2"/></td>target="MP_JOIN"/></td> </tr> <tr><td align="center" colspan="1" rowspan="1">MP_OPT=2</td> <td align="center" colspan="1" rowspan="1">MP_FAST_CLOSE</td> <td align="center" colspan="1" rowspan="1">Close<td>MP_OPT=2</td> <td>MP_FAST_CLOSE</td> <td>Close an MP-DCCP connection unconditionally</td><td align="center" colspan="1" rowspan="1"><td> <xreftarget="MP_FAST_CLOSE" format="default" sectionFormat="of" derivedContent="Section 3.2.3"/></td>target="MP_FAST_CLOSE"/></td> </tr> <tr><td align="center" colspan="1" rowspan="1">MP_OPT=3</td> <td align="center" colspan="1" rowspan="1">MP_KEY</td> <td align="center" colspan="1" rowspan="1">Exchange<td>MP_OPT=3</td> <td>MP_KEY</td> <td>Exchange key material for MP_HMAC</td><td align="center" colspan="1" rowspan="1"><td> <xreftarget="MP_KEY" format="default" sectionFormat="of" derivedContent="Section 3.2.4"/></td>target="MP_KEY"/></td> </tr> <tr><td align="center" colspan="1" rowspan="1">MP_OPT=4</td> <td align="center" colspan="1" rowspan="1">MP_SEQ</td> <td align="center" colspan="1" rowspan="1">Multipath<td>MP_OPT=4</td> <td>MP_SEQ</td> <td>Multipath sequence number</td><td align="center" colspan="1" rowspan="1"><td> <xreftarget="MP_SEQ" format="default" sectionFormat="of" derivedContent="Section 3.2.5"/></td>target="MP_SEQ"/></td> </tr> <tr><td align="center" colspan="1" rowspan="1">MP_OPT=5</td> <td align="center" colspan="1" rowspan="1">MP_HMAC</td> <td align="center" colspan="1" rowspan="1">Hash-based<td>MP_OPT=5</td> <td>MP_HMAC</td> <td>Hash-based messageauth.authentication code for MP-DCCP</td><td align="center" colspan="1" rowspan="1"><td> <xreftarget="MP_HMAC" format="default" sectionFormat="of" derivedContent="Section 3.2.6"/></td>target="MP_HMAC"/></td> </tr> <tr><td align="center" colspan="1" rowspan="1">MP_OPT=6</td> <td align="center" colspan="1" rowspan="1">MP_RTT</td> <td align="center" colspan="1" rowspan="1">Transmit<td>MP_OPT=6</td> <td>MP_RTT</td> <td>Transmit RTT values and calculation parameters</td><td align="center" colspan="1" rowspan="1"><td> <xreftarget="MP_RTT" format="default" sectionFormat="of" derivedContent="Section 3.2.7"/></td>target="MP_RTT"/></td> </tr> <tr><td align="center" colspan="1" rowspan="1">MP_OPT=7</td> <td align="center" colspan="1" rowspan="1">MP_ADDADDR</td> <td align="center" colspan="1" rowspan="1">Advertise<td>MP_OPT=7</td> <td>MP_ADDADDR</td> <td>Advertise additional address(es)/port(s)</td><td align="center" colspan="1" rowspan="1"><td> <xreftarget="MP_ADDADDR" format="default" sectionFormat="of" derivedContent="Section 3.2.8"/></td>target="MP_ADDADDR"/></td> </tr> <tr><td align="center" colspan="1" rowspan="1">MP_OPT=8</td> <td align="center" colspan="1" rowspan="1">MP_REMOVEADDR</td> <td align="center" colspan="1" rowspan="1">Remove<td>MP_OPT=8</td> <td>MP_REMOVEADDR</td> <td>Remove address(es)/ port(s)</td><td align="center" colspan="1" rowspan="1"><td> <xreftarget="MP_REMOVEADDR" format="default" sectionFormat="of" derivedContent="Section 3.2.9"/></td>target="MP_REMOVEADDR"/></td> </tr> <tr><td align="center" colspan="1" rowspan="1">MP_OPT=9</td> <td align="center" colspan="1" rowspan="1">MP_PRIO</td> <td align="center" colspan="1" rowspan="1">Change<td>MP_OPT=9</td> <td>MP_PRIO</td> <td>Change subflow priority</td><td align="center" colspan="1" rowspan="1"><td> <xreftarget="MP_PRIO" format="default" sectionFormat="of" derivedContent="Section 3.2.10"/></td>target="MP_PRIO"/></td> </tr> <tr><td align="center" colspan="1" rowspan="1">MP_OPT=10</td> <td align="center" colspan="1" rowspan="1">MP_CLOSE</td> <td align="center" colspan="1" rowspan="1">Close<td>MP_OPT=10</td> <td>MP_CLOSE</td> <td>Close an MP-DCCP connection</td><td align="center" colspan="1" rowspan="1"><td> <xreftarget="MP_CLOSE" format="default" sectionFormat="of" derivedContent="Section 3.2.11"/></td>target="MP_CLOSE"/></td> </tr> <tr><td align="center" colspan="1" rowspan="1">MP_OPT=11</td> <td align="center" colspan="1" rowspan="1">MP_EXP</td> <td align="center" colspan="1" rowspan="1">Experimental<td>MP_OPT=11</td> <td>MP_EXP</td> <td>Experimental option for private use</td><td align="center" colspan="1" rowspan="1"><td> <xreftarget="MP_EXP" format="default" sectionFormat="of" derivedContent="Section 3.2.12"/></td>target="MP_EXP"/></td> </tr> <tr><td align="center" colspan="1" rowspan="1">MP_OPT>11</td> <td align="center" colspan="1" rowspan="1">Unassigned</td> <td align="center" colspan="1" rowspan="1">Reserved<td>MP_OPT>11</td> <td>Unassigned</td> <td>Reserved for future Multipath options</td><td align="center" colspan="1" rowspan="1"> </td><td> </td> </tr> </tbody> </table><t indent="0" pn="section-8.3-4">Future<t>Future Multipath options with MP_OPT>11arewill be assigned from this registry using the RFC Required policy(Section 4.7 of <xref(<xref target="RFC8126"format="default"sectionFormat="of"derivedContent="RFC8126"/>).</t>section="4.7"/>).</t> </section> <sectionanchor="new-dccp-reset-code" numbered="true" removeInRFC="false" toc="include" pn="section-8.4"> <name slugifiedName="name-new-dccp-reset-code">New DCCP Resetanchor="new-dccp-reset-code"> <name>New DCCP-Reset Code</name><t indent="0" pn="section-8.4-1">IANA is requested to assign<t>IANA has assigned a new DCCP-ResetCodeCode, value13 suggested13, in theDCCP-Reset Codes Registry,"Reset Codes" registry, with theshortdescription "Abrupt MP termination". Use of this reset code is defined insection<xreftarget="MP_FAST_CLOSE" format="default" sectionFormat="of" derivedContent="Section 3.2.3"/>.</t>target="MP_FAST_CLOSE"/>.</t> </section> <sectionanchor="new-multipath-key-type-registry" numbered="true" removeInRFC="false" toc="include" pn="section-8.5"> <name slugifiedName="name-new-multipath-key-type-regi">Newanchor="new-multipath-key-type-registry"> <name>New Multipath Key Typeregistry</name> <t indent="0" pn="section-8.5-1">IANA is requested to assignRegistry</name> <t>IANA has created a new "Multipath Key Type" registry for this version of the MP-DCCP protocola new 'Multipath Key Type' registry containingthat 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 <xreftarget="MP_KEY" format="default" sectionFormat="of" derivedContent="Section 3.2.4"/> according totarget="MP_KEY"/>. See the initial entries in <xreftarget="ref-mp_key-sub-opt-list" format="default" sectionFormat="of" derivedContent="Table 9"/>target="ref-mp_key-sub-opt-list"/> below. Values in the range3-2541-254 (decimal) inclusive remain unassigned in thisherespecified version 0 of the protocol andarewill be assigned via the RFC Required policy <xreftarget="RFC8126" format="default" sectionFormat="of" derivedContent="RFC8126"/>target="RFC8126"/> in potential future versions of the MP-DCCP protocol.</t> <tableanchor="ref-mp_key-sub-opt-list" align="center" pn="table-9"> <name slugifiedName="name-multipath-key-type-registry">Multipathanchor="ref-mp_key-sub-opt-list"> <name>Multipath Key TyperegistryRegistry with the MP_KEY Key Types forkey data exchangeKey Data Exchange ondifferent paths</name>Different Paths</name> <thead> <tr><th align="center" colspan="1" rowspan="1">Type</th> <th align="center" colspan="1" rowspan="1">Name</th> <th align="center" colspan="1" rowspan="1">Meaning</th> <th align="left" colspan="1" rowspan="1">Reference</th><th>Type</th> <th>Name</th> <th>Meaning</th> <th>Reference</th> </tr> </thead> <tbody> <tr><td align="center" colspan="1" rowspan="1">0</td> <td align="center" colspan="1" rowspan="1">Plain<td>0</td> <td>Plain Text</td><td align="center" colspan="1" rowspan="1">Plain<td>Plain text key</td><td align="left" colspan="1" rowspan="1"><td> <xreftarget="MP_KEY" format="default" sectionFormat="of" derivedContent="Section 3.2.4"/></td>target="MP_KEY"/></td> </tr> <tr><td align="center" colspan="1" rowspan="1">1-254</td> <td align="center" colspan="1" rowspan="1">Unassigned</td> <td align="center" colspan="1" rowspan="1">Reserved<td>1-254</td> <td>Unassigned</td> <td>Reserved for future use</td><td align="left" colspan="1" rowspan="1"><td> <xreftarget="MP_KEY" format="default" sectionFormat="of" derivedContent="Section 3.2.4"/></td>target="MP_KEY"/></td> </tr> <tr><td align="center" colspan="1" rowspan="1">255</td> <td align="center" colspan="1" rowspan="1">Experimental</td> <td align="center" colspan="1" rowspan="1">For<td>255</td> <td>Experimental</td> <td>For private use only</td><td align="left" colspan="1" rowspan="1"><td> <xreftarget="MP_KEY" format="default" sectionFormat="of" derivedContent="Section 3.2.4"/></td>target="MP_KEY"/></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"/> <referencesanchor="sec-combined-references" pn="section-9"> <name slugifiedName="name-references">References</name>anchor="sec-combined-references"> <name>References</name> <referencesanchor="sec-normative-references" pn="section-9.1"> <name slugifiedName="name-normative-references">Normativeanchor="sec-normative-references"> <name>Normative References</name> <referenceanchor="DCCP.Parameter" target="https://www.iana.org/assignments/dccp-parameters/dccp-parameters.xhtml" quoteTitle="true" derivedAnchor="DCCP.Parameter">anchor="DCCP-PARAMETERS" target="https://www.iana.org/assignments/dccp-parameters"> <front><title>IANA Datagram<title>Datagram Congestion Control Protocol (DCCP) Parameters</title> <author><organization showOnFrontPage="true"/><organization>IANA</organization> </author><date>n.d.</date> </front> </reference> <reference anchor="RFC2119" quoteTitle="true" target="https://www.rfc-editor.org/rfc/rfc2119" 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" quoteTitle="true" target="https://www.rfc-editor.org/rfc/rfc4086" 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" quoteTitle="true" target="https://www.rfc-editor.org/rfc/rfc4340" 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" quoteTitle="true" target="https://www.rfc-editor.org/rfc/rfc6234" 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" quoteTitle="true" target="https://www.rfc-editor.org/rfc/rfc8126" 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" quoteTitle="true" target="https://www.rfc-editor.org/rfc/rfc8174" 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> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4086.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4340.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6234.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> </references> <referencesanchor="sec-informative-references" pn="section-9.2"> <name slugifiedName="name-informative-references">Informativeanchor="sec-informative-references"> <name>Informative References</name><reference anchor="I-D.amend-iccrg-multipath-reordering" quoteTitle="true" target="https://datatracker.ietf.org/doc/html/draft-amend-iccrg-multipath-reordering-03" derivedAnchor="I-D.amend-iccrg-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="I-D.amend-tsvwg-dccp-udp-header-conversion" quoteTitle="true" target="https://datatracker.ietf.org/doc/html/draft-amend-tsvwg-dccp-udp-header-conversion-01" derivedAnchor="I-D.amend-tsvwg-dccp-udp-header-conversion"> <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<!-- [I-D.amend-iccrg-multipath-reordering] draft-amend-iccrg-multipath-reordering-03 IESG State: Expired asa typical exampleofa 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 long10/13/25 --> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.amend-iccrg-multipath-reordering.xml"/> <!-- [I-D.amend-tsvwg-dccp-udp-header-conversion] draft-amend-tsvwg-dccp-udp-header-conversion-01 IESG State: Expired asthe protocol penetrationofDCCP 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>10/13/25 --> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.amend-tsvwg-dccp-udp-header-conversion.xml"/> <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">target="https://datatracker.ietf.org/meeting/105/materials/slides-105-tsvwg-sessa-62-dccp-extensions-for-multipath-operation-00"> <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"/><organization/> </author><date>n.d.</date><date month="July" year="2019"/> </front><seriesInfo name="IETF105" value=""/><refcontent>IETF 105 Proceedings</refcontent> </reference> <reference anchor="MP-DCCP.Paper"quoteTitle="true" target="https://doi.org/10.1109/LCN44214.2019.8990746" derivedAnchor="MP-DCCP.Paper">target="https://doi.org/10.1109/LCN44214.2019.8990746"> <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"/><organization/> </author> <author initials="E." surname="Bogenfeld" fullname="Eckard Bogenfeld"><organization showOnFrontPage="true"/><organization/> </author> <author initials="M." surname="Cvjetkovic" fullname="Milan Cvjetkovic"><organization showOnFrontPage="true"/><organization/> </author> <author initials="V." surname="Rakocevic" fullname="Veselin Rakocevic"><organization showOnFrontPage="true"/><organization/> </author> <author initials="M." surname="Pieska" fullname="Marcus Pieska"><organization showOnFrontPage="true"/><organization/> </author> <author initials="A." surname="Kassler" fullname="Andreas Kassler"><organization showOnFrontPage="true"/><organization/> </author> <author initials="A." surname="Brunstrom" fullname="Anna Brunstrom"><organization showOnFrontPage="true"/><organization/> </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> <referenceanchor="multipath-dccp.org" target="https://multipath-dccp.org/" quoteTitle="true" derivedAnchor="multipath-dccp.org">anchor="MP-DCCP.Site" target="https://multipath-dccp.org/"> <front> <title>Multipath extension for DCCP</title> <author><organization showOnFrontPage="true"/><organization/> </author><date>n.d.</date></front> </reference> <!-- [rfced] We found the URL <https://dl.acm.org/doi/10.1145/2413176.2413178> from the ACM Digital Library. Would you like us to update this reference with this URL as shown below? Current: [OLIA] Khalili, R., Gast, N., Popovic, M., Upadhyay, U., and J. Le Boudec, "MPTCP is not pareto-optimal: performance issues and a possible solution", CoNEXT '12: Proceedings of the 8th international conference on Emerging networking experiments and technologies, pp. 1-12, December 2012. Perhaps: [OLIA] Khalili, R., Gast, N., Popovic, M., Upadhyay, U., and J. Le Boudec, "MPTCP is not pareto-optimal: performance issues and a possible solution", CoNEXT '12: Proceedings of the 8th international conference on Emerging networking experiments and technologies, pp. 1-12, December 2012, <https://dl.acm.org/doi/10.1145/2413176.2413178>. --> <referenceanchor="OLIA" quoteTitle="true" derivedAnchor="OLIA">anchor="OLIA"> <front> <title>MPTCP is not pareto-optimal: performance issues and a possible solution</title> <author initials="R." surname="Khalili"><organization showOnFrontPage="true"/><organization/> </author> <author initials="N." surname="Gast"><organization showOnFrontPage="true"/><organization/> </author> <author initials="M." surname="Popovic"><organization showOnFrontPage="true"/><organization/> </author> <author initials="U." surname="Upadhyay"><organization showOnFrontPage="true"/><organization/> </author> <author initials="J." surname="Le Boudec"><organization showOnFrontPage="true"/><organization/> </author> <date month="December" year="2012"/> </front><seriesInfo name="Proceedings<refcontent>CoNEXT '12: Proceedings of the 8th international conference on Emerging networking experiments and technologies,ACM" value=""/> </reference> <reference anchor="RFC2104" quoteTitle="true" target="https://www.rfc-editor.org/rfc/rfc2104" 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" quoteTitle="true" target="https://www.rfc-editor.org/rfc/rfc3711" 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"/>pp. 1-12</refcontent> </reference><reference anchor="RFC4043" quoteTitle="true" target="https://www.rfc-editor.org/rfc/rfc4043" derivedAnchor="RFC4043"> <front> <title>Internet X.509 Public Key Infrastructure Permanent Identifier</title> <author fullname="D. Pinkas" initials="D." surname="Pinkas"/> <author fullname="T. Gindin" initials="T." surname="Gindin"/> <date month="May" year="2005"/> <abstract> <t indent="0">This document defines a new form of name, called permanent identifier, that may be included in the subjectAltName extension of a public key certificate issued to an entity.</t> <t indent="0">The permanent identifier is an optional feature that may be used by a CA to indicate that two or more certificates relate<!-- Note tothe same entity, even if they contain different subject name (DNs) or different names in the subjectAltName extension, or if the name or the affiliation of that entity stored in the subject or another name form in the subjectAltName extension has changed.</t> <t indent="0">The subject name, carried in the subject field, is only unique for each subject entity certified by the one CA as defined by the issuer name field. However, the new name form can carry a name that is unique for each subject entity certified by a CA. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="4043"/> <seriesInfo name="DOI" value="10.17487/RFC4043"/> </reference> <reference anchor="RFC5238" quoteTitle="true" target="https://www.rfc-editor.org/rfc/rfc5238" 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 usePE: Updated version ofDatagram 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>[OLIA] <referenceanchor="RFC5280" quoteTitle="true" target="https://www.rfc-editor.org/rfc/rfc5280" derivedAnchor="RFC5280">anchor="OLIA" target="https://dl.acm.org/doi/10.1145/2413176.2413178"> <front><title>Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile</title> <author fullname="D. Cooper" initials="D." surname="Cooper"/> <author fullname="S. Santesson" initials="S." surname="Santesson"/> <author fullname="S. Farrell" initials="S." surname="Farrell"/> <author fullname="S. Boeyen" initials="S." surname="Boeyen"/> <author fullname="R. Housley" initials="R." surname="Housley"/> <author fullname="W. Polk" initials="W." surname="Polk"/> <date month="May" year="2008"/> <abstract> <t indent="0">This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation<title>MPTCP isdescribed. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="5280"/> <seriesInfo name="DOI" value="10.17487/RFC5280"/> </reference> <reference anchor="RFC5596" quoteTitle="true" target="https://www.rfc-editor.org/rfc/rfc5596" 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-orientednot pareto-optimal: performance issues anddatagram-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 inanear- 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" quoteTitle="true" target="https://www.rfc-editor.org/rfc/rfc5597" derivedAnchor="RFC5597"> <front> <title>Network Address Translation (NAT) Behavioral Requirements for the Datagram Congestion Control Protocol</title>possible solution</title> <authorfullname="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" quoteTitle="true" target="https://www.rfc-editor.org/rfc/rfc6356" derivedAnchor="RFC6356"> <front> <title>Coupled Congestion Control for Multipath Transport Protocols</title>surname="Khalili"> <organization/> </author> <authorfullname="C. Raiciu" initials="C." surname="Raiciu"/>initials="N." surname="Gast"> <organization/> </author> <authorfullname="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" quoteTitle="true" target="https://www.rfc-editor.org/rfc/rfc6773" 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"/>surname="Popovic"> <organization/> </author> <authorfullname="G. Fairhurst" initials="G." surname="Fairhurst"/>initials="U." surname="Upadhyay"> <organization/> </author> <authorfullname="C. Perkins" initials="C." surname="Perkins"/>initials="J." surname="Le Boudec"> <organization/> </author> <datemonth="November"month="December" 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" quoteTitle="true" target="https://www.rfc-editor.org/rfc/rfc6904" derivedAnchor="RFC6904"> <front> <title>Encryption<refcontent>CoNEXT '12: Proceedings ofHeader Extensions intheSecure 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"/>8th international conference on Emerging networking experiments and technologies, pp. 1-12</refcontent> <seriesInfo name="DOI"value="10.17487/RFC6904"/>value="10.1145/2413176.2413178"/> </reference><reference anchor="RFC6951" quoteTitle="true" target="https://www.rfc-editor.org/rfc/rfc6951" 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--> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2104.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3711.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4043.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5238.xml"/> <!-- We note thatthis 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[RFC5280] isbeing 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 andnottunneling (egress or ingress) endpoints.</t> </abstract> </front> <seriesInfo name="RFC" value="6951"/> <seriesInfo name="DOI" value="10.17487/RFC6951"/> </reference> <reference anchor="RFC7323" quoteTitle="true" target="https://www.rfc-editor.org/rfc/rfc7323" 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" quoteTitle="true" target="https://www.rfc-editor.org/rfc/rfc8041" 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)cited inreal 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" quoteTitle="true" target="https://www.rfc-editor.org/rfc/rfc8684" 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 withinthenetwork and thus improve user experience through higher throughput and improved resilience to network failure.</t> <t indent="0">Multipath TCP provides the abilitytext. Would you like tosimultaneously use multiple paths between peers. This document presentsadd aset of extensions to traditional TCP to support multipath operation. The protocol offers the same type of servicecitation toapplications 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" quoteTitle="true" target="https://www.rfc-editor.org/rfc/rfc9293" 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 intheInternet 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 withtext or remove theprotocol specificationreference entry fromRFC 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 intheSYN-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>Informative References? --> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5280.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5596.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5597.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6356.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6773.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6904.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6951.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7323.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8041.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8684.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9293.xml"/> <reference anchor="TS23.501"target="https://www.3gpp.org/ftp//Specs/archive/23_series/23.501/23501-g70.zip" quoteTitle="true" derivedAnchor="TS23.501">target="https://www.3gpp.org/ftp//Specs/archive/23_series/23.501/23501-g70.zip"> <front> <title>System architecture for the 5G System; Stage 2; Release 16</title> <author><organization showOnFrontPage="true">3GPP</organization><organization>3GPP</organization> </author> <date year="2020" month="December"/> </front> <refcontent>Version 16.7.0, Release 16</refcontent> </reference> </references> </references> <sectionanchor="diff_mptcp" numbered="true" removeInRFC="false" toc="include" pn="section-appendix.a"> <name slugifiedName="name-differences-from-multipath-">Differencesanchor="diff_mptcp"> <name>Differences from Multipath TCP</name><t indent="0" pn="section-appendix.a-1">This<t>This appendix isInformative.</t> <t indent="0" pn="section-appendix.a-2">Multipathinformative.</t> <t>Multipath DCCP is similar to Multipath TCP <xreftarget="RFC8684" format="default" sectionFormat="of" derivedContent="RFC8684"/>,target="RFC8684"/> in that it extends the related basic DCCP transport protocol <xreftarget="RFC4340" format="default" sectionFormat="of" derivedContent="RFC4340"/>target="RFC4340"/> with multipath capabilities in the same way as Multipath TCP extends TCP <xreftarget="RFC9293" format="default" sectionFormat="of" derivedContent="RFC9293"/>.target="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"/><t><xref target="table_tcp_dccp_comp"/> 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, whichisfor TCP is an exact copy of the generatedbyte-stream.byte stream. DCCP behaves differently and does not guaranteeto deliverthe 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> <tableanchor="table_tcp_dccp_comp" align="center" pn="table-10"> <name slugifiedName="name-tcp-and-dccp-protocol-compa">TCPanchor="table_tcp_dccp_comp"> <name>TCP and DCCPprotocol comparison</name>Protocol Comparison</name> <thead> <tr><th align="center" colspan="1" rowspan="1">Feature</th> <th align="center" colspan="1" rowspan="1">TCP</th> <th align="center" colspan="1" rowspan="1">DCCP</th><th>Feature</th> <th>TCP</th> <th>DCCP</th> </tr> </thead> <tbody> <tr><td align="center" colspan="1" rowspan="1">Full-Duplex</td> <td align="center" colspan="1" rowspan="1">yes</td> <td align="center" colspan="1" rowspan="1">yes</td><td>Full-Duplex</td> <td>yes</td> <td>yes</td> </tr> <tr><td align="center" colspan="1" rowspan="1">Connection-Oriented</td> <td align="center" colspan="1" rowspan="1">yes</td> <td align="center" colspan="1" rowspan="1">yes</td><td>Connection-Oriented</td> <td>yes</td> <td>yes</td> </tr> <tr><td align="center" colspan="1" rowspan="1">Header<td>Header option space</td><td align="center" colspan="1" rowspan="1">40<td>40 bytes</td><td align="center" colspan="1" rowspan="1"><<td>< 1008 bytes or PMTU</td> </tr> <tr><td align="center" colspan="1" rowspan="1">Data<td>Data transfer</td><td align="center" colspan="1" rowspan="1">reliable</td> <td align="center" colspan="1" rowspan="1">unreliable</td><td>reliable</td> <td>unreliable</td> </tr> <tr><td align="center" colspan="1" rowspan="1">Packet-loss<td>Packet-loss handling</td><td align="center" colspan="1" rowspan="1">retransmission</td> <td align="center" colspan="1" rowspan="1">report<td>retransmission</td> <td>report only</td> </tr> <tr><td align="center" colspan="1" rowspan="1">Ordered<td>Ordered data delivery</td><td align="center" colspan="1" rowspan="1">yes</td> <td align="center" colspan="1" rowspan="1">no</td><td>yes</td> <td>no</td> </tr> <tr><td align="center" colspan="1" rowspan="1">Sequence<td>Sequence numbers</td><td align="center" colspan="1" rowspan="1">one<td>one per byte</td><td align="center" colspan="1" rowspan="1">one<td>one per PDU</td> </tr> <tr><td align="center" colspan="1" rowspan="1">Flow<td>Flow control</td><td align="center" colspan="1" rowspan="1">yes</td> <td align="center" colspan="1" rowspan="1">no</td><td>yes</td> <td>no</td> </tr> <tr><td align="center" colspan="1" rowspan="1">Congestion<td>Congestion control</td><td align="center" colspan="1" rowspan="1">yes</td> <td align="center" colspan="1" rowspan="1">yes</td><td>yes</td> <td>yes</td> </tr> <tr><td align="center" colspan="1" rowspan="1">ECN<td>ECN support</td><td align="center" colspan="1" rowspan="1">yes</td> <td align="center" colspan="1" rowspan="1">yes</td><td>yes</td> <td>yes</td> </tr> <tr><td align="center" colspan="1" rowspan="1">Selective<td>Selective ACK</td><td align="center" colspan="1" rowspan="1">yes</td> <td align="center" colspan="1" rowspan="1">depends<td>yes</td> <td>depends on congestion control</td> </tr> <tr><td align="center" colspan="1" rowspan="1">Fix<td>Fix message boundaries</td><td align="center" colspan="1" rowspan="1">no</td> <td align="center" colspan="1" rowspan="1">yes</td><td>no</td> <td>yes</td> </tr> <tr><td align="center" colspan="1" rowspan="1">Path<td>Path MTU discovery</td><td align="center" colspan="1" rowspan="1">yes</td> <td align="center" colspan="1" rowspan="1">yes</td><td>yes</td> <td>yes</td> </tr> <tr><td align="center" colspan="1" rowspan="1">Fragmentation</td> <td align="center" colspan="1" rowspan="1">yes</td> <td align="center" colspan="1" rowspan="1">no</td><td>Fragmentation</td> <td>yes</td> <td>no</td> </tr> <tr><td align="center" colspan="1" rowspan="1">SYN<td>SYN flood protection</td><td align="center" colspan="1" rowspan="1">yes</td> <td align="center" colspan="1" rowspan="1">no</td><td>yes</td> <td>no</td> </tr> <tr><td align="center" colspan="1" rowspan="1">Half-open<td>Half-open connections</td><td align="center" colspan="1" rowspan="1">yes</td> <td align="center" colspan="1" rowspan="1">no</td><td>yes</td> <td>no</td> </tr> </tbody> </table><t indent="0" pn="section-appendix.a-5">Consequently,<t>Consequently, the multipathfeatures,features shown in <xreftarget="table_mptcp_mpdccp_comp" format="default" sectionFormat="of" derivedContent="Table 11"/>,target="table_mptcp_mpdccp_comp"/> are the same, supporting volatile pathshavingthat have varyingcapacitycapacities and latency, sessionhandoverhandovers, and path aggregation capabilities. All ofthemthese features profit by the existence of congestion control.</t> <tableanchor="table_mptcp_mpdccp_comp" align="center" pn="table-11"> <name slugifiedName="name-mptcp-and-mp-dccp-protocol-">MPTCPanchor="table_mptcp_mpdccp_comp"> <name>MPTCP and MP-DCCPprotocol comparison</name>Protocol Comparison</name> <thead> <tr><th align="center" colspan="1" rowspan="1">Feature</th> <th align="center" colspan="1" rowspan="1">MPTCP</th> <th align="center" colspan="1" rowspan="1">MP-DCCP</th><th>Feature</th> <th>MPTCP</th> <th>MP-DCCP</th> </tr> </thead> <tbody> <tr><td align="center" colspan="1" rowspan="1">Volatile<td>Volatile paths</td><td align="center" colspan="1" rowspan="1">yes</td> <td align="center" colspan="1" rowspan="1">yes</td><td>yes</td> <td>yes</td> </tr> <tr><td align="center" colspan="1" rowspan="1">Session<td>Session handover</td><td align="center" colspan="1" rowspan="1">yes</td> <td align="center" colspan="1" rowspan="1">yes</td><td>yes</td> <td>yes</td> </tr> <tr><td align="center" colspan="1" rowspan="1">Path<td>Path aggregation</td><td align="center" colspan="1" rowspan="1">yes</td> <td align="center" colspan="1" rowspan="1">yes</td><td>yes</td> <td>yes</td> </tr> <tr><td align="center" colspan="1" rowspan="1">Data<td>Data reordering</td><td align="center" colspan="1" rowspan="1">yes</td> <td align="center" colspan="1" rowspan="1">optional</td><td>yes</td> <td>optional</td> </tr> <tr><td align="center" colspan="1" rowspan="1">Expandability</td> <td align="center" colspan="1" rowspan="1">limited<td>Expandability</td> <td>limited by TCP header</td><td align="center" colspan="1" rowspan="1">flexible</td><td>flexible</td> </tr> </tbody> </table><t indent="0" pn="section-appendix.a-7">Therefore,<t>Therefore, the sender logic is not much different between MP-DCCP and MPTCP.</t><t indent="0" pn="section-appendix.a-8">The<t>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 <xreftarget="MP_SEQ" format="default" sectionFormat="of" derivedContent="Section 3.2.5"/>)target="MP_SEQ"/>) facilitates adding optional mechanisms for data stream packet reordering at the receiver. Information from the MP_RTT multipath option (<xreftarget="MP_RTT" format="default" sectionFormat="of" derivedContent="Section 3.2.7"/>),target="MP_RTT"/>), DCCP pathsequencingsequencing, and the DCCP Timestamp Option provide further means for advanced reordering approaches, e.g., as proposed in <xreftarget="I-D.amend-iccrg-multipath-reordering" format="default" sectionFormat="of" derivedContent="I-D.amend-iccrg-multipath-reordering"/>. Suchtarget="I-D.amend-iccrg-multipath-reordering"/>. However, such mechanismsdo, however,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),andso 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<t>In contrast to TCP, the receiver processing for MPTCP adopted a rigid "just wait" approach, because TCP guarantees reliable in-order delivery.</t> </section> <sectionanchor="authors-addresses"anchor="acknowledgments" numbered="false"removeInRFC="false" toc="include" pn="section-appendix.b"> <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, 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>> <name>Acknowledgments</name> <t><xref target="RFC8684"/> defines Multipath TCP and provides important inputs for this specification.</t> <t>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> </back> <!--##markdown-source: H4sIAAAAAAAAA+y96XLbWJYw+B9PgXBGTEplkhYlr6rOnKZlu1JdXtSWsqor 6qvJgEhIQpokWABoWWX7i36NiZh5uX6SOfs9FwAlOdPV27RqsUQCdzn33LMv w+EwaYpmnu+nzw4OjtLnH5p8WRflsk7Pyip9tZ43xSprLtI3q7zKGvgivSzg T/5inqeT2azK6zqvk+z0tMrf77t3cMRkVk6X2QLGn1XZWTMs8uZs2NTvL8+H C31wOJtOV8Pd+8ksa+DB3Z3dB8Od+8PdJ8k0a/bTupklSbGq9tOmWtfN7s7O k53dJMmqPMOPsmW9KqsmuTzfT0/0r3QC36Z/LKt3xfI8/V1VrlfJu/zqsqxm ++nhssmrZd4Mn+GSknp9uihq3HRztYL5D5+fvEim5Qze3E/X9TCrp0WR1E22 nP2UzctlTgvJk2RV7Kd/bsrpIK1hyio/q+G3qwX+8hdY37q5KKv9JB0maVos a4DMKJ0s8uUM/maQvMqqd+vaPiwrmPBZvm7q6UWenuTz/F25gM8Vss9O4I8a Jsqb8NxQnhtO5vM8T5/AI9OiuYIHsmoBi541+Ek5g+ke3t998oD+Wi+bCh75 XV4tsuUVfJQvsmKuCxrRgv6x4YFHsxweqErEkXxWNGXltjQZpU+r9RIWRSvl bU2Wyyz6mDb2+6ya43rSH5fF+7yqYZFuO/Zh3tTnGcA63bWd6JthIw/G6ePH fifHl/ksX4aNZLCE0aku4R/fZetRncfr/n1W1/O8cqsGTM5q9/l/xLJpDaN3 vIbuuv8wSt9m78pp/r6Y2sr/kNf5vFhG39DaD2AdA7fwtDxLX5bLWbl0W3gN uHuRLVYN3O3jv67hWtkO7FlbMIzV5LP093A3ZnS0svD3vIRRpUsYjf8Rxxhl 09H6ndvA8Sj9p/JiWdOwvPzjJl9d5Ev3OS3+qcf2ySyDX7N5egQYausDdAXS VcPq0x9yICQG6cOjB+ne2+e3WXnNs48uRj/z/P942oym8ESyLOF2NAA7uMPp 2xcHu+PxE/n1/s7jh/rr3v0d+fXh7t59+fXxePeh/fqIPkVqOILlw56B/OAn aSqk93DyegL3tcnO4dv0oFye5zXRWvgV8Bd2XZVAZ+CXLRxlO7Vhah4mq84R ShdNs6r37927vLwcFRncAADkPUCl4nwJN7qp7xGhXdnL7b9HHy6axRyI7fLM 7/1w+GyUIUkQwk1vrWer4UWezfJqOC2XhGDlMn66mE4rT+arHMhvXiFdVYju KMD2Ho3HBtz7e/Lrg929x/brY4XzgwdPHoZfHyn09x7opw8fPdIRHj6xKR4+ eaBTPNrb1Qce79zXTx8/fKzPPtl9Qg+cHO/ujR7sjKPjOr4CpFmkWTW9AJya NusqJ27ZANV+8Dv5+reA19l5nu7+Nn0LhDSr83T8kEYxxkA/hOt7vzs6or+Z A34LLHBnON4djh99u/GA985XKzrgs2Z1797xKp/W92hJ7/N7u3s/1QDovL7H y4d/4P+H5492Rn8rVjBkzHtHtAi/xcDEc5UIaIvE0vtW1B3wHjz36mgoaL9q ofwkfYFYBwz5XZA0sukUZIn0eL0iHo6f/7isgLBkpyBqKNtGLn92VkyBNyNz b8kbXQgP5d+0y4blp5cb9736HNhdeZ4vz/J55/Xn03dZNet83zP7wfuf8+Zd yYQ6XkIxBxbS+b49RosLREP0MYMN6zgCBHmX9YBhCmCIvmy/HLHP6O0uF93w vpcPWiO0pAd3K8ZPhmO4GPf5VjCKI7HSo3725nA/He+MxuOdJ/deHry+f393 fH+E740eP3my8+g+3kCU78Y7D0bH82KW1xFWCr4S5uVLwDpEMBIxz/IKueeP z47uHR7hR4SBJdA9uUuAoLDMLEVMrGGX/DHSxiWQiOI9sl9AXkT4+msiqQOC 7qz3guLiYNnTd3k1QiGcrugCmCts8R68dA/oPQyVzet7NQEGIP1ACD6I93U2 fLjLlN8oQj0EODn6XqqOMNzZSWARb14eTiLw3nl1dALQLep0WTYAqSpvSnir KRYZcGJ4m9jOcprDI/U6r1EeSgCkJbAwpAB1OV/j+HccVtyB09290wHFHWCZ 0zxHIb7Gg0Pa/BhoREFEhFYJ0gScDhxsjjOC4PF8kVfneOJyTvhr/gGWVRD3 xNWkQO8vluW8PIeZBunk4NWdzmHqUdI5voWbcpHNi3nR/e71KP0diDXdL/Bu lisjANF3P47SH1fZ7OIqu+p++U+j4Z9G6cscqNB6lk+TZDgcgvqAotO0SZLk S2QMkIEW62UxJVjBXuFSz/KzYglCFJKXFwcpij7wOXC/YnmBYGzmVylog01V TFHWaso0S5FGw9ERgQZQpnohyuUAxqtXwEHpcLL3II5lpwAollPtVslhyMU6 hb9yEBZXOcor6Qm+KS/BdIAd8+JveXiZX6oL/CBb5uW6hiXi7c5Y30XMRiBM gezmywvCPZ0QdlKuK/iAR814zcViVcG1hzWDUnl+sVo3A0KMYjmtiMvDa/A4 4RSsSAc7g92BnABwxKXhXYOF8IxEY2Afa8BfwTd8e5QkP8JwUxizrYzT0reE WG3j1HM47nRRAiSADCHVh3e28tH5aJDCFLMa1JMBCOkXxRTk5W1aMK4TlA/g uvP0olzkKegv+WV2VcNisiYF6XjZwP8i4LnTq3F3swJwaDltbJuoQaMWvJ5e IMJM8/l8Pc8qmvCPBbBy5O8vyynMSRr6a6GI6dYfX05ew8pgn9FLZ8UHwCQR DJR+AgstF0g+CMfyD7SK8yDUBKtAuhKsdosKcDxhMMI/2wOj/UCdYOimmOIa 4JDqNSkOeAJzgNByegX0EOgfSsdptlrN9YqwZeR9Vl3hYqr8r2vYMFMOfJnl GEZVRpghicNwXnNU0K7gwE8uYPZZOV3ja2kNMl1xViAdBERt8FbodoJYRudA C6djI66VO1AYUebbAhjlXrVDRvyrgcEgDUXsAVyCZSG0aOjLC0SsAgnFbE0I uwA6mC2LekHzw51HZllf0M46txCwZrqukEDwcGfz8hI2Na2AsAMOnRENbuKb PmLitShms3meJN+g+EezE9H6+A0t5vOXkbSPH0Vh+/wZjzlLunjCUMQrjjww PS1mcIhTYRdEDusmugXlWTK1mZHd48xzQJh1kFxnskY4Atp/TFqRgiYx2SyX uSeco/QNHFCVnq2XM1StGuDSytRoQF09GsUAYReLrIIDIEJd80LTMb7gABDu A46iS02IWlxk73Icky6dG+P+6BEzQfcGnNp5CUSEHoApzkARR0KXRO89UOTD BQKtBSoKUM/g0E+zuqhFfXLIj8/jEc3rMqFLlhOi2Y5ruF450060gi3yASIp bIiuL0g5zRBGBhBshUXsbg8SXf4K1NApIifPPUdMZKpIOCEGQb8hZoD1tCpO CbLJoqyQ2ML9mXsgPRw9HO2NvuAq40U6z4XsZrNZuLxJLZqQXPHf6jhAP+dX eIJBUUIlPyN5FbcBcxBJXK+SFi/cykbvRtkgvVOvT+ke3gHaB0JXdi58qEYM 4q8GaVDZEdERjwciBlWLYmmHLmwUL+1GLpUwaaqV9YZLhNtrsWhHUIhaKLGI NyNIgsz7NE/hf0sQUKbI0FD08KSZYKuCfDJH2TjNFmgboovEGzu9EtKlHHma ASoBvb4XSfEl0asZPp6013O4xBMsWFTAIRZdRbpWIo34XGWzHAYECXmBaltu aGjMYpAYYodbwzh7ORSO1LPZWUlCtrCh5Hydwe4bkIiN3yitd6xxsp4V5b0/ AOkryfSWwSGfw6G6bektREH6XFwC8Hup11KHhLXOifuBnIZc/WxNdhJDYHpx Wq7nM7gAZQlY55Wvkujd2uSfefEuT9BKggYW1qxEJlCdwOSdCX+uRoJj2DPi 7yA9Bv48vaBfEcTHADG+JFuTk+Pj4227pEQ3P35U28/nzySWXFydVkVHFBGu W9B6ga6fwhkCztJScZYMTmE55D/5TRI+RayBB4K0w1+rgIvS4BAPb4VAvOel NRHU6HVm7zCmLGhkYJRbsa55P3Kzp4B7VVEq1csAjbM5C6GABnDgJKGpWIzc gHRcnOoU/u+ymAEqZ+fnVX4u7iA03eIeWQYRqON5pYdHA1SYccei9gGuZqt6 jVg7Y6xRC1HyKlBTgBEI+GUj213HUrBsDxmJsGk5r64JCrncx4+xvo+f4W4+ foyMU58/j5LJfC5gClPCFGcF3LeqXCDferOC3R6zWvCyWK4/wAVTDdIwngFj iwOmDRDsXx/JfLmDixDUDkAFuQWchyT1GyxQAhOSQvoQHNkQFwKD4fy2GVG8 gZohMlWKGPBxdC0REjUIIWviU/UUcAxfbfoWGi0SRsMFwnJWGRJrkt1Oyw9B GXk9OQHacAYU6RJYGPwKUPpAqjTKc2tCOkAC4Qs1WVLh5cNnxzWwqbyZbqcR eVMOSAeZToKpYJGDQj7DZTullcQfNA6D/AdQLOoWKABXbm3qhiGQyQBByd/n QX4mHYDuEN4bfAt5YlAtWCjJP4DGVgMVBlZXsvQ9z7MlCcr5qlHAjtIXKBcJ dGnfJBMBYZ6h9jitrlZ4k+ChWZnz4S6RxMtXxIXc5Kjk4lAFiiRAdVHQB6pf NOF1ZCRX8Ams/3LpxnECP8AZ0GMgYhQIiTMSjxTOwBZlShXJ4KSBg4NQwUJb E0sVtj+8lWF5+ilKd7P1nOiT6t7OUkR2ifoCF0sH2LrUIq2gPEvkBogsMn3j YGgXEUyW7bBMRseIn5ytKyLt+VxUOWGorBAyJ4pVTjjvb75pK+uiYr0OhqXj BqRU0GMWK8Sxn4R8/1Tjx58DypgmYnKjyaMmFH78CEQIUBNV4qIGylGeDcld nVUzxmD4fbhY8e+6xyFNVaMqBBwITUQNCaGAJ/Psik5nlDrUTWAVIGOygqKM 5bQlenhVkliUKpAIz2WZmKzLQoR7F3Eun58B9JL/DT/B7tn3c3d4/c/d61// 5H6fuCXY90l7grtfNvun1rh+wvgPha///obZ02H0n87fiUxg48azH7Nwrzpx 5++vsHf8OdQ99e5dv+08/GtnJ9z5uJ9+8yuuBJurv/v2wF4nPiivM1yRrLg7 ylSDX/8Wru8kPXh5mGaNMM3ZqgRqk26h7Ldk2ZYZ1LaIwHqf4F6gTbo4X5Oe PGPNLA9670EwPaj2owOQgjETuysycGWORo5P100Puw/En0k4PcJU7ITUPDR3 XwGpasJfn9u2qjXKF/iA6rGwfpGKdbLEKGbLRpd1mTS6YplJZyQW2reklpVA uT8QMbStZSgdIp9Bh05yBBOgj1GsBDk+CizkXRCvkZySXMZCepVPc1SKBm6u pGHw8mRI6dL7w2aN2h6iAwuB+PoMjT+iDGccD2Vmkg2P4b71AGlG1q1kCxEM yFZYOyJtcOCnSVm9RDNotjB7xuHR+4f0JvxyX/lwDtIK8coU3VRFxZo7QeHw aCgr3+cjIajoQwqd9mM6cFOe52ygAq5MSxNA7SdJ+htazH76592dnfH+7PTx /h787N+Hn/0H8LP/EH72H8HP/mP4+cv+eHcPltz3+BR+9mfws5/Dz/4Z/Pxl //7e7lhmuY/BY3sj9P/tjcYyUPhkl59NhOIRggjxIym+Zo+FmShTMQU1DUnR ZFsxbGaPxtatMeIeBakhROttviIIrJpMfSJ9hLvBBlLjsGoLDCYTuJ7BshJo AuM83QwaF+5bWXl7DilzIpUtE89+pyR+ql0yt4uCqHVR1o04W0y7DNYbEA3y DyB4o0Jb61LZGlCiIa6H2cPyw6LTQ1JsQfGu0q2Dw23cBKwCbm5ahG9M+q2D FJI5kLkFAchwPlx1cFKcr9GaVIOwjmFEfe+B3FOSYY13enCI5qaaSDigB8IR iKw8ogtEjxbNQ6fOOslF9j4XGclkITFfkYxJnqsk+QFeQ283sgceQ0z1ZMIL YnukVbI8y4Q1IarBL5RsP1i133YYkybJt3e/3ae9rYCWYKjiKTCtBSgeRObw 2INJ7302X+d1r+2nzhOi9AMS65QYWTiHJ8smZ6+qvNGxByrqw8oATwdJlZ+T CYRxZxjE5joH/tcUU1Jd4Ryn67pWLqFcl5Ro4FVvvcPlJYiZa2Cc6IamHb/L r1KM/qzTO69+PD65M+B/09dv6Pe3z//5x8O3z5/h78c/TF6+tF/4CRwG/n7z 40t5BH8LLx+8efXq+etn/D58mrY+ejX50x3aNY3z5ujk8M3rycs7pn4bG0Vu x6hjUONrFVmeYZCnAJ3xfWYUGJgGjIKZxvgRMg20yjCYyyVgK/8Jh0Hieg6g hpkBj3EkUOgLdCg4TQoRHgXxb1zY75v3aNrLL0EOKFc/lfIXOmDEAkCUkhDp ls4QJkaRh3iU/AGtU2s/TCrDeJcTXbFTJE/BZoduEwwlKP6W85p8PAFZyJVy m0KNzko6A5Jb2CZ/VsxJmYWbnM8Sor49nqXDZ45kHRw+2x7Bfb7MSYKgyU2m EgUOZK9i3gzh8LzR3uzuZkdWUq1XC8l45yYDQichLkutMJGPeNj2EccoJJa2 pHuTJoCE6UVxjlaM9/lceZMSFHMn8t3Gw0zYUiw2MhGPvWKH8ua8aJJgGQjD sFrex6yETbEZM/Gs+H2ROa8hWd4HHLLDIpDwavZ3xA+TEDgim9u0rIAvr8ol xogYklnoY7lku4X6x0QCEixDd+D8CgjXEPhRvkC8Zr4/56fCKzMOCxIqWVYF nDdxEL8jdgQzdYVBp8WKbCCeY7KsuACd+hR9bmgrzir8Y5qhgS9GOrP293mZ cfNmaOXTjXxeweISrhzRLt24t9+4J+Ds1itl9k66DrI1wpvcKPn8il1x+FK5 btAGx6+RsZFW5Z2BqFC1LCqO3zsbSeyvdc+Ik4cIT9KRbdAgh5YJ3BEdF2MQ 2+AOnXlM3SnZ8kr8dj3SDYhKrcWq6wuPlyfEYJW6E6hCZpKArSJc1uIpkkQH EiLIxUnnt4Hb62esQCoWg8xSN4MEZMThejWgsCUkZFO50isgvhWweg12WZQz UxMHcpiLEkQD9AYGX6zeWNQl43uJPOUyn8/VzyxwpiN29DlxMchpShi6XC9O OeYungPpAcZYpLN1pX66ZF6c5ehBI3hsxhQW7Fq4Tw8ylIgFz+D6WQZMQu4N FDVnZGal7TsadWv8JdnZ1nWQrTQUxPs00D4v3nQgCoQMGXxyyftIxPLHjDr2 VS1WP6GzEpAMiHj6BlleEoYaICnzBtgOGVYPfOaDG2h37Feeh/UkAH3m5PN8 eY6wcwHe7NkpxfTckltarAbdLT0LCZOKMdmFsvATrTFfHf0EEhXte+UcoInc VTaoKE0nJsV3YQEcnqRxmtIc/0SQRYUQKraGKzLXcdjezh8l0djkXgENAfC7 8p4FDHt6nxkaBLW9VsVDDC8KjdMcBJyirAKjFqOyfH8gboKP34jDAMQwNgIL BzTL1roGtB6q1w8EQ0crz/Ml6UIqy7VZvVqqMRQINX300WLAUIpWXDScAweo STjvRp2wlcl01Y5JF5UfUPOu/6GHniabjH3Rs5seSiRBLZ2M8TH7azd6Wz9+ Gj30dDeJZ7tx7vivpGX8bP214eNP0Wtbnvqhbr9ebW9+7QbzKP583/PaP9zi vesW+Qv3Jt/3bfHG1269t/iT/p32vYaxwCg+zQq4L2u4JjEbEqG1y3l/KWAi w/X111jt089F3NVF0FPm4v/2c5KS+vubFK0MPYab0xwEnlrp+v0hOmws/mtg FiC5t84QdLhMb0duBvJur4xCAQEa54M0V02zmlKKdxZlDriV8DRSg1rGm/Dn tBIy9YRVZ202CwASxokTqpXdmKMzBXnNTOzMJjgQLTIN8l1+xVSP7Owq1IQt CHnDRTIR89KKLbZXHFE46VOkyaiXtaPGffzonkMWqK+3Jdb0tKQAbLFykgIt wCStC1gmK5sC/ZGizh8v8mAAgmsgYh1GrkQKlJ0aGToFOhzTPcdjCSN05TnQ aDB4mkSHgG8UiRGmy5omQ81EBW4L++2Tfgnhf/qnN4evRWrwZy8PetlKqQ9K esvrhz4kEQmjZmu2DfSYMd1pEz3Tw2WL3dymE9t+QCBRE1t30TAyLFMM7uan 3oj0jGSqGRe3vbmRU5gOR7SobLnpLA37HZMto7vg2Kx+8ZTXh8RFUULOH4Fc LNekYKkRpccS3qd/oeMN8V1GUv9bPTKCaBK3nlk7tFAlwBUsWD1I+oQStTbG N0ofMTz9VOz/erG9std60zI4Zmx6p+20bhwMKrROTm4gMXIWJyWj8OpFkhfP ILoEAAnxSk7G/zD8/ukuH8cu/Q5DT+bNBWYzkIJqu9MF6PkW0QLIrkPmwgzd aojvYpDG4AgUsye7gxa66Ei0Mp1oLhk5FA0TLHutwRBnKhDJjDAR7SxA4aJY Rgl65avWnZEMyBKsMzMCQxkcadZRATV4iPIq9CJjzs9UrDyxAhliYCizZIav 3CNNkYR8WcFIpo39pkrN6/ZQPpo/M1+GAoUoV9C7Kw6hRaUpEF30qgde2kqc MWslWfGCB5IU6H54YIyWGOXMr4rgIBU50oiFmA8Q6LfQjsW0ZRFbMNbPSJ/J w2PUwDObVQl3/So4WYUv25HEThOg2ZGZhHQ+guglSh7EEOcFaH7shcs+FIv1 whkg/JVibqV5ExhfjoFtGL5coAeDiBGGp3lfhUaG743uWxA+ph1//rzN8Pf0 NTpY0VYxI8HWjDAVLZWNExeUjJTDXYTbjmRKNiCZiMRe8nwm8aaA1OXC4aUa heqU/CGnqAkj9POZu2mVEgcyWhkpdEp5iDMDlPN5QkM2IxvGMFiZpTtrkBzz 23K9nA1PqmKVnqA9Z+vtycl2ZJQNsY595kgNjgIJoCY7tsRKO5um2XcGkf9Q xAQOXmDDb8ZQp2snpBk9HGokk/t+ScdDEQ1s05O0BY0kMDAe+yuiAfSB5/uY KXWItYSPOjapGN9It6LEjmPBt8ejve1Rjwwjl3Rein850Dm6JD8dvHxz/Nzk JrvbtJrhAb72Nv9rKtng/AHc3holiHq0QddAwzVBhRAMGVLTxSqe/sXk+CRa wyj9fX7Fdlkz36gkFWQkjJHgRDgDqe2Fo3X8yCxUYKApj7lecgonGTDqi3Uz Q84WXJkefGiMsc8tx+jjN2bcYjtPHBukOggoOw2elx7SQyYKdnzb7E+XUJ6O gxAdUjM+KyIVQe7TCUgkfCF/CBEbY55mnbg4SZQB5Y0hLol8P5/S1/y8qqiv 8myJc23QYN/m02+X6ds1XMZPIJ7wifwBHcf05V+/nYFi+2nfq9r78Z9dVdx9 3X5W/97/pEFm4x1baUf+7ejax3E03I778jX+a9q3h4vq2h04Y5RX2P9+wo71 KkeLXDGXfKhqPZfALpXgTSo/PjKqUouiUAFDHgp1uWpFRYXsor1WIhe56B3o dSl6Q8iR353/OYlNijQXGZK7d0vGD/fiCHcJB8mjUjzUfL0gderOn+6kxVlw MsPvOQ3aE7dAzCWhSHiKo4vXAuy5IMZ25/Ud4ohL/z2bQyUJhNUzcX1K5i29 WmdnpCqIlIC/HghzWXkLtw2b0EXJFyuA9QGbcfVRzcSMw+SIsWWtay1UMj6s fnL8YPR4WzQZuFNJ+/6q8VzN60Mxr8sMtFplUlcgRt1/2Hen+Ql/pU/wYcBy No6nL3nUTXf7ExN1zKr8P8Pl3XQT2z/78fXFa3r/od458xvE97V7Uf8kf9iF dJvq3keBCbAUvJLfp6/RrC9KIWapP6eaVXwnlCwKmUPsEbAQlGCuOQmeKFLl mGyFjqZQQAepL9XqochMjA0CbgYoz46YkgTicxAL2yHgSpJ0eoz6Nn8N+jbF SShhomabqjeo9joOBjflLEnkKAxyYGlfxpnIrSw5zXwGfBRT1uOlcuazLeSn k6PJ05fPt4linLW5DKdsl8FvXjfVOhTIsdD1c1D2lhbsKRm5gSOmT3PTGVrp pZ4ucMT4gOUKCSHQAC8OX7J9q4GFrQ1CEoscBObgSMOoFyMSm6HApFIvJwXa DU+vGtaFZL4qX7E5S5eDzsnah0uJ10uiPqsAyrDdOLvRxzdYDgKZq5YgM09z s16ip9ucsJKs4nVVoluSWQKi60CyT86aBWoXZ+W6Sk9RzDWSslgNBVeHLIbD WTHUrsRMugBAUdaNTCezJf0xbCyNibJRc3zgjg9m7SYkpew306X5Z/P0DzIp nyeFISwtShB2oYva6Zv4b3lVtrx9/ikYpKyCP1BDGUbOowVyxDhNd9N0D/64 n6YP0hRI3iP8zoerR6HrlJ8AxE6XDr//GNb86YZ3I1dB53SUQr7gv9SsvBGf 3WX4ViRXzR42k7Ree3uJ4MPH0Cu89MlBQW/ZyCIxc3q8bbnfREbMama4TAFy SeQB5xgXiuDiFQgx89RDzzSj+g5tk2wr8R2NMMkNtvbXZZzUNIxpVbIBdro1 JxWS7tdjbE6SAywlosq5FvrIVLR56+DooEgZq0xbnCW6u1NR/QGgFJU2x2A3 YrIYzczkJO9Jc9CDGDDY+XqsLBESVn1M6NBdtYhZL29cturEHrwo19XE9LLz KqeKPc6oo7fcJSeZsshApK0NBGtF8+U8tyRsVobZwnTD/t2BgnsVDPgzTbi4 1mvAgEAtF8miLtXFephsWlToZ+LRUbLHVFDeLwkgVCoBxGim2gxmHhxYDgZ6 ki9v2RJrXwpYWeTt59owjYX8JhiVLLyGUIFSk8/WdvTRvSp82Gh21ggJ9WKA f1wHdoJrnwzwgFnUKZAiisBQzYESAYlFhGg/EZTWy0ATWmhRp+xK3KXA11Yq exuFduLomkgB30+jYAbBrC/54UPTsl/080Xv8yta8AyFdbTG3DWS4KS0Aex6 Z7s/F65Xfo9/vk82pNHJrPUKp1Uci+cdAKg7k98mzqBnzt+4C1AGfv4dTPCb jcxQsaPlK3cWHRWYPHJKSUHbCXLEseQD8FEHpd27i8m7ugHndgbqYg9UhHKh dCNjuHK7I73NtFeKpdPFxNg5tiWYWMJUg64vq8REzdFAqYm8YWYm8CG/1UQp u/17wWbIWd9L0xsscDLAg0op8Mq5/pHb1I9LUtkjp1GPVCnfoSAQG7vIrBCi cJOWLtC5tyPyCnGyxsCRrU0vxlp7NLcY5mmPVjSmdvSWTryVYedWQqQb3+mj mGfsPqo2SVdaII98j03qVAa868Sy1fr6Vtmiiwi9QawZRESvzaQkae8MIwZP MUWZbCrOHF0KAMh+3ImTeCH50uojy0LND5WicGgc+fPnpKUniy7+8RsJ6Qtp 0ETjXVUkNYSY1+u95A30BSNGBbDSMycXF3XXA1BE+eSCqmKBUP0Hg1S7acrj 8KsLL9uz35J0B1PSHjx8lD5+wr+mDx/xryl+jL+m/MTjJyET9la/JJ92dsY7 4/F455Oz8RAc4ReyDIJQk45Goy8dmGwj391/2CG1EVA2Gmb4a1UtSM8IqW3N Rd49AU75jCTveEaxbun2fPJee3o0gZFtp8cAxm+Hnxvs3Zt+1ErWton12Mhu MH5v+kFDGtrR1HQNyC4LBlnlOyQgb16/OHz7ij5Shoy66sr0banmJVodO1pw 9wLy9gzjXQUJYPV3GkojH/1T6ZxCN8u+BqVNe9ilGYJzBvZAtKU/amy9nKIX WHMwonPYNMMezfD753+yk36urkdMDNPSpxKM/dMPryYHG046muGJDQeKP85w /Pyf7aOAicfq+4y8K5twKZphd89meEAzhKV9Sn/I6gupcibuNwroH1ER9Ciw /JoZ3Ek/pBnenuid+MT9FNAxjh+KSY3NXPOpFoEJofs3n8MjmmHy7Bn89y19 NJkBg2yKOop4kaiFrbzepggZJFzX7eFxOIfHvIfnr9784TlOgn4oCtn3Y6Z9 g147w/0wwxOa4ejt4Rv9SCRvvRFmBLn2ZzOUxnKnyU8pM1xzH37JDHynn/9L qNHw3OrcZnNvl4TNvEfHN+quN85w8vSZDPf9eNx6FM6BxCfWdaUaWCe2f9SZ octvIjdARMUooQ85zQsZ/sicPxYL5QS+jAp6BjmcLKyaVUe6YbcyEjIxdFbH +QpUUA5dYKCBFs5eyMLJpvIGLI+0wodQYKM4hbMMgHPFuQbsmHPb6WGRQayi 1E1KFzDGQCKV/PG5v8TKTdJLuATwQzWmv0Sa6T6cOBvnL/wFY62D1CMIDp/w D8hBYsvyWRo1iUBfZW4VjOA3ESqEq36301VLeQnX22jDefE5IyofY2neTrhN evvklq06zzsSlLz2+fP2KDnG4n867mWBcv9t0mEkVkQWXNQh4TGET9vSEnSU yBStsluVpsdYLmMjiaUaZxsCOnQI8sFIGSwMFkzQ+pVNeaXL/DKvfMyQc6Rc YPrzMsoWHZjRTMm6KgIuPyxOjEtwNInY5dK4Eir6nnSQ+GFaLKpzV3nDkY2W SCQKiahMQURLOgUhDHZL54dAKqEhYTiBWEwpdo60XD2dqCxnTBGzqsI6xuW6 wRI5ZPEk/VAqHnRXEJGyDUiVBCcLq6/ia9QMTOkhRfLSb1PGT/6LiWIw/ofK LBSGxdG6V+rrTLrLo7Dzui6nLoeuPK3LOUgoND+Wwk63fETZFGHQxrGUC75J qY5LghUF3F6irII7nRdTsaMwwunglpSANffkHFTiYfEySCfB+C9vUxSTxiTP pFpcaSHVh88wESunDgudV0V4JRRuDXMVRY8XVF2SIrXg3LGM/qwDSc40aCgQ UOsY2VEUZ2zMeh+r3Poq6WPsdii7ywyXmvPMsUJQHByYhPAtQAkN5ldK82ry J0Qtzl5T23kXEawKkYNDVtuG0UnBMZtYSDemZe2bQV5evBlSb97QKxGR3yif 4n0+vSjZLwDSxJrTKyS6FO8rPo9htT0wj2hDUWuQmoSCYvAmUM4ai74WeRTm XU6na7i6FI1KlAtdJDFFE2sMW9ZgH2iqJycVR5KXnABCCzKXGmxBfBJ50yGH VHN/RyN2SrF3nmmCO7p1OR4i/WOBAeYNhYO3wYdxmFR/WZPRL4pq1ibGXJDI P+a55ZmwJ9QM0/UKT9iCg3k4+ZAuchLYjHA0CvGkEONpQ2Kc1N4I52Y7Znfp Jabgquv6UjaHTs/zpZYPbl8a4llklp0lrdHG4q0MQQW94oBtiXEmlPJxZIvS LimufJVTYJZnxfms56KEgt6MxHYqUiZIc4em5apgB9kp0M0Fnwhy0xnfrOA6 jMQtvjP0Fa5N40GIKDFmzcV00LOIyFnH37NRr3N1sGaw3vxSV8BzE/VBD3Qt 1S0pbLoLiFbyPa9AYmUNflmTlOQFdLXXWKhgqthhcYTEjL28XR73J74rWg2u 85pyDH5TMFte3ZWK8UJ00BhzgVZoMXiTxHMo9mxkQoNWKE5QHKhUrJAdKf9D +co1AocSOsKcd/2y7oZt3NVdcmUJ88TfhHdC5HuRRl2aIRzLwtZ5fLlcHMR/ UdI9rlu3ZhC8HEh1E6G6wAWNTwkEcQ3ISPB8opPNLMDhQuk2i12t+wkoR2Fg V+HeG1ZhVJHc+1DAjigN74W9CyUXKaXqpDlALKtJI2QZ9IpHAVxhAj/guMuW LIEEAQep5Ss9K1pSsJG2GTJqi19kIw3bPs4lHaMdx7f55+9vLA3vb7R/tM1Q aIdaXrnMmS/92Wwuatuj/o5TtQ1TX2GqrvFFrukma78qplJSx240arJRWAFy XMswbDukaIaQ9HoWPGWRftbnqKFkRlW2z8typmYWSUNkQpGlSexNWzIOT3aH T3c36YPS3oUYNtPloGe0JFgkaOOR5v6iclqwS9cun0pZXGSyWGJsA7y+hYVl uC5dKN++rf7j2OMngnQPOYplpqJu2s9qGaLOurfG20k3udRtVIbeEthsjzq2 pFuVdnCPPk1vV+FBfzY9fLtKD/rz6yo+dNcS/8XguFUdgN5nPvUP4HF2C45u CSL3dmDAcHjXD3B72vn9hhV8rS0ICt9Nuz/XD0AhJA7XFQwDBcK2HcNX2ELb itehLptKMehNNCKG1RjgJ5moLLeZELaDAVvUEIv4kg0ASZRop6TbBLIo6WdU 8CufRYRyq59SqlqMxuMfco0RYIHVEgJMuSBdVO45rF+usc9QUNIpOtL9kdFf i+jD1lomtQlQwlQ9gyUy2LhPurWmJhojrrK2mkPggewqiGDaa2pzxQYuT4Y2 gJpVZb9QFXm1Rg3HCUv59PgZLX11DbfAYLasmkuZ02XYgLEQZVsEoMn0neIF dxoDqXTlrchCDBiI7cl2/4dk/3uTbMRoT6/tjO5v3zTAjbC9cQXu5399lS3s RlsYf9EWhsP/tQkZhrflOn27uD0M8OfXrqDv5zZAxIvbx/JuMcAGvrf7H8D3 lFfcmvcJMdfXTAH/9nNwVFJ8CXkp8bcvc1He0hd5W6df5FVERyL8u6NexfEn ojzp4bNPXzLehjoxEfS/aLzXlG127Wl+wXjBk8ma/3fjXXVljmNk0KPa5MCk L6MTPnFfdGvxYF3FzBc92BBQlPiyhMBcpWDzMRrHQni6lZPi8FEvCujwFuH7 ++d/YovV5krk2vUIzeLmW7VKDNqYDW3B6gzB1nVWzCcU5+HYI41I0zAen4pE NklbGwFLssXaah8HepLbLCG3GY71+TNpyRJ1OUqPfT2KVhGiCB4Dmy4qZbUp 89Dyf0LQarfIY1yMUt0YWsGKs0FqC2m1gDVrySgm6XUt3hN2A0r5aF9B1OMc Qmo6LasZ6dEi+YSOjKHyhmVN9yGmLg4w8I7c8zvplsoah8+2nd8pdorLcrT0 peK3uSzpUeoQkGiPCA1B5RMdYPa0eZ0Pj8QDSegVykNxIeRC+lFYhy2OfBbr hI7LCXHwi6052ZDptshWUtGe/TaZNjMIJWTUCpPUYvTDKyDTBviY31Y+0XKx W4SpwQz2+fN2om4TFscZXBjo4kAV2mnEzpRBQuiRaex6ezqtLYHtxvrWiE1F eaFkipVINtUFPDXim5M1mA4sLcBlsiR03OTdiT2Rq7qURBLI3mytONPZmmtU hQKySdsm5Ey7fCtZkTB3gDrwBCD4XoLJpYLPYZfmJwuEL2g/Gh1O908MCveM wviyLF0CGpqw+DKxmOJZTAtphs0tEBQhE0yyxCpTbEUnjKsbrjqHtXRWK+rS 3i4fhnugBvChhhH6oRAPOfPXua4o3EUwcrJsJZwmFNRC9C3CMybf1NHBahs3 MQzR0dIOJ5BmKq5yYeivwQVhoiKG7KvBGMSZlkjnKaWcsC18soyRlHpxK4/g 25mUWl08rnjs68lNqZDf/IqjeIYhE/bMXfvE3JKhYq0e2kIDBBilWNJAq0K6 tzs8BdJTYVfIhRAbbYgR++O5EERMXYHbdiyLWLYHAYNRuMZh6Zi5TDYWfiF7 QLfmL3BUzhjRJfJ6sM6+GBW4tTC6AyVcldPviPf629AptVh3mv22kz+JSL4v ixkZd7G2TUO9n0Lex8EhngSG5fgaAVEescXvSJJm5rI1XLrIIE2YRAaqpFjB NXz6CkJH0YAiY7vyNyRph7+1jQPiDiIJ5mpSyCkc5Vuq1iNpFrjt02q9QusN J4BkTjKDy/ejz1kaEOPm3JHWeIShFxrGEuqCAX+RPfpWNTr9ZRbCzEZpMqmp c+0AS4DQHadRQ2KKvxZaEDPJpO8IISJcQDGLR8XU+vNjttZL6uzIBUfoFmZ1 owvelp7PK6zHAKh7WuXZu+EpxVENF3im1k1VKJ2+STXPsc+KhVxYvUOL+OUy Wskdqp10J0hIwUPJ50K7RzmrVU40bEPTfzw6BJ+oczuM+nJcfq0SFtJbvjQE 87pgT/zESMUvie+8Nppzt6MC+UJSGxShPuiiOkT1VMXgdpktuRVA+071BnoT 0WT7W8B4uq0qRUXTar+m/nOOIvS8PbdcarF4vg6JNr5SLSRvRGDlBfEnB5hx MN4bSREk68RDGVq5sOlWba/WRCB7Y1xbqIR4qiXyyYFtRub5XElAz6DqRzeZ KtPC/7et99ULeyHBIHRwQJzhmpbVsOp8PXV+4wq+FDsqEYfCDfprniXJhKzO Km/fCMGBHiGdbYNdfmhT8XGqzBQCMjplmReLfIbyDuoCWqYOOduPKwmaWEXV WNTS7lbG6pfp5XMKdCrY/JMo8AbRmQrb6WKZJf63EQbOOtGL1MFEYvvUUzc0 kjZtCRs14pbk/acCMYpi6web73nfcVe7DlvKalHdJx6LUsoNLU3HPZ/1WcCZ xMLjuynQ0xSIawqUNn3yJZ8l3R6aX/w3EWKaAP+H/9kRy6FGWPD3+h94gr+H k3w/4+/Tr7WQXojebGzTn09fbx2I1hRFgyZx+ZtohPubv99tfY9//z3WsYfz tLjhNe+mEQ+UH2WF8iMcca/DERHhN7FC/K7PJBh97o2CpoBuqq9Nxjm8k1H2 nopVrDpsET2eDJguP92WoldcesrXWDlhaZ00HGnrp365ZYj9Iq0GG2j2thyU Qt6xEkTWpLoI5UyYVHoLVtZh8GKZTClkVjUJljitubmrYc5ibKc3wTUShCpl bLQga/vnbSxrjr0b/0arYj0vKmNai67ero1bFwiPbJljJHhfqVGyYGr54t3/ a293lEzITufiwxFlNbLTGm1vwB8WXwUtMevb1TYeP6KDeLSXYkEuKcesXQUJ VThNko0U1KwqebwrD7PajkTfNCm9SrXUjtp98ICMHSKeS/6GXTi2t1lhIgYZ 1epTVmnFFt5JQdNRqgWX8Bn8lJvSkZ0nDm6CL4f4pa/th1NLgb+IqtEXAqMt 2t72bbKbPyUbQ0R6v7hFQAmGq+2k3x3NsXHMCTbSdavs/DyGD92jtL2+Vabj 4e6D+z1f9e6qN/UwnK0MiYf7XZQGuWHIh/fhwxet3EjSPONVKnWMDs4lLiJa 24mTLyxsPdkP/KHdIGBFT3FTYkF8oXg/CMVjqWZ74Axk2ngNZ0xSqoAFL8Ac 8Dj8P5BHKpwmaflE6PTSKlHzBhsYApe+NcPdbeMrroGoCKtY05/nMXMPG754 CQXlq3H5b2rtis1CEqz2wtvYT2nwyXe0yru0yPD1U/n6KX39FL+ebCPI39cg NwKAdwii/jy1gqndV60swmWbmZIa1F01P2VLKsPKowgAPRhYmGtPyXTHyLVg XCuTtL3WV1rnzJqLEE6xOcHViY4CF4WgacJYT7WPDaWloiwrZXK1FddCu7Q1 W1AkdbW1+np7RQayJDls8Sw8ZDSHIYnlyVjulxIq+LGjf4S4GzuVo/myBDVl ScmGOSZzTaVvgpRDVAcgx1NWTTElK5SdvTjXIs8cR+q4sP73FO+zxkyNhA3c mtNg5fNhU6Bl1E0YeSfdCvd4OyjaVmKMRQOQWSiJWHVcLMGOiU+x6bp25Wqo Ti7u0c4jGBjp0DoGzVsUfeFUvajaCw65bpnxald0aKN9ERM2SOnBRL7/nknG bGzaGX8Ss9PObeo8fKVs4y5j6x+4z5//RCX3+x3JHU9tk+SO3/VJ7tHnJrmT iLycDZtyiDfz/mPyFmhqi1Sq0HC0RBsBbG5heeI8VZQP3Ho33Tp8dvx6O5Vu zOJJZ+8EUE729u48fohe6InjQlRHLqs43DBpxceFvradyDkQyJAu4P2AISpy wqFra0AxmVmTZLFrBO4S2X1P5wV1J+H2qhfFz3BvuLEeJuMU2IsYcGhAibDk m1TH9aPRbqtA3ig6Al0XchEsGw/TUNqXC36QOHPrYtbZE73rSp4mZBHkgPP5 3EVkZj4+c3Lwe604NRKbJhvI+kYnAeYiW9fUE6TvOaoODud3WWEqFcjVtOVH e7t7vmXh+bpg7z6Ve0ZTnPQsgJeAmFZss0pqtun1b7SteqhGU+fnC64RaX61 5ARpLkh7XA7XGgEz48EpUF1CpD/BDtjqEOrZX8KTn5csGrFv2hUDbk/OpQ9D B/VXvMjkWJ57qYssXBpwJumgcPAnXNus5RLS2op7rY4Do+QAK/hKPeETnbQN wDNZkjRaYPsu5jJi6rqY6jISjCiGFT+mssiujoBWHaZiAVmtytz9xwTiZIot Jpch6UxT77RUQL3Gq1Jw7DCV3LBvVeYEZo3Je8n5vDwltyTAuqG4kdAVhZaq qu74wc4OK4Ca8Bg6zaA4lNBhwUB7jx6kR8VTbSQcH18PqrkiHORwJMZIoTq/ mDP+Ynb4yxlQm/nRb8r8xp9S3NDw+IfJ7oOH6dauQHL715XY6ONfsD1hYA86 DIzAu4mD0Zd9LCz+wlufzPkWNUe2+JcQjTHQ6AyX3mUjch0ALWpEDhslZEnP yGa8+blkf2QcA/dT2yGRtOXvJgSni/AMDA4oroV9BaEQOW7iSuu6yI5OjWO7 sLEgHqTSAXlGCJpUdiqygkXklmj67njnPnaXQxOc9UhLjDULKl1kNbKfc0yS vli0FQ0Y5iEgNnr/9cUErvlqTbUmTotzFD+KTEvPAQVaL1l0FaJv1c7HD3eY ugfcpQZ/TnFJmKgSYfPV1K1LLiox0r+Xn4oXb4murAUKA78D6sKduDOIgHAB 27C6uu0QCda3J/SO+usqUIRRBQ4fgp68MVwilCuh+e68YgXyjlaPQHvgoJ2A HKO4Nj6wqAqaxAVtFLEnu9Ec3k7SNncOE/+WpMGakr35DYueGKjdNfPmB0LP fem65LbFLSCWGCvirYtkDNX2RRLAQ0EH0SXF0eBacHEc6VyODO0ZCVyUmLy0 FgzhaMS/JC/UBnilma6Q2kCsvOocpHIJWuu+3g91cX+j5Gtrsp1+54dDU8h3 jCJwhvX5d28nd98+3e558+nGN5/Km0/vvp3Qm/i/ifSW7bT+66RexuQjPgRB qf1OPB4cIofwsNgZ4q1c+CGd9JmVn0FdmrrLhqIsaG9iUy4cLkvgO6P2EFyu VYOqJAjIkoHgbRqTsHfr9dM321/1hHHsr3/IAZJ3CYp3Yd1bh0fb9O8R7Hf7 F2HALYeNTjhQif30uJyTBzk6a2qC+F8Ool8FfttYzfY29BWtjlNQoT8UXOdX EdUaIVAzkcTCw8VKxzX6SboFdXeOQbCh6Whf6bBs6RRDC0rX8AOyD2r8tVU1 0KeKOg3lUsKFHSVv9DoOooBdNVUZdbfN9MGkrJIIJCNf1pmDY0MA/ayQZUg7 CnJcBRJi+090Z4daeOId4qdWaTI2ZDwhzoOOaipwoeqEC2XULM1487cOcVeX qnUyovoZ9MVuVNEpsWgKeauoO+WsPN8Klak15ZAH3fCeE16DpApU+s0yPi3U qQZBSpBTc0EfQcwNsYj+Ajq5TyJnGLqmKlkrUTLahpXq0Wr3gMytU+2f9kni IiwtvoQC41sBlr6yXHtHXIx7iz6+rEoqMZIuCirEJv05naxs5RnZ0kIB3NIT 1XSJS2uIq3Gf3aWLLd0JGXhM8CLX305ebS4a5m+W7ZCDqkG2I+WY01GRMm5Z dTULTyek6cbjj9Lk1ou0S9u4KMs4KFVnDobibepUR69wZDyX6ArX2ZmzW6ib +TUhYWqn0EifnkHKIZoJ8wSjjaYlUjG3rG4VppOMWt9hlpIgiKRWceJNy4kO SIAEZkEVp6pKtaiNItF2MJdjTV2yCsAv/53N5ZY9h5/gplG5/4Qlhb+yYfxT Ojm/qcrJrbPirjVHhPS4hx1zBO5wkzUCv+szRkSfe1tEs6EAM/r8tqpcOgSw FLsATbRgRlBL3cLTHGP7Ve3tlg0jU16ohIgap7PWcTxz6wFYGWbaqdbaIkNA 7qNge1q31tSa5lEDiTi4rsSMCr5HVt2RiTDb2y6IqMKrc0yWYMjh4NTI/Dxv L9OSFdDTds6l+0hoob5E2Nm3Kkpsl5yQ8fgDzQyUczx+sgdbWVe1zPGCgjro UNHlFvfs1OAO/FqWT5pcx8wcIj9YM6eDxl4yydvskl7f+m5nO9lP9U+XycVh 5uSVphJhoUdy19/9CvCARxvjaPqnjEbtRSQCigHQM0L2QUbYpRHkzy8Y4XhR oi2AB9nDQSbYBA+jF75spOcYhXBwABpiHFLjbCuk0vFRao0twcyialH0+Izq ER6u1EZiF6wAm2uiBQMKOaQHvq9UKE+JY2pYkggEWuWH1t1qfMfBG2QbBpSV Pq2IvFZDPYq2IhN/z+XB3KVh1DS8s5yU6hmodIgkYU2By/iEFBdbCAv0ZIPk lGXpanuGZ3FA0klqLUJGxhhx0KHPhcUBPl+4azvdGIe4r1SWcordBd8Mlgxc cFzbd5Xg6lv3XEOxMDWS2S7D4SdrKjOi98atCmgsZ9MMlE58crIbkmVJlsbv SPFIHO21MuL5B6CUBFJLW+Lsqm9rjFk8R0yDFcKvTVXOXTgGlxWhM3mfXwWb ZIuQsgO+j22MQmRgFIuNm0x0Ly3tCwmiBg5G5Bk3+dMsn6NDo8/7wReiLufr JkJFmI8Mfto0yJe8DTUzW+cHC5PItqsFYHtVTPUqYcD1EMTqdxKYx7+zZueL VGpvnPRn5FDVwLrekFCm/KLjXZSCllI6b0n6gbWMl4yvgUb7gOy5xoqFyGek 8EuA0j1fPaWnu4L8aNJ6mlKNvP7g47dyOlG3R66sAZDawvPcbkfuauNIOu1u QadWzQd9WKSjtijk9vVd9+GwjF0q8YGi23iIf34KD9O9uc0y/Abjn/YGe+Sp nzrNvHL4E3vzcqbYmV6SEDiMaIQmS6Q6Im+rPkUyt2pDJoJ11GILJap7WlPA h1sZtuHjZ9HVOEi4mxiHNVBMnGav0Y221rDA1ay8r3yoKb3Z8iphqi8Zgdd2 VhEKHGgPXIP6IqeLyx27gpkFj5qu0T2Xoaqb4i9P0bWdh3qBoxCSpvXpQs66 03bVDiX6UUJJhC4sGC1E1uUDsxgNhiJiSaAqjGotomfeREhESLPQM+BXV+nW 4dH7+6gZw78PORRcDYlZ6s4BoyI4l+0kyoiHBVeEKBY6vMsRvg/ZhHy73NeG Axedw0uzYYFHJRRE6fX4UJVPJXwhf6L9up4qTJMSl0beyTM9IS6Gx7erDuyA jFGDXrYMOqAAfqzr3MJDi0pajU1zRUjgsnlVee4W1yZWy9Fkjjn85xdihM0/ rDhBKtS7zn7mSsfwIlpgppThRU4zbYfJue+4vFVWVJR6GznGNARI7QxbTMfp jcc7Cadw1vp3NysKPaWliFT56gKEGezIzEGHtMiE27xtS+H7wOR5sVuYY4qj 4CsSxTQvM6zOPodLgWYiNuElLMBwInzXYZq54sI0e2G2WMBPlrwS/cJiNzZb e5hRqRXlSosUkA4m2QEq0VggiF4j65kpsZfcSsF15QppuN5Q5+lkyMhF6oUi Lema3kTZwXwzxPRmIcKdiZ1uHAIW3Lf0apCVo/54wSiUBDU6cvaqi1cizvDR ge/B6hsb5bOOg93VWjEbMqHuJV7LOnKgEiZQTrt37preMrAiCmJ8ppsiLZyc Bo7lOjSmWxtzkLN3Ip7PeBTJDU3YH8x1LzCbVAotUFwxW8AQy0NMOdYDsNRG 7YKgFUIlQtaiB/hMdLHR/oDWxt6eARPQgXPCDYIXTokRrmiFCD5zBlpeRtJB Ir4ohrmhgF5Pw8TOyy5WQTdAYNUOxbtt/yEVriBKy91+snlny77UR5RUimjc oMqKJDQplj9LvFrnDnGOzNLdX4kRjLKDRsnrsuHbPnC8G7sXEDSUgCuD5rvC C2PXgrFQJOlsn3ZZBWfz4vyiEfup4gvuj3sPoVV9mRRcnHpWgOzFJ5H5ytid 0tOukRQTkaJJ2p4ghSX5v3vN2J7h0GH4zWYWLbYVmoiEsGv2YM16mpAk5oJw C5YKl33h7a9CA6XP3RKK/udLEjr//fI52/96leIL8jnHks/p/PdflkZ57Tr6 ASo/X1jzbMPPjd/H69B9ssQ5hANgGnGPRE/4YPxQo97+PutAV3u61ZHxaLpP wZGoLb5vMbGibTvZsz/X81FHI7PC8hus3B1VCovfsjVPaRA1w4jq3bhWJta/ nXqfcVWqRAtpqVlERzL1w+U5Uv5NXBJqxPMTsUJ5sSGZMfSskMTPVu0hJEmL bJlJQbSaomyp9ALqWWwdcnvQ0rud4l9xIZzaeeUk/zLhIlStljnGM6kymK8r xFICvFJWbFLRkj0ncWgN953Xyl5RMbJWXa+4jpnKUFs+zNVVaXHQ3v6tiC+S /sRy3Bw1oYYLqwDcEZ6odsX2UBWRSXicR8Cf51mFcT7vi0xbEhsQfTCRadBY T8rqmwXD11J6crj2F4Rp5xSqTBlQtF+Ze3j4DNMXFDZWm4ozunwtmLi9UpYe HCaovmyH4sQgF6pGwb5IWqKOGblCnMjEDXlOJWExLoMWEvoODklZ8gmNcYfX KRseE28ubW9ilJpIQcEgcdEs7LM0K+opJkpY9w0LpVKFnnJ1R+lbCudWZCoY J12Ttf0k+U0cIq+aj8GDajIMMPbjN+avt2lmcUEt3OGS0/bwmqH2caSJZvU0 X2Iz6NrHGBTae6c2cXiOEhaMA6MSkEmSozNKMluUGkuI1sdLcGuj6ymKMA5N VAaz9xLJ+qpxgPtxGIvT5Bo05bswtZDCRtpwXZ41DJ5REhLP9MLiOU0vypJh IX2O6IJH47CXpJhKayaqJEb2HhQ6ywqNafMC1A7xjsCNpAUSGgTzjaa8GijU quoiLBTfk9eTEzXfsDGdQ2sxOLWo1B6tBYwKGAqQd6pDtJRwrngegkwTys5z NiwSTc+yabvPgixYQvykg5fHXsydPK1An59mHG9FNjP6I6gted0ONXClvIpV wRk33MxBHUKZVooi1cTSODu+QSDPNFuofyk0GOuXTUlobVWrDKHcqOsj8uSt IqpRcn/IoHE5qpicVCzhxP+GKT+c5JhWRf1OCya2QmO1hYSzhQERQtqRtPkL 3TJPLHtdHBoTk3DtBWlyOggXiHWBdlkYrLKiTeZt3ZoGYi1Z0UXKxqO6Jj+q 1yQt2Jcp33RK66aLsShq9joMCBMyNOWwCVM+ThDKFn1lZSEpkaueruta1QVd GyoLpCf5uplBcdE14eZlQcsy0FvzkQObwwQpX3UQ1+5zWx2T8CMTGF+/OUmU Hsi21RIUFL5ohdS1EvaKC5vns3NyjK6bhFVvpLWSuFqmM6CbpVhY48aKxJrL U+n3R4onWUgxzC2/RN6LRRBhWHbbUKFM2EBrzo6bFrv0VnDpmcJUqY5Gh0az KPK9J+y4yKfv6hC1rSYu3Oc9Ygu+u2/sVYthqXcB6dvUVjkLhXtFQ0y2Yn1x uxVP2VvNVuuK+s6lSoZTaeLUp2Vz+uFZQR0CGn/vMB1yvUrMGNsXCx0sKOtl qNg00KRKQBwFXKKNSn3dE70B2i5Zxqe23T7FwySDJKYLNZJxY8Gj1K4K8rgL ZXbm1wBWWZyfk5UfkVPvSdJdEtmBfV3mrizRWSS5Lhprfgr/wGMda6ZH8dOr qD6XGjqp6aGdHbJQpmO9yKThpWqFtYqdIhUmIMcHdzCcoUqLfnP6jp6DC7nm tIf80pNAl+EeWKVDB5IUW+Zq/oqVHhOwNxpsPMDO2isPDWuTKHfxtjsSwCJa SJCpNACOPGZtPYh9/lyLVYIN5MlymSc9JYpdDp+Lz+aYvfAclvwc+MJvUW3W /nJyMWYKYbZSt+KKQ2pKZjJ1eXBpYJN0kOVgvmxW1ey7kNqWADQCj1xhR/cL acdI9eoQ2QUY0XJwFc5VoOjpoCllbF0VgYCfb3lEM5tEsNr2YQxIEbk0b6is hn6MwPM4mXN+Zegf+NYoiUPEEaWoXobq3lJJUe5UX7VeFl5YjlwaqHX89AXA TGRLflwiUaPHLGtagl5doy6peGoUfiuTIbQiKj60Ta5VWCKKKMZFfOQ7JuBR orgnO2w+wDk1z+areSt9Q8Gv67Ds+of68iY5AP9/nET/v3ESqdQVOVi06Oiv cLJ45PqP9rMsQPPWRPyv6mjp3tav6WuZpDGfVz/ZBp9LT6N3wiRqXpW0F4wU luVJ6VpBOMgBoX0Olw2iuU9M/feWzrGqLFu0XGNuMdXUWkWBjDQwJNe2Tbzp FVgp8SyOMos3Y/HOriN4IsXiQsJsUKkVHxUIwvxVXiYSwPwiBCO204StJERk nOToCJdqVCFCaFyOSBwaL7CFogjIKZo+LaC9yOerWqWNVh1WNB6hvM1V8nln V1IqTKxeZmTXBg/Y0A27ssBt8T6E0tXDXjO9wxYQtHZKFE1sblX/QXMEcttu OIGqiNgnLOZQMcB6UVAJriCnk8M7sj5zgaueGybvXutG/AIv4q91Iv76yqMd B6J3GO64v8f876c09iB++hpruNY1eBvn4ddw2XX9apIz8rjtWHucJMPvow7n LVee97vFxGFjfkmPQOW7bFE/QtJf8DcJfqQwXetIz7yylWvo2+CaMRFUL+B4 iXJ3LayC0Y3reS6G8wXXv57l04JLJ7BFhzkUzSzl93CYZJVdUWQViDdn5Bei ykKWxqX+In7RBV6zQU0DFxOOZ6RsljwkkV0A3yWBUHY6dVVviO2RRyjxy5bN xDvAlbYWauZ81KmkMQw7voSBYOS/zqvZOKCDSYpN7PbUoM4qF7uiauFTqq6A EjBzNKef04ZFS/xjMXxR4O7PqjyXgg/TfD4npQPZCtn5gYAn78v5egH098Hv 6HMBEKoH52xTXS/ozLdFa9QdUDAb5dRqm/S6lJ0OvNdHAlQzkH9OcRUswayx gMaa7e4oi1UiWnGJAfiUeaIeOp31IqN+JiKBSWzi9KIsplb7EGBXKYtUlHVV Y7leASZEXVqot+qKiEBZ2B43rTG/aLcfhXwcVAjrSXF9pe8vK/X9FWJDfm1N aQ43/zLaPv60RYW+tz8RRFvh379iHT2kVWmrZUEKaX3SiVkgdNhENmNc0by8 kLOliXeVi442reYIN0mBxeTkhGPbT59pFUXRhDgTgo1eLr4anx7vp8dYj+70 ah8N6fJaKo3BpN+RkBlHj8QYxEKNbJ4e3+L0FfTncYnaBfxKnezCxGFNoWuK JTedpTpeqU6WzngaTl7ltGBnXYEbiLvahV3pe1++L6PGfmeiH2DT5XyJrtb2 NnQH5RR0XY2DljrcmF+PJ6kDqtOzkAoV4Vixc90UqAA7NpmAdXet40w51Sen OqQKjgjQRX/pOGkKhsQ82iPJpGSTYmqP5X0wfAGWVUsn4Vqj+aNdU9qzDHVW WYvlprN+Rrs9jFx6sI/Yu6AzMlh62siszvP1iBXyCdgGlH5a9XSfKskBLu9j LoIifMhKbdxgjHtnbZQbpT8wk9LqkTpJm7uPbCSzd0r5RvUVBsO9ICGbh2kl bVFB5g5D3niq/jgF/dnSSOeKx6qD+ePtFGxYbDpzd8SU34CljjlHJkTZi7qO NVDGI7iPvDgWD1T0kvMnDelAhQRZexnucNxyG5fOw0QoGI0RX0mkMHKx3fwk +rgLhJV9YWh3f45RhlKwunIbwd4cLZonkstNNhsqEHPGFlS92kSJ83zGeQrL 9qrwAoiQO1D8YmsUDoZNRaoIiVuvGyrbymZUC1QjJaZsxqF4GSyQtPtFR4OH wuwiPhJ+Fxf4q4+kxaSSdO+Lkcd92WrWjiukKA7GMU9svOB9LdGhHmtUhTVO kpjlZxkgCAwIV60oKzEcSic9iicKrCe5ZgryWqBQ8N3etkuyonfNLhO54gEA 4jbpb18bRV1NtGZ0IH9rNAmiQVK8EYlKJWy6Pyc9htxycO25Dxs1paVeiFqm QxRJbbkkFpqoPxvXtnv7/ODNq1fPXz97/szFDGWdZVERjGW5HGIcvApKCS+J JfveNhNYkaDiiDdJ569odXLmnLCjfqXWTuE+cbdIZzbqnwXb/6iyGc4olDsK imiNqaZIKaUMfp3Gc+5gZ0Kx/gXjn5jYqWjvoF9SNNdEZG7EkEW2TWon7ETi PaUqCL+s/bTZz3jiWSTZwq2Cr+N/KonuDccPJEfOR1iJCgX7BbifX2lF06Ll pOC6w2R0Zbsf5YHSuz/pu85/oZ4DVsRKCcPYktf0A2p7SkTF0MdfbgpWIaeo qzXMolco3kuvigQkVemREdeOHrW0NOFxRJ5RCRWAlSYfjDmtzzbDcoVuCas2 sZPRww+2Fr5guHBTV6YxlI8mxTBWVke4B+/m5TnHtl6fouA8VBtTFPrRT7IV vtSSLsYg1wlSm0D+sho0X1x35iv2/hv/nXv/jXc6quT1ff96Wv5NeumX3A44 52nOPdLEh+xiSqQ4XOhtp7IsB9Bh3a4415ElUvYvq1fd/LNcf6DjsQxW/8Ri HCnlsol8J7SGVv9g4aFbEqEtcXrk+H6b/5WjSMJHWGKKDHqdB8W9zOsPend4 SDIeyc6UVdVVDO3EIovf5fmKZTXmPVYY1/fojubGNqKN21RT9j83YEiXXG8g kB1eSOd0+UHsG8j9uoVj0XrfYvV8cmykye37EjKJGbY6T6mXqacxYRJhy82d CcPhk9rAVV1bkBbCQ3UmtA5sVHqtjaHoTOU1+n42wXKpjqb2DK5FYgenwgdc um5DS8L4PUIbyam3yUgG4YCO0JUwKVVkt1bNKhkOWh0Io7MlmR+GPXz9O8G+ hB1bwVvvOmkyWtuqdEnSEGojRim7pyP1oWduUKBTcxJzCDVoJYoO7VxqQYoQ UOx6kIVOlJJx2X45tI7WujBhQnT01XErScH+Zzd0kuyDzg1nlqpPzjBv0M0B v8yxCXh944Xl6LBwnCAjy2Xlfpwcqh51quy0nwyUlDg7BdFYYBMVH9CicoRk aj6O9s7h1owxvN3WHfGNFzbjCxc7MLoDuC0cil2vPmhcvJJ1IPoU5dwKfIdp qaoNyqTaac73/mQZx/WWRtEJUEXasNVUrUeaFXsWZSkaMw27i5pxvWqXgoZJ nv/LkZqIrBEXyTPwBRlxSUBicFTcAwzVks5QjXa5I4arpRPwyHK/BJdtcAb6 mDZXKhZkLRB2jUMuir+1SjPx6SClL6flXGLflNSp90dCkSUxwpxd+fJ9UZVL 6YpXuQSXKJUg9DnFM3U9eGuN4FrkGUdQdTqXjUTcSRPdmNjwxuOoGIEFA+ZW gcXVM0tJNQZM2v/v69fmtXUTY8eh0SlRpJOnz+j7r+TXBrm2F5i3+bnRrX3T T79be0O66HjcEZjxmm4Sl/G7jueFIMi1WqgYMkl8eB3JVtpTXA8vd04ZkCqD hIuLWqCEZWoPkFDLZPfBrhV8Ia2IL+oPTkA6MgHp4ze+lGdUzQyz0ObzNWvP 0Z3va8l2+/LprWskRbJv+yOVtJNNB3v92+E5C7+Z0OW1v/qurfvR556Ok3jO X7AC+rtVV+r6l8Nz3ZejHnp30wN20r8lu9/B5Gjy9OXzAVy57fAyr5YFo62D w+EEXsMYy63x9oB/2d3mV8Kiv9eX/6EP9mGspzzWU/8uds6Mlq3iBosNd6nJ MZqP0pfRqtN42b8WYFYd94tfvh1piX+uBdiNP19l2fGHv+rlDUjWxrH+lwVD UAAjFBm8ncToEQMsflnA596fDN4CelmxgK2n210Mi5fNiHbXsOx2y/71AKNT +wUvK0hsi33wugFgX4BhnWUf/P7GZUd8sYfih/J2zFQ6LET5IyeGqjoWOExv q08uBe8aImiDVY7LDZoMI6oL+xoeZCsOdRCh8EB7nYqmYDGhkcKo3BZnGZoU SzSTil8SuRTPN2UdWE157ZDp+oD2xddTK5sRj+i7dhehQXgwdsAkN+bjjAwo T9tAEXpLW9K74IT/JPVw8uCALcTgkEV2oPJUoCLhTvH3FKOfsBPbd5KWkHHp mBaKtEk1iwBKAmOShkestGuIQe1HiAl3AxUvhbyLLUujxrcbQWevIyqLTBQw lfQs0E7JFRi5jmZWovXN0fPXFgB82Kj//pSCLLTGnHakEyMaqpaYfIeheGWF OqaoYXyR8gzNgCRFbqli+AS/dlZQ4Od1KfG+qu65vOnT/KqUY+ZEmrmCiFW+ rHK1DRpzK1kOpl+D+RIZsOShskAyOZPLrGhqd7NxOQZgOlWBvtiaqDOlBFEn 5qO0drhhT0oeXLN28UPFBKXbKKxOuQge9wi2nFElSEl4/9+H9LjSKjwGQ+Tf /vX/rumCodPZkpCdGbRDQEcosrqEDyAWKKVLFhV1joKh3k5ahdI7bTn8peCO XnloYxNZl9+63fRSniTtpz0u26OfALWBknB9ZUeG/bbSt09b/U7I88drt64c SIkmnb6SlvHkOoaQu9/ag6FOJhzuoi/XyoiTa/+GZ3amGUDUWW4qwbynVy78 g1dvBjTfnAElAAEIMgEy5Npms5ApoUDzjdY2MB18Db6mrkKvvrCV1jVk1gDu esC5ApgRQvwnPIMItBODZ3w0ish6ONhx/qudwW0bod3EqwKr41w8bkyAzmDK e2JMchIbWw1Uzw1lC6wtPNkxJ5J5zrZctM5xpGZIkd5ONNKd7PpbjCjbQPyX 0pTdKrC4aEWrhxAGpcQuYZTa8KZbj28rbgiDJ5GYQYKtJ9LnrW2fAP6hxZFQ BDvpHX6V1S5XNHQQtgoisZfPcjWZQ2AubhDktopZurttVwH36aoYWHwDxxjU ZEvXGuUwv+NdUhDJjqYmIp1JXog1bO7PXqXqRRdRAQWh4uE0J7s/HR4Rik24 NhPGt9PVEoOyXhefZ98N+StqNwtD2CJjdnZSzkdykZXq+YhrOZA8DVAFdNXc +mtr6mZm4IFNJMkk7tvpkaXto9WSZpHc4+tBexeXdgBUePam3er1w1sdcpWv 4duxG7NFNiKLWmh9xNRS1yHhGV6GYLdqXEgeZMa/gmA4NoR0+XZZB2QU5qGC 3FMfIyQJA6u+onlxVQjfnsj8QeqRleiikE/vGknUpAPMC72H3K2MlZmMwwC8 WBbHK3Xnct3GHRCsx3h80BRno82aKJNYOx4geWUQtUWNDhW5HYo8/UUo0sKK /yxm1l9qZ/2ahtavZWkNVJ87GsjhEjm3ssBEMgdA1tA01TIcet5+V1DQod6t zDq3XTb/02M+9AaztNO5oGfn/2Brl7tkS/YNDlvL32AZcrx2k2VIr4yhtrY7 eGuptEHWcGU4bpA2LKieK264yGB1+Fs83gaBo5uX3lNe5fZiBycO90ge3Xn+ jsKH4/4AJElmFr4vLQhQHKGS6F48D9VVegj9l4khXcbsIfqreLPr3fqfhj3/ Eu68t/d34M49VQb+szNohMMvZdCDfg7duW3/w6P/O/HocLyeTXvGd3sejdj3 X4xH7+0NYij4HWzg0TFj2sSm3b2JODUaDw6kKEd/ksPHb7TIU2whMFYtZa5c xomqdFgUUIqsAWMqw3ISHz2qdWA04pce9xWqopSL3ojiThGkY3n8wehhy7YO 843yEcsM3gBDIW/3XESdlnDlvUi8lCSBS68IqbvcCuaNGsyyv6eo+iKiyWwi 4w8STs0S4qQQjKznAVRrBrjPW3ArJzNZWwI4nLyeAByolOuRcgDgd2cSzZqi +V8q76ZRSYBWPr1GfFZhrgfp1hum5c+rqqy225k5GmZmdRu00hm5ILD+Zhjr Sbp1Upbp03V9te1yaiRsRmsDnlkFdc7IwKyehLLgpbVVKCsd6tNk8TzkWbDM YnMsaLFSDKrLpqEzjWF3hkU9rTuNNCzM0QORSR2B2ncWRc+LFpcT0cf7M5p8 5eyYhtIxPnNV31pTqEJJTh14U4ZSGPm6ixQhSm1X5wFWhPPB+egdy7jPNGGn MWZtZajhwdFTnQBjV3tewzMxx49+bs1TmZvKW7dhXu7BjcURWj//IEO+kYYH rXjuu7cdR38MAH+efEsW5L+kXzrEn1u9pf4iA7iw3bthHvcz/F6e/PNTnXvT WDf+KFwCzfn120g6fq8edBbyK1kqHME7936AOy8we5DgcCfZKPG3goMHmh/o iagkNkkvryTEcRNuR3JsHHxskdG8039PhHbLv9talTz9nxwJvnAAFF5eSHN3 kFOsz7sJKkqCziglDTNWicl5BVWxDMvdUQa9pu4OpHR6YrSdtWLAqVBlE6dM cU7hmYKgkoyE3+IctL6EFHYn1USUtUorZy+pSuBq6M2fevkjJ6aniducQux3 iC9rwj0aSl4daRQG5j66xAR8mCICylBX0iLDE2xPTYIZ3CJSo9rB6jWOAJ9d 3cPE3BDooaBUnZ/Khs6sAV1CCZxctAgZP/GxRhM2qmZjbMygFbmhRfJ8bTx9 S53TWCvSbA/k2VuH6nqt9rAASkp+s5nZlU2M3UXx9IbRNqmUvw2xIOZR1zwh c6Rb1XcpxxDnkXFkm+5A8307NJBS6PFtwLOknQEeA0oK8BmSpi0UlPr3hVVD TrRmnvjebVJNwGDKK/nvJOUuZ6uSqnAhUpGf8BxrPmlKsCBVKkilpbacDm7Y lbQDLhQ3DQXaC5JrFjhCWYXNtu9bqITS4gaL1U9y4mrV66zarSSZsRi45nrg 1hA7PNHxcPngolieRyzVeBgOmuoEutAZXbcgPbsQBZP0WDg2r2ETil2DNVKc yB4I96FN4yw7HdMmtT16YTYtjNhzbnWMWMMQ/1SKhp7mru7tKJEmBuovdHXf fy65ruq1nWpRG+0hUeHqWeaJVtHRtGgprMNET+26PeRgwERAV9i6NIniH5UA KLgLyoUktxdxc05HD+zmaJ0QLXkLrwfoKNVWT/SIejuHQqVUQwGeAWpMd0zr /G05W+c2bdTqUGNXDK24rNE8cVMPwbOupspbt3YsxqW4SoTCg0uJqpbQrgy6 EXcyCUHDeFevWyAyEVu+rLDKM4Z43sPgxZTsmhKdwwfuIkWJac+5KwMlynN6 PlZLfY+5Snw6tVRhcuyL3tSiuqdXqSvrOWLkpw6nCbd+AN21CXm2FGdCmZ5t w8WmkEAsOG8j0f1MiODKXYpj+VxPRUxZucyu4HV4hZ4KNQuV6bIl+5wOjgqS 48g5MxObs1xeZtWsdldTqxjhk9W6xuY2zcWV7J2T2YQrFpL6aYORPNZuK6us hA9+VpUrjjQJ3TEk+YaKzpJYw30l+NOaXlmRgZfbzIfoS63lTJbGZ/KYeoXw b06a3BukyQG/tc3cX5OFN458xldmk9DSrk1LjRgcHz25sCZBlh0vTaKMSjpM lQ41nJ2IVXjQ8FNwneOP31Cg6nDGf3+OkngxZlaXwNmxIXG4ljTjrKKwoYZr nGsR26T7OJ/tLJiO4hz+Ad/CGjs7efkP7oLAz0s2Z+W6GmJp8jgy9wz1OLYs BpuIwIsWJNvkbL8kZD6xd41cAVgVC60b7Q1IdyEdAYmyvg40YpS88Oauxqpg ZtW0TreI1aLHcJtvUo3tQeLMTC6+TAL/yeGr53+cHJ4MyF8CSCgqpWE+u3g0 vTbuMWSb9WnegEtcpYiVBbvNkicMc4agZS9mdeEsbastUEeLw+MimFtq7yh1 uQbpsLTg06RzP7ncpwz89vk///gci3xz/jLLDd2jTaQUhdSKZooq4h1RDi4A bX0Cqf4zEwIryIXf+Io5CQGW1WE2TW2eX5LFmwuXre7m5dhYnDThJkycTK6n y9Wn6AAGWuEHMGl+5dLnrs2AJJ/BDTmSXAjzOnX4vf3f5p9P14/i1nCjH8OP Eq8dU8MYHbtfXDfKJ3KdY/mhnrWw2TXtLL9nFFTzlxuWbl/dPMqmnxpOW3W8 G0a54TT6H3Oj3N0IvPin59zcKPD/Lw+PT4AsXI9Bn+y62mOdtdy93VrublqL zlRN3xsQ/Q9/Ll7oG8+Ij0Kejn7wG0nk+q9yRm+fHx+9ef3spjM6mrw9IRr/ 73JG7WQ4+eweilI96Y0bzujGlLovuo0bIX7DKBEx+h6/ITimrfS7G6hU/HMX 4cj/uQ7i8SjKwJikMS/6JP9J449vWAsC1xwS9CX/Bw2KcFL+q9vuyI3iJ7h+ RzeMsvmZG+9RzyidmxTdIys04k/1Lo3hp/j+k5XK0VdvcY86++ncpA33KIKh H0UIXh7zks20Lm/6RvEPXjtKz/OfFOPQeSLr7I7ibohBJGzM4Zwb5X1nFPgf uV09/ocXPrW3eS10w0DxtJ9aUgectElqnZNu/YTZO1/3r+Umqa1vki50f9FP dGF+0Si7r45fUklEVHhWINnW/TEmrFn6WlMcZfLqOjWrZc8X9ZPDQzGZDIvu 4lgHkhZxEHVQTZJjqpgmDnlugY56rJUf0/dx4rU0ppbmzmWiUQpcaJLCDNAh xBUJubIo2tPcMNqumoIdMm0NQRVNtTSHBCEcsZ/7uPhb3lo0KOGLVY11OUQx jpuNh67vPqZBq8DicFuvjo7NrmYRGawiMhRz0m3EmB3X8zAvPkU2cK0j2kSv kq4hMuP7o/SPBbaObshaBEhAxUrZ0aPegWxWrjQhLBhRdd/UKMz1gcXtHb06 +RHr/aDLZeG79/C5pk/Zz7bmdo68Rq9Lhh6D2kTQ+ur4x7BwUlFPreSxFtME QAqQolpk+nXwWpHdoxb4q+le+7Xn2kAqKiQ6rUrrV8v6O9b1YmLWQvcW6oT4 lWMNEGmjvQ4wK3M17IsPj4tBYT/gJja5mxk46Y+VCUmz4q0wrw1FK60qXDv2 xLW6Tq7xKRtAtHCz9kn1nbp9QbiEOqdp+W9fe/w0X+ZnhdQY7CYB15xh3S0N zK1CKNGpu6Gi3TO+1oy5KsdGbJ02xqHCmA+eZYrvO0haIbV/+9f/pynL9HRd X/3bv/6/7Sje4MEVc10MH7L2f5hyoW8ulGxd1swJGeq29nv5HNi0/W1wDr0s 3uWXRZ27ptUcT2vRedyb24Wy1T1Ator0dL3IgBH1s3Et6vUamzGIkt3Rmq8V MHWVBaz8DLA1X07RoMlWQV2DmALrC0Dt4Zxs8y4NnEPd2FYK6ISp3VQhDSPR Y4dxDyKxdU/qJSpyqiOsB4nkbltGOTlZptP1KltOrby61LI7XaOLBoFwT0gF 1lqjNMw/ertX/DgPTeF6mZTSDetoJcLZejQR9fSKjBaIc65UHhqDG/S4XuRF ZWNcFssZDWH0MFuUa45D5LXwOiKL3cDto71UAnl9I8x9Ov40rxqyK2K9CyyB Vc4wliCjGxASVBGu0vaAOkFzCyjkKdhNUQ8RD7y1JPIHWSghIGaBRropE29Y zPAUxrssZjAeGjHRdikI5jZes0ekCYGONOyprwFySh2bM2yLm06ODoWcSWul iAfJPoy2xDZuZgFHnerYeCk+ftNX+TpwAcEFios/X0tBB7jSc+RWWKsaEVlM 0G5Ybf/AEw6oIDhXaC2413DqmZS19iRKNI+/5ItbbKq0fqbtQbzpVSNIefFZ OrtaZgtsmsU9Wo1CAHvHDGJfuRUrBNZWLoOrDw+dS2lmvltqbpXVijmWdKul I4dYqpobaOKeXYRNvL2enrc+Uyou9+ojhEngJGSksuQ5ik1+WUgBhhhEM6yo 0OXBH18/w9Henpwo/tq2e+ThibZhHYEorEfXivqFSS9KLlHH4pECy2FJ3KMr XQPV0OKQDmMItxfofgkSTNFYmyGQGIZNOcRq7y2h1ijNIQpsy5ys9IXJ0+hI jMpHKnx+uDqtCrQMEUbAOw9+l05Ojo+PtfbmUVTsXS6K1Xp3jePsGb0/gTrg uqQLY9zNS7h/DQIeNUFFrwjt5Ex6LgtXBKCvO9EwFpbs20PnMwsnmuUAnxl1 s3cgRF21mBJRw9aMV3Cs5cI8DTFObgqFShfUuZWbcwOURegUZuocJsi/qkrb xCpJzjE8G4ebiYom/doYZYBegxIwUIVkzkIu9p8v50DCEW3dn+zCvMfpBzOO HZj9vK4bPmZzTOkmqDmalYtllQWmOwX2JA517RphEoZvOxD6kcuetzRgnrYu IW01rWMGeg/X6Mca1nEklXmZrTvplU1skj9sE/th0G2bI1ZTgJzDm3CnRNyj WTH2RErwaO9x7pDARFfEpoLZsayYe5UiReYKxl6zgwFkleJUCkFrroWgcYZQ KbtVpB8v5FncVCVdFRjZo67SGWLkedjP0G+GSgnYeVrHZUL5DY/DHf6eYvD3 07fruTIkmFIlbJrVU7JN85LntS3lB+mOaLCE68Q1YrXb9qycrvHFURITlKJ2 rL6I7jNI1cv1B1/HIZ7940eT2ck+MiorrpVJdOugt6PDx286DR2S5JmhEbng +6mZr6+Os4d65Zxc4cX6TCwkdIENSNp2PSMdPeb2GHjnGtAI3mk4K7OXSxGQ kMGYjBBKkKPYlNQFfpMtgYTUSg8pGvC8ys9VA6ENBlUCA3KpKJJ0u3JpQXoF V+tmlKaJNvBRBbUNE26k0TLlDDwwwh6pcnwoVVzlQ9DocrK4yH5nOWdHUKnm ToOOwD8TYzjBFa3JrcEWgnIRKfDTiww1bZgKljkdJZMNzT9kFRQ+lMXdgVD4 FIMEnUmd5xifl5DOj8yee8cQAg0cDAfAOJb4BA6D1XhAsxmkeTPlUto9i+iy dRQyqDkQ3oYgRkuodRKihLtJKHjWlyUHBFeSrjMIbGBZpudrgA3MlEtMT+Ma jlHsHUXozooaQ/0QJZiRwKBbMup2wMj6ghrkWWDDadk0c9Cjp+8GFgpUYwur rJr14A2BfJELiBN3rrCX5RlSJQwCrQpQL4pQYtt6e1laTNDsk2k7JyduBybG yMUq5wQ6J6n44mipB/OJhpixdLJezfPe3QAxewffHHILQgxMMcky3Xp5ONmO 838oqtfXHNdKgEr73r44eLj34OHnz8Q3y/l7banIUesjaU6XRFA07SoyUsY4 I3E5HIsiUVDYYkka5mzeIc/kOxdaSbtSS860AKdS6BviAOslXckuqAKkPn58 A7CyNvAxUFAJC9f0jGUsvVQBC5hKcDEsBHPSs5dMZ6zl8TZ1Yl6KQq0cltQA TOyiIvKDZIUGHSaT01LLNnp+mB6eDaRmQC7haofPT14kekRIfIQUtXZkbXKN GfBFFetpolUJdUVSFACTDi/L6l0b39yiWn2I8fRFlsfLh8uLuh265Zmu/X8s T+vVb+GmuN+Sb9DcvSaBqWOxr+Ub4MfHQCKlxR1HQXWMsbqaaXW1asrzKltd YJKGDJEYGUNB9SJn5QCZKTooMHbVWSCoAeCmgbbQ/H1eERnHdizIrKYSCk8i 34zZFz/AOpSxPQorh6+HUrtBwk7h5W2vER0ewXQg/J+8PGZyH9JSHuzuPea0 FG6C6tQ/XaI0Hdaz+G1CEEbbaTYfku3nxDjfkcavbx2/PTna5jn2Ho3HaDit SfoF7jKjHi6JBbtTbGW0d4BkVBTg+ZLAJ1fwB6prmTzHEEZuooeZwDAhhdl6 jZuJ2JOd++gIIdJk4GZhJ6EkX34BbnwnX8cUzABaq/p5UfyckaBLggbZgWsR /VXmkNRSJBuox8FZwqfD8myoOqJU26AwvEQbN/CMy9JQq292LBi5ZLcPD4Lm 4mVZrkQHQf1GGg/WGCR+nlXWwMWO1iXUxFVIQXR5V4cyqEmBGDdbT4kuh17m 7bwLP/TpzxwdV0e+JHhzP8HGvUd63et6XaHtLXXZOmQaxPh05DoS38z1bzcW ukdiyJdlyk0LGyxYq7TTlJlOOd7fpE+5mmmoPcP9oSiI/iqsCm2yVhsv2AA4 oPOMzE4a4Ww95cM2OzdU89N90dbMSo5SHT5VutMM9u5KLH97hsr5tzj8hGR1 lkOvbvSisH7QmLMTSSZa86cXRU7cHWWx8zLDmO2QL0eJZsgksE7jkI20IbjU +JjR9igzv3Z5HwNfcEUKsMRdCBCFEo+dXqN3ohVr2+aQEjr3Lr+SPQIyJCQc oqmarlls2SY2FVWuNv0SbaycEUo3LTH5GPgbMrVR+qyt6tuCfSeUgbMdaL4L WUqTKNvlmiwTEqOx8VUI0k419dEUpKSV5GRM7rMkfWlUc+8iGVrnpSs1nFCO FCoWBRdXsWSdHWLvS3FuRY4lHCU8p5lKOSXtz0LLNGwwBhxwZnQvlcx9Fbxx i1iP8zSnRIEPmuCAZH1Ovob8Q8MtNDFdY5arYPIBn+eAZJwZSxplpAPGbHeB rU2BBA96Sw1rUSlxssxD6WnKkSmWZ6WUXmZaR/gWFukx7TQHcsMdlTDoGb5C XYwOHDFNa0jSCCR0ofcOH/8h3LFXnEWYTCLWSN7KOt3CW1Rva4PdEPSfN+sV uelJnESSwIQs6SGvLczrT0zjygYudrxFUr3KQ7OLTSF233BKkvpRbCk5dchc at5O8BQ1LC8y0ZUClW+jClVirQCpmjzWIaWRrLbUHpTAi8tHKP02ocuAtL6V aMonL4EU+KuWK5bGnltUXrbmWk9YRjxREA6HvMxOwinlXLFvlwjKqQNhyfps mH6U/G4NIhHZcJdawIhKb8TriKzMVBpEMAhWQAEvicV+7Dx+iBTgGQeYLBFv 5yGOYxAn7wWmlLjq41uqOkkZ8b78JlfqvFbJJAlZM9uShVmcL1leUKnaYDEH 6Myp42uPhCPnXOK+ZsBZZ2tl4AE3azGnCgd24ghoA5OaYkbWWqatXV5UKtxg MneoeotSnDStSgT1chbQhEGyaZ7tuxSVomQeB7PrIRhdfVsnxjm0lByl2IV7 FyfbtUAWF3Uv6iTEi2Aow8plSoo3EkMhKkxe4MaIyQ8a4VGYNYnujEQMrJcY QyAd4dyqVIhhNd9yJp3IGLqJpQ0G13DDr66Qi8EsJYB1kJAwD6hYTKlEHVvP QGdeMty6nB6vFkxTZeeanQ0bK1aFmFJlWjYcROCPYC63PmmHkIh8a0ERF/ma bXY1EiBqGNCQQEKBTKym86my8IsCMYPc5Hw8ohFjXjv7uGaU64su43AwSlHk yDExZmxoIXEYzgBgW7L9kAx/MC4MpZFL1gh7kGBQkWTRS0NvFmBp4RrjRNuk efVF4rUgURbn3LbbcW0xSeLzyPdS9koem+SYMHqgjXVK6ook8rZAh8slzxyZ xqJtDNRDhAbY0pXPUYshOtzZ+JAJtnDd75ChiYF6+hfo/YegbGgB8iK8x6+p OuUSPM189HpygtUQQG66BNjAr0CvPgAHGJBmtK5ZKFUKVl/VsFUgoYfPjutt 3gbhaM1WK0mPDXmVAvMkDyot2tzUdKmaco1MaiqdpTEaCC4vmvCoGQWWRNJ4 zMTvAcnbRUFni7QNZOd5ecWWIVbJpPCR8Wp2zaO1WQ9+k1brpjH9WhTEombf KhrhsA6QFBjaub8XBSU+3BbLMt02vsLIsbHQe8NVOgpqIQAnACJHokeAnd/J JmL9SyQEMQKxZhPrMeI+2O7x4AkaNs1AFbk1hpQ7BId5wX1UuKY1d67HEbaA NIYaNjDu1YKDAradLDSME6VdwSfNvQPapM209aSpFS9NXGJH77xWDkRmQXem wspRvmTkJKCZ6UPlANjmIzJlsiHk0aM9t+k6/fHZEZpWslWNlfs1ygMhfVJl mGiezS1CQwJSAePrYDxjwovD5H6YcG9wvOODkyO1xDwYo1jyYo2sJIlsq7W6 Ncn4J3xK2mPyNN4sKi5eN6faa81qZUhqpodLhJGHYtGRD5z6RNbEw4hj8BQu ZkopfHaKarrlZRuf4WEJncR/LJQ5CA0N4AkMUUunDIr8CibmoF3b4EIj3lOj W3gZ04sncPUGKeiCCwBkoyZPCoaYw9oqbDV9xdK5s5vnH2C3qpI4c/raKo00 17lAMdlHorxImRQse/zw8X3AMk0Mj83x5JIzLF2g0RCYPxDR1dpaz4QQ56k/ WW5WXWMX80a6mLtKqhSuRa9Qe/sVZrUuSSDyVmci/M+K6l36HpD9h/U5QO01 rA0kkjx9Wy7K9BUICkv49M0CMPw1Fvg9A45WXmQY6PG0XE+zWVaALHVcLJCJ vsgrOCd4fA7yKQY7A03AeoBUJOJ3JZZ9eQHPX6wr6bzyNL+YItcHAvkuu8oE y7BmXzs+OGopa7T5XDUFEfbMGTCpRWZ8LdrChJt7w1XYwvG3UToWGyD8Viia IJZQLeA6uCw0qi01fhRFr5jhFvUNDpSlJZk/DLCAcv6oCPCqBHHvysocPB7v PvQc4P7okXqS7JgUdxDCeCG4VrF1YBAjGa+UCkcotxDhj+BJS30hUqsCRXZ+ JZIFVrDhFrb0sTii+oak0ezt86pEPZfi/V7D+wHJtbaNL1IkZ2nbs/BBWida R+js5PZH5Y2shi/dDasGszxnp6dEjJuHhvyIar+5CpRSibfFFBCj7VTT/PhR j1Yr5IT6WbDw6iqUy8aK4bLIIbYCQ75i1mL4MqDRxiPYDNmN0ddOcHgyuj8C 8Udjme/QMOp/uENKKYbrwhl9Sv9A+BPl5diqUAuNfz6lx5HTD1N3Pu23E372 ux9d9+X+J2quO96BQzs/Z+y1/KAu+vA6/ox480zQ5i+4jo/73/RBX/N0tLae OrY2Ah+zc76X4pkl3dfn8GZZ7adHczKtkb0a7nRrCRIWFSJmtC8uGddhnHAl hOtqvRqdGbmEr8TkxBG1so+HWNlZMI5Zq7NC3x+eYl4EWnKtdTVLDjqV0Coy jZkZO2Lko/SGGym6Md/Ib3WQP/AE9bcBXy0CqR+RuYCCRGC1QMI3zBVuaqSQ bMPZLHpNosZm6ORkxJHF4O9t/O5gMOfB7V+Ln/sdhDUE3ZFR0x34cQjcwdDw zng4fqC/r5eZMqeebLwIqQU0EVK3oY/OrL83ErOE2j6xOh3js7AzLpsum5KQ OX9oLsWkhxduOebXYozbox6mIuF9bIDQa3Q7nsKs8/7DiNrekSq+5JO4E1YN r90Js/JD9Z1u8SKyV705OiFBkCZsc+XW/WmPeesL1MeFxHYd+BAxLVDamg4n SiNOdNNaeDLPn66ZA+VxjBNaYckdCm7FEFbq8/3AjFBwNqAWyiFQl3FmSO1F wK1oM6JP6TPX7v5WP58A0RSlw+3q5VO3IAA3//S9QnxO+rPvxItzTQXkE+00 WGkJs3sSlkjONQmNxqH0BnySasI8DJwC71AnHHcmJEtr+OSfymLpzaXXl5Kj V5xtNoBUJ9ztTBiVYv0kSdMbajYvLUCb7AgySKdsrZ9wrzMhljhznzzXWpno RlN3l3jguRJcB2lcYb7uDu93JsT2D/4TQ+V2k4wNP59cU4yeCR90JoxW/cl7 yKzlBqg6Iy737WMN4gnF7dyZ8GFnQgyAd5+cSAUkCowXVQlJsXY85BBm67Vh E8LjvTt81JlQM1Dkk4n5IlxEhhiCtvJ6+x4K/Vv1dhuk5tloTfi4u8PQJYDJ BocZuCnS9hx9Z+gbwvgJn3QmpED18Ik0KNebaEHuG39kQhym7wzHO9Gz7brY 19/D6ybUK9iZcBw9C58+/5cj/8lzH1npOqiKZ4ncd30TwjB9SPN9a8IfvUiV 8hlSjQS2JZ+J+NIu6BtP2LNrL4vFLM+ksTb/9DpF+v/1dn2vbRxB+P3+isN5 qUESdpxCAn1J7Zqa0lgQpVAomIskh2vvJKOTG4s2/3t3vvmxs3cr2djQPIRw 0e3t7e3Ozs583zfmOA2erBU55WX+DweKC2IYxXePqzI4fI8dK5h37tMz5/T6 ck/xl9ErHbmyQUR6FdeJp8DRe2iZU2zFCfMfTcryU7d0vr+VL6ijDJ9TjRzs ETmv0QAZ0Wc8NAAWfOsdo0xaUKM+A6dOH+S8Ol816KvPkRpZxZEnvUwnlQTj qlg7/7+/WJn2mksaILr5FkdBNcm5SrVSxtWHE4B77ruR4UQaNsxx6J338aA5 OOHjFX68gdk6G7/+/g1RfuZ1WzXHfDiFnJko7bkDjwJfgcOJ/dMxPrG6STa6 AkSyFojSmawBN9kpABfzMrLq7bCy5wNOyAPFxMi4nWrQlhU+3t4/ia9pTuYe J/IJvmX6Ew6WnOA5UwB/ZsuHbfL4qeGB4OrkeuhmADV4is82tJ0HDGhipQcN wtXv2/r468ueuQck5UAPxfRmpuLQ9g7WdlI8S1cMY87ofVDkmBhvUUt91SOM dnScDmPPotrFq1JJS3PNmKah/H9e0f037d12fvdNjqOkkR5c2geyMVcKlyKp zT5rhELbMY3UazhmEUa8foBa5OToohN0hZSarrpwvmJao6GQbS15JC8Kk2ei pA4JBUQKSWdW/bSFPjr8m5Mc716/OyOra9iKz0tWQZY1t3BjpzFXxKQoYNlA yVjTIciVW4ZXOPp7uEQs0z/VWx2otrCPiWwfcEI34cvcUNLmhlKyYQwEutul FifzCHpP7dtIAu9klD7vyhUHFAFNriOfu944QUxHOYsZ7bDHvQ8nkj8JImKj UzZu/JUwW8YCAvJwKvlD05hfnERb57Q/3hlGNFZ9o9DhmBVdJL+NQg/LLo5Q w+F/A9JEThJrT9QsOrozGeiV8B0YUhce6ai9NUOXWT2HrD+1DjVgdWAyysfI zNHLrDeFuKNte78y5H9LT5cFIkBMhZoi4g3Kh7DurYjkYlL8CMjKYCEoU4pa OIM4rNTgkm2+KpLnY3SQj1+2hBXIUXEAUK7uttYrykmg5IZssbzK0qmFnUdD 0gNzPTuf9i/5Y1zGwudjG/kN57E9CIGLy/umGV8Q/+gh7chu2fWePbzU7xuF NxQMcL2pOR38/NaY9aB+UndXzUUk9Y1WQoyt/fFDeXpy8lYrJG5YpMm3dmFS Drf+qP6vEAsbF0EKRmtwsde3adRAAIKsYd+BWht7vQi+xDmr/m4YW7veMCoG G5YZhfy4rdYHhg2tfUzDEp3dChAUBe8o2ZBeml582tPaJTTsZRH4jjyrb+fD hbW3tcdnyE/nHywl+FjfHm9NtCiCNScB/sOtOTx+xlZg3IJToOEaiZaSWcsM 0lP6BoY3TWmVBNu95E0vN9WXSPo+/KZPmG+/f6BKCeuFx7Q+u7Wfq+aW8Uge FPm81kjtL+MYqHfpHRLnHRiai/xDAikwPrwRvnp0qSQhGVwYrbRsjgicxPC3 c0ZGCa58pBOXDMffa4qqWbk/ko+jqxVXgDAuLVhXSnGWDHfU91CtoUKZ6ZiR zutjYSD2H1p6X1LfEgwSgsIiqpEhbx7ax/RjsJeWuz7u72r797HDW1f2Ovax 35IRHPQhvySy19kS9Mb2Ra1h7fqP8qLWsI9tlsadfWJra630l7YWTnIExBP4 xOAukKvY5Z0Z8D1cvyUCSro9+tU2mP0xs9n35Pcsu1nKXBAvkCCCcyXbtIS4 iye6nngEqKJ4nKCpDMgMV9JHzSmxBT8YMmNyqHQugG3InmhZRAZguy8h0GkW f+Gx3rFGJDICx04rCujHWFw89MfRE0yPStQbRf7BTYVCuBj6quEAchUpPF64 BhH/tp9u/S5G8Y9HpbAz3XuxTNMipi5ndUugz/B9r5M6qCaDxcBaKI+a4Jjr sAILyYSy6A3TWZncjljV1fhiUhERd1zP55sv4wjOi+3QufQjzQY3Wou1U3qE QAyOKAyCBpiU53zhdVa8iMggiFSWv9IhpUiYzoyU7ZL5kjuOsI5VFxmuzc6U cIr1/ZbZAzJ78JVFBcgEe+jsQb5Jdb+o1/gMNNJrEb8j0DVepUtZrXGs1U9i MocVoZIKgDyTfcUum4KFa8QNMDDL9V9LLhiBtiAGaRJS8fjZp7CEO8NLbaPg KBttrL14E+902LdYJSV0gyjhfvg5aK4hAQG84psMV4eIXkA/KoYv8iR4954A 73fbtezdxqvVmrDUPIECZK+smMs6ozCCX4ulS/Sy8YElFPHZYNFDs4viiGSm yq9VvT2yxRH7Snc4Hr5NuHrFUgrulF64yNZ/omEbQIioAQA=[rfced] Terminology a) Throughout the text, the following terminology appears to be used inconsistently. Please review these occurrences and let us know if/how they may be made consistent. CLOSED state vs. CLOSE state vs. CLOSING state Client and Server vs. client and server (as well as 'the client and the server') Congestion Control procedure vs. congestion control scheme [Note: Should the case be made the same for these terms?] "Fast Close" vs. fast close [Note: Should the first mention in quotes be "fast close" for consistency?] Feature number 10 vs. feature number 10 Length vs. length handshake procedure/process vs. handshaking procedure/process Key Type vs. Key types vs. key type Multipath Capability vs. multipath capability Multipath feature vs. multipath feature Multipath option vs. multipath option vs. MP option Multipath Capable Feature vs. Multipath Capable feature vs. MP-Capable feature vs. MP_CAPABLE feature Nonce vs. nonce Plain Text Key (Table 5) vs. Plain text key (Table 9) Reset Code vs. reset code Remove Address vs. Remove address (Tables 3 and 8) SHA256 vs. SHA-256 [Note: "SHA256" is consistent in this document; however, "SHA-256" is hyphenated in the running text and some descriptions in RFC 6234; are any updates needed in this document for consistency with that RFC?] b) FYI: We updated the following terms to the form on the right for consistency: address ID -> Address ID age -> Age Change request -> change request (per all other RFCs) DCCP Connections -> DCCP connections four-way -> 4-way host A -> Host A IP Address -> IP address key data -> Key Data maximum segment lifetime -> Maximum Segment Lifetime multi-path -> multipath UDP Encapsulation -> UDP encapsulation (per RFC 6773) NAT Traversal -> NAT traversal (per RFC 6773) --> <!-- [rfced] Abbreviations a) FYI - We have added expansions for the following abbreviations per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each expansion in the document carefully to ensure correctness. command-line interface (CLI) congestion window (CWND) Path MTU (PMTU) pebibytes (PiBs) Stream Control Transmission Protocol (SCTP) b) We note the following variations. Do you prefer the expansion to contain the hyphen or no hyphen? Multipath-DCCP (MP-DCCP) vs. Multipath DCCP (MP-DCCP) c) As recommended in the Web Portion of the Style Guide <https://www.rfc-editor.org/styleguide/part2/#exp_abbrev>, once an abbreviation is introduced, the abbreviated form should be used thereafter. Please consider if you would like to apply this style for the following terms (i.e., replace the expansion with the abbreviated form on the right): Connection Identifier -> CI Multipath DCCP -> MP-DCCP --> <!-- [rfced] Please review the "Inclusive Language" portion of the online Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> and let us know if any changes are needed. Updates of this nature typically result in more precise language, which is helpful for readers. For example, please consider whether "traditionally" should be updated for clarity. While the NIST website <https://web.archive.org/web/20250214092458/https://www.nist.gov/nist-research-library/ nist-technical-series-publications-author-instructions#table1> indicates that this term is potentially biased, it is also ambiguous. "Tradition" is a subjective term, as it is not the same for everyone. --> </rfc>