Résumé

  • RFC 9812 impose désormais une revue IETF documentée pour libérer une part importante et non routinière de l’espace IPv6 réservé : RFC du flux IETF, Last Call et constat de consensus par l’IESG.
  • Cette procédure autorise une modification de registre ; elle n’attribue pas une adresse à un opérateur, n’annonce aucune route et ne transforme pas la participation technique en mandat politique général.

Le mot « réservé » produit une intuition trompeuse. Dans une réservation commerciale, quelqu’un détient déjà un droit d’usage. Dans la terminologie de RFC 8126, une valeur réservée n’est ni attribuée ni disponible : elle est retenue pour un usage futur ou pour l’extension du registre. Le bénéficiaire n’existe pas encore.

C’est le point de départ de RFC 9812. L’architecture IPv6 définie par RFC 4291 place l’unicast global courant dans 2000::/3. RFC 7249 rappelait qu’environ sept huitièmes de l’espace total restaient réservés par l’IETF. Le registre IANA de l’espace IPv6 montre encore cette dissymétrie : un bloc supérieur consacré à l’unicast global, de nombreux autres blocs marqués « Reserved by IETF ».

La quantité rendait la procédure décisive. RFC 1881 avait confié à l’IANA la gestion initiale de l’espace IPv6 sans fixer la procédure de libération future. Le registre avait ensuite affiché « IESG approval ». Or cette formule est une soupape, pas un parcours normal pour une décision de cette portée.

RFC 8126 précise qu’une approbation IESG peut intervenir sans RFC. L’IESG peut demander un dossier, mais la publication permanente n’est pas une condition. Le mécanisme est prévu pour une urgence ou une raison impérieuse lorsque les autres procédures ne conviennent pas ; il ne doit pas contourner la revue publique. Une marge exécutive exceptionnelle était donc devenue, dans l’affichage du registre, la porte d’entrée de la majeure partie de la réserve.

RFC 9812 ne raconte pas un abus passé. Elle corrige l’architecture d’autorisation. Pour une ouverture majeure et non routinière, la documentation ne doit plus dépendre du choix discrétionnaire des approbateurs. Elle devient constitutive de la décision.

La nouvelle règle est IETF Review. Elle exige une RFC du flux IETF, issue d’un groupe de travail ou parrainée par un directeur de domaine, passée par un IETF Last Call, puis approuvée par l’IESG comme expression du consensus IETF. Le dossier peut être examiné par les groupes compétents, les directorats et les spécialistes. L’objet du contrôle est concret : éviter une atteinte à l’interopérabilité ou une extension dommageable des protocoles.

La preuve n’est donc pas le nombre de personnes dans une salle. Elle est composée d’états corrélables : préfixe demandé, finalité, version du texte, parrain, période de Last Call, objections, réponses, vote ou position de l’IESG, RFC finale, instruction IANA et ligne modifiée. Cette chaîne permet de savoir qui a proposé, qui a examiné, qui a autorisé et qui a exécuté.

Pourquoi ne pas exiger une Standards Action ? Cette procédure n’accepte que les RFC Standards Track ou BCP. IETF Review peut aussi s’appuyer sur une RFC Informational, Experimental ou Historic du flux IETF. RFC 9812 conserve cette latitude parce que l’ouverture d’une plage d’adresses ne crée pas nécessairement une nouvelle norme de protocole.

Le choix évite une fausse solennité. Le statut d’une RFC doit décrire son contenu normatif. Le forcer pour habiller une décision de registre pourrait confondre expérimentation, coordination et standardisation. RFC 9812 renforce l’examen sans falsifier la nature du document attendu.

Les trois politiques ne forment pas une simple échelle de prestige. IESG Approval apporte une discrétion rapide, éventuellement sans RFC. IETF Review rend obligatoires le document, la revue communautaire et le constat de consensus. Standards Action réduit en plus les catégories de RFC admissibles. Le bon niveau dépend de la nature de l’acte, pas du désir d’apposer l’étiquette la plus imposante.

