All posts tagged IPv6 transition technology

Managing Windows CLAT (WinCLAT) with Intune Remediations

Microsoft Intune icon

Windows CLAT (WinCLAT) allows IPv4 applications to reach IPv4 destinations on IPv6-only and IPv6-mostly networks. Windows does not permit WinCLAT on Wi-Fi or Ethernet by default, and Microsoft Intune does not currently expose a setting to permit it. This post explains how to deploy the permit setting with Intune Remediations, verify that WinCLAT is translating, and maintain connectivity to Intune when removing the setting.

WinCLAT Configuration Options in Intune

At the time of this writing, Intune does not expose WinCLAT configuration settings in the Settings Catalog or through a CSP. The corresponding Group Policy settings are defined in the built-in Windows template tcpip.admx. However, Intune’s custom ADMX import feature is intended for third-party and custom templates. Microsoft explicitly advises against importing built-in Windows ADMX files when the goal is to configure those settings, recommending the Settings Catalog or a custom profile instead.

Configuring WinCLAT with Remediations

An Intune Remediation can write the same registry value that Group Policy uses to permit WinCLAT on non-cellular interfaces. Windows reads that value as policy and gives it precedence over the local permit setting. If Group Policy already configures the setting on a device, continue managing it through Group Policy, since a policy refresh can overwrite the value written by the remediation script.

Deployment Requirements

Before deploying the Remediation, confirm that clients meet the following connectivity, platform, and licensing requirements.

Intune Connectivity Before WinCLAT Starts

The Intune Management Extension must be able to reach the endpoints it uses to retrieve the script package before WinCLAT starts. Native IPv4 provides that path on dual-stack networks and on IPv6-mostly networks where Windows still has a DHCPv4 lease. On an IPv6-only network, DNS64 and NAT64 can provide access to IPv4-only Intune endpoints by name. If the target network has no working path to the required endpoints before WinCLAT starts, deploy the package from a network that does. After deployment, verify that the device can still check in with Intune from the target network.

NetworkPath to Intune before WinCLAT is enabledExpected delivery path available?
Dual-stackNative IPv4Yes
IPv6-mostly (DHCPv4 option 108)Native IPv4. While WinCLAT is not permitted, Windows does not honor option 108 and takes a DHCPv4 leaseYes
IPv6-only with DNS64/NAT64DNS64 and NAT64Yes
IPv6-only without DNS64/NAT64No path to required IPv4-only endpoints in this scenarioNo

Windows and Intune Prerequisites

Devices must run Windows 11 version 25H2 build 26200.9550 or later, be Microsoft Entra joined or Microsoft Entra hybrid joined, and be enrolled in Intune or co-managed. Verify that device users have a qualifying license, such as Windows Enterprise E3 or E5, and that the Intune Management Extension is installed before running the package on demand.

WinCLAT Policy Settings

The WinCLAT Group Policy settings are in tcpip.admx under Computer Configuration > Policies > Administrative Templates > Network > TCPIP Settings > IPv6 Transition Technologies, and they are stored as DWORD values in the following location.

HKLM\SOFTWARE\Policies\Microsoft\Windows\TCPIP\v6Transition\IPxlatCfgSvc
Registry valuenetsh.exe settingModule propertyPurpose
PermitNonCellularCLATpermitPermitPermits WinCLAT on non-cellular interfaces
GetPrefixInfoFromRApref64fromraPref64FromRADiscovers the NAT64 prefix from the PREF64 option in router advertisements
GetPrefixInfoFromDNSpref64fromdnsPref64FromDnsDiscovers the NAT64 prefix by querying ipv4only.arpa against a DNS64 server

Interpreting WinCLAT Policy Values

Each policy value is a REG_DWORD. A value of 1 enables the setting, and a value of 0 disables it. Deleting the value returns control to the local setting. Windows allows NAT64 prefix discovery through both router advertisements and DNS by default, so the scripts in this post manage only PermitNonCellularCLAT.

Deploying the WinCLAT Remediation

Detect-WinClatPermitPolicy.ps1 compares PermitNonCellularCLAT with the desired registry state. It returns exit code 0 when the state matches and 1 when a change is needed. When detection returns 1, Intune runs Remediate-WinClatPermitPolicy.ps1 to write or remove the policy value.

Setting the Desired Policy State

Both scripts begin with a $DesiredState variable that corresponds to the three states of the Group Policy setting. Remediations do not accept parameters, so set the variable to the same value in both scripts before uploading them and create a separate Remediation for each state that is needed, such as Enable WinCLAT and Remove WinCLAT Policy.

# Enabled, Disabled, or NotConfigured. Must match the remediation script.
$DesiredState = 'Enabled'
Desired stateRegistry valueResult
Enabled1WinCLAT is permitted, and the setting is under policy control
Disabled0WinCLAT is not permitted, and the setting is under policy control
NotConfiguredDeleted, along with the IPxlatCfgSvc key if it is then emptyThe setting returns to the local configuration

Creating and Assigning the Package

Perform the following steps to create the Remediation in the Microsoft Intune admin center.

  1. Go to Devices > Manage devices > Scripts and remediations, then select Create script package.
  2. Enter a name, such as Enable WinCLAT, and upload the detection and remediation scripts with $DesiredState set to Enabled.
  3. Configure the following settings:
    1. Run this script using the logged-on credentials: No. The scripts write to HKLM and must run as SYSTEM.
    2. Enforce script signature check: No, unless the scripts are signed.
    3. Run script in 64-bit PowerShell: Yes.
  4. Assign the Remediation to a group of devices and choose a schedule. An hourly or daily schedule keeps the value in place if it is removed.
Intune Remediation script package settings

Intune Remediation script configuration settings.

Testing the Remediation on a Single Device

To test the package, open the device’s Overview page in the Intune admin center, select Run remediation, and choose the WinCLAT script package. You can run the package on demand without assigning it to the device. The device must be online, have the Intune Management Extension installed, and be able to communicate with Intune and the Windows Push Notification Service (WNS).

Run remediation action on an Intune device page

Run Remediation interactively on a specific endpoint.

Reviewing Remediation Results in Intune

On the device page in the Intune admin center, select Remediations to review the script package results. In the example below, With issues indicates that the registry state differed from the desired state, and Issue fixed indicates that the script corrected it. Verify the effective permit setting and translation state separately on the client.

Intune device Remediations results showing With issues and Issue fixed

Remediation results.

WinCLAT Activation After Remediation

Applying the permit policy allows Windows to start WinCLAT automatically on eligible interfaces. What happens next depends on whether the interface already has a native IPv4 address and whether Windows can discover a NAT64 prefix.

IPv6-Only Networks

On an IPv6-only test network, WinCLAT begins translating about a minute after the script writes the permit value, without a reboot, Group Policy refresh, or service restart. The instance uses an address from the IPv4 Service Continuity Prefix (RFC 7335), typically 192.0.0.1. Automatic activation requires an eligible interface with a Stateless Address Autoconfiguration (SLAAC) address, a discoverable NAT64 prefix, and autoenable enabled. The policy value persists across reboots.

IPv6-Mostly Networks

On an IPv6-mostly network, Windows already has a DHCPv4 lease when the remediation runs. Neither applying the permit policy nor running ipconfig /renew releases the existing lease. After the adapter restarts, Windows honors DHCPv4 option 108 (IPv6-Only Preferred), comes up without a native IPv4 address, and starts translating within seconds. For a production rollout, let devices reconnect normally or restart the target adapter during a maintenance window. Restarting it interrupts connectivity.

WinCLAT Activation Events

Use the Microsoft-Windows-IPxlatCfg/Operational log to verify that WinCLAT started. Event 1106 (Instance enabled) records why Windows enabled the instance, and Get-WinClatInstance reports that reason in TriggerSource when the event is available. When a new instance starts translating, event 1106 is typically followed by event 1108 (Remote prefix discovered) and event 1109 (Translation started). For more on event 1106 and how to identify the associated network adapter, see Understanding Windows CLAT (WinCLAT) Event Logging.

Event 1109 in the IPxlatCfg Operational log showing that WinCLAT translation started

Event 1109 shows that WinCLAT began translating.

Verifying Policy and Translation

Verify the effective permit setting first, then check whether WinCLAT is translating on the target interface. Use netsh.exe or the WinCLAT PowerShell module for both checks.

Verifying the Effective Permit Setting

Run netsh.exe interface clat show global store=both or Get-WinClatConfiguration -Store Both to compare the active and persistent stores. The active store shows the effective configuration, and the persistent store shows the saved local configuration. In this example, policy enables permit in the active store while the local setting remains disabled. Use the module’s PolicyControlled property to confirm that policy controls Permit, even when both stores report the same value.

Output of netsh interface clat show global store=both

Output of netsh.exe interface clat show global store=both.

Get-WinClatConfiguration -Store Both | Format-List
Output of Get-WinClatConfiguration -Store Both

Output of Get-WinClatConfiguration -Store Both.

Verifying Translation on an Interface

From an elevated command window, run netsh.exe interface clat show instance interface=<index> using the interface index from Get-NetAdapter, and look for Is translating : yes. Alternatively, run Get-WinClatInstance and look for IsTranslating : True on the target interface. The module lists active adapters with IPv6 enabled, so you can run it without supplying an interface index. To verify end-to-end connectivity, test an IPv4-only application or connect to a literal IPv4 address from the target network.

Output of netsh interface clat show instance

Output of netsh.exe interface clat show instance.

Output of Get-WinClatInstance

Output of Get-WinClatInstance.

Removing the WinCLAT Policy

Unassigning the enablement package leaves the policy value in the registry. To restore local control, create a removal package using the same scripts with $DesiredState set to NotConfigured. Use Disabled when you want policy to enforce a disabled permit setting.

Maintaining Intune Connectivity During Removal

Before removing the policy, confirm that the device will still be able to reach Intune if automatic WinCLAT translation stops. A device that relies on WinCLAT to reach IPv4-only Intune endpoints can lose its ability to report the result or receive a recovery package. Use a network with a working path to Intune through native IPv4 or DNS64 and NAT64. On an IPv6-mostly network, check whether the device has a native IPv4 address after removal. Reconnect the adapter if it needs to obtain a new DHCPv4 lease.

Replacing the Enablement Assignment

Before assigning the Remove WinCLAT Policy package, remove the target devices from the enablement assignment. Use a pilot device to confirm that it has received the assignment change and that the enablement package no longer runs on it. After the target devices report successful removal, you can assign the removal package more broadly.

Verifying Policy Removal

Run Get-WinClatConfiguration and confirm that PolicyControlled no longer lists Permit. The effective Permit value should now match the local setting, which is disabled by default. If removal stops an automatically enabled instance, Get-WinClatInstance should report IsTranslating : False for that interface. The operational log may also show event 1110 (Translation stopped) and event 1107 (Instance disabled).

Event 1107 showing that Windows disabled the WinCLAT instance

Event 1107 shows that Windows disabled the WinCLAT instance on the interface.

Get-WinClatConfiguration output showing Permit False and an empty PolicyControlled field

Get-WinClatConfiguration shows Permit=False and an empty PolicyControlled field.

Get-WinClatInstance output showing IsTranslating False

Get-WinClatInstance shows IsTranslating=False.

Limits of Registry-Based Management

The script packages manage the WinCLAT permit policy. Automatic activation, manually enabled instances, and local changes to policy-controlled settings require separate checks.

Automatic Activation

The autoenable setting is enabled by default and has no corresponding WinCLAT Group Policy setting. If an administrator has disabled it, setting PermitNonCellularCLAT to 1 permits WinCLAT but leaves automatic activation disabled. To restore automatic activation, use netsh.exe interface clat set global autoenable=enabled or Set-WinClatConfiguration -AutoEnable Enabled.

Manually Enabled Instances

Disabling Permit stops automatically enabled instances. A manually enabled instance can continue translating until you disable it explicitly or the device reboots. Check the instance state on the target interface if your objective is to stop translation.

Local Changes to Policy-Controlled Settings

When policy controls a WinCLAT setting, netsh.exe interface clat set global can report success and update the local value in the persistent store while the active value continues to follow policy. Use netsh.exe interface clat show global store=active to verify the effective value. If you use Set-WinClatConfiguration to request a value that differs from the effective policy value, the cmdlet reports PolicyOverride.

Using netsh.exe in a Remediation

