Zusammenfassung

  • Die Übergabe verlagerte Registerobjekte, Reverse-DNS-Zuständigkeit und Mitgliedsverträge auf AFRINIC, schrieb aber keine eigenständig auslösbare Fortführungs-, Treuhand- oder Portabilitätsgarantie in den Vorgang selbst.
  • Kontinuitätspflichten bestehen nur als allgemeine ICP-2-Anforderungen an das anerkennende RIR; heute ist AFRINIC deren Gegenstand, nicht ihr Durchsetzer.
  • Prüfbar bleibt der operative Test: ob WHOIS- und RDAP-Daten vollständig abfragbar bleiben, ob Reverse-DNS-Delegationen weiter auflösen und ob Mitglieder ihre Datensätze erhalten.

Was zwischen 2003 und 2005 übertragen wurde

AFRINIC wurde 2004 in Mauritius gegründet. Der ICANN-Vorstand erteilte am 30. September 2004 die vorläufige Zustimmung; im April 2005 erkannte ICANN AFRINIC nach den ICP-2-Kriterien als fünftes Regional Internet Registry an. Am 27. April 2005 wurde AFRINIC fünftes Mitglied der Number Resource Organization (Anerkennungs- und Übergabeunterlagen).

Vorher bezogen Netzbetreiber in Afrika Nummernressourcen von APNIC, ARIN und RIPE NCC. RIPE NCC bearbeitete IPv4-Zuteilungen und -Zuweisungen für afrikanische Länder nördlich des Äquators zwischen Oktober 2003 und April 2005 und stellte die Zuteilung an die afrikanische Region im April 2005 ein (RIPE-NCC-Dokumentation zur Regionenübergabe).

Mit dem Ressourcenwechsel endeten auch die Vertragsverhältnisse. RIPE NCC kündigte die Standard Service Agreements mit afrikanischen Mitgliedern; AFRINIC schloss mit diesen Mitgliedern neue Verträge ab. Als Teil des Übergangs unterzeichnete AFRINIC eine Vertraulichkeitsvereinbarung, die LIR-Informationen abdeckt (RIPE-NCC-Unterlagen zum Übergang).

Technisch leistete das AFRINIC-ERX-Projekt die eigentliche Verlagerung: inetnum- und aut-num-Objekte sowie ASNs und provider-unabhängiger Adressraum wurden aus der RIPE-Datenbank in die AFRINIC-Datenbank überführt; referenzierte Objekte wurden übertragen oder kopiert. AFRINIC übernahm zudem Registrierungsdaten von ARIN und APNIC (AFRINIC-ERX-Dokumentation).

Ein Detail dieser Verlagerung wirkt bis heute nach: Wo Ressourcen von RIPE NCC an ein anderes RIR wanderten, wurden die zugehörigen DOMAIN-Objekte in der RIPE-Datenbank gelöscht, und die Verantwortung für die Beantragung neuer Reverse-DNS-Delegationen ging sofort auf die empfangende Seite über (RIPE-Datenbank-Unterlagen zum Reverse-DNS-Übergang). Es gab also keinen Übergangszustand mit doppelter Zuständigkeit und keine automatische Fortschreibung der bisherigen Delegationen – nur einen Stichtag, an dem die neue Seite liefern musste.

Vier Kontrollpunkte und wer sie hielt

Die Übergabe lässt sich als Kette von vier Kontrollpunkten lesen, und an jedem Punkt war die Kontrolle am Ende eindeutig, nicht geteilt.

Erstens der Datenbestand. Die autoritative Kopie der Registrierungsobjekte für die afrikanische Region liegt seither bei AFRINIC; Quellunterlagen bei RIPE NCC blieben Referenz, nicht Reserve. Zweitens die Reverse-DNS-Delegation: Verantwortung und Antragslast wechselten vollständig. Drittens das Mitgliedsverhältnis: Verträge, Abrechnung und Vertraulichkeitsbindung liegen beim Empfänger. Viertens die institutionelle Anerkennung: ICANN erkannte AFRINIC als RIR an, und die Anerkennung ist die Größe, an der Pflichten hängen – nicht die Betriebsbereitschaft des Registers.

