Summary

  • Microsoft announced Windows CLAT for Windows 11 Client 25H2, build 26200.9550. Its post describes configuration discovery when IPv4 connectivity is unavailable or when DHCP option 108 signals IPv6-only preference.
  • At RIPE 93, Wilhelm Boeddinghaus said option 108 activates WinCLAT. In the Q&A, he described a Windows client with no DHCPv4 relay as showing an APIPA error instead. He said he still planned to test Windows with a local service that sends option 108 without assigning an IPv4 address.

Analysis

“Generally available” is a release label. A DHCP response is a packet on a wire. An enterprise cannot use the first as proof of the second.

The distinction matters because IPv6-only networking does not make every old application IPv6-capable. An application that opens an IPv6 socket can reach IPv4 destinations through NAT64. A legacy program that insists on an IPv4 socket needs a client-side translator. In 464XLAT, CLAT translates on the client; a provider-side PLAT/NAT64 completes the path. Windows calls its client feature WinCLAT.

Microsoft’s 27 October announcement puts the feature in Windows 11 Client 25H2 from build 26200.9550. It describes two routes into configuration discovery: no IPv4 connectivity, or DHCPv4 option 108 telling the client that the network prefers IPv6-only operation. Two days later, Boeddinghaus told RIPE’s IPv6 Working Group that Microsoft had moved WinCLAT out of preview and that administrators still needed to configure it. He said the feature was not yet exposed in the graphical interface; his examples were netsh and Active Directory Group Policy.

The talk turned on the signal that gets the translator moving. RFC 8925’s IPv6-Only Preferred option is part of DHCPv4. A capable client asks for it; an IPv6-mostly pool can return it, telling the client to forgo an IPv4 address for a bounded period. That clock is useful only after the client can exchange DHCP messages with the server.

That is where an IPv6-only office can end up keeping an IPv4-era service alive. If the DHCPv4 server is central and the client’s interface has no IPv4 route, how does option 108 get there? Boeddinghaus named three designs: tunnel DHCPv4 to the central server, which he called unattractive; carry DHCPv4 over DHCPv6, using RFC 7341 and RFC 9928’s relay-agent support; or let each switch run a small stateless DHCPv4 service that sends option 108 but gives out no IPv4 address.

The last design is tidy on a whiteboard and still an open Windows test. Boeddinghaus said it worked with another client implementation and planned to check what Windows did. In the Q&A, when asked why a client could not simply receive no DHCPv4 response and activate CLAT, he said Windows treated the resulting APIPA address as an error and did not start the translator. The transcript does not identify the Windows build or show a packet capture.

Microsoft’s wording leaves a useful distinction unresolved. “Configuration discovery” could describe prefix discovery after a translator has been enabled; the talk treats option 108 as the activation trigger. Those may be separate stages, or they may describe different builds and conditions. The public talk record does not settle which one applies to a silent DHCPv4 interface.

This is not the same question as how long option 108 postpones an IPv4 lease. The timer begins after the signal arrives. The earlier question is whether the supported Windows build reaches the CLAT state when DHCPv4 is absent, and which service must remain to deliver the signal if it does not.

Before retiring a relay, an operator needs one reproducible run on the build it plans to deploy: record the DHCPDISCOVER and any option-108 reply, the client’s IPv4 state, NAT64 prefix discovery, CLAT state and one legacy IPv4 application attempt. If silent DHCP starts the translator, the documented trigger should say so. If it does not, the network still needs an option-108 path—central over DHCPv6 or local at the switch.

Sources