Résumé

  • Un transfert reconnu par le 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 en détention, location, réserve opérationnelle, renumérotation, utilisation future engagée, intégration échouée ou production routée. Un bloc peut passer d'un état à un autre, et plusieurs états peuvent s'appliquer à différentes portions de la même plage transférée.
  • BGP est la preuve publique la plus solide d'origine et de propagation de route, 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 un cadre qui n'expose pas la partie commerciale.
  • RPKI ajoute une preuve d'autorisation d'origine, et non une preuve qu'une route existe ou transporte du trafic. Le DNS inverse ajoute une preuve de délégation et de nommage, et non d'utilisation. RDAP ajoute des informations d'enregistrement et de contact, et non un recensement opérationnel. Chaque source répond à une question différente.
  • Le temps est essentiel. Une étiquette quotidienne apposée à la date de transfert classera à tort les étapes normales. L'étude doit conserver les références pré-transfert, observer les routes exactes et englobantes, mesurer les changements d'origine et de visibilité, et laisser les cas non résolus ouverts plutôt que de les forcer dans les catégories « utilisé » ou « inutilisé ».
  • Le non-routage ne doit jamais être traité automatiquement comme de la spéculation. La capacité de réserve, la reprise après sinistre, la renumérotation progressive, les engagements clients, les conditions de financement, le contentieux, la contamination technique et l'intégration abandonnée peuvent tous produire du silence sans prouver une intention manipulatrice.
  • De meilleures preuves de marché publieraient les transitions d'état, la couverture d'observation et l'incertitude sans exiger de contrats confidentiels. Le registre doit conserver un historique précis des transferts; les opérateurs, chercheurs et acteurs du marché doivent pouvoir tester ce qui s'est passé ensuite sans transformer la télémétrie réseau en licence d'approbation commerciale.

Une clôture n'est pas un paquet

Le titre décrit une erreur analytique courante plutôt qu'un scandale unique. Un acheteur et un vendeur conviennent de conditions. Les vérifications requises sont effectuées. Un registre change le détenteur 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. Cette réponse peut être correcte 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 destinataire, un préfixe, une date, un code de pays et indiquer si l'événement était un transfert politique ou un changement de structure d'entreprise. Il marque un événement institutionnel. Il ne divulgue pas le marché privé, la date de règlement, les conditions de financement, les arrangements de location, le plan de migration, les contrats clients ou la conception du réseau interne.

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é a transporté une annonce pour un préfixe à un moment donné. Elle n'identifie pas le propriétaire réel. Elle ne montre pas le prix d'achat. Elle ne montre pas si des paquets ont atteint un service fonctionnel. Elle ne nous dit pas si la route provient d'un preneur, 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 la frontière particulièrement claire. L'exactitude de l'enregistrement et l'unicité sont des objectifs du registre, tandis que la question de savoir si les adresses sont effectivement annoncées et comment elles sont annoncées sont des questions opérationnelles hors du périmètre du système de registre. La rareté n'a pas effacé cette séparation. Elle a rendu les conséquences de son oubli plus coûteuses.

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

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 conservé pour la croissance, des blocs plus petits loués à des clients et une partie en cours de nettoyage après un abus antérieur. Une seule étiquette pour l'ensemble du /16 détruit l'information même dont le marché a besoin.

Une classification plus utile commence par sept états.

Détentionsignifie que le destinataire conserve le contrôle reconnu sans assez de preuves pour attribuer un objectif opérationnel immédiat. La détention est une description, pas un jugement. Elle couvre une position longue de type pension, une position de stock, 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 obtient une utilisation contractuelle tandis que le détenteur enregistré de premier niveau peut rester inchangé. Le preneur peut être à l'origine des 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 incohérente avec le nom enregistré sans expliquer le contrat.

Réservesignifie que le bloc est conservé comme assurance opérationnelle ou capacité planifiée. La reprise après sinistre, les plans de continuité en cas de fusion, le basculement client, la séparation de réputation d'adresse et une marge pour une croissance soudaine peuvent tous créer une valeur d'option avant l'apparition d'une route publique. 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 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.

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

