Modern network usage is fundamentally mobile. Users walk between rooms, transition from WiFi to cellular networks, and switch between multiple access points—often without realizing it. Yet traditional TCP connections are fragile, breaking irreparably when any element of the network path changes.

Connection migration is QUIC's answer to this reality. It allows a connection to seamlessly survive network changes—continuing an ongoing download despite switching from WiFi to 4G, or maintaining a video call when moving between wireless access points. This capability represents a fundamental rethinking of what a 'connection' means in networking.

This isn't merely a performance optimization; it's a paradigm shift. TCP's connection model, designed for static workstations with dedicated network connections, simply doesn't match how we use the internet today.

TCP connections are identified by a 4-tuple: source IP address, source port, destination IP address, and destination port. This tuple forms the connection's identity—every packet must carry these exact values for the connection to continue.

TCP Connection Identity:

┌─────────────────────────────────────────────────────────────┐
│ Source IP      : 192.168.1.100  (Your device on WiFi)      │
│ Source Port    : 52431          (Ephemeral port)           │
│ Destination IP : 93.184.216.34  (Server)                   │
│ Destination Port: 443           (HTTPS)                    │
└─────────────────────────────────────────────────────────────┘

If ANY of these values change, the connection is severed.

What Happens During Network Changes:

The Core Problem:

TCP was designed in an era when computers sat on desks and network interfaces were physically wired. The assumption that IP addresses represented stable endpoints was reasonable in 1981. Today, it's fundamentally incorrect.

Consider a typical mobile scenario:

User Scenario: Walking into a coffee shop while on a video call

Time 0:00 - User outside on cellular
  └─ TCP Connection: 104.221.50.7:54321 ─▶ Server
  └─ Video call active, working perfectly

Time 0:30 - User enters coffee shop, phone connects to WiFi
  └─ New IP: 192.168.1.47
  └─ Old TCP connection: DEAD (server still expects 104.221.50.7)
  └─ Video call: DROPPED

Time 0:45 - App reconnects via WiFi
  └─ New TCP connection established
  └─ Call rejoined (if the other person waited)
  └─ Lost 15+ seconds of conversation

The TCP stack cannot 'move' the connection to the new IP. It must terminate the old connection and establish a new one. This involves:

• TCP three-way handshake (1 RTT)
• TLS handshake (1-2 RTT for TLS 1.2, 1 RTT for TLS 1.3)
• Application reconnection (session re-establishment)

For real-time applications, this latency is catastrophic.

QUIC's solution is elegant: don't use IP addresses and ports to identify connections. Instead, QUIC introduces the Connection ID—a unique token that identifies the connection regardless of the underlying network path.

Connection ID Architecture:

QUIC Connection Identity:

┌─────────────────────────────────────────────────────────────┐
│ Destination Connection ID (DCID)                            │
│   - Chosen by the receiver                                  │
│   - Carried in every packet                                 │
│   - Used to route packets to the correct connection state   │
└─────────────────────────────────────────────────────────────┘

When network path changes:
  - IP/port tuple changes → irrelevant to connection identity
  - Connection ID remains → connection survives
  - State preserved → streams, data, crypto all continue

Connection IDs are not fixed—they can change during a connection's lifetime. Each endpoint can provide multiple Connection IDs to its peer, allowing seamless ID rotation for privacy and migration resilience.

Connection ID Mechanics:

Each QUIC packet header includes a Destination Connection ID (and optionally Source Connection ID in long headers). The receiving endpoint uses this ID—not the IP tuple—to locate the connection state:

Packet Processing Flow:

1. UDP packet arrives at server
   └─ Source: 192.168.1.47:61234
   └─ Destination: 93.184.216.34:443

2. QUIC layer extracts Connection ID from packet header
   └─ DCID: 0x7a3f9c2e8b1d4a6c

3. Server looks up connection by ID (not by IP tuple)
   └─ Found: Connection #42
   └─ Connection state: all streams, encryption keys, etc.

4. Processing continues regardless of source IP change
   └─ If this was 104.221.50.7 before, it doesn't matter
   └─ Connection ID is the authority

