Zusammenfassung

  • Ein Host darf bei RIPE Atlas höchstens zwei Software-Sonden hinter derselben IP-Adresse und vier im selben BGP-sichtbaren Präfix verbinden; hostübergreifend gelten 32 für ein IPv4- und 64 für ein IPv6-Präfix.
  • Die Regel benennt Kosten, begrenzten Informationsgewinn dichter Installationen, Ausnahmen und veränderbare Höchstwerte. Offen bleibt die reproduzierbare Verbindung zwischen einem datierten Routingzustand und der tatsächlich gezählten Gruppe.
  • Ein datensparsamer privater Entscheidungsbeleg sollte Zeitpunkt, Routingansicht, aufgelöstes Präfix, Zähler, ausgelöste Schwelle, Freigabebedingung und Ausnahmeprüfung binden; öffentlich genügen geschützte Aggregate.

Eine knappe Regel mit vier verschiedenen Nennern

RIPE Atlas will möglichst viele nützliche Blickpunkte auf das Internet, nicht möglichst viele identische Prozesse. Jede verbundene Sonde beansprucht zentrale Ressourcen. Dicht beieinander installierte Software-Sonden können zugleich ähnliche Ergebnisse liefern. Weil aktive Hosts Guthaben verdienen, muss das System echte Teilnahme belohnen, ohne bloße Verdichtung zum eigenen Geschäftsmodell zu machen.

Die Ankündigung vom 29. April 2026 nennt vier Grenzen. Ein Host kann zwei Software-Sonden von derselben IP-Adresse verbinden. Vier sind im selben IP-Präfix erlaubt, „wie es in BGP gesehen wird“. Unabhängig vom Host dürfen höchstens 32 Sonden aus einem IPv4-Präfix und 64 aus einem IPv6-Präfix verbunden sein. Jenseits der Grenze bleibt eine Sonde draußen, bis eine andere ausfällt oder ausscheidet.

Diese Zahlen sind nicht bloß vier Härtegrade. Zwei verknüpft Konto und Adresse. Vier verknüpft Konto und Routingpräfix. 32 und 64 zählen hostübergreifend im Präfix und unterscheiden die Adressfamilie. Ein sinnvoller Status muss deshalb nennen, welche Population und welche Schwelle maßgeblich waren.

RIPE NCC beschreibt die Zahlen nicht als ewige Konstanten. Sie können angepasst werden. Wenn Sonden eines Nutzers scheinbar aus demselben Netz kommen, tatsächlich aber geografisch weit verteilt sind, darf der Host den Fall per E-Mail erläutern und eine Lockerung beantragen. Zum Zeitpunkt der Ankündigung wurden 71 Sonden von 13 Hosts als betroffen geschätzt. Das ist eine Momentaufnahme der Einführung, weder ein heutiger Bestand noch ein Nachweis, dass alle 71 später angehalten wurden.

Die Worte „wie es in BGP gesehen wird“ sind die eigentliche Systemgrenze. Die Regel setzt nicht einfach Registerzuteilung, gesamtes ASN oder Selbstauskunft mit dem operativen Netz gleich. Sie nimmt beobachtbares Routing. Ein solches Präfix haftet jedoch nicht am Gerät. Eine spezifischere Ankündigung kann auftauchen, eine Route kann aggregiert oder zurückgezogen werden, der Ursprung kann wechseln, verschiedene Beobachter können abweichende Zustände sehen. Die Sonde bleibt stehen, ihre rechnerische Nachbarschaft nicht zwingend.

Das ist eine technische Möglichkeit, kein dokumentierter Vorfall. Keine geprüfte Quelle zeigt, dass eine bestimmte Sonde allein wegen einer BGP-Änderung gehalten oder freigegeben wurde. Ebenso unbekannt sind Routingquelle, Kollektoren, Sichtbarkeitsschwelle, Beobachtungszeit und die Auswahlregel bei mehreren passenden Routen.

Große Präfixe prüfen die Gleichsetzung mit Redundanz

In der öffentlichen Diskussion fragte Robert Scheck nach AS3209 und AS3320. Bei einer früheren Untersuchung hätten Sonden im gleichen BGP-sichtbaren Präfix unterschiedliches Verhalten gezeigt.

Das beweist nicht den Wert jeder zusätzlichen Sonde. Es trennt aber Präfixzugehörigkeit von experimenteller Austauschbarkeit. Hinter einer global sichtbaren Route können in einem großen Zugangsnetz unterschiedliche interne Pfade, Aggregationsstufen, Richtlinien und Fehlerdomänen liegen.

