Résumé

  • RFC 8928 plaçait le drapeau C de l’EARO au bit 3 dans une figure, sans enregistrer cette position auprès de l’IANA ; RFC 9685 a ensuite enregistré le champ P sur les bits 2 et 3.
  • RFC 9927 déplace C au bit 1. Elle précise que la correction n’est pas rétrocompatible, mais ne prescrit pas de transition car ses auteurs ne connaissaient ni implémentation ni déploiement de RFC 8928.
  • Le RFC corrigé et le registre IANA fixent la convention actuelle. Ils ne prouvent ni la version d’un parseur, ni l’interprétation d’un paquet, ni un résultat de service.

Deux lecteurs raisonnables, une grammaire impossible

RFC 8928 définit la protection de Neighbor Discovery par enregistrement d’adresse. Dans son Extended Address Registration Option, le drapeau C indique que le Registration Ownership Verifier contient un Crypto-ID et que le nœud 6LoWPAN qui enregistre l’adresse peut être soumis à un défi de propriété. La figure montrait C au bit 3. Un développeur pouvait donc en tirer un encodeur ou un décodeur cohérent avec le texte publié.

Il manquait cependant l’autre moitié du contrat : l’allocation n’avait pas été portée au registre IANA des drapeaux de l’option. Or un octet partagé est un espace de noms. Un auteur de norme qui consulte le registre doit pouvoir savoir quelles positions sont disponibles sans relire toute l’histoire graphique des RFC.

RFC 9685 a plus tard introduit le Registered Address Type Indicator. Son champ P, large de deux bits, occupe les bits 2 et 3 et a fait l’objet des enregistrements requis. Le bit 3 acquérait ainsi deux lectures possibles. Ce n’était pas un simple doublon terminologique : les mêmes bits sur le fil pouvaient alimenter deux grammaires différentes.

Le dossier ne contient aucun incident attribué à cette ambiguïté. Il autorise une conclusion plus sobre : les documents permettaient une divergence de parseurs, même si aucune divergence déployée n’est établie.

Déplacer C restaure une allocation unique

RFC 9927 remplace les figures EARO concernées dans les messages Neighbor Solicitation et Neighbor Advertisement. C passe au bit 1 ; P conserve les bits 2 et 3. Le texte rectifie aussi « Enhanced Address Registration Option » en « Extended Address Registration Option ».

Le registre IANA courant présente désormais une carte sans chevauchement : bit 0 non attribué, bit 1 pour C, bits 2–3 pour P, bits 4–5 pour I, bit 6 pour R et bit 7 pour T. Cette vue commune évite que chaque équipe reconstruise l’intention à partir de versions documentaires successives.

RFC 8126 aide à comprendre la fonction de ce registre. L’allocation de valeurs de protocole est un acte de coordination soumis à une politique, pas une formalité après rédaction. Sa portée reste néanmoins limitée. L’IANA atteste l’affectation convenue dans le système de normalisation ; elle n’atteste pas qu’un binaire particulier la respecte.

Une absence connue n’est pas une inexistence démontrée

RFC 9927 annonce sans détour que la modification n’est pas rétrocompatible. Un émetteur construit selon l’ancienne figure et un récepteur construit selon la nouvelle carte peuvent attribuer des sens différents au bit 3. Le RFC juge pourtant inutile de définir un plan de transition, au motif qu’aucune implémentation et aucun déploiement de RFC 8928 ne sont connus.

La formulation doit rester intacte. « Aucun connu » décrit l’état d’information des auteurs au moment de la décision. Elle ne fournit ni méthode de recensement universel, ni garantie sur du code expérimental, ni preuve que rien n’existait dans un laboratoire fermé. En faire une certitude absolue supprimerait précisément la condition qui rend la correction peu coûteuse.

Une organisation sans trace de RFC 8928 peut adopter directement la carte corrigée. Celle qui retrouve un prototype doit, elle, inventorier ses versions, conserver les identifiants de build, éprouver encodeurs et décodeurs avec des vecteurs contrôlés, observer les pairs et prévoir un retour arrière. L’absence de transition normalisée ne dispense pas d’une transition locale quand les faits locaux l’exigent.

Le registre n’est pas un capteur d’exécution

La Minimum Initial Specification de Heng Lu offre ici une grille de lecture, non une règle de l’IETF : une convention initiale étroite coordonne les participants tout en laissant l’adoption aux implémentations. Running-Code Primacy fixe l’autre borne : la netteté du texte ne remplace jamais l’observation du code. Reality Layers empêche enfin de transformer une autorité symbolique en constat opérationnel.

La chaîne de preuve doit donc rester segmentée. RFC 8928 établit ce que sa figure montrait. RFC 9685 et l’action IANA établissent l’allocation coordonnée de P. RFC 9927 établit la correction normative et le jugement de transition. Le registre actif établit l’état actuel de l’espace de noms. Aucun de ces éléments ne révèle seul ce qu’un équipement non identifié décode.

Pour parler d’exécution, il faut rattacher une version source ou binaire nommée à son comportement d’encodage et de décodage, à sa configuration, à des vecteurs de test ou captures contrôlées, à la version du pair et à l’observation du résultat. Pour parler de service, une mesure de service doit encore fermer la chaîne.

Limites du dossier

Les sources ne nomment aucun produit, paquet capturé, exploitation, panne, taux d’adoption ou conséquence économique. Le drapeau C ne vaut pas davantage titre public sur une adresse, autorisation globale de routage ou preuve d’acceptation par un service. Il appartient à un mécanisme précis de vérification de propriété dans l’EARO.

La leçon est donc double. Un schéma assez précis pour guider du code doit être relié au registre qui coordonne l’espace partagé. Un registre corrigé doit, à son tour, rester distinct de l’inventaire et des observations d’exécution. RFC 9927 répare le premier lien ; les opérateurs restent responsables du second.

Sources