Resumen

  • preferred_address autentica lo que el servidor ofreció para esta conexión, no que el cliente pueda alcanzar la dirección anunciada.
  • Tras confirmar el handshake, el cliente elige IPv4 o IPv6, utiliza un identificador de conexión no usado y valida la ruta antes de migrar.
  • Validación, MTU, congestión y RTT, continuidad de la aplicación y resultado empresarial son campos de evidencia separados.

El error aparece cuando un inventario convierte una dirección preferida anunciada en un extremo activo antes de probarla. QUIC permite que un servidor acepte una conexión en una IP y ofrezca otra poco después del handshake. Puede ser útil cuando la dirección inicial es compartida por varios servidores y una dirección unicast podría aportar mayor estabilidad. Pero la oferta no es una medición del destino.

Solo el servidor envía el parámetro de transporte preferred_address, dentro del handshake TLS. Su recepción autenticada demuestra qué valores proporcionó el par para esta conexión. No demuestra que el cliente alcance el tuple IPv4 o IPv6, que la validación vaya a tener éxito, ni que exista MTU utilizable, capacidad disponible, disponibilidad futura, continuidad de la aplicación o éxito comercial.

El parámetro puede incluir dirección y puerto IPv4 y dirección y puerto IPv6. Una familia puede omitirse mediante dirección y puerto completamente nulos. Eso ofrece una opción adecuada al acceso de red del cliente; no afirma que ambas rutas hayan sido probadas. Después de confirmar el handshake, el cliente elige una dirección e inicia la validación. El servidor no inicia la migración: en QUIC la inicia el cliente. Debería usar un identificador activo previamente no usado de preferred_address o NEW_CONNECTION_ID. El identificador alternativo tiene número de secuencia 1 e incluye un Stateless Reset Token de 16 bytes. No está ligado a la dirección preferida y puede usarse en cualquier ruta.

Un servidor con identificador de longitud cero no puede ofrecer una dirección preferida, y el parámetro no puede contener uno. Las infracciones son condiciones TRANSPORT_PARAMETER_ERROR. Antes de validar, el cliente no debe enviar tramas no probatorias a la dirección preferida; así se limita la exposición a falsificación de solicitudes. PATH_CHALLENGE y PATH_RESPONSE forman parte de la validación. Una validación posterior no convierte la oferta original en una medición retroactiva.

Si la validación tiene éxito, el cliente debería enviar los paquetes futuros a la nueva dirección con el nuevo identificador y dejar de usar la antigua dirección del servidor. Si falla, debe seguir enviando hacia la IP original. El servidor tiene condiciones independientes: sondea desde la dirección preferida y mantiene el tráfico no probatorio desde la original hasta recibir un paquete no probatorio del cliente en la dirección preferida y validar la nueva ruta. Solo entonces envía exclusivamente allí, aunque puede procesar paquetes retrasados recibidos por la dirección antigua.

La dirección es válida solo para la conexión que la recibió; no puede reutilizarse en otra conexión, incluidas las reanudadas. disable_active_migration no prohíbe este procedimiento explícito. Si el cliente se mueve antes, debería validar simultáneamente las direcciones original y preferida desde su nueva dirección. Un cambio de enlace NAT puede hacer que el servidor observe otra fuente; entonces aplica defensas contra suplantación e inicia validación hacia esa fuente.

El registro debe separar recepción autenticada; tuples IPv4/IPv6 y familias ausentes; resumen protegido del identificador de secuencia 1 y referencia al token; confirmación del handshake; elección de familia; identificador usado y su estado no usado; inicio, resultado y abandono de validación; cambio del cliente y retorno a la dirección original; sondeo y cambio del servidor; NAT; MTU; congestión/RTT; continuidad y resultado comercial. Los resúmenes privados y la retención limitada son recomendaciones operativas, no requisitos de QUIC.

La separación también importa frente a TR-027, TR-040, TR-059, TR-062 y TR-047: cada uno cubre convergencia de migración, inventario de identificadores, límites de recepción, evidencia de retorno completada o límites de inactividad. Ninguno convierte una invitación en garantía.