Résumé

  • La feuille de route 2026 d’APNIC prévoit au troisième trimestre d’automatiser l’alignement entre gestion des routes, détention des ressources, Whois et RPKI après transferts, désallocations et changements de système.
  • Ces surfaces ne disent pas la même chose : la détention fonde une autorité de registre, l’objet IRR décrit une politique, la ROA autorise une origine, tandis que BGP montre une annonce observée et soumise aux choix locaux.
  • La fiche publique ne précise ni la préséance en cas de conflit, ni la limite transactionnelle, ni le traitement d’un succès partiel, ni la preuve de notification et de retour arrière. Ce silence public ne permet pas d’affirmer qu’APNIC ne possède aucun dessin interne.
  • L’automatisation gagnerait en légitimité avec une matrice de décision par type de registre et un reçu de tâche conservant l’état antérieur, l’autorité, le motif, les étapes effectuées et la dernière position sûre.

Le jour où « aligner » devient un verbe de pouvoir

Une équipe de produit peut parler d’alignement comme d’une opération ménagère : supprimer les doublons, réconcilier des colonnes, rendre l’écran plus net. La fiche « Route management alignment » de la feuille de route d’APNIC semble d’abord appartenir à ce registre. Classée sous l’équipe Registry, annoncée pour le troisième trimestre 2026, elle mentionne ARMS, RPKI et Whois. Elle promet de réduire un rapprochement manuel fastidieux et sujet aux erreurs après les transferts, les désallocations et les modifications de systèmes.

L’objectif est raisonnable. Les opérateurs n’ont aucun intérêt à recopier plusieurs fois la même intention dans des interfaces différentes. Une erreur de saisie au moment d’un transfert peut être coûteuse. Mais la proposition assemble des objets qui ne sont semblables qu’en apparence. Lorsqu’ils divergent, le logiciel doit choisir : conserver, supprimer, différer, remplacer ou demander une intervention. Ce choix détermine qui peut parler pour un préfixe et quelle déclaration atteindra les réseaux qui s’appuient sur elle.

La fiche structurée est bien datée de 2026, avec une cible T3 et un résumé précis. Son changelog est vide. Elle ne décrit pas publiquement la priorité entre les sources, le périmètre d’une transaction, l’état d’un traitement partiellement réussi, la marche arrière, l’avis envoyé au membre, ni la frontière avec un NIR ou un IRR extérieur. Il serait abusif d’en conclure que ces règles n’existent pas dans les travaux internes. On peut seulement constater qu’elles ne sont pas encore attachées à la promesse publique.

Or une promesse d’alignement est incomplète sans la grammaire des désaccords.

La détention n’est pas une annonce

La première surface est la détention d’une ressource. Elle répond à une question institutionnelle : quel compte ou quelle organisation APNIC reconnaît-il comme titulaire d’une plage d’adresses ou d’un numéro de système autonome ? Cette reconnaissance donne accès à des actes de gestion. Elle ne précise pas forcément l’AS qui doit annoncer chaque préfixe à cet instant.

La seconde surface est l’Internet Routing Registry. APNIC présente l’IRR comme un ensemble distribué de bases dans lesquelles les opérateurs publient leurs politiques et annonces de routage. Les objets de route peuvent alimenter des outils produisant des filtres. Le RFC 2725 exige, lors de leur création, une autorisation portant à la fois sur le préfixe et sur l’AS d’origine. Il prévoit aussi les réalités que les tableaux trop simples effacent : plusieurs origines pour un même préfixe, des sous-préfixes qui se chevauchent, le changement de fournisseur et la période de grâce d’une renumérotation.

Une divergence entre deux objets de route ne désigne donc pas mécaniquement un faux enregistrement. Elle peut représenter un multihoming volontaire, une transition ou des politiques distinctes pour des préfixes plus spécifiques. L’IRR formalise une intention utilisable pour construire une politique ; il ne signe pas une photographie exhaustive de l’Internet.

