Zusammenfassung

  • Der hier untersuchte Entwurf ist AFPUB-2019-V4-003-DRAFT02, Version 2.0, eingereicht am 13. August 2020. Das Datum 8. Oktober 2021 gehört zu AFPUB-2020-GEN-006-DRAFT02, einem anderen Vorschlagsstrang, und darf weder dessen Status noch dessen spätere Geschichte auf diesen Entwurf übertragen.
  • ARIN und APNIC hielten die Pflicht des Absenders, die Regeln der empfangenden Registry einzuhalten, für inkompatibel. RIPE NCC beanstandete den Start des Vorgangs bei der empfangenden statt bei der quellführenden Registry. LACNIC verlangte zwar keine Gegenseitigkeit, sah aber ebenfalls beide Übergabefehler.
  • AFRINIC durfte als private technische Registerstelle die eigene Seite einer kompatiblen Umschreibung prüfen und koordinieren. Es konnte weder die Regeln einer anderen Registry außer Kraft setzen noch durch eine fallweise Ausnahme eine nicht ausführbare Schnittstelle heilen.
  • Entwurf 2 wurde vorgeschlagen, diskutiert, geprüft und später archiviert. Ein bedingtes Signal groben Konsenses und eine Last-Call-Phase waren keine Aufnahme in das Consolidated Policy Manual, keine Ratifizierung und keine produktive Umsetzung.
  • Eine belastbare Lösung wäre ein versionsgebundenes Kompatibilitätszertifikat gewesen: für jede Richtung, Ressourcenart und Gegenstelle mit festgelegter Authentifizierung, Startstelle, Nachrichtenfolge, atomarer Registeränderung, abhängigen Diensten, Rückabwicklung und datierter Bestätigung.

L3 — Vier Empfangswege ohne passenden Anschluss

Die Tabelle, die den Entwurf auf den Boden holte

Die entscheidende Szene spielte nicht in einer abstrakten Debatte über offene Märkte. Sie lag in einer Vergleichstabelle. Vier andere regionale Internet-Registries wurden sinngemäß gefragt, ob ihre Transferregeln und Arbeitsabläufe an AFRINICs zweiten Entwurf anschließen könnten. Keine der vier Antworten lieferte den erhofften Beleg für eine ohne Weiteres befahrbare Strecke.

ARIN beanstandete einen Satz, der auf den ersten Blick vernünftig klingen konnte: Die Quelle, also der bisherige Rechtsinhaber der IPv4-Ressource, sollte die Regeln der empfangenden Registry einhalten. Für ARIN war gerade diese Zuweisung mit der eigenen Inter-RIR-Regelung unvereinbar. APNIC kam bei dem maßgeblichen, in Entwurf 2 und dem unmittelbar folgenden Text gleichlautenden Mechanismus zum selben Ergebnis. Auch dort scheiterte die Passung insbesondere daran, dass die Quelle den Regeln der empfangenden Registry unterworfen werden sollte.

RIPE NCC setzte an einem anderen, ebenso grundlegenden Punkt an. Abschnitt 5.7.5 schickte die übertragende Partei mit einem Standardformular und einer offiziellen Transfervereinbarung zunächst zur empfangenden Registry. Nach deren Zustimmung sollte diese die abgebende Registry, die Quelle und den Empfänger benachrichtigen; anschließend sollten die Ressourcen übertragen werden. Das passte nicht zum Verfahren von RIPE NCC, das beim RIR begann, in dessen Register die Ressource zu diesem Zeitpunkt geführt wurde. Wer den Datensatz hält, kann die dort eingetragene Quelle prüfen.

Eine fremde Empfangsstelle kann diese Feststellung nicht allein dadurch übernehmen, dass der AFRINIC-Text ihr den Antrag zuerst zuschickt.

LACNIC machte die Lage besonders aufschlussreich. Gegenseitigkeit war dort keine notwendige Vorbedingung. Trotzdem hielt auch LACNIC die Verpflichtung der Quelle auf die Regeln des anderen RIR für wenig sinnvoll und sah im Beginn bei der empfangenden Registry eine Abweichung von anderen Inter-RIR-Verfahren. Die vier Antworten waren daher keine gemeinsame politische Front gegen Transfers. Sie waren vier praktische Hinweise darauf, dass dieselben Daten, Rollen und Bestätigungen an den Übergabepunkten nicht zusammenpassten.

