Zusammenfassung

  • AFRINICs Implementierungserfahrungsbericht von 2018 beschreibt einen konkreten Fall: Ein anonymer End User konnte für ein redundantes zweites Rechenzentrum kein zusätzliches /24 erhalten, weil die Gesamtnutzung unter 90 Prozent lag.
  • AFPUB-2026-IPv4-002-DRAFT02, derzeit im Last Call, würde eine Abweichung zulassen, wenn bestehende Ressourcen einen nachgewiesenen technischen Zweck praktisch nicht bedienen können. Als gemeinsame Beweisregel bleibt jedoch nur eine ausreichend dokumentierte Begründung; die Sitzungsdebatte lehnt bewusst eine universelle Unterlagenliste ab.
  • Flexibilität verlangt keine unsichtbare Entscheidung. Ein geschützter, versionierter Ausnahmebeleg kann Normalberechnung, Ausnahmeklasse, Beweisverwahrung, Prüffragen, Begründungscodes und Beschwerdeweg festhalten, während die Architektur beim Betreiber bleibt.

Das zweite Rechenzentrum war ein Hostmaster-Fall

Die erste Quelle entstand nicht für die heutige Debatte. Im Policy Implementation Experience Report für AFRINIC-29 dokumentierte AFRINIC 2018 eine Schwierigkeit aus der Antragsprüfung.

Ein End-User-Mitglied beantragte ein zusätzliches IPv4-/24 für die Redundanz eines Rechenzentrums. Die aktuelle Nutzung summierte sich auf weniger als 90 Prozent. Nach AFRINICs damaliger Auslegung der Soft-Landing-Regel war das Mitglied nicht für weitere Ressourcen berechtigt und konnte das zweite Rechenzentrum daher nicht einrichten.

Der veröffentlichte Fall nennt weder Mitglied noch Land, Ticketdatum, Ausgangspräfix oder Netzaufbau. Stromversorgung, Leitungswege, Alternativen, Beschwerde und späteres Ergebnis bleiben unbekannt. Er beweist nicht, dass jeder zweite Standort einen neuen Block benötigt.

Er belegt eine schmalere Kollision. Auslastung beschreibt bereits gehaltene Adressen. Redundanz beschreibt Funktionen, die gleichzeitig verfügbar sein müssen. Muss die zweite Funktion warten, bis die erste fast voll ist, kommt der alternative Fehlerbereich erst nach dem Risiko.

Draft 2 würde eine Ausnahme schaffen, nicht rückwirkend eine Praxis

Der unabhängige NOG-Alliance-Tracker führt AFPUB-2026-IPv4-002-DRAFT02 unter der breiteren Bezeichnung Under discussion. Die Aufzeichnung von AFRINIC-37 dokumentiert rough consensus und den Übergang in den Last Call. Draft 1 wurde am 6. Mai 2026 eingereicht; Draft 2 trägt das Datum 16. Juni und wurde am 24. Juni vorgestellt. Am 23. August ist die Ausnahme weder ratifiziert noch implementiert.

Die Grundregel bliebe bestehen. Während der Exhaustion Phase muss ein LIR oder End User für eine weitere IPv4 allocation oder assignment mindestens 90 Prozent Nutzung aller früher erhaltenen IPv4-Ressourcen nachweisen. Eine neue Organisation ohne Vorbestand bleibt bei ihrem ersten Antrag ausgenommen.

Draft 2 würde einen weiteren Weg öffnen. AFRINIC könnte die Schwelle für nachgewiesene wesentliche technische Zwecke aussetzen, wenn der vorhandene Bestand sie praktisch nicht bedienen kann oder technische Zwänge für den Bestand entstehen. Redundanz, Hochverfügbarkeit, IPv6-Übergangsmechanismen und neue Standorte sind nicht abschließende Beispiele. Für diese Bestimmung würde der Antrag wie eine erste allocation oder assignment behandelt.

Der gesamte öffentliche Nachweisvertrag steht im letzten Satz: Die Begründung muss so ausreichend dokumentiert sein, dass AFRINIC ihre Einhaltung prüfen kann.

Das ist strenger als ein Etikett. High availability reicht nicht; der Antragsteller muss Tatsachen liefern, AFRINIC muss sie überprüfen. Unbenannt bleiben die Mindesttatsachen und die Relation, die ein späterer Prüfer erneut nachvollziehen soll.

