Where is Dat on IPv6 support?

Neither the local network mDNS nor the global DNS peer-discovery services currently support IPv6.

What is the plan for IPv6? Where is IPv6 support on the Dat roadmap?

Having globally reachable unique address for every node that isn’tencumbered by NAT should really help with connectivity.

1 Like

There’s currently no plan for IPv6 in Dat. Hyperswarm isn’t shipping with it, and I don’t think it’s going to be much of a priority. I think the reasoning I heard was that IPv6 support is still pretty bad and it’d be a lot of maintenance overhead for not enough payoff.

1 Like

Also of interest is the IPv6 issue with bittorrent-dht.

and more directly:

1 Like

I researched a little about ways to add IPv6 to DAT.

At the core there is the problem of ipv4-peers which is used by dht-rpc to emit and store peer URLs. Holepunching is important for IPv6 as well which means you need to be able to transfer IPs. This is used in the upcoming hyperswarm/dht. The current implementation uses
bittorrent-dht in which the ip-encoding is baked in. There is a 3 year old PR thought implements ipv6 support but it adds quite a bit of complexity. Imo bittorrent-dht would also profit of using an external library for encoding/decoding.

Part two applies to the other part of lookup used: multicast-dns & dns lookup. In the old version dns-discovery also has ipv4 support baked in which would need to be replaced similarly to the dht support. The new implementation uses multicast-dns which adds udp holepunching and has an option for IPv6 but it is problematic to use.

A tricky third problem is with that in DAT both dns and dht are combined and that the peers need de-duplication. After all the same peer could come in through several lookup methods (if it announces through various articles). Being able to reach a IPv6 address depends on routers between two address. Which means that three peers (A, B, C) could all support IPv6 but if the routers between A & C don’t support IPv6 then an IPv4 fallback needs to be used for this communication only. Should IPv6 be preferred even though IPv4 works? Should IPv6 only be tried if IPv4 fails? What if the IPv4 address is lost or changed (IP’s can change during runtime): Shouldn’ the IPv6 address be retried before removing the peer from the peer list? That means we need to store more information with the peers we keep.


Just want to clarify on this:
The old discovery-tracker (ab)used DNS as a wire protocol but it wasn’t really DNS. The new discovery-tracker (hyperswarm/dht) won’t use DNS as a wire protocol. It will still use multicast DNS for local discovery, but that’s an orthogonal system.

The difficulties of IPv6 you list after that all sound correct.

1 Like

Some important numbers:

One in four devices that talk to Google services now use IPv6 [1].

94 % of mobile ISPs deploy Carrier Grade NAT (CGN) for IPv4 worldwide[2, p. 22]. 17 % of residential ISPs (particularly in Europe and Asia) use CGNs [2, p. 22].

Customers of these ISPs share IPv4 addresses with other customers. I can’t find numbers of how many ISPs that use CGNs also deploy IPv6. Hopefully, it’s the majority and they’re the driving force behind the recent increase in IPv6 deployments.

Talking to mafintosh on IRC a while ago, it seems that the main thing that’d need to be done is a new ipv6-peers module modeled after https://github.com/mafintosh/ipv4-peers/

From there we could get a second DHT going for IPv6 inside hyperswarm/discovery and that should be sufficient for the support we’d need.