Not sure this is the best place to ask, but I'm not sure where else to go at this point... I'm trying to find somebody on the Windows development team that might be able & willing to help me track down some info on a bizarre IPv6 bug I've been chasing in Win10 & its related fix. I can confirm the bug in question was silently fixed somewhere in between 10.0.18362.657 and 10.0.18362.693 and that it seems to be within the tcpip.sys component, but the release notes for KB4535996 make zero mention of it. The fix has also seemingly never been backported to LTSC 2019. Essentially the problem is that, in a dual-stack environment, if a DNS lookup returns both an A and an AAAA record, Windows will prefer to make a connection to the target host via v4, claiming that it chose to do so because it is "Prefer[ring] [the] Aoac Interface", as if the given network interface only supports Connected/Modern Standby for IPv4 and not v6. Despite this, with the exact same drivers on the exact same host with the exact same hardware & network interfaces connected to the exact same LAN, the seemingly-fixed tcpip.sys no longer behaves this way. (It actually even works on "buggy" tcpip.sys after a fresh reboot, but only for some undefined amount of time before it reverts to this behavior. My theory is the codepath that is causing this is only *supposed* to be followed while the PC is *actually* asleep & not during normal operation, but some bit in memory is getting flipped when some event occurs, and the logic that is taking this particular bit into account is faulty.) If anybody can put me in touch with somebody who can pull a changelog of tcpip.sys between those two versions, I'd really appreciate it! I'm just trying to better understand the exact nature of the bug & the fix, since a NetTrace would implicate buggy network interface drivers, but that clearly can't be the whole story. And I'd like to figure out if a workaround is available for still-supported Windows versions that do not incorporate the actual fix (e.g., some registry entry that will make Windows ignore the freaking AOAC support reported by the network interface driver...the NetTrace entry implies Windows is following RFC 6724 and that it is considering the IPv6 destination to be "unreachable" [merely because of lack of AOAC support in the driver for IPv6?!], which is clearly not the case). Thanks! -- Nathan Anderson First Step Internet, LLC nathana@fsr.com