9. Connection Migration

The use of a connection ID allows connections to survive changes to endpoint addresses (IP address and port), such as those caused by an endpoint migrating to a new network. This section describes the process by which an endpoint migrates to a new address.

The design of QUIC relies on endpoints retaining a stable address for the duration of the handshake. An endpoint MUST NOT initiate connection migration before the handshake is confirmed, as defined in Section 4.1.2 of [QUIC-TLS].

A client is responsible for initiating all migrations. Servers do not send non-probing packets (see Section 9.1) toward a client address until they see a non-probing packet from that address.

9.1 Probing a New Path

An endpoint MAY probe for peer reachability from a new local address using path validation (Section 8.2) prior to migrating the connection to the new local address.

9.2 Initiating Connection Migration

An endpoint can migrate a connection to a new local address by sending packets containing non-probing frames from that address.

9.3 Responding to Connection Migration

Receiving a packet from a new peer address containing a non-probing frame indicates that the peer has migrated to that address.

9.3.1 Peer Address Spoofing

It is possible that a peer is spoofing its source address to cause an endpoint to send excessive amounts of data to an unwilling host.

9.3.2 On-Path Address Spoofing

An on-path attacker could cause a spurious connection migration by copying and forwarding a packet with spoofed address information.

9.3.3 Off-Path Packet Forwarding

An off-path attacker that can observe packets might forward copies of genuine packets to endpoints.

9.4 Loss Detection and Congestion Control

The capacity available on a new path might not be the same as the old path. Packets sent on the old path MUST NOT contribute to congestion control or RTT estimation for the new path.

9.5 Privacy Implications of Connection Migration

Using a stable connection ID on multiple network paths allows a passive observer to correlate activity between those paths.

9.6 Server's Preferred Address

QUIC allows servers to accept connections on one IP address and transfer these connections to a more preferred address shortly after the handshake.

9.6.1 Communicating a Preferred Address

A server conveys a preferred address by including the preferred_address transport parameter in the TLS handshake.

9.6.2 Migration to a Preferred Address

A client that migrates to a preferred address MUST validate the new path before sending any data to that address.

9.6.3 Interaction of Client Migration and Preferred Address

A client might need to perform a connection migration before it has migrated to the server's preferred address.

9.7 Use of IPv6 Flow Label and Migration

Endpoints that send data using IPv6 SHOULD apply an IPv6 flow label in compliance with [RFC6437], unless the local API does not allow setting IPv6 flow labels.