Intégration échouéesignifie que l'utilisation prévue ne s'est pas matérialisé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. Ceci est commercialement important car un transfert clos peut encore échouer en tant qu'investissement.

Production routéesignifie que le bloc est observablement annoncé et soutenu par des signes supplémentaires cohérents avec une exploitation. Même cette catégorie a besoin de 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 préfixe stable le plus spécifique soutenu par les données et doit préserver les transitions. La question n'est pas « L'accord a-t-il été utilisé? » mais « 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

Leformat de journal de transfert NROcourant donne aux chercheurs un point de départ précieux. Il permet aux RIR de publier des enregistrements de transfert intra-régionaux et inter-régionaux cumulatifs dans une structure JSON partagée. La valeur est la comparabilité: un préfixe, un type de transfert, une source, un destinataire, une date et des champs régionaux connexes peuvent être normalisés entre institutions.

Cet enregistrement partagé n'est toujours pas un registre de tous les faits commerciaux. Une ligne de transfert peut représenter un préfixe plutôt qu'un accord entier. Une acquisition commerciale peut être divisée en plusieurs lignes parce que l'espace d'adressage a été 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 ensuite être divisé entre différents arrangements opérationnels.

Le type d'événement compte également. Lesstatistiques de transfert du RIPE NCCdistinguent les transferts politiques 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 temporaire d'enregistrement n'est pas équivalent à une cession définitive. Compter chaque ligne comme un actif acheté corromprait à la fois l'analyse des prix et celle du déploiement.

La date publiée doit également être interprétée avec soin. Laspécification historique du journal de transfert d'APNICdécrit la date de transfert comme la date à laquelle le destinataire a reçu la ressource dans l'enregistrement. Cette date est un 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 rapproché. Les lignes avec les mêmes parties, type d'événement, chemin institutionnel et date de clôture peuvent être liées, tout en préservant chaque préfixe. Le cas doit conserver au moins trois horloges: accord ou règlement lorsque des contributeurs confidentiels peuvent le fournir, reconnaissance par le registre et premier changement d'état opérationnel observé.

L'analyse publique peut procéder sans connaître le prix. Elle peut se demander comment le préfixe s'est comporté avant et après la reconnaissance par le 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 publique de routage et une vue incomplète

LeRFC 4271définit BGP comme un échange d'informations d'accessibilité soumis à une politique de routage locale. Les annonceurs reçoivent des routes, choisissent entre 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 de registre ne peut.

Cela explique aussi pourquoi un collecteur n'est pas Internet. LeService d'Information de Routagedu RIPE reçoit les mises à jour et les retraits BGP de réseaux qui se connectent volontairement à ses collecteurs de routes. RouteViews archive également 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 routage devrait 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 première date de visibilité, la dernière date de visibilité, le nombre de pairs collecteurs, le nombre de collecteurs distincts et la persistance de l'observation.

Le deuxième test devrait rechercher des spécifications plus précises. Le /20 peut ne jamais apparaître comme une seule route car 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 nombre d'adresses et temps, en veillant à ne pas compter deux fois les routes qui se chevauchent.

Le troisième test devrait rechercher des routes englobantes. 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 via cet agrégat sans exposer un /20 séparé. Un collecteur de routes ne révélera pas la frontière transférée car l'agrégation de routage fait exactement ce pour quoi elle a été conçue.

Le quatrième test devrait mesurer la continuité et le changement d'origine. Une nouvelle origine après un 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 encore le réseau temporairement, que les parties appartiennent au même groupe d'entreprises, que l'acheteur a acquis la société exploitante, ou que l'espace d'adressage est reloué. La continuité d'origine est une preuve, pas un verdict.

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

La visibilité d'une route n'est pas le trafic, le service ou le revenu

Une route BGP stable est une preuve plus solide 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 partie. 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 terminaux actifs derrière un /20, tandis qu'un autre opérateur annonce un bloc de même taille pour une poignée de systèmes d'infrastructure. BGP traite les deux comme une seule annonce de préfixe.

L'erreur opposée compte aussi. Une route peut être visible alors qu'aucun service utile n'est disponible. Un acheteur peut annoncer un bloc brièvement pour tester des filtres ou mettre à jour des 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 une production autorisée.

