Fragilité de la base de données IRR ARIN

Résumé

La fragilité des bases de données IRR dans la région ARIN est un problème de fragmentation des sources: le même préfixe, ASN d'origine, jeu AS (AS-SET) ou relation de routage peut être représenté différemment selon ARIN, les sources miroirs, les dépôts de type RADb et les bases de données de routage privées.
La question pratique pour le marché n'est pas seulement de savoir si un enregistrement de route unique est valide, mais de savoir quelle source un fournisseur de transit, une plateforme cloud, un serveur de route IXP ou un générateur de filtres choisit de croire en premier.
La frontière d'autorité d'ARIN est importante car les données provenant d'ARIN et liées aux ressources gérées par ARIN ont un poids probatoire différent de celui des données non autorisées ou de tiers qui peuvent encore être consommées par des filtres privés.
Le mirroring et les copies obsolètes créent des survivances cachées: un enregistrement corrigé à un endroit peut continuer à affecter le filtrage ailleurs si une autre source, un miroir ou un chemin de jeu AS pointe toujours vers l'ancienne version.
L'expansion des jeux AS aggrave le problème car les ensembles récursifs peuvent incorporer des membres et des préfixes provenant de plusieurs sources, faisant de l'ordre des sources une politique économique non reconnue.
Les transferts IPv4, l'intégration dans le cloud et la participation aux IXP exigent désormais une diligence concernant les sources IRR, en particulier pour les petits FAI et les opérateurs des Caraïbes qui ne peuvent pas facilement absorber des exceptions manuelles.
Le RPKI améliore l'environnement de preuve, mais il n'élimine pas la fragilité de l'IRR car les filtres privés utilisent encore les données IRR pour la politique de routage, les cônes clients, l'appartenance aux jeux AS et l'admission opérationnelle.

La fragilité provient de sources multiples, pas d'une seule mauvaise entrée

La première erreur est de chercher un seul enregistrement défaillant. Dans une transaction de transfert, un ticket de provisionnement IXP, un examen "apportez votre propre IP" dans le cloud ou un cas d'intégration de transit, le problème se présente souvent comme un désaccord entre les sources. Une base de données indique que le préfixe appartient au nouvel ASN d'origine du titulaire. Une autre reflète encore un ancien fournisseur de transit. Une troisième source contient un enregistrement de route saisi des années auparavant par un ingénieur réseau qui a depuis quitté l'entreprise. Un miroir présente des données qui semblent fraîches parce que la requête a fonctionné aujourd'hui, même si l'enregistrement sous-jacent provient d'un ancien arrangement opérationnel. Un jeu AS s'étend à travers une chaîne qui inclut un membre inattendu, et le générateur de filtres traite le résultat comme une politique de routage ordinaire.

C'est cela, la fragilité des bases de données IRR. Ce n'est pas la même question que de savoir qui peut publier ou supprimer un enregistrement préfixe-origine particulier. Cette question plus étroite est importante, mais elle s'inscrit dans une architecture de marché plus vaste. Le problème plus large est que l'environnement du registre de routage Internet est pluriel. Il est composé de sources gérées par les RIR, de dépôts commerciaux et privés, de miroirs, de préférences de sources locales, d'ensembles récursifs, d'enregistrements copiés, d'entrées abandonnées et d'outils qui traduisent ces preuves inégales en filtres privés. L'effet économique apparaît lorsqu'un réseau doit décider à quelle version de l'histoire de routage croire.

L'ARIN est un cas d'étude utile parce que sa région combine un marché de transfert IPv4 très développé avec une dépendance opérationnelle dense. Les opérateurs nord-américains, les plateformes cloud, les réseaux de contenu, les banques, les universités, les fournisseurs d'hébergement, les sociétés de services gérés, les organismes publics et les opérateurs des Caraïbes utilisent tous des adresses dont la valeur dépend de leur acceptation par les autres. Les adresses IPv4, devenues rares, ne sont pas seulement enregistrées. Elles sont routées, filtrées, intégrées dans des plateformes cloud, financées, louées, examinées sur le plan de la réputation et intégrées dans les plans de continuité des clients. Dans cet environnement, le coût de la fragmentation des preuves IRR n'est pas théorique. Il se traduit par des retards, des remises, un travail d'exception manuel et parfois une accessibilité partielle.

La question est également institutionnelle. Un registre est le plus légitime lorsqu'il préserve un grand livre fiable des ressources de numéros limitées et facilite la preuve opérationnelle. Il devient dangereux lorsqu'il tente de transformer ce grand livre en un contrôle discrétionnaire sur chaque utilisation commerciale des adresses. La fragmentation de l'IRR teste cette frontière dans l'autre sens. Si l'ARIN n'en fait pas assez pour clarifier la sémantique des sources faisant autorité pour les ressources de sa région, les dépôts privés et les anciens miroirs comblent le vide. Si elle tente d'imposer tous les choix de filtrage, elle outrepasse ses compétences. La réponse durable se situe entre ces erreurs: une autorité de source claire, une sémantique de publication propre, des preuves responsables et des limites explicites sur ce que l'enregistrement du registre prouve ou ne prouve pas.

Cet article porte sur la sélection des sources. Le même enregistrement de route peut avoir une signification opérationnelle différente selon qu'il provient de l'ARIN, d'une source non autorisée adjacente à l'ARIN, de RADb, de l'IRR privé d'un ancien fournisseur, d'un miroir d'un autre dépôt ou d'un jeu AS développé de manière récursive. Le même préfixe peut sembler propre à un fournisseur amont et suspect à un autre parce que l'ordre de leurs sources diffère. Le même transfert peut être opérationnellement complet dans le grand livre de l'ARIN et encore incomplet dans le monde des filtres parce que l'acheteur n'a pas trouvé toutes les sources qu'un accepteur privé consomme.

La frontière d'autorité de l'ARIN et l'ombre des données non autorisées

La distinction la plus importante dans l'environnement IRR de la région ARIN est la frontière entre les données faisant autorité et les données qui semblent simplement utiles. Pour les ressources gérées par l'ARIN, un enregistrement de routage provenant de l'ARIN, lié au titulaire reconnu et géré dans le cadre du contrôle des ressources de l'ARIN, a un caractère probatoire différent de celui d'un enregistrement qui se trouve dans un dépôt tiers. Cela ne signifie pas que les dépôts privés sont sans valeur. Cela signifie qu'ils ne doivent pas être confondus avec la déclaration du registre concernant une ressource placée sous sa responsabilité de coordination.

