Résumé

  • Un transfert reconnu par un registre prouve un changement enregistré associé à un préfixe. Il ne prouve pas en soi le paiement, la possession, le routage public, l'utilisation par un client, l'intégration productive ou l'identité du réseau exploitant les adresses.
  • Les états post-transfert doivent être classés séparément: détention, location, réserve opérationnelle, renumérotation, usage futur engagé, échec d'intégration ou production routée. Un bloc peut passer d'un état à l'autre, et plusieurs états peuvent s'appliquer à différentes portions d'un même préfixe transféré.
  • BGP est la preuve publique la plus solide de l'origination et de la propagation des routes, mais les collecteurs de routes ne voient que ce que leurs pairs volontaires leur envoient. Un préfixe peut être masqué par agrégation, visible uniquement via des chemins privés ou limités, temporairement retiré ou utilisé dans le cadre d'un arrangement qui n'expose pas la partie commerciale.
  • RPKI ajoute une preuve d'autorisation d'origine, pas la preuve qu'une route existe ou transporte du trafic. Le DNS inverse ajoute une preuve de nommage et de délégation, pas d'utilisation. RDAP ajoute des informations d'enregistrement et de contact, pas un recensement opérationnel. Chaque source répond à une question différente.
  • Le temps est essentiel. Une étiquette quotidienne attachée à la date de transfert classera à tort une mise en place ordinaire. L'étude doit conserver les références pré-transfert, observer les routes exactes et couvrantes, mesurer les changements d'origine et de visibilité, et conserver les cas non résolus au lieu de les forcer dans « utilisé » ou « inutilisé ».
  • L'absence de routage ne doit jamais être traitée automatiquement comme de la spéculation. La capacité de réserve, la reprise après sinistre, la renumérotation par étapes, les engagements clients, les conditions de financement, les litiges, la contamination technique et l'abandon d'intégration peuvent tous produire du silence sans prouver une intention manipulatrice.
  • Un meilleur élément de preuve du marché publierait les transitions d'état, la couverture des observations et l'incertitude sans exiger des contrats confidentiels. Le registre doit conserver un historique de transfert précis; les opérateurs, les chercheurs et les acteurs du marché doivent pouvoir vérifier ce qui s'est passé ensuite sans transformer la télémétrie du réseau en une licence d'approbation commerciale.

Une clôture n'est pas un paquet

Le titre décrit une erreur d'analyse courante plutôt qu'un scandale unique. Un acheteur et un vendeur conviennent des conditions. Les vérifications requises sont effectuées. Un registre modifie le titulaire enregistré et ajoute une ligne à une liste publique de transferts. La transaction est désormais visible pour quiconque télécharge cette liste. Pourtant, un collecteur de routes ne voit jamais le préfixe transféré annoncé par l'acheteur.

Que s'est-il passé?

La réponse tentante est que l'acheteur a acquis le bloc uniquement pour le conserver sans l'utiliser. Cette réponse peut être juste dans un cas particulier. Elle n'est pas établie par les preuves. L'enregistrement du transfert et l'enregistrement de routage sont des observations de systèmes différents.

L'enregistrement du registre concerne l'administration reconnue. Selon la région et le type de transfert, il peut identifier une source, un bénéficiaire, un préfixe, une date, un code pays et si l'événement était un transfert de politique ou un changement de structure d'entreprise. Il marque un événement institutionnel. Il ne divulgue pas l'accord privé, la date de règlement, les conditions de financement, les accords de location, le plan de migration, les contrats clients ou la conception interne du réseau.

BGP concerne les informations d'accessibilité échangées entre systèmes autonomes. Une route vue chez un collecteur montre qu'au moins un chemin surveillé transportait une annonce pour un préfixe à un moment donné. Il n'identifie pas le propriétaire bénéficiaire. Il ne montre pas le prix d'achat. Il ne montre pas si les paquets ont atteint un service fonctionnel. Il ne nous dit pas si la route provenait d'un locataire, d'un client de transit, d'un fournisseur de services gérés ou de l'acquéreur lui-même.

Lesystème de registre des numéros Internet décrit dans le RFC 7020rend cette frontière particulièrement claire. L'exactitude et l'unicité de l'enregistrement sont des objectifs du registre, tandis que le fait que les adresses soient effectivement annoncées et la manière dont elles sont annoncées sont des questions opérationnelles en dehors du champ du système de registre. La rareté n'a pas effacé cette séparation. Elle a rendu les conséquences de l'oublier plus coûteuses.

Un chercheur en transferts devrait donc commencer par deux questions indépendantes. Quel changement le registre a-t-il reconnu? Qu'est-ce qui a changé dans le fonctionnement observable du réseau? Ce n'est qu'après avoir répondu aux deux que l'étude devrait demander quel état économique est compatible avec les preuves combinées.

Le marché a besoin de sept états, pas d'un verdict binaire

« Routé » et « non routé » sont des observations utiles. Ce sont de mauvaises catégories économiques. Un /16 transféré peut contenir plusieurs /20 en production, un /19 détenu pour la croissance, des blocs plus petits loués à des clients et une portion en cours de nettoyage après un abus antérieur. Une seule étiquette pour le /16 entier détruit l'information même dont le marché a besoin.

Une classification plus utile commence par sept états.

Détentionsignifie que le bénéficiaire conserve le contrôle reconnu sans preuve suffisante pour attribuer un objectif opérationnel immédiat. La détention est une description, pas un jugement. Elle couvre une position à long terme de type fonds de pension, une position d'inventaire, une entreprise attendant une vente, ou simplement un cas pour lequel les observateurs publics en savent trop peu. Le terme ne doit pas être silencieusement transformé en « accaparement » ou « spéculation ».

Locationsignifie qu'un autre opérateur reçoit une utilisation contractuelle tandis que le titulaire enregistré de premier niveau peut rester inchangé. Le locataire peut originer les routes depuis son propre système autonome, utiliser une origine gérée fournie par le bailleur, ou placer des clients derrière les adresses. Le routage public peut révéler une origine incompatible avec le nom enregistré sans expliquer le contrat.

Réservesignifie que le bloc est détenu comme assurance opérationnelle ou capacité planifiée. La reprise après sinistre, la contingence de fusion, le basculement client, la séparation de la réputation des adresses et une marge pour une croissance soudaine peuvent tous créer une valeur d'option avant qu'une route publique n'apparaisse. La réserve est économiquement active même lorsque les paquets ne circulent pas.

Renumérotationsignifie que le déploiement est en transition. L'acquéreur peut préparer la politique de routage, les listes d'accès, les corrections de géolocalisation, le DNS inverse, les contrôles de sécurité, les avis aux clients et les modifications d'applications avant d'annoncer la nouvelle plage. Les anciennes et nouvelles plages peuvent se chevaucher pendant des mois. Un bloc transféré ne peut être productif qu'après un basculement délibérément lent.

Usage futursignifie qu'un déploiement crédible est engagé mais pas encore actif. La distinction avec la réserve est la preuve d'un projet daté, d'un contrat client, d'une commande d'équipement, de l'ouverture d'une installation ou d'un plan de migration. Les observateurs publics ne peuvent souvent pas voir ces preuves, ils doivent donc enregistrer l'état comme possible plutôt que de le déclarer prouvé.

Échec d'intégrationsignifie que l'utilisation prévue ne s'est pas concrétisée. La cause peut être un client perdu, un échec de financement, une réputation d'adresse endommagée, un conflit de politique de routage, des erreurs de géolocalisation, un litige juridique, un changement d'entreprise ou un plan technique qui s'est avéré non économique. C'est important commercialement car un transfert conclu peut encore échouer en tant qu'investissement.

