Zusammenfassung

  • Version 2 entfernte die breite Neubewertung bewusst; der Antragsteller stellte später klar, dass unveränderte Bedarfe für bestehende Inhaber keine Folgen haben.
  • Mit zusätzlichem Bedarf greift der Pfad zur nächsten Nibble-Grenze. Fehlt angrenzender Raum, folgen eine neue Zuweisung und die Rückgabe der alten innerhalb einer sechsmonatigen Umnummerierungsfrist.
  • Ein vierzehnteiliger Übergangsbeleg und fünf Testvektoren können die Entscheidung nachvollziehbar machen, ohne Topologie, Kunden oder den internen Migrationsplan offenzulegen.

Eine Datenbankzeile ist kein Übergang

Der Registerbetrieb sieht am Ende möglicherweise ein größeres Präfix. Der Netzbetrieb erlebt davor zwei Präfixwelten, DNS-Änderungen, Filter, Überwachung und Anwendungen. Dazwischen liegt eine Entscheidung, die sich später nicht aus dem Endobjekt herauslesen lässt.

Ein Teilnehmer machte das Ausgangsbild 2025 greifbar: Sein Netz habe neun verschiedene /48-PI-Zuweisungen, die er möglichst ohne Umnummerierung zusammenführen wolle. Er nannte sowohl Datenbankobjekte als auch DNS.

Das ist eine zuordenbare Eigenaussage, keine unabhängige Bestandsprüfung und keine Aussage über die Häufigkeit solcher Fälle. Neun /48 belegen weder Missbrauch noch Verschwendung. Sie zeigen lediglich, dass ein historischer Bestand mehrere eigenständige Identitäten und Abhängigkeiten besitzen kann.

Bewusste Ruhe für unveränderte Inhaber

Die Ankündigung von Version 2 benennt die Straffung ausdrücklich. Die vorgeschlagene End-Site-Definition und die Neubewertung des Bedarfs bei einem zusätzlichen oder größeren Antrag wurden entfernt. Die Fassung sollte kürzer und lesbarer werden.

Als im März 2026 nach bestehenden Inhabern mehrerer PI-Zuweisungen ohne wachsenden Bedarf gefragt wurde, antwortete der Antragsteller: Solange sich der Bedarf nicht ändert, gibt es für diese Inhaber keine Auswirkungen.

Das ist kein Schlupfloch. Es ist eine Stabilitätsgrenze. Ein Regelwechsel soll kein funktionierendes Netz allein deshalb zur Migration zwingen, weil sein historischer Bestand nicht wie ein neues Schema aussieht. Das Register koordiniert Ressourcen; es besitzt nicht den Wartungsplan jedes Geräts.

Der Wachstumsantrag setzt die Kette in Gang

Anders ist der Fall, wenn ein Inhaber von einer oder mehreren PI-Zuweisungen zusätzlichen Raum benötigt. Abschnitt 7.1.2 führt zur Erweiterung an die nächste Nibble-Grenze. Ist eine zusammenhängende Erweiterung nicht möglich, kann eine neue Zuweisung erfolgen; die vorherige oder die vorherigen Zuweisungen sollen innerhalb von sechs Monaten zurückgegeben werden. Ein Teilnehmer zitierte diesen Pfad und hielt die Frist für diskussionsbedürftig.

Dieser Artikel entscheidet nicht zwischen sechs, zwölf oder 24 Monaten. Er behauptet weder einen Fristverstoß noch einen Ausfall. Fest steht nur die Abfolge:

Altbestand → geänderter Bedarf → Kontiguitätsprüfung → Erweiterung oder Ersatz → Überlappung → Rückgabe.

Für jede Kante braucht es eine Identität. Welcher Antrag war der Auslöser? Welche Textfassung galt? Welche alten Objekte gehörten dazu? Auf welchem Reservierungsstand beruhte die Prüfung? Wann startete die Überlappung? Welche Rückgaben schließen den Vorgang ab?

Der Status verlangt Zurückhaltung

Am 15. Juni 2026 meldeten die Arbeitsgruppenvorsitzenden acht Unterstützer und die beabsichtigte Weitergabe in die Review Phase. Kleinere redaktionelle Änderungen, ein Policy-Entwurf und eine Folgenanalyse sollten folgen.

Diese Nachricht ist keine Annahme oder Implementierung. Die hier geprüften Quellen belegen nicht, dass die Review Phase anschließend eröffnet, Konsens erzielt oder Produktionssysteme geändert wurden. Gegenstand bleibt ein Entwurf.

Gerade dieses Zwischenstadium bietet die Gelegenheit, den Übergangsbeleg in Text und Folgenanalyse aufzunehmen, statt ihn später aus Fallpraxis abzuleiten.

Umnummerierung braucht gleichzeitig Alt und Neu

RFC 4192 beschreibt IPv6-Umnummerierung ohne Stichtagsumschaltung. Das neue Präfix wird vorbereitet und hinzugefügt; Routing, DNS, DHCP und fest konfigurierte Verweise werden schrittweise geändert; Alt und Neu laufen parallel; erst nach Tests wird das alte Präfix entfernt.

RFC 5887 zeigt die verbleibenden Reibungen. Statische Adressen verteilen sich über viele Systeme. Manche Abhängigkeiten werden erst durch Störungen sichtbar. Während der Überlappung müssen Regeln und Monitoring beide Präfixmengen verstehen, während manche Werkzeuge gerade diesen Doppelzustand schlecht unterstützen.

Die RFCs bestimmen nicht RIPEs Policy. Sie belegen nur, dass eine Rückgabefrist mehrere betriebliche Zustände umfasst. Der Registerbeleg muss sie referenzieren können, ohne die lokale Durchführung zu zentralisieren.

