Showing IPV6 even when I have disabled it

[contibru]

Even with IPV6 disabled, the command vm debug keep saying that I have it enabled.

Is this right?

[coreybutler]

Are you sure it is disabled? The check pings the local ipv6 address. If it responds, your system is actively listening for connections on that ip address. See

nvm-windows/src/web/web.go

Line 71 in 94f952a

conn, err := net.Dial("tcp", "[::1]:80")

.

[contibru]

I am pretty sure it is disabled:

I was looking at the code and I am not sure if this IF is ok (Shouldn't it be without the denial?):

nvm-windows/src/nvm.go

Line 1159 in 94f952a

} else if !ipv6 {

[coreybutler]

It's still enabled for bluetooth. That's probably why NVM4W is picking it up. That said, I'll check that line... you may be right that there is a false positive.

[contibru]

This is still happening, I just did a test turning the nvm-windows off and then executing the npm i directly from the node installation folder and it works perfectly and pretty fast.

[NiKiZe]

Why is it slow with IPv6 enabled (any pointers appriciated)
Disabling IPv6 should never be recommended or even suggested. It is the current standard Internet Protocol, and I dread the day you have some one disable it, and then loose all internet connectivity.

I guess that the real issue is that some server is startarted on 127.0.0.1 or some kind of such bad practice, and then called by a localhost lookup?

[coreybutler]

NVM for Windows uses the OS for network calls (which is just how Go does it). There is a very real chance that any issues with IPv6 have been resolved in Windows updates since this was written.

I don't know why this happens. It was a recommended solution on Microsoft's docs, for general networking issues. I came across it while researching the issue (I do not remember the link off the top of my head), but I don't have time to troubleshoot Microsoft's network stack.

To be clear, the recommendation is not to turn off IPv6 unless this is a blocking issue.

[NiKiZe]

Ok, thanks that might be enough to go on... I don't think this should have been an issue since Go 1.12.
Is the failure here most often seen when NVM goes out to do a http download? or anything else?

Feel free to ping me on any thread/issue that seems IPv6 issue related.

I think the issue is misunderstood, blaming the network stack for bad network configuration, When connecting, if anything has an IPv6 address, (when checking DNS), and the network is reachable (there is a route for it) then that takes priority, and should be tried first. (As by RFC, if IPv6 is misconfigured, this will fail, and isn't uncommon. (let's say you would configure a bad gateway address in your IPv4 settings, that isn't an OS problem)

The way "around" this is called Happy Eyeballs* (there is a few different RFCs for this, but we don't have to go into that.) which essentially makes sure to start multiple connection attempts, and then use the connection that succeeds. This seems to finally have been enabled by default in Go 1.12 golang/go#22225

Microsoft does strongly recommend against disabling anything IPv6 from vista and onwards, things will break.

• Since Happy Eyeballs are implemented in most software, it actually hide actual IPv6 configuration problems instead of exposing them.

[contibru]

This was some time ago, but If I remember corretcly, I tried disable the IPV6 because the npm i command was taking too much time. And then even disabling it, it shows as enabled by nvm debug.

At the time I remember to turn nvm off and then the speed was pretty fast than using nvm.

[coreybutler]

@NiKiZe thanks for the insights. Go 1.12 is quite old. Even the old versions of NVM4W only go back to v1.18. I believe you're correct that misconfigured IPv6 is typically the root cause, but there are a lot of ways to misconfigure something ;-) I don't think NVM4W should be responsible for guiding users through fixes, aside from notifying users they need to check their IPv6 config. Perhaps the language in the debug output could better reflect that.

@contibru this sounds like something else was going on, because NVM4W has nothing to do with npm. NVM4W's only job is downloading or removing installations of Node and setting the symlink that points to the executable. That's it. When you run npm, it is interacting directly with Node.

If nvm debug still shows IPv6 even when it is turned off, it is possible NVM4W IPv6 check is outdated or different from locale to locale. I remember the check being a bit hacky because there was no direct way to check for IPv6 at the time. Again, there's a more robust way to do it now.

[NiKiZe]

Agree, you shouldn't guide fixes, you should do just as much for bad IPv6 as you do for bad IPv4.
I understand that some software get reports when it's "just their application" that isn't working. When in reality it is bad configs, and this swings both ways. If I have working v6 but bad v4 route config then GitHub desktop would be buggy.

Every properly working machine must have a working ::1, otherwise I would say it is miss configured (I'm fully aware that not everyone agrees with this statement)