Production routéesignifie que le bloc est annoncé de manière observable et soutenu par des signes supplémentaires compatibles avec le fonctionnement. Même cette catégorie nécessite des niveaux. Une route vue une fois n'est pas la même chose qu'une visibilité soutenue à travers les collecteurs, une autorisation d'origine stable, un nommage inverse et des services accessibles.

Les états ne sont pas mutuellement exclusifs au niveau agrégé. La classification doit se faire au niveau du préfixe stable le plus spécifique soutenu par les données et doit conserver les transitions. La question n'est pas « L'accord a-t-il été utilisé? » C'est « Quelles portions sont entrées dans quels états, à quels moments, sur quelles preuves? »

Les journaux de transfert publics établissent une limite d'événement, pas une conclusion économique

Le format commun dejournal de transfert NROdonne aux chercheurs un point de départ précieux. Il permet aux RIR de publier des enregistrements cumulatifs de transferts intra-régionaux et inter-régionaux dans une structure JSON partagée. La valeur est la comparabilité: un préfixe, un type de transfert, une source, un bénéficiaire, une date et des champs régionaux connexes peuvent être normalisés entre les institutions.

Cet enregistrement partagé n'est toujours pas un grand livre de tous les faits commerciaux. Une ligne de transfert peut représenter un préfixe plutôt qu'un accord complet. Une acquisition commerciale peut être divisée en de nombreuses lignes parce que l'espace d'adressage était fragmenté. Plusieurs lignes un même jour peuvent refléter un seul prix et un seul règlement. Inversement, un agrégat transféré peut plus tard être divisé entre différents arrangements opérationnels.

Le type d'événement compte également. Lesstatistiques de transfertde RIPE NCC distinguent les transferts de politique des changements de structure d'entreprise et peuvent identifier les cas permanents ou temporaires. Une mise à jour liée à une fusion n'est pas automatiquement une vente sur le marché. Un changement d'enregistrement temporaire n'équivaut pas à une cession permanente. Compter chaque ligne comme un actif acheté corromprait à la fois l'analyse des prix et du déploiement.

La date publiée doit également être interprétée avec prudence. La spécification historique dujournal de transfert d'APNICdécrit la date de transfert comme la date à laquelle le bénéficiaire a reçu la ressource dans l'enregistrement. Cette date est un point d'ancrage administratif. L'accord commercial peut être antérieur, le paiement peut être conditionnel et la migration opérationnelle peut être postérieure.

L'unité correcte est donc un cas de transfert réconcilié. Les lignes avec les mêmes parties, le même type d'événement, le même chemin institutionnel et la même date de clôture peuvent être liées, tout en préservant chaque préfixe. Le cas doit conserver au moins trois horloges: l'accord ou le règlement lorsque les contributeurs confidentiels peuvent le fournir, la reconnaissance du registre et le premier changement d'état opérationnel observé.

L'analyse publique peut se poursuivre sans connaître le prix. Elle peut demander comment le préfixe s'est comporté avant et après la reconnaissance du registre. Mais elle ne doit jamais décrire la date de transfert comme si un interrupteur était actionné dans chaque routeur. La date crée une fenêtre d'observation; elle ne prédétermine pas ce que la fenêtre doit contenir.

BGP fournit la meilleure preuve de route publique et une vue incomplète

Le RFC 4271définit BGP comme un échange d'informations d'accessibilité soumis à la politique de routage locale. Les locuteurs reçoivent des routes, choisissent parmi elles et décident quoi annoncer à leurs pairs. Cela rend les données BGP puissantes: elles peuvent montrer l'apparition, le retrait, l'origine et la propagation d'une route d'une manière qu'aucune entrée d'enregistrement ne peut.

Cela explique aussi pourquoi un collecteur n'est pas l'Internet. LeRouting Information Servicede RIPE reçoit des mises à jour et des retraits BGP des réseaux qui s'apparient volontairement avec ses collecteurs de routes. RouteViews archive de même les données RIB et UPDATE de ses propres pairs collecteurs. Ces projets fournissent une observation large et historiquement profonde. Ils ne reçoivent pas toutes les routes de tous les systèmes autonomes.

Le premier test de route doit rechercher le préfixe transféré exact. Si un /20 a été déplacé, un collecteur a-t-il vu ce /20? Enregistrez l'AS d'origine, la date de première vue, la date de dernière vue, le nombre de pairs collecteurs, le nombre de collecteurs distincts et la persistance de l'observation.

Le deuxième test doit rechercher des plus spécifiques. Le /20 peut ne jamais apparaître comme une seule route parce que l'opérateur annonce seize /24. Une étude qui ne vérifie que le préfixe transféré qualifiera un déploiement actif de silencieux. La couverture plus spécifique doit être mesurée par le nombre d'adresses et le temps, en prenant soin de ne pas compter deux fois les routes qui se chevauchent.

Le troisième test doit rechercher des routes couvrantes. Le /20 transféré peut se trouver à l'intérieur d'un /16 déjà annoncé par une société mère, un fournisseur ou une société du groupe. La table globale peut atteindre les adresses par cet agrégat sans exposer un /20 séparé. Un collecteur de routes ne révélera pas la limite transférée parce que l'agrégation de routage fait exactement ce pour quoi elle a été conçue.

Le quatrième test doit mesurer la continuité et le changement d'origine. Une nouvelle origine après le transfert peut indiquer une intégration, une location ou un arrangement de routage géré. Une origine inchangée peut signifier que le vendeur exploite toujours le réseau temporairement, que les parties appartiennent au même groupe d'entreprises, que l'acheteur a acquis la société d'exploitation ou que l'espace d'adressage est reloué. La continuité de l'origine est une preuve, pas un verdict.

Enfin, l'étude doit conserver la couverture des collecteurs. « Non vu » doit signifier non vu par les collecteurs et pairs répertoriés pendant la période indiquée. Sans cette phrase, l'absence est exagérée.

La visibilité des routes n'est pas le trafic, le service ou le revenu

Une route BGP stable est une preuve plus forte qu'une ligne de registre pour la production routée, mais elle reste une preuve du plan de contrôle. Elle montre un chemin annoncé. Elle ne mesure pas le nombre de clients, l'occupation des adresses, le volume de paquets, la qualité de service ou le revenu.

Un opérateur peut annoncer un /16 entier tout en n'utilisant qu'une petite portion. La route fournit l'accessibilité pour l'agrégat, pas une carte d'utilisation. Une société d'hébergement peut placer des milliers de points de terminaison actifs derrière un /20, tandis qu'un autre opérateur annonce le même bloc pour une poignée de systèmes d'infrastructure. BGP traite les deux comme une seule annonce de préfixe.

L'erreur inverse compte également. Une route peut être visible alors qu'aucun service utile n'est disponible. Un acheteur peut annoncer un bloc brièvement pour tester les filtres ou mettre à jour les services de géolocalisation. Un bailleur peut maintenir une route agrégée présente alors qu'aucun client n'utilise une sous-plage particulière. Un détournement ou une fuite de route peut créer une visibilité sans rapport avec la production autorisée.

Les mesures du plan de données peuvent ajouter du contexte. Les adresses réactives, les réponses DNS, les handshakes TLS et les mesures de chemin peuvent étayer une inférence opérationnelle. Pourtant, chaque méthode a des angles morts. Les pare-feu suppriment les réponses. Les services peuvent être privés, contrôlés par accès ou accessibles uniquement depuis certains réseaux. L'anycast peut rendre un emplacement de sonde non représentatif. La traduction d'adresses réseau peut prendre en charge de nombreux utilisateurs derrière quelques adresses publiques. L'analyse éthique limite ce qui doit être tenté.

L'échelle des preuves doit donc être explicite. Une observation de route prouve la visibilité aux points de vue BGP surveillés. Des routes exactes ou plus spécifiques persistantes à travers divers pairs soutiennent une large propagation. Une réponse cohérente du plan de données soutient un service actif. Les enregistrements des clients ou des opérateurs peuvent soutenir une utilisation productive sous confidentialité. Aucun échelon ne doit être réétiqueté comme utilisation économique complète.

Cette distinction est importante pour l'évaluation du marché. Les acheteurs se soucient de savoir si un bloc peut être routé proprement, mais ils se soucient également de la réputation, de la géolocalisation, de l'acceptation en amont, de la demande des clients et du coût interne. Une route qui apparaît est une étape. Ce n'est pas le compte de résultat.

RPKI prouve l'autorisation, pas l'annonce

RPKI est souvent mal interprété dans la direction opposée. Une autorisation d'origine de route (ROA) semble fournir un lien clair entre un préfixe, une longueur maximale et un AS d'origine. Il est donc tentant de traiter une nouvelle ROA comme une preuve que l'acheteur a déployé le bloc.

L'architecture dit le contraire.Le RFC 6480explique que les informations d'allocation dans l'infrastructure de clé publique ne suffisent pas à guider les décisions de routage. Une ROA rend une autorisation d'origine explicite. Elle indique qu'un AS est autorisé à originer une route pour un préfixe dans la longueur autorisée. L'autorisation n'est pas une annonce.

Un bénéficiaire peut créer une ROA des semaines avant le lancement comme préparation prudente. Il peut autoriser plusieurs origines pour le basculement. Un bailleur peut autoriser l'AS d'un locataire. Une entreprise peut laisser une autorisation en place pendant une migration. Une ROA obsolète peut survivre après que le plan opérationnel a changé. Aucun de ces objets ne nous dit si une route était visible ou transportait du trafic.

L'absence d'une ROA est tout aussi ambiguë. L'adoption de RPKI est incomplète. Un opérateur peut router valablement au sens BGP ordinaire sans publier d'autorisation d'origine. Sa route sera « non trouvée » plutôt que prouvée non autorisée. Une étude qui ne compte que l'espace couvert par RPKI sous-estimera le fonctionnement.

Le RFC 6811ajoute deux mises en garde supplémentaires. La validation d'origine attribue un état à une route BGP reçue; elle n'atteste pas le chemin AS complet. Les routeurs appliquent ensuite une politique locale à l'état de validation. Différents caches peuvent temporairement avoir des vues différentes parce que les objets signés sont distribués et rafraîchis au fil du temps.

Pour l'analyse des transferts, RPKI fournit des preuves de transition utiles. L'ancienne autorisation a-t-elle disparu? Une nouvelle origine est-elle devenue autorisée? Y a-t-il eu un chevauchement sans interruption? Des routes visibles sont-elles devenues invalides parce qu'une longueur maximale ou une origine ne correspondait pas? Ces observations peuvent révéler la qualité de l'intégration et le risque opérationnel.

Elles ne peuvent pas prouver pourquoi un bloc est resté silencieux. Une nouvelle ROA suivie d'aucune route est compatible avec un usage futur, une réserve, un lancement raté ou un acheteur prudent. Aucune ROA et aucune route observée est compatible avec la détention, l'utilisation privée, le routage couvert ou la simple non-adoption. L'étiquette honnête est non résolu à moins qu'une autre source ne le précise.

Le DNS inverse montre la délégation et la discipline de nommage, pas l'occupation

Le DNS inverse est un autre signal utile mais surinterprété. Le mappage inverse IPv4 place les adresses sousin-addr.arpa. La délégation peut montrer qu'un opérateur ou un client a préparé l'autorité pour une plage. Les enregistrements PTR peuvent révéler des conventions de nommage associées à l'accès, l'hébergement, l'infrastructure ou les clients.

La préparation n'est pas la production. Un acheteur peut établir des serveurs de noms et remplir des modèles avant le routage. Un bloc peut rester activement routé avec des enregistrements PTR clairsemés ou absents parce que le service n'en a pas besoin. Les plages d'accès grand public peuvent utiliser des noms génériques. Les fournisseurs d'hébergement peuvent créer des enregistrements inverses uniquement sur demande. Les opérateurs soucieux de la sécurité peuvent délibérément divulguer peu d'informations.

Les limites de délégation compliquent également la mesure.Le RFC 2317décrit la délégation inverse sans classe pour les plages plus petites qu'un /24. L'arrangement technique peut utiliser des alias et des zones enfants qui ne correspondent pas directement à une ligne de transfert. Une organisation parente peut conserver l'autorité inverse tout en déléguant des plages clients. Une délégation obsolète peut persister après que la relation économique a changé.

La meilleure utilisation du DNS inverse est comme un signal de changement daté. De nouveaux serveurs de noms faisant autorité près de la date de transfert peuvent étayer une inférence d'intégration. Un changement du modèle de nommage du vendeur à celui de l'acheteur peut marquer une renumérotation. Divers enregistrements PTR de marque client peuvent soutenir la production ou la location. La disparition d'anciens noms peut montrer un nettoyage.

L'absence doit rester de faible poids. Une réponse PTR manquante ne montre pas qu'une adresse est inutilisée. Une réponse PTR présente ne montre pas que l'hôte nommé existe. Même un nom inverse réactif confirmé par une résolution directe ne prouve qu'une relation configurée au moment de l'observation.

Les chercheurs doivent conserver les preuves de délégation de zone séparément de la densité individuelle de PTR. Ils doivent enregistrer l'heure de la requête, le chemin du résolveur et si la réponse faisait autorité. Les études massives de DNS inverse peuvent également créer des problèmes de confidentialité en exposant des modèles de nommage jamais destinés à être divulgués sur le marché. Les résultats agrégés sont généralement suffisants.

Le DNS inverse est précieux précisément parce qu'il est indépendant du journal de transfert. Il ajoute une texture opérationnelle. Il ne devient trompeur que lorsqu'un indice de configuration est traité comme un compteur d'occupation.

RDAP nous dit qui le registre reconnaît, dans les limites de la publication

RDAP modernise l'accès aux informations d'enregistrement.Le RFC 7480définit son utilisation sur HTTP, tandis quele RFC 9082définit les requêtes pour les ressources de numéros Internet et les enregistrements associés.Le RFC 7484fournit un moyen de trouver le service faisant autorité pour une plage d'adresses.

Pour la recherche sur les transferts, RDAP peut confirmer la plage enregistrée actuelle, les entités, les statuts, les événements, les liens et les avis que le serveur met à disposition. Des instantanés répétés peuvent montrer quand l'enregistrement public a changé et si une plage a été divisée. RDAP est souvent plus structuré et automatisable que l'ancienne sortie WHOIS.

Il reflète toujours l'enregistrement, pas tous les rôles économiques. L'entité répertoriée peut être le titulaire reconnu, une société mère, un contact administratif, un contact d'abus ou un autre rôle défini par le service. L'opérateur qui annonce la route peut être une filiale, un client, un locataire, un fournisseur géré ou un partenaire de transit. Les règles de confidentialité et de publication peuvent supprimer des détails. Les informations de contact peuvent être en retard sur la réalité.

Une étude de transfert ne doit pas « résoudre » une discordance d'origine en supposant qu'une source est erronée. Si RDAP nomme la Société A et que BGP montre une origine associée à la Société B, la relation est inconnue jusqu'à ce qu'elle soit étayée. Il peut s'agir d'une location légitime, d'un accord d'externalisation, d'une fusion, d'une cession de client ou d'une structure de groupe. Il peut également s'agir d'un détournement. La discordance est une piste de recherche, pas une constatation de mauvaise conduite.

Les événements RDAP peuvent améliorer la chronologie, mais la sémantique des événements varie selon le service. Un horodatage de dernière modification n'est pas nécessairement la date de clôture commerciale ou le début de l'utilisation. Les caches et les miroirs peuvent ajouter des retards. Les instantanés historiques sont donc importants; une requête actuelle ne peut pas reconstruire chaque état intermédiaire.

La déclaration d'enregistrement la plus solide est étroite: à l'heure indiquée, le service RDAP faisant autorité a renvoyé l'enregistrement indiqué pour la plage interrogée. Cela peut valider une ligne de transfert public ou révéler un changement ultérieur. Cela ne peut pas prouver que chaque adresse est occupée, qu'un acheteur a payé ou qu'une entité nommée contrôle l'origine de la route.

Cette retenue n'est pas du pédantisme. Elle protège les opérateurs légitimes d'être accusés sur la base d'une confusion de rôles.

Le temps transforme de faibles indices en une séquence crédible

Un instantané d'un seul jour est presque garanti d'exagérer la certitude. Les transferts et les migrations de réseau sont des processus. Les preuves deviennent utiles lorsqu'elles sont placées sur une chronologie commune.

La référence de base doit commencer avant le premier événement commercial ou de registre connu. Au minimum, l'étude a besoin de suffisamment d'historique pour distinguer un bloc vraiment silencieux de celui qui a été annoncé par intermittence. Elle doit enregistrer les routes exactes, plus spécifiques et couvrantes; les origines; la visibilité des collecteurs; les ROA; la délégation inverse; les données du titulaire RDAP; et les signaux évidents du plan de données.

La fenêtre de transfert a alors besoin de marqueurs d'événements. Ceux-ci peuvent inclure la date de transfert public, le changement RDAP, le retrait de l'ancienne route, la création d'une nouvelle ROA, l'apparition d'une nouvelle route, le changement de DNS inverse et la première réponse soutenue. Lorsque les parties fournissent des preuves privées, l'accord, le dépôt fiduciaire, la soumission au registre, le règlement et le lancement client peuvent être inclus sous confidentialité.

Après le transfert, l'observation doit se poursuivre assez longtemps pour capturer la mise en place ordinaire et les plans échoués. Sept jours peuvent détecter un déploiement immédiat. Quatre-vingt-dix jours peuvent détecter une migration. Un an peut révéler une activation de réserve, un placement en location ou une revente. Aucun seuil universel ne convertit le silence en mobile. L'étude doit publier plusieurs horizons plutôt que de choisir une date limite morale.

Les transitions d'état sont plus informatives que les points finaux. Une séquence de changement de registre, nouvelle ROA, délégation inverse puis visibilité de route soutenue soutient une intégration planifiée. Une séquence de changement de registre, aucun changement de configuration et un transfert ultérieur peut soutenir une détention d'inventaire. Une brève route, une invalidité répétée et un retrait peuvent soutenir un échec d'intégration. Chacune reste une inférence avec une étiquette de confiance.

L'intermittence mérite sa propre mesure. Un bloc vu deux jours sur une année diffère de celui vu quotidiennement. L'étendue des collecteurs compte également. Les dates de première et de dernière vue doivent être accompagnées de la part de jours visibles, du nombre médian de pairs et de la stabilité de l'origine.

Les cas non résolus doivent rester non résolus. Une étude doit résister à la pression de faire correspondre chaque ligne à un graphique final. Dans un marché où les locations et les opérations internes sont privées, l'incertitude fait partie du sujet, pas un défaut à cacher.

La détention est un modèle de fait, pas une catégorie morale

Supposons qu'un préfixe transféré soit absent des observations BGP exactes et plus spécifiques pendant dix-huit mois. RDAP montre le bénéficiaire. Aucun changement de ROA ou de délégation inverse. Le bénéficiaire transfère à nouveau le bloc plus tard. C'est une preuve solide d'une période de détention sans production routée publique.

Cela n'établit toujours pas une spéculation nuisible par elle-même. L'acheteur peut avoir eu l'intention de déployer et a abandonné. Il peut avoir acheté plusieurs alternatives et en avoir sélectionné une autre. Il peut avoir détenu le bloc comme garantie ou inventaire. Il peut avoir attendu une vente. Le mobile nécessite des preuves au-delà de la télémétrie.

La gouvernance du marché confond souvent cette distinction parce que la « détention » semble passive et que la rareté donne à la passivité un poids politique. Pourtant, chaque marché de capitaux contient des stocks et de la valeur d'option. Un opérateur garde des routeurs de rechange, des paires de fibres, de la capacité cloud et des liquidités. La question pertinente n'est pas de savoir si un intrant est resté inutilisé à un moment donné. C'est de savoir si la conduite a causé un préjudice défini qui justifie une intervention.

Les preuves publiques peuvent mesurer la concentration, les périodes de détention, l'activation des routes et les transferts répétés. Elles peuvent montrer si un petit nombre d'entités acquièrent de grands volumes qui restent publiquement silencieux. Elles peuvent comparer le déploiement ultérieur et la revente. Ce sont des faits précieux. Ils n'identifient pas automatiquement la manipulation, le pouvoir de marché ou la fausse déclaration.

Le mot « spéculation » doit donc être réservé aux cas avec une définition économique: acquisition principalement pour profiter d'un changement de prix attendu, étayée par le comportement transactionnel ou l'intention divulguée. Même alors, la spéculation n'est pas synonyme d'abus. Une analyse distincte doit montrer la tromperie, la rareté artificielle, la manipulation, le contournement des politiques ou un autre préjudice identifiable.

Cette discipline améliore la recherche plutôt que de l'affaiblir. Une constatation que 30 % d'une cohorte est restée inobservée à un an serait significative si les définitions de couverture et d'état étaient solides. Traiter les mêmes adresses d'« accaparées » ajouterait de la rhétorique et supprimerait la précision.

Le marché a besoin de mesures de l'inactivité. Il n'a pas besoin que la télémétrie soit transformée en jugement de caractère.

La location sépare le contrôle enregistré de l'opération routée

La location est la raison la plus évidente pour laquelle un titulaire transféré et l'origine de la route peuvent différer. Un acheteur peut acquérir un contrôle reconnu puis accorder l'utilisation à un autre réseau. Selon l'arrangement, le locataire peut annoncer le préfixe depuis son propre AS, utiliser l'origine du bailleur, ou recevoir des adresses derrière un réseau géré.

BGP peut exposer un changement d'origine sans divulguer l'accord. RDAP peut continuer à identifier le titulaire. RPKI peut contenir une ROA autorisant l'AS du locataire. Le DNS inverse peut pointer vers le locataire, ses clients ou l'infrastructure du bailleur. Pris ensemble, ces signaux peuvent soutenir une hypothèse de location.

Ils ne peuvent pas prouver la relation de paiement. Le même modèle peut résulter d'un routage externalisé, d'une filiale, d'une réaffectation de client, d'une fusion non encore reflétée dans la marque publique ou d'un service de sécurité géré. La cartographie d'entreprise et la confirmation des parties sont nécessaires avant d'étiqueter un cas spécifique.

La location signifie également qu'un bloc peut être économiquement productif avant qu'un modèle de route publique propre n'émerge. Un bailleur peut préparer la plage, réparer la réputation et mettre en place les clients progressivement. Le locataire peut annoncer des plus spécifiques sous une route couvrante. Certaines adresses peuvent desservir des interconnexions privées ou des services à accès limité que les collecteurs larges et les analyses n'observent pas.

Pour l'analyse du marché, la distinction utile est entre le contrôle reconnu de premier niveau et l'utilisation opérationnelle. Les deux doivent être enregistrés. Un titulaire peut être économiquement actif en fournissant de la capacité même s'il n'est pas l'AS d'origine. Un opérateur peut dépendre d'adresses qu'il ne possède pas ou ne détient pas au premier niveau.

Cela a des conséquences de gouvernance. Si un registre essaie de déduire une location interdite d'une discordance d'origine, il risque de punir des relations de réseau ordinaires. S'il ignore entièrement les rôles opérationnels, les contacts d'abus et de continuité peuvent pointer vers la mauvaise partie. La réponse est la clarté des rôles, pas l'identité forcée.

Un enregistrement léger peut identifier le titulaire reconnu, un opérateur autorisé facultatif et un contact opérationnel sans publier le loyer, la durée, les listes de clients ou d'autres dispositions sensibles. Le marché peut alors distinguer la location d'une discordance inexpliquée tout en préservant la confidentialité commerciale.

La capacité de réserve a une utilité économique avant l'utilisation routée

Les réseaux sont construits pour les pics et les pannes, pas pour l'élégance d'un jour moyen. Un bloc d'adresses conservé pour la reprise après sinistre peut être précieux précisément parce qu'il n'est pas en production normale. Une réserve de migration client peut empêcher un achat d'urgence. La capacité détenue pour une ouverture de centre de données signé peut soutenir le financement et les engagements de vente avant que le premier routeur ne l'annonce.

La réserve a donc une utilité économique sans routage public actuel. La valeur est l'optionalité. Le titulaire paie pour réduire la probabilité qu'une pénurie future, un bloc contaminé ou une transaction retardée n'interrompe le service.

La télémétrie publique classera souvent la réserve comme silence. Il peut y avoir des ROA ou une délégation inverse préparatoires, mais les opérateurs prudents peuvent aussi attendre. Les plans d'adressage internes et les engagements clients ne sont normalement pas publics. Les chercheurs ne devraient pas exiger leur divulgation simplement pour éviter une étiquette négative.

La méthode défendable est probabiliste. Un bloc acheté par un réseau en exploitation, adjacent à ses avoirs existants, accompagné de nouveaux objets d'autorité et activé lors d'un événement de capacité ultérieur est compatible avec une réserve. Un bloc détenu pendant plusieurs années et proposé à la vente à plusieurs reprises est plus compatible avec un inventaire. Aucune inférence n'est certaine sans preuve des parties.

La réserve modifie également la manière dont la politique d'utilisation doit être jugée. Une règle qui ne reconnaît que les adresses transportant des paquets à la date d'examen pénalise la résilience. Elle encourage les opérateurs à créer un trafic cosmétique ou à annoncer l'espace prématurément. Elle peut rendre la reprise après sinistre moins robuste tout en prétendant à l'efficacité.

La transparence du marché doit distinguer la réserve planifiée de l'inactivité inexpliquée lorsque le titulaire choisit d'attester la différence. L'attestation peut rester confidentielle pour un auditeur, avec une sortie publique limitée à des catégories agrégées et des bandes temporelles vérifiées. Aucun registre n'a besoin de contrats clients ou de schémas de réseau pour maintenir l'enregistrement de premier niveau unique.

Le principe clé est que le routage est une forme d'utilisation, pas la définition de toute valeur. Une police d'assurance est utile avant l'incendie. Les adresses de réserve sont similaires: leur contribution est la capacité de répondre lorsque l'offre ordinaire ne le peut pas.

La renumérotation est lente parce que les dépendances sont réelles

Il est facile de dire qu'un acheteur devrait router immédiatement après la clôture. Il est plus difficile de déplacer un réseau de production sans casser les clients.

Les adresses apparaissent dans la politique de routage, les pare-feu, les listes d'accès, les règles de surveillance, le DNS, les systèmes de géolocalisation, les contrôles de fraude, les listes blanches des partenaires, les certificats, la configuration des applications, la documentation client et les contrats des fournisseurs. Certaines dépendances sont détenues par des tiers qui mettent à jour selon leur propre calendrier. Une migration propre nécessite donc plus qu'une annonce d'origine.

Un acheteur peut d'abord vérifier que les fournisseurs en amont acceptent la plage et que les filtres de route ont rattrapé l'enregistrement. Il peut créer des ROA, demander une délégation DNS inverse, corriger la géolocalisation, tester les services de réputation et informer les clients. Pendant le basculement, il peut annoncer les anciennes et nouvelles plages ensemble. Il peut déplacer d'abord les services à faible risque, puis les bases de données, les partenaires de paiement ou les clients réglementés.

La séquence BGP peut sembler désordonnée. L'ancienne origine peut persister. De nouveaux plus spécifiques peuvent apparaître brièvement. Une route couvrante peut masquer la limite transférée. Certaines routes peuvent être invalides jusqu'à ce que les autorisations soient corrigées. Un instantané quotidien pourrait étiqueter chaque phase différemment.

C'est pourquoi la première apparition de route ne suffit pas. L'étude doit estimer une date de stabilisation: le point après lequel l'origine, la visibilité et l'autorisation restent dans une plage définie pendant une période soutenue. Elle doit également conserver le retrait de l'ancien bloc et la durée de chevauchement lorsqu'il est visible.

La renumérotation échouée nécessite un traitement séparé. Si la nouvelle plage est contaminée par des erreurs de géolocalisation ou de réputation, l'acheteur peut inverser le mouvement. Si un partenaire critique refuse les adresses, le déploiement peut caler. Le transfert de registre peut rester valide alors que le projet opérationnel échoue.

Ce sont des signaux de qualité du marché. Un bloc légalement transférable mais coûteux à intégrer vaut moins. Des preuves sur le temps jusqu'au routage stable, les erreurs d'autorisation et la transition du DNS inverse peuvent aider les acheteurs à évaluer ce risque. Les preuves devraient améliorer la diligence raisonnable, pas devenir une raison pour une institution d'approuver le plan d'affaires de l'acheteur.

L'usage futur n'est crédible que si la revendication temporelle peut être testée

« Usage futur » peut expliquer n'importe quel bloc silencieux, ce qui le rend facile à invoquer et difficile à évaluer. Une catégorie crédible a besoin d'un horizon et de preuves.

Les preuves pourraient être un engagement client signé, un bail d'installation, un achat d'équipement, un plan de capacité approuvé par le conseil, une condition de financement ou un calendrier de migration. Rien de tout cela ne doit être public. Un examinateur indépendant peut vérifier l'existence et la date des preuves sans révéler les contreparties ou les montants. La classification publique peut dire « utilisation engagée vérifiée dans les douze mois » et signaler plus tard si l'activation a eu lieu.

L'idée n'est pas de faire revivre un test de besoins par la porte arrière. Le marché n'a pas besoin d'un administrateur pour décider si le projet mérite des adresses. Les preuves servent la recherche et la divulgation volontaire. Un acheteur qui ne souhaite pas divulguer peut rester dans la catégorie non observée sans perdre la reconnaissance.

