Zusammenfassung

  • AFPUB-2019-v4-001-DRAFT01, Version 1.0, wurde von Jordi Palet Martinez am 13. Mai 2019 als „Under discussion“ veröffentlicht. Der Entwurf wollte eine reale Lücke schließen: Legacy-IPv4-Ressourcen konnten wirtschaftlich die Kontrolle wechseln, während ein fehlender Inter-RIR-Prozess die Registrierungsgeschichte veralten ließ.
  • Rechtmäßige Inhaberprüfung, ein Hinweis auf bestehende Streitigkeiten, die Abstimmung mit dem anderen RIR und ein datierter Registerabgleich sind legitime und wertvolle Leistungen. Sie schützen Inhaber, Empfänger und Netze vor falschen, doppelten oder widersprüchlichen Einträgen.
  • Vertragsbeitritt, eine Bedarfsentscheidung und der Verlust des Legacy-Status sind dagegen eigenständige Folgen. Sie werden nicht schon dadurch notwendig, dass AFRINIC einen Eintrag richtigstellen soll. Entwurf 1 erreichte am 19. Juni 2019 keinen Konsens; seine Veröffentlichung beweist weder Annahme noch Umsetzung noch einen tatsächlich ausgeführten Transfer.

L3 — Der Registereintrag, der ohne Vertrag ankam

Die praktische Ausgangslage war weder theoretisch noch exotisch. AFRINIC erklärte, Legacy-Einträge von RIPE NCC, ARIN und APNIC übernommen zu haben. Diese Einträge betrafen Organisationen in der afrikanischen Dienstregion, mit denen AFRINIC kein gewöhnliches Vertragsverhältnis unterhielt. Der operative Datensatz war also bei AFRINIC angekommen, der historische Rechtstitel oder die tatsächliche Kontrolle aber nicht durch einen AFRINIC-Vertrag entstanden. Genau diese Trennung macht den Fall schwierig.

Wer nur auf die Datenbank schaut, könnte den Eindruck gewinnen, die Stelle, die eine Zeile pflegt, habe auch die zugrunde liegende Position geschaffen. Tatsächlich beschreibt der Eintrag eine außerhalb dieses Vertragsgefüges entstandene Wirklichkeit. Er soll sie für Netze, Gegenstellen und technische Dienste verlässlich abbilden.

Sobald eine Übertragung verlangt wird, reicht jedoch auch die umgekehrte, allzu schlichte Antwort nicht aus. Dass AFRINIC den Block nicht geschaffen hat, verpflichtet es nicht, jede Änderungsbitte ungeprüft einzutragen. Ein veralteter Eintrag ist gefährlich; ein falsch geänderter Eintrag ist es ebenfalls. AFRINICs Hinweise für Legacy-Inhaber sehen deshalb einen Nachweis der Inhaberschaft vor, bevor Organisations- und Ressourcendaten in WHOIS geändert werden. Erst wenn die anfragende Partei nach der Prüfung berechtigt erscheint, soll der Registerstand angepasst werden. Das ist keine Behauptung von Eigentum durch AFRINIC.

Es ist die elementare Sorgfalt eines technischen Buchführers, der vermeiden muss, dass eine fremde Person die öffentlich wirksame Zuordnung umschreibt.

Vor diesem Hintergrund veröffentlichte Jordi Palet Martinez am 13. Mai 2019 die Version 1.0 von „IPv4 Inter-RIR Legacy Resource Transfers“. Die offizielle Kennung lautete AFPUB-2019-v4-001-DRAFT01. Der Status war „Under discussion“, nicht beschlossen, angenommen oder umgesetzt. Vorgeschlagen wurden Änderungen an Artikel 5.7 des Consolidated Policy Manual. Das Problem wurde dabei als fehlender AFRINIC-Mechanismus für regionenübergreifende Legacy-IPv4-Transfers beschrieben. Weil ein Markt bereits existiere, könne eine Bewegung außerhalb des offiziellen Prozesses die Registrierungsgeschichte unterbrechen.

Der stärkste Sinn des Vorhabens lag somit in der Kontinuität des Registers: Die dokumentierte Zuordnung sollte der tatsächlichen Kontrolle nicht hinterherlaufen.

Der Entwurf unterschied zwei räumliche Konstellationen. Ein Intra-RIR-Transfer lag vor, wenn Quelle und Empfänger in der AFRINIC-Dienstregion waren. Ein Inter-RIR-Transfer lag vor, wenn sich eine Partei in dieser Region und die andere in der Region eines anderen RIR befand. Diese Unterscheidung war nicht bloß redaktionell. Sie entschied darüber, welches Register die Empfängervoraussetzungen prüfte, welche Vertragsdokumente den Empfänger binden sollten und wie der Legacy-Status behandelt wurde. Auch der erlaubte Ressourcenumfang war richtungsabhängig.

Für eine Übertragung aus der AFRINIC-Region in die Region eines anderen RIR erlaubte Entwurf 1 nur Legacy-IPv4-Ressourcen. Für eingehende Übertragungen nach Afrika enthielt er keine entsprechende Beschränkung auf Legacy-Bestände. Das Protokoll von AFRINIC-30 gab diese Asymmetrie ebenfalls so wieder: Jede Art von IPv4-Ressource sollte hereinkommen können, hinausgehen aber nur Legacy-IPv4. Darin lag ein versuchter Kompromiss. Er öffnete einen Weg für die besondere historische Klasse, ohne von AFRINIC ausgegebene Ressourcen allgemein für den Abfluss freizugeben.

Ob dieser Kompromiss politisch klug war, ist von der engeren Frage zu trennen, welche Prüfungen für einen konkreten Registerwechsel sachlich erforderlich wären.

Auf der Quellseite verlangte der Text zwei zentrale Sicherungen. Die Quelle musste der gegenwärtige rechtmäßige Inhaber sein, den das jeweils zuständige RIR anerkannte. Außerdem durfte sie nicht in einen Streit über den Status der Ressource verwickelt sein. Beide Anforderungen reagieren auf offenkundige Registerrisiken. Ohne Identitäts- und Kontrollnachweis könnte eine gefälschte Anfrage den eingetragenen Inhaber verdrängen. Ohne Streitkennzeichnung könnte eine technische Änderung den Eindruck erwecken, ein ungelöster Anspruch sei entschieden.

Die richtige Konsequenz ist allerdings begrenzt: Ein aktiver Konflikt rechtfertigt es, keine voreilige Änderung vorzunehmen. Die Registerprüfung wird dadurch nicht zu einem endgültigen Urteil darüber, wem ein Adressblock nach privatem oder öffentlichem Recht gehört.

Für den Empfänger sah der Entwurf andere Fragen vor. Befand er sich in der AFRINIC-Dienstregion, sollte AFRINIC den nach bestehenden Regeln nachgewiesenen IPv4-Bedarf genehmigen. Befand er sich in einer anderen RIR-Region, sollten die Regeln des Zielregisters das maßgebliche Kriterium liefern. Hinzu kam die Aussage, der Empfänger müsse Mitglied des betreffenden RIR sein und dessen Richtlinien sowie Rechtsdokumenten oder Dienstleistungsverträgen unterliegen. Damit verließ der Entwurf die reine Quellenauthentifizierung.

Er verknüpfte die Anerkennung des Empfängers mit einem organisatorischen Status, einer Bedarfsprüfung und einem Vertragsrahmen.

Diese Verknüpfung muss präzise gelesen werden. Ein Empfänger kann laufende Registerdienste wünschen, und ein Dienstleister kann offen beschreiben, zu welchen Bedingungen er diese Leistungen anbietet. Mitgliedschaft, Ansprechpartner, Zahlungswege, Sicherheitskontakte und Verantwortung für die weitere Pflege lassen sich in einem Vertrag sinnvoll ordnen. Daraus folgt aber nicht, dass ein korrekter Wechsel des Registereintrags logisch nur möglich wäre, wenn jede Vertragsbedingung akzeptiert wird. Noch weniger folgt daraus, dass die historische Stellung der Ressource von selbst verschwindet.

Registerpflege und Vertragsbeitritt können gleichzeitig angeboten werden, bleiben aber unterschiedliche Geschäfte.

Bei der Statusfolge war Entwurf 1 für zwei Fälle ausdrücklich. Legacy-IPv4-Ressourcen sollten nach einem Intra-RIR-Transfer nicht mehr als Legacy gelten. Dasselbe sollte für einen Inter-RIR-Transfer gelten, der in die AFRINIC-Dienstregion einging. Für einen ausgehenden Inter-RIR-Transfer erklärte der Text vom 13. Mai dagegen nicht, welchen Legacy-Status die Ressource danach haben sollte. Diese Stille darf nicht mit einer allgemeinen Verlustregel gefüllt werden.

Die präzise Aussage lautet daher: Der Entwurf ordnete den Statusverlust in den beiden benannten Richtungen an und ließ die resultierende Stellung eines ausgehenden Blocks im Text offen.

Gerade die Kombination aus fehlendem Altvertrag und automatischer Statusfolge legt die institutionelle Spannung frei. Der Legacy-Inhaber erscheint am Anfang als Partei außerhalb der gewöhnlichen Registration Service Agreement-Kette. Um eine tatsächliche Veränderung sauber dokumentieren zu lassen, muss er einen Prozess nutzen, dessen vorgeschlagene Folgen über die Korrektur der Zeile hinausreichen. Beim Intra-RIR-Fall soll der Block nach dem Transfer seine historische Einordnung verlieren. Beim eingehenden Inter-RIR-Fall trifft ihn dieselbe Folge.

