Résumé

  • Le 9 mai 2018, pendant AFRINIC-28 à Dakar, les participants ont examiné le premier projet publié le 28 mars. Un intervenant a demandé la suppression d’une condition qui aurait obligé le bénéficiaire à annoncer son bloc dans les douze mois avec la désagrégation minimale possible ; l’auteur l’a acceptée. Le Draft 2 du 11 mai a donc conservé un plan d’attribution de /48 sur douze mois, mais a retiré l’obligation d’annonce de route.
  • Le texte a maintenu /32 comme allocation initiale minimale tout en permettant un bloc plus grand sur justification. Il a élargi l’éligibilité d’un LIR aux services fournis à d’autres organisations, à des utilisateurs finaux, ainsi qu’à ses propres départements, entités ou sites apparentés. L’examen pouvait porter sur l’espace destiné aux clients, le nombre d’utilisateurs, l’étendue de l’infrastructure, la structure hiérarchique ou géographique, la segmentation de sécurité et la durée de vie prévue du bloc.
  • Une nouvelle procédure permettait, une seule fois, de corriger une allocation initiale devenue inadaptée sans attendre le seuil ordinaire d’utilisation d’une allocation ultérieure. Selon l’adjacence et l’inventaire, le préfixe pouvait être étendu, remplacé par un plus grand — avec restitution de l’ancien dans les six mois suivant la renumérotation — ou complété par un second préfixe.
  • Cette souplesse pouvait éviter fragmentation et renumérotation inutiles. Elle exposait aussi des prévisions commerciales et une architecture technique au jugement du personnel d’AFRINIC. Sans définitions reproductibles, motifs de décision, voie de correction factuelle et statistiques anonymisées, un bon mécanisme d’admission pouvait devenir un levier discrétionnaire.
  • AFRINIC décidait de l’accès à son inventaire IPv6 non attribué et de l’exactitude de son registre. Elle n’était ni souverain, ni régulateur, ni police, ni juridiction publique. Une décision sur une nouvelle allocation ne créait aucune compétence sur le réseau du demandeur et ne pouvait être assimilée à un pouvoir de punir ou de confisquer ses ressources existantes.

L3 — La correction rédigée deux jours après Dakar

Un changement de deux jours, puis six mois de mise en œuvre

Le sujet paraît minuscule si l’on ne regarde que les dates. Un premier texte est publié le 28 mars 2018. Il est discuté à Dakar le 9 mai, pendant AFRINIC-28. Deux jours plus tard, le 11 mai, la version 2.0 de AFPUB-2018-V6-003-DRAFT02 — IPv6 Initial Allocation Update est mise en ligne. Le Board d’AFRINIC la ratifie le 8 août par la résolution 201808.447. AFRINIC indique ensuite une mise en œuvre le 23 novembre dans le CPM v1.3, puis publie le 29 novembre un avis identifiant les sections modifiées : 6.5.1.1, 6.5.1.2, 6.5.1.3 et 6.5.2.3.

Cette chronologie ne raconte pourtant pas un simple nettoyage rédactionnel. Le passage du Draft 1 au Draft 2 touche trois décisions que tout demandeur doit pouvoir anticiper. D’abord : qui peut présenter une architecture IPv6 comme un besoin admissible ? Ensuite : à quelles conditions l’allocation initiale dépasse-t-elle /32 ? Enfin : que se passe-t-il lorsque le bloc accordé sur la foi d’une prévision ne correspond plus au déploiement réel ? À ces trois décisions s’ajoute une soustraction significative : le Draft 2 ne reprend pas la condition d’annonce de route qui figurait dans le Draft 1.

Le compte rendu officiel d’AFRINIC-28 établit l’enchaînement sans fournir un verbatim. Un participant demande le retrait de l’obligation d’annonce ; l’auteur, Jordi Palet Martinez, accepte. Les coprésidents consignent un soutien fort, aucune opposition, un consensus pour mettre le texte à jour et un passage en dernier appel. Ce compte rendu prouve ce que le processus privé a fait. Il ne prouve ni que les personnes présentes représentaient toute l’Afrique numérique, ni que le mot « consensus » conférait une autorité publique. Le Board a ensuite accompli un acte de ratification interne.

Cet acte a rendu la règle applicable au service d’AFRINIC ; il n’a pas transformé une société privée en législateur.