Contrast with TCP:

TCP demultiplexing is fundamentally IP-based:

TCP Packet Processing:

1. TCP packet arrives
2. Kernel looks up: (192.168.1.47, 61234, 93.184.216.34, 443)
3. No match found → packet dropped or RST sent
4. Connection is dead

The difference is structural. TCP uses IP tuples as connection keys; QUIC uses Connection IDs. This single architectural change enables connection migration.

Connection migration introduces a critical security concern: how do we know the migrated client is the real client and not an attacker? An attacker could potentially:

1. Observe a valid Connection ID in transit
2. Spoof packets from a different IP claiming that Connection ID
3. Hijack the connection or redirect traffic

QUIC addresses this through path validation—a cryptographic proof that the entity at the new address is the legitimate connection participant.

Path Validation Mechanism:

Path Validation Flow:

Client (new IP: 10.0.0.50)              Server
         │                                  │
         │                                  │
         │─────── Data from new IP ────────▶│  (1)
         │        DCID: 0x7a3f9c...         │
         │                                  │
         │                                  │  Server sees new source IP
         │                                  │  Suspects migration or attack
         │                                  │
         │◀──── PATH_CHALLENGE ─────────────│  (2)
         │      (random 8-byte data)        │  Sent to NEW address
         │                                  │
         │─────── PATH_RESPONSE ───────────▶│  (3)
         │      (echoed 8-byte data)        │
         │                                  │
         │                                  │  Challenge data matches!
         │                                  │  Path validated ✓
         │                                  │
         │◀──── Full communication ─────────│  (4)
         │      (using new path)            │

The PATH_CHALLENGE contains 8 bytes of random data. The legitimate client—who possesses the cryptographic keys—can decrypt the challenge and echo it back in a PATH_RESPONSE. An off-path attacker cannot produce the correct response.

Proactive vs Reactive Migration:

QUIC supports two migration patterns:

Proactive Migration (Client-Initiated):

1. Client detects network change (new interface, better signal)
2. Client sends packet from new address with PATH_CHALLENGE
3. Server validates and switches to new path
4. Old path may be abandoned or kept as backup

Reactive Migration (Server Response):

1. Client's network changes without client awareness (NAT rebind)
2. Client sends packet from new address (unaware of change)
3. Server sees new source, initiates path validation
4. Connection continues after validation

Multipath Potential:

While standard QUIC supports migration between paths, experimental extensions enable simultaneous multipath—using WiFi and cellular concurrently for redundancy or aggregated bandwidth. This requires additional signaling but builds on the same Connection ID foundation.

Multipath QUIC (Experimental):

┌─────────────────────────────────────────────────────────────┐
│                      QUIC Connection                        │
├─────────────────┬───────────────────────────────────────────┤
│ Path 0 (WiFi)   │ Path 1 (Cellular)                        │
│ 192.168.1.47    │ 104.221.50.7                             │
│ Active stream   │ Active stream                            │
│ data            │ data (redundant or additional)           │
└─────────────────┴───────────────────────────────────────────┘

If WiFi fails, cellular continues without reconnection.
Bandwidth can be aggregated for large downloads.

Managing Connection IDs throughout a connection's lifetime requires careful orchestration. Each endpoint must:

1. Provide sufficient spare Connection IDs to its peer
2. Retire IDs that have been used or compromised
3. Avoid reusing IDs that could enable tracking
4. Coordinate ID changes during migration

Connection ID Supply Chain:

Connection ID Flow:

┌───────────────────────────────────────────────────────────────┐
│ Client                              Server                    │
├───────────────────────────────────────────────────────────────┤
│                                                               │
│ Initial handshake:                                            │
│   Client provides: CID_C1, CID_C2    Server provides: CID_S1 │
│                                                               │
│ During connection:                                            │
│   Server sends: NEW_CONNECTION_ID(CID_S2, CID_S3, CID_S4)    │
│   Client now has 4 server CIDs to choose from                │
│                                                               │
│ Client migrates to cellular:                                  │
│   Uses CID_S2 (fresh, unlinkable)                             │
│   Sends: RETIRE_CONNECTION_ID(CID_S1)                        │
│                                                               │
│ Server replenishes:                                           │
│   Sends: NEW_CONNECTION_ID(CID_S5)                           │
│   Client always has spares for future migration              │
└───────────────────────────────────────────────────────────────┘

