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:00aa and 64:ff9b::c000:00ab. The final 32 bits, c000:00aa and c000:00ab, 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 Microsoft Begins Rolling Out Windows CLAT (WinCLAT) for IPv6-Mostly and IPv6-Only Networks 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

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

Configure DHCP Option 108 on Windows DHCP Server

RFC 6877 464XLAT: Combination of Stateful and Stateless Translation

RFC 6052: IPv6 Addressing of IPv4/IPv6 Translators

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

DirectAccess IPHTTPS and Let’s Encrypt 6-Day Certificates

I’ve written extensively about how public TLS certificate lifetimes will drop to just 47 days by March 2029. Before then, we’ll see certificate lifetimes gradually drop from the current 398 days to 200 days on March 15, 2026, and then to 100 days on March 15, 2027. In preparation for this, I’ve been working with many customers to deploy automated certificate enrollment and renewal solutions to eliminate the need for manual intervention. Interestingly, Let’s Encrypt now offers extremely short-lived certificates that are good for just 6 days! While they work just fine for Always On VPN, I discovered they will not work for DirectAccess.

6-Day Certificate

After successfully enrolling for a 6-day TLS certificate from Let’s Encrypt (I used CertKit, BTW!), I encountered an error when trying to assign the short-lived certificate to the IP-HTTPS listener in the DirectAccess configuration. Specifically, when running the Set-RemoteAccess PowerShell command, I received the following error.

Set-RemoteAccess: The parameter is incorrect.

Further investigation showed that I could install other public TLS certificates just fine. For some reason, though, DirectAccess did not like this new 6-day certificate.

Missing Subject Name

After digging a bit deeper, I realized the Subject field of the new 6-day Let’s Encrypt certificate was empty.

Subject vs. SAN in Modern TLS

Modern TLS clients rely entirely on the Subject Alternative Name (SAN) field for identity validation, and the older practice of matching against the certificate’s Subject field has been phased out for many years. Many certificate authorities, including Let’s Encrypt, now leave the Subject field empty because it no longer serves a functional purpose in current TLS implementations. DirectAccess still expects this field to contain data and does not properly fall back to SAN‑only validation. As a result, any certificate with an empty Subject field, such as the new 6‑day certificates from Let’s Encrypt, will fail when applied to the DirectAccess IP‑HTTPS listener.

Workaround

Admittedly, using 6-Day public TLS certificates for DirectAccess is extreme and likely overkill for this workload. The good news is that DirectAccess still works perfectly with 90-day Let’s Encrypt certificates, so the lack of 6-day certificate support should not be impactful.

CertKit

Have you heard about CertKit? CertKit, an online service for automating Let’s Encrypt certificate enrollment and renewal, has added support for Always On VPN and DirectAccess. Find details on leveraging it for public TLS certificates for these solutions here.

Additional Information

Always On VPN SSTP with Let’s Encrypt Certificates

Always On VPN and 47-Day Public TLS Certificates

The Case for Short-Lived Certificates in Enterprise Environments

CertKit Agent Support for Always On VPN SSTP and DirectAccess IP-HTTPS TLS Certificates