Auto detect IPv6 connectivity #28061

1. 
   vasild commented at 3:02 pm on July 10, 2023: contributor

   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):

   https://github.com/bitcoin/bitcoin/blob/79e8247ddb166f9b980f40249b7372a502402a4d/src/netbase.cpp#L462

   should return EAFNOSUPPORT.

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

   https://github.com/bitcoin/bitcoin/blob/79e8247ddb166f9b980f40249b7372a502402a4d/src/netbase.cpp#L527

   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#pullrequestreview-1516531774

2. vasild added the label Feature on Jul 10, 2023
3. 
   amitiuttarwar commented at 6:35 pm on July 12, 2023: contributor

   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.
4. 
   kristapsk commented at 7:00 pm on July 12, 2023: contributor

   Concept ACK. Last time I checked a lots of ISPs in Latvia still don’t support IPv6.
5. 
   ajtowns commented at 1:45 am on July 13, 2023: contributor

   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)

6. 
   vasild commented at 5:24 pm on August 14, 2023: contributor

   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.
7. 
   ValeZAA commented at 6:50 pm on August 14, 2023: none

   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.

8. 
   ajtowns commented at 2:45 am on August 18, 2023: contributor

   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.

9. 
   vasild commented at 3:30 pm on August 24, 2023: contributor

   @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
10. 
    ajtowns commented at 10:26 am on August 25, 2023: contributor

    @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 - #27213 (comment)
    • make it slightly more likely to choose reachable addresses for outbound attempts - #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.

Contributors
vasild amitiuttarwar kristapsk ajtowns ValeZAA

Labels
Feature