Die Antwort von RIPE NCC in den offiziellen Thread-Antworten blieb eng. Die Grenzen seien so gewählt, dass die übliche Zahl von Software-Sonden in diesen großen Netzen nicht beeinträchtigt werde. Man werde beobachten und könne großen Präfixen künftig mehr Spielraum geben. Das macht die Präfixgröße zu einer anerkannten Stellschraube, verspricht aber keinem ASN ein Sonderkontingent.

Eine zweite Frage galt der Bedienoberfläche: Würde der Host einen Grund sehen oder nur „Disconnected“? RIPE NCC kündigte ein eigenes Kennzeichen und eine vorherige Kontaktaufnahme mit den geschätzten 13 Hosts an. Die Website-Änderungen vom 15. Juli melden inzwischen, dass die Sondenübersicht einen Halt wegen einer Farming-Verletzung anzeigt.

Diese Benennung verhindert eine wichtige Fehlersuche. Ein bewusster Aufnahmestopp lässt sich von Firewall-, Anschluss- oder Controllerproblemen unterscheiden. Doch das Label allein nennt weder zwei, vier, 32 oder 64 noch das aufgelöste Präfix, die gezählte Menge oder den nächsten Prüfzeitpunkt.

Präfixfelder sind noch keine Entscheidungsprovenienz

Die heutige FAQ zur Sondenverwaltung wiederholt alle Grenzen, den BGP-Bezug und den Weg für geografisch verteilte Ausnahmen. Die FAQ für Hosts erklärt den Anreiz: verbundene Sonden bringen Guthaben, während RIPE Atlas topologische Vielfalt anstrebt und Credit Farming verhindern will.

Die öffentliche Sonden-API dokumentiert prefix_v4 und prefix_v6. Solche Felder beschreiben einen Zustand. Im geprüften Material definieren sie jedoch keinen Entscheidungsdatensatz, der Präfix, Routingzeit, Zähler, Schwelle und Prüfung miteinander verbindet. Auch wäre eine vollständige Veröffentlichung der Missbrauchserkennung unklug. Exakte Adressen, Kontozusammenhänge und umgehungsrelevante Details gehören geschützt.

Deshalb braucht es zwei Ebenen. Betreiber und betroffener Host benötigen einen privaten, reproduzierbaren Beleg. Forschung und Öffentlichkeit benötigen aggregierte Wirkungsdaten ohne identifizierbare Installationen. Transparenz muss nicht für beide Empfänger dasselbe bedeuten.

Die BGP-State-Dokumentation von RIPEstat liefert nur ein Vokabular. Ein reproduzierbarer Routingzustand kann Ressource, Zeitpunkt, gewählte Kollektoren, Quellkennung und Abfragezeit benennen. Daraus folgt nicht, dass Atlas RIPEstat, RIS, alle RIS-Kollektoren oder denselben Rechenweg nutzt. Es zeigt lediglich, wie viel präziser „in BGP gesehen“ dokumentiert werden kann.

Der minimale Entscheidungsbeleg

Ein privater Beleg beginnt mit Entscheidungszeit, Adressfamilie und einer geschützten Darstellung der Quelladresse. Er hält das aufgelöste Präfix, den Zeitpunkt des Routingzustands und die verwendete Datengrenze fest. Bei konkurrierenden oder überlappenden Routen gehört die Auswahlregel dazu.

Danach folgt die ausgelöste Stufe. War es die dritte Sonde desselben Hosts an einer Adresse, die fünfte desselben Hosts im Präfix, die 33. im IPv4- oder die 65. im IPv6-Kollektiv? Zähler unmittelbar vor der Entscheidung und geltender Höchstwert gehören nebeneinander. Bei fast gleichzeitigen Verbindungen muss auch eine stabile Reihenfolge nachvollziehbar sein.

Schließlich braucht der Beleg einen Ausgang. „Bis andere Sonden ausscheiden“ erklärt das Prinzip, aber nicht, wann neu gezählt wird, ob eine Routingänderung eine Prüfung auslöst, ob eine Warteschlange existiert und welches Ereignis die Verbindung wieder freigab. Für Ausnahmen genügen Antrag, Begründungsklasse, Entscheidung, Prüfer und Ablaufdatum; die sensible Erklärung bleibt privat.

Öffentlich reichen gruppierte Zahlen: Halte- und Freigabevorgänge nach Stufe und Adressfamilie, Wartezeit, Ausnahmegesuche und Ergebnisse, Auswirkungen geänderter Höchstwerte sowie Neubewertungen nach BGP-Grenzänderungen. Kleine Gruppen lassen sich verzögert oder in größeren Zeitfenstern melden.

Dies ist Theo Marchs redaktionelle Empfehlung. Sie unterstellt RIPE NCC keine fehlenden internen Protokolle. Sie macht aus einer Schwellenüberschreitung auch keine Absichtserklärung des Hosts. Der Produktstatus bezeichnet den Kontrollpfad, nicht den Charakter einer Person.

Quellen