Zusammenfassung

  • Ein fähiger Client setzt Code 108 in seine DHCPv4 Parameter Request List. Nur ein ausdrücklich als IPv6-mostly konfigurierter Pool soll die Option zurückgeben; der Client fordert die angebotene IPv4-Adresse anschließend nicht an.
  • Die Untergrenze beträgt 300 Sekunden, der RFC-Standardwert 1800 Sekunden. Nach Ablauf oder einem neuen Network-Attachment-Ereignis kann DHCPv4 wieder beginnen. Fünf Minuten sind ein Rückholmechanismus, keine dauerhafte Abschaltung.

Ein Angebot, das abgelehnt werden soll

Ein DHCPOFFER lädt gewöhnlich dazu ein, eine Adresse anzufordern. Option 108 erzeugt innerhalb desselben Protokolls das Gegenteil. Der Client nimmt den Code „IPv6-Only Preferred“ in DHCPDISCOVER oder DHCPREQUEST auf. Den vier Byte langen Zeitwert sendet er nicht selbst. Er erklärt lediglich, dass eine IPv4-Adresse auf dieser Schnittstelle optional ist, sofern das Netz die nötige IPv6-only-Funktion bereitstellt.

Der Server darf Schweigen nicht als Zustimmung deuten. Die Option muss angefordert worden sein, und der ausgewählte Pool muss explizit als IPv6-mostly gelten. Dann übermittelt der Server V6ONLY_WAIT. Als angebotene Adresse empfiehlt RFC 8925 0.0.0.0. Kann die Infrastruktur damit nicht umgehen, darf eine reale freie Adresse erscheinen; sie sollte aber nicht reserviert werden, weil der Client sie voraussichtlich nie anfordert.

So können alte und neue Endpunkte im selben Segment bleiben. Geräte ohne Option 108 erhalten IPv4 wie bisher. Fähige Geräte verzichten. IPv4-only, Dual Stack und IPv6-only-fähige Systeme teilen SSID oder VLAN, ohne dass eine Zugangsinstanz jedes Gerät und jede Anwendung vorher klassifizieren muss.

Die Regel ist bewusst dünn. Sie bewertet weder Geschäfts- noch Gerätemodelle, setzt keine politische Frist und erklärt Nichtteilnehmer nicht für ungültig. Eine Schnittstelle und ein klar abgegrenzter Serverpool treffen eine lokale Wahl.

Die Uhr als Sicherung gegen eine falsche Annahme

V6ONLY_WAIT ist ein 32-Bit-Wert in Sekunden. Liegt der Serverwert unter der Grenze, setzt der Client 300 Sekunden an. Der Standardwert der RFC beträgt 1800 Sekunden. Die oft zitierte Fünf-Minuten-Spanne ist daher die Mindest-, nicht die Standarddauer.

Währenddessen soll der Client die DHCPv4-Konfiguration stoppen und darf den IPv4-Stack auf der betroffenen Schnittstelle abschalten. Die Pause endet mit der Zeit oder einem neuen Anschlussereignis. Damit wird eine Entscheidung aus dem Büronetz nicht ungeprüft auf ein anderes WLAN übertragen, das vielleicht weder IPv6 noch NAT64 bietet.

Der 6MOPS-Entwurf in Version 07 vom März 2026 empfiehlt für den Einstieg 300 Sekunden, um schnell zurückrollen zu können, und längere Zeiten erst nach nachgewiesener Zuverlässigkeit. Es handelt sich um einen Internet-Draft, nicht um eine RFC. Die Empfehlung bleibt als Versuch prüfbar: Option am Server abstellen, Timer oder Wiederanschluss abwarten und beobachten, ob der Client wieder IPv4 bezieht.

Kurze Zeiträume erzeugen allerdings Last. Wenn eine große Flotte alle fünf Minuten DHCPDISCOVER sendet, kann das die Infrastruktur belasten. Ein kurzer Timer begrenzt die Dauer eines Fehlers; ein langer reduziert Steuerverkehr. Clientzahl, Serverkapazität, Störungsrate und tatsächliche Wiederherstellungszeit müssen die Einstellung bestimmen.

Die Uhr drückt keine Unentschlossenheit aus. Sie reserviert Zeit, um eine irrtümliche Fähigkeitsbehauptung zu korrigieren.

Sechs Zustände statt eines Schalters

„Option 108 aktiviert“ ist kein belastbarer Betriebsnachweis. Mindestens sechs Zustände gehören getrennt ins Protokoll.

Erstens die Schnittstellenrichtlinie: Wer erklärte das Gerät für fähig, auf Basis welcher OS-Version, CLAT-Verfügbarkeit und Anwendungstests? Die RFC nennt dies ausdrücklich eine Policy-Entscheidung.

Zweitens die Anforderung: War Code 108 im tatsächlichen Paket vorhanden? Ohne ihn liegt keine Erklärung des Clients vor.

Drittens der Serverumfang: Stammt die Antwort aus genau dem IPv6-mostly-Pool? Eine globale Funktionsanzeige beweist die Konfiguration des gewählten Pools nicht.

Viertens das Angebot: War die Option vier Byte lang, welcher Timer galt, und erschien 0.0.0.0 oder eine nicht reservierte reale Adresse? Eine kontrollierte Paketaufzeichnung liefert den Beleg.

Fünftens der Clientzustand: Verzichtete das System wirklich auf die Adresse, stoppte DHCPv4 und reagierte korrekt auf INIT-REBOOT, Erneuerung und Wiederanschluss? Das Senden durch den Server beweist nicht das Verhalten des Endpunkts.

Sechstens das Nutzungsergebnis: Kam PREF64 rechtzeitig an? War NAT64 erreichbar? Stand CLAT für alte IPv4-Sockets bereit? Konnte der Nutzer seine Aufgabe abschließen? Eine leere Lease-Zeile beantwortet das nicht.

Erst getrennt ergibt sich eine überprüfbare Aussage: Dieser Client lehnte in diesem Pool für diese Dauer eine Adresse ab, und bestimmte Anwendungen liefen oder scheiterten. „IPv4 aus“ verwischt die Ursache.

Übersetzung bleibt eine eigene Abhängigkeit

RFC 8925 nimmt NAT64 für Ziele an, die nur IPv4 sprechen. Option 108 handelt aber keine Übersetzungstechnik aus, verteilt kein NAT64-Präfix und prüft keinen Pfad zum Übersetzer.

RFC 8781, ebenfalls mit Linkova als Koautorin, definiert dafür eine PREF64-Option in Router Advertisements. RFC 9872 empfiehlt dieses RA-Verfahren für neue Installationen und lässt DNS-basierte Erkennung als Rückfall, wenn die RA-Option fehlt oder nicht unterstützt wird. Solange PREF64 nicht vorliegt, können IPv4-only-Anwendungen und Ziele beeinträchtigt sein.

464XLAT überbrückt eine andere Lücke. Ein clientseitiger CLAT bietet alter Software eine IPv4-Oberfläche und transportiert die Pakete über IPv6. RFC 6877 begrenzt die Zusage ausdrücklich: Es ist eingeschränkte IPv4-Konnektivität, kein vollständiger Eins-zu-eins-Ersatz. Eingehendes IPv4 und alle Peer-to-Peer-Muster kehren damit nicht zurück.

Deshalb kann Option 108 korrekt sein, während der Dienst scheitert. Der Client verzichtet, aber die RA enthält kein PREF64. Das Präfix stimmt, aber NAT64 ist nicht geroutet. Die Übersetzung läuft, doch ein VPN blockiert IPv6-Erweiterungsheader. Der Browser nutzt natives IPv6, während eine Anwendung mit IPv4-Literal mangels CLAT ausfällt.

Eine Störungsanalyse muss die konkrete Schicht benennen. Wer alles „IPv6-Problem“ nennt, verliert sowohl den DHCP-Nachweis als auch den Reparaturpunkt.

Der Erfolg, den Dual Stack vortäuschen kann

Happy Eyeballs weicht einem gestörten IPv6-Pfad über IPv4 aus. Das schützt Nutzer, kann aber einen Defekt jahrelang verbergen. Sobald die IPv4-Adresse fehlt, wird das bereits vorhandene Problem sichtbar.

