Enable Gateway on localhost IPv6 (ip4+ip6 by default)

[lidel]

Version information:

0.4.18

Type:

enhancement

Description:

What? How do we feel about migrating default Gateway config to listen on ipv6 as well? For now, this can be enabled manually via:

$ ipfs config --json Addresses.Gateway '["/ip4/127.0.0.1/tcp/8080","/ip6/::1/tcp/8080"]'

Why? It is a cosmetic change that enables much shorter URLs for local gateway and shift focus towards IPFS paths:

How?

Current default:

$ ipfs config --json Addresses.Gateway
/ip4/127.0.0.1/tcp/8080

Proposed change (arrays are supported since https://github.com/ipfs/go-ipfs-config/pull/11):

$ ipfs config --json Addresses.Gateway
[
  "/ip4/127.0.0.1/tcp/8080",
  "/ip6/::1/tcp/8080"
]

Additional notes:

• To avoid socket: address family not supported by protocol error on systems without ipv6 we go-ipfs could detect runtime without ipv6 and ignore multiaddrs starting with /ip6/, as suggested in https://github.com/ipfs/go-ipfs/issues/1675#issuecomment-139111308
• Investigating vanity hostnames for localhost HTTP gateway: https://github.com/ipfs/in-web-browsers/issues/109
  • tl;dr

    AFAIK only 127.0.0.1 and ::1 are whitelisted by browser vendors (eg. firefox #903966) while localhost is not (that is why Companion uses raw IP)

[Stebalien]

We should definitely listen on both. Mind making a PR?

[alanshaw]

...also to JS IPFS 🙏

[da2x]

For what it’s worth, I’ve been running my local gateway on [::1] for almost a year with no issues.

[Kubuxu]

@Stebalien We can include it in upcoming migration, what do you think?

[Stebalien]

SGTM (iff the user is already listening on 127.0.0.1).

[Winterhuman]

@lidel Any update on this?

[lidel]

No update. Browser use case ended up having a better solution in the form of subdomain gateway on {cid}.ipfs.localhost:8080 where each CID gets its own Origin sandbox, so adding ip6 listener lost its utility.

Something we would still want to do is to detect when the system does not support ip4 and then use ip6 instead, but this is low priority since we had no user reports that this is a real issue.

[Faolain]

If it helps at all for bumping this, I'm looking to deploy IPFS on railway for easy deployments for end users with templates. However the issue is that on Railway, all services, which can be seen as a self contained module/dockerfile can only expose 1 port for inbound connections, given that there are a few ports that IPFS exposes the way to go around this is to create more "services" that are simply Caddy reverse proxies which allow users to have access to that inbound port. Now the other issue that arises is that...railway only allows communication within its private network via ipv6. Having this as a default would reduce the need to manually enable ipv6 via config.