NEW_CONNECTION_ID Frame Structure:

NEW_CONNECTION_ID Frame:
┌────────────────────────────────────────────────────────────┐
│ Type (0x18)                                                 │
├────────────────────────────────────────────────────────────┤
│ Sequence Number: Variable-length integer                    │
│   Monotonically increasing for each new CID issued         │
├────────────────────────────────────────────────────────────┤
│ Retire Prior To: Variable-length integer                    │
│   Peer should retire CIDs with sequence < this value       │
├────────────────────────────────────────────────────────────┤
│ Length: 1-20 bytes                                          │
├────────────────────────────────────────────────────────────┤
│ Connection ID: Variable length                              │
├────────────────────────────────────────────────────────────┤
│ Stateless Reset Token: 16 bytes                             │
│   Used for stateless connection termination                 │
└────────────────────────────────────────────────────────────┘

Stateless Reset:

Even with Connection IDs, a server might lose connection state (crash, failover). The Stateless Reset Token enables graceful termination:

Stateless Reset Scenario:

1. Client sends packet to server
2. Server has no state for that Connection ID (crashed/rebooted)
3. Server sends Stateless Reset:
   - Fixed header format (looks like short header packet)
   - Random padding
   - Ends with Stateless Reset Token (16 bytes)
4. Client recognizes token, terminates connection gracefully
5. Client can reconnect without waiting for timeout

This mechanism allows connection termination without maintaining per-connection state—crucial for massively scaled deployments.

Connection migration transforms user experience across numerous real-world scenarios. Let's examine the most impactful cases:

Scenario 1: WiFi to Cellular Handoff

The quintessential mobile networking challenge. A user starts a large download on WiFi, then leaves the building.

Scenario 2: NAT Rebinding

Carrier-grade NAT frequently reassigns public IP addresses, especially for idle connections.

NAT Rebinding Timeline:

Time 0:00  - Connection established
             Public IP: 203.0.113.42:61234

Time 1:00  - Connection idle (user reading page)

Time 1:30  - NAT timeout (carrier reclaims mapping)
             Public IP: now 203.0.113.88:54321

Time 1:45  - User clicks link, triggering request

TCP Result:
  └─ Server receives: 203.0.113.88:54321
  └─ No match for existing connection
  └─ Connection reset; user sees error
  └─ Must reload page, re-authenticate

QUIC Result:
  └─ Server receives: 203.0.113.88:54321 + valid Connection ID
  └─ Path validation initiated
  └─ Connection continues on new path
  └─ User's click processed normally

Scenario 3: Video Conferencing Mobility

Video calls are extremely sensitive to network disruption. Even 500ms of packet loss causes visible glitches.

Scenario 4: Enterprise WiFi Roaming

In large buildings, devices roam between access points. Aggressive roaming (L3 roaming between subnets) changes IP addresses.

Office Building Roaming:

┌─────────────┐     ┌─────────────┐     ┌─────────────┐
│ AP Floor 1  │     │ AP Floor 2  │     │ AP Floor 3  │
│ 10.1.1.0/24 │     │ 10.2.1.0/24 │     │ 10.3.1.0/24 │
└─────────────┘     └─────────────┘     └─────────────┘
       │                   │                   │
       │                   ▼                   │
       │            ┌───────────┐              │
       └───────────▶│ User Walk │◀─────────────┘
                    │ East Wing │
                    └───────────┘

User's IP changes each floor crossing:
  10.1.1.47 → 10.2.1.112 → 10.3.1.89

TCP: Three complete connection resets
QUIC: Seamless path migration (3x path validation)

Scenario 5: Dual-Stack Transition (IPv4 ↔ IPv6)

Devices with both IPv4 and IPv6 may switch between address families based on network conditions.

IPv6 to IPv4 Fallback:

