Windows Server DHCP and Option 108

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 Plans to Extend CLAT Support in Windows 11

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

RFC 8925 – IPv6-Only Preferred Option for DHCPv4

IPv6 Buzz Podcast on PacketPushers.Net

Always On VPN Windows Server 2025 Binding Handle is Invalid Error

Microsoft released Windows Server 2025 late last year. I’ve been doing extensive testing with the Routing and Remote Access (RRAS) role, commonly deployed to support Always On VPN client connections. I heavily use automation to deploy VPN servers in my lab and for large customer deployments, and after deploying some new Windows Server 2025 machines, I encountered the “binding handle is invalid” error message when running specific commands.

VPN Ports

By default, Windows Server RRAS enables IKEv2 for Remote Access (RAS) and SSTP for RAS and Routing. Each is provisioned with 128 ports. Often, these settings are updated because there are not enough ports to support expected concurrent connections. Also, SSTP should not be enabled for Routing as it is not required, and PPPoE is enabled for Routing, which is also not required. The best practice is to disable any protocols and services that are not being used.

Although updating these settings can be updated in the GUI (rrasmgmt.msc), automating these changes requires command line configuration.

Netsh

Here’s the command to configure additional SSTP ports and disable Routing using netsh.exe.

netsh.exe ras set wanports device = “WAN Miniport (SSTP)” rasinonly = enabled ddinout = disabled ddoutonly = disabled maxports = 500

However, running this command returns the following error message.

“The binding handle is invalid.”

PowerShell

You might be wondering why we don’t use PowerShell for these tasks. Sadly, not all these settings are exposed via PowerShell. For example, with the native Set-VpnServerConfiguration PowerShell command, you can set the number of ports for IKEv2, SSTP, L2TP, and GRE. However, you cannot turn these protocols on or off entirely as you can with netsh.exe commands.

Here’s an example of setting up VPN server port configuration using PowerShell.

Set-VpnServerConfiguration -SstpPorts 500 -Ikev2Ports 500 -PassThru

Note: You must restart the server (not just the RemoteAccess service) when increasing the number of ports beyond the default setting of 128.

Set-VpnServerConfiguration does not support configuration for PPTP. However, PPTP is disabled by default on Windows Server 2025.

Backup and Restore

This issue will also impede the ability to back and restore the RRAS configuration using netsh.exe. You can back up the RRAS configuration by running the following command.

netsh.exe ras dump | Out-File rasconfig.txt -Encoding ascii

You can restore the configuration by running the following command.

netsh.exe exec .\rasconfig.txt

However, you will receive “binding handle is invalid” error when running this command.

AovpnTools

Be advised that the following functions in my AovpnTools PowerShell module use netsh.exe commands that will return the “binding handle is invalid” error message when configuring Windows Server 2025 servers.

Workaround

Until Microsoft resolves this issue, administrators must use a combination of the native PowerShell commands and manual configuration using the Routing and Remote Access management console (rrasmgmt.msc) to implement these settings changes. When backing up and restoring the RRAS configuration, additional configuration will be required after configuration import to ensure the VPN server port configuration is configured correctly.

Additional Information

Always On VPN PowerShell Module on GitHub

Microsoft DirectAccess Formally Deprecated

Today, Microsoft has announced the formal deprecation of DirectAccess. Microsoft DirectAccess is a widely deployed enterprise secure remote access solution that provides seamless, transparent, always-on remote network connectivity for managed (domain-joined) Windows clients. First introduced in Windows Server 2008 R2, it’s been a popular solution with many advantages over ordinary VPN technologies of the past.

Windows Server 2012

DirectAccess was almost entirely rewritten in Windows Server 2012. Many of the features and enhancements offered for DirectAccess with the Unified Access Gateway (UAG – a separate product with additional costs) were built into the operating system directly. In addition, Microsoft introduced integrated load balancing and geographic redundancy features.

Demise of DirectAccess

DirectAccess relies heavily on classic on-premises technologies like Active Directory. All DirectAccess servers and clients must be joined to a domain. In addition, all DirectAccess clients must be running the Enterprise edition of Windows. With organizations rapidly adopting cloud services such as Azure and Entra ID, Microsoft began to develop an alternative solution that better integrated with the cloud. That solution is Always On VPN. With that, Microsoft stopped developing DirectAccess after the release of Windows Server 2012 R2. No new features or capabilities have been added to DirectAccess since that time.

Deprecation

We’ve been speculating about the end of life for DirectAccess for quite some time now. However, this formal deprecation announcement from Microsoft is official. It is the end of the road for this technology. To be clear, though, DirectAccess is available today in Windows Server 2022 and Windows 11. DirectAccess will be included in the upcoming release of Windows Server 2025. However, formal deprecation from Microsoft means they will remove DirectAccess components from the next release of the operating system.

What Happens Now?

Organizations should begin formal planning efforts to migrate away from DirectAccess. Here are a few popular solutions to consider.

Always On VPN

Always On VPN is the direct replacement for DirectAccess. It was designed to provide feature parity for DirectAccess, with seamless, transparent, always-on remote network connectivity. However, Always On VPN better integrates with Entra ID and supports conditional access. It does not require domain-joined devices or servers and works well with cloud-native endpoints. Always On VPN is a good choice for organizations that employ hybrid Entra-joined devices.

Entra Private Access

Entra Private Access, part of the Entra Global Secure Access suite, is an identity-centric zero-trust network access (ZTNA) solution from Microsoft. It is in public preview now and has some compelling advantages over traditional VPNs. However, Entra Private Access is not feature complete today. In addition, it is best suited to cloud-native (Entra-joined only) endpoints.

Absolute Secure Access

Absolute Secure Access (formerly NetMotion Mobility) is a premium enterprise remote access solution with many advanced options. It is by far the best solution on the market today. Absolute Secure Access is a software solution that supports zero-trust configuration and includes many features to improve and enhance security, performance, and visibility. In addition, it provides cross-platform support, including Windows, macOS, iOS, and Android operating systems.

Learn More

We have several decades of experience working with secure remote access technologies. We can help you and your organization find the best solution for your needs. Fill out the form below for a free one-hour consultation to discuss your DirectAccess migration strategy today.

Additional Information

Deprecated Features for Windows Client