Damit veränderte sich die zentrale Frage. Sie lautete nicht mehr: Will AFRINIC Transfers erlauben? Sie lautete: Kann eine konkrete, datierte Fassung auf beiden Seiten einer bestimmten Strecke denselben Inhaber, dieselbe Ressource, dieselbe Richtung und denselben Abschlusszustand eindeutig verarbeiten? Ein auf der AFRINIC-Seite als offen beschriebener Weg blieb unbenutzbar, wenn der Anschluss auf der anderen Seite einen anderen Startpunkt, einen anderen Prüfer oder eine andere Bindung der Beteiligten verlangte.

Zuerst die richtige Fassung

Diese Prüfung ist nur brauchbar, wenn Kennung, Datum und Text zusammenbleiben. Gegenstand dieser Analyse ist ausschließlich AFPUB-2019-V4-003-DRAFT02, die Resource Transfer Policy in Version 2.0, eingereicht am 13. August 2020. Der Entwurf sollte Abschnitt 5.7 des Consolidated Policy Manual ändern. Seine Revisionsgeschichte nennt Änderungen an den Abschnitten 5.7.3.1, 5.7.4.1 und 5.7.4.3.

Das mitunter danebenstehende Datum 8. Oktober 2021 gehört nicht zu dieser Kennung. Es bezeichnet die Einreichung von AFPUB-2020-GEN-006-DRAFT02, also einen anderen Vorschlagsstrang. Noch weniger darf die Ratifizierung von AFPUB-2020-GEN-006-DRAFT03, die AFRINIC am 4. Februar 2026 bekanntgab, als nachträgliche Bestätigung des hier untersuchten Entwurfs behandelt werden. Ähnliche Titel schaffen keine gemeinsame institutionelle Biografie.

Auch der Status braucht dieselbe Disziplin. Entwurf 2 wurde eingereicht, erörtert, von Mitarbeitenden geprüft und bei AFRINIC später als archiviert geführt. Er wurde am 17. September 2020 bei AFRINIC-32 neben konkurrierenden Transfervorschlägen vorgestellt. Am 21. September wurde ein bedingter grober Konsens samt Last Call mit einem ausdrücklich genannten ARIN-bezogenen Gegenseitigkeitsproblem und weiterem Änderungsbedarf angekündigt. Das war ein Verfahrensstand.

Es war weder die Annahme des Textes in das Handbuch noch eine Ratifizierung durch das Board, und schon gar kein Nachweis, dass ein einziger Transferweg produktiv umgesetzt worden war.

Vorgeschlagen, diskutiert, bedingt konsensfähig, archiviert, angenommen, ratifiziert und umgesetzt sind verschiedene Zustände. Werden sie vermischt, entsteht eine Scheingenauigkeit: Eine Sitzungshandlung erscheint plötzlich als Betriebsfreigabe. Für Portabilität ist das besonders gefährlich, weil die Gegenstelle keine Absichtserklärung verarbeitet. Sie verarbeitet einen bestimmten Regeltext und eine bestimmte Abfolge von Nachweisen.

Was Entwurf 2 tatsächlich vorsah

Der Entwurf benannte ein echtes Defizit. Die damals bestehende Regelung bot nach seiner Darstellung keinen wechselseitigen Inter-RIR-Mechanismus. Vorgesehen waren Transfers innerhalb der AFRINIC-Region sowie in die Region hinein und aus ihr hinaus. Die Problembeschreibung nannte IPv4-Adressen und AS-Nummern. In den operativen Bestimmungen stand jedoch IPv4 im Mittelpunkt; gerade diese Abweichung bewertete die interne Prüfung als verwirrend.

Als Quelle sollte der aktuelle Rechteinhaber einer bei irgendeinem RIR registrierten IPv4-Ressource gelten. Diese Quelle sollte die Regeln des empfangenden RIR einhalten. Für einen Eingang aus einer anderen Region blieb eine AFRINIC-Prüfung des IPv4-Bedarfs bestehen; AFRINIC sollte den Bedarf des Empfängers nach den jeweils geltenden Regeln billigen. Für einen Ausgang aus der AFRINIC-Region schrieb der Text dagegen vor, dass der Transfer der Regel der empfangenden Registry folgen müsse.

