QUIC Connection IDs and Network Path Migration
QUIC connection IDs are opaque identifiers carried in QUIC packets so an endpoint can recognize a connection independently of the sender’s current IP address and port. That separation lets a client move between network paths—such as Wi-Fi and cellular—without creating a new encrypted session.
The problem with identifying a connection by address
Traditional network flows are commonly associated with a five-tuple: protocol, source IP address, source port, destination IP address, and destination port. A TCP connection, for example, is tied to the two endpoint addresses and ports. If a laptop changes from Wi-Fi to cellular, its source IP address usually changes. A NAT device can also change the source port while the application is still running.
To a server that relies only on the five-tuple, the packets arriving from the new path look like a new connection. The client would need to establish another TCP or QUIC connection, repeat the handshake, and arrange for application state to move to it. In-flight data and stream state would need careful handling, and an encrypted session could not simply continue under the old address pair.
QUIC avoids making the network address the connection’s identity.
An IP address and port describe the current path to a peer. A QUIC connection ID identifies the connection itself.
What a connection ID is
A connection ID, or CID, is an opaque byte string selected by a QUIC endpoint. “Opaque” means that the peer must treat it as an identifier, not decode it as an IP address, port, timestamp, or other structured value.
QUIC packets can carry two relevant IDs:
- The destination connection ID (DCID) tells the packet’s recipient which connection the packet belongs to.
- The source connection ID (SCID) is the ID the sender provides for the peer to use in packets sent back.
The names describe the packet’s direction. A client’s SCID is generally the server’s DCID, and the server’s SCID is generally the client’s DCID. The IDs can change during the lifetime of a connection.
A server can use the DCID to find connection state even when the packet arrives from a different source address or port. This is especially useful in a server cluster: a load balancer can inspect the connection ID and route packets to the machine holding the connection, without relying on the client’s changing address.
The ID is not a password and does not prove that a packet is genuine. QUIC still authenticates and encrypts packet contents with keys established by its TLS 1.3 handshake. The connection ID is primarily a routing and continuity handle.
How migration works
During the initial exchange, the endpoints choose connection IDs and learn enough about one another to place those IDs in packet headers. The client and server also establish QUIC packet-protection keys through TLS. Those keys belong to the QUIC connection, not to one particular IP address.
Suppose a client has an active connection over Wi-Fi:
client 192.0.2.10:53000 -> server 198.51.100.20:443
The client then switches to cellular and receives a different address:
client 203.0.113.7:41000 -> server 198.51.100.20:443
The client can send a QUIC packet from the new address using the connection’s DCID. The server sees the familiar ID, locates the existing connection state, and decrypts the packet with the keys already in use. It does not interpret the new four-tuple—source and destination addresses and ports—as proof that this is a new application session.
The server must still verify that the new path really reaches the client. Otherwise, an attacker could make the server send large amounts of traffic to a victim by claiming that the victim’s address belongs to an existing connection. QUIC performs this check with path validation: one endpoint sends a PATH_CHALLENGE, a small value that the peer must return in a PATH_RESPONSE on that path. Until validation provides enough confidence, QUIC limits how much new traffic an endpoint may send under its anti-amplification rules.
After validation, normal application packets can use the new path. The connection’s streams, flow-control state, packet numbers, acknowledgements, and TLS keys continue. A request that was in progress does not need to be replayed merely because the client changed networks.
More than one connection ID
An endpoint can issue multiple connection IDs in advance. QUIC communicates these with NEW_CONNECTION_ID frames, each associated with a sequence number and a stateless reset token—a value that lets an endpoint recognize a reset for that connection if its state has disappeared.
Having several IDs helps an endpoint change the identifier it uses on a new path. It also limits linkability: if the same long-lived identifier appeared everywhere, an observer could more easily correlate the client’s activity across networks. Replacing IDs does not make traffic invisible, but it gives implementations a way to avoid unnecessarily reusing one identifier.
Endpoints can retire IDs they no longer want used. A peer that receives a retirement request stops sending packets with the retired ID and selects another available one. Implementations must keep the mapping between active IDs and connection state consistent while this happens.
Migration is not automatic in every situation
Connection IDs make migration possible; they do not guarantee that every network change will succeed. A firewall may block UDP, a new network may not route the traffic, or the server may deliberately disable client-initiated migration with the disable_active_migration transport parameter. NAT rebinding can also occur without the application intentionally changing networks, and QUIC uses the same connection-identity principle to handle many such address changes.
For debugging, this explains why a QUIC log can show a source-address change without a new TLS handshake, while a packet capture shows a different four-tuple but the same connection context. The important distinction is between path and connection: the path can change, while the encrypted QUIC connection—and the application streams carried by it—continues.