La frontière de type ARIN-NONAUTH est utile précisément parce qu'elle nomme l'ambiguïté. Une source non autorisée peut contenir des données opérationnellement pertinentes. Elle peut décrire un arrangement client réel, une migration historique ou une route qui a fonctionné autrefois. Mais ce n'est pas la même chose qu'une déclaration faisant autorité de l'ARIN, ancrée dans le grand livre des ressources de l'ARIN. Si les filtres privés traitent ces catégories comme égales, ils transforment la commodité en une autorité cachée. Si les opérateurs ignorent totalement les données non autorisées, ils risquent de passer à côté des preuves qu'un fournisseur amont ou un serveur de route utilise effectivement. L'objectif n'est pas de supprimer une catégorie. L'objectif est d'éviter la confusion des catégories.

Dans un environnement à faible valeur, la confusion des catégories pourrait être tolérable. Une petite incohérence serait résolue par un ticket, un appel téléphonique ou une exception manuelle. Sur le marché actuel, l'incohérence peut affecter le prix de transfert, le calendrier de règlement, la migration cloud, l'admission aux IXP et la continuité des clients. Un acheteur d'espace IPv4 peut obtenir un statut de transfert reconnu par l'ARIN et constater néanmoins qu'une entrée de type RADb, une source d'un ancien fournisseur ou un enregistrement non autorisé est la première chose que voit un outil de filtrage. L'acheteur n'a pas perdu la ressource. Il a hérité d'une charge de la preuve.

La frontière d'autorité est également importante pour les vendeurs. Un vendeur qui possède des enregistrements ARIN propres mais laisse en place d'anciennes données de route de tiers n'a pas fourni un historique opérationnel propre. Le vendeur peut dire, à juste titre, que l'ARIN reconnaît le transfert. L'acheteur peut répondre, également à juste titre, que les filtres privés n'interrogent pas uniquement l'ARIN. Le différend ne porte pas sur la propriété métaphysique. Il porte sur les preuves qui peuvent être lues par les réseaux dont l'acceptation rend le bloc utile.

Le rôle de l'ARIN doit être discipliné. Elle ne doit pas prétendre être le tribunal mondial de chaque source IRR. Elle ne peut pas et ne doit pas ordonner à chaque réseau privé de préférer les données de l'ARIN dans tous les filtres. Mais elle peut rendre la frontière de la source ARIN plus difficile à mal comprendre. Elle peut publier une sémantique des sources qui sépare les données des ressources gérées par l'ARIN, faisant autorité, des données non autorisées ou de tiers. Elle peut indiquer clairement qu'un transfert de la reconnaissance du registre ne garantit pas que toutes les sources IRR externes aient été nettoyées. Elle peut aider les titulaires à faire la distinction entre l'état détenu par l'ARIN et les données qui survivent en dehors du contrôle de l'ARIN.

Cette frontière protège également l'ARIN contre l'excès de pouvoir. Le registre ne doit pas devenir un régulateur général des routes simplement parce que les filtres privés sont désordonnés. Sa fonction principale est plus étroite: l'unicité, la reconnaissance actuelle des ressources, les contacts responsables, la continuité du service et les preuves adjacentes au routage que les réseaux peuvent évaluer. Si la source fait autorité, dites pourquoi. Si la source ne fait pas autorité, dites-le clairement. Si un enregistrement a été mis en miroir, préservez l'origine de la revendication. Les marchés peuvent tolérer l'incertitude lorsque l'incertitude est étiquetée. Ils deviennent fragiles lorsque les étiquettes disparaissent.

Le mirroring fait paraître les anciennes données comme vivantes

Le mirroring est utile car il rend les données disponibles. Il est dangereux car il peut faire paraître les anciennes données comme vivantes. Un opérateur interrogeant un serveur IRR peut ne pas remarquer si la réponse provient de la source originale, d'une copie miroir, d'un miroir obsolète d'une source autrefois valide, ou d'un dépôt qui conserve les données historiques plus longtemps que la relation opérationnelle ne survit. La requête aboutit, la réponse est structurée et le préfixe apparaît dans un format que les outils peuvent consommer. Cela suffit à de nombreux filtres pour continuer.

C'est la survie silencieuse des données de routage. Un enregistrement peut être corrigé à un endroit mais rester visible par un autre chemin. Un ancien fournisseur peut mettre à jour sa propre source, tandis que le calendrier de rafraîchissement d'un miroir est en retard. Un dépôt commercial peut conserver une route enregistrée par proxy par commodité. Un IRR privé peut être mis en miroir par un pair qui n'a pas remarqué que la source a changé. Un jeu AS peut pointer vers une source dont les membres incluent des données plus anciennes. Un serveur de route peut se reconstruire quotidiennement, mais à partir d'une liste d'entrées qui donne plus de poids à un miroir obsolète qu'à une source autorisée corrigée.

Le problème économique est que la partie qui essaie de router paie pour l'historique. Un acheteur de transfert ne peut pas simplement dire: "L'ARIN me reconnaît maintenant." Il doit demander quelles sources de données consomme chaque contrepartie importante. Une équipe cloud peut demander pourquoi l'ancienne origine apparaît toujours. Un fournisseur de transit peut rejeter jusqu'à ce que le conflit soit résolu. Un serveur de route d'échange peut ne pas expliquer quelle source a provoqué le refus. Un prêteur ou un conseiller peut marquer le bloc comme opérationnellement désordonné. Les anciennes données deviennent une petite taxe sur le titulaire actuel.

Le mirroring obscurcit également les responsabilités. Si un enregistrement obsolète est interrogé à partir d'un miroir, qui doit le corriger? Le titulaire peut ne pas contrôler la source originale. La source originale peut dire que les données ont déjà changé. L'opérateur du miroir peut traiter le problème comme un problème de rafraîchissement plutôt que comme un problème d'autorité. Le réseau qui a consommé le miroir peut ne pas divulguer sa liste de sources. Le résultat est un exercice de preuve à quatre coins autour d'un enregistrement qui a pu commencer comme une simple commodité de routage.

C'est pourquoi la provenance des sources importe autant que le contenu. Une réponse IRR utile ne doit pas se contenter de rapporter les données de préfixe, d'origine et de gestionnaire. Elle doit conserver suffisamment d'informations sur la source pour que le lecteur sache d'où provient la revendication et si les données font autorité pour la ressource en question. Si un miroir est impliqué, le lecteur doit comprendre qu'il s'agit d'un miroir. Si une source n'est pas autorisée, le lecteur ne doit pas être autorisé à déduire l'autorité à partir du formatage. Si un enregistrement est ancien, les informations de dernière modification et de fraîcheur doivent être faciles à trouver et faciles à conserver par les outils.

Pour l'ARIN, la leçon n'est pas que le mirroring est mauvais. L'écosystème des politiques de routage de l'Internet dépend de la réplication, de l'accessibilité et de la commodité des requêtes. La leçon est que les preuves répliquées ont besoin d'une identité claire. Une fonction de grand livre fiable à la source peut encore perdre de sa force si les miroirs estompent l'autorité. Le registre peut publier les données actuelles, mais le marché consomme des copies. Si les copies ne comportent pas la sémantique de la source, le marché voit un monde plat: une réponse parmi tant d'autres, toutes en forme de RPSL, toutes apparemment capables d'influencer les filtres.

