Résumé

  • Après exclusion des annonces plus spécifiques que /24, l’étude APRICOT 2020 d’Anurag Bhatia recensait 34 565 préfixes IPv4 à visibilité limitée dans les vues choisies, et non 34 565 pannes mondiales.
  • Pour transformer une absence en conclusion, il faut conserver collecteur, pair, instant, données brutes, règle de comparaison, causes candidates et tests indépendants.

Le mot « manquant » contracte deux phrases. La première est vérifiable : un préfixe figure dans l’ensemble A mais pas dans la vue B à un instant donné. La seconde attribue déjà une portée et une faute : des utilisateurs ne pouvaient pas atteindre ce préfixe parce qu’un réseau nommé aurait mal agi. Entre les deux se trouvent les politiques d’import et d’export, la sélection du meilleur chemin, les pairs du collecteur, la convergence, les données de validation et le plan de transfert.

La présentation « Observations from Routing diff » d’Anurag Bhatia à APRICOT 2020 rend cette distance visible. Son schéma précise qu’un collecteur reçoit des meilleurs chemins. Il offre donc une surface d’observation, pas la copie de toutes les routes détenues par tous les routeurs.

L’étude comptait d’abord 802 156 préfixes IPv4 uniques, dont 34 872 à visibilité limitée, soit 4,34 %. Après retrait des annonces plus spécifiques que /24, elle en comptait 801 834, dont 34 565 à visibilité limitée, soit 4,31 %. Les vues différaient fortement : 32 691 préfixes apparaissaient dans l’écart associé à AS7018, contre 4 904 pour AS6939.

Ces nombres localisent des questions. Ils ne mesurent ni utilisateurs, ni octets, ni recettes, ni connexions échouées. Un préfixe de couverture peut encore transporter le trafic. La route absente chez un pair peut exister chez un autre. Et le chemin exporté au collecteur ne livre pas les chemins alternatifs disponibles à l’intérieur du réseau observé.

La présentation propose elle-même plusieurs explications : filtrage RPKI, filtre IRR construit sur un objet erroné, maillon absent dans un AS-SET, annonce anycast assortie de NO_EXPORT, convergence lente, confusion entre pair et transit, ou filtrage aval incohérent. La ligne d’un diff ne peut choisir seule parmi ces hypothèses.

Le RFC 4271 donne la raison structurelle. BGP distingue les routes reçues dans Adj-RIBs-In, celles retenues localement dans Loc-RIB et celles sélectionnées pour chaque Adj-RIBs-Out. Une politique locale peut exclure d’un export une route pourtant présente dans Loc-RIB. Quand le collecteur reçoit un chemin, plusieurs décisions sont déjà intervenues ; quand il ne le reçoit pas, il ne sait pas laquelle manque.

L’observateur a lui aussi un périmètre. La documentation des collecteurs RIPE RIS explique que les données arrivent par des sessions BGP volontaires, depuis des pairs, des points d’échange et des sessions multihop différents. Le pair choisit ce qu’il exporte et le collecteur enregistre ce qui arrive. Leur table n’est pas une RIB mondiale omnisciente.

Le temps produit une autre limite. La documentation MRT de RIS sépare les dumps, états à un moment donné, des fichiers d’updates, changements durant un intervalle. Deux dumps peuvent montrer une différence sans dire si elle a duré quelques secondes, suivi une remise à zéro de session ou disparu entre les photographies. La séquence des mises à jour constitue une preuve distincte.

La documentation de l’API RouteViews décrit elle aussi l’accès courant comme un sous-ensemble de son infrastructure et renvoie les recherches historiques aux archives MRT. Une référence sérieuse doit donc nommer collecteur, pair, horodatage et objet d’archive, pas seulement « RouteViews ».

Les travaux ultérieurs de Bhatia montrent comment exposer ces limites. Dans son analyse 2025 des réseaux sans transit, il combine des dumps Oregon RouteViews et RIPE RIS, fixe date et point de vue, avertit que les tables varient selon le lieu et refuse d’assimiler proportion de routes et proportion de trafic. Les 749 millions de lignes collectées augmentent la puissance de requête, pas la portée logique du résultat.

Son analyse 2024 du backbone Google rencontre une autre zone aveugle : les vues BGP publiques n’exposent pas la table complète. Il leur ajoute des traces actives depuis Google Cloud et qualifie explicitement l’expérience d’imparfaite. Deux plans de preuve ne rendent pas tout visible ; ils permettent d’écarter davantage d’hypothèses.

La biographie publique de Bhatia le présente comme chercheur réseau basé en Haryana, travaillant sur BGP, les IXP, DNS, IPv6, l’anycast et la mesure. Elle établit l’identité et le contexte de cette méthode, pas une autorité sur les réseaux comparés.

Le produit défendable est un registre des écarts. Pour chaque préfixe : famille d’adresses, heure et intervalle, collecteur et pair, fichier brut et empreinte, chemin sélectionné, ensemble de référence, exclusions, préfixe couvrant, état RPKI et IRR horodaté, séquence des updates, tests actifs autorisés, confirmation opérateur, causes candidates et rejetées, confiance, effet mesuré séparément, surface de contrôle, prochain test et expiration.

Ce registre maintient quatre états : absence observée, cause candidate, impact de transfert, remède attribuable. Sauter une étape fabrique un récit rapide, mais pas un diagnostic de réseau.