Zusammenfassung

  • Die Vorsitzenden der RIPE Address Policy Working Group teilten am 24. September 2026 mit, dass der Vorschlag 2024-01 zur Überarbeitung der IPv6-PI-Regeln zurückgezogen wurde. Er solle archiviert werden; das Thema könne erneut eingebracht werden. Eine konkrete Ursache des Rückzugs oder eine Annahme einzelner Bestimmungen nennt die Nachricht nicht.
  • Bei direkter Prüfung am 27. September zeigte die Seite von Fassung 3.0 noch „Review Phase: Open for discussion“. Die jüngere Mitteilung belegt den Verfahrensstand, die ältere Seitenanzeige eine Lücke im öffentlichen Nachvollzug. Weder ein Fortgang des Verfahrens noch Absicht hinter der Lücke ist dadurch bewiesen.
  • Für einen heutigen Antrag zählen die veröffentlichte IPv6-Richtlinie RIPE-738 und die PI-Antragshinweise: /48 ist die Mindestgröße, ein größerer Block verlangt Begründung, und PI-Präfixe dürfen nicht aufgrund einer bloß vorgeschlagenen Ausnahme an andere Organisationen weitergegeben werden.
  • Der Rückzug hebt keine bestehende PI-Zuweisung auf und macht keine nie beschlossene Reform rückgängig. Nach dem RIPE Policy Development Process kann das Thema wieder vorgebracht werden; daraus folgen weder Wortlaut noch Ergebnis einer künftigen Regel.

Der Antrag liegt auf dem Tisch, nicht in der Zukunft

Ein Netzbetreiber hat mehrere Standorte und möchte seine Adressen so ordnen, dass späteres Wachstum nicht jedes Mal eine neue, getrennte Route erzwingt. In Fassung 3.0 von 2024-01 findet er Vorschläge für PI-Größen an Vier-Bit-Grenzen, eine empfohlene Freihaltung zusammenhängenden Raums und eine Erweiterung bestehender Blöcke, soweit angrenzende Adressen verfügbar sind. Wo das nicht gelingt, beschreibt der Entwurf einen neuen Block mit Umnummerierung und Rückgabe des alten. Für eine Investitionsentscheidung sind das greifbare Bedingungen. Gerade deshalb darf der Betreiber sie nicht als bereits erteiltes Angebot des Registers behandeln.

Die Mitteilung aus der Arbeitsgruppe beendet den öffentlichen Weg dieses Textes. Alex Le Heux schrieb im Namen der Vorsitzenden, der Vorschlag sei zurückgezogen. Er fasste dessen Ziel zusammen, den Betriebsaufwand für PI zu verringern und ältere Formulierungen zu klären, kündigte das Archiv an und verwies auf die Möglichkeit einer erneuten Einbringung. Mehr sagt die Nachricht über den Entscheidungsgrund nicht. Sie meldet keine Abstimmung, erklärt keine einzelne technische Kritik für ausschlaggebend und beschreibt kein Veto des RIPE NCC Executive Board. Wer ihr eine solche Ursache hinzufügt, macht aus einer belegten Disposition eine unbelegte Erzählung.

Der Webseitenbefund ist ebenso begrenzt. Am 27. September zeigte die Vorschlagsseite weiterhin Fassung 3.0 vom 25. August als in der Review Phase offen. Im geprüften Archivverzeichnis war 2024-01 noch nicht sichtbar. Das passt zur Zukunftsform der Ankündigung, dass der Vorschlag archiviert werde. Es sagt nicht, wer eine Aktualisierung veranlasst hat, wann sie erfolgt oder warum sie noch aussteht. Ein veralteter Status auf der Webseite sollte korrigiert werden. Er widerlegt aber die spätere, eindeutige Nachricht nicht; ebenso wenig ist er ein Beleg für bewusste Irreführung.

Der Antragsteller benötigt deshalb eine Reihenfolge der Dokumente. Eine datierte Verfahrensmitteilung beantwortet, ob der Entwurf noch im PDP ist. Das veröffentlichte Richtliniendokument beantwortet, welche Bedingungen derzeit gelten. Die Antragshilfe zeigt, welche Informationen RIPE NCC für eine konkrete Prüfung verlangt. Entwurf und Folgenabschätzung bleiben als dokumentierte Debatte lesbar. Ein bereits registrierter Block, ein RPKI-Objekt oder eine BGP-Ankündigung ändert sich hingegen durch keinen Statusvermerk auf der Vorschlagsseite. Jede solche Änderung braucht einen eigenen operativen Vorgang.

Die stärkste Verteidigung des breiten Entwurfs

2024-01 war mehr als eine neue Zahl hinter dem Schrägstrich. Abschnitt 2.6 sollte den Gebrauch einer Zuweisung und die Grenze der Weitergabe an andere Rechtsträger klären. Abschnitt 5.4 betraf Zuweisungen aus größeren IPv6-Allokationen. Abschnitt 7.1 mit Unterabschnitten verband PI-Größe, Vier-Bit-Stufen, Wachstum, Ersatz und Umnummerierung. Diese Fragen hängen tatsächlich zusammen. Ein größerer Block wirft Fragen nach Nutzung und Registrierung auf. Eine Wachstumsreserve kann durch teilweise Übertragung entwertet werden. Eine lockerere Nutzungsregel beeinflusst, welcher Bedarf legitim dargestellt wird.

