Datagram Congestion Control Protocol (DCCP) Extensions for Multipath Operation with Multiple Addresses
Extracted elements (31)
Address IDs are used for address removal (via MP_REMOVEADDR) rather than source IP addresses to enable address removal through NATs and other middleboxes that rewrite source addresses. This design, borrowed from MPTCP, also allows correlation between MP_JOIN and MP_ADDADDR to prevent duplicate subflows on the same path.
MP-DCCP does not apply its own encryption mechanisms, making it an efficient choice for traffic that is already encrypted or does not need encryption. This design keeps MP-DCCP lean and consistent with DCCP's core service model, while still providing HMAC-based authentication against on-path attackers for control plane messages.
The 48-bit MP_SEQ sequence number was chosen because, compared to TCP where sequence numbers are byte-based, DCCP increments per packet. At the current globally routable MPS of 1500 bytes, 48 bits corresponds to roughly 375 PiBs of data within the sequence number space, making it sufficiently large without requiring 64 bits as recommended for TCP.
During the MP-DCCP fallback procedure, if DCCP-Request or DCCP-Response messages do not carry the Multipath Capable Feature, the connection SHOULD fall back to regular DCCP; if fallback is not possible, the connection MUST be closed. A subflow attempting to join an existing connection with missing or faulty options MUST be closed rather than falling back.
An Address ID MUST always be unique over the lifetime of a subflow and can only be reassigned if sender and receiver no longer have them in use. A host MUST store the mappings between Address IDs and addresses for both itself and the remote host.
An MP_HMAC MUST directly follow its associated Multipath Option so that the receiver can correctly associate HMAC validation with the corresponding suboption (MP_JOIN, MP_ADDADDR, or MP_REMOVEADDR). If the HMAC validation fails for MP_JOIN, the subflow MUST be closed; for MP_ADDADDR or MP_REMOVEADDR, the receiving host MUST silently ignore the option.
At least Key Type 0 (Plain Text) MUST be supported for interoperability tests in implementations of MP-DCCP. If the CI cannot be verified by the receiving host during a handshake negotiation, the new subflow MUST be closed.
Clients MUST include a Change R option during the initial handshake request to supply a list of supported MP-DCCP protocol versions ordered by preference. Servers MUST include a Confirm L option in the subsequent response to agree on an MP-DCCP version from the client list, followed by the server's own supported versions ordered by preference.
If a sending host of an MP_ADDADDR knows that no incoming subflows can be established at a particular address, an MP_ADDADDR MUST NOT announce that address unless the sending host has new knowledge about the possibility to do so. The advertisement of broadcast or multicast IP addresses MUST be ignored by the recipient.
If version negotiation fails or the Multipath Capable Feature is not present in the DCCP-Request or DCCP-Response packets, the MP-DCCP connection either MUST fall back to regular DCCP or MUST close the connection. If the Key Type cannot be agreed in the handshake, the MP-DCCP connection MUST also fall back to not using MP-DCCP.
MP_FAST_CLOSE MUST be sent from the initiating host on all subflows using a DCCP-Reset packet with Reset Code 13. After sending, Host A MUST tear down all subflows immediately. Upon reception with valid Key Data, Host B MUST send a DCCP-Reset on all subflows and MUST tear down all subflows.
Multipath Options requiring confirmation (MP_ADDADDR, MP_REMOVEADDR, MP_PRIO) MUST be sent in a DCCP datagram with MP_SEQ to allow the receiver to identify whether options are associated with obsolete datasets. The order of confirmed Multipath Options in the MP_CONFIRM list MUST reflect the incoming order at the confirming host, with the most recent suboption listed first.
The MP_SEQ number space is independent of the path-individual sequence number space and MUST be sent with all DCCP-Data and DCCP-DataACK packets. When the sequence number space is exhausted, the sequence number MUST be wrapped.
The Multipath Capable Feature negotiation MUST be part of the initial handshake procedure, and no subsequent renegotiation of the Multipath Capable Feature is allowed for the same MP-DCCP connection. Any subflow added to an existing MP-DCCP connection MUST use the version negotiated for the first subflow.
To gracefully close an MP-DCCP connection, the regular DCCP termination procedure MUST be initiated on all subflows with the first packet on each subflow carrying MP_CLOSE. The selected Key Data of the peer host MUST be included in MP_CLOSE and MUST be validated by the peer host to prevent unauthorized shutdown.
IANA creates a new MP-DCCP Versions Registry. Version 0 is defined by this document; future versions require Standards Action. The registry tracks compatible MP-DCCP implementation versions.
IANA registers a new Multipath Capable DCCP Feature with Feature Number 10, Reconciliation Rule SP (server-priority), Initial Value 0, and Required=N (behaves as an extension).
IANA registers a new Multipath Option type 46 for DCCP and creates a new Multipath Option Type Registry with MP_OPT values 0–11 defined (MP_CONFIRM through MP_EXP), values 12 and above reserved for future use.
IANA registers new DCCP-Reset Code 13 for use with MP_FAST_CLOSE to signal an abrupt MP-DCCP connection closure. IANA also creates a new Multipath Key Type Registry with Key Type 0 (Plain Text, 8 bytes) and Key Type 255 (Experimental, 64 bytes) defined.
MP_CLOSE and MP_FAST_CLOSE include the peer's Key Data to prevent unauthorized shutdown of MP-DCCP connections. The Nonce in MP_JOIN, MP_ADDADDR, and MP_REMOVEADDR prevents replay attacks. An MP_SEQ accompanies options requiring confirmation to prevent inconsistencies from reordering.
MP-DCCP uses HMAC-SHA256 (truncated to 160 bits) to authenticate MP_ADDADDR and MP_REMOVEADDR messages and to authenticate new subflows joining via MP_JOIN, protecting against unauthorized injection of address signals or connection hijacking by on-path attackers. The key material is exchanged in plain text during the initial handshake (Key Type 0), providing protection only against off-path attackers.
MP-DCCP per-subflow states follow DCCP state transitions (CLOSED → REQUEST → PARTOPEN → OPEN → CLOSEREQ/CLOSING → TIMEWAIT → CLOSED) with modifications for the 4-way handshake. Fast close (MP_FAST_CLOSE) transitions Client to TIMEWAIT and Server to CLOSED directly; application data cannot be sent while in REQUEST state.
MP_ADDADDR (MP_OPT=7) has variable length (12–26 bytes): Type=46, MP_OPT=7, 1-byte Address ID, 4-byte Nonce, 4-byte IPv4 or 16-byte IPv6 address, optional 2-byte port. Must be followed by an MP_HMAC option.
MP_HMAC (MP_OPT=5) is 23 bytes: Type=46, Length=23, MP_OPT=5, followed by 20 bytes of HMAC-SHA256 output truncated to the leftmost 160 bits (big-endian). Provides authentication for MP_JOIN, MP_ADDADDR, and MP_REMOVEADDR.
MP_JOIN (MP_OPT=1) is 12 bytes: Type=46, Length=12, MP_OPT=1, 1-byte Address ID, 4-byte Connection Identifier, 4-byte Nonce. Used to add a new subflow to an existing MP-DCCP connection.
MP_PRIO (MP_OPT=9) is 4 bytes: Type=46, Length=4, MP_OPT=9, with a 4-bit reserved field and a 4-bit priority value (0=do not use, 1=standby, 2=secondary, 3–15=primary with higher numbers indicating higher priority).
MP_REMOVEADDR (MP_OPT=8) is 8 bytes: Type=46, Length=8, MP_OPT=8, 1-byte Address ID, 4-byte Nonce. Must be immediately followed by an MP_HMAC option. Address removal is done by Address ID to support NAT traversal.
MP_RTT (MP_OPT=6) is 12 bytes: Type=46, Length=12, MP_OPT=6, 1-byte RTT Type (0=Raw, 1=Min, 2=Max, 3=Smooth), 4-byte RTT value (32-bit integer, ~1193 hours range), and 4-byte Age in milliseconds since the RTT measurement was taken.
MP_SEQ (MP_OPT=4) is 9 bytes: Type=46, Length=9, MP_OPT=4, followed by a 48-bit multipath sequence number providing end-to-end datagram sequencing for the MP-DCCP connection. The IDSN SHOULD be set randomly.
The Multipath Capable Feature Value Field is 1 byte: the leftmost 4 bits specify the MP-DCCP version (MUST be 0 in this specification), and the following 4 bits are unassigned (MUST be set to zero by sender, MUST be ignored by receiver).
The Multipath Option uses Type=46 with variable length; the third byte is the MP_OPT sub-type field (values 0–11 defined), followed by value bytes. All multipath operations are signaled through this single option type.