🗿 Kubo in an IPv6 only world 🥚

[Jorropo]

The current state of IPv6 Kubo is not very great, we have some traffic going over IPv6 but Kubo still require an IPv4 connection to work properly (unless you are running a private network and do not expect public network connectivity).

Ideally a Kubo running with access to the IPv6 network exclusively would run at feature parity as a Kubo with IPv6+IPv4.

Todos:

• Start API on both IPv4 and IPv6  #9637
  • corehttp/metrics.go: ERROR with more than one RPC API listener #9397
  • An error has occurred while serving routing_http_client metrics #9891
• Enable Gateway on localhost IPv6 (ip4+ip6 by default) #5905
  • corehttp/metrics.go: ERROR with more than one RPC API listener #9397
  • An error has occurred while serving routing_http_client metrics #9891
• dns free ipv6 bootstrap nodes? #8979
• add ipv6-only mode #7786
• Find out a good way to do P2P networking over statefull ipv6 firewalls
  • holepunch: low IPv6 success rate libp2p/go-libp2p#2068
  • UPNP alternative for v6 statefull firewalls libp2p/go-libp2p#2496
• Run split DHTs for IPv4 and IPv6
  Currently trying to use Kubo with IPv6 networking only leave you with a partial DHT routing table, it mostly works. However it happens frequently that all the 20 final peers are unreachable over IPv6 (due to the statefull nats issue) so your query can't completely to the right part of the keyspace.
  • Stop running split DHTs routing table for client and server when not using the accelerated DHT client #10076
  • autonat: provide different reachability states and callbacks for IPv6 and IPv4 libp2p/go-libp2p#2466
  • Support publishing self-records in LAN DHT even when WAN DHT is available. #7168
  • the composable routers should be powerfull enough to configure multi-dhts setups and we should drop the adhoc dht dual #10075
• cid.contact is not accesible for IPv6 only machines ipni/storetheindex#2136
• Find commun ranges and build LAN dhts using public IPv6 addresses on the same subnet ?

Note: I'm adding an exception to the feature parity, if some data is exclusively hosted on IPv4 nodes, this issue is not interested in working out a way to fetch this data using IPv4 ←→ IPv6 relays. Similarly if some data is exclusively hosted on IPv6 nodes, I am not expecting an IPv4 node to be able to fetch it.

[hacdias]

🎉

[hsanjuan]

booooooo 😆

[galargh]

⭕⭕⭕⭕

[Jorropo]

Note for readers: this issue is not currently prioritized, I've created this task list precisely because I guess fixing all of the elements on this task list are not high priority and so the precious #10000 issue number will remain open for a long time ⏳.
This is also an artificially high bar to meet, you could get acceptable ipv6 networking much faster with quick wins (mainly split DHTs for IPv4 and IPv6).

[deavmi]

I just want to check and to confirm something. I have a Docker instance with IPv4 and IPv6, but sometimes to test v6-only I will disable my host's v4 connection and restart my container.

I see some swarm addresses and the list grows but I want to know, can Kubo work without v4 or does it need it for some part of startup?

I can ping my laptop using ipfs ping between the two and both are IPv6 only (the one has DNS64+NAT64, the laptop). Maybe it's just that most content I am trying to reach has no v6 peers?

Update: I presume it is the above. The laptop and v6 only machine are on different subnets and not discoverable locally. So maybe few v6 accessible content exists.

If anyone has any then please let me know, I would love to test.

Update 2x: Seems like QmZfSNpHVzTNi9gezLcgq64Wbj1xhwi9wk4AxYyxMZgtCG is reachable, just few content then.

---

I rescind my comment but I do urge people to support v6 and get v6 setup at home! Sovereign network!

Keep up the good work fellas.

[Jorropo]

@deavmi Kubo starts with v6, the main problem we have is around network reachability.
A huge part of the network is not reachable.
This should be fixed by:

• Having a dedicated DHT for v6, this would lessen the issues of a partially reachable DHT, currently trying to use the DHT for v6 is a roll of the dice because you can't properly fill up your buckets properly, this cause you to fire your DHT requests in a really wide low density area of the key space (centered around where it should actually be) and the chance you hit one of the proper 20 peers is lower.
  • See Run split DHTs for IPv4 and IPv6 in the list above.
• Solve Networking issues on v6.
  • holepunch: low IPv6 success rate libp2p/go-libp2p#2068
  • UPNP alternative for v6 statefull firewalls libp2p/go-libp2p#2496

[deavmi]

Ah that makes sense.