Windows CLAT ist da – IPv4 stirbt trotzdem nicht – Grams IT

Microsoft hat am 27. Oktober 2026 im Networking Blog gemeldet, dass Windows CLAT jetzt allgemein verfügbar ist. Windows CLAT ist die clientseitige Hälfte von 464XLAT: Windows 11 übersetzt IPv4-Pakete einer Anwendung selbst in IPv6, damit auch Programme, die nur IPv4 können, in einem reinen IPv6-Netz weiterlaufen. Für alle, die seit Jahren Dual-Stack betreiben, weil irgendein Fachverfahren oder Lizenzserver an IPv4 hängt, ist das eine gute Nachricht.

Ich habe die Ankündigung gegen die übrigen Microsoft-Quellen geprüft. Im Kern ist alles stimmig, bei der Frage, mit welchem Update CLAT tatsächlich ankommt, lohnt aber ein zweiter Blick. Dieser Artikel klärt das, zeigt, wie Sie CLAT aktivieren und prüfen, was das Netz dafür liefern muss, und warum IPv4 in lokalen Subnetzen noch lange nicht verschwindet.

Was Microsoft zu Windows CLAT angekündigt hat

Laut dem Beitrag von Jim Alumbaugh im Networking Blog ist Windows CLAT (Customer-side Translator) für Windows 11 Client 25H2 ab Build 26200.9550 allgemein verfügbar. Auf die Frage eines Lesers, ob für 25H2 weitere Patches nötig seien, antwortet der Autor in den Kommentaren, ab Build 26200.9550 oder neuer sei nichts weiter erforderlich.

Microsoft beschreibt CLAT als Funktion für IPv6-fähige Verbindungen über WLAN, Ethernet und Mobilfunk. Die Konfigurationserkennung startet, wenn ein Netz keine IPv4-Konnektivität bietet oder per DHCP-Option 108 signalisiert, dass es IPv6-only bevorzugt. Das Übersetzungspräfix (PREF64) holt sich Windows aus den Router Advertisements nach RFC 8781. Fehlt es dort, fragt Windows per DNS den Namen ipv4only.arpa ab (RFC 7050). Ausdrücklich gilt das alles nur für Netze, in denen ein NAT64-Dienst existiert. Ohne Gegenstelle übersetzt CLAT ins Leere.

Als Vorteile nennt Microsoft den Zugriff auf IPv4-Ressourcen ohne durchgehenden Dual-Stack, einen geringeren Bedarf an öffentlichen IPv4-Adressen, weil sich Geräte über NAT64 eine Adresse teilen, und eine einfachere Netzkonfiguration.

Faktencheck: KB5124010 oder KB5127936?

Build 26200.9550 kommt mit dem Preview-Update KB5124010 vom 22. September 2026. KB5124010 bringt die Builds 26300.9550, 26200.9550 und 26100.9550 und gilt für Windows 11 26H2, 25H2 und 24H2. Nur: In den Release Notes von KB5124010 taucht CLAT nicht auf. Kein Wort zu IPv6, 464XLAT oder netsh.

Dokumentiert hat Microsoft die Funktion an anderer Stelle. Die Release-Preview-Notizen zu den Builds 26200.9807 und 26300.9807 vom 16. Oktober 2026 nennen „IPv6 CLAT for Wi-Fi and Ethernet“ erstmals als neue Funktion für 25H2 und 26H2. Dasselbe steht im Supportartikel zu KB5127936, dem Preview-Update mit den Builds 26300.9818 und 26200.9818. Die Seite trägt das Datum 28. Oktober 2026, an anderer Stelle verweist Microsoft auf dasselbe Update als „released October 27, 2026“. Und: CLAT steht dort im Abschnitt „Gradual rollout“. Die Funktion kann also schrittweise auf Geräten ankommen, nicht auf allen gleichzeitig.

