Résumé

  • En octobre 2020, ARIN et APNIC ont jugé incompatible l’obligation faite à la source de respecter les règles du registre destinataire ; RIPE NCC a rejeté un parcours qui commençait auprès de ce même registre destinataire ; LACNIC, sans exiger la réciprocité, a néanmoins relevé les deux défauts.
  • Le texte ici examiné est AFPUB-2019-V4-003-DRAFT02, version 2.0 soumise le 13 août 2020. La date du 8 octobre 2021 appartient à AFPUB-2020-GEN-006-DRAFT02, une proposition distincte, et ne doit jamais être rattachée à Draft 2.
  • Draft 2 a été proposé, débattu, évalué puis archivé. Un état de consensus approximatif conditionnel et de dernier appel n’équivalait ni à une adoption dans le CPM, ni à une ratification, ni à une mise en œuvre.
  • La portabilité inter-RIR fonctionne comme un dispositif à deux clés : le registre de départ doit pouvoir authentifier la source, le registre d’arrivée doit pouvoir qualifier le destinataire, et leurs règles doivent produire une seule modification autoritative des enregistrements et services dépendants.
  • Une issue robuste aurait pris la forme d’un certificat de compatibilité versionné : texte immuable, sens du transfert, type et statut de ressource, responsabilités d’authentification, point d’entrée, messages, bascule atomique, retour arrière, versions des règles homologues et confirmations datées.

L3 — Quatre raccords qui ne s’alignaient pas

La scène décisive n’est pas une salle où une direction choisit d’ouvrir ou de fermer un marché. C’est un tableau de compatibilité. Sur une colonne figure AFPUB-2019-V4-003-DRAFT02; en face, quatre registres Internet régionaux répondent à une question étroite : le parcours de transfert décrit par ce texte peut-il s’emboîter dans leurs propres règles et leurs pratiques ? ARIN et APNIC butent sur la même phrase. RIPE NCC bute sur le point de départ de la demande. LACNIC, bien qu’il ne fasse pas de la réciprocité une condition, retrouve les deux anomalies. La voie paraît ouverte sur le document d’AFRINIC, mais chacun des quatre raccords extérieurs laisse apparaître un décalage.

Cette image restitue mieux le problème que le vocabulaire de l’autorisation. Dans un transfert entre deux registres, la difficulté n’est pas de savoir si un responsable d’AFRINIC veut bien faire une exception. Il faut savoir si les deux systèmes peuvent reconnaître les mêmes parties, vérifier les mêmes éléments au bon endroit, accepter le même sens de mouvement et accomplir un passage sans produire deux vérités concurrentes. Une phrase adoptée d’un seul côté ne suffit pas. Une bonne intention ne suffit pas.

Même un accord privé entre un cédant et un destinataire ne suffit pas si les deux registres auxquels incombe la tenue des enregistrements ne peuvent pas exécuter la même séquence.

Il faut commencer par corriger le repère temporel, car toute analyse de compatibilité dépend de la version exacte examinée. La proposition est intitulée Resource Transfer Policy, porte l’identifiant AFPUB-2019-V4-003-DRAFT02, correspond à la version 2.0 et a été soumise le 13 août 2020. Elle visait une modification de la section 5.7 du Consolidated Policy Manual. Le 8 octobre 2021 est la date d’un autre texte, AFPUB-2020-GEN-006-DRAFT02. Associer cette date plus tardive à l’identifiant de 2019 reviendrait à fabriquer un objet composite qui n’a jamais existé : le numéro d’une lignée, le calendrier d’une autre, puis éventuellement le statut encore ultérieur de la seconde. Ici, la correction n’est pas une minutie bibliographique. Sans elle, on ne sait plus quelles clauses les registres homologues ont effectivement évaluées.