Le mirroring transforme la publication en une chaîne d'approvisionnement. Une chaîne d'approvisionnement défectueuse n'est pas réparée simplement en réparant l'usine si les distributeurs continuent d'expédier le vieux stock. En termes d'IRR, la source autorisée est peut-être l'usine, mais le serveur de route, le fournisseur de transit et le bureau cloud reçoivent souvent les marchandises par l'intermédiaire d'intermédiaires. La fragilité réside dans cette distance.

RADb et les IRR privés font partie du marché, ils n'en sont pas exclus

RADb et d'autres sources IRR non RIR ou privées sont souvent considérées comme une nuisance dans les discussions politiques, mais elles font partie du marché réel. Elles existent parce que les opérateurs avaient besoin d'un endroit pour publier la politique de routage, les données de route des clients et les informations sur les jeux AS lorsque les bases de données des RIR étaient incomplètes, difficiles à utiliser, lentes à s'adapter ou ne faisaient pas autorité pour la ressource décrite. Elles existent également parce que les réseaux privés prennent des décisions de routage privées. Un grand transporteur, un fournisseur de services gérés ou un centre de données peut maintenir des enregistrements pour les clients parce que cela réduit les frictions de provisionnement.

Le résultat est une économie probatoire mixte. Certains enregistrements de tiers sont obsolètes. Certains sont négligés. Certains sont des enregistrements de proxy qui auraient dû être retirés. Certains sont la seule preuve lisible par machine qu'un petit client peut fournir à un fournisseur amont. Certains décrivent des relations client-fournisseur légitimes que l'ARIN elle-même ne devrait pas essayer de juger. Certains sont des commodités commerciales. Certains deviennent des passifs opérationnels des années plus tard. Traiter toutes les données de tiers comme des déchets est erroné. Les traiter toutes comme équivalentes aux données du registre faisant autorité est également erroné.

Les sources de type RADb revêtent une importance particulière dans la région ARIN car celle-ci compte de nombreux titulaires historiques, clients cloud, arrangements de location d'adresses, clients de centres de données, réseaux gérés et acheteurs de transferts dont les relations de routage ne correspondent pas à une simple histoire de titulaire-origine. Une entreprise peut posséder un bloc mais router par l'intermédiaire d'un fournisseur. Une université peut utiliser une plage historique par le biais d'un réseau de consortium. Un client cloud peut avoir besoin d'un ASN de plateforme pendant une migration. Un fournisseur caribéen peut dépendre d'un fournisseur amont qui maintient des enregistrements en son nom. Les données IRR privées peuvent mieux refléter ces relations qu'une simple ligne de titulaire. Mais cette utilité opérationnelle ne répond pas à la question de l'autorité.

La question de l'autorité est: que prouve la source? Un enregistrement de tiers peut prouver que quelqu'un a publié une revendication de routage dans ce dépôt. Il peut être la preuve qu'un fournisseur amont attendait une route. Il peut être une donnée d'entrée utile pour un filtre. Il peut étayer une relation de service. Il ne prouve pas, en soi, le contrôle actuel de la ressource reconnu par l'ARIN. Lorsque les filtres privés ne parviennent pas à maintenir cette distinction, une source privée peut acquérir un pouvoir pratique sur une ressource rare sans assumer la responsabilité au niveau du registre.

C'est là que l'économie institutionnelle est utile. Un dépôt privé réduit les coûts de transaction pour les entités qui comprennent ses limites. Il augmente les coûts systémiques lorsque des tiers s'y fient sans comprendre ces limites. Le même enregistrement de type RADb peut être utile entre un fournisseur et son client, mais nuisible si un futur acheteur, une plateforme cloud ou un serveur de route le confond avec l'autorité du titulaire actuel. La valeur de l'enregistrement dépend du contexte. La fragilité apparaît lorsque le contexte est supprimé par le mirroring et la génération automatisée de filtres.

La réponse constructive n'est pas d'exiger un monde pur avec uniquement des données RIR. La politique de routage est trop diverse pour cela. La réponse consiste à rendre explicite la qualité des sources et à aligner la préférence de source sur la chaîne d'autorité de la ressource. Pour l'espace d'adressage géré par l'ARIN, les données actuelles de la source ARIN devraient normalement avoir un poids particulier en tant que signal proche du grand livre. Les données de tiers doivent être traitées comme des preuves de relation, et non comme une preuve finale de l'autorité sur la ressource. Lorsque des données de tiers sont en conflit avec des données ARIN faisant autorité, le conflit doit déclencher une explication plutôt qu'une acceptation aveugle de la source qui apparaît en premier dans un outil local.

Cette distinction améliorerait le marché. Les vendeurs sauraient quels enregistrements externes doivent être divulgués. Les acheteurs sauraient ce dont ils héritent. Les fournisseurs amont pourraient utiliser des sources privées sans prétendre qu'elles constituent une preuve de type titre de propriété. Les IXP pourraient élaborer des politiques de sources suffisamment claires pour que les membres puissent corriger les erreurs. L'ARIN pourrait préserver la discipline de son mandat en clarifiant sa propre source plutôt qu'en revendiquant un contrôle sur toutes les autres.

La récursivité des jeux AS est le point où la fragilité s'aggrave

Les jeux AS sont le point où la fragilité de l'IRR cesse d'être une liste d'enregistrements isolés pour devenir un réseau d'hypothèses héritées. Un enregistrement de route indique qu'un préfixe est censé provenir d'un ASN. Un jeu AS indique quels ASN, ou quels autres jeux AS, appartiennent au cône de routage ou au groupe de politique d'un client. Les générateurs de filtres commencent souvent par un nom de jeu AS, le développent récursivement, collectent les préfixes associés et génèrent des listes de préfixes ou des politiques de route. Si la chaîne du jeu AS traverse plusieurs sources, les données obsolètes peuvent se multiplier silencieusement.

La récursivité est importante parce que la première question peut être innocente: "Quel est votre jeu AS?" Un client fournit un nom. L'outil du fournisseur le recherche dans une liste de sources. Si le même nom existe dans plus d'une source, l'ordre des sources peut décider quel ensemble est utilisé. Si un ensemble inclut un autre ensemble, l'outil suit la chaîne. Si un ensemble membre pointe vers une ancienne source, le filtre peut intégrer d'anciens ASN. Si les enregistrements de route pour ces ASN proviennent de plusieurs sources, la liste de préfixes finale peut inclure des routes que personne n'a examinées récemment. Au moment où le filtre est déployé, l'entrée semble faire autorité parce qu'elle est devenue une configuration.

