Résumé

  • Dans un message du 24 septembre 2026, les coprésidents du groupe Address Policy ont annoncé le retrait de la proposition 2024-01 sur les attributions IPv6 PI. Le texte sera archivé et le sujet pourra revenir ; aucune raison précise du retrait, ni adoption partielle, n’est donnée.
  • Lors d’une consultation directe le 27 septembre, la fiche de la version 3.0 affichait toujours une Review Phase ouverte. Le message postérieur renseigne l’état du processus ; la fiche illustre un décalage de publication, sans établir sa cause ni démentir le retrait.
  • RIPE-738 et les consignes actuelles de demande IPv6 PI restent la base pratique : /48 minimum, justification d’une taille supérieure et interdiction de réattribuer des préfixes PI à une autre organisation. Les assouplissements envisagés dans 2024-01 ne sont pas devenus des droits.
  • Retirer le projet ne retire aucune attribution existante et ne revient pas sur une règle que le projet n’a jamais créée. Le PDP de RIPE permet de rouvrir le débat par une nouvelle proposition, sans présumer de son texte ni de son résultat.

Un /44 imaginé n’est pas un /44 accordé

Une entreprise construit une architecture pour plusieurs sites et calcule qu’un /48 ne lui donnera pas la marge souhaitée. Elle a lu le projet 2024-01 : une progression par limites de quatre bits, la possibilité d’un /44 lorsque le besoin le justifie, une réservation contiguë destinée à faciliter la croissance. Ce sont des paramètres de réseau, pas de simples mots de juriste. Ils orienteraient le plan d’adressage, les investissements et peut-être les engagements faits à des clients. Mais ils n’ont jamais franchi la frontière entre un texte discuté et la règle sous laquelle RIPE NCC traite une demande.

Le courrier des coprésidents est bref. Il indique que 2024-01 a été retirée, rappelle qu’elle visait à réduire la charge liée à l’espace PI et à éclaircir une rédaction ancienne, annonce son archivage et précise que toute personne peut réintroduire le sujet. Il n’explique pas ce qui a convaincu les auteurs ou les présidents. Il ne décrit ni vote, ni constat détaillé d’échec du consensus, ni décision d’un conseil d’administration empêchant la politique. Les discussions techniques abondantes ne comblent pas ce silence. On peut comprendre les difficultés d’un projet sans inventer la cause administrative de sa fin.

La page du projet demeurait pourtant, au contrôle du 27 septembre, marquée comme ouverte en phase de révision, pour la version 3.0 du 25 août. L’index des propositions archivées consulté au même moment ne présentait pas encore d’entrée visible pour 2024-01. Un lecteur peut raisonnablement être désorienté. Il ne peut raisonnablement en déduire que le retrait a été annulé. Le décalage peut relever du temps nécessaire à la mise à jour d’un site ; sa cause exacte n’est pas documentée dans les sources examinées. Il faut exposer le conflit des affichages sans lui prêter une intention.

Pour l’entreprise, l’ordre des preuves évite l’erreur. Le message daté traite de la disposition de la proposition. Le document de politique publié fixe les conditions actuelles. Les instructions du registre expliquent comment soumettre une demande aujourd’hui. Le projet retiré et l’analyse de ses effets conservent une valeur historique et intellectuelle. Aucun de ces documents ne modifie à lui seul l’itinéraire BGP, le titulaire enregistré ou les objets RPKI existants. Ce sont des couches différentes, que l’on gagne à ne pas réunir sous un seul mot « politique ».

Pourquoi le projet réunissait trop de questions pour être lu à la légère

Il y avait une défense sérieuse de la démarche des auteurs. La version 3.0 ne se contentait pas d’augmenter une taille. Elle retouchait la définition d’une attribution et certaines utilisations du préfixe au §2.6, la description des attributions issues d’allocations au §5.4, puis, au §7.1, la taille PI, les limites de nibble, les extensions et le remplacement lorsque l’extension contiguë était impossible. Un cas d’usage toléré peut changer le nombre d’adresses requises ; la taille attribuée influence le choix de routes ; une réserve de croissance n’a pas la même valeur si un transfert partiel fragmente le bloc.

Traiter ces interactions ensemble pouvait rendre visibles des coûts qu’une petite modification isolée aurait cachés.

