RFC 9897
Datagram Congestion Control Protocol (DCCP) Extensions for Multipath Operation with Multiple Addresses
RFC 9897: Datagram Congestion Control Protocol (DCCP) Extensions for Multipath Operation with Multiple Addresses 🦋
Title block tea ☕
- RFC number: 9897
- Category: Standards Track (an Internet Standards Track document 💅)
- ISSN: 2070-1721
- Date: January 2026
- Stream: Internet Engineering Task Force (IETF)
- Authors: M. Amend, Ed. (DT), A. Brunstrom (Karlstad University), A. Kassler (Karlstad University), V. Rakocevic (City St George's, University of London), and S. Johnson (BT). The squad is iconic 👑
- Obsoletes / Updates: the title block doesn't list anything this RFC obsoletes or updates 🌸
Abstract
Okay so, DCCP (Datagram Congestion Control Protocol) connections, as defined in RFC 4340, are stuck on one path per connection 🙈 even when a device has several network paths to its peer. Using multiple paths at once for a single DCCP session can boost network resource utilization, improve throughput, and make things more resilient when links fail. Basically, a better user experience ✨
Multipath DCCP (MP-DCCP) is giving main character energy for mobile devices like handsets and vehicles, plus residential home gateways. These devices keep connections open over different network types at the same time, like cellular plus Wireless Local Area Networks (WLANs), or cellular plus fixed access networks 📶. Compared to existing multipath transports like Multipath TCP (MPTCP), MP-DCCP is especially well suited to latency-sensitive apps that have different needs for reliability and in-order delivery 🦋
This document specifies a set of extensions to DCCP that make multipath operation possible. These extensions keep the same service model as DCCP, and they add mechanisms to set up and use several concurrent DCCP flows across different network paths 💜
Status of This Memo
This is an Internet Standards Track document. 🎀
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9897. 🔗
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. ⭐
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) 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.
Table of Contents 🧚
1. Introduction
1.1. Multipath DCCP in the Networking Stack
1.2. Terminology
1.3. Requirements Language
2. Operation Overview
2.1. MP-DCCP Concept
3. MP-DCCP Protocol
3.1. Multipath Capable Feature
3.2. Multipath Option
3.2.1. MP_CONFIRM
3.2.2. MP_JOIN
3.2.3. MP_FAST_CLOSE
3.2.4. MP_KEY
3.2.5. MP_SEQ
3.2.6. MP_HMAC
3.2.7. MP_RTT
3.2.8. MP_ADDADDR
3.2.9. MP_REMOVEADDR
3.2.10. MP_PRIO
3.2.11. MP_CLOSE
3.2.12. Experimental Multipath Option MP_EXP for Private Use
3.3. MP-DCCP Handshake Procedure
3.4. Address Knowledge Exchange
3.4.1. Advertising a New Path (MP_ADDADDR)
3.4.2. Removing a Path (MP_REMOVEADDR)
3.5. Closing an MP-DCCP Connection
3.6. Fallback
3.7. State Diagram
3.8. Congestion Control Considerations
3.9. Maximum Packet Size Considerations
3.10. Maximum Number of Subflow Considerations
3.11. Path Usage Strategies
3.11.1. Path Mobility
3.11.2. Concurrent Path Usage
4. Security Considerations
5. Interactions with Middleboxes
6. Implementation
7. IANA Considerations
7.1. New Multipath Capable DCCP Feature
7.2. New MP-DCCP Versions Registry
7.3. New Multipath Option Type and Registry
7.4. New DCCP-Reset Code
7.5. New Multipath Key Type Registry
8. References
8.1. Normative References
8.2. Informative References
Appendix A. Differences from Multipath TCP
Acknowledgments
Authors' Addresses1. Introduction ✨
The Datagram Congestion Control Protocol (DCCP) [RFC4340] is a transport protocol that gives you bidirectional unicast connections made of congestion-controlled unreliable datagrams. DCCP connections are limited to one single path, though. The other basics of DCCP are summed up in Section 1 of [RFC4340], like the reliable handshake in Section 4.7 of [RFC4340] and the reliable feature negotiation in Section 4.5 of [RFC4340]. Those are the foundation this document builds on 🫶 The same goes for the packet-based DCCP sequencing scheme (Section 4.2 of [RFC4340]) and the rules for loss and retransmission of features, which are explained in more detail in Section 6.6.3 of [RFC4340]. This document changes DCCP so it supports multipath. That means signaling and setting up multiple paths (a.k.a., "subflows"), managing those subflows, reordering data, and ending sessions 🌈
Multipath DCCP (MP-DCCP) lets a DCCP connection establish a flow across multiple paths at the same time. This is great for apps that move large amounts of data, since they can use the capacity and connectivity of several paths at once 💖 Multipath extensions also let you trade off timeliness against reliability. That matters for low-latency apps that don't need guaranteed delivery, like audio and video streaming 🎀
Beyond DCCP services, implementers or future specifications could pick MP-DCCP for other use cases too, like 3GPP 5G multi-access solutions. One example is Access Traffic Steering, Switching, and Splitting (ATSSS), which is specified in [TS23.501]. Another is hybrid access networks. ATSSS combines 3GPP and non-3GPP access between the user equipment and an operator network. Hybrid access combines fixed and cellular access between a residential gateway and an operator network. In these scenarios MP-DCCP can be used for load balancing, seamless session handover, and bandwidth aggregation, when non-DCCP traffic such as IP, UDP, or TCP gets encapsulated into MP-DCCP 🧚 More details on potential MP-DCCP use cases are in [MP-DCCP.Site], [IETF105.Slides], and [MP-DCCP.Paper]. All of these use cases benefit from an Open Source Linux reference implementation provided under [MP-DCCP.Site] 💅
Encapsulating non-DCCP traffic (like UDP or IP) in MP-DCCP to enable the use cases above is not part of this specification 🙅 Also out of scope is encapsulating DCCP traffic in UDP so it can get past middleboxes (like NATs, firewalls, proxies, intrusion detection systems (IDSs), and so on) that don't support DCCP. A possible method is defined in [RFC6773], and [U-DCCP] considers a way to do the same thing with less overhead 🦋
MP-DCCP is based entirely on the lean concept of DCCP 🍓 For traffic that is already encrypted, or that doesn't need encryption, MP-DCCP is an efficient choice, because it doesn't apply its own encryption mechanisms. The MP-DCCP procedures also allow later reordering of traffic and efficient traffic scheduling, which improve performance as shown in [MP-DCCP.Paper]. They take into account how the protocol interacts with the other elements that multipath transport needs 😭✨
1.1. Multipath DCCP in the Networking Stack
MP-DCCP adds a set of features to DCCP. Figure 1 shows this layering. MP-DCCP is designed so applications use it the same way they use DCCP, with no changes to the application itself 🌸
+-------------------------------+
| Application |
+---------------+ +-------------------------------+
| Application | | MP-DCCP |
+---------------+ + - - - - - - - + - - - - - - - +
| DCCP | |Subflow (DCCP) |Subflow (DCCP) |
+---------------+ +-------------------------------+
| IP | | IP | IP |
+---------------+ +-------------------------------+Figure 1: Comparison of Standard DCCP and MP-DCCP Protocol Stacks
A command-line interface (CLI) at the endpoint, or some other method, could be used to configure and manage the DCCP connections. That could be extended to support MP-DCCP too, but this specification doesn't define it 💜
1.2. Terminology
This document uses terms that are either specific to multipath transport as defined in [RFC8684], or defined in the context of MP-DCCP. Here they are, bestie 🫶
- Path: A sequence of links between a sender and a receiver. In this context it's defined by a 4-tuple of the source and destination address and the source and destination ports. This definition follows [RFC8684], and the two examples below show IPv6 and IPv4. Each one shows a pair of sender IP-address:port and a pair of receiver IP-address:port, which together form the 4-tuple 🌈
- IPv6:
[2001:db8:3333:4444:5555:6666:7777:8888]:1234,[2001:db8:3333:4444:cccc:dddd:eeee:ffff]:4321 - IPv4:
203.0.113.1:1234,203.0.113.2:4321
- IPv6:
- Subflow: A DCCP flow that is sent over a specific path (a 4-tuple of source and destination address/port pairs) and forms one of the multipath flows used by a single connection 🦋
- (MP-DCCP) Connection: A set of one or more subflows over which an application can communicate between two hosts. The MP-DCCP connection shows up as a single DCCP socket to the application 👑
- Connection Identifier (CI): A unique identifier that a host assigns to a multipath connection so it can tell several multipath connections apart locally. CIs must therefore be locally unique per host, and they do not have to be the same across the peers 🎀
- Host: An end host that runs an MP-DCCP implementation and either starts or accepts an MP-DCCP connection 🧚
'+': The plus symbol means the concatenation of values 💅
Beyond these terms, within the MP-DCCP framework, Section 3 discusses how MP-DCCP changes and affects regular single-path DCCP semantics. It's a whole thing 🙈
1.3. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Lowercase versions don't count, so keep that in mind 🍓
2. Operation Overview ✨
okay so DCCP sends congestion-controlled unreliable datagrams over a single path 🌸 Different congestion control mechanisms exist to tune DCCP for specific traffic types, and each profile is labelled with a Congestion Control IDentifier (CCID) 💅 BUT DCCP has no built-in support for managing multiple subflows inside one connection 😭 That's the gap MP-DCCP fills, and Section 3 has all the juicy details.
At a high level, the data stream from a DCCP app gets split by MP-DCCP into one or more subflows that can travel over different paths, like paths over different links 🦋 The control info lets the receiver optionally reassemble everything and deliver it to the app in the order it was originally sent. This can be necessary because DCCP does not guarantee in-order delivery 🙈 How the sender schedules transmissions and how the receiver reorders (if it reorders at all) is up to each side, and that stuff is outside the scope of this document.
An MP-DCCP connection is a bidirectional connection of datagrams between two hosts that are using DCCP 💜 It needs no changes to the applications 🎀 The hosts can use multiple paths with different 4-tuples to carry the packets of one MP-DCCP connection. MP-DCCP handles requesting, setting up, authenticating, prioritizing, modifying, and removing DCCP subflows across those paths, and it also handles exchanging performance parameters. Main character energy, honestly 👑
The number of DCCP subflows can change over the lifetime of an MP-DCCP connection 🧚 When to add or remove subflows is a path management decision that is outside the scope of this document.
The multipath capability gets negotiated with a new DCCP feature, which is specified in Section 3.1. Once it's negotiated, every later MP-DCCP operation for that connection is signaled with a variable length multipath-related option, described in Section 3. All of those MP-DCCP operations are signaled by the Multipath Options in Section 3.2. Options that need confirmation from the remote peer get retransmitted by the sender until they're confirmed, or until the confirmation stops being relevant ⭐
The sections that follow spell out MP-DCCP behavior in full detail 📖✨
2.1. MP-DCCP Concept
Figure 2 gives you a general overview of how MP-DCCP works, and the main characteristics are summarized in this section 💖
Host A Host B
------------------------ ------------------------
Address A1 Address A2 Address B1 Address B2
---------- ---------- ---------- ----------
| | | |
| (DCCP subflow setup) | |
|----------------------------------->| |
|<-----------------------------------| |
| | | |
| | (DCCP subflow setup)| |
| |--------------------->| |
| |<---------------------| |
| merge individual DCCP subflows to one MP-DCCP connection
| | | |Figure 2: Example MP-DCCP Usage Scenario
- The handshake: An MP-DCCP connection starts with a 4-way handshake between two hosts 🤝 In Figure 2, the connection gets established between addresses A1 and B1 on Hosts A and B. The Multipath Capable Feature is used during that handshake to negotiate multipath support for the connection, and host-specific keys get exchanged too. The details of the MP-DCCP handshake procedure are in Section 3.3. Also, MP-DCCP does not require both peers to have more than one address 🙌
- Adding more subflows: When extra paths and their addresses/ports are available, new DCCP subflows can be created on those paths and attached to the existing MP-DCCP connection 🦋 An MP_JOIN option is what connects a new subflow to an existing MP-DCCP connection. It carries a Connection Identifier (CI) during the setup of the initial subflow, and it gets exchanged in the 4-way handshake for the subflow together with the Multipath Capable Feature. In the example, Figure 2 shows an extra subflow between Address A2 on Host A and Address B1 on Host B. Both subflows keep giving the applications at both endpoints a single connection, which is so iconic 💅
- Finding paths: MP-DCCP spots multiple paths by looking for multiple addresses/ports on the hosts, and combinations of those addresses/ports indicate the additional paths 🗺️ In the example, other potential paths that could be set up are A1<->B2 and A2<->B2. Even though the extra subflow in the example starts at A2, it could have started at B1 or B2 instead 🫶
- Path management: Discovering and setting up extra subflows is handled by a path management method, which covers the logic and procedures for adding and removing subflows 🧠 This document only describes the procedures that let a host start new subflows or signal its available IP addresses to peers. Defining the path management method itself (the sequence and timing of when subflows get created) is outside the scope of this document. That method is governed by a policy and by the specifics of the implementation. If an MP-DCCP peer wants to cap the maximum number of paths it maintains (similar to what is discussed in Section 3.4 of [RFC8041]), it skips creating new subflows from that peer once the maximum-paths threshold is exceeded, and incoming subflow requests MUST be rejected 🚫
- Reordering and hints: With Multipath Options, MP-DCCP adds connection-level sequence numbers and an exchange of Round-Trip Time (RTT) information, which enables optional reordering features ⏱️ A Multipath Option also lets a peer indicate its priorities for which path to use, and that works as a hint for scheduling decisions 💜
- Closing up: Subflows get terminated the same way regular DCCP connections do, as described in Section 8.3 of [RFC4340] 👋 MP-DCCP connections are closed by including an MP_CLOSE option in subflow DCCP-CloseReq or DCCP-Close messages. An MP-DCCP connection can also be reset using an MP_FAST_CLOSE option 💀 Key Data from the initial handshake is included in MP_CLOSE and MP_FAST_CLOSE, which protects against an unauthorized shutdown of MP-DCCP connections 🔐
3. MP-DCCP Protocol
The DCCP protocol feature list (Section 6.4 of [RFC4340]) gets extended by this document with a new Multipath Feature that has Feature Number 10, as you can see in Table 1 🌈
+========+===================+============+===============+=======+
| Number | Meaning | Rec'n Rule | Initial Value | Req'd |
+========+===================+============+===============+=======+
| 10 | Multipath Capable | SP | 0 | N |
+--------+-------------------+------------+---------------+-------+Table 1: Multipath Feature
- Rec'n Rule: This is the reconciliation rule used for the feature. SP means server-priority, as defined in Section 6.3 of [RFC4340] 🎀
- Initial Value: The initial value for the feature. Every feature has a known initial value ✨
- Req'd: This column is "Y" if and only if every DCCP implementation MUST understand the feature. If it's "N", the feature acts like an extension, and it's totally safe to respond to Change options for the feature with empty Confirm options 🫧
This specification adds a DCCP protocol option, as defined in Section 5.8 of [RFC4340], which gives us a new multipath-related variable-length option with option type 46 💖 You can check it out in Table 2 🦋
+======+===============+===========+============+
| Type | Option Length | Meaning | DCCP-Data? |
+======+===============+===========+============+
| 46 | variable | Multipath | Y |
+------+---------------+-----------+------------+Table 2: Multipath Option Set
3.1. Multipath Capable Feature ✨
okay bestie, so DCCP endpoints negotiate the Multipath Capable Feature 💅 to figure out whether multipath extensions can be turned on for a DCCP connection 🦋
The Multipath Capable Feature (MP_CAPABLE) is Feature Number 10, and it follows the feature structure from Section 6 of [RFC4340] 🎀 Besides negotiating the feature itself, you can also swap one or several values. The value field here is one byte long, and it can be repeated several times inside the DCCP option for feature negotiation 🧚 That's useful for stuff like announcing support for different protocol versions, ngl 🫶 The leftmost four bits in Figure 3 are the compatible version of the MP-DCCP implementation, and they MUST be set to 0 following this specification 💖 The four bits after the Version field are unassigned in version 0. The sender MUST set them to zero, and the receiver MUST ignore them 🙈
0 1 2 3 4 5 6 7
+-----------+------------+
| Version | Unassigned |
+-----------+------------+Figure 3: Format of the Multipath Capable Feature Value Field
The setting of the Multipath Capable Feature MUST follow the server-priority reconciliation rule from Section 6.3.1 of [RFC4340] 👑 This is what lets multiple versions be listed in order of priority, so it's giving organized 📋
The negotiation MUST be part of the initial handshake procedure from Section 3.3. No renegotiation of the Multipath Capable Feature is allowed for the same MP-DCCP connection once it's set 🚫
Clients MUST include a Change R option (Section 6 of [RFC4340]) in the initial handshake request. This option supplies a list of supported MP-DCCP protocol versions, ordered by preference 🌸
Servers MUST include a Confirm L option (Section 6 of [RFC4340]) in the subsequent response. The server uses it to agree on an MP-DCCP version from the Client's list, and then adds its own supported version(s), also ordered by preference ✨ Any subflow added to an existing MP-DCCP connection MUST use the version negotiated for the first subflow, no exceptions 🔥
If no agreement is found, the Server MUST reply with an empty Confirm L option with Feature Number 10 and no values 💀
Here's an example of successful version negotiation. It follows the negotiation example in Section 6.5 of [RFC4340] 🦋 For clarity, this example uses the unspecified MP-DCCP versions 1 and 2, in addition to the MP-DCCP version 0 specified in this document 🌈
Client Server
------ ------
DCCP-Req + Change R(MP_CAPABLE, 1 0)
----------------------------------->
DCCP-Resp + Confirm L(MP_CAPABLE, 1, 2 1 0)
<-----------------------------------
* agreement on version = 1 *Figure 4: Example of MP-DCCP Support Negotiation Using MP_CAPABLE
This example illustrates the following:
- The Client indicates support for both MP-DCCP versions 1 and 0, with a preference for version 1 💜
- The Server agrees on using MP-DCCP version 1, which is indicated by the first value, and supplies its own preference list with the subsequent values 🎀
- MP-DCCP is then enabled between the Client and Server with version 1 🥳
Unlike the example in Figure 4, this document only allows the negotiation of MP-DCCP version 0 🙅♀️ So for a successful negotiation of MP-DCCP as defined here, the Client and the Server MUST both support MP-DCCP version 0. No exceptions, bestie 💖
If the version negotiation fails, or the Multipath Capable Feature isn't present in the DCCP-Request or DCCP-Response packets of the initial handshake procedure, the MP-DCCP connection either MUST fall back to regular DCCP or MUST close the connection 😭 The further details are in Section 3.6 🧚
3.2. Multipath Option 🦋
MP-DCCP uses one single option to signal various multipath-related operations, which is honestly so efficient 🍓 The format of this Multipath Option is shown in Figure 5.
1 2 3
01234567 89012345 67890123 45678901 23456789
+--------+--------+--------+--------+--------+
|00101110| Length | MP_OPT | Value(s) ...
+--------+--------+--------+--------+--------+
Type=46Figure 5: Multipath Option Format
The fields used by the Multipath Option are described in Table 3. MP_OPT is the name for a Multipath Option 💅
+======+========+================+=================================+
| Type | Option | MP_OPT | Meaning |
| | Length | | |
+======+========+================+=================================+
| 46 | var | 0 =MP_CONFIRM | Confirm reception and |
| | | | processing of an MP_OPT option |
+------+--------+----------------+---------------------------------+
| 46 | 12 | 1 =MP_JOIN | Join subflow to an existing MP- |
| | | | DCCP connection |
+------+--------+----------------+---------------------------------+
| 46 | var | 2 | Close an MP-DCCP connection |
| | | =MP_FAST_CLOSE | unconditionally |
+------+--------+----------------+---------------------------------+
| 46 | var | 3 =MP_KEY | Exchange key material for |
| | | | MP_HMAC |
+------+--------+----------------+---------------------------------+
| 46 | 9 | 4 =MP_SEQ | Multipath sequence number |
+------+--------+----------------+---------------------------------+
| 46 | 23 | 5 =MP_HMAC | Hash-based message |
| | | | authentication code for MP-DCCP |
+------+--------+----------------+---------------------------------+
| 46 | 12 | 6 =MP_RTT | Transmit RTT values and |
| | | | calculation parameters |
+------+--------+----------------+---------------------------------+
| 46 | var | 7 =MP_ADDADDR | Advertise one or more |
| | | | additional addresses/ports |
+------+--------+----------------+---------------------------------+
| 46 | 8 | 8 | Remove one or more addresses/ |
| | | =MP_REMOVEADDR | ports |
+------+--------+----------------+---------------------------------+
| 46 | 4 | 9 =MP_PRIO | Change subflow priority |
+------+--------+----------------+---------------------------------+
| 46 | var | 10 =MP_CLOSE | Close an MP-DCCP connection |
+------+--------+----------------+---------------------------------+
| 46 | var | 11 =MP_EXP | Experimental option for private |
| | | | use |
+------+--------+----------------+---------------------------------+
| 46 | TBD | >11 | (available for future Multipath |
| | | | Options) |
+------+--------+----------------+---------------------------------+Table 3: MP_OPT Option Types
Future Multipath Options could be defined in a later version of this specification, or in an extension to it 🔮
These operations are largely inspired by the signals defined in [RFC8684] 🫶 The procedures for handling faulty or unknown Multipath Options are described in Section 3.6 🧐
3.2.1. MP_CONFIRM 💌
Okay so bestie, MP_CONFIRM is the option that says "yep, got it!" 🫶 Some Multipath Options need the other host to confirm they actually received them (check Table 4 for which ones), and that's exactly what this one is for ✨
1 2 3 4 5
01234567 89012345 67890123 45678901 23456789 01234567 89012345
+--------+--------+--------+--------+--------+--------+--------+
|00101110| var |00000000| List of confirmations ...
+--------+--------+--------+--------+--------+--------+--------+
Type=46 Length MP_OPT=0
Figure 6: Format of the MP_CONFIRM OptionSo, like, options that need confirming get resent by the sender until an MP_CONFIRM shows up 🔁 OR until the confirmation stops mattering because the data in the option has already been replaced by something newer 🙈 That's the main character move right there, no cap 💅
For example, with an MP_PRIO option, if the path prioritization changes while the old prioritization hasn't been confirmed yet, the old one is basically yesterday's news 💀 What the receiving host does with the Multipath Options after that is not the subject of MP_CONFIRM, so that's a different story 🦋
Now, Multipath Options can arrive out of order, which is so chaotic 😭 So Multipath Options listed in Table 4 MUST be sent in a DCCP datagram with MP_SEQ (see Section 3.2.5). This lets the receiver figure out whether an option is tied to an obsolete dataset (the info carried in the option header) that would otherwise clash with a newer one 👑 For MP_ADDADDR or MP_REMOVEADDR, the dataset is identified by the AddressID. For MP_PRIO, it's identified by the subflow in use 🎀 An outdated multipath option gets detected at the receiver if an earlier one for the same dataset had a higher MP_SEQ number in it. An MP_CONFIRM MAY be generated for Multipath Options that are identified as outdated 🌸
MP_CONFIRM can also arrive out of order, bestie 😵💫 So the associated MP_SEQ that was received MUST be echoed back, so the most recent Multipath Option is the one that gets confirmed ✨ This protects against some seriously messy stuff. Imagine three MP_PRIO options get sent one after another on one path, setting the path priority to 0, then 1, then 0 again 🌈 If the third MP_PRIO gets lost, AND the MP_CONFIRM for the second and third updates also gets lost, the sender would wrongly think the priority is 0 without realizing the receiver actually applied priority 1. Yikes 💀 That's why the MP_SEQ matters!
The length of the MP_CONFIRM option, and the path it's sent over, depend on the confirmed Multipath Options and the received MP_SEQ. Both of those get copied over verbatim and appended as a list of confirmations 🧚 The list starts with the received MP_SEQ, followed by the related Multipath Option or options being confirmed. The same rules apply when Multipath Options with different MP_SEQs get confirmed all at once 💖 That can happen if, in quick succession, you receive a datagram with an MP_PRIO and a first MP_SEQ_1, and another datagram with an MP_ADDADDR and a second MP_SEQ_2. In that case the structure gets concatenated like this: MP_SEQ_2 + MP_ADDADDR + MP_SEQ_1 + MP_PRIO 🍓
The order of the confirmed Multipath Options in the list of confirmations MUST reflect the incoming order at the host sending the MP_CONFIRM, with the most recent suboption received listed first 🔥 This lets the host receiving the MP_CONFIRM check that the options were applied in the correct order, and take countermeasures if they weren't. For example, if an MP_REMOVEADDR overtakes an MP_ADDADDR that refers to the same dataset 🙃 Lowkey genius design, honestly 👑
+======+===============+==================+=========================+
| Type | Option Length | MP_OPT | MP_CONFIRM Sending Path |
+======+===============+==================+=========================+
| 46 | var | 7 =MP_ADDADDR | Any available |
+------+---------------+------------------+-------------------------+
| 46 | 4 | 8 | Any available |
| | | =MP_REMOVEADDR | |
+------+---------------+------------------+-------------------------+
| 46 | 4 | 9 =MP_PRIO | Any available |
+------+---------------+------------------+-------------------------+
Table 4: Multipath Options Requiring ConfirmationHere's an example of the MP-DCCP confirm procedure for MP_PRIO, shown in Figure 7 🦋 Host A sends a DCCP-Request on path A2-B2 with an MP_PRIO option with value 1 and an associated sequence number of 1. Host B replies on the same path in this instance (any path can be used) with a DCCP-Response containing the MP_CONFIRM option, and a list with the original sequence number (1) together with the associated option (MP_PRIO) 💕
Host A Host B
------------------------ ------------------------
Address A1 Address A2 Address B1 Address B2
---------- ---------- ---------- ----------
| | | |
| | DCCP-Request(seqno 1) + MP_PRIO(1)| |
| |------------------------------------------>|
| | | |
| | DCCP-Response + | |
| |<---- MP_CONFIRM(seqno 1, MP_PRIO) --------|
| | | |
Figure 7: Example MP_CONFIRM ProcedureAnd here's a second example, Figure 8, where an out-of-date option also gets delivered 🙈 The first DCCP-Data goes from Host A to Host B with MP_PRIO set to 4. Then Host A sends the second DCCP-Data with MP_PRIO set to 1. But the first MP_PRIO gets delayed in the network between Host A and Host B, so it arrives after the second one 😭 Host B ignores this second MP_PRIO, since its sequence number is earlier than the first's. Then Host B sends a DCCP-Ack with sequence number 2 to confirm it received MP_PRIO(1) 💅
Host A Host B
------------------------ ------------------------
Address A1 Address A2 Address B1 Address B2
---------- ---------- ---------- ----------
| | | |
| | DCCP-Data(seqno 1) + MP_PRIO(4) | |
| |------------ | |
| | \ | |
| | DCCP-Data(seqno 2) + MP_PRIO(1) | |
| |--------------\--------------------------->|
| | \ | |
| | -------------------------->|
| | | |
| | DCCP-Ack + | |
| |<---- MP_CONFIRM(seqno 2, MP_PRIO) --------|
| | | |
Figure 8: Example MP_CONFIRM Procedure with an Outdated Suboption3.2.2. MP_JOIN 🦋
Okay, MP_JOIN is how you add a brand-new subflow to an existing MP-DCCP connection 🌸 And a successful establishment of the first subflow using MP_KEY is REQUIRED, so no skipping that step, bestie 💅
1 2 3
01234567 89012345 67890123 45678901
+--------+--------+--------+--------+
|00101110|00001100|00000001| Addr ID|
+--------+--------+--------+--------+
| Connection Identifier |
+--------+--------+--------+--------+
| Nonce |
+--------+--------+--------+--------+
Type=46 Length=12 MP_OPT=1
Figure 9: Format of the MP_JOIN SuboptionThe CI is the one from the peer host, which was previously exchanged with the MP_KEY option 🔑 MP_HMAC MUST be set when using MP_JOIN within a DCCP-Response packet, see Section 3.2.6 for the details 🧚 Just like the setup of the first subflow, MP_JOIN also exchanges the Multipath Capable Feature MP_CAPABLE, as described in Section 3.1 💖 This procedure includes the DCCP Confirm principle, so it ensures a reliable exchange of the MP_JOIN in accordance with Section 6.6.4 of [RFC4340] ✨
The MP_JOIN option includes an "Addr ID" (Address ID) generated by the sender of the option. It's used to identify the source address of this packet, even if a middlebox changed the IP header in transit 🙈 The value of this field is generated by the sender, and it MUST map uniquely to a source IP address for the sending host. The Address ID allows address removal (Section 3.2.9) without the receiver needing to know the source address, which means address removal can work through NATs 🌈 The Address ID also helps correlate new subflow setup attempts with address signaling (Section 3.2.8). That way, you don't end up setting up duplicate subflows on the same path if an MP_JOIN and MP_ADDADDR get sent at the same time 👑
The Address IDs of the subflow used in the initial DCCP Request/Response exchange of the first subflow in the connection are implicit, and have the value zero 🍓 A host MUST store the mappings between Address IDs and addresses, for both itself and the remote host. An implementation also needs to know which local and remote Address IDs are associated with which established subflows, for when addresses get removed from a local or remote host 🎀 An Address ID MUST always be unique over the lifetime of a subflow, and it can only be reassigned if the sender and receiver no longer have it in use 🫶
The Nonce is a 32-bit random value that's generated locally for every MP_JOIN option 🎲 Together with the derived key from both hosts' Key Data (as described in Section 3.2.4), the Nonce value builds the basis for calculating the Hash-based Message Authentication Code (HMAC) used in the handshake process (as described in Section 3.3). This helps avoid replay attacks 🔐
If the CI cannot be verified by the receiving host during a handshake negotiation, the new subflow MUST be closed, as specified in Section 3.6. Non-negotiable, bestie 🚫💀
3.2.3. MP_FAST_CLOSE 💅
okay so, regular DCCP can send a Close or Reset to abruptly end a connection 🥺. In MP-DCCP though, a normal Close or Reset only affects the one subflow it came in on 🦋. It closes that subflow and leaves the other subflows and the MP-DCCP connection alone (unless it was the last subflow standing). This is what makes break-before-make handover between subflows possible ✨.
If you actually want an MP-DCCP-level "reset" that abruptly closes the whole connection, that's what the MP_FAST_CLOSE suboption is for 💖.
1 2 3
01234567 89012345 67890123 45678901 23456789
+--------+--------+--------+--------+--------+
|00101110| var |00000010| Key Data ...
+--------+--------+--------+--------+--------+
Type=46 Length MP_OPT=2
Figure 10: Format of the MP_FAST_CLOSE SuboptionWhen Host A wants to abruptly close an MP-DCCP connection with Host B, it sends out the MP_FAST_CLOSE 🔥. The MP_FAST_CLOSE suboption MUST be sent from Host A on all subflows, using a DCCP-Reset packet with Reset Code 13 💀. Sending it on every subflow means Host B is more likely to actually get it and do the same thing 🫶. To protect against an unauthorized shutdown of the MP-DCCP connection, the MP_FAST_CLOSE option carries the peer's selected Key Data from the handshake procedure 🔐. Only the right host can close the connection, not some random on-path gremlin 👑.
After sending the MP_FAST_CLOSE on all subflows, Host A MUST tear down all subflows, and the MP-DCCP connection immediately terminates 🌸.
When Host B gets the first MP_FAST_CLOSE with Key Data that validates successfully, it sends a DCCP-Reset packet with Reset Code 13 back on all subflows to Host A 🧚. This is to clean up any potential middlebox states 🧹. Host B MUST then tear down all subflows and terminate the MP-DCCP connection 💜.
3.2.4. MP_KEY 🗝️
MP-DCCP protects against some on-path attackers, and Section 4 goes into the details 🛡️. The foundation for that protection is an initial exchange of keys during MP-DCCP connection setup, and that's exactly what MP_KEY is for 🎀. Yep, the foundation is laid by that initial key exchange during setup, which is why MP_KEY exists 🌈.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
|0 0 1 0 1 1 1 0| var |0 0 0 0 0 0 1 1| resvd |
+---------------+---------------+---------------+---------------+
| Connection Identifier |
+---------------+---------------+---------------+---------------+
| Key Type (1) | Key Data (1) | Key Type (2) | Key Data (2) |
+---------------+---------------+---------------+---------------+
| Key Type (3) | ...
+---------------+---------------+
Type=46 Length MP_OPT=3
Figure 11: Format of the MP_KEY SuboptionThe MP_KEY suboption is how hosts (Host A and Host B) swap a CI and key material for a given connection 🤝. The CI is a number that's unique within the host for each multipath connection, and it gets generated for the first exchange of a connection that uses MP_KEY 🔢. With the CI, other DCCP subflows can join an MP-DCCP connection using MP_JOIN (Section 3.2.2) 🔗. The CI is 32 bits, so a host can have at most 2^32 simultaneous MP-DCCP connections 📈. Depending on the Key-related elements in MP_KEY, the Length is between 17 and 73 bytes for a single-key message, and up to 82 bytes when all specified Key Types, 0 and 255, are included 📏. The Key Type field tells you what kind of Key Data comes next 🏷️. Here are the Key Types, in Table 5 💅.
+===============+====================+===================+
| Key Type | Key Length (bytes) | Meaning |
+===============+====================+===================+
| 0 =Plain Text | 8 | Plain text Key |
+---------------+--------------------+-------------------+
| 1-254 | | (available for |
| | | future Key Types) |
+---------------+--------------------+-------------------+
| 255 | 64 | For private use |
| =Experimental | | only |
+---------------+--------------------+-------------------+
Table 5: MP_KEY Key TypesPlain Text 📝: the Key Data goes over the wire in plain text between Host A and Host B. Each host then uses the two key parts (KeyA and KeyB) to make a derived key (d-key) by putting the local key first and the other one after it 🔑. So:
Host A: d-keyA=(KeyA+KeyB)
Host B: d-keyB=(KeyB+KeyA)
Experimental 🧪: this Key Type lets you use other Key Data, and it's there to test other key exchange mechanisms that might become a future spec 🔬.
Multiple keys are only allowed in the DCCP-Request message of the handshake for the first subflow 🙅♀️. That's how the hosts agree on the one Key Type they'll both use, as described in Section 3.3 🤝.
Not every host is going to support every Key Type, and this spec doesn't recommend or enforce announcing any particular Key Type in MP_KEY, because that could have security implications 🙈. Still, Key Type 0 (Plain Text) MUST be supported for interoperability tests in MP-DCCP implementations 🧪. And if the Key Type can't be agreed on during the handshake, the MP-DCCP connection MUST fall back to not using MP-DCCP, as covered in Section 3.6 🔙.
3.2.5. MP_SEQ 🔢
DCCP [RFC4340] has a packet sequencing scheme, and it keeps applying to each individual DCCP subflow inside an MP-DCCP connection 🧵. But for MP-DCPP to work, the order of packets across the whole MP-DCCP connection MUST be known before packets get assigned to subflows. That's so the received Multipath Options get applied in the right order, and so you can tell whether a delayed Multipath Option is obsolete 🕰️. That's why MP_SEQ exists, and it can also be used to reorder data packets on the receiver side 📦.
1 2 3 4 5
01234567 89012345 67890123 45678901 23456789 01234567 89012345
+--------+--------+--------+--------+--------+--------+--------+
|00101110|00001001|00000100| Multipath Sequence Number
+--------+--------+--------+--------+--------+--------+--------+
|
+--------+--------+
Type=46 Length=9 MP_OPT=4
Figure 12: Format of the MP_SEQ SuboptionThe MP_SEQ suboption carries end-to-end 48-bit datagram-based sequence numbers for an MP-DCCP connection 🎯. The initial data sequence number (IDSN) SHOULD be set randomly [RFC4086] 🎲. Just like the regular DCCP sequence number, the data sequence number shouldn't start at zero. It should start at a random value so blind session hijacking is harder 🕵️♀️. See also Section 7.2 of [RFC4340] 📖.
The MP_SEQ number space is independent of each path's own sequence number space, and MUST be sent with all DCCP-Data and DCCP-DataACK packets 📬.
When the sequence number space runs out, the sequence number MUST be wrapped 🔁. [RFC7323] gives guidance on picking a sequence number space that's the right size for the Maximum Segment Lifetime (MSL) of TCP ⏳. For TCP, 64 bits is the recommended size so the sequence space doesn't go all the way around within a segment's lifetime 💫. For DCCP, the MSL is the same as TCP's, as specified in Section 3.4 of [RFC4340] 🧮. The big difference is that DCCP increments the sequence number per packet, not per byte sent 📦. Because of that, the 48 bits in MP_SEQ are considered big enough for the current globally routable maximum packet size (MPS) of 1500 bytes. That works out to roughly 375 pebibytes (PiBs) of data in the sequence number space 🌌✨.
3.2.6. MP_HMAC ✨
Okay bestie, so MP-DCCP already protects against some on-path attackers (more on that in Section 4) 🛡️. Once an MP-DCCP connection is up, the MP_HMAC option adds another layer of protection, built on the key material swapped in MP_KEY during setup 🔐.
1 2 3 4
01234567 89012345 67890123 45678901 23456789 01234567
+--------+--------+--------+--------+--------+--------+
|00101110|00010111|00000101| HMAC-SHA256 (20 bytes) ...
+--------+--------+--------+--------+--------+--------+
Type=46 Length=23 MP_OPT=5Figure 13: Format of the MP_HMAC Suboption
The MP_HMAC suboption authenticates the MP_ADDADDR and MP_REMOVEADDR suboptions 🎀. It also authenticates subflows that join an existing MP-DCCP connection, in the second and third steps of the handshake for a later subflow (see Section 3.3) 🤝. For this version of MP-DCCP, the HMAC code is generated according to [RFC2104] together with the SHA-256 hash algorithm from [RFC6234]. The output is in big-endian format and truncated to the leftmost 160 bits (20 bytes). Future versions of MP-DCCP might define other hash algorithms, so keep an eye out 👀.
The "Key" for the HMAC computation is the derived key (d-keyA for Host A or d-KeyB for Host B) described in Section 3.2.4 🔑. The HMAC "Message" for MP_JOIN, MP_ADDADDR, and MP_REMOVEADDR must be calculated on both hosts. The sender uses it to protect the Multipath Option, and the receiver uses it to validate the Multipath Option. The Message is a concatenation of the following:
- For MP_JOIN: The Nonces of the MP_JOIN messages for which authentication shall be performed. Which formula applies depends on whether Host A or Host B does the HMAC-SHA256 calculation:
MP_HMAC(A) = HMAC-SHA256(Key=d-keyA, Msg=RA+RB)MP_HMAC(B) = HMAC-SHA256(Key=d-keyB, Msg=RB+RA)
A usage example is shown in Figure 21 🦋.
- For MP_ADDADDR: The Address ID and Nonce, plus an associated IP address and port if defined. If they aren't defined, use 2 bytes of value 0 instead. The IP address and port MUST be used in network byte order (NBO) 🌐. Which formula applies depends on whether Host A or Host B does the HMAC-SHA256 calculation:
MP_HMAC(A) = HMAC-SHA256(Key=d-keyA, Msg=Address ID+Nonce+NBO(IP)+NBO(Port))MP_HMAC(B) = HMAC-SHA256(Key=d-keyB, Msg=Address ID+Nonce+NBO(IP)+NBO(Port))
- For MP_REMOVEADDR: Solely the Address ID. Which formula applies depends on whether Host A or Host B does the HMAC-SHA256 calculation:
MP_HMAC(A) = HMAC-SHA256(Key=d-keyA, Msg=Address ID+Nonce)MP_HMAC(B) = HMAC-SHA256(Key=d-keyB, Msg=Address ID+Nonce)
MP_JOIN, MP_ADDADDR, and MP_REMOVEADDR can coexist or be used multiple times within a single DCCP packet 📦. All of these Multipath Options require an individual MP_HMAC option, so each MP_HMAC stays correctly tied to its partner. Without that, the receiver can't validate multiple MP_JOIN, MP_ADDADDR, or MP_REMOVEADDR options. So an MP_HMAC MUST directly follow its associated Multipath Option 🧷. The most likely case is sending an MP_JOIN together with an MP_ADDADDR, which gives MP_JOIN + MP_HMAC_1 + MP_ADDADDR + MP_HMAC_2. Here the first MP_HMAC_1 goes with the MP_JOIN, and the second MP_HMAC_2 goes with the MP_ADDADDR suboption.
On the receiving side, the HMAC validation of the suboptions MUST be carried out in the order they were sent, where each associated MP_HMAC follows its suboption 🔁. If a receiving host can't validate a suboption because the HMAC check fails (the HMAC is wrong or missing), what happens next depends on which suboption was being checked 😬. If the suboption being authenticated was MP_ADDADDR or MP_REMOVEADDR, the receiving host MUST silently ignore it (see Sections 3.2.8 and 3.2.9) 🙈. If it was MP_JOIN, the subflow MUST be closed (see Section 3.6) 💀.
If an MP_HMAC can't be associated with a suboption, that MP_HMAC MUST be ignored. The one exception is a single MP_HMAC sent in a DCCP-Ack that responds to a DCCP response packet carrying MP_JOIN (see the penultimate arrow in Figure 21) 🌸.
3.2.7. MP_RTT 💖
The MP_RTT suboption carries RTT values and Age (in milliseconds) for the path the information is sent over 🛤️. Receivers use this to work out the RTT difference between subflows and to guess whether some missing data has been lost 🕵️♀️.
1 2 3 4 5
01234567 89012345 67890123 45678901 23456789 01234567 89012345
+--------+--------+--------+--------+--------+--------+--------+
|00101110|00001100|00000110|RTT Type| RTT
+--------+--------+--------+--------+--------+--------+--------+
| Age |
+--------+--------+--------+--------+--------+
Type=46 Length=12 MP_OPT=6Figure 14: Format of the MP_RTT Suboption
The RTT and Age values are 32-bit integers, which covers roughly 1193 hours ⏳.
The RTT type field tells you what kind of RTT estimation is being sent 📊:
- Raw RTT (=0): The raw RTT value of the last Datagram round trip.
- Min RTT (=1): The minimum RTT value over a given period.
- Max RTT (=2): The maximum RTT value over a given period.
- Smooth RTT (=3): The averaged RTT value over a given period.
Each CCID specifies the algorithms and periods it uses for its own RTT estimations. Which of these types you can use in the MP_RTT option depends on what the CCID implementation supports 🧠.
Age: The Age parameter is the time difference, in milliseconds, between now (when the MP_RTT option is created) and the RTT measurement that was taken. If there's no previous measurement, for example right after initialization, the value is 0 ⌛.
Figure 15 shows an example flow of the per-path RTT info being exchanged 🌈. RTT1 refers to the first path and RTT2 to the second. The RTT values could come from the sender's congestion control algorithm and get sent to the receiver using the MP_RTT suboption 📨. Once the receiver has RTT1 and RTT2, it can work out the path_delta, which is the absolute difference between the two values 🧮. If the per-path RTTs are symmetric in the down-link and up-link directions and there's no jitter, then packets with a missing sequence number MP_SEQ (say, in a reordering process) can be assumed lost after path_delta/2 🎯.
MP-DCCP MP-DCCP
Sender Receiver
+--------+ MP_RTT(RTT1) +-------------+
| RTT1 |----------------| |
| | | path_delta= |
| | MP_RTT(RTT2) | |RTT1-RTT2| |
| RTT2 |----------------| |
+--------+ +-------------+Figure 15: Exemplary Flow of MP_RTT Exchange and Usage
3.2.8. MP_ADDADDR 🦋
okay so MP_ADDADDR is the suboption where a host basically goes "hey, come find me at these addresses!" 📣 It can also include port numbers if you want 🎀 It can be sent any time during an existing MP-DCCP connection, like when the sender wants to turn on multiple paths and/or when new paths pop up. You can even stack several of these in one packet to advertise new addresses all at once 💅
The Length is variable because it depends on the address family (IPv4 or IPv6) and on whether a port number is included. It lands somewhere between 12 and 26 bytes 📏
The Nonce is a 32-bit random value that gets generated locally for every MP_ADDADDR option. It's used in the HMAC calculation to stop replay attacks 🔐
The final 2 bytes are optional and say which DCCP port to use. You can tell whether they're there just by looking at the option's length 👀 Honestly most people are gonna keep the same port pairs as the initial subflow (like port 80 staying port 80 on every subflow, and the client's ephemeral port staying put too). But sometimes you need a different port, like with port-based load balancing 🍓 If no port is specified, the receiving host MUST assume that any attempt to connect to the specified address uses the port already used by the subflow on which the MP_ADDADDR signal was sent.
Now the security part, and this is so important 🔒 Along with the MP_ADDADDR option, an MP_HMAC option MUST be sent for authentication. The truncated HMAC parameter in that MP_HMAC option is the leftmost 20 bytes of an HMAC, negotiated and calculated the way Section 3.2.6 describes. Just like MP_JOIN, the HMAC key is d-KeyA when Host A is the one transmitting and d-KeyB when it's Host B. These are the keys that got exchanged and picked in the original MP_KEY handshake 🗝️ The HMAC covers the Address ID, Nonce, IP address, and port number that sit in front of the HMAC inside the MP_ADDADDR option. If the port number isn't in the MP_ADDADDR option, the HMAC message includes 2 bytes of value zero instead. The whole point is to stop unauthorized entities from sneaking in MP_ADDADDR signals to hijack a connection 🚫 It also means the address can't be changed in flight unless an intermediary knows the key. And if a host gets an MP_ADDADDR option whose HMAC it can't validate, it MUST silently ignore the option. ghosted, no notification 👻
The presence of an MP_SEQ (Section 3.2.5) MUST be ensured in any DCCP datagram that carries an MP_ADDADDR, as described in Section 3.2.1 ✨
Here's the layout 💖
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+-------+-------+---------------+
|0 0 1 0 1 1 1 0| var |0 0 0 0 0 1 1 1| Address ID |
+---------------+---------------+-------+-------+---------------+
| Nonce |
+-------------------------------+-------------------------------+
| Address (IPv4 - 4 bytes / IPv6 - 16 bytes) |
+-------------------------------+-------------------------------+
| Port (2 bytes, optional) | + MP_HMAC option
+-------------------------------+
Type=46 Length MP_OPT=7
Figure 16: Format of the MP_ADDADDR SuboptionEvery address gets an Address ID, which can be used to uniquely identify that address inside a connection when you want to remove it later 🆔 Each host keeps a list of unique Address IDs and manages them however it likes. The Address ID is also how MP_JOIN options (see Section 3.2.2) get linked to the same address, even when address translators are in the mix 🔗 The Address ID MUST uniquely identify the address for the sender of the option (within the scope of the connection). How you allocate those IDs is up to the implementation 🛠️
All the Address IDs you learn from MP_JOIN or MP_ADDADDR can get stored by the receiver in a data structure that collects every Address-ID-to-address mapping for a connection (identified by a CI pair) 📚 That gives you a stored mapping between the Address ID, the observed source address, and the CI pair, which is super handy for processing control info later 🧠 Heads up though: an implementation MAY discard incoming address advertisements. Reasons for that include, for example:
- to avoid needing that mapping state, or
- because the advertised addresses are of no use to it.
Possible scenarios for this are not having enough resources to store a mapping, or getting IPv6 addresses advertised when the host only supports IPv4 🙃 So a host MUST treat address announcements as soft state. A sender MAY choose to refresh the announcements periodically to get around temporary limitations ⏰
A host MAY advertise private addresses, for example if there's a NAT on the path. This is actually desirable, because both hosts might have extra interfaces on the same private network 🏠 Advertising broadcast or multicast IP addresses is a different story: the recipient MUST ignore that, because it isn't permitted under the unicast principle of basic DCCP 🚫📡
The MP_JOIN handshake that creates a new subflow (Section 3.2.2) has mechanisms to keep security risks low 🛡️ The MP_JOIN message carries a 32-bit CI that uniquely identifies a connection to the receiving host. If the CI is unknown, the host MUST send a DCCP-Reset 🔄
There's more security stuff about MP_ADDADDR messages that accidentally (or maliciously) send new MP_JOIN attempts to the wrong place, and that's covered in Section 4 📖 If a sending host knows that no incoming subflows can be established at a particular address, then an MP_ADDADDR MUST NOT announce that address, unless the sending host has new knowledge that makes it possible. That info can come from local firewall or routing settings, knowledge of an external NAT or firewall, or connectivity checks done by the host or application 🕵️♀️
Receiving an MP_ADDADDR gets acknowledged with MP_CONFIRM (Section 3.2.1). That's what makes the address exchange reliable 🤝
Now, if a host gets an MP_ADDADDR but the IP address and port number fail at connection setup, it SHOULD NOT keep trying that address/port combination for this connection, so it doesn't waste resources 😤 But if a sender really wants a fresh incoming connection attempt on a previously advertised address/port combination, they can refresh the MP_ADDADDR information by sending the option again 🔁
A host MAY send an MP_ADDADDR message with an Address ID that's already been assigned, using the IP address previously assigned to that ID. The new one could keep the same port number or use a different one 🎀 The receiver MUST silently ignore the MP_ADDADDR if the IP address isn't the same as the one previously assigned to that Address ID. And if a host wants to replace an existing Address ID, it MUST first remove the existing one (Section 3.2.9) 🧹
3.2.9. MP_REMOVEADDR 💅
So if a previously announced address becomes invalid during an MP-DCCP connection's lifetime (like when an interface disappears), the affected host SHOULD announce that 📢 The peer can then remove the address using its Address ID with the Remove Address (MP_REMOVEADDR) suboption. This terminates any subflows currently using that address 💀
MP_REMOVEADDR is only for closing already-established subflows that have an invalid address. If a flow still has a valid address, it MUST be closed with a DCCP Close exchange (just like regular DCCP), not with MP_REMOVEADDR 🙅♀️ For more info, check Section 3.5 🔍
The Nonce is a 32-bit random value generated locally for each MP_REMOVEADDR option, and it's used in the HMAC calculation to prevent replay attacks 🔐
Along with the MP_REMOVEADDR suboption, an MP_HMAC option MUST be sent for authentication. The truncated HMAC parameter in that MP_HMAC option is the leftmost 20 bytes of an HMAC, negotiated and calculated as Section 3.2.6 describes. Same deal as MP_JOIN: the HMAC key is d-KeyA when Host A sends it and d-KeyB when Host B sends it. Those are the keys exchanged and selected in the original MP_KEY handshake 🗝️ For this one, the HMAC message is just the Address ID.
The reason for using an HMAC is to keep unauthorized entities from injecting MP_REMOVEADDR signals to hijack a connection 🚫 Also, the HMAC means the address can't be modified in flight unless an intermediary knows the key. If a host gets an MP_REMOVEADDR option it can't validate the HMAC for, it MUST silently ignore the option 👻
A receiver MUST include an MP_SEQ (Section 3.2.5) in a DCCP datagram that sends an MP_REMOVEADDR. More details are in Section 3.2.1 ✨
Receiving an MP_REMOVEADDR gets acknowledged with MP_CONFIRM (Section 3.2.1), which keeps the address info exchange reliable 🤝 To avoid inconsistent states, the sender only releases the Address ID after the MP_REMOVEADDR has been confirmed 🧠
Sending and receiving this message SHOULD trigger the closing procedure described in [RFC4340] between the client and the server on the affected subflow(s), if that's possible 🧹 This helps clear out middlebox state before the local state gets removed.
Address removal happens by Address ID, which lets it work with NATs and other middleboxes that rewrite source addresses 🌈 If there's no address at the requested Address ID, the receiver silently ignores the request 🙈
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
|0 0 1 0 1 1 1 0|0 0 0 0 0 1 0 0|0 0 0 0 1 0 0 0| Address ID |
+---------------+---------------+---------------+---------------+
| Nonce |
+-------------------------------+-------------------------------+
Type=46 Length=8 MP_OPT=8
-> followed by the MP_HMAC option
Figure 17: Format of the MP_REMOVEADDR Suboption3.2.10. MP_PRIO 🌸
okay so MP_PRIO is the little hint-dropper for the packet scheduler 💅 It tells the scheduler which path to pick for payload traffic. Say one path is way more special than the rest. A host can tell its peer "hey, lean on this one" using this option. It's giving main character energy for paths 👑 It's super useful when paths cost different amounts (Wi-Fi is free, cellular has a data cap, and 5G eats battery 🔋). It also helps when a phone is about to die and the user just wants one path to carry everything 🫶
The MP_PRIO suboption, shown below, sets a priority value for the subflow it's received on ✨
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
|0 0 1 0 1 1 1 0|0 0 0 0 0 1 0 0|0 0 0 0 1 0 0 1|(resvd)| prio |
+---------------+---------------+---------------+---------------+
Type=46 Length=4 MP_OPT=9
Figure 18: Format of the MP_PRIO SuboptionHere are the prio values you can use 🌈
0: Do not use. The path is not available 🙈1: Standby: Do not use this path for traffic scheduling if another path (secondary or primary) is available. The path will only be used if other secondary or primary paths are not established 🧚2: Secondary: Do not use this path for traffic scheduling if the other paths are good enough. The path will be used occasionally to temporarily boost capacity, e.g., when primary paths are congested or unavailable. This is the recommended setting for paths with costs or data caps, since they get used less often than primary paths 💜3 - 15: Primary: The path can be used for packet scheduling decisions. The number shows how much higher one primary path ranks than another, and higher numbers mean higher priority. The peer should consider sending traffic over higher priority paths first. This is the recommended setting for paths with no cost or data cap, since they get used a lot 🔥
Some example use cases, because examples make everything click 🦋
- Set Wi-Fi to Primary and cellular to Secondary. Wi-Fi gets used, and cellular only kicks in when Wi-Fi is congested or gone. Cellular is only used temporarily when you need more capacity than Wi-Fi can give, which clearly shows Wi-Fi is the favourite, probably for cost reasons 💅
- Set Wi-Fi to Primary and cellular to Standby. Wi-Fi gets used, and cellular is only used if Wi-Fi isn't available at all 🌸
- Set Wi-Fi to Primary and cellular to Primary. Both paths can be picked when the scheduler makes decisions 👯♀️
If no value is set, the default is to always use a path for scheduling (MP_PRIO=3) once it's established and added to an existing MP-DCCP connection ✨ At least one path ought to have an MP_PRIO value greater than or equal to one, or the connection isn't allowed to send anything 💀 It is RECOMMENDED to bump at least one path to a non-zero MP_PRIO value when every path is sitting at zero. This helps the MP-DCCP connection keep scheduling when the multipath scheduler strictly respects MP_PRIO value 0 🫶 To make sure transmission is reliable, the MP_PRIO suboption MUST be acknowledged via an MP_CONFIRM (see Table 4) 🔐
The relative ratio of the primary values 3-15 depends on the path usage strategy, which is explained more in Section 3.11. With path mobility (Section 3.11.1), only one path is used at a time, and that path MUST have the highest available priority value. That includes the prio numbers 1 and 2 too 🎀 With concurrent path usage (Section 3.11.2), the multipath scheduler logic decides what happens 🧠
Last but not least, an MP_SEQ (Section 3.2.5) MUST be present in any DCCP datagram that carries an MP_PRIO suboption. More details are in Section 3.2.1 💖
3.2.11. MP_CLOSE 🦋
Okay, so plain DCCP [RFC4340] has a closing mechanism, but it can't tell you that a whole MP-DCCP connection is closing. That connection usually has several DCCP subflows, so closing one subflow doesn't mean the whole connection is closing 🙈 That's where MP_CLOSE comes in and saves the day 🦸♀️
1 2 3
01234567 89012345 67890123 45678901 23456789
+--------+--------+--------+--------+--------+
|00101110| var |00001010| Key Data ...
+--------+--------+--------+--------+--------+
Type=46 Length MP_OPT=10
Figure 19: Format of the MP_CLOSE SuboptionYou can close an MP-DCCP connection gracefully by sending an MP_CLOSE to the peer host 💜 On every subflow, the regular termination procedure from [RFC4340] MUST be started using MP_CLOSE in the first packet, which is either a DCCP-CloseReq or a DCCP-Close. If a DCCP-CloseReq is used, the DCCP-Close that follows MUST also carry MP_CLOSE, so the sender of the DCCP-CloseReq doesn't have to keep any state around 🧚 On the side that starts the DCCP-CloseReq, every socket, including the MP-DCCP connection socket, moves into the CLOSEREQ state 🌸
Here's the security bit, and it's serious 🔐 To stop anyone shutting down a multipath connection without permission, the selected Key Data of the peer host MUST be included in the MP_CLOSE option during the handshake, and the peer host MUST validate it. The Key Data in a DCCP-CloseReq won't match the Key Data in a DCCP-Close, because they come from different ends of the connection 👀
When the first DCCP-CloseReq shows up with an MP_CLOSE carrying valid Key Data (or a local decision is made), every subflow moves to the CLOSING state before sending a DCCP-Close with MP_CLOSE 💅 The MP-DCCP connection socket on the host sending the DCCP-Close mirrors the state of the initial subflow from the handshake with the MP_KEY option. If the initial subflow no longer exists, the state goes straight to CLOSED ✨
When the first DCCP-Close with an MP_CLOSE carrying valid Key Data reaches the peer, all subflows and the MP-DCCP connection socket move to the CLOSED state 💀 After that, a DCCP-Reset with Reset Code 1 MUST be sent on any subflow in response to a received DCCP-Close that contains a valid MP_CLOSE option 🫶
When the MP-DCCP connection socket is in the CLOSEREQ or CLOSED state, new subflow requests using MP_JOIN MUST be ignored 🙅♀️
Unlike MP_FAST_CLOSE (Section 3.2.3), no single-sided abrupt termination happens here 🌈 This is the polite, gentle way out.
3.2.12. Experimental Multipath Option MP_EXP for Private Use 🧚
This section sets aside a Multipath Option for experiments 🧪 It's for defining and specifying extra features that make MP-DCCP better or faster. These could be useful for specific environments or scenarios with new requirements, and it's meant for private use only 🔒 MP_OPT Feature Number 11 gets an example description below, as an example and nothing more 💖
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
|0 0 1 0 1 1 1 0| var |0 0 0 0 1 0 1 1| Data |
+---------------+---------------+---------------+---------------+
| ...
+---------------------------------------------------------------+
Type=46 Length MP_OPT=11
Figure 20: Format of the MP_EXP SuboptionThe Data field can carry whatever the experimenters want, as long as the Length is at most 252 bytes 🍓
3.3. MP-DCCP Handshake Procedure
okay bestie, the handshake is where the magic starts 💖 an example MP-DCCP handshake procedure is shown in Figure 21 🦋
Host A Host B
------------------------ ----------
Address A1 Address A2 Address B1
---------- ---------- ----------
| | |
| DCCP-Request + Change R (MP_CAPABLE,...) |
|----- MP_KEY(CI-A + KeyA(1), KeyA(2),...) ---------->|
|<------------------- MP_KEY(CI-B + KeyB) ------------|
| DCCP-Response + Confirm L (MP_CAPABLE, ...) |
| | |
| DCCP-Ack | |
|---------------------------------------------------->|
|<----------------------------------------------------|
| DCCP-Ack | |
| | |
| |DCCP-Request + Change R(MP_CAPABLE,...)|
| |--- MP_JOIN(CI-B,RA) ----------------->|
| |<------MP_JOIN(CI-A,RB) + MP_HMAC(B)---|
| |DCCP-Response+Confirm L(MP_CAPABLE,...)|
| | |
| |DCCP-Ack |
| |-------- MP_HMAC(A) ------------------>|
| |<--------------------------------------|
| |DCCP-Ack |Figure 21: Example MP-DCCP Handshake
the basic initial handshake for the first subflow goes like this 🎀
- Host A sends a DCCP-Request with the Multipath Capable Feature change request and the MP_KEY option with a Host-specific CI-A and a KeyA for each of the supported Key Types as described in 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 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. 💅
- 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. 🎉
it should be noted that DCCP is protected against corruption of DCCP header data (Section 9 of [RFC4340]), so no additional mechanisms beyond the general confirmation are required to ensure that the header data has been properly received. the header is already guarded, so ngl that's giving main character energy 👑
Host A waits for the final DCCP-Ack from Host B before starting any establishment of additional subflow connections. patience is a whole vibe 🧚
the handshake for subsequent subflows, based on a successful initial handshake, is as follows: 🌈
- Host A sends a DCCP-Request with the Multipath Capable Feature change request and the MP_JOIN option with Host B's CI-B, obtained during the initial handshake. Additionally, a random Nonce RA is transmitted with the MP_JOIN. 🍓
- Host B computes the HMAC of the DCCP-Request and sends a DCCP-Response with a Confirm feature option for MP-Capable and the MP_JOIN option with the CI-A and a random Nonce RB together with the computed MP_HMAC. As specified in Section 3.2.6, the HMAC is calculated by taking the leftmost 20 bytes from the SHA-256 hash of an HMAC code that is created by using the Nonce received with MP_JOIN(A) and the local Nonce RB as the Message and the derived key as the Key, as described in Section 3.2.4:
MP_HMAC(B) = HMAC-SHA256(Key=d-keyB, Msg=RB+RA)
- Host A sends a DCCP-Ack with the HMAC computed for the DCCP-Response. As specified in Section 3.2.6, the HMAC is calculated by taking the leftmost 20 bytes from the SHA-256 hash of an HMAC code created by using the local Nonce RA and the Nonce received with MP_JOIN(B) as message and the derived key described in Section 3.2.4 as key:
MP_HMAC(A) = HMAC-SHA256(Key=d-keyA, Msg=RA+RB)
- Host B sends a DCCP-Ack to confirm the HMAC and to conclude the handshake. ✅
3.4. Address Knowledge Exchange
3.4.1. Advertising a New Path (MP_ADDADDR)
when a host (Host A) wants to advertise the availability of a new path, it should use the MP_ADDADDR option (Section 3.2.8) as shown in the example in Figure 22 🛣️ the MP_ADDADDR option passed in the DCCP-Data contains the following parameters:
- an identifier (id 2) for the new IP address, which is used as a reference in subsequent control exchanges 🆔
- a Nonce value to prevent replay attacks 🔐
- the IP address of the new path (A2_IP)
- a pair of bytes specifying the port number associated with this IP address. The value of 00 here indicates that the port number is the same as that used for the initial subflow address A1_IP.
according to Section 3.2.8, the following options are required in a packet carrying MP_ADDADDR:
- the leftmost 20 bytes of the HMAC(A) generated during the initial handshake procedure described in Sections 3.3 and 3.2.6
- the MP_SEQ option with the sequence number (seqno 12) for this message, according to Section 3.2.5
Host B acknowledges receipt of the MP_ADDADDR message with a DCCP-Ack containing the MP_CONFIRM option. the parameters supplied in this response are as follows: 💌
- an MP_CONFIRM containing the MP_SEQ number (seqno 12) of the packet carrying the option that we are confirming together with the MP_ADDADDR option
- the leftmost 20 bytes of the HMAC(B) generated during the initial handshake procedure (Section 3.3)
Host A Host B
------------------------ -----------
Address A1 Address A2 Address B1
---------- ---------- -----------
| | |
| DCCP-Data + MP_ADDADDR(id 2, Nonce, A2_IP, 00) + |
|------- MP_HMAC(A) + MP_SEQ(seqno 12) -------------->|
| | |
| DCCP-Ack + MP_HMAC(B) + |
|<----- MP_CONFIRM(seqno 12, MP_ADDADDR) -------------|Figure 22: Example MP_ADDADDR Procedure
3.4.2. Removing a Path (MP_REMOVEADDR)
when a host (Host A) wants to indicate that a path is no longer available, it should use the MP_REMOVEADDR option (Section 3.2.9) as shown in the example in Figure 23 🚧 the MP_REMOVEADDR option passed in the DCCP-Data contains the following parameters:
- an identifier (id 2) for the IP address to remove (A2_IP) and that was specified in a previous MP_ADDADDR message
- a Nonce value to prevent replay attacks 🔐
according to Section 3.2.9, the following options are required in a packet carrying MP_REMOVEADDR:
- the leftmost 20 bytes of the HMAC(A) generated during the initial handshake procedure described in Sections 3.3 and 3.2.6
- the MP_SEQ option with the sequence number (seqno 33) for this message, according to Section 3.2.5
Host B acknowledges receipt of the MP_REMOVEADDR message with a DCCP-Ack containing the MP_CONFIRM option. the parameters supplied in this response are as follows: 💫
- an MP_CONFIRM containing the MP_SEQ number (seqno 33) of the packet carrying the option that we are confirming, together with the MP_REMOVEADDR option
- the leftmost 20 bytes of the HMAC(B) generated during the initial handshake procedure (Section 3.3)
Host A Host B
------------------------ -----------
Address A1 Address A2 Address B1
---------- ---------- -----------
| | |
| DCCP-Data + MP_REMOVEADDR(id 2, Nonce) + |
|------- MP_HMAC(A) + MP_SEQ(seqno 33) -------------->|
| | |
| DCCP-Ack + MP_HMAC(B) + |
|<----- MP_CONFIRM(seqno 33, MP_REMOVEADDR) ----------|Figure 23: Example MP_REMOVEADDR Procedure
3.5. Closing an MP-DCCP Connection
okay so when a host wants to close one existing subflow but not the whole MP-DCCP connection, it MUST initiate the regular DCCP connection termination procedure as described in Section 5.6 of [RFC4340], i.e., it sends a DCCP-Close/DCCP-Reset on the subflow. this may be preceded by a DCCP-CloseReq. in the event of an irregular termination of a subflow, e.g., during subflow establishment, it MUST use an appropriate DCCP-Reset Code as specified by IANA [DCCP-PARAMETERS] for DCCP operations. this could be, for example, sending Reset Code 5 (Option Error) when an MP-DCCP option provides invalid data or Reset Code 9 (Too Busy) when the maximum number of maintainable paths is reached. note that receiving a Reset Code 9 for secondary subflows MUST NOT impact already existing active subflows. if necessary, these subflows are terminated in a subsequent step using the procedures described in this section. 🙈
a host terminates an MP-DCCP connection using the DCCP connection termination specified in Section 5.5 of [RFC4340] on each subflow, with the first packet on each subflow carrying MP_CLOSE (see Section 3.2.11). 💜
Host A Host B
------ ------
<- Optional DCCP-CloseReq +
MP_CLOSE [A's key]
[on all subflows]
DCCP-Close + MP_CLOSE ->
[B's key] [on all subflows]
<- DCCP-Reset
[on all subflows]additionally, an MP-DCCP connection may be closed abruptly using the "fast close" procedure described in Section 3.2.3, where a DCCP-Reset is sent on all subflows, each carrying the MP_FAST_CLOSE option. 💀
Host A Host B
------ ------
DCCP-Reset + MP_FAST_CLOSE ->
[B's key] [on all subflows]
<- DCCP-Reset
[on all subflows]3.6. Fallback 🦋
okay so, when a subflow isn't doing what MP-DCCP is supposed to do, we have to fall back 🙈 That can mean falling back to regular DCCP [RFC4340], or just removing the problematic subflow. The usual suspects are:
- no MP support at the peer host
- failure to negotiate the protocol version
- loss of Multipath Options
- faulty/non-supported MP-DCCP options
- modification of payload data
At the start of an MP-DCCP connection, the handshake makes sure the MP-DCCP feature and options actually get exchanged, so the path is fully MP-DCCP capable 💅 If the DCCP-Request or DCCP-Response messages don't carry the Multipath Capable Feature during the handshake, the MP-DCCP connection won't get established, and the handshake SHOULD fall back to regular DCCP. If that's not possible, the connection MUST be closed. 😭
If the endpoints can't agree on a protocol version during the Multipath Capable Feature negotiation, the connection MUST either be closed or fall back to regular DCCP. This is described in Section 3.1. Version negotiation is split into two situations: setting up the initial connection, and adding later subflows. If version negotiation fails during the initial connection establishment, the MP-DCCP connection will fall back to regular DCCP.
The fallback procedure for regular DCCP MUST also be applied if the MP_KEY (Section 3.2.4) Key Type cannot be negotiated. 🔑
If a subflow tries to join an existing MP-DCCP connection, but the MP-DCCP options or the Multipath Capable Feature are missing or faulty in the handshake, that subflow MUST be closed. This is especially true if a different MP_CAPABLE version than the originally negotiated one shows up. Getting a non-verifiable MP_HMAC (Section 3.2.6), or an invalid CI used in MP_JOIN (Section 3.2.2), during flow establishment MUST cause the subflow to be closed. Bestie, that's a hard no 🚫
The subflow closing procedure MUST also be applied if a final ACK carrying MP_KEY with the wrong KeyA/KeyB is received, or if the MP_KEY option is malformed.
Then there's the case where middleboxes mess with your payload data 👀 DCCP protects the data with a checksum, as described in Section 9 of [RFC4340]. A checksum fails if the data has changed in any way, and everything from the start of the segment that failed onwards can't be trusted anymore. As DCCP defines it, if the checksum fails, the receiving endpoint MUST drop the application data and report it as dropped due to corruption, using a Data Dropped option (Drop Code 3, Corrupt). If data gets dropped for corruption on an MP-DCCP connection, the affected subflow MAY be closed. The same procedure applies if the Multipath Option is unknown. 💀
3.7. State Diagram 🌈
the MP-DCCP per-subflow state transitions mostly follow the DCCP ones from [RFC4340], with a few tweaks for the MP-DCCP 4-way handshake and the fast close procedure. The diagram below shows the most common transitions. It's illustrative, not exhaustive! For example, there are arcs (not shown) from several other states to TIMEWAIT, which happen when a valid DCCP-Reset is received. 🧚
When the state moves from CLOSED to OPEN during the 4-way handshake, the states themselves stay the same as in DCCP. The difference is that application data can't be sent while you're in the REQUEST state anymore. The fast close procedure can be kicked off by either the client or the server, and it sends a Reset packet. It moves the Client straight to TIMEWAIT, and the Server straight to CLOSED. ⭐
+----------------------------+ +------------------------------+
| v v |
| +----------+ |
| +-------------+ CLOSED +-------------+ |
| | passive +----------+ active | |
| | open open | |
| | snd Request | |
| v v |
| +-----------+ +----------+ |
| | LISTEN | | REQUEST | |
| +-----+-----+ +----+-----+ |
| | rcv Request rcv Response | |
| | snd Response snd Ack | |
| v v |
| +-----------+ +----------+ |
| | RESPOND | | PARTOPEN | |
| +-----+-----+ +----+-----+ |
| | rcv Ack rcv Ack/DataAck | |
| | snd Ack | |
| | +-----------+ | |
| +------------>| OPEN |<-----------+ |
| +--+-+-+-+--+ |
| server active close | | | | active close |
| snd CloseReq | | | | or rcv CloseReq |
| | | | | snd Close |
| | | | | |
| +-----------+ | | | | +----------+ |
| | CLOSEREQ |<---------+ | | +----------->| CLOSING | |
| +-----+-----+ | | +----+-----+ |
| | rcv Close | | rcv Reset | |
| | snd Reset | | | |
| | | | active FastClose | |
|<----------+ rcv Close | | or rcv FastClose v |
| or server active FastClose | | snd Reset +----+-----+ |
| or server rcv FastClose | +------------->| TIMEWAIT | |
| snd Reset | +----+-----+ |
+------------------------------+ | |
+-----------+
2MSL timer expiresFigure 24: Most Common State Transitions of an MP-DCCP Subflow
3.8. Congestion Control Considerations 🚦
Senders MUST keep track of the congestion status for each path, and they MUST NOT send more data down a given path than congestion control allows for that path. Traffic jams are not it, bestie 🚗💨
3.9. Maximum Packet Size Considerations 📏
A DCCP implementation keeps track of the maximum packet size (MPS) while a DCCP session is running. This is specified for single-path DCCP in Section 14 of [RFC4340]. Without any restrictions, the same approach carries over to MP-DCCP, including the Path MTU (PMTU) measurement and the Sender Behavior. The DCCP application interface SHOULD let the application discover the current MPS. That number is the largest size currently supported for the data stream across all of the active MP-DCCP subflows together. 🎀
3.10. Maximum Number of Subflow Considerations 🫧
MP-DCCP doesn't have any explicit way to negotiate the maximum number of subflows between endpoints. In practice though, hosts have resource limits, and some use cases just don't gain anything from extra subflows. 🙃
It is RECOMMENDED to limit the number of subflows in implementations. It is also RECOMMENDED to reject incoming subflow requests with a DCCP-Reset using the Reset Code "too busy" according to [RFC4340], if the resource limit is exceeded or it's known that the multipath connection won't benefit from more subflows. Likewise, it is RECOMMENDED that the host wanting to create the subflows weighs the available resources against the possible gains. Think before you spawn 🧠
To avoid extra inefficiency from short-lived connections, it MAY be useful to delay the start of additional subflows. The decision about how many initial subflows to open can be based on how full the socket buffer is, the timing, or both. 🕰️
With the socket-buffer approach, you keep opening new subflows until their initial windows cover the amount of buffered application data. The timing-based approach waits for a certain period of time, a certain load, or knowledge of the traffic and path properties before starting additional subflows. The delay-based approach also gives resilience to low-bandwidth but long-lived applications. Advanced APIs that signal application traffic requests to MP-DCCP could support all of this too. ✨
3.11. Path Usage Strategies 🛣️
MP-DCCP can be set up to use one of several path usage strategies, by choosing one DCCP subflow out of the many DCCP subflows inside an MP-DCCP connection to carry the data. This can be a dynamic process, helped along by DCCP and MP-DCCP-defined options. Examples are path preference using MP-PRIO, adding or removing subflows with MP_REMOVEADDR, MP_ADDADDR, or DCCP-Close/DCCP-Reset, and path metrics such as packet loss rate, congestion window (CWND), or RTT, as provided by the congestion control algorithm. 📊
Picking the right method lets MP-DCCP realize different path utilization strategies. That's what makes it suitable for end-to-end use over the Internet, or for controlled environments like Hybrid Access or 5G ATSSS. 🌸
3.11.1. Path Mobility 🦋
The path mobility strategy uses a single path, with a seamless handover to keep the connection going when the path currently in use is deemed unsuitable for delivering the service. Some DCCP subflows of an MP-DCCP connection might go inactive, either because of certain error conditions (for example a DCCP timeout, a packet loss threshold, an RTT threshold, or a subflow that was closed or removed), or because the MP-DCCP user adjusted things. 🫠
When there's outbound data to send and the primary path goes inactive (for example due to failures) or gets deprioritized, the MP-DCCP endpoint SHOULD try to send the data through an alternate path with a different source or destination address (depending on where the failure happened), if one exists. This process SHOULD respect the path priority configured by the MP_PRIO suboption. Otherwise, if path priority isn't available, it picks the most divergent source-destination pair from the originally used one. 💖
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 [MP-DCCP.Site].
3.11.2. Concurrent Path Usage ✨
Okay so this one is different from path mobility 🦋. Choosing between MP-DCCP subflows here is a per-packet decision, and it's part of the multipath scheduling process 💅. The big payoff is that several subflows can be used at the same time to pool the path resources, which gets you higher connection throughput 🚀.
Here, the congestion control, the per-packet scheduling, and any reordering method all work together to form a concurrent path utilization strategy, and that strategy decides the transport characteristics you end up with 🌸. A concurrent path usage method can be designed to maximize reliability, maximize throughput, minimize latency, and so on 💖.
Concurrent path usage over the Internet comes with some implications, bestie 😭. When an MP-DCCP connection uses two or more paths, there's no guarantee those paths are fully disjoint 🙈. If two or more subflows share the same bottleneck, then running a standard congestion control algorithm can distribute capacity unfairly. The multipath connection ends up taking more capacity than single-path connections competing with it, and that's not a vibe 💀.
Multipath TCP handles this with the coupled congestion control Linked Increases Algorithm (LIA), which is specified in an experimental specification [RFC6356] 🧚. The same scheme could also be specified for MP-DCCP. Other coupled congestion control algorithms proposed for Multipath TCP, like the Opportunistic Linked Increases Algorithm [OLIA], could work here too 🎀.
The specification of scheduling for concurrent multipath, plus the related congestion control algorithms and reordering methods for general Internet use, is out of scope for this document 🙅♀️. If and when the IETF specifies a method for concurrent usage of multiple paths for the general Internet, the framework in this document could be used to provide an IETF-recommended method for MP-DCCP 👑.
4. Security Considerations 🔐
Okay, this section is serious, so let's go 😤. Just like DCCP, MP-DCCP doesn't inherently provide cryptographic security guarantees 💀. So if applications need cryptographic security (integrity, authentication, confidentiality, access control, and anti-replay protection), then the use of IPsec, DTLS over DCCP [RFC5238], or other end-to-end security is recommended. The Secure Real-time Transport Protocol (SRTP) [RFC3711] is one candidate protocol for authentication. Integrity is provided if you use SRTP together with the encryption of header extensions described in [RFC6904] 🔒.
DCCP [RFC4340] protects against hijacking and limits the potential impact of some denial-of-service attacks 🛡️. But DCCP has no inherent protection against an on-path attacker snooping on data packets 👀. When it comes to MP-DCCP compared to regular DCCP, no additional risks should be introduced 🫶. The security objectives for MP-DCCP are:
- Provide assurance that the parties involved in an MP-DCCP handshake procedure are identical to those in the original DCCP connection.
- Before a path is used, verify that the new advertised path is valid for receiving traffic.
- Provide replay protection, i.e., ensure that a request to add/remove a subflow is 'fresh'.
- Allow a party to limit the number of subflows that it allows.
To hit these goals, MP-DCCP includes a hash-based handshake algorithm documented in Sections 3.2.4, 3.2.6, and 3.3 ✨. The security of an MP-DCCP connection depends on keys that are shared once at the start of the first subflow and are never sent over the network again 🗝️. Depending on the security requirements, different Key Types can be negotiated in the handshake procedure, or the connection must follow the fallback scenario described in Section 3.6. If there are security requirements that go beyond what Key Type 0 can do, then it is RECOMMENDED that Key Type 0 not be enabled, so you don't get downgrade attacks that end up sending the key as plain text 🚨.
To make demultiplexing easy without revealing any cryptographic material, subsequent subflows use the CI information that was exchanged at the start 🧩. The keys exchanged at the beginning get concatenated and used as keys for creating HMACs during subflow setup. This verifies that the parties in the handshake of subsequent subflows are the same as in the original connection setup 💅. It also verifies that the peer can receive traffic at this new address 📬.
Replay attacks would still be possible if only keys were used, so the handshakes use single-use random numbers (Nonces) from both parties. This ensures the HMAC is never the same across two handshakes 🎲. Guidance on generating random numbers suitable for use as keys is given in [RFC4086] 📚. During normal operation, the regular DCCP protection mechanisms (such as the header checksum that protects DCCP headers against corruption) are designed to give the same level of protection against attacks on individual DCCP subflows as regular DCCP has 🥹.
As discussed in Section 3.2.8, a host may advertise its private addresses, but those might point to different hosts in the receiver's network 😬. The MP_JOIN handshake (Section 3.2.2) is designed to make sure this doesn't set up a subflow to the wrong host. However, it could still create unwanted DCCP handshake traffic 🙃. That makes this feature of MP-DCCP a possible target for denial-of-service exploits, where malicious participants in MP-DCCP connections encourage the recipient to target other hosts in the network. Therefore, implementations should consider heuristics at both the sender and the receiver to reduce the impact of this 🧠.
As described in Section 3.9, an MPS is maintained for an MP-DCCP connection. If MP-DCCP exposes a minimum MPS across all paths, then any change to one path impacts the sender for all paths 😱. To mitigate attacks that try to force a low MPS, MP-DCCP could detect an attempt to reduce the MPS to less than a minimum MPS and then stop using these paths 🛑.
5. Interactions with Middleboxes 🧱
Issues from interaction with on-path middleboxes like NATs, firewalls, proxies, IDSs, and others have to be considered for all extensions to standard protocols 🙋♀️. Otherwise, unexpected reactions from middleboxes may hinder deployment. DCCP already gives you ways to reduce the potential impact of middleboxes compared to TCP (see Section 16 of [RFC4340]) ✨. When both hosts are behind a NAT or firewall, you need specific measures, like the simultaneous-open technique in [RFC5596], which updates the asymmetric connection-establishment procedures for DCCP 🤝. More standardized technologies for middleboxes operating as NATs are provided in [RFC5597] 🌈.
[RFC6773] specifies UDP encapsulation for NAT traversal of DCCP sessions 🦋. It's similar to other UDP encapsulations, like the Stream Control Transmission Protocol (SCTP) [RFC6951]. Future IETF specifications could specify other methods for DCCP encapsulation 🔮.
The security impact of MP-DCCP-aware middleboxes is discussed in Section 4 💜.
6. Implementation 🛠️
The approach described above has been implemented as open source across different testbeds, and a new scheduling algorithm has been extensively tested 🧪. Demonstrations of a laboratory setup have also been run and published, so check out [MP-DCCP.Site] 🎀.
7. IANA Considerations 📋
Okay, this section is basically the to-do list for IANA 📝. It gives guidance on registering values related to the MP extension of the DCCP protocol, following the RFC Required policy in Section 4.7 of [RFC8126] 💅. This document defines one new value that gets allocated in the IANA "DCCP Feature Numbers" registry, and it creates three new registries inside the "Datagram Congestion Control Protocol (DCCP) Parameters" registry group 🌸.
7.1. New Multipath Capable DCCP Feature 🙌
IANA assigned a new DCCP feature parameter for negotiating multipath capability for DCCP sessions between hosts, as described in Section 3 🎉. The following entry in Table 6 was added to the "Feature Numbers" registry in the DCCP registry group, according to Section 19.4 of [RFC4340]:
+========+=====================+===========+
| Number | Description/Meaning | Reference |
+========+=====================+===========+
| 10 | Multipath Capable | RFC 9897 |
+--------+---------------------+-----------+
Table 6: Addition to DCCP Feature
Numbers Registry7.2. New MP-DCCP Versions Registry 🔢
Section 3.1 specifies the new 1-byte entry above, which includes a 4-bit part for specifying the version of the MP-DCCP implementation being used 🧩. IANA created a new "MP-DCCP Versions" registry in the DCCP registry group to track the MP-DCCP version. The initial content of this registry is as follows:
+=========+============+===========+
| Version | Value | Reference |
+=========+============+===========+
| 0 | 0000 | RFC 9897 |
+---------+------------+-----------+
| 1-15 | Unassigned | |
+---------+------------+-----------+
Table 7: MP-DCCP Versions RegistryFuture MP-DCCP versions 1 to 15 will be assigned from this registry using the RFC Required policy (Section 4.7 of [RFC8126]) 🚀.
7.3. New Multipath Option Type and Registry 🎀
okay bestie, so this is the part where IANA gets the registry paperwork sorted 📋✨ First up, IANA has assigned value 46 in the DCCP "Option Types" registry, as described in Section 3.2. Super important, that number is the MP-DCCP option type 💖
IANA also made a brand new "Multipath Options" registry inside the DCCP registry group 🌸 The entries in Table 8 got added to it, and the numeric value field has an upper boundary of 255. Literally the cutest little table ever 🦋
+===============+===============+=====================+===========+
| Multipath | Name | Description | Reference |
| Option | | | |
+===============+===============+=====================+===========+
| MP_OPT=0 | MP_CONFIRM | Confirm reception/ | Section |
| | | processing of an | 3.2.1 |
| | | MP_OPT option | |
+---------------+---------------+---------------------+-----------+
| MP_OPT=1 | MP_JOIN | Join subflow to an | Section |
| | | existing MP-DCCP | 3.2.2 |
| | | connection | |
+---------------+---------------+---------------------+-----------+
| MP_OPT=2 | MP_FAST_CLOSE | Close an MP-DCCP | Section |
| | | connection | 3.2.3 |
| | | unconditionally | |
+---------------+---------------+---------------------+-----------+
| MP_OPT=3 | MP_KEY | Exchange key | Section |
| | | material for | 3.2.4 |
| | | MP_HMAC | |
+---------------+---------------+---------------------+-----------+
| MP_OPT=4 | MP_SEQ | Multipath sequence | Section |
| | | number | 3.2.5 |
+---------------+---------------+---------------------+-----------+
| MP_OPT=5 | MP_HMAC | Hash-based message | Section |
| | | authentication code | 3.2.6 |
| | | for MP-DCCP | |
+---------------+---------------+---------------------+-----------+
| MP_OPT=6 | MP_RTT | Transmit RTT values | Section |
| | | and calculation | 3.2.7 |
| | | parameters | |
+---------------+---------------+---------------------+-----------+
| MP_OPT=7 | MP_ADDADDR | Advertise one or | Section |
| | | more additional | 3.2.8 |
| | | addresses/ports | |
+---------------+---------------+---------------------+-----------+
| MP_OPT=8 | MP_REMOVEADDR | Remove one or more | Section |
| | | addresses/ports | 3.2.9 |
+---------------+---------------+---------------------+-----------+
| MP_OPT=9 | MP_PRIO | Change subflow | Section |
| | | priority | 3.2.10 |
+---------------+---------------+---------------------+-----------+
| MP_OPT=10 | MP_CLOSE | Close an MP-DCCP | Section |
| | | connection | 3.2.11 |
+---------------+---------------+---------------------+-----------+
| MP_OPT=11 | MP_EXP | Experimental option | Section |
| | | for private use | 3.2.12 |
+---------------+---------------+---------------------+-----------+
| MP_OPT=12-255 | Unassigned | | |
+---------------+---------------+---------------------+-----------+Table 8: Multipath Options Registry
Future Multipath Options with MP_OPT>11 will be assigned from this registry using the RFC Required policy (Section 4.7 of [RFC8126]) 🔮
7.4. New DCCP-Reset Code 🌈
IANA has assigned a new DCCP-Reset Code, value 13, in the "Reset Codes" registry 🍓 The description is "Abrupt MP termination". Use of this Reset Code is defined in Section 3.2.3 💅
7.5. New Multipath Key Type Registry 🦋
IANA has created a new "Multipath Key Type" registry for this version of the MP-DCCP protocol 💜 It has two different suboptions to the MP_KEY option, which identify the MP_KEY Key types in terms of 8-bit values, as specified in Section 3.2.4. See the initial entries in Table 9 below ✨
Values in the range 1-254 (decimal) inclusive remain unassigned in this specified version 0 of the protocol. They will be assigned via the RFC Required policy [RFC8126] in potential future versions of the MP-DCCP protocol 🧚
+=======+==============+======================+===============+
| Type | Name | Meaning | Reference |
+=======+==============+======================+===============+
| 0 | Plain Text | Plain text Key | Section 3.2.4 |
+-------+--------------+----------------------+---------------+
| 1-254 | Unassigned | | |
+-------+--------------+----------------------+---------------+
| 255 | Experimental | For private use only | Section 3.2.4 |
+-------+--------------+----------------------+---------------+Table 9: Multipath Key Type Registry with the MP_KEY Key Types for Key Data Exchange on Different Paths
8. References 📚
8.1. Normative References 💖
[DCCP-PARAMETERS]
IANA, "Datagram Congestion Control Protocol (DCCP)
Parameters",
<https://www.iana.org/assignments/dccp-parameters>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005,
<https://www.rfc-editor.org/info/rfc4086>.
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram
Congestion Control Protocol (DCCP)", RFC 4340,
DOI 10.17487/RFC4340, March 2006,
<https://www.rfc-editor.org/info/rfc4340>.
[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
(SHA and SHA-based HMAC and HKDF)", RFC 6234,
DOI 10.17487/RFC6234, May 2011,
<https://www.rfc-editor.org/info/rfc6234>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.8.2. Informative References 📚✨
These are the extra reads, bestie. They're informative, so you don't have to implement them, but they're giving background, history, and receipts 💅
- [IETF105.Slides] Amend, M., "MP-DCCP for enabling transfer of UDP/IP traffic over multiple data paths in multi-connectivity networks", IETF 105 Proceedings, July 2019, <https://datatracker.ietf.org/meeting/105/materials/slides-105-tsvwg-sessa-62-dccp-extensions-for-multipath-operation-00>.
- [MP-DCCP.Paper] Amend, M., Bogenfeld, E., Cvjetkovic, M., Rakocevic, V., Pieska, M., Kassler, A., and A. Brunstrom, "A Framework for Multiaccess Support for Unreliable Internet Traffic using Multipath DCCP", 2019 IEEE 44th Conference on Local Computer Networks (LCN), pp. 316-323, DOI 10.1109/LCN44214.2019.8990746, October 2019, <https://doi.org/10.1109/LCN44214.2019.8990746>. 🌈
- [MP-DCCP.Site] "Multipath extension for DCCP", <https://multipath-dccp.org/>. 🦋
- [MULTIPATH-REORDERING] Amend, M. and D. Von Hugo, "Multipath sequence maintenance", Work in Progress, Internet-Draft, draft-amend-iccrg-multipath-reordering-03, 25 October 2021, <https://datatracker.ietf.org/doc/html/draft-amend-iccrg-multipath-reordering-03>. 🧚
- [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, DOI 10.1145/2413176.2413178, December 2012, <https://dl.acm.org/doi/10.1145/2413176.2413178>. 🔥
- [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, DOI 10.17487/RFC2104, February 1997, <https://www.rfc-editor.org/info/rfc2104>. 🔐
- [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, DOI 10.17487/RFC3711, March 2004, <https://www.rfc-editor.org/info/rfc3711>. 🎀
- [RFC5238] Phelan, T., "Datagram Transport Layer Security (DTLS) over the Datagram Congestion Control Protocol (DCCP)", RFC 5238, DOI 10.17487/RFC5238, May 2008, <https://www.rfc-editor.org/info/rfc5238>. 💜
- [RFC5596] Fairhurst, G., "Datagram Congestion Control Protocol (DCCP) Simultaneous-Open Technique to Facilitate NAT/Middlebox Traversal", RFC 5596, DOI 10.17487/RFC5596, September 2009, <https://www.rfc-editor.org/info/rfc5596>. 🌸
- [RFC5597] Denis-Courmont, R., "Network Address Translation (NAT) Behavioral Requirements for the Datagram Congestion Control Protocol", BCP 150, RFC 5597, DOI 10.17487/RFC5597, September 2009, <https://www.rfc-editor.org/info/rfc5597>. 🍓
- [RFC6356] Raiciu, C., Handley, M., and D. Wischik, "Coupled Congestion Control for Multipath Transport Protocols", RFC 6356, DOI 10.17487/RFC6356, October 2011, <https://www.rfc-editor.org/info/rfc6356>. ⭐
- [RFC6773] Phelan, T., Fairhurst, G., and C. Perkins, "DCCP-UDP: A Datagram Congestion Control Protocol UDP Encapsulation for NAT Traversal", RFC 6773, DOI 10.17487/RFC6773, November 2012, <https://www.rfc-editor.org/info/rfc6773>. 🫶
- [RFC6904] Lennox, J., "Encryption of Header Extensions in the Secure Real-time Transport Protocol (SRTP)", RFC 6904, DOI 10.17487/RFC6904, April 2013, <https://www.rfc-editor.org/info/rfc6904>. 🙈
- [RFC6951] Tuexen, M. and R. Stewart, "UDP Encapsulation of Stream Control Transmission Protocol (SCTP) Packets for End-Host to End-Host Communication", RFC 6951, DOI 10.17487/RFC6951, May 2013, <https://www.rfc-editor.org/info/rfc6951>. 🌈
- [RFC7323] Borman, D., Braden, B., Jacobson, V., and R. Scheffenegger, Ed., "TCP Extensions for High Performance", RFC 7323, DOI 10.17487/RFC7323, September 2014, <https://www.rfc-editor.org/info/rfc7323>. 👑
- [RFC8041] Bonaventure, O., Paasch, C., and G. Detal, "Use Cases and Operational Experience with Multipath TCP", RFC 8041, DOI 10.17487/RFC8041, January 2017, <https://www.rfc-editor.org/info/rfc8041>. 🦋
- [RFC8684] Ford, A., Raiciu, C., Handley, M., Bonaventure, O., and C. Paasch, "TCP Extensions for Multipath Operation with Multiple Addresses", RFC 8684, DOI 10.17487/RFC8684, March 2020, <https://www.rfc-editor.org/info/rfc8684>. 💅
- [RFC9293] Eddy, W., Ed., "Transmission Control Protocol (TCP)", STD 7, RFC 9293, DOI 10.17487/RFC9293, August 2022, <https://www.rfc-editor.org/info/rfc9293>. 🔥
- [TS23.501] 3GPP, "System architecture for the 5G System; Stage 2; Release 16", Version 16.7.0, Release 16, December 2020, <https://www.3gpp.org/ftp//Specs/archive/23_series/23.501/23501-g70.zip>. 📡
- [U-DCCP] Amend, M., Brunstrom, A., Kassler, A., and V. Rakocevic, "Lossless and overhead free DCCP - UDP header conversion (U-DCCP)", Work in Progress, Internet-Draft, draft-amend-tsvwg-dccp-udp-header-conversion-01, 8 July 2019, <https://datatracker.ietf.org/doc/html/draft-amend-tsvwg-dccp-udp-header-conversion-01>. 🎀
Appendix A. Differences from Multipath TCP ✨
This appendix is informative. 🦋
okay so MP-DCCP is basically the cousin of Multipath TCP [RFC8684] 💖 It takes the basic DCCP transport protocol [RFC4340] and gives it multipath powers, the same way Multipath TCP glows up TCP [RFC9293]. BUT, and this is a big but, DCCP and TCP are very different underneath, so MPTCP and MP-DCCP don't act the same. Not me being dramatic, it's just the facts 💅
Table 10 lays out the basic TCP vs DCCP vibes. These are the traits that each multipath extension inherits 🌸 The big difference is what happens to the payload. TCP delivers an exact copy of the byte stream the sender made. DCCP doesn't do that. It doesn't guarantee that any payload arrives, and it doesn't guarantee the order either 😭 This mostly changes things for the receiving end of a TCP or DCCP connection, so the sender side looks pretty similar in both. Both of them start a connection with the 3-way handshake, and both use congestion control to match their sending rate to what the path can handle ✨
+=======================+================+======================+
| Feature | TCP | DCCP |
+=======================+================+======================+
| Full-Duplex | yes | yes |
+-----------------------+----------------+----------------------+
| Connection-Oriented | yes | yes |
+-----------------------+----------------+----------------------+
| Header option space | 40 bytes | < 1008 bytes or PMTU |
+-----------------------+----------------+----------------------+
| Data transfer | reliable | unreliable |
+-----------------------+----------------+----------------------+
| Packet-loss handling | retransmission | report only |
+-----------------------+----------------+----------------------+
| Ordered data delivery | yes | no |
+-----------------------+----------------+----------------------+
| Sequence numbers | one per byte | one per PDU |
+-----------------------+----------------+----------------------+
| Flow control | yes | no |
+-----------------------+----------------+----------------------+
| Congestion control | yes | yes |
+-----------------------+----------------+----------------------+
| ECN support | yes | yes |
+-----------------------+----------------+----------------------+
| Selective ACK | yes | depends on |
| | | congestion control |
+-----------------------+----------------+----------------------+
| Fix message | no | yes |
| boundaries | | |
+-----------------------+----------------+----------------------+
| Path MTU discovery | yes | yes |
+-----------------------+----------------+----------------------+
| Fragmentation | yes | no |
+-----------------------+----------------+----------------------+
| SYN flood protection | yes | no |
+-----------------------+----------------+----------------------+
| Half-open connections | yes | no |
+-----------------------+----------------+----------------------+
Table 10: TCP and DCCP Protocol ComparisonSo the multipath traits in Table 11 are the same for both, and they cover volatile paths with changing capacity and latency, session handovers, and path aggregation. 🦋 All of these perks get a boost from having congestion control around 👑
+==================+=======================+==========+
| Feature | MPTCP | MP-DCCP |
+==================+=======================+==========+
| Volatile paths | yes | yes |
+------------------+-----------------------+----------+
| Session handover | yes | yes |
+------------------+-----------------------+----------+
| Path aggregation | yes | yes |
+------------------+-----------------------+----------+
| Data reordering | yes | optional |
+------------------+-----------------------+----------+
| Expandability | limited by TCP header | flexible |
+------------------+-----------------------+----------+
Table 11: MPTCP and MP-DCCP Protocol ComparisonWhich means the sender logic isn't that different between MP-DCCP and MPTCP. Iconic, honestly 🙈
The receiver side is where MP-DCCP has to do the heavy lifting, since DCCP's delivery is unreliable 😭 The multipath sequence numbers in MP-DCCP (see Section 3.2.5) make it easier to add optional mechanisms for reordering the data stream at the receiver 🧚 The MP_RTT Multipath Option (Section 3.2.7), DCCP path sequencing, and the DCCP Timestamp Option also give extra tools for fancier reordering approaches, like the one proposed in [MULTIPATH-REORDERING] 💜 Those mechanisms don't affect interoperability and aren't part of the MP-DCCP protocol itself, so no stress. Plenty of apps built on unreliable transports can already handle out-of-sequence data (adaptive audio and video buffers, for example), so extra reordering support might not even be needed 🎀 Adding optional reordering mechanisms will likely matter more when the DCCP subflows run over paths with different latencies. In theory, apps using DCCP already know that packets might get reordered, because DCCP doesn't have a way to restore the original packet order 🌈
Compare that to TCP, where the receiver processing in MPTCP took a rigid "just wait" approach, because TCP guarantees reliable in-order delivery 🍓
Acknowledgments
[RFC8684] defines Multipath TCP and gave this specification some important inputs 💖
The authors gratefully acknowledge the significant input into this document from Dirk von Hugo, Nathalie Romo Moreno, Omar Nassef, Mohamed Boucadair, Simone Ferlin, Olivier Bonaventure, Gorry Fairhurst, and Behcet Sarikaya. Thank you, besties 🫶✨
Authors' Addresses
Markus Amend (editor) 🎀
Markus Amend (editor)
Deutsche Telekom
Deutsche-Telekom-Allee 9
64295 Darmstadt
Germany
Email: Markus.Amend@telekom.deAnna Brunstrom
Karlstad University
Universitetsgatan 2
SE-651 88 Karlstad
Sweden
Email: anna.brunstrom@kau.seAndreas Kassler
Karlstad University
Universitetsgatan 2
SE-651 88 Karlstad
Sweden
Email: andreas.kassler@kau.seVeselin Rakocevic
City St George's, University of London
Northampton Square
London
United Kingdom
Email: veselin.rakocevic.1@city.ac.ukStephen Johnson
BT
Adastral Park
Martlesham Heath
IP5 3RE
United Kingdom
Email: stephen.h.johnson@bt.comThat's the whole thing, bestie 🦋💅 The end!
📦 where this page comes from
- ietf: rfc9897 2026-01
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms