Résumé

  • Pour un même hôte, RIPE Atlas autorise jusqu’à deux sondes logicielles derrière une adresse IP et quatre dans un préfixe vu dans BGP ; tous hôtes confondus, les plafonds sont de 32 sondes pour un préfixe IPv4 et de 64 pour un préfixe IPv6.
  • La règle expose utilement ses objectifs, ses exceptions et le caractère révisable des plafonds. Elle ne publie pas la jointure qui relie un état BGP daté au groupe effectivement compté lors d’une décision.
  • Un reçu privé et respectueux des données devrait fixer l’heure, la vue de routage, le préfixe résolu, les compteurs, le seuil déclenché, la sortie d’attente et l’examen d’une exception ; le public n’a besoin que d’agrégats prudents.

Une politique claire sur une frontière mouvante

Un réseau mondial de mesure ne peut pas additionner les machines sans limite. Chaque sonde connectée consomme des ressources centrales et, lorsque plusieurs logiciels observent le même réseau depuis le même endroit, le gain d’information peut devenir faible. En parallèle, les hôtes gagnent des crédits tant que leurs sondes sont actives. Le dispositif doit donc accueillir les points de vue réellement utiles sans transformer le nombre de processus installés en objectif autonome.

Le message de déploiement du 29 avril 2026 formule ce compromis avec quatre nombres. Un hôte peut connecter deux sondes logicielles depuis la même adresse IP. Il peut en connecter quatre depuis le même préfixe IP « vu dans BGP ». Tous hôtes confondus, un préfixe IPv4 peut en compter 32 et un préfixe IPv6, 64. Au-delà, une nouvelle sonde ne se connecte pas tant qu’une autre n’est pas sortie du groupe.

Ces nombres ne sont pas quatre degrés d’une même mesure. Le seuil de deux joint le compte et l’adresse. Celui de quatre joint le compte et un préfixe de routage. Les seuils de 32 et 64 oublient le compte et regardent l’ensemble du préfixe, avec une distinction entre IPv4 et IPv6. Une décision intelligible doit donc indiquer quel test a échoué, pas seulement afficher un mot générique.

RIPE NCC a aussi laissé la règle respirer. Les maximums pourront être ajustés. Si des sondes d’un même utilisateur paraissent appartenir au même réseau alors qu’elles sont largement dispersées, l’hôte peut expliquer le cas par courriel et demander un assouplissement. Au moment de l’annonce, RIPE NCC estimait que 71 sondes relevant de 13 hôtes seraient concernées. Ce chiffre photographie la préparation du 29 avril ; il ne mesure ni la situation actuelle ni le nombre final de mises en attente.

La formule « vu dans BGP » évite une approximation administrative. Elle ne suppose pas qu’une allocation de registre, un ASN ou une description saisie par l’hôte corresponde exactement au réseau observable. Mais cette rigueur introduit son propre mouvement. Une annonce plus spécifique peut apparaître, une agrégation ou un retrait peut suivre, l’origine peut changer et deux points d’observation peuvent ne pas voir le même état. La sonde ne bouge pas ; le groupe auquel la règle l’assigne, lui, peut bouger.

Il s’agit d’une conséquence technique possible, pas d’un incident démontré. Aucun document examiné ne prouve qu’une sonde précise ait été bloquée ou libérée uniquement à cause d’une modification BGP. Les textes publics ne nomment pas non plus la source de routage, les collecteurs, le seuil de visibilité, l’instant de calcul ni la méthode de choix d’un préfixe. Il faut garder ces inconnues comme telles.

Le cas des grands réseaux n’est pas une exception décorative

Dans la discussion publique, Robert Scheck a demandé si le plafond toucherait AS3209 ou AS3320. Son exemple portait sur une enquête passée où plusieurs sondes incluses dans un même préfixe visible dans BGP avaient manifesté des comportements différents.

L’objection ne dit pas que toute sonde supplémentaire est précieuse. Elle rappelle que l’appartenance à un préfixe et l’interchangeabilité expérimentale ne sont pas synonymes. Dans un vaste réseau d’accès, des parcours internes, des équipements d’agrégation ou des domaines de panne peuvent produire des observations différentes sous une même route globale.

La réponse de RIPE NCC, conservée dans les réponses officielles du fil, est prudente. Les seuils auraient été choisis pour ne pas réduire le nombre habituel de sondes dans ces grands réseaux. La situation serait suivie et l’algorithme pourrait un jour accorder davantage de marge aux grands préfixes. Cela reconnaît un paramètre à régler ; cela ne garantit pas un quota spécial à chaque opérateur.

Le fil demandait aussi comment distinguer la règle d’une simple déconnexion. RIPE NCC annonçait une étiquette dédiée et un contact préalable avec les 13 hôtes estimés concernés. La version du site du 15 juillet indique désormais que la vue d’ensemble signale à l’hôte qu’une sonde est mise en attente à cause d’une « farming violation ».

Ce progrès est concret. Il sépare une décision du système d’un défaut de connectivité ordinaire. Mais une étiquette n’est pas encore une provenance. Elle ne précise pas si le plafond de deux, quatre, 32 ou 64 a joué, quel préfixe a été retenu, combien de sondes ont été comptées, ni quel événement déclenchera un nouveau calcul.

Montrer un préfixe ne suffit pas à expliquer une décision

La FAQ de gestion des sondes reprend aujourd’hui les quatre plafonds, la référence au préfixe BGP et la voie d’exception géographique. La FAQ consacrée aux hôtes donne le contexte économique : les hôtes reçoivent des crédits, tandis que RIPE Atlas recherche une diversité topologique et veut empêcher le « credit farming ».

La référence de l’API des sondes publie des champs prefix_v4 et prefix_v6. Ils décrivent un état utile, mais les documents consultés ne définissent pas d’objet reliant, pour une mise en attente donnée, le préfixe, le compteur, le seuil et l’état de routage. Il n’est d’ailleurs ni nécessaire ni prudent de publier toute la mécanique anti-abus. Une adresse exacte, des associations de comptes ou des détails facilitant le contournement doivent rester protégés.

Il faut séparer les destinataires. L’opérateur et l’hôte touché ont besoin d’une trace suffisamment précise pour refaire la décision. Les chercheurs et le public ont besoin de statistiques agrégées permettant d’évaluer l’effet de la règle. La transparence n’impose pas que les deux couches soient identiques.

La documentation BGP State de RIPEstat fournit ici une grammaire, pas la description du système Atlas. Elle montre qu’un état de route reproductible peut nommer la ressource interrogée, l’horodatage, les collecteurs choisis, les identifiants de source et l’heure de requête. Rien ne permet d’affirmer que l’anti-farming utilise RIPEstat, RIS, tous les collecteurs RIS ou le même calcul. L’exemple prouve seulement que « vu dans BGP » peut recevoir des coordonnées vérifiables.

Le contenu minimal d’un reçu

Le reçu privé devrait commencer par l’heure de décision, la famille d’adresses et une représentation protégée de l’adresse source. Il conserverait le préfixe résolu, l’heure de l’état de routage et la frontière des données utilisée. Si plusieurs routes couvrantes ou concurrentes sont visibles, il indiquerait la règle qui en a choisi une.

Ensuite viendrait le test déclenché. S’agit-il de la troisième sonde du même hôte et de la même adresse, de la cinquième du même hôte et du même préfixe, de la trente-troisième dans un groupe IPv4 ou de la soixante-cinquième dans un groupe IPv6 ? Le compteur juste avant la décision et le plafond applicable doivent apparaître ensemble. Les arrivées simultanées exigent aussi une règle d’ordre stable.

Enfin, le reçu doit expliquer la sortie. La formule « jusqu’à ce que d’autres sondes se retirent » convient à une annonce. Pour agir, l’hôte doit savoir quand le groupe sera recompté, si un changement de route provoque un réexamen, s’il existe une file d’attente et quel événement a rendu la connexion possible. Une exception peut enregistrer la date, la catégorie du motif, la décision, le réviseur et l’expiration sans divulguer la justification sensible.

Le tableau public serait plus sobre : mises en attente et libérations par famille d’adresses et type de seuil ; délais de retour ; demandes d’exception et résultats ; effets des révisions de plafonds ; réexamens liés à une modification de frontière BGP. Les petits volumes peuvent être regroupés ou publiés avec retard afin de protéger les hôtes.

Cette recommandation de Theo March ne suppose pas l’absence de journaux internes. Elle demande un contrat de preuve entre un état visible par l’hôte et l’observation réseau mobile qui l’a produit. Elle ne transforme pas non plus tout hôte au-dessus d’un seuil en fraudeur : le libellé du produit décrit une règle, pas l’intention d’une personne.

Sources