Wer diese vier Punkte zusammen hält, hält den Nummernraum einer Region. Wer sie zusammen übernimmt, übernimmt damit auch das Ausfallrisiko der Region – ohne dass die Übergabe selbst dafür eine Gegenmaßnahme vorsah.

Was die ICP-2 verlangt – und was sie nicht auslöst

Die ICP-2-Kriterien verlangen von einem RIR, Fortführungsverfahren, Redundanzen und die Weitergabe von Aufzeichnungen so zu unterhalten, dass ein anderes RIR seine Dienste bei Bedarf übernehmen kann; sie verlangen ferner prüfbare Aufzeichnungen und beschreiben ein Aberkennungs- und Übergabeverfahren, in dem ein aberkanntes RIR mit ICANN und anderen RIRs zusammenarbeiten muss, um den Betrieb auf einen benannten Nachfolger oder eine Zwischeneinrichtung zu übertragen (ICP-2-Kriterien und Anerkennungsverfahren).

Diese Pflichten sind real, aber sie sind an die Institution adressiert. Vorschläge zur Anerkennung oder Aberkennung stammen nach Mehrheitsentscheidung des NRO-Exekutivrats; ICANN behält die letzte Entscheidung. IANA, von ICANN betrieben, trägt die letzte Verantwortung für zugeteilten und nicht zugeteilten IPv4-, IPv6- und ASN-Raum und delegiert Blöcke an die RIRs (ICP-2- und IANA-Zuständigkeitsunterlagen). Das beschreibt Zuständigkeit, nicht Auslösbarkeit: Kein Satz verpflichtet einen Nachfolger, einzuspringen, bevor ein Aberkennungsverfahren abgeschlossen ist.

Section 9 des NRO-MoU richtet ein Advisory Appeals Panel ein, das Beschwerden darüber prüft, dass ein RIR, die NRO oder eine NRO-Unterorganisation dokumentierte globale Policy-Entwicklungsverfahren nicht eingehalten hat; das Panel berichtet dem NRO-Exekutivrat (NRO-MoU und Beschwerdeweg). Das ist ein Verfahrensweg für Policy-Fragen – kein Registerdaten-Escrow und kein Failover-Mechanismus.

Die Prüfung von 2019: rund 4,17 Millionen Adressen

Im Juli 2019 wurde eine Prüfung beauftragt, die um Januar 2021 öffentlich wurde. Sie fand 2.371.584 aus dem freien IPv4-Pool von AFRINIC missbräuchlich entnommene Adressen. Etwa 1.060.864 davon wurden zurückgeholt und für zwölf Monate unter Quarantäne gestellt; 1.310.720 Adressen, die zwei Organisationen zugeordnet waren, blieben zur Rückholung offen. Zusätzlich galten 1.799.168 Legacy-IPv4-Adressen als beeinträchtigt: 394.496 wurden konsolidiert, nicht belegte Änderungen an 467.968 Adressen rückgängig gemacht, 936.704 blieben strittig. Zu den Gegenmaßnahmen gehörten zusätzliche Verifikationsebenen (AFRINIC-Prüfungs- und Übergabeunterlagen, Berichterstattung zum Prüfbefund).

Bemerkenswert ist nicht allein die Größenordnung, sondern der Nachweisweg: Diese Zahlen konnten nur erhoben werden, weil die Registerführung prüfbar war. Genau diese Prüfbarkeit ist der Vermögenswert, den die Übergabe von 2004/2005 mitverlagert hat – und für den es, soweit öffentlich dokumentiert, keine externe Reserve gibt.

Von der Klage zur Zwangsverwaltung

