Summary

  • RFC 9897 specifies how endpoints negotiate MP-DCCP, advertise addresses and authenticate an additional subflow into an existing connection.
  • MP_CONFIRM and MP_JOIN prove bounded control facts. They do not prove scheduler use, timely receipt, successful reordering, failover or an application-level resilience result.

The operations screen is green. A second subflow has completed its handshake, its connection identifier resolves, and its HMAC binds the join to the parties that opened the first flow. The service owner asks a different question: which important datagram crossed that path when the primary path deteriorated? The control log cannot answer.

RFC 9897, published as a Proposed Standard in January 2026, extends DCCP for multipath operation. The RFC Editor record fixes that publication identity. The base RFC 4340 service remains congestion-controlled and unreliable: MP-DCCP can expose several DCCP subflows as one connection without converting datagrams into a reliable byte stream.

The first subflow negotiates the Multipath Capable feature and exchanges host-specific key material. A later subflow carries MP_JOIN, the peer's Connection Identifier and a fresh nonce; MP_HMAC helps establish that the joining parties belong to the original connection. This is valuable. It distinguishes an authenticated association from an arbitrary flow claiming membership. But successful association says nothing yet about which application packet the scheduler selected for that subflow.

Address signaling sits one rung lower. MP_ADDADDR advertises an address and optional port, protected by HMAC and sequenced to distinguish newer information from stale information. The peer can retain or discard the advertisement. MP_CONFIRM makes the exchange of the option reliable, yet the RFC expressly leaves subsequent processing outside the confirmation's meaning. A confirmed advertisement is not a completed join. A completed join is not observed data-plane use.

The distinction is designed into the standard. MP-DCCP supplies connection-level sequence numbers and RTT information that may support reordering, and it carries path-priority hints. It leaves the sender's scheduling algorithm, the receiver's optional reordering mechanism, and the policy for when and in what sequence to add or remove subflows to endpoints. Even the maximum number of subflows is not negotiated by a protocol procedure; implementations are expected to impose sensible resource limits.

That local freedom is where service behavior is made. In a mobility strategy, an endpoint may try an alternate path when the primary one becomes unsuitable. The rule for choosing the best source-destination pair is still an implementation decision. Under concurrent use, the scheduler chooses per packet, while congestion control and possible reordering shape the result. Several subflows may share one bottleneck, so a larger path count does not prove independent failure domains or additional capacity.

The security boundary is equally narrow. RFC 9897 protects joins and selected control messages within its key model, but does not inherently supply all cryptographic guarantees an application may need. It points to end-to-end protections such as DTLS over DCCP. Nor does an address identifier defeat every middlebox. DCCP-UDP offers an encapsulation method for traversal, but RFC 9897 keeps that method outside MP-DCCP itself.

The design borrows multipath vocabulary and signaling ideas from RFC 8684, while the path-limit discussion cites RFC 8041. Those records are useful context, not permission to import MPTCP's delivery properties or operational experience into MP-DCCP. The IANA DCCP registry proves that Feature 10, Option 46, version 0 and the multipath suboptions have authoritative assignments; it does not prove that a deployed endpoint supports or uses them correctly.

An operator therefore needs four joined ledgers. The control ledger records capability negotiation, address advertisements, confirmations, joins, nonces, key types and close/fallback events. The path ledger records scheduler decisions, source-destination tuples, congestion admission, packet timing, loss and shared-bottleneck evidence. The receiver ledger records arrival, sequence gaps, late packets and any reordering action. The service ledger records whether the application met the exact failover, latency, continuity or aggregation objective.

Heng Lu's Minimum Initial Specification explains why the RFC need not dictate one universal scheduler: keep the interoperable settlement thin, and leave future operating decisions where they can be observed and reversed. Running-Code Primacy demands the packet and service evidence. Reality Layers prevents an authenticated symbol in a control log from becoming authority over a later application outcome.

The standard gives the second path a disciplined way to join. Resilience begins only when the evidence continues beyond that join.

Sources