Resumen

  • Un paquete Version Negotiation lleva una lista no protegida de versiones que su emisor presenta como aceptables.
  • El eco de los identificadores aporta un indicio limitado de que el emisor observó el Initial, pero no autentica al servidor ni su política de producción.
  • El registro útil enlaza el paquete bruto con la versión elegida después y con la Version Information autenticada durante el handshake.

Un panel de compatibilidad muestra tres versiones QUIC junto a una dirección de borde. La fuente es una captura: el cliente probó una versión, recibió Version Negotiation y leyó tres alternativas. El panel convierte esa observación en una matriz de capacidad. La captura no llega tan lejos.

La sección 6.1 de RFC 9000 indica que el servidor responde cuando no acepta la versión elegida por el cliente. Incluye versiones que aceptaría y puede generar el paquete sin conservar estado. También puede limitar cuántas respuestas envía. El silencio, por tanto, tampoco es una lista completa de lo que no admite.

El formato proporciona una unión estrecha. Según RFC 9000 §17.2.1, Version vale cero; el DCID copia el SCID del cliente y el SCID copia el DCID del Initial. Ese eco aporta un indicio limitado de que el emisor vio el Initial. Después aparece la lista de versiones de 32 bits.

Observar el Initial no equivale a autenticarse como el servicio. RFC 9000 §12.1 establece que estos paquetes carecen de protección criptográfica. Un sistema en ruta ve los identificadores que debe repetir. La respuesta no contiene el certificado, la verificación Finished ni parámetros autenticados que vinculen la afirmación posterior con el extremo autenticado mediante TLS.

Las reglas del cliente eliminan ambigüedades fáciles sin elevar la prueba. RFC 9000 §6.2 exige que un cliente que solo admite QUIC v1 abandone la tentativa al recibir un paquete válido para este proceso. Hay dos excepciones: debe descartarlo después de procesar con éxito otro paquete y también si la lista incluye la versión ofrecida originalmente. Eso reduce inyecciones evidentes o respuestas obsoletas; no convierte la lista restante en una política firmada.

La capa fuerte llega dentro del handshake. RFC 9368 §3 define Version Information con Chosen Version y Available Versions, intercambiada mediante un mecanismo autenticado. En QUIC v1 viaja en version_information. RFC 9368 §9 afirma que la seguridad depende de esa autenticidad y que los parámetros de transporte de QUIC v1 la proporcionan.

Así aparece una escalera probatoria. El Initial conserva el intento del cliente. El paquete sin proteger conserva lo que anunció un emisor en ese contexto. El siguiente Initial muestra la nueva elección. El handshake autenticado fija la versión elegida y, si se usa negociación compatible, las versiones disponibles autenticadas. La conexión completa demuestra qué combinación funcionó.

Ese conjunto sirve para explicar un reinicio o abandono concreto. No demuestra que todos los nodos anycast ofrezcan la misma lista, que las opciones sigan activas hoy, que cada una transporte tráfico de aplicación o que el servicio nombrado enviara el paquete. Para un inventario hacen falta sondeos autorizados en distintos bordes, identidad TLS, Version Information autenticada, identidad de software y configuración, y una prueba de aplicación completada.

El recibo operativo debe guardar versión ofrecida, hora y quíntupla, DCID y SCID originales, bytes exactos, identificadores repetidos, lista y orden, resultado de las reglas de descarte, próxima versión, versión negociada, version_information, identidad TLS, borde o entrega y resultado final. Ver una versión posterior más baja tampoco prueba por sí solo una degradación deliberada; hacen falta el transcript autenticado, los conjuntos disponibles y las reglas de selección.

El paquete sigue siendo valioso en su escala correcta: documenta una bifurcación de compatibilidad. No es un certificado del servidor, un manifiesto de despliegue ni una promesa de toda la flota.