Connection IDs and network migration

You step outside the office and your phone switches from WiFi to LTE. Your TCP connections all die — every app reconnects, re-authenticates, re-loads. QUIC makes this switch invisible to the application.

Why TCP breaks on IP change

TCP connections are identified by the 4-tuple: client IP, client port, server IP, server port. When the client’s IP changes — WiFi to cellular, NAT rebind — the 4-tuple is broken. The server sees packets from an unknown source and ignores them. The client must start a new TCP handshake, re-negotiate TLS, and re-establish application state. This takes seconds and is visible to users.

Connection IDs decouple identity from address

QUIC introduces an opaque Connection ID (up to 20 bytes, typically 8) chosen by the server. The Connection ID is carried in every QUIC packet header. The server maps Connection IDs to connection state, not IP addresses.

When the client’s IP changes:

1. The client sends a QUIC packet from the new address with the same Connection ID.
2. The server recognizes the Connection ID, notes the new source address.
3. The server sends a PATH_CHALLENGE frame — a random 8-byte token.
4. The client echoes the token in a PATH_RESPONSE frame.
5. Path validated — the server updates the connection’s current address and unlocks full send rate.

All stream state, flow-control windows, and congestion state survive the migration. The connection continues as if nothing happened.

Anti-amplification limit

Before validating the client’s new address, the server may send at most 3× the bytes it received from that address. This prevents UDP-based amplification attacks: an attacker cannot spoof the client’s address to make the server send large responses to a victim.

Clients must send Initial packets padded to at least 1200 bytes so servers have headroom for a ~3600-byte response burst. Once PATH_RESPONSE is verified, the server unlocks full send rate.