Zusammenfassung

  • APNICs signiertes Gesamttransferprotokoll weist neun Präfixe am 1. September 2026 als M&A von ZTNET CO., LTD (KH) an ZT INFORMATION NETWORK CO., LIMITED (HK) aus.
  • Die übertragenen Präfixe umfassen 57.088 Adressen beziehungsweise 223 /24-Einheiten. Ein /24 und ein /19 mit 8.448 Adressen bleiben auf der bisherigen Seite; beide Mengen ergeben exakt das ursprüngliche /16.
  • Die folgende Delegationsdatei macht aus einer Zeile elf, behält aber überall 20071203. Laut APNIC-Dokumentation führt eine aus einem anderen Register übertragene Ressource das erste Zuteilungs- oder Zuweisungsdatum des ursprünglichen RIR fort.
  • Eine belastbare Zeitleiste muss Transferereignis und Ressourcenursprung getrennt benennen und die datierten Dateien, Hashes sowie die Präfixrechnung erhalten.

Neun Präfixe definieren den öffentlichen Umfang

Das APNIC-Gesamttransferprotokoll vom 1. September 2026 enthält neun Zeilen mit identischen Parteien, Datumsfeldern und demselben Typ. Quelle ist ZTNET CO., LTD mit KH; Empfänger ist ZT INFORMATION NETWORK CO., LIMITED mit HK. Als früheres Delegationsdatum steht 20071203, als Transferdatum 20260901, als Typ M&A.

Die prop-142-Spezifikation bezeichnet transfer_date als den Tag, an dem der Empfänger die Ressource erhielt. M&A bedeutet, dass APNIC den Transfer nach der Merger-and-Acquisition-Richtlinie bearbeitete. Daraus folgen weder Kaufpreis noch Gegenleistung, Vertrag, Kontrollwechsel oder konkrete gesellschaftsrechtliche Konstruktion. Öffentlich ist die Registerkategorie, nicht die Unternehmensakte.

Übertragen wurden 79.109.0.0/24, 79.109.2.0/23, 79.109.4.0/22, 79.109.8.0/21, 79.109.16.0/20, 79.109.32.0/19, 79.109.64.0/18, 79.109.128.0/18 und 79.109.192.0/19. Zusammen enthalten sie 57.088 Adressen, also 223 Einheiten zu je /24.

Zwei Bereiche des früheren /16 fehlen in der Empfängermenge: 79.109.1.0/24 und 79.109.224.0/19. Sie umfassen 8.448 Adressen oder 33 /24-Einheiten. Die Kontrolle ist vollständig: 57.088 plus 8.448 ergibt 65.536, und 223 plus 33 ergibt 256 /24 – genau ein /16. Warum dieser Rest blieb, lässt sich daraus nicht ableiten.

Die Delegationsstatistik misst kein letztes Besitzereignis

In der Datei vom 1. September steht der Bereich in einer Zeile: Start 79.109.0.0, Wert 65.536, Volkswirtschaft KH, Status allocated, Datum 20071203, opaque ID A91100B2.

APNIC stellte die Datei vom 2. September als gzip bereit. Entpackt enthält sie elf betroffene Zeilen. Neun tragen HK und A91556B2 und entsprechen den transferierten Präfixen. Zwei tragen KH und die bisherige ID und bilden /24 plus /19 ab. Das Datum lautet in allen elf Fällen 20071203.

Das ist in README-EXTENDED so vorgesehen. Wenn eine Zuteilung oder Zuweisung aus einem anderen Register übertragen wurde, bezeichnet das Datumsfeld die erste Zuteilung oder Zuweisung, die vom ursprünglichen RIR übernommen wurde. Die Delegationsdatei bewahrt den Ressourcenursprung; sie ist keine Tabelle des jüngsten Empfängerwechsels.

Das kumulative Transferprotokoll enthält außerdem einen früheren Schritt: das ganze 79.109.0.0/16 ging am 9. Oktober 2025 von RIPE an ZTNET CO., LTD innerhalb APNICs, mit 20071203 als vorherigem Delegationsdatum und Typ Unused. Diese Zeile erklärt nicht die geschäftlichen Umstände von 2007. Sie zeigt aber, wie das Ursprungsdatum spätere Registerereignisse überdauert.

