Summary

  • preferred_address authenticates what the server supplied for this connection; it does not establish that the advertised path is reachable from this client.
  • The client chooses an advertised IPv4 or IPv6 address after handshake confirmation, uses an unused connection ID, and must validate the path before migration.
  • Path validation, MTU, congestion and RTT, application continuity, and business outcome belong in separate evidence fields.

The operational mistake begins quietly: an inventory receives a server’s authenticated preferred address and immediately promotes it to “live endpoint.” That label outruns the protocol. QUIC lets a server accept a connection on one IP address and offer another address for movement shortly after the handshake. The design can help when an initial address is shared by several servers and a unicast address may provide greater connection stability. But the offer is an invitation to attempt migration, not a measurement of the destination.

Only a server sends the preferred_address transport parameter, carried in the TLS handshake. Receipt proves that this peer supplied these parameter values for this connection once the authenticated handshake has been accepted. It does not prove that the client can reach the advertised IPv4 or IPv6 tuple, that validation will succeed, or that the path has a usable MTU, available capacity, future availability, application continuity, or a successful business result.

The address fields contain an IPv4 address and port and an IPv6 address and port. One family may be omitted through an all-zero address and port. That is a choice available to the client’s network attachment, not evidence that both families were tested. After the handshake is confirmed, the client chooses an advertised address and initiates validation. The server does not initiate this connection migration. The client should use a previously unused active connection ID from preferred_address or NEW_CONNECTION_ID; the supplied alternative has sequence number 1 and includes a 16-byte Stateless Reset Token. The connection ID is not bound to the preferred address and may be used on any path. The reset token is routing material for the protocol, not an identity score.

A server using a zero-length connection ID cannot provide a preferred address, and the parameter cannot contain one. Such violations produce TRANSPORT_PARAMETER_ERROR. The client must not send non-probing frames to the preferred address before validation, limiting request-forgery exposure. A PATH_CHALLENGE and its response are part of the validation process; they do not retroactively turn the original advertisement into a measurement.

If validation succeeds, the client should send future packets to the new server address with the new connection ID and stop using the old server address. If validation fails, it must continue toward the original server IP address. Server transition is independently conditioned: the server probes from the preferred address and continues non-probing traffic from the original address until it receives a non-probing client packet at the preferred address and validates the new path. Only then does it exclusively send non-probing traffic there, while still potentially processing delayed packets from the old address.

The parameter is connection-local. It cannot be reused for another connection, including a resumed connection. disable_active_migration does not block this peer-directed preferred-address procedure. If the client moves first, it should validate the original and preferred server addresses concurrently from the new client address. A changed NAT binding can make the server observe a different client source address at the preferred address, requiring migration spoofing defenses and validation toward that address.

The ledger should therefore separate authenticated parameter receipt; exact IPv4 and IPv6 tuples, including zero-valued absent families; a protected digest of the sequence-1 connection ID and a reset-token reference; handshake confirmation; family and selection decision; the actually used, previously unused connection ID; validation start, evidence, result, and abandonment reason; client switch and original-address fallback; server probe, validation, and first non-probing packet; NAT-binding change and concurrent validation; path MTU; congestion and RTT; application continuity; and business outcome.

Privacy-safe digests and retention controls are operational recommendations, not QUIC requirements.

This is narrower than TR-027’s general migration convergence, TR-040’s connection-ID routing inventory, TR-059’s receive ceiling versus path MTU, TR-062’s evidence from completed path returnability, and TR-047’s idle-timeout boundaries. A completed validation has a bounded meaning. It does not make an invitation a guarantee.