Some content on this site is available only to logged-in subscribers. Contact Us for information on becoming a subscriber.

InSource.Solutions | InSource Training | InSource Client Portal
InSource Solutions Logo
Log In Sign Up
InSource.Solutions InSource Training InSource Client Portal Log In Sign Up
  • Home
  • AVEVA General
  • AVEVA General Tech Notes

TN - G - 26092208 Resolving IPv6 Precedence & Hostname Resolution Binding Issues

Last updated: September 22nd, 2026

Description

  • Author: James Rochester
  • Published: September 22nd, 2026

Details:

  • Document Version: 001
  • Applies to Version(s): Windows Server / Windows Desktop Environments (AVEVA System Platform, Historian, & License Server Host Environments)

 

 

Description  

This tech note describes how to resolve IPv6 Precedence & Hostname Resolution Binding Issues

Issue Overview

When IPv6 is enabled by default in Windows, system name resolution (DNS/NetBIOS) prioritizes IPv6 address lookup (AAAA records / ::1 loopback) over IPv4 (A records / 127.0.0.1).

This is an example of IPV6 taking precedence.

In industrial automation environments—such as those running AVEVA Historian search services, License Manager endpoints, or local SuiteLink communications—this can lead to:

  • High latency or timeouts during local service-to-service communication.
  • Object Deployment failures to remote nodes.(Platform deployment failures)
  • Service configuration failures such as Historian Search failing to configure.
     
  • Services attempting to bind to ::1 instead of 127.0.0.1 or the primary IPv4 network interface card (NIC).
     
  • Failed remote node hostname resolution when dual-stack network adapters are present.
     

Solution Steps:

In order to force Windows to prefer IPv4 over IPv6 without fully disabling the IPv6 stack (which can break core OS components like Remote Desktop or Windows Update), apply Microsoft’s standard dual-stack prefix policy preference via the Windows Registry, enforce local IPv4 loopback mappings, and clear local resolution caches.

Registry Value Warning:

Do not set DisabledComponents to 0xFFFFFFFF (completely disabling IPv6). Unbinding IPv6 entirely can cause unexpected failures in modern Windows services, Windows Remote Management (WinRM), and certain database engine components that expect the dual-stack interface to remain active. Using value 0x20 safely shifts preference to IPv4 while leaving the stack functional.       

 

 

1.Configure Registry to Prefer IPv4 over IPv6:Requires System Reboot.

Modify the DisabledComponents registry value to prioritize IPv4 in the Microsoft prefix policy table instead of completely binding off the IPv6 protocol driver.

Open PowerShell or Command Prompt as Administrator.

Run the following command to set IPv4 precedence:

reg add "HKLM\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters" /v DisabledComponents /t REG_DWORD /d 0x20 /f

Verification: To confirm the value was applied correctly before rebooting, run:

reg query "HKLM\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters" /v DisabledComponents

The output should display 0x20 (32 in decimal).

2.Enforce Local IPv4 Mapping in Hosts File: Optional / Recommended for Hostname Binding.

To prevent internal applications (such as local Historian search services or licensing daemons) from attempting loopback calls over IPv6 (::1), force explicit local IPv4 mappings.

Open Notepad as Administrator.

Navigate to and open:

C:\Windows\System32\drivers\etc\hosts

Ensure the local IPv4 mapping is active and explicit, and comment out or remove explicit ::1 entries if they are overriding local hostname bindings:

127.0.0.1       localhost
127.0.0.1       <LOCAL_HOST_NAME>

Save and close the file.

3.Flush Network Caches and Reset Stack

Clear out cached IPv6 name resolutions from the local Resolver Cache and reset interface statistics.

Open PowerShell or Command Prompt as Administrator.

Execute the following sequential commands:

ipconfig /flushdns
nbtstat -R
netsh interface IP reset

Verification: Check for the response Successfully flushed the DNS Resolver Cache.

4.Reboot System

Reboot the machine to allow the TCPIP6 registry changes and driver prefix policies to take effect.

5.Verify IPv4 Precedence Post-Reboot

After the system restarts, verify that ICMP and network diagnostic utilities default to IPv4.

Open CMD and run a ping against the local hostname and loopback:

ping localhost
ping $env:COMPUTERNAME

Expected Result: The reply must return an IPv4 address (127.0.0.1 or the assigned static IPv4) rather than ::1 or an IPv6 address.

                              _____________________________________________________________________________________________________

 

ipv4 ipv6 binding
Give feedback about this article

Recommended articles

[ISS Support Case] Time Synchronization on Standalone InTouch Nodes

Customer has a few standalone InTouch nodes that are not part of a domain. They want to be able to sync the time on each node so they are all the same but are not 100% sure how to do that without a domain. The Net Time command doesn't seem to be working for them.

Read More

[ISS Support Case] Platforms stuck connected but in store forward

After a historian reboot, many platforms will not come out of store forward. the connected is off then back on when historian reboot is complete but stuck in store forward. two ways to clear - reboot the client. or browse to client via SMC and take platform off scan and put back on scan. toggling the connect statecmd nor toggling scanscate command will clear issue.

Read More
Support Icon

CONTACT SUPPORT

How to reach us

10800 Midlothian Turnpike Tpke, Suite 209, Richmond, VA 23235

1.877.INSOURCE

Technical Support - 1.888.691.3858

Contact Us

  • InSource Solutions
  • InSource Training
  • InSource Client Portal
  • Log In
InSource Solutions Group Logo

© 2026 InSource Solutions. All Rights Reserved.

Knowledge Base Software powered by Helpjuice

Expand