enable IPv6 by default

[bjacquin]

This patch series goes on top of https://github.com/monero-project/monero/pull/9279 and is targetting to address https://github.com/monero-project/monero/issues/8818 by enabling IPv6 by default for P2P and RPC.

As of 2024-04-01, IPv6 represents ~43% of traffic entering Google with up to 75% is some country, and in generally more available when IPv6 was introduced in Monero in 2019 as part of 155475d97196 ("Add IPv6 support").

Monero overall has a very low presence over IPv6 which in part can be explained from the fact that IPv6 need to be specifically enabled before it is used and often requires nodes to be manually added in configuration.

This commit enabled IPv6 by default for both RPC and P2P as an attempt to improve Monero network mesh diversity.

The change has been tested in a lot of different scenario: IPv4 only, IPv6 only, IPv4+IPv6, IPv4+IPv6 with broken/invalid IPv4 system configuration, IPv4+IPv6 with broken/invalid IPv6 system configuration.

• --p2p-use-ipv6 is now deprecated and has no effect
• --p2p-ignore-ipv6 is introduced to ignore unsuccessful IPv6 P2P binding
• --rpc-use-ipv6 is now deprecated and has no effect
• --rpc-ignore-ipv6 is introduced to ignore unsuccessful IPv6 RPC binding

Also add IPv6 only nodes I own in default node list.

[selsta]

@vtnerd what is your opinion on IPv6 enabled by default and risk of Sybil attack?

[vtnerd]

It will make sybil attacks easier - we currently prefer IPv4 connections to different class B networks. There's no similar logic to IPv6 that can be added afaik.

Perhaps a blended mode where a portion of the out connections is guaranteed to be IPv4? I'm not certain what other p2p applications do here (I can check if you want).

[bjacquin]

It will make sybil attacks easier - we currently prefer IPv4 connections to different class B networks. There's no similar logic to IPv6 that can be added afaik.

Perhaps a blended mode where a portion of the out connections is guaranteed to be IPv4? I'm not certain what other p2p applications do here (I can check if you want).

The concern about sybil attacks is valid here, however having IPv6 disabled by default just hides the issue, all users defining --p2p-use-ipv6 today are vulnerable or at least subject to it.

For reference, code involved to prefer IPv4 connection to different class B today: https://github.com/monero-project/monero/blob/master/src/p2p/net_node.inl#L1546

I'd like to propose to address IPv6 sybil attacks by using a similar approach by preferring connecting to IPv6 nodes in different /48 network as specified in rfc3177, although it has been deprecated in favour of rfc6177, which no longer provide any particular requirement for end site address assignment.

Regardless of this, AWS, Google Cloud offer /56 CIDR VPC while offer /48 to its customer for further chunking. ISP very often offer /60 to customer. There is of course no rule of thumb that will fit all use case, however would be more particular than today's scenario. If /48 selected as a starting point, it could further be improved over time if needed.

[86dd]

It will make sybil attacks easier - we currently prefer IPv4 connections to different class B networks. There's no similar logic to IPv6 that can be added afaik.

Sybil attacks are also very much possible on IPv4, if you take into contrast just how many large cloud providers have received or bought massive blocks.

Perhaps a blended mode where a portion of the out connections is guaranteed to be IPv4? I'm not certain what other p2p applications do here (I can check if you want).

Not a good idea, there are already many IPv6 only networks, even without IPv4 translators.

Leaving IPv6 disabled makes the network less future proof for IPv6 and less resilient, here is my proposal for preferring different networks.

Standard network size is /64.
    BGP: Typically, the longest prefix that can be announced is a /48.
    BCP: ISPs should assign /56 to each end site.
         Residential ISPs usually assign a /48 to /60.
         Cloud ISPs usually assign a /64 to /128.

Standard and maximum initial allocations of RIRs are below. If one requires more than that, extra paperwork is to be presented.
AFRINIC: /32
         https://www.afrinic.net/policy/manual#Allocations-Assignments-Policies
   ARIN: /32
         https://www.arin.net/participate/policy/nrpm/#6-5-2-initial-allocation-to-lirs
  APNIC: /32
         https://www.apnic.net/community/policy/resources#a_h_8_1
 LACNIC: N/A       
   RIPE: /29
         https://www.ripe.net/publications/docs/ripe-738/#51-initial-allocation

From this we can derive that /32 is probably a good bet. However, I propose something similar to the following: Personally, I do rate-limiting on a /64, then /56, then /48 basis. No larger simply because it would then affect too many other customers from one ISP.

So maybe we do node selection based on like
At max   2 nodes from /64,
         4 nodes from /56,
        16 nodes from /48,
       256 nodes from /32.

Please keep in mind that an IPv4 NAT can serve a network with a single /128 to a whole /40 and beyond in use in IPv6, but a host with a /128 can also have a /24 in IPv4 routed to it! Both are different protocols and their address space should not be correlated/connected/compared.

[G10h4ck]

+1 for enabling IPv6 by default, IPv6 is a huge improvements for P2P applications