Résumé

  • draft-munizaga-quic-alternative-server-address-02 décrit une liste complète d’adresses candidates, remplacée par numéro de séquence et séparée en préférences et secours autour de CURRENT_PATH; le texte reste un Internet-Draft individuel.
  • L’annonce ne crée aucun chemin. Le client peut écarter l’ordre selon sa politique et doit valider le chemin avant d’y envoyer autre chose que des sondes.
  • Une exploitation sérieuse conserve séparément l’état annoncé, l’admission locale, la validation dans chaque sens, le chemin effectivement utilisé et la charge agrégée créée lorsque de nombreux clients réagissent ensemble.

Le scénario paraît simple : une adresse de serveur se dégrade, une autre devient préférable, et la connexion QUIC devrait suivre sans recommencer. La révision 02 propose un cadre pour transmettre ce changement après la poignée de main. Le serveur envoie une trame ALTERNATIVE_ADDRESS; le client décide ensuite s’il faut sonder, attendre ou rester sur place.

La trame contient un numéro de séquence et la totalité de l’ensemble annoncé. Un numéro supérieur remplace atomiquement l’état précédent, même si le réseau réordonne les paquets. L’absence d’une adresse dans la nouvelle trame signifie qu’elle n’est plus annoncée. Cela prouve la version de la recommandation du serveur. Cela ne prouve pas que toutes les sondes de l’ancienne version sont annulées, ni que tous les clients ont traité la nouvelle au même instant.

CURRENT_PATH est un séparateur, pas une adresse. Sans multipath négocié, les entrées placées avant sont préférées au chemin courant; celles placées après sont des secours. Les valeurs de Priority Hint ne sont comparables que d’un même côté. Le projet les qualifie d’indicatives : le client peut choisir les validations parallèles, le candidat finalement utilisé ou ignorer l’ordre pour une raison locale.

Cette autonomie n’est pas une faiblesse de l’extension. Le serveur ne voit pas nécessairement les règles de portée du client, son NAT, ses interfaces, son budget d’énergie, sa réserve de Connection IDs ou une interdiction d’entreprise. Une adresse privée ou locale peut être utile dans un domaine et dépourvue de sens dans un autre. L’annonce exprime une connaissance côté serveur; la joignabilité appartient au chemin concret.

La validation apporte une deuxième preuve, elle aussi bornée. Le client envoie PATH_CHALLENGE vers le candidat. La réponse correspondante peut arriver par un autre chemin tout en validant celui où le défi est parti. À l’inverse, une sonde authentifiée reçue d’une source non annoncée ne valide pas cette source. Il faut conserver le défi, le quadruplet visé, le sens, l’heure et le résultat, plutôt que d’attribuer la confiance à l’adresse qui a simplement transporté la réponse.

Le serveur doit encore valider son sens d’émission avant d’y placer du trafic non exploratoire. Puis vient l’usage : migration unique, chemin supplémentaire en multipath, secours silencieux ou aucun octet applicatif. Le projet multipath sépare lui-même la gestion des chemins de l’algorithme de répartition. Une validation réussie ne promet donc ni meilleur RTT, ni capacité, ni continuité de l’application.

La limite la plus politique apparaît dans la section sécurité. Un serveur malveillant peut annoncer la même victime comme alternative prioritaire à une population de clients. Chaque trame est protégée; chaque client peut valider le chemin; l’ensemble peut tout de même produire une ruée. Un délai aléatoire est suggéré, sans définir de budget global, de preuve de consentement de la destination ou d’observation de la charge convergente.

C’est ici que la lecture de Heng Lu devient utile. Une convention minimale peut rendre l’annonce et son remplacement vérifiables. Elle ne doit pas transformer le classement d’un acteur en autorité sur le choix futur d’un autre. La décision devient réelle quand le client l’adopte dans son code; l’effet devient réel quand le chemin et l’application l’observent. La popularité d’un réglage par défaut ne change pas cette chaîne de preuves.

Enfin, le statut doit rester exact. Le document daté du 25 septembre 2026 est une proposition individuelle, sans flux RFC ni directeur responsable, au stade I-D Exists. Il demande des enregistrements provisoires, absents de la photographie IANA conservée ici. Un paragraphe IANA n’est pas une attribution, et une attribution future ne démontrerait ni implémentation ni déploiement.

Sources