All posts in category Microsoft

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 Global Secure Access (GSA) Traffic Forwarding Profiles v2

Microsoft recently introduced custom Entra Private Access traffic forwarding profiles in public preview. Administrators can now provide different sets of private applications to selected users, groups, devices, and device platforms. This post explains how the profiles are assigned and prioritized, how to configure one, and how the new local network option handles overlapping address space.

Forwarding Profiles v1

Previously, organizations could assign the default Private Access traffic forwarding profile to selected users and groups, but they could not create separate Private Access profiles with different acquisition rules for different target groups. That made it difficult to give Windows devices one set of private application destinations and mobile devices another. Administrators could still control access through application assignments and Conditional Access, but the traffic the client acquired was less tailored to the user or device.

Forwarding Profiles v2

Global Secure Access (GSA) provides default traffic forwarding profiles for Microsoft traffic, Private Access, and Internet Access. Administrators can also create custom Private Access profiles and scope them to users, groups, devices, and device platforms. During the preview, a tenant can have up to 10 custom Private Access profiles.

Policy Processing

GSA evaluates traffic against the Microsoft, Private Access, and Internet Access profile types in that order. Traffic that matches none of them is not forwarded to the service. This order is separate from the priority used to choose between multiple applicable Private Access profiles.

Multiple Profiles

Each custom Private Access profile has its own acquisition rules, assignments, status, and priority. Assign a priority from 101 through 199. A lower number represents a higher priority. When more than one enabled Private Access profile applies to the same user and device, the client uses only the highest-priority applicable profile. The application rules from the other profiles are not combined with it.

Configure a Custom Private Access Profile

In the Microsoft Entra admin center, go to Global Secure Access > Connect > Traffic forwarding. Select Create new traffic forwarding profile, then Private access profile. Enter a descriptive name and, optionally, a description. Set a priority from 101 through 199 and choose whether the profile is enabled. Select Next, review the settings, and select Create. Note that the new profile has no acquisition rules or assignments until you configure them.

Acquisition Rules

Open the new profile and select Acquisition rules. Choose whether to include Quick Access destinations, then select the Private Access applications whose destinations the profile should acquire. Adding an application to a forwarding profile determines which traffic the client captures. Users must also be authorized to connect to the application’s resources.

Including Quick Access Destinations

Including Quick Access adds its configured destinations to the acquisition rules of this profile alongside the selected Private Access applications. This can provide a common set of destinations across custom profiles, but it does not change the Quick Access application’s configuration or grant users access to its resources. Confirm that the intended users are assigned to Quick Access as well as to the forwarding profile.

Assignments

Under Assignments, select View next to User and device assignments. Choose All users and devices or Selected users and devices, then save your selection.

Next, select View next to Device platform assignments and choose the supported platforms that should receive the profile. A device must match both assignment conditions. For example, selecting a user group and Windows limits the profile to Windows devices used by members of that group.

The new profile appears in the traffic forwarding list by priority, as shown here.

On an assigned client, open Advanced diagnostics > Forwarding profile to confirm that the expected Private Access application segments are present, as shown here.

Prefer Local Network

The Windows GSA client includes a Prefer local network option for cases where a local subnet overlaps with a configured private application destination. When an administrator enables the option, it appears in the client settings. A user can select it to keep applicable local subnet traffic on the local network, such as traffic to a printer or screen casting device, instead of having the client acquire that destination for Private Access. Microsoft introduced the option in Windows GSA client version 2.32.294.

The Problem It Solves

Overlapping private address space can make a local destination look like a destination defined in a Private Access application segment. For example, a user’s home printer and a corporate resource might both use 192.168.1.50. Prefer local network lets the user favor the directly connected local destination in this situation, such as when printing or screen casting.

Intelligent Local Access

Intelligent Local Access (ILA) serves a different purpose. It uses configured DNS probes to identify a corporate private network and can then send traffic directly to specified Private Access applications available on that network. Prefer local network addresses when there is an overlap between the device’s local subnet and a Private Access destination, such as a printer on a home network. ILA depends on a matching configured private network and application. An address overlap alone does not trigger it.

Summary

Custom Private Access traffic forwarding profiles give administrators more control over which private application destinations the Global Secure Access (GSA) client acquires for different users and devices. Assignments determine who receives a profile, while priority determines which profile applies when assignments overlap. The Prefer local network option also helps Windows users reach local devices when their subnet overlaps a Private Access destination.

Additional Information

Global Secure Access traffic forwarding profiles

Create a Private Access traffic forwarding profile

Entra Private Access Intelligent Local Access

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

Richard M. Hicks Consulting, Inc.

Microsoft MVP

Consulting

Pluralsight

Newsletter

All posts in category Microsoft

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

What WinCLAT Does

When WinCLAT Operates

When WinCLAT Does Not Activate

SLAAC Addressing Requirement

Which Traffic Uses WinCLAT?

IPv6 Traffic Bypasses WinCLAT

WinCLAT Deployment Examples

IPv6-Only Network

Connecting to a Literal IPv4 Address

IPv6-Mostly Network

Supporting IPv4 and IPv6-Only Clients Together

IPv4-Only Application and IPv6-Capable Browser

Where WinCLAT Does Not Help

Verify WinCLAT Operation

Testing the WinCLAT Path

Confirm Configuration and Traffic

Summary

Additional Information

Share this:

Like this:

Microsoft Global Secure Access (GSA) Traffic Forwarding Profiles v2

Forwarding Profiles v1

Forwarding Profiles v2

Policy Processing

Multiple Profiles

Configure a Custom Private Access Profile

Acquisition Rules

Including Quick Access Destinations

Assignments

Prefer Local Network

The Problem It Solves

Intelligent Local Access

Summary

Additional Information

Share this:

Like this:

How Windows CLAT (WinCLAT) Discovers the NAT64 Prefix

464XLAT

Well-Known Prefix

Prefix Discovery

Router Advertisement

DNS

Configure Prefix Discovery

DHCP Option 108

Windows DHCP Server and Option 108

Summary

Additional Information

Share this:

Like this:

Always On VPN Book

DirectAccess Book

Masterclass

Yubikey

Recent Posts

Resources

Always On VPN Resources

DirectAccess Resources