A Remediation can also run netsh.exe to configure WinCLAT, and this is the only way to enforce autoenable. However, netsh.exe changes the local configuration rather than policy, and reliable detection requires parsing localized command output, so this approach is outside the scope of this post.

Summary

Intune Remediations can deploy and remove the WinCLAT permit policy on Windows 11. Make sure devices can reach Intune before deployment, then verify the effective policy and translation state on the target interface. On IPv6-mostly networks, devices with an existing DHCPv4 lease may need to reconnect before Windows uses WinCLAT. Before removing the policy, confirm that devices will still have a working path to Intune.

Additional Information

WinCLAT resources on directaccess.richardhicks.com

Leave a comment
by Richard M. Hicks on November 9, 2026  •  Permalink
Posted in IPv6, Microsoft Intune, PowerShell, Windows CLAT
Tagged , , , , , , , , , , , ,

Posted by Richard M. Hicks on November 9, 2026

https://directaccess.richardhicks.com/2026/11/09/managing-windows-clat-with-intune-remediations/

Understanding Windows CLAT (WinCLAT) Event Logging

Windows CLAT (WinCLAT) allows IPv4-only applications to continue working on IPv6-only and IPv6-mostly networks by translating their IPv4 traffic to IPv6 for delivery to a NAT64 gateway. When troubleshooting WinCLAT, checking its current state provides only part of the picture. Windows also records events that help administrators understand when WinCLAT was enabled, how it discovered the NAT64 prefix, and when translation started or stopped. This post explains where to find these events, what they mean, and how they can assist with troubleshooting.

Contents

Locating WinCLAT Event Logs

WinCLAT records events in the Microsoft-Windows-IPxlatCfg/Operational event log. In Event Viewer, the log is located under Applications and Services Logs > Microsoft > Windows > IPxlatCfg > Operational Channel. The log is enabled by default.

IPxlatCfg operational event log.

You can also use PowerShell to display the most recent events.

Get-WinEvent -LogName 'Microsoft-Windows-IPxlatCfg/Operational' -MaxEvents 10 | Format-Table -Property TimeCreated, Id, Message -Wrap

Recent WinCLAT events displayed using PowerShell.

Creating a WinCLAT Custom View

To make viewing WinCLAT event log entries easier, I recommend creating a custom view in Event Viewer. To do this, download the WinCLAT Event Viewer XML configuration file here. Next, open Event Viewer (eventvwr.msc) and perform the following steps.

  1. Right-click Custom Views and choose Import Custom View.
  2. Select the winclat-event.xml file downloaded previously and click Open.
  3. Review the Name and Description of the Custom View and click OK.
  4. Click OK.

WinCLAT events displayed in an Event Viewer custom view.

WinCLAT Event ID Reference

The following table shows the WinCLAT event IDs.

Event IDDescriptionWhen it is recorded
1106Instance enabledCLAT is enabled on an interface, automatically or manually
1107Instance disabledCLAT is disabled on an interface
1108Remote prefix discoveredCLAT discovers the NAT64 prefix for an interface
1109Translation startedCLAT begins translating on an interface
1110Translation stoppedCLAT stops translating on an interface
1111CLAT IPv6 address DAD failureThe CLAT IPv6 address fails duplicate address detection

Event ID 1106: Instance Enabled

Description: WinCLAT has been enabled on an interface. The event includes the trigger source, which identifies why WinCLAT was enabled, and the interface LUID.

When it is recorded: When WinCLAT is enabled on an interface, either automatically by Windows or manually by an administrator. The trigger source is one of the following.

CodeTrigger sourceMeaning
1Pref64 RAEnabled automatically because the network’s router advertisements include the PREF64 option
3No IPv4Enabled automatically because the interface has no IPv4 connectivity
5ManualEnabled manually with netsh.exe interface clat set instance interface=<ifIndex> state=enabled

Identifying the Trigger Source and Network Adapter

The event includes the trigger source, which identifies why WinCLAT was enabled, and the interface’s locally unique identifier (LUID). The interface LUID matches the NetLuid property returned by Get-NetAdapter. The following PowerShell commands list each event 1106 with its trigger source and adapter name.

$Adapters = @{}
Get-NetAdapter | ForEach-Object -Process { $Adapters[[uint64]$_.NetLuid] = $_.Name }
Get-WinEvent -FilterHashtable @{ LogName = 'Microsoft-Windows-IPxlatCfg/Operational'; Id = 1106 } |
    Select-Object -Property TimeCreated,
        @{ Name = 'TriggerSource'; Expression = { Switch ($_.Properties[0].Value) { 1 { 'Pref64 RA' } 3 { 'No IPv4' } 5 { 'Manual' } Default { "Unknown ($_)" } } } },
        @{ Name = 'Interface'; Expression = { $Adapters[[uint64]$_.Properties[1].Value] } }

Event ID 1107: Instance Disabled

Description: WinCLAT has been disabled on an interface.

When it is recorded: When WinCLAT is disabled on an interface. This can happen in any of the following cases.

  • AutoEnable is disabled (netsh.exe interface clat set global autoenable=disabled) or Permit is disabled (netsh.exe interface clat set global permit=disabled). Both settings disable any automatically enabled instances.
  • A manually enabled instance is disabled with netsh.exe interface clat set instance interface=<ifIndex> state=disabled.
  • The network adapter of an automatically enabled instance is restarted.

Event ID 1108: Remote Prefix Discovered

Description: WinCLAT has discovered the NAT64 prefix used for translation. The event includes the discovery source, prefix, prefix length, and prefix lifetime (seconds). The source is one of the following:

  • RA – The prefix was obtained from the PREF64 option in IPv6 router advertisements (RFC 8781).
  • DNS – The prefix was obtained by querying ipv4only.arpa against a DNS64 server (RFC 7050).

When it is recorded: When WinCLAT discovers the NAT64 prefix for an interface (normally following event 1106) and when a prefix discovered through DNS is refreshed at the end of its lifetime.

Event ID 1109: Translation Started

Description: WinCLAT has started translating IPv4 traffic on an interface. The event includes the remote prefix (NAT64 prefix), the CLAT (synthetic) IPv6 address, and the CLAT (synthetic) IPv4 address, which is assigned from the IPv4 Service Continuity Prefix 192.0.0.0/29 (RFC 7335), typically 192.0.0.1.

When it is recorded: When translation begins on an interface, which normally follows events 1106 and 1108, and when Windows restarts translation on an interface that remains enabled, such as after a network adapter restart.

Event ID 1110: Translation Stopped

Description: WinCLAT has stopped translating IPv4 traffic on an interface.

When it is recorded: When translation ends on an interface. It precedes event 1107 when an instance is disabled, and it is also recorded when Windows restarts translation on an interface that remains enabled. In that case, it is followed by event 1109.

Event ID 1111: WinCLAT IPv6 Address DAD Failure

Description: The WinCLAT IPv6 address failed duplicate address detection (DAD), meaning another node on the network is already using the address.

When it is recorded: When Windows generates a CLAT IPv6 address for an interface and duplicate address detection reports a conflict.

WinCLAT Event Logging Limitations

WinCLAT events describe changes to an instance’s state, but they do not identify the applications using WinCLAT or the destination IPv4 addresses those applications access. Administrators can use Sysmon to collect this additional information. See How to Identify Applications That Use Windows CLAT (WinCLAT) with Sysmon for more details.

Summary

WinCLAT event logging helps administrators understand how WinCLAT operates on individual network interfaces. The events record instance enablement and disablement, NAT64 prefix discovery, translation activity, and address conflicts. Reviewing this history alongside the current WinCLAT configuration and interface state provides a clearer picture when troubleshooting. For visibility into the applications and destination addresses associated with WinCLAT traffic, administrators can supplement these events with Sysmon.

Additional Information

Windows CLAT (WinCLAT) PowerShell Module on GitHub.com

Troubleshooting Windows CLAT (WinCLAT) with the WinCLAT PowerShell Module

Windows CLAT (WinCLAT) Frequently Asked Questions (FAQ)

WinCLAT resources at directaccess.richardhicks.com

Leave a comment
by Richard M. Hicks on November 5, 2026  •  Permalink
Posted in IPv6, PowerShell, Windows CLAT
Tagged , , , , , , , , , ,

Posted by Richard M. Hicks on November 5, 2026

https://directaccess.richardhicks.com/2026/11/05/understanding-windows-clat-winclat-event-logging/

How to Identify Applications That Use Windows CLAT (WinCLAT) with Sysmon

Windows CLAT (WinCLAT) allows applications that use IPv4 sockets or literal IPv4 addresses to continue working on IPv6-only and IPv6-mostly networks by translating their IPv4 traffic to IPv6 for delivery to a NAT64 gateway. For administrators planning an IPv6-only deployment, this raises an obvious question: which applications still depend on IPv4 and are using WinCLAT?

Application Visibility

WinCLAT’s built-in logging does not identify the applications using it. This post explains how to use Microsoft Sysinternals Sysmon to record the executable, user account, and destination associated with IPv4 connections that use the WinCLAT source address. It also describes the filtering requirements and limitations of this approach. The behavior described applies to Sysmon 15.22. Later versions may differ.

What WinCLAT Logs

WinCLAT records events in the Microsoft-Windows-IPxlatCfg/Operational event log, but those events describe the WinCLAT instance on each interface, not the traffic passing through it.

Event IDDescription
1106Instance enabled
1107Instance disabled
1108Remote prefix discovered
1109Translation started
1110Translation stopped
1111WinCLAT IPv6 address DAD failure

No event identifies the application that used WinCLAT or the destination it connected to. The netsh.exe interface clat commands report the same kind of instance and configuration state. As a result, WinCLAT can translate traffic on an interface with no built-in record of what generated it.

Logging WinCLAT Connections with Sysmon

Sysmon is a Microsoft Sysinternals tool that runs as a Windows service and logs detailed system activity, including process creation, network connections, and file changes, to the Windows Event Log. Sysmon can be configured specifically to log network traffic generated by WinCLAT.

Identifying WinCLAT Traffic in Event ID 3

Sysmon Event ID 3 (Network connection) logs TCP and UDP connections and links each one to a process. When an application uses WinCLAT, its socket is still an IPv4 socket, so the event shows the application’s IPv4 addresses rather than the translated IPv6 addresses:

  • Calling executable and account – Image, ProcessId, ProcessGuid, and User
  • Destination – DestinationIp, DestinationPort, and Protocol
  • WinCLAT source address – SourceIp

The source address is what makes this useful. While WinCLAT is active, it assigns the interface an IPv4 address from the IPv4 Service Continuity Prefix 192.0.0.0/29 (RFC 7335), typically 192.0.0.1. Filtering on that source separates traffic that uses WinCLAT from other network activity. Traffic that uses a native IPv4 route has a different source address, and traffic from applications that use IPv6 directly, including through DNS64 and NAT64, is not IPv4 traffic and does not match.

Preparing the WinCLAT Filter

Network connection events are disabled by default, so Sysmon requires a configuration file to enable them. Save the following as sysmon-winclat.xml, or download it from GitHub here.

<Sysmon schemaversion="4.82">
  <DnsLookup>False</DnsLookup>
  <EventFiltering>
    <NetworkConnect onmatch="include">
      <SourceIp condition="is any">192.0.0.1;192.0.0.2;192.0.0.3;192.0.0.4;192.0.0.5;192.0.0.6;192.0.0.7</SourceIp>
    </NetworkConnect>
    <NetworkConnect onmatch="exclude">
      <DestinationIp condition="begin with">224.</DestinationIp>
      <DestinationIp condition="begin with">239.</DestinationIp>
      <DestinationIp condition="is">255.255.255.255</DestinationIp>
      <DestinationIp condition="is any">192.0.0.0;192.0.0.1;192.0.0.2;192.0.0.3;192.0.0.4;192.0.0.5;192.0.0.6;192.0.0.7</DestinationIp>
    </NetworkConnect>
    <ProcessCreate onmatch="include" />
    <FileCreateTime onmatch="include" />
    <ProcessTerminate onmatch="include" />
    <DriverLoad onmatch="include" />
    <RawAccessRead onmatch="include" />
  </EventFiltering>
</Sysmon>