Le temps rend la revendication responsable. Si l'horizon déclaré passe, l'enregistrement peut passer à retardé, réserve, échec d'intégration, loué, détenu ou production routée. La revendication originale reste dans l'historique. Cela permet aux chercheurs d'estimer à quelle fréquence les plans engagés se matérialisent sans transformer les échecs en mauvaise conduite.

Les preuves d'usage futur sont particulièrement importantes pour les grandes transactions. Un déploiement à très grande échelle peut nécessiter de longs délais et une coordination multirégionale. Un petit fournisseur d'accès peut avoir besoin d'adresses immédiatement pour un lancement. Appliquer une période de grâce unique aux deux serait arbitraire.

La catégorie peut également exposer des frictions de financement. Un prêteur peut exiger la reconnaissance du registre avant de débloquer des fonds pour l'équipement. L'acheteur peut donc d'abord conclure l'acquisition d'adresses et construire le réseau ensuite. Le silence pendant cet intervalle n'est pas une preuve que l'acquisition manquait de but; cela peut être une conséquence de la séquence de financement.

De bonnes données permettraient au marché de comparer l'horizon promis, l'activation réelle et les raisons du retard. Elles ne donneraient pas à un registre le pouvoir d'annuler une acquisition parce qu'un projet a glissé. L'échec commercial appartient aux parties à moins qu'une autre revendication légale ne soit établie.

L'échec d'intégration est une preuve que le marché du transfert ne devrait pas effacer

Les statistiques de transfert terminé traitent généralement la reconnaissance comme un succès. Du point de vue du service de registre, c'est compréhensible. L'enregistrement a changé correctement. D'un point de vue économique, un acheteur peut encore perdre.

L'échec d'intégration se produit lorsque le plan de route, de location ou de déploiement client prévu ne devient pas durable. La réputation de l'adresse peut rendre le courrier ou les services grand public inutilisables. Les fournisseurs de géolocalisation peuvent placer la plage dans le mauvais pays. Les filtres en amont peuvent rejeter les annonces. Une acquisition d'entreprise peut se défaire. Un client majeur peut annuler. Le financement peut disparaître après la clôture.

Les signaux publics peuvent révéler une partie de l'échec. Une annonce de courte durée suivie d'un retrait, une invalidité d'origine répétée, des changements rapides dans le DNS inverse ou une revente ultérieure peuvent former un modèle. Rien ne prouve la cause. Des entretiens avec les parties, des dossiers de courtier, des tickets de support et des vérifications de réputation datées peuvent être nécessaires.

La catégorie est importante parce que le silence après le transfert est autrement interprété comme une détention délibérée. Cela cache une mauvaise qualité de bloc et une friction institutionnelle. Si un acheteur a essayé et échoué à router, le marché a besoin de savoir quels obstacles se répètent. Une meilleure diligence raisonnable, une correction de géolocalisation, des appels de réputation et une préparation en amont peuvent réduire ces échecs.

C'est également important pour les études de prix. Un bloc échoué peut revenir sur le marché avec une décote. Si les chercheurs qualifient la période de détention de spéculation, ils manquent le choc de qualité qui a causé la revente. Ils peuvent alors blâmer l'acheteur pour un résultat créé par des défauts opérationnels cachés.

Les données d'échec peuvent rester confidentielles. Le rapport agrégé peut identifier la proportion de cas contribués affectés par la réputation, l'acceptation de routage, un litige, une annulation de client, un coût d'intégration ou une cause inconnue. Les contributeurs doivent divulguer la couverture afin que la clientèle d'un courtier ne soit pas présentée comme l'ensemble du marché.

Un marché de capitaux mature apprend des déploiements échoués, pas seulement de la paperasserie terminée. Le registre n'a pas besoin de garantir le succès commercial. Il doit simplement éviter de décrire la reconnaissance comme une preuve que l'intégration économique a eu lieu.

La production routée a besoin d'une échelle de confiance

Parce que chaque source de preuve est partielle, la production routée devrait être graduée plutôt qu'affirmée comme un fait unique.

Niveau un: annonce observée.Le préfixe exact ou un plus spécifique apparaît chez un ou plusieurs collecteurs BGP nommés. Enregistrez l'heure, l'origine et le nombre de points de vue. C'est une preuve directe d'une annonce atteignant ces observateurs.

Niveau deux: propagation soutenue.La route reste visible pendant une part déclarée de jours et à travers plusieurs collecteurs ou pairs indépendants. L'origine et la longueur du préfixe sont raisonnablement stables. Cela soutient un routage public continu.

Niveau trois: cohérence d'autorisation.Les routes pertinentes sont couvertes par une autorisation d'origine RPKI cohérente lorsque le titulaire utilise RPKI, avec des fenêtres de transition expliquées. Cela soutient une origination autorisée, pas le trafic.

Niveau quatre: configuration opérationnelle.La délégation inverse, les modèles PTR, les objets IRR ou d'autres configurations publiques correspondent à l'opérateur observé. Cela soutient un déploiement intentionnel.

Niveau cinq: preuve de service.Des observations éthiques et limitées du plan de données ou des dossiers d'opérateur contribués montrent des services actifs, des clients ou du trafic. Cela soutient la production.

L'échelle empêche les fausses équivalences. Un préfixe annoncé pendant une heure lors d'un test ne devrait pas compter comme un bloc visible pendant un an avec une autorisation cohérente et des services. Un bloc sous une route couvrante peut atteindre le niveau quatre ou cinq même sans route exacte.

La confiance doit également diminuer lorsque les preuves sont contradictoires. Une route d'une origine inattendue sans ROA correspondante peut être légitime mais non résolue. Un contact RDAP obsolète affaiblit l'attribution de rôle. Une réponse du plan de données d'une seule adresse ne peut pas établir l'utilisation de tout le bloc.

Les rapports publics peuvent montrer des résultats pondérés par adresse et par préfixe. Les grands agrégats dominent autrement les comptes d'adresses, tandis que les /24 fragmentés dominent les comptes de préfixes. Les deux vues comptent.

Le but n'est pas une étiquette de certification universelle. C'est une méthode de recherche reproductible. Un autre analyste utilisant le même ensemble d'observations devrait pouvoir atteindre le même niveau, voir les mêmes limites et contester l'inférence.

La matrice de preuves doit préserver la contradiction

Une solide étude de transfert ne force pas chaque source à être d'accord. La contradiction est souvent le résultat le plus informatif.

Considérons un bénéficiaire indiqué dans RDAP, une origine associée au vendeur inchangée dans BGP, une nouvelle ROA autorisant cette origine et le DNS inverse toujours sous les serveurs de noms du vendeur. Cela peut décrire un service de transition, une location-vente, une opération gérée ou un transfert incomplet. Les preuves soutiennent la continuité et l'autorisation planifiée. Elles n'identifient pas le contrat.

Considérons maintenant un nouveau bénéficiaire, aucune route exacte, des plus spécifiques actifs sous plusieurs origines tierces, des ROA correspondantes et des noms inverses de marque client. C'est compatible avec une location ou des cessions de clients. Qualifier l'agrégat de non routé serait incorrect.

Un troisième cas peut montrer un nouveau bénéficiaire, une nouvelle ROA, une route exacte pendant trois jours, des plus spécifiques invalides répétés, un retrait et aucune activité ultérieure. Ce modèle soutient une tentative d'intégration instable. Il reste possible que l'opération ait continué en dehors de la visibilité des collecteurs, donc la confiance doit être déclarée.