Ob der Empfänger einen neuen Dienstleistungsvertrag freiwillig und informiert schließen will, ist eine legitime Vertragsfrage. Ob die richtige Datenbankpflege als Hebel dienen darf, diese Antwort vorzugeben, ist die entscheidende Grenzfrage.

Entwurf 1 enthielt auch eine zeitliche Beschränkung für die Quelle. Nach dem Transfer sollte sie zwölf Monate lang keine weiteren IPv4-Zuteilungen oder -Zuweisungen von AFRINIC erhalten können. In der vorgeschlagenen Spalte fehlte hingegen die bis dahin bestehende Einschränkung, nach der ein Empfang innerhalb der vorangegangenen zwölf Monate einen Transfer verhinderte. Für die Bewertung ist beides festzuhalten, ohne daraus einen vollzogenen Sanktionsfall zu erfinden. Die Nachfrist stand im Entwurf; eine tatsächliche Anwendung auf eine bestimmte Partei ist nicht belegt.

Bei der Interoperabilität machte der Autor mehrere Aussagen über andere Regionen. Der Vorschlag werde bidirektionale Transfers mit LACNIC und RIPE erlauben, den Austausch mit APNIC auf Legacy-Ressourcen begrenzen und wegen der dortigen Reziprozitätsformulierung keinen Austausch mit ARIN zulassen. Das sind Kompatibilitätsbehauptungen des Vorschlags. Sie wurden in den hier zugrunde liegenden Belegen nicht unabhängig für jede Gegenregion neu entschieden. Man kann sie daher nutzen, um die vorgesehene Architektur zu verstehen, nicht aber als endgültiges Urteil über die Regeln oder das Verhalten der vier anderen Register.

Auch die Gebührenfrage verlangt eine saubere Herkunftsangabe. Entwurf 1 schuf keine neue Transfergebühr und legte keine solche Gebühr fest. Der zeitgenössische Maßstab stammt aus AFRINICs Transferleitfaden mit dem Stand Februar 2018. Danach zahlte ein Legacy-Übertragender, der kein Mitglied war, keine Transfergebühr. Ein neuer Empfänger als Mitglied hatte den Jahresbeitrag und eine einmalige Zuteilungs- oder Zuweisungsgebühr zu tragen; für ein bestehendes Mitglied fiel die einschlägige einmalige Gebühr an, während es seinen guten Mitgliedsstatus wahren musste.

Diese Aufteilung beschreibt den damaligen Dienstleistungsrahmen, nicht eine im Mai 2019 neu erfundene Belastung.

Die Unterscheidung ist mehr als formale Quellenpflege. Würde man die Gebühren aus dem Leitfaden dem Entwurf zuschreiben, erschiene die Vorlage als finanziell umfangreicher, als sie tatsächlich war. Würde man umgekehrt die Gebührenlage ganz ausblenden, fehlte ein wichtiger Teil der praktischen Entscheidung für Quelle und Empfänger. Richtig ist: Der vorgeschlagene Transferprozess traf auf einen bestehenden Dienstleistungs- und Gebührenrahmen. Die Quellenposition eines nicht angeschlossenen Legacy-Inhabers war darin gebührenfrei. Empfängerseitig konnten Mitgliedschaft und einmalige Leistungen Kosten auslösen.

Ob die Beträge nachweislich nur den Bearbeitungsaufwand deckten, ist nicht belegt; der Leitfaden enthält keine Kostenstudie.

Am 19. Juni 2019 wurde die Legacy-Vorlage bei AFRINIC-30 gemeinsam mit einer getrennten, umfassender angelegten Vorlage diskutiert. Dass beide nebeneinander auftraten und ihr Autor den inhaltlichen Unterschied als einen Satz beschrieb, macht sie nicht zu demselben Instrument. Für diese Analyse zählt allein AFPUB-2019-v4-001-DRAFT01. Das Sitzungsprotokoll hält Einwände aus dem Saal und die richtungsabhängige Legacy-Grenze fest. Die Co-Vorsitzenden stellten keinen Konsens fest und schickten beide Vorlagen zurück auf die Mailingliste. Damit hatte Entwurf 1 an diesem Tag nicht einmal die private Verfahrensschwelle von AFRINIC überschritten.

