Zusammenfassung

  • Der RIPEstat-Plan für das dritte Quartal 2026 nennt Routing History als nächste hochwertige Visualisierung für den Neuaufbau und begründet dies mit langfristiger Wartbarkeit und der Aktivierung von Content Security Policy.
  • Die öffentliche Data API ist die einzige Datenquelle der Oberfläche; weiches Zeilenlimit, Peer-Schwelle, First-Hop-Option, Sichtbarkeitsnormalisierung, Zeitraum und fehlende Peer-Daten beeinflussen dennoch die sichtbare Aussage.
  • Ein kleiner Paritätsnachweis sollte beide Ansichten an feste Antworten binden, Defaults und beabsichtigte Abweichungen offenlegen, Grenzfälle testen und Korrektur sowie Abschaltung dokumentieren.

Die Schwelle ist Teil der sichtbaren Geschichte

Eine Präfixankündigung wird zunächst von neun RIS-Full-Table-Peers gesehen, später von elf. Eine Darstellung mit der voreingestellten Mindestzahl zehn beginnt erst im zweiten Abschnitt. Senkt man die Schwelle, erscheint auch der erste. Die Messungen widersprechen sich nicht. Trotzdem vermitteln zwei Screenshots verschiedene Zeitpunkte für den Beginn der Route.

Dieses Beispiel behauptet keinen tatsächlichen Fehler. Es markiert die Art von Entscheidung, die beim nächsten RIPEstat-Schritt prüfbar bleiben sollte. Laut Quartalsplanung Q3 2026 ist Routing History die nächste zu erneuernde Visualisierung und für interne wie externe Nutzer besonders wertvoll. Der RIPE NCC will weitere Legacy-Ansichten mit neuer Technik und überarbeiteter Oberfläche neu bauen, um sie langfristig warten und in RIPEstat Content Security Policy, CSP, aktivieren zu können. Der Status lautet „in Arbeit“.

Die institutionell stärkste Verteidigung dieser Entscheidung überzeugt. Alte Frontends können korrekte Daten liefern und dennoch zum Sicherheits- und Wartungsrisiko werden. Historische Annahmen über eingebettete Scripts, Styles oder externe Ressourcen erschweren strikte Browserregeln. Die CSP-Level-3-Spezifikation des W3C definiert Mechanismen, mit denen eine Seite steuert, welche Ressourcen sie laden oder ausführen darf. Ein Report-only-Modus erlaubt Beobachtung vor der Durchsetzung. Code zu ersetzen, der diese zusätzliche Schutzschicht verhindert, ist ordentliche Wartung und kein Eingeständnis eines Angriffs.

Semantische Parität verlangt ebenso wenig identische Pixel. Besserer Farbkontrast, nachvollziehbare Tastaturführung und eine verständliche mobile Reduktion dürfen das Bild verändern. Die archivierten RIPEstat-Pläne zeigen, dass bereits Funktionsparität zwischen alter und neuer UI hergestellt, UI-Tests automatisiert, Widget-Abhängigkeiten vorsichtig ausgerollt und Auswirkungen einer RIS-Datenverarbeitungsmigration überwacht wurden. Die Quellen belegen nicht, dass interne Prüfungen fehlen.

Doch Ausführungssicherheit und Bedeutungskontinuität sind zwei verschiedene Prüfziele. CSP beantwortet, ob die neue Anwendung unter einer strengeren Browserpolicy funktioniert. Semantische Parität beantwortet, ob dieselben Beobachtungen für den Nutzer dieselben wesentlichen Tatsachen enthalten. Eine CSP-konforme Seite kann den sichtbaren Beginn oder die Gruppierung einer Route dennoch verschieben.

Eine API-Antwort ist noch keine fertige Grafik

RIPEstat beschreibt seine Zuständigkeiten ungewöhnlich klar. Die Data-API-Dokumentation nennt die API die öffentliche Schnittstelle und einzige Datenquelle für Widgets und UI. Die Seite Was ist RIPEstat? trennt den Teil, der Daten liefert und Abfragen beantwortet, von der UI, die zeigt, wie diese Daten visualisiert werden können.

Damit ist die API-Antwort ein guter Anker für einen Versionsvergleich. Sie nimmt der Oberfläche aber nicht ihre Entscheidungen ab. Der aktuelle Routing-History-Endpunkt, Version 2.3, liefert aus RIS-Route-Collectors stammende Ankündigungszeiträume, gruppiert nach Origin und Präfix. Mehrere Parameter verändern, was sichtbar wird.

max_rows ist ein weiches Limit mit dem Default 3.000. Sobald es erreicht ist, werden zwar alle aufgezeichneten Routen eines bereits einbezogenen Origins ausgegeben, weitere Origins aber nicht. Sortierung und Hinweis auf Kürzung werden damit bedeutungsrelevant. include_first_hop ergänzt die erste ASN im Pfad und kann eine Origin-Serie in mehrere Kombinationen teilen. normalise_visibility berechnet den Anteil der RIS-Full-Table-Peers, die eine Route sehen. min_peers steht standardmäßig auf zehn und schließt schwach sichtbare oder lokale Ankündigungen unterhalb dieser Schwelle aus. Start- und Endzeit bestimmen das Fenster; ohne Endzeit bewegt es sich mit den neuesten verfügbaren BGP-Daten.

