net: node on Linux allows opening a connection to `0.0.0.0`/`::` while on Windows it doesn't

[refack]

• Version: master
• Platform: Windows
• Subsystem: net

Refs: #14865
Refs: #14111

Linux converts the ipv6 address "::" to "::1", while windows does not.

This makes server.address().address useless [as a target address] when bound to IPv6 localhost 0.0.0.0 or :: on Windows.

[addition]
Specifically the use of server.address().address for initiating new connection:

const server = net.createServer(() => {});
server.listen();
server.address().address === '::';
net.connect(
  { port: server.address().port, host: server.address().address }
); // throws 'Error: connect EADDRNOTAVAIL :::56210'

While apparently Linux does allow opening a connection to the :: unspecified address

[gibfahn]

See #7291 (comment), basically using localhost should work, but on some machines this doesn't, hence common.IPv6Hosts:

node/test/common/index.js

Lines 169 to 183 in 9ecc440

	exports.localIPv6Hosts = ['localhost'];
	if (exports.isLinux) {
	exports.localIPv6Hosts = [
	// Debian/Ubuntu
	'ip6-localhost',
	'ip6-loopback',
	// SUSE
	'ipv6-localhost',
	'ipv6-loopback',
	// Typically universal
	'localhost',
	];
	}

The ideal solution would be to fix IPv6Hosts (see #7288 (comment)), however localhost should be fine for most machines.

Bunch of related Issues/PRs:

• Inconsistencies with IPv6 endpoint specification across platforms #7728
• test: avoid connecting to :: in test-net-timeout #7781
• test: Avoid usage of mixed IPV6 addresses #7702
• test: don't connect to :: (use localhost instead) #10854
• win: gc/test-net-timeout.js failure in v6.2.1 #7291

[bnoordhuis]

Linux converts the ipv6 address "::" to "::1", while windows does not.

BTW, that doesn't sound right: :: (or ::0) is the 'any' address, ::1 is the localhost address.

I suspect that 'any' on Windows doesn't include localhost, whereas it does on Linux.

[refack]

BTW, that doesn't sound right: :: (or ::0) is the 'any' address, ::1 is the localhost address.

I suspect that 'any' on Windows doesn't include localhost, whereas it does on Linux.

That makes more sense, so why does Linux allow net.connect({ port: X, host: '::' }); or even net.connect({ port: X, host: '0.0.0.0' });

[refack]

The ideal solution would be to fix IPv6Hosts (see #7288 (comment)), however localhost should be fine for most machines.

After @bnoordhuis's comment I feel like the disparity is deeper than just test cases.
Changed title.

[bnoordhuis]

This isn't something for node to solve though. I can tweak routing rules on Linux to exclude lo from :: or 0.0.0.0 and I'm sure you can do the reverse on Windows.

Node papers over platform differences when it's feasible and makes sense but that isn't the case here.

[refack]

This isn't something for node to solve though. I can tweak routing rules on Linux to exclude lo from :: or 0.0.0.0 and I'm sure you can do the reverse on Windows.

Seems like on Windows it's always EADDRNOTAVAIL same as port 0 on POSIX:

D:\code$ ROUTE ADD 0.0.0.0 MASK 255.255.255.255 0.0.0.0 METRIC 1 IF 1
 OK!

D:\code$ ping 0.0.0.0

Pinging 0.0.0.0 with 32 bytes of data:
PING: transmit failed. General failure.
PING: transmit failed. General failure.
PING: transmit failed. General failure.

D:\code$ ROUTE print 0.0.0.0
IPv4 Route Table
=====================================================================Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0      192.168.1.1    192.168.1.127     25
          0.0.0.0          0.0.0.0      192.168.1.1    192.168.0.112     45
          0.0.0.0  255.255.255.255         On-link         127.0.0.1     76
=====================================================================

So IMHO this disparity needs to be addressed at least with a note in the documentation.
Somewhere around https://github.com/nodejs/node/blob/master/doc/api/net.md#socketconnect

*Note*: Attempting to connect to port 0 will err with `EADDRNOTAVAIL`.
On Windows attempting to connect to address 0 (`'0.0.0.0'` or `'[::]'`) will cause the same error.

[bzoz]

Fixed in libuv 1.19.0 (libuv/libuv@2b32e77)