Summary

  • QUIC Connection IDs are endpoint-selected routing and demultiplexing handles. A connection can have a pool of them, allowing packets to reach the right connection after an IP address or UDP port changes.
  • Carrying a valid ID does not authorize a new path. QUIC separately validates the new address with unpredictable PATH_CHALLENGE/PATH_RESPONSE data and limits sending before validation.
  • Connection continuity does not make path evidence portable: congestion and RTT state normally restart, fresh IDs reduce cross-network linkage, and stateless reset is reserved for an endpoint that has lost connection state.

The address changed before the work was done

A laptop leaves Wi-Fi and uses mobile service. A NAT expires a mapping and assigns another UDP port. In both cases, the network address tuple changes even though the application still has streams, acknowledgments and protected state that both endpoints understand.

Treating every change as a new connection is simple, but it gives the address tuple authority over work that exists above it. QUIC chose a narrower contract. RFC 8999 defines the Connection ID as a version-independent opaque field. Its primary function is to ensure that changes at UDP, IP or lower layers do not send a packet to the wrong QUIC endpoint. At the endpoint, it selects the intended connection.

The field is not one permanent name. RFC 9000 says a connection owns a set of identifiers, independently chosen by the endpoints. Each endpoint chooses the values its peer will place in packets sent toward it. That directionality is easy to miss: the receiver issues the routing handle by which incoming traffic can find it.

A pool makes continuity replaceable

During establishment, long headers carry source and destination identifiers. Later short headers normally carry a Destination Connection ID whose length is already known. An endpoint can provide additional values through NEW_CONNECTION_ID; its peer removes a value with RETIRE_CONNECTION_ID. Sequence numbers keep issue and retirement ordered, while active_connection_id_limit bounds how many active values must be retained.

A pool solves more than exhaustion. It lets a peer change the visible handle when the path changes. RFC 9000 requires issued IDs not to contain information that lets an external, non-cooperating observer correlate the different values of one connection. Reissuing the same value on that connection is forbidden.

Zero-length IDs are permitted where address information is enough to route traffic locally. The apparent economy has a boundary. Sharing one local address and port among multiple zero-ID connections becomes fragile under peer migration, NAT rebinding and client port reuse. An endpoint that chooses zero length during the handshake cannot later issue ordinary replacement IDs. Removing the field does not remove the need to distinguish connections; it pushes that need back into addresses or deployment-specific state.

The identifiers used in the handshake are not simply trusted because they appeared in a packet. RFC 9000 repeats the relevant values in transport parameters and checks them through the cryptographic handshake. RFC 9001 supplies the TLS 1.3 and packet-protection context. This prevents an injector from choosing the IDs of a successful handshake. It does not make a bare Connection ID a credential, a server certificate or a human identity.

Migration must prove the new path

Connection IDs allow continuity; they do not prove that a newly observed source address belongs to the peer. RFC 9000 therefore separates migration from path validation.

Active migration begins only after the handshake is confirmed. A change may also be involuntary: NAT rebinding can replace a public port or address without the application asking. When an endpoint sees a new peer address that has not already been validated, it sends a PATH_CHALLENGE carrying unpredictable data. The peer echoes that data in PATH_RESPONSE on the path where the challenge arrived.

The result is deliberately narrow. It shows that a challenge sent toward one IP-and-port pair reached an entity able to produce the bound response. It is not proof of legal ownership, benign intent, path optimality or permanent reachability. Validation in each direction belongs to that endpoint's own test; an ordinary acknowledgment lacks enough unpredictable evidence to replace it.

Before a new address is validated, anti-amplification rules bound how much traffic can be redirected there. Otherwise a spoofed migration could turn the server into a traffic amplifier against an unwilling victim. If validation fails while an older path remains valid, the new path is abandoned rather than the entire connection. QUIC can return to the last validated address.

The connection moves; the measurements stay behind

Encryption keys and streams may survive migration, but a new path can have different bandwidth, delay, loss and ECN behaviour. RFC 9000 therefore normally resets the congestion controller and round-trip estimator after the new address is confirmed. Packets from the old path do not become evidence about the new one.

A port-only change, commonly caused by NAT rebinding, can retain those estimates cautiously. Even there, the specification warns that reused state can transmit too aggressively if the path characteristics actually changed. Continuity is not permission to carry every assumption across the boundary.

A moving connection can become a tracking beacon

If the same Connection ID appeared on café Wi-Fi and later on a mobile network, a passive observer could join the two traces. QUIC requires an endpoint not to reuse one ID when sending from more than one local address or toward more than one destination address.

Fresh IDs reduce direct linkage, and protected packet numbers remove another obvious correlate. They do not create anonymity. Timing, packet size and cooperating routing infrastructure can still connect the activity. A server-side routing scheme that knows how to recover a backend from an ID necessarily holds information that outsiders are not meant to infer.

Privacy also depends on supply. If the peer runs out of unused identifiers, it cannot safely probe or answer on a new path. Issuing enough unlinkable IDs before movement is part of migration readiness, not optional decoration after the address changes.

The last message from a server that forgot

An outage can erase an endpoint's connection state while its peer continues sending. A normal CONNECTION_CLOSE requires the state that has vanished. RFC 9000 therefore defines Stateless Reset as a last resort.

Each eligible Connection ID has a hard-to-guess 16-byte reset token delivered through protected connection context. A datagram ending in the matching token tells the peer to stop immediately. Retirement of the ID invalidates its token.

The reset packet itself has no cryptographic protection and is shaped to resemble a short-header packet. If the token leaks, another party can terminate the connection. IDs and tokens therefore cannot be casually reused. Stateless Reset is not a general error report and not evidence that the remote endpoint remains healthy; it is a bounded way for a receiver with no memory to end work the sender still remembers.

Sources and limits

The closed source set is RFC 8999, RFC 9000 and RFC 9001. It defines protocol contracts, not current deployment share, vendor behaviour, migration success rates or performance advantage. Connection IDs are not globally unique identities, and path validation is not address ownership.