IPv6 support?

[zbugrkx]

Hi,

I just found this tool after tons of google searching for a solution to my particular issue and wondering if this could help?

NCSI does not want to consider a nat66 ipv6 address as "internet" despite it working just fine and will set the netconncetionprofile for ipv6 to localnetwork . This causes everything to prefer ipv4

Does this tool also changes the values etc for ipv6 or is it ipv4 only?

Thanks!

[djdarcy]

Hi @zbugrkx, interesting question.

Today the tool is IPv4-only. It redirects only the IPv4 NCSI active web probe (ActiveWebProbeHost / ActiveWebProbePath in the registry plus a hosts-file entry), runs an IPv4 HTTP server, and detects the local IPv4 address. It does not touch any of the IPv6 (...V6) registry values, add an IPv6 hosts entry, or listen on an IPv6 socket. So it won't currently change anything about how Windows classifies IPv6.

But...

The longer, more useful answer -- and why your NAT66 case is tricky: what you're describing is probably Windows' passive NCSI probe, not the active one this tool overrides. Every ~15 seconds Windows checks, per interface, whether that interface has a "global unicast IPv6 address" (GUA). With NAT66 your client typically only has a unique local address (a ULA -- an fd00::/8 address) and no GUA, so Windows hits its internal NoGlobalAddress condition and downgrades the interface's IPv6 to "local network", regardless of whether traffic actually works. (Windows internals expert Gary Nebbett confirms this exact mechanism here: https://learn.microsoft.com/en-gb/answers/questions/1333548/ncsi-passive-probe-not-working-ipv6 )

That's the catch: this tool works by intercepting the active probe and answering it locally. It cannot satisfy a passive check that is specifically looking for a real GUA on your adapter, and I don't think pointing the IPv6 probe at a loopback/local address would be credited to your actual network interface. So even a future IPv6 version of this tool likely wouldn't fix a ULA-only NAT66 setup. I suspect a proper fix for that scenario is router-side.

RE: router-side I can make some suggestions on how to fix this if you are interested.

Caveat: there is a case the NCSI-Resolver tool may be able to help with, but I want to find out if you're in it first. If your interface does have a GUA and Windows is still saying "no internet" on IPv6, that points to the active probe being intercepted/blocked (the IPv6 twin of the exact problem this tool already solves for IPv4), which should be fixable. To tell which situation you're in, could you paste the output of these (run in an admin PowerShell)?

Get-NetConnectionProfile | Format-List Name, IPv4Connectivity, IPv6Connectivity, NetworkCategory

netsh interface ipv6 show address

Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Services\NlaSvc\Parameters\Internet' | Select-Object ActiveWebProbeHostV6, ActiveWebProbePathV6, ActiveWebProbeContentV6, ActiveDnsProbeHostV6, ActiveDnsProbeContentV6, EnableActiveProbing

The main thing we're looking for in netsh interface ipv6 show address is whether you have any Public (global) address or only Unique Local (fd..) / Link-Local (fe80..) ones. That detail ultimately decides whether this is "router needs to hand you a GUA" (can't fix from Windows) vs. "active probe is being blocked" (fixable).

FWIW: I'm scoping a small IPv6 diagnostic for the tool that would print exactly this verdict automatically, and (only if testing proves it actually changes Windows' reported state) an optional IPv6 active-probe redirect for the GUA-present case. I'm hesitant to ship a redirect I haven't watched flip real IPv6 status, so the diagnostic comes first.

Either way your logs will help confirm the actual issue. Should be interesting!

[djdarcy]

@zbugrkx
update: I've built an experimental IPv6 path on a branch for you to test. I'd appreciate your help testing it since you have a NAT66 setup that's exhibiting the "no internet, secured" issue I can't as easily reproduce solo.

I moved the discussion (with instructions on how to try the new IPV6 code) to issue #9 to make the feature request easier to track. Here is the exact comment explaining how to test the new IPv6 code: #9 (comment)

Please feel free to comment there to continue the convo!