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

default cluster.listen_multiaddress is legacy IP only #1000

Closed
RubenKelevra opened this issue Feb 2, 2020 · 6 comments
Closed

default cluster.listen_multiaddress is legacy IP only #1000

RubenKelevra opened this issue Feb 2, 2020 · 6 comments
Labels
exp/novice Someone with a little familiarity can pick up help wanted Seeking public contribution on this issue kind/enhancement A net-new feature or improvement to an existing feature status/ready Ready to be worked

Comments

@RubenKelevra
Copy link
Collaborator

Additional information:

  • OS: Linux
  • IPFS Cluster version: 0.12.1
  • Installation method: binary

Describe the bug:

The default configuration of ipfs-cluster-service only creates IPv4 entries for the cluster connections on port 9096 (+quic). The IPv6 entries have to be added manually.

Why?

@RubenKelevra RubenKelevra added kind/bug A bug in existing code (including security flaws) need/review Needs a review labels Feb 2, 2020
@hsanjuan hsanjuan added kind/enhancement A net-new feature or improvement to an existing feature status/wontfix This will not be addressed and removed kind/bug A bug in existing code (including security flaws) need/review Needs a review labels Feb 3, 2020
@hsanjuan
Copy link
Collaborator

hsanjuan commented Feb 3, 2020

It is the safest default. For this, I think it is reasonable that the user configures it the way it works for them... at least for the time being

@RubenKelevra
Copy link
Collaborator Author

@hsanjuan what's unsafe about using IPv6? 🤔

In many countries, you only get IPv4 with very bad carrier-grade nat for private internet connections. But you get a public IPv6 which can let you establish reliable connections.

If you configure only IPv4 by default on the servers, you end up with a lot of use of relay hopping inside the cluster, or connection issues.

@hsanjuan
Copy link
Collaborator

hsanjuan commented Feb 3, 2020

Well, the first question I have is whether it blows up whenever it starts on a device without ipv6 interfaces/config.

@RubenKelevra
Copy link
Collaborator Author

I don't think there's a OS out there which doesn't have IPv6 enabled by default.

The worst case is, that you open 1-2 ports on ::1, depending if you have quic enabled or not, and never use them.

If you got an idea which OS have no IPv6 out of the box, let me know and I'll set up a VM and test it.

Also: Just for this one weird edge case I wouldn't disable IPv6 by default. We don't have new IPv4 to allocate in nearly all regions. Which will lead to more and more crude workarounds by providers.

@hsanjuan hsanjuan removed the status/wontfix This will not be addressed label Feb 3, 2020
@hsanjuan
Copy link
Collaborator

hsanjuan commented Feb 3, 2020

Fair enough, mind sending a PR? cluster_config.go, api/restapi/config.go, api/ipfsproxy/config.go have default listen addresses. The last two need a small adaptation so we can parse both a string and an array from the json, this was already fixed in cluster_config.go -> using ipfsconfig.Strings.

@hsanjuan hsanjuan added exp/novice Someone with a little familiarity can pick up help wanted Seeking public contribution on this issue status/ready Ready to be worked labels Feb 3, 2020
@Luflosi
Copy link

Luflosi commented Aug 5, 2022

@RubenKelevra did #1010 resolve this issue? If so, it can be closed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
exp/novice Someone with a little familiarity can pick up help wanted Seeking public contribution on this issue kind/enhancement A net-new feature or improvement to an existing feature status/ready Ready to be worked
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants