The Windows CLAT (WinCLAT) FAQ provides answers to common questions about how WinCLAT works, how to configure it, and its known issues. WinCLAT enables IPv4-dependent applications to communicate over IPv6-only and IPv6-mostly networks using 464XLAT. The questions below cover network prerequisites, automatic and manual operation, configuration options, and practical steps for verifying connectivity and troubleshooting problems. For more information about WinCLAT, see the WinCLAT reference at winclat.com.

Commands in this FAQ

Windows CLAT is managed with the netsh.exe interface clat command context. Where a netsh.exe command is shown, the equivalent command from the WinCLAT PowerShell module follows it. The module runs locally or against many computers with the -ComputerName parameter, returns its results as objects, and reads the state back after every change.

WinCLAT PowerShell Module

To install the WinCLAT PowerShell module from the PowerShell Gallery, open an elevated PowerShell command window and run the following command.

Install-Module -Name WinCLAT -Scope CurrentUser

Install it on the computer you run the commands from. Remote computers need WinRM enabled, but they do not need the module. Commands that stop WinCLAT and all Set-WinClatInstance changes ask for confirmation by default.

Contents

• Overview
• How WinCLAT Works
• Configuration
• Automatic and Manual Instances
• Known Issues
• Monitoring and Troubleshooting
• Provide Feedback

Overview

WinCLAT provides IPv4 application compatibility on Windows devices connected to IPv6-only and IPv6-mostly networks. The following questions explain what it does, which Windows versions include it, and the network services required for operation.

What is Windows CLAT (WinCLAT)?

Windows CLAT (WinCLAT) is the Microsoft Windows customer-side translator (CLAT) of 464XLAT (RFC 6877). It translates locally generated IPv4 traffic into IPv6 for delivery to a NAT64 gateway, known as the provider-side translator (PLAT). Windows previously offered CLAT on cellular interfaces only. WinCLAT extends it to other non-cellular interfaces, such as Ethernet and Wi-Fi.

What problem does it solve?

DNS64 and NAT64 let IPv6-capable applications reach IPv4-only destinations by name, but they cannot help an application that uses an IPv4 socket or a literal IPv4 address. WinCLAT gives those applications a working IPv4 path on IPv6-only and IPv6-mostly networks.

Which versions of Windows include it?

Microsoft announced on October 27, 2026, that WinCLAT is generally available on Windows 11 version 25H2, starting with build 26200.9550. To validate that a machine has the feature installed, look for clat in the list of available sub-contexts in the output of the following command.

netsh.exe interface ?

With the WinCLAT module, a computer without the feature returns a Status of FeatureNotAvailable, and the OSBuild property shows its build.

Get-WinClatConfiguration

Is it available on Windows Server?

No. Microsoft has indicated that it does not currently plan to support WinCLAT on Windows Server.

What does the network need to provide?

• NAT64, which is where translated traffic is delivered.
• Stateless Address Autoconfiguration (SLAAC) and an IPv6 default route. WinCLAT requires a SLAAC-configured IPv6 address on the interface. DHCPv6-only address assignment does not meet this requirement.
• A way to discover the NAT64 prefix, through the PREF64 option in router advertisements (RFC 8781), a DNS64 server that answers queries for ipv4only.arpa (RFC 7050), or both.

How WinCLAT Works

WinCLAT activates on eligible interfaces and translates locally generated IPv4 traffic into IPv6 for delivery to a NAT64 gateway. This section explains the activation requirements, local addressing, NAT64 prefix discovery, and interaction with other network interfaces.

When Does WinCLAT Activate?

Automatic activation on a non-cellular interface requires all of the following.

• Permit and autoenable are enabled.
• The interface has an IPv6 address from SLAAC and an IPv6 default route.
• The interface has no native IPv4 connectivity. An APIPA address (RFC 3927) does not count as native IPv4.
• A NAT64 prefix has been discovered.

What happens when WinCLAT activates?

Windows enables an instance on the interface, discovers the NAT64 prefix, and starts translating. It then adds the following to the interface.

• An IPv4 address from 192.0.0.0/29, starting with 192.0.0.1/32.
• An IPv4 default route with a next hop of 192.0.0.0.
• A CLAT IPv6 address, which is regenerated each time the instance is re-created, so it is not a stable identifier.

