Zusammenfassung

  • Draft 2 bewahrt die 90-%-Grundregel und schlägt eine Ausnahme für nachgewiesene zentrale technische Zwecke vor.
  • Ein Fallpaket sollte Topologie, Präfixgröße, Auslastungsrechnung, Alternativen und Betrugskontrollen dokumentieren.
  • Der grobe Konsens bei AFRINIC 37 und der Status Last call sind weder Board-Ratifizierung noch Umsetzung.

Veröffentlichungshinweis: „Veröffentlicht“ bezeichnet das geplante Redaktionsdatum, den 7. September 2026. Die tatsächliche Server-Veröffentlichungszeit ist nicht festgelegt.

CPM Abschnitt 5.4.6.1 verlangt von einem LIR oder End User, der während der Erschöpfungsphase eine weitere IPv4-Zuweisung oder -Vergabe beantragt, eine Nutzung von mindestens 90 % aller früheren Ressourcen. Der erste Antrag eines neuen LIR oder End Users ohne frühere Ressourcen ist ausgenommen.

AFPUB-2026-IPv4-002-DRAFT02 vom 16. Juni 2026, nach Draft 1 vom 6. Mai, würde diese Grundlage beibehalten. AFRINIC könnte eine Ausnahme vom Grenzwert gewähren, wenn ein nachgewiesener zentraler technischer Zweck praktisch nicht aus dem vorhandenen Ressourcenpool des Betreibers bedient werden kann oder technische Einschränkungen für diesen Pool erzeugt. Die nicht abschließenden Beispiele sind Redundanz und Hochverfügbarkeit, IPv6-Übergangsmechanismen sowie die Erweiterung auf neue Standorte.

Die Begründung soll ausreichend dokumentiert sein, damit die Einhaltung geprüft werden kann; ein öffentliches Evidenzschema, ein Mindestdokumentsatz, ein Entscheidungsregister oder eine Veröffentlichungspflicht werden jedoch nicht genannt.

Das ist für Gleichbehandlung, Betrugsresistenz und prüfbare Hostmaster-Entscheidungen entscheidend. Die Beispiele einer Rechenzentrumserweiterung und eines ISP mit mehreren BGP-PoPs sowie 464XLAT und NAT64 stammen vom Verfasser des Vorschlags. Sie sind kein verifizierter Nachweis für die Eignung eines bestimmten Mitglieds. Auch die Angabe von etwa drei Millionen zurückgewonnenen IPv4-Adressen ist ein zugeschriebenes politisches Argument, keine unabhängig gemessene Bestandszahl dieses Dossiers.

AFRINIC-Mitarbeiter sehen die 90 % weiterhin als Baseline und wollen die Ausnahme auf technische, nicht betriebliche Einschränkungen begrenzen. Hostmaster sollen eine dokumentierte Richtlinie erhalten; Verfahren müssen betrügerische Anträge erkennen und Missbrauch verhindern. Verfahren und FAQs von Member Services müssten aktualisiert werden. Für WHOIS, RDAP, MyAFRINIC, NetSuite, NMRP oder RPKI wurden keine Systemänderungen identifiziert. Das Ziel einer Umsetzung innerhalb von 30 Tagen nach Ratifikation ist eine Einschätzung und ein Plan, kein Nachweis für Ratifikation oder Umsetzung.

Bei AFRINIC 37 am 24. Juni 2026 wurden die Schwierigkeit einer 90-%-Nutzung über mehrere Standorte und der Unterschied zwischen effizienter Nutzung und betrieblicher Topologie diskutiert. Der formale Vorsitzbeschluss stellte groben Konsens fest und kündigte eine Nutzungsdefinition während Last Call an. Im offenen Mikrofon sagte ein Teilnehmer zunächst, der Vorschlag sei nicht angenommen; der PDWG-Co-Chair stellte klar, dass grober Konsens erreicht worden war. Zum Berichtsstichtag lautet der Status auf der Vorschlagsseite Last call. Diese Prüfphase ist von einer späteren Empfehlung an das Board, der Ratifikation und der Umsetzung zu unterscheiden.

BTW-Analyse: empfohlenes Evidenzpaket. Es sollte Topologie, Standorte und Service-Rollen, die Begründung der Präfixgröße, aktuelle und erwartete Auslastung, geprüfte Alternativen, den zeitlich begrenzten Bedarf, Betrugschecks, Prüferidentität, Entscheidungsdatum, Bedingungen und spätere Überprüfung enthalten. Ein Entscheidungsbeleg sollte Regel, maßgebliche Evidenz, Gründe und Bedingungen festhalten. Dies ist eine BTW-Empfehlung, kein bestehendes oder verabschiedetes AFRINIC-Produkt beziehungsweise Erfordernis.