Résumé

  • La résolution 202002.552 a ratifié en février 2020 Multihoming Not Required for ASN Draft 4 et Adjusting IPv6 PI dans un même acte interne. Ce regroupement n’est pas en soi un défaut : il pouvait réduire les répétitions et permettre une entrée en service coordonnée.
  • Les deux instruments devaient néanmoins garder des dossiers séparés. L’évaluation du premier projet ASN, les versions qui lui ont succédé et les modifications propres à l’éligibilité ASN ne prouvent ni l’examen ni la mise en œuvre de la clarification IPv6 PI, et la réciproque est tout aussi vraie.
  • La date commune du 29 mai 2020 forme une frontière de mise en œuvre, non une preuve indifférenciée. Pour comprendre ce qui a réellement changé, il faut relier chaque texte final à ses objections, à son responsable opérationnel, à ses formulaires ou sections du manuel et à une vérification après l’entrée en service.
  • AFRINIC demeure, dans cet épisode, un teneur de registre et coordinateur technique privé. La ratification autorise l’administration de règles de service ; elle ne crée aucun pouvoir souverain, réglementaire, policier, de poursuite, punitif, de confiscation ou juridictionnel.

L3 — Une résolution, deux dossiers techniques

Deux portes ont bougé au même instant institutionnel

Pour un opérateur, la difficulté ne commence pas par une théorie du Conseil d’administration. Elle commence par une question concrète adressée au guichet d’un registre : quelles preuves faut-il fournir pour obtenir ou conserver la coordination technique dont son réseau a besoin ? En février 2020, la réponse a changé sur deux terrains différents. Un réseau qui justifiait un besoin d’identité de routage publique n’avait plus à traiter l’achat d’un second lien physique comme une condition absolue à l’accès à un ASN public.

Un utilisateur d’espace IPv6 PI pouvait, de son côté, avoir un usage légitime qui ne se manifestait pas par une annonce dans la table mondiale, notamment sur un LAN de peering d’IXP ou dans un réseau privé. Ces deux changements pouvaient réduire des frictions réelles. Ils ne procédaient pas du même raisonnement.

Le registre public du Conseil d’administration place la résolution 202002.552 en février 2020 et lui associe deux instruments : Multihoming Not Required for ASN Draft 4 et Adjusting IPv6 PI. Le dossier disponible ne permet pas d’établir le jour exact du vote, son décompte, les motifs individuels des administrateurs ou le contenu des documents soumis au Conseil. Il serait donc faux de préciser une date de jour, de reconstruire une négociation ou d’attribuer une intention particulière à ses membres. Ce que la ligne publique prouve est plus limité et plus solide : un seul acte interne a ratifié deux règles de service distinctes.

Cette distinction entre acte commun et preuves séparées est le cœur de l’affaire. Une décision peut être commune pour des raisons de calendrier, de publication ou de coordination des équipes. Mais le raccourci administratif ne change pas la nature de ce qui est décidé. La règle ASN portait sur le critère utilisé pour reconnaître le besoin d’une identité de routage mondialement unique. La clarification IPv6 PI portait sur le rapport entre usage, annonce et risque de reprise de l’allocation. Le premier dossier devait répondre à une question de topologie et d’identité publique.

Le second devait protéger la continuité d’usages qui, par définition, peuvent rester invisibles dans le routage mondial. Mettre les deux noms sur une même ligne ne crée aucune preuve commune de leur qualité technique.

Il faut donc lire la résolution comme une couverture posée sur deux dossiers, et non comme un dossier unique. Sous cette couverture, chaque instrument devait conserver son identifiant, sa version exacte, sa question technique, les objections qu’il avait suscitées, les réponses apportées, les réserves restées ouvertes et la trace des changements demandés aux équipes. La résolution pouvait conclure une étape institutionnelle. Elle ne pouvait pas effacer ce qui s’était passé avant elle ni remplacer ce qui devait être démontré après elle.

La piste ASN : de la multiconnexion physique à l’identité publique

La première piste commence le 27 février 2019 avec la soumission de la première version de Multihoming Not Required for ASN, annoncée séparément le 7 mars. Son enjeu était précis : fallait-il continuer de traiter la présence de plusieurs interconnexions physiques comme le passage obligatoire pour reconnaître qu’un réseau avait besoin d’un ASN public ? La réforme ne supprimait ni les ASN privés, ni tout examen d’éligibilité. Elle cherchait à distinguer deux choses trop facilement confondues : acheter une deuxième connectivité et démontrer qu’une coordination mondiale exige une identité publique unique.

L’évaluation du personnel datée du 8 avril 2019 fournit une pièce importante, mais strictement limitée, de cette histoire. Elle concernait la première version. Elle relevait un conflit avec la section 5.1 du RFC 1930, examinait quatre cas comprenant des situations à un seul pair ou des configurations envisagées, demandait des ajustements de terminologie, abordait la consommation de l’espace de noms et recensait des travaux nécessaires sur la documentation opérationnelle. Elle indiquait aussi l’absence de commentaire du conseiller juridique dans ce cadre.