1. Connection established over IPv6
   └─ 2001:db8::1:47 → 2001:db8::2:80

2. IPv6 path becomes congested/unreachable

3. QUIC migrates to IPv4 path
   └─ 192.168.1.47 → 93.184.216.34

4. Connection ID preserved
   └─ All streams continue
   └─ No application-layer reconnection

This flexibility enables aggressive Happy Eyeballs v2 implementations that can switch protocols mid-connection based on performance.

Connection migration expands the attack surface compared to TCP. QUIC's design includes multiple defensive mechanisms:

Threat 1: Connection Hijacking

An attacker attempts to impersonate a legitimate client by sending packets with a known Connection ID from a different IP.

Mitigation:

• Path validation requires responding to challenges
• Challenges are encrypted; only the legitimate endpoint can decrypt them
• Stateless Reset Token provides final line of defense

Threat 2: Traffic Analysis and Tracking

An observer monitors network traffic and attempts to correlate activity across network changes (e.g., track a user's movement).

Mitigation:

• Connection ID rotation on migration
• NEW_CONNECTION_ID frames allow endpoints to issue fresh IDs
• Retire Prior To field forces old ID abandonment
• Encrypted packet numbers prevent sequence analysis

Threat 3: Amplification Attacks

An attacker spoofs a victim's IP address and triggers a server to send large responses to the victim.

Amplification Attack Attempt:

1. Attacker sends packet from Victim's IP
   └─ Spoofed source: 10.0.0.1 (Victim)
   └─ Connection ID: [observed or guessed]
   └─ Request: large data (video, download)

2. Server attempts to send response to 10.0.0.1
   └─ Victim receives unsolicited traffic
   └─ If response >> request, amplification achieved

Mitigation:

• Until path validation completes, server limits data to 3x client data
• Effectively limits amplification factor to 3x
• Major improvement over 100-200x amplification in vulnerable UDP protocols

Threat 4: Denial of Service via Migration Storm

An attacker triggers rapid fake migrations, consuming server resources in path validation.

Mitigation:

• Rate limiting on path validation attempts
• Active connection ID limits (active_connection_id_limit)
• Resource limits on outstanding challenges

Implementing connection migration correctly requires attention to several practical concerns:

Client Implementation:

Client-Side Migration Logic:

1. Network Interface Monitoring:
   - Listen for interface up/down events
   - Track IP address changes
   - Monitor link quality metrics

2. Path Selection:
   - Prefer interfaces with best RTT
   - Consider power implications (WiFi vs cellular)
   - Balance reliability vs bandwidth

3. Migration Trigger:
   - Proactive: Better path available
   - Reactive: Current path degraded/failed
   - Application hint: User preference (e.g., "WiFi only")

4. Connection ID Management:
   - Maintain pool of unused server CIDs
   - Request new CIDs before pool exhaustion
   - Retire used CIDs promptly

Server Implementation:

Server-Side Migration Handling:

1. Packet Reception:
   - Index connections by Connection ID (not IP tuple)
   - Support multiple concurrent CIDs per connection
   - Handle packets from unexpected IPs gracefully

2. Path Validation:
   - Generate cryptographically random challenges
   - Rate limit validation attempts
   - Track multiple paths simultaneously

3. Load Balancer Integration:
   - Encode routing info in Connection ID structure
   - Coordinate CID generation with LB
   - Handle migration across LB nodes

4. State Management:
   - Connection state must be portable (for migration across servers)
   - Stateless Reset Tokens must be derivable

Common Implementation Pitfalls:

Power Considerations:

On mobile devices, aggressive migration can drain batteries. Implementations should:

• Avoid unnecessary migrations (minor signal fluctuations)
• Consider power state when choosing paths
• Batch migration operations where possible
• Respect device power policies

Connection migration represents a fundamental rethinking of what 'connection' means in networking. Let's consolidate the key concepts:

What's Next:

With QUIC's foundational architecture and migration capabilities understood, we'll examine the performance improvements HTTP/3 delivers. From reduced round trips to eliminated head-of-line blocking, we'll quantify why HTTP/3 is faster and explore the scenarios where its advantages are most pronounced.