Die Normalregel hat eine Zahl, die Ausnahme keinen Typ

Das aktuelle Consolidated Policy Manual bezeichnet Version 1.6 als gültig. Neben der 90-Prozent-Hürde enthält es allgemeine Beweisgrundsätze. Anträge dürfen Engineering-, Subnetting-, Topologie- und Routingpläne enthalten; Prognosen müssen realistisch und begründbar sein. Regeln und Praxis sollen unabhängig von Standort, Nationalität oder Größe fair angewandt werden. Geschäftsinformationen, die zur Prüfung dienen, aber nicht öffentlich registriert werden müssen, bleiben vertraulich.

Damit existiert ein professioneller Prüfrahmen. Was fehlt, ist ein Datentyp für die neue Ausnahme.

Zwei Antragsteller können dieselbe Bestandsnutzung haben und beide Redundanz schreiben. Einer bevorzugt aufgrund eines Geschäftsvertrags eine zweite Stadt. Der andere muss Strom, Transit und Übersetzungsfunktion trennen, damit eine Störung nicht beide Seiten trifft. Erst die Tatsachen unter dem Begriff zeigen, ob bestehende Adressen praktisch ungeeignet sind und ob der Zwang technisch oder betrieblich ist.

Gemeinsame Felder entscheiden den Fall nicht automatisch. Sie bewahren, worüber entschieden wurde. Genau das ist die notwendige, begrenzte Aufgabe.

Keine Einheitsakte heißt nicht keine gemeinsame Schnittstelle

In der Aufzeichnung von AFRINIC-37 fragte eine Teilnehmerin nach den technischen Unterlagen für mehrere Standorte vor Erreichen der 90 Prozent. Der Autor antwortete, eine einzige Liste passe nicht: IPv6-Übergang und Multi-Site-Aufbau verlangten unterschiedliche Beweise. Die Prüfung sei ein Input/Output-Dialog mit den Mitarbeitenden.

Die Ablehnung eines Universalpakets ist plausibel. Ein Rechenzentrumsdiagramm dimensioniert nicht zwingend einen Übersetzerpool. Eine Bestellung belegt keine Trennung der Fehlerbereiche. Eine Verkehrsprognose weist keine unabhängigen Routen nach.

Ein weiterer Teilnehmer unterstützte den Ansatz, warnte aber vor einer Formulierung, mit der nahezu jeder Hochverfügbarkeit behaupten könne. Gerechte und einheitliche Prüfung werde so schwierig. Der Autor lehnte eine vollständige Fallliste ab, weil sie legitime neue Entwürfe ausschließe und die Mitarbeitenden im Detail steuere. Der Head of Member Services setzte die entscheidende Grenze: Technische Zwänge können die Ausnahme tragen, betriebliche Zwänge nicht.

Die Debatte schließt zwei schlechte Modelle aus. Eine universelle Akte wäre starr. Ein unstrukturiertes Adjektiv wäre kaum prüfbar. Dazwischen fehlt eine gemeinsame Feldschnittstelle mit fallbezogenen Werten.

Die Co-Chairs stellten in der Sitzung rough consensus fest und schickten den Text in den Last Call. Laut Aufzeichnung sollte das Secretariat dort eine Definition von utilisation bereitstellen. Der neutrale Tracker behält seine breitere Bezeichnung, und keine hier verwendete öffentliche Quelle belegt Ratifizierung, Implementierung oder ein feldbezogenes Ausnahmeschema. Daraus folgt nicht, dass niemals anderswo eine Definition kursierte. Es folgt nur, dass Vorschlag und Sitzungsaufzeichnung die Entscheidung nicht rekonstruierbar machen.

Die Schutzwirkung wanderte in die Korrespondenz

Die Vorstellung und Diskussion des Vorschlags legt die Schutzwirkung in die Formulierung „ausreichend dokumentiert“. Der technische Bedarf müsse nachgewiesen, der vorhandene Bestand als praktisch ungeeignet gezeigt und die Relation von AFRINIC überprüft werden können.

Der implizite Test hat drei Glieder:

technische Funktion → mit vorhandenem Bestand praktisch nicht bedienbar → zusätzliche IPv4-Teilmenge