Il faut également résister à une confusion créée par les archives. La page historique du projet conserve un ancien libellé laissant entendre que la mise en œuvre serait encore en attente. Les avis ultérieurs et le rapport d’AFRINIC-29 indiquent au contraire que la règle était active à compter du 23 novembre 2018. La date d’entrée en service est donc documentée. En revanche, les documents publics ne disent pas combien de demandes ont été approuvées au-delà de /32, combien ont été refusées, combien d’opérateurs ont utilisé la correction unique ni combien de renumérotations ont été évitées. L’existence de la règle est un fait ; son rendement opérationnel ne peut pas être déduit de son adoption.

La porte d’entrée avant le Draft 2

Avant la modification, la section 6.5.1.1 du CPM posait un modèle relativement étroit. Le demandeur devait être un LIR, ne pas être un site terminal, montrer un plan détaillé pour fournir de la connectivité IPv6 à des organisations de la région de service d’AFRINIC et présenter un plan raisonnable d’attributions de /48 à des sites terminaux de cette région dans les douze mois. Cette formulation présumait en pratique une figure reconnaissable : un intermédiaire distribuant de la connectivité à des organisations extérieures.

Or tous les réseaux qui ont besoin d’une allocation agrégée ne se décrivent pas proprement ainsi. Un LIR peut exploiter une infrastructure répartie entre ses propres sites. Un groupe peut relier des départements ou entités apparentées. Une organisation peut fournir des services à des utilisateurs finaux sans que son architecture ressemble à celle d’un fournisseur vendant simplement des blocs à une collection d’entreprises clientes.

Le Draft 2 a répondu à ce décalage en conservant l’exigence de statut LIR, mais en reconnaissant une palette plus large : connectivité ou services destinés à d’autres organisations, à des utilisateurs finaux, ou aux départements, entités et sites appartenant au demandeur ou liés à lui, toujours dans la région AFRINIC.

Ce changement est substantiel parce qu’une règle d’entrée peut exclure avant même d’examiner la qualité d’un plan. Quand la définition du demandeur présuppose un seul modèle commercial, elle force les autres opérateurs à décrire leur réseau dans une catégorie mal ajustée ou à rester hors du service. Inclure les sites propres et apparentés rapproche donc le registre de la réalité qu’il doit consigner. Cela ne donne pas à AFRINIC le droit de décider quel modèle organisationnel est souhaitable. Cela signifie seulement que son formulaire privé cesse de nier des architectures qui existent déjà.

Le plan de douze mois, lui, demeure. Le texte exige encore un plan raisonnable pour effectuer des attributions de /48 à des sites terminaux de la région dans ce délai. Un /48 est ici une unité de planification mentionnée par la règle ; il ne faut pas transformer cette notation en un nombre certain de clients, d’utilisateurs ou de machines. Une taille de préfixe exprime une structure dans l’espace d’adressage. Elle ne démontre pas, à elle seule, la capacité commerciale, le trafic, l’adoption effective ou le nombre d’abonnés. Le plan devait rendre l’intention de déploiement suffisamment concrète pour l’admission, non fournir une prophétie exacte.

Cette nuance importe car une prévision à douze mois sert deux fonctions très différentes. Elle peut être un indice raisonnable qu’un demandeur n’accumule pas un bloc sans projet identifiable. Mais elle peut aussi devenir, si elle est traitée comme une promesse rigide, un instrument par lequel l’évaluateur substitue sa confiance ou sa préférence au jugement technique de l’opérateur. Le Draft 2 reconnaît lui-même que les prévisions peuvent échouer, puisqu’il ajoute une voie de rectification.

La cohérence commande donc de lire le plan de douze mois comme une preuve révisable fondée sur les informations disponibles, pas comme un serment sur l’avenir.

/32 : un minimum prévisible, pas un verdict sur le réseau

Le Draft 2 maintient /32 comme allocation initiale minimale. Cette base a une vertu administrative : un demandeur admissible sait quel plancher le service propose. Mais le texte ne s’arrête pas à un forfait uniforme. Une allocation supérieure devient possible lorsque la documentation du réseau la justifie. L’amélioration réside dans cette possibilité de faire correspondre l’entrée au registre à la forme du déploiement plutôt que d’attendre que l’opérateur accumule les coûts d’un mauvais dimensionnement.

Il serait incorrect de dire que /32 est « petit » en raison du seul nombre d’adresses qu’il recouvre. L’arithmétique IPv6 est trompeuse lorsqu’elle est convertie directement en mesure de capacité. Un bloc peut contenir une quantité immense d’identifiants et rester mal adapté à une architecture particulière si la politique interne réserve des niveaux cohérents à des régions, filiales, sites, fonctions ou domaines de sécurité. Le problème n’est pas nécessairement l’épuisement numérique. Il peut être l’impossibilité de conserver une hiérarchie stable, de déléguer proprement, de documenter les agrégats ou de laisser une marge raisonnable à une structure appelée à durer.

