Every now and then we developers are re-reminded that the internet is undergoing a phase change, from IPv4 ( 184.108.40.206 ) to the new IPv6 protocol. BitTornado has some IPv6 compatibility, but it isn't complete simply because, in order to be complete, some extensions will need to be made to the tracker protocol. I'm going to propose some extensions here and I'm hoping for some good comments from you folk.
Well, actually the basic bittorrent protocol was perfectly ipv6-aware, the main problems came with the compact extension, and the fact that there are mixed swarms.
If DNS were set up properly for the whole internet, we could just work with the domainnames and every client could decide for itself which kind of connection it wants... unfortunately it's not the case.
Should be correct.
ANNOUNCE BEHAVIOR AND EXTENSION:
If a peer does not have IPv4 connectivity, or if the tracker does not have IPv4 connectivity, then the peer should connect to the tracker via IPv6. No additional information is required in the announce for this instance.
If both peer and tracker have IPv4 connectivity, then the peer should announce to the tracker VIA IPv4. This is because, just as for usual IPv4 connections, the peer may be behind a network address translator and the tracker needs to be able to test the peer's connectivity.
Actually I don't like the idea of having IPv4 as the default way of announcing. Especially since IPv6connections usually are "cheaper".
However I also dislike the whole idea of NAT-checking. It just is additional work for the tracker, and it's a work it isn't even meant to be made by it.
It's not for the tracker to decide which clients to connect to... however that's a different matter and has nothing to do with IPv6.
If the peer has IPv6 capability, it should add the key "ipv6=" to the announce, containing the peer's IPv6 address in standard format, as shown here:
Well, if you do it the above way this would be necessarry... however I have another idea (see below).
RESPONSE BEHAVIOR AND EXTENSION:
A new key will be added to the response: 'peers6'. If a peer connects to the tracker via IPv6, it will receive a peer list via the 'peers6' key; if a peer connects to the tracker via IPv4 along with the "ipv6=" key, it will receive peers via both the original 'peers' and the new 'peers6' key. The tracker will need to determine an optimal mix between the number of peers returned in each category.
The content of the 'peers6' key is a string value, much like the string returned in 'peers' when the "compact=1" is used, except each "record" in the string is 18 bytes long instead of six, consisting of a 16-byte IPv6 address and a two-byte port number.
I don't think it's a good idea to introduce a new response key, since it would exclude all clients with a working IPv6 implementation, which doesn't understand the new key.
And sending them in this "compressed" format doesn't seem to be very consistent with the usual behaviour of tracker responses (except the compact mode).
Here's my suggestion: Seperate the swarms!
Instead of trying to make an addition for client and tracker to support both address types at once, just treat it as if there were two seperate swarms, one only consisting of IPv4 clients and one only of IPv6 clients.
Technically I'm thinking of the following: If a client gets a torrent with a tracker URL, that has an A-record and
an AAAA-record, it just makes two completely seperate announces, one to the IPv4-address, and one to the IPv6-address. And of course it will get two answers, one consisting of IPv4-adresses, and one consisting of IPv6-addresses.
- More traffic for both, client and tracker, since every announce has to be done twice
- Possibility of connectiong to the same peer twice (IPv4 and Ipv6). Though probably here we can use the PeerID somehow and drop the slower of the two connections.
- Should be easier to implement. The tracker can just keep two completely seperate lists internally. I don't know what kind of data type you had in mind for your idea above, but if you kept it as a single list, you have to search every entry for an IPv6-address, if they are requested.
- More consistency and future-proof. You wrote, that in case both (client/tracker) are only reachable via IPv6 there shouldn't be any change in the behaviour, so why should there if they are (additionally) reachable by IPv4?
- You could operate two physically seperate trackers. The AAAA-record and the A-record of the tracker doesn't need to point to the same physical machine.
- Downward-compatibility. If a client has an IPv6-only connection it will (obviously) only announce to the IPv6 tracker, while an IPv4-only client will only contact the IPv4-tracker... both doesn't need to worry about spheres they aren't able to reach.
- You can keep the compact-response. (Personally I don't like this format, however some people do. ) If you put both sort of peers into the same tracker response, you have to use the full format. But onot if you keep them seperate.
Probably it would be good to implement a new IPv6-compact-response. Of course it would need some sort of mechanism (header?) to avoid other clients, that have basic IPv6 connectivity but no knowlede of this behaviour, from assuming it's a response consisting of IPv4-addresses. I've seen quite a few clients, that weren't programmed very good: They connected to the tracker via IPv6, only because they used IPv6-aware HTTP libraries, but the programmer didn't really think/know of IPv6 for the core program.
However there is one problem: We can be sure, that the connections to the tracker will be always made with the correct protocol, but we can't know about the IP-parameter in the announce URL. Even though a client is able to connect via IPv6 to a tracker, there is no guarantee, that the reported IP-parameter isn't an v4-address, or vice versa. And there is still the possibility, that it's a domainname, which could resolve to both types of address. So probably it would be wise for the tracker
to check this parameter and return one of the following error-messages: "Error: Reported an IPv4-address through IPv6-connection", "Error: Reported an IPv6-address through IPv4-connection", "Error: reported Domainname doesn't resolve to IPv6-address", "Error: reported Domainname doesn't resolve to IPv4-address".
One last thing: IF we assume, that we are only using one tracker (instead of two seperate ones), it could
be wise to add an "addipv4peers=1" to the IPv6-tracker-request, which tells the tracker, that it also want's a few v4-peers in the result. But basically there shouldn't be much cases in which this is useful. Maybe if the user isn't able (or doesn't want) to recieve incoming IPv4-connections AND doesn't want to connect to the IPv4 tracker. Maybe we should drop this idea.:
Okay, basically this was my suggestion. Maybe it's better, maybe not. However I think it is..