Jeder Pfeil braucht Tatsachen. Welche Funktion? Welche vorhandenen Blöcke wurden geprüft? Warum scheiden Wiederverwendung, Renumbering, andere Aggregation oder Platzierung aus? Welcher Standort oder Fehlerbereich erhält den neuen Teil? Wie lange besteht Parallelbetrieb? Welche Beobachtung würde die Begründung widerlegen?

Ohne feste Feldnamen bleibt die Schutzwirkung im Ticket. Der heutige Antragsteller versteht vielleicht das Ergebnis. Ein Nachfolger, Auditor oder Beschwerdeführer findet später nur unterschiedliche Anhänge und einen Endstatus.

Ermessen, Gründe und Beschwerde sind nicht dasselbe

Die Sitzungsaufzeichnung beschreibt die Prüfung als Dialog, nicht als Universalakte. Sie belegt weder eine endgültige Entscheidung noch ein bestimmtes Rechtsmittel. Fachliches Ermessen, dokumentierte Gründe und jeder anwendbare Korrektur- oder Prüfweg sind daher getrennte Gestaltungsentscheidungen.

Ermessen ist der Raum für Tatsachen, die kein Automatentest erfasst. Gründe dokumentieren die Nutzung dieses Raums. Eine Beschwerde prüft, ob Regel, Tatsachen und Gründe richtig verbunden wurden.

Das erste Element zu erhalten verlangt nicht, die anderen zu verbergen. Ohne Entscheidungsakte wiederholt eine Korrektur oder Prüfung nur das Gespräch auf einer anderen Ebene. Sichtbar sein muss, ob Architektur, Unmöglichkeit der Wiederverwendung, Antragsgröße, Beweisqualität, Klassifikation oder Regelversion ausschlaggebend waren.

Ein Multi-PoP-Beispiel schafft keinen Automatismus

Die Vorstellung des Vorschlags nutzt eine Multi-PoP-464XLAT-Installation als motivierendes Beispiel. Sie ist ein Entwurfsszenario, keine geprüfte Mitgliedsinstallation, kein automatischer Anspruch auf neuen Raum und keine universelle Topologie. Die Aussage ist enger: Eine technische Funktion kann gleichzeitig in mehreren Fehlerbereichen benötigt werden, bevor die Gesamtnutzung eine sequenzielle Schwelle erreicht.

Die 464XLAT-Architektur in RFC 6877 verbindet zustandsbehaftete Übersetzung im Kern mit zustandsloser Übersetzung am Rand, um begrenzte IPv4-Konnektivität über ein IPv6-only-Netz bereitzustellen. Der RFC ist Informational. Er schreibt weder vier PoPs noch zwei Geräte pro Standort oder eine bestimmte öffentliche Präfixgröße vor.

Die gemeinsame Regel muss kein Produkt oder Layout bestimmen. Sie kann erfassen, welche Funktion und welcher Fehlerbereich die neue Ressource nutzen, warum der Bestand nicht reicht und wie der Bedarf berechnet wurde. Platzierung und Routing bleiben Betreiberentscheidungen.

Eine Mindestspezifikation ist schmal und streng, nicht unbestimmt

Lu Hengs Minimum Initial Specification trennt die wenigen deterministischen Fakten, die für gemeinsame Koordination nötig sind, von späteren Betriebsentscheidungen der tatsächlich laufenden Teilnehmer.

AFRINIC verwaltet einen endlichen IPv4-Bestand. Bedarfsprüfung, Eindeutigkeit, Registerrichtigkeit und gleichmäßige Anwendung brauchen eine gemeinsame Regel. Rechenzentrumsanbieter, NAT64-Plattform, internes Routing und Baufolge werden dadurch nicht zu Registry-Invarianten.

Die praktische Lösung ist kleiner als ein Architekturhandbuch und stärker als ein Adjektiv: gemeinsame Entscheidungsfelder festlegen; passende fallbezogene Beweise zulassen; sensible Anlagen schützen; nur Schemaversion und datenschutzgerechte Aggregate veröffentlichen.

Eine vage gemeinsame Ebene ist nicht leichtgewichtig. Sie zwingt jeden Hostmaster und jeden Antragsteller, privat eine eigene Spezifikation zu erfinden. Die Mindestschnittstelle macht nur den gemeinsamen Teil ausdrücklich.

Achtzehn Felder für den Ausnahmebeleg