Meine Lesart: Der Code steckt seit Build 26200.9550 im System, wie der Networking Blog sagt, offiziell in den Release Notes beschrieben ist er erst mit KB5127936. Für 26H2 gilt die Funktion damit ebenfalls, denn KB5127936 ist ausdrücklich für beide Versionen bestimmt, auch wenn der GA-Beitrag selbst nur 25H2 nennt. Für 24H2 habe ich keine Microsoft-Aussage zu CLAT gefunden, obwohl KB5124010 auch dort Build 26100.9550 installiert. Davon würde ich nichts ableiten. Wer es genau wissen will, prüft am Gerät mit netsh interface clat show global, ob der Befehlskontext existiert.

Übrigens ist „Customer-side Translator“ keine Microsoft-Wortschöpfung. So heißt der Baustein bereits in RFC 6877 von 2013.

So funktioniert 464XLAT mit CLAT und PLAT

RFC 6877 beschreibt 464XLAT als Kombination aus zwei Übersetzern. Der CLAT auf dem Endgerät übersetzt zustandslos nach RFC 6145 private IPv4-Adressen 1:1 in globale IPv6-Adressen. Der PLAT auf Providerseite, praktisch ein NAT64-Gateway nach RFC 6146, übersetzt zustandsbehaftet viele IPv6-Absender auf wenige öffentliche IPv4-Adressen. Die Anwendung sieht davon nichts: Sie bekommt eine synthetische IPv4-Adresse und eine IPv4-Standardroute und glaubt, im IPv4-Netz zu sein.

Schaubild: Oben läuft eine IPv4-only-App über den CLAT im Windows-Client, das IPv6-only-Netz und PLAT/NAT64 zum IPv4-Dienst im Internet. Unten führt vom IPv6-only-Client kein direkter Weg zu einem lokalen IPv4-Drucker mit privater Adresse, weil der Well-Known Prefix 64:ff9b::/96 laut RFC 6052 keine RFC-1918-Adressen abbilden darf.

Der obere Weg ist der, den Microsoft beschreibt. Der untere ist der, über den in der Ankündigung niemand spricht, und auf den komme ich gleich zurück.

Neu ist die Technik auf Windows nicht. CLAT gab es bisher für Mobilfunkverbindungen. Im März 2024 schrieb Microsoft im Networking Blog, man werde die CLAT-Unterstützung auf Nicht-Mobilfunk-Schnittstellen ausweiten. Im November 2025 folgte die Private Preview, danach die Public Preview im Insider-Programm, die erstmals Gruppenrichtlinien mitbrachte. Gut zweieinhalb Jahre von der Ankündigung bis zur allgemeinen Verfügbarkeit. Für ein Stück Netzwerkstack, das jeden Windows-Client betrifft, finde ich das nicht übertrieben.

Windows CLAT aktivieren und prüfen

Laut KB5127936 und der netsh-Referenz auf Microsoft Learn schalten Sie CLAT in einer administrativen Eingabeaufforderung so ein:

netsh interface clat set global permit=enabled pref64fromdns=enabled pref64fromra=enabled

Der Parameter permit legt fest, ob CLAT auf Schnittstellen erlaubt ist, die keine Mobilfunkschnittstellen sind. pref64fromra aktiviert die Präfixerkennung über Router Advertisements, pref64fromdns die über DNS. Sind beide aktiv, dient DNS nur als Rückfallebene. Schalten Sie beide ab, kann CLAT nicht starten, Microsoft nennt diese Kombination ungültig. In der Public Preview verlangte jede Änderung an den PREF64-Methoden einen Neustart. Ob das in der GA-Version noch so ist, schreibt Microsoft nicht, ich würde nach der Umstellung trotzdem neu starten.

Zur Kontrolle gibt es zwei Befehle:

netsh interface clat show global
netsh interface clat show instance interface="Ethernet"

Der erste zeigt die wirksame globale Konfiguration, der zweite pro Schnittstelle das lokale Präfix, die CLAT-IPv6-Adresse und die synthetische IPv4-Adresse. Für Domänenumgebungen gibt es die Einstellungen als Gruppenrichtlinie, laut Microsoft unter Network > TCPIP Settings > IPv6 Transition Technologies in den administrativen Vorlagen der Computerkonfiguration. Laut Public-Preview-Beitrag überschreibt ein per GPO gesetzter Wert den per netsh gesetzten, und show global zeigt die wirksame Kombination.

Ob CLAT auf Ethernet und WLAN ohne Zutun aktiv ist, sagt Microsoft nicht ausdrücklich. Die Release Notes formulieren „Enable CLAT by using …“, das klingt nach Opt-in. show global beantwortet die Frage für Ihr Gerät verlässlicher als jede Pressemeldung.

Drei Einschränkungen nennt Microsoft in den Release Notes, und die sind für Unternehmensnetze nicht nebensächlich: CLAT braucht IPv6-Adressen per SLAAC. DHCPv6 Prefix Delegation wird derzeit nicht unterstützt, und das Windows-Subsystem für Linux (WSL) ebenfalls nicht. Wer seine Clients per stateful DHCPv6 adressiert, um Adressen sauber im IPAM zu führen, muss also erst einmal umdenken oder warten.

Voraussetzungen im Netz: NAT64, PREF64 und DHCP-Option 108

CLAT allein bewirkt nichts. Das Netz muss drei Dinge liefern.

Erstens ein NAT64-Gateway, das als PLAT arbeitet. Der IETF-Entwurf „IPv6-mostly Networks“ (draft-ietf-v6ops-6mops-08) vom Juli 2026 hält es für deutlich günstiger, NAT44 und NAT64 auf denselben Geräten zu bündeln, weil separate Boxen zusätzliche Kapazitätsplanung, Rackplatz und Strom kosten.

Zweitens das PREF64-Präfix in den Router Advertisements. Das ist der Weg, den Windows standardmäßig zuerst nutzt. Der 6mops-Entwurf warnt ausdrücklich: Wer ein gefälschtes NAT64-Präfix ins Netz bringt, kann den Verkehr umleiten oder lahmlegen, und ein IPv6-only-Client hat keinen IPv4-Notausgang mehr. Als Gegenmaßnahme nennt er PREF64 in den RAs zusammen mit RA-Guard (RFC 6105) am Switch.

Drittens, für gemischte Segmente, DHCP-Option 108 nach RFC 8925. Damit sagt ein Client: Ich komme ohne IPv4 aus, wenn ihr NAT64 habt. IPv4 wird nur abgeschaltet, wenn Client und Server beide mitspielen. Der Server darf die Option nur schicken, wenn der Client sie anfragt, und laut RFC nur, wenn das Netz NAT64 bereitstellt. Alle anderen Geräte bekommen wie gewohnt ihre IPv4-Adresse. Der Client verzichtet dann für eine Wartezeit (V6ONLY_WAIT, Standard 1800 Sekunden, Minimum 300) auf DHCPv4. Der IETF-Entwurf rät für den Anfang zu 300 Sekunden, damit ein Rollback schnell greift.

Eine Stolperfalle aus dem Entwurf sollten Sie vor dem Test kennen: Switches mit DHCP-Snooping oder Portsicherheit, die den Netzzugang an eine erfolgreiche IPv4-Zuweisung koppeln, sperren Clients mit Option 108 unter Umständen aus. Solche harten Abhängigkeiten müssen vorher raus.

Warum IPv4 nicht sterben will – vor allem im lokalen Subnetz

Jetzt zum unteren Teil der Grafik. 464XLAT löst den Weg ins Internet. Für das eigene Subnetz löst es wenig, und genau dort lebt IPv4 am zähesten.

Das erste Problem ist ein formales. Der bekannte NAT64-Präfix 64:ff9b::/96, den viele Gateways ab Werk nutzen, darf laut RFC 6052, Abschnitt 3.1 keine nicht-globalen IPv4-Adressen abbilden, also keine Adressen aus 10.0.0.0/8, 172.16.0.0/12 oder 192.168.0.0/16. Übersetzer müssen solche Pakete verwerfen. Will ein IPv6-only-Client mit CLAT also den Drucker auf 192.168.10.50 erreichen, braucht es ein netzspezifisches NAT64-Präfix oder ein Gateway, das den Entwurf draft-ietf-v6ops-nat64-wkp-1918 umsetzt, der diese Einschränkung aufheben will. Und der Verkehr zum Drucker zwei Meter weiter läuft dann über das NAT64-Gateway, statt direkt im Segment zu bleiben. Der 6mops-Entwurf sagt es nüchtern: Sind interne Dienste nicht IPv6-fähig, muss NAT64 auch für interne Ziele her und unter Umständen näher an die Clients rücken.

Das zweite Problem ist die Gerätesuche. Im selben Segment entstehen laut 6mops-Entwurf zwei voneinander unabhängige „.local“-Zonen: eine für IPv4-only-Geräte, eine für IPv6-only-Geräte. mDNS-basierte Suche funktioniert über diese Grenze nicht ohne Relay. Wo Geräte direkt miteinander sprechen sollen, müssen alle Beteiligten Dual-Stack oder IPv6-mostly sein. In Netzen mit Client-Isolation, etwa einem Gäste-WLAN, fällt das nicht ins Gewicht. Im Büro mit Netzwerkdrucker, Besprechungsraum-Display und Zeiterfassungsterminal schon.

Das dritte Problem sind die Geräte selbst. Drucker, Gebäudeleittechnik, USV-Karten, ältere Telefonanlagen, Zutrittskontrolle, Messgeräte: Nach meiner Erfahrung spricht vieles davon kein oder nur halbherzig IPv6, und manches bekommt nie wieder ein Firmware-Update. CLAT ändert daran nichts, es hilft nur dem Windows-Client. Der 6mops-Entwurf hält fest, dass viele Systeme und Anwendungen tiefe IPv4-Abhängigkeiten haben und sowohl eine IPv4-Adresse am Host als auch IPv4-Routing im Netz brauchen. Anwendungen, die IPv4-Literale fest einprogrammiert haben, profitieren nicht von DNS64, nur von CLAT.

Und schließlich die große Zahl: Am 28. März 2026, einem Samstag, griffen laut Internet Society Pulse erstmals mehr als die Hälfte der Nutzer über IPv6 auf Google zu, genau 50,10 Prozent. Umgekehrt heißt das: Die andere Hälfte kam auch 2026 noch über IPv4.

Für die öffentliche Verwaltung kommt eine Besonderheit dazu. IPv6-Adressraum ist dort nicht das Problem. Der Bund hat laut IP- und ASN-Referenzhandbuch der öffentlichen Verwaltung schon 2009 einen /26-Block für die gesamte Verwaltung erhalten, 2018 wurde er auf ein /23 erweitert. Kommunen beziehen ihre Präfixe in der Regel über die Sub-LIR ihres Landes. Das IPv6-Routingkonzept für die öffentliche Verwaltung von 2016 nannte als Hauptgrund für das fehlende behördenübergreifende Routing die Verwendung von IPv4 mit identischen, sich überschneidenden internen Adressbereichen. Die Adressen liegen also bereit. Was fehlt, ist meist die Zeit, jedes Altgerät und jedes Fachverfahren auf IPv6-Tauglichkeit zu prüfen.

Die Gegenposition: Warum nicht einfach Dual-Stack lassen?

Fairerweise: Dual-Stack funktioniert. Es ist gut verstanden, jede Firewall kann es, und Fehler in einem Protokoll fallen nicht sofort auf, weil das andere einspringt. CLAT dagegen fügt zwei Übersetzungsstufen hinzu, ein NAT64-Gateway als neue kritische Komponente und mit Option 108 einen weiteren Zustand, den man beim Troubleshooting im Kopf haben muss. Ein IPv6-only-Client hat bei IPv6-Störungen keinen Rückfallweg. Für ein Netz mit 80 Arbeitsplätzen, das seine IPv4-Adressen aus RFC 1918 bezieht und nie knapp wird, ist der Nutzen überschaubar.

Das Argument trägt, aber nur kurzfristig. Der 6mops-Entwurf nennt Dual-Stack eine langfristige Krücke, die Probleme überdeckt, statt sie sichtbar zu machen. Genau das erlebe ich in Dual-Stack-Netzen: IPv6 läuft „irgendwie mit“, niemand testet es ernsthaft, und wenn es einmal klemmt, schaltet jemand IPv6 auf dem Adapter ab. Microsoft rät davon in seiner Anleitung zur IPv6-Konfiguration übrigens ausdrücklich ab, weil Windows mit gebundenem IPv6 getestet wird. Mit CLAT gibt es jetzt auch auf Windows-Clients einen sauberen Weg, IPv6-only zu testen, ohne das Fachverfahren von 2009 gleich mit abzuschalten.

Was Windows CLAT für Kommunen und Admins bedeutet

Eile gibt es keine. CLAT ändert nichts, solange Ihr Netz kein NAT64 anbietet und Sie die Funktion nicht freischalten. Sinnvoll ist ein geordneter Test:

Ein Test-VLAN aufsetzen, mit SLAAC, PREF64 in den Router Advertisements, RA-Guard am Switch und NAT64 auf der Firewall.
Option 108 im DHCPv4-Scope dieses VLANs aktivieren, Wartezeit 300 Sekunden.
Zwei, drei Windows-11-Clients mit aktuellem Patchstand per GPO für CLAT freischalten und mit netsh interface clat show instance prüfen.
Die Fachverfahren durchtesten, die Sie als IPv4-abhängig im Verdacht haben, und dazu die lokalen Geräte: Drucker, Scanner, Terminals, Webinterfaces von Appliances.
Eine Liste der IPv4-only-Geräte führen. Die wird länger, als Sie denken, und sie ist der eigentliche Zeitplan Ihrer IPv6-Migration.

Für Netze mit vielen Altgeräten im selben Segment ist IPv6-mostly der realistische Zielzustand für die nächsten Jahre, nicht IPv6-only. Die Windows-Clients laufen IPv6-only mit CLAT, Drucker und Steuerungen behalten ihre IPv4-Adresse, und der lokale Verkehr zwischen beiden ist der Teil, den Sie bewusst planen müssen. Wer WSL einsetzt oder Clients per stateful DHCPv6 verwaltet, lässt CLAT vorerst aus.

Fazit

Windows CLAT holt auf den Desktop, was im Mobilfunk seit Jahren Alltag ist. Der Vorläuferentwurf des 6mops-Dokuments hielt schon 2024 fest, dass Geräte mit CLAT, etwa Mobiltelefone, im IPv6-only-Betrieb problemlos laufen. Jetzt können auch Windows-Clients in IPv6-only-Netzen weiterarbeiten, auch wenn eine Anwendung nur IPv4 kennt. Eine Präzisierung zur Ankündigung bleibt: Build 26200.9550 aus KB5124010 enthält die Funktion laut Microsoft, beschrieben ist sie aber erst in den Release Notes von KB5127936, und dort im schrittweisen Rollout.

IPv4 verschwindet damit nicht. Es zieht sich aus dem Weg ins Internet zurück und bleibt dort, wo es am längsten überlebt: im lokalen Subnetz, bei Druckern, Steuerungen und Geräten ohne Updates. CLAT hilft dem Client, nicht dem Gerät auf der anderen Seite des Kabels.

Mein Vorschlag: Setzen Sie noch dieses Jahr ein Test-VLAN mit NAT64 und Option 108 auf und schalten Sie CLAT auf zwei Clients frei. Die Liste der Geräte, die dabei nicht mehr erreichbar sind, ist die ehrlichste IPv6-Bestandsaufnahme, die Sie bekommen können.

Quellen: