Microsoft Begins Rolling Out Windows CLAT (WinCLAT) for IPv6-Mostly and IPv6-Only Networks

Following successful private and public previews, Microsoft has begun deploying Windows Customer-side Translator (WinCLAT) through Controlled Feature Rollout (CFR) to Windows 11 clients. WinCLAT allows IPv4-dependent applications to operate on IPv6-only and IPv6-mostly networks, removing an important compatibility barrier for organizations transitioning away from native IPv4. As of September 23, 2026, I estimate that approximately half of eligible Windows endpoints have received the feature, with availability expected to expand over the next several weeks.

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

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

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

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.

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/.

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

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

RFC 6877 – 464XLAT: Combination of Stateful and Stateless Translation

RFC 8925 – IPv6-Only Preferred Option for DHCPv4

Windows Server DHCP and Option 108

Intranet Certificate Monitoring with CertKit

CertKit is a cloud-based solution that automates the issuance and management of public TLS certificates. It also provides certificate monitoring and alerting for public-facing workloads. However, many organizations have internal (non-public-facing) services that also use TLS. CertKit agent v1.13.0, currently in preview, closes this gap by providing visibility into TLS certificates used by intranet resources. After installing the latest release of the agent, CertKit can now provide visibility into the status of TLS certificates for internal resources.

Intranet Monitoring

After installing or updating the CertKit agent to v1.13.0, administrators can select an internal TLS service to monitor. Follow the steps below to enable this feature.

Certificate Collection

I recommend creating a separate Certificate Collection to support intranet monitoring. In the CertKit management console, click Add Collection, enter a unique, descriptive name, and click Add Collection.

Install the Agent

Once the new collection is created, navigate to the Agents tab, select your platform, then download, install, and register the agent.

Monitor New Host

After the agent is installed and registered, navigate to the Monitoring tab and click Monitor New Host. Enter the fully qualified domain name (FQDN) of the resource and specify its TLS port. Under Host Visibility, select Internal, and then choose the agent to monitor the host from. When finished, click Monitor Host.

Note: The server running the CertKit agent does not require a TLS certificate of its own to monitor internal resources.

Monitored Hosts

CertKit can track certificates for any internal workload that uses TLS. In this example, the monitored resources include web applications, security appliances, load balancers, and HTTP CRL distribution points. The list also includes LDAPS on the domain controllers and the RDP and WinRM HTTPS services on the management workstation.

The circle next to each resource indicates its certificate status. Green indicates a healthy certificate, yellow indicates one approaching expiration, and red indicates an expired certificate or another detected issue.

Note: The RDP certificate on the management workstation appears red because it contains only the Remote Desktop Authentication EKU (1.3.6.1.4.1.311.54.1.2). It intentionally does not include Server Authentication, which CertKit currently expects when validating the service. CertKit is aware of this limitation and plans to address it in a future release.

Host Discovery

CertKit provides robust discovery for public websites but does not currently offer equivalent functionality for intranet resources. Administrators can identify internal systems listening on a specific port by using Nmap.

nmap.exe -Pn -p [port] --open [internal subnet]

For example:

nmap.exe -Pn -p 443 --open 172.16.0.0/24

Alternatively, add the -oX switch to save the output in XML format.

nmap.exe -Pn -p 443 --open 172.16.0.0/24 -oX scan.xml

The resulting Nmap XML file output can be converted to CSV format using this PowerShell code.

Summary

CertKit agent v1.13.0 extends certificate monitoring to internal TLS services, giving administrators greater visibility into certificates that were previously difficult to track. Although intranet host discovery remains a manual process, tools such as Nmap and PowerShell can help identify resources to add to the monitoring platform

Getting Started with CertKit

Need help improving certificate visibility and management across your organization? Want to automate public TLS certificate enrollment for workloads such as DirectAccess, Always On VPN, IIS, SQL, and more? I can help you assess your certificate environment, identify monitoring gaps, and develop a strategy for managing certificates across internal and public-facing workloads. Fill out the form below, and I’ll provide you with more information.

← Back

Thank you for your response. ✨

Additional Information

CertKit Website

What Is CertKit?

CerKit Agent Support for Always On VPN SSTP and DirectAccess IPHTTPS TLS Certificates

IIS TLS Certificate Deployment with CertKit

The Case for 6-Day Public TLS Certificates

DirectAccess IPHTTPS and Let’s Encrypt 6-Day TLS Certificates

Always On VPN Dynamic Profile Configurator (DPC) Webinar

Managing Microsoft Always On VPN deployments doesn’t have to be complicated. Always On VPN Dynamic Profile Configurator (DPC) is a free, open-source solution that simplifies deploying and managing Always On VPN client configuration settings while extending the capabilities of native deployment methods such as Microsoft Intune VPN profiles, custom XML, and PowerShell scripts.

Whether you’re deploying Always On VPN for the first time or looking to streamline an existing implementation, DPC provides powerful features that make advanced VPN configuration easier to deploy, manage, and maintain.

Join Our Live Webinar

Join me on Tuesday, August 18, at 1:00 PM EDT for a live webinar featuring Leo D’Arcy, creator and lead developer of Always On VPN DPC. During this live session, we’ll demonstrate many of DPC’s latest capabilities and show how they can simplify even the most complex Always On VPN deployments. Topics include:

  • Configuring flexible VPN deployment strategies
  • Optimizing interface and route metrics
  • Dynamically excluding Microsoft 365 and custom domains from the VPN tunnel
  • Configuring IKE mobility settings for improved roaming
  • Defining and managing IPv6 routes
  • Deploying DPC using Active Directory and Microsoft Intune
  • Exploring additional advanced features and deployment scenarios

Throughout the webinar, we’ll share practical guidance, configuration tips, and real-world examples to help you get the most from Always On VPN DPC.

Register Today

Registration is free, but you must register in advance to attend. If you can’t attend the live session, register anyway, and you’ll receive access to the on-demand recording after the event.

We’ll also reserve time for a live Q&A at the end of the presentation, giving you the opportunity to ask questions directly to the developers and experts behind DPC.

We look forward to seeing you there!

Additional Information

Always On VPN Dynamic Profile Configurator (DPC)

Always On VPN DPC Advanced Features

Always On VPN DPC with Microsoft Intune

Migrating from Always On VPN DPC Commercial to Open Source

Always On VPN DPC Commercial Support Now Available

Always On VPN DPC Discord Channel