RFC 10069: Managing Multiple Paths for a QUIC Connection | RFC Editor

This document specifies a multipath extension for the QUIC protocol to enable the simultaneous usage of multiple paths for a single connection. It introduces explicit path identifiers to create, delete, and manage multiple paths. This document does not specify address discovery or management, nor how applications using QUIC schedule traffic over multiple paths.¶
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/rfc10069.¶
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.¶
This document specifies an extension to QUIC version 1 [QUIC-TRANSPORT] to enable the simultaneous usage of multiple paths for a single connection, using the same or different 4-tuples (of source/destination port numbers and source/destination IP addresses).¶
Connection migration as specified in Section 9 of [QUIC-TRANSPORT] directs a peer to switch sending through a new preferred path and, if successful, to release resources associated with the old path. The multipath extension specified in this document builds on this mechanism but introduces a path identifier, or path ID, to manage connection IDs and packet number spaces per path, enabling the use of multiple paths simultaneously. As such, a path in this extension is defined by its path ID. Note that it therefore is possible to have multiple paths / path IDs for the same 4-tuple.¶
The connection ID of a packet binds the packet to a path ID and therefore to a packet number space. That means each connection ID is associated with exactly one path ID but multiple connection IDs are usually issued for each path ID. The same path ID is used in both directions, starting with 0 for the initial path. Path IDs are monotonically increasing and cannot be reused.¶
This extension uses multiple packet number spaces, specifically one for each path. Each path ID-specific packet number space starts at packet number 0. As such, each path maintains distinct packet number states for sending and receiving packets, as in [QUIC-TRANSPORT]. Using multiple packet number spaces enables direct use of the loss detection and congestion control mechanisms defined in [QUIC-RECOVERY] on a per-path basis. However, use of multiple packet number spaces requires non-zero connection IDs in order to identify the path and the respective packet number space, as well as a modified Authenticated Encryption with Associated Data (AEAD) calculation including the path ID (see Section 2.4).¶
As such, this extension specifies a departure from the specification of path management in Section 9 of [QUIC-TRANSPORT] and therefore requires a new transport parameter, as specified in Section 2.1, to indicate support of the multipath extension specified in this document.¶
Further, this document specifies the needed path management mechanisms for path initiation in Section 3.1, handling of per-path connection IDs in Section 3.2, signaling of preferred path usage in Section 3.3, and explicit removal of paths that have been abandoned in Section 3.4. Note that in this extension, a QUIC server does not initiate the creation of a path, but it has to validate a new path created by a client.¶
This extension does not cover address discovery and management. The extension specified in this document can be used as is if address management and the actual decision to set up or tear down paths are handled by the application. This document does not prevent future extensions from defining mechanisms to cope with the remaining scenarios.¶
Further, this document does not specify scheduling algorithms that define how multiple, simultaneously open paths are used to send packets. As these differ depending on application requirements, only some basic implementation guidance is discussed in Section 5. This extension can be used with different scheduling algorithms that, e.g., can range from support for failover to simultaneous use of the aggregated capacity across all open paths. There are currently no IETF specifications that define scheduling algorithms for simultaneously (i.e., concurrently) using multiple paths.¶
Specifically, while failover between Wi-Fi and mobile networks is a well-known multipath use case, it only temporarily uses two paths at the same time to avoid transmission pauses. Simultaneous path usage generally, however, needs more consideration than specified in this document to avoid negative performance impacts, e.g., when stream data is distributed over multiple paths with different delays.¶
The operational considerations for QUIC are addressed in [RFC9312]. They also apply to QUIC connections using the extensions defined in this document. An additional complexity is that applications might use a combination of monitored and non-monitored paths, but that complexity already exists when using path migration as defined in [QUIC-TRANSPORT].¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in thi