Alles in einem Text zu behandeln, konnte diese Abhängigkeiten sichtbar machen, statt sie hinter mehreren kleinen Änderungen zu verstecken.

Die Folgenabschätzung von RIPE NCC nutzte genau diese Breite zur Prüfung. Für den Fall der Annahme erwartete sie erheblichen Aufwand für Software, Abläufe, Dokumentation und Schulungen. Sie benannte Bedingungen, deren tatsächliche Einhaltung schwer effizient zu prüfen wäre, mit möglichen Folgen für die Genauigkeit der Registrierungsdaten. Wenn neu zugewiesener Raum sofort teilweise übertragen werden könnte, verlöre eine zusammenhängende Reserve ihren Zweck. Die Analyse fragte auch nach alten Zuweisungen, nach nicht erfüllten 24-Monats-Plänen und nach Folgen einer Umnummerierung, die nach sechs Monaten nicht abgeschlossen ist. Das Executive Board riet dringend zu einer Überarbeitung.

Es ist richtig, diese Punkte ernst zu nehmen. Sie zeigen, dass ein Entwurf über die Größe eines PI-Blocks in Wirklichkeit auch Kontrolle, Transferregeln und Ausnahmen verändert. Es wäre jedoch unzulässig, aus der Abschätzung den nicht genannten Grund des Rückzugs abzuleiten. Das Board sprach eine Empfehlung aus, nicht das in der Mitteilung behauptete Verfahrensvotum. Der RIPE-PDP trennt die öffentliche Diskussion, die Bewertung des Konsenses und die unterstützende Rolle des Sekretariats. Eine journalistische Analyse sollte dieselben Grenzen einhalten, die sie von der Institution verlangt.

Welche Regel den heutigen Fall trägt

RIPE-738 setzt die Mindestgröße einer IPv6-PI-Zuweisung auf /48. Das ist keine starre Höchstgrenze: Ein größerer Bedarf kann nach den geltenden Maßstäben begründet werden, etwa mit Nutzung oder besonderen Routing-Anforderungen. Es ist aber kein Anspruch auf den nächsten Vier-Bit-Schritt und keine heutige Zusage einer zusammenhängenden Reserve. PI-Raum darf nicht an andere Organisationen weiter zugewiesen werden; ein LIR erhält PI für die eigene Infrastruktur unter den entsprechenden Voraussetzungen, nicht als Weg zur Versorgung von Kundenstandorten.

Die PI-Antragshinweise von RIPE NCC machen daraus eine praktische Prüfung. Wer mehr als /48 benötigt, soll den Bedarf oder die abweichenden Routing-Erfordernisse dokumentieren. Einen Teil des PI-Raums als Präfix an einen Dritten weiterzugeben, ist auch dann nicht dadurch erlaubt, wenn es sich um ein /64 oder /96 handelt. Einzelne Adressen auf einem vom Inhaber betriebenen Netz zu verwenden, ist eine andere Situation. Ein Antrag muss erkennen lassen, wer welchen Standort und welche Infrastruktur betreibt und welches Objekt tatsächlich übertragen werden soll. Andernfalls kann eine vielversprechende Formulierung des zurückgezogenen Entwurfs eine Architekturentscheidung fälschlich legitimieren.

Auch Bestandsinhaber brauchen eine klare Aussage. Der Rückzug entzieht ihnen keine bestehenden PI-Zuweisungen, löst keine Rückgabe aus, schreibt keine Migration vor und löscht keine Sicherheits- oder Routingdaten. 2024-01 war nicht implementiert worden, daher kann sein Rückzug keine Implementierung zurücknehmen. Falls eine spätere, andere Richtlinie bestehende Ressourcen berührt, müssen Geltung, Übergang und konkrete Registerhandlung dann gesondert sichtbar sein. Der Schutz von Kontinuität beruht hier auf Präzision, nicht auf der Behauptung, dass jede Reform unzulässig wäre.

Ein Thema kann wiederkommen, ohne seine alte Autorität mitzunehmen

Die Vorsitzenden ließen die Tür für einen neuen Anlauf offen. Das heißt nicht, dass Fassung 3.0 neu gestartet oder ein künftiger Konsens vorweggenommen wurde. Ein neuer Vorschlag könnte etwa den Gebrauch innerhalb eines Standorts enger von der PI-Größe trennen, die Behandlung teilweiser Transfers konkretisieren oder den Übergang alter Zuweisungen anders regeln. Er müsste wieder einen überprüfbaren Text vorlegen und Einwände bearbeiten. Die geleistete Arbeit am alten Vorschlag bleibt Wissen; sie ist keine Anzahlung auf die Verbindlichkeit des nächsten.

Die öffentliche Seite sollte den datierten Rückzug schließlich mit Versionen, Folgenabschätzung, Archiv und geltender RIPE-738 verknüpfen. Das ist eine beschränkte Pflicht zur guten Dokumentation, keine Aufforderung an das Register, über Geschäftsmodelle der Nutzer zu herrschen. Ein Betreiber muss auch vor dieser Korrektur einen Antrag stellen können. Er sollte ihn auf die Regel stützen, die tatsächlich veröffentlicht ist, und nicht auf eine Überschrift, deren Aktualisierung aussteht.

Quellen