Cette évaluation montre qu’un examen technique concret a eu lieu : on ne s’est pas contenté d’un slogan favorable ou hostile au multihoming.

Mais précisément parce que cette pièce est utile, il faut lui assigner la bonne portée. Elle ne constitue pas l’examen complet du texte finalement ratifié. Des Drafts 2, 3 et 4 ont suivi, respectivement les 10 avril, 3 novembre et 25 novembre 2019. L’objet de la résolution 202002.552 était Draft 4, pas Draft 1. On peut donc utiliser l’évaluation d’avril pour établir l’existence d’une objection, de scénarios testés et d’une liste de conséquences opérationnelles dans la lignée du projet.

On ne peut pas présenter chaque formulation de Draft 1 comme si elle se retrouvait à l’identique dans Draft 4, ni prétendre que la première évaluation clôt à elle seule toutes les questions portant sur la version finale.

La discipline de version importe pour l’opérateur autant que pour l’historien. Un formulaire, une liste de contrôle et une consigne au personnel peuvent reposer sur un mot qui a changé entre deux versions. Si le dossier public ne relie pas clairement l’objection initiale, les révisions et le texte gelé qui est soumis à ratification, un demandeur ne sait pas si le problème reconnu a été corrigé, contourné ou simplement déplacé. La bonne question n’est donc pas seulement : « y a-t-il eu un débat ? » Elle est : « quelle version a reçu quelle objection, quelle réponse et quel effet opérationnel ? »

Le résultat de la réforme ASN peut être décrit sans lui prêter une portée qu’elle n’a pas. Il s’agissait de permettre l’examen du besoin d’un ASN public à partir de la nécessité d’une identité de routage mondialement coordonnée, sans faire de l’achat d’un second fournisseur physique une condition absolue. Les usages purement locaux pouvaient continuer à relever d’ASN privés. Le registre pouvait examiner les faits utiles à l’unicité et à la coordination. Il ne gagnait pas le droit de prescrire une architecture, d’imposer une redondance commerciale ou de juger moralement le choix de fournisseurs d’un réseau.

La suite publique de cette piste associe Draft 4 au statut mis en œuvre et place la frontière d’entrée en service au 29 mai 2020, dans le même temps que la version 1.5 du manuel consolidé. Cela donne deux points d’ancrage : le texte final identifié par sa version, puis une date de changement du service. Entre les deux, une preuve complète devrait montrer les modifications du formulaire de demande ASN, de la liste de contrôle, de la documentation et des consignes du personnel. Ce sont ces éléments qui transforment une ratification en règle réellement administrée.

Le simple mot « mis en œuvre » reste trop large s’il n’est pas rapporté aux opérations propres à l’ASN.

La piste IPv6 PI : usage légitime ne signifie pas annonce mondiale

La seconde piste ne naît pas du débat ASN. Elle plonge ses racines dans l’IPv6 PI Update de 2018, connu sous l’identifiant V6-004. Ce texte avait ouvert une voie pour des utilisateurs finaux. Lors de la réunion AFRINIC-28, le 6 juin 2018, les participants avaient discuté de la condition d’annonce dans les douze mois, du suivi du routage et d’autres aspects techniques. La résolution 201808.449 l’avait ratifié le 8 août 2018 et avait demandé sa mise en œuvre. Le 29 novembre, AFRINIC avait annoncé une mise en œuvre partielle, en précisant que certains éléments d’automatisation restaient à achever.

Cette chronologie de 2018 ne prouve pas le changement de 2020. Elle explique pourquoi une clarification ultérieure était devenue une question opérationnelle plutôt qu’un exercice abstrait. Le texte antérieur conservait une phrase susceptible de lier l’absence d’annonce après douze mois à une logique de reprise de l’allocation. Or l’observation d’une route mondiale n’est pas une mesure universelle de l’usage. Un préfixe destiné au LAN de peering d’un point d’échange Internet peut remplir sa fonction sans être annoncé globalement. Il en va de même d’un réseau privé.

Dans ces cas, le silence de la table mondiale ne prouve ni l’abandon, ni l’inutilité, ni l’absence d’activité technique.

Adjusting IPv6 PI a identifié cette discordance. Son problème était donc différent de celui de l’ASN : il ne s’agissait pas de remplacer une exigence de multiconnexion par un examen du besoin d’identité publique, mais d’empêcher qu’un indicateur visible — l’annonce mondiale — soit utilisé comme substitut trop large de l’usage réel. La conséquence pour l’opérateur était aussi différente. Une mauvaise lecture du critère ASN pouvait entretenir un coût de topologie ou un délai discrétionnaire. Une mauvaise lecture de la règle IPv6 PI pouvait faire planer sur un usage non annoncé mais valable un risque de remise en cause de continuité.