The configuration does the following.

  • Includes connections with a source address in the WinCLAT range. A computer with several translating interfaces uses a different address on each one.
  • Excludes multicast and broadcast destinations, and destinations in the WinCLAT range itself. Local protocols such as LLMNR and NetBIOS can use the WinCLAT IPv4 address, but this traffic is not destined for NAT64. A source address in the WinCLAT range therefore does not by itself prove that a packet was translated.
  • Disables reverse DNS lookups with DnsLookup. A reverse lookup would add unnecessary queries, and its result would not show the name the application requested anyway.
  • Turns off other default event types with empty include rules. Without these rules, Sysmon also logs events such as process creation and termination, which are unrelated to WinCLAT and can far outnumber the network connection events. Sysmon still logs its service state and configuration change events, which cannot be filtered.

Turning off process creation events removes the command line and parent process from the log. To keep that context for investigations, remove the ProcessCreate rule and accept the additional volume. See the Sysmon documentation for more filtering options.

Installing and Configuring Sysmon

Sysmon is available natively in Windows 11 since February, 2026, but it is not installed by default. Administrators can install it by navigating to Settings > System > Optional features > More Windows features and selecting Sysmon.

Optionally, administrators can install Sysmon by opening an elevated PowerShell command window and running the following command.

Enable-WindowsOptionalFeature -Online -FeatureName Sysmon

For Windows versions that don’t include Sysmon, administrators can download Sysmon from the Sysinternals website.

Applying the WinCLAT Filter

After installing Sysmon, open an elevated command window and install it with the configuration file by running the following command.

sysmon.exe -i sysmon-winclat.xml

To apply a changed configuration to a computer where Sysmon is already installed, use -c.

sysmon.exe -c sysmon-winclat.xml

Reading Sysmon Events

Events are recorded in the Microsoft-Windows-Sysmon/Operational log.

Sysmon event log indicating the calling application.

Sysmon event log indicating the source and destination IPv4 addresses used by the calling application.

Viewing Recent Events with PowerShell

Run the following command to display the time and message for up to 20 of the most recent Sysmon Event ID 3 records.

Get-WinEvent -FilterHashtable @{ LogName = 'Microsoft-Windows-Sysmon/Operational'; Id = 3 } -MaxEvents 20 | Format-List -Property TimeCreated, Message

Sysmon event log details viewed using PowerShell.

The example above shows several fields of interest for a TCP connection to an IPv4 address through WinCLAT.

Network connection detected:
ProcessId: 10536
Image: C:\Tools\putty.exe
User: LAB\rhicks
Protocol: tcp
Initiated: true
SourceIsIpv6: false
SourceIp: 192.0.0.1
SourcePort: 50935
DestinationIsIpv6: false
DestinationIp: 172.16.0.254
DestinationPort: 22

Listing Applications and User Accounts

To produce a list of the applications and destinations recorded on a computer, read the values from the event data and remove the duplicates.

Get-WinEvent -FilterHashtable @{ LogName = 'Microsoft-Windows-Sysmon/Operational'; Id = 3 } |
    Select-Object -Property @{ Name = 'Image'; Expression = { $_.Properties[4].Value } },
        @{ Name = 'User'; Expression = { $_.Properties[5].Value } } |
    Sort-Object -Property Image, User -Unique |
    Format-Table -AutoSize

This query includes all retained Event ID 3 records, including events collected before the WinCLAT configuration was applied.

Unique application and user account combinations recorded by Sysmon.

To report across many computers, collect the events centrally with Windows Event Forwarding or a SIEM agent.

Interpreting the Results

Sysmon Event ID 3 records different information depending on the protocol and whether the connection succeeds. The table below shows which types of traffic can produce an event and what each record tells you about the connection.

Traffic through WinCLATRecorded by Event ID 3What an event means
TCP connectionYesThe connection was established
TCP attempt with no responseMay not be recordedNot applicable
UDPYes, with or without a replyThe application attempted to send, not that the traffic was delivered
ICMPNoNot applicable

Limitations of Event ID 3

Use these events to identify which processes communicate with IPv4 destinations. When reviewing the results, keep in mind that some activity may be missing and that the recorded fields provide limited information about the application’s behavior.

  • ICMP is not recorded. Event ID 3 covers TCP and UDP only, so ping to an IPv4 address leaves no event.
  • Failed TCP attempts can be missed. An application that repeatedly tries to reach an unresponsive IPv4 address may not appear in the log. This matters because unreachable destinations through WinCLAT time out rather than failing immediately.
  • Events show WinCLAT use, not literal use. An application that resolves a name to an IPv4 address and connects with an IPv4 socket produces the same event as an application that uses a literal IPv4 address. The destination is the resolved address in both cases, so Sysmon cannot confirm that an address is hard-coded. Sysmon Event ID 22 (DNS query) can provide supporting context, because it identifies the process that made a query, but the absence of a matching query is not proof of a literal. The configuration above does not log this event, so collecting it requires adding a DnsQuery rule.
  • Event counts are not traffic counts. Sysmon does not record one event per packet or per flow, so several UDP sends on one socket can produce a different number of events. Use the events to identify which applications communicate with which destinations, not to measure traffic volume.
  • Shared processes hide the service. Traffic from a Windows service can appear with an Image of svchost.exe. Use the ProcessId to identify the service while the process is still running.
  • Native IPv4 is excluded. On a computer with native IPv4 connectivity, some connections may use a native IPv4 source address instead of the WinCLAT source address. Those connections do not match this filter and are not included in the results.

Additional Troubleshooting Tools

If traffic that Sysmon does not record becomes important, such as ICMP or failed connection attempts, the following sources may help. Each has its own trade-offs, so evaluate them in your environment.

  • Windows Filtering Platform auditing. The Filtering Platform Connection audit subcategory records permitted and blocked connections in the Security event log as events 5156 and 5157, including the application where available. It can generate a high volume of events.
  • Packet capture. A capture on the physical adapter with a tool such as pktmon.exe can show translated IPv6 traffic, including ICMP and unanswered connection attempts. The IPv4 destination is embedded in the destination address under the NAT64 prefix. Packet headers alone do not identify the calling executable, so process attribution requires additional correlation.
  • NAT64 gateway logs. Depending on the gateway, its logs can show the client and destination of translated traffic, but not the application.

Summary

WinCLAT logs instance state changes but does not identify the applications using it. Sysmon Event ID 3, filtered on WinCLAT source addresses and with common local traffic excluded, provides a practical way to identify applications likely using WinCLAT. The events record the executable, user account, destination address, and port for matching TCP and UDP connections. They do not cover ICMP, may omit failed TCP attempts, and cannot distinguish a literal IPv4 address from an address obtained through name resolution. Use the results to identify applications for further investigation and confirm translation with a packet capture when needed.

Additional Information

Sysmon XML Configuration File for WinCLAT Tracing on GitHub

WinCLAT resources on directaccess.richardhicks.com

Leave a comment
by Richard M. Hicks on November 3, 2026  •  Permalink
Posted in IPv6, Windows CLAT
Tagged , , , , , , , ,

Posted by Richard M. Hicks on November 3, 2026

https://directaccess.richardhicks.com/2026/11/03/how-to-identify-applications-that-use-windows-clat-winclat-with-sysmon/

Troubleshooting Windows CLAT (WinCLAT) with the WinCLAT PowerShell Module

Windows CLAT (WinCLAT) is generally available on Windows 11 25H2, starting with build 26200.9550. WinCLAT is the Windows client-side translator for 464XLAT (RFC 6877). It translates IPv4 traffic from applications into IPv6 for delivery to a NAT64 gateway, allowing IPv4-only applications to continue working on IPv6-only and IPv6-mostly networks. Successful operation depends on both the Windows client configuration and the supporting network infrastructure. This post explains how to use the WinCLAT PowerShell module to verify these requirements, diagnose common problems, and test IPv4 connectivity through the translation path.

Why Use the WinCLAT PowerShell Module

WinCLAT is configured and inspected using the netsh.exe interface clat command context. However, its output requires careful interpretation when troubleshooting. A configuration command can complete without error even when Group Policy prevents the requested setting from taking effect. An instance can report that it is translating while IPv4 traffic fails, and disabling a global setting does not necessarily stop a manually enabled instance. The WinCLAT PowerShell module simplifies these tasks by checking the effective configuration after changes and providing health checks with explanations and recommended corrective actions. It supports troubleshooting on individual computers and across multiple remote computers.

How WinCLAT Activates

Understanding when WinCLAT activates automatically helps explain many troubleshooting scenarios. With AutoEnable enabled, Windows automatically activates WinCLAT on eligible non-cellular interfaces when the following conditions are met.

  • WinCLAT is permitted. The Permit setting is enabled. Today, it is disabled by default in Windows.
  • The interface has an IPv6 address assigned using Stateless Address Autoconfiguration (SLAAC) and an IPv6 default route.
  • The interface has no native IPv4 connectivity. On an IPv6-mostly network, DHCPv4 option 108, called IPv6-Only Preferred (RFC 8925), tells a compatible client to operate without a native IPv4 address for the period specified by the DHCPv4 server. WinCLAT provides IPv4 application connectivity over IPv6 during that time.
  • A NAT64 prefix has been discovered, either from the PREF64 option in router advertisements (RFC 8781) or by querying ipv4only.arpa for AAAA records through a DNS64 server (RFC 7050). DNS64 is required for the DNS-based discovery method but is not required when WinCLAT discovers the prefix through PREF64.

NAT64 Gateway Requirements

Successful IPv4 connectivity through WinCLAT also requires a reachable NAT64 gateway configured to translate traffic using the discovered prefix. Discovering a prefix and activating WinCLAT do not confirm that the gateway is reachable or that traffic can pass through it.

Automatic and Manual Activation

AutoEnable is enabled by default and allows Windows to activate WinCLAT automatically when an interface meets the required conditions. Manually enabled instances behave differently, as described later in this post. WinCLAT can be enabled manually on a specific interface after automatic activation is disabled. When WinCLAT is translating, Windows assigns the interface an IPv4 address from the 192.0.0.0/29 IPv4 Service Continuity Prefix (RFC 7335) and adds an IPv4 default route through WinCLAT.

Installing the Module

The WinCLAT module is available in the PowerShell Gallery and runs on Windows PowerShell 5.1 and PowerShell 7. Run the following command to install the module.

Install-Module -Name WinCLAT -Scope CurrentUser

The module is needed only on the computer running the commands. Remote computers require WinRM, and commands that read interface state or change configuration require an elevated session on the target.

Step 1: Run Test-WinCLAT

Test-WinClat is the starting point for any WinCLAT problem. Run it from an elevated session so the interface checks can run.

Test-WinClat

The summary shows the overall result (Pass, Warning, Fail, or NotApplicable), whether any interface is translating, and the checks that returned a warning or failure. Individual checks can also return Info for conditions that do not affect the overall result. To display every check and its explanation, use -Detailed with Format-List.

Test-WinClat -Detailed | Format-List -Property Check, InterfaceAlias, Result, Detail

To show only the checks that need attention, including recommended corrective actions, run the following command.

Test-WinClat -Detailed | Where-Object -FilterScript { $_.Result -in 'Fail', 'Warning' } | Format-List -Property Check, InterfaceAlias, Detail, Remediation

Test-WinClat Tests

The following is a list of checks that Test-WinClat performs.

TestWhat it verifies
Feature presentThe clat netsh.exe context exists on the computer
CLAT permittedPermit is enabled in the active (effective) configuration
Prefix discovery validAt least one of Pref64FromRA and Pref64FromDns is enabled
Policy overrideGroup Policy is not overriding the local configuration
SLAAC addressThe interface has an IPv6 address from SLAAC
IPv6 default routeThe interface has an IPv6 default route
Native IPv4The interface has no native IPv4 address
Instance activeWinCLAT is translating when its prerequisites are met
CLAT addressThe WinCLAT IPv6 address is assigned to the interface and on its current prefix
Prefix consistencyThe NAT64 prefix matches the prefix returned by DNS64, when DNS64 is available
Mode sanityWinCLAT can activate: AutoEnable is enabled, or an instance has been enabled manually
Functional testIPv4 traffic passes through WinCLAT (optional)

Global checks do not require elevation. Interface checks are skipped, rather than failed, when the session is not elevated. Results of Info are informational and do not affect the overall result.

Step 2: Inspect the Configuration

Get-WinClatConfiguration returns the global settings. Use -Store Both to compare the active (effective) configuration with the persistent (local) configuration.

Get-WinClatConfiguration -Store Both

Compare the active configuration with the persistent configuration to identify differences between the effective settings and the locally stored settings. Use the PolicyControlled property to identify settings controlled by Group Policy. This property also identifies policy-controlled settings whose effective values match the local values, which a comparison of the two stores alone would not reveal.

Step 3: Inspect the Instances

Get-WinClatInstance returns the WinCLAT state of each IPv6-enabled interface. It requires elevation.

Get-WinClatInstance

Two properties are particularly useful when troubleshooting:

  • Mode shows whether the instance was enabled Automatically by Windows or Manually by an administrator.
  • TriggerSource shows why the instance was enabled: Pref64 RA (the network advertises PREF64), No IPv4 (the interface has no IPv4 connectivity), or Manual. It is read from event 1106 in the Microsoft-Windows-IPxlatCfg/Operational event log.

Common Problems

The following are common problems associated with WinCLAT configuration and operation.

Feature Not Present

Get-WinClatConfiguration returns Status FeatureNotAvailable, and Test-WinClatfails the Feature present check. WinCLAT is generally available on Windows 11 25H2 build 26200.9550 and later. The OSBuild property shows each computer’s build number, making it easy to identify computers that need the latest cumulative update.

WinCLAT is not available on Windows Server. Servers return Status NotSupported, and Test-WinClat reports an overall result of NotApplicable.

WinCLAT Not Permitted

Permit is disabled by default, so WinCLAT does not activate automatically on Wi-Fi or Ethernet interfaces until Permit is enabled, either locally or through Group Policy. Test-WinClat fails the CLAT permitted check only when an interface is IPv6-only and could use WinCLAT. On a dual-stack network, the check is informational because WinCLAT would not be used there anyway.

With AutoEnable enabled, WinCLAT activates on eligible interfaces as soon as Permit is enabled.

DHCPv4 Option 108

Permit also affects DHCPv4 option 108. Windows honors option 108 only while WinCLAT is permitted. With Permit disabled, a client on an IPv6-mostly network accepts a DHCPv4 lease and uses native IPv4, so WinCLAT is not needed, and the CLAT permitted check is informational.

WinCLAT Not Active on Dual-Stack Network

This is expected. WinCLAT does not activate on an interface with native IPv4. Test-WinClatreports Native IPv4 and Instance active as Info on dual-stack interfaces. If a dual-stack interface has no SLAAC address or no IPv6 default route, as on a network that assigns IPv6 addresses with DHCPv6 only, those checks are also Info rather than Fail, because they matter only if the network becomes IPv6-only.

SLAAC Addressing Not Present

WinCLAT requires an IPv6 address configured using SLAAC. An interface whose IPv6 addresses are assigned only through DHCPv6 does not meet this requirement. DHCPv6 can still provide other configuration information, such as DNS server addresses and a domain search list. Test-WinClat checks for a SLAAC address and reports when an interface that needs WinCLAT does not have one.

Group Policy Overrides Local Configuration

Netsh.exe reports success when a local change is made to a setting that Group Policy controls, but the effective value does not change. Set-WinClatConfiguration reads the configuration back after every change and reports the result with Status PolicyOverride when the policy keeps a different value.

In addition, Test-WinClat indicates when local settings conflict with Group Policy enforced settings.

Group Policy can control Permit, Pref64FromRA, and Pref64FromDns. There is no policy for AutoEnable. The policy values are stored in the following registry location.

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

No NAT64 Prefix Discovered

An instance that is enabled but has no NAT64 prefix cannot translate. Test-WinClat fails the Instance active check and names the prefix discovery methods that are enabled. Common causes include:

  • The network does not include the PREF64 option in router advertisements, and Pref64FromDns is disabled.
  • No usable NAT64 prefix is available through router advertisements, and Pref64FromDns is enabled, but the DNS servers assigned to the client do not provide DNS64.
  • Both Pref64FromRA and Pref64FromDns are disabled. Netsh.exe accepts this combination silently, but WinCLAT can never activate. Set-WinClatConfiguration refuses it.

When WinCLAT discovers a NAT64 prefix through the PREF64 option in router advertisements, DNS64 is not required for prefix discovery or for translating IPv4 application traffic. A reachable NAT64 gateway using that prefix is still required. If DNS64 is unavailable, the Prefix consistency check is informational because there is no DNS64-derived prefix to compare.

Delayed WinCLAT Activation

WinCLAT activates fastest when the network advertises the NAT64 prefix through PREF64. When DNS64 is the only available prefix discovery method, Windows first waits to determine that the interface has no native IPv4 connectivity, so activation takes several seconds longer. Allow time for this process before treating an inactive instance as a configuration problem.

Manually Enabled Instances Continue Translating

Disabling Permit or AutoEnable stops translation on instances that Windows enabled automatically. Manually enabled instances can continue translating after either setting is disabled. When troubleshooting continued translation, check the instance’s Mode property to determine whether it was enabled manually.

Use Get-WinClatInstance to identify manually enabled instances.

Get-WinClatInstance | Where-Object -FilterScript { $_.Enabled -and $_.Mode -eq 'Manual' }

Note that netsh.exe refuses to change an instance while AutoEnable is enabled. To return an interface from manual to automatic control, disable AutoEnable, disable the instance, and enable AutoEnable again:

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

WinCLAT Stops Working After Reboot

Manual instance state is runtime only. It survives an adapter restart and link loss, but it is lost on reboot. Enabling an instance manually requires disabling AutoEnable, and AutoEnable remains disabled after the reboot, so WinCLAT does not activate at all. Enable AutoEnable again to restore automatic operation:

Set-WinClatConfiguration -AutoEnable Enabled

The Mode sanity check in Test-WinClat reports this condition.

IPv4 Fails After Moving to a Different Network

When a translating client moves to a different IPv6 network without restarting its network adapter, WinCLAT keeps its IPv6 address on the previous network’s prefix. The instance still reports that it is translating, but IPv4 traffic through WinCLAT fails. Microsoft has acknowledged this known issue and is working to resolve it in a future release.

Test-WinClat detects this condition. The CLAT address check fails, naming the address in use and the current prefix, while the Instance active check passes.

Restarting the network adapter resolves the issue.

Restart-NetAdapter -Name 'Ethernet'

The IPv6 address reported by netsh.exe interface clat show instance cannot be used to detect this condition, because it may report a new address that is not actually assigned to the interface. The CLAT address check compares the addresses actually assigned to the adapter with its current prefix.

Netsh.exe Reports Addresses That Are Not Assigned

An instance that is enabled but no longer translating can retain stale information in netsh.exe output. For example, a manually enabled instance on an interface that now has native IPv4 connectivity might still report a WinCLAT IPv6 address and 192.0.0.1 even though those addresses are no longer assigned to the interface. It might also display a NAT64 prefix with a remaining lifetime of zero. Use Get-NetIPAddress to confirm the addresses assigned to the interface. Clear the manual instance using the three-command sequence shown earlier or restart the computer.

Testing the Translation Path

The checks above assess WinCLAT configuration and local instance state. The functional test verifies connectivity to a specific IPv4 destination through WinCLAT and the NAT64 gateway. Use Test-WinClat with an IPv4 target address that is reachable through the gateway and known to respond to the selected test.

Test-WinClat -IPv4Target 172.16.0.204 -Detailed | Format-Table -Property Check, InterfaceAlias, Result, Detail -Wrap

The test sends up to three ICMP echo requests. Add -IPv4Port to test a TCP connection instead, which is useful where ICMP is filtered.

Test-WinClat -IPv4Target 172.16.0.204 -IPv4Port 443

Keep the following in mind when interpreting the result.

  • Use an IPv4 address as the target. A hostname can resolve to a synthesized AAAA record through DNS64, allowing the connection to use IPv6 through NAT64 without using WinCLAT. Testing with an IPv4 address ensures the test uses IPv4. Check the selected interface and source address to confirm that the traffic passes through WinCLAT.
  • Native IPv4 can bypass WinCLAT. If another interface provides native IPv4 connectivity to the test destination, Windows might send the test traffic through that interface. The module reports Info when the selected path bypasses WinCLAT, even if the destination responds successfully. Review the Detail property to identify the selected interface and source address and confirm whether the test used WinCLAT.
  • Unreachable destinations time out. ICMP destination unreachable messages that NAT64 returns for IPv4 destinations are not delivered to the IPv4 application, so a test to an unreachable or filtered address returns a Warning after timing out rather than an immediate failure. Choose a target that is known to respond, ideally on your own infrastructure.
  • One test covers one path. When several interfaces translate, the test proves that IPv4 works through the interface Windows chose, not on each interface.

Troubleshooting at Scale

The WinCLAT commands accept computer names from the pipeline, including input from Get-Content and Get-ADComputer, and process remote computers in parallel over WinRM. Before connecting, the module checks TCP port 5985. If that connection fails, it reports the computer as Unreachable without waiting for a full WinRM timeout. This status indicates that the module could not reach the required endpoint. The computer might be offline, the port might be blocked, or WinRM might be configured to use a different TCP port.

Filtering and Exporting Results

The module returns a result for every target computer, including those that cannot be reached, do not support the feature, or cannot be fully checked because the session lacks elevation. The Status property identifies the outcome, and the Message property explains it.

# Test every computer in an OU and show only the computers with problems
Get-ADComputer -Filter * -SearchBase 'OU=Windows Clients,DC=corp,DC=example,DC=net' | Test-WinClat | Where-Object -FilterScript { $_.Overall -ne 'Pass' }
# Export the detailed results of every check for later analysis
Get-Content -Path .\clients.txt | Test-WinClat -Detailed | Export-Csv -Path .\winclat-results.csv -NoTypeInformation
# Save the names of unreachable computers to test again later
Get-Content -Path .\clients.txt | Test-WinClat | Where-Object -FilterScript { $_.Status -eq 'Unreachable' } | Select-Object -ExpandProperty ComputerName | Set-Content -Path .\retry.txt

The output is flat, so it exports cleanly with Export-Csv for reporting and comparison over time.

Known Issues

The following Windows behaviors can affect WinCLAT operation and troubleshooting. The module can identify some of these conditions, but it does not correct the underlying Windows behavior. Available workarounds are listed below.

IssueEffectWorkaround
WinCLAT keeps its IPv6 address on the previous prefix after a network changeIPv4 traffic through WinCLAT fails; Test-WinClat reports CLAT address FailRestart the network adapter
WinCLAT IPv4 address is dynamically registered in DNSConnections to the client may fail when DNS resolves its name to a WinCLAT IPv4 addressNone
Translated ICMP errors are not delivered to IPv4 applicationsUnreachable IPv4 destinations time out instead of failing immediatelyNone

Summary

Troubleshooting WinCLAT starts with Test-WinClat, which checks every prerequisite, explains each failure, and suggests remediation. Get-WinClatConfiguration reveals Group Policy overrides, and Get-WinClatInstance shows whether each instance was enabled automatically or manually. Most problems come down to a few causes: Permit disabled by default, Group Policy overriding local settings, no NAT64 prefix discovered, a manual instance that does not follow the global settings, or a stale WinCLAT address after a network change. Because netsh.exe reports success even when a change does not take effect, always verify the result by reading the state back, which the WinCLAT module does automatically.

Additional Information

WinCLAT PowerShell Module on GitHub

WinCLAT on directaccess.richardhicks.com

6 Comments
by Richard M. Hicks on November 2, 2026  •  Permalink
Posted in IPv6, PowerShell, Windows CLAT, Windows Server
Tagged , , , , ,

Posted by Richard M. Hicks on November 2, 2026

https://directaccess.richardhicks.com/2026/11/02/troubleshooting-windows-clat-winclat-with-the-winclat-powershell-module/

Introducing the WinCLAT PowerShell Module

Windows CLAT (WinCLAT) is now generally available, and many organizations are beginning to evaluate it in their IPv6-mostly and IPv6-only environments. I’ve written extensively about WinCLAT recently, including how it works, when to use it, and how it discovers the NAT64 prefix. Today, I’m pleased to announce the release of the WinCLAT PowerShell module, a free, open-source tool that makes managing, reporting on, and troubleshooting WinCLAT much easier, especially at scale.

Background

Today, WinCLAT is configured and managed using the netsh.exe.exe interface clat command context. While netsh.exe works well enough on a single computer, it has some notable limitations. Its output is plain text, which is difficult to filter, sort, or export. It also provides no built-in way to collect information from many computers at once. And, in some cases, netsh.exe reports success even when Group Policy overrides the change, which can be misleading.

The WinCLAT PowerShell module addresses these challenges. It wraps netsh.exe and returns structured objects to the pipeline, so administrators can work with WinCLAT the same way they work with any other PowerShell command. Every function runs against the local computer or against many remote computers in parallel using WinRM.

Key Features

Version 1.0 of the WinCLAT PowerShell module includes the following capabilities.

  • Fleet-wide reporting. Every function accepts computer names directly, from a text file using Get-Content, or from Get-ADComputer. Results include one row for every computer, including those that are offline, do not have the feature, or are not elevated. It detects unreachable computers in about two seconds rather than waiting for a WinRM timeout.
  • Health checks with remediation. Test-WinClat checks the global configuration and every IPv6-enabled interface, explains each warning and failure, and optionally validates the CLAT path end to end.
  • Safe configuration changes. Set-WinClatConfiguration refuses changes that would prevent CLAT from ever activating, reads back every change to detect Group Policy overrides, and prompts for confirmation before any change that stops CLAT.
  • Baselines. Export and import the WinCLAT configuration or reset computers to the Windows defaults.
  • Structured output. Every function returns flat objects that can be filtered, sorted, and exported to CSV.

Every result includes a Status property (Success, Unreachable, FeatureNotAvailable, NotSupported, ElevationRequired, PolicyOverride, or Failed) and a Message property that explains anything other than Success.

Requirements

The WinCLAT PowerShell module has the following requirements.

  • Windows PowerShell 5.1 or PowerShell 7 on the computer running the commands.
  • Windows 11 25H2 build 26200.9550 or later on target computers. WinCLAT is not available on Windows Server.
  • WinRM enabled on remote target computers.
  • Administrative privileges on target computers for Get-WinClatInstance, the Set, Import, and Reset functions, and the interface checks performed by Test-WinClat. Get-WinClatConfiguration and Export-WinClatConfiguration do not require elevation.
  • English (en-US) netsh.exe output on target computers.

Installation

The WinCLAT module is available in the PowerShell Gallery. To install it, open an elevated PowerShell window and run the following command.

Install-Module -Name WinCLAT

The module needs to be installed only on the computer where the commands are run. It is not required on target computers. To update to the latest release, run the following command.

Update-Module -Name WinCLAT

Once installed, run the following command to view the available functions.

Get-Command -Module WinCLAT

The source code is also available on GitHub.

Functions

The WinCLAT PowerShell module includes the following functions.

FunctionDescription
Get-WinClatConfigurationReturns the global WinCLAT configuration
Get-WinClatInstanceReturns the WinCLAT state of each network interface
Test-WinClatDiagnoses WinCLAT readiness and operation
Set-WinClatConfigurationChanges the global WinCLAT configuration
Set-WinClatInstanceManually enables or disables WinCLAT on an interface
Export-WinClatConfigurationSaves the WinCLAT configuration to a file
Import-WinClatConfigurationApplies a saved WinCLAT configuration
Reset-WinClatConfigurationReturns the WinCLAT configuration to the Windows defaults

Every function accepts the -ComputerName, -Credential, and -ThrottleLimit parameters. The -ComputerName parameter accepts pipeline input, including output from Get-Content and Get-ADComputer. Blank lines and lines beginning with # are ignored, so a simple text file of computer names works without modification. The default -ThrottleLimit is 32 concurrent connections.

Get-WinClatConfiguration

The Get-WinClatConfiguration function returns the global WinCLAT settings: Permit, Pref64FromDns, Pref64FromRA, and AutoEnable. By default, it returns the active (effective) configuration. Use the -Store parameter to view the persistent (local) configuration, or both. Comparing the two is helpful for identifying settings controlled by Group Policy. The output also includes the OS build number, which is useful for tracking which computers have received the feature.

Get-WinClatConfiguration -Store Both

Get-WinClatInstance

The Get-WinClatInstance function returns the WinCLAT state for each active network interface with IPv6 enabled. The output shows whether the interface is translating, the NAT64 prefix and its remaining lifetime, and the CLAT addresses assigned. It also reports whether the instance was enabled automatically or manually (Mode and TriggerSource), which the module reads from the Microsoft-Windows-IPxlatCfg/Operational event log.

Get-WinClatInstance

To identify every interface actively translating across a group of computers, run the following command.

Get-Content -Path .\clients.txt | Get-WinClatInstance | Where-Object IsTranslating

Note: Get-WinClatInstance requires administrative privileges on the target computer.

Test-WinClat

Test-WinClat is the function I expect administrators will use most often. It performs a series of health checks on the global configuration and on each IPv6-enabled interface. By default, it returns a single summary per computer with an overall result of Pass, Warning, Fail, or NotApplicable, along with a list of the checks that failed or returned a warning.

Test-WinClat

Use the -Detailed switch to return one result per check. Each warning and failure includes a Detail explaining what was found and a Remediation describing how to correct it.

Test-WinClat -Detailed | Format-List

Note: The screen capture above contains additional information. It has been truncated for brevity.

Global checks include whether the feature is present, whether CLAT is permitted, whether NAT64 prefix discovery is enabled, and whether Group Policy overrides the local configuration. These do not require elevation. Interface checks include a SLAAC address, an IPv6 default route, the presence of native IPv4, an active CLAT instance, a CLAT address, and prefix consistency. Interface checks require administrative privileges and are skipped when the function is not run elevated.

Functional Test

Test-WinClat can also validate the CLAT path end to end. When the -IPv4Target parameter is specified, and an interface is translating, the function sends up to three ICMP echo requests to the target. Optionally, include the -IPv4Port parameter to test with a TCP connection instead. The results show which interface and source address the traffic used.

Test-WinClat -IPv4Target 192.0.2.10 -IPv4Port 443 -Detailed | Select-Object Check, Result, Detail

Important: Always specify an IPv4 address, not a hostname, for -IPv4Target. A hostname can be reached using DNS64 and NAT64 without CLAT, which defeats the purpose of the test. Also, Windows prefers a native IPv4 route over CLAT. If the computer has native IPv4 connectivity on another interface, the functional test reports Info rather than testing CLAT.

To test many computers and return only failures and warnings, run the following command.

Get-Content -Path .\clients.txt | Test-WinClat -Detailed | Select-Object ComputerName, Check, Result, Detail

Set-WinClatConfiguration

The Set-WinClatConfiguration function changes the global WinCLAT settings. Only the settings specified are changed. Before making any change, the function reads the current configuration and refuses any change that would leave both Pref64FromRA and Pref64FromDns disabled, since CLAT would never activate in that state. To enable WinCLAT, run the following command.

Set-WinClatConfiguration -Permit Enabled

Note: In the example above, the WinCLAT configuration is managed by group policy, which overrides the locally configured settings.

As I mentioned earlier, netsh.exe reports success even when Group Policy overrides a setting. To address this, Set-WinClatConfiguration reads back every change after it is made. If policy enforces a different value, the result is reported with a Status of PolicyOverride, as shown here.

The function supports -WhatIf. Disabling Permit or AutoEnable prompts for confirmation by default, because doing so stops CLAT on every interface where it was enabled automatically.

Set-WinClatInstance

The Set-WinClatInstance function manually enables or disables WinCLAT on a single interface, specified by name or interface index. This is primarily useful for testing and troubleshooting. Because netsh.exe refuses manual changes while AutoEnable is enabled, the function disables AutoEnable first, under a single confirmation prompt.

Set-WinClatInstance -InterfaceAlias 'Ethernet' -State Enabled

Please note that a Manual instance state does not survive a reboot, but the AutoEnable setting remains disabled. After a reboot, WinCLAT will not activate until AutoEnable is enabled again using Set-WinClatConfiguration -AutoEnable Enabled.

Reset-WinClatConfiguration

The Reset-WinClatConfiguration function returns the WinCLAT global configuration to the Windows defaults without requiring an export file. It sets Pref64FromDns, Pref64FromRA, and AutoEnable to enabled. Only settings that differ from the defaults are changed. To reset the WinCLAT configuration, run the following command.

Reset-WinClatConfiguration

Crucially, the Permit setting is changed only when the -Permit parameter is specified. This means a basic reset never stops CLAT. For a full reset to the current Windows defaults, including Permit, specify -Permit Disabled. Since this stops CLAT, the function prompts for confirmation by default.

Reset-WinClatConfiguration -Permit Disabled

Export and Import

The Export-WinClatConfiguration function saves the WinCLAT global configuration of one or more computers to the local computer, one file per computer. Files are named WinCLAT-<ComputerName>-<yyyyMMdd-HHmmss>.txt and are never overwritten, so repeated runs maintain a history of baselines. Export the WinCLAT configuration by running the following command.

Export-WinClatConfiguration -Path <folder name>

The Import-WinClatConfiguration function applies those files. Importantly, the files are never executed. Each file is parsed strictly, and any file containing content other than what netsh.exe writes is rejected before any computer is contacted. Only settings that differ from the file are changed.

Known Issues

During testing, I encountered the following issues. These are Windows behaviors, not issues with the module. They were observed on builds 26200.9711 and 26300.9711.

  • Stale CLAT address. After a network change, CLAT may retain its IPv6 address on the previous network’s prefix, causing IPv4 traffic through CLAT to fail. Test-WinClat reports a CLAT address failure in this scenario. Restarting the network adapter resolves the issue.
  • DNS registration. CLAT registers its IPv4 address (192.0.0.x) in DNS, which is unnecessary and may have negative side effects.
  • ICMP errors. ICMP error messages returned by NAT64 for IPv4 destinations do not reach IPv4 applications. As a result, ping to an unreachable IPv4 address times out rather than reporting that the destination is unreachable.

Summary

The WinCLAT PowerShell module makes it easier for administrators to configure, report on, and troubleshoot Windows CLAT across their environment. Whether you’re evaluating WinCLAT on a handful of test machines or preparing for a broad IPv6-only deployment, the module provides structured output, fleet-wide reporting, and built-in health checks that netsh.exe alone does not. Download it today from the PowerShell Gallery and let me know what you think. Feedback, issues, and feature requests are always welcome on GitHub.

Additional Information

WinCLAT PowerShell Module on the PowerShell Gallery

WinCLAT PowerShell Module on GitHub

Windows CLAT (WinCLAT): IPv4 Application Support on IPv6 Networks

Windows CLAT Overview and Configuration

When Windows CLAT (WinCLAT) Is Used on IPv6-Mostly and IPv6-Only Networks

How Windows CLAT (WinCLAT) Discovers the NAT64 Prefix

Windows CLAT Is Now Generally Available (Microsoft)

Leave a comment
by Richard M. Hicks on October 29, 2026  •  Permalink
Posted in IPv6, Microsoft Intune, PowerShell, Windows CLAT
Tagged , , , ,

Posted by Richard M. Hicks on October 29, 2026

https://directaccess.richardhicks.com/2026/10/29/introducing-the-winclat-powershell-module/

When Windows CLAT (WinCLAT) Is Used on IPv6-Mostly and IPv6-Only Networks

Always On VPN DNS Registration Update Available

Recently, I wrote that Microsoft has begun rolling out Windows CLAT (WinCLAT) for IPv6-mostly and IPv6-only networks. I also described how WinCLAT discovers the NAT64 prefix. This post explains the conditions under which it operates, which traffic uses it, and several practical deployment scenarios.

What WinCLAT Does

Windows customer-side translator (WinCLAT) helps IPv4-dependent applications work when a Windows 11 device connects to an IPv6-only network. It can also operate on an IPv6-mostly network when the device forgoes a native IPv4 address. WinCLAT translates IPv4 traffic generated by the device, while applications that use IPv6 natively can communicate without it. Microsoft currently offers the noncellular Windows CLAT feature in public preview for evaluation.

When WinCLAT Operates

Enabling WinCLAT permits it to operate on eligible non-cellular interfaces but does not mean every connection will be translated. The client must have IPv6 connectivity using Stateless Address Autoconfiguration (SLAAC), operate without native IPv4 connectivity on the interface, and discover a usable NAT64 prefix through a router advertisement or DNS. The network must also provide a NAT64 gateway, known as the provider-side translator (PLAT), that can reach the IPv4 destination. When an application generates IPv4 traffic, WinCLAT translates its packets into IPv6 for delivery to the PLAT.

When WinCLAT Does Not Activate

