Summary

  • A QUIC Version Negotiation packet carries an unprotected list of versions that its sender presents as acceptable.
  • Echoed connection IDs give some assurance that the sender observed the client’s Initial; they do not authenticate the named server or its production policy.
  • A useful operational receipt joins the raw packet to the subsequent chosen version and authenticated handshake Version Information instead of treating the list as a capability inventory.

The compatibility dashboard shows three QUIC versions beside an edge address. A packet capture supplied the values: the client tried one version, received Version Negotiation, and the response listed three alternatives. The inventory marks all three as “server-supported”. That conclusion is tidier than the evidence.

RFC 9000 §6.1 defines the ordinary trigger. If the client-selected version is unacceptable, the server responds with a Version Negotiation packet containing versions it will accept. The response can be generated without retaining connection state, and a server may limit how many such responses it sends. A missing packet is therefore not a complete negative inventory, just as a received packet is not yet an authenticated positive inventory.

The packet format offers a narrow binding. Under RFC 9000 §17.2.1, the Version field is zero. The response Destination Connection ID copies the client’s Source Connection ID, while its Source Connection ID copies the client’s original Destination Connection ID. The specification says this echo gives the client some assurance that the sender observed its Initial. The remaining bytes form a list of 32-bit versions.

“Observed the Initial” is not “authenticated as the service”. The distinction is explicit in RFC 9000 §12.1: Version Negotiation packets have no cryptographic protection. An on-path system can see the connection IDs that need to be echoed. A raw response does not carry the TLS certificate, Finished verification or authenticated transport parameters that bind later statements to the peer.

Client handling removes several easy ambiguities without upgrading that proof. RFC 9000 §6.2 requires a QUIC v1-only client to abandon a qualifying attempt, but it must discard Version Negotiation after successfully processing another packet and must discard a list containing the version it originally selected. Those rules help resist obvious injected or stale responses. They do not turn the remaining list into a signed policy document.

The stronger evidence arrives in the handshake. RFC 9368 §3 defines Version Information with a Chosen Version and Available Versions, exchanged in both directions through an authenticated handshake mechanism. For QUIC v1, the information is carried in the version_information transport parameter. RFC 9368 §9 makes the dependency explicit: the negotiation mechanism relies on the authenticity of that Version Information, and QUIC v1 transport parameters provide it.

This creates an evidence ladder rather than one boolean. The first Initial records what the client attempted. A validly shaped Version Negotiation packet records which values an unauthenticated sender advertised in that context. The next Initial records the client’s next choice. The authenticated handshake records the chosen version and, where the compatible-negotiation mechanism is used, authenticated available versions. The completed connection records what actually worked.

An operator can use that ladder to diagnose a single attempt. A Version Negotiation packet may explain why a client made another version attempt, why a QUIC v1-only client abandoned, or why a middlebox capture shows a change in the version field. It does not prove that every edge in an anycast service offered the same list, that the values remain enabled now, that application traffic succeeded on each version, or that the named service sent the packet.

The fleet claim needs a different test. Probe multiple authorised edges and paths, retain TLS identity and authenticated Version Information, record software and configuration identity, and separate advertised availability from a completed application exchange. Repeating that observation over time can support a deployment inventory. One unprotected packet cannot.

The incident record should preserve exact bytes and sequence: client-offered version; timestamp and five-tuple; Initial DCID and SCID; Version Negotiation timestamp; echoed IDs; raw advertised list in original order; discard-rule result; next attempted version; handshake-selected version; authenticated version_information; TLS peer identity; edge or release identity; and final outcome. Store absence separately from a negative response because response suppression, loss and minimum-datagram rules can leave the trace silent.

That receipt also keeps downgrade language disciplined. A lower later version is an observation, not an attribution. Establishing a downgrade requires the authenticated negotiation transcript, the endpoints’ actual available sets and the selection rules—not merely the presence of a Version Negotiation packet.

The packet is operationally valuable precisely because its claim is small. It can mark a compatibility branch in one attempted exchange. It is not a server certificate, a release manifest or a fleet-wide support promise.