All posts tagged DHCP

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

Leave a comment
by Richard M. Hicks on September 28, 2026  •  Permalink
Posted in 464XLAT, CLAT, DHCP Option 108, DNS64, Enterprise, IPv6, IPv6 Transition, IPv6 Translation, Microsoft, NAT64, Option 108, WinCLAT, Windows 11, Windows CLAT
Tagged , , , , , , , , , , , , , , , ,

Posted by Richard M. Hicks on September 28, 2026

https://directaccess.richardhicks.com/2026/09/28/how-windows-clat-winclat-discovers-the-nat64-prefix/

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

3 Comments
by Richard M. Hicks on August 25, 2025  •  Permalink
Posted in 464XLAT, administration, CLAT, Deployment, DHCP, Dynamic Host Configuration Protocol, Enterprise, Infrastructure, IPv6, IPv6 Transition, Microsoft, Operational Support, PowerShell, systems management, transition technology, WinCLAT, Windows 11, Windows CLAT, Windows Server 2016, Windows Server 2019, Windows Server 2022, Windows Server 2025
Tagged , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,

Posted by Richard M. Hicks on August 25, 2025

https://directaccess.richardhicks.com/2025/08/25/windows-server-dhcp-and-option-108/

Always On VPN Client IP Address Assignment Methods

When Always On VPN clients connect to the VPN server, they must be assigned an IP address to facilitate network communication. When using Windows Server and Routing and Remote Access Service (RRAS) for VPN services, administrators must choose between Dynamic Host Configuration Protocol (DHCP) and static address pool assignment methods.

DHCP

DHCP is a quick and easy way to handle VPN client IP address assignment. However, there are some drawbacks and limitations associated with this option. Consider the following.

Allocation

DHCP for Always On VPN clients does not work as you might expect. For example, when a VPN client connects, it does not obtain its IP address directly from the DHCP server. Instead, the VPN server leases a block of IP addresses from the DHCP server and manages those on behalf of its clients. On the DHCP server, you will see the Unique ID column of these IP address leases indicating RAS.

Address Block Size

After configuring the VPN server to use DHCP VPN client IP address assignment, the VPN server will automatically lease a block of ten IP addresses from a DHCP server. When this initial block of ten IP addresses is exhausted, the VPN server will lease another block of ten IP addresses. Administrators can increase the size of the requested address block by creating the following registry key on each VPN server.

Key: HKLM\SYSTEM\CurrentControlSet\Services\RemoteAccess\Parameters\IP
Value: InitialAddressPoolSize
Type: DWORD
Data: <size of DHCP pool request>

Alternatively, administrators can download Update-VpnServerDhcpPoolSize.ps1 from my GitHub repository and run it on each VPN server to increase the size of the initial DHCP address pool request.

DHCP Options

The VPN server discards all DHCP option information returned by the DHCP server. The VPN server uses only the IP address from the DHCP lease. The client is unaware of any other information in the DHCP lease.

Subnet

By default, the VPN server will only request DHCP addresses from a scope that matches the same subnet as the IP address assigned to the VPN server’s network adapter. If the VPN server has more than one network interface, it will send DHCP requests from the network interface listed on the Adapter drop-down list, as shown here.

Note: This option is only available on servers configured with multiple network interfaces. Also, if the value is set to Allow RAS to select adapter, it is best to specifically define the network interface where DHCP and DNS requests are made.

Scope Size

When using the DHCP assignment method, ensure the DHCP scope contains enough IP addresses to support the number of concurrent connections expected on all VPN servers.

IPv6

DHCPv6 is not supported on RRAS for VPN client IP address assignment. The only option for IPv6 is prefix assignment.

RRAS in Azure

DHCP is not supported when deploying RRAS in Azure. Administrators deploying RRAS in Azure to support Always On VPN must use the static address pool assignment method. More details here.

Known Issues

When using DHCP with Windows Server 2019 RRAS servers, a known issue prevents this from working correctly. Administrators can download Update-VpnServerDhcpPrivileges.ps1 from my GitHub repository and run it on each VPN server to ensure proper DHCP operation.

Increased Complexity

Since the VPN server leases IP addresses on behalf of clients and discards DHCP option information included in the lease, there’s no real benefit to using DHCP. Using DHCP only adds complexity and introduces another dependency, making the solution more brittle and difficult to manage. Using the static address pool assignment method is a better choice.

Static Pool

Implementation best practices dictate using the static address pool assignment method instead of DHCP. The following is guidance for configuring RRAS to support the static address pool option for VPN client IP address assignment.

Unique Subnet

Using a unique IP subnet is best when using the static address pool assignment method. However, this also requires configuring internal network routing to return traffic for that subnet to the individual VPN server where that subnet is assigned. Each server must have a unique IP address pool assigned. Define static address pools using subnet boundaries when configuring multiple VPN servers. Assigning IP address pools along subnet boundaries simplifies internal network routing configuration. Ensure that assigned IP address pool subnets are large enough to accommodate the total number of concurrent connections expected on each server. Be sure to overprovision to handle failover scenarios.

Same Subnet

Alternatively, administrators can assign VPN client IP addresses from the same subnet as the VPN server’s network interface. Assigning VPN client IP addresses from the same subnet as the VPN server eliminates the need for any internal network routing configuration, simplifying deployment. However, server subnets are often small and may not have enough IP address space to support numerous concurrent VPN connections. Be sure to plan accordingly.

Static IP Addresses

It is possible to assign a static IP address to an individual user. However, assigning a static IP address to a specific device is not. I will discuss static IP address assignments for Always On VPN clients in a future blog post.

Other Limitations

Here are some additional things to consider when creating a VPN client IP addressing strategy.

DNS

Always On VPN clients can be configured to register their IP address in DNS. However, the VPN client configuration controls this setting. The DHCP server does not register IP addresses in DNS when using DHCP. The client registers its IP address in DNS directly after it connects. In addition, a VPN client will receive a different IP address each time it connects to the VPN server. DNS propagation can delay hostname resolution on-premises for remote-connected VPN clients.

Selective Addressing

Regardless of which assignment method is selected, assigning different IP addresses to different types of connections is not possible. For example, a common ask is to assign user connections from one IP address pool and device connections from another. The only option to support this is to use different servers for each type of connection.

Summary

The best practice for IPv4 VPN client addressing is to use the static address pool method with a unique IPv4 subnet per server. Using static address pool assignment provides the most flexible configuration options and eliminates the dependency on internal services, making the solution more resilient and easier to manage. A unique address pool per server ensures that a large enough subnet can be defined to support the expected number of concurrent connections, regardless of the subnet size the VPN server is assigned to. Also, a unique IP subnet for VPN clients makes configuring internal firewall rules to control VPN client access easier.

Additional Information

Always On VPN and IPv6

Always On VPN Client DNS Server Configuration

Always On VPN Routing Configuration

Always On VPN RRAS Internal Interface Non-Operational

Leave a comment
by Richard M. Hicks on February 12, 2024  •  Permalink
Posted in administration, Always On VPN, AOVPN, Deployment, device tunnel, DNS, Enterprise, enterprise mobility, Geographic Redundnacy, GitHub, Infrastructure, IPv6, Microsoft, Mobility, Operational Support, PowerShell, Remote Access, routing, routing and remote access service, RRAS, user tunnel, VPN, Windows 10, Windows 11, Windows Server 2016, Windows Server 2019, Windows Server 2022
Tagged , , , , , , , , , , , , , , , , , , , ,

Posted by Richard M. Hicks on February 12, 2024

https://directaccess.richardhicks.com/2024/02/12/always-on-vpn-client-ip-address-assignment-methods/

« Older Posts