Résumé

  • La version 2 a sciemment supprimé la réévaluation générale ; son auteur a ensuite précisé qu'un détenteur existant n'était pas concerné tant que son besoin ne changeait pas.
  • Une demande de croissance ouvre en revanche un embranchement : extension au prochain palier nibble ou nouvelle attribution suivie de la restitution des anciens préfixes sous six mois si la contiguïté manque.
  • Un reçu de transition en quatorze champs peut rendre cet embranchement contrôlable sans publier la topologie, les clients ni le plan de migration du détenteur.

Le lundi valide et la demande du mardi

Lundi, neuf objets /48 peuvent décrire un réseau ancien mais légitime. Mardi, le même détenteur demande de l'espace supplémentaire. Les lignes de la base n'ont pas encore changé, mais la nature du dossier, elle, vient de basculer.

Cet exemple n'est pas abstrait. En mars 2025, un participant a déclaré détenir neuf attributions PI en /48 et vouloir les regrouper, de préférence sans renumérotation. Il citait aussi bien les objets de registre que le DNS. Son message est le récit attribuable d'un opérateur ; ce n'est ni un audit de ses ressources actuelles, ni une statistique régionale, ni la preuve d'un abus.

Il montre néanmoins ce qu'une politique doit conserver : l'ensemble initial n'est pas une quantité sans histoire. Chaque préfixe peut être présent dans le routage, les zones inverses, les listes de contrôle, la supervision et des configurations que personne ne recense dans un même endroit.

La stabilité n'est pas une lacune

La présentation de la version 2, en octobre 2025, dit clairement ce que les auteurs ont retiré. La définition proposée d'« End Site » disparaît, tout comme la réévaluation des besoins lors d'une demande additionnelle ou plus grande. Le texte devait devenir plus concis et plus lisible. Il ne faut donc pas raconter cette suppression comme un oubli.

En mars 2026, une question vise précisément les détenteurs de plusieurs PI qui ne demandent aucune croissance. La réponse de l'auteur tient en une limite institutionnelle : il n'y a pas d'effet pour eux si leur besoin d'espace ne change pas.

C'est une bonne règle de non-intervention. Une nouvelle architecture de politique ne doit pas rendre fautif un déploiement qui était valable la veille. Elle ne doit pas non plus transformer le registre en chef de projet du réseau. Tant qu'aucun événement nouveau n'est soumis, l'ancien état peut rester localement stable.

La croissance, elle, produit un événement

La discussion de la section 7.1.2 décrit l'autre côté. Un détenteur d'une ou plusieurs PI qui a besoin d'espace supplémentaire doit viser une extension au prochain palier de quatre bits. Si aucun espace contigu ne permet cette extension, il peut obtenir une nouvelle attribution et doit restituer les précédentes au terme d'une renumérotation de six mois. Un participant a repris ce passage et contesté la durée, préférant douze ou vingt-quatre mois, ou une prolongation justifiée.

La présente analyse ne tranche pas ce choix. Six mois ne sont ni déclarés impossibles, ni présentés comme une échéance déjà manquée. L'important est ailleurs : la demande crée une chaîne de décisions que la seule nouvelle ligne de préfixe ne peut raconter.

Il faut relier l'ancien ensemble, la demande qui modifie le besoin, la version de règle utilisée, le résultat du test de contiguïté, l'embranchement choisi, le nouveau préfixe, le début de coexistence et la clôture des restitutions. Sans ce lien, deux personnes peuvent regarder le même état final et reconstruire deux histoires différentes.

La fenêtre de rédaction est encore ouverte

Le 15 juin 2026, les coprésidents ont annoncé huit soutiens et l'intention de passer en phase de révision. Ils indiquaient que des corrections éditoriales mineures seraient intégrées et qu'une analyse d'impact ainsi qu'un projet de politique seraient publiés.

Cette annonce n'est pas une adoption. Le corpus examiné ici ne permet pas d'affirmer qu'une phase de révision a ensuite été ouverte, qu'un consensus a été trouvé ou qu'un système de production a été modifié. C'est justement pourquoi le moment est utile : la sémantique du passage peut encore être inscrite dans le texte et dans l'analyse d'impact, avant de devenir une convention implicite de traitement des dossiers.

La renumérotation dépasse le dossier administratif

Un délai unique paraît propre sur le papier. Le réseau, lui, avance par recouvrement. Le RFC 4192 décrit une renumérotation IPv6 sans « jour J » : obtenir le nouveau préfixe, préparer les sous-préfixes, ajouter les nouvelles adresses, modifier routage, DNS, DHCP et références configurées, faire fonctionner ancien et nouveau en parallèle, tester, puis retirer l'ancien.

Le RFC 5887 rappelle ce qui résiste à cette belle séquence. Des adresses statiques restent disséminées ; certaines ne se révèlent qu'au premier incident. Pendant le recouvrement, les règles et la supervision doivent comprendre les deux familles de préfixes. Des outils supportent mal cet état double.