Der mögliche Empfänger wurde weit beschrieben: jede Partei, die mit dem Absender eine Transfervereinbarung erreichte. Die AFRINIC-Mitarbeitenden lasen die Bestimmungen für einen Empfänger in der eigenen Region jedoch so, dass Mitgliedschaft und Bedarfsprüfung erforderlich seien. Zugleich sahen sie einen Konflikt zwischen den Empfängerklauseln 5.7.4.1 und 5.7.4.2. Das ist mehr als redaktionelle Unebenheit. Eine Gegenstelle muss wissen, ob ein benannter Empfänger überhaupt die Eingangsvoraussetzungen erfüllt, bevor sie einen unwiderruflich wirkenden Registerwechsel bestätigt.

Der Entwurf entfernte bestehende Wartefristen von zwölf Monaten. Wo Sender und Empfänger sich geeinigt hatten, sollte es im Rahmen der jeweils geltenden Regel keinen Höchstbetrag für Transfer, Zuteilung oder Zuweisung geben. Übertragene historische IPv4-Ressourcen sollten ihren Legacy-Status verlieren. Diese Punkte verdeutlichen die Reichweite des Vorhabens: Es ging nicht nur um das Verschieben einer Zeile, sondern auch um Berechtigung, Knappheitsprüfung, Zeitbindung, Mengenbegrenzung und Statusfolge.

Die vorgesehene Reihenfolge begann beim Empfänger-RIR. Die übertragende Partei sollte dort anhand einer Standardvorlage und einer offiziellen Vereinbarung anfragen. Nach der Zustimmung sollte das empfangende RIR das übertragende RIR sowie Quelle und Empfänger informieren. Erst dann sollten die Ressourcen übertragen werden. Der Ausdruck „Standardvorlage“ löste selbst eine offene Frage aus: War dieses Format global akzeptiert? Der Nachweis einer Schnittstelle kann nicht darin bestehen, ein Formular als standardisiert zu bezeichnen, wenn die Partner dessen Felder, Bedeutung und Beweiskraft nicht gemeinsam bestätigt haben.

Warum die Quellprüfung keine Formalität war

AFRINICs eigene Prüfung traf den Kern. Warum sollte eine Quelle Regeln einer empfangenden Registry befolgen, zu der sie keine Beziehung hatte? Und wie sollte die Quellinhaberschaft verifiziert werden, wenn die Quelle direkt zur empfangenden Registry ging, statt sich an die Registry zu wenden, die ihren Datensatz führte?

Die zweite Frage lässt sich nicht mit Managementermessen beantworten. Eine Registry hält einen privaten technischen Registerbestand. Ihr sinnvoller Beitrag ist, Anträge zu authentifizieren, den registrierten Status zu prüfen und mit einer kompatiblen Gegenstelle einen eindeutigen Wechsel zu koordinieren. Die Empfangsstelle besitzt nicht automatisch die Belege, mit denen die Quellstelle den Kontoinhaber, die Vertretungsbefugnis, den aktuellen Ressourcenstatus oder einen möglichen Streit erkennen kann. Sie kann auch nicht einfach annehmen, dass die formale Transfervereinbarung all diese Registertatsachen ersetzt.

Genau deshalb ist die Startstelle eine Kontrollentscheidung. Beginnt der Vorgang beim Inhaberregister, kann dieses zuerst klären, ob die Quelle zur Verfügung berechtigt ist und ob die Ressource frei von einem ungeklärten Gegenanspruch behandelt werden darf. Danach kann eine strukturierte, authentifizierte Nachricht an das Zielregister gehen. Beginnt der Vorgang dagegen bei einer Stelle ohne den maßgeblichen Datensatz, droht ein Kreis aus Rückfragen oder eine Bestätigung auf unzureichender Grundlage. Das verursacht Prüfung, Verzögerung und Transaktionsrisiko.

Der vorhandene Nachweis belegt jedoch keinen vollzogenen Verlust, keinen ausgefallenen Dienst und keine gescheiterte konkrete Transaktion; solche Folgen dürfen nicht hinzuerfunden werden.