Why does the WinCLAT interface have a 192.0.0.1 IP address?

The address comes from the IPv4 Service Continuity Prefix (RFC 7335). It gives IPv4 applications a local source address, and it is not native IPv4 connectivity. A second translating interface on the same computer receives 192.0.0.2. Additional translating interfaces can receive other addresses from the same reserved prefix.

How does Windows discover the NAT64 prefix?

WinCLAT discovers the NAT64 prefix from the PREF64 option in IPv6 router advertisements or through DNS64 queries for AAAA records for ipv4only.arpa. Either method can be enabled or disabled independently.

The following comparison includes timings and prefix lifetimes observed during testing. Activation times vary with Windows build, network readiness, router advertisement timing, and DNS response time.

The extra time on a DNS64-only network is Windows waiting to conclude that the interface has no IPv4 addressing. In testing, the DNS64 query itself completed in less than 0.1 seconds.

Should I use PREF64 or DNS64?

NAT64 prefix discovery with PREF64 is preferred. DNS64 prefix discovery can be used as a fallback. Both discovery methods for WinCLAT are enabled by default.

Does WinCLAT run on a dual-stack network?

WinCLAT does not activate automatically on an interface with native IPv4 connectivity. This is expected on a conventional dual-stack network. An existing manual instance can remain enabled, so an enabled instance alone does not demonstrate that translation is active or that application traffic uses WinCLAT.

What if a computer has native IPv4 on another interface?

In multihomed configurations, WinCLAT can still run on an eligible IPv6-only interface when another interface has native IPv4 connectivity. With typical routing settings, Windows prefers the native IPv4 path. However, route selection depends on the destination prefix and the combined route and interface metrics. Use Find-NetRoute with the destination IPv4 address to confirm the selected path.

How does WinCLAT work with DHCP option 108?

DHCPv4 option 108 (RFC 8925), called IPv6-Only Preferred, allows a compatible client to suspend DHCPv4 configuration for the indicated wait period and operate without a native IPv4 address. In the Windows behavior described here, the client honors this option when permit is enabled. Option 108 does not provide the NAT64 prefix. WinCLAT discovers that separately through router advertisements or DNS64.

See also: Configure DHCP Option 108 on Windows DHCP Server for IPv6-Mostly

Does WinCLAT work with DHCPv6-only addressing?

No. WinCLAT requires an address from SLAAC.

Can WinCLAT run on virtual and VPN adapters?

The non-cellular WinCLAT feature discussed here supports Ethernet and Wi-Fi interfaces. Virtual and VPN adapters are not supported by this feature.

How long does WinCLAT take to start after a reboot?

In testing on a network advertising PREF64, Windows enabled WinCLAT approximately seven seconds after boot. Actual startup time varies with the Windows build, adapter initialization, and network readiness.

Which service does WinCLAT use?

The IP Translation Configuration Service (IPxlatCfgSvc). It typically runs while WinCLAT is translating and is stopped otherwise, but it is trigger-started and netsh.exe queries may start it, so its state is not a reliable indicator of whether WinCLAT is working.

Configuration

WinCLAT uses global settings to control whether translation is permitted, how the NAT64 prefix is discovered, and whether eligible interfaces are enabled automatically. These settings can be managed locally or through Group Policy. The following questions explain the defaults, configuration commands, and how to identify the effective settings.

What are the WinCLAT configuration settings and their defaults?

Microsoft has indicated that it plans to enable permit by default in a future release, with no date announced.

Why is WinCLAT not active on a new computer?

Permit is disabled by default, so WinCLAT does not activate on Ethernet or Wi-Fi until it is enabled.

How do I enable WinCLAT?

Enable permit from an elevated prompt. With autoenable enabled, Windows automatically activates WinCLAT when an interface meets the addressing and NAT64 prefix-discovery requirements.

netsh.exe interface clat set global permit=enabled

With the WinCLAT module.

Set-WinClatConfiguration -Permit Enabled

Can I configure WinCLAT with Group Policy?

Yes. The settings are under Computer Configuration > Policies > Administrative Templates > Network > TCPIP Settings > IPv6 Transition Technologies.  You can inspect the policy-controlled WinCLAT settings in Registry Editor (regedit.exe) at the following location.

