Zusammenfassung

  • AFRINIC behandelt transferierte Legacy-IPv4-Ressourcen nach der adoptierten Regel in CPM v1.6 (Abschnitt 5.7.4.3, Stand 17. November 2020) und auf der Transfer-Seite nicht mehr als Legacy; der Block kann unter denselben Adressen weiter genutzt werden, die Registerkategorie ändert sich.
  • Die Transferprüfung verlangt einen rechtmäßigen Inhaber ohne aktiven Streit, korrekte Kontakte, Mitgliedschaft, Bedarfsbegründung und die neueste RSA; M&A-Transfers folgen einem gesonderten Genehmigungsverfahren.

Ein IPv4-Block kann im Netz weiter genutzt werden, während das Register ihn anders einordnet. Der praktische Effekt der adoptierten Regel liegt im Register: Die Kategorie wechselt bei der Registeraktualisierung; Netzroute, Rechtstitel und wirtschaftliche Zuordnung sind getrennte Fragen. Im Folgenden geht es darum, welche Verfahren diese Änderung auslösen und wo CPM und RSA den Prüfrahmen setzen.

Die adoptierte Regel und ihre institutionelle Einordnung

AFRINIC ist das Regional Internet Registry für Afrika und den Indischen Ozean. Es verwaltet IPv4, IPv6 und ASNs und entwickelt Politik im offenen Multi-Stakeholder-PDP. Die öffentliche About-Seite beschreibt AFRINIC als gemeinnützige, mitgliederbasierte Organisation nach dem Gesellschaftsrecht von Mauritius; sie ist eines von fünf RIRs, erhält Zuweisungen von Public Technical Identifiers und wirkt an der Koordination der IANA-Funktionen mit. Die Satzung von 2020 weist sie als private company limited by guarantee aus.

Diese Einordnung erklärt, warum das Register nicht nur eine Datenbank führt, sondern ein administratives Tor für Mitgliedschaft, Ressourcendokumentation, Reverse-DNS-Delegationen, Zertifizierung und Transferprüfung bildet. Die Regel in Abschnitt 5.7.4.3 setzt das Ergebnis der Kategorieänderung; sie ist keine Aussage über Netzroute, Rechtstitel oder wirtschaftliche Zuordnung. Weil die Kategorie bei der Registeraktualisierung wechselt, kann ein Inhaber aus dem weiteren Routing nicht ableiten, dass der Legacy-Status fortbesteht. Due Diligence muss deshalb Netzbetrieb und Registerstatus getrennt prüfen.

CPM v1.6 belegt keine vollständigen Politiktexte oder Ratifikationsakten aus 2026; die Aussage zur Legacy-Umwandlung bleibt dennoch eine dokumentierte Registerregel.

Verfahren nach CPM und RSA

CPM v1.6 behandelt unter anderem die Verwahrung öffentlicher Ressourcen, Registrierung, die Behandlung nicht registrierter Ressourcen, die Bedarfsprüfung bei Transfers, die Legacy-Umwandlung, ASN-Verwahrung und IPv6-Lizenzierung. Im Transferverfahren reicht die Einigung der Parteien nicht. Entscheidend ist die Reihenfolge: Zuerst prüft das Register den rechtmäßigen Inhaber und einen ungelösten Streit; das sind registerrechtliche Eingangsfragen. Danach folgen Kontakt und Mitgliedschaft, weil das Register den Antragsteller erreichen und als Gegenüber behandeln muss.

Erst dann ordnet man Bedarfsbegründung, RSA-Zustimmung und vertragliche Nebenabreden zu. Bei M&A kommt der gesonderte Genehmigungsweg hinzu. Wer diese Reihenfolge umdreht, verwechselt eine kommerzielle Zusage mit einem Registerbeweis.

Die Legacy-Umwandlung setzt an der Registeraktualisierung an; sie ist kein separater Netzakt. Die öffentlich dokumentierte RSA-Fassung trägt den Versionsstand vom 27. November 2017. Sie enthält Aussagen zu Transferverbot und Zustimmungserfordernissen, Haftungsobergrenzen und Widerruf bei Vertragsende. Diese Klauseln beeinflussen den Umfang von Rechtsbehelfen und das Risiko einer Beendigung; deshalb sollte der Due-Diligence-Vermerk die Versionsangabe festhalten.

Praktische Folgen – Nachweispaket und Vertragsbedingungen

Für die Transaktionsvorbereitung ist zuerst das maßgebliche Dokument zu benennen: die einschlägige CPM-Fassung, die RSA-Version, die Transfer-Seite und die Mitgliedschaftsvereinbarung. Danach ordnet das Nachweispaket Belege den Prüfschritten zu. Inhaberidentität und Streitfreiheit stützen die registerrechtliche Eingangsfrage; Kontakt und Mitgliedschaft zeigen, ob das Register den Antragsteller erreicht; Transferformular, Bedarfsbegründung und Umwandlungsplan verbinden Registervorgang und tatsächliche Nutzung.

Wer diese Ebenen mischt, behandelt eine kommerzielle Zusage als Registerbeweis und übersieht, wo ein Preis- oder Finanzierungsabschluss noch von einer offenen Registerfrage abhängt.

Im Vertrag setzt man deshalb die Registergenehmigung als aufschiebende Bedingung, verbindet Zusicherungen und Gewährleistungen mit den tatsächlich prüfbaren Registerangaben und regelt Escrow, Gebührenzuordnung, Kontinuität von Reverse DNS und Resource Certification sowie den Weg für Einspruch und Überprüfung. Der Nutzen liegt nicht in der Anzahl der Klauseln, sondern darin, dass jede Klausel an einen dokumentierten Prüfpunkt anschließt. Wer den Transfer will, muss zuerst die Registerfrage klären; erst danach kann die kommerzielle Zusage darauf aufbauen.

Ein Designvorschlag

Die Regel setzt das Ergebnis der Kategorieänderung; die Prüfung, welche Nachweise in welcher Reihenfolge zählen, ist eine Entscheidung der anwendbaren Verfahren und Verträge. Der Designvorschlag setzt deshalb an einer Trennung an: Registerbeweis und Genehmigung des Geschäftsmodells. Das Register prüft, ob der Antragsteller der anerkannte Inhaber oder ein legitimer Nachfolger ist, ob ein ungelöster konkurrierender Anspruch besteht, ob die Kontakte korrekt sind und ob die für Betrieb und Missbrauch Verantwortlichen erreichbar sind.

Ein Interesse an regionaler Nutzung und Datenintegrität sollte nur so weit reichen, wie es nicht zur Prüfung der Geschäftsstrategie wird.

Daran schließt eine öffentliche Legacy-Konvertierungskarte an. Sie sollte den Statusverlust, die Benachrichtigung des Inhabers, Übergangsschutz, die Wirkung auf Mitgliedschaft, Transferierbarkeit, Überprüfung, Reverse DNS und Zertifizierung sowie die Umkehrbarkeit in einem Verfahren erklären. Ergänzend braucht es eine Kategorien-Disziplin: vom verifizierten Inhaber über Nachfolger in Prüfung, ruhenden Kontakt, fehlende historische Dokumentation, konkurrierenden Anspruch, Betrugsermittlung, gerichtliche Sperre und Zahlungssperre bis zur Transfersperre. Jede Kategorie braucht Prozess, Frist und Folge.

Nach angemessener Prüfung sollte Finalität die Regel sein; Wiedereröffnung nur bei Betrug, wesentlicher Falschdarstellung, Gerichtsbeschluss, definiertem Politikverstoß oder später entdecktem konkurrierendem Anspruch. Verhältnismäßigkeit bedeutet zuerst Korrektur, Rücknahme als letztes Mittel. Wo das Register zugleich Richter und Partei ist, sollte eine unabhängige Überprüfung hinzukommen. Der Vorschlag antwortet auf den Entscheidungskonflikt zwischen Registerbeweis und Geschäftsmodell; er ist keine adoptierte Politik.

Beobachtungsfelder und offene Punkte

Das NRO RIR Governance Document Version 3 trägt den Stand FINAL DRAFT vom 1. September 2026 und ist zur Prüfung und Diskussion vorgelegt. Der Entwurf schlägt offene Mitgliedschaft, operative Unabhängigkeit, Kontinuität in Notlagen, Audits, Compliance-Prüfungen und Derecognition vor. Die ICP-2 der ASO/ICANN ist ein 2001 angenommener Prinzipienrahmen für die Anerkennung neuer RIRs; der NRO EC bat die ASO AC im Oktober 2023 um eine Überprüfung. Diese Dokumente bilden den Governance-Kontext; für die AFRINIC-Transferpraxis zählt, ob und wann daraus angenommene Regeln und Umsetzungsverfahren werden.

Bei der Transferpolitik ist die Klarstellung zur Legacy-Konvertierung der entscheidende Beobachtungspunkt: ob Prüfkategorien veröffentlicht werden und ob die Konvertierung prospektiv oder rückwirkend gilt. Beim NRO-Version-3-Text sind Annahme, ICANN-Schritte und Umsetzungsverfahren zu verfolgen. Die AFRINIC-Newsseite von 2026 enthält Hinweise auf Gerichts- und Governance-Mitteilungen; ihre Kurzfassungen sind nicht der Volltext. Deshalb liefert die Newsseite ein institutionelles Signal, aber keinen belastbaren Schluss auf ein Gerichtsurteil über Adresseigentum.

Offen bleibt nicht die Regel selbst, sondern ihre Anwendung: Ob die erfasste RSA-Fassung heute gilt und welche Rechtswirkung sie hat, ist ebenso zu prüfen wie die Belastbarkeit des Gebührenhinweises und die Behandlung von M&A, Umstrukturierung, Leasing und Inter-RIR-Transfers. Der Kategorienwechsel nach einem Transfer ist belegt; seine konkrete Wirkung auf Mitgliedschaft, Gebühren, Reverse DNS, Zertifizierung und Transferierbarkeit hängt von den anwendbaren Regeln und Verträgen ab.

Sicht der Beteiligten

Die öffentliche Analyse von LARUS und die Notiz auf heng.lu argumentieren für ein Register, das den Datensatz führt und nicht das Netz kontrolliert. LARUS betont den Rechtstitel- und Registerbeweis; heng.lu formuliert die Trennung von Registerführung und Netzwerkkontrolle als Designprinzip. Beide sind interessierte Positionen zur Gestaltung, keine adoptierte AFRINIC-Politik. Ihr Prüfmaßstab ist dennoch praktisch: Wenn ein Register einen Block anerkennt, aktualisiert es nicht nur eine Zeile, sondern definiert das administrative Tor, durch das Transfers, Dienste und Streitigkeiten laufen. Genau an diesem Tor setzt der Designvorschlag an.