Die Mitarbeitenden fanden weitere Lücken: Es gab keine Leitlinie für umstrittene Ressourcen. Sie warnten vor Missbrauch durch wiederholte Zuteilungen. Sie sahen den erwähnten Widerspruch zwischen Empfängerklauseln und die unscharfe Rolle von AS-Nummern. Jede dieser Fragen betrifft einen anderen Anschlusswert. Ein sauberer IPv4-Pfad sagt noch nichts über ASN-Transfers. Ein nicht umstrittener Präfix sagt nichts darüber, wie ein offener Anspruch isoliert wird. Eine Mengenfreiheit beantwortet nicht, ob kurz zuvor erhaltene Ressourcen erneut weitergereicht werden dürfen.

Die unsichtbare Betriebsarbeit

Der Entwurf hätte außerdem mehrere abhängige Systeme berührt. Die AFRINIC-Prüfung nannte mögliche Änderungen am Transferwerkzeug in MyAFRINIC, am Reverse DNS, an RPKI-ROAs, Transferprotokollen und dem Ticketsystem. Dazu kamen eine Überarbeitung des Verfahrens, die Abstimmung mit RIRs, deren Regeln tatsächlich kompatibel waren, zusätzliche Kapazität im Mitgliederservice und Softwarearbeit.

Diese Liste erklärt, warum „genehmigt“ kein hinreichender Endzustand ist. Eine Ressource kann nicht zugleich auf der einen Seite als abgegeben und auf der anderen als unbestätigt erscheinen. Der öffentliche Registrierungsstand, Routing-Autorisierungen, Delegationen und der interne Prüfpfad müssen in einer kontrollierten Reihenfolge wechseln. Scheitert ein Teil, braucht es eine festgelegte Rückabwicklung, die weder Duplikate noch verwaiste Zustände erzeugt.

Für Betreiber bedeutet Vorhersehbarkeit hier Geschäftskontinuität, nicht politische Unterwerfung. Die von LARUS beschriebene Betreiberperspektive macht verständlich, warum unklare RIR-Entscheidungen Infrastruktur- und Transaktionsrisiken erhöhen können. Sie belegt aber nicht, dass Entwurf 2 einen bestimmten Ausfall oder Preisverlust verursacht hat. NRS wiederum zeigt aus Mitgliedersicht, dass Kontostatus, Dokumentation, Transferfreigaben und die anwendbaren RIR-Regeln reale Sorgfaltspunkte sind. Beides führt zurück zur Schnittstelle: Der Handelspartner braucht keine Gunst, sondern eine nachvollziehbare Folge überprüfbarer Akte.

Der faire Blick auf den Versuch

Die stärkste wohlwollende Lesart verdient Gewicht. IPv4-Knappheit machte Beweglichkeit wirtschaftlich wichtig. Eine rein intra-regionale Regel konnte Unternehmen in einem regionalen Bestand festhalten, obwohl Bedarf und verfügbare Ressourcen anders verteilt waren. Entwurf 2 strebte Bewegung in beide Richtungen an, beseitigte Mengenobergrenzen, hielt für Eingänge nach AFRINIC an einer Bedarfsprüfung fest und versuchte, Quelle, Empfänger und Übergabe zu definieren.

Zudem mussten die Verfasser fünf institutionelle Systeme mit unterschiedlicher Terminologie und Praxis zusammenbringen. Antworten anderer RIRs kommen nicht augenblicklich, und ein Fehler in einer solchen Fassung beweist weder böse Absicht noch institutionelle Vereinnahmung. Der Maßstab darf deshalb nicht moralische Verdächtigung sein. Er muss ausführbare Genauigkeit sein.

Gerade die wohlwollende Lesart verschärft aber die praktische Antwort. Wenn Portabilität das Ziel ist, darf eine nur auf einer Seite plausible Klausel nicht als fertiger Weg gelten. Vor einer Aussage über Kompatibilität hätte der genaue Text eingefroren, jede Richtung gegen die jeweils aktuelle Gegenregel geprüft und jede Verbindung als bestätigt, bedingt, offen oder inkompatibel ausgewiesen werden müssen. Wo die Quellprüfung und der Antragsbeginn nicht übereinstimmten, fehlte nicht bloß eine freundlichere Formulierung. Es fehlte der erste verlässliche Schritt zu einer einzigen autoritativen Umschreibung.