Les mesures du plan de données peuvent ajouter du contexte. Des adresses répondantes, des réponses DNS, des poignées de main TLS et des mesures de chemin peuvent soutenir 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 des réseaux sélectionnés. 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. Le balayage éthique limite ce qui devrait être tenté.

L'échelle de preuve doit donc être explicite. Une observation de route prouve la visibilité aux points d'observation 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. Des enregistrements de clients ou d'opérateurs peuvent soutenir une utilisation productive sous confidentialité. Aucun échelon ne doit être requalifié comme utilisation économique complète.

Cette distinction compte pour l'évaluation du marché. Les acheteurs se soucient de savoir si un bloc peut être routé proprement, mais ils se soucient aussi de la réputation, de la géolocalisation, de l'acceptation par l'amont, de la demande des clients et des coûts internes. 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 l'autre sens. Une autorisation d'origine de route (ROA) semble fournir un lien net 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. LeRFC 6480explique que les informations d'allocation dans l'infrastructure à clé publique des ressources ne suffisent pas à guider les décisions de routage. Une ROA rend explicite une autorisation d'origine. Elle indique qu'un AS est autorisé à être à l'origine d'une route pour un préfixe dans la longueur autorisée. L'autorisation n'est pas une annonce.

Un destinataire 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 preneur. 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 de ROA est tout aussi ambiguë. L'adoption de RPKI est incomplète. Un opérateur peut router valablement dans le 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 l'exploitation.

LeRFC 6811ajoute deux mises en garde supplémentaires. La validation d'origine attribue un état à une route BGP reçue; elle n'atteste pas la totalité du chemin AS. Les routeurs appliquent ensuite une politique locale à l'état de validation. Différents caches peuvent temporairement contenir des vues différentes car les objets signés sont distribués et actualisés 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 de type « make-before-break »? 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 cohérente avec une utilisation future, une réserve, un lancement échoué ou un acheteur prudent. Pas de ROA et aucune route observée est cohérent avec une détention, un usage privé, un routage couvert ou une 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 souvent 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 aux 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 épars 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 peu divulguer.

Les limites de délégation compliquent également la mesure. LeRFC 2317décrit la délégation inverse sans classe pour les plages plus petites qu'un /24. La configuration technique peut utiliser des alias et des zones filles qui ne correspondent pas facilement à 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 signal de changement daté. De nouveaux serveurs de noms faisant autorité proches de la date de transfert peuvent soutenir une inférence d'intégration. Un changement du modèle de nommage du vendeur à celui de l'acheteur peut marquer une renumérotation. Des enregistrements PTR diversifiés au nom du client peuvent soutenir une production ou une 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 vérifié de manière forward-confirmed 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 était faisant autorité. Les études DNS inverses en masse 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 devient trompeur seulement lorsqu'un indice de configuration est traité comme un compteur d'occupation.

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

RDAP modernise l'accès aux informations d'enregistrement. LeRFC 7480définit son utilisation via HTTP, tandis que leRFC 9082définit les requêtes pour les ressources de numéros Internet et les enregistrements connexes. LeRFC 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, le statut, 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 plus automatisable que les anciennes sorties WHOIS.

Il reflète toujours l'enregistrement, pas tous les rôles économiques. L'entité listée peut être le détenteur reconnu, une société mère, un contact administratif, un contact contre les abus ou un autre rôle défini par le service. L'opérateur annonçant la route peut être une filiale, un client, un preneur, 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 incompatibilité d'origine en supposant qu'une source est erronée. Si RDAP nomme la société A et BGP montre une origine associée à la société B, la relation est inconnue jusqu'à confirmation. Il peut s'agir d'un bail légitime, d'un arrangement d'externalisation, d'une fusion, d'une affectation client ou d'une structure de groupe. Il peut aussi s'agir d'un détournement. L'incompatibilité est une piste de recherche, pas une conclusion d'inconduite.

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 un délai. Les instantanés historiques sont donc importants; une requête actuelle ne peut pas reconstruire tous les états intermédiaires.