L’analyse d’impact de RIPE NCC a justement mis ces interactions à l’épreuve. En cas d’adoption, elle prévoyait une forte charge de développement, des changements de procédure, de documentation et de formation. Elle soulevait des difficultés pour vérifier certaines obligations sans rendre le registre moins précis. Elle notait qu’un bloc attribué sur une limite de nibble pourrait ensuite être transféré en partie, compromettant l’espace réservé à son extension. Elle demandait également comment traiter les attributions déjà faites, les plans d’utilisation incomplets et une renumérotation non terminée dans les six mois. L’Executive Board recommandait vivement de revoir le texte.

Ce diagnostic explique pourquoi une attribution plus large ne serait pas un simple réglage informatique. Il ne prouve ni dommage déjà subi ni motif du retrait annoncé le 24 septembre. Une évaluation d’impact décrit des effets possibles si le projet est accepté. Une recommandation du conseil de le réviser ne doit pas devenir, sous la plume d’un journaliste, un veto de politique. Le PDP donne à la discussion communautaire, aux présidents du groupe et au secrétariat des rôles distincts. Leur confusion serait particulièrement malvenue dans un article consacré à la différence entre statut et règle.

La demande réelle revient à RIPE-738

La politique IPv6 RIPE-738 reste le texte publié. Elle donne /48 comme taille minimale d’une attribution PI. Une demande plus vaste appelle une justification pertinente, notamment par l’usage prévu ou des exigences de routage différentes ; le retrait de 2024-01 n’instaure pas une interdiction absolue d’obtenir davantage. En revanche, le mécanisme proposé de progression par limites de nibble et la réservation recommandée ne sont pas des garanties actuelles. RIPE-738 interdit en outre de sous-attribuer PI à une autre organisation, tandis que la règle relative aux LIR vise leur propre infrastructure et non les sites de leurs clients.

Les instructions de RIPE NCC pour demander du PI rendent la distinction concrète : il faut étayer le besoin d’un préfixe plus grand ou les contraintes de routage, et le PI ne peut servir à remettre un préfixe à un tiers, même de longueur /64 ou /96. L’usage d’adresses isolées et la délégation d’un préfixe ne sont pas assimilables. Une société qui souhaite relier l’équipement d’autrui doit donc préciser qui exploite le réseau, qui contrôle le site et ce qu’elle remet effectivement. Si elle doit suivre une autre voie, par exemple une allocation ou un espace fourni en amont, le choix découle des options présentes, non de la disparition du projet.

Le titulaire déjà enregistré, lui, ne reçoit pas un ordre de repartir de zéro. Le retrait n’annule pas sa ressource, ne déclenche pas automatiquement une restitution, ne l’oblige pas à renuméroter et ne retire aucune route. Le projet n’était pas devenu une politique mise en œuvre. Une éventuelle modification ultérieure de l’enregistrement, de la certification ou de la topologie aurait sa propre base et ses propres étapes observables. C’est la limite fondamentale du raisonnement par étiquette : le mot « retiré » porte sur la proposition, pas sur tous les objets que la proposition aurait pu un jour toucher.

Conserver les questions, sans leur prêter une décision

L’invitation à réintroduire le sujet n’est ni une promesse de reprendre exactement la version 3.0 ni une annonce de consensus futur. Elle signifie que les besoins évoqués — croissance PI, usage sur un même site, agrégation, transition — demeurent discutables. Un futur texte devrait dire clairement à qui il s’applique, comment un besoin est prouvé, ce que deviennent les attributions anciennes et ce qui se passe lorsqu’une extension contiguë ou une renumérotation échoue. Il pourrait découper le problème autrement.

Il lui faudrait malgré tout parcourir ses propres étapes du PDP ; le temps consacré à l’ancien dossier ne vaut pas approbation transférable.

Le site, pour sa part, devrait finir par relier la décision du 24 septembre à la fiche, aux versions et à l’archive. Il ne s’agit pas de transformer chaque retard de publication en crise de légitimité. Il s’agit de permettre à un opérateur de retrouver facilement quelle proposition a cessé d’avancer et quelle règle continue à s’appliquer. Tant que deux surfaces publiques diffèrent, il faut les lire selon leur date et leur fonction. Une décision de réseau ne devrait jamais dépendre du seul badge que le moteur de recherche a choisi de montrer.

Sources