2026 beantwortet folglich die Frage, wann der aktuelle Empfänger die neun Präfixe im APNIC-Prozess erhielt. 2007 beantwortet, welches erste Datum des ursprünglichen RIR die Ressourcen begleiten. Wer beides allocation_date nennt, produziert eine falsche Eindeutigkeit.

23 zusätzliche Zeilen sind keine 23 zusätzlichen Zuteilungen

Die IPv4-Zusammenfassung steigt von 61.519 auf 61.542 Zeilen, netto um 23. APNIC erklärt ausdrücklich, dass diese Zahl Zeilen und nicht Ressourcenmengen zählt.

Der untersuchte Übergang erklärt zehn Zeilen: aus einer werden elf. Die übrigen 13 stammen aus anderen Veränderungen in der Tagesdatei. Auch die Adressmenge des /16 bleibt unverändert. Eine Meldung über „23 neue IPv4-Zuteilungen“ würde Darstellungsfragmentierung, Adressvolumen und Ereignisursache vermischen.

Beide Delegationsdateien und das Transferprotokoll stimmen mit ihren veröffentlichten MD5-Begleitdateien überein. Die drei abgesetzten OpenPGP-Signaturen wurden außerdem über den erfassten Originalbytes mit APNICs exakt veröffentlichtem UID-losen Schlüssel, Fingerabdruck 53484F6685D112B194DD25D9CB342F01D1524E14, geprüft. Das belegt kryptografische Gültigkeit unter diesem Schlüssel. Es belegt keine externe Identitätszertifizierung, kein Web-of-Trust-Urteil und keine ewige Unveränderlichkeit historischer URLs.

RDAP ergänzt den aktuellen Registrierungszustand

Der RDAP-Datensatz des transferierten /24 nennt ZT1-HK und HK; Registrierung und letzte Änderung datieren auf den 1. September 2026. Das verbliebene /24 und das verbliebene /19 erscheinen als ZTNETCOLTD-KH und KH.

Das bestätigt einen öffentlichen Registerzustand. Es beweist keine BGP-Ankündigung, ROA/RPKI-Autorisierung, Nutzung, Dienstleistung, physische Lage, Kundenbeziehung oder wirtschaftliches Eigentum. Auch der Volkswirtschaftscode der Delegationsdatei bezeichnet die Organisation und nicht verbindlich den aktuellen Nutzungsort. Kontaktdaten aus RDAP gehören nicht in diese Analyse.

Ein Nachweisobjekt für beide Uhren

Ein Transferdatensatz sollte Dateiname und SHA-256 des Transferprotokolls, Ereignisdatum und -typ, früheres Delegationsdatum, Präfixliste und Adresssumme festhalten. Hinzu kommen Vorher- und Nachher-Datei der Delegationsstatistik mit Hashes, die Definition des Ursprungsdatums, der verbliebene Rest, der RDAP-Beobachtungszeitpunkt und spätere Korrektur- oder Ersetzungshinweise.

Dieser Zwei-Uhren-Nachweis ist ein Vorschlag für Datennutzer, keine APNIC zugeschriebene Pflicht. Er verlangt weder Verträge noch Mitgliedertickets, Rechnungen, interne Freigaben oder private Kontaktdaten. Er verhindert lediglich, dass Ursprungsdatum und Ereignisdatum ihre Rollen tauschen.

Was nicht belegt ist

Die Quellen belegen keinen Verkauf, Preis, Beweggrund, konkrete Umstrukturierung, Routingänderung, ROA-Zustand, Dienst, Schaden oder Fehlverhalten. Sie erklären nicht, warum 8.448 Adressen verblieben. Die opaque ID gruppiert einen Halter innerhalb der Serie und kann sich zwischen Versionen ändern. Der Vorgang erklärt zehn der 23 zusätzlichen IPv4-Zeilen, nicht alle.

Quellen