La déclaration d'enregistrement la plus solide est étroite: au moment indiqué, le service RDAP faisant autorité a renvoyé l'enregistrement indiqué pour la plage interrogée. Cela peut valider une ligne de transfert publique 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 les indices faibles en une séquence crédible

Un instantané d'un seul jour est presque garanti pour exagérer la certitude. Les transferts et les migrations de réseau sont des processus. La preuve devient utile lorsqu'elle est placée sur une chronologie commune.

La ligne de base doit commencer avant le premier événement commercial ou de registre connu. Au minimum, l'étude a besoin d'assez d'historique pour distinguer un bloc véritablement silencieux d'un bloc qui était annoncé par intermittence. Elle doit enregistrer les routes exactes, plus spécifiques et englobantes; les origines; la visibilité du collecteur; les ROA; la délégation inverse; les données du détenteur RDAP; et les signaux évidents du plan de données.

La fenêtre de transfert a ensuite besoin de marqueurs d'événement. Ceux-ci peuvent inclure la date de transfert publique, le changement RDAP, le retrait de l'ancienne route, la création de la nouvelle ROA, l'apparition de la 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 séquestre, la soumission au registre, le règlement et le lancement client peuvent être inclus sous confidentialité.

Après le transfert, l'observation doit continuer assez longtemps pour capturer les étapes normales 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, une mise en location ou une revente. Aucun seuil universel ne transforme 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 de stock. Une route brève, une invalidité répétée et un retrait peuvent soutenir une intégration échouée. Chacune reste une inférence avec une étiquette de confiance.

L'intermittence mérite sa propre mesure. Un bloc vu deux jours sur un an diffère d'un bloc vu quotidiennement. L'étendue du collecteur compte aussi. Les dates de première et dernière visibilité 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 devrait résister à la pression de faire rentrer chaque ligne dans un tableau 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 ensemble de faits, 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 destinataire. Aucune ROA ni délégation inverse ne change. Le destinataire transfère ensuite le bloc à nouveau. C'est une preuve solide d'une période de détention sans production routée publique.

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

La gouvernance du marché efface souvent cette distinction parce que la « détention » sonne passif et que la rareté donne un poids politique à la passivité. Pourtant, tout marché de capitaux contient des stocks et une valeur d'option. Un opérateur conserve des routeurs de rechange, des paires de fibres, une capacité cloud et de l'argent liquide. La question pertinente n'est pas de savoir si un intrant est resté inutilisé à un moment donné. C'est de savoir si le comportement 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 gros 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 représentation.

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, soutenue par un comportement de transaction ou une intention divulguée. Même alors, la spéculation n'est pas synonyme d'abus. Une analyse séparée doit montrer une tromperie, une rareté artificielle, une manipulation, un contournement de politique 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 sont restés non observés à un an serait significative si la couverture et les définitions d'état étaient solides. Appeler les mêmes adresses « accaparées » ajouterait de la rhétorique et supprimerait la précision.

Le marché a besoin d'une mesure 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 détenteur transféré et une origine de route peuvent différer. Un acheteur peut acquérir le contrôle reconnu puis accorder l'utilisation à un autre réseau. Selon l'arrangement, le preneur 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 détenteur. RPKI peut contenir une ROA autorisant l'AS du preneur. Le DNS inverse peut pointer vers le preneur, ses clients ou l'infrastructure du bailleur. Ensemble, ces signaux peuvent soutenir une hypothèse de location.

Ils ne peuvent pas prouver la relation de paiement. Le même motif peut résulter d'un routage externalisé, d'une filiale, d'une réaffectation client, d'une fusion non encore reflétée dans la marque publique ou d'un service de sécurité géré. Un mapping d'entreprise et une 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 motif de route publique clair n'émerge. Un bailleur peut préparer la plage, réparer la réputation et installer les clients progressivement. Le preneur peut annoncer des plus spécifiques sous une route englobante. Certaines adresses peuvent servir des interconnexions privées ou des services à accès limité que les collecteurs et balayages larges n'observent pas.