Der 6MOPS-Entwurf ordnet die Einführung: zuerst PREF64 signalisieren, dann Option 108 serverseitig aktivieren und bei verwalteten Endpunkten kontrolliert pro Gerät vorgehen. Er warnt, dass einige Betriebssysteme Option 108 standardmäßig verarbeiten und keinen Abschalter bieten. Für sie macht eine Serveränderung die kompatiblen Geräte augenblicklich IPv6-only — aus einem kleinen Konfigurationsschritt wird ein Subnetzereignis.

Linkovas IETF-118-Folien schildern Pilotstandorte in Google-Büros, die Ausweitung über Standorte und schrittweise höhere Aktivierungsanteile. Sie berichten auch geringere DHCP-Auslastung und erwartete Adressrückgewinnung. Diese Zahlen sind Aussagen der Präsentation aus einer bestimmten Umgebung, keine unabhängigen universellen Messwerte.

Übertragbar ist die Versuchsanordnung: begrenzte Kohorte, Beobachtung, Erweiterung und ein verfügbarer Rückweg. Der Text formuliert eine Hypothese. Leases, Pakete und Störungen entscheiden, ob sie im Betrieb trägt.

Was eine abgelehnte Lease über Bedarf sagt

Eine nicht bezogene Adresse bleibt für andere Endpunkte frei. Bei öffentlichen IPv4-Adressen kann das öffentlichen Verbrauch senken. In RFC-1918-Netzen kann es privaten Adressdruck mindern oder eine weitere NAT-Schicht vermeiden. Neue Segmente können kleiner geplant werden; bestehende müssen womöglich neu nummeriert werden, bevor freie Stellen als zusammenhängender Raum nutzbar sind.

Der Nachweis ist aber bedingt: Diese Schnittstelle, diese Version, diese Richtlinie und diese Übersetzungsumgebung kamen während dieses Intervalls ohne Lease aus. Er beweist weder den Erfolg aller Anwendungen noch dasselbe Verhalten in einem anderen Netz. Er sagt auch nicht, dass der verbleibende IPv4-Bedarf unberechtigt ist.

Knappheit verschwindet dadurch nicht. Bedarf kann sich auf diejenigen Nutzungen konzentrieren, die nicht ausweichen können. Der wirtschaftliche Wert der Option liegt darin, automatische Zuteilung von beobachtetem Bedarf zu trennen, nicht darin, den Wert der Adresse zu leugnen.

Ein Dashboard sollte daher Anforderungen, gültige Antworten, vermiedene Leases, spätere Rückkehr, NAT64/CLAT-Zustand, Fehler nach Anwendung und tatsächlich verkleinerten oder wiederverwendeten Adressraum getrennt zeigen. Eine freie Tabellenzeile ist noch keine zurückgewonnene Ressource.

Die Fünf-Minuten-Uhr verhindert, dass aus einer zeitweisen Antwort ein Dogma wird. Das Netz protokolliert „jetzt nicht“, beobachtet und darf später anders entscheiden.

Jen Linkovas belegte Rolle

RFC 8925 nennt Lorenzo Colitti, Jen Linkova, Michael C. Richardson und Tomek Mrugalski. Linkova erscheint außerdem mit weiteren Autoren auf RFC 8781, RFC 9872 und dem aktuellen 6MOPS-Entwurf. Das belegt fortgesetzte Mitarbeit an verbundenen IPv6-Betriebsmechanismen, nicht alleinige Erfindung oder Kontrolle über Produkte und Netze.

Diese Begrenzung passt zur Architektur. Die Spezifikation definiert gemeinsame Semantik, der Client fordert an, der Betreiber konfiguriert den Pool, und laufender Code erzeugt das Ergebnis. Nichtteilnehmer führen gewöhnliches DHCPv4 fort und werden nicht institutionell bestraft.

Der bleibende Beitrag ist kein Datum für IPv4s Ende. Er besteht darin, eine große Frage klein und prüfbar zu machen: Kann diese Adresse unter diesen Bedingungen für eine Weile in Bereitschaft bleiben? Nach fünf Minuten darf die Antwort erneut gegeben werden.

Quellen