Résumé

  • En mars 2018, la proposition AFPUB-2018-V6-001-DRAFT01 a entrepris une réparation circonscrite du manuel IPv6 d’AFRINIC : remplacer la référence périmée à RFC 3177 par RFC 6177, retirer le conseil du /128 pour un appareil unique, passer d’une utilisation comptée en /48 à une utilisation comptée en préfixes, corriger un renvoi interne et supprimer une procédure d’examen devenue obsolète.
  • Cette intervention pouvait être présentée à juste titre comme une clarification sans changement de pratique immédiat. Elle avait pourtant une portée opérationnelle réelle : un texte plus juste modifie ce que les membres peuvent raisonnablement prévoir, les justificatifs qu’ils préparent, la façon dont le personnel lit l’utilisation et le risque de choix d’adressage coûteux à défaire.
  • La leçon institutionnelle est celle d’une compétence étroite. AFRINIC est un teneur de registre et un coordinateur technique privé, sans aucune autorité souveraine, réglementaire, policière, punitive, confiscatoire ou juridictionnelle. Un manuel exact rend ce service privé plus fiable ; il ne le transforme pas en droit public.
  • Toute correction future devrait laisser des preuves facilement vérifiables : registre des dépendances techniques, différence visible entre ancien et nouveau texte, reçu d’interprétation, avis d’exécution et contrôle explicite de portée. Le même dispositif qui améliore l’exactitude doit empêcher qu’une opération de maintenance serve de véhicule à une extension de pouvoir.

L3 — La référence périmée cachée dans le manuel

Le défaut initial tenait en apparence à quelques lignes. Dans la section 6.0 du manuel, un lecteur trouvait encore une répartition héritée d’un document de 2001 : un /48 comme recommandation générale, un /64 lorsqu’un seul sous-réseau était connu et un /128 lorsqu’un seul appareil était connu. Le texte parlait en outre d’ISP et indiquait RFC 3177 comme référence. Or, depuis mars 2011, RFC 6177 avait expressément rendu RFC 3177 obsolète. Pendant sept ans, le manuel interne d’AFRINIC était donc resté raccordé à une recommandation que le dossier technique pertinent avait déjà remplacée.

Cette distance temporelle n’établit ni malveillance, ni négligence, ni dommage concret. Elle établit quelque chose de plus sobre mais de suffisamment important : le document utilisé pour guider les demandes et leur traitement n’était plus entièrement synchronisé avec son propre environnement technique.

Il faut résister à deux raccourcis opposés. Le premier consisterait à dire qu’il ne s’agissait que d’une coquille, sans conséquence possible. Une référence normative n’est pas un élément décoratif lorsque des opérateurs s’en servent pour dimensionner une architecture et lorsque le personnel s’en sert pour comprendre une demande. Le second raccourci ferait de chaque évolution d’un conseil technique une faute institutionnelle ou une rupture radicale de pratique.

Les sources disponibles ne mesurent ni le nombre de membres ayant suivi l’ancienne formule, ni le nombre de /128 effectivement attribués à cause du manuel, ni aucun coût de renumérotation. Elles ne permettent pas davantage d’affirmer que le personnel appliquait mécaniquement chaque phrase ancienne. La conclusion solide se situe entre ces excès : une incohérence documentée créait un risque d’interprétation, et la corriger relevait du devoir ordinaire d’un service de registre fiable.

La substitution de RFC 6177 à RFC 3177 ne revenait pas à remplacer une taille obligatoire par une autre. C’est précisément l’inverse. La recommandation de 2011 refusait qu’une seule taille soit imposée à tous les sites d’extrémité. Elle décourageait l’attribution d’un simple /128, trop étroit pour la logique normale d’un site IPv6, mais elle ne transformait pas non plus le /48 en réponse universelle. La taille exacte restait une question de jugement opérationnel éclairé par l’architecture du réseau.

Cette nuance est centrale, car un manuel mal lu peut facilement fabriquer une règle absolue là où la source technique organise une gamme de choix. Corriger le renvoi signifiait ainsi remettre la latitude technique au bon endroit : ni dans un automatisme hérité de 2001, ni dans une discrétion illimitée du registre, mais dans une appréciation liée aux besoins réels de l’utilisateur final.

Le nouveau texte proposé pour la section 6.0 traduisait ce changement de perspective. Il remplaçait le vocabulaire d’ISP par celui de LIR, plus adapté au rôle de registre local dans la chaîne d’allocation. Il conservait des exemples autour du /48 et du /64, mais supprimait le conseil spécifique du /128 pour un appareil unique. Il orientait le lecteur vers RFC 6177. Ces modifications ne prétendaient pas redessiner toute la politique IPv6. Elles nettoyaient l’interface entre la politique locale et la recommandation technique extérieure.