Pour l'analyse du marché, la distinction utile est entre le contrôle enregistré de premier niveau et l'utilisation opérationnelle. Les deux doivent être enregistrés. Un détenteur 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 niveau supérieur.

Cela a des conséquences en matière de gouvernance. Si un registre tente de déduire une location interdite à partir d'une incompatibilité d'origine, il risque de punir des relations 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 une identité forcée.

Un enregistrement léger peut identifier le détenteur 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 incompatibilité inexpliquée tout en préservant la confidentialité commerciale.

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

Les réseaux sont construits pour les pics et les pannes, pas pour l'élégance de la moyenne journalière. 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 pour migration client peut empêcher un achat d'urgence. Une capacité détenue pour l'ouverture d'un centre de données signé peut soutenir le financement et les engagements commerciaux avant que le premier routeur ne l'annonce.

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

La télémétrie publique classera souvent la réserve comme du silence. Il peut y avoir des ROA préparatoires ou une délégation inverse, 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 doivent 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 cohérent avec une réserve. Un bloc détenu pendant plusieurs années et offert à plusieurs reprises à la vente est plus cohérent avec un stock. Aucune inference n'est certaine sans preuve des parties.

La réserve change aussi la façon dont la politique d'utilisation devrait ê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 du trafic cosmétique ou à annoncer l'espace prématurément. Elle peut rendre la reprise après sinistre moins robuste tout en revendiquant l'efficacité.

La transparence du marché devrait distinguer la réserve planifiée de l'inactivité inexpliquée, le détenteur choisissant d'attester la différence. L'attestation peut rester confidentielle pour un auditeur, avec une sortie publique limitée aux catégories agrégées et aux bandes de temps vérifiées. Aucun registre n'a besoin de contrats clients ou de diagrammes 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 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 d'autorisation des partenaires, les certificats, la configuration des applications, la documentation client et les contrats fournisseurs. Certaines dépendances sont détenues par des tiers qui mettent à jour selon leurs propres calendriers. Une migration propre nécessite donc plus qu'une annonce d'origine.

Un acheteur peut d'abord vérifier que les amonts acceptent la plage et que les filtres de route ont rattrapé l'enregistrement. Il peut créer des ROA, demander la délégation DNS inverse, corriger la géolocalisation, tester les services de réputation et notifier les clients. Pendant la transition, il peut annoncer ensemble les anciennes et nouvelles plages. Il peut d'abord déplacer 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 nouvelles spécifications plus précises peuvent apparaître brièvement. Une route englobante peut masquer la frontière 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 d'une route ne suffit pas. L'étude devrait 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 devrait également conserver le retrait de l'ancien bloc et la durée de chevauchement là où c'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 annuler le déménagement. Si un partenaire critique refuse les adresses, le déploiement peut stagner. Le transfert de registre peut rester valide alors que le projet opérationnel échoue.

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

L'utilisation future n'est crédible que lorsque la revendication temporelle peut être testée

« Utilisation future » peut expliquer tout bloc silencieux, ce qui la rend facile à invoquer et difficile à évaluer. Une catégorie crédible a besoin d'un horizon et de preuves.

La preuve peut ê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 ne doit être public. Un réviseur indépendant peut vérifier l'existence et la date de la preuve 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 rapporter plus tard si l'activation a eu lieu.

Le but n'est pas de raviver un test de besoin par la porte dérobée. Le marché n'a pas besoin qu'un administrateur décide si le projet mérite des adresses. La preuve sert la recherche et la divulgation volontaire. Un acheteur qui ne souhaite pas divulguer peut rester dans la catégorie non observée sans perdre sa reconnaissance.

Le temps rend la revendication responsable. Si l'horizon indiqué passe, l'enregistrement peut passer en retard, réserve, intégration échouée, location, détention ou production routée. La revendication originale reste dans l'histoire. Cela permet aux chercheurs d'estimer à quelle fréquence les plans engagés se matérialisent sans transformer les échecs en inconduite.

La preuve d'utilisation future est particulièrement importante pour les grandes transactions. Un déploiement hyperscale peut nécessiter de longs délais et une coordination multi-région. Un petit fournisseur d'accès peut avoir besoin d'adresses immédiatement pour un lancement. Appliquer un même délai de grâce aux deux serait arbitraire.

