Résumé

  • RFC 9844 impose aux interfaces qui acceptent une adresse IPv6 non globale de permettre aussi la sélection de sa zone, le plus souvent au moyen d’un nom d’interface du système.
  • Le texte lisible est résolu en index numérique propre à l’hôte pour les appels socket ; nécessaire à l’action locale, il est dépourvu de sens partagé et ne doit pas partir sur le réseau.
  • La preuve robuste conserve donc entrée, validation, résolution, état de l’interface et résultat à l’intérieur de la machine, tout en attestant que le paquet émis ne contient aucun libellé local.

Le formulaire affichait une adresse valide. La machine, elle, attendait encore une décision.

Sur un hôte multihomé, la même écriture link-local peut être interprétée sur plusieurs liens. Sans choix de zone, l’outil ne sait pas quel monde local viser. Ajouter le nom de l’interface rétablit l’action, mais crée une tentation : enregistrer la chaîne complète comme si elle nommait un endpoint universel. Rejouée ailleurs, elle peut sélectionner un autre lien ou ne rien sélectionner du tout.

RFC 9844, publiée sur le Standards Track en août 2025, organise ce passage délicat. Sa notice, son texte brut et sa source XML consignent une exigence d’interface, pas une enquête de conformité. Le document remplace RFC 6874 et met à jour RFC 4007, 7622 et 8089. Rien dans ce statut ne garantit le comportement d’un système précis.

L’adresse qualifie une portée, pas le lien choisi

RFC 4291 pose l’architecture d’adressage et RFC 5952 sa représentation textuelle recommandée. Une adresse link-local reste volontairement bornée. Lorsque plusieurs interfaces rejoignent des liens différents, ses bits ne suffisent pas à nommer le lien sur lequel agir.

RFC 4007 introduit le zone index pour qualifier l’usage interne d’une adresse scoped. Côté humain, le système l’expose souvent sous forme de zone identifier : un nom comme eth0, ou un nombre décimal. Le suffixe n’est pas une extension de l’adresse IPv6 transmise. C’est une instruction adressée au système local.

Cette instruction est un levier. Un diagnostic, une configuration ou une capture peuvent viser le mauvais lien malgré une adresse bien formée. À l’inverse, un outil incapable de recevoir la zone rend inutilisable un équipement qui n’a qu’une adresse link-local. RFC 9844 cite ces cas, ainsi que des ports d’impression virtuels et un réseau maritime. RFC 6991 apporte un contexte YANG ; RFC 8925 montre pourquoi l’absence de voie IPv4 de secours rend le défaut plus pressant.

Le copier-coller du littéral complet réduit les fautes de saisie. Il préserve l’intention écrite, jamais la table d’interfaces qui lui donnait sens. Une preuve qui voyage sans son hôte d’origine est donc incomplète.

Le vrai contrat se trouve dans la conversion

RFC 9844 exige un moyen de saisir l’adresse non globale et sa zone. Le format complet de RFC 4007 devrait être compris ; à défaut, une autre séparation, deux champs, une liste de zones actives ou un paramètre de ligne de commande sont permis. Ces formes ne sont pas concurrentes sur le fond. Toutes doivent livrer deux valeurs contrôlables au point où la pile réseau les résout.

La chaîne fe80::1%eth0 n’est pas directement convertible par inet_pton(). L’application peut recourir à getaddrinfo(), ou séparer adresse et nom avant d’appeler inet_pton() puis if_nametoindex(). RFC 3493 prévoit sin6_scope_id dans la structure socket IPv6, mais laisse sa correspondance avec les interfaces à l’implémentation.

Le reçu minimal doit aller au-delà de « valeur acceptée ». Il lie les octets saisis, la version du parseur, les contrôles de longueur et de caractères, l’index numérique obtenu, l’identité de l’interface à cet instant, l’adresse scoped, la construction du socket et le résultat observé. Une interface supprimée entre affichage et exécution doit produire une divergence visible, pas rattacher silencieusement une autorisation ancienne à un objet nouveau.

Le running code tranche ainsi plusieurs propositions distinctes : la syntaxe a été acceptée ; le nom a été résolu ; le paquet est parti ; l’équipement attendu a répondu. Aucun voyant vert unique ne devrait les confondre.

Une preuve locale doit rester locale