If a device has working native IPv4 connectivity on a conventional dual-stack network, its IPv4 traffic uses that connectivity. If the network does not provide NAT64 or the client cannot learn its prefix, WinCLAT cannot provide access to IPv4 destinations. Merely enabling the Windows setting does not turn an ordinary IPv6 network into a 464XLAT network.

SLAAC Addressing Requirement

The current Windows implementation also requires SLAAC for the client’s IPv6 address. A network that assigns addresses exclusively through stateful DHCPv6 does not meet this requirement.

Which Traffic Uses WinCLAT?

The address family used by a connection determines whether it needs WinCLAT. An application that opens an IPv4 socket, including one that connects to a literal IPv4 address such as https://10.21.12.83 or \\172.16.21.12\data, generates IPv4 traffic. On an eligible IPv6-only interface, WinCLAT translates that traffic to IPv6, and the PLAT translates it to IPv4 for delivery to the destination. WinCLAT uses 192.0.0.1/32 locally for IPv4 compatibility. That address belongs to the 192.0.0.0/29 IPv4 Service Continuity Prefix reserved by RFC 7335. It does not represent native IPv4 connectivity, and the translated IPv4 packets are not sent on the IPv6-only physical network.

IPv6 Traffic Bypasses WinCLAT

An IPv6-capable application connecting to a native IPv6 destination uses IPv6 directly. If its destination is IPv4-only, the application can instead receive a DNS64-synthesized AAAA record and reach it through NAT64 using IPv6. In that case, the traffic does not pass through WinCLAT. DNS64 cannot help an application that insists on an IPv4 socket or a literal IPv4 address, which is where WinCLAT becomes useful.

Hostname access via DNS64 and NAT64 on an IPv6-only network. The application uses a synthesized AAAA record and native IPv6 – WinCLAT is not the path. The only translator is the PLAT/NAT64 gateway.

WinCLAT Deployment Examples

The following are example scenarios used to illustrate when and how WinCLAT works.

IPv6-Only Network

On an IPv6-only network, a Windows device receives an IPv6 address using SLAAC but no native IPv4 address. The router advertises a network-specific NAT64 prefix using PREF64, and a NAT64 gateway has a route to an IPv4-only management server. A legacy tool connects to that server using an IPv4 socket. WinCLAT translates the tool’s outbound packets into IPv6 and translates the replies for the application.

Connecting to a Literal IPv4 Address

The management tool might be configured with the server’s IPv4 address instead of its host name. Because the application does not perform a name lookup, DNS64 has no opportunity to synthesize an AAAA record. WinCLAT constructs an IPv6 destination using the discovered NAT64 prefix and the server’s IPv4 address. A capture on the endpoint’s network interface would show IPv6 traffic toward that prefix, while the application continues to see an IPv4 connection.

WinCLAT on an IPv6-only network when an application uses a literal IPv4 address. The client translates at WinCLAT and the PLAT/NAT64 gateway translates back to IPv4.

WinCLAT NAT64 prefix and IPv6 address configuration.

Application traffic using IPv4 via WinCLAT.

Packet capture showing WinCLAT translated traffic using the discovered NAT64 prefix.

IPv6-Mostly Network

An IPv6-mostly network provides NAT64 while retaining IPv4 service for devices that need it. DHCPv4 option 108, called IPv6-Only Preferred, allows a compatible client to forgo a native IPv4 address for the indicated period. If the network also provides SLAAC and a discoverable NAT64 prefix, WinCLAT can carry that client’s IPv4 application traffic over IPv6. WinCLAT discovers the NAT64 prefix separately because option 108 does not supply this information. See How Windows CLAT (WinCLAT) Discovers the NAT64 Prefix for more information.

Supporting IPv4 and IPv6-Only Clients Together

For example, an enterprise could enable option 108 on a Wi-Fi subnet that provides SLAAC and NAT64. A WinCLAT-capable Windows laptop uses IPv6 and does not consume a native IPv4 lease. A legacy printer or another device that does not request option 108 can still receive an IPv4 address on the same subnet. If an application on the laptop opens an IPv4 socket to an IPv4 service, the laptop uses WinCLAT for that connection.

Packet capture showing DHCPv4 parameter request list indicating support for IPv6-only.

IPv4-Only Application and IPv6-Capable Browser

Two applications on the same IPv6-only Windows device can take different paths to an IPv4-only service. An older application that opens an IPv4 socket uses WinCLAT and then NAT64. If an IPv6-capable browser receives a DNS64-synthesized AAAA record for the service and connects to that IPv6 address, it uses NAT64 without WinCLAT. Both connections reach the IPv4 destination, but only the first begins as IPv4 traffic on the client.

Where WinCLAT Does Not Help

WinCLAT is intended to provide outgoing IPv4 compatibility across an IPv6-only access network. It is not a substitute for native IPv4 on the local link. Applications that depend on IPv4 broadcast, multicast discovery, or direct access to an IPv4-only device on the same subnet may need a different solution. Protocols that embed IPv4 addresses or otherwise depend on behavior beyond ordinary translated unicast connections should also be tested individually.

Verify WinCLAT Operation

On a Windows 11 device where the feature is available, first verify that WinCLAT is permitted and inspect its global configuration.

netsh.exe interface clat show global

Next, inspect the interface-specific state, using the name of the connected interface.

netsh.exe interface clat show instance interface=<interface name>

Testing the WinCLAT Path

A successful connection to an IPv4-only website does not, by itself, demonstrate WinCLAT operation. An IPv6-capable browser may receive a DNS64-synthesized AAAA record and use NAT64 without WinCLAT. Test an application that explicitly uses an IPv4 socket or a literal IPv4 destination, then inspect the WinCLAT instance and capture traffic on the physical interface. The capture should show IPv6 traffic toward the NAT64 prefix for that connection.

Confirm Configuration and Traffic

Confirm that the interface has an IPv6 address configured using SLAAC and that WinCLAT has discovered a NAT64 prefix. The 192.0.0.1/32 address is used locally by WinCLAT and does not indicate native IPv4 connectivity. For that test, confirm the physical interface sends IPv6 traffic to the NAT64 prefix. Together, the configuration and packet capture provide stronger evidence of WinCLAT operation than either one alone.

Summary

WinCLAT is used when an eligible Windows interface operates without native IPv4 connectivity and an application generates IPv4 traffic. On an IPv6-only network, it gives IPv4 sockets and literal IPv4 addresses a path through NAT64. On an IPv6-mostly network, DHCPv4 option 108 can let a capable client forgo a native IPv4 lease and use the same translation path. Applications using native IPv6 or DNS64-synthesized AAAA records do not require WinCLAT. Successful deployment depends on SLAAC, NAT64, prefix discovery, and testing the applications that still require IPv4.

Additional Information

Windows CLAT (WinCLAT) Overview and Configuration

How Windows CLAT (WinCLAT) Discovers the NAT64 Prefix

Configure DHCP Option 108 on Windows DHCP Server for IPv6-Mostly

Windows CLAT (WinCLAT) Resources

Leave a comment
by Richard M. Hicks on September 30, 2026  •  Permalink
Posted in IPv6, Windows CLAT
Tagged , , , , , ,

Posted by Richard M. Hicks on September 30, 2026

https://directaccess.richardhicks.com/2026/09/30/when-windows-clat-winclat-is-used-on-ipv6-mostly-and-ipv6-only-networks/

How Windows CLAT (WinCLAT) Discovers the NAT64 Prefix

DirectAccess Troubleshooting and the Windows 10 Network Connectivity Assistant

Recently, Microsoft began rolling out Windows Customer-side Translator (WinCLAT) for Windows 11, allowing IPv4 applications to communicate over IPv6-only networks using 464XLAT. To translate that traffic, WinCLAT must discover the network’s NAT64 prefix. This post explains how WinCLAT learns the prefix through router advertisements or DNS, and where DHCPv4 option 108 fits into an IPv6-only deployment.

464XLAT

The 464XLAT CLAT translates an application’s IPv4 packets into IPv6 and sends them across an IPv6-only network to the PLAT. CLAT embeds the destination IPv4 address inside a special NAT64 IPv6 prefix (PREF64). The PLAT extracts the embedded IPv4 address and converts the packets back to IPv4 so they can reach the destination IPv4 address.

Well-Known Prefix

The NAT64 well-known prefix (WKP) is 64:ff9b::/96 as defined in RFC 6052. An IPv4 address is embedded in the last 32 bits of this prefix to produce a corresponding IPv6 address. In the example below, I’ve made two DNS queries for an IPv4-only resource: one to the standard Cloudflare public DNS server, and another to the Cloudflare public DNS64 server. The first response returns only an A resource record. In the second response, the server also returns an AAAA resource record using the well-known NAT64 prefix. You’ll find the last 32 bits of this record include the hexadecimal representation of the IPv4 address (ace9:996f = 172.233.153.111).

DNS queries and responses from standard and DNS64 DNS servers

This example uses the well-known prefix, but a network may use a different, network-specific NAT64 prefix (NSP). WinCLAT must discover the prefix used by the network’s PLAT before it can translate traffic correctly.

Prefix Discovery

WinCLAT can learn the NAT64 prefix in two ways. It can learn the NAT64 prefix from a PREF64 option carried in an IPv6 Router Advertisement (RFC 8781), or by querying ipv4only.arpa and extracting the prefix from the DNS64-synthesized AAAA records (RFC 7050).

Router Advertisement

NAT64 prefix discovery via RA is the preferred method. The router includes a PREF64 option in its IPv6 Router Advertisements to tell hosts which NAT64 prefix to use for 464XLAT. However, not all routers support the PREF64 option in RAs. Check whether your network equipment and software support it. If they do not, you may need a software upgrade or different equipment before you can use RA-based prefix discovery. Windows 11 clients with WinCLAT enabled use an advertised prefix to construct IPv6 destination addresses for IPv4 traffic. When both RA and DNS prefix discovery are enabled, Windows uses DNS as a fallback.

IPv6 router advertisement with PREF64 enabled

DNS

WinCLAT can also discover the NAT64 prefix through DNS. On an IPv6-only network, it sends a query over IPv6 to the network’s DNS64 resolver, requesting AAAA records for ipv4only.arpa. The ‘ipv4’ in the domain name does not mean the query travels over IPv4. It is part of a special name used for prefix discovery. The domain has two A records, 192.0.0.170 and 192.0.0.171, but no native AAAA records. The DNS64 resolver embeds those IPv4 addresses in synthesized AAAA responses using the network’s NAT64 prefix. For example, with the well-known prefix 64:ff9b::/96, the responses are 64:ff9b::c000:aa and 64:ff9b::c000:ab. The final 32 bits, c000:aa and c000:ab, represent 192.0.0.170 and 192.0.0.171, respectively. WinCLAT extracts the prefix from the responses and uses it for translation.

DNS queries and responses for the ipv4only.arpa domain using standard and DNS64 servers

DNS64 query response for the ipv4only.arpa domain

Configure Prefix Discovery

WinCLAT’s two NAT64 prefix discovery methods can be enabled or disabled independently using the pref64fromra and pref64fromdns settings configured with netsh.exe or via Active Directory group policy settings. For example, if your network advertises a PREF64 option, you can disable DNS discovery and use router advertisements alone. When both methods are enabled, DNS serves as a fallback. At least one method must remain enabled; CLAT cannot activate if both are disabled.

See Windows CLAT (WinCLAT) Overview and Configuration for guidance on configuring these options.

DHCP Option 108

WinCLAT supports networks that use DHCPv4 option 108, called IPv6-Only Preferred and defined in RFC 8925. The Windows DHCP client requests this option, which lets a DHCPv4 server indicate that the client can operate without a native IPv4 address for a specified wait period. If a DHCPOFFER contains a valid option 108, the client normally stops DHCPv4 configuration for that period and uses IPv6 connectivity instead. WinCLAT then attempts to discover the configuration it needs, and 464XLAT can provide IPv4 connectivity for applications over the IPv6-only network. Option 108 does not supply the NAT64 prefix. WinCLAT discovers that separately through router advertisements or DNS, as described previously.

DHCP Discover requesting option 108

DHCP Offer with option 108

Windows DHCP Server and Option 108

DHCP option 108 is not natively supported in Windows DHCP Server. However, administrators can create a Custom Predefined Option to enable DHCP option 108 support in their environment. You will find detailed guidance for configuring DHCP option 108 for Windows DHCP servers here.

Summary

WinCLAT allows IPv4 applications to work on an IPv6-only network by translating their traffic for a NAT64 gateway. To do this, it discovers the network’s NAT64 prefix through a router advertisement or DNS. DHCPv4 option 108 serves a separate purpose: it tells compatible clients they can defer native IPv4 configuration and rely on IPv6 connectivity.

Additional Information

Windows CLAT (WinCLAT) Overview and Configuration

Configure DHCP Option 108 on Windows DHCP Server for IPv6-Mostly

464XLAT: Combination of Stateful and Stateless Translation (RFC 6877)

IPv6 Addressing of IPv4/IPv6 Translators (RFC 6052)

Windows CLAT (WinCLAT) Resources

Leave a comment
by Richard M. Hicks on September 28, 2026  •  Permalink
Posted in IPv6, Windows CLAT
Tagged , , , , , , ,

Posted by Richard M. Hicks on September 28, 2026

https://directaccess.richardhicks.com/2026/09/28/how-windows-clat-winclat-discovers-the-nat64-prefix/

Windows CLAT (WinCLAT) Overview and Configuration

Microsoft has announced the general availability of Windows CLAT (WinCLAT), extending IPv4 application compatibility to IPv6-only and IPv6-mostly networks on Windows 11. WinCLAT works with a network NAT64 gateway to allow IPv4-dependent applications to communicate without native IPv4 connectivity on the client’s network interface. This article provides an overview of WinCLAT, explains its network requirements, and demonstrates how to enable and configure it using netsh.exe and Active Directory Group Policy.

What Is CLAT?

CLAT (customer-side translator) is part of the 464XLAT IPv6 transition and translation technology. CLAT uses the Stateless IP/ICMP Translation Algorithm (SIIT) to translate IPv4 packets generated by the client into IPv6. A corresponding provider-side translator (PLAT), typically a NAT64 gateway, translates the packets back to IPv4 before forwarding them to their destination.

Background

CLAT has been part of Windows for quite some time. It first shipped with Windows Phone and was later ported to Windows 10 with the Creators Update (v1703) in April 2017. Until now, the implementation was limited to wireless wide area network (WWAN) cellular interfaces.

Why Do We Need CLAT?

Although modern applications increasingly support IPv6, many applications and services still depend on IPv4. Some applications use IPv4-only sockets or application programming interfaces (APIs), while others connect directly to literal IPv4 addresses. Because these applications cannot use DNS64-generated AAAA records, they require another mechanism to communicate across an IPv6-only network. WinCLAT provides this compatibility while allowing the network to operate without native IPv4 connectivity.

How WinCLAT Works

When enabled, WinCLAT determines whether the client is operating without native IPv4 connectivity. This can occur on an IPv6-only network or an IPv6-mostly network where Dynamic Host Configuration Protocol for IPv4 (DHCPv4) Option 108 instructs capable clients to forgo an IPv4 address. WinCLAT then learns the network’s NAT64 prefix from a router advertisement (RA) or via DNS and the ipv4only.arpa domain. Next, WinCLAT creates a synthetic IPv4 address on the network interface. When an application generates IPv4 traffic, WinCLAT statelessly translates the IPv4 packets to IPv6 using the discovered NAT64 prefix and forwards them to the network. Return traffic is translated back to IPv4. This process is transparent to most applications, which can continue using IPv4 sockets without native IPv4 connectivity on the network.

SLAAC Requirement

WinCLAT currently requires the client to obtain its IPv6 address using Stateless Address Autoconfiguration (SLAAC). It does not work on networks that assign client IPv6 addresses exclusively through stateful DHCPv6. Organizations using DHCPv6 for IPv6 address assignment must also enable SLAAC before deploying WinCLAT.

The Role of DNS64 and NAT64

DNS64 and NAT64 work alongside WinCLAT to provide access to IPv4-only resources from an IPv6-only network. Their role depends on whether an application communicates using IPv6 or still requires IPv4.

IPv4 Connectivity for IPv6 Applications

DNS64 synthesizes AAAA records from IPv4 A records, allowing IPv6-capable applications to communicate with IPv4-only destinations through the NAT64 gateway. Applications that use IPv4 sockets or connect to literal IPv4 addresses cannot use these synthesized records and instead rely on WinCLAT for compatibility.

NAT64 Prefix Discovery

DNS also provides one method for WinCLAT to discover the network’s NAT64 prefix. WinCLAT can obtain the prefix by querying ipv4only.arpa, although the preferred method is the PREF64 option in an IPv6 router advertisement.

Note: DNS64 and NAT64 are likely familiar to Microsoft DirectAccess administrators, as these technologies were introduced with DirectAccess in Windows Server 2012.

Configure WinCLAT

After the WinCLAT feature becomes available on your device, you can enable and configure it using netsh.exe.

Enable WinCLAT

To permit WinCLAT operation on non-cellular interfaces, open an elevated command window and run the following command.

netsh.exe interface clat set global permit=enabled

View WinCLAT Settings

You can view the current global configuration by running the following command.

netsh.exe interface clat show global
netsh interface clat show global output displaying WinCLAT global settings

You can also view interface-specific settings using the following command.

netsh.exe interface clat show instance interface=<interface name>
netsh interface clat show instance output displaying WinCLAT settings for a network interface

Prefix Discovery

Optionally, you can enable or disable NAT64 prefix discovery options (from DNS and/or from RA) using the following commands.

# enable pref64 discovery methods
netsh.exe interface clat set global pref64fromdns=enabled
netsh.exe interface clat set global pref64fromra=enabled

# disable pref64 discovery methods
netsh.exe interface clat set global pref64fromdns=disabled
netsh.exe interface clat set global pref64fromra=disabled

Note: At least one prefix-discovery method must remain enabled. When both are enabled, WinCLAT prefers the PREF64 option in an IPv6 router advertisement and uses DNS-based discovery as a fallback.

WinCLAT IPv4 Address

WinCLAT assigns 192.0.0.1/32 to the interface for use by the local IPv4 stack. This address comes from the IANA-reserved 192.0.0.0/29 IPv4 Service Continuity Prefix defined in RFC 7335. Addresses from this prefix support local IPv4 compatibility and are not transmitted as IPv4 packets on the physical network.

Network interface with the WinCLAT IPv4 address 192.0.0.1 assigned

Test IPv4 Connectivity

To test connectivity with WinCLAT, browse to a website or connect to another resource that uses IPv4 only from an IPv6-only network. In this example, I’m connecting to Google’s IPv4-only website https://ipv4.google.com/.

Browser loading the IPv4-only site ipv4.google.com from an IPv6-only network using WinCLAT

Connectivity test confirming IPv4 access to ipv4.google.com from an IPv6-only network

Group Policy

Administrators can also manage WinCLAT configuration settings using Active Directory (AD) and Group Policy. To begin, copy the tcpip.admx and tcpip.adml files from C:\Windows\PolicyDefinitions and C:\Windows\PolicyDefinitions\en-us (or another preferred language) from a device on which WinCLAT is available to the Group Policy Central Store in AD. Once complete, you will find WinCLAT settings in the following location in the Group Policy Management console (gpmc.msc).

Computer Configuration > Policies > Administrative Templates > Network > TCPIP Settings > IPv6 Transition Technologies

Group Policy Management Editor showing WinCLAT settings under IPv6 Transition Technologies

Summary

WinCLAT extends Windows support for 464XLAT to noncellular network interfaces, allowing IPv4-dependent applications to operate on IPv6-only and IPv6-mostly networks. It translates locally generated IPv4 traffic to IPv6 and forwards it to a NAT64 gateway, while DNS64 provides direct NAT64 connectivity for IPv6-capable applications. Administrators can configure WinCLAT locally using netsh.exe or centrally through Group Policy and can use either router advertisements or DNS to discover the NAT64 prefix. WinCLAT currently requires SLAAC-based IPv6 addressing and does not support networks that assign client IPv6 addresses exclusively through stateful DHCPv6.

Additional Information

Microsoft Plans to Extend CLAT Support in Windows 11

Microsoft Windows CLAT Public Preview

464XLAT: Combination of Stateful and Stateless Translation (RFC 6877)

IPv6-Only Preferred Option for DHCPv4 (RFC 8925)

Configure DHCP Option 108 on Windows DHCP Server for IPv6-Mostly

Windows CLAT (WinCLAT) Resources

Leave a comment
by Richard M. Hicks on September 23, 2026  •  Permalink
Posted in Always On VPN, DNS and NRPT, IPv6, Windows CLAT
Tagged , , , , , ,

Posted by Richard M. Hicks on September 23, 2026

https://directaccess.richardhicks.com/2026/09/23/microsoft-begins-rolling-out-windows-clat-for-ipv6-only-networks/

Configure Windows Server DNS64 for IPv6-Mostly and IPv6-Only

IPv4 to IPv6 transition

Many organizations are modernizing their networks by migrating from legacy IPv4 to IPv6. The goal is to replace IPv4 with IPv6 entirely. However, even though an organization can successfully migrate to IPv6-only networks internally, it does not control networks outside its boundaries. In some cases, a host on an IPv6-only or IPv6-mostly network may need to communicate with an IPv4 resource. Administrators must deploy an IPv6 transition technology to support this scenario. A common solution to address this need is DNS64 and NAT64.

Last updated: November 8, 2026

What are DNS64 and NAT64?

DNS64 and NAT64, defined in RFCs 6147 and 6146, respectively, work together to ensure endpoints on an IPv6-only network can still communicate with IPv4-only resources. DNS64 enables IPv6-only clients to communicate with IPv4-only servers by synthesizing AAAA DNS records from A records. When an IPv6-only client queries a domain with only an IPv4 address (A record), the DNS64 server creates a synthetic IPv6 address by embedding the IPv4 address within an administrator-defined NAT64 IPv6 prefix. The default (referred to as ‘well known’) prefix is 64:ff9b::/96. In the example below, the IPv4-only resource ipv4.test-ipv6.com is resolved using the Cloudflare public DNS64 resolver.

Resolve-DnsName query for the IPv4-only resource ipv4.test-ipv6.com using the Cloudflare public DNS64 resolver, returning a synthesized AAAA record

Using the synthetic DNS64 address allows the client to send IPv6 packets to a NAT64 gateway, which translates them to IPv4 for the destination server. DNS64 ensures seamless address resolution for IPv6-only networks accessing IPv4 resources without requiring actual IPv6 addresses for the target.

Caveat