Il ne s'agit pas d'une faiblesse théorique. C'est un dispositif de mise à l'échelle quotidien. Les grands réseaux ne peuvent pas approuver manuellement chaque préfixe en aval. Les IXP ne peuvent pas construire à la main le cône client de chaque membre. Les opérations cloud et de transit ne peuvent pas compter sur des courriels personnalisés pour chaque route. L'expansion des jeux AS transforme des déclarations de routage dispersées en une politique lisible par machine. Cela est précieux. Le danger est que la récursivité cache le chemin par lequel une source ancienne ou faible est entrée dans la décision finale.

Pour un acheteur de transfert, cela peut être coûteux. L'acheteur peut nettoyer les enregistrements de route du bloc acheté et découvrir néanmoins qu'un ancien jeu AS contrôlé par un ancien fournisseur ramène le préfixe dans un chemin de politique obsolète. Un petit FAI peut mettre à jour son propre ensemble mais laisser un membre client dans une source privée qui se développe différemment selon les fournisseurs amont. Un centre de données peut demander à un client d'utiliser un jeu AS maintenu par le fournisseur parce que cela correspond à l'outillage du fournisseur, tandis qu'un autre pair insiste sur un ensemble qualifié par la source ailleurs. Un serveur de route peut rejeter parce que le jeu AS déclaré du membre n'inclut pas la combinaison exacte origine-source que le serveur attend.

La récursivité des jeux AS crée également des problèmes de nommage. Les noms qui ne sont pas qualifiés par la source peuvent entrer en collision. Un ensemble dans un dépôt peut ne pas être l'ensemble qu'un outil choisit. Un client peut supposer que le fournisseur développe l'ensemble actuel, alors que la liste de sources du fournisseur trouve d'abord un ensemble plus ancien. Un grand opérateur peut être en mesure de résoudre ce problème par une coordination directe. Un petit opérateur peut ne recevoir qu'un rejet indiquant que son jeu AS est incorrect. La différence n'est pas seulement une question de connaissances techniques. C'est une question de pouvoir de négociation.

Une bonne hygiène de l'IRR exige donc une visibilité de la chaîne. Un générateur de filtres devrait être en mesure de dire à un client non seulement qu'un préfixe a été rejeté, mais aussi quel chemin de jeu AS et quelle source ont produit le rejet. Un titulaire devrait pouvoir vérifier quels ensembles nomment son ASN ou ses préfixes. Un dossier de diligence de transfert devrait inclure non seulement les enregistrements de route du bloc, mais aussi les références de jeux AS qui peuvent faire persister l'ancienne histoire de routage. Un serveur de route devrait encourager l'utilisation de jeux AS qualifiés par la source lorsque l'ambiguïté est probable. Ces pratiques n'éliminent pas la récursivité. Elles la rendent inspectable.

Le RPKI ne résout pas ce problème particulier parce qu'il ne modélise pas les cônes clients. Un ROA peut indiquer qu'un AS peut être à l'origine d'un préfixe. Il ne dit pas quels ASN appartiennent au jeu AS d'un client, si un fournisseur doit accepter une route en aval ou si un serveur de route doit inclure les clients d'un membre dans les filtres générés. Les données IRR restent le langage des relations de politique de routage. C'est pourquoi la fragilité des jeux AS reste économiquement importante même dans un marché plus sensibilisé au RPKI.

L'ordre des sources est une politique économique cachée

L'ordre des sources ressemble à une préférence d'ingénierie. Dans la pratique, il peut se comporter comme une politique économique. Un générateur de filtres peut interroger d'abord l'ARIN, puis RADb, puis RIPE, puis un dépôt privé. Un autre peut mettre RADb en premier parce que ses clients l'utilisaient historiquement. Un autre peut préférer le RPKI pour la validation de l'origine mais utiliser plusieurs sources IRR pour la génération de listes de préfixes. Un serveur de route IXP peut publier une liste de sources par défaut. Un opérateur peut garder sa liste privée. Le résultat est que deux réseaux peuvent évaluer différemment la même revendication de route sans que l'un ou l'autre ne soit irrationnel.

Lorsque l'ordre des sources diffère, les résultats commerciaux diffèrent. Un préfixe accepté par un fournisseur amont peut être rejeté par un autre. Une demande d'intégration dans le cloud peut être acceptée après qu'un examinateur humain a donné la priorité aux preuves actuelles de l'ARIN, tandis qu'un filtre de transit rejette parce qu'un enregistrement tiers plus ancien apparaît en premier. Un acheteur peut croire que le nettoyage est terminé parce que son consultant a interrogé un ordre de sources, alors que le fournisseur préféré de l'acheteur en utilise un autre. Un petit FAI peut perdre une semaine à découvrir que "décalage IRR" signifie en réalité "notre outil a préféré une source non autorisée dont vous ignoriez que nous la consommions."

Cette politique cachée a des effets distributifs. Les grands réseaux peuvent demander des exceptions, persuader leurs pairs et maintenir des contacts directs avec les équipes de filtrage. Les petits réseaux ne le peuvent souvent pas. Un grand client cloud peut recevoir une explication détaillée; une petite société d'hébergement peut recevoir une réponse type. Un opérateur national peut appliquer sa propre politique de sources; un fournisseur d'accès caribéen peut être lié par les choix de deux fournisseurs de transit disponibles. L'ordre des sources alloue donc des coûts fixes. Il décide qui doit nettoyer quelle base de données avant que les revenus ne puissent continuer.

La nature cachée de l'ordre des sources fausse également les prix. Un acheteur de transfert peut exiger une remise si le bloc semble désordonné selon des listes de sources courantes. Un vendeur peut résister, affirmant que l'état autorisé de l'ARIN est propre. Les deux peuvent avoir raison. L'écart de valeur provient de la probabilité que des contreparties importantes préfèrent des données obsolètes ou non autorisées avant de voir l'état nettoyé. Cette probabilité est difficile à chiffrer si l'ordre des sources est opaque. Elle devient une prime de risque.

La meilleure discipline est la transparence, et non l'uniformité. Il serait irréaliste d'exiger que chaque réseau utilise les mêmes sources IRR dans le même ordre. Les réseaux ont des historiques, des clients, des postures de sécurité et des appétits pour le risque différents. Mais les réseaux qui rejettent des routes en raison de données IRR devraient divulguer suffisamment d'informations pour que le titulaire puisse résoudre le problème. Si le rejet est dû à un conflit de source spécifique, dites quelle source. Si le problème vient d'un chemin de jeu AS, montrez le chemin. Si le réseau préfère les données de la source ARIN pour les ressources ARIN, dites-le. S'il préfère une source commerciale large pour des raisons opérationnelles, rendez le risque visible.

L'ordre des sources est le point où le code en cours d'exécution révèle la réalité institutionnelle. Les réunions peuvent décrire une base de données comme faisant autorité, mais la liste des sources du générateur de filtres détermine si cette autorité est lue en premier, plus tard ou pas du tout. Un marché d'adresses construit autour de la rareté des IPv4 ne peut pas ignorer ce fait. Si l'ordre des sources est caché, les acteurs du marché négocient des actifs dont ils ne peuvent pas voir pleinement les règles d'acceptation. Si l'ordre des sources est visible, le même marché peut chiffrer le nettoyage, attribuer les responsabilités et réduire les surprises.

