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

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

How Windows CLAT (WinCLAT) Discovers the NAT64 Prefix

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

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

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

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, they do 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 client-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 requiring a full IPv4 stack, making it an efficient solution for networks transitioning to IPv6 while maintaining compatibility with legacy IPv4 systems. To support 464XLAT, Windows provides specific functionality for CLAT, though with some limitations.

CLAT for Windows

Windows currently provides CLAT support only for cellular network interfaces. CLAT is not available for Wi-Fi or Ethernet interfaces today. However, Microsoft has publicly announced plans to extend CLAT support in Windows for these non-cellular network interfaces soon.

IPv6 Mostly

IPv6 Mostly, defined in RFC 8925, refers to a network configuration where IPv6 is the primary protocol for communication, but IPv4 is still supported for specific use cases. Devices in these networks prefer IPv6 for most operations, leveraging its larger address space and modern features, while maintaining limited IPv4 compatibility. IPv6 Mostly networks ease the transition from IPv4 to IPv6, balancing modern protocol adoption with support for older applications. They optimize resource usage and prepare networks for a future where IPv6 dominates, with tools like 464XLAT providing seamless IPv4 access when necessary.

DHCP Option 108

DHCP Option 108 is a specific configuration in DHCP that enables IPv6-only networks to signal clients to disable IPv4. When a client receives this option, it deactivates its IPv4 stack, relying solely on IPv6 for communication. Turning off IPv4 when it isn’t needed helps streamline network operations in IPv6-focused environments.

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.

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 represents the duration for which a client should prefer IPv6-only mode. For example, 86,400 seconds (1 day) is 0x15180.
  5. Click Ok.

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

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

DHCP Offer

Once configured, if the client indicates support for DHCP option 108 in its DHCP Request, the DHCP server will include it in the DHCP Offer, as shown here.

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]

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

How Windows CLAT (WinCLAT) Discovers the NAT64 Prefix

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

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

RFC 8925 – IPv6-Only Preferred Option for DHCPv4

IPv6 Buzz Podcast on PacketPushers.Net