Ein Rückgabewert darf nicht als gewöhnliche Zahl behandelt werden. Bei fehlenden oder unzuverlässigen Peer-Informationen kann die normalisierte Sichtbarkeit -1 betragen. Das ist nicht null Sichtbarkeit. Ein Punkt auf der Nulllinie würde gemessene Abwesenheit suggerieren. Stilles Weglassen könnte Kontinuität vortäuschen. Eine Verbindung über die Lücke hinweg würde eine Beobachtung erfinden. Die visuelle Lösung ist gestaltbar, die Trennung von „unbekannt“ und „null“ nicht.

Auch der Beobachtungsraum muss mit der Kurve reisen. Routing History nennt RIS-Collectors als Quelle. Die Dokumentation zu Routing Status spricht von durch RIS beobachtetem Zustand und weist darauf hin, dass ein AS zusätzliche, dort nicht beobachtete Nachbarn haben kann. Die Grafik ist wertvolle öffentliche Evidenz aus einem definierten Beobachtungssystem, kein allwissendes Bild des Internets.

Zeit erzeugt eine weitere Falle. RIPEstat erklärt, dass Aktualität von Erfassungsfrequenz, Speicherupdates, Verarbeitungsverzug, Fehlern und Caches abhängt. Zwei zu unterschiedlichen Zeitpunkten geöffnete Live-Seiten vergleichen womöglich zwei Backendzustände statt zwei Frontends. Der semantische Test braucht deshalb eine gespeicherte Antwort mit Zeitstempel, Hash und festem Abfragefenster. Live-Tests bleiben für Verfügbarkeit und Aktualität wichtig, beantworten aber eine andere Frage.

Der kleinstmögliche belastbare Nachweis

Es braucht weder ein neues Gremium noch zwei dauerhaft laufende Oberflächen. Ein versionierter Paritätsnachweis kann den Rollout anhand weniger repräsentativer Fixtures begleiten.

Für jeden Fall hält er alte und neue Build-Version, Endpunkt- und Methodenversion, Ressource, UTC-Zeitraum, Anzeigezeitzone, explizite Parameter, tatsächlich aufgelöste Defaults sowie Zeitpunkt und Hash der festen API-Antwort fest. Dazu kommen Gruppierung, Sortierung, Kürzung und Behandlung fehlender Werte in beiden Ansichten.

Die Fälle müssen die unbequemen Grenzen wählen: ein Single-Origin-Präfix, ein Multi-Origin-Fall, eine Antwort am weichen Limit, Beobachtungen beiderseits der Peer-Schwelle, aktivierter First Hop, unzuverlässige Peer-Daten, ein offener letzter Zeitraum sowie Tastatur- und Schmalbildschirmnutzung. Ziel ist nicht Pixelgleichheit, sondern die Frage, ob eine wesentliche Tatsache verschwindet, die Gruppe wechselt oder eine Zeitgrenze wandert.

Beabsichtigte Unterschiede gehören ausdrücklich in den Nachweis. Eine zugänglichere Farbpalette ist kein Fehler. Eine neu geordnete Legende kann Fehlinterpretationen reduzieren. Ein Wechsel auf UTC kann sinnvoll sein, wenn Tooltip und Export folgen. Die dokumentierte Begründung verhindert, dass künftige Wartung eine Verbesserung im Namen vermeintlicher Gleichheit zurückbaut.

Zuletzt braucht der Nachweis Verantwortliche, offene Ausnahmen, Prüftermin, Korrektur- und Ablöseverweise sowie eine Abschaltregel. Legacy-Code muss nicht wegen kosmetischer Unterschiede weiterleben. Er kann gehen, sobald entscheidungsrelevante Abweichungen geschlossen oder ausdrücklich akzeptiert sind, barrierefreie Nutzung besteht und sich die neue Ansicht aus der gespeicherten Anfrage reproduzieren lässt.

Was die Quellen nicht belegen

Die Unterlagen zeigen nicht, dass die aktuelle Routing-History-Darstellung falsch ist, dass der Ersatz bereits ausgerollt wurde oder scheiterte, dass CSP Routingdaten verändert, dass eine ausnutzbare Schwachstelle besteht oder dass der RIPE NCC Daten verloren hat. Der Quartalsplan ist kein Abschlussbericht; öffentliche API-Dokumentation ist kein vollständiger interner Testkatalog.

Der Vorschlag ist vorbeugend. Er hält RIS-Beobachtung, öffentlichen API-Vertrag und sichtbare Entscheidung eines bestimmten UI-Builds auseinander. Sicherheitsmodernisierung kann dann zügig erfolgen, ohne dass Nutzer semantische Kontinuität lediglich glauben müssen.

Quellen