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.