Ein Modell für den Auslösepunkt

P0 sei der geordnete alte PI-Bestand zu einem bestimmten Zeitpunkt, N0 der bis dahin dokumentierte Bedarf und q der neue Antrag. H bezeichnet Text und Version, C(q, P0) das Ergebnis der Reservierungs- und Kontiguitätsprüfung, T den gewählten Pfad, P1 den neuen Ressourcenstand und D Überlappung, Frist und Abschluss.

Der prüfbare Vorgang lautet:

E = G(P0, N0, q, H, C, T, P1, D).

Das ist Theo Marchs Prüfmodell, kein veröffentlichtes RIPE-NCC-Schema. Vor q bleibt P0 unberührt. Danach müssen Antrag, Belege, Entscheidung und beide Ressourcenstände zusammenbleiben.

Vierzehn Felder für den Wachstumsübergang

  1. Belegidentität. Stabile ID und Schemaversion.
  2. Anwendbare Regel. Vorschlag oder Policy, Fassung, authentischer Digest, Status und Wirksamkeitsdatum.
  3. Altbestandsstichtag. Exakter Zeitpunkt und Zeitzone der Ausgangsmenge.
  4. Inhaber und Antrag. Öffentlich verträgliche Referenz, Vorgangs-ID und authentifizierte Eingangszeit, ohne private Kontaktdaten.
  5. Auslöserklasse. Unveränderte Anfrage, zusätzlicher Raum, größere Zuweisung oder Korrektur; dazu der Grund, warum 7.1.2 greift oder nicht.
  6. Vorherige PI-Menge. Geordnete Objektidentitäten, Präfixlängen, Status und Datensatz-Digests.
  7. Bewerteter Bedarf. Genehmigt, abgelehnt oder offen, Zielgröße und begrenzter öffentlicher Grundcode; Rohdaten zur Topologie bleiben geschützt.
  8. Nibble-Ziel. Beantragte und bewertete Grenze samt Begründung einer Abweichung.
  9. Kontiguitätsnachweis. Identität des Reservierungsstands, geprüfter Nachbarbereich, Zeit und deterministisches Ergebnis, ohne fremde Bestände offenzulegen.
  10. Gewählter Pfad. Erweitern, ersetzen, unverändert lassen, ablehnen oder Nachweise anfordern.
  11. Ergebnisressource. Identität, Präfix, Objektversion und Aktivierungszeit.
  12. Überlappungsuhr. Beginn, Rückgabefrist, Zeitzone sowie Identität einer erlaubten Pause oder Verlängerung.
  13. Rückgabemenge und Abschluss. Einzelstatus, Abschlussnachweis und offene Ausnahme.
  14. Korrekturkette. Entscheidungsstelle, Prüf- oder Korrekturweg, ersetzter Beleg und Endstatus.

Die Felder dokumentieren eine Entscheidung. Sie machen aus einer signierten Bedarfsbehauptung noch keinen bewiesenen Bedarf.

Fünf Testvektoren

  1. Mehrere alte PI ohne Wachstum. Kein Auslöser, keine Rückgabeuhr.
  2. Zusammenhängende Erweiterung. Altmenge, Reservierungsnachweis und erweitertes Objekt werden verknüpft.
  3. Nicht zusammenhängender Ersatz. Neue Zuweisung, eindeutige Rückgabemenge und Überlappungsfrist.
  4. Rücknahme vor Aktivierung. Abschluss ohne Start der Rückgabefrist.
  5. Korrektur von Menge oder Startzeit. Append-only-Ersetzung statt stiller Überschreibung.

Die Werkzeuge dürfen unterschiedlich sein. Gleich sein muss die Bedeutung der Ergebnisse.

Der gemeinsame Kern endet früh

HENG.LU Note 64 verlangt nur so viel gemeinsame Spezifikation, wie Identität, Interoperabilität und gemeinsame Sicherheit benötigen. Hier sind das Alt- und Neuidentität, Regelversion, Auslöser, Kontiguität, Entscheidung, Uhr, Abschluss und Korrektur.

Topologie, Verkehr, Kunden, detaillierte Nutzung, Gerätebestand, Geschäftsgrund und Reihenfolge der Arbeiten bleiben lokal oder geschützt. Die Gemeinschaft setzt die Regel. RIPE NCC bewertet und belegt seine Entscheidung. Der Inhaber liefert Fakten und betreibt das Netz. Dritte prüfen, ohne Zuweisungs- oder Routingmacht zu erhalten.

Auch Nichtstun bleibt möglich. Ohne geänderten Bedarf gibt es keinen Übergang, der nur für ein Formular erzwungen werden müsste. Erst ein tatsächlich bewerteter Zustandswechsel erzeugt den gemeinsamen Beleg.

Quellen

Evidenzgrenzen

Verifiziert: Version 2 strich die breite Neubewertung; unveränderter Bedarf bleibt folgenlos; der diskutierte Text enthält den Wachstumszweig und sechs Monate; die Vorsitzenden wollten weitergehen; IPv6-Umnummerierung hat Überlappungszustände.

Schlussfolgerung: Das Endobjekt allein rekonstruiert Auslöser, Kontiguität, Rückgabemenge und Uhr nicht.

Empfehlung: vierzehnteiliger Beleg und fünf Testvektoren vor der Implementierung.

Unbekannt: Review-Text, Folgenanalyse, endgültige Frist, Uhrstart, Ausnahmen, internes Fallschema, Zahl betroffener Inhaber und Produktionseinführung.