Skip to content
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

Open
wants to merge 6 commits into
base: master
Choose a base branch
from

Conversation

bjacquin
Copy link
Contributor

@bjacquin bjacquin commented Apr 9, 2024

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.

  • --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.

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/
@selsta
Copy link
Collaborator

selsta commented Apr 9, 2024

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

@vtnerd
Copy link
Contributor

vtnerd commented Apr 14, 2024

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
Copy link
Contributor Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants