Zusammenfassung

  • Option 108 lässt einen IPv6-only-fähigen Client auf IPv4 verzichten; der Server antwortet nur in einem konfigurierten IPv6-mostly-Pool.
  • Der Entwurf definiert keine allgemeine Einsatzreife. Gerätepolitik, Ausstieg und von IPv4 verdeckte Fehler bleiben Betreiberaufgaben.

Ein DHCP-Server prüft nicht die Anwendungen eines Laptops und garantiert keinen störungsfreien Arbeitstag ohne IPv4. Option 108 versucht das auch nicht. Ein Client kann den Verzicht signalisieren; der Betreiber entscheidet, wo das Signal gilt.

Version 12 des IETF-Entwurfs zu IPv6-mostly-Netzen wurde am 29. Oktober aktualisiert und steht bis zum 12. November im IESG Last Call. IPv4- und IPv6-only-Geräte teilen ein Segment. Fordert ein Client Option 108 an und erhält sie im DHCPOFFER, soll er die angebotene Adresse nicht anfordern. Geräte ohne Unterstützung können weiter IPv4 aus einem Pool beziehen, der ausdrücklich für IPv6-mostly eingerichtet ist.

Option 108 ist ein Signal, kein Test. „IPv6-only-capable“ hat laut Entwurf keine strenge technische Definition. Gemeint ist ein Gerät, das ohne natives IPv4 funktioniert und Nutzern dieselbe Erfahrung bietet. Anwendungen können IPv6 nutzen; NAT64 macht IPv4-only-Ziele erreichbar; oder das Gerät betreibt CLAT für alte Anwendungen. RFC 6877 definiert diesen kundenseitigen Übersetzer. RFC 8925 behandelt die Erklärung einer Schnittstelle als fähig bereits als politische Entscheidung. DHCP erkennt Einsatzreife nicht. Der Betreiber muss festlegen, welche Geräte das Signal senden dürfen.

Der Server sendet Option 108 nur, wenn der Client danach gefragt hat und der Pool ausdrücklich als IPv6-mostly konfiguriert ist. Der vier Byte lange Wert gibt an, wie lange DHCPv4 deaktiviert wird. Der Server sendet V6ONLY_WAIT oder null, wenn kein Timer gesetzt ist. Die Pool-Konfiguration bestimmt, wo IPv4 verschwindet.

IPv4-only-Ziele brauchen weiter einen Pfad. Der Entwurf setzt auf NAT64 und Präfixsignalisierung nach RFC 8781, per DNS64 nach RFC 6147 oder beidem. Fällt Gerät, DNS, Übersetzer oder Netzzugang aus, ist die Dual-Stack-Ausweichspur weg.

Empfohlen wird ein freiwilliger Pilot, danach die stufenweise Aktivierung von PREF64 und Option 108 mit Ausstiegsmöglichkeit. Nutzer müssen womöglich Fehler melden, um auszusteigen. Das macht Ausfälle sichtbar und Betroffene zugleich zum ersten Testteam. IPv4-Sperren per ACL bleiben eine Übergangslösung, weil die Regeln für mobile Geräte aktuell gehalten werden müssen.

Der Entwurf enthält weder Einsatzzahlen noch gemessene Fehlerdaten und belegt deshalb keine Adressersparnis oder Nutzererfahrung. Sein Argument ist architektonisch: Ein gemeinsames Netz kann IPv4 an verzichtende Clients nicht vergeben und es den übrigen lassen. Offen bleibt, wie Einsatzreife belegt wird, bevor der Support die Antwort Anwendung für Anwendung lernt.

IETF draft -12 · RFC 8925 · RFC 6877 · RFC 8781 · RFC 6147