BitTorrent tracker not working via IPv6

[Popolechien]

Reported by user:

It looks like IPv6 is broken
Connecting to http://tracker.openzim.org ([http://tracker.openzim.org]> (https://t.co/QWCU3b9tiE))|51.159.30.163|:6969... connected.
Connecting to http://tracker.openzim.org (http://tracker.openzim.org)|2001:bc8:6005:1a:dac4:97ff:fe2a:33d8|:6969... failed: Connection refused.

[rgaudin]

Looks like opentracker needs to be ran (and built) either for v6 or for v4. We'd need to run two trackers to support ipv4 and ipv6.

Do we want to?

http://erdgeist.org/gitweb/opentracker/tree/README_v6

[signout]

I reported this issue (via twitter)
I really like IPv6, but understand if you don't want to maintain two different instances. If that's what you end up deciding then please remove the AAAA record so torrent clients can use the IPv4. rtorrent prefers IPv6 and doesn't use the v4 even if the v6 doesn't answer.

[rgaudin]

Ok I'll remove the record until we decide to act upon this. Thank you for the tip

[signout]

Thank you :)

[rgaudin]

Was a CNAME to another record which had both A and AAAA records. Replaced it with an A record. Please give it a try in like an hour from now and let me know if this works with your client.

[kelson42]

I'm not sure we should not have two instances....

[kelson42]

@rgaudin Considering the already large amount of users using IPv6, we have now to fix this issue if we want a working BitTorrent infrastructure. We should probably considere having another kind of tracker, because having two:

• won't mutualise the peers
• willgenerate complexity on the superseeder side

https://torrust.com/ seems a valid alternative.

[rgaudin]

Checked out torrust ; looks good. Can work the same way we currently do. Given its an API, we can have a pure tracker running and simply manage the whitelist via API calls on k8s-cronjobs. We could even use their web-index software for advocacy purposes.

Small effort overall.

[rgaudin]

Important to note that we cannot run the tracker on our k8s as IPv6 is not supported. It would thus need to de deployed on a non-node machine and that should be discussed in #operations.

[kelson42]

@rgaudin What is important to me is that the tracker is IPv6 ready and can distribute IPv6 peers. This should be doable even if the tracker service is only addressable in IPv4 right?

[rgaudin]

I can not answer that but from what I understand, each peer announces itself to the tracker, informing about its IP and port.
If the tracker is not reachable because it's domain resolves only to IPv4, then the client can not announce itself to it.

If the peer has dual stack then I suppose that if the tracker supports IPv4 and IPv6 (torrust or opentracker compiled with the flag) then assuming its bt-client sends both IPs, then I believe the tracker plays its role for both IPs.

[rgaudin]

FYI the tracker software has been changed to torrust which does support IPv6. It's still not reachable from IPv6 though.