La matrice doit stocker chaque observation indépendamment: événement de registre, état RDAP, route exacte, couverture plus spécifique, route couvrante, origines, étendue des collecteurs, état RPKI, délégation inverse, densité PTR, signal du plan de données et preuves privées contribuées. La classification est dérivée de la matrice et peut changer lorsque de nouvelles preuves arrivent.

La contradiction ne doit pas être « nettoyée » en choisissant une source faisant autorité pour chaque question. RDAP fait autorité pour l'enregistrement qu'il sert, pas pour la propagation BGP. Les collecteurs BGP sont des témoins directs des routes reçues, pas des contrats. RPKI ne fait autorité que dans sa chaîne de certificats et d'autorisations, pas pour le transfert réel.

Cette architecture produit plus d'incertitude qu'un graphique binaire. Elle produit aussi plus de vérité. Les marchés peuvent tolérer les inconnues lorsqu'elles sont nommées. Ils deviennent dangereux lorsqu'une institution les cache derrière un seul mot de statut.

Une étude de cohorte peut tester le marché sans espionner les opérateurs

Le projet empirique est réalisable avec des données publiques et des contributions confidentielles volontaires. Commencez par toutes les lignes de transfert IPv4 publiées sur une période déclarée. Réconciliez les lignes en cas tout en conservant les préfixes et les types d'événements. Excluez ou signalez séparément les fusions, les événements temporaires et correctifs lorsqu'ils ne peuvent pas être comparés aux acquisitions de marché.

Pour chaque préfixe, collectez une référence de base pré-transfert et une série temporelle post-transfert à la fois de RIS et de RouteViews lorsque disponibles. Mesurez les routes exactes, la couverture d'adresses plus spécifique, les routes couvrantes, les changements d'origine, les jours visibles et l'étendue des observateurs. Conservez les changements d'appartenance des collecteurs afin qu'un changement apparent de visibilité ne soit pas causé par un nouveau pair.

Collectez les observations RPKI à partir d'archives de charges utiles validées datées, pas seulement l'état actuel. Enregistrez les changements d'autorisation et le statut de validation d'origine de route sans traiter « non trouvé » comme un échec. Capturez la délégation DNS inverse et des échantillons de modèles PTR à une densité éthique. Stockez des instantanés RDAP avec les heures de requête et la provenance de la réponse.

Appliquez la classification à sept états à des horizons fixes: par exemple 30, 90, 180 et 365 jours, plus la dernière observation. Les bandes exactes peuvent être débattues, mais elles doivent être déclarées avant d'inspecter les résultats. Autorisez les états non résolus et mixtes.

Invitez les acheteurs, vendeurs, bailleurs, courtiers et opérateurs à fournir des dates d'événements confidentielles et des catégories d'objectif. Exigez des contributeurs qu'ils identifient leur rôle, et dédupliquez le même cas signalé par plusieurs parties. Publiez la part des cas publics couverts par des contributions privées.

Les sorties doivent être descriptives avant d'être causales. Quelle part est devenue observablement routée? Combien de temps jusqu'à une visibilité soutenue? Quelle part est restée couverte par un agrégat? À quelle fréquence les origines ont-elles changé? Quels cas montrent des signaux de location cohérents? Combien de tentatives de déploiement ont échoué? Combien restent inconnus?

Aucun préfixe individuel n'a besoin d'être accusé ou noté publiquement. Les cellules agrégées peuvent être supprimées lorsque le nombre de contributeurs est faible. Les chercheurs peuvent publier les méthodes, la couverture et l'incertitude tout en protégeant les contrats et la sécurité du réseau.

C'est du renseignement de marché plutôt que de la surveillance: mesurer les résultats institutionnels et opérationnels au niveau nécessaire pour comprendre le système, pas pour exposer la topologie des clients.

Les registres devraient publier de meilleures preuves d'événements, pas surveiller l'utilisation ultérieure

Les RIR contrôlent des faits que les collecteurs de routes ne peuvent pas fournir: le type de cas, l'heure de mise à jour de l'enregistrement, le chemin inter-RIR dirigé, les corrections et si plusieurs lignes appartiennent à un seul cas administratif. Publier ces faits de manière cohérente améliorerait l'analyse sans exposer les informations de prix ou de client.

Le journal de transfert commun devrait porter un identifiant de cas stable ou un lien de cas préservant la confidentialité afin qu'un accord fractionné sur plusieurs préfixes ne soit pas compté plusieurs fois. Il devrait distinguer le transfert de politique, la fusion, le changement temporaire, la correction et d'autres types d'événements reconnus. Il devrait conserver les révisions plutôt que de remplacer silencieusement les lignes.

Chaque institution pourrait également publier des horodatages lisibles par machine pour l'acceptation, l'achèvement et la mise à jour de l'enregistrement public, avec des définitions. Rien de tout cela ne nécessite la divulgation du plan d'utilisation interne d'un acheteur.

Ce que les registres ne devraient pas faire, c'est utiliser la télémétrie post-transfert comme un nouveau pouvoir d'approbation. Une alerte d'absence de route peut aider un titulaire à détecter un problème d'intégration. Elle ne devrait pas déclencher une annulation simplement parce que l'institution préfère un routage immédiat. Une discordance d'origine de route peut inciter à un avis de sécurité. Elle ne devrait pas être traitée comme une preuve de location ou de contrôle non autorisé.

La différence est l'intention. Les preuves peuvent améliorer l'exactitude des enregistrements, la sécurité et la qualité du service. Cela devient dangereux lorsqu'un administrateur prétend que la visibilité publique lui donne autorité sur l'objectif commercial.

La séparation du RFC 7020 reste une frontière solide. Les systèmes d'enregistrement préservent l'unicité et des enregistrements exacts. Les opérateurs décident s'il faut annoncer des routes et comment. Les marchés, les contrats et les tribunaux traitent des droits commerciaux et des litiges. Les systèmes de sécurité peuvent valider l'autorisation sans posséder la décision d'investissement.

Un registre qui publie des preuves de transfert précises deviendra plus fiable, pas moins. Il peut dire exactement ce qu'il a fait et laisser à d'autres institutions le soin de prouver les faits relevant de leur compétence.

Les acteurs du marché peuvent transformer les limites de visibilité en diligence raisonnable tarifée

Les acheteurs se soucient déjà de l'historique des routes parce qu'il affecte l'intégration. Un rapport de preuves discipliné peut rendre cette préoccupation comparable.

Le rapport devrait montrer les origines historiques, les annonces exactes et couvrantes, les périodes de silence, les plus spécifiques connus, l'historique RPKI, l'autorité DNS inverse, l'historique RDAP, les événements de transfert, les observations de réputation et les conflits non résolus. Chaque champ a besoin d'un horodatage et d'une source. L'absence doit nommer la portée de l'observation.

Le rapport ne devrait pas certifier « inutilisé ». Il peut dire « aucune route exacte ou plus spécifique observée chez les pairs RIS et RouteViews répertoriés pendant l'intervalle indiqué ». Cette phrase est plus longue et bien plus précieuse. Elle permet à l'acheteur de comprendre ce qui a été testé et ce qui reste inconnu.

Les mêmes preuves peuvent soutenir les vendeurs. Un titulaire peut démontrer une période de retrait propre, un état d'autorité cohérent et l'absence d'enregistrement contradictoire. Un bailleur peut montrer qu'une route de client antérieure s'est terminée. Un acheteur peut conserver le rapport comme référence pour des litiges ultérieurs.