HKLM\SOFTWARE\Policies\Microsoft\Windows\TCPIP\v6Transition\IPxlatCfgSvc

There is no policy for autoenable, so Group Policy cannot stop an administrator from disabling it.

Note: More details on configuring WinCLAT with Group Policy can be found here.

Why did netsh.exe report success but the setting did not change?

Group Policy is probably controlling it. Netsh.exe interface clat set global on a policy-controlled setting returns exit code 0 with no message, changes the persistent store, and leaves the active store unchanged. Compare the stores to see the effective value:

netsh.exe interface clat show global store=both

The active store is the effective configuration, and the persistent store is the local configuration. A policy that matches the local value does not show up as a difference between the stores, so with netsh.exe, only the registry key above reveals it.

How do I know if WinCLAT settings are controlled with Group Policy?

With the WinCLAT module, the PolicyControlled property lists every setting that policy controls, and Set-WinClatConfiguration returns a Status of PolicyOverride when policy keeps a different value.

What is the difference between permit and autoenable?

Permit controls whether WinCLAT can be enabled on non-cellular interfaces. Autoenable controls whether Windows enables eligible interfaces automatically. Disabling either setting stops automatic instances, but existing manual instances can continue translating, as shown below.

What happens if both discovery methods are disabled?

Netsh.exe accepts pref64fromra=disabled and pref64fromdns=disabled simultaneously without complaint. However, WinCLAT can never activate in this state. Set-WinClatConfiguration refuses this combination and returns a Status of Failed.

How do I turn WinCLAT off completely?

Neither permit nor autoenable is a master off switch, because existing manual instances can remain enabled. Disable permit, then inspect each interface and disable any remaining manually enabled instances, even if they are not currently translating. If Group Policy controls permit, change the policy instead.

# For each remaining manually enabled instance
netsh.exe interface clat set global permit=disabled
netsh.exe interface clat show instance interface=<index>
# Only when an instance is still translating
netsh.exe interface clat set global autoenable=disabled
netsh.exe interface clat set instance interface=<index> state=disabled
netsh.exe interface clat set global autoenable=enabled

With the WinCLAT module, disable Permit, then inspect the interface instances. Disable any remaining manually enabled instances, including those that are not currently translating.

Set-WinClatConfiguration -Permit Disabled
Get-WinClatInstance
# For each remaining manually enabled interface
Set-WinClatConfiguration -AutoEnable Disabled
Set-WinClatInstance -InterfaceAlias 'Ethernet' -State Disabled
Set-WinClatConfiguration -AutoEnable Enabled

How do I see or save the configuration?

Netsh.exe interface clat dump displays a configuration script with a single netsh.exe interface clat set global command. It contains the persistent (local) values, not values set by Group Policy, and does not include instance state.

netsh.exe interface clat dump

With the WinCLAT module, the same output is saved to a file, one per computer, in an existing folder. Import-WinClatConfiguration applies a saved file.

Export-WinClatConfiguration -Path C:\Exports

Which commands require elevation?

Test-WinClat runs its global checks without elevation and skips its interface checks.

Automatic and Manual Instances

WinCLAT maintains a translation instance for each interface on which it is enabled. Windows normally manages these instances automatically, but administrators can enable them manually for troubleshooting. Automatic and manual instances respond differently to configuration changes, adapter restarts, and reboots.

What is the difference between an automatic and a manual instance?

Windows starts an automatic instance when an interface becomes eligible and stops it when permit or autoenable is disabled. An administrator starts a manual instance with netsh.exe interface clat set instance, and Windows tracks it separately. A manual instance keeps running through changes to the global settings until it is disabled or the computer reboots.

How do I enable WinCLAT manually?

Netsh.exe refuses set instance while autoenable is enabled, in both directions, so disable autoenable first. Permit must also be enabled, or netsh.exe returns “CLAT not permitted.”

netsh.exe interface clat set global autoenable=disabled
netsh.exe interface clat set instance interface=<index> state=enabled

Disabling autoenable stops WinCLAT on every automatically enabled interface on the computer. Get the interface index from Get-NetAdapter. An interface name also works, but the index avoids quoting problems.

With the WinCLAT module, one command disables autoenable when needed and enables the instance, under one confirmation.