Le cas de 5f00::/16 a servi de précédent. RFC 9602, travaillée au sein de 6MAN, a demandé ce préfixe pour les SID SRv6. Après le processus IETF, l’IANA l’a inscrit dans le registre IPv6 des usages spéciaux. RFC 9812 montre ainsi que la procédure proposée avait déjà fonctionné dans un dossier substantiel.

Mais le précédent ne constitue pas une preuve de déploiement. RFC 9602 marque le bloc comme non globalement joignable et demande encore des conventions opérationnelles. Une ligne IANA ne démontre ni support logiciel, ni acceptation BGP, ni passage de filtre, ni livraison de paquet. La plage parente peut rester réservée tandis qu’une sous-plage reçoit un usage spécial plus précis.

Cette superposition illustre le besoin de registres distincts. Le registre unicast global IPv6 ne porte pas la même assertion que le registre des usages spéciaux. Un préfixe supérieur, une exception enfant et une allocation régionale répondent à des questions différentes. Les lire comme une seule « allocation Internet » fait disparaître l’autorité de chaque acteur.

RFC 7020 décrit une hiérarchie fonctionnelle : l’IANA gère le sommet du système des numéros, les RIR assurent les allocations régionales selon leurs processus. RFC 7249 place séparément les adresses unicast globales non réservées dans ce système. RFC 9812 ne transfère pas à l’IETF la politique quotidienne des RIR ; elle encadre le moment antérieur où une partie majeure de la réserve supérieure change de statut.

RFC 2860 situe l’IANA comme exécutant des politiques IETF pour les paramètres techniques. Une ligne du registre atteste donc l’exécution d’une instruction. Elle n’est ni un titre de propriété, ni une route, ni une acceptation contractuelle par un opérateur.

Il faut résister à une seconde inflation : appeler IETF Review « la volonté de la communauté mondiale ». Dans Le mirage multipartite, Heng Lu distingue participation et mandat. Ici, la légitimité tient à un périmètre plus étroit. L’IETF entretient un espace de protocole partagé ; l’ouverture d’un bloc supérieur peut toucher l’interopérabilité de tous les logiciels IPv6. L’examen technique est rattaché à cette dépendance commune.

Il ne devient pas pour autant une représentation démocratique de chaque utilisateur ou propriétaire d’actifs. La revue peut fournir expertise, objection et traçabilité. Elle n’autorise pas une politique patrimoniale absente de la RFC. La limite fait partie de la qualité du mécanisme.

La Spécification initiale minimale offre la bonne lecture : rendre obligatoire uniquement la règle commune nécessaire, puis laisser visibles les décisions locales. RFC 9812 gouverne la sortie de réserve. Les filtres, produits, annonces et usages restent attribuables à leurs opérateurs.

Les couches de réalité empêchent le raccourci. Une proposition peut exister sans consensus. Une RFC peut être approuvée avant la mise à jour IANA. Une ligne IANA peut exister sans route. Une route peut être annoncée sans être acceptée partout. Un paquet peut être accepté sans produire le service attendu.

La primauté du code en fonctionnement complète cette chaîne. Le registre rend une signification publique et stable ; seul le code et la configuration montrent que cette signification est utilisée. Les deux preuves sont indispensables, mais elles ne sont pas interchangeables.

RFC 9812 clarifie aussi que RFC 1881 appartenait au flux IETF alors que l’index l’avait classée à tort « Legacy ». RFC 8729 fournit le cadre des flux. Une erreur d’index n’annulait pas l’histoire ; sa correction restaure la provenance. C’est une autre leçon de gouvernance par les preuves.

La conclusion de sécurité reste prudente : la nouvelle politique n’a pas d’effet de sécurité direct, mais l’examen des mécanismes d’allocation soutient la responsabilité opérationnelle. Cela ne promet pas que chaque usage futur sera sûr. Les conséquences apparaîtront dans la spécification, les produits, les filtres et les réseaux concernés.

Une décision responsable conserve donc deux dossiers. Le premier prouve l’autorisation : préfixe, document, Last Call, objections, IESG, RFC, instruction IANA. Le second prouve l’opération : allocation enfant, ROA, route, filtre, support, mesure et retrait. Confondre les deux transformerait l’amélioration procédurale de RFC 9812 en nouveau symbole vide.

Sources