https://www.rfc-editor.org/rfc/rfc10069.txt

 Internet Engineering Task Force (IETF) 刘彦梅 (Y. Liu), Ed. Request for Comments: 10069 Alibaba Inc. Category: Standards Track 马云飞 (Y. Ma) ISSN: 2070-1721 Harvey AI Q. De Coninck, Ed. University of Mons (UMONS) O. Bonaventure UCLouvain and WELRI C. Huitema Private Octopus Inc. M. Kühlewind, Ed. Ericsson November 2026 Managing Multiple Paths for a QUIC Connection Abstract 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. 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/rfc10069. 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. Conventions and Definitions 2. Connection Lifecycle and Packet Protection 2.1. initial_max_path_id Transport Parameter 2.2. Relation to Other Transport Parameters 2.3. Handling ACK and PATH_ACK in 0-RTT and 1-RTT 2.4. Nonce Calculation after Handshake Completion 2.5. Key Phase Update Process 2.6. Connection Closure 3. Path Management 3.1. Path Initiation and Validation 3.1.1. Path Establishment Example 3.1.2. Relation to Probing and Migration 3.1.3. Address Validation Token 3.2. Handling Connection IDs 3.2.1. Issuing New Connection IDs 3.2.2. Rotating and Retiring Connection IDs 3.3. Path Status Management 3.4. Path Close 3.4.1. Path Closure Example 3.4.2. Avoiding Spurious Stateless Resets 3.4.3. Handling PATH_ACK for Abandoned Paths 4. New Frames 4.1. PATH_ACK Frame 4.2. PATH_ABANDON Frame 4.2.1. Error Codes 4.3. PATH_STATUS_AVAILABLE and PATH_STATUS_BACKUP Frames 4.4. PATH_NEW_CONNECTION_ID Frame 4.5. PATH_RETIRE_CONNECTION_ID Frame 4.6. MAX_PATH_ID Frame 4.7. PATHS_BLOCKED and PATH_CIDS_BLOCKED Frames 5. Implementation Considerations 5.1. Connection ID Changes, Migration, and NAT Rebindings 5.2. Using Multiple Paths on the Same 4-tuple 5.3. Congestion Control 5.4. Computing Path RTT 5.5. Packet Scheduling 5.6. Retransmissions 5.7. PTO Expiration 5.8. Paths Having Different PMTU Sizes 5.9. Idle Timeout and Keep-Alives 6. IANA Considerations 7. Security Considerations 7.1. Memory Allocation for Per-Path Resources 7.2. Denial of Service with Multiple Paths 7.3. Cryptographic Handshake and AEAD Nonce 8. References 8.1. Normative References 8.2. Informative References Acknowledgments Authors' Addresses 1. Introduction 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 pre