Zusammenfassung

  • ARIN-2026-2 ist ein Draft Policy in der Diskussion, keine angenommene oder umgesetzte Regel.
  • Der Vorschlag würde öffentliche Formeln und Nutzungsgrenzen durch Pläne mit Zuteilungseinheiten, Hierarchie, Aggregation und Wachstum ersetzen.
  • BTW empfiehlt einen vergleichbaren Plan-zu-Entscheidung-Datensatz; die operative Umsetzung durch das Personal und die Nachweispflichten der Antragsteller sind unbekannt.

Der Vorschlagstext ist vom 4. Mai 2026 und wurde am 24. Juni 2026 zum Draft Policy. Beim Berichtsstand vom 5. September 2026 war er weiterhin in Diskussion. Der genannte Entwurfsindex zeigte weder eine Prüfung durch Personal oder Rechtsabteilung noch einen Eintrag zu einer Community-Präsentation. Die Quellen belegen weder Empfehlung, Konsens, last call, Board-Annahme noch Umsetzung; der Text ist nicht Bestandteil des aktuellen NRPM.

Der Entwurf würde Entscheidungen über anfängliche LIR-Zuteilungen aus den derzeitigen formel- und nutzungsbasierten Mechanismen herauslösen. Jeder Antrag würde typische Größen für Zuteilungen an entfernte Standorte oder Kunden, die Adresshierarchie und logische Struktur sowie die prognostizierte Nutzung von Adressierungseinheiten nach ungefähr einem, zwei und fünf Jahren dokumentieren. ARIN würde die erwartete Zahl und Art nachgelagerter Zuteilungen, den Aggregationsbedarf und die Fähigkeit zu zusammenhängendem Wachstum berücksichtigen.

Die anfängliche Zuteilung würde den dokumentierten Plan und eine effiziente Erweiterung unterstützen; eine neue deterministische Dimensionierungsformel veröffentlicht der Vorschlag jedoch nicht.

Bei späteren LIR-Zuteilungen würden eine plan­konforme Umsetzung, aktualisierte Prognosen und die Möglichkeit einer Erweiterung des bestehenden Blocks berücksichtigt. PI-Anträge würden ebenfalls anhand von Standortanforderungen, interner Hierarchie und Segmentierung, Aggregation, Wachstum und der Vermeidung einer Umnummerierung bewertet. Rück- oder Neuzuweisungen an externe Einrichtungen von /64 oder größer würden nach dem vorgeschlagenen Text in den ARIN-Verzeichnisdiensten registriert.

Die derzeit umgesetzte Grundlage ist anders. NRPM 6.5.2.1 verwendet Nibble-Grenzen, einen Standardboden von /32 mit /36- oder /40-Optionen, IPv4-Besitzbedingungen für /40, eine Obergrenze von /16 sowie eine Formel, die an versorgte Standorte, den größten versorgten Standort und einen 75%-Standard gebunden ist. NRPM 6.5.2.2 umfasst frühere IPv4-Berechtigung, IPv6-Multihoming oder technische Begründung, prognostizierte Zuteilungen nach einem, zwei und fünf Jahren sowie mindestens 50 Zuteilungen innerhalb von fünf Jahren.

NRPM 6.5.3 verwendet für spätere LIR-Zuteilungen 75% Gesamtnutzung, mehr als 90% Nutzung an einem versorgten Standort oder mehr als 90% Zuteilung an versorgte Standorte. NRPM 6.5.8 legt für Endnutzer eine Standortleiter fest: /48 für einen Standort, /44 für 2–12, /40 für 13–192, /36 für 193–3.072 und /32 für mehr als 3.072 Standorte.

Das Governance-Problem ist weder eine Erschöpfung noch wirtschaftliche Knappheit von IPv6. Es geht um proportionale Zuteilung, Aggregation, Fragmentierung der Routing-Tabelle, Kontinuität und wiederholbare Verwaltung. Ein Plan kann die tatsächliche IPv6-Architektur eines Betreibers besser abbilden als eine starre Formel. Wenn jedoch mehrere öffentliche Schwellenwerte entfallen, hängt die Entscheidungsqualität stärker davon ab, wie einheitlich Analysten Pläne auslegen und die Umsetzung mit früheren Prognosen vergleichen.

Das ist eine Schlussfolgerung aus dem Entwurf, keine Behauptung willkürlichen Mitarbeiterverhaltens und keine Aussage, dass Ermessen zwangsläufig Missbrauch sei.

BTW empfiehlt für jede Bewertungsklasse ein kompaktes Entscheidungsregister. Es sollte Annahmen zu Zuteilungseinheiten, Hierarchie, Ein-, Zwei- und Fünfjahresprognosen, Abweichungen vom früheren Plan, die Begründung für zusammenhängendes Wachstum und den Grund für die Proportionalität des ausgegebenen Präfixes festhalten. Dieses Register ist eine Empfehlung dieser Analyse, kein bestehendes oder zugesagtes ARIN-System.

Veröffentlichungshinweis: „Veröffentlicht“ bezeichnet das geplante Redaktionsdatum, den 6. September 2026, in Asia/Shanghai. Die tatsächliche Server-Veröffentlichungszeit bleibt bis publish-now ungesetzt.