Le dossier local appelle ici une prudence de version particulière. Le registre de sélection identifie Adjusting IPv6 PI Draft 1 parmi les instruments ratifiés. La page substantielle conservée pour examiner le problème et sa lignée est celle de 2019-v6-001 Draft 2. Elle atteste la clarification, ses exemples d’usages non annoncés et une étape plus tardive de son évolution. Elle ne permet pas de reporter silencieusement chaque mot de Draft 2 dans Draft 1. Lorsqu’on décrit la décision commune, il est donc plus exact de parler de l’instrument Adjusting IPv6 PI. Lorsqu’on s’appuie sur une formulation détaillée de la page conservée, il faut préciser qu’elle appartient à Draft 2 et ne pas la faire passer pour la rédaction exacte de Draft 1.

Cette précaution n’est pas une subtilité bibliographique. Si une phrase relative à la reprise de l’allocation, à l’annonce ou à la qualification d’un usage évolue d’une version à l’autre, cette évolution peut modifier la pratique du registre. La piste IPv6 devait donc posséder son propre dossier de révision, ses propres discussions et son propre raccordement au manuel. L’évaluation du 8 avril sur l’ASN ne dit rien de l’adéquation d’un LAN d’IXP à la règle IPv6. Les scénarios portant sur un réseau à un seul pair ne prouvent rien sur l’usage d’un préfixe dans un réseau privé.

Deux problèmes peuvent être ratifiés ensemble sans partager un seul test technique.

Le 29 mai 2020 constitue également la frontière de mise en œuvre attestée pour cette clarification dans les éléments de cycle de vie et le manuel consolidé. Mais la date commune ne suffit pas davantage ici. La preuve propre à IPv6 devrait montrer quelle phrase du manuel a été corrigée, comment les équipes distinguent non-annonce et non-usage, et par quel contrôle on peut vérifier que l’ancien raccourci ne continue pas d’influencer l’examen. Le statut ASN ne peut pas répondre à ces questions. La mise en œuvre du volet IPv6 doit être lue dans le cycle de vie IPv6 et dans la modification correspondante du texte du manuel.

Le meilleur argument en faveur du regroupement

Il serait facile, mais injuste, de considérer qu’une résolution portant deux noms est nécessairement opaque ou irrégulière. Deux propositions mûres peuvent arriver ensemble devant un conseil après avoir suivi des chemins indépendants. Les ratifier dans un seul acte peut réduire les répétitions, éviter un délai artificiel, synchroniser la formation du personnel et permettre la mise à jour cohérente d’un manuel. Une même date d’entrée en service peut aussi éviter que demandeurs et agents travaillent pendant plusieurs semaines avec des règles partiellement décalées.

Rien dans le dossier n’établit que le regroupement était illégal, qu’un des deux textes aurait échappé à l’examen, ou que le Conseil aurait échangé l’acceptation de l’un contre celle de l’autre.

Cet argument favorable est le plus solide parce qu’il ne demande pas de confondre les instruments. Il dit seulement que l’acte institutionnel peut être plus court que l’histoire technique qui le précède. Deux résolutions séparées auraient pu ajouter de la cérémonie sans ajouter une seule information utile. Si les versions finales sont correctement identifiées, si chaque examen est accessible et si les changements opérationnels sont traçables, une signature commune ne porte aucun préjudice intrinsèque à la compréhension.

La réponse constructive n’est donc pas d’exiger deux numéros de résolution. Elle est d’exiger un tableau à deux lignes annexé à l’acte commun. La ligne ASN devrait nommer Draft 4, résumer la question de l’identité publique, renvoyer aux objections et révisions de cette lignée, identifier les formulaires et la section ASN du manuel, désigner le responsable de l’entrée en service et énoncer le contrôle postérieur. La ligne IPv6 devrait identifier sans ambiguïté la version gelée de Adjusting IPv6 PI, résumer le défaut lié à la non-annonce, renvoyer aux échanges IPv6, montrer la phrase corrigée et préciser comment l’application de la règle sera vérifiée.

Ainsi conçu, le regroupement économise la répétition tout en préservant la preuve. La résolution commune se situe au-dessus des deux lignes : elle les autorise simultanément. Elle ne s’insère pas à leur place. Cette architecture documentaire rend la décision plus intelligible pour le demandeur, le membre du personnel, le futur administrateur et l’observateur extérieur. Elle permet aussi de corriger une erreur dans une piste sans contaminer l’autre.

Si une ambiguïté apparaît plus tard dans l’examen des ASN, personne ne devrait avoir à relire toute l’histoire IPv6 pour déterminer ce qui a changé ; si une difficulté touche un usage IPv6 privé, l’évaluation RFC 1930 n’apporte aucune réponse.

La leçon de niveau L3 est donc simple : la résolution 202002.552 a pu réunir le moment de ratification, mais elle n’a jamais pu fusionner les objets techniques. Une identité publique de routage et un préfixe PI non annoncé ne sont pas deux variantes du même problème. Chacun appelle des faits, une lecture et une preuve d’entrée en service qui lui sont propres.