L'objectif n'est pas de rendre tous les filtres privés obéissants à l'ARIN. L'objectif est de rendre le filtrage privé suffisamment intelligible pour que l'autorité actuelle sur les ressources ne soit pas mise en échec par accident, inertie ou une préférence non examinée pour les anciennes données.

Gestion des conflits: silence, préférence et charge

Les conflits ne sont pas des exceptions rares. Ils sont des sous-produits normaux d'un monde de registres de routage pluriel. Le même préfixe peut apparaître dans plusieurs sources. Une ancienne origine peut coexister avec une nouvelle origine. Un jeu AS peut inclure un membre qui n'en fait plus partie. Un dépôt privé peut décrire une relation client que l'ARIN ne peut pas voir. Un miroir peut être en retard. Un serveur de route peut lire une réponse tandis qu'une plateforme cloud en lit une autre. La gestion des conflits détermine si cette pluralité reste gérable ou devient une pénalité de marché.

Il existe trois façons fondamentales de gérer les conflits: le silence, la préférence et le déplacement de la charge. Le silence signifie que le réseau qui rejette donne peu d'explications. Le titulaire apprend seulement que sa route n'est pas passée. La préférence signifie que le réseau a une hiérarchie des sources ou une règle de décision, qu'elle soit publique ou privée. Le déplacement de la charge signifie que le titulaire actuel doit prouver pourquoi la source obsolète ou conflictuelle doit être ignorée. La plupart des systèmes réels combinent les trois. La question économique est de savoir qui paie lorsqu'ils entrent en collision.

Le silence est le plus coûteux pour les petits acteurs. Un grand réseau peut diagnostiquer en exécutant ses propres outils et en appelant ses pairs. Un petit FAI peut ne pas savoir si le problème est un enregistrement RADb obsolète, un résidu de type ARIN-NONAUTH, un retard de miroir, une collision de jeu AS, un qualificatif de source manquant ou un décalage RPKI. Plus le diagnostic est long, plus l'opérateur paie en temps perdu. Dans un marché caribéen avec des options de transit limitées, le retard peut signifier un coût de gros plus élevé, des performances clients dégradées ou des délais de service non respectés.

La préférence peut être efficace si elle est claire. Un serveur de route qui déclare préférer les données RIR faisant autorité pour les ressources de la région concernée, puis utilise des sources tierces sélectionnées pour les données de relation, offre aux membres un chemin prévisible. Un fournisseur de transit qui indique qu'il interroge des sources spécifiées dans un ordre spécifié permet aux clients de tester avant la mise en service. Un fournisseur cloud qui explique comment il concilie les données ARIN, les ROA et les enregistrements IRR réduit le risque d'intégration. La préférence devient problématique lorsqu'elle est cachée mais traitée comme une vérité objective.

Le déplacement de la charge est inévitable mais doit être discipliné. Si un titulaire actuel veut que d'autres ignorent un ancien enregistrement tiers, il doit fournir des preuves. Si une origine déléguée veut maintenir une route acceptée, elle doit montrer l'autorité actuelle. Si un fournisseur maintient un jeu AS proxy, il doit le tenir à jour. Mais la charge ne doit pas être infinie. Une fois que l'autorité actuelle de la source ARIN, la posture actuelle du ROA le cas échéant et les preuves opérationnelles actuelles s'alignent, les données non autorisées obsolètes ne devraient pas pouvoir prendre le marché en otage indéfiniment.

La norme de gestion des conflits devrait se demander ce que chaque source est compétente pour prouver. Les données de la source ARIN sont les plus solides sur l'autorité des ressources ARIN. Les données de type RADb ou privées peuvent être les plus solides sur une relation de routage client-fournisseur. Un miroir n'est aussi solide que sa source et sa fraîcheur. Un jeu AS est une preuve de l'intention politique, pas de propriété. Un ROA est une autorisation d'origine de route, pas une carte du cône client. Si chaque signal est maintenu dans son domaine de compétence, les conflits peuvent être résolus sans prétendre qu'un seul artefact répond à toutes les questions.

Le gain économique d'une gestion disciplinée des conflits est la liquidité. Un bloc avec d'anciens débris IRR n'est pas sans valeur; c'est un bloc avec un risque de nettoyage. Un bloc avec des données autorisées claires et des résidus externes isolés est plus facile à évaluer. Un réseau avec des raisons de rejet transparentes est plus facile à traiter. Un registre qui étiquette l'autorité des sources réduit les litiges sans devenir un organe d'exécution. Les conflits ne disparaîtront pas. Mais l'ambiguïté ne devrait pas pouvoir décider du résultat par défaut.

Diligence de transfert dans un monde IRR fragmenté

Les transferts IPv4 exposent la fragilité de l'IRR parce qu'un transfert modifie l'histoire du titulaire plus rapidement que l'environnement du registre de routage ne peut changer. L'ARIN peut reconnaître le destinataire. Les parties peuvent conclure. Les conseillers peuvent mettre à jour les documents. L'acheteur peut préparer un nouveau plan d'origine. Pourtant, le monde des filtres peut encore contenir des enregistrements plus anciens, des copies miroirs, des jeux AS proxy, des entrées non autorisées et des données maintenues par le fournisseur qui pointent vers le passé opérationnel du vendeur. L'actif a été déplacé. La chaîne d'approvisionnement des preuves ne l'a pas entièrement suivi.

Un dossier de diligence de transfert sérieux devrait donc inclure un inventaire des sources IRR. Il devrait répertorier les enregistrements de la source ARIN, les enregistrements non autorisés adjacents à l'ARIN lorsqu'ils sont visibles, les enregistrements de type RADb, les enregistrements maintenus par le fournisseur, les références IRR privées connues des parties, les copies miroirs, les références de jeux AS et les résultats courants des générateurs de filtres. Il devrait distinguer les enregistrements que le vendeur peut modifier, les enregistrements que l'acheteur peut modifier après la clôture, les enregistrements contrôlés par les fournisseurs et les enregistrements qui peuvent nécessiter la coopération d'un tiers. Il devrait également identifier quelles contreparties importantes s'appuient sur quelles sources.

Il ne s'agit pas d'un ornement juridique. C'est de l'économie de la livraison. Un acheteur qui a besoin du bloc pour la migration cloud, le basculement des clients, la protection DDoS, les marchés publics, l'expansion de l'hébergement ou le service haut débit régional ne peut pas traiter le nettoyage de l'IRR comme une tâche post-clôture informelle. Si le fournisseur amont préféré de l'acheteur n'accepte pas la route tant qu'une source obsolète n'est pas corrigée, l'acheteur ne reçoit pas une capacité productive immédiate. Il reçoit un projet de remédiation. Le prix devrait en tenir compte.

