TCP Extensions for Multipath Operation with Multiple Addresses
obsoletes
- rfc-6824 — TCP Extensions for Multipath Operation with Multiple Addresses
Extracted elements (28)
Address IDs are used instead of raw IP addresses to identify endpoints, so that address removal and subflow association work correctly through NATs that change the source IP address. The Address ID is locally assigned by the sender and must map uniquely to a source address.
MPTCP uses a shared receive window across all subflows rather than per-subflow windows to prevent subflow starvation: with per-subflow windows, slower or temporarily stalled subflows would consume receive window that faster subflows could use, reducing aggregate throughput.
The Data Sequence Mapping covers a range of bytes (subflow sequence space + length) rather than using per-packet signaling, to handle TCP segmentation offloading on NICs and Performance Enhancing Proxies that split or coalesce segments independently of the stack generating the data.
MPTCP v1 is not backward compatible with v0 (RFC 6824). When a v1 initiator contacts a v0-only listener, the listener ignores the v1 SYN (which lacks a key) and replies without MP_CAPABLE. The v1 initiator MAY then retry with v0 if it supports it, or fall back to plain TCP.
A crypto algorithm MUST be specified in the MP_CAPABLE flags (bits D–H). If all five flag bits are 0, the MP_CAPABLE option MUST be treated as invalid and ignored, falling back to regular TCP. The responder selects from the initiator's proposal by setting exactly one bit.
A host MUST NOT close all functioning subflows unless all outstanding data has been DATA_ACKed or the DATA_FIN segment is the only outstanding segment. Once a DATA_FIN has been acknowledged, all remaining subflows MUST be closed with standard FIN exchanges.
A host MUST store the mappings between Address IDs and addresses for both itself and the remote host. The Address IDs of the initial subflow are implicit and have value zero.
A host's MPTCP key MUST be hard to guess and MUST be unique across all current MPTCP connections on that host. An implementation SHOULD check its list of connection tokens for collisions before sending a key and generate a new key if a collision is found.
A sender MUST NOT change a declared Data Sequence Mapping after it has been sent. A TCP subflow MUST NOT use the Urgent Pointer to interrupt an existing DSS mapping.
An implementation MUST NOT use the RCV.WND field of a TCP segment at the connection level if the segment does not also carry a DSS option with a Data ACK field. A receiver MUST NOT shrink the right edge of the receive window (DATA_ACK + receive window).
An MPTCP implementation receiving a duplicate ACK that contains an MPTCP option MUST NOT treat it as a signal of congestion. An implementation SHOULD NOT send more than two duplicate ACKs in a row solely for the purpose of carrying MPTCP options.
An MPTCP sender MUST NOT free data from the send buffer until it has been acknowledged by both a Data ACK on any subflow and at the subflow level by all subflows on which the data was sent.
Data sequence numbers MUST be maintained as 64-bit quantities internally. An implementation MUST send the full 64-bit DSN when transmitting at a rate where the 32-bit value could wrap within the MSL. Implementations MUST accept both 32-bit and 64-bit DSN values and MUST promote 32-bit values to 64-bit.
Demultiplexing of subflow SYNs MUST be done using the token (not destination port as in standard TCP). If the token is unknown or local policy prohibits the subflow, the receiver MUST respond with a TCP RST, optionally including MP_TCPRST with an 'Administratively prohibited' reason code.
If either host sets the Checksum Required bit (A=1) in its MP_CAPABLE SYN, checksums MUST be used for the connection. If a host receives A=1 but does not want to use checksums, it MUST fall back to regular TCP by ignoring the MP_CAPABLE option.
New subflows MUST NOT be established using MP_JOIN until a DSS option has been successfully received across the path. If at any point the MPTCP negotiation is compromised by a middlebox, the host MUST stop using MPTCP and no longer include MPTCP options in future packets.
The connection token MUST be the most significant 32 bits of the SHA-256 hash of the host's key, and the IDSN MUST be the least significant 64 bits of the SHA-256 hash of the key. The key MUST be hashed in network byte order.
MP_FASTCLOSE is an abrupt connection close analogous to TCP RST. It can be sent on an ACK (reliable) or RST (unreliable). It carries the peer's key and causes the receiver to RST all subflows. It is the only time after the handshake that a key is sent in the clear.
MP_TCPRST is a subflow reset option that carries a reason code explaining why the subflow was reset. It is carried on TCP RST segments and SHOULD be included whenever a subflow is closed with a RST due to an MPTCP-specific error.
The ADD_ADDR option advertises an additional address to the remote host and includes an Echo flag, the IP address, an Address ID, and an HMAC authenticating the advertisement. The receiver MUST echo it back (Echo-flag=1) to confirm receipt, enabling the sender to retransmit if no echo is received.
The REMOVE_ADDR option signals removal of a previously advertised address using its Address ID, allowing address removal even through NATs without knowing the actual IP address at the receiver.
This document creates or updates four IANA registries: TCP Option Kind Numbers (assigning a single kind for all MPTCP options), MPTCP Option Subtypes (subtype values 0x0–0xF), MPTCP Handshake Algorithms (cryptographic algorithm identifiers), and MP_TCPRST Reason Codes.
Keys are sent in the clear only in the MP_CAPABLE handshake and MP_FASTCLOSE; all subsequent subflow authentications use HMAC-SHA256 over the exchanged keys and per-connection random nonces to prevent replay attacks. ADD_ADDR is protected by an HMAC to prevent address injection by on-path attackers.
Standard TCP validity checks (sequence number and acknowledgment number in-window per RFC 5961) MUST be performed before processing any MPTCP signals, providing a baseline defense against blind injection attacks on MPTCP signaling.
The MP_JOIN ACK places the subflow in the PRE_ESTABLISHED state; it transitions to ESTABLISHED only on receipt of a TCP ACK from the peer. Data MUST NOT be sent while in PRE_ESTABLISHED. The ACK carrying the initiator's 160-bit HMAC must be retransmitted until acknowledged.
The Data Sequence Signal (DSS) option carries up to five variable-length fields controlled by flags: Data ACK (4 or 8 octets), Data Sequence Number (4 or 8 octets), Subflow Sequence Number (4 octets), Data-Level Length (2 octets), and optional Checksum (2 octets). Maximum option length with all flags set is 28 octets.
The MP_CAPABLE option has variable length depending on which handshake packet it appears in: SYN carries only the 4-byte header (Kind, Length, Subtype, Version, flags); SYN/ACK adds the sender's 64-bit key (Length=12); ACK adds both keys (Length=20); ACK with first data also includes Data-Level Length and optional Checksum (Length=22 or 24).
The MP_JOIN SYN option (Length=12) carries: Subtype, 3 reserved bits, B (backup) flag, Address ID (8 bits), Receiver's Token (32 bits), and Sender's Random Number (32 bits). The SYN/ACK variant (Length=16) replaces the token with a truncated 64-bit HMAC and adds its own nonce. The ACK variant (Length=24) carries only the full 160-bit truncated HMAC.