AFRINIC und Cloud Innovation Ltd prozessieren seit etwa Mitte 2019. Am 19. Juli 2022 entschied der Supreme Court of Mauritius zugunsten von Cloud Innovation und hob die vorläufige Einwendung von AFRINIC auf. AFRINIC wurde unter Zwangsverwaltung gestellt; am 15. Oktober 2024 verhandelte der Court of Civil Appeal eine Beschwerde gegen die Verwaltungsanordnung. Am 10. Februar 2025 beendete die Bankruptcy Division die Bestellung des zunächst bestellten Official Receiver und bestellte Herrn Gowtamsingh Dabee; die Frist für die Vorstandswahl wurde bis zum 25. April 2025 verlängert (Verfahrens- und Verwaltungsunterlagen, Berichterstattung zum Verfahrensverlauf).

ICANN schrieb am 6. Juni 2025 an den gerichtlich bestellten Verwalter und verlangte Transparenz und Fairness bei der Vorstandswahl, reichte am 19. Juni 2025 einen Antrag beim Supreme Court of Mauritius ein, erwirkte eine Anordnung, dass der Verwalter ein Kommuniqué zu einer fehlerhaften Registrierung an die Mitglieder richtet, und schrieb am 25. Juni 2025 erneut mit dem Hinweis auf eine mögliche Compliance-Prüfung wegen mutmaßlich betrügerischen Verhaltens. Die Wahl wurde am 23. Juni 2025 ausgesetzt und schließlich vom 10. bis 12. September 2025 durchgeführt.

Am 25. Juli 2025 erklärte der Präsident von Mauritius AFRINIC nach Section 230 des Companies Act zu einer „declared company“, nachdem Cloud Innovation Ltd einen Liquidationsantrag gestellt hatte. Die Erklärung setzt laufende Gerichtsverfahren mit Bezug auf AFRINIC aus und löst eine von der Regierung beauftragte Untersuchung der Angelegenheiten des Unternehmens aus. Der Rechtsstreit wird damit nicht beendet, sondern in ein Verwaltungsverfahren überführt – die Kontrolle über die Gesellschaft liegt nun nicht mehr allein bei ihren Mitgliedern.

Was fehlt: eine auslösbare Fortführungsgarantie

In den für diese Untersuchung zugänglichen öffentlichen Unterlagen findet sich kein Instrument, das in die Übergabe von 2004/2005 selbst eine eigenständig auslösbare Treuhandreserve über die Registerdaten, eine Reverse-DNS-Kontinuitätsgarantie oder ein Portabilitätsrecht für Mitgliederdatensätze schreibt. Kontinuitätspflichten erscheinen ausschließlich als allgemeine ICP-2-Anforderungen an das empfangende RIR – ein RIR, das heute Gegenstand dieser Anforderungen ist und sie nicht durchsetzt (ICP-2-Kriterien, Übergabedokumentation, Reverse-DNS-Unterlagen).

Der beobachtbare Test der Kontinuität ist deshalb operativ und nicht institutionell: Bleiben AFRINIC-WHOIS- und RDAP-Datensätze abfragbar und vollständig? Lösen Reverse-DNS-Delegationen für übertragene Ressourcen weiterhin auf? Erhalten Mitglieder ihre Datensätze? Und hat RIPE NCC irgendeine Ausfallrolle behalten? Keine dieser Fragen ließ sich mit den geprüften Quellen bestätigen (Reverse-DNS- und Übergabeunterlagen, RIPE-NCC-Unterlagen, Übergangsvertragsunterlagen).

Zu den offenen Punkten gehören: die genaue Übergabevereinbarung zwischen RIPE NCC und AFRINIC; Spezifikationen des AFRINIC-ERX-Datentransfers und die Behandlung der DOMAIN-Objekte in Primärform; die Kündigungsbedingungen der Standard Service Agreements; die Reichweite der Übergangs-NDA; die Frage, wer während Zwangsverwaltung und Declared-Company-Verfahren tatsächlich Verwahrer der Register-, Reverse-DNS- und Mitgliedsdaten ist; der volle Wortlaut der Anordnung nach Section 230; und die Nachvollziehbarkeit der Prüfungskette von 2019. Diese Lücken sind keine Nebensache.

Sie sind der Grund, warum dieselbe Frage – wem gehört die Wahrheit über eine Nummer? – nach zwei Jahrzehnten noch offen ist, während die Institution, die sie beantworten müsste, unter Aufsicht steht.