Zusammenfassung

  • Am 28. August waren ASN 329802 und 4.096 IPv4-Adressen ab 102.201.96.0 verfügbar. Einen Tag später ist die ASN allokiert und das letzte /24 des früheren Blocks zugewiesen.
  • Beide neuen Zeilen enthalten 20260828, den Ländercode NA und die Kennung F36CF852. Laut AFRINIC gehören Zeilen mit gleicher Kennung in einer Datei demselben Ressourceninhaber.
  • Die vier verfügbaren Reste umfassen 3.840 Adressen. Zusammen mit den 256 zugewiesenen Adressen ergeben sie exakt den früheren Bestand von 4.096.
  • AFRINIC erlaubt die Zusammenfassung zu einer Allokation oder Zuweisung nur bei gleichem Ressourcentyp. Für die Verbindung von ASN und IPv4 fehlt ein eigenes, datensparsames Ausstellungsprotokoll.

Sechs neue und verschwundene Bestandszeilen

Die Datei vom 28. August zeigt zwei ungebundene Ressourcen. ASN 329802 steht auf available; Datum und Inhaberkennung sind leer. Eine IPv4-Zeile beginnt bei 102.201.96.0, zählt 4.096 Adressen und ist ebenfalls verfügbar. Größe und Grenze entsprechen 102.201.96.0/20.

In der nächsten Datei sind beide Zeilen ersetzt. ASN 329802 trägt nun den Status allocated, den Code NA, das Datum 28. August 2026 und die undurchsichtige ID F36CF852. Neu ist außerdem eine IPv4-Zeile mit 256 Adressen ab 102.201.111.0, Status assigned und denselben drei Angaben.

Der Rest des /20 wird in vier verfügbaren Bereichen sichtbar: 2.048 Adressen ab 102.201.96.0, 1.024 ab 102.201.104.0, 512 ab 102.201.108.0 und 256 ab 102.201.110.0. Das sind ein /21, ein /22, ein /23 und ein /24.

Ihre Summe beträgt 3.840. Das neue /24 umfasst 256 Adressen und liegt am Ende des früheren /20. 3.840 plus 256 ergibt 4.096. Die öffentliche Projektion lässt keine ungeklärte Lücke und keine Doppelzählung zurück.

Auch die Kopfzeile passt. Die Gesamtzahl der Datensätze steigt von 19.621 auf 19.625. Die IPv4-Zusammenfassung steigt von 6.051 auf 6.055 Zeilen, weil eine verfügbare Zeile durch eine zugewiesene und vier Restzeilen ersetzt wird. Bei ASN bleibt der Wert 4.350, da eine verfügbare Zeile lediglich durch eine allokierte ersetzt wird.

Diese Übereinstimmung ist ein entlastender Befund. Der betrachtete Übergang zeigt keine verlorenen Adressen, keinen unerklärten Zuwachs und keine fehlerhafte Bestandsrechnung. AFRINICs Tagesdatei erfüllt ihren Zweck als Zustandsprojektion.

Die Arithmetik kann jedoch nur die Herkunft des IPv4-/24 rekonstruieren. Sie verbindet nicht die Prüfung der ASN mit der Prüfung des Präfixes. Zahlen über Adressbestände sind keine Belege für einen gemeinsamen Verwaltungsakt.

Dieselbe ID bezeichnet denselben Inhaber

AFRINIC definiert die opaque ID als serieninterne Kennung einer Organisation beziehungsweise eines Inhabers von Internetnummernressourcen. Alle Zeilen einer Datei mit derselben Kennung sind demselben Inhaber zugeordnet.

Für den 29. August ist die Aussage deshalb belastbar: ASN 329802 und 102.201.111.0/24 gehören im veröffentlichten Registerbild zum selben pseudonymisierten Inhaber. Ein Name ist dafür nicht nötig.

Die Pseudonymisierung ist sinnvoll. Sie ermöglicht strukturelle Auswertung, ohne die Statistik in eine Liste von Antragstellern zu verwandeln. Geschäftliche Expansion, Ansprechpartner und Antragsunterlagen bleiben geschützt.

Die Dokumentation begrenzt die Kennung zugleich. Sie muss zwischen Dateiversionen nicht stabil bleiben. Sie ist keine dauerhafte juristische Identität, kein Eigentumsnachweis und keine universelle Kontonummer.

Vor allem beantwortet sie eine Inhaberfrage: Unter wem ist eine Ressource registriert? Eine Ereigniskennung würde eine andere Frage beantworten: Welche Zustandswechsel gehören zu derselben Entscheidung? Wer beide Begriffe gleichsetzt, ändert die Bedeutung des Feldes.

Der Ressourcentyp gehört zum Schlüssel

Der README-Text nennt drei Bedingungen, unter denen mehrere Zeilen als eine Allokation oder Zuweisung gelten können: gleicher Typ, gleiche opaque ID und gleiches Datum. Das Wort Typ ist nicht optional.

Mehrere IPv4-Bereiche desselben Inhabers und Datums können so zu einer IPv4-Entscheidung zusammengeführt werden. ASN und IPv4 bleiben dagegen verschiedene Typen. In diesem Fall stimmen Kennung und Datum überein, der Typ aber nicht.

Mehrere harmlose Abläufe passen zum Befund. Eine Organisation könnte in einem koordinierten Vorgang ASN und Präfix beantragt haben. Zwei getrennte Anträge könnten durch verschiedene Prüfungen gelaufen und am selben Tag wirksam geworden sein. Oder zwei zu unterschiedlichen Zeiten entschiedene Vorgänge könnten in derselben Tagesdatei erschienen sein.

