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
[email protected]

Reply via email to