Le registre public actuel qualifie Draft 2 d’archivé. Ce mot décrit l’état d’un dossier ; il ne prouve pas que son contenu a été adopté dans le CPM, ratifié par le conseil d’administration ou déployé comme règle opérationnelle. Le texte a été soumis, discuté et évalué. Il a été présenté à AFRINIC-32 le 17 septembre 2020. Le 21 septembre, un résumé des coprésidents a annoncé un consensus approximatif conditionnel et un dernier appel, tout en signalant une préoccupation de réciprocité liée à ARIN et en demandant des amendements. Ce moment appartenait à un processus de discussion. Il ne transformait pas les parcours décrits en transferts exécutables. Draft 3 a suivi le même jour, mais son contenu n’est pas celui de la présente analyse. Quant à la ratification annoncée le 4 février 2026, elle concernait AFPUB-2020-GEN-006-DRAFT03, dans la lignée distincte déjà mentionnée. Aucun de ces événements ne peut être projeté rétrospectivement sur Draft 2.

Le projet partait pourtant d’un manque réel. La politique existante ne proposait pas de mécanisme inter-RIR dans les deux sens. Dans un environnement où les ressources IPv4 sont rares, l’impossibilité de déplacer leur reconnaissance entre régions peut compliquer une acquisition, une réorganisation ou la continuité d’une activité. Draft 2 annonçait donc des transferts à l’intérieur de la région de service d’AFRINIC, vers celle-ci et depuis celle-ci. Son exposé du problème nommait les adresses IPv4 et les numéros de système autonome. Il cherchait à substituer à la captivité régionale une mobilité encadrée.

Plusieurs choix rendaient cette ambition substantielle. Le texte supprimait les délais d’attente de douze mois qui existaient auparavant. Il ne fixait pas de plafond à la quantité transférée, allouée ou assignée lorsque l’expéditeur et le destinataire étaient parvenus à un accord mutuel, sous réserve des règles en vigueur. Pour une entrée depuis un autre RIR vers AFRINIC, il conservait une évaluation du besoin : AFRINIC devait approuver le besoin IPv4 du destinataire selon les règles alors applicables. Pour une sortie depuis AFRINIC, le transfert devait suivre la politique du RIR destinataire.

Les ressources IPv4 historiques transférées cessaient d’être considérées comme historiques. Ce sont des choix qui touchent l’éligibilité, la quantité, le statut et les obligations des parties ; ils ne sont pas de simples formulations décoratives.

Deux instructions formaient cependant le cœur du défaut. Premièrement, la source devait être le détenteur actuel des droits sur des ressources IPv4 enregistrées auprès de n’importe quel RIR et se conformer aux politiques du RIR destinataire. Deuxièmement, la partie transférante devait envoyer sa demande au RIR destinataire au moyen d’un modèle standard et d’un accord de transfert officiel. Après approbation, ce RIR devait notifier le registre de départ, la source et le destinataire, puis les ressources seraient transférées.

Pris depuis la seule page d’AFRINIC, ce parcours pouvait sembler complet : une source, un destinataire, un accord, une demande, une approbation et une notification. Pris depuis les deux extrémités, il laissait sans réponse la question la plus élémentaire : qui a la capacité documentaire d’authentifier la source ?

Le personnel d’AFRINIC avait lui-même signalé le problème. Pourquoi demander à une source de se conformer aux règles d’un registre avec lequel elle n’avait aucune relation ? Et comment vérifier qu’elle détenait réellement la ressource si elle s’adressait directement au registre destinataire plutôt qu’au registre qui tenait son inscription ? Une base autoritative n’est pas une formalité interchangeable. Le registre de départ sait quel compte, quel statut de membre, quels documents et quels enregistrements correspondent à la ressource. Le registre d’arrivée peut apprécier l’éligibilité et, le cas échéant, le besoin du destinataire.

Inverser ces responsabilités ne renforce pas le contrôle : cela place une vérification auprès de l’institution la moins bien située pour la réaliser.

La même évaluation interne posait d’autres questions qui révélaient l’incomplétude de l’interface. Le modèle annoncé comme standard était-il réellement accepté dans le monde entier ? Que devait-il se passer lorsque les ressources étaient contestées ? Le texte ne donnait pas de ligne directrice sur ce cas. Le personnel avertissait aussi d’un risque d’abus par allocations répétées.

Il relevait une tension entre les clauses 5.7.4.1 et 5.7.4.2 relatives au destinataire : alors qu’une formulation permettait à toute partie ayant conclu un accord avec l’expéditeur d’être destinataire, la lecture opérationnelle appliquée à la région AFRINIC impliquait une adhésion à AFRINIC et une évaluation du besoin. Enfin, les ASN figuraient dans le résumé du problème mais pas dans les clauses opératoires consacrées à IPv4, une discordance susceptible de créer de la confusion sur le périmètre réel.

Les réponses homologues ont transformé ces interrogations en tests de raccord concrets. ARIN a estimé que la phrase obligeant la source à respecter la politique du RIR destinataire rendait Draft 2 incompatible avec sa politique inter-RIR. Il ne s’agissait pas pour ARIN de recevoir une permission d’AFRINIC ni d’en accorder une. Sa propre règle déterminait le parcours qu’il pouvait exécuter. Une déclaration d’AFRINIC ne pouvait pas faire disparaître cette règle, pas davantage que la direction d’ARIN n’aurait pu réécrire unilatéralement les conditions d’AFRINIC.

APNIC a abouti au même résultat. Son appréciation précisait que Draft 2 et Draft 3 partageaient sur ce point un texte pertinent et n’étaient pas compatibles, notamment parce que la source devait satisfaire aux politiques du registre destinataire. La mention de deux versions ne les confond pas : elle dit que cette formulation précise était encore présente dans les textes examinés. Pour la présente analyse, la conclusion reste strictement attachée à AFPUB-2019-V4-003-DRAFT02. Elle ne permet pas de déduire le sort de versions ultérieures qui auraient pu modifier d’autres éléments.

RIPE NCC a trouvé dans la section 5.7.5 un défaut de séquence. Draft 2 envoyait la partie transférante vers le RIR destinataire pour commencer le processus. La pratique de RIPE débutait auprès du RIR où les ressources étaient alors enregistrées. Le désaccord peut sembler administratif, comme une question de guichet. Il est en réalité probatoire : démarrer auprès du registre de départ permet à celui qui tient l’enregistrement autoritatif de vérifier le contrôle de la ressource avant qu’une autre institution n’organise son accueil. Selon l’évaluation, le parcours de Draft 2 était donc incompatible et non réalisable.

LACNIC offre le cas le plus instructif, car il neutralise l’idée que toute difficulté provenait d’une exigence rigide de réciprocité. LACNIC ne demandait pas cette réciprocité. Il trouvait néanmoins peu sensé d’imposer à la source les règles de l’autre RIR et observait que l’ouverture du dossier auprès du registre destinataire ne correspondait pas aux autres arrangements inter-RIR. Même lorsque la première barrière politique était absente, les responsabilités et la séquence restaient mal alignées. Le problème n’était donc pas seulement une préférence d’ARIN ou une querelle de vocabulaire.

Il touchait la capacité à produire un transfert que les deux côtés puissent reconnaître.

Ces quatre réponses ne constituaient pas un refus universel de la portabilité, encore moins une preuve de mauvaise foi des auteurs. Elles documentaient des incompatibilités attachées à une rédaction et à une date. Elles ne formaient pas non plus un accord bilatéral signé qui aurait détaillé un dispositif de mise en œuvre. L’archive conservée compile des positions de contreparties ; elle ne démontre ni transfert accompli, ni rejet d’une transaction précise, ni panne, ni perte de prix, ni dommage client. L’incertitude doit rester visible. On peut établir que les raccords décrits ne s’alignaient pas.

On ne peut pas inventer l’incident qui aurait résulté de leur utilisation, puisque le dossier ne montre pas que Draft 2 a été mis en œuvre.

Le meilleur argument favorable au projet mérite donc d’être conservé. Ses auteurs travaillaient entre cinq ensembles institutionnels dont les termes, les contrôles et les procédures n’étaient pas identiques. Obtenir des réponses homologues prend du temps. Ils essayaient de résoudre un vrai problème de rareté et de continuité, de permettre un mouvement dans les deux sens, de lever des plafonds quantitatifs et de préserver certaines vérifications du côté de la source et du destinataire. Une erreur de rédaction ou une séquence mal conçue ne prouve ni captation, ni volonté de domination, ni dessein punitif.

Mais cette lecture bienveillante ne rend pas la voie praticable. Elle explique pourquoi il fallait poursuivre le travail d’interopérabilité au lieu de traiter un état interne de discussion comme une preuve de fonctionnement.