La catégorie peut aussi exposer les frictions de financement. Un prêteur peut exiger la reconnaissance du registre avant de libérer des fonds pour l'équipement. L'acheteur peut donc clore d'abord 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; il 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 au registre le pouvoir d'annuler une acquisition parce qu'un projet a pris du retard. L'échec commercial appartient aux parties à moins qu'une autre réclamation légale ne soit établie.

L'intégration échouée est une preuve que le marché des transferts ne devrait pas effacer

Les statistiques de transfert achevé 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'intégration échouée se produit lorsque la route planifiée, la location ou le déploiement client ne devient pas durable. La réputation des adresses peut rendre les services de messagerie ou grand public inutilisables. Les fournisseurs de géolocalisation peuvent placer la plage dans le mauvais pays. Les filtres amont peuvent rejeter les annonces. Une acquisition d'entreprise peut s'effondrer. 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é répétée de l'origine, des changements rapides dans le DNS inverse ou une revente ultérieure peuvent former un motif. Aucun ne prouve la cause. Des entretiens avec les parties, des enregistrements de courtiers, des tickets de support et des vérifications de réputation datées peuvent être nécessaires.

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

Cela compte aussi pour les études de prix. Un bloc échoué peut revenir sur le marché à un prix réduit. Si les chercheurs étiquettent la période de détention comme 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. Un rapport agrégé peut identifier la proportion de cas contribués affectés par la réputation, l'acceptation du routage, un litige juridique, une annulation client, un coût d'intégration ou une cause inconnue. Les contributeurs doivent divulguer la couverture afin que la clientèle d'un seul courtier ne soit pas présentée comme l'ensemble du marché.

Un marché de capitaux mature apprend du déploiement échoué, pas seulement des formalités administratives. 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 doit ê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 d'observation. C'est une preuve directe qu'une annonce a atteint ces observateurs.

Niveau deux: propagation soutenue.La route reste visible sur une part déclarée de jours et sur 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 de l'autorisation.Les routes pertinentes sont couvertes par une autorisation d'origine RPKI cohérente lorsque le détenteur utilise RPKI, avec des fenêtres de transition expliquées. Cela soutient une origine autorisée, pas du trafic.

Niveau quatre: configuration opérationnelle.La délégation inverse, les motifs 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 enregistrements d'opérateurs contribués montrent des services actifs, des clients ou du trafic. Cela soutient la production.

L'échelle empêche la fausse équivalence. Un préfixe annoncé pendant une heure lors d'un test ne doit pas compter autant qu'un bloc visible pendant un an avec une autorisation et des services cohérents. Un bloc sous une route englobante peut atteindre le niveau quatre ou cinq même sans route exacte.

La confiance doit également baisser lorsque les preuves se contredisent. Une route provenant d'une origine inattendue sans ROA correspondante peut être légitime mais non résolue. Un contact RDAP obsolète affaiblit l'attribution du rôle. Une réponse du plan de données provenant d'une seule adresse ne peut pas établir l'utilisation de l'ensemble du 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 preuve doit préserver la contradiction

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

Considérons un destinataire montré dans RDAP, une origine associée au vendeur inchangée dans BGP, une nouvelle ROA autorisant cette origine et un DNS inverse toujours sous les serveurs de noms du vendeur. Cela peut décrire un service de transition, une relocation, une opération gérée ou une passation incomplète. Les preuves soutiennent la continuité et l'autorisation planifiée. Elles n'identifient pas le contrat.

Considérons maintenant un nouveau destinataire, pas de route exacte, des plus spécifiques actives sous plusieurs origines tierces, des ROA correspondantes et des noms inverses au nom du client. C'est cohérent avec une location ou des affectations clients. Qualifier l'agrégat de non routé serait erroné.

Un troisième cas peut montrer un nouveau destinataire, 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 motif soutient une tentative d'intégration mais instable. Il reste possible que l'opération se soit poursuivie en dehors de la visibilité du collecteur, donc la confiance doit être indiquée.