La tarification peut alors refléter les composants de risque réels. Des détournements historiques persistants peuvent réduire la valeur. La fragmentation et l'acceptation des filtres de route peuvent augmenter le coût d'intégration. Une longue période de silence propre peut être positive pour la réputation mais ne dit rien de certain sur le titre. Les ROA existantes peuvent être des actifs ou des risques de transition selon le contrôle et le moment.

La portabilité des preuves est importante. Si le rapport n'existe qu'à l'intérieur du système privé d'un courtier, la partie doit racheter son propre historique lors de la transaction suivante. Un enregistrement signé et exportable permet au titulaire de transporter les observations entre fournisseurs et de contester les erreurs.

Le marché n'a pas besoin d'un score unique. Les notes composites cachent des compromis. Il a besoin de faits datés et d'inférences explicites. Un acheteur peut valoriser un long historique non routé; un autre peut préférer un bloc avec une propagation mondiale prouvée. Un rapport neutre permet les deux choix sans décider quelle entreprise mérite la ressource.

La NRS peut héberger une norme de preuve portable sans devenir un tribunal d'utilisation

La Société des ressources numériques (NRS) peut apporter une contribution constructive en définissant un enregistrement de preuve de transfert ouvert. Cet enregistrement ne déterminerait pas le prix, n'approuverait pas l'objectif ni ne déciderait si la détention est vertueuse. Il préserverait les observations et leurs limites.

Au minimum, l'enregistrement pourrait lier un reçu de transfert reconnu à des réponses RDAP datées, des résumés de visibilité BGP, des changements RPKI, une délégation DNS inverse et des attestations privées volontaires. Chaque observation identifierait son collecteur, sa source de requête, sa plage temporelle, sa méthode et sa confiance. Les états dérivés seraient versionnés afin que les preuves ultérieures n'effacent pas le raisonnement antérieur.

Le titulaire devrait pouvoir exporter l'enregistrement et le transférer à un autre fournisseur de services. Les chercheurs devraient pouvoir implémenter la méthode publique indépendamment. Des analystes concurrents peuvent être en désaccord sur l'interprétation tout en s'accordant sur les observations sous-jacentes.

Les preuves confidentielles peuvent être représentées par une déclaration vérifiable qu'un examinateur autorisé a inspecté un document daté soutenant la réserve, la location ou l'usage futur engagé. La déclaration n'a pas besoin de révéler le client, le prix, la durée ou la conception du réseau. La participation doit être volontaire; le refus doit laisser l'état inconnu, pas créer une présomption négative.

La NRS devrait également publier la couverture. Un résumé BGP doit identifier quelles familles de collecteurs et quels pairs ont été utilisés. Un rapport de DNS inverse doit indiquer la densité d'échantillonnage. Une déclaration RPKI doit identifier le moment de l'observation. La portabilité sans provenance ne ferait que faire voyager plus vite des affirmations faibles.

C'est un rôle institutionnel étroit avec une valeur pratique élevée. Il réduit la diligence raisonnable répétée, rend les transitions d'état comparables et préserve les preuves lorsqu'un courtier, un registre ou une plateforme change. Il ne place pas la NRS au-dessus de l'opérateur.

Le test positif est simple: un titulaire peut-il quitter le service de preuve avec une copie complète et vérifiable et continuer à fonctionner? Si oui, le service soutient le marché. Si le départ entraîne la perte de validité des preuves ou la perte de reconnaissance des adresses, le service est devenu un autre gardien.

La limite de visibilité doit apparaître dans chaque conclusion

Il n'y a pas de caméra globale au-dessus de BGP. RIS et RouteViews observent les routes reçues de pairs entités. Leur ampleur les rend indispensables, mais pas omniscients. La composition des pairs change. La politique d'exportation cache des chemins. L'agrégation cache des limites de transfert. Les interconnexions privées et les services restreints peuvent rester invisibles.

Il n'y a pas de recensement RPKI complet de l'utilisation. Une ROA est une autorisation. Elle peut précéder, survivre ou ne jamais accompagner une route. « Non trouvé » n'est pas « inutilisé ». L'invalidité peut refléter une erreur d'intégration plutôt qu'une opération non autorisée.

Il n'y a pas de recensement DNS inverse complet de l'occupation. Les noms peuvent être absents d'adresses actives, présents sur des adresses inactives, délégués à différentes limites ou conservés pendant une transition.

Il n'y a pas de réponse d'enregistrement qui énumère chaque rôle économique. RDAP peut fournir des données d'enregistrement faisant autorité tout en omettant une location, une opération de client ou une relation bénéficiaire. Les champs de contact et de statut publics sont limités par la politique et la confidentialité.

Même les preuves privées ont un biais de sélection. Les entités ayant des déploiements réussis peuvent contribuer plus facilement que les acheteurs ayant échoué. Les courtiers voient des transactions sélectionnées. Les grands opérateurs tiennent de meilleurs registres que les petits. Chaque estimation agrégée devrait publier la couverture et la composition des contributeurs.

Ces limites ne rendent pas la recherche impossible. Elles définissent les affirmations que les preuves peuvent soutenir. « Routage soutenu observé » est défendable. « Aucune route observée à ces points de vue » est défendable. « L'acheteur n'a jamais utilisé le bloc » ne l'est généralement pas.

La discipline devrait survivre aux gros titres. Une conclusion dramatique sur l'espace transféré silencieux attirera l'attention. La phrase méthodologique ne doit pas disparaître du résumé public. Si l'incertitude est trop importante pour la note de bas de page, elle appartient à la conclusion.

L'accord qui n'a jamais routé peut encore avoir changé l'économie du réseau

Un transfert reconnu par un registre est important. Il modifie la relation enregistrée autour d'un intrant opérationnel rare. Il peut débloquer un financement, régler une acquisition, permettre une location, créer une capacité de réserve ou commencer une migration. Il peut également laisser un acheteur avec un bloc qui ne fonctionne jamais comme prévu.

Les preuves de routage sont tout aussi importantes. BGP peut montrer si des annonces sont apparues, comment les origines ont changé et dans quelle mesure les routes se sont propagées parmi les pairs observés. RPKI peut montrer l'autorisation. Le DNS inverse peut montrer la configuration. RDAP peut montrer l'enregistrement. Aucun ne doit se faire passer pour les autres.

Le marché a besoin des sept états parce que le silence a des causes. La détention, la location, la réserve, la renumérotation, l'usage futur, l'échec d'intégration et la production routée diffèrent économiquement et institutionnellement. Certains sont visibles. Certains ne peuvent être vérifiés que privément. Certains restent inconnus.

L'interdiction centrale est donc analytique, pas commerciale: ne convertissez pas « non observé » en « spéculatif » sans preuve de mobile et de préjudice. La rareté crée des incitations, mais elle n'abroge pas les règles d'inférence.

Un meilleur marché du transfert préserverait l'événement de registre, collecterait les observations opérationnelles au fil du temps, publierait la couverture, protégerait les conditions confidentielles et permettrait aux preuves de voyager avec le titulaire. Les registres resteraient des conservateurs de registres exacts. Les opérateurs resteraient responsables des routes. Les chercheurs exprimeraient l'incertitude. Les acheteurs évalueraient le risque d'intégration plutôt que de se fier au folklore.

L'accord qui a été conclu mais jamais routé n'est pas une contradiction. C'est un rappel qu'un transfert IPv4 peut être un événement juridique, un événement institutionnel, un projet d'exploitation et un investissement à des moments différents. Les preuves ne deviennent utiles que lorsque ces moments et ces rôles sont maintenus séparés.

Sources