„Kein Konsens“ bedeutet dabei genau das und nicht mehr. Es ist ein klarer Gegenbeleg gegen die Darstellung, Entwurf 1 sei im Juni angenommen worden. Es ist aber kein Gerichtsurteil über die Natur von IPv4, kein öffentlich-rechtlicher Entscheid und keine nachträgliche Aussage über alle denkbaren Transfermechanismen. Ebenso wenig belegt der Sitzungsverlauf, dass irgendein Inhaber unter diesem Text tatsächlich eine Ressource übertragen, einen Status verloren oder eine Gebühr gezahlt hätte. Der nachweisbare Vorgang ist Beratung mit anschließender Rückgabe zur weiteren Diskussion.

Auf der offiziellen Vorschlagsseite folgte eine Einschätzung des AFRINIC-Personals vom 20. Juli. Sie gehört zum Lebenslauf derselben Vorlage, ist jedoch nicht Teil der Worte, die der Autor am 13. Mai vorgelegt hatte. Das Personal verstand übertragenen Legacy-Bestand als einem Registration Service Agreement unterworfen und als nicht länger legacy. Es notierte außerdem Umsetzungsfragen und verzeichnete keine Hinweise eines Rechtsberaters. Diese Passage zeigt, wie die Verwaltung den Text las und welche Schwierigkeiten sie sah. Sie ist weder eine nachträgliche Ergänzung durch den Autor noch ein unabhängiger Rechtsspruch.

Die offizielle Seite nennt den 3. Dezember als letzte Änderung und führt weiterhin den Status „Under discussion“ sowie nur einen Eintrag in der Versionsgeschichte. Auch daraus lässt sich keine spätere Fassung, Annahme oder operative Verwendung ableiten. Die belastbare Chronologie bleibt eng: Vorlage am 13. Mai, Diskussion ohne Konsens am 19. Juni, Personaleinschätzung am 20. Juli und ein späteres Änderungsdatum der Seite. Jede Behauptung über einen ausgeführten Transfer oder eine verbindliche Regel würde diese Beweislage überschreiten.

Für den Legacy-Inhaber lagen die unmittelbaren Interessen auf der Hand. Er brauchte eine Möglichkeit, eine echte Veränderung dokumentieren zu lassen, ohne dass ein veralteter Registerstand seine Gegenpartei, technische Dienstleister oder Sicherheitskontakte in die Irre führte. Gleichzeitig musste er wissen, ob die Bitte um Aktualisierung seinen historischen Status oder seine vertragliche Stellung verändern sollte. Für den Empfänger zählten die Gewissheit, dass die Quelle handeln durfte, die künftige Erreichbarkeit von Registerdiensten und die Offenheit über Mitgliedschaft, Gebühren und Verpflichtungen.

Für Betreiber zählte vor allem, dass die veröffentlichte Zuordnung mit der operativen Kontrolle übereinstimmte.

Diese drei Interessen laufen teilweise zusammen. Alle profitieren davon, dass eine falsche Person den Eintrag nicht ändern kann. Alle profitieren von einer eindeutigen Kommunikation zwischen den beteiligten Registern. Alle profitieren von einem Zeitpunkt, ab dem WHOIS, Organisationsdaten und Ressourcenzuordnung denselben Zustand beschreiben. Der Konflikt beginnt nicht bei diesen Sicherungen. Er beginnt dort, wo der Zugang zu ihnen zum Preis einer anderen, nicht technisch erforderlichen Rechtsfolge gemacht wird.

Die offenen Punkte müssen sichtbar bleiben. Es ist kein konkreter Transfer unter dem nicht angenommenen Entwurf belegt. Es gibt keine Zahl zu Marktvolumen, Preisen, off-record abgeschlossenen Geschäften oder messbaren Liquiditätseinbußen im Jahr 2019. Die vollständige Mailinglisten-Debatte liegt nicht vor. Die heutige Seite für Legacy-Inhaber wurde nach 2019 aktualisiert und darf nur die dauerhafte Struktur — geerbte Einträge, fehlender Vertrag, Prüfung vor Änderung — erklären, nicht jedes heute genannte Dokument in den Mai 2019 zurückprojizieren.

Und keine der herangezogenen Unterlagen entscheidet, ob IPv4 in einer bestimmten Rechtsordnung Eigentum ist.

Trotz dieser Grenzen lässt sich die zentrale Tatsache sicher erkennen. Die Vorlage wollte ein echtes Genauigkeitsproblem lösen und koppelte seine Lösung an mehrere unterschiedliche Kontrollflächen. Genau deshalb verdient sie weder pauschale Ablehnung noch institutionellen Freibrief. Man muss jede Fläche einzeln prüfen: Wer ist die Quelle? Gibt es einen offenen Statusstreit? Wie gleichen die Register ihre Einträge ab? Welche transparenten Kosten entstehen für die Leistung? Und welche Vertrags- oder Statusfolge soll unabhängig davon vereinbart werden?

Erst diese Trennung zeigt, was gute Registerführung leistet und wo sie in unzulässige Vereinnahmung umschlagen kann.