La matrice doit stocker chaque observation indépendamment: événement de registre, état RDAP, route exacte, couverture plus spécifique, route englobante, origines, étendue du collecteur, état RPKI, délégation inverse, densité PTR, signal du plan de données et preuve privée contribuée. 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 fait autorité uniquement dans sa chaîne de certificats et d'autorisations, pas pour le transfert réel.

Cette architecture produit plus d'incertitude qu'un tableau binaire. Elle produit aussi plus de vérité. Les marchés peuvent tolérer des inconnues lorsqu'elles sont nommées. Ils deviennent dangereux lorsqu'une institution les cache derrière un 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. Rapprochez les lignes en cas tout en conservant les préfixes et les types d'événement. Excluez ou rapportez séparément les événements de fusion, temporaires et correctifs lorsqu'ils ne peuvent pas être comparés aux acquisitions sur le marché.

Pour chaque préfixe, collectez une référence pré-transfert et une série temporelle post-transfert à partir de RIS et RouteViews lorsque disponibles. Mesurez les routes exactes, la couverture d'adresse plus spécifique, les routes englobantes, les changements d'origine, les jours visibles et l'étendue des observateurs. Gardez la trace des changements de composition 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 de l'origine de route sans traiter « non trouvé » comme un échec. Capturez la délégation DNS inverse et des échantillons de motifs PTR à une densité éthique. Stockez des instantanés RDAP avec les heures de requête et la provenance des réponses.

Appliquez la classification en 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 à contribuer des dates d'événement confidentielles et des catégories de finalité. 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 résultats doivent être descriptifs avant d'être causals. Quelle part est devenue observablement routée? Combien de temps pour 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 publiquement accusé ou noté. 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 client.

Les registres doivent publier de meilleures preuves d'événement, pas policer l'utilisation ultérieure

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

Le journal de transfert commun devrait porter un identifiant de cas stable ou un lien de cas préservant la vie privée afin qu'un accord fragmenté entre préfixes ne soit pas compté plusieurs fois. Il devrait distinguer le transfert politique, la fusion, le changement temporaire, la correction et d'autres types d'événements reconnus. Il devrait préserver 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 du registre public, avec des définitions. Aucune de ces mesures n'exige la divulgation du plan d'utilisation interne de l'acheteur.

Ce que les registres ne devraient pas faire est d'utiliser la télémétrie post-transfert comme un nouveau pouvoir d'approbation. Une alerte d'absence de route peut aider un détenteur à 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 incompatibilité d'origine de route peut donner lieu à 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 réside dans le but. Les preuves peuvent améliorer la précision des enregistrements, la sécurité et la qualité de service. Elles deviennent dangereuses lorsqu'un administrateur prétend que la visibilité publique lui donne autorité sur le but commercial.

La séparation du RFC 7020 reste une frontière solide. Les systèmes d'enregistrement préservent l'unicité et des enregistrements précis. Les opérateurs décident si et comment annoncer les routes. 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 digne de confiance, pas moins. Il peut dire exactement ce qu'il a fait et laisser d'autres institutions 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 car 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 englobantes, 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 le périmètre d'observation.

Le rapport ne doit pas certifier « inutilisé ». Il peut dire « aucune route exacte ou plus spécifique observée chez les pairs RIS et RouteViews listé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 détenteur 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 client antérieure a pris fin. Un acheteur peut conserver le rapport comme référence pour d'éventuels litiges ultérieurs.

La tarification peut alors refléter les composantes de risque réelles. 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 calendrier.

La portabilité des preuves compte. Si le rapport n'existe que dans le système privé d'un courtier, la partie doit racheter sa propre histoire lors de la transaction suivante. Un enregistrement signé et exportable permet au détenteur de transporter les observations entre fournisseurs et de contester les erreurs.

Le marché n'a pas besoin d'un score unique. Les notations composites cachent les 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.

NRS peut promouvoir un standard de preuve portable sans en exploiter un

Number Resource Society peut apporter une contribution constructive en promouvant une spécification de preuve de transfert ouverte et en publiant des recherches sur la manière dont les registres, opérateurs et analystes indépendants existants la mettent en œuvre. La spécification ne déterminerait pas le prix, n'approuverait pas le but ni ne déciderait si la détention est vertueuse. Elle décrirait comment des teneurs de registres compétents peuvent préserver les observations et leurs limites.

