Zusammenfassung

  • Die Versionshinweise vom 18. August 2026 beschreiben vier BGP-Zustände im AFRINIC-Monitor: ursprüngliches Präfix angekündigt, nur spezifischere Routen, nicht geroutet und keine Daten.
  • Wendet man den öffentlichen Anzeigecode auf die am 3. September vollständig abgerufene Südafrika-Datei an, ergeben 239 exakte und 42 ausschließlich spezifischere Fälle zusammen 281 von 522 Blöcken. Gerundet sind das 54 Prozent.
  • Die Datei nennt den 20. August als Erstellungsdatum, aber keinen Zeitpunkt des BGP-Snapshots. Hier wird eine veröffentlichte Berechnung nachvollzogen, keine neue Routing- oder Verfügbarkeitsmessung vorgenommen.

Ein grünes Feld kann viel Arbeit ersparen. Es kann aber auch Arbeit verbergen, wenn niemand mehr fragt, welche Beobachtung es zusammenfasst. Bei einer Routinganzeige ist deshalb entscheidend, ob das ursprüngliche Präfix selbst sichtbar ist oder lediglich spezifischere Routen innerhalb seines Adressbereichs.

AFRINIC hat diese Unterscheidung in seinem Africa IPv6 & DNSSEC Deployment Monitor ausgebaut. Die Versionshinweise vom 18. August beschreiben den Wechsel von zwei auf vier BGP-Zustände. Außerdem wird fehlende Datengrundlage von einem als nicht geroutet eingestuften Block getrennt. Das ist eine nützliche Verbesserung: Unwissen erscheint nicht mehr als negatives Messergebnis.

Die feinere Klassifikation bedeutet allerdings nicht, dass die übergeordnete Kennzahl nur die exakten Ankündigungen zählt. An den öffentlichen Daten für Südafrika lässt sich die Zusammensetzung nachvollziehen.

Zwei Gruppen bilden den Zähler

Die am 3. September vollständig geladene Südafrika-Datei enthält 522 unterschiedliche Präfixeinträge. Davon tragen 451 den Status allocated und 71 den Status assigned. Der Nenner zählt somit aufgeführte Blöcke und nicht 522 gleichartige Vergabevorgänge.

Der öffentliche Code der Länderseite prüft zunächst, ob ein Eintrag ausdrücklich nicht von den BGP-Daten erfasst ist. Danach folgen exakte Ankündigung, Ankündigung ohne exaktes Präfix und schließlich die Einstufung als nicht geroutet. Für die untersuchte Datei ergibt sich diese Aufteilung:

Zustand nach der Regel des Monitors Blöcke
Ursprüngliches Präfix angekündigt 239
Nur spezifischere Routen 42
Als nicht geroutet eingestuft 241
Als ohne Daten eingestuft 0

Die Hauptkennzahl addiert die ersten beiden Gruppen: 239 plus 42 ergibt 281. Geteilt durch 522 und auf eine ganze Zahl gerundet sind das 54 Prozent. Auch der vom Code aufgebaute Erklärungssatz benennt beide Bestandteile. Die Aufschlüsselung ist also Teil des angebotenen Instruments, nicht erst eine nachträgliche Forderung an den Betreiber.

Würde man nur die 239 exakten Ankündigungen berücksichtigen, käme man auf rund 46 Prozent. Das wäre keine korrigierte Verfügbarkeitsquote, sondern eine andere Kennzahl. Jeder Block zählt gleich viel, unabhängig von seiner Präfixlänge. Weder die eine noch die andere Rechnung misst den Anteil der Adressen, Organisationen, Kunden oder erfolgreichen Verbindungen.

Spezifischer bedeutet nicht automatisch schlechter

Das Wort „nur“ kann den Eindruck eines unvollständigen Betriebs erwecken. Die technische Aussage ist enger. RFC 4271 beschreibt eine spezifischere Route als längeres Präfix, das eine kleinere Menge von Zielen umfasst. Diese Mengenbeziehung ist noch kein Qualitätsurteil über das Netzdesign.

Ein rein rechnerisches Beispiel: Die beiden korrekt ausgerichteten /33-Hälften eines /32 können zusammen den gesamten /32-Bereich beschreiben, ohne dass das /32 selbst angekündigt wird. Für keinen der 42 Fälle wurde hier eine solche Konfiguration nachgewiesen. Das Beispiel zeigt lediglich, warum das fehlende Aggregat allein keine Lücke im durch spezifischere Routen beschriebenen Adressraum beweist.

Umgekehrt garantiert eine exakte Präfixankündigung weder ein funktionierendes Gerät an jeder Adresse noch die Annahme der Route durch jeden Beobachter oder die Antwort einer Anwendung. Die bloße Zahl spezifischerer Routen verrät auch nicht deren Vereinigungsmenge und Überschneidungen. Routinginformationen ersetzen keinen Test des benötigten Dienstes.

Die 42 Fälle dürfen daher auf dieser Grundlage nicht als gestört, ungenutzt oder unsicher bezeichnet werden. Auch die 241 negativen Einstufungen bleiben auf den Datensatz des Monitors begrenzt. Sie belegen nicht, dass in jeder möglichen BGP-Sicht eine Route fehlt. Die null unbekannten Fälle betreffen diese Südafrika-Datei, nicht die Vollständigkeit der Beobachtung des gesamten Kontinents.

Drei Zeitpunkte mit unterschiedlicher Bedeutung

Die Versionshinweise erklären, die frühere Methode habe einen Block bereits gezählt, wenn irgendein Teil in der Routingtabelle auftauchte. Niedrigere Prozentwerte führt die Seite auf eine strengere Messung zurück. Das ist ihre Darstellung der historischen Änderung. Diese Untersuchung hat weder die alte Version rekonstruiert noch die BGP-Eingaben vor und nach der Umstellung verglichen. Sie kann deshalb keinen Rückgang beziffern und erst recht keine Verschlechterung der Netze feststellen.

Die geprüfte Datei nennt den 20. August 2026 als Erstellungsdatum; das Feld für den BGP-Snapshot ist leer. Der Code bewahrt den Unterschied und nennt einen Snapshot-Zeitpunkt nur, wenn er vorhanden ist. Andernfalls spricht er vom Erstellen der Daten. Der Abruf am 3. September ersetzt keinen fehlenden Beobachtungszeitpunkt und macht die Datei nicht zu einer neuen Routingmessung dieses Tages.

Die Länderseite trennt außerdem Domain-Dienste, Nutzung durch Endanwender, Adressraum und BGP in eigene Registerkarten. Diese Trennung sollte auch die Auswertung bewahren. Eine Routenankündigung hat weder einen Webauftritt noch einen Maildienst oder den Anschluss eines Kunden getestet.

Der Gewinn der Änderung liegt somit in besser unterscheidbaren Beobachtungen, nicht zwingend in einer besseren Rangliste. Die Summe kann das Vorliegen einer von zwei Ankündigungsformen zusammenfassen. Die Komponenten helfen, den nächsten Untersuchungsschritt zu bestimmen. Dafür müssen sie keine Noten für richtige und falsche Netzarchitekturen werden.