G02-MQ: Yes
Rationale
A server can advertise a preferred address for its replacement access during the handshake. After confirmation, the client validates that address and transfers the connection's traffic to it; the server validates the return path before completing the switch. Peer-address and connection state change at the communicating endpoints, without a network-wide host-location announcement. Multipath-21 section 2.2 explicitly retains this preferred-address migration, with path ID 0 when the client's local address is unchanged.
Assessment method
Primary documentation and pinned source review; no runtime experiment
Source context
RFC 9000 preferred server address and multipath-21 section 2.2
Outstanding qualification
Bounded planned destination handover: provision both server attachments on already-routed prefixes, retain connection state and keep the initial path usable until validation succeeds. This is not an arbitrary mid-connection server-address update; discovery beyond the advertised address remains outside multipath-21. The address is valid only for that connection, and simultaneous use of both server addresses must not be assumed. C01 remains No because the numeric destination changes; F23's client-migration result is separate. No runtime experiment or latest-draft claim.
Public sources
- https://www.rfc-editor.org/rfc/rfc9000.html#section-9.6
- https://www.ietf.org/archive/id/draft-ietf-quic-multipath-21.html#section-2.2
Editorial evidence references
The following identifiers refer to research records not included in this public package; they are not public links.
- round569.html
- round569-sources.json