Au minimum, NRS peut recommander qu'un enregistrement tenu par le registre responsable, l'opérateur ou un fournisseur de preuves qualifié lie un reçu de transfert reconnu à des réponses RDAP datées, des résumés de visibilité BGP, des changements RPKI, la délégation DNS inverse et des attestations privées volontaires. Chaque observation devrait identifier son collecteur, sa source de requête, sa plage temporelle, sa méthode et son niveau de confiance. Les états dérivés devraient être versionnés afin que des preuves ultérieures n'effacent pas le raisonnement antérieur.

NRS peut représenter les membres cherchant le droit d'exporter ces enregistrements et de les transférer vers un autre fournisseur de services qualifié. Les chercheurs devraient pouvoir mettre en œuvre 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. NRS ne détient pas l'état du registre faisant autorité ni ne rend un transfert effectif.

Les preuves confidentielles peuvent être représentées par une déclaration vérifiable d'un réviseur indépendant autorisé par les parties, pas par NRS. Un tel réviseur peut inspecter un document daté soutenant la réserve, la location ou l'utilisation future engagée sans révéler le client, le prix, la durée ou la conception du réseau. La participation devrait être volontaire; le refus devrait laisser l'état inconnu, pas créer une présomption négative.

NRS peut publier des recherches comparatives sur la couverture de divulgation et presser les implémenteurs de la déclarer. Un résumé BGP devrait identifier quelles familles de collecteurs et quels pairs ont été utilisés. Un rapport DNS inverse devrait indiquer la densité d'échantillonnage. Une déclaration RPKI devrait identifier l'heure d'observation. La portabilité sans provenance ne ferait que faire voyager plus vite des affirmations faibles.

C'est un rôle étroit de plaidoyer et de représentation des membres avec une haute valeur pratique. Il peut exposer les diligences dupliquées, comparer les méthodes de transition d'état et militer pour des preuves qui survivent à un changement de courtier, de registre ou de plateforme. La garde, la vérification, l'attestation signée et la tenue de l'enregistrement faisant autorité restent à l'institution compétente et autorisée à remplir chaque fonction.

Le test positif pour la politique que NRS défend est simple: un détenteur peut-il quitter un service de preuves avec une copie complète et vérifiable et continuer à opérer? Si oui, le service soutient le marché. Si le départ fait perdre leur validité aux preuves ou aux adresses leur reconnaissance, ce service est devenu un autre gardien. NRS peut documenter et contester cette dépendance; elle ne peut pas la supprimer en se déclarant service de remplacement.

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 des pairs entités. Leur étendue les rend indispensables, mais pas omniscients. La composition des pairs change. La politique d'exportation cache les chemins. L'agrégation cache les frontières 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 frontières ou conservés pendant une transition.

Il n'y a pas de réponse d'enregistrement qui liste tous les rôles économiques. RDAP peut fournir des données d'enregistrement faisant autorité tout en omettant une location, une exploitation client ou une relation bénéficiaire. Les champs publics de contact et de statut sont contraints par la politique et la vie privée.

Même les preuves privées ont un biais de sélection. Les entités avec 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 d'observation » est défendable. « L'acheteur n'a jamais utilisé le bloc » ne l'est généralement pas.

La discipline doit survivre aux gros titres. Une découverte dramatique concernant un 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 été routé peut encore avoir changé l'économie du réseau

Un transfert reconnu par le 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 aussi laisser un acheteur avec un bloc qui ne fonctionne jamais comme prévu.

La preuve de routage est tout aussi importante. BGP peut montrer si des annonces sont apparues, comment les origines ont changé et à quel point 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'utilisation future, l'intégration échouée 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é des transferts 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 détenteur. Les registres resteraient des teneurs de registres précis. Les opérateurs resteraient responsables des routes. Les chercheurs énonceraient 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 opérationnel et un investissement à différents moments. La preuve devient utile seulement lorsque ces moments et ces rôles sont maintenus séparés.

Sources