C’est une différence importante : le registre ne créait pas l’architecture d’IPv6 et n’acquérait aucun pouvoir sur elle. Il entretenait le document privé par lequel il expliquait aux membres comment son service traiterait les demandes relevant de sa fonction de coordination.

La proposition allait cependant au-delà d’un simple échange de référence bibliographique. La définition de l’utilisation était elle aussi réécrite. L’ancien texte mesurait l’utilisation à partir des /48 attribués aux sites d’extrémité. Cette formulation liait artificiellement le calcul à une taille particulière, alors même que la mise à jour reconnaissait que des besoins différents pouvaient appeler des préfixes différents. Le projet définissait donc l’utilisation par le nombre de préfixes attribués, et non par leur taille ni par le nombre d’adresses effectivement actives à l’intérieur de chacun.

Ce passage d’un dénominateur implicitement fixé au /48 à un comptage de préfixes n’est pas une subtilité mathématique isolée. Il rétablit la cohérence entre le choix de taille fondé sur le besoin et la manière de décrire les affectations qui en résultent.

Cette définition protège aussi contre une confusion fréquente entre trois réalités. Compter les préfixes attribués n’est pas compter les adresses utilisées ; dans IPv6, le volume théorique d’adresses d’un préfixe ne constitue pas une mesure utile de l’occupation appareil par appareil. Compter les préfixes n’est pas non plus convertir toute affectation en unités fictives de /48. Enfin, compter des préfixes n’oblige pas chaque site à recevoir le même préfixe. La proposition alignait ainsi le vocabulaire du suivi sur la diversité opérationnelle qu’elle reconnaissait par ailleurs.

Un LIR pouvait comprendre plus facilement ce qui entrait dans la notion d’utilisation, et le personnel disposait d’une base moins contradictoire pour lire les éléments soumis.

Le texte révisé remplaçait en parallèle des listes de tailles fixes par une logique de besoin. Il recommandait le /48 pour une infrastructure plus simple, encourageait la persistance des préfixes et retenait le /64 globalement routable pour les liens point à point. Ces éléments faisaient écho au document RIPE-690 publié en octobre 2017. Celui-ci insistait sur l’importance de donner aux utilisateurs finaux un espace suffisant et stable, en tenant compte du coût des choix trop serrés ou trop provisoires.

La persistance n’est pas un luxe rédactionnel : changer un préfixe peut toucher le provisionnement, les journaux, les listes de contrôle, la documentation, l’assistance client et de nombreux automatismes. Le manuel ne pouvait éliminer ces coûts, mais il pouvait cesser d’orienter les lecteurs vers une architecture périmée qui les rendait plus probables.

L’exemple des liens point à point demande la même discipline. Recommander un /64 globalement routable pour cet usage dans le cadre décrit ne signifie pas que tout /64 serait nécessairement correct dans toute situation, ni que l’ensemble de l’adressage devrait être aplati sur ce choix. Cela signifie que la politique devait refléter des pratiques opératoires documentées au lieu de transformer le nombre d’équipements visibles en règle de dimensionnement. La différence est celle qui sépare un manuel de coordination d’un tableau arbitraire.

Le premier expose des repères et permet une justification technique ; le second substitue la rigidité du formulaire à l’architecture réelle.

Une autre correction touchait la mécanique interne du document. L’exception pertinente renvoyait à la section 6.3.3, alors que le bon renvoi était la section 6.5.2. Un numéro faux oblige le lecteur à chercher par lui-même la règle visée ou, pire, le conduit vers une disposition qui ne répond pas à sa question. La proposition réparait ce lien tout en maintenant l’idée que des informations détaillées sur le réseau des utilisateurs ne seraient pas normalement exigées. Là encore, une ligne éditoriale touche directement la frontière de l’action du personnel.

Si l’exception est mal pointée, le membre ne sait plus quand une demande supplémentaire est justifiée ; si la réserve sur les informations détaillées disparaît ou devient ambiguë, la collecte peut paraître plus large qu’elle ne devrait l’être. Le bon numéro rend donc une limite existante lisible.

La suppression de l’ancienne section 6.5.4.2 complétait la réparation. Cette section organisait au niveau d’AFRINIC la documentation et l’examen de plusieurs /48 destinés à un seul site d’extrémité. La proposition la marquait pour suppression. L’avis d’exécution du 29 novembre 2018 confirme que l’ancienne section fut retirée dans le CPM 1.3 et que l’ancienne section suivante reprit sa place dans la numérotation. Ce geste réduisait une procédure générale devenue incompatible avec l’approche fondée sur le besoin.