À l’inverse, la complexité d’un organigramme ne prouve pas automatiquement qu’un préfixe plus grand est nécessaire. Un demandeur doit relier la taille souhaitée à une structure d’adressage intelligible. La bonne question n’est donc ni « combien d’adresses existe-t-il mathématiquement sous /32 ? » ni « cette organisation paraît-elle assez grande ? ». Elle est : quel niveau d’agrégation, quelles subdivisions et quelle longévité rendent cette taille proportionnée à un réseau documenté ? Le registre peut vérifier le lien entre les faits présentés et le bloc demandé. Il ne peut pas ériger son goût pour une architecture compacte ou uniforme en loi du réseau.

Le bénéfice possible d’un bloc initial mieux dimensionné est concret, même si les sources ne le quantifient pas. Une allocation cohérente dès le départ peut réduire la probabilité de demandes fragmentées, de multiples préfixes à annoncer ou de renumérotation. Elle peut préserver une lecture plus simple de la topologie et donner à l’opérateur une marge de croissance ordonnée. Mais « peut » est ici décisif. Le texte n’a pas garanti l’agrégation mondiale, la routabilité, l’adoption d’IPv6 ou une économie mesurable. Il a créé une option d’admission dont la valeur dépendait de l’application et de la qualité de son examen.

Six familles de preuves, six portes ouvertes à l’interprétation

Pour justifier une taille supérieure à /32, le Draft 2 mentionne l’espace destiné aux clients, le nombre d’utilisateurs, l’étendue de l’infrastructure, sa structure hiérarchique ou géographique, la segmentation de sécurité ou d’une autre nature, et la longévité prévue de l’allocation initiale. Le texte réemploie ces facteurs pour déterminer la taille d’une allocation ultérieure. Pris ensemble, ils forment une tentative sérieuse de regarder un réseau comme un système et non comme une simple ligne de consommation.

L’espace client peut renseigner sur les délégations prévues et sur le niveau auquel l’opérateur veut conserver des limites stables. Le nombre d’utilisateurs peut donner une échelle, à condition de ne pas supposer une relation mécanique entre une personne et un volume d’adresses. L’étendue de l’infrastructure peut couvrir la présence sur plusieurs sites ou l’ampleur des éléments à administrer, mais elle doit être décrite avec des unités compréhensibles. La hiérarchie et la géographie peuvent expliquer pourquoi le plan réserve des niveaux distincts.

La segmentation de sécurité peut justifier des frontières qui ne suivent ni les clients ni les bâtiments. La longévité, enfin, oblige à penser le coût d’un plan conçu pour quelques mois face à celui d’une allocation destinée à accompagner une infrastructure durable.

Ces facteurs ont une qualité commune : ils sont liés à l’ingénierie. Ils ont aussi une faiblesse commune : leur intitulé ne dit pas exactement quelle preuve suffit. Qu’est-ce qu’un « utilisateur » lorsqu’un service compte à la fois salariés, clients, terminaux automatisés et utilisateurs occasionnels ? Comment mesurer l’« étendue » d’une infrastructure : nombre de villes, de sites, de routeurs, de zones opérationnelles ou de services ? Une structure géographique projetée doit-elle reposer sur des contrats déjà signés, un budget approuvé ou une fourchette de croissance ? Combien de niveaux de segmentation sont raisonnables ?

À quel horizon une allocation devient-elle durable plutôt que spéculative ?

Le texte officiel ne livre pas, dans les sources disponibles, un dictionnaire public complet de ces notions ni une série de décisions illustrant leur application. Cette absence ne prouve pas que le personnel décidait arbitrairement. Elle signifie que le public ne peut pas vérifier, à partir du dossier historique, si deux plans comparables recevaient une appréciation comparable. C’est une limite de connaissance, et non une accusation de mauvaise foi. Elle suffit toutefois à identifier le lieu du risque institutionnel : plus le facteur est ouvert, plus le résultat dépend du raisonnement non publié de l’évaluateur.

Un guide opérateur ultérieur de NRS décrit le parcours pratique : vérification de l’éligibilité, documents juridiques et techniques, diagrammes de réseau, plan de déploiement IPv6 et évaluation par des hostmasters. Cette description n’établit pas comment Draft 2 fut appliqué en 2018, mais elle montre pourquoi les mots du CPM ont une conséquence matérielle. Un facteur n’est pas une abstraction lorsqu’il détermine quels plans, schémas et prévisions un opérateur doit réunir, expliquer, mettre à jour et parfois défendre. Le coût de preuve commence avant la décision.

