Résumé

  • preferred_address authentifie les valeurs fournies par le serveur pour cette connexion, mais pas l’accessibilité de l’adresse depuis ce client.
  • Après confirmation du handshake, le client choisit une adresse IPv4 ou IPv6, emploie un identifiant de connexion inutilisé et valide le chemin avant de migrer.
  • La validation, le MTU, la congestion et le RTT, la continuité applicative et le résultat métier doivent rester des preuves distinctes.

L’erreur de gestion apparaît lorsqu’un inventaire transforme une adresse préférée annoncée en point de terminaison actif avant tout essai. QUIC permet au serveur d’accepter une connexion sur une adresse IP puis de proposer une autre adresse peu après le handshake. Cette conception peut être utile lorsqu’une adresse initiale est partagée entre plusieurs serveurs et qu’une adresse unicast pourrait offrir une meilleure stabilité de connexion. Elle ne transforme pas pour autant la proposition en mesure du chemin.

Seul le serveur envoie le paramètre de transport preferred_address, transporté par le handshake TLS. Sa réception authentifiée établit que le pair a fourni ces valeurs pour cette connexion. Elle ne prouve pas que le client peut joindre le tuple IPv4 ou IPv6, que la validation réussira, ni que le chemin dispose d’un MTU utilisable, d’une capacité disponible, d’une disponibilité future, d’une continuité applicative ou d’un résultat commercial favorable.

Le paramètre peut contenir une adresse et un port IPv4 ainsi qu’une adresse et un port IPv6. Une famille peut être omise par un codage entièrement nul. Cette possibilité donne un choix adapté au rattachement réseau du client; elle ne signifie pas que les deux chemins ont été testés. Une fois le handshake confirmé, le client choisit une adresse et lance la validation. Le serveur ne déclenche pas cette migration: en QUIC, le client l’initie. Il devrait utiliser un identifiant de connexion actif précédemment inutilisé, fourni par preferred_address ou NEW_CONNECTION_ID. L’identifiant fourni porte le numéro de séquence 1 et le paramètre comprend un Stateless Reset Token de 16 octets. L’identifiant n’est pas lié à l’adresse préférée et peut être utilisé sur n’importe quel chemin.

Un serveur utilisant un identifiant de longueur nulle ne peut pas fournir d’adresse préférée, et le paramètre ne peut pas contenir un tel identifiant. Ces violations relèvent de TRANSPORT_PARAMETER_ERROR. Avant validation, le client ne doit pas envoyer de trames non-sondes à l’adresse préférée; cela limite l’exposition à la falsification de requêtes. PATH_CHALLENGE et PATH_RESPONSE appartiennent à la validation. Une validation ultérieure ne transforme pas rétroactivement l’annonce en mesure.

Si la validation réussit, le client devrait envoyer les paquets futurs à la nouvelle adresse avec le nouvel identifiant et cesser d’utiliser l’ancienne adresse serveur. En cas d’échec, il doit conserver l’adresse IP serveur d’origine. Le serveur suit ses propres conditions: il sonde depuis l’adresse préférée et continue d’envoyer le trafic non-sonde depuis l’adresse d’origine jusqu’à réception d’un paquet client non-sonde sur la nouvelle adresse et validation du nouveau chemin. Il ne passe exclusivement à la nouvelle adresse qu’après ces deux conditions, tout en pouvant traiter des paquets retardés sur l’ancienne.

L’annonce est valable uniquement pour la connexion qui la porte et ne peut pas être réutilisée, même pour une connexion reprise. disable_active_migration n’interdit pas cette procédure explicitement déclenchée par l’adresse préférée du pair. Si le client se déplace avant la migration, il devrait valider concurremment les adresses serveur originale et préférée depuis sa nouvelle adresse. Un changement de liaison NAT peut modifier l’adresse source observée par le serveur et déclencher ses défenses contre l’usurpation ainsi qu’une validation vers cette source.

Le registre opérationnel doit distinguer réception authentifiée, tuples IPv4/IPv6 et familles absentes, empreinte protégée de l’identifiant de séquence 1, référence au token, confirmation du handshake, choix de famille, identifiant effectivement utilisé, début et résultat de validation, bascule du client, retour à l’adresse d’origine, sonde du serveur, validation du serveur, premier paquet client non-sonde reçu à l’adresse préférée, bascule du serveur, changement NAT, MTU, congestion/RTT, continuité applicative et résultat métier.

Les empreintes respectueuses de la vie privée et la conservation limitée sont des recommandations d’exploitation, non des obligations de QUIC.

Cette frontière complète la séparation avec TR-027, qui traite la convergence générale de migration; TR-040, l’inventaire des identifiants; TR-059, le plafond de réception face au MTU; TR-062, la portée d’une validation achevée; et TR-047, les limites d’inactivité. Une invitation reste une invitation.