La troisième surface est RPKI. Le RFC 9582 définit la ROA comme un objet signé par lequel le détenteur d’espace d’adressage autorise un AS à être origine de routes pour certains préfixes. Plusieurs AS autorisés appellent plusieurs ROA. L’objet établit une permission dans une chaîne de certificats. Il ne prouve ni qu’une annonce existe maintenant, ni qu’un routeur l’acceptera, ni que le trafic aboutit.

La quatrième surface, BGP, n’est pas nommée comme produit à synchroniser dans la fiche, mais elle reste nécessaire pour comprendre le résultat. Une route reçue comporte un préfixe, une origine et un chemin. Le RFC 6483 explique comment comparer cette observation aux ROA valides afin d’obtenir un état Valid, Invalid ou Unknown. Ce même texte laisse aux politiques locales le sort d’une route Unknown ou Invalid. Le registre fournit l’autorisation ; chaque réseau conserve sa décision d’exploitation.

Enfin, les horloges diffèrent. Le RFC 6483 souligne qu’une route et les objets RPKI associés ne se propagent pas nécessairement au même rythme. Une autorisation de secours peut être préparée avant toute annonce. Une route peut apparaître avant qu’un cache local ait reçu la nouvelle ROA. Un objet IRR peut rester utile pendant une migration contrôlée. Ce ne sont pas quatre copies imparfaites d’un même fait, mais quatre réponses à des questions différentes.

Un ancien manuel montre pourquoi le conflit doit rester visible

Le guide APNIC de gestion des routes publié en 2017 fournit un précédent révélateur. Son âge interdit d’en faire le contrat du projet 2026. Il montre néanmoins que l’organisation distinguait déjà l’état souhaité dans MyAPNIC de l’objet effectivement publié dans Whois.

Dans ce guide, la « route » MyAPNIC est un modèle permettant de créer un objet de route Whois. Les deux peuvent exister séparément. Un modèle peut ne pas avoir encore d’objet public ; un objet Whois peut ne pas être administré par le modèle. Lorsque quelqu’un modifie l’objet Whois par un autre canal, le modèle MyAPNIC ne s’adapte pas silencieusement. L’outil signale un conflit. L’utilisateur choisit d’accepter la modification ou de rétablir l’objet conformément au modèle.

Ce mécanisme a une vertu qu’un rapprochement purement automatique pourrait perdre : il transforme la différence en événement intelligible. L’opérateur voit qu’une autre voie a produit une nouvelle valeur. Le système n’efface pas immédiatement l’une au profit de l’autre.

Le guide décrit aussi un statut pending pendant certaines synchronisations multiples. Il permet à l’utilisateur disposant des droits nécessaires de demander des ROA correspondantes. Dans un cas de suppression, désactiver une sous-route gérée dont la ROA est activée entraîne également la suppression de cette ROA. Une interface apparemment unique cachait donc déjà plusieurs états, des autorisations différentes, une exécution en arrière-plan et des couplages optionnels.

Le nouveau chantier peut parfaitement adopter une autre architecture. Ce précédent sert seulement à poser la bonne question : lorsqu’une modification légitime arrive de l’extérieur, le système 2026 conservera-t-il la trace du conflit et du choix, ou ne laissera-t-il derrière lui qu’un enregistrement désormais « propre » ?

La transaction qui s’arrête à la frontière d’un système

L’annonce de l’API Registry par APNIC en octobre 2024 complète ce tableau. L’API permet de consulter les délégations et de gérer les enregistrements Whois, le DNS inverse, les ROA et les objets de route. APNIC propose l’exemple d’une annonce BGP pour laquelle un membre crée automatiquement une ROA et un objet de route, sans répéter l’opération manuellement dans MyAPNIC.

Le texte contient une réserve décisive. Les opérations de gestion de route peuvent être soumises en lot et ces lots prennent effet « transactionally where possible ». Toutes les mises à jour passent par des objets de tâche asynchrones : la requête rend un lien, le client suit l’état, puis consulte le résultat.