Ces RFC ne fixent aucune règle au RIPE NCC. Ils donnent seulement la forme opérationnelle du problème. « Restitué » est le dernier état d'un processus dont les preuves sont distribuées entre le registre et le détenteur.

Modéliser le seuil plutôt que l'inventer après coup

Notons P0 la liste ordonnée des anciennes PI à une date donnée, N0 le besoin alors documenté et q la nouvelle demande. H identifie le texte applicable. C(q, P0) représente le résultat de réservation et de contiguïté ; T, l'extension ou le remplacement choisi ; P1, la ressource résultante ; D, les horloges de coexistence et de restitution.

L'événement contrôlable devient :

E = G(P0, N0, q, H, C, T, P1, D).

C'est un modèle d'audit proposé par l'auteur, pas un schéma publié par RIPE NCC. Il permet de voir pourquoi une attribution finale n'est pas une preuve complète. Avant q, rien ne bouge. Après q, les identités doivent rester jointes jusqu'à la clôture ou à la correction.

Quatorze champs suffisent

Le reçu commun n'a pas à exposer le dossier technique intégral.

  1. Identité du reçu. Identifiant stable et version du schéma.
  2. Règle applicable. Proposition ou politique, version, empreinte du texte, statut et date d'effet.
  3. Coupe de l'état antérieur. Instant exact et fuseau de l'inventaire initial.
  4. Détenteur et demande. Référence publique minimale, numéro de dossier et heure authentifiée, sans coordonnées privées.
  5. Classe du déclencheur. Absence de changement, demande additionnelle, attribution plus grande ou correction, avec la raison d'activer ou non la section 7.1.2.
  6. Ensemble PI initial. Identités ordonnées, longueurs, états et empreintes des objets.
  7. Besoin évalué. Accepté, refusé ou indéterminé, unité cible et motif public borné ; la topologie brute reste protégée.
  8. Palier nibble. Valeur demandée, valeur retenue et raison de l'écart.
  9. Preuve de contiguïté. Instantané de réservation, plage voisine testée, heure et résultat déterministe, sans révéler des ressources étrangères au dossier.
  10. Voie choisie. Extension, nouvelle attribution, maintien, refus ou demande de preuves.
  11. Ressource résultante. Identité, préfixe, version d'objet et heure d'activation.
  12. Horloge de coexistence. Début, échéance de restitution, fuseau et identité de toute suspension ou prolongation autorisée.
  13. Ensemble à restituer. État de chaque ancienne attribution, preuve de clôture et exception non résolue.
  14. Chaîne de correction. Autorité de décision, voie de recours ou de correction, reçu remplacé et état final.

Le reçu atteste une séquence. Il ne transforme pas une affirmation de besoin en vérité automatique et ne publie pas les secrets du réseau.

Cinq cas doivent produire cinq réponses prévisibles

  1. Ancien ensemble sans croissance. Plusieurs PI et aucun besoin nouveau : aucun déclenchement, aucune horloge de restitution.
  2. Extension contiguë. Besoin justifié et espace voisin disponible : l'ancien ensemble, le test de réservation et l'objet étendu restent liés.
  3. Remplacement non contigu. Besoin justifié sans place voisine : nouvelle attribution, liste explicite des restitutions et période de recouvrement.
  4. Demande retirée. Retrait avant activation de la nouvelle ressource : clôture sans démarrage du délai.
  5. Correction. Une ancienne attribution mal incluse ou une date erronée est remplacée par un reçu de correction, sans effacement silencieux.

Ces vecteurs ne dictent pas l'outil. Ils garantissent que deux outils différents nomment la même transition de la même manière.

Un noyau commun, pas un centre de commande

La Note 64 de HENG.LU conduit à réduire le socle partagé : identités ancienne et nouvelle, version de règle, déclencheur, contiguïté, décision, horloge, clôture et correction. Tout le reste peut demeurer local ou protégé : topologie, trafic, clients, données d'utilisation, inventaire des équipements, objectif commercial et ordre réel des travaux.

La communauté définit la règle. RIPE NCC l'applique et signe sa décision. Le détenteur fournit des faits et pilote son réseau. Un tiers vérifie le reçu, sans acquérir le pouvoir d'attribuer ou d'invalider une ressource.

La même frontière protège le choix de ne rien faire. Un détenteur valide dont le besoin ne change pas n'a pas à se regrouper pour satisfaire un nouveau format. Le reçu devient nécessaire lorsqu'une transition faisant autorité est réellement instruite.

Sources

Limites des preuves

Vérifié : la version 2 a retiré la réévaluation générale ; l'auteur a exclu les besoins inchangés ; le texte discuté contient un embranchement de croissance et un délai de six mois ; les coprésidents envisageaient la phase suivante ; une renumérotation IPv6 traverse plusieurs états opérationnels.

Inférence : la nouvelle ligne de préfixe ne permet pas, à elle seule, de reconstruire le passage ni ses horloges.

Recommandation : un reçu en quatorze champs et cinq cas de test avant mise en œuvre.

Inconnu : texte de révision, analyse d'impact, durée finale, point de départ du délai, exceptions, schéma interne, nombre de détenteurs concernés et toute mise en production.