Auto detect IPv6 connectivity

[vasild]

Please describe the feature you'd like to see added.

Auto detect if the host has connectivity to the IPv6 network and only attempt to make automatic outbound connections if it has.

Is your feature related to a problem, if so please describe it.

IPv6 is set to reachable by default. If it is not in practice then some outbound connection attempts will be made in vain, trying to connect to IPv6 hosts.

Describe the solution you'd like

If the kernel does not have IPv6 support compiled in then socket(2):

bitcoin/src/netbase.cpp

Line 462 in 79e8247

SOCKET hSocket = socket(((struct sockaddr*)&sockaddr)->sa_family, SOCK_STREAM, IPPROTO_TCP);

should return EAFNOSUPPORT.

Or if the kernel has support, but the error from connect(2):

bitcoin/src/netbase.cpp

Line 527 in 79e8247

if (sock.Connect(reinterpret_cast<struct sockaddr*>(&sockaddr), len) == SOCKET_ERROR) {

is EADDRNOTAVAIL then that means the machine has no IPv6 address configured (but it may be configured later).

In those cases, I guess, we can disable IPv6 with SetReachable(NET_IPV6, false) or at least log a warning prompting the user to explicitly list all reachable networks with -onlynet and omit IPv6 if it is not.

Describe any alternatives you've considered

A workaround would be to list all other networks on onlynet, e.g. if there is connectivity to IPv4 and I2P, use -onlynet=ipv4 -onlynet=i2p.

Please leave any additional context

Inspired by #27213 (review)

[amitiuttarwar]

concept ACK. there have been several reports of nodes running in environments where IPV6 is unreachable. since the code considers it reachable by default, addrman currently persists the unusable addresses and the node periodically attempts to make connections even in those environments.

[kristapsk]

Concept ACK. Last time I checked a lots of ISPs in Latvia still don't support IPv6.

[ajtowns]

is EADDRNOTAVAIL then that means the machine has no IPv6 address configured (but it may be configured later).

If the system can be reconfigured at runtime to make ipv6 available, it seems a bad idea to force the user to also have to restart bitcoind in order for bitcoind to start making/accepting ipv6 connections. (You might also have ipv6 fail due to your router/isp not supporting ipv6, which also may change at runtime)

[vasild]

That is the case currently as well: ifconfig eth0 up/down and IPv4 or IPv6 connectivity comes and goes. Tor or I2P or CJDNS router restart - same, at runtime.

[ValeZAA]

Concept ACK. Last time I checked a lots of ISPs in Latvia still don't support IPv6.

It does not matter. Migration to ipv6 happened. And anyway, here everyone mobile or optical fibre ISPs support ipv6.

[ajtowns]

That is the case currently as well: ifconfig eth0 up/down and IPv4 or IPv6 connectivity comes and goes. Tor or I2P or CJDNS router restart - same, at runtime.

Sure: but the way that works is if you configure bitcoind for tor/i2p/etc, and if it goes down for a while, bitcoind will continue working once it comes back up again (and emit log messages about it in the meantime). ipv6 handling shouldn't be worse than that.

[vasild]

@ajtowns, what about something like this:

1. at startup check IPv6 support in the kernel - create a dummy socket and close it. If socket() fails with EAFNOSUPPORT, then disable IPv6 permanently
2. otherwise assume IPv6 is reachable; if connect() fails with EADDRNOTAVAIL then disable IPv6 for some time and after that re-enable it

[ajtowns]

@ajtowns, what about something like this:

1. at startup check IPv6 support in the kernel - create a dummy socket and close it. If `socket()` fails with `EAFNOSUPPORT`, then disable IPv6 permanently

2. otherwise assume IPv6 is reachable; if `connect()` fails with `EADDRNOTAVAIL` then disable IPv6 for some time and after that re-enable it

Why not just do (2) on its own?

I think there's a few different ideas here other than what's described in the OP:

• don't waste the computer's time attempting connections that will fail (described here)
• don't fill up the log with unreachable ipv6 connection attempts when net debug logging is enabled - p2p: Diversify automatic outbound connections with respect to networks #27213 (comment)
• make it slightly more likely to choose reachable addresses for outbound attempts - Auto detect IPv6 connectivity #28061 (comment)
• others?

The first two of those don't seem super important to me -- better to waste computer time than people time, and net debug logs are always going to be super noisy anyway. Just doing (2) seems like it would get a modest improvement on the first two, and a good improvement on the last, so seems fine to me.