Ce coût peut être légitime. Une distribution coordonnée exige assez d’information pour éviter les doubles inscriptions et choisir un agrégat cohérent dans l’inventaire non attribué. Mais la collecte doit rester proportionnée à la décision. Une projection commerciale détaillée ne devrait pas être exigée si une plage chiffrée, une topologie et des hypothèses explicites suffisent. Un diagramme de sécurité ne devrait pas exposer des détails exploitables lorsqu’une description des domaines et des ratios répond à la question de taille. La preuve utile établit le besoin technique ; elle ne livre pas gratuitement l’intimité stratégique du demandeur.

La correction unique : reconnaître que le futur résiste au formulaire

La nouvelle section 6.5.1.3 contient probablement l’innovation la plus opératoire du Draft 2. Lorsqu’une organisation constate que son allocation initiale ne répond plus aux besoins du déploiement, elle peut présenter un nouveau plan d’adressage sans devoir d’abord franchir le seuil d’utilisation normalement applicable à une allocation ultérieure. Le mécanisme sépare donc deux situations : demander davantage parce qu’un bloc a été consommé selon le rythme prévu, et corriger un dimensionnement initial qui ne correspond plus à la structure réelle.

Cette distinction est saine. Un opérateur peut découvrir qu’une hiérarchie prévue ne résiste pas à une fusion de réseaux, qu’une expansion géographique rend le plan trop compact ou qu’une nouvelle segmentation de sécurité exige des limites différentes. Il peut aussi avoir mal anticipé sa croissance. Forcer d’abord le remplissage d’un plan reconnu comme inadéquat pourrait multiplier les exceptions locales, créer une structure difficile à exploiter puis imposer une renumérotation plus coûteuse. La correction permet de traiter l’erreur de prévision comme un problème d’architecture plutôt que comme une faute.

Le texte propose trois issues dépendant de l’adjacence du stock et de l’inventaire disponible. Si un espace contigu existe, le préfixe initial peut être étendu. C’est l’issue la plus simple : l’opérateur conserve la continuité du bloc et ajoute de la capacité structurelle. Si l’extension n’est pas possible, l’organisation peut recevoir un nouveau préfixe plus grand, renuméroter, puis restituer l’ancien dans les six mois suivant cette renumérotation. Enfin, elle peut recevoir un préfixe complémentaire ; les deux blocs sont alors considérés ensemble lorsqu’une future allocation est évaluée.

Aucune de ces options n’est gratuite. L’extension dépend d’un fait que le demandeur ne contrôle pas : la disponibilité d’espace adjacent dans le registre. Le remplacement offre un ensemble plus cohérent mais déclenche une renumérotation. Le préfixe complémentaire évite peut-être cette opération immédiate, au prix d’une architecture à plusieurs blocs. Le mécanisme ne supprime donc pas le coût du mauvais dimensionnement ; il donne un éventail de sorties et empêche que le seuil ordinaire d’utilisation bloque toute correction.

La période de six mois ne doit pas être décrite comme si elle suffisait toujours. Les sources établissent le délai, pas sa facilité. Une renumérotation peut toucher les configurations, les fenêtres de changement des clients, les contrôles de sécurité, la supervision, la documentation et le DNS inverse ; chaque environnement détermine l’ampleur réelle. Dire que le coût existe est fondé. Prétendre que Draft 2 l’a supprimé ou qu’un nombre précis d’opérateurs l’a évité ne le serait pas.

L’usage unique de la procédure crée, lui aussi, un compromis. Il empêche qu’une voie d’exception remplace indéfiniment la discipline des allocations ultérieures. En même temps, il rend la première correction particulièrement importante : un opérateur sait qu’une seconde erreur structurelle ne bénéficiera pas du même raccourci. Le registre devrait donc expliquer très clairement les hypothèses retenues lors de la rectification. Sans motifs, le demandeur ne peut pas distinguer une insuffisance factuelle qu’il aurait pu corriger d’une préférence de l’évaluateur qu’aucun document ne satisfera jamais.

La procédure porte une leçon plus profonde. En permettant une rectification, le texte admet implicitement qu’une prévision ex ante peut être raisonnable et néanmoins devenir fausse. Cette admission devrait gouverner tout l’examen initial. Les prévisions sont des estimations structurées, pas des faits futurs déjà observables. Une décision robuste doit évaluer la méthode, les hypothèses et la cohérence du plan, tout en laissant une place explicite à l’incertitude. Exiger une certitude impossible ne produit pas plus d’exactitude ; cela récompense seulement les demandes qui savent donner à l’incertain une apparence définitive.

La condition d’annonce supprimée : ne pas confondre attribution et routage

Le Draft 1 du 28 mars ajoutait un critère : annoncer le bloc attribué dans les douze mois avec le minimum de désagrégation possible. À Dakar, le 9 mai, un participant a demandé son retrait et l’auteur a accepté. Le Draft 2 du 11 mai ne contient plus cette obligation. C’est la différence démontrable qui autorise à parler de Draft 1 ici ; le premier projet n’est pas le sujet indépendant de cette analyse.

La suppression est importante parce qu’une inscription d’allocation et une décision de routage ne sont pas la même chose. Un opérateur peut organiser un déploiement par étapes. Il peut avoir des raisons techniques de ne pas annoncer immédiatement la totalité du bloc ou de choisir un calendrier lié à ses migrations, à ses accords de transit et à ses contrôles internes. Une règle d’admission peut demander un projet crédible ; elle ne doit pas imposer sans nécessité un comportement de routage particulier comme condition de la relation de registre.

Le retrait suggère que les participants ont distingué l’éligibilité à l’allocation d’un choix opérationnel ultérieur. C’est une inférence bornée, soutenue par la demande de suppression et par l’omission qui suit. Elle ne permet pas de conclure que la proposition a modifié le routage mondial, amélioré la visibilité de préfixes ou garanti l’agrégation. Elle permet seulement d’observer qu’un contrôle envisagé sur la manière et le moment d’annoncer n’a pas survécu au passage au Draft 2.

Le compte rendu mentionne aussi une suggestion d’alignement sur les frontières de nibble. L’auteur a refusé de l’ajouter à cette proposition afin de ne pas la rendre plus complexe ; le personnel indiquait déjà traiter certains cas de manière opérationnelle et accueillait favorablement une formulation de politique. Ce détail montre la discipline nécessaire à toute analyse de version : tout ce qui a été discuté n’a pas été adopté. Le texte final doit être évalué pour ce qu’il contient, pas pour l’ensemble des améliorations imaginées dans la salle.

Le meilleur cas en faveur du Draft 2

Avant d’éprouver la portée institutionnelle du mécanisme, il faut lui accorder son meilleur cas. Un minimum uniforme de /32 pouvait être mal ajusté à un réseau gouvernemental, à un grand fournisseur ou à un opérateur réparti entre de nombreuses zones, hiérarchies et frontières de sécurité. Un plan documenté pouvait aider à sélectionner, dès l’origine, un agrégat assez vaste pour éviter une croissance fragmentée. Les facteurs de sécurité, de géographie et de hiérarchie correspondent à de véritables choix d’ingénierie. L’intégration des départements et sites apparentés corrigeait une vision trop étroite du LIR comme simple distributeur externe.

La correction unique répondait elle aussi à un vrai problème. Lorsqu’un plan initial n’est plus adapté, attendre un seuil d’utilisation ordinaire peut enfermer l’opérateur dans une architecture qu’il sait déjà mauvaise. L’extension contiguë, le remplacement ou le complément donnaient trois réponses possibles aux contraintes de l’inventaire. Et la suppression de la condition d’annonce empêchait une préférence de routage de devenir un péage à l’entrée.

Dans cette lecture, AFRINIC ne dessinait pas les réseaux. Elle tentait de mieux ajuster un service d’attribution à ce que les opérateurs construisaient réellement. Le registre devait sélectionner une taille dans un stock non attribué, préserver l’unicité des inscriptions et enregistrer le résultat. Pour accomplir cette tâche, il pouvait raisonnablement demander pourquoi un agrégat plus large était nécessaire. Un formulaire aveugle à la structure serait aussi défectueux qu’un formulaire qui prétend la commander.

Ce cas est fort parce qu’il ne dépend pas d’un slogan sur IPv6. IPv6 n’abolit ni le coût du capital, ni la complexité, ni les erreurs de configuration, ni la difficulté d’une renumérotation. Une abondance arithmétique d’adresses ne rend pas toutes les structures équivalentes. Un critère qui reconnaît l’architecture peut donc servir l’opérateur. Mais cette justification ne valide que la collecte d’éléments pertinents et la décision sur l’inventaire demandé. Elle ne valide ni des définitions mouvantes, ni des refus sans motifs, ni une compétence générale sur les choix du réseau.