-
-
Notifications
You must be signed in to change notification settings - Fork 3.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
enable IPv6 by default #9285
base: master
Are you sure you want to change the base?
enable IPv6 by default #9285
Conversation
Modify all IPv4 variables, function arguments name and daemon arguments to IPv4 specific naming to raise consistency with IPv6. This change is done in order to make source code more legible before addressing monero-project#8818. * --p2p-bind-ip is replaced with --p2p-bind-ipv4-address * --p2p-bind-port is replaced with --p2p-bind-port-ipv4 * --rpc-bind-ip is replaced with --rpc-bind-ipv4-address * --rpc-restricted-bind-ip is replaced with --rpc-restricted-bind-ipv4-address Bug: monero-project#8818
* --p2p-bind-port-ipv4 is replaced with --p2p-bind-ipv4-port * --p2p-bind-port-ipv6 is replaced with --p2p-bind-ipv6-port
To ensure retro compatibility, legacy IPv4 daemon arguments and configuration settings changes are marked as deprecated, but can still be used falling back to new option name when new options are not used. Raise warning in case legacy option are used. * --p2p-bind-ip is an alias to --p2p-bind-ipv4-address * --p2p-bind-port is an alias to --p2p-bind-ipv4-port * --p2p-bind-port-ipv6 is an alias to --p2p-bind-ipv6-port * --rpc-bind-ip is an alias to --rpc-bind-ipv4-address * --rpc-restricted-bind-ip is an alias to --rpc-restricted-bind-ipv4-address
Address backlog item to resolve IPv6 address in addition to IPv4 address. See: monero-project#8818
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 155475d ("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 See: monero-project#8818 See: https://www.google.com/intl/en/ipv6/statistics.html See: https://www.vyncke.org/ipv6status/
@vtnerd what is your opinion on IPv6 enabled by default and risk of Sybil attack? |
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 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. |
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.
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.
From this we can derive that /32 is probably a good bet. However, I propose something similar to the following:
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. |
+1 for enabling IPv6 by default, IPv6 is a huge improvements for P2P applications |
This patch series goes on top of #9279 and is targetting to address #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 155475d ("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.
Also add IPv6 only nodes I own in default node list.