Die folgende Schnittstelle ist ein Vorschlag dieses Artikels, kein vorhandenes AFRINIC-Formular.

  1. Antrags- oder Ticket-ID. Verbindet einen Antrag mit Beweisen, Dialog und Ergebnis.
  2. Regelidentität. Speichert Policy-, Draft- oder Implementierungsversion und angewandten Absatz.
  3. Antragsteller und Antragstyp. Trennt LIR/End User, allocation/assignment sowie Erst- und Zusatzantrag.
  4. Normale Ausgangslage. Friert Portfolio und genaue 90-Prozent-Berechnung ein, die ohne Ausnahme gelten würde.
  5. Ausnahmeklasse. Benennt Redundanz, Hochverfügbarkeit, IPv6-Übergang, neuen Standort oder anderen technischen Zweck.
  6. Funktionseinheiten. Identifiziert Standorte, PoPs oder Funktionen geschützt und verwendet öffentlich nur pseudonyme oder aggregierte Bezeichnungen.
  7. Beantragte Teilmengen. Ordnet jedes Präfix oder Volumen einem Standort oder einer Funktion zu.
  8. Gleichzeitigkeitsfenster. Erklärt den parallelen Aufbau und die Dauer des Nebeneinanders alter und neuer Ressourcen.
  9. Ungeeignetheitsrelation. Beschreibt Topologie-, Routing-, Übersetzungs- oder Fehlerbereichsgrund gegen die Nutzung des Bestands.
  10. Adressplan. Bewahrt aktuelle und prognostizierte Nutzung, Einheit und Zeitraum für jede relevante Teilmenge.
  11. Analyse ungenutzter Bestände. Inventarisiert freien Raum und begründet die Ablehnung von Wiederverwendung, Renumbering oder anderer Platzierung.
  12. Beweisverwahrung. Listet Dateien, Hashes, Verantwortliche, Zugriffsgrenzen und Aufbewahrung, ohne vertrauliche Topologie zu veröffentlichen.
  13. Dialogverlauf. Hängt Prüffragen, Antworten und Zeitstempel an, statt frühere Begründungen zu überschreiben.
  14. Klassifikation und Gründe. Hält technical, operational oder mixed mit stabilen Codes und Erläuterung fest.
  15. Entscheidung und Bedingungen. Dokumentiert Genehmigung/Ablehnung, gewährte Größe, Auflagen, Ablauf und Folgeprüfung.
  16. Korrektur und Beschwerde. Verknüpft Mitteilung, Sachkorrektur, Frist und einschlägigen Beschwerdeweg.
  17. Ablösung. Verweist auf spätere Regelversionen und erhält zugleich die zum Entscheidungszeitpunkt angewandte Fassung.
  18. Öffentliche Aggregate. Ermöglicht Statistik zu Mengen, Klassen, Bearbeitungsbändern, Ergebnissen und Korrekturen ohne Mitglieds- oder Topologieoffenlegung.

Die Felder entscheiden nicht automatisch, ob ein Vier-PoP-Entwurf echt ist. Sie machen die Beurteilung wiederholbar. Ein zweiter Prüfer sieht dasselbe Portfolio, denselben Zwang und dieselbe offene Frage. Der Antragsteller korrigiert einen Sachfehler, ohne die Geschichte umzuschreiben. AFRINIC erkennt unerklärte Unterschiede zwischen Klassen, Größen und Prüfphasen.

Die Schnittstelle muss vor der operativen Ausnahme stehen

Die Richtung von Draft 2 ist vertretbar. Ein zweiter Fehlerbereich sollte nicht warten, bis der erste fast voll ist; sonst entsteht Redundanz erst nach dem Ausfall. Der Bericht von 2018 belegt, dass der Konflikt AFRINICs reale Prüfung erreicht hat.

Der Entwurf enthält zugleich eine notwendige Disziplin: Der technische Zweck muss belegt, nicht nur behauptet werden. Das Problem ist nicht fachliches Urteil. Es ist das Fehlen einer gemeinsamen Aussage darüber, was nach diesem Urteil fortbesteht.

„Ausreichend dokumentiert“ kann einen Dialog eröffnen. Als dauerhafte Akte einer knappen Ressourcenausnahme reicht es nicht. Vor einer Implementierung sollte AFRINIC Mindestfelder, Schutzregeln und Begründungscodes veröffentlichen. Dann kann die Registry den Pool schützen, ohne das Netz zu entwerfen, und der Betreiber das Netz entwerfen, ohne seinen Beweisstandard selbst zu setzen.

Quellen