While DNS64 is great for ensuring IPv4 access on IPv6-only networks, it has one critical limitation. The client must connect to a resource using a hostname or a fully qualified domain name. If a client attempts to connect to an IPv4 resource directly (e.g., https://172.16.21.12 or \\10.21.12.83\data), the resource will be unreachable. To address this limitation, the 464XLAT IPv6 transition technology must be used. For more information about 464XLAT, see my previous article, Windows CLAT (WinCLAT) Overview and Configuration.

Enterprise DNS64

While there are public DNS64 resolvers from Cloudflare, Google, and others, they aren’t helpful when trying to resolve internal hostnames in the enterprise. Organizations must deploy their own private DNS64 services in this scenario.

Windows Server and DNS64

Today, Windows Server does not natively support DNS64. Organizations are advised to use an enterprise DNS solution such as Infoblox or BlueCat for DNS64 services. Alternatively, administrators can deploy BIND DNS on the Linux platform of their choice. DNS64 is supported in BIND 9.8.0 and later.

DNS64 Proxy

To support testing and evaluation (and perhaps production deployment for smaller organizations), it is possible to configure any supported version of Windows Server to serve as a DNS64 proxy. In this scenario, a Windows Server is configured as a DNS64 server, but the server itself is not an actual DNS server. It does not have a DNS database or zone file; it is not authoritative for any zones and can’t perform conditional forwarding. It simply forwards DNS queries to the servers defined on its own network interface.

Windows Server DNS64 Configuration

The DNS64 service must be installed using PowerShell and the Set-NetDnsTransitionConfiguration command. Administrators will define some variables, configure DNS64, and create firewall rules to allow DNS traffic inbound to the server.

Configure DNS64

On a Windows Server member server (domain-join is optional), open an elevated PowerShell command window and run the following commands.

# Define variables
$AcceptInterface = 'Ethernet' # The interface name or alias that will accept DNS64 traffic
$SendInterface = 'Ethernet' # The interface name or alias that will send DNS64 traffic
$Nat64Prefix = '64:ff9b::/96' # The NAT64 prefix

# Configure DNS64
Set-NetDnsTransitionConfiguration -State Enabled -AcceptInterface $AcceptInterface -SendInterface $SendInterface -PrefixMapping "$Nat64Prefix,0.0.0.0/0" -PassThru
PowerShell output of Set-NetDnsTransitionConfiguration enabling DNS64 on Windows Server

Configure Windows Firewall

Run the following PowerShell commands to configure the Windows Firewall to allow inbound DNS requests.

# Create firewall rules to allow DNS64 traffic inbound
New-NetFirewallRule -Name 'DNSSrv-DNS-UDP-In' -DisplayName 'DNS (UDP, Incoming)' -Description 'Inbound rule to allow remote UDP access to the DNS64 service.' -Group 'DNS64 Service' -Protocol UDP -LocalPort 53 -Direction Inbound -Profile Any -Action Allow -Enabled True

New-NetFirewallRule -Name 'DNSSrv-DNS-TCP-In' -DisplayName 'DNS (TCP, Incoming)' -Description 'Inbound rule to allow remote TCP access to the DNS64 service.' -Group 'DNS64 Service' -Protocol TCP -LocalPort 53 -Direction Inbound -Profile Any -Action Allow -Enabled True
PowerShell output creating Windows Firewall rules to allow inbound DNS64 traffic on TCP and UDP port 53

GitHub

For reference, I’ve posted the relevant commands for configuring DNS64 on Windows Server on GitHub here.

DNS64 Testing

Once DNS64 is configured on the Windows Server, administrators can test operation by sending a DNS query for an IPv4-only resource to the DNS64 server using the following PowerShell command.

Resolve-DnsName -Name ipv4.test-ipv6.com -Server <DNS64 server IPv6 address>

For example.

Resolve-DnsName -Name ipv4.test-ipv6.com -Server 2001:db8::64
Resolve-DnsName query to the Windows Server DNS64 proxy returning the native IPv4 address and a synthesized IPv6 address

The DNS64 server returns the native IPv4 address (A record) along with the synthesized IPv6 address (AAAA record). If the target resource already has a native AAAA record, the DNS64 server returns that record and does not synthesize one, as shown below.

Resolve-DnsName query through the Windows Server DNS64 proxy for a resource with a native IPv6 address

Resolve-DnsName query through the Windows Server DNS64 proxy for a dual-stack resource returning its native IPv4 and IPv6 addresses

DNS64 and Windows CLAT (WinCLAT)

DNS64 also supports Windows CLAT (WinCLAT), which allows IPv4-dependent applications to work on IPv6-only and IPv6-mostly networks using 464XLAT. To translate IPv4 traffic, WinCLAT must discover the network’s NAT64 prefix. One way it does this is by querying a DNS64 server for AAAA records for ipv4only.arpa (RFC 7050) and extracting the prefix from the synthesized response. The Windows Server DNS64 proxy answers these queries, so it can provide DNS-based NAT64 prefix discovery for WinCLAT clients. To verify, run the following PowerShell command.

Resolve-DnsName -Name ipv4only.arpa -Type AAAA -Server <DNS64 server IPv6 address>

With the well-known prefix, the response includes 64:ff9b::c000:aa and 64:ff9b::c000:ab, which embed the ipv4only.arpa addresses 192.0.0.170 and 192.0.0.171 in hexadecimal. The PREF64 option in IPv6 router advertisements is the preferred discovery method, with DNS64 serving as a fallback. For more information, see How Windows CLAT (WinCLAT) Discovers the NAT64 Prefix.

Summary

DNS64 and NAT64 are essential tools for enabling communication between IPv6-only networks and IPv4 resources. While public resolvers exist, enterprises often need their own DNS64 service for internal hostname resolution. Windows Server does not natively support DNS64, but administrators can configure it as a DNS64 proxy for testing and smaller deployments. In this scenario, Windows Server can provide DNS64 functionality, helping organizations transition toward IPv6-only networks while maintaining access to legacy IPv4 systems. The Windows Server DNS64 proxy also answers ipv4only.arpa queries, allowing WinCLAT clients to discover the NAT64 prefix using DNS.

Additional Information

Windows CLAT (WinCLAT) Overview and Configuration

How Windows CLAT (WinCLAT) Discovers the NAT64 Prefix

Configure DHCP Option 108 on Windows DHCP Server for IPv6-Mostly

What is 464XLAT? CLAT and PLAT Explained

What is an IPv6-Mostly Network?

IPv6 Transition Technology Options – IPv6 Buzz Podcast

Set-NetDnsTransitionConfiguration

Stateful NAT64 (RFC 6146)

DNS64 (RFC 6147)

464XLAT: Combination of Stateful and Stateless Translation (RFC 6877)

Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis (RFC 7050)

What is IPv6?

Windows CLAT (WinCLAT) Resources

Leave a comment
by Richard M. Hicks on September 15, 2025  •  Permalink
Posted in Always On VPN, DNS and NRPT, IPv6, PowerShell, Windows CLAT, Windows Server
Tagged , , , , , ,

Posted by Richard M. Hicks on September 15, 2025

https://directaccess.richardhicks.com/2025/09/15/windows-server-dns64-and-ipv6-only/

Configure DHCP Option 108 on Windows DHCP Server for IPv6-Mostly

IPv6

While enterprise adoption of IPv6 has been slow, it is still moving forward. For example, the U.S. federal government has mandated [M-21-07 – PDF] the transition to IPv6 to modernize its networks and enhance security, scalability, and interoperability. During the migration to IPv6, most systems will be configured with both IPv4 and IPv6, a configuration referred to as dual stack. Ultimately, the goal is the elimination of IPv4 entirely and the use of IPv6 exclusively. However, IPv6-only presents some unique challenges.

Access to IPv4

Although an organization can successfully migrate to IPv6-only networks internally, it does not control networks outside its boundaries. In some cases, a host on an IPv6-only network may need to communicate with an IPv4 resource. Administrators must deploy an IPv6 transition technology to support this scenario.

464XLAT

464XLAT, defined in RFC 6877, is a network architecture that facilitates the transition from IPv4 to IPv6 by enabling IPv4 traffic to operate over an IPv6-only network. It combines two translation mechanisms: a customer-side translator (CLAT) on the user device, which converts IPv4 packets to IPv6, and a provider-side translator (PLAT) at the network edge, which converts the IPv6 packets back to IPv4 to communicate with IPv4-only internet services. This dual-translation approach allows devices in an IPv6-only environment to access both IPv6 and IPv4 resources without native IPv4 connectivity, making it an efficient solution for networks transitioning to IPv6 while maintaining compatibility with legacy IPv4 systems. On Windows, Windows CLAT (WinCLAT) provides the CLAT component.

CLAT for Windows

Windows has long included CLAT support for cellular network interfaces. Windows CLAT (WinCLAT) extends this support to Wi-Fi and Ethernet interfaces and is generally available on Windows 11 version 25H2, starting with build 26200.9550. WinCLAT is disabled by default on non-cellular interfaces and must be permitted before it can operate. Windows also honors DHCP option 108 only while WinCLAT is permitted. WinCLAT is not available on Windows Server. For configuration details, see Windows CLAT (WinCLAT) Overview and Configuration.

IPv6-Mostly

An IPv6-mostly network, as defined in RFC 8925, provides NAT64 alongside native IPv4 and allows IPv6-only, dual-stack, and IPv4-only devices to coexist on the same network segment. Devices that can operate without IPv4 forgo an IPv4 address, while devices that still require IPv4 continue to receive one. This approach reduces IPv4 address consumption and allows organizations to move toward IPv6-only incrementally, with 464XLAT providing IPv4 access for applications that still need it.

DHCP Option 108

DHCPv4 option 108, called IPv6-Only Preferred, allows an IPv6-mostly network to signal to capable clients that they can operate without a native IPv4 address. Only clients that can operate without IPv4, usually because they include a CLAT or because all of their applications work over IPv6, request the option. When the DHCP scope is configured for IPv6-mostly operation, the server includes option 108 in its response, along with a wait time. The client then stops DHCPv4 configuration for that period, or until it reconnects to a network, and relies on IPv6 and NAT64 for connectivity. Disabling the IPv4 stack entirely during that time is optional. Clients that do not request the option obtain an IPv4 address as usual.

Option 108 and Windows Server DHCP

Commercial DHCP appliances like Infoblox and many open source DHCP platforms natively support DHCP option 108. However, no supported version of Windows Server, including the latest release (Windows Server 2025), supports DHCP option 108 natively. To enable DHCP option 108 on Windows DHCP servers, administrators can create a custom predefined option.

Custom Predefined Option

To create a custom predefined option for DHCP option 108 on a Windows DHCP server, open the DHCP management console (dhcpmgmt.msc) and perform the following steps.

  1. Right-click IPv4 and choose Set Predefined Options.
  2. Click Add.
  3. Enter IPv6 Only Preferred in the Name field.
  4. Select Long from the Data type drop-down list.
  5. Enter 108 in the Code field.
  6. Click Ok.
DHCP management console creating custom option 108 IPv6 Only Preferred with data type Long

Assigning DHCP Option 108

Once complete, perform the following steps to assign DHCP option 108 to a DHCP scope.

  1. Select an IPv4 DHCP scope.
  2. Right-click Scope Options and choose Configure Options.
  3. Select 108 IPv6 Only Preferred from the Available Options list.
  4. Enter a value in seconds, in hexadecimal format. This value is the period during which a client stops DHCPv4 configuration and operates without native IPv4. RFC 8925 sets a minimum of 300 seconds (clients treat lower values as 300) and a default of 1800 seconds. For example, 86,400 seconds (1 day) is 0x15180.
  5. Click Ok.
DHCP scope options with 108 IPv6 Only Preferred set to 0x15180

PowerShell

Custom predefined options can also be configured using PowerShell.

Custom Predefined Option

To create a custom predefined option for DHCP option 108, open an elevated PowerShell command on a Windows DHCP server and run the following command.

Add-DhcpServerv4OptionDefinition -Name 'IPv6 Only Preferred' -OptionId 108 -Type DWORD -PassThru
PowerShell output of Add-DhcpServerv4OptionDefinition creating DHCP option 108

Assigning DHCP Option 108

To assign the custom predefined DHCP option 108 to a DHCP scope, run the following PowerShell command.

Set-DhcpServerv4OptionValue -ScopeId 172.16.5.0 -OptionId 108 -Value 0x15180 -PassThru
PowerShell output of Set-DhcpServerv4OptionValue assigning option 108 to a DHCP scope

DHCP Offer

Once configured, if the client requests DHCP option 108 in its DHCP Discover, the DHCP server includes it in the DHCP Offer, as shown here. Windows DHCP Server does not send option 108 to clients that do not request it, as required by RFC 8925.

Packet capture of a DHCP Offer containing option 108 IPv6-Only Preferred

Learn More

If you are interested in learning more about IPv6-mostly and DHCP option 108, be sure to listen to the following episodes of the IPv6 Buzz Podcast.

Summary

As organizations continue their transition toward IPv6, DHCP option 108 provides administrators with a simple and effective way to reduce reliance on legacy IPv4 by signaling clients to prefer IPv6-only operation if they can support it. While Windows Server does not natively support this option, creating a custom predefined setting ensures administrators can take advantage of this important feature.

Additional Information

M-21-07 – Completing the Transition to IPv6 for U.S. Federal Government Agencies [PDF]

Windows CLAT (WinCLAT) Overview and Configuration

How Windows CLAT (WinCLAT) Discovers the NAT64 Prefix

When Windows CLAT (WinCLAT) Is Used on IPv6-Mostly and IPv6-Only Networks

What is 464XLAT? CLAT and PLAT Explained

What is an IPv6-Mostly Network?

464XLAT: Combination of Stateful and Stateless Translation (RFC 6877)

IPv6-Only Preferred Option for DHCPv4 (RFC 8925)

IPv6 Buzz Podcast on PacketPushers.Net

Windows CLAT (WinCLAT) Resources

3 Comments
by Richard M. Hicks on August 25, 2025  •  Permalink
Posted in IPv6, PowerShell, Windows CLAT, Windows Server
Tagged , , , , , , , , , , , , ,

Posted by Richard M. Hicks on August 25, 2025

https://directaccess.richardhicks.com/2025/08/25/windows-server-dhcp-and-option-108/

« Older Posts