« Là où c’est possible » n’est pas une faiblesse de rédaction. C’est la reconnaissance d’une limite réelle. Une transaction de base de données peut couvrir plusieurs écritures dans le même stockage. Elle ne peut pas, à elle seule, forcer un cache RPKI indépendant à se rafraîchir, un IRR tiers à accepter un objet, un autre RIR à finir un transfert ou un réseau à reconstruire ses filtres. Une interface commune ne transforme pas plusieurs domaines d’autorité en un seul commit.

Il faut donc publier le complément de la phrase : où la transaction s’arrête-t-elle ? Si l’objet Whois est créé mais que la ROA prévue ne l’est pas, un statut Failed sans détail ne suffit pas. Une nouvelle tentative peut être dangereuse si elle rejoue aveuglément l’étape déjà effectuée. Le résultat doit montrer les sous-opérations réussies, l’étape fautive, la dernière position cohérente et l’éventuelle action compensatoire.

Rien ici ne démontre qu’une tâche APNIC actuelle échoue de cette manière. L’intérêt du vocabulaire de 2024 est ailleurs : APNIC possède déjà les notions publiques de lot, de transaction conditionnelle, de tâche asynchrone et de résultat. Le projet d’alignement peut s’en servir pour rendre ses choix lisibles.

Le transfert, test décisif de la préséance

Les conditions de transfert d’APNIC donnent au mot alignement sa conséquence la plus nette. Lorsqu’un transfert inter-RIR sortant est achevé, l’entité source n’a plus de droits sur les ressources et celles-ci sont enregistrées au nom du destinataire. APNIC indique aussi que les sous-attributions, objets de route et objets de domaine associés sont supprimés de sa base Whois.

Cette règle concerne explicitement les objets Whois cités. Le passage ne dit pas ce qu’il advient des ROA. Il ne faut pas inventer une suppression RPKI à partir de ce silence. Il faut au contraire voir dans cette limite la nécessité d’un ordre documenté.

Le changement de détention répond à la question de l’autorité. La suppression de l’objet de route répond à une règle du registre source. La création d’une nouvelle ROA dépend de la partie désormais autorisée et de l’origine voulue. La continuité opérationnelle dépend encore de la publication, de la propagation, des filtres et de BGP. Ces étapes sont corrélées sans être interchangeables.

Prenons trois scénarios analytiques. Dans le premier, le destinataire conserve le même AS d’origine : la détention change, mais l’intention de routage peut rester identique. Dans le deuxième, une nouvelle origine doit être préparée avant l’abandon de l’ancienne pour réduire le risque d’une route Invalid. Dans le troisième, le Whois du registre source est nettoyé avant que le registre destinataire ou ses caches ne rendent la nouvelle situation visible. Aucun scénario n’est présenté comme un incident observé chez APNIC. Tous montrent que le badge « aligné » doit contenir plus qu’un booléen.

Supprimer tout au premier instant produit une coupure évitable. Conserver indéfiniment l’ancien état laisse une autorité périmée. Copier l’annonce BGP actuelle dans une ROA transforme une observation en permission. L’ordre sûr dépend du type de transfert, du titulaire, de l’origine prévue et de la capacité de revenir au dernier état sain.

Les désaccords qu’un algorithme doit savoir respecter

Le multihoming est le premier. Plusieurs origines peuvent être intentionnelles dans l’IRR comme dans RPKI. Une règle fondée sur l’unicité peut rendre les bases plus cohérentes tout en supprimant une redondance légitime. La priorité ne doit donc pas porter seulement sur une valeur ; elle doit comprendre la cardinalité autorisée et le motif opérationnel.

Le décalage temporel est le deuxième. Un changement peut être committed dans le registre, publié dans un dépôt, puis observé plus tard par les validateurs. Chaque état a sa propre preuve. Un moteur qui confond « écrit », « publié » et « largement visible » risque de relancer, d’annuler ou de signaler à tort.

La modification effectuée par un autre canal est le troisième. L’ancien outil demandait si l’utilisateur voulait accepter ou rétablir l’objet Whois. Le système à venir devra déterminer si l’auteur était autorisé, si la modification représente une intention plus récente, si elle implique réellement RPKI et si l’urgence justifie une action automatique. Proclamer le modèle MyAPNIC supérieur dans tous les cas écraserait une correction légitime ; importer toute modification extérieure ferait disparaître la gouvernance du modèle.