Keine Variante ist aus den Zeilen auszuwählen. Den Inhaber als Transaktion zu behandeln, könnte getrennte Fälle verschmelzen. Es könnte auch Prüfbelege des einen Ressourcentyps ohne Grundlage auf den anderen übertragen.

Diese Unsicherheit ist keine Anschuldigung. Sie ist eine Eigenschaft des veröffentlichten Datenmodells und sollte als solche benannt werden.

Ein Tagesdatum ist keine Prozessuhr

Beide neuen Zeilen enthalten 20260828, während die sichtbare Änderung in der Datei vom 29. August liegt. Daraus folgt ein registriertes Allokations- beziehungsweise Zuweisungsdatum am 28. August, nicht die Uhrzeit der Entscheidung.

Unbekannt bleiben Eingang des Antrags, Vollständigkeit der Unterlagen, Abschluss der Prüfung, Zahlungsabwicklung, Änderung der operativen Datenbank und Erstellung der öffentlichen Datei. Eine Tagesprojektion kann korrekt sein, obwohl sie diese Schritte nicht als Transaktionsjournal abbildet.

Auch NA hat eine enge Bedeutung. Nach AFRINIC bezeichnet der Ländercode den rechtlichen Sitz des Inhabers. Er darf nicht zuverlässig als Standort der IP-Nutzung interpretiert werden. Die Zeilen belegen daher weder Routing in Namibia noch dortige Geräte, Kunden oder Verkehr.

Sie belegen ebenso wenig BGP-Ankündigung, ROA, Aktivierung in WHOIS oder RDAP, Reverse DNS oder einen Diensterfolg. Die ASN ist allocated, der IPv4-Bereich assigned. Beide Wörter sind Registerzustände und kein Synonym für produktiven Betrieb.

Das stärkste Argument für das schlanke Format

Die erweiterten Statistiken sind ein gemeinsames RIR-Projekt. Ein kompakter, stabiler Aufbau macht tägliche und regionale Vergleiche möglich. Er soll nicht die internen Fallverwaltungssysteme der fünf Register vereinheitlichen oder öffentlich spiegeln.

Mehr Verknüpfung erzeugt Datenschutzrisiken. Eine beständige Fallnummer könnte Antragsrhythmen, Produkteinführungen oder Netzpläne verraten. Bedarfsnachweise, Rechnungen, interne Tickets, Mitarbeitendennamen und Kommunikation gehören nicht in die Statistik.

Die beiden Dateien liefern keinen Anhaltspunkt für Fehlverhalten. Ihre offiziellen MD5-Werte stimmen, die OpenPGP-Signaturen sind gültig, und die IPv4-Teilung ist exakt. Die Ausgabe eines ASN und eines /24 an denselben Inhaber kann ein vollständig normaler Vorgang sein.

Gerade eine enge Ereignisbeziehung würde diese gutartige Lesart schützen. Ohne sie kann Kritik einen geheimnisvollen Zusammenhang andeuten; Verteidigung kann ebenso unbelegt behaupten, alles sei ein Antrag gewesen. Ein kleiner Nachweis begrenzt beide Erzählungen.

Ein Ereignisnachweis ohne öffentliches Dossier

Die fehlende Kennung sollte den Ausstellungsakt, nicht den Inhaber bezeichnen. Ein pseudonymes Episoden-ID könnte Ressourcentyp, Start, Größe, vorherigen und neuen Status auflisten. Für IPv4 würde es den Quell-/20, das entnommene /24 und die vier Restbereiche verbinden.

Die Beziehung zwischen Zeilen kann auf drei Werte beschränkt bleiben: gemeinsam in einer Entscheidung ausgestellt; getrennte Entscheidungen mit gemeinsamem Wirksamkeitsdatum; kein Ereigniszusammenhang. Antragsklasse und Regelgrundlage können grob bleiben. Entscheidungs-, Wirksamkeits- und Veröffentlichungsdatum sollten getrennt werden.

Korrekturen müssen ihren Vorgänger nennen. Eine spätere Änderung darf den früheren Stand nicht geräuschlos überschreiben. Name des Inhabers, Antragsnarrativ, Rechnung, interne Ticketnummer, prüfende Person und sicherheitsrelevante Details bleiben nichtöffentlich.

Falls eine dauerhafte Episoden-ID zu viel Korrelation ermöglicht, kann AFRINIC nur eine signierte gemeinsam-ausgestellt-Beziehung zwischen den beiden öffentlichen Zeilen liefern. Eine nicht durchsuchbare kryptografische Bindung wäre eine weitere Möglichkeit.

Das Ziel ist kein dickes Aufsichtssystem. Es ist der kleinste Nachweis, der Inhaberidentität und Ereignisidentität auseinanderhält.

Der belastbare Befund bleibt begrenzt

Zwischen zwei signierten Dateien wurde ASN 329802 von verfügbar zu allokiert. Das letzte /24 eines verfügbaren /20 wurde zugewiesen. Der IPv4-Rest stimmt exakt. In der späteren Datei teilen beide Ressourcen Datum, Ländercode und Inhaberkennung.

Nicht belegt sind ein gemeinsamer Antrag, eine gemeinsame Genehmigung oder Transaktion. Ebenso wenig belegt sind Routing, Nutzung, Schaden, Verzögerung, Regelverstoß oder institutionelles Fehlverhalten.

Ein genaues Register muss private Vorgänge nicht offenlegen. Es muss nur verhindern, dass ein Feld zwei unvereinbare Aufgaben übernimmt. AFRINIC hat Zustand, Inhaberbeziehung und Bestandsrechnung veröffentlicht. Für die gemeinsame Entscheidung fehlt ein eigenes, dünnes Beweisobjekt.

Quellen