QUIC Connection IDs and Connection Migration

19 Sep 2026 networking

QUIC connection IDs are identifiers carried in QUIC packet headers that let endpoints recognize the same connection even after its IP address or port changes. They separate a connection’s identity from the network path currently carrying its packets.

The problem with a connection tied to an address

A traditional TCP connection is identified by a four-part tuple:

client IP address
client port
server IP address
server port

If one part changes, the tuple no longer matches the connection. A laptop switching from Wi-Fi to cellular is a common example: its source IP address changes. A less visible example is NAT rebinding, where a router changes the public source port or address associated with an internal client, often after a timeout or network event.

TCP and many UDP-based protocols generally treat the new tuple as a new flow. The application may reconnect, repeat authentication, and rebuild any state associated with the old transport connection. For a long-lived HTTP/3 request, stream, upload, or session, that interruption is undesirable.

QUIC runs over UDP, so it does not inherit TCP’s tuple-based connection handling. Instead, it gives each connection one or more connection IDs. A server can therefore recognize that packets arriving from a new address belong to an existing, authenticated connection.

A connection ID identifies the QUIC connection; the source and destination addresses describe the current path to it.

What a connection ID does

A QUIC packet can contain a destination connection ID (DCID), which tells the receiving endpoint which connection the packet belongs to. It can also contain a source connection ID (SCID), which the sender offers for the peer to use as a destination ID in later packets.

The IDs are opaque values. An endpoint must not assume that they encode an IP address, port, or other particular structure. A server might use them to route packets to the worker or machine that owns a connection, but that is an implementation choice.

During the handshake, the endpoints exchange initial IDs. After the connection is established, a server can send NEW_CONNECTION_ID frames to provide additional IDs. The client can later use one of those IDs when sending on a different path. Each issued ID has a sequence number, and it also comes with a reset token: a value that allows the peer to recognize a stateless reset for that particular ID.

Using several IDs is useful for two reasons. First, a server can route a packet arriving at a new address without requiring the old address to remain reachable. Second, an endpoint can replace an ID so that observers cannot as easily link traffic on different paths merely by watching the same visible identifier. QUIC does not promise perfect privacy, but changing IDs can reduce this form of tracking.

How migration works

Suppose a client is connected over Wi-Fi and then moves to cellular.

The client keeps the QUIC connection state: its encryption keys, packet-number space, streams, acknowledgements, and flow-control state.
Its source IP address, and possibly its source port, changes.
The client sends a packet from the new address, using a connection ID that identifies the existing connection.
The server receives the packet and sees a known DCID, even though the packet came from a different address.
The endpoints validate the new path before treating it as usable for normal traffic.

Path validation prevents an attacker from making a server send traffic to a victim by spoofing a packet that appears to come from the victim’s address. The endpoint sends a PATH_CHALLENGE frame containing an unpredictable value. The peer returns that value in a PATH_RESPONSE frame. Receiving the correct response demonstrates that the peer can receive packets on the new path.

While validation is in progress, QUIC restricts what can be sent on the unvalidated path. Small control packets used for validation are allowed, but an endpoint should not immediately send unrestricted application data there. This both limits amplification and avoids committing to a path that may not actually work.

Once validation succeeds, the endpoint can use the new path. The connection does not restart: existing streams continue, packet numbers and cryptographic state remain part of the same connection, and the application does not need to repeat its transport-level setup.

NAT rebinding is the same idea at a smaller scale

With NAT rebinding, the client may not have deliberately changed networks. Its local address can stay the same while the NAT changes the public source port. From the server’s perspective, packets suddenly arrive from a new address-and-port pair.

A QUIC implementation can associate those packets with the existing connection because their connection ID and authenticated QUIC contents still match. It can then validate the new path and continue the connection. This is why a temporary NAT mapping change need not look like a disconnect to an HTTP/3 application.

The connection ID is not itself proof that the sender is legitimate. QUIC packet protection authenticates the packet, and path validation confirms reachability at the new address. These protections work together: the ID helps find the connection, encryption and authentication verify the packet, and the challenge-response exchange verifies the path.

Limits and operational clues

Migration is not automatic in every direction. An endpoint can advertise the disable_active_migration transport parameter, telling its peer not to intentionally move the connection to a new path. NAT rebinding still needs to be handled so that ordinary address changes do not unnecessarily break a connection, but deliberate migration is then restricted.

A server also needs a way to route a DCID to the right connection state. Distributed QUIC deployments commonly encode or map connection IDs to a server instance. If that routing data is lost during a failover, the connection may still fail even though the client’s network path is healthy.

When diagnosing logs, messages such as “new peer address,” “path validation,” PATH_CHALLENGE, PATH_RESPONSE, or “connection ID retired” often describe this machinery rather than a new application session. The important distinction is whether the connection’s identity and cryptographic state survived. If they did, QUIC can replace the path underneath an ongoing connection instead of establishing a new transport connection.