La désallocation est un quatrième cas dont la fiche ne donne pas les détails. La fin de l’autorité sur une ressource peut justifier des retraits, mais la séquence, les délais et les recours ne se déduisent pas du seul mot. Les ressources gérées avec un NIR ou des objets maintenus dans un IRR extérieur ajoutent des frontières qu’APNIC ne peut pas résoudre par une écriture locale.

Une matrice plutôt qu’une « source unique de vérité »

Le slogan de la source unique de vérité est attirant parce qu’il évite de nommer les responsabilités. Ici, il pose la mauvaise question. La détention doit être source d’autorité pour savoir qui peut agir. Une demande authentifiée peut être source d’intention. L’objet IRR est une déclaration publiée et autorisée selon ses propres règles. La ROA est la preuve cryptographique d’une permission. BGP est une observation. Aucun de ces rôles ne devrait absorber tous les autres.

Une matrice publique pourrait tenir sur une page. En ligne : transfert, désallocation, édition directe Whois, modification du modèle de route, changement de ROA, migration de système. En colonne : acteur habilité, état déclencheur, registres susceptibles de changer, divergences autorisées, étapes automatiques, motif imposant une revue et durée de contestation.

Une autre colonne définirait l’atomicité. Quelles écritures forment réellement une transaction ? Quelles publications sont asynchrones ? Quelles surfaces restent hors du contrôle d’APNIC ? Quelle est la conduite à tenir si une seule étape aboutit ? La promesse ne serait pas « tout change à la même microseconde », mais « chaque frontière est nommée et chaque résultat est récupérable ».

Enfin, la matrice distinguerait le nettoyage d’un ancien droit de la création d’une nouvelle intention. Un transfert peut retirer au cédant son pouvoir de modifier sans autoriser le registre à deviner l’origine choisie par le destinataire. Cette séparation empêche l’automatisation de produire une politique de routage par simple extrapolation administrative.

Le reçu d’alignement

Chaque tâche importante devrait produire un reçu versionné. Il commencerait par l’identifiant de l’événement, le déclencheur et l’heure, puis par l’instantané de détention utilisé pour vérifier l’autorité du demandeur. Il conserverait l’état avant et après du modèle de route, des objets Whois et des ROA, avec une règle de préséance et un code de motif pour chaque changement.

Le reçu tracerait la frontière transactionnelle : écritures effectuées ensemble, publications encore en attente, vérifications externes et domaines hors contrôle. En cas de résultat partiel, il indiquerait l’étape réussie, l’étape échouée, la dernière position sûre, la condition de nouvelle tentative et l’action compensatoire. Le mot rollback ne devrait pas signifier que l’histoire est effacée ; il devrait signifier que l’état de service revient en arrière tout en gardant la preuve.

Des temps de visibilité séparés compléteraient la tâche : consultation de l’objet Whois, publication RPKI, première observation indépendante de validation. Une observation BGP peut être jointe comme signal, jamais comme ordre de créer une autorisation.

Les frontières inter-RIR, NIR et IRR extérieur seraient des attributs de portée. Les avis envoyés, leur accusé de réception, la voie de revue et le responsable du service seraient enregistrés sans exposer de secret ni de donnée personnelle inutile. Un pointeur historique immuable permettrait ensuite de comprendre une correction ou une contestation.

Ce reçu est une proposition éditoriale, non un engagement déjà annoncé par APNIC. Il est plus modeste qu’un journal public de toutes les opérations internes. Il donne seulement aux personnes concernées de quoi distinguer une concordance réussie, une différence volontaire, un traitement incomplet et une décision contestable.

L’automatisation peut réellement réduire les erreurs et la charge de travail. Elle devient risquée lorsqu’elle rend invisible le jugement qui produit cette simplicité. Avant qu’un système ne désigne le gagnant d’un conflit, APNIC devrait publier les règles du match et conserver la trace du résultat.

Sources