Pour les transferts à forte dépendance, les conditions de règlement peuvent devoir inclure des jalons IRR. Le vendeur peut accepter de divulguer les enregistrements de route et de jeux AS connus. Les parties peuvent convenir des enregistrements qui restent temporairement pendant la migration. Les fournisseurs peuvent être informés. L'acheteur peut créer des enregistrements de remplacement de la source ARIN lorsque l'autorité le permet. Les dépôts externes peuvent être contactés. Un calendrier de séquestre peut distinguer la reconnaissance du registre de l'acceptation opérationnelle pour les contreparties les plus importantes. Tous les transferts n'ont pas besoin d'un tel niveau de détail. Mais plus le cas d'affaires dépend d'une accessibilité rapide, plus le dossier des sources IRR est important.

La contribution de l'ARIN est d'être explicite sur ce qu'elle peut et ne peut pas fournir. Elle peut enregistrer le transfert, maintenir le grand livre des ressources faisant autorité, soutenir les données de routage de la source ARIN et aider les titulaires à comprendre l'état du côté ARIN. Elle ne peut pas garantir que RADb, un IRR privé, une source d'un ancien fournisseur, un serveur de route IXP ou une plateforme cloud a mis à jour sa propre vue. Cette limitation devrait faire partie de la compréhension standard du marché, et non une surprise découverte après la clôture.

La diligence de transfert est le point où le principe du registre en tant que grand livre devient pratique. Le grand livre doit être propre, étroit et fiable. Autour de lui se trouve un marché d'acceptation plus large qui doit être inspecté. Un acheteur d'IPv4 rares n'achète pas simplement une plage de numéros. Il achète un chemin pour être cru par de nombreux systèmes indépendants. Les données IRR fragmentées sont l'un des endroits où ce chemin peut se briser.

Les petits opérateurs, les clouds et les IXP sont les premiers à en subir le coût

La fragilité de l'IRR n'est pas répartie uniformément. Les grands réseaux peuvent souvent la contourner. Ils disposent d'équipes d'ingénierie, de contacts privés, d'outils de politique de routage, de voies d'escalade et de soutien juridique. Ils peuvent effectuer leurs propres comparaisons de sources. Ils peuvent négocier des exceptions. Ils peuvent persuader un fournisseur cloud, un partenaire de transit ou un pair de réexaminer. Un petit FAI, une société d'hébergement régionale, un département universitaire, un fournisseur de services gérés ou un opérateur caribéen peut avoir la même revendication légitime de ressource mais moins de moyens pour rendre cette revendication lisible.

Pour les petits opérateurs, le coût est fixe. Apprendre les règles des sources IRR, maintenir les jeux AS, auditer les miroirs, nettoyer les anciens enregistrements de type RADb, coordonner les ROA et répondre aux rejets opaques des filtres prend du temps quelle que soit la taille du bloc. Un /24 utilisé par un petit fournisseur d'accès peut nécessiter presque le même travail de preuve qu'un portefeuille plus important détenu par une plateforme sophistiquée. Ce coût fixe est régressif. Il pénalise les opérateurs dont le revenu par exercice de preuve est faible.

Les réseaux caribéens illustrent bien ce point. La région de service de l'ARIN comprend des opérateurs insulaires et de petits marchés dont la connectivité peut dépendre d'un ensemble limité de câbles sous-marins, de choix de fournisseurs amont, d'options d'échange et de régions cloud en dehors de leur marché domestique. Si un conflit IRR retarde un serveur de route ou une mise en service de transit, l'opérateur peut ne pas avoir cinq substituts. Il peut payer plus, accepter de moins bons chemins ou décevoir des clients qui ne se soucient pas que le problème provienne d'une source obsolète. Des preuves fragiles deviennent un coût de connectivité locale.

Les plateformes cloud créent une autre forme de pression. Les programmes "apportez votre propre IP" exigent souvent la preuve que le client contrôle le préfixe et peut autoriser l'origine de la plateforme. Le RPKI peut faire partie de cette preuve. Les données IRR peuvent également être examinées, en particulier lorsque la plateforme souhaite comprendre les anciennes origines ou la politique de routage actuelle. Si une source tierce obsolète dit une chose et que les preuves actuelles de l'ARIN en disent une autre, la plateforme peut faire une pause. La pause est rationnelle du point de vue de la plateforme. Elle est coûteuse pour le client.

Les IXP et les serveurs de route mettent la logique en code. Un serveur de route doit protéger les membres contre les mauvaises routes et les erreurs de configuration. Il peut utiliser les données IRR et le RPKI ensemble. Il peut générer des filtres à partir des jeux AS des membres. Si les données IRR du membre sont manquantes, conflictuelles ou cachées derrière un mauvais ordre des sources, la route peut ne pas être propagée. Pour un grand réseau de contenu, c'est un chemin parmi d'autres. Pour un opérateur régional, l'acceptation par le serveur de route peut affecter sensiblement les performances et le coût du transit.

Le coût social n'est pas seulement un inconvénient. Si seules les grandes plateformes peuvent se permettre des preuves propres, le marché des adresses devient moins concurrentiel. Les petits titulaires peuvent vendre à prix réduit parce qu'ils ne peuvent pas prouver efficacement la propreté. Les petits acheteurs peuvent éviter les blocs aux historiques compliqués. Les réseaux régionaux peuvent rester dépendants des fournisseurs amont qui maintiennent la machinerie IRR pour eux. Le marché récompense alors la capacité administrative autant que le besoin opérationnel.

L'ARIN peut réduire ce fardeau de coûts fixes sans devenir un programme de subventions ou une police des routes. Elle peut fournir des conseils plus clairs sur les frontières des sources, une meilleure visibilité pour les titulaires sur les données de routage de la source ARIN, des listes de contrôle pratiques pour les transferts, des exemples de qualification de source des jeux AS et des explications sur la façon dont les preuves RPKI et IRR interagissent. Les réseaux privés peuvent aider en donnant des raisons de rejet exploitables. Les IXP peuvent publier leurs politiques de sources. Les clouds peuvent expliquer quelles preuves ils exigent et pourquoi. L'objectif commun est une légitimité à faible friction: un petit opérateur légitime ne devrait pas avoir besoin d'une campagne institutionnelle sur mesure pour prouver une route de routine.

Pourquoi le RPKI aide mais ne fait pas disparaître l'IRR

Le RPKI est la réponse la plus solide à une partie du problème. Un ROA permet à un titulaire de ressource d'autoriser un ASN d'origine dans un système basé sur des certificats. La validation de l'origine des routes permet aux réseaux de classer les annonces par rapport à cette autorisation. Comparé à un enregistrement IRR tiers non structuré, un ROA valide lié au titulaire actuel de la ressource est un signal beaucoup plus propre pour l'autorisation de l'origine. Un déploiement plus large du RPKI réduit la marge de manœuvre pour que certaines revendications d'origine de route fausses ou obsolètes soient crues.

