Visual RFC.
ALL RFCs / RFC 9000
Read the RFC ↗
RFC 9000 / MECHANISMS

Move a connection to a new path

06

Connection IDs help route packets to an existing connection when a client address changes. New paths need reachability validation.

Related RFCs and changes

“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.

DIAGRAM§ 9 ↗
RFC 9000 · § 9EXAMPLE
3 / 3
Move a connection to a new pathTwo physical paths are separate from connection identity; an echoed challenge validates the new route.ESTABLISHED CONNECTION · NEW CLIENT PATHclientserverWi-Fi · old routeMobile · new routePATH_CHALLENGE XPATH_RESPONSE XConnection continues on validated pathNew path may require fresh RTT and congestion state
03
Validate and use the new path.

A matching PATH_RESPONSE supports continued traffic on the new route.

Protocol participantThreat or exceptionProtocol controlSimplified drawings · precise section references
KEY POINT

Keep connection identity distinct from the network address.

  • Active migration is not initiated before handshake confirmation.
  • PATH_CHALLENGE carries unpredictable data; PATH_RESPONSE echoes it to prove reachability on the tested path.
  • New connection IDs help reduce linkability; migration can require new congestion and RTT state.
DETAILS

Migration can be disabled by the peer’s transport parameter. NAT rebinding and a server’s advertised preferred address have additional rules; not every address change is unrestricted.

Read the RFC section ↗

Diagrams simplify the RFC. Read the linked sections for complete requirements.

Privacy
All chapters in this RFC
  1. Streams progress independently
  2. Stream IDs describe direction
  3. Establish a protected connection
  4. Limit data and stream counts
  5. Recover data, not packets
  6. Move a connection to a new path
RFC 9700 / CHAPTERS

Chapters

For full details, tables, algorithms, and exceptions, read the original RFC.

RFC status and corrections ↗