La règle de sécurité est nette. Le zone identifier a une signification locale seulement et ne doit pas être émis. Un logiciel qui l’obtient par son interface ne devrait pas le retransmettre. RFC 4007 avertit aussi qu’un texte de portée non globale reçu comme donnée ne mérite pas confiance : une machine distante ne possède pas l’autorité nécessaire pour définir les zones de la machine réceptrice.

Il ne s’agit pas d’effacer le journal. À l’intérieur, le libellé et son index expliquent le choix de chemin. À la frontière réseau, ils doivent perdre leur pouvoir. Le paquet contient l’adresse scoped, non le vocabulaire d’interfaces de l’hôte. Une capture peut afficher une annotation locale, mais le reçu doit distinguer l’annotation des octets réellement transmis.

Cette séparation évite aussi la fausse reproductibilité. Copier eth0 vers mille hôtes ne copie ni câblage, ni namespace réseau, ni machine virtuelle. Un orchestrateur qui conserve uniquement cette chaîne accumule une apparence de précision. Le nom humain peut être renommé ou réutilisé ; l’index numérique peut être recyclé après un redémarrage. Il faut donc host, temps, contexte de boot et état observé, sans jamais prétendre obtenir une identité éternelle.

La liberté du champ appelle une politique typée

RFC 4007 ne fixe ni taille maximale universelle ni alphabet. RFC 9844 recommande une limite adaptée à l’environnement, souvent celle des noms d’interface du système, et des contrôles de caractères propres au contexte. Le NUL ASCII doit être refusé, faute de quoi deux étapes de traitement pourraient voir deux fins de chaîne différentes.

Les risques dépassent le débordement mémoire. Un séparateur peut subir plusieurs décodages ; la normalisation peut modifier la recherche ; un wrapper shell peut interpréter un caractère ; le journal peut rendre une valeur différente de celle reçue par l’appel système. Une expression régulière universelle ne résout pas ces contrats. Il faut conserver l’entrée exacte, valider selon la cible, résoudre près de l’usage et journaliser entrée et résultat.

Le détour par le navigateur a été refermé

RFC 6874 avait essayé d’inscrire la zone dans les littéraux IPv6 des URI. Sa notice atteste désormais son obsolescence. RFC 9844 rapporte que les navigateurs ont jugé cette voie impraticable, annule son effet sur RFC 3986 et remplace la solution par une exigence générique d’interface. Les références correspondantes disparaissent aussi de RFC 7622 et de la spécification file URI.

Ce recul est un signe de maturité : le consensus définit un minimum, puis l’expérience d’implémentation peut obliger à replacer ce minimum dans la couche qui maîtrise réellement la sémantique. RFC 9844 précise qu’elle ne résout pas le modèle d’origine HTTP de RFC 6454 et que ses prescriptions ne s’appliquent pas aux URI récupérées par un navigateur.

Prouver la présence, puis la disparition

Un test utile met deux interfaces actives face au même texte link-local. Il vérifie le choix explicite, l’erreur sur zone inconnue et l’absence de fallback arbitraire. Il renomme ou supprime l’interface entre sélection et usage, redémarre pour provoquer le recyclage d’index, injecte valeur trop longue, NUL, séparateurs, Unicode délicat et caractères significatifs pour shell ou journal.

Ensuite vient la frontière. Le reçu local doit montrer l’index utilisé ; la capture doit prouver l’absence du nom. Une zone fournie par un pair ne peut être acceptée comme vérité locale. L’échec de résolution doit être fermé et explicite.

Enfin, l’opérateur doit voir la différence entre entrée acceptée, interface résolue, paquet émis et réponse du bon équipement. C’est là que la norme minimale rejoint la responsabilité locale : elle impose la possibilité de choisir, non la politique de nommage, la rétention ou l’autorisation de l’acte.

Limite de preuve

Aucun OS, navigateur, routeur, outil de capture, client YANG ou réseau maritime n’a été testé. Aucun taux d’adoption, de défaut ou d’incident n’est mesuré. Les exemples des RFC expliquent une mécanique sans certifier un produit actuel.

La conclusion solide est structurelle : le contexte local peut être indispensable à l’action tout en étant illégitime comme identité transportée. Une architecture responsable conserve le reçu au bon endroit et détruit l’ambiguïté à la frontière.

Sources