Mais le RPKI ne fait pas disparaître l'IRR parce qu'il répond à une question différente. Le RPKI indique si un AS est autorisé à être à l'origine d'un préfixe, dans les limites de longueur de préfixe spécifiées. Il ne décrit pas un jeu AS, un cône client, une politique de peering, une relation de transit, une appartenance à un serveur de route, une délégation de service géré ou une source de filtre préférée du fournisseur. Les données IRR restent le langage de travail pour bon nombre de ces relations de politique. Les réseaux qui construisent des filtres clients ont encore besoin d'un moyen de savoir quels ASN et préfixes se trouvent derrière un client. Le RPKI seul ne raconte pas cette histoire.

Il existe également un écart de déploiement. Certains réseaux appliquent strictement la validation de l'origine des routes. D'autres l'utilisent comme avertissement. Certaines routes sont couvertes par des ROA. D'autres restent "NotFound". Certaines erreurs sont temporaires et opérationnelles plutôt que malveillantes. Certains réseaux combinent le RPKI avec des filtres IRR, n'acceptant une route que si l'autorisation d'origine et la politique IRR semblent plausibles. Dans ce monde mixte, un conflit IRR peut encore retarder une route même lorsque le RPKI est correct, et un ROA manquant peut encore laisser l'IRR comme principale preuve lisible par machine.

Le RPKI peut également affiner le calendrier des transferts. Un transfert peut nécessiter des modifications de ROA, des changements d'origine et un nettoyage de l'IRR dans une séquence coordonnée. Si le ROA est mis à jour mais que les anciennes données IRR persistent, certains filtres peuvent encore remettre en question la route. Si les données IRR sont mises à jour mais que le ROA est erroné, la validation de l'origine de la route peut classer l'annonce comme invalide. Si les anciens et les nouveaux états se chevauchent pendant la migration, les deux systèmes doivent être compris. La valeur du RPKI est élevée précisément parce qu'il ajoute un meilleur signal; la nécessité d'une discipline IRR demeure parce que l'acceptation privée lit encore plusieurs signaux.

Les systèmes échouent également différemment. Le RPKI repose sur la continuité des certificats et des dépôts, la fraîcheur des publications, le comportement des validateurs et les choix corrects de maxLength. L'IRR repose sur la qualité des sources, les mainteneurs, le mirroring, la récursivité des jeux AS et les préférences locales des sources. Un opérateur mature surveille les deux. Un dossier de transfert mature explique les deux. Un processus d'intégration cloud mature concilie les deux. Traiter l'un comme un substitut total de l'autre crée des angles morts.

Pour l'ARIN, le RPKI est une opportunité d'améliorer la hiérarchie des preuves. Lorsque l'autorité actuelle des ressources ARIN, la posture actuelle des ROA et les données IRR actuelles de la source ARIN s'alignent, les filtres privés devraient avoir une bonne raison de faire confiance à l'histoire de l'origine de la route. Lorsqu'ils sont en conflit, le conflit doit être visible et explicable. Lorsque des données de tiers entrent en conflit avec les deux, les données de tiers doivent être traitées comme une revendication nécessitant un contexte, et non comme un vote égal. Le RPKI renforce les preuves autorisées. Il n'efface pas la nécessité d'étiqueter les preuves non autorisées.

Le marché devrait donc cesser de se demander si le RPKI ou l'IRR l'emporte. La question pertinente est de savoir comment les deux signaux sont ordonnés dans un dossier d'acceptation pratique. Un bloc propre de la région ARIN doit avoir une reconnaissance actuelle du registre, des contacts précis, des ROA appropriés, des enregistrements de route actuels de la source ARIN si nécessaire, un état connu du nettoyage de l'IRR externe, des jeux AS qualifiés par la source et une explication claire de tout résidu tiers restant. Le RPKI est central dans ce dossier. Il n'est pas tout le dossier.

Ce que l'ARIN peut faire sans devenir un régulateur des routes

La voie constructive pour l'ARIN est étroite mais significative. Elle ne doit pas dicter à chaque réseau ce qu'il doit router. Elle ne doit pas superviser les conditions commerciales des baux IPv4, des migrations cloud ou des relations de transit. Elle ne doit pas transformer la préférence de source en une loi régionale obligatoire sur le routage. Sa légitimité est la plus forte lorsqu'elle agit comme un grand livre fiable et une institution de cohérence des preuves. La fragilité de l'IRR a précisément besoin de ce type de discipline.

Premièrement, l'ARIN peut clarifier la sémantique des sources. Les opérateurs doivent pouvoir distinguer les données de la source ARIN faisant autorité pour les ressources gérées par l'ARIN des données non autorisées, miroirs ou de tiers. La distinction doit être visible pour les humains et facile à conserver pour les outils. Si un enregistrement n'est pas autorisé pour la ressource, l'étiquette doit survivre aux requêtes, à la mise en miroir et à l'exportation dans les contextes de construction de filtres lorsque cela est possible. Une étiquette claire est une forme bon marché d'infrastructure de marché.

Deuxièmement, l'ARIN peut améliorer la visibilité pour les titulaires. Les titulaires doivent pouvoir comprendre les enregistrements de routage côté ARIN associés à leurs ressources et les implications de base des catégories de sources. Cela n'exige pas que l'ARIN découvre chaque entrée RADb ou IRR privée. Cela exige que l'ARIN rende son propre état suffisamment lisible pour qu'un titulaire puisse séparer les preuves régies par l'ARIN des tâches de nettoyage externes. Un petit opérateur ne devrait pas avoir besoin d'un spécialiste simplement pour savoir ce que l'ARIN dit de son préfixe.

Troisièmement, l'ARIN peut publier des conseils IRR orientés transfert. Les entités aux transferts doivent savoir que la reconnaissance du registre et le nettoyage de l'IRR sont liés mais pas identiques. Une liste de contrôle pratique devrait demander: quels enregistrements de la source ARIN existent, quels enregistrements externes sont connus, quels jeux AS font référence aux ASN concernés, quels miroirs ou listes de sources les contreparties importantes utilisent, quels ROA doivent changer, quelles anciennes origines restent temporairement valides et quels enregistrements nécessitent une coopération de tiers. Des conseils de ce type soutiennent les marchés sans dicter les conditions des transactions.

Quatrièmement, l'ARIN peut résister à la tentation d'utiliser la fragilité de l'IRR comme une expansion de mandat. Les sources fragmentées sont un problème réel, mais tous les problèmes réels ne relèvent pas du registre en tant que souverain. Les réseaux privés ont le droit de gérer les risques. Les clients sont responsables de leurs relations de routage. Les dépôts tiers peuvent être utiles. Les tribunaux et les contrats tranchent de nombreux litiges commerciaux. La mission de l'ARIN est de maintenir le dossier central fiable, et non de devenir le juge final de toute acceptation de route.

Le test est de savoir si l'ARIN réduit le coût de la preuve sans augmenter les goulets d'étranglement discrétionnaires. Un titulaire devrait trouver plus facile de prouver l'autorité actuelle sur les ressources. Un acheteur devrait trouver plus facile d'identifier les résidus IRR externes. Un serveur de route devrait trouver plus facile de préférer des preuves propres. Un petit FAI devrait trouver plus facile de remédier à un rejet. Une plateforme cloud devrait trouver plus facile de comprendre l'histoire de l'origine de la route. Aucun de ces résultats n'exige que l'ARIN commande le routage. Ils exigent que l'ARIN maintienne le grand livre et ses preuves adjacentes adaptés à un marché où l'IPv4 est un capital.

Sources et méthode

Cet article traite les mécanismes de registre public et de sécurité du routage comme des pièces factuelles, et non comme un cadrage institutionnel. Le cadre analytique est celui de l'économie institutionnelle autour des ressources de numéros limitées: la distinction entre un grand livre et un gardien, le danger du risque au niveau du registre une fois que l'IPv4 devient un capital, la discipline selon laquelle les réseaux en fonctionnement plutôt que la rhétorique déterminent la réalité opérationnelle, et la nécessité de protéger la continuité des ressources de numéros sans transformer un registre en un exécuteur général.

La frontière opérationnelle est importante parce que le même bloc d'adresses peut transiter par plusieurs canaux de preuve en même temps. Les contacts du registre et les ROA peuvent étayer l'histoire du titulaire actuel. Les objets de route, les jeux AS, les copies miroirs et les enregistrements maintenus par le fournisseur peuvent encore décrire d'anciens arrangements opérationnels. Les filtres cloud, de transit et d'échange peuvent alors préférer des listes de sources différentes. Cet article s'intéresse à cette fragmentation: comment de multiples sources IRR, miroirs, récursivité des jeux AS et ordre des sources font que la même revendication de routage signifie des choses différentes pour différents filtres.

Les mécanismes officiels du registre ne sont utiles ici que pour identifier ce que font les systèmes: données du registre de routage de la source ARIN, RPKI, ROA, enregistrements publics des ressources, étiquettes de source et services liés au routage. Ils ne fournissent pas la conclusion. La conclusion découle du contexte du marché: la rareté des IPv4, les pratiques de transfert nord-américaines, l'intégration dans le cloud et les centres de données, le filtrage IXP, les contraintes de capacité des petits opérateurs et le fait que les réseaux privés transforment les données de routage publiques et semi-publiques en décisions d'acceptation privées.

L'article évite délibérément une simple moralité. Les sources de type RADb et les IRR privés ne sont pas traités comme des méchants. Les données de la source ARIN ne sont pas traitées comme de la magie. Le RPKI n'est pas traité comme un remplacement universel. Chaque source de preuve est jugée par ce qu'elle est compétente pour prouver et par le coût imposé lorsque ses limites sont mal comprises. C'est la méthode requise pour un marché dont les actifs sont intangibles, rares et opérationnellement intégrés.

Conclusion: la fragilité est un coût pour être cru

La fragilité des bases de données IRR est facile à sous-estimer parce qu'elle ressemble à un problème de données techniques. C'est en réalité un problème de coût de confiance. Un bloc IPv4 rare ne devient utile que lorsque suffisamment de systèmes indépendants croient l'histoire de routage actuelle. Ces systèmes ne lisent pas tous les mêmes preuves. Certains lisent l'ARIN. Certains lisent RADb. Certains lisent des miroirs. Certains développent récursivement les jeux AS. Certains combinent l'IRR et le RPKI. Certains utilisent d'anciennes listes de sources. Certains cachent leur ordre de sources derrière une file d'attente de support. Le titulaire fait l'expérience de cette pluralité comme une friction.

Pour l'ARIN, la posture institutionnelle correcte n'est ni la passivité ni l'excès de pouvoir. La passivité laisse les données non autorisées obsolètes et les habitudes des sources privées allouer un pouvoir pratique sur les ressources de la région ARIN. L'excès de pouvoir transformerait le registre en un régulateur des routes et répéterait l'ancienne erreur de convertir la tenue de livres en contrôle discrétionnaire. La meilleure posture est la discipline du grand livre: clarifier l'état autorisé, préserver l'identité des sources, soutenir les preuves actuelles adjacentes au routage, étiqueter les limites et aider les opérateurs à comprendre ce qui reste en dehors de l'ARIN.

Pour le marché, la leçon pratique est que la diligence sur les sources IRR fait désormais partie de la diligence des actifs IPv4. Un dossier de transfert qui ignore les sources de routage externes est incomplet. Une migration cloud qui ignore les anciens chemins de jeux AS est exposée. Une politique IXP qui ne donne aux membres aucune raison de rejet exploitable augmente les coûts fixes. Un acheteur qui suppose que la reconnaissance de l'ARIN nettoie automatiquement les enregistrements de type RADb achète des surprises. Un vendeur qui laisse derrière lui des données tierces obsolètes livre un actif moins liquide que ce que le prix pourrait laisser entendre.

Le RPKI améliore ce monde, mais il ne l'abolit pas. L'avenir n'est pas un système de preuve unique qui fait disparaître toutes les autres sources. L'avenir est une hiérarchie de preuves dans laquelle chaque source porte le poids approprié à son autorité. Les données de la source ARIN doivent faire autorité pour les ressources gérées par l'ARIN. Le RPKI doit avoir une forte valeur d'autorisation d'origine. Les sources de type RADb et privées doivent décrire des relations avec des limites claires. Les miroirs doivent préserver la provenance. Les jeux AS doivent être qualifiés par la source lorsque l'ambiguïté est importante. Les générateurs de filtres doivent expliquer leurs choix lorsque ces choix bloquent des routes légitimes.

Les aspects économiques sont modestes mais conséquents. Une sémantique des sources propre réduit les coûts de transaction. Des conflits visibles rendent le risque chiffrable. Une meilleure hygiène des jeux AS réduit les barrières accidentelles du marché. Des raisons de rejet claires aident les petits réseaux à être compétitifs. La diligence de transfert qui inclut les sources IRR protège les acheteurs et les vendeurs. L'ARIN n'a pas besoin de devenir plus puissante pour produire ces gains. Elle doit rendre ses preuves existantes plus lisibles et plus difficiles à confondre avec des preuves plus faibles.

C'est pourquoi la fragilité de l'IRR fait partie de la discussion sur la rareté des IPv4. La rareté donne un prix aux adresses, mais l'acceptation leur donne une valeur productive. Dans un monde IRR fragmenté, l'acceptation ne dépend pas seulement d'être correct, mais d'être correct dans la source qu'un filtre privé croit en premier. L'économie de la fragilité de la base de données IRR de l'ARIN est l'économie de cette première croyance.