Set-WinClatInstance -InterfaceAlias 'Ethernet' -State Enabled

When should I use a manual instance?

Treat manual mode as a troubleshooting tool, not a production configuration. Manual state does not survive a reboot, and manual mode leaves autoenable disabled for the whole computer.

Which changes preserve a manual instance?

Why did WinCLAT stop working after a reboot?

The computer was probably in manual mode. The manual instance was lost, but autoenable stayed disabled, so WinCLAT does not activate. Enable autoenable again to restore automatic operation.

netsh.exe interface clat set global autoenable=enabled

With the WinCLAT module.

Set-WinClatConfiguration -AutoEnable Enabled

Can I disable WinCLAT on one interface in automatic mode?

No. Netsh.exe refuses set instance while autoenable is enabled, and an eligible interface starts WinCLAT again whenever autoenable is enabled. The only way to stop WinCLAT in automatic mode is to disable autoenable or permit, which affects every automatically enabled interface.

How do I return an interface from manual to automatic control?

Enabling autoenable is not enough, because a running manual instance keeps running. Use all three commands. The first one briefly stops WinCLAT on every automatically enabled interface.

netsh.exe interface clat set global autoenable=disabled
netsh.exe interface clat set instance interface=<index> state=disabled
netsh.exe interface clat set global autoenable=enabled

With the WinCLAT module.

Set-WinClatConfiguration -AutoEnable Disabled
Set-WinClatInstance -InterfaceAlias 'Ethernet' -State Disabled
Set-WinClatConfiguration -AutoEnable Enabled

A reboot also clears a manual instance, but autoenable must still be enabled afterward if it was left disabled.

Known Issues

The following table summarizes known WinCLAT issues, their current status, and available workarounds. Each issue is explained in more detail below.

Issues and workarounds

Why does IPv4 fail after moving to a different network?

When a translating client moves to a different IPv6 network without an adapter restart, its SLAAC addresses move to the new prefix, but the WinCLAT IPv6 address stays on the previous one. This affects both automatic and manual instances. Symptoms include:

• IPv4 traffic through WinCLAT fails.
• Netsh.exe interface clat show instance still reports that the instance is translating.
• Netsh.exe interface clat show instance may report the old prefix, or a new address that is not actually assigned.
• No event is logged after the move.

To investigate, list the adapter’s IPv6 addresses and compare them with the WinCLAT IPv6 address reported by the instance. A WinCLAT address with a PrefixOrigin of Manual that remains on the previous network’s prefix indicates this condition. PrefixOrigin alone is not sufficient to identify a stale WinCLAT address.

Get-NetIPAddress -InterfaceIndex <ifIndex> -AddressFamily IPv6 | Format-Table -Property IPAddress, PrefixOrigin, SuffixOrigin

With the WinCLAT module, Test-WinClat reports this condition as a failed CLAT address check, with the remediation in the result.

Test-WinClat -Detailed | Where-Object -FilterScript { $_.Check -eq 'CLAT address' } | Format-List -Property InterfaceAlias, Result, Detail, Remediation

To resolve the issue, restart the adapter. Windows then assigns WinCLAT an IPv6 address on the current prefix

Restart-NetAdapter -Name 'Ethernet'

Why are computers registering WinCLAT addresses in DNS?

Windows clients with WinCLAT active may dynamically register their local WinCLAT IPv4 address, such as 192.0.0.1, in DNS. This address provides local IPv4 compatibility and is not reachable from other computers. Publishing it can cause connection failures or delays when another system attempts to use the resulting A record.

Why does ping to an unreachable IPv4 address time out?

NAT64 returns ICMPv6 destination unreachable messages, which are visible in a packet capture on the adapter, but the translated errors never reach the IPv4 socket. Ping and TCP connections to an unreachable address therefore time out instead of failing immediately. TCP resets are not affected, so a connection to a closed port that sends a reset is refused as usual.

Monitoring and Troubleshooting

Troubleshooting WinCLAT requires checking the effective configuration, interface addressing, translation state, and application traffic. Command output and event logs provide useful evidence, but neither alone confirms successful translation. The following questions explain how to interpret these results and test the IPv4 traffic path.

How do I check whether WinCLAT is working?

Run the following commands from an elevated prompt. An active instance shows State:enabled, Is translating:yes, a remote prefix, and an IPv4 address in 192.0.0.0/29.

netsh.exe interface clat show global store=both
netsh.exe interface clat show instance interface=<index>

With the WinCLAT module, Test-WinClat also checks the prerequisites and explains each failure.

Get-WinClatConfiguration -Store Both
Get-WinClatInstance -InterfaceAlias 'Ethernet'
Test-WinClat

Because netsh.exe interface clat show instance can report addresses that are not assigned to the adapter (as described under Known Issues), also confirm the addresses with Get-NetIPAddress and test the traffic path.

How do I prove traffic is going through WinCLAT?

Use Find-NetRoute to identify the interface and source address Windows would select for the destination. A source address in 192.0.0.0/29 indicates selection of the WinCLAT path. This confirms route selection, but a connectivity test is still required to verify that traffic successfully reaches the destination.

Find-NetRoute -RemoteIPAddress 1.1.1.1

With the WinCLAT module, specify -IPv4Target to perform a functional connectivity test. The test uses ICMP echo requests unless -IPv4Port is specified. The following example tests TCP connectivity to port 443 on an IPv4 destination.

Test-WinClat -IPv4Target 172.16.0.204 -IPv4Port 443

Note: Add -Detailed to the command above to display individual check results and remediation guidance.

Why did connecting by name work when IPv4 does not?

An IPv6-capable application can receive a DNS64-synthesized AAAA record and reach an IPv4-only destination through NAT64 without using WinCLAT. A successful connection by name therefore does not confirm WinCLAT operation. Use a literal IPv4 address when testing the WinCLAT traffic path.

What does netsh.exe interface clat show instance report when something is missing?

Get-WinClatInstance shows an empty RemotePrefix for both none and ::/0, and the Enabled property tells them apart. An expired prefix keeps its value, with a lifetime of 00:00:00.

Why is the instance enabled but not translating?

The usual causes are:

• No usable NAT64 prefix was discovered. Check whether PREF64 advertisements are available and pref64fromra is enabled, or whether DNS64 discovery is available and pref64fromdns is enabled.
• The interface now has native IPv4. This is typical of a leftover manual instance.
• A previously discovered prefix has expired. After moving to a network without a discoverable NAT64 prefix, a manual instance may temporarily retain the old prefix before translation stops.

Why does netsh.exe report addresses that are not on the adapter?

Netsh.exe interface clat show instance is not a reliable record of what is assigned. An enabled instance that is not translating can keep reporting its CLAT IPv6 address and 192.0.0.1, although neither is on the adapter, and it can keep an expired prefix at 0s indefinitely. The same mismatch can occur after a network change. Get-NetIPAddress shows what is actually assigned.

Should I worry about a DNS-discovered prefix lifetime near zero?

A low remaining lifetime does not by itself indicate a problem. In testing with DNS-based prefix discovery, Windows queried DNS64 again when the lifetime expired, logged event 1108, and retained the same WinCLAT IPv6 address. Translation continued without a logged interruption.

What do the netsh.exe exit codes and messages mean?

A successful change prints nothing, so exit code 0 does not prove that a change took effect. Always read the state back. The WinCLAT module does this after every change and reports the outcome in the Status and Message properties.

A missing feature and an elevation failure both return exit code 1, so read the message rather than the code. Netsh.exe also checks autoenable before elevation, so a standard user running netsh.exe interface clat set instance in automatic mode sees the AutoEnable message.

Which events does Windows log?

WinCLAT events are recorded in the Microsoft-Windows-IPxlatCfg/Operational log, which is enabled by default.

Is the event log a complete record?

No. Changes to the global settings are not logged and appear only through their effect on instances. A manual instance surviving those changes logs nothing, a stale address after a network change logs nothing, and Windows can disable an instance without logging 1107. In addition, the log does not record individual application connections through WinCLAT, including application names, destination addresses, or ports. Perform a network trace or use other connection-monitoring tools to investigate application traffic.

Additional Information

WinCLAT Resources on directaccess.richardhicks.com

Feedback Welcome

Have a question that isn’t covered here, a correction, or a suggestion for improving the WinCLAT FAQ? Use the form below to share your feedback.