rfc9897.original.xml   rfc9897.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version='1.0' encoding='UTF-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" ipr="trust200902" do
cName="draft-ietf-tsvwg-multipath-dccp-24" category="std" consensus="true" submi <!DOCTYPE rfc [
ssionType="IETF" tocInclude="true" sortRefs="true" symRefs="true" prepTime="2025 <!ENTITY nbsp "&#160;">
-04-29T07:56:08" indexInclude="true" scripts="Common,Latin" tocDepth="3"> <!ENTITY zwsp "&#8203;">
<!-- xml2rfc v2v3 conversion 3.28.1 --> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;">
]>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" ipr="trust200902" do
cName="draft-ietf-tsvwg-multipath-dccp-24" number="9897" updates="" obsoletes=""
category="std" consensus="true" submissionType="IETF" tocInclude="true" sortRef
s="true" symRefs="true" tocDepth="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> <front>
<title abbrev="Multipath DCCP">DCCP Extensions for Multipath Operation with <title abbrev="Multipath DCCP">Datagram Congestion Control Protocol (DCCP) E
Multiple Addresses</title> xtensions for Multipath Operation with Multiple Addresses</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-tsvwg-multipath-dccp-24" <seriesInfo name="RFC" value="9897"/>
stream="IETF"/>
<author initials="M." surname="Amend" fullname="Markus Amend" role="editor"> <author initials="M." surname="Amend" fullname="Markus Amend" role="editor">
<organization abbrev="DT" showOnFrontPage="true">Deutsche Telekom</organiz ation> <organization abbrev="DT">Deutsche Telekom</organization>
<address> <address>
<postal> <postal>
<street>Deutsche-Telekom-Allee 9</street> <street>Deutsche-Telekom-Allee 9</street>
<city>Darmstadt</city> <city>Darmstadt</city>
<code>64295</code> <code>64295</code>
<country>Germany</country> <country>Germany</country>
</postal> </postal>
<email>Markus.Amend@telekom.de</email> <email>Markus.Amend@telekom.de</email>
</address> </address>
</author> </author>
<author initials="A." surname="Brunstrom" fullname="Anna Brunstrom"> <author initials="A." surname="Brunstrom" fullname="Anna Brunstrom">
<organization showOnFrontPage="true">Karlstad University</organization> <organization>Karlstad University</organization>
<address> <address>
<postal> <postal>
<street>Universitetsgatan 2</street> <street>Universitetsgatan 2</street>
<city>Karlstad</city> <city>Karlstad</city>
<code>651 88</code> <code>651 88</code>
<country>Sweden</country> <country>Sweden</country>
</postal> </postal>
<email>anna.brunstrom@kau.se</email> <email>anna.brunstrom@kau.se</email>
</address> </address>
</author> </author>
<author initials="A." surname="Kassler" fullname="Andreas Kassler"> <author initials="A." surname="Kassler" fullname="Andreas Kassler">
<organization showOnFrontPage="true">Karlstad University</organization> <organization>Karlstad University</organization>
<address> <address>
<postal> <postal>
<street>Universitetsgatan 2</street> <street>Universitetsgatan 2</street>
<city>Karlstad</city> <city>Karlstad</city>
<code>651 88</code> <code>651 88</code>
<country>Sweden</country> <country>Sweden</country>
</postal> </postal>
<email>andreas.kassler@kau.se</email> <email>andreas.kassler@kau.se</email>
</address> </address>
</author> </author>
<author initials="V." surname="Rakocevic" fullname="Veselin Rakocevic"> <author initials="V." surname="Rakocevic" fullname="Veselin Rakocevic">
<organization showOnFrontPage="true">City, University of London</organizat ion> <organization>City, University of London</organization>
<address> <address>
<postal> <postal>
<street>Northampton Square</street> <street>Northampton Square</street>
<city>London</city> <city>London</city>
<country>United Kingdom</country> <country>United Kingdom</country>
</postal> </postal>
<email>veselin.rakocevic.1@city.ac.uk</email> <email>veselin.rakocevic.1@city.ac.uk</email>
</address> </address>
</author> </author>
<author initials="S." surname="Johnson" fullname="Stephen Johnson"> <author initials="S." surname="Johnson" fullname="Stephen Johnson">
<organization showOnFrontPage="true">BT</organization> <organization>BT</organization>
<address> <address>
<postal> <postal>
<street>Adastral Park</street> <street>Adastral Park</street>
<city>Martlesham Heath</city> <city>Martlesham Heath</city>
<code>IP5 3RE</code> <code>IP5 3RE</code>
<country>United Kingdom</country> <country>United Kingdom</country>
</postal> </postal>
<email>stephen.h.johnson@bt.com</email> <email>stephen.h.johnson@bt.com</email>
</address> </address>
</author> </author>
<date month="04" year="2025" day="29"/> <date month="October" year="2025"/>
<area>transport</area>
<workgroup>Transport Area Working Group</workgroup> <area>WIT</area>
<keyword>Internet-Draft</keyword> <workgroup>tsvwg</workgroup>
<abstract pn="section-abstract">
<t indent="0" pn="section-abstract-1">Datagram Congestion Control Protocol <!-- [rfced] Please insert any keywords (beyond those that appear in
(DCCP) communications, as defined in RFC 4340, are inherently restricted to a s the title) for use on https://www.rfc-editor.org/search. -->
ingle path per connection, despite the availability of multiple network paths be
tween peers. The ability to utilize multiple paths simultaneously for a DCCP ses <abstract>
sion can enhance network resource utilization, improve throughput, and increase <t>Datagram Congestion Control Protocol (DCCP) communications, as defined
resilience to network failures, ultimately enhancing the user experience.</t> in RFC 4340, are inherently restricted to a single path per connection, despite
<t indent="0" pn="section-abstract-2">Use cases for Multipath DCCP (MP-DCC the availability of multiple network paths between peers. The ability to utilize
P) include mobile devices (e.g., handsets, vehicles) and residential home gatewa multiple paths simultaneously for a DCCP session can enhance network resource u
ys that maintain simultaneous connections to distinct network types, such as cel tilization, improve throughput, and increase resilience to network failures, ult
lular and Wireless Local Area Networks (WLANs) or cellular and fixed access netw imately enhancing the user experience.</t>
orks. Compared to existing multipath transport protocols, such as Multipath TCP <t>Use cases for Multipath DCCP (MP-DCCP) include mobile devices (e.g., ha
(MPTCP), MP-DCCP is particularly suited for latency-sensitive applications with ndsets and vehicles) and residential home gateways that maintain simultaneous co
varying requirements for reliability and in-order delivery.</t> nnections to distinct network types such as cellular and Wireless Local Area Net
<t indent="0" pn="section-abstract-3">This document specifies a set of pro works (WLANs) or cellular and fixed access networks. Compared to existing multip
tocol extensions to DCCP that enable multipath operations. These extensions main ath transport protocols, such as Multipath TCP (MPTCP), MP-DCCP is particularly
tain the same service model as DCCP while introducing mechanisms to establish an suited for latency-sensitive applications with varying requirements for reliabil
d utilize multiple concurrent DCCP flows across different network paths.</t> ity and in-order delivery.</t>
<t>This document specifies a set of protocol extensions to DCCP that enabl
e 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> </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="excl
ude" 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" p
n="section-toc.1">
<name slugifiedName="name-table-of-contents">Table of Contents</name>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="section-to
c.1-1">
<li pn="section-toc.1-1.1">
<t indent="0" pn="section-toc.1-1.1.1"><xref derivedContent="1" form
at="counter" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-introduction">Introduction</xref><
/t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-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-mu
ltipath-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-te
rminology">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-re
quirements-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" form
at="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-operation-overview">Operation Over
view</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-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 derived
Content="" format="title" sectionFormat="of" target="name-mp-dccp-concept">MP-DC
CP 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" form
at="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-mp-dccp-protocol">MP-DCCP Protocol
</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-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 derived
Content="" format="title" sectionFormat="of" target="name-multipath-capable-feat
ure">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 derived
Content="" format="title" sectionFormat="of" target="name-multipath-option">Mult
ipath Option</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-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 derived
Content="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 derived
Content="3.2.2" format="counter" sectionFormat="of" target="section-3.2.2"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-mp_join">M
P_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 derived
Content="3.2.3" format="counter" sectionFormat="of" target="section-3.2.3"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-mp_fast_cl
ose">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 derived
Content="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 derived
Content="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 derived
Content="3.2.6" format="counter" sectionFormat="of" target="section-3.2.6"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-mp_hmac">M
P_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 derived
Content="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 derived
Content="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 derived
Content="3.2.9" format="counter" sectionFormat="of" target="section-3.2.9"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-mp_removea
ddr">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 derive
dContent="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 derive
dContent="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 derive
dContent="3.2.12" format="counter" sectionFormat="of" target="section-3.2.12"/>.
 <xref derivedContent="" format="title" sectionFormat="of" target="name-experime
ntal-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 derived
Content="" format="title" sectionFormat="of" target="name-mp-dccp-handshaking-pr
ocedu">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 derived
Content="" format="title" sectionFormat="of" target="name-address-knowledge-exch
ange">Address knowledge exchange</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-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 derived
Content="3.4.1" format="counter" sectionFormat="of" target="section-3.4.1"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-advertisin
g-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 derived
Content="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 derived
Content="" format="title" sectionFormat="of" target="name-closing-an-mp-dccp-con
necti">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 derived
Content="" format="title" sectionFormat="of" target="name-fallback">Fallback</xr
ef></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 derived
Content="" format="title" sectionFormat="of" target="name-state-diagram">State D
iagram</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 derived
Content="" format="title" sectionFormat="of" target="name-congestion-control-con
sider">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 derived
Content="" format="title" sectionFormat="of" target="name-maximum-packet-size-co
nside">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 deriv
edContent="" format="title" sectionFormat="of" target="name-maximum-number-of-su
bflows-">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 deriv
edContent="" format="title" sectionFormat="of" target="name-path-usage-strategie
s">Path usage strategies</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-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 derive
dContent="3.11.1" format="counter" sectionFormat="of" target="section-3.11.1"/>.
  <xref derivedContent="" format="title" sectionFormat="of" target="name-path-mo
bility">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 derive
dContent="3.11.2" format="counter" sectionFormat="of" target="section-3.11.2"/>.
  <xref derivedContent="" format="title" sectionFormat="of" target="name-concurr
ent-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" form
at="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" f
ormat="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" form
at="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-interactions-with-middlebox">Inter
actions 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" form
at="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-implementation">Implementation</xr
ef></t>
</li>
<li pn="section-toc.1-1.7">
<t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" form
at="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" f
ormat="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" form
at="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-iana-considerations">IANA Consider
ations</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-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 derived
Content="" 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 derived
Content="" format="title" sectionFormat="of" target="name-new-mp-dccp-version-re
gistr">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 derived
Content="" format="title" sectionFormat="of" target="name-new-multipath-option-a
nd-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 derived
Content="" format="title" sectionFormat="of" target="name-new-dccp-reset-code">N
ew 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 derived
Content="" 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" form
at="counter" sectionFormat="of" target="section-9"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-references">References</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-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 derived
Content="" 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 derived
Content="" 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="Append
ix A" format="default" sectionFormat="of" target="section-appendix.a"/>.  <xref
derivedContent="" format="title" sectionFormat="of" target="name-differences-fro
m-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="" form
at="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="
" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Add
resses</xref></t>
</li>
</ul>
</section>
</toc>
</front> </front>
<middle> <middle>
<section anchor="intro" numbered="true" removeInRFC="false" toc="include" pn <section anchor="intro">
="section-1"> <name>Introduction</name>
<name slugifiedName="name-introduction">Introduction</name> <t>The Datagram Congestion Control Protocol (DCCP) <xref target="RFC4340"/
<t indent="0" pn="section-1-1">Datagram Congestion Control Protocol (DCCP) >
<xref target="RFC4340" format="default" sectionFormat="of" derivedContent="RFC4 is a transport protocol that provides bidirectional unicast connections
340"/> is a of congestion-controlled unreliable datagrams. DCCP communications are
transport protocol that provides bidirectional unicast connections of restricted to one single path. Other fundamentals of the DCCP protocol
congestion-controlled unreliable datagrams. DCCP communications are are summarized in <xref target="RFC4340" sectionFormat="of"
restricted to one single path. Other fundamentals of the DCCP protocol section="1"/> such as the reliable handshake process in <xref
are summarized in section 1 of <xref target="RFC4340" format="default" sectionFo target="RFC4340" sectionFormat="of" section="4.7"/> and the reliable
rmat="of" derivedContent="RFC4340"/>, such as the reliable negotiation of features in <xref target="RFC4340"
handshake process in section 4.7 and the reliable negotiation of features sectionFormat="of" section="4.5"/>. These are an important basis for
in section 4.5. These are an important basis for this document. This also this document.
applies to the DCCP sequencing scheme, which is packet-based (section 4.2),
and the principles for loss and retransmission of features as described in <!--[rfced] Please clarify what "This" refers to in the following
more detail in section 6.6.3. sentence - is it "These fundamentals"?
This document specifies a set of protocol changes that add multipath
support to DCCP; specifically, support for signaling and setting up Current:
multiple paths (a.k.a, "subflows"), managing these subflows, reordering of This also applies to the DCCP sequencing scheme, which is
data, and termination of sessions.</t> packet-based (Section 4.2 of [RFC4340]) and the principles for loss
<t indent="0" pn="section-1-2">Multipath DCCP (MP-DCCP) and retransmission of features as described in more detail in
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 to DCCP, specifically
support for signaling and setting up multiple paths (a.k.a., "subflows"),
managing these subflows, the reordering of data, and the termination of
sessions.</t>
<t>Multipath DCCP (MP-DCCP)
enables a DCCP connection to simultaneously establish a flow across multiple pat hs. This can be beneficial to applications that transfer enables a DCCP connection to simultaneously establish a flow across multiple pat hs. This can be beneficial to applications that transfer
large amounts of data, by utilizing the capacity/connectivity offered by large amounts of data, by utilizing the capacity/connectivity offered by
multiple paths. In addition, the multipath extensions enable to tradeoff timelin multiple paths. In addition, the multipath extensions enable the trade-off of ti
ess and reliability, meliness and reliability, which is important for low-latency applications that d
which is important for low-latency applications that do not require o not require
guaranteed delivery services, such as Audio/Video streaming.</t> guaranteed delivery services such as Audio/Video streaming.</t>
<t indent="0" pn="section-1-3">In addition to the integration into DCCP se
rvices, implementers or future specification could choose MP-DCCP for other use <!--[rfced] Please clarify the latter part of this sentence,
cases like specifically "between" and the slash ("/"). Is the intended
3GPP 5G multi-access solutions (e.g., Access Traffic Steering, Switching, and Sp meaning that hybrid access networks combine access between the
litting (ATSSS) specified in <xref target="TS23.501" format="default" sectionFor user equipment "or" residential gateway "and" an operator network
mat="of" derivedContent="TS23.501"/>) or hybrid access networks that either comb (option A) or is it between the user equipment "and" a
ine a 3GPP and a non-3GPP access or a fixed and cellular access between user-equ residential gateway within an operator network (option B)?
ipment/residential gateway and operator network. MP-DCCP can be used in these sc
enarios for load balancing, seamless session handover and bandwidth aggregation Original:
when non-DCCP traffic like IP, UDP or TCP is encapsulated into MP-DCCP. In addition to the integration into DCCP services, implementers or
More details on potential use cases for MP-DCCP are provided in <xref target="mu future specification could choose MP-DCCP for other use cases like
ltipath-dccp.org" format="default" sectionFormat="of" derivedContent="multipath- 3GPP 5G multi-access solutions (e.g., Access Traffic Steering,
dccp.org"/>, <xref target="IETF105.Slides" format="default" sectionFormat="of" d Switching, and Splitting (ATSSS) specified in [TS23.501]) or hybrid
erivedContent="IETF105.Slides"/>, and <xref target="MP-DCCP.Paper" format="defau access networks that either combine a 3GPP and a non-3GPP access or a
lt" sectionFormat="of" derivedContent="MP-DCCP.Paper"/>. fixed and cellular access between user-equipment/residential gateway
All these use cases profit from an Open Source Linux reference implementation pr and operator network.
ovided under <xref target="multipath-dccp.org" format="default" sectionFormat="o
f" derivedContent="multipath-dccp.org"/>.</t> Perhaps A:
<t indent="0" pn="section-1-4">The encapsulation of non-DCCP traffic (e.g. In addition to the integration into DCCP services, implementers or
, UDP or IP) in MP-DCCP to enable the above-mentioned use cases is not considere future specifications could choose MP-DCCP for other use cases such
d in this specification. as 3GPP 5G multi-access solutions (e.g., Access Traffic Steering,
Also out of scope is the encapsulation of DCCP traffic in UDP to pass middleboxe Switching, and Splitting (ATSSS) as specified in [TS23.501]) or
s (e.g., NATs, firewalls, proxies, intrusion detection systems (IDSs), etc) tha hybrid access networks that combine either 3GPP and non-3GPP access
t do not support DCCP. A possible method is defined in <xref target="RFC6773" fo or fixed and cellular access between the user equipment or
rmat="default" sectionFormat="of" derivedContent="RFC6773"/> or is considered in residential gateway and an operator network.
<xref target="I-D.amend-tsvwg-dccp-udp-header-conversion" format="default" sect
ionFormat="of" derivedContent="I-D.amend-tsvwg-dccp-udp-header-conversion"/> to or
achieve the same with less overhead.</t> Perhaps B:
<t indent="0" pn="section-1-5">MP-DCCP is based exclusively on the lean co In addition to the integration into DCCP services, implementers or
ncept of DCCP. For traffic that is already encrypted or does not need encryption future specifications could choose MP-DCCP for other use cases such
, MP-DCCP is an efficient choice as it does not apply its own encryption mechani as 3GPP 5G multi-access solutions (e.g., Access Traffic Steering,
sms. Also, the procedures defined by MP-DCCP, which allow subsequent reordering Switching, and Splitting (ATSSS) as specified in [TS23.501]) or
of traffic and efficient traffic scheduling, improve performance, as shown in <x hybrid access networks that combine either 3GPP and non-3GPP access
ref target="MP-DCCP.Paper" format="default" sectionFormat="of" derivedContent="M or fixed and cellular access between the user equipment and
P-DCCP.Paper"/>, and take into account the interaction of the protocol with the residential gateway within an operator network.
further elements required for multi-path transport.</t> -->
<section anchor="mpdccp_network_stack" numbered="true" removeInRFC="false"
toc="include" pn="section-1.1"> <t>In addition to the integration into DCCP services, implementers or futu
<name slugifiedName="name-multipath-dccp-in-the-netwo">Multipath DCCP in re specification could choose MP-DCCP for other use cases like
the Networking Stack</name> 3GPP 5G multi-access solutions (e.g., Access Traffic Steering, Switching, and Sp
<t indent="0" pn="section-1.1-1">MP-DCCP provides a set of features to D litting (ATSSS) specified in <xref target="TS23.501"/>) or hybrid access network
CCP; <xref target="ref-comparison-of-standard-dccp-and-mp-dccp-protocol-stacks" s that either combine a 3GPP and a non-3GPP access or a fixed and cellular acces
format="default" sectionFormat="of" derivedContent="Figure 1"/> illustrates this s between user-equipment/residential gateway and operator network. MP-DCCP can b
layering. e used in these scenarios for load balancing, seamless session handover, and ban
dwidth aggregation when non-DCCP traffic such as IP, UDP, or TCP is encapsulated
into MP-DCCP. More details on potential use cases for MP-DCCP are provided in <
xref target="MP-DCCP.Site"/>, <xref target="IETF105.Slides"/>, and <xref target=
"MP-DCCP.Paper"/>.
All of these use cases profit from an Open Source Linux reference implementation
provided under <xref target="MP-DCCP.Site"/>.</t>
<t>The encapsulation of non-DCCP traffic (e.g., UDP or IP) in MP-DCCP to e
nable 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 middleboxe
s (e.g., NATs, firewalls, proxies, intrusion detection systems (IDSs), etc.) tha
t do not support DCCP. However, a possible method is defined in <xref target="RF
C6773"/> and considered in <xref target="I-D.amend-tsvwg-dccp-udp-header-convers
ion"/> to achieve the same with less overhead.</t>
<t>MP-DCCP is based exclusively on the lean concept of DCCP. For traffic t
hat is already encrypted or does not need encryption, MP-DCCP is an efficient ch
oice as it does not apply its own encryption mechanisms. Also, the procedures de
fined by MP-DCCP, which allow subsequent reordering of traffic and efficient tra
ffic scheduling, improve performance, as shown in <xref target="MP-DCCP.Paper"/>
, and take into account the interaction of the protocol with the further element
s required for multipath transport.</t>
<section anchor="mpdccp_network_stack">
<name>Multipath DCCP in the Networking Stack</name>
<t>MP-DCCP provides a set of features to DCCP; <xref target="ref-compari
son-of-standard-dccp-and-mp-dccp-protocol-stacks"/> illustrates this layering.
MP-DCCP is MP-DCCP is
designed to be used by applications in the same way as DCCP with no designed to be used by applications in the same way as DCCP with no
changes to the application itself.</t> changes to the application itself.</t>
<figure anchor="ref-comparison-of-standard-dccp-and-mp-dccp-protocol-sta <figure anchor="ref-comparison-of-standard-dccp-and-mp-dccp-protocol-sta
cks" align="left" suppress-title="false" pn="figure-1"> cks">
<name slugifiedName="name-comparison-of-standard-dccp">Comparison of s <name>Comparison of Standard DCCP and MP-DCCP Protocol Stacks</name>
tandard DCCP and MP-DCCP protocol stacks</name> <artwork><![CDATA[
<artwork align="left" pn="section-1.1-2.1"><![CDATA[
+-------------------------------+ +-------------------------------+
| Application | | Application |
+---------------+ +-------------------------------+ +---------------+ +-------------------------------+
| Application | | MP-DCCP | | Application | | MP-DCCP |
+---------------+ + - - - - - - - + - - - - - - - + +---------------+ + - - - - - - - + - - - - - - - +
| DCCP | |Subflow (DCCP) |Subflow (DCCP) | | DCCP | |Subflow (DCCP) |Subflow (DCCP) |
+---------------+ +-------------------------------+ +---------------+ +-------------------------------+
| IP | | IP | IP | | IP | | IP | IP |
+---------------+ +-------------------------------+ +---------------+ +-------------------------------+]]></artwork>
]]></artwork>
</figure> </figure>
<t indent="0" pn="section-1.1-3">A CLI at the endpoint (or another metho ---------------+ <span class="insert">+------------------------------
d) could be used to configure and manage the DCCP Connections. This could be ext -+]]&gt;&lt;/artwork&gt;</span>
ended to also support MP-DCCP, but this specification does not define this.</t> <t>A command-line interface (CLI) at the endpoint (or another method) co
uld be used to configure and manage the DCCP connections. This could be extended
to also support MP-DCCP, but this specification does not define it.</t>
</section> </section>
<section anchor="terminology" numbered="true" removeInRFC="false" toc="inc <section anchor="terminology">
lude" pn="section-1.2"> <name>Terminology</name>
<name slugifiedName="name-terminology">Terminology</name> <t>This document uses terms that are either specific for multipath
<t indent="0" pn="section-1.2-1">This document uses terms that are eithe transport as defined in <xref target="RFC8684"/> or defined in the
r specific context of MP-DCCP, as follows:</t>
for multipath transport as defined in <xref target="RFC8684" format="default" se
ctionFormat="of" derivedContent="RFC8684"/> or are defined in the context of MP- <dl spacing="normal" newline="false">
DCCP, as follows:</t> <dt>Path:</dt><dd><t>A sequence of links between a sender and a
<t indent="0" pn="section-1.2-2">Path: A sequence of links between a sen receiver, defined in this context by a 4-tuple of the source and
der and a receiver, defined in destination address and the source and destination ports. This
this context by a 4-tuple of source and destination address and the source and d definition follows <xref target="RFC8684"/> and is illustrated in
estination ports. This definition follows <xref target="RFC8684" format="default the following two examples for IPv6 and IPv4, which each show a pair
" sectionFormat="of" derivedContent="RFC8684"/> and is illustrated in the follow of sender IP-address:port and a pair of receiver IP-address:port,
ing two examples for IPv6 and IPv4, which each show a pair of sender IP-address: which together form the 4-tuple:</t>
port and a pair of receiver IP-address:port, which together form the 4-tuple:</t <ul>
> <li>IPv6: [2001:db8:3333:4444:5555:6666:7777:8888]:1234, [2001:db8:3
<ul spacing="normal" bare="false" empty="false" indent="3" pn="section-1 333:4444:cccc:dddd:eeee:ffff]:4321</li>
.2-3"> <li>IPv4: 203.0.113.1:1234, 203.0.113.2:4321</li>
<li pn="section-1.2-3.1"> </ul></dd>
<t indent="0" pn="section-1.2-3.1.1">IPv6: [2001:db8:3333:4444:5555: <dt>Subflow:</dt><dd>A DCCP flow that is transmitted
6666:7777:8888]:1234, [2001:db8:3333:4444:cccc:dddd:eeee:ffff]:4321</t> by using a specific path (4-tuple of source and destination
</li> address/port pairs) that forms one of the multipath flows used by a
<li pn="section-1.2-3.2"> single connection.</dd>
<t indent="0" pn="section-1.2-3.2.1">IPv4: 203.0.113.1:1234, 203.0.1 <dt>(MP-DCCP) Connection:</dt><dd>A set of one or more subflows,
13.2:4321</t> over which an application can communicate between two hosts. The
</li> MP-DCCP connection is exposed as a single DCCP socket to the
</ul> application.</dd>
<t indent="0" pn="section-1.2-4">Subflow: A subflow refers to a DCCP flo <dt>Connection Identifier (CI):</dt><dd>A unique identifier that is
w transmitted using a specific path (4-tuple of source and destination address/p assigned to a multipath connection by the host to distinguish
ort several multipath connections locally. The CIs must therefore be
pairs) that forms one of the multipath flows used by a single connection.</t> locally unique per host and do not have to be the same across the
<t indent="0" pn="section-1.2-5">(MP-DCCP) Connection: A set of one or m peers.</dd>
ore subflows, over which an <dt>Host:</dt><dd>An end host that operates an MP-DCCP implementation
application can communicate between two hosts. The MP-DCCP connection is and either initiates or accepts an MP-DCCP connection.</dd>
exposed as single DCCP socket to the application.</t> <dt>'+':</dt><dd>The plus symbol means the concatenation of values.</d
<t indent="0" pn="section-1.2-6">Connection Identifier (CI): A unique id d>
entifier that is assigned to a multipath connection by the host to distinguish s </dl>
everal multipath connections locally. The CIs must therefore be locally unique p <t>In addition to these terms, within the framework of MP-DCCP, the
er host and do not have to be the same across the peers.</t> interpretation of, and effect on, regular single-path DCCP semantics
<t indent="0" pn="section-1.2-7">Host: An end host operating an MP-DCCP is discussed in <xref target="protocol"/>.</t>
implementation, and either
initiating or accepting an MP-DCCP connection.</t>
<t indent="0" pn="section-1.2-8">'+': The plus symbol means concatenatio
n of values.</t>
<t indent="0" pn="section-1.2-9">In addition to these
terms, within the framework of MP-DCCP, the interpretation of, and effect on,
regular single-path DCCP semantics is discussed in <xref target="protocol" forma
t="default" sectionFormat="of" derivedContent="Section 3"/>.</t>
</section> </section>
<section anchor="requirements-language" numbered="true" removeInRFC="false <section anchor="requirements-language">
" toc="include" pn="section-1.3"> <name>Requirements Language</name>
<name slugifiedName="name-requirements-language">Requirements Language</ <t>
name> The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
<t indent="0" pn="section-1.3-1">The key words "MUST", "MUST NOT", "REQU IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
IRED", "SHALL", "SHALL NOT", NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"OPTIONAL" in this document are to be interpreted as described in "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
BCP 14 <xref target="RFC2119" format="default" sectionFormat="of" derivedCont be interpreted as
ent="RFC2119"/> <xref target="RFC8174" format="default" sectionFormat="of" deriv described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
edContent="RFC8174"/> when, and only when, they appear in all when, and only when, they appear in all capitals, as shown here.
capitals, as shown here.</t> </t>
</section> </section>
</section> </section>
<section anchor="op_overview" numbered="true" removeInRFC="false" toc="inclu <section anchor="op_overview">
de" pn="section-2"> <name>Operation Overview</name>
<name slugifiedName="name-operation-overview">Operation Overview</name> <t>DCCP transmits congestion-controlled unreliable datagrams over a single
<t indent="0" pn="section-2-1">DCCP transmits congestion-controlled unreli path.
able datagrams over a single path.
Various congestion control mechanisms have been specified to optimize Various congestion control mechanisms have been specified to optimize
DCCP performance for specific traffic types in terms of profiles denoted DCCP performance for specific traffic types in terms of profiles denoted
by a Congestion Control IDentifier (CCID). by a Congestion Control IDentifier (CCID).
However, DCCP does not provide built-in However, DCCP does not provide built-in
support for managing multiple subflows within one DCCP connection. The support for managing multiple subflows within one DCCP connection. The
extension of DCCP for Multipath-DCCP (MP-DCCP) is described in detail extension of DCCP for Multipath-DCCP (MP-DCCP) is described in detail
in <xref target="protocol" format="default" sectionFormat="of" derivedContent="S in <xref target="protocol"/>.</t>
ection 3"/>.</t> <t>At a high level of MP-DCCP operation, the data
<t indent="0" pn="section-2-2">At a high level of the MP-DCCP operation, t
he data
stream from a DCCP application is split stream from a DCCP application is split
by MP-DCCP operation into one or more subflows which can be by the MP-DCCP operation into one or more subflows that can be
transmitted via different paths, for example using paths via different links. transmitted via different paths, for example, using paths via different links.
The corresponding control information allows the receiver to optionally The corresponding control information allows the receiver to optionally
re-assemble and deliver the received data in the originally transmitted order to the reassemble and deliver the received data in the originally transmitted order to the
recipient application. This may be necessary because DCCP does not guarantee in- order delivery. recipient application. This may be necessary because DCCP does not guarantee in- order delivery.
The details of the transmission scheduling mechanism and The details of the transmission scheduling mechanism and
optional reordering mechanism are up to the sender and receiver, respectively, optional reordering mechanism are up to the sender and receiver, respectively,
and are outside the scope of this document.</t> and are outside the scope of this document.</t>
<t indent="0" pn="section-2-3">A Multipath DCCP connection provides a bidi rectional connection of datagrams <t>A Multipath DCCP connection provides a bidirectional connection of data grams
between two hosts exchanging data using DCCP. It does not require between two hosts exchanging data using DCCP. It does not require
any change to the applications. Multipath DCCP enables the any change to the applications. Multipath DCCP enables the
hosts to use multiple paths with different 4-tuples to transport hosts to use multiple paths with different 4-tuples to transport
the packets of an MP-DCCP connection. MP-DCCP manages the request, the packets of an MP-DCCP connection. MP-DCCP manages the request,
set-up, authentication, prioritization, modification, and removal of set-up, authentication, prioritization, modification, and removal of
the DCCP subflows on different paths as well as the exchange of performance the DCCP subflows on different paths as well as the exchange of performance
parameters.<br/> parameters.</t>
The number of DCCP subflows can vary during the <t>The number of DCCP subflows can vary during the
lifetime of a Multipath DCCP connection. The details of the path management deci sions for lifetime of a Multipath DCCP connection. The details of the path management deci sions for
when to add or remove subflows are outside the scope of this document.</t> when to add or remove subflows are outside the scope of this document.</t>
<t indent="0" pn="section-2-4">The Multipath Capability for MP-DCCP is neg <t>The Multipath Capability for MP-DCCP is negotiated with a new DCCP
otiated with a new DCCP feature, as specified in <xref target="mp_capable"/>. Once
feature, as specified in <xref target="mp_capable" format="default" sectionForma negotiated, all subsequent MP-DCCP operations for that connection are signaled w
t="of" derivedContent="Section 3.1"/>. Once ith a
negotiated, all subsequent MP-DCCP operations for that connection are signalled variable length multipath-related option, as described in <xref target="protocol
with a "/>.
variable length multipath-related option, as described in <xref target="protocol All MP-DCCP operations are signaled by Multipath options described in <xref targ
" format="default" sectionFormat="of" derivedContent="Section 3"/>. et="MP_OPT"/>. Options that
All MP-DCCP operations are signaled by Multipath options described in <xref targ
et="MP_OPT" format="default" sectionFormat="of" derivedContent="Section 3.2"/>.
Options that
require confirmation from the remote peer are retransmitted by the sender until confirmed or until require confirmation from the remote peer are retransmitted by the sender until confirmed or until
confirmation is no longer considered relevant.</t> confirmation is no longer considered relevant.</t>
<t indent="0" pn="section-2-5">The following sections define MP-DCCP behav <t>The sections that follow define MP-DCCP behavior in detail.</t>
ior in detail.</t> <section anchor="concept">
<section anchor="concept" numbered="true" removeInRFC="false" toc="include <name>MP-DCCP Concept</name>
" pn="section-2.1"> <t><xref target="ref-example-mp-dccp-usage-scenario"/> provides a genera
<name slugifiedName="name-mp-dccp-concept">MP-DCCP Concept</name> l overview of the MP-DCCP working mode, whose main
<t indent="0" pn="section-2.1-1"><xref target="ref-example-mp-dccp-usage
-scenario" format="default" sectionFormat="of" derivedContent="Figure 2"/> provi
des a general overview of the MP-DCCP working mode, whose main
characteristics are summarized in this section.</t> characteristics are summarized in this section.</t>
<figure anchor="ref-example-mp-dccp-usage-scenario" align="left" suppres <figure anchor="ref-example-mp-dccp-usage-scenario">
s-title="false" pn="figure-2"> <name>Example MP-DCCP Usage Scenario</name>
<name slugifiedName="name-example-mp-dccp-usage-scena">Example MP-DCCP <artwork><![CDATA[
usage scenario</name>
<artwork align="left" pn="section-2.1-2.1"><![CDATA[
Host A Host B Host A Host B
------------------------ ------------------------ ------------------------ ------------------------
Address A1 Address A2 Address B1 Address B2 Address A1 Address A2 Address B1 Address B2
---------- ---------- ---------- ---------- ---------- ---------- ---------- ----------
| | | | | | | |
| (DCCP subflow setup) | | | (DCCP subflow setup) | |
|----------------------------------->| | |----------------------------------->| |
|<-----------------------------------| | |<-----------------------------------| |
| | | | | | | |
| | (DCCP subflow setup)| | | | (DCCP subflow setup)| |
| |--------------------->| | | |--------------------->| |
| |<---------------------| | | |<---------------------| |
| merge individual DCCP subflows to one MP-DCCP connection | merge individual DCCP subflows to one MP-DCCP connection
| | | | | | | |]]></artwork>
]]></artwork>
</figure> </figure>
<ul spacing="normal" bare="false" empty="false" indent="3" pn="section-2 <ul>
.1-3"> <li>
<li pn="section-2.1-3.1"> <t>An MP-DCCP connection begins with a 4-way handshake between
<t indent="0" pn="section-2.1-3.1.1">An MP-DCCP connection begins wi two hosts. In <xref target="ref-example-mp-dccp-usage-scenario"/>,
th a 4-way handshake, between
two hosts. In <xref target="ref-example-mp-dccp-usage-scenario" format="default"
sectionFormat="of" derivedContent="Figure 2"/>,
an MP-DCCP connection is established between addresses A1 and B1 on Hosts 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 mult ipath support for the connection. Host specific keys are also exchanged between Host A and Host B during the handshake. The details of the MP-DCCP handshaking p rocedure is described in <xref target="handshaking" format="default" sectionForm at="of" derivedContent="Section 3.3"/>. MP-DCCP does not require both peers to h ave A and B. In the handshake, a Multipath Capable feature is used to negotiate mult ipath support for the connection. Host-specific keys are also exchanged between Host A and Host B during the handshake. The details of the MP-DCCP handshaking p rocedure is described in <xref target="handshaking"/>. MP-DCCP does not require both peers to have
more than one address.</t> more than one address.</t>
</li> </li>
<li pn="section-2.1-3.2"> <li>
<t indent="0" pn="section-2.1-3.2.1">When additional paths and corre <t>When additional paths and corresponding addresses/ports are avail
sponding addresses/ports are available, additional DCCP subflows can be created able, additional DCCP subflows can be created on
on these paths and attached to the existing MP-DCCP connection. An MP_JOIN option i
these paths and attached to the existing MP-DCCP connection. An MP_JOIN option i s used to connect a new DCCP subflow to an existing MP-DCCP connection. It conta
s used to connect a new DCCP subflow to an existing MP-DCCP connection. It conta ins a Connection Identifier during the setup of the initial subflow and is excha
ins a Connection Identifier during the setup of the initial subflow and is excha nged in the 4-way handshake for the subflow together with the Multipath Capable
nged in the 4-way handshake for the subflow together with the Multipath Capable feature. The example in <xref target="ref-example-mp-dccp-usage-scenario"/> illu
feature. The example in <xref target="ref-example-mp-dccp-usage-scenario" format strates the creation of an additional DCCP subflow between Address A2 on Host A
="default" sectionFormat="of" derivedContent="Figure 2"/> illustrates creation o and Address B1 on Host B. The two subflows
f 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 continue to provide a single connection to the applications at both
endpoints.</t> endpoints.</t>
</li> </li>
<li pn="section-2.1-3.3"> <li>
<t indent="0" pn="section-2.1-3.3.1">MP-DCCP identifies multiple pat <t>MP-DCCP identifies multiple paths by the presence of multiple
hs by the presence of multiple
addresses/ports at hosts. Combinations of these multiple addresses/ports addresses/ports at hosts. Combinations of these multiple addresses/ports
indicate the additional paths. In the example, other potential indicate the additional paths. In the example, other potential
paths that could be set up are A1&lt;-&gt;B2 and A2&lt;-&gt;B2. Although the paths that could be set up are A1&lt;-&gt;B2 and A2&lt;-&gt;B2. Although the
additional subflow in the example is shown as being initiated from A2, an additi onal subflow could additional subflow in the example is shown as being initiated from A2, an additi onal subflow could
alternatively have been initiated from B1 or B2.</t> alternatively have been initiated from B1 or B2.</t>
</li> </li>
<li pn="section-2.1-3.4"> <li>
<t indent="0" pn="section-2.1-3.4.1">The discovery and setup of addi <t>The discovery and setup of additional subflows is achieved
tional subflows is achieved
through a path management method including the logic and details of the procedur es for adding/removing subflows. through a path management method including the logic and details of the procedur es for adding/removing subflows.
This document describes the procedures that enable a host to initiate new subflo This document describes the procedures that enable a host to initiate new subflo
ws or to signal available IP addresses between peers. However, the definition of ws or to signal available IP addresses between peers. However, the definition of
a path management method, in which sequence and when subflows are created, is o a path management method, in which sequence and subflows are created, is outsid
utside the scope of this document. This method is subject to a e the scope of this document. This method is subject to a
corresponding policy and the specifics of the implementation. If an MP-DCCP peer 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. s host wishes to limit the maximum number of paths that can be maintained (e.g.,
imilar to that discussed in section 3.4 of <xref target="RFC8041" format="defaul similar to that discussed in <xref target="RFC8041" sectionFormat="of" section="
t" sectionFormat="of" derivedContent="RFC8041"/>), the creation of new subflows 3.4"/>), the creation of new subflows from that peer host is omitted when the th
from that peer host is omitted when the threshold of maximum paths is exceeded a reshold of maximum paths is exceeded and incoming subflow requests <bcp14>MUST</
nd incoming subflow requests MUST be rejected.</t> bcp14> be rejected.</t>
</li> </li>
<li pn="section-2.1-3.5"> <li>
<t indent="0" pn="section-2.1-3.5.1">Through the use of multipath op <t>Through the use of multipath options, MP-DCCP adds connection-lev
tions, MP-DCCP adds connection-level sequence numbers and exchange of el sequence numbers and the exchange of
Round-Trip Time (RTT) information to enable optional reordering features. As a h Round-Trip Time (RTT) information to enable optional reordering features. As a h
int for scheduling decisions, a multipath option that allows a peer to indicate int for scheduling decisions, a multipath option that allows a peer to indicate
its priorities for what path to use is also defined.</t> its priorities for which path to use is also defined.</t>
</li> </li>
<li pn="section-2.1-3.6"> <li>
<t indent="0" pn="section-2.1-3.6.1">Subflows are terminated in the <t>Subflows are terminated in the same way as regular DCCP connectio
same way as regular DCCP connections, as described ns, as described
in (<xref target="RFC4340" format="default" sectionFormat="of" derivedContent="R in <xref target="RFC4340" sectionFormat="of" section="8.3"/>. MP-DCCP connection
FC4340"/>, Section 8.3). MP-DCCP connections are closed by including an MP_CLOSE s are closed by including an MP_CLOSE option in subflow DCCP-CloseReq or DCCP-Cl
option in subflow DCCP-CloseReq or DCCP-Close messages. An MP-DCCP connection m ose messages. An MP-DCCP connection may also be reset through the use of an MP_F
ay also be reset through the use of an MP_FAST_CLOSE option. Key data from the i AST_CLOSE option. Key Data from the initial handshake is included in MP_CLOSE an
nitial handshake is included in the MP_CLOSE and MP_FAST_CLOSE to protect from u d MP_FAST_CLOSE to protect from an unauthorized shutdown of MP-DCCP connections.
nauthorized shutdown of MP-DCCP connections.</t> </t>
</li> </li>
</ul> </ul>
</section> </section>
</section> </section>
<section anchor="protocol" numbered="true" removeInRFC="false" toc="include" <section anchor="protocol">
pn="section-3"> <name>MP-DCCP Protocol</name>
<name slugifiedName="name-mp-dccp-protocol">MP-DCCP Protocol</name> <t>The DCCP protocol feature list (<xref section="6.4" target="RFC4340"/>)
<t indent="0" pn="section-3-1">The DCCP protocol feature list (<xref secti is
on="6.4" sectionFormat="of" target="RFC4340" format="default" derivedLink="https
://rfc-editor.org/rfc/rfc4340#section-6.4" derivedContent="RFC4340"/>) is
extended in this document by adding a new Multipath feature with Feature number 10, as extended in this document by adding a new Multipath feature with Feature number 10, as
shown in <xref target="ref-feature-list" format="default" sectionFormat="of" der shown in <xref target="ref-feature-list"/>.</t>
ivedContent="Table 1"/>.</t> <table anchor="ref-feature-list">
<table anchor="ref-feature-list" align="center" pn="table-1"> <name>Multipath Feature</name>
<name slugifiedName="name-multipath-feature">Multipath feature</name>
<thead> <thead>
<tr> <tr>
<th align="center" colspan="1" rowspan="1">Number</th> <th>Number</th>
<th align="left" colspan="1" rowspan="1">Meaning</th> <th>Meaning</th>
<th align="center" colspan="1" rowspan="1">Rec'n Rule</th> <th>Rec'n Rule</th>
<th align="center" colspan="1" rowspan="1">Initial Value</th> <th>Initial Value</th>
<th align="center" colspan="1" rowspan="1">Req'd</th> <th>Req'd</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="center" colspan="1" rowspan="1">10</td> <td>10</td>
<td align="left" colspan="1" rowspan="1">Multipath Capable</td> <td>Multipath Capable</td>
<td align="center" colspan="1" rowspan="1">SP</td> <td>SP</td>
<td align="center" colspan="1" rowspan="1">0</td> <td>0</td>
<td align="center" colspan="1" rowspan="1">N</td> <td>N</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<dl indent="3" newline="false" spacing="normal" pn="section-3-3"> <dl>
<dt pn="section-3-3.1">Rec'n Rule:</dt> <dt>Rec'n Rule:</dt>
<dd pn="section-3-3.2"> <dd>
<t indent="0" pn="section-3-3.2.1">The reconciliation rule used for th <t>The reconciliation rule used for the feature. SP indicates the serv
e feature. SP indicates the server-priority as defined in section 6.3 of <xref t er-priority as defined in <xref target="RFC4340" sectionFormat="of" section="6.3
arget="RFC4340" format="default" sectionFormat="of" derivedContent="RFC4340"/>.< "/>.</t>
/t>
</dd> </dd>
<dt pn="section-3-3.3">Initial Value:</dt> <dt>Initial Value:</dt>
<dd pn="section-3-3.4"> <dd>
<t indent="0" pn="section-3-3.4.1">The initial value for the feature. <t>The initial value for the feature. Every feature has a known initia
Every feature has a known initial value.</t> l value.</t>
</dd> </dd>
<dt pn="section-3-3.5">Req'd:</dt> <dt>Req'd:</dt>
<dd pn="section-3-3.6"> <dd>
<t indent="0" pn="section-3-3.6.1">This column is "Y" if and only if e <t>This column is "Y" if and only if every DCCP implementation <bcp14>
very DCCP implementation MUST 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 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> with empty Confirm options.</t>
</dd> </dd>
</dl> </dl>
<t indent="0" pn="section-3-4">This specification adds a DCCP protocol opt <t>This specification adds a DCCP protocol option as defined in <xref targ
ion as defined in (<xref target="RFC4340" format="default" sectionFormat="of" de et="RFC4340" sectionFormat="of" section="5.8"/>, providing
rivedContent="RFC4340"/>, Section 5.8) providing a new multipath-related variable-length option with option type 46, as
a new Multipath related variable-length option with option type 46, as shown in <xref target="ref-option-list"/>.</t>
shown in <xref target="ref-option-list" format="default" sectionFormat="of" deri <table anchor="ref-option-list">
vedContent="Table 2"/>.</t> <name>Multipath Option Set</name>
<table anchor="ref-option-list" align="center" pn="table-2">
<name slugifiedName="name-multipath-option-set">Multipath option set</na
me>
<thead> <thead>
<tr> <tr>
<th align="center" colspan="1" rowspan="1">Type</th> <th>Type</th>
<th align="center" colspan="1" rowspan="1">Option Length</th> <th>Option Length</th>
<th align="center" colspan="1" rowspan="1">Meaning</th> <th>Meaning</th>
<th align="center" colspan="1" rowspan="1">DCCP-Data?</th> <th>DCCP-Data?</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="center" colspan="1" rowspan="1">46</td> <td>46</td>
<td align="center" colspan="1" rowspan="1">variable</td> <td>variable</td>
<td align="center" colspan="1" rowspan="1">Multipath</td> <td>Multipath</td>
<td align="center" colspan="1" rowspan="1">Y</td> <td>Y</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<ul empty="true" bare="false" indent="3" spacing="normal" pn="section-3-6" <section anchor="mp_capable">
> <name>Multipath Capable Feature</name>
<li pn="section-3-6.1"> <t>A DCCP endpoint negotiates the Multipath Capable Feature to determine
<t indent="0" pn="section-3-6.1.1">Note to the RFC Editor: The Feature whether multipath extensions can be enabled for a DCCP connection.</t>
Number and Option Type reflect the temporary assignment by IANA and must be ver <t>The Multipath Capable feature (MP_CAPABLE) has feature number 10 and
ified once again.</t> follows the structure for features given in <xref target="RFC4340" sectionFormat
</li> ="of" section="6"/>. Beside the negotiation of the feature itself, one or severa
</ul> l values can also be exchanged. The value field specified here for the Multipath
<section anchor="mp_capable" numbered="true" removeInRFC="false" toc="incl Capable feature has a length of one byte and can be repeated several times with
ude" pn="section-3.1"> in the DCCP option for feature negotiation. This can be, for example, required t
<name slugifiedName="name-multipath-capable-feature">Multipath Capable F o announce support of different versions of the protocol. For that, the leftmost
eature</name> four bits in <xref target="ref-mp-capable-format"/> specify the compatible vers
<t indent="0" pn="section-3.1-1">A DCCP endpoint negotiates the Multipat ion of the
h Capable Feature to determine whether multipath extensions can be enabled for a MP-DCCP implementation and <bcp14>MUST</bcp14> be set to 0 following this specif
DCCP connection.</t> ication. The four bits following the Version field are unassigned in version 0 a
<t indent="0" pn="section-3.1-2">The Multipath Capable feature (MP_CAPAB nd <bcp14>MUST</bcp14> be set to zero by the sender and <bcp14>MUST</bcp14> be i
LE) has feature number 10 and follows the structure for features given in <xref gnored by the receiver.</t>
target="RFC4340" format="default" sectionFormat="of" derivedContent="RFC4340"/> <figure anchor="ref-mp-capable-format">
Section 6. Beside the negotiation of the feature itself, also one or several val <name>Format of the Multipath Capable Feature Value Field</name>
ues can be exchanged. The value field specified here for the Multipath Capable f <artwork><![CDATA[
eature has a length of one-byte and can be repeated several times within the DCC 0 1 2 3 4 5 6 7
P option for feature negotiation. This can be for example required to announce s +-----------+------------+
upport of different versions of the protocol. For that, the leftmost four bits i | Version | Unassigned |
n <xref target="ref-mp-capable-format" format="default" sectionFormat="of" deriv +-----------+------------+]]></artwork>
edContent="Figure 3"/> specify the compatible version of the
MP-DCCP implementation and MUST be set to 0 following this specification. The fo
ur bits following the Version field are unassigned in version 0 and MUST be set
to zero by the sender and MUST be ignored by the receiver.</t>
<figure anchor="ref-mp-capable-format" align="left" suppress-title="fals
e" pn="figure-3">
<name slugifiedName="name-format-of-the-multipath-cap">Format of the M
ultipath Capable feature value field</name>
<artwork align="left" pn="section-3.1-3.1"><![CDATA[
0 1 2 3 4 5 6 7
+-----------+------------+
| Version | Unassigned |
+-----------+------------+
]]></artwork>
</figure> </figure>
<t indent="0" pn="section-3.1-4">The setting of the MP_CAPABLE feature M <t>The setting of the MP_CAPABLE feature <bcp14>MUST</bcp14> follow the
UST follow the server-priority reconciliation rule described server-priority reconciliation rule described
in (<xref target="RFC4340" format="default" sectionFormat="of" derivedContent="R in <xref target="RFC4340" sectionFormat="of" section="6.3.1"/>. This allows mult
FC4340"/>, Section 6.3.1). This allows multiple versions to be iple versions to be
specified in order of priority.</t> specified in order of priority.</t>
<t indent="0" pn="section-3.1-5">The negotiation MUST be a part of the i <t>The negotiation <bcp14>MUST</bcp14> be a part of the initial handshak
nitial handshake procedure e procedure
described in <xref target="handshaking" format="default" sectionFormat="of" der described in <xref target="handshaking"/>. No subsequent renegotiation of
ivedContent="Section 3.3"/>. No subsequent re-negotiation of
the MP_CAPABLE feature is allowed for the same MP-DCCP connection.</t> the MP_CAPABLE feature is allowed for the same MP-DCCP connection.</t>
<t indent="0" pn="section-3.1-6">Clients MUST include a Change R (<xref section="6" sectionFormat="comma" target="RFC4340" format="default" derivedLink= "https://rfc-editor.org/rfc/rfc4340#section-6" derivedContent="RFC4340"/>) optio n during the initial handshake request to <t>Clients <bcp14>MUST</bcp14> include a Change R option (<xref section= "6" sectionFormat="of" target="RFC4340"/>) during the initial handshake request to
supply a list of supported MP-DCCP protocol versions, ordered by preference.</t> supply a list of supported MP-DCCP protocol versions, ordered by preference.</t>
<t indent="0" pn="section-3.1-7">Servers MUST include a Confirm L (<xref section="6" sectionFormat="comma" target="RFC4340" format="default" derivedLink ="https://rfc-editor.org/rfc/rfc4340#section-6" derivedContent="RFC4340"/>) opti on in the subsequent response to agree on <t>Servers <bcp14>MUST</bcp14> include a Confirm L option (<xref section ="6" sectionFormat="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 an MP-DCCP version to be used from the Client list, followed by its own
supported version(s), ordered by preference. Any subflow added to an existing MP -DCCP connection MUST use the supported version(s), ordered by preference. Any subflow added to an existing MP -DCCP connection <bcp14>MUST</bcp14> use the
version negotiated for the first subflow.</t> version negotiated for the first subflow.</t>
<t indent="0" pn="section-3.1-8">If no agreement is found, the Server MU ST reply with an empty Confirm L option <t>If no agreement is found, the Server <bcp14>MUST</bcp14> reply with a n empty Confirm L option
with feature number 10 and no values.</t> with feature number 10 and no values.</t>
<t indent="0" pn="section-3.1-9">An example of successful version negoti <t>An example of successful version negotiation is shown hereafter and f
ation is shown hereafter and follows the negotiation example shown in <xref targ ollows the negotiation example shown in <xref target="RFC4340" sectionFormat="of
et="RFC4340" format="default" sectionFormat="of" derivedContent="RFC4340"/> Sect " section="6.5"/>. For better understanding, this example uses the unspecified M
ion 6.5. For better understanding, this example uses the unspecified MP-DCCP ver P-DCCP versions 1 and 2 in addition to the MP-DCCP version 0 specified in this d
sions 1 and 2 in addition to the MP-DCCP version 0 specified in this document:</ ocument:</t>
t> <figure anchor="ref-mp-capable-example">
<figure anchor="ref-mp-capable-example" align="left" suppress-title="fal <name>Example of MP-DCCP Support Negotiation Using MP_CAPABLE</name>
se" pn="figure-4"> <artwork><![CDATA[
<name slugifiedName="name-example-of-mp-dccp-support-">Example of MP-D Client Server
CCP support negotiation using MP_CAPABLE</name> ------ ------
<artwork align="left" pn="section-3.1-10.1"><![CDATA[ DCCP-Req + Change R(MP_CAPABLE, 1 0)
Client Server ----------------------------------->
------ ------
DCCP-Req + Change R(MP_CAPABLE, 1 0)
----------------------------------->
DCCP-Resp + Confirm L(MP_CAPABLE, 1, 2 1 0) DCCP-Resp + Confirm L(MP_CAPABLE, 1, 2 1 0)
<----------------------------------- <-----------------------------------
* agreement on version = 1 * * agreement on version = 1 *]]></artwork>
]]></artwork>
</figure> </figure>
<ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-3.
1-11"><li pn="section-3.1-11.1" derivedCounter="1."> <!--[rfced] Section 3.1: Would you like to add text to introduce
<t indent="0" pn="section-3.1-11.1.1">The Client indicates support f the numbered list that immediately follows Figure 4?
or both MP-DCCP versions 1 and 0, with a preference
Original:
1. The Client indicates support for both MP-DCCP versions 1 and 0,
with a preference for version 1.
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, w
ith a preference
for version 1.</t> for version 1.</t>
</li> </li>
<li pn="section-3.1-11.2" derivedCounter="2."> <li>
<t indent="0" pn="section-3.1-11.2.1">Server agrees on using MP-DCCP <t>The Server agrees on using MP-DCCP version 1 indicated by the fir
version 1 indicated by the first value, and supplies its own preference list wi st value and supplies its own preference list with the subsequent values.</t>
th the following values.</t>
</li> </li>
<li pn="section-3.1-11.3" derivedCounter="3."> <li>
<t indent="0" pn="section-3.1-11.3.1">MP-DCCP is then enabled betwee <t>MP-DCCP is then enabled between the Client and Server with versio
n the Client and Server with version 1.</t> n 1.</t>
</li> </li>
</ol> </ol>
<t indent="0" pn="section-3.1-12">Unlike the example in <xref target="re <t>Unlike the example in <xref target="ref-mp-capable-example"/>, this d
f-mp-capable-example" format="default" sectionFormat="of" derivedContent="Figure ocument only allows the
4"/>, this document only allows the negotiation of MP-DCCP version 0. Therefore, per successful
negotiation of MP-DCCP version 0. Therefore, successful
negotiation of MP-DCCP as defined in this document, the client negotiation of MP-DCCP as defined in this document, the client
and the server MUST both support MP-DCCP version 0.</t> and the server <bcp14>MUST</bcp14> both support MP-DCCP version 0.</t>
<t indent="0" pn="section-3.1-13">If the version negotiation fails or th <t>If the version negotiation fails or the MP_CAPABLE feature is not pre
e MP_CAPABLE feature is not present in the DCCP-Request or DCCP-Response packets sent in the DCCP-Request or DCCP-Response packets of the initial handshake proce
of the initial handshake procedure, the MP-DCCP connection MUST either fall bac dure, the MP-DCCP connection either <bcp14>MUST</bcp14> fall back to regular DC
k to regular DCCP or MUST close the connection. Further details are specified in CP or <bcp14>MUST</bcp14> close the connection. Further details are specified in
<xref target="fallback" format="default" sectionFormat="of" derivedContent="Sec <xref target="fallback"/>.</t>
tion 3.6"/></t>
</section> </section>
<section anchor="MP_OPT" numbered="true" removeInRFC="false" toc="include" <section anchor="MP_OPT">
pn="section-3.2"> <name>Multipath Option</name>
<name slugifiedName="name-multipath-option">Multipath Option</name> <t>MP-DCCP uses one single option to signal various multipath-related op
<t indent="0" pn="section-3.2-1">MP-DCCP uses one single option to signa erations. The format of this multipath option is shown in <xref target="ref-mp-o
l various multipath-related operations. The format of this multipath option is s ption-format"/>.</t>
hown in <xref target="ref-mp-option-format" format="default" sectionFormat="of"
derivedContent="Figure 5"/>.</t> <figure anchor="ref-mp-option-format">
<figure anchor="ref-mp-option-format" align="left" suppress-title="false <name>Multipath Option Format</name>
" pn="figure-5"> <artwork><![CDATA[
<name slugifiedName="name-multipath-option-format">Multipath option fo
rmat</name>
<artwork align="left" pn="section-3.2-2.1"><![CDATA[
1 2 3 1 2 3
01234567 89012345 67890123 45678901 23456789 01234567 89012345 67890123 45678901 23456789
+--------+--------+--------+--------+--------+ +--------+--------+--------+--------+--------+
|00101110| Length | MP_OPT | Value(s) ... |00101110| Length | MP_OPT | Value(s) ...
+--------+--------+--------+--------+--------+ +--------+--------+--------+--------+--------+
Type=46 Type=46]]></artwork>
]]></artwork>
</figure> </figure>
<t indent="0" pn="section-3.2-3">The fields used by the multipath option
are described in <xref target="ref-mp-option-list" format="default" sectionForm <t>The fields used by the multipath option are described in <xref target
at="of" derivedContent="Table 3"/>. MP_OPT refers to a Multipath option.</t> ="ref-mp-option-list"/>. MP_OPT refers to a Multipath option.</t>
<table anchor="ref-mp-option-list" align="center" pn="table-3">
<name slugifiedName="name-mp_opt-option-types">MP_OPT option types</na <!--[rfced] Table 4: May we update these IANA-registered descriptions as
me> 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
-->
<table anchor="ref-mp-option-list">
<name>MP_OPT Option Types</name>
<thead> <thead>
<tr> <tr>
<th align="left" colspan="1" rowspan="1">Type</th> <th>Type</th>
<th align="left" colspan="1" rowspan="1">Option Length</th> <th>Option Length</th>
<th align="left" colspan="1" rowspan="1">MP_OPT</th> <th>MP_OPT</th>
<th align="left" colspan="1" rowspan="1">Meaning</th> <th>Meaning</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left" colspan="1" rowspan="1">46</td> <td>46</td>
<td align="left" colspan="1" rowspan="1">var</td> <td>var</td>
<td align="left" colspan="1" rowspan="1">0 =MP_CONFIRM</td> <td>0 =MP_CONFIRM</td>
<td align="left" colspan="1" rowspan="1">Confirm reception and pro <td>Confirm reception and processing of an MP_OPT option</td>
cessing of an MP_OPT option</td>
</tr> </tr>
<tr> <tr>
<td align="left" colspan="1" rowspan="1">46</td> <td>46</td>
<td align="left" colspan="1" rowspan="1">12</td> <td>12</td>
<td align="left" colspan="1" rowspan="1">1 =MP_JOIN</td> <td>1 =MP_JOIN</td>
<td align="left" colspan="1" rowspan="1">Join subflow to an existi <td>Join subflow to an existing MP-DCCP connection</td>
ng MP-DCCP connection</td>
</tr> </tr>
<tr> <tr>
<td align="left" colspan="1" rowspan="1">46</td> <td>46</td>
<td align="left" colspan="1" rowspan="1">var</td> <td>var</td>
<td align="left" colspan="1" rowspan="1">2 =MP_FAST_CLOSE</td> <td>2 =MP_FAST_CLOSE</td>
<td align="left" colspan="1" rowspan="1">Close an MP-DCCP connecti <td>Close an MP-DCCP connection unconditionally</td>
on unconditionally</td>
</tr> </tr>
<tr> <tr>
<td align="left" colspan="1" rowspan="1">46</td> <td>46</td>
<td align="left" colspan="1" rowspan="1">var</td> <td>var</td>
<td align="left" colspan="1" rowspan="1">3 =MP_KEY</td> <td>3 =MP_KEY</td>
<td align="left" colspan="1" rowspan="1">Exchange key material for <td>Exchange key material for MP_HMAC</td>
MP_HMAC</td>
</tr> </tr>
<tr> <tr>
<td align="left" colspan="1" rowspan="1">46</td> <td>46</td>
<td align="left" colspan="1" rowspan="1">9</td> <td>9</td>
<td align="left" colspan="1" rowspan="1">4 =MP_SEQ</td> <td>4 =MP_SEQ</td>
<td align="left" colspan="1" rowspan="1">Multipath Sequence Number <td>Multipath sequence number</td>
</td>
</tr> </tr>
<tr> <tr>
<td align="left" colspan="1" rowspan="1">46</td> <td>46</td>
<td align="left" colspan="1" rowspan="1">23</td> <td>23</td>
<td align="left" colspan="1" rowspan="1">5 =MP_HMAC</td> <td>5 =MP_HMAC</td>
<td align="left" colspan="1" rowspan="1">Hash-based message auth. <td>Hash-based message authentication code for MP-DCCP</td>
code for MP-DCCP</td>
</tr> </tr>
<tr> <tr>
<td align="left" colspan="1" rowspan="1">46</td> <td>46</td>
<td align="left" colspan="1" rowspan="1">12</td> <td>12</td>
<td align="left" colspan="1" rowspan="1">6 =MP_RTT</td> <td>6 =MP_RTT</td>
<td align="left" colspan="1" rowspan="1">Transmit RTT values and c <td>Transmit RTT values and calculation parameters</td>
alculation parameters</td>
</tr> </tr>
<tr> <tr>
<td align="left" colspan="1" rowspan="1">46</td> <td>46</td>
<td align="left" colspan="1" rowspan="1">var</td> <td>var</td>
<td align="left" colspan="1" rowspan="1">7 =MP_ADDADDR</td> <td>7 =MP_ADDADDR</td>
<td align="left" colspan="1" rowspan="1">Advertise additional addr <td>Advertise additional address(es)/port(s)</td>
ess(es)/port(s)</td>
</tr> </tr>
<tr> <tr>
<td align="left" colspan="1" rowspan="1">46</td> <td>46</td>
<td align="left" colspan="1" rowspan="1">8</td> <td>8</td>
<td align="left" colspan="1" rowspan="1">8 =MP_REMOVEADDR</td> <td>8 =MP_REMOVEADDR</td>
<td align="left" colspan="1" rowspan="1">Remove address(es)/ port( <td>Remove address(es)/port(s)</td>
s)</td>
</tr> </tr>
<tr> <tr>
<td align="left" colspan="1" rowspan="1">46</td> <td>46</td>
<td align="left" colspan="1" rowspan="1">4</td> <td>4</td>
<td align="left" colspan="1" rowspan="1">9 =MP_PRIO</td> <td>9 =MP_PRIO</td>
<td align="left" colspan="1" rowspan="1">Change subflow priority</ <td>Change subflow priority</td>
td>
</tr> </tr>
<tr> <tr>
<td align="left" colspan="1" rowspan="1">46</td> <td>46</td>
<td align="left" colspan="1" rowspan="1">var</td> <td>var</td>
<td align="left" colspan="1" rowspan="1">10 =MP_CLOSE</td> <td>10 =MP_CLOSE</td>
<td align="left" colspan="1" rowspan="1">Close an MP-DCCP connecti <td>Close an MP-DCCP connection</td>
on</td>
</tr> </tr>
<tr> <tr>
<td align="left" colspan="1" rowspan="1">46</td> <td>46</td>
<td align="left" colspan="1" rowspan="1">var</td> <td>var</td>
<td align="left" colspan="1" rowspan="1">11 =MP_EXP</td> <td>11 =MP_EXP</td>
<td align="left" colspan="1" rowspan="1">Experimental option for p <td>Experimental option for private use</td>
rivate use</td>
</tr> </tr>
<tr> <tr>
<td align="left" colspan="1" rowspan="1">46</td> <td>46</td>
<td align="left" colspan="1" rowspan="1">TBD</td> <td>TBD</td>
<td align="left" colspan="1" rowspan="1">&gt;11</td> <td>&gt;11</td>
<td align="left" colspan="1" rowspan="1">Reserved for future Multi <td>Reserved for future Multipath options.</td>
path options.</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t indent="0" pn="section-3.2-5">Future MP options could be defined in a <t>Future MP options could be defined in a later version of or extension
later version or extension to this specification.</t> to this specification.</t>
<t indent="0" pn="section-3.2-6">These operations are largely inspired b <t>These operations are largely inspired by the signals defined in <xref
y the signals defined in <xref target="RFC8684" format="default" sectionFormat=" target="RFC8684"/>. The procedures for handling faulty or unknown MP options ar
of" derivedContent="RFC8684"/>. The procedures for handling faulty or unknown MP e described in <xref target="fallback"/>.</t>
options are described in <xref target="fallback" format="default" sectionFormat <section anchor="MP_CONFIRM">
="of" derivedContent="Section 3.6"/>.</t> <name>MP_CONFIRM</name>
<section anchor="MP_CONFIRM" numbered="true" removeInRFC="false" toc="in <figure anchor="ref-mp-confirm-format">
clude" pn="section-3.2.1"> <name>Format of the MP_CONFIRM Option</name>
<name slugifiedName="name-mp_confirm">MP_CONFIRM</name> <artwork><![CDATA[
<figure anchor="ref-mp-confirm-format" align="left" suppress-title="fa 1 2 3 4 5
lse" pn="figure-6"> 01234567 89012345 67890123 45678901 23456789 01234567 89012345
<name slugifiedName="name-format-of-the-mp_confirm-op">Format of the +--------+--------+--------+--------+--------+--------+--------+
MP_CONFIRM option</name> |00101110| var |00000000| List of confirmations ...
<artwork align="left" pn="section-3.2.1-1.1"><![CDATA[ +--------+--------+--------+--------+--------+--------+--------+
1 2 3 4 5 Type=46 Length MP_OPT=0]]></artwork>
01234567 89012345 67890123 45678901 23456789 01234567 89012345
+--------+--------+--------+--------+--------+--------+--------+
|00101110| var |00000000| List of confirmations ...
+--------+--------+--------+--------+--------+--------+--------+
Type=46 Length MP_OPT=0
]]></artwork>
</figure> </figure>
<t indent="0" pn="section-3.2.1-2">Some multipath options require conf irmation from the remote peer (see <xref target="ref-mp-option-confirm" format=" default" sectionFormat="of" derivedContent="Table 4"/>). <t>Some multipath options require confirmation from the remote peer (s ee <xref target="ref-mp-option-confirm"/>).
Such options will be retransmitted by the sender until an MP_CONFIRM is received or the confirmation 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 ha s already been of options is considered irrelevant because the data contained in the options ha s already been
replaced by newer information. This can happen, for example, with an MP_PRIO opt ion if the path prioritization replaced by newer information. This can happen, for example, with an MP_PRIO opt ion if the path prioritization
is changed while the previous prioritization has not yet been confirmed. The fur ther processing is changed while the previous prioritization has not yet been confirmed. The fur ther processing
of the multipath options in the receiving host is not the subject of MP_CONFIRM. </t> 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 options could arrive out- <t>Multipath options could arrive out of order; therefore, multipath o
of-order, therefore multipath options defined in <xref target="ref-mp-option-con ptions defined in <xref target="ref-mp-option-confirm"/>
firm" format="default" sectionFormat="of" derivedContent="Table 4"/> <bcp14>MUST</bcp14> be sent in a DCCP datagram with MP_SEQ (see <xref target="MP
MUST be sent in a DCCP datagram with MP_SEQ; see <xref target="MP_SEQ" format="d _SEQ"/>). This allows a receiver to identify whether
efault" sectionFormat="of" derivedContent="Section 3.2.5"/>. This allows a recei multipath options are associated with obsolete datasets (information carried in
ver to identify whether the option header) that would otherwise conflict with newer datasets. In the cas
multipath options are associated with obsolete datasets (information carried in e of MP_ADDADDR or MP_REMOVEADDR, the same dataset is identified based on Addres
the option header) that would otherwise conflict with newer datasets. In the cas sID, whereas the same dataset for MP_PRIO is identified by the subflow in use. A
e of MP_ADDADDR or MP_REMOVEADDR the same dataset is identified based on Address n outdated
ID, 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 refe rring to the same dataset contained a higher sequence number multipath option is detected at the receiver if a previous multipath option refe rring to the same dataset contained a higher sequence number
in the MP_SEQ. An MP_CONFIRM MAY be generated for multipath options that are ide in the MP_SEQ. An MP_CONFIRM <bcp14>MAY</bcp14> be generated for multipath optio
ntified as outdated.</t> ns that are identified as outdated.</t>
<t indent="0" pn="section-3.2.1-4">Similarly, an MP_CONFIRM could arri <t>Similarly, an MP_CONFIRM could arrive out of order. The associated
ve out of order. The associated MP_SEQ received <bcp14>MUST</bcp14> be echoed to ensure that the most recent mul
MP_SEQ received MUST be echoed to ensure that the most recent multipath option i tipath option is confirmed. This protects from inconsistencies that could occur,
s confirmed. This protects from inconsistencies that could occur, e.g. if three e.g., if three MP_PRIO options are sent one after
MP_PRIO options are sent one after the other on one path in order to first set the path priority to 0, then to 1, a
the other on one path in order to first set the path priority to 0, then to 1 an nd finally to 0 again. Without an associated
d 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 s econd update and the third update would MP_SEQ, a loss of the third MP_PRIO option and a loss of the MP_CONFIRM of the s econd update and the third update would
cause the sender to incorrectly interpret that the priority value was set to 0 w ithout recognizing that the receiver has applied cause the sender to incorrectly interpret that the priority value was set to 0 w ithout recognizing that the receiver has applied
priority value 1.</t> priority value 1.</t>
<t indent="0" pn="section-3.2.1-5">The length of the MP_CONFIRM option and the path over which the option is sent depend on the confirmed multipath op tions and the received <t>The length of the MP_CONFIRM option and the path over which the opt ion 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, 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 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 rules apply when multipath options with different MP_SEQs are confirmed at once.
once. This could happen if a datagram with MP_PRIO and a first MP_SEQ_1 and anot
her datagram with MP_ADDADDR and a second MP_SEQ_2 are <!--[rfced] May we rephrase this sentence for improved readability?
received in short succession. In this case, the structure described above is con
catenated resulting in MP_SEQ_2 + MP_ADDADDR + MP_SEQ_1 + MP_PRIO. Original:
The order of the confirmed multipath options in the list of confirmations MUST r This could happen if a datagram with MP_PRIO and a first MP_SEQ_1
eflect the incoming order at the host who sends the MP_CONFIRM, with the most 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 da
tagram with MP_ADDADDR and a second MP_SEQ_2 are received in short succession. I
n this case, the structure described above is concatenated resulting in MP_SEQ_2
+ MP_ADDADDR + MP_SEQ_1 + MP_PRIO.
The order of the confirmed multipath options in the list of confirmations <bcp14
>MUST</bcp14> reflect the incoming order at the host who sends the MP_CONFIRM, w
ith 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 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 overtake s an MP_ADDADDR that refers to the same dataset.</t> and to take countermeasures if they were not, e.g., if an MP_REMOVEADDR overtake s an MP_ADDADDR that refers to the same dataset.</t>
<table anchor="ref-mp-option-confirm" align="center" pn="table-4"> <table anchor="ref-mp-option-confirm">
<name slugifiedName="name-multipath-options-requiring">Multipath opt <name>Multipath Options Requiring Confirmation</name>
ions requiring confirmation</name>
<thead> <thead>
<tr> <tr>
<th align="left" colspan="1" rowspan="1">Type</th> <th>Type</th>
<th align="left" colspan="1" rowspan="1">Option Length</th> <th>Option Length</th>
<th align="left" colspan="1" rowspan="1">MP_OPT</th> <th>MP_OPT</th>
<th align="left" colspan="1" rowspan="1">MP_CONFIRM Sending path <th>MP_CONFIRM Sending Path</th>
</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left" colspan="1" rowspan="1">46</td> <td>46</td>
<td align="left" colspan="1" rowspan="1">var</td> <td>var</td>
<td align="left" colspan="1" rowspan="1">7 =MP_ADDADDR</td> <td>7 =MP_ADDADDR</td>
<td align="left" colspan="1" rowspan="1">Any available</td> <td>Any available</td>
</tr> </tr>
<tr> <tr>
<td align="left" colspan="1" rowspan="1">46</td> <td>46</td>
<td align="left" colspan="1" rowspan="1">4</td> <td>4</td>
<td align="left" colspan="1" rowspan="1">8 =MP_REMOVEADDR</td> <td>8 =MP_REMOVEADDR</td>
<td align="left" colspan="1" rowspan="1">Any available</td> <td>Any available</td>
</tr> </tr>
<tr> <tr>
<td align="left" colspan="1" rowspan="1">46</td> <td>46</td>
<td align="left" colspan="1" rowspan="1">4</td> <td>4</td>
<td align="left" colspan="1" rowspan="1">9 =MP_PRIO</td> <td>9 =MP_PRIO</td>
<td align="left" colspan="1" rowspan="1">Any available</td> <td>Any available</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t indent="0" pn="section-3.2.1-7">An example to illustrate the MP-DCC <t>An example to illustrate the MP-DCCP confirm procedure for the MP_P
P confirm procedure for the MP_PRIO option is shown in <xref target="ref-mp-dccp RIO option is shown in <xref target="ref-mp-dccp-confirm-good"/>. Host A sends a
-confirm-good" format="default" sectionFormat="of" derivedContent="Figure 7"/>. DCCP-Request on path A2-B2 with an MP_PRIO option with value 1 and an associated
The Host A sends a sequence number of 1. Host B replies on the same path in
DCCP-Request on path A2-B2 with an MP_PRIO option with value 1 and associated se
quence 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_CONF IRM option and a list containing the original sequence number (1) this instance (any path can be used) with a DCCP-Response containing the MP_CONF IRM option and a list containing the original sequence number (1)
together with the associated option (MP_PRIO).</t> together with the associated option (MP_PRIO).</t>
<figure anchor="ref-mp-dccp-confirm-good" align="left" suppress-title=
"false" pn="figure-7"> <!--[rfced] Figure Titles
<name slugifiedName="name-example-mp-dccp-confirm-pro">Example MP-DC
CP CONFIRM procedure</name> a) Should the titles of Figures 7 and 8 include "MP_CONFIRM"
<artwork align="left" pn="section-3.2.1-8.1"><![CDATA[ (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
-->
<figure anchor="ref-mp-dccp-confirm-good">
<name>Example MP-DCCP CONFIRM Procedure</name>
<artwork><![CDATA[
Host A Host B Host A Host B
------------------------ ------------------------ ------------------------ ------------------------
Address A1 Address A2 Address B1 Address B2 Address A1 Address A2 Address B1 Address B2
---------- ---------- ---------- ---------- ---------- ---------- ---------- ----------
| | | | | | | |
| | DCCP-Request(seqno 1) + MP_PRIO(1)| | | | DCCP-Request(seqno 1) + MP_PRIO(1)| |
| |------------------------------------------>| | |------------------------------------------>|
| | | | | | | |
| | DCCP-Response + | | | | DCCP-Response + | |
| |<---- MP_CONFIRM(seqno 1, MP_PRIO) --------| | |<---- MP_CONFIRM(seqno 1, MP_PRIO) --------|
| | | | | | | |]]></artwork>
]]></artwork>
</figure> </figure>
<t indent="0" pn="section-3.2.1-9">A second example to illustrate the same MP-DCCP confirm procedure but where an out of date option is also delivered is shown in (<xref target="ref-mp-dccp-confirm-outdated" format="default" secti onFormat="of" derivedContent="Figure 8"/>. <t>A second example that illustrates the same MP-DCCP confirm procedur e but where an out-of-date option is also delivered is shown in <xref target="re f-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 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 netw ork between Host A and Host B and arrives after the second MP_PRIO. Host B set to 1. In this case, the delivery of the first MP_PRIO is delayed in the netw ork 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 th ignores this second MP_PRIO as the associated sequence number is earlier than th
e first. Host B sends a DCCP-Ack confirming receipt of the MP_PRIO(1) with seque e first. Host B sends a DCCP-Ack with sequence number 2 to confirm the receipt o
nce number 2.</t> f the MP_PRIO(1).</t>
<figure anchor="ref-mp-dccp-confirm-outdated" align="left" suppress-ti <figure anchor="ref-mp-dccp-confirm-outdated">
tle="false" pn="figure-8"> <name>Example MP-DCCP CONFIRM Procedure with an Outdated Suboption</
<name slugifiedName="name-example-mp-dccp-confirm-proc">Example MP-D name>
CCP CONFIRM procedure with outdated suboption</name> <artwork><![CDATA[
<artwork align="left" pn="section-3.2.1-10.1"><![CDATA[
Host A Host B Host A Host B
------------------------ ------------------------ ------------------------ ------------------------
Address A1 Address A2 Address B1 Address B2 Address A1 Address A2 Address B1 Address B2
---------- ---------- ---------- ---------- ---------- ---------- ---------- ----------
| | | | | | | |
| | DCCP-Data(seqno 1) + MP_PRIO(4) | | | | DCCP-Data(seqno 1) + MP_PRIO(4) | |
| |------------ | | | |------------ | |
| | \ | | | | \ | |
| | DCCP-Data(seqno 2) + MP_PRIO(1) | | | | DCCP-Data(seqno 2) + MP_PRIO(1) | |
| |--------------\--------------------------->| | |--------------\--------------------------->|
| | \ | | | | \ | |
| | -------------------------->| | | -------------------------->|
| | | | | | | |
| | DCCP-Ack + | | | | DCCP-Ack + | |
| |<---- MP_CONFIRM(seqno 2, MP_PRIO) --------| | |<---- MP_CONFIRM(seqno 2, MP_PRIO) --------|
| | | | | | | |]]></artwork>
]]></artwork>
</figure> </figure>
</section> </section>
<section anchor="MP_JOIN" numbered="true" removeInRFC="false" toc="inclu <section anchor="MP_JOIN">
de" pn="section-3.2.2"> <name>MP_JOIN</name>
<name slugifiedName="name-mp_join">MP_JOIN</name> <figure anchor="ref-MP_JOIN">
<figure anchor="ref-MP_JOIN" align="left" suppress-title="false" pn="f <name>Format of the MP_JOIN Suboption</name>
igure-9">
<name slugifiedName="name-format-of-the-mp_join-subop">Format of the <!--[rfced] We note that Figures 9, 11, and 19 are listed first within
MP_JOIN suboption</name> their sections without any lead-in text. Is this intended, or
<artwork align="left" pn="section-3.2.2-1.1"><![CDATA[ would you like to add a lead-in sentence for consistency with the
1 2 3 other sections?
01234567 89012345 67890123 45678901 -->
+--------+--------+--------+--------+
|00101110|00001100|00000001| Addr ID| <artwork><![CDATA[
+--------+--------+--------+--------+ 1 2 3
| Connection Identifier | 01234567 89012345 67890123 45678901
+--------+--------+--------+--------+ +--------+--------+--------+--------+
| Nonce | |00101110|00001100|00000001| Addr ID|
+--------+--------+--------+--------+ +--------+--------+--------+--------+
Type=46 Length=12 MP_OPT=1 | Connection Identifier |
]]></artwork> +--------+--------+--------+--------+
| Nonce |
+--------+--------+--------+--------+
Type=46 Length=12 MP_OPT=1]]></artwork>
</figure> </figure>
<t indent="0" pn="section-3.2.2-2">The MP_JOIN option is used to add a
new subflow to an existing MP-DCCP <!--[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-D
CCP
connection and REQUIRES a successful establishment of the first subflow using MP _KEY. connection and REQUIRES a successful establishment of the first subflow using MP _KEY.
The Connection Identifier (CI) is the one from the peer host, The Connection Identifier (CI) is the one from the peer host,
which was previously exchanged with the MP_KEY option. which was previously exchanged with the MP_KEY option.
MP_HMAC MUST be set when using MP_JOIN within a DCCP-Response packet; see MP_HMAC <bcp14>MUST</bcp14> be set when using MP_JOIN within a DCCP-Response pac
<xref target="MP_HMAC" format="default" sectionFormat="of" derivedContent="Secti ket; see
on 3.2.6"/> for details. Similar to the setup of the first subflow, MP_JOIN also <xref target="MP_HMAC"/> for details. Similar to the setup of the first subflow,
exchanges the Multipath Capable feature MP_CAPABLE as described in <xref target MP_JOIN also exchanges the Multipath Capable feature MP_CAPABLE as described in
="mp_capable" format="default" sectionFormat="of" derivedContent="Section 3.1"/> <xref target="mp_capable"/>. This procedure includes the DCCP Confirm principle
. This procedure includes the DCCP Confirm principle and thus ensures a reliable and thus ensures a reliable exchange of the MP_JOIN in accordance with <xref ta
exchange of the MP_JOIN in accordance with section 6.6.4 of <xref target="RFC43 rget="RFC4340" sectionFormat="of" section="6.6.4"/>.</t>
40" format="default" sectionFormat="of" derivedContent="RFC4340"/>.</t> <t>The MP_JOIN option includes an "Addr ID" (Address ID) generated by
<t indent="0" pn="section-3.2.2-3">The MP_JOIN option includes an "Add the sender of the option, which is used to identify the source
r ID" (Address ID) generated by the sender of the option, used to identify the s
ource
address of this packet, even if the IP header was changed in address of this packet, even if the IP header was changed in
transit by a middlebox. The value of this field is generated transit by a middlebox. The value of this field is generated
by the sender and MUST map uniquely to a source IP address for the by the sender and <bcp14>MUST</bcp14> map uniquely to a source IP address for th
sending host. The Address ID allows address removal (<xref target="MP_REMOVEADD e
R" format="default" sectionFormat="of" derivedContent="Section 3.2.9"/>) sending host. The Address ID allows address removal (<xref target="MP_REMOVEADD
R"/>)
without the need to know the source address at the receiver, without the need to know the source address at the receiver,
thus allowing address removal through NATs. The Address ID also thus allowing address removal through NATs. The Address ID also
allows correlation between new subflow setup attempts and address allows correlation between new subflow setup attempts and address
signaling (<xref target="MP_ADDADDR" format="default" sectionFormat="of" derived Content="Section 3.2.8"/>), to prevent setting up duplicate subflows signaling (<xref target="MP_ADDADDR"/>), to prevent setting up duplicate subflow s
on the same path, if an MP_JOIN and MP_ADDADDR are sent at the same on the same path, if an MP_JOIN and MP_ADDADDR are sent at the same
time.</t> time.</t>
<t indent="0" pn="section-3.2.2-4">The Address IDs of the subflow used <t>The Address IDs of the subflow used in the initial DCCP Request/Res
in the initial DCCP Request/Response exchange of ponse exchange of
the first subflow in the connection are implicit, and have the value the first subflow in the connection are implicit and have the value
zero. A host MUST store the mappings between Address IDs and zero. A host <bcp14>MUST</bcp14> store the mappings between Address IDs and
addresses both for itself and the remote host. An implementation addresses for both itself and the remote host. An implementation
will also need to know which local and remote Address IDs are will also need to know which local and remote Address IDs are
associated with which established subflows, for when addresses are associated with which established subflows for when addresses are
removed from a local or remote host. An Address ID always MUST be unique removed from a local or remote host. An Address ID <bcp14>MUST</bcp14> always be
over the lifetime of a subflow and can only be re-assigned if sender and unique
over the lifetime of a subflow and can only be reassigned if sender and
receiver no longer have them in use.</t> receiver no longer have them in use.</t>
<t indent="0" pn="section-3.2.2-5">The Nonce is a 32-bit random value <t>The Nonce is a 32-bit random value locally generated for every MP_JOIN option
locally generated for every MP_JOIN option. .
Together with the derived key from the both hosts Key Data described in <xref ta
rget="MP_KEY" format="default" sectionFormat="of" derivedContent="Section 3.2.4" <!--[rfced] Please clarify this sentence, specifically "from the both
/>, the Nonce value builds the basis to calculate the hosts Key Data".
HMAC used in the handshaking process as described in <xref target="handshaking"
format="default" sectionFormat="of" derivedContent="Section 3.3"/> to avoid repl Original:
ay attacks.</t> Together with the derived key from the both hosts
<t indent="0" pn="section-3.2.2-6">If the CI cannot be verified by the Key Data described in Section 3.2.4, the Nonce value builds the basis
receiving host during a handshake negotiation, to calculate the HMAC used in the handshaking process as described in
the new subflow MUST be closed, as specified in <xref target="fallback" format=" Section 3.3 to avoid replay attacks.
default" sectionFormat="of" derivedContent="Section 3.6"/>.</t>
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 ta
rget="MP_KEY"/>, the Nonce value builds the basis to calculate the Hash-based Me
ssage Authentication Code (HMAC) used in the handshaking process as described in
<xref target="handshaking"/> to avoid replay attacks.</t>
<t>If the CI cannot be verified by the receiving host during a handsha
ke negotiation,
the new subflow <bcp14>MUST</bcp14> be closed, as specified in <xref target="fal
lback"/>.</t>
</section> </section>
<section anchor="MP_FAST_CLOSE" numbered="true" removeInRFC="false" toc= <section anchor="MP_FAST_CLOSE">
"include" pn="section-3.2.3"> <name>MP_FAST_CLOSE</name>
<name slugifiedName="name-mp_fast_close">MP_FAST_CLOSE</name> <t>DCCP can send a Close or Reset signal to abruptly close a
<t indent="0" pn="section-3.2.3-1">DCCP can send a Close or Reset sign
al to abruptly close a
connection. Using MP-DCCP, a regular Close or Reset only has the scope of the connection. Using MP-DCCP, a regular Close or Reset only has the scope of the
subflow over which a signal was received. subflow over which a signal was received.
As such, it will only close the subflow and does not 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 affect other remaining subflows or the MP-DCCP connection (unless it is the last
subflow). subflow).
This permits break-before-make handover between This permits break-before-make handover between
subflows.</t> subflows.</t>
<t indent="0" pn="section-3.2.3-2">In order to provide an MP-DCCP-leve l <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> "reset" and thus allow the abrupt closure of the MP-DCCP connection, the MP_FAST _CLOSE suboption can be used.</t>
<figure anchor="ref-MP_FAST_CLOSE" align="left" suppress-title="false" <figure anchor="ref-MP_FAST_CLOSE">
pn="figure-10"> <name>Format of the MP_FAST_CLOSE Suboption</name>
<name slugifiedName="name-format-of-the-mp_fast_close">Format of the <artwork><![CDATA[
MP_FAST_CLOSE suboption</name> 1 2 3
<artwork align="left" pn="section-3.2.3-3.1"><![CDATA[ 01234567 89012345 67890123 45678901 23456789
1 2 3 +--------+--------+--------+--------+--------+
01234567 89012345 67890123 45678901 23456789 |00101110| var |00000010| Key Data ...
+--------+--------+--------+--------+--------+ +--------+--------+--------+--------+--------+
|00101110| var |00000010| Key Data ... Type=46 Length MP_OPT=2]]></artwork>
+--------+--------+--------+--------+--------+
Type=46 Length MP_OPT=2
]]></artwork>
</figure> </figure>
<t indent="0" pn="section-3.2.3-4">When Host A wants to abruptly close <t>When Host A wants to abruptly close an MP-DCCP connection with Host
an MP-DCCP connection with Host B, it will send out the MP_FAST_CLOSE. The MP_F B, it will send out the MP_FAST_CLOSE. The MP_FAST_CLOSE suboption <bcp14>MUST<
AST_CLOSE suboption MUST be sent from Host A on all subflows /bcp14> be sent from Host A on all subflows
using a DCCP-Reset packet with Reset Code 13. The requirement to send the MP_FAS using a DCCP-Reset packet with Reset Code 13. The requirement to send the MP_FAS
T_CLOSE on all subflows increases the probability that Host B will receive the M T_CLOSE on all subflows increases the probability that Host B will receive the M
P_FAST_CLOSE to take the same action. To protect from unauthorized shutdown of a P_FAST_CLOSE to take the same action. To protect from an unauthorized shutdown o
n MP-DCCP connection, f an MP-DCCP connection,
the selected Key Data of the peer host during the handshaking procedure the selected Key Data of the peer host during the handshaking procedure
is carried by the MP_FAST_CLOSE option.</t> is carried by the MP_FAST_CLOSE option.</t>
<t indent="0" pn="section-3.2.3-5">After sending the MP_FAST_CLOSE on <t>After sending the MP_FAST_CLOSE on all subflows, Host A <bcp14>MUST
all subflows, Host A MUST tear down all subflows </bcp14> tear down all subflows,
and the multipath DCCP connection immediately terminates.</t> and the Multipath DCCP connection immediately terminates.</t>
<t indent="0" pn="section-3.2.3-6">Upon reception of the first MP_FAST <t>Upon reception of the first MP_FAST_CLOSE with successfully validat
_CLOSE with successfully validated ed
Key Data, Host B will send a DCCP-Reset packet response on all subflows to 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 A with Reset Code 13 to clean potential middlebox states.
Host B MUST then tear down all subflows and terminate the MP-DCCP connection.</t > Host B <bcp14>MUST</bcp14> then tear down all subflows and terminate the MP-DCCP connection.</t>
</section> </section>
<section anchor="MP_KEY" numbered="true" removeInRFC="false" toc="includ <section anchor="MP_KEY">
e" pn="section-3.2.4"> <name>MP_KEY</name>
<name slugifiedName="name-mp_key">MP_KEY</name> <figure anchor="ref-MP_KEY">
<figure anchor="ref-MP_KEY" align="left" suppress-title="false" pn="fi <name>Format of the MP_KEY Suboption</name>
gure-11"> <artwork><![CDATA[
<name slugifiedName="name-format-of-the-mp_key-subopt">Format of the 1 2 3
MP_KEY suboption</name> 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
<artwork align="left" pn="section-3.2.4-1.1"><![CDATA[ +---------------+---------------+---------------+---------------+
1 2 3 |0 0 1 0 1 1 1 0| var |0 0 0 0 0 0 1 1| resvd |
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 +---------------+---------------+---------------+---------------+
+---------------+---------------+---------------+---------------+ | Connection Identifier |
|0 0 1 0 1 1 1 0| var |0 0 0 0 0 0 1 1| resvd | +---------------+---------------+---------------+---------------+
+---------------+---------------+---------------+---------------+ | Key Type (1) | Key Data (1) | Key Type (2) | Key Data (2) |
| Connection Identifier | +---------------+---------------+---------------+---------------+
+---------------+---------------+---------------+---------------+ | Key Type (3) | ...
| Key Type (1) | Key Data (1) | Key Type (2) | Key Data (2) | +---------------+---------------+
+---------------+---------------+---------------+---------------+ Type=46 Length MP_OPT=3]]></artwork>
| Key Type (3) | ...
+---------------+---------------+
Type=46 Length MP_OPT=3
]]></artwork>
</figure> </figure>
<t indent="0" pn="section-3.2.4-2">The MP_KEY suboption is used to exc <t>The MP_KEY suboption is used to exchange a Connection Identifier (C
hange a Connection Identifier (CI) and key material between I) and key material between
hosts (host A, host B) for a given connection. hosts (Host A and Host B) for a given connection.
The CI is a unique number in the host for each multipath connection and is gener The CI is a unique number in the host for each multipath connection and is gener
ated for inclusion in the first exchange of a connection with MP_KEY. With the ated for inclusion in the first exchange of a connection with MP_KEY. With the
CI it is possible to connect other DCCP subflows to an MP-DCCP connection with M CI, it is possible to connect other DCCP subflows to an MP-DCCP connection with
P_JOIN (<xref target="MP_JOIN" format="default" sectionFormat="of" derivedConten MP_JOIN (<xref target="MP_JOIN"/>). Its size of 32 bits also defines the maximum
t="Section 3.2.2"/>). Its size of 32-bits also defines the maximum number of sim number of simultaneous MP-DCCP connections in a host to 2<sup>32</sup>.
ultaneous MP-DCCP connections in a host to 2^32. According to the Key-related elements of the MP_KEY suboption, the Length varies
According to the Key related elements of the MP_KEY suboption, the Length varies between 17 and 73 bytes for a single-key message and up to
between 17 and 73 bytes for a single-key message, and up to
82 bytes when all specified Key Types 0 and 255 are provided. The Key Type field 82 bytes when all specified Key Types 0 and 255 are provided. The Key Type field
specifies the type of the following key data. specifies the type of the following Key Data.
The set of key types are shown in <xref target="ref-key-type-list" format="defau The set of key types are shown in <xref target="ref-key-type-list"/>.</
lt" sectionFormat="of" derivedContent="Table 5"/>.</t> t>
<table anchor="ref-key-type-list" align="center" pn="table-5">
<name slugifiedName="name-mp_key-key-types">MP_KEY key types</name> <table anchor="ref-key-type-list">
<name>MP_KEY Key Types</name>
<thead> <thead>
<tr> <tr>
<th align="left" colspan="1" rowspan="1">Key Type</th> <th>Key Type</th>
<th align="left" colspan="1" rowspan="1">Key Length (bytes)</th> <th>Key Length (bytes)</th>
<th align="left" colspan="1" rowspan="1">Meaning</th> <th>Meaning</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left" colspan="1" rowspan="1">0 =Plain Text</td> <td>0 =Plain Text</td>
<td align="left" colspan="1" rowspan="1">8</td> <td>8</td>
<td align="left" colspan="1" rowspan="1">Plain Text Key</td> <td>Plain Text Key</td>
</tr> </tr>
<tr> <tr>
<td align="left" colspan="1" rowspan="1">1-254</td> <td>1-254</td>
<td align="left" colspan="1" rowspan="1"> </td> <td> </td>
<td align="left" colspan="1" rowspan="1">Reserved for future Key <td>Reserved for future Key Types</td>
Types</td>
</tr> </tr>
<tr> <tr>
<td align="left" colspan="1" rowspan="1">255 =Experimental</td> <td>255 =Experimental</td>
<td align="left" colspan="1" rowspan="1">64</td> <td>64</td>
<td align="left" colspan="1" rowspan="1">For private use only</t <td>For private use only</td>
d>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<dl newline="true" indent="3" spacing="normal" pn="section-3.2.4-4"> <dl newline="true" spacing="normal">
<dt pn="section-3.2.4-4.1">Plain Text</dt> <dt>Plain Text:</dt>
<dd pn="section-3.2.4-4.2"> <dd><t>Key Data is exchanged in plain text between hosts (Host A and
<t indent="0" pn="section-3.2.4-4.2.1">Key Data is exchanged in pl Host B), and the respective key parts (KeyA and KeyB) are used by
ain text between hosts (Host A, Host B), and the respective key each host to generate the derived key (d-key) by concatenating the
parts (KeyA, KeyB) are used by each host to generate the derived two parts with the local key in front. That is,</t>
key (d-key) by concatenating the two parts with the local key <dl spacing="normal">
in front. That is, <dt>Host A:</dt><dd>d-keyA=(KeyA+KeyB)</dd>
</t> <dt>Host B:</dt><dd>d-keyB=(KeyB+KeyA)</dd>
<ul spacing="normal" bare="false" empty="false" indent="3" pn="sec </dl>
tion-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=(Key
A+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=(Key
B+KeyA)</t>
</li>
</ul>
</dd> </dd>
</dl> <dt>Experimental:</dt>
<dl newline="true" indent="3" spacing="normal" pn="section-3.2.4-5"> <dd><t>This Key Type allows the use of other Key Data and can be use
<dt pn="section-3.2.4-5.1">Experimental</dt> d
<dd pn="section-3.2.4-5.2"> to validate other key exchange mechanisms for a possible future
<t indent="0" pn="section-3.2.4-5.2.1">This Key Type allows to use specification.</t>
other Key Data and can be used to validate other key exchange
mechanisms for a possible future specification.</t>
</dd> </dd>
</dl> </dl>
<t indent="0" pn="section-3.2.4-6">Multiple keys are only permitted in the DCCP-Request message <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 of the handshake procedure for the first subflow. This allows the hosts to agree
on a single key type to be used, as described in <xref target="handshaking" form on a single key type to be used, as described in <xref target="handshaking"/></t
at="default" sectionFormat="of" derivedContent="Section 3.3"/></t> >
<t indent="0" pn="section-3.2.4-7">It is possible that not all hosts w <t>It is possible that not all hosts will support all key types, and t
ill support all key types and this specification does not his specification does not
recommend or enforce the announcement of any particular Key Type within MP_KEY o recommend or enforce the announcement of any particular Key Type within the MP_K
ption as this could have security EY option as this could have security
implications. However, at least Key Type 0 (Plain Text) MUST be supported for in implications. However, at least Key Type 0 (Plain Text) <bcp14>MUST</bcp14> be s
teroperability tests upported for interoperability tests
in implementations of MP-DCCP. If the key type cannot be agreed in the handshake procedure, the MP-DCCP connection in implementations of MP-DCCP. If the key type cannot be agreed in the handshake procedure, the MP-DCCP connection
MUST fall back to not using MP-DCCP, as indicated in <xref target="fallback" for mat="default" sectionFormat="of" derivedContent="Section 3.6"/>.</t> <bcp14>MUST</bcp14> fall back to not using MP-DCCP, as indicated in <xref target ="fallback"/>.</t>
</section> </section>
<section anchor="MP_SEQ" numbered="true" removeInRFC="false" toc="includ <section anchor="MP_SEQ">
e" pn="section-3.2.5"> <name>MP_SEQ</name>
<name slugifiedName="name-mp_seq">MP_SEQ</name> <figure anchor="ref-MP_SEQ">
<figure anchor="ref-MP_SEQ" align="left" suppress-title="false" pn="fi <name>Format of the MP_SEQ Suboption</name>
gure-12"> <artwork><![CDATA[
<name slugifiedName="name-format-of-the-mp_seq-subopt">Format of the 1 2 3 4 5
MP_SEQ suboption</name> 01234567 89012345 67890123 45678901 23456789 01234567 89012345
<artwork align="left" pn="section-3.2.5-1.1"><![CDATA[ +--------+--------+--------+--------+--------+--------+--------+
1 2 3 4 5 |00101110|00001001|00000100| Multipath Sequence Number
01234567 89012345 67890123 45678901 23456789 01234567 89012345 +--------+--------+--------+--------+--------+--------+--------+
+--------+--------+--------+--------+--------+--------+--------+ |
|00101110|00001001|00000100| Multipath Sequence Number +--------+--------+
+--------+--------+--------+--------+--------+--------+--------+ Type=46 Length=9 MP_OPT=4]]></artwork>
|
+--------+--------+
Type=46 Length=9 MP_OPT=4
]]></artwork>
</figure> </figure>
<t indent="0" pn="section-3.2.5-2">The MP_SEQ suboption is used for en d-to-end 48-bit datagram-based sequence <t>The MP_SEQ suboption is used for end-to-end 48-bit datagram-based s equence
numbers of an MP-DCCP connection. The initial data sequence numbers of an MP-DCCP connection. The initial data sequence
number (IDSN) SHOULD be set randomly <xref target="RFC4086" format="default" sec number (IDSN) <bcp14>SHOULD</bcp14> be set randomly <xref target="RFC4086"/>. As
tionFormat="of" derivedContent="RFC4086"/>. As with the standard DCCP with the standard DCCP
sequence number, the data sequence number should not start at zero, but at sequence number, the data sequence number should not start at zero but at
a random value to make blind session hijacking more difficult, see also a random value to make blind session hijacking more difficult; see also
section 7.2 in <xref target="RFC4340" format="default" sectionFormat="of" derive <xref target="RFC4340" sectionFormat="of" section="7.2"/>.</t>
dContent="RFC4340"/>.</t> <t>The MP_SEQ number space is
<t indent="0" pn="section-3.2.5-3">The MP_SEQ number space is independent of the path individual sequence number space and <bcp14>MUST</bcp14>
independent of the path individual sequence number space and MUST be be
sent with all DCCP-Data and DCCP-DataACK packets.</t> sent with all DCCP-Data and DCCP-DataACK packets.</t>
<t indent="0" pn="section-3.2.5-4">When the sequence number space is e <t>When the sequence number space is exhausted, the sequence number <b
xhausted, the sequence number MUST cp14>MUST</bcp14>
be wrapped. <xref target="RFC7323" format="default" sectionFormat="of" derivedCo be wrapped. <xref target="RFC7323"/> provides guidance on selecting an appropria
ntent="RFC7323"/> provides guidance on selecting an appropriately tely
sized sequence number space according to the maximum segment lifetime of sized sequence number space according to the Maximum Segment Lifetime (MSL) of
TCP. 64 bits is the recommended size for TCP to avoid the sequence number TCP. 64 bits is the recommended size for TCP to avoid the sequence number
space going through within the segment lifetime. For DCCP, the Maximum space going through within the segment lifetime. For DCCP, the MSL is the same a
Segment Lifetime is the same as that of TCP as specified in <xref section="3.4" s that of TCP as specified in <xref section="3.4" target="RFC4340"/>.
sectionFormat="of" target="RFC4340" format="default" derivedLink="https://rfc-ed
itor.org/rfc/rfc4340#section-3.4" derivedContent="RFC4340"/>.
Compared to TCP, the sequence number for DCCP is incremented Compared to TCP, the sequence number for DCCP is incremented
per packet rather than per byte transmitted. For this reason, the 48 bits per packet rather than per byte transmitted. For this reason, the 48 bits
chosen in MP_SEQ are considered sufficiently large considering the current chosen in MP_SEQ are considered sufficiently large per the current
globally routable maximum packet size of 1500 bytes, which corresponds to globally routable maximum packet size (MPS) of 1500 bytes, which corresponds to
roughly 375 PiB of data within the sequence number space.</t> roughly 375 pebibytes (PiBs) of data within the sequence number space.</t>
</section> </section>
<section anchor="MP_HMAC" numbered="true" removeInRFC="false" toc="inclu <section anchor="MP_HMAC">
de" pn="section-3.2.6"> <name>MP_HMAC</name>
<name slugifiedName="name-mp_hmac">MP_HMAC</name> <figure anchor="ref-MP_HMAC">
<figure anchor="ref-MP_HMAC" align="left" suppress-title="false" pn="f <name>Format of the MP_HMAC Suboption</name>
igure-13"> <artwork><![CDATA[
<name slugifiedName="name-format-of-the-mp_hmac-subop">Format of the 1 2 3 4
MP_HMAC suboption</name> 01234567 89012345 67890123 45678901 23456789 01234567
<artwork align="left" pn="section-3.2.6-1.1"><![CDATA[ +--------+--------+--------+--------+--------+--------+
1 2 3 4 |00101110|00010111|00000101| HMAC-SHA256 (20 bytes) ...
01234567 89012345 67890123 45678901 23456789 01234567 +--------+--------+--------+--------+--------+--------+
+--------+--------+--------+--------+--------+--------+ Type=46 Length=23 MP_OPT=5]]></artwork>
|00101110|00010111|00000101| HMAC-SHA256 (20 bytes) ...
+--------+--------+--------+--------+--------+--------+
Type=46 Length=23 MP_OPT=5
]]></artwork>
</figure> </figure>
<t indent="0" pn="section-3.2.6-2">The MP_HMAC suboption is used to pr <t>The MP_HMAC suboption is used to provide authentication for the
ovide authentication for the MP_ADDADDR and MP_REMOVEADDR suboptions.
MP_ADDADDR, and MP_REMOVEADDR suboptions. In addition, it provides
<!--[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, authentication for subflows joining an existing MP_DCCP connection,
as described in the second and third step of the handshake of a as described in the second and third step of the handshake of a
subsequent subflow in <xref target="handshaking" format="default" sectionFormat= subsequent subflow in <xref target="handshaking"/>. For this specification of MP
"of" derivedContent="Section 3.3"/>. For this specification of MP-DCCP, -DCCP,
the HMAC code is generated according to <xref target="RFC2104" format="default" the HMAC code is generated according to <xref target="RFC2104"/> in combination
sectionFormat="of" derivedContent="RFC2104"/> in combination with the SHA256 hash algorithm described in <xref target="RFC6234"/>, with the
with the SHA256 hash algorithm described in <xref target="RFC6234" format="defau
lt" sectionFormat="of" derivedContent="RFC6234"/>, with the
output in big-endian format truncated to the leftmost 160 bits (20 bytes). It is possible 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> 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 "Key" used for the HMAC computa <t>The "Key" used for the HMAC computation is the derived key (d-keyA
tion is the derived key (d-keyA for Host A or d-KeyB for Host B) for Host A or d-KeyB for Host B)
described in <xref target="MP_KEY" format="default" sectionFormat="of" derivedCo described in <xref target="MP_KEY"/>, while the HMAC "Message" for MP_JOIN, MP_A
ntent="Section 3.2.4"/>, while the HMAC "Message" for MP_JOIN, MP_ADDADDR and MP DDADDR, and MP_REMOVEADDR must be calculated in both hosts in order to protect t
_REMOVEADDR must be calculated in both hosts in order to protect the multipath o he multipath option when sending and to validate the multipath option when recei
ption when sending and to validate the multipath option when receiving, and is a ving; it is a concatenation of:</t>
concatenation of:</t> <ul>
<ul spacing="normal" bare="false" empty="false" indent="3" pn="section <li>
-3.2.6-4"> <t>For MP_JOIN: The nonces of the MP_JOIN messages for which
<li pn="section-3.2.6-4.1"> authentication shall be performed. Depending on whether Host A
<t indent="0" pn="section-3.2.6-4.1.1">for MP_JOIN: The nonces of or Host B performs the HMAC-SHA256 calculation, it is carried
the MP_JOIN messages for which authentication out as follows: </t>
shall be performed. Depending on whether Host A or Host B performs the HMAC-S <ul>
HA256 calculation, it is carried out as follows: </t> <li>
<ul spacing="normal" bare="false" empty="false" indent="3" pn="sec <t>MP_HMAC(A) = HMAC-SHA256(Key=d-keyA, Msg=RA+RB)</t>
tion-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) = HMAC-S
HA256(Key=d-keyA, Msg=RA+RB)</t>
</li> </li>
<li pn="section-3.2.6-4.1.2.2"> <li>
<t indent="0" pn="section-3.2.6-4.1.2.2.1">MP_HMAC(B) = HMAC-S <t>MP_HMAC(B) = HMAC-SHA256(Key=d-keyB, Msg=RB+RA)</t>
HA256(Key=d-keyB, Msg=RB+RA)</t>
</li> </li>
</ul> </ul>
</li> </li>
</ul> </ul>
<t indent="0" pn="section-3.2.6-5">A usage example is shown in <xref t <t>A usage example is shown in <xref target="ref-mp-dccp-handshaking"/
arget="ref-mp-dccp-handshaking" format="default" sectionFormat="of" derivedConte >.</t>
nt="Figure 21"/>.</t> <ul>
<ul spacing="normal" bare="false" empty="false" indent="3" pn="section <li>
-3.2.6-6"> <t>For MP_ADDADDR: The Address ID and Nonce with an associated IP
<li pn="section-3.2.6-6.1"> address and a port, if defined; otherwise, 2 bytes of value 0. The
<t indent="0" pn="section-3.2.6-6.1.1">for MP_ADDADDR: The Address IP
ID and Nonce with associated IP address and if defined port, address and port <bcp14>MUST</bcp14> be used in network byte
otherwise two bytes of value 0. IP address and port MUST be used in network b order (NBO). Depending on whether Host A or Host B performs the
yte HMAC-SHA256 calculation, it is carried out as follows: </t>
order (NBO). Depending on whether Host A or Host B performs the HMAC-SHA256 c <ul>
alculation, <li>
it is carried out as follows: </t> <t>MP_HMAC(A) = HMAC-SHA256(Key=d-keyA, Msg=Address
<ul spacing="normal" bare="false" empty="false" indent="3" pn="sec ID+Nonce+NBO(IP)+NBO(Port))</t>
tion-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) = HMAC-S
HA256(Key=d-keyA, Msg=Address ID+Nonce+NBO(IP)+NBO(Port))</t>
</li> </li>
<li pn="section-3.2.6-6.1.2.2"> <li>
<t indent="0" pn="section-3.2.6-6.1.2.2.1">MP_HMAC(B) = HMAC-S <t>MP_HMAC(B) = HMAC-SHA256(Key=d-keyB, Msg=Address
HA256(Key=d-keyB, Msg=Address ID+Nonce+NBO(IP)+NBO(Port))</t> ID+Nonce+NBO(IP)+NBO(Port))</t>
</li> </li>
</ul> </ul>
</li> </li>
<li pn="section-3.2.6-6.2"> <li>
<t indent="0" pn="section-3.2.6-6.2.1">for MP_REMOVEADDR: Solely t <t>For MP_REMOVEADDR: Solely the Address ID. Depending on
he Address ID. whether Host A or Host B performs the HMAC-SHA256 calculation,
Depending on whether Host A or Host B performs the HMAC-SHA256 calculation, it is carried out as follows: </t>
it is carried out as follows: </t> <ul>
<ul spacing="normal" bare="false" empty="false" indent="3" pn="sec <li>
tion-3.2.6-6.2.2"> <t>MP_HMAC(A) = HMAC-SHA256(Key=d-keyA, Msg=Address ID+Nonce)<
<li pn="section-3.2.6-6.2.2.1"> /t>
<t indent="0" pn="section-3.2.6-6.2.2.1.1">MP_HMAC(A) = HMAC-S
HA256(Key=d-keyA, Msg=Address ID+Nonce)</t>
</li> </li>
<li pn="section-3.2.6-6.2.2.2"> <li>
<t indent="0" pn="section-3.2.6-6.2.2.2.1">MP_HMAC(B) = HMAC-S <t>MP_HMAC(B) = HMAC-SHA256(Key=d-keyB, Msg=Address ID+Nonce)<
HA256(Key=d-keyB, Msg=Address ID+Nonce)</t> /t>
</li> </li>
</ul> </ul>
</li> </li>
</ul> </ul>
<t indent="0" pn="section-3.2.6-7">MP_JOIN, MP_ADDADDR and MP_REMOVEAD
DR can co-exist or be used multiple times <t>MP_JOIN, MP_ADDADDR, and MP_REMOVEADDR can coexist or be used multi
ple times
within a single DCCP packet. All these multipath options require an individual within a single DCCP packet. All these multipath options require an individual
MP_HMAC option. This ensures that the MP_HMAC is correctly associated. MP_HMAC option. This ensures that the MP_HMAC is correctly associated.
Otherwise, the receiver cannot validate multiple MP_JOIN, MP_ADDADDR or Otherwise, the receiver cannot validate multiple MP_JOIN, MP_ADDADDR, or
MP_REMOVEADDR. Therefore, an MP_HMAC MUST directly follow its associated multipa MP_REMOVEADDR options. Therefore, an MP_HMAC <bcp14>MUST</bcp14> directly follow
th its associated multipath
option. In the likely case of sending a MP_JOIN together with an MP_ADDADDR, thi option. In the likely case of sending an MP_JOIN together with an MP_ADDADDR, th
s is
results in concatenating MP_JOIN + MP_HMAC_1 + MP_ADDADDR + MP_HMAC_2, whereas t he results in concatenating MP_JOIN + MP_HMAC_1 + MP_ADDADDR + MP_HMAC_2, whereas t he
first MP_HMAC_1 is associated with the MP_JOIN and the second MP_HMAC_2 is assoc iated with the first MP_HMAC_1 is associated with the MP_JOIN and the second MP_HMAC_2 is assoc iated with the
MP_ADDADDR suboption.</t> MP_ADDADDR suboption.</t>
<t indent="0" pn="section-3.2.6-8">On the receiver side, the HMAC vali dation of the suboptions MUST be carried out according to <t>On the receiver side, the HMAC validation of the suboptions <bcp14> MUST</bcp14> be carried out according to
the sending sequence in which the associated MP_HMAC follows a suboption. If the suboption 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 wrong or missing), the subsequent handling depends 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 on which suboption was being verified. If the suboption to be authenticated was either
MP_ADDADDR or MP_REMOVEADDR, the receiving host MUST silently ignore it (see <xr MP_ADDADDR or MP_REMOVEADDR, the receiving host <bcp14>MUST</bcp14> silently ign
ef target="MP_ADDADDR" format="default" sectionFormat="of" derivedContent="Secti ore it (see Sections <xref target="MP_ADDADDR" format="counter"/> and <xref targ
on 3.2.8"/> and <xref target="MP_REMOVEADDR" format="default" sectionFormat="of" et="MP_REMOVEADDR" format="counter"/>).
derivedContent="Section 3.2.9"/>). If the suboption to be authenticated was MP_JOIN, the subflow <bcp14>MUST</bcp14
If the suboption to be authenticated was MP_JOIN, the subflow MUST be closed (se > be closed (see <xref target="fallback"/>).</t>
e <xref target="fallback" format="default" sectionFormat="of" derivedContent="Se <t>In the event that an MP_HMAC cannot be associated with a suboption,
ction 3.6"/>).</t> this MP_HMAC <bcp14>MUST</bcp14> be ignored, unless
<t indent="0" pn="section-3.2.6-9">In the event that an MP_HMAC cannot it is a single MP_HMAC that was sent in a DCCP-Ack corresponding to a DCCP respo
be associated with a suboption this MP_HMAC MUST be ignored, unless nse packet with MP_JOIN (see the penultimate arrow in <xref target="ref-mp-dccp-
it is a single MP_HMAC that was sent in a DCCP-Ack corresponding to a DCCP respo handshaking"/>).</t>
nse packet with MP_JOIN (penultimate arrow in <xref target="ref-mp-dccp-handshak
ing" format="default" sectionFormat="of" derivedContent="Figure 21"/>).</t>
</section> </section>
<section anchor="MP_RTT" numbered="true" removeInRFC="false" toc="includ <section anchor="MP_RTT">
e" pn="section-3.2.7"> <name>MP_RTT</name>
<name slugifiedName="name-mp_rtt">MP_RTT</name> <figure anchor="ref-MP_RTT">
<figure anchor="ref-MP_RTT" align="left" suppress-title="false" pn="fi <name>Format of the MP_RTT Suboption</name>
gure-14"> <artwork><![CDATA[
<name slugifiedName="name-format-of-the-mp_rtt-subopt">Format of the 1 2 3 4 5
MP_RTT suboption</name> 01234567 89012345 67890123 45678901 23456789 01234567 89012345
<artwork align="left" pn="section-3.2.7-1.1"><![CDATA[ +--------+--------+--------+--------+--------+--------+--------+
1 2 3 4 5 |00101110|00001100|00000110|RTT Type| RTT
01234567 89012345 67890123 45678901 23456789 01234567 89012345 +--------+--------+--------+--------+--------+--------+--------+
+--------+--------+--------+--------+--------+--------+--------+ | Age |
|00101110|00001100|00000110|RTT Type| RTT +--------+--------+--------+--------+--------+
+--------+--------+--------+--------+--------+--------+--------+ Type=46 Length=12 MP_OPT=6]]></artwork>
| Age |
+--------+--------+--------+--------+--------+
Type=46 Length=12 MP_OPT=6
]]></artwork>
</figure> </figure>
<t indent="0" pn="section-3.2.7-2">The MP_RTT suboption is used to tra nsmit RTT values and age <t>The MP_RTT suboption is used to transmit RTT values and Age
(represented in milliseconds) that belong to the path over which this informatio n is transmitted. (represented in milliseconds) that belong to the path over which this informatio n is transmitted.
This information is useful for the receiving host to This information is useful for the receiving host to
calculate the RTT difference between the subflows and to estimate whether calculate the RTT difference between the subflows and to estimate whether
missing data has been lost.</t> missing data has been lost.</t>
<t indent="0" pn="section-3.2.7-3">The RTT and Age information is a 32 -bit integer. This covers a period of <t>The RTT and Age information is a 32-bit integer. This covers a peri od of
approximately 1193 hours.</t> approximately 1193 hours.</t>
<t indent="0" pn="section-3.2.7-4">The Field RTT type indicates the ty <t>The Field RTT type indicates the type of RTT estimation, according
pe of RTT estimation, according to the following description:</t> to the following description:</t>
<dl newline="true" indent="3" spacing="normal" pn="section-3.2.7-5"> <dl newline="true">
<dt pn="section-3.2.7-5.1">Raw RTT (=0)</dt> <dt>Raw RTT (=0)</dt>
<dd pn="section-3.2.7-5.2"> <dd>
<t indent="0" pn="section-3.2.7-5.2.1">Raw RTT value of the last D <t>Raw RTT value of the last Datagram round trip.</t>
atagram Round-Trip</t>
</dd> </dd>
</dl> <dt>Min RTT (=1)</dt>
<dl newline="true" indent="3" spacing="normal" pn="section-3.2.7-6"> <dd>
<dt pn="section-3.2.7-6.1">Min RTT (=1)</dt> <t>Min RTT value over a given period.</t>
<dd pn="section-3.2.7-6.2">
<t indent="0" pn="section-3.2.7-6.2.1">Min RTT value over a given
period</t>
</dd> </dd>
</dl> <dt>Max RTT (=2)</dt>
<dl newline="true" indent="3" spacing="normal" pn="section-3.2.7-7"> <dd>
<dt pn="section-3.2.7-7.1">Max RTT (=2)</dt> <t>Max RTT value over a given period.</t>
<dd pn="section-3.2.7-7.2">
<t indent="0" pn="section-3.2.7-7.2.1">Max RTT value over a given
period</t>
</dd> </dd>
</dl> <dt>Smooth RTT (=3)</dt>
<dl newline="true" indent="3" spacing="normal" pn="section-3.2.7-8"> <dd>
<dt pn="section-3.2.7-8.1">Smooth RTT (=3)</dt> <t>Averaged RTT value over a given period.</t>
<dd pn="section-3.2.7-8.2">
<t indent="0" pn="section-3.2.7-8.2.1">Averaged RTT value over a g
iven period</t>
</dd> </dd>
</dl> </dl>
<t indent="0" pn="section-3.2.7-9">Each CCID specifies the algorithms
and period applied for their corresponding RTT estimations.The availability of t <t>Each CCID specifies the algorithms and period applied for their cor
he above described types, to be used in the MP_RTT option, depends on the CCID i responding RTT estimations. The availability of the above-described types, to be
mplementation in place.</t> used in the MP_RTT option, depends on the CCID implementation in place.</t>
<dl newline="true" indent="3" spacing="normal" pn="section-3.2.7-10"> <dl newline="false">
<dt pn="section-3.2.7-10.1">Age</dt> <dt>Age:</dt>
<dd pn="section-3.2.7-10.2"> <dd>
<t indent="0" pn="section-3.2.7-10.2.1">The Age parameter defines <t>The Age parameter defines the time difference between now --
the time difference between now - creation of the MP_RTT option - the creation of the MP_RTT option -- and the conducted RTT
and the conducted RTT measurement in milliseconds. If no previous measurement measurement in milliseconds. If no previous measurement exists,
exists, e.g., when initialized, the value is 0.</t> e.g., when initialized, the value is 0.</t>
</dd> </dd>
</dl> </dl>
<t indent="0" pn="section-3.2.7-11">An example of a flow showing the
exchange of path individual <t>An example of a flow showing the exchange of path individual
RTT information is provided in RTT information is provided in
<xref target="ref-MP_RTT_example" format="default" sectionFormat="of" derivedCon tent="Figure 15"/>. <xref target="ref-MP_RTT_example"/>.
RTT1 refers to the first path and RTT2 to the second path. The 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 recepti on of RTT1 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 recepti on of RTT1
and RTT2, the receiver is able to calculate the path_delta which corresponds to and RTT2, the receiver is able to calculate the path_delta that corresponds to
the absolute difference of both values. the absolute difference of both values.
In the case that the path individual RTTs are symmetric in the down-link and up- In the case where the path individual RTTs are symmetric in the down-link and up
link directions and there is no jitter, packets with missing sequence number MP_ -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> _SEQ, e.g., in a reordering process, can be assumed lost after path_delta/2.</t>
<figure anchor="ref-MP_RTT_example" align="left" suppress-title="false <figure anchor="ref-MP_RTT_example">
" pn="figure-15"> <name>Exemplary Flow of MP_RTT Exchange and Usage</name>
<name slugifiedName="name-exemplary-flow-of-mp_rtt-ex">Exemplary flo <artwork><![CDATA[
w of MP_RTT exchange and usage</name> MP-DCCP MP-DCCP
<artwork align="left" pn="section-3.2.7-12.1"><![CDATA[ Sender Receiver
MP-DCCP MP-DCCP +--------+ MP_RTT(RTT1) +-------------+
Sender Receiver | RTT1 |----------------| |
+--------+ MP_RTT(RTT1) +-------------+ | | | path_delta= |
| RTT1 |----------------| | | | MP_RTT(RTT2) | |RTT1-RTT2| |
| | | path_delta= | | RTT2 |----------------| |
| | MP_RTT(RTT2) | |RTT1-RTT2| | +--------+ +-------------+]]></artwork>
| RTT2 |----------------| |
+--------+ +-------------+
]]></artwork>
</figure> </figure>
--------+ <span class="insert">+-------------+]]&gt;&lt;/artwork& gt;</span>
</section> </section>
<section anchor="MP_ADDADDR" numbered="true" removeInRFC="false" toc="in <section anchor="MP_ADDADDR">
clude" pn="section-3.2.8"> <name>MP_ADDADDR</name>
<name slugifiedName="name-mp_addaddr">MP_ADDADDR</name> <t>The MP_ADDADDR suboption announces additional addresses (and, optio
<t indent="0" pn="section-3.2.8-1">The MP_ADDADDR suboption announces nally,
additional addresses (and, optionally,
port numbers) by which a host can be reached. This can be sent at any 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 time during an existing MP-DCCP connection, when the sender wishes to
enable multiple paths and/or when additional paths become available. enable multiple paths and/or when additional paths become available.
Multiple instances of this suboption within a packet Multiple instances of this suboption within a packet
can simultaneously advertise new addresses.</t> can simultaneously advertise new addresses.</t>
<t indent="0" pn="section-3.2.8-2">The Length is variable depending on <t>The Length is variable depending on the address family (IPv4 or IPv
the address family (IPv4 or IPv6) and whether a port number is 6) and whether a port number is
used. This field is in range between 12 and 26 bytes.</t> used. This field is in the range between 12 and 26 bytes.</t>
<t indent="0" pn="section-3.2.8-3">The Nonce is a 32-bit random value <t>The Nonce is a 32-bit random value that is generated locally for
that is generated locally for
each MP_ADDADDR option and is used in the HMAC calculation process each MP_ADDADDR option and is used in the HMAC calculation process
to prevent replay attacks.</t> to prevent replay attacks.</t>
<t indent="0" pn="section-3.2.8-4">The final 2 bytes, optionally speci fy the DCCP port number to <t>The final 2 bytes optionally specify the DCCP port number to
use, and their presence can be inferred from the length of the option. 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 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 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 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 client), there could be cases (such as port-based load balancing) where
the explicit specification of a different port is required. If no the explicit specification of a different port is required. If no
port is specified, the receiving host MUST assume that any attempt to port is specified, the receiving host <bcp14>MUST</bcp14> assume that any attemp t to
connect to the specified address uses the port already used by the connect to the specified address uses the port already used by the
subflow on which the MP_ADDADDR signal was sent.</t> subflow on which the MP_ADDADDR signal was sent.</t>
<t indent="0" pn="section-3.2.8-5">Along with the MP_ADDADDR option an MP_HMAC option MUST be sent for <t>Along with the MP_ADDADDR option, an MP_HMAC option <bcp14>MUST</bc p14> be sent for
authentication. The truncated HMAC parameter present in this MP_HMAC authentication. The truncated HMAC parameter present in this MP_HMAC
option is the leftmost 20 bytes of an HMAC, negotiated and calculated option is the leftmost 20 bytes of an HMAC, negotiated and calculated
as described in <xref target="MP_HMAC" format="default" sectionFormat="of" deriv as described in <xref target="MP_HMAC"/>.
edContent="Section 3.2.6"/>. In the same way as for MP_JOIN,
<!--[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 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, by Host A, will be d-KeyA, and in the case of Host B,
d-KeyB. These are the keys that were exchanged and d-KeyB. These are the keys that were exchanged and
selected in the original MP_KEY handshake. The message for the HMAC is 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 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, 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 HMAC message will include 2 bytes of value zero.
The rationale for the HMAC is to prevent unauthorized entities from The rationale for the HMAC is to prevent unauthorized entities from
injecting MP_ADDADDR signals in an attempt to hijack a connection. injecting MP_ADDADDR signals in an attempt to hijack a connection.
Note that, additionally, the presence of this HMAC prevents the Additionally, note that the presence of this HMAC prevents the
address from being changed in flight unless the key is known by an 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 intermediary. If a host receives an MP_ADDADDR option for which it
cannot validate the HMAC, it MUST silently ignore the option.</t> cannot validate the HMAC, it <bcp14>MUST</bcp14> silently ignore the option.</t>
<t indent="0" pn="section-3.2.8-6">The presence of an MP_SEQ (<xref ta <t>The presence of an MP_SEQ (<xref target="MP_SEQ"/>) <bcp14>MUST</bc
rget="MP_SEQ" format="default" sectionFormat="of" derivedContent="Section 3.2.5" p14> be ensured in a DCCP datagram
/>) MUST be ensured in a DCCP datagram in which MP_ADDADDR is sent, as described in <xref target="MP_CONFIRM"/>.</t>
in which MP_ADDADDR is sent, as described in <xref target="MP_CONFIRM" format="d <figure anchor="ref-MP_ADDADDR">
efault" sectionFormat="of" derivedContent="Section 3.2.1"/>.</t> <name>Format of the MP_ADDADDR Suboption</name>
<figure anchor="ref-MP_ADDADDR" align="left" suppress-title="false" pn <artwork><![CDATA[
="figure-16"> 1 2 3
<name slugifiedName="name-format-of-the-mp_addaddr-su">Format of the 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
MP_ADDADDR suboption</name> +---------------+---------------+-------+-------+---------------+
<artwork align="left" pn="section-3.2.8-7.1"><![CDATA[ |0 0 1 0 1 1 1 0| var |0 0 0 0 0 1 1 1| Address ID |
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 | Nonce |
+---------------+---------------+-------+-------+---------------+ +-------------------------------+-------------------------------+
|0 0 1 0 1 1 1 0| var |0 0 0 0 0 1 1 1| Address ID | | Address (IPv4 - 4 bytes / IPv6 - 16 bytes) |
+---------------+---------------+-------+-------+---------------+ +-------------------------------+-------------------------------+
| Nonce | | Port (2 bytes, optional) | + MP_HMAC option
+-------------------------------+-------------------------------+ +-------------------------------+
| Address (IPv4 - 4 bytes / IPv6 - 16 bytes) | Type=46 Length MP_OPT=7]]></artwork>
+-------------------------------+-------------------------------+
| Port (2 bytes, optional) | + MP_HMAC option
+-------------------------------+
Type=46 Length MP_OPT=7
]]></artwork>
</figure> </figure>
<t indent="0" pn="section-3.2.8-8">Each address has an Address ID that could be used for uniquely <t>Each address has an Address ID that could be used for uniquely
identifying the address within a connection for address removal. identifying the address within a connection for address removal.
Each host maintains a list of unique Address IDs and it manages these as it wish Each host maintains a list of unique Address IDs, and it manages these as it wis
es. The hes. The
Address ID is also used to identify MP_JOIN options (see <xref target="MP_JOIN" Address ID is also used to identify MP_JOIN options (see <xref target="MP_JOIN"/
format="default" sectionFormat="of" derivedContent="Section 3.2.2"/>) >)
relating to the same address, even when address translators are in use. relating to the same address, even when address translators are in use.
The Address ID MUST uniquely identify the address for the sender of the The Address ID <bcp14>MUST</bcp14> uniquely identify the address for the sender of the
option (within the scope of the connection); the mechanism for option (within the scope of the connection); the mechanism for
allocating such IDs is implementation specific.</t> allocating such IDs is implementation specific.</t>
<t indent="0" pn="section-3.2.8-9">All Address IDs learned via either MP_JOIN or MP_ADDADDR can be stored <t>All Address IDs learned via either MP_JOIN or MP_ADDADDR can be sto red
by the receiver in a data structure that gathers all the by the receiver in a data structure that gathers all the
Address-ID-to-address mappings for a connection (identified by a CI 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, 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 the observed source address, and the CI pair for future processing of control
information for a connection. Note that an implementation information for a connection. Note that an implementation
MAY discard incoming address advertisements. Reasons for this are for example:</ <bcp14>MAY</bcp14> discard incoming address advertisements. Reasons for this are
t> , for example:</t>
<ul spacing="normal" bare="false" empty="false" indent="3" pn="section <ul>
-3.2.8-10"> <li>
<li pn="section-3.2.8-10.1"> <t>to avoid the required mapping state, or</t>
<t indent="0" pn="section-3.2.8-10.1.1">to avoid the required mapp
ing state, or</t>
</li> </li>
<li pn="section-3.2.8-10.2"> <li>
<t indent="0" pn="section-3.2.8-10.2.1">because advertised address <t>because advertised addresses are of no use to it.</t>
es are of no use to it.</t>
</li> </li>
</ul> </ul>
<t indent="0" pn="section-3.2.8-11">Possible scenarios in which this a pplies are the lack of resources to store <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 a mapping or when IPv6 addresses are advertised even though the host only
supports IPv4. Therefore, a host MUST treat address announcements as soft state. supports IPv4. Therefore, a host <bcp14>MUST</bcp14> treat address announcements
However, a sender MAY choose to update the announcements periodically to as soft state.
However, a sender <bcp14>MAY</bcp14> choose to update the announcements periodic
ally to
overcome temporary limitations.</t> overcome temporary limitations.</t>
<t indent="0" pn="section-3.2.8-12">A host <t>A host
MAY advertise private addresses, e.g., because there is a <bcp14>MAY</bcp14> advertise private addresses, e.g., because there is a
NAT on the path. It is NAT on the path. It is
desirable to allow this, since there could be cases where both hosts desirable to allow this as there could be cases where both hosts
have additional interfaces on the same private network. The advertisement have additional interfaces on the same private network. The advertisement
of broadcast or multicast IP addresses MUST be ignored by the recipient of of broadcast or multicast IP addresses <bcp14>MUST</bcp14> be ignored by the rec ipient of
this option, as it is not permitted according to the unicast principle of the this option, as it is not permitted according to the unicast principle of the
basic DCCP.</t> basic DCCP.</t>
<t indent="0" pn="section-3.2.8-13">The MP_JOIN handshake to <t>The MP_JOIN handshake used to
create a new subflow (<xref target="MP_JOIN" format="default" sectionFormat="of" create a new subflow (<xref target="MP_JOIN"/>) provides mechanisms to minimize
derivedContent="Section 3.2.2"/>) provides mechanisms to minimize
security risks. The MP_JOIN message contains a 32-bit CI that security risks. The MP_JOIN message contains a 32-bit CI that
uniquely identifies a connection to the receiving host. If the uniquely identifies a connection to the receiving host. If the
CI is unknown, the host MUST send a DCCP-Reset.</t> CI is unknown, the host <bcp14>MUST</bcp14> send a DCCP-Reset.</t>
<t indent="0" pn="section-3.2.8-14">Further security considerations ar <t>Further security considerations around the issue of
ound the issue of
MP_ADDADDR messages that accidentally misdirect, or maliciously direct, MP_ADDADDR messages that accidentally misdirect, or maliciously direct,
new MP_JOIN attempts are discussed in <xref target="security" format="default" s ectionFormat="of" derivedContent="Section 4"/>. new MP_JOIN attempts are discussed in <xref target="security"/>.
If a sending host of an MP_ADDADDR knows that no incoming subflows can If a sending host of an MP_ADDADDR knows that no incoming subflows can
be established at a particular address, an MP_ADDADDR MUST NOT be established at a particular address, an MP_ADDADDR <bcp14>MUST NOT</bcp14>
announce that address unless the sending host has new knowledge about announce that address unless the sending host has new knowledge about
the possibility to do so. This information can be obtained from local the possibility to do so. This information can be obtained from local
firewall or routing settings, knowledge about availability of external firewall or routing settings, knowledge about availability of an external
NAT or firewall, or from connectivity checks performed by the NAT or a firewall, or connectivity checks performed by the
host/application.</t> host/application.</t>
<t indent="0" pn="section-3.2.8-15">The reception of an MP_ADDADDR mes <t>The reception of an MP_ADDADDR message is acknowledged using MP_CON
sage is acknowledged using MP_CONFIRM FIRM
(<xref target="MP_CONFIRM" format="default" sectionFormat="of" derivedContent="S (<xref target="MP_CONFIRM"/>). This ensures a reliable exchange of address
ection 3.2.1"/>). This ensures reliable exchange of address
information.</t> information.</t>
<t indent="0" pn="section-3.2.8-16">A host that receives an MP_ADDADDR <t>A host that receives an MP_ADDADDR but finds
, but finds at connection set up that the IP address and port number is unsuccessful at connection setup <bcp14>S
that the IP address and port number is unsuccessful, SHOULD NOT perform HOULD NOT</bcp14> perform
further connection attempts to this address/port combination for this further connection attempts to this address/port combination for this
connection to save resources. If a sender, however, wishes to trigger a new inco connection to save resources. However, if a sender wishes to trigger a new incom
ming ing
connection attempt on a previously advertised address/port combination connection attempt on a previously advertised address/port combination, they
can therefore refresh the MP_ADDADDR information by sending the option again.</t can refresh the MP_ADDADDR information by sending the option again.</t>
> <t>A host <bcp14>MAY</bcp14> send an MP_ADDADDR message with an alread
<t indent="0" pn="section-3.2.8-17">A host MAY send an MP_ADDADDR mess y-assigned Address
age with an already assigned Address ID using the IP address previously assigned to this Address ID. The new
ID using the IP Address previously assigned to this Address ID. The new
MP_ADDADDR could have the same port number or a different port number. The MP_ADDADDR could have the same port number or a different port number. The
receiver MUST silently ignore the MP_ADDADDR if the IP Address is not the receiver <bcp14>MUST</bcp14> silently ignore the MP_ADDADDR if the IP address is not the
same as that previously assigned to this Address ID. A host wishing to same as that previously assigned to this Address ID. A host wishing to
replace an existing Address ID MUST first remove the existing one replace an existing Address ID <bcp14>MUST</bcp14> first remove the existing one
(<xref target="MP_REMOVEADDR" format="default" sectionFormat="of" derivedContent (<xref target="MP_REMOVEADDR"/>).</t>
="Section 3.2.9"/>).</t>
</section> </section>
<section anchor="MP_REMOVEADDR" numbered="true" removeInRFC="false" toc= <section anchor="MP_REMOVEADDR">
"include" pn="section-3.2.9"> <name>MP_REMOVEADDR</name>
<name slugifiedName="name-mp_removeaddr">MP_REMOVEADDR</name> <t>If, during the lifetime of an MP-DCCP connection, a previously anno
<t indent="0" pn="section-3.2.9-1">If, during the lifetime of an MP-DC unced
CP connection, a previously announced
address becomes invalid (e.g., if an interface disappears), the address becomes invalid (e.g., if an interface disappears), the
affected host SHOULD announce this. The peer can remove a previously affected host <bcp14>SHOULD</bcp14> announce this. The peer can remove a previou sly
added address with an Address ID from a connection added address with an Address ID from a connection
using the Remove Address (MP_REMOVEADDR) suboption. This using the Remove Address (MP_REMOVEADDR) suboption. This
will terminate any subflows currently using that address.</t> will terminate any subflows currently using that address.</t>
<t indent="0" pn="section-3.2.9-2">MP_REMOVEADDR is only used to close <t>MP_REMOVEADDR is only used to close already-established subflows th
already established subflows that at
have an invalid address. Functional flows with a valid address MUST be have an invalid address. Functional flows with a valid address <bcp14>MUST</bcp1
4> be
closed with a DCCP Close exchange (as with regular DCCP) instead of closed with a DCCP Close exchange (as with regular DCCP) instead of
using MP_REMOVEADDR. For more information see <xref target="closing" format="def using MP_REMOVEADDR. For more information see <xref target="closing"/>.</t>
ault" sectionFormat="of" derivedContent="Section 3.5"/>.</t> <t>The Nonce is a 32-bit random value that is generated locally for
<t indent="0" pn="section-3.2.9-3">The Nonce is a 32-bit random value
that is generated locally for
each MP_REMOVEADDR option and is used in the HMAC calculation process each MP_REMOVEADDR option and is used in the HMAC calculation process
to prevent replay attacks.</t> to prevent replay attacks.</t>
<t indent="0" pn="section-3.2.9-4">Along with the MP_REMOVEADDR subopt ion a MP_HMAC option MUST be sent for <t>Along with the MP_REMOVEADDR suboption, an MP_HMAC option <bcp14>MU ST</bcp14> be sent for
authentication. The truncated HMAC parameter present in this MP_HMAC authentication. The truncated HMAC parameter present in this MP_HMAC
option is the leftmost 20 bytes of an HMAC, negotiated and calculated option is the leftmost 20 bytes of an HMAC, negotiated and calculated
as described in <xref target="MP_HMAC" format="default" sectionFormat="of" deriv edContent="Section 3.2.6"/>. In the same way as for MP_JOIN, as described in <xref target="MP_HMAC"/>. In the same way as for MP_JOIN,
the key for the HMAC algorithm, in the case of the message transmitted 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, by Host A, will be d-KeyA, and in the case of Host B,
d-KeyB. These are the keys that were exchanged and d-KeyB. These are the keys that were exchanged and
selected in the original MP_KEY handshake. The message for the HMAC is selected in the original MP_KEY handshake. The message for the HMAC is
the Address ID.</t> the Address ID.</t>
<t indent="0" pn="section-3.2.9-5">The rationale for using a HMAC is t o prevent unauthorized entities from <t>The rationale for using an HMAC is to prevent unauthorized entities from
injecting MP_REMOVEADDR signals in an attempt to hijack a connection. injecting MP_REMOVEADDR signals in an attempt to hijack a connection.
Note that, additionally, the presence of this HMAC prevents the Additionally, note that the presence of this HMAC prevents the
address from being modified in flight unless the key is known by an 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 intermediary. If a host receives an MP_REMOVEADDR option for which it
cannot validate the HMAC, it MUST silently ignore the option.</t> cannot validate the HMAC, it <bcp14>MUST</bcp14> silently ignore the option.</t>
<t indent="0" pn="section-3.2.9-6">A receiver MUST include an MP_SEQ ( <t>A receiver <bcp14>MUST</bcp14> include an MP_SEQ (<xref target="MP_
<xref target="MP_SEQ" format="default" sectionFormat="of" derivedContent="Sectio SEQ"/>) in a DCCP datagram that sends
n 3.2.5"/>) in a DCCP datagram that sends an MP_REMOVEADDR. Further details are given in <xref target="MP_CONFIRM"/>.</t>
an MP_REMOVEADDR. Further details are given in <xref target="MP_CONFIRM" format= <t>The reception of an MP_REMOVEADDR message is acknowledged using MP_
"default" sectionFormat="of" derivedContent="Section 3.2.1"/>.</t> CONFIRM
<t indent="0" pn="section-3.2.9-7">The reception of an MP_REMOVEADDR m (<xref target="MP_CONFIRM"/>). This ensures a reliable exchange of address
essage is acknowledged using MP_CONFIRM
(<xref target="MP_CONFIRM" format="default" sectionFormat="of" derivedContent="S
ection 3.2.1"/>). This ensures reliable exchange of address
information. To avoid inconsistent states, the sender releases information. To avoid inconsistent states, the sender releases
the address ID only after MP_REMOVEADDR has been confirmed.</t> the Address ID only after MP_REMOVEADDR has been confirmed.</t>
<t indent="0" pn="section-3.2.9-8">The sending and receiving of this m <t>The sending and receiving of this message <bcp14>SHOULD</bcp14> tri
essage SHOULD trigger the closing procedure gger the closing procedure
described in <xref target="RFC4340" format="default" sectionFormat="of" derivedC described in <xref target="RFC4340"/> between the client and the server on the a
ontent="RFC4340"/> between the client and the server on the affected ffected
subflow(s), if possible. This helps remove middlebox state, before subflow(s), if possible. This helps remove middlebox state before
removing any local state.</t> removing any local state.</t>
<t indent="0" pn="section-3.2.9-9">Address removal is done by Address ID to allow the use of NATs and other <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 middleboxes that rewrite source addresses. If there is no address
at the requested Address ID, the receiver will silently ignore the request.</t> at the requested Address ID, the receiver will silently ignore the request.</t>
<figure anchor="refMP_REMOVEADDR" align="left" suppress-title="false" <figure anchor="refMP_REMOVEADDR">
pn="figure-17"> <name>Format of the MP_REMOVEADDR Suboption</name>
<name slugifiedName="name-format-of-the-mp_removeaddr">Format of the <artwork><![CDATA[
MP_REMOVEADDR suboption</name>
<artwork align="left" pn="section-3.2.9-10.1"><![CDATA[
1 2 3 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 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 | |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 | | Nonce |
+-------------------------------+-------------------------------+ +-------------------------------+-------------------------------+
Type=46 Length=8 MP_OPT=8 Type=46 Length=8 MP_OPT=8
-> followed by MP_HMAC option -> followed by the MP_HMAC option]]></artwork>
]]></artwork>
</figure> </figure>
&gt; followed by <span class="insert">the</span> MP_HMAC <span class="insert">op tion]]&gt;&lt;/artwork&gt;</span>
</section> </section>
<section anchor="MP_PRIO" numbered="true" removeInRFC="false" toc="inclu <section anchor="MP_PRIO">
de" pn="section-3.2.10"> <name>MP_PRIO</name>
<name slugifiedName="name-mp_prio">MP_PRIO</name> <t>The path priority signaled with the MP_PRIO option provides hints
<t indent="0" pn="section-3.2.10-1">The path priority signaled with th
e MP_PRIO option provides hints
for the packet scheduler when making decisions about which path to use for for the packet scheduler when making decisions about which path to use for
payload traffic. payload traffic.
When a single specific path from the set of available When a single specific path from the set of available
paths is treated with higher priority compared to the others paths is treated with higher priority compared to the others
when making scheduling decisions for payload traffic, a host can when making scheduling decisions for payload traffic, a host can
signal such change in priority to the peer. signal such change in priority to the peer.
This could be used when there are different costs for This could be used when there are different costs for
using different paths (e.g., Wi-Fi is free while cellular has limit on using different paths (e.g., Wi-Fi is free while cellular has a limit on
volume, 5G has higher energy consumption). The priority of a path volume, and 5G has higher energy consumption). The priority of a path
could also change, for example, when a mobile host runs out could also change, for example, when a mobile host runs out
of battery, the usage of only a single path may be the preferred choice of battery, and the usage of only a single path may be the preferred choice
of the user.</t> of the user.</t>
<t indent="0" pn="section-3.2.10-2">The MP_PRIO suboption, shown below , can be used to set a priority value <t>The MP_PRIO suboption, shown below, can be used to set a priority v alue
for the subflow over which the suboption is received.</t> for the subflow over which the suboption is received.</t>
<figure anchor="ref-MP_PRIO" align="left" suppress-title="false" pn="f <figure anchor="ref-MP_PRIO">
igure-18"> <name>Format of the MP_PRIO Suboption</name>
<name slugifiedName="name-format-of-the-mp_prio-subop">Format of the
MP_PRIO suboption</name> <!-- [rfced] FYI: For consistency with the other figures, we fixed the
<artwork align="left" pn="section-3.2.10-3.1"><![CDATA[ bit ruler on Figure 18. (We extended the right side of the box by one
1 2 3 space so that the placement of the final "1" is over the minus sign
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 rather than the plus sign.) Please let us know if this is not accurate.
+---------------+---------------+---------------+--------------+ -->
|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 |
+---------------+---------------+---------------+--------------+ <artwork><![CDATA[
Type=46 Length=4 MP_OPT=9 1 2 3
]]></artwork> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
|0 0 1 0 1 1 1 0|0 0 0 0 0 1 0 0|0 0 0 0 1 0 0 1|(resvd)| prio |
+---------------+---------------+---------------+---------------+
Type=46 Length=4 MP_OPT=9]]></artwork>
</figure> </figure>
<t indent="0" pn="section-3.2.10-4">The following values are available <t>The following values are available for the Prio field:</t>
for the Prio field:</t> <ul>
<ul spacing="normal" bare="false" empty="false" indent="3" pn="section <li>
-3.2.10-5"> <t>0: Do not use. The path is not available.</t>
<li pn="section-3.2.10-5.1">
<t indent="0" pn="section-3.2.10-5.1.1">0: Do not use. The path is
not available.</t>
</li> </li>
<li pn="section-3.2.10-5.2"> <li>
<t indent="0" pn="section-3.2.10-5.2.1">1: Standby: do not use thi <t>1: Standby: Do not use this path for traffic scheduling if anot
s path for traffic scheduling, if another her
path (secondary or primary) is available. The path will only be used if path (secondary or primary) is available. The path will only be used if
other secondary or primary paths are not established.</t> other secondary or primary paths are not established.</t>
</li> </li>
<li pn="section-3.2.10-5.3"> <li>
<t indent="0" pn="section-3.2.10-5.3.1">2: Secondary: do not use t <t>2: Secondary: Do not use this path for traffic scheduling if th
his path for traffic scheduling, if the other e other
paths are good enough. The path will be used occasionally for increasing paths are good enough. The path will be used occasionally for increasing
temporarily the available capacity, e.g. when primary paths are the available capacity temporarily, e.g., when primary paths are
congested or are not available. This is the recommended setting for 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 paths that have costs or data caps as these paths will be used less
frequently then primary paths.</t> frequently then primary paths.</t>
</li> </li>
<li pn="section-3.2.10-5.4"> <li>
<t indent="0" pn="section-3.2.10-5.4.1">3 - 15: Primary: The path <t>3 - 15: Primary: The path can be used for packet scheduling dec
can be used for packet scheduling decisions. The isions. The
priority number indicates the relative priority of one path over the priority number indicates the relative priority of one path over the
other for primary paths. Higher numbers indicate higher priority. other for primary paths. Higher numbers indicate higher priority.
The peer should consider sending traffic first over higher priority paths. 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 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> data caps associated with them as these paths will be frequently used.</t>
</li> </li>
</ul> </ul>
<t indent="0" pn="section-3.2.10-6">Example use cases include:</t> <t>Example use cases include:</t>
<ol spacing="normal" type="1" indent="adaptive" start="1" pn="section- <ol><li>
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 Wi-Fi path to Prim <!--[rfced] Section 3.2.10. Please confirm if "Cellular paths" should
ary and Cellular paths to Secondary. In this case 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 Seconda
ry. In this case,
Wi-Fi will be used and Cellular will be used only if the Wi-Fi path is conges ted or not Wi-Fi will be used and Cellular will be used only if the Wi-Fi path is conges ted or not
available. Such setting results in using the Cellular path only temporally, 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 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> clear priority of the Wi-Fi path over the Cellular due to, e.g., cost reasons .</t>
</li> </li>
<li pn="section-3.2.10-7.2" derivedCounter="2."> <li>
<t indent="0" pn="section-3.2.10-7.2.1">Setting Wi-Fi path to Prim <t>Setting the Wi-Fi path to Primary and Cellular path to Standby.
ary and Cellular to Standby. In this case Wi-Fi In this case, Wi-Fi
will be used and Cellular will be used only if the Wi-Fi path is not availabl e.</t> will be used and Cellular will be used only if the Wi-Fi path is not availabl e.</t>
</li> </li>
<li pn="section-3.2.10-7.3" derivedCounter="3."> <li>
<t indent="0" pn="section-3.2.10-7.3.1">Setting Wi-Fi path to Prim <t>Setting the Wi-Fi path to Primary and Cellular path to Primary.
ary and Cellular path to Primary. In this case, In this case,
both paths can be used when making packet scheduling decisions.</t> both paths can be used when making packet scheduling decisions.</t>
</li> </li>
</ol> </ol>
<t indent="0" pn="section-3.2.10-8">If not specified, the default beha vior is to always use a path for <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 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 added to an existing MP-DCCP connection. At least one path ought to have an
MP_PRIO value greater or equal to one for it to be allowed to send on the MP_PRIO value greater than or equal to one for it to be allowed to send on the
connection. It is RECOMMENDED to update at least one path to a non-zero MP_PRIO connection. It is <bcp14>RECOMMENDED</bcp14> to update at least one path to a no
n-zero MP_PRIO
value when an MP-DCCP connection enters a state where all paths remain with an 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 MP_PRIO value of zero. This helps an MP-DCCP connection to
schedule when the multipath scheduler strictly respects MP_PRIO value 0. schedule when the multipath scheduler strictly respects MP_PRIO value 0.
To ensure reliable transmission, the MP_PRIO suboption MUST be acknowledged via To ensure reliable transmission, the MP_PRIO suboption <bcp14>MUST</bcp14> be ac
an MP_CONFIRM knowledged via an MP_CONFIRM
(see <xref target="ref-mp-option-confirm" format="default" sectionFormat="of" de (see <xref target="ref-mp-option-confirm"/>).</t>
rivedContent="Table 4"/>).</t> <t>The relative ratio of the primary path values 3-15 depends on the path usage
<t indent="0" pn="section-3.2.10-9">The relative ratio of the primary strategy, which is described in more detail in <xref target="path_usage_strategy
path values 3-15 depend on the path usage strategy, which is described in more d "/>.
etail in <xref target="path_usage_strategy" format="default" sectionFormat="of"
derivedContent="Section 3.11"/>. In the case of path mobility (<xref target="pat <!--[rfced] Please clarify "and MUST be the appropriate one" - is
h_mobility" format="default" sectionFormat="of" derivedContent="Section 3.11.1"/ "appropriate one" essential to the sentence, or could it be
>), only one path can be used at a time and MUST be the appropriate one that has reworded as "the path MUST have the highest available priority
the highest available priority value including also the prio numbers 1 and 2. I value" as shown below?
n the other case of concurrent path usage (<xref target="concurrent_usage" forma
t="default" sectionFormat="of" derivedContent="Section 3.11.2"/>), the definitio Original:
n is up to the multipath scheduler logic.</t> In the case of path mobility (Section 3.11.1), only one path can be
<t indent="0" pn="section-3.2.10-10">An MP_SEQ (<xref target="MP_SEQ" used at a time and MUST be the appropriate one that has the highest
format="default" sectionFormat="of" derivedContent="Section 3.2.5"/>) MUST be pr available priority value including also the prio numbers 1 and 2.
esent in a DCCP datagram
in which the MP_PRIO suboption is sent. Further details are given in <xref targe Perhaps:
t="MP_CONFIRM" format="default" sectionFormat="of" derivedContent="Section 3.2.1 In the case of path mobility (Section 3.11.1), only one path can be
"/>.</t> 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 h
ighest available priority value including also the prio numbers 1 and 2. In the
other case of concurrent path usage (<xref target="concurrent_usage"/>), the def
inition is up to the multipath scheduler logic.</t>
<t>An MP_SEQ (<xref target="MP_SEQ"/>) <bcp14>MUST</bcp14> be present
in a DCCP datagram
in which the MP_PRIO suboption is sent. Further details are given in <xref targe
t="MP_CONFIRM"/>.</t>
</section> </section>
<section anchor="MP_CLOSE" numbered="true" removeInRFC="false" toc="incl <section anchor="MP_CLOSE">
ude" pn="section-3.2.11"> <name>MP_CLOSE</name>
<name slugifiedName="name-mp_close">MP_CLOSE</name> <figure anchor="ref-MP_CLOSE">
<figure anchor="ref-MP_CLOSE" align="left" suppress-title="false" pn=" <name>Format of the MP_CLOSE Suboption</name>
figure-19"> <artwork><![CDATA[
<name slugifiedName="name-format-of-the-mp_close-subo">Format of the 1 2 3
MP_CLOSE suboption</name> 01234567 89012345 67890123 45678901 23456789
<artwork align="left" pn="section-3.2.11-1.1"><![CDATA[ +--------+--------+--------+--------+--------+
1 2 3 |00101110| var |00001010| Key Data ...
01234567 89012345 67890123 45678901 23456789 +--------+--------+--------+--------+--------+
+--------+--------+--------+--------+--------+ Type=46 Length MP_OPT=10]]></artwork>
|00101110| var |00001010| Key Data ...
+--------+--------+--------+--------+--------+
Type=46 Length MP_OPT=10
]]></artwork>
</figure> </figure>
<t indent="0" pn="section-3.2.11-2">An MP-DCCP connection can be grace <t>An MP-DCCP connection can be gracefully closed by sending an MP_CLO
fully closed by sending and MP_CLOSE to the peer host. SE to the peer host.
On all subflows, the regular termination procedure as described in <xref target= On all subflows, the regular termination procedure described in <xref target="RF
"RFC4340" format="default" sectionFormat="of" derivedContent="RFC4340"/> C4340"/>
MUST be initiated using MP_CLOSE in the initial packet (either a DCCP-CloseReq o <bcp14>MUST</bcp14> be initiated using MP_CLOSE in the initial packet (either a
r a DCCP-Close). DCCP-CloseReq or a DCCP-Close).
When a DCCP-CloseReq is used, the following DCCP-Close MUST also carry the MP_C When a DCCP-CloseReq is used, the following DCCP-Close <bcp14>MUST</bcp14> also
LOSE carry the MP_CLOSE
to avoid keeping a state in the sender of the DCCP-CloseReq. to avoid keeping a state in the sender of the DCCP-CloseReq.
At the initiator of the DCCP-CloseReq, all sockets including the MP-DCCP connect ion socket, At the initiator of the DCCP-CloseReq, all sockets, including the MP-DCCP connec tion socket,
transition to CLOSEREQ state. transition to CLOSEREQ state.
To protect from unauthorized shutdown of a multi-path connection, the selected K
ey Data of <!--[rfced] Please clarify "in by"; is the intended meaning included
the peer host during the handshaking procedure MUST be included in by the MP_CLO "in" or "by" the MP_CLOSE option? Also, should the second "must"
SE option 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 Ke
y Data of
the peer host during the handshaking procedure <bcp14>MUST</bcp14> be included i
n by the MP_CLOSE option
and must be validated by the peer host. 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> 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 reception of the first DCCP-Clo seReq carrying an MP_CLOSE with valid Key Data, <t>On reception of the first DCCP-CloseReq carrying an MP_CLOSE with v alid Key Data,
or due to a local decision, all subflows transition to the CLOSING state or due to a local decision, all subflows transition to the CLOSING state
before transmitting a DCCP-Close carrying MP_CLOSE. before transmitting a DCCP-Close carrying MP_CLOSE.
The MP-DCCP connection socket on the host sending the DCCP-Close reflects the st ate of The MP-DCCP connection socket on the host sending the DCCP-Close reflects the st ate of
the initial subflow during handshake with MP_KEY option. the initial subflow during the handshake with MP_KEY option.
If the initial subflow no longer exists, the state moves immediately to CLOSED.< /t> If the initial subflow no longer exists, the state moves immediately to CLOSED.< /t>
<t indent="0" pn="section-3.2.11-4">Upon reception of the first DCCP-C lose carrying an MP_CLOSE with valid Key Data <t>Upon reception of the first DCCP-Close carrying an MP_CLOSE with va lid Key Data
at the peer host, all subflows, as well as the MP-DCCP connection socket, at the peer host, all subflows, as well as the MP-DCCP connection socket,
move to the CLOSED state. After this, a DCCP-Reset with Reset Code 1 move to the CLOSED state. After this, a DCCP-Reset with Reset Code 1
MUST be sent on any subflow in response to a received DCCP-Close containing a va <bcp14>MUST</bcp14> be sent on any subflow in response to a received DCCP-Close
lid MP_CLOSE option.</t> containing a valid MP_CLOSE option.</t>
<t indent="0" pn="section-3.2.11-5">When the MP-DCCP connection socket <t>When the MP-DCCP connection socket is in CLOSEREQ or CLOSE state, n
is in CLOSEREQ or CLOSE state, new subflow requests using MP_JOIN MUST be ignor ew subflow requests using MP_JOIN <bcp14>MUST</bcp14> be ignored.</t>
ed.</t> <t>Contrary to an MP_FAST_CLOSE (<xref target="MP_FAST_CLOSE"/>), no s
<t indent="0" pn="section-3.2.11-6">Contrary to an MP_FAST_CLOSE (<xre ingle-sided abrupt termination is applied.</t>
f target="MP_FAST_CLOSE" format="default" sectionFormat="of" derivedContent="Sec
tion 3.2.3"/>), no single-sided abrupt termination is applied.</t>
</section> </section>
<section anchor="MP_EXP" numbered="true" removeInRFC="false" toc="includ <section anchor="MP_EXP">
e" pn="section-3.2.12"> <name>Experimental Multipath Option MP_EXP for Private Use</name>
<name slugifiedName="name-experimental-multipath-opti">Experimental Mu <t>This section reserves a Multipath option to define and specify any
ltipath option MP_EXP for private use</name> experimental additional feature for improving and optimizing the MP-DCCP protoco
<t indent="0" pn="section-3.2.12-1">This section reserves a Multipath l. This
option to define and specify any experimental additional feature for improving a
nd optimization of the MP-DCCP protocol. This
option could be applicable to specific environments or scenarios according to po tential new requirements and is meant for private use only. MP_OPT option could be applicable to specific environments or scenarios according to po tential new requirements and is meant for private use only. MP_OPT
feature number 11 is specified with an exemplary description as below:</t> feature number 11 is specified with an exemplary description as below:</t>
<figure anchor="ref-MP_EXP" align="left" suppress-title="false" pn="fi <!--[rfced] Figure 20: May we change "Data TBD" to simply "Data",
gure-20"> as shown below? It is already explained directly below the figure:
<name slugifiedName="name-format-of-the-mp_exp-subopt">Format of the "The Data field can carry any data..."
MP_EXP suboption</name>
<artwork align="left" pn="section-3.2.12-2.1"><![CDATA[ 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 |
-->
<figure anchor="ref-MP_EXP">
<name>Format of the MP_EXP Suboption</name>
<artwork><![CDATA[
1 2 3 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 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 | |0 0 1 0 1 1 1 0| var |0 0 0 0 1 0 1 1| Data TBD |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| ... | ...
+---------------------------------------------------------------+ +---------------------------------------------------------------+
Type=46 Length MP_OPT=11 Type=46 Length MP_OPT=11]]></artwork>
]]></artwork>
</figure> </figure>
<t indent="0" pn="section-3.2.12-3">The Data field can carry any data according to the foreseen use by the experimenters with a maximum length of 252 bytes.</t> <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>
</section> </section>
<section anchor="handshaking" numbered="true" removeInRFC="false" toc="inc <section anchor="handshaking">
lude" pn="section-3.3"> <name>MP-DCCP Handshaking Procedure</name>
<name slugifiedName="name-mp-dccp-handshaking-procedu">MP-DCCP Handshaki <t>An example MP-DCCP handshake procedure is shown in <xref target="ref-
ng Procedure</name> mp-dccp-handshaking"/>.</t>
<t indent="0" pn="section-3.3-1">An example to illustrate the MP-DCCP ha <figure anchor="ref-mp-dccp-handshaking">
ndshake procedure is shown in <xref target="ref-mp-dccp-handshaking" format="def
ault" sectionFormat="of" derivedContent="Figure 21"/>.</t> <!--[rfced] FYI, in Figure 21, "DCCP-ACK" has been updated to
<figure anchor="ref-mp-dccp-handshaking" align="left" suppress-title="fa "DCCP-Ack" to match usage in the rest of the document.
lse" pn="figure-21"> -->
<name slugifiedName="name-example-mp-dccp-handshake">Example MP-DCCP h
andshake</name> <name>Example MP-DCCP Handshake</name>
<artwork align="left" pn="section-3.3-2.1"><![CDATA[ <artwork><![CDATA[
Host A Host B Host A Host B
------------------------ ---------- ------------------------ ----------
Address A1 Address A2 Address B1 Address A1 Address A2 Address B1
---------- ---------- ---------- ---------- ---------- ----------
| | | | | |
| DCCP-Request + Change R (MP_CAPABLE,...) | | DCCP-Request + Change R (MP_CAPABLE,...) |
|----- MP_KEY(CI-A + KeyA(1), KeyA(2),...) ---------->| |----- MP_KEY(CI-A + KeyA(1), KeyA(2),...) ---------->|
|<------------------- MP_KEY(CI-B + KeyB) ------------| |<------------------- MP_KEY(CI-B + KeyB) ------------|
| DCCP-Response + Confirm L (MP_CAPABLE, ...) | | DCCP-Response + Confirm L (MP_CAPABLE, ...) |
| | | | | |
skipping to change at line 1558 skipping to change at line 1711
| DCCP-Ack | | | DCCP-Ack | |
| | | | | |
| |DCCP-Request + Change R(MP_CAPABLE,...)| | |DCCP-Request + Change R(MP_CAPABLE,...)|
| |--- MP_JOIN(CI-B,RA) ----------------->| | |--- MP_JOIN(CI-B,RA) ----------------->|
| |<------MP_JOIN(CI-A,RB) + MP_HMAC(B)---| | |<------MP_JOIN(CI-A,RB) + MP_HMAC(B)---|
| |DCCP-Response+Confirm L(MP_CAPABLE,...)| | |DCCP-Response+Confirm L(MP_CAPABLE,...)|
| | | | | |
| |DCCP-Ack | | |DCCP-Ack |
| |-------- MP_HMAC(A) ------------------>| | |-------- MP_HMAC(A) ------------------>|
| |<--------------------------------------| | |<--------------------------------------|
| |DCCP-ACK | | |DCCP-Ack |]]></artwork>
]]></artwork>
</figure> </figure>
<t indent="0" pn="section-3.3-3">The basic initial handshake for the fir <t>The basic initial handshake for the first subflow is as follows:</t>
st subflow is as follows:</t> <ul>
<ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3 <li>
.3-4"> <t>Host A sends a DCCP-Request with the MP-Capable feature change
<li pn="section-3.3-4.1">
<t indent="0" pn="section-3.3-4.1.1">Host A sends a DCCP-Request wit
h the MP-Capable feature Change
request and the MP_KEY option with a Host-specific CI-A and a KeyA for request and the MP_KEY option with a Host-specific CI-A and a KeyA for
each of the supported key types as described in <xref target="MP_KEY" format="de fault" sectionFormat="of" derivedContent="Section 3.2.4"/>. CI-A is a unique ide ntifier during the each of the supported key types as described in <xref target="MP_KEY"/>. CI-A is a unique identifier during the
lifetime of an MP-DCCP connection.</t> lifetime of an MP-DCCP connection.</t>
</li> </li>
<li pn="section-3.3-4.2"> <li>
<t indent="0" pn="section-3.3-4.2.1">Host B sends a DCCP-Response wi <t>Host B sends a DCCP-Response with a Confirm feature for
th Confirm feature for
MP-Capable and the MP_Key option with a unique Host-specific CI-B and a single H ost-specific KeyB. MP-Capable and the MP_Key option with a unique Host-specific CI-B and a single H ost-specific KeyB.
The type of the key is chosen from the list of supported types The type of the key is chosen from the list of supported types
from the previous request.</t> from the previous request.</t>
</li> </li>
<li pn="section-3.3-4.3"> <li>
<t indent="0" pn="section-3.3-4.3.1">Host A sends a DCCP-Ack to conf <t>Host A sends a DCCP-Ack to confirm the proper key exchange.</t>
irm the proper key exchange.</t>
</li> </li>
<li pn="section-3.3-4.4"> <li>
<t indent="0" pn="section-3.3-4.4.1">Host B sends a DCCP-Ack to comp <t>Host B sends a DCCP-Ack to complete the handshake and set both co
lete the handshake and set both connection ends to the OPEN state.</t> nnection ends to the OPEN state.</t>
</li> </li>
</ul> </ul>
<t indent="0" pn="section-3.3-5">It should be noted that DCCP is protect <t>It should be noted that DCCP is protected against corruption of DCCP
ed against corruption of DCCP header data (section 9 of <xref target="RFC4340" f header data (<xref target="RFC4340" sectionFormat="of" section="9"/>), so no add
ormat="default" sectionFormat="of" derivedContent="RFC4340"/>), so no additional itional mechanisms beyond the general confirmation are required to ensure that t
mechanisms beyond the general confirmation are required to ensure that the head he header data has been properly received.</t>
er data has been properly received.</t> <t>Host A waits for the final DCCP-Ack from Host B before starting any
<t indent="0" pn="section-3.3-6">Host A waits for the final DCCP-Ack fro
m Host B before starting any
establishment of additional subflow connections.</t> establishment of additional subflow connections.</t>
<t indent="0" pn="section-3.3-7">The handshake for subsequent subflows b <t>The handshake for subsequent subflows, based on a successful initial
ased on a successful initial handshake, is as follows:</t>
handshake is as follows:</t> <ul>
<ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3 <li>
.3-8"> <t>Host A sends a DCCP-Request with the MP-Capable feature change
<li pn="section-3.3-8.1"> request and the MP_JOIN option with Host B's CI-B, obtained during
<t indent="0" pn="section-3.3-8.1.1">Host A sends a DCCP-Request wit the initial handshake.
h the MP-Capable feature Change
request and the MP_JOIN option with Host B's CI-B, <!--[rfced] What does "own" refer to in "own random nonce RA"?
obtained during the initial handshake. Additionally, an own random nonce
RA is transmitted with the MP_JOIN.</t> 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>
<li pn="section-3.3-8.2"> <li>
<t indent="0" pn="section-3.3-8.2.1">Host B computes the HMAC of the <t>Host B computes the HMAC of the DCCP-Request and sends a
DCCP-Request and sends a DCCP-Response DCCP-Response with a Confirm feature option for MP-Capable and the
with Confirm feature option for MP-Capable and the MP_JOIN option with MP_JOIN option with the CI-A and a random nonce RB together with
the CI-A and a random nonce RB together with the computed MP_HMAC. the computed MP_HMAC.
As specified in <xref target="MP_HMAC" format="default" sectionFormat="of" deriv
edContent="Section 3.2.6"/>, the HMAC is calculated by taking the leftmost 20 by <!--[rfced] In Section 3.3, is "message" the "HMAC Message" and "key"
tes from the SHA256 hash the "Key" described in Section 3.2.6? If so, should these terms
of a HMAC code created by using the nonce received with MP_JOIN(A) and the be capitalized as shown below? Note that there is similar text in
local nonce RB as message and the derived key described in <xref target="MP_KEY" the paragraph that follows (which refers to MP_JOIN(B)").
format="default" sectionFormat="of" derivedContent="Section 3.2.4"/> as key: <
/t> Original:
<t indent="0" pn="section-3.3-8.2.2"> As specified in Section 3.2.6, the HMAC is calculated by taking the
MP_HMAC(B) = HMAC-SHA256(Key=d-keyB, Msg=RB+RA)</t> 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 <xref 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>MP_HMAC(B) = HMAC-SHA256(Key=d-keyB, Msg=RB+RA)</t>
</li> </li>
<li pn="section-3.3-8.3"> <li>
<t indent="0" pn="section-3.3-8.3.1">Host A sends a DCCP-Ack with th <t>Host A sends a DCCP-Ack with the HMAC computed for the
e HMAC computed for the DCCP-Response. DCCP-Response. As specified in <xref target="MP_HMAC"/>, the HMAC
As specified in <xref target="MP_HMAC" format="default" sectionFormat="of" deriv is calculated by taking the leftmost 20 bytes from the SHA256 hash
edContent="Section 3.2.6"/>, the HMAC is calculated by taking the leftmost 20 by of an HMAC code created by using the local nonce RA and the nonce
tes from the SHA256 hash received with MP_JOIN(B) as message and the derived key described
of a HMAC code created by using the local nonce RA and the nonce received in <xref target="MP_KEY"/> as key: </t>
with MP_JOIN(B) as message and the derived key described in <xref target="MP_KEY <t>MP_HMAC(A) = HMAC-SHA256(Key=d-keyA, Msg=RA+RB)</t>
" format="default" sectionFormat="of" derivedContent="Section 3.2.4"/> as key:
</t>
<t indent="0" pn="section-3.3-8.3.2">
MP_HMAC(A) = HMAC-SHA256(Key=d-keyA, Msg=RA+RB)</t>
</li> </li>
<li pn="section-3.3-8.4"> <li>
<t indent="0" pn="section-3.3-8.4.1">Host B sends a DCCP-Ack to conf <t>Host B sends a DCCP-Ack to confirm the HMAC and to conclude the
irm the HMAC and to conclude the handshaking.</t>
handshaking.</t>
</li> </li>
</ul> </ul>
</section> </section>
<section anchor="address-knowledge-exchange" numbered="true" removeInRFC=" <section anchor="address-knowledge-exchange">
false" toc="include" pn="section-3.4"> <name>Address Knowledge Exchange</name>
<name slugifiedName="name-address-knowledge-exchange">Address knowledge <section anchor="advertising-a-new-path-mpaddaddr">
exchange</name> <name>Advertising a New Path (MP_ADDADDR)</name>
<section anchor="advertising-a-new-path-mpaddaddr" numbered="true" remov <t>When a host (Host A) wants to advertise the availability of a new p
eInRFC="false" toc="include" pn="section-3.4.1"> ath, it should use the MP_ADDADDR option (<xref target="MP_ADDADDR"/>) as
<name slugifiedName="name-advertising-a-new-path-mp_a">Advertising a n shown in the example in <xref target="ref-mp-dccp-add-address"/>. The MP_ADDADDR
ew path (MP_ADDADDR)</name> option passed in the DCCP-Data contains the following parameters:</t>
<t indent="0" pn="section-3.4.1-1">When a host (Host A) wants to adver <ul>
tise the availability of a new path, it should use the MP_ADDADDR option (<xref <li>
target="MP_ADDADDR" format="default" sectionFormat="of" derivedContent="Section <t>an identifier (id 2) for the new IP address, which is used as a
3.2.8"/>) as reference in subsequent control exchanges</t>
shown in the example in <xref target="ref-mp-dccp-add-address" format="default"
sectionFormat="of" derivedContent="Figure 22"/>. The MP_ADDADDR option passed in
the DCCP-Data contains the following parameters:</t>
<ul 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 identifier (id 2) for th
e new IP address which is used as a reference in subsequent control exchanges.</
t>
</li> </li>
<li pn="section-3.4.1-2.2"> <li>
<t indent="0" pn="section-3.4.1-2.2.1">a Nonce value to prevent re <t>a Nonce value to prevent replay attacks</t>
play attacks</t>
</li> </li>
<li pn="section-3.4.1-2.3"> <li>
<t indent="0" pn="section-3.4.1-2.3.1">the IP address of the new p <t>the IP address of the new path (A2_IP)</t>
ath (A2_IP)</t>
</li> </li>
<li pn="section-3.4.1-2.4"> <li>
<t indent="0" pn="section-3.4.1-2.4.1">A pair of bytes specifying <t>a pair of bytes specifying the port number associated with this
the port number associated with this IP address. The value of 00 here indicates IP address. The value of 00 here indicates that the port number is the same
that the port number is the same as that used for the initial subflow address A1_IP.</t>
as that used for the initial subflow address A1_IP</t>
</li> </li>
</ul> </ul>
<t indent="0" pn="section-3.4.1-3">According to <xref target="MP_ADDAD <t>According to <xref target="MP_ADDADDR"/>, the following options are
DR" format="default" sectionFormat="of" derivedContent="Section 3.2.8"/>, the fo required in a packet carrying MP_ADDADDR:</t>
llowing options are required in a packet carrying MP_ADDADDR:</t> <ul>
<ul spacing="normal" bare="false" empty="false" indent="3" pn="section <li>
-3.4.1-4"> <t>the leftmost 20 bytes of the HMAC(A) generated during the initi
<li pn="section-3.4.1-4.1"> al handshaking procedure described in Sections <xref target="handshaking" format
<t indent="0" pn="section-3.4.1-4.1.1">the leftmost 20 bytes of th ="counter"/> and <xref target="MP_HMAC" format="counter"/></t>
e HMAC(A) generated during the initial handshaking procedure described in <xref
target="handshaking" format="default" sectionFormat="of" derivedContent="Section
3.3"/> and <xref target="MP_HMAC" format="default" sectionFormat="of" derivedCo
ntent="Section 3.2.6"/></t>
</li> </li>
<li pn="section-3.4.1-4.2"> <li>
<t indent="0" pn="section-3.4.1-4.2.1">the MP_SEQ option with the <t>the MP_SEQ option with the sequence number (seqno 12) for this
sequence number (seqno 12) for this message according to <xref target="MP_SEQ" f message, according to <xref target="MP_SEQ"/></t>
ormat="default" sectionFormat="of" derivedContent="Section 3.2.5"/>.</t>
</li> </li>
</ul> </ul>
<t indent="0" pn="section-3.4.1-5">Host B acknowledges receipt of the MP_ADDADDR message with a DCCP-Ack containing the MP_CONFIRM option. The paramet ers supplied in this <t>Host B acknowledges receipt of the MP_ADDADDR message with a DCCP-A ck containing the MP_CONFIRM option. The parameters supplied in this
response are as follows:</t> response are as follows:</t>
<ul spacing="normal" bare="false" empty="false" indent="3" pn="section <ul>
-3.4.1-6"> <li>
<li pn="section-3.4.1-6.1"> <t>an MP_CONFIRM containing the MP_SEQ number (seqno 12) of the pa
<t indent="0" pn="section-3.4.1-6.1.1">an MP_CONFIRM containing th cket carrying the option that we are confirming together with the MP_ADDADDR opt
e MP_SEQ number (seqno 12) of the packet carrying the option that we are confirm ion</t>
ing together with the MP_ADDADDR option</t>
</li> </li>
<li pn="section-3.4.1-6.2"> <li>
<t indent="0" pn="section-3.4.1-6.2.1">the leftmost 20 bytes of th <t>the leftmost 20 bytes of the HMAC(B) generated during the initi
e HMAC(B) generated during the initial handshaking procedure <xref target="hands al handshaking procedure (<xref target="handshaking"/>)</t>
haking" format="default" sectionFormat="of" derivedContent="Section 3.3"/></t>
</li> </li>
</ul> </ul>
<figure anchor="ref-mp-dccp-add-address" align="left" suppress-title=" <figure anchor="ref-mp-dccp-add-address">
false" pn="figure-22"> <name>Example MP-DCCP ADDADDR Procedure</name>
<name slugifiedName="name-example-mp-dccp-addaddr-pro">Example MP-DC <artwork><![CDATA[
CP ADDADDR procedure</name>
<artwork align="left" pn="section-3.4.1-7.1"><![CDATA[
Host A Host B Host A Host B
------------------------ ----------- ------------------------ -----------
Address A1 Address A2 Address B1 Address A1 Address A2 Address B1
---------- ---------- ----------- ---------- ---------- -----------
| | | | | |
| DCCP-Data + MP_ADDADDR(id 2, Nonce, A2_IP, 00) + | | DCCP-Data + MP_ADDADDR(id 2, Nonce, A2_IP, 00) + |
|------- MP_HMAC(A) + MP_SEQ(seqno 12) -------------->| |------- MP_HMAC(A) + MP_SEQ(seqno 12) -------------->|
| | | | | |
| DCCP-Ack + MP_HMAC(B) + | | DCCP-Ack + MP_HMAC(B) + |
|<----- MP_CONFIRM(seqno 12, MP_ADDADDR) -------------| |<----- MP_CONFIRM(seqno 12, MP_ADDADDR) -------------|]]></artwork>
]]></artwork>
</figure> </figure>
</section> </section>
<section anchor="removing-a-path-mpremoveaddr" numbered="true" removeInR <section anchor="removing-a-path-mpremoveaddr">
FC="false" toc="include" pn="section-3.4.2"> <name>Removing a Path (MP_REMOVEADDR)</name>
<name slugifiedName="name-removing-a-path-mp_removead">Removing a path <t>When a host (Host A) wants to indicate that a path is no longer ava
(MP_REMOVEADDR)</name> ilable, it should use the MP_REMOVEADDR option (<xref target="MP_REMOVEADDR"/>)
<t indent="0" pn="section-3.4.2-1">When a host (Host A) wants to indic as
ate that a path is no longer available, it should use the MP_REMOVEADDR option ( shown in the example in <xref target="ref-mp-dccp-remove-address"/>. The MP_REMO
<xref target="MP_REMOVEADDR" format="default" sectionFormat="of" derivedContent= VEADDR option passed in the DCCP-Data contains the following parameters:</t>
"Section 3.2.9"/>) as <ul>
shown in the example in <xref target="ref-mp-dccp-remove-address" format="defaul <li>
t" sectionFormat="of" derivedContent="Figure 23"/>. The MP_REMOVEADDR option pas <t>an identifier (id 2) for the IP address to remove (A2_IP) and t
sed in the DCCP-Data contains the following parameters:</t> hat was specified in a previous MP_ADDADDR message</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 identifier (id 2) for th
e IP address to remove (A2_IP) and which was specified in a previous MP_ADDADDR
message.</t>
</li> </li>
<li pn="section-3.4.2-2.2"> <li>
<t indent="0" pn="section-3.4.2-2.2.1">a Nonce value to prevent re <t>a Nonce value to prevent replay attacks</t>
play attacks</t>
</li> </li>
</ul> </ul>
<t indent="0" pn="section-3.4.2-3">According to <xref target="MP_REMOV <t>According to <xref target="MP_REMOVEADDR"/>, the following options
EADDR" format="default" sectionFormat="of" derivedContent="Section 3.2.9"/>, the are required in a packet carrying MP_REMOVEADDR:</t>
following options are required in a packet carrying MP_REMOVEADDR:</t> <ul>
<ul spacing="normal" bare="false" empty="false" indent="3" pn="section <li>
-3.4.2-4"> <t>the leftmost 20 bytes of the HMAC(A) generated during the initi
<li pn="section-3.4.2-4.1"> al handshaking procedure described in Sections <xref target="handshaking" format
<t indent="0" pn="section-3.4.2-4.1.1">the leftmost 20 bytes of th ="counter"/> and <xref target="MP_HMAC" format="counter"/></t>
e HMAC(A) generated during the initial handshaking procedure described in <xref
target="handshaking" format="default" sectionFormat="of" derivedContent="Section
3.3"/> and <xref target="MP_HMAC" format="default" sectionFormat="of" derivedCo
ntent="Section 3.2.6"/></t>
</li> </li>
<li pn="section-3.4.2-4.2"> <li>
<t indent="0" pn="section-3.4.2-4.2.1">the MP_SEQ option with the <t>the MP_SEQ option with the sequence number (seqno 33) for this
sequence number (seqno 33) for this message according to <xref target="MP_SEQ" f message, according to <xref target="MP_SEQ"/></t>
ormat="default" sectionFormat="of" derivedContent="Section 3.2.5"/>.</t>
</li> </li>
</ul> </ul>
<t indent="0" pn="section-3.4.2-5">Host B acknowledges receipt of the MP_REMOVEADDR message with a DCCP-Ack containing the MP_CONFIRM option. The para meters supplied in this <t>Host B acknowledges receipt of the MP_REMOVEADDR message with a DCC P-Ack containing the MP_CONFIRM option. The parameters supplied in this
response are as follows:</t> response are as follows:</t>
<ul spacing="normal" bare="false" empty="false" indent="3" pn="section <ul>
-3.4.2-6"> <li>
<li pn="section-3.4.2-6.1"> <t>an MP_CONFIRM containing the MP_SEQ number (seqno 33) of the pa
<t indent="0" pn="section-3.4.2-6.1.1">an MP_CONFIRM containing th cket carrying the option that we are confirming, together with the MP_REMOVEADDR
e MP_SEQ number (seqno 33) of the packet carrying the option that we are confirm option</t>
ing, together with the MP_REMOVEADDR option</t>
</li> </li>
<li pn="section-3.4.2-6.2"> <li>
<t indent="0" pn="section-3.4.2-6.2.1">the leftmost 20 bytes of th <t>the leftmost 20 bytes of the HMAC(B) generated during the initi
e HMAC(B) generated during the initial handshaking procedure <xref target="hands al handshaking procedure (<xref target="handshaking"/>)</t>
haking" format="default" sectionFormat="of" derivedContent="Section 3.3"/></t>
</li> </li>
</ul> </ul>
<figure anchor="ref-mp-dccp-remove-address" align="left" suppress-titl <figure anchor="ref-mp-dccp-remove-address">
e="false" pn="figure-23"> <name>Example MP-DCCP REMOVEADDR Procedure</name>
<name slugifiedName="name-example-mp-dccp-removeaddr-">Example MP-DC <artwork><![CDATA[
CP REMOVEADDR procedure</name>
<artwork align="left" pn="section-3.4.2-7.1"><![CDATA[
Host A Host B Host A Host B
------------------------ ----------- ------------------------ -----------
Address A1 Address A2 Address B1 Address A1 Address A2 Address B1
---------- ---------- ----------- ---------- ---------- -----------
| | | | | |
| DCCP-Data + MP_REMOVEADDR(id 2, Nonce) + | | DCCP-Data + MP_REMOVEADDR(id 2, Nonce) + |
|------- MP_HMAC(A) + MP_SEQ(seqno 33) -------------->| |------- MP_HMAC(A) + MP_SEQ(seqno 33) -------------->|
| | | | | |
| DCCP-Ack + MP_HMAC(B) + | | DCCP-Ack + MP_HMAC(B) + |
|<----- MP_CONFIRM(seqno 33, MP_REMOVEADDR) ----------| |<----- MP_CONFIRM(seqno 33, MP_REMOVEADDR) ----------|]]></artwork>
]]></artwork>
</figure> </figure>
</section> </section>
</section> </section>
<section anchor="closing" numbered="true" removeInRFC="false" toc="include <section anchor="closing">
" pn="section-3.5"> <name>Closing an MP-DCCP Connection</name>
<name slugifiedName="name-closing-an-mp-dccp-connecti">Closing an MP-DCC <t>When a host wants to close an existing subflow but not the whole MP-D
P connection</name> CCP
<t indent="0" pn="section-3.5-1">When a host wants to close an existing connection, it <bcp14>MUST</bcp14> initiate the regular DCCP connection terminat
subflow but not the whole MP-DCCP ion procedure
connection, it MUST initiate the regular DCCP connection termination procedure as described in <xref target="RFC4340" sectionFormat="of" section="5.6"/>, i.e.,
as described in Section 5.6 of <xref target="RFC4340" format="default" sectionFo it sends a DCCP-Close/DCCP-Reset on the subflow. This
rmat="of" derivedContent="RFC4340"/>, i.e., it sends a DCCP-Close/DCCP-Reset on
the subflow. This
may be preceded by a DCCP-CloseReq. In the event of an irregular termination of a subflow, may be preceded by a DCCP-CloseReq. In the event of an irregular termination of a subflow,
e.g., during subflow establishment, it MUST use an appropriate DCCP-Reset code a s specified in IANA <xref target="DCCP.Parameter" format="default" sectionFormat ="of" derivedContent="DCCP.Parameter"/> for DCCP operations. This could be, for example, sending reset code 5 (Option Error) when an MP-DCCP e.g., during subflow establishment, it <bcp14>MUST</bcp14> use an appropriate DC CP-Reset code as specified by IANA <xref target="DCCP-PARAMETERS"/> for DCCP ope rations. 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 option provides invalid data or reset code 9 (Too Busy) when the maximum number of maintainable paths
is reached. Note that receiving a reset code 9 for secondary subflows MUST NOT i mpact already existing active is reached. Note that receiving a reset code 9 for secondary subflows <bcp14>MUS T NOT</bcp14> impact already existing active
subflows. If necessary, these subflows are terminated in a subsequent step using the procedures described in subflows. If necessary, these subflows are terminated in a subsequent step using the procedures described in
this section.</t> this section.</t>
<t indent="0" pn="section-3.5-2">A host terminates an MP-DCCP connection <t>A host terminates an MP-DCCP connection using the DCCP connection ter
using the DCCP connection termination specified in section 5.5 of mination specified in
<xref target="RFC4340" format="default" sectionFormat="of" derivedContent="RFC43 <xref target="RFC4340" sectionFormat="of" section="5.5"/> on each subflow with t
40"/> on each subflow with the first packet on each subflow carrying MP_CLOSE (s he first packet on each subflow carrying MP_CLOSE (see <xref target="MP_CLOSE"/>
ee <xref target="MP_CLOSE" format="default" sectionFormat="of" derivedContent="S ).</t>
ection 3.2.11"/>).</t> <artwork><![CDATA[
<artwork align="left" pn="section-3.5-3"><![CDATA[ Host A Host B
Host A Host B ------ ------
------ ------ <- Optional DCCP-CloseReq +
<- Optional DCCP-CloseReq + MP_CLOSE [A's key]
MP_CLOSE [A's key] [on all subflows]
[on all subflows] DCCP-Close + MP_CLOSE ->
DCCP-Close + MP_CLOSE -> [B's key] [on all subflows]
[B's key] [on all subflows] <- DCCP-Reset
<- DCCP-Reset [on all subflows]]]></artwork>
[on all subflows]
]]></artwork> <t>Additionally, an MP-DCCP connection may be closed abruptly using the
<t indent="0" pn="section-3.5-4">Additionally, an MP-DCCP connection may "Fast Close"
be closed abruptly using the "Fast Close" procedure described in <xref target="MP_FAST_CLOSE"/>, where a DCCP-Reset is sen
procedure described in <xref target="MP_FAST_CLOSE" format="default" sectionForm t on all
at="of" derivedContent="Section 3.2.3"/>, where a DCCP-Reset is sent on all
subflows, each carrying the MP_FAST_CLOSE option.</t> subflows, each carrying the MP_FAST_CLOSE option.</t>
<artwork align="left" pn="section-3.5-5"><![CDATA[
Host A Host B <artwork><![CDATA[
------ ------ Host A Host B
DCCP-Reset + MP_FAST_CLOSE -> ------ ------
[B's key] [on all subflows] DCCP-Reset + MP_FAST_CLOSE ->
<- DCCP-Reset [B's key] [on all subflows]
[on all subflows] <- DCCP-Reset
]]></artwork> [on all subflows]]]></artwork>
</section> </section>
<section anchor="fallback" numbered="true" removeInRFC="false" toc="includ <section anchor="fallback">
e" pn="section-3.6"> <name>Fallback</name>
<name slugifiedName="name-fallback">Fallback</name> <t>When a subflow fails to operate following the intended behavior of th
<t indent="0" pn="section-3.6-1">When a subflow fails to operate followi e MP-DCCP, it is
ng MP-DCCP intended behavior, it is necessary to proceed with a fallback. This may be either falling back
necessary to proceed with a fall back. This may be either falling back to regular DCCP <xref target="RFC4340"/> or removing a problematic subflow. The
to regular DCCP <xref target="RFC4340" format="default" sectionFormat="of" deriv main reasons for
edContent="RFC4340"/> or removing a problematic subflow. The main reasons for a subflow failing include: no MP support at the peer host, failure to negotiate
subflow failing include: no MP support at peer host, failure to negotiate protoc the protocol
ol version, loss of Multipath options, faulty/non-supported MP-DCCP options, or mod
version, loss of Multipath options, faulty/non-supported MP-DCCP options or modi ification
fication
of payload data.</t> of payload data.</t>
<t indent="0" pn="section-3.6-2">At the start of an MP-DCCP connection, <t>At the start of an MP-DCCP connection, the handshake ensures the exch
the handshake ensures exchange of MP-DCCP feature and ange of the MP-DCCP feature and options and thus ensures that the path is fully
options and thus ensures that the path is fully MP-DCCP capable. If during the MP-DCCP capable. If during the
handshake procedure it appears that DCCP-Request or DCCP-Response 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 messages do not carry the MP_CAPABLE feature, the MP-DCCP connection will not be
established and the handshake SHOULD fall back to regular DCCP. If this is not established and the handshake <bcp14>SHOULD</bcp14> fall back to regular DCCP. I
possible the connection MUST be closed.</t> f this is not
<t indent="0" pn="section-3.6-3">If the endpoints fail to agree on the p possible, the connection <bcp14>MUST</bcp14> be closed.</t>
rotocol version to use during the Multipath <t>If the endpoints fail to agree on the protocol version to use during
Capable feature negotiation, the connection MUST either be closed or fall back the Multipath
to regular DCCP. This is described in <xref target="mp_capable" format="default" Capable feature negotiation, the connection <bcp14>MUST</bcp14> either be closed
sectionFormat="of" derivedContent="Section 3.1"/>. The protocol version negotia or fall back
tion to regular DCCP. This is described in <xref target="mp_capable"/>. The protocol
distinguishes between negotiation for the initial connection establishment, and version negotiation
addition of subsequent subflows. If protocol version negotiation is not successf distinguishes between negotiation for the initial connection establishment and
ul the addition of subsequent subflows. If protocol version negotiation is not succ
during the initial connection establishment, MP-DCCP connection will fall back t essful
o regular DCCP.</t> during the initial connection establishment, the MP-DCCP connection will fall ba
<t indent="0" pn="section-3.6-4">The fall back procedure to regular DCCP ck to regular DCCP.</t>
MUST be also applied if the MP_KEY <xref target="MP_KEY" format="default" secti <t>The fallback procedure for regular DCCP <bcp14>MUST</bcp14> also be a
onFormat="of" derivedContent="Section 3.2.4"/> Key Type cannot be negotiated.</t pplied if the MP_KEY (<xref target="MP_KEY"/>) Key Type cannot be negotiated.</t
> >
<t indent="0" pn="section-3.6-5">If a subflow attempts to join an existi <t>If a subflow attempts to join an existing MP-DCCP connection but MP-D
ng MP-DCCP connection, but MP-DCCP options or MP_CAPABLE CCP options or the MP_CAPABLE feature are not present or are faulty in the hands
feature are not present or are faulty in the handshake procedure, that subflow M hake procedure, that subflow <bcp14>MUST</bcp14> be closed.
UST be closed. This is the case especially if a different MP_CAPABLE version than the originall
This is especially the case if a different MP_CAPABLE version than the originall y negotiated
y negotiated version is used. Reception of a non-verifiable MP_HMAC (<xref target="MP_HMAC"/>
version is used. Reception of a non-verifiable MP_HMAC (<xref target="MP_HMAC" f ) or an invalid
ormat="default" sectionFormat="of" derivedContent="Section 3.2.6"/>) or an inval CI used in MP_JOIN (<xref target="MP_JOIN"/>) during flow establishment <bcp14>M
id UST</bcp14> cause the
CI used in MP_JOIN (<xref target="MP_JOIN" format="default" sectionFormat="of" d
erivedContent="Section 3.2.2"/>) during flow establishment MUST cause the
subflow to be closed.</t> subflow to be closed.</t>
<t indent="0" pn="section-3.6-6">The subflow closing procedure MUST be a <t>The subflow closing procedure <bcp14>MUST</bcp14> also be applied if
lso applied if a final ACK carrying MP_KEY with wrong KeyA/KeyB is a final ACK carrying MP_KEY with the wrong KeyA/KeyB is
received or MP_KEY option is malformed.</t> received or the MP_KEY option is malformed.</t>
<t indent="0" pn="section-3.6-7">Another relevant case is when payload d <t>Another relevant case is when payload data is modified by middleboxes
ata is modified by middleboxes. DCCP uses . DCCP uses
checksum to protect the data, as described in section 9 of <xref target="RFC4340 a checksum to protect the data, as described in <xref target="RFC4340" sectionFo
" format="default" sectionFormat="of" derivedContent="RFC4340"/>. A checksum wil rmat="of" section="9"/>. A checksum will
l
fail if the data has been changed in any way. All data from the start of the seg ment that fail if the data has been changed in any way. All data from the start of the seg ment that
failed the checksum onwards cannot be considered trustworthy. DCCP defines that failed the checksum onwards cannot be considered trustworthy. If
if the checksum fails as defined by the DCCP, the receiving endpoint <bcp14>MUST</b
the checksum fails, the receiving endpoint MUST drop the application data and re cp14> drop the application data and report
port
that data as dropped due to corruption using a Data Dropped option (Drop Code 3, 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 af fected Corrupt). If data is dropped due to corruption for an MP-DCCP connection, the af fected
subflow MAY be closed. The same procedure applies if the MP option is unknown.</ t> subflow <bcp14>MAY</bcp14> be closed. The same procedure applies if the MP optio n is unknown.</t>
</section> </section>
<section anchor="state-diagram" numbered="true" removeInRFC="false" toc="i <section anchor="state-diagram">
nclude" pn="section-3.7"> <name>State Diagram</name>
<name slugifiedName="name-state-diagram">State Diagram</name> <t>The MP-DCCP per subflow state transitions follow the
<t indent="0" pn="section-3.7-1">The MP-DCCP per subflow state transitio state transitions defined for DCCP in <xref target="RFC4340"/> to a large extent
ns to a large extent follow the , with some modifications
state transitions defined for DCCP in <xref target="RFC4340" format="default" se due to the MP-DCCP 4-way handshake and fast close procedures. The state diagram
ctionFormat="of" derivedContent="RFC4340"/>, with some modifications below
due to the MP-DCCP four-way handshake and fast close procedures. The state diagr shows the most common state transitions. The diagram is illustrative.
am below
illustrates the most common state transitions. The diagram is illustrative.
For example, there are arcs (not shown) from several additional states For example, there are arcs (not shown) from several additional states
to TIMEWAIT, contingent on the receipt of a valid DCCP-Reset.</t> to TIMEWAIT, contingent on the receipt of a valid DCCP-Reset.</t>
<t indent="0" pn="section-3.7-2">The states transitioned
when moving from the CLOSED to OPEN state during the four-way handshake <!--[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 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 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 transmiss ion can be triggered by either the client or the server and results in the transmiss ion
of a Reset packet. The fast close procedure moves the state of the client and se rver of a Reset packet. The fast close procedure moves the state of the client and se rver
directly to TIMEWAIT and CLOSED, respectively.</t> directly to TIMEWAIT and CLOSED, respectively.</t>
<figure anchor="ref-mp-dccp-state-transition" align="left" suppress-titl <figure anchor="ref-mp-dccp-state-transition">
e="false" pn="figure-24"> <name>Most Common State Transitions of an MP-DCCP Subflow</name>
<name slugifiedName="name-most-common-state-transitio">Most common sta <artwork><![CDATA[
te transitions of an MP-DCCP subflow</name> +----------------------------+ +------------------------------+
<artwork align="left" pn="section-3.7-3.1"><![CDATA[ | v v |
+----------------------------+ +------------------------------+ | +----------+ |
| v v | | +-------------+ CLOSED +-------------+ |
| +----------+ | | | passive +----------+ active | |
| +-------------+ CLOSED +-------------+ | | | open open | |
| | passive +----------+ active | | | | snd Request | |
| | open open | | | v v |
| | snd Request | | | +-----------+ +----------+ |
| v v | | | LISTEN | | REQUEST | |
| +-----------+ +----------+ | | +-----+-----+ +----+-----+ |
| | LISTEN | | REQUEST | | | | rcv Request rcv Response | |
| +-----+-----+ +----+-----+ | | | snd Response snd Ack | |
| | rcv Request rcv Response | | | v v |
| | snd Response snd Ack | | | +-----------+ +----------+ |
| v v | | | RESPOND | | PARTOPEN | |
| +-----------+ +----------+ | | +-----+-----+ +----+-----+ |
| | RESPOND | | PARTOPEN | | | | rcv Ack rcv Ack/DataAck | |
| +-----+-----+ +----+-----+ | | | snd Ack | |
| | rcv Ack rcv Ack/DataAck | | | | +-----------+ | |
| | snd Ack | | | +------------>| OPEN |<-----------+ |
| | +-----------+ | | | +--+-+-+-+--+ |
| +------------>| OPEN |<-----------+ | | server active close | | | | active close |
| +--+-+-+-+--+ | | snd CloseReq | | | | or rcv CloseReq |
| server active close | | | | active close | | | | | | snd Close |
| snd CloseReq | | | | or rcv CloseReq | | | | | | |
| | | | | snd Close | | +-----------+ | | | | +----------+ |
| | | | | | | | CLOSEREQ |<---------+ | | +----------->| CLOSING | |
| +-----------+ | | | | +----------+ | | +-----+-----+ | | +----+-----+ |
| | CLOSEREQ |<---------+ | | +----------->| CLOSING | | | | rcv Close | | rcv Reset | |
| +-----+-----+ | | +----+-----+ | | | snd Reset | | | |
| | rcv Close | | rcv Reset | | | | | | active FastClose | |
| | snd Reset | | | | |<----------+ rcv Close | | or rcv FastClose v |
| | | | active FastClose | | | or server active FastClose | | snd Reset +----+-----+ |
|<----------+ rcv Close | | or rcv FastClose v | | or server rcv FastClose | +------------->| TIMEWAIT | |
| or server active FastClose | | snd Reset +----+-----+ | | snd Reset | +----+-----+ |
| or server rcv FastClose | +------------->| TIMEWAIT | | +------------------------------+ | |
| snd Reset | +----+-----+ | +-----------+
+------------------------------+ | | 2MSL timer expires]]></artwork>
+-----------+
2MSL timer expires
]]></artwork>
</figure> </figure>
</section> </section>
<section anchor="congestion-control-considerations" numbered="true" remove <section anchor="congestion-control-considerations">
InRFC="false" toc="include" pn="section-3.8"> <name>Congestion Control Considerations</name>
<name slugifiedName="name-congestion-control-consider">Congestion Contro <t>Senders <bcp14>MUST</bcp14> manage per-path congestion status and avo
l Considerations</name> id
<t indent="0" pn="section-3.8-1">Senders MUST manage per-path congestion sending more data on a given path than congestion control allows for each path.<
status, and avoid to /t>
sending more data on a given path than congestion control
for each path allows.</t>
</section> </section>
<section anchor="mps" numbered="true" removeInRFC="false" toc="include" pn <section anchor="mps">
="section-3.9"> <name>Maximum Packet Size Considerations</name>
<name slugifiedName="name-maximum-packet-size-conside">Maximum Packet Si <t>A DCCP implementation maintains the maximum packet size (MPS) during
ze Considerations</name> operation of a DCCP session. This procedure is specified for single-path DCCP in
<t indent="0" pn="section-3.9-1">A DCCP implementation maintains the max <xref target="RFC4340" sectionFormat="of" section="14"/>. Without any restricti
imum packet size (MPS) during operation of a DCCP session. This procedure is spe ons, this is adopted for MP-DCCP operations, in particular the Path MTU (PMTU) m
cified for single-path DCCP in <xref target="RFC4340" format="default" sectionFo easurement and the Sender Behavior. The DCCP application interface <bcp14>SHOULD
rmat="of" derivedContent="RFC4340"/>, Section 14. Without any restrictions, this </bcp14> allow the application to discover the current MPS. This reflects the cu
is adopted for MP-DCCP operations, in particular the PMTU measurement and the S rrent largest size supported for the data stream that can be used across the set
ender Behaviour. The DCCP application interface SHOULD allow the application to of all active MP-DCCP subflows.</t>
discover the current MPS. This reflects the current supported largest size for t
he data stream that can be used across the set of all active MP-DCCP subflows.</
t>
</section> </section>
<section anchor="maximum-number-of-subflows-considerations" numbered="true <section anchor="maximum-number-of-subflows-considerations">
" removeInRFC="false" toc="include" pn="section-3.10"> <name>Maximum Number of Subflow Considerations</name>
<name slugifiedName="name-maximum-number-of-subflows-">Maximum number of <t>MP-DCCP does not support any explicit procedure to negotiate
Subflows Considerations</name> the maximum number of subflows between endpoints. However, in practical
<t indent="0" pn="section-3.10-1">MP-DCCP does not support any explicit scenarios, there will be resource limitations on the host
procedure to negotiate
the maximum number of subflows between endpoints. In practical
scenarios, however, there will be resource limitations on the host
or use cases that do not benefit from additional subflows.</t> or use cases that do not benefit from additional subflows.</t>
<t indent="0" pn="section-3.10-2">It is RECOMMENDED to limit the number <t>It is <bcp14>RECOMMENDED</bcp14> to limit the number of subflows in implement
of subflows in implementations and to reject incoming subflow requests with a DC ations and to reject incoming subflow requests with a DCCP-Reset using the Reset
CP-Reset using the Reset Code "too busy" according to <xref target="RFC4340" for Code "too busy" according to <xref target="RFC4340"/> if the resource limit is
mat="default" sectionFormat="of" derivedContent="RFC4340"/> if the resource limi exceeded or it is known that the multipath connection will not benefit from furt
t is exceeded or it is known that the multipath connection will not benefit from her subflows.
further subflows. Likewise, the host that wants to create the subflows is RECOM
MENDED to consider the aspect of available resources and the possible gains.</t> <!--[rfced] Is "aspect of" essential to this sentence or may it be removed?
<t indent="0" pn="section-3.10-3">To avoid further inefficiencies with s
ubflows due to short-lived connections, it MAY be useful to delay the start of a Original:
dditional subflows. The decision on the initial number of subflows can be based Likewise, the host that wants to create the subflows is RECOMMENDED
on the occupancy of the socket buffer and/or the timing.</t> to consider the aspect of available resources and the possible
<t indent="0" pn="section-3.10-4">While in the socket buffer based appro gains.
ach the number of initial subflows can be derived by opening new subflows until
their initial windows cover the amount of buffered application data, the timing Perhaps:
based approach delays the start of additional subflows based on a certain time p Likewise, it is RECOMMENDED that the host that wants to create the
eriod, load or knowledge of traffic and path properties. The delay based approac subflows considers the available resources and possible gains.
h also provides resilience for low-bandwidth but long-lived applications. All th -->
is could also be supported by advanced APIs that signal application traffic requ
ests to the MP-DCCP.</t> Likewise, the host that wants to create the subflows is <bcp14>RECOMMENDED</bcp1
4> to consider the aspect of available resources and the possible gains.</t>
<t>To avoid further inefficiencies with subflows due to short-lived conn
ections, it <bcp14>MAY</bcp14> be useful to delay the start of additional subflo
ws. The decision on the initial number of subflows can be based on the occupancy
of the socket buffer and/or the timing.</t>
<t>While in the socket-buffer-based approach the number of initial subfl
ows can be derived by opening new subflows until their initial windows cover the
amount of buffered application data, the timing-based approach delays the start
of additional subflows based on a certain time period, load, or knowledge of tr
affic and path properties. The delay-based approach also provides resilience for
low-bandwidth but long-lived applications. All this could also be supported by
advanced APIs that signal application traffic requests to the MP-DCCP.</t>
</section> </section>
<section anchor="path_usage_strategy" numbered="true" removeInRFC="false" <section anchor="path_usage_strategy">
toc="include" pn="section-3.11"> <name>Path Usage Strategies</name>
<name slugifiedName="name-path-usage-strategies">Path usage strategies</ <t>MP-DCCP can be configured to realize one of several strategies for pa
name> th usage via selecting one DCCP subflow out of the multiple DCCP subflows within
<t indent="0" pn="section-3.11-1">MP-DCCP can be configured to realize o an MP-DCCP connection for data transmission.
ne of several strategies for path usage, via selecting one DCCP subflow of the m
ultiple DCCP subflows within an MP-DCCP connection for data transmission. This c <!--[rfced] FYI: We added semicolons to this list for better
an be a dynamic process further facilitated by the means of DCCP and MP-DCCP def readability. Please let us know if you prefer otherwise.
ined options such as path preference using MP-PRIO, adding or removing DCCP subf
lows using MP_REMOVEADDR, MP_ADDADDR or DCCP-Close/DCCP-Reset and also path metr Original:
ics such as packet-loss-rate, CWND or RTT provided by the Congestion Control Alg This can be a dynamic process further facilitated by the means of
orithm. 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 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 an
d MP-DCCP-defined options such as path preference using MP-PRIO; adding or remov
ing 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 provide
d by the Congestion Control Algorithm.
Selecting an appropriate method can allow MP-DCCP to realize different path util ization 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> Selecting an appropriate method can allow MP-DCCP to realize different path util ization strategies that make MP-DCCP suitable for end-to-end implementation over the Internet or in controlled environments such as Hybrid Access or 5G ATSSS.</ t>
<section anchor="path_mobility" numbered="true" removeInRFC="false" toc= <section anchor="path_mobility">
"include" pn="section-3.11.1"> <name>Path Mobility</name>
<name slugifiedName="name-path-mobility">Path mobility</name> <t>The path mobility strategy provides the use of a single path with a
<t indent="0" pn="section-3.11.1-1">The path mobility strategy provide seamless handover function to continue the connection when the currently used p
s the use of a single path with a seamless handover function to continue the con ath is deemed unsuitable for service delivery.
nection 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
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 lo
either the occurrence of certain error conditions (e.g., DCCP timeout, packet lo ss threshold, RTT threshold, and closed/removed) or adjustments from the MP-DCCP
ss threshold, RTT threshold, closed/removed) or adjustments from the MP-DCCP use user.
r. When there is outbound data to send and the primary path becomes inactive (e.g.,
When there is outbound data to send and the primary path becomes inactive (e.g., due to failures) or deprioritized, the MP-DCCP endpoint <bcp14>SHOULD</bcp14> t
due to failures) or de-prioritized, the MP-DCCP endpoint SHOULD try to send the ry to send the data through an alternate path with a different source or destina
data through an alternate path with a different source or destination address ( tion address (depending on the point of failure), if one exists.
depending on the point of failure), if one exists. This process SHOULD respect t
he path priority configured by the MP_PRIO suboption or if not available pick th <!--[rfced] Does "SHOULD" refer only to the first part of this
e most divergent source-destination pair from the original used source-destinati sentence? And does "if not available" refer to the "path
on pair.</t> priority"? If so, may we rephrase the text as shown below for
<ul empty="true" bare="false" indent="3" spacing="normal" pn="section- clarity?
3.11.1-2">
<li pn="section-3.11.1-2.1"> Original:
<t indent="0" pn="section-3.11.1-2.1.1">Note: Rules for picking th This process SHOULD respect the path priority configured by the MP_PRIO
e most appropriate source-destination pair are an implementation decision and ar suboption or if not available pick the most divergent source-
e not specified within this document. destination pair from the original used source-destination pair.
Path mobility is supported in the current Linux reference implementation <xref t
arget="multipath-dccp.org" format="default" sectionFormat="of" derivedContent="m Perhaps:
ultipath-dccp.org"/>.</t> This process SHOULD respect the path priority configured by the
</li> MP_PRIO suboption; otherwise, if the path priority is not
</ul> 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-d
estination pair from the original used source-destination pair.</t>
<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 <xref
target="MP-DCCP.Site"/>.</t></aside>
</section> </section>
<section anchor="concurrent_usage" numbered="true" removeInRFC="false" t <section anchor="concurrent_usage">
oc="include" pn="section-3.11.2"> <name>Concurrent Path Usage</name>
<name slugifiedName="name-concurrent-path-usage">Concurrent path usage <t>Different from a path mobility strategy, the selection between MP-D
</name> CCP
<t indent="0" pn="section-3.11.2-1">Different to a path mobility strat
egy, the selection between MP-DCCP
subflows is a per-packet decision that is a part of the multipath subflows is a per-packet decision that is a part of the multipath
scheduling process. This method would allow multiple subflows to be scheduling process. This method would allow multiple subflows to be
simultaneously used to aggregate the path resources to obtain higher simultaneously used to aggregate the path resources to obtain higher
connection throughput.<br/> connection throughput.</t>
In this scenario, the selection of congestion control, per-packet scheduling <t>In this scenario, the selection of congestion control, per-packet scheduling,
and potential re-ordering method determines a concurrent path utilization and a potential reordering method determines a concurrent path utilization
strategy and result in a particular transport characteristic. strategy and result in a particular transport characteristic.
A concurrent path usage method uses a scheduling design that could seek to A concurrent path usage method uses a scheduling design that could seek to
maximize reliability, throughput, minimizing latency, etc.</t> maximize reliability, maximize throughput, minimize latency, etc.</t>
<t indent="0" pn="section-3.11.2-2">Concurrent path usage over the Int <t>Concurrent path usage over the Internet can have implications. When
ernet can have implications. When a a
Multipath DCCP connection uses two or more paths, there is no guarantee Multipath DCCP connection uses two or more paths, there is no guarantee
that these paths are fully disjoint. When two (or more) subflows share that these paths are fully disjoint. When two (or more) subflows share
the same bottleneck, using a standard congestion control scheme could the same bottleneck, using a standard congestion control scheme could
result in an unfair distribution of the capacity with the multipath result in an unfair distribution of the capacity with the multipath
connection using more capacity than competing single path connections.<br/> connection using more capacity than competing single-path connections.</t>
Multipath TCP uses the coupled congestion control Linked Increases <t>Multipath TCP uses the coupled congestion control Linked Increases
Algorithm (LIA) specified in the experimental specification <xref target="RFC635 Algorithm (LIA) specified in an experimental specification <xref target="RFC6356
6" format="default" sectionFormat="of" derivedContent="RFC6356"/> to solve this "/> to solve this problem. This
problem. This
scheme could also be specified for Multipath DCCP. The same applies to scheme could also be specified for Multipath DCCP. The same applies to
other coupled congestion control schemes that have been proposed for other coupled congestion control schemes that have been proposed for
Multipath TCP such as Opportunistic Linked Increases Algorithm <xref target="OLI Multipath TCP such as the Opportunistic Linked Increases Algorithm <xref target=
A" format="default" sectionFormat="of" derivedContent="OLIA"/>.</t> "OLIA"/>.</t>
<t indent="0" pn="section-3.11.2-3">The specification of scheduling fo <t>The specification of scheduling for concurrent multipath and relate
r concurrent multipath and related the d
congestion control algorithms and re-ordering methods for use in the general congestion control algorithms and reordering methods for use in the general
Internet are outside the scope of this document. If, and when, the IETF Internet are outside the scope of this document. If, and when, the IETF
specifies a method for concurrent usage of multiple paths for the specifies a method for concurrent usage of multiple paths for the
general Internet, the framework specified in this document could be used to general Internet, the framework specified in this document could be used to
provide an IETF recommended method for MP-DCCP. provide an IETF-recommended method for MP-DCCP.
 </t> </t>
<t indent="0" pn="section-3.11.2-4"> </t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="security" numbered="true" removeInRFC="false" toc="include" <section anchor="security">
pn="section-4"> <name>Security Considerations</name>
<name slugifiedName="name-security-considerations">Security Considerations <t>Similar to DCCP, MP-DCCP does not provide cryptographic security
</name>
<t indent="0" pn="section-4-1">Similar to DCCP, MP-DCCP does not provide c
ryptographic security
guarantees inherently. Thus, if applications need cryptographic security guarantees inherently. Thus, if applications need cryptographic security
(integrity, authentication, confidentiality, access control, and (integrity, authentication, confidentiality, access control, and
anti-replay protection) the use of IPsec, DTLS over DCCP <xref target="RFC5238" format="default" sectionFormat="of" derivedContent="RFC5238"/> or other anti-replay protection), the use of IPsec, DTLS over DCCP <xref target="RFC5238" />, or other
end-to-end security is recommended; end-to-end security is recommended;
Secure Real-time Transport Protocol (SRTP) <xref target="RFC3711" format="defaul the Secure Real-time Transport Protocol (SRTP) <xref target="RFC3711"/> is one c
t" sectionFormat="of" derivedContent="RFC3711"/> is one candidate andidate
protocol for authentication. Together with Encryption of Header protocol for authentication. Integrity would be provided if using SRTP together
Extensions in SRTP, as provided by <xref target="RFC6904" format="default" secti with the encryption of header extensions described in <xref target="RFC6904"/>.<
onFormat="of" derivedContent="RFC6904"/>, also integrity would /t>
be provided.</t> <t>DCCP <xref target="RFC4340"/> provides protection against hijacking
<t indent="0" pn="section-4-2">DCCP <xref target="RFC4340" format="default
" sectionFormat="of" derivedContent="RFC4340"/> provides protection against hija
cking
and limits the potential impact of some denial-of-service attacks, but and limits the potential impact of some denial-of-service attacks, but
DCCP provides no inherent protection against an on-path attacker snooping on dat a DCCP provides no inherent protection against an on-path attacker snooping on dat a
packets. Regarding the security of MP-DCCP no additional risks should be packets. Regarding the security of MP-DCCP compared to regular DCCP, no addition
introduced compared to regular DCCP. The security objectives for MP-DCCP are:</t al risks should be introduced. The security objectives for MP-DCCP are:</t>
> <ul>
<ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4-3 <li>
"> <t>Provide assurance that the parties involved in an
<li pn="section-4-3.1">
<t indent="0" pn="section-4-3.1.1">Provide assurance that the parties
involved in an
MP-DCCP handshake procedure are identical to those in the original DCCP connecti on.</t> MP-DCCP handshake procedure are identical to those in the original DCCP connecti on.</t>
</li> </li>
<li pn="section-4-3.2"> <li>
<t indent="0" pn="section-4-3.2.1">Before a path is used, verify that <t>Before a path is used, verify that the new advertised path is valid
the new advertised path is valid for receiving traffic.</t> for receiving traffic.</t>
</li> </li>
<li pn="section-4-3.3"> <li>
<t indent="0" pn="section-4-3.3.1">Provide replay protection, i.e., en <t>Provide replay protection, i.e., ensure that a request to add/remov
sure that a request to add/remove a e a
subflow is 'fresh'.</t> subflow is 'fresh'.</t>
</li> </li>
<li pn="section-4-3.4"> <li>
<t indent="0" pn="section-4-3.4.1">Allow a party to limit the number o <t>Allow a party to limit the number of subflows that it allows.</t>
f subflows that it allows.</t>
</li> </li>
</ul> </ul>
<t indent="0" pn="section-4-4">To achieve these goals, MP-DCCP includes a
hash-based handshake <!-- [rfced] Should "Section 4" be "Section 3.6" where the fallback
algorithm documented in Sections <xref target="MP_KEY" format="default" sectionF scenario is discussed? Note that this sentence occurs in Section 4.
ormat="of" derivedContent="Section 3.2.4"/>, <xref target="MP_HMAC" format="defa
ult" sectionFormat="of" derivedContent="Section 3.2.6"/> and <xref target="hands Current:
haking" format="default" sectionFormat="of" derivedContent="Section 3.3"/>. The 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="counter"/>, <xref
target="MP_HMAC" format="counter"/>, and <xref target="handshaking" format="cou
nter"/>. The
security of the MP-DCCP connection depends on the use of keys that are 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 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 ca n over the network. Depending on the security requirements, different Key Types ca n
be negotiated in the handshake procedure or must follow the fallback scenario be negotiated in the handshake procedure or must follow the fallback scenario
described in <xref target="security" format="default" sectionFormat="of" derived described in <xref target="security"/>. If there are security requirements that
Content="Section 4"/>. If there are security requirements that go beyond the go beyond the
capabilities of Key Type 0, then it is RECOMMENDED that Key Type 0 is not enable capabilities of Key Type 0, then it is <bcp14>RECOMMENDED</bcp14> that Key Type
d 0 not be enabled
to avoid downgrade attacks that result in the key being exchanged as plain text. to avoid downgrade attacks that result in the key being exchanged as plain text.
To ease demultiplexing while not revealing To ease demultiplexing while not revealing
cryptographic material, subsequent subflows use the initially exchanged cryptographic material, subsequent subflows use the initially exchanged
CI information. The keys exchanged once at the beginning are CI information. The keys exchanged once at the beginning are
concatenated and used as keys for creating Hash-based Message concatenated and used as keys for creating HMACs used on subflow setup, in order
Authentication Codes (HMACs) used on subflow setup, in order to verify to verify
that the parties in the handshake of subsequent subflows are the same as in the original 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 connection setup. This also provides verification that the peer can
receive traffic at this new address. Replay attacks would still be receive traffic at this new address. Replay attacks would still be
possible when only keys are used; possible when only keys are used;
therefore, the handshakes use single-use random numbers (nonces) for both 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. 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 Guidance on generating random numbers suitable for use as keys is given
in <xref target="RFC4086" format="default" sectionFormat="of" derivedContent="RF in <xref target="RFC4086"/>. During normal operation, regular DCCP protection
C4086"/>. During normal operation, regular DCCP protection mechanisms (such as the header checksum to protect DCCP headers against
mechanisms (such as header checksum to protect DCCP headers against
corruption) is designed to provide the same level of protection against attacks on corruption) is designed to provide the same level of protection against attacks on
individual DCCP subflows as exists for regular DCCP.</t> individual DCCP subflows as exists for regular DCCP.</t>
<t indent="0" pn="section-4-5">As discussed in <xref target="MP_ADDADDR" f ormat="default" sectionFormat="of" derivedContent="Section 3.2.8"/>, a host may advertise its private <t>As discussed in <xref target="MP_ADDADDR"/>, a host may advertise its p rivate
addresses, but these might point to different hosts in the receiver's addresses, but these might point to different hosts in the receiver's
network. The MP_JOIN handshake (<xref target="MP_JOIN" format="default" section Format="of" derivedContent="Section 3.2.2"/>) is designed to ensure that this network. The MP_JOIN handshake (<xref target="MP_JOIN"/>) is designed to ensure that this
does not set up a subflow to the incorrect host. does not set up a subflow to the incorrect host.
However, it could still create unwanted DCCP handshake traffic. This However, it could still create unwanted DCCP handshake traffic. This
feature of MP-DCCP could be a target for denial-of-service exploits, feature of MP-DCCP could be a target for denial-of-service exploits,
with malicious participants in MP-DCCP connections encouraging the with malicious participants in MP-DCCP connections encouraging the
recipient to target other hosts in the network. Therefore, recipient to target other hosts in the network. Therefore,
implementations should consider heuristics at both the implementations should consider heuristics at both the
sender and receiver to reduce the impact of this.</t> sender and receiver to reduce the impact of this.</t>
<t indent="0" pn="section-4-6">As described in <xref target="mps" format=" default" sectionFormat="of" derivedContent="Section 3.9"/>, a Maximum Packet Siz e (MPS) is maintained for an MP-DCCP connection. <t>As described in <xref target="mps"/>, an MPS is maintained for an MP-DC CP connection.
If MP-DCCP exposes a minimum MPS across all paths, If MP-DCCP exposes a minimum MPS across all paths,
any change to one path impacts the sender for 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 To mitigate attacks that seek to force a low MPS, MP-DCCP
could detect an attempt to reduce the MPS less than a minimum MPS, and then could detect an attempt to reduce the MPS to less than a minimum MPS and then
stop using these paths.</t> stop using these paths.</t>
</section> </section>
<section anchor="middlebox" numbered="true" removeInRFC="false" toc="include <section anchor="middlebox">
" pn="section-5"> <name>Interactions with Middleboxes</name>
<name slugifiedName="name-interactions-with-middlebox">Interactions with M
iddleboxes</name> <!-- [rfced] We note that RFC 4043 does not contain Section 16. Please
<t indent="0" pn="section-5-1">Issues from interaction with on-path middle confirm which section should be referenced.
boxes such as NATs, firewalls, proxies,
intrusion detection systems (IDSs), and others have to be considered for all Current:
extensions to standard protocols since otherwise unexpected reactions of 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, firewall
s, proxies,
IDSs, and others have to be considered for all
extensions to standard protocols; otherwise, unexpected reactions of
middleboxes may hinder its deployment. DCCP already provides means to middleboxes may hinder its deployment. DCCP already provides means to
mitigate the potential impact of middleboxes, also in comparison to TCP (see mitigate the potential impact of middleboxes, in comparison to TCP (see
<xref target="RFC4043" format="default" sectionFormat="of" derivedContent="RFC40 <xref target="RFC4043" sectionFormat="of" section="16"/>). When both hosts are l
43"/>, Section 16). When both hosts are located behind a NAT or ocated behind a NAT or
firewall entity, specific measures have to be applied such as the <xref target=" firewall entity, specific measures have to be applied such as the
RFC5596" format="default" sectionFormat="of" derivedContent="RFC5596"/> specifie simultaneous-open technique specified in <xref target="RFC5596"/> that updates t
d he (traditionally asymmetric) connection-establishment procedures for DCCP. Fur
simultaneous-open technique that update the (traditionally asymmetric) ther standardized technologies
connection-establishment procedures for DCCP. Further standardized technologies addressing middleboxes operating as NATs are provided in <xref target="RFC5597"/
addressing middleboxes operating as NATs are provided in <xref target="RFC5597" >.</t>
format="default" sectionFormat="of" derivedContent="RFC5597"/>.</t> <t><xref target="RFC6773"/> specifies UDP encapsulation for NAT traversal
<t indent="0" pn="section-5-2"><xref target="RFC6773" format="default" sec of DCCP sessions,
tionFormat="of" derivedContent="RFC6773"/> specifies UDP Encapsulation for NAT T similar to other UDP encapsulations such as the Stream Control Transmission Prot
raversal of DCCP sessions, ocol (SCTP) <xref target="RFC6951"/>. Future
similar to other UDP encapsulations such as for SCTP <xref target="RFC6951" form
at="default" sectionFormat="of" derivedContent="RFC6951"/>. Future
specifications by the IETF could specify other methods for DCCP encapsulation.</ t> specifications by the IETF could specify other methods for DCCP encapsulation.</ t>
<t indent="0" pn="section-5-3">The security impact of MP-DCCP aware middle <t>The security impact of MP-DCCP-aware middleboxes is discussed in <xref
boxes is discussed in <xref target="security" format="default" sectionFormat="of target="security"/>.</t>
" derivedContent="Section 4"/>.</t>
</section>
<section anchor="implementation" numbered="true" removeInRFC="false" toc="in
clude" pn="section-6">
<name slugifiedName="name-implementation">Implementation</name>
<t indent="0" pn="section-6-1">The approach described above has been imple
mented in open source across different testbeds and a new scheduling algorithm h
as been extensively tested. Also,
demonstrations of a laboratory setup have been executed and have been published
at <xref target="multipath-dccp.org" format="default" sectionFormat="of" derived
Content="multipath-dccp.org"/>.</t>
</section> </section>
<section anchor="acknowledgments" numbered="true" removeInRFC="false" toc="i <section anchor="implementation">
nclude" pn="section-7"> <name>Implementation</name>
<name slugifiedName="name-acknowledgments">Acknowledgments</name> <t>The approach described above has been implemented in open source across
<t indent="0" pn="section-7-1"><xref target="RFC8684" format="default" sec different testbeds, and a new scheduling algorithm has been extensively tested.
tionFormat="of" derivedContent="RFC8684"/> defines Multipath TCP and provided im Also,
portant demonstrations of a laboratory setup have been executed and published; see <xref
inputs for this specification.</t> target="MP-DCCP.Site"/>.</t>
<t indent="0" pn="section-7-2">The authors gratefully acknowledge signific
ant input into this document from Dirk von Hugo, Nathalie Romo Moreno, Omar Nass
ef, Mohamed Boucadair, Simone Ferlin, Olivier Bonaventure, Gorry Fairhurst and B
ehcet Sarikaya.</t>
</section> </section>
<section anchor="iana-considerations" numbered="true" removeInRFC="false" to <section anchor="iana-considerations">
c="include" pn="section-8"> <name>IANA Considerations</name>
<name slugifiedName="name-iana-considerations">IANA Considerations</name> <t>This section provides guidance to the Internet Assigned Numbers Authori
<t indent="0" pn="section-8-1">This section provides guidance to the Inter ty (IANA) regarding the registration of values related to the MP extension of th
net Assigned Numbers Authority (IANA) regarding registration of values related t e DCCP protocol
o the MP extension of the DCCP protocol in accordance with the RFC Required policy in <xref target="RFC8126" sectionForm
in accordance with the RFC Required policy of <xref target="RFC8126" format="def at="of" section="4.7"/>. This document defines one new value that has been allo
ault" sectionFormat="of" derivedContent="RFC8126"/>, Section 4.7. This document cated in the IANA "DCCP Feature Numbers" registry and creates three new registri
defines one new value which is requested to be allocated in the IANA DCCP Featu es that have been added in the "Datagram Congestion Control Protocol (DCCP) Para
re Numbers registry and three new registries to be allocated in the DCCP registr meters" registry group.</t>
y group.</t> <section anchor="new-multipath-capable-dccp-feature">
<section anchor="new-multipath-capable-dccp-feature" numbered="true" remov <name>New Multipath Capable DCCP Feature</name>
eInRFC="false" toc="include" pn="section-8.1"> <t>Per this document, IANA has assigned a new DCCP feature parameter for
<name slugifiedName="name-new-multipath-capable-dccp-">New Multipath Cap negotiating
able DCCP feature</name>
<t indent="0" pn="section-8.1-1">This document requests IANA to assign a
new DCCP feature parameter for negotiating
the support of multipath capability for DCCP sessions between hosts the support of multipath capability for DCCP sessions between hosts
as described in <xref target="protocol" format="default" sectionFormat="of" deri as described in <xref target="protocol"/>. The following entry in <xref target="
vedContent="Section 3"/>. The following entry in <xref target="ref-add-feature-l ref-add-feature-list"/> has been
ist" format="default" sectionFormat="of" derivedContent="Table 6"/> should be added to the "Feature Numbers" registry in the DCCP registry group accord
added to the Feature Numbers registry in the DCCP registry group according to <x ing to <xref target="RFC4340" sectionFormat="of" section="19.4"/>.</t>
ref target="RFC4340" format="default" sectionFormat="of" derivedContent="RFC4340
"/>, Section 19.4. under the "DCCP Protocol" heading.</t> <!--[rfced] We have included some clarifications about the IANA text
<table anchor="ref-add-feature-list" align="center" pn="table-6"> below. In addition, please review all of the IANA-related updates
<name slugifiedName="name-addition-to-dccp-feature-nu">Addition to DCC carefully and let us know if any further updates are needed.
P Feature Numbers registry</name>
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/>.
-->
<table anchor="ref-add-feature-list">
<name>Addition to DCCP Feature Numbers Registry</name>
<thead> <thead>
<tr> <tr>
<th align="center" colspan="1" rowspan="1">Value</th> <th>Number</th>
<th align="center" colspan="1" rowspan="1">Feature Name</th> <th>Description/Meaning</th>
<th align="center" colspan="1" rowspan="1">Specification</th> <th>Reference</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="center" colspan="1" rowspan="1">10 suggested</td> <td>10</td>
<td align="center" colspan="1" rowspan="1">Multipath Capable</td> <td>Multipath Capable</td>
<td align="center" colspan="1" rowspan="1">[ThisDocument]</td> <td>RFC 9897</td>
</tr> </tr>
</tbody> </tbody>
</table> </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 repl
ace [ThisDocument] with a reference to the final RFC</t>
</li>
</ul>
</section> </section>
<section anchor="new-mp-dccp-version-registry" numbered="true" removeInRFC <section anchor="new-mp-dccp-version-registry">
="false" toc="include" pn="section-8.2"> <name>New MP-DCCP Versions Registry</name>
<name slugifiedName="name-new-mp-dccp-version-registr">New MP-DCCP versi <t><xref target="mp_capable"/> specifies the new 1-byte entry above that
on registry</name> includes a 4-bit part to specify the version of the used MP-DCCP implementation
<t indent="0" pn="section-8.2-1"><xref target="mp_capable" format="defau . IANA has created a new "MP-DCCP Versions" registry in the DCCP registry group
lt" sectionFormat="of" derivedContent="Section 3.1"/> specifies the new 1-byte e to track the MP-DCCP version. The initial content of this registry is as follows
ntry above includes a 4-bit part to specify the version of the used MP-DCCP impl :</t>
ementation. This document requests IANA to create a new 'MP-DCCP Versions' regis <table anchor="ref-add-version-list">
try within the DCCP registry group to track the MP-DCCP version. The initial con <name>MP-DCCP Versions Registry</name>
tent of this registry is as follows:</t>
<table anchor="ref-add-version-list" align="center" pn="table-7">
<name slugifiedName="name-mp-dccp-versions-registry">MP-DCCP Versions
Registry</name>
<thead> <thead>
<tr> <tr>
<th align="center" colspan="1" rowspan="1">Version</th> <th>Version</th>
<th align="center" colspan="1" rowspan="1">Value</th> <th>Value</th>
<th align="center" colspan="1" rowspan="1">Specification</th> <th>Reference</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="center" colspan="1" rowspan="1">0</td> <td>0</td>
<td align="center" colspan="1" rowspan="1">0000 suggested</td> <td>0000</td>
<td align="center" colspan="1" rowspan="1">[ThisDocument]</td> <td>RFC 9897</td>
</tr> </tr>
<tr> <tr>
<td align="center" colspan="1" rowspan="1">1-15</td> <td>1-15</td>
<td align="center" colspan="1" rowspan="1">unassigned</td> <td>Unassigned</td>
<td align="center" colspan="1" rowspan="1"> </td> <td> </td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<ul empty="true" bare="false" indent="3" spacing="normal" pn="section-8. <t>Future MP-DCCP versions 1 to 15 will be assigned from this registry u
2-3"> sing the RFC Required policy (<xref target="RFC8126" sectionFormat="of" section=
<li pn="section-8.2-3.1"> "4.7"/>).</t>
<t indent="0" pn="section-8.2-3.1.1">Note to RFC Editor: Please repl
ace [ThisDocument] with a reference to the final RFC</t>
</li>
</ul>
<t indent="0" pn="section-8.2-4">Future MP-DCCP versions 1 to 15 are ass
igned from this registry using the RFC Required policy (Section 4.7 of <xref tar
get="RFC8126" format="default" sectionFormat="of" derivedContent="RFC8126"/>).</
t>
</section> </section>
<section anchor="new-multipath-option-and-registry" numbered="true" remove <section anchor="new-multipath-option-and-registry">
InRFC="false" toc="include" pn="section-8.3"> <name>New Multipath Option Type and Registry</name>
<name slugifiedName="name-new-multipath-option-and-re">New Multipath opt <t>IANA has assigned value 46 in the DCCP "Option Types" registry, as de
ion and registry</name> scribed in <xref target="MP_OPT"/>.</t>
<t indent="0" pn="section-8.3-1">This document requests IANA to assign v <t>IANA has created a new "Multipath Options" registry within the DCCP r
alue 46 in the DCCP "Option Types" registry to "Multipath Options", as described egistry group. The following entries in <xref target="ref-add-proto-opt-list"/>
in <xref target="MP_OPT" format="default" sectionFormat="of" derivedContent="Se have been added to the new "Multipath Options" registry. The registry has an upp
ction 3.2"/>.</t> er boundary of 255 in the numeric value field.</t>
<t indent="0" pn="section-8.3-2">IANA is requested to create a new 'Mult
ipath Options' registry within the DCCP registry group. The following entries in <table anchor="ref-add-proto-opt-list">
<xref target="ref-add-proto-opt-list" format="default" sectionFormat="of" deriv <name>Multipath Options Registry</name>
edContent="Table 8"/> should be added to the new 'Multipath Options' registry. T
he registry in <xref target="ref-add-proto-opt-list" format="default" sectionFor
mat="of" derivedContent="Table 8"/> has an upper boundary of 255 in the numeric
value field.</t>
<table anchor="ref-add-proto-opt-list" align="center" pn="table-8">
<name slugifiedName="name-multipath-options-registry">Multipath Option
s registry</name>
<thead> <thead>
<tr> <tr>
<th align="center" colspan="1" rowspan="1">Multipath Option</th> <th>Multipath Option</th>
<th align="center" colspan="1" rowspan="1">Name</th> <th>Name</th>
<th align="center" colspan="1" rowspan="1">Description</th> <th>Description</th>
<th align="center" colspan="1" rowspan="1">Reference</th> <th>Reference</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="center" colspan="1" rowspan="1">MP_OPT=0</td> <td>MP_OPT=0</td>
<td align="center" colspan="1" rowspan="1">MP_CONFIRM</td> <td>MP_CONFIRM</td>
<td align="center" colspan="1" rowspan="1">Confirm reception/proce <td>Confirm reception/processing of an MP_OPT option</td>
ssing of an MP_OPT option</td> <td>
<td align="center" colspan="1" rowspan="1"> <xref target="MP_CONFIRM"/></td>
<xref target="MP_CONFIRM" format="default" sectionFormat="of" de
rivedContent="Section 3.2.1"/></td>
</tr> </tr>
<tr> <tr>
<td align="center" colspan="1" rowspan="1">MP_OPT=1</td> <td>MP_OPT=1</td>
<td align="center" colspan="1" rowspan="1">MP_JOIN</td> <td>MP_JOIN</td>
<td align="center" colspan="1" rowspan="1">Join subflow to an exis <td>Join subflow to an existing MP-DCCP connection</td>
ting MP-DCCP connection</td> <td>
<td align="center" colspan="1" rowspan="1"> <xref target="MP_JOIN"/></td>
<xref target="MP_JOIN" format="default" sectionFormat="of" deriv
edContent="Section 3.2.2"/></td>
</tr> </tr>
<tr> <tr>
<td align="center" colspan="1" rowspan="1">MP_OPT=2</td> <td>MP_OPT=2</td>
<td align="center" colspan="1" rowspan="1">MP_FAST_CLOSE</td> <td>MP_FAST_CLOSE</td>
<td align="center" colspan="1" rowspan="1">Close an MP-DCCP connec <td>Close an MP-DCCP connection unconditionally</td>
tion unconditionally</td> <td>
<td align="center" colspan="1" rowspan="1"> <xref target="MP_FAST_CLOSE"/></td>
<xref target="MP_FAST_CLOSE" format="default" sectionFormat="of"
derivedContent="Section 3.2.3"/></td>
</tr> </tr>
<tr> <tr>
<td align="center" colspan="1" rowspan="1">MP_OPT=3</td> <td>MP_OPT=3</td>
<td align="center" colspan="1" rowspan="1">MP_KEY</td> <td>MP_KEY</td>
<td align="center" colspan="1" rowspan="1">Exchange key material f <td>Exchange key material for MP_HMAC</td>
or MP_HMAC</td> <td>
<td align="center" colspan="1" rowspan="1"> <xref target="MP_KEY"/></td>
<xref target="MP_KEY" format="default" sectionFormat="of" derive
dContent="Section 3.2.4"/></td>
</tr> </tr>
<tr> <tr>
<td align="center" colspan="1" rowspan="1">MP_OPT=4</td> <td>MP_OPT=4</td>
<td align="center" colspan="1" rowspan="1">MP_SEQ</td> <td>MP_SEQ</td>
<td align="center" colspan="1" rowspan="1">Multipath sequence numb <td>Multipath sequence number</td>
er</td> <td>
<td align="center" colspan="1" rowspan="1"> <xref target="MP_SEQ"/></td>
<xref target="MP_SEQ" format="default" sectionFormat="of" derive
dContent="Section 3.2.5"/></td>
</tr> </tr>
<tr> <tr>
<td align="center" colspan="1" rowspan="1">MP_OPT=5</td> <td>MP_OPT=5</td>
<td align="center" colspan="1" rowspan="1">MP_HMAC</td> <td>MP_HMAC</td>
<td align="center" colspan="1" rowspan="1">Hash-based message auth <td>Hash-based message authentication code for MP-DCCP</td>
. code for MP-DCCP</td> <td>
<td align="center" colspan="1" rowspan="1"> <xref target="MP_HMAC"/></td>
<xref target="MP_HMAC" format="default" sectionFormat="of" deriv
edContent="Section 3.2.6"/></td>
</tr> </tr>
<tr> <tr>
<td align="center" colspan="1" rowspan="1">MP_OPT=6</td> <td>MP_OPT=6</td>
<td align="center" colspan="1" rowspan="1">MP_RTT</td> <td>MP_RTT</td>
<td align="center" colspan="1" rowspan="1">Transmit RTT values and <td>Transmit RTT values and calculation parameters</td>
calculation parameters</td> <td>
<td align="center" colspan="1" rowspan="1"> <xref target="MP_RTT"/></td>
<xref target="MP_RTT" format="default" sectionFormat="of" derive
dContent="Section 3.2.7"/></td>
</tr> </tr>
<tr> <tr>
<td align="center" colspan="1" rowspan="1">MP_OPT=7</td> <td>MP_OPT=7</td>
<td align="center" colspan="1" rowspan="1">MP_ADDADDR</td> <td>MP_ADDADDR</td>
<td align="center" colspan="1" rowspan="1">Advertise additional ad <td>Advertise additional address(es)/port(s)</td>
dress(es)/port(s)</td> <td>
<td align="center" colspan="1" rowspan="1"> <xref target="MP_ADDADDR"/></td>
<xref target="MP_ADDADDR" format="default" sectionFormat="of" de
rivedContent="Section 3.2.8"/></td>
</tr> </tr>
<tr> <tr>
<td align="center" colspan="1" rowspan="1">MP_OPT=8</td> <td>MP_OPT=8</td>
<td align="center" colspan="1" rowspan="1">MP_REMOVEADDR</td> <td>MP_REMOVEADDR</td>
<td align="center" colspan="1" rowspan="1">Remove address(es)/ por <td>Remove address(es)/ port(s)</td>
t(s)</td> <td>
<td align="center" colspan="1" rowspan="1"> <xref target="MP_REMOVEADDR"/></td>
<xref target="MP_REMOVEADDR" format="default" sectionFormat="of"
derivedContent="Section 3.2.9"/></td>
</tr> </tr>
<tr> <tr>
<td align="center" colspan="1" rowspan="1">MP_OPT=9</td> <td>MP_OPT=9</td>
<td align="center" colspan="1" rowspan="1">MP_PRIO</td> <td>MP_PRIO</td>
<td align="center" colspan="1" rowspan="1">Change subflow priority <td>Change subflow priority</td>
</td> <td>
<td align="center" colspan="1" rowspan="1"> <xref target="MP_PRIO"/></td>
<xref target="MP_PRIO" format="default" sectionFormat="of" deriv
edContent="Section 3.2.10"/></td>
</tr> </tr>
<tr> <tr>
<td align="center" colspan="1" rowspan="1">MP_OPT=10</td> <td>MP_OPT=10</td>
<td align="center" colspan="1" rowspan="1">MP_CLOSE</td> <td>MP_CLOSE</td>
<td align="center" colspan="1" rowspan="1">Close an MP-DCCP connec <td>Close an MP-DCCP connection</td>
tion</td> <td>
<td align="center" colspan="1" rowspan="1"> <xref target="MP_CLOSE"/></td>
<xref target="MP_CLOSE" format="default" sectionFormat="of" deri
vedContent="Section 3.2.11"/></td>
</tr> </tr>
<tr> <tr>
<td align="center" colspan="1" rowspan="1">MP_OPT=11</td> <td>MP_OPT=11</td>
<td align="center" colspan="1" rowspan="1">MP_EXP</td> <td>MP_EXP</td>
<td align="center" colspan="1" rowspan="1">Experimental option for <td>Experimental option for private use</td>
private use</td> <td>
<td align="center" colspan="1" rowspan="1"> <xref target="MP_EXP"/></td>
<xref target="MP_EXP" format="default" sectionFormat="of" derive
dContent="Section 3.2.12"/></td>
</tr> </tr>
<tr> <tr>
<td align="center" colspan="1" rowspan="1">MP_OPT&gt;11</td> <td>MP_OPT&gt;11</td>
<td align="center" colspan="1" rowspan="1">Unassigned</td> <td>Unassigned</td>
<td align="center" colspan="1" rowspan="1">Reserved for future Mul <td>Reserved for future Multipath options</td>
tipath options</td> <td> </td>
<td align="center" colspan="1" rowspan="1"> </td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t indent="0" pn="section-8.3-4">Future Multipath options with MP_OPT&gt ;11 are assigned from this registry using the RFC Required policy (Section 4.7 o f <xref target="RFC8126" format="default" sectionFormat="of" derivedContent="RFC 8126"/>).</t> <t>Future Multipath options with MP_OPT&gt;11 will be assigned from this registry using the RFC Required policy (<xref target="RFC8126" sectionFormat="o f" section="4.7"/>).</t>
</section> </section>
<section anchor="new-dccp-reset-code" numbered="true" removeInRFC="false" <section anchor="new-dccp-reset-code">
toc="include" pn="section-8.4"> <name>New DCCP-Reset Code</name>
<name slugifiedName="name-new-dccp-reset-code">New DCCP Reset Code</name <t>IANA has assigned a new DCCP-Reset Code, value 13, in the "Reset Code
> s" registry, with the description "Abrupt MP termination". Use of this reset co
<t indent="0" pn="section-8.4-1">IANA is requested to assign a new DCCP- de is defined in <xref target="MP_FAST_CLOSE"/>.</t>
Reset Code value 13 suggested in the DCCP-Reset Codes Registry, with the short d
escription "Abrupt MP termination". Use of this reset code is defined in sectio
n <xref target="MP_FAST_CLOSE" format="default" sectionFormat="of" derivedConten
t="Section 3.2.3"/>.</t>
</section> </section>
<section anchor="new-multipath-key-type-registry" numbered="true" removeIn <section anchor="new-multipath-key-type-registry">
RFC="false" toc="include" pn="section-8.5"> <name>New Multipath Key Type Registry</name>
<name slugifiedName="name-new-multipath-key-type-regi">New Multipath Key <t>IANA has created a new "Multipath Key Type" registry for this version
Type registry</name> of the MP-DCCP protocol that contains two different suboptions to the MP_KEY op
<t indent="0" pn="section-8.5-1">IANA is requested to assign for this ve tion to identify the MP_KEY Key types in terms of 8-bit values as specified in <
rsion of the MP-DCCP protocol a new 'Multipath Key Type' registry containing two xref target="MP_KEY"/>. See the initial entries in <xref target="ref-mp_key-sub
different suboptions to the MP_KEY option to identify the MP_KEY Key types in t -opt-list"/> below. Values in the range 1-254 (decimal) inclusive remain unassig
erms of 8-bit values as specified in <xref target="MP_KEY" format="default" sect ned in this specified version 0 of the protocol and will be assigned via the RFC
ionFormat="of" derivedContent="Section 3.2.4"/> according to the entries in <xre Required policy <xref target="RFC8126"/> in potential future versions of the MP
f target="ref-mp_key-sub-opt-list" format="default" sectionFormat="of" derivedCo -DCCP protocol.</t>
ntent="Table 9"/> below. Values in range 3-254 (decimal) inclusive remain unassi <table anchor="ref-mp_key-sub-opt-list">
gned in this here specified version 0 of the protocol and are assigned via RFC R <name>Multipath Key Type Registry with the MP_KEY Key Types for Key Da
equired <xref target="RFC8126" format="default" sectionFormat="of" derivedConten ta Exchange on Different Paths</name>
t="RFC8126"/>
in potential future versions of the MP-DCCP protocol.</t>
<table anchor="ref-mp_key-sub-opt-list" align="center" pn="table-9">
<name slugifiedName="name-multipath-key-type-registry">Multipath Key T
ype registry with the MP_KEY Key Types for key data exchange on different paths<
/name>
<thead> <thead>
<tr> <tr>
<th align="center" colspan="1" rowspan="1">Type</th> <th>Type</th>
<th align="center" colspan="1" rowspan="1">Name</th> <th>Name</th>
<th align="center" colspan="1" rowspan="1">Meaning</th> <th>Meaning</th>
<th align="left" colspan="1" rowspan="1">Reference</th> <th>Reference</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="center" colspan="1" rowspan="1">0</td> <td>0</td>
<td align="center" colspan="1" rowspan="1">Plain Text</td> <td>Plain Text</td>
<td align="center" colspan="1" rowspan="1">Plain text key</td> <td>Plain text key</td>
<td align="left" colspan="1" rowspan="1"> <td>
<xref target="MP_KEY" format="default" sectionFormat="of" derive <xref target="MP_KEY"/></td>
dContent="Section 3.2.4"/></td>
</tr> </tr>
<tr> <tr>
<td align="center" colspan="1" rowspan="1">1-254</td> <td>1-254</td>
<td align="center" colspan="1" rowspan="1">Unassigned</td> <td>Unassigned</td>
<td align="center" colspan="1" rowspan="1">Reserved for future use <td>Reserved for future use</td>
</td> <td>
<td align="left" colspan="1" rowspan="1"> <xref target="MP_KEY"/></td>
<xref target="MP_KEY" format="default" sectionFormat="of" derive
dContent="Section 3.2.4"/></td>
</tr> </tr>
<tr> <tr>
<td align="center" colspan="1" rowspan="1">255</td> <td>255</td>
<td align="center" colspan="1" rowspan="1">Experimental</td> <td>Experimental</td>
<td align="center" colspan="1" rowspan="1">For private use only</t <td>For private use only</td>
d> <td>
<td align="left" colspan="1" rowspan="1"> <xref target="MP_KEY"/></td>
<xref target="MP_KEY" format="default" sectionFormat="of" derive
dContent="Section 3.2.4"/></td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
</section> </section>
</middle> </middle>
<back> <back>
<references anchor="sec-combined-references" pn="section-9">
<name slugifiedName="name-references">References</name> <displayreference target="I-D.amend-iccrg-multipath-reordering" to="MULTIPATH-RE
<references anchor="sec-normative-references" pn="section-9.1"> ORDERING"/>
<name slugifiedName="name-normative-references">Normative References</na <displayreference target="I-D.amend-tsvwg-dccp-udp-header-conversion" to="U-DCCP
me> "/>
<reference anchor="DCCP.Parameter" target="https://www.iana.org/assignme
nts/dccp-parameters/dccp-parameters.xhtml" quoteTitle="true" derivedAnchor="DCCP <references anchor="sec-combined-references">
.Parameter"> <name>References</name>
<references anchor="sec-normative-references">
<name>Normative References</name>
<reference anchor="DCCP-PARAMETERS" target="https://www.iana.org/assignm
ents/dccp-parameters">
<front> <front>
<title>IANA Datagram Congestion Control Protocol (DCCP) Parameters</ title> <title>Datagram Congestion Control Protocol (DCCP) Parameters</title >
<author> <author>
<organization showOnFrontPage="true"/> <organization>IANA</organization>
</author> </author>
<date>n.d.</date>
</front>
</reference>
<reference anchor="RFC2119" quoteTitle="true" target="https://www.rfc-ed
itor.org/rfc/rfc2119" derivedAnchor="RFC2119">
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</tit
le>
<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 cap
italized. This document defines these words as they should be interpreted in IET
F 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-ed
itor.org/rfc/rfc4086" derivedAnchor="RFC4086">
<front>
<title>Randomness Requirements for Security</title>
<author fullname="D. Eastlake 3rd" initials="D." surname="Eastlake 3
rd"/>
<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 a
lgorithms that foil pattern analysis attempts. However, the security of these sy
stems is dependent on generating secret quantities for passwords, cryptographic
keys, and similar quantities. The use of pseudo-random processes to generate sec
ret quantities can result in pseudo-security. A sophisticated attacker may find
it easier to reproduce the environment that produced the secret quantities and t
o 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 pi
tfalls in using poor entropy sources or traditional pseudo-random number generat
ion techniques for generating such quantities. It recommends the use of truly ra
ndom hardware techniques and shows that the existing hardware on many systems ca
n be used for this purpose. It provides suggestions to ameliorate the problem wh
en 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 Interne
t 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-ed
itor.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 congestio
n-controlled unreliable datagrams. DCCP is suitable for applications that transf
er fairly large amounts of data and that can benefit from control over the trade
off 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-ed
itor.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 3
rd"/>
<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-ed
itor.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 t
hat use constants to identify various protocol parameters. To ensure that the va
lues in these fields do not have conflicting uses and to promote interoperabilit
y, 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, g
uidance 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. Th
is document defines a framework for the documentation of these guidelines by spe
cification authors, in order to assure that the provided guidance for the IANA C
onsiderations is clear and addresses the various issues that are likely in the o
peration of a registry.</t>
<t indent="0">This is the third edition of this document; it obsol
etes 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-ed
itor.org/rfc/rfc8174" derivedAnchor="RFC8174">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
tle>
<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 clari
fying that only UPPERCASE usage of the key words have the defined special meanin
gs.</t>
</abstract>
</front> </front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="8174"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference> </reference>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
086.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
340.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
234.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
126.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
174.xml"/>
</references> </references>
<references anchor="sec-informative-references" pn="section-9.2"> <references anchor="sec-informative-references">
<name slugifiedName="name-informative-references">Informative References <name>Informative References</name>
</name>
<reference anchor="I-D.amend-iccrg-multipath-reordering" quoteTitle="tru
e" target="https://datatracker.ietf.org/doc/html/draft-amend-iccrg-multipath-reo
rdering-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</organizatio
n>
</author>
<author fullname="Dirk Von Hugo" initials="D." surname="Von Hugo">
<organization showOnFrontPage="true">Deutsche Telekom</organizatio
n>
</author>
<date day="25" month="October" year="2021"/>
<abstract>
<t indent="0"> This document discusses the issue of packet reord
ering 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> <!-- [I-D.amend-iccrg-multipath-reordering]
</abstract> draft-amend-iccrg-multipath-reordering-03
</front> IESG State: Expired as of 10/13/25
<seriesInfo name="Internet-Draft" value="draft-amend-iccrg-multipath-r -->
eordering-03"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.
<refcontent>Work in Progress</refcontent> amend-iccrg-multipath-reordering.xml"/>
</reference>
<reference anchor="I-D.amend-tsvwg-dccp-udp-header-conversion" quoteTitl
e="true" target="https://datatracker.ietf.org/doc/html/draft-amend-tsvwg-dccp-ud
p-header-conversion-01" derivedAnchor="I-D.amend-tsvwg-dccp-udp-header-conversio
n">
<front>
<title>Lossless and overhead free DCCP - UDP header conversion (U-DC
CP)</title>
<author fullname="Markus Amend" initials="M." surname="Amend">
<organization showOnFrontPage="true">Deutsche Telekom</organizatio
n>
</author>
<author fullname="Anna Brunstrom" initials="A." surname="Brunstrom">
<organization showOnFrontPage="true">Karlstad University</organiza
tion>
</author>
<author fullname="Andreas Kassler" initials="A." surname="Kassler">
<organization showOnFrontPage="true">Karlstad University</organiza
tion>
</author>
<author fullname="Veselin Rakocevic" initials="V." surname="Rakocevi
c">
<organization showOnFrontPage="true">City University of London</or
ganization>
</author>
<date day="8" month="July" year="2019"/>
<abstract>
<t indent="0"> The Datagram Congestion Control Protocol (DCCP) i
s a transport-layer
protocol that provides upper layers with the ability to use non-
reliable congestion-controlled flows. DCCP is not widely deployed in
the Internet, and the reason for that can be defined as a typical
example of a chicken-egg problem. Even if an application developer
decided to use DCCP, the middle-boxes like firewalls and NATs would
prevent DCCP end-to-end since they lack support for DCCP. Moreover,
as long as the protocol penetration of DCCP does not increase, the
middle-boxes will not handle DCCP properly. To overcome this
challenge, NAT/NATP traversal and UDP encapsulation for DCCP is
already defined. However, the former requires special middle-box
support and the latter introduces overhead. The recent proposal of a
multipath extension for DCCP further underlines the challenge of
efficient middle-box passing as its main goal is to be applied over
the Internet, traversing numerous uncontrolled middle-boxes. This
document introduces a new solution which disguises DCCP during
transmission as UDP without requiring middle-box modification or
introducing any overhead.
</t> <!-- [I-D.amend-tsvwg-dccp-udp-header-conversion]
</abstract> draft-amend-tsvwg-dccp-udp-header-conversion-01
</front> IESG State: Expired as of 10/13/25
<seriesInfo name="Internet-Draft" value="draft-amend-tsvwg-dccp-udp-he -->
ader-conversion-01"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.
<refcontent>Work in Progress</refcontent> amend-tsvwg-dccp-udp-header-conversion.xml"/>
</reference>
<reference anchor="IETF105.Slides" target="https://datatracker.ietf.org/ <reference anchor="IETF105.Slides" target="https://datatracker.ietf.org/
meeting/105/materials/slides-105-tsvwg-sessa-62-dccp-extensions-for-multipath-op meeting/105/materials/slides-105-tsvwg-sessa-62-dccp-extensions-for-multipath-op
eration-00" quoteTitle="true" derivedAnchor="IETF105.Slides"> eration-00">
<front> <front>
<title>MP-DCCP for enabling transfer of UDP/IP traffic over multiple data paths in multi-connectivity networks</title> <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"> <author initials="M." surname="Amend" fullname="Markus Amend">
<organization showOnFrontPage="true"/> <organization/>
</author> </author>
<date>n.d.</date> <date month="July" year="2019"/>
</front> </front>
<seriesInfo name="IETF105" value=""/> <refcontent>IETF 105 Proceedings</refcontent>
</reference> </reference>
<reference anchor="MP-DCCP.Paper" quoteTitle="true" target="https://doi.
org/10.1109/LCN44214.2019.8990746" derivedAnchor="MP-DCCP.Paper"> <reference anchor="MP-DCCP.Paper" target="https://doi.org/10.1109/LCN442
14.2019.8990746">
<front> <front>
<title>A Framework for Multiaccess Support for Unreliable Internet T raffic using Multipath DCCP</title> <title>A Framework for Multiaccess Support for Unreliable Internet T raffic using Multipath DCCP</title>
<author initials="M." surname="Amend" fullname="Markus Amend"> <author initials="M." surname="Amend" fullname="Markus Amend">
<organization showOnFrontPage="true"/> <organization/>
</author> </author>
<author initials="E." surname="Bogenfeld" fullname="Eckard Bogenfeld "> <author initials="E." surname="Bogenfeld" fullname="Eckard Bogenfeld ">
<organization showOnFrontPage="true"/> <organization/>
</author> </author>
<author initials="M." surname="Cvjetkovic" fullname="Milan Cvjetkovi c"> <author initials="M." surname="Cvjetkovic" fullname="Milan Cvjetkovi c">
<organization showOnFrontPage="true"/> <organization/>
</author> </author>
<author initials="V." surname="Rakocevic" fullname="Veselin Rakocevi c"> <author initials="V." surname="Rakocevic" fullname="Veselin Rakocevi c">
<organization showOnFrontPage="true"/> <organization/>
</author> </author>
<author initials="M." surname="Pieska" fullname="Marcus Pieska"> <author initials="M." surname="Pieska" fullname="Marcus Pieska">
<organization showOnFrontPage="true"/> <organization/>
</author> </author>
<author initials="A." surname="Kassler" fullname="Andreas Kassler"> <author initials="A." surname="Kassler" fullname="Andreas Kassler">
<organization showOnFrontPage="true"/> <organization/>
</author> </author>
<author initials="A." surname="Brunstrom" fullname="Anna Brunstrom"> <author initials="A." surname="Brunstrom" fullname="Anna Brunstrom">
<organization showOnFrontPage="true"/> <organization/>
</author> </author>
<date year="2019" month="October"/> <date year="2019" month="October"/>
</front> </front>
<refcontent>2019 IEEE 44th Conference on Local Computer Networks (LCN) , pp. 316-323</refcontent>
<seriesInfo name="DOI" value="10.1109/LCN44214.2019.8990746"/> <seriesInfo name="DOI" value="10.1109/LCN44214.2019.8990746"/>
</reference> </reference>
<reference anchor="multipath-dccp.org" target="https://multipath-dccp.or
g/" quoteTitle="true" derivedAnchor="multipath-dccp.org"> <reference anchor="MP-DCCP.Site" target="https://multipath-dccp.org/">
<front> <front>
<title>Multipath extension for DCCP</title> <title>Multipath extension for DCCP</title>
<author> <author>
<organization showOnFrontPage="true"/> <organization/>
</author> </author>
<date>n.d.</date>
</front> </front>
</reference> </reference>
<reference anchor="OLIA" quoteTitle="true" derivedAnchor="OLIA">
<!-- [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>.
-->
<reference anchor="OLIA">
<front> <front>
<title>MPTCP is not pareto-optimal: performance issues and a possibl e solution</title> <title>MPTCP is not pareto-optimal: performance issues and a possibl e solution</title>
<author initials="R." surname="Khalili"> <author initials="R." surname="Khalili">
<organization showOnFrontPage="true"/> <organization/>
</author> </author>
<author initials="N." surname="Gast"> <author initials="N." surname="Gast">
<organization showOnFrontPage="true"/> <organization/>
</author> </author>
<author initials="M." surname="Popovic"> <author initials="M." surname="Popovic">
<organization showOnFrontPage="true"/> <organization/>
</author> </author>
<author initials="U." surname="Upadhyay"> <author initials="U." surname="Upadhyay">
<organization showOnFrontPage="true"/> <organization/>
</author> </author>
<author initials="J." surname="Le Boudec"> <author initials="J." surname="Le Boudec">
<organization showOnFrontPage="true"/> <organization/>
</author> </author>
<date year="2012"/> <date month="December" year="2012"/>
</front>
<seriesInfo name="Proceedings of the 8th international conference on E
merging networking experiments and technologies, ACM" value=""/>
</reference>
<reference anchor="RFC2104" quoteTitle="true" target="https://www.rfc-ed
itor.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 messag
e authentication using cryptographic hash functions. HMAC can be used with any i
terative cryptographic hash function, e.g., MD5, SHA-1, in combination with a se
cret shared key. The cryptographic strength of HMAC depends on the properties of
the underlying hash function. This memo provides information for the Internet c
ommunity. 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-ed
itor.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 Transpo
rt Protocol (SRTP), a profile of the Real-time Transport Protocol (RTP), which c
an provide confidentiality, message authentication, and replay protection to the
RTP traffic and to the control traffic for RTP, the Real-time Transport Control
Protocol (RTCP). [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3711"/>
<seriesInfo name="DOI" value="10.17487/RFC3711"/>
</reference>
<reference anchor="RFC4043" quoteTitle="true" target="https://www.rfc-ed
itor.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 per
manent identifier, that may be included in the subjectAltName extension of a pub
lic 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 to the sam
e entity, even if they contain different subject name (DNs) or different names i
n 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 o
nly unique for each subject entity certified by the one CA as defined by the iss
uer name field. However, the new name form can carry a name that is unique for e
ach 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-ed
itor.org/rfc/rfc5238" derivedAnchor="RFC5238">
<front>
<title>Datagram Transport Layer Security (DTLS) over the Datagram Co
ngestion Control Protocol (DCCP)</title>
<author fullname="T. Phelan" initials="T." surname="Phelan"/>
<date month="May" year="2008"/>
<abstract>
<t indent="0">This document specifies the use of Datagram Transpor
t Layer Security (DTLS) over the Datagram Congestion Control Protocol (DCCP). DT
LS 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 datagra
m service. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5238"/>
<seriesInfo name="DOI" value="10.17487/RFC5238"/>
</reference>
<reference anchor="RFC5280" quoteTitle="true" target="https://www.rfc-ed
itor.org/rfc/rfc5280" derivedAnchor="RFC5280">
<front>
<title>Internet X.509 Public Key Infrastructure Certificate and Cert
ificate 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.50
9 v2 certificate revocation list (CRL) for use in the Internet. An overview of t
his 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 descri
bed and two Internet-specific extensions are defined. A set of required certific
ate extensions is specified. The X.509 v2 CRL format is described in detail alon
g with standard and Internet-specific extensions. An algorithm for X.509 certifi
cation path validation is described. An ASN.1 module and examples are provided i
n 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-ed
itor.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 Co
ngestion Control Protocol (DCCP), a connection-oriented and datagram-based trans
port protocol. The update adds support for the DCCP-Listen packet. This assists
DCCP applications to communicate through middleboxes (e.g., a Network Address Po
rt Translator or a DCCP server behind a firewall), where peering endpoints need
to initiate communication in a near- simultaneous manner to establish necessary
middlebox state. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5596"/>
<seriesInfo name="DOI" value="10.17487/RFC5596"/>
</reference>
<reference anchor="RFC5597" quoteTitle="true" target="https://www.rfc-ed
itor.org/rfc/rfc5597" derivedAnchor="RFC5597">
<front>
<title>Network Address Translation (NAT) Behavioral Requirements for
the Datagram Congestion Control Protocol</title>
<author fullname="R. Denis-Courmont" initials="R." surname="Denis-Co
urmont"/>
<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 al
low DCCP applications, such as streaming applications, to operate consistently,
and they are very similar to the TCP requirements for NATs, which have already b
een published by the IETF. Ensuring that NATs meet this set of requirements will
greatly increase the likelihood that applications using DCCP will function prop
erly. This document specifies an Internet Best Current Practices for the Interne
t 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-ed
itor.org/rfc/rfc6356" derivedAnchor="RFC6356">
<front>
<title>Coupled Congestion Control for Multipath Transport Protocols<
/title>
<author fullname="C. Raiciu" initials="C." surname="Raiciu"/>
<author fullname="M. Handley" initials="M." surname="Handley"/>
<author fullname="D. Wischik" initials="D." surname="Wischik"/>
<date month="October" year="2011"/>
<abstract>
<t indent="0">Often endpoints are connected by multiple paths, but
communications are usually restricted to a single path per connection. Resource
usage within the network would be more efficient were it possible for these mul
tiple paths to be used concurrently. Multipath TCP is a proposal to achieve mult
ipath transport in TCP.</t>
<t indent="0">New congestion control algorithms are needed for mul
tipath 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 t
hat 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 trav
ersed by more than one of its subflows. Further, it is desirable that a source w
ith multiple paths available will transfer more traffic using the least congeste
d 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 failu
re.</t>
<t indent="0">This document presents a congestion control algorith
m that couples the congestion control algorithms running on different subflows b
y linking their increase functions, and dynamically controls the overall aggress
iveness 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 docum
ent 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-ed
itor.org/rfc/rfc6773" derivedAnchor="RFC6773">
<front>
<title>DCCP-UDP: A Datagram Congestion Control Protocol UDP Encapsul
ation for NAT Traversal</title>
<author fullname="T. Phelan" initials="T." surname="Phelan"/>
<author fullname="G. Fairhurst" initials="G." surname="Fairhurst"/>
<author fullname="C. Perkins" initials="C." surname="Perkins"/>
<date month="November" year="2012"/>
<abstract>
<t indent="0">This document specifies an alternative encapsulation
of the Datagram Congestion Control Protocol (DCCP), referred to as DCCP-UDP. Th
is encapsulation allows DCCP to be carried through the current generation of Net
work Address Translation (NAT) middleboxes without modification of those middleb
oxes. This document also updates the Session Description Protocol (SDP) informat
ion 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-ed
itor.org/rfc/rfc6904" derivedAnchor="RFC6904">
<front>
<title>Encryption of Header Extensions in the Secure Real-time Trans
port 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) provi
des authentication, but not encryption, of the headers of Real-time Transport Pr
otocol (RTP) packets. However, RTP header extensions may carry sensitive informa
tion for which participants in multimedia sessions want confidentiality. This do
cument provides a mechanism, extending the mechanisms of SRTP, to selectively en
crypt 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 tr
ansforms specify how RTP header extensions are to be encrypted.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6904"/>
<seriesInfo name="DOI" value="10.17487/RFC6904"/>
</reference>
<reference anchor="RFC6951" quoteTitle="true" target="https://www.rfc-ed
itor.org/rfc/rfc6951" derivedAnchor="RFC6951">
<front>
<title>UDP Encapsulation of Stream Control Transmission Protocol (SC
TP) 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 encapsula
ting Stream Control Transmission Protocol (SCTP) packets into UDP packets and it
s limitations. This allows the usage of SCTP in networks with legacy NATs that d
o not support SCTP. It can also be used to implement SCTP on hosts without direc
tly accessing the IP layer, for example, implementing it as part of the applicat
ion without requiring special privileges.</t>
<t indent="0">Please note that this document only describes the fu
nctionality 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 e
ncapsulation is being used by the peer, nor the mechanisms for determining which
remote UDP port number can be used. These functions are out of scope for this d
ocument.</t>
<t indent="0">This document covers only end-hosts and not tunnelin
g (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-ed
itor.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" surn
ame="Scheffenegger"/>
<date month="September" year="2014"/>
<abstract>
<t indent="0">This document specifies a set of TCP extensions to i
mprove performance over paths with a large bandwidth * delay product and to prov
ide reliable operation over very high-speed paths. It defines the TCP Window Sca
le (WS) option and the TCP Timestamps (TS) option and their semantics. The Windo
w Scale option is used to support larger receive windows, while the Timestamps o
ption can be used for at least two distinct mechanisms, Protection Against Wrapp
ed Sequences (PAWS) and Round-Trip Time Measurement (RTTM), that are also descri
bed herein.</t>
<t indent="0">This document obsoletes RFC 1323 and describes chang
es 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-ed
itor.org/rfc/rfc8041" derivedAnchor="RFC8041">
<front>
<title>Use Cases and Operational Experience with Multipath TCP</titl
e>
<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 operation
al experience with Multipath TCP (MPTCP) in real networks. It lists several prom
inent use cases where Multipath TCP has been considered and is being used. It al
so gives insight to some heuristics and decisions that have helped to realize th
ese 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-ed
itor.org/rfc/rfc8684" derivedAnchor="RFC8684">
<front>
<title>TCP Extensions for Multipath Operation with Multiple Addresse
s</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 si
ngle path per connection, yet multiple paths often exist between peers. The simu
ltaneous use of these multiple paths for a TCP/IP session would improve resource
usage within the network and thus improve user experience through higher throug
hput and improved resilience to network failure.</t>
<t indent="0">Multipath TCP provides the ability to simultaneously
use multiple paths between peers. This document presents a set of extensions to
traditional TCP to support multipath operation. The protocol offers the same ty
pe of service to applications as TCP (i.e., a reliable bytestream), and it provi
des the components necessary to establish and use multiple TCP flows across pote
ntially disjoint paths.</t>
<t indent="0">This document specifies v1 of Multipath TCP, obsolet
ing v0 as specified in RFC 6824, through clarifications and modifications primar
ily driven by deployment experience.</t>
</abstract>
</front> </front>
<seriesInfo name="RFC" value="8684"/> <refcontent>CoNEXT '12: Proceedings of the 8th international conferenc
<seriesInfo name="DOI" value="10.17487/RFC8684"/> e on Emerging networking experiments and technologies, pp. 1-12</refcontent>
</reference> </reference>
<reference anchor="RFC9293" quoteTitle="true" target="https://www.rfc-ed
itor.org/rfc/rfc9293" derivedAnchor="RFC9293"> <!-- Note to PE:
Updated version of [OLIA]
<reference anchor="OLIA" target="https://dl.acm.org/doi/10.1145/2413176.
2413178">
<front> <front>
<title>Transmission Control Protocol (TCP)</title> <title>MPTCP is not pareto-optimal: performance issues and a possibl
<author fullname="W. Eddy" initials="W." role="editor" surname="Eddy e solution</title>
"/> <author initials="R." surname="Khalili">
<date month="August" year="2022"/> <organization/>
<abstract> </author>
<t indent="0">This document specifies the Transmission Control Pro <author initials="N." surname="Gast">
tocol (TCP). TCP is an important transport-layer protocol in the Internet protoc <organization/>
ol stack, and it has continuously evolved over decades of use and growth of the </author>
Internet. Over this time, a number of changes have been made to TCP as it was sp <author initials="M." surname="Popovic">
ecified in RFC 793, though these have only been documented in a piecemeal fashio <organization/>
n. This document collects and brings those changes together with the protocol sp </author>
ecification from RFC 793. This document obsoletes RFC 793, as well as RFCs 879, <author initials="U." surname="Upadhyay">
2873, 6093, 6429, 6528, and 6691 that updated parts of RFC 793. It updates RFCs <organization/>
1011 and 1122, and it should be considered as a replacement for the portions of </author>
those documents dealing with TCP requirements. It also updates RFC 5961 by addin <author initials="J." surname="Le Boudec">
g a small clarification in reset handling while in the SYN-RECEIVED state. The T <organization/>
CP header control bits from RFC 793 have also been updated based on RFC 3168.</t </author>
> <date month="December" year="2012"/>
</abstract>
</front> </front>
<seriesInfo name="STD" value="7"/> <refcontent>CoNEXT '12: Proceedings of the 8th international
<seriesInfo name="RFC" value="9293"/> conference on Emerging networking experiments and
<seriesInfo name="DOI" value="10.17487/RFC9293"/> technologies, pp. 1-12</refcontent>
<seriesInfo name="DOI" value="10.1145/2413176.2413178"/>
</reference> </reference>
<reference anchor="TS23.501" target="https://www.3gpp.org/ftp//Specs/arc
hive/23_series/23.501/23501-g70.zip" quoteTitle="true" derivedAnchor="TS23.501"> -->
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
104.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
711.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
043.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
238.xml"/>
<!-- We note that [RFC5280] is not cited in the text. Would you like
to add a citation to the text or remove the reference entry from
the Informative References?
-->
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
280.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
596.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
597.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
356.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
773.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
904.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
951.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
323.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
041.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
684.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
293.xml"/>
<reference anchor="TS23.501" target="https://www.3gpp.org/ftp//Specs/arc
hive/23_series/23.501/23501-g70.zip">
<front> <front>
<title>System architecture for the 5G System; Stage 2; Release 16</t itle> <title>System architecture for the 5G System; Stage 2; Release 16</t itle>
<author> <author>
<organization showOnFrontPage="true">3GPP</organization> <organization>3GPP</organization>
</author> </author>
<date year="2020" month="December"/> <date year="2020" month="December"/>
</front> </front>
<refcontent>Version 16.7.0, Release 16</refcontent>
</reference> </reference>
</references> </references>
</references> </references>
<section anchor="diff_mptcp" numbered="true" removeInRFC="false" toc="includ <section anchor="diff_mptcp">
e" pn="section-appendix.a"> <name>Differences from Multipath TCP</name>
<name slugifiedName="name-differences-from-multipath-">Differences from Mu <t>This appendix is informative.</t>
ltipath TCP</name> <t>Multipath DCCP is similar to Multipath TCP <xref target="RFC8684"/> in
<t indent="0" pn="section-appendix.a-1">This appendix is Informative.</t> that it
<t indent="0" pn="section-appendix.a-2">Multipath DCCP is similar to Multi extends the related basic DCCP transport protocol <xref target="RFC4340"/> with
path TCP <xref target="RFC8684" format="default" sectionFormat="of" derivedConte
nt="RFC8684"/>, in that it
extends the related basic DCCP transport protocol <xref target="RFC4340" format=
"default" sectionFormat="of" derivedContent="RFC4340"/> with
multipath capabilities in the same way as Multipath TCP extends TCP multipath capabilities in the same way as Multipath TCP extends TCP
<xref target="RFC9293" format="default" sectionFormat="of" derivedContent="RFC92 93"/>. <xref target="RFC9293"/>.
However, because of the differences between the underlying TCP and DCCP However, because of the differences between the underlying TCP and DCCP
protocols, the transport characteristics of MPTCP and MP-DCCP are protocols, the transport characteristics of MPTCP and MP-DCCP are
different.</t> different.</t>
<t indent="0" pn="section-appendix.a-3"><xref target="table_tcp_dccp_comp" format="default" sectionFormat="of" derivedContent="Table 10"/> compares the pr otocol characteristics of TCP <t><xref target="table_tcp_dccp_comp"/> compares the protocol characterist ics of TCP
and DCCP, which are by nature inherited by their respective multipath and DCCP, which are by nature inherited by their respective multipath
extensions. A major difference lies in the delivery of payload, which extensions. A major difference lies in the delivery of the payload, which
is for TCP an exact copy of the generated byte-stream. DCCP behaves for TCP is an exact copy of the generated byte stream. DCCP behaves
differently and does not guarantee to deliver any payload nor the differently and does not guarantee the delivery of any payload nor the
order of delivery. order of delivery.
Since this is mainly affecting the receiving endpoint of a TCP or Since this is mainly affecting the receiving endpoint of a TCP or
DCCP communication, many similarities on the sender side can be identified. DCCP communication, many similarities on the sender side can be identified.
Both transport protocols share the 3-way initiation of a Both transport protocols share the 3-way initiation of a
communication and both employ congestion control to adapt the sending communication and both employ congestion control to adapt the sending
rate to the path characteristics.</t> rate to the path characteristics.</t>
<table anchor="table_tcp_dccp_comp" align="center" pn="table-10"> <table anchor="table_tcp_dccp_comp">
<name slugifiedName="name-tcp-and-dccp-protocol-compa">TCP and DCCP prot <name>TCP and DCCP Protocol Comparison</name>
ocol comparison</name>
<thead> <thead>
<tr> <tr>
<th align="center" colspan="1" rowspan="1">Feature</th> <th>Feature</th>
<th align="center" colspan="1" rowspan="1">TCP</th> <th>TCP</th>
<th align="center" colspan="1" rowspan="1">DCCP</th> <th>DCCP</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="center" colspan="1" rowspan="1">Full-Duplex</td> <td>Full-Duplex</td>
<td align="center" colspan="1" rowspan="1">yes</td> <td>yes</td>
<td align="center" colspan="1" rowspan="1">yes</td> <td>yes</td>
</tr> </tr>
<tr> <tr>
<td align="center" colspan="1" rowspan="1">Connection-Oriented</td> <td>Connection-Oriented</td>
<td align="center" colspan="1" rowspan="1">yes</td> <td>yes</td>
<td align="center" colspan="1" rowspan="1">yes</td> <td>yes</td>
</tr> </tr>
<tr> <tr>
<td align="center" colspan="1" rowspan="1">Header option space</td> <td>Header option space</td>
<td align="center" colspan="1" rowspan="1">40 bytes</td> <td>40 bytes</td>
<td align="center" colspan="1" rowspan="1">&lt; 1008 bytes or PMTU</ <td>&lt; 1008 bytes or PMTU</td>
td>
</tr> </tr>
<tr> <tr>
<td align="center" colspan="1" rowspan="1">Data transfer</td> <td>Data transfer</td>
<td align="center" colspan="1" rowspan="1">reliable</td> <td>reliable</td>
<td align="center" colspan="1" rowspan="1">unreliable</td> <td>unreliable</td>
</tr> </tr>
<tr> <tr>
<td align="center" colspan="1" rowspan="1">Packet-loss handling</td> <td>Packet-loss handling</td>
<td align="center" colspan="1" rowspan="1">retransmission</td> <td>retransmission</td>
<td align="center" colspan="1" rowspan="1">report only</td> <td>report only</td>
</tr> </tr>
<tr> <tr>
<td align="center" colspan="1" rowspan="1">Ordered data delivery</td <td>Ordered data delivery</td>
> <td>yes</td>
<td align="center" colspan="1" rowspan="1">yes</td> <td>no</td>
<td align="center" colspan="1" rowspan="1">no</td>
</tr> </tr>
<tr> <tr>
<td align="center" colspan="1" rowspan="1">Sequence numbers</td> <td>Sequence numbers</td>
<td align="center" colspan="1" rowspan="1">one per byte</td> <td>one per byte</td>
<td align="center" colspan="1" rowspan="1">one per PDU</td> <td>one per PDU</td>
</tr> </tr>
<tr> <tr>
<td align="center" colspan="1" rowspan="1">Flow control</td> <td>Flow control</td>
<td align="center" colspan="1" rowspan="1">yes</td> <td>yes</td>
<td align="center" colspan="1" rowspan="1">no</td> <td>no</td>
</tr> </tr>
<tr> <tr>
<td align="center" colspan="1" rowspan="1">Congestion control</td> <td>Congestion control</td>
<td align="center" colspan="1" rowspan="1">yes</td> <td>yes</td>
<td align="center" colspan="1" rowspan="1">yes</td> <td>yes</td>
</tr> </tr>
<tr> <tr>
<td align="center" colspan="1" rowspan="1">ECN support</td> <td>ECN support</td>
<td align="center" colspan="1" rowspan="1">yes</td> <td>yes</td>
<td align="center" colspan="1" rowspan="1">yes</td> <td>yes</td>
</tr> </tr>
<tr> <tr>
<td align="center" colspan="1" rowspan="1">Selective ACK</td> <td>Selective ACK</td>
<td align="center" colspan="1" rowspan="1">yes</td> <td>yes</td>
<td align="center" colspan="1" rowspan="1">depends on congestion con <td>depends on congestion control</td>
trol</td>
</tr> </tr>
<tr> <tr>
<td align="center" colspan="1" rowspan="1">Fix message boundaries</t <td>Fix message boundaries</td>
d> <td>no</td>
<td align="center" colspan="1" rowspan="1">no</td> <td>yes</td>
<td align="center" colspan="1" rowspan="1">yes</td>
</tr> </tr>
<tr> <tr>
<td align="center" colspan="1" rowspan="1">Path MTU discovery</td> <td>Path MTU discovery</td>
<td align="center" colspan="1" rowspan="1">yes</td> <td>yes</td>
<td align="center" colspan="1" rowspan="1">yes</td> <td>yes</td>
</tr> </tr>
<tr> <tr>
<td align="center" colspan="1" rowspan="1">Fragmentation</td> <td>Fragmentation</td>
<td align="center" colspan="1" rowspan="1">yes</td> <td>yes</td>
<td align="center" colspan="1" rowspan="1">no</td> <td>no</td>
</tr> </tr>
<tr> <tr>
<td align="center" colspan="1" rowspan="1">SYN flood protection</td> <td>SYN flood protection</td>
<td align="center" colspan="1" rowspan="1">yes</td> <td>yes</td>
<td align="center" colspan="1" rowspan="1">no</td> <td>no</td>
</tr> </tr>
<tr> <tr>
<td align="center" colspan="1" rowspan="1">Half-open connections</td <td>Half-open connections</td>
> <td>yes</td>
<td align="center" colspan="1" rowspan="1">yes</td> <td>no</td>
<td align="center" colspan="1" rowspan="1">no</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t indent="0" pn="section-appendix.a-5">Consequently, the multipath featur <t>Consequently, the multipath features shown in
es, shown in <xref target="table_mptcp_mpdccp_comp"/> are the same, supporting volatile paths
<xref target="table_mptcp_mpdccp_comp" format="default" sectionFormat="of" deriv that have varying capacities and latency, session handovers, and path
edContent="Table 11"/>, are the same, supporting volatile paths aggregation capabilities. All of these features profit by the existence of
having varying capacity and latency, session handover and path
aggregation capabilities. All of them profit by the existence of
congestion control.</t> congestion control.</t>
<table anchor="table_mptcp_mpdccp_comp" align="center" pn="table-11"> <table anchor="table_mptcp_mpdccp_comp">
<name slugifiedName="name-mptcp-and-mp-dccp-protocol-">MPTCP and MP-DCCP <name>MPTCP and MP-DCCP Protocol Comparison</name>
protocol comparison</name>
<thead> <thead>
<tr> <tr>
<th align="center" colspan="1" rowspan="1">Feature</th> <th>Feature</th>
<th align="center" colspan="1" rowspan="1">MPTCP</th> <th>MPTCP</th>
<th align="center" colspan="1" rowspan="1">MP-DCCP</th> <th>MP-DCCP</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="center" colspan="1" rowspan="1">Volatile paths</td> <td>Volatile paths</td>
<td align="center" colspan="1" rowspan="1">yes</td> <td>yes</td>
<td align="center" colspan="1" rowspan="1">yes</td> <td>yes</td>
</tr> </tr>
<tr> <tr>
<td align="center" colspan="1" rowspan="1">Session handover</td> <td>Session handover</td>
<td align="center" colspan="1" rowspan="1">yes</td> <td>yes</td>
<td align="center" colspan="1" rowspan="1">yes</td> <td>yes</td>
</tr> </tr>
<tr> <tr>
<td align="center" colspan="1" rowspan="1">Path aggregation</td> <td>Path aggregation</td>
<td align="center" colspan="1" rowspan="1">yes</td> <td>yes</td>
<td align="center" colspan="1" rowspan="1">yes</td> <td>yes</td>
</tr> </tr>
<tr> <tr>
<td align="center" colspan="1" rowspan="1">Data reordering</td> <td>Data reordering</td>
<td align="center" colspan="1" rowspan="1">yes</td> <td>yes</td>
<td align="center" colspan="1" rowspan="1">optional</td> <td>optional</td>
</tr> </tr>
<tr> <tr>
<td align="center" colspan="1" rowspan="1">Expandability</td> <td>Expandability</td>
<td align="center" colspan="1" rowspan="1">limited by TCP header</td <td>limited by TCP header</td>
> <td>flexible</td>
<td align="center" colspan="1" rowspan="1">flexible</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t indent="0" pn="section-appendix.a-7">Therefore, the sender logic is not much different between MP-DCCP and <t>Therefore, the sender logic is not much different between MP-DCCP and
MPTCP.</t> MPTCP.</t>
<t indent="0" pn="section-appendix.a-8">The receiver side for MP-DCCP has <t>The receiver side for MP-DCCP has to deal with the unreliable delivery
to deal with the unreliable delivery provided by provided by
DCCP. The multipath sequence numbers included in MP-DCCP (see <xref target="MP_S DCCP. The multipath sequence numbers included in MP-DCCP (see <xref target="MP_S
EQ" format="default" sectionFormat="of" derivedContent="Section 3.2.5"/>) facili EQ"/>) facilitates
tates
adding optional mechanisms for data stream packet reordering adding optional mechanisms for data stream packet reordering
at the receiver. Information from the MP_RTT multipath option (<xref target="MP at the receiver. Information from the MP_RTT multipath option (<xref target="MP
_RTT" format="default" sectionFormat="of" derivedContent="Section 3.2.7"/>), _RTT"/>),
DCCP path sequencing and the DCCP Timestamp Option provide further means DCCP path sequencing, and the DCCP Timestamp Option provide further means
for advanced reordering approaches, e.g., as proposed in <xref target="I-D.amend for advanced reordering approaches, e.g., as proposed in <xref target="I-D.amend
-iccrg-multipath-reordering" format="default" sectionFormat="of" derivedContent= -iccrg-multipath-reordering"/>.
"I-D.amend-iccrg-multipath-reordering"/>. However, such mechanisms do not affect interoperability
Such mechanisms do, however, not affect interoperability
and are not part of the MP-DCCP protocol. Many and are not part of the MP-DCCP protocol. Many
applications that use unreliable transport protocols can also inherently process applications that use unreliable transport protocols can also inherently process
out-of-sequence data (e.g., through adaptive audio and video buffers), out-of-sequence data (e.g., through adaptive audio and video buffers),
and so additional reordering support might not be necessary. The addition of opt ional so additional reordering support might not be necessary. The addition of optiona l
reordering mechanisms are likely to be needed when the reordering mechanisms are likely to be needed when the
different DCCP subflows are routed across paths with different latencies. different DCCP subflows are routed across paths with different latencies.
In theory, applications using DCCP are aware that packet reordering could In theory, applications using DCCP are aware that packet reordering could
occur, because DCCP does not provide mechanisms to restore the original packet o rder.</t> occur, because DCCP does not provide mechanisms to restore the original packet o rder.</t>
<t indent="0" pn="section-appendix.a-9">In contrast to TCP, the receiver p rocessing for MPTCP adopted a rigid <t>In contrast to TCP, the receiver processing for MPTCP adopted a rigid
"just wait" approach, because TCP guarantees reliable in-order delivery.</t> "just wait" approach, because TCP guarantees reliable in-order delivery.</t>
</section> </section>
<section anchor="authors-addresses" numbered="false" removeInRFC="false" toc <section anchor="acknowledgments" numbered="false" >
="include" pn="section-appendix.b"> <name>Acknowledgments</name>
<name slugifiedName="name-authors-addresses">Authors' Addresses</name> <t><xref target="RFC8684"/> defines Multipath TCP and provides important
<author initials="M." surname="Amend" fullname="Markus Amend" role="editor inputs for this specification.</t>
"> <t>The authors gratefully acknowledge significant input into this
<organization abbrev="DT" showOnFrontPage="true">Deutsche Telekom</organ document from <contact fullname="Dirk von Hugo"/>, <contact
ization> fullname="Nathalie Romo Moreno"/>, <contact fullname="Omar Nassef"/>,
<address> <contact fullname="Mohamed Boucadair"/>, <contact fullname="Simone
<postal> Ferlin"/>, <contact fullname="Olivier Bonaventure"/>, <contact
<street>Deutsche-Telekom-Allee 9</street> fullname="Gorry Fairhurst"/>, and <contact fullname="Behcet
<city>Darmstadt</city> Sarikaya"/>.</t>
<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</organiz
ation>
<address>
<postal>
<street>Northampton Square</street>
<city>London</city>
<country>United Kingdom</country>
</postal>
<email>veselin.rakocevic.1@city.ac.uk</email>
</address>
</author>
<author initials="S." surname="Johnson" fullname="Stephen Johnson">
<organization showOnFrontPage="true">BT</organization>
<address>
<postal>
<street>Adastral Park</street>
<city>Martlesham Heath</city>
<code>IP5 3RE</code>
<country>United Kingdom</country>
</postal>
<email>stephen.h.johnson@bt.com</email>
</address>
</author>
</section> </section>
</back> </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 hyphenat
ed
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 clari
ty.
While the NIST website
<https://web.archive.org/web/20250214092458/https://www.nist.gov/nist-research-l
ibrary/
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> </rfc>
 End of changes. 410 change blocks. 
3934 lines changed or deleted 2521 lines changed or added

This html diff was produced by rfcdiff 1.48.