Il retirait aussi une occasion de demander des pièces de manière routinière lorsque la taille devait plutôt être expliquée dans son contexte opérationnel. Rien dans le dossier ne démontre cependant combien de dossiers avaient effectivement subi cet examen, ni que son retrait ait produit un résultat mesurable.

La section 6.8, consacrée à l’espace indépendant du fournisseur, recevait une introduction raccourcie. Il faut délimiter soigneusement ce point. V6-001 ne refondait pas l’architecture complète d’éligibilité au PI ; une proposition voisine, V6-004, portait la question plus large de cette mise à jour. De même, V6-002 désignait une proposition distincte sur les sous-attributions IPv6. Le texte étudié ici porte le numéro prouvé AFPUB-2018-V6-001-DRAFT01. La confusion de catalogue qui lui avait parfois attribué V6-002 doit être corrigée, mais elle ne mérite pas de devenir un récit parallèle.

L’enjeu est justement de savoir lire les identifiants, les sections et les objets sans fusionner plusieurs délibérations.

Pris ensemble, les changements formaient donc un delta complet : terminologie ISP remplacée par LIR ; ancienne référence remplacée ; conseil du /128 retiré ; choix de taille rattaché au besoin ; /48, persistance et /64 point à point replacés dans un cadre de pratique ; utilisation recomptée en préfixes ; renvoi de section réparé ; principe de retenue dans la demande d’informations conservé ; ancien examen des multiples /48 supprimé ; introduction PI raccourcie sans refonte du régime voisin. Réduire cette liste à une correction de liens serait inexact.

La présenter comme une révolution des droits contractuels ou des décisions d’allocation le serait tout autant. C’était une révision étroite, mais son étroitesse n’annulait pas son contenu.

Le parcours public du projet apporte une autre couche de précision. La page officielle attribue le texte à Jordi Palet Martinez, inscrit une soumission au 11 mars 2018 et note sa publication initiale sur la liste rpd le 14 mars. Le 9 mai, lors d’AFRINIC-28, l’auteur indiqua que la proposition n’affectait ni l’émission des ressources ni les informations de justification. Le personnel déclara qu’elle pouvait être mise en œuvre telle quelle sans impact opérationnel pour AFRINIC, puis l’issue annoncée par la coprésidence la dirigea vers le Last Call.

Le CPM 1.3 consigna les modifications au 1er novembre et l’annonce du 29 novembre les présenta comme mises en œuvre. Ces éléments décrivent une chaîne privée de révision ; ils ne constituent ni une loi, ni un consentement territorial.

Une incertitude documentaire demeure. La page archivée de la proposition affiche encore un statut correspondant à une discussion en cours, alors que les comptes rendus ultérieurs et l’avis d’exécution établissent son passage au Last Call puis son intégration au manuel. Cela montre pourquoi un seul champ de statut ne suffit pas à raconter le cycle de vie d’un texte. Le dossier ne contient pas le registre complet des messages du Last Call, le procès-verbal précis de la ratification par le conseil ni sa date exacte. Il serait donc injustifié de remplir ces blancs par déduction.

La chronologie sûre est celle que les documents disponibles permettent de recouper ; les maillons absents doivent rester signalés comme tels.

La forme de la proposition mérite enfin attention. Le projet exposait l’ancien et le nouveau texte de façon visible. Le lecteur pouvait examiner la différence, identifier une suppression, vérifier un renvoi et demander si un changement présenté comme éditorial modifiait réellement une charge de justification. Cette présentation n’est pas seulement confortable. Elle distribue la capacité de contrôle : le membre n’est pas condamné à comparer deux éditions consolidées ligne par ligne, et le personnel ne peut pas s’appuyer sur une modification invisible.

Une révision silencieuse aurait pu produire un manuel techniquement meilleur tout en affaiblissant la preuve de ce qui avait été décidé. La qualité du résultat et la traçabilité du geste sont deux obligations distinctes.

Ce premier niveau livre ainsi un constat sans grandiloquence. Une référence obsolète, une mesure d’utilisation incohérente, un renvoi erroné et une procédure vieillie pouvaient infléchir des choix sans jamais prendre la forme d’une décision spectaculaire. Le risque institutionnel se loge souvent dans cette matière grise : ce que le formulaire présuppose, ce que la section permet de demander, ce que le membre croit devoir justifier. Réparer ces éléments est une fonction légitime de tenue de registre, parce qu’un registre exact dépend aussi de règles d’interface exactes. Mais cette légitimité reste strictement fonctionnelle.

Elle ne confère à AFRINIC aucun pouvoir au-delà de la coordination nécessaire à l’unicité, à la fiabilité des enregistrements et à la continuité opérationnelle.