By erdgeist | December 28, 2007
If you haven’t spent the last decade behind a C64 you may have noticed a HugeNewThing™ called IPv6 is coming. There still are some issues that prevent its wide spread use. No consumer DSL has it. Most people wouldn’t even care what *IPv4* is. However, bittorrent has been designed to work with IPv6 out of the box. Many convenience extensions in the Bittorrent-Tracker protocol – compact tracker responses, for example – do not. Worse: others like the UDP-Tracker protocol do not even look like having taken IPv6 into account at all.
Still, we consider IPv6 very important and convenient. Its use could solve all NAT-dependent connectivity issues and heavily reduce complexity in clients. On the other hand we noticed that introducing IPv6 in a transitional way creates many headaches in inter-protocol communication. To remove some barriers we propose the following request for comments which will be incorporated into opentracker and thus available at tpb soon.
1. The clouds
To be frank: there will be two clouds for each torrent, one in IPv4 and one in IPv6. Clients capable of handling IPv6 connections and still interested in IPv4 peers will need to announce their torrents to trackers twice. This is a harsh decission, but in the end most IPv4 peers are not interested in IPv6 peers and there is no easy way to tell whom to return which peers.
The proposed way to identify a peer’s internet protocol version defaults to the incoming socket address and can be overridden by the ip parameter from the announce http request.
This is very much how Bram Cohen layed it out in his Tracker-Protocol. Of course, overriding only works for trackers that allow overriding ip addresses with the one passed in the query. All others have no means of obtaining the ip address for the other protocol version.
Scrapes will be answered for each cloud independently according to the requestors ip address protocol version.
2. Tracker TCP Responses
Most trackers (e.g. opentracker) have completely switched to only returning compact responses in order to save, or better: not to waste bandwidth. That compact format is just a string of multiple of six bytes that contain ip address and port for as many peers as do fit there. Filling it with or mixing in IPv6 addresses is impossible without breaking backward compatibility.
So we propose adding another “peers6″ entry in the announce response dictionary that contains a string of zero or more entries, each 16 bytes network byte order IPv6 addresses followed by 2 byte network byte order port number. The “peers6″ entry must not be present in non-compact mode.
3. Tracker UDP Responses
The UDP-protocol has not left any space for IPv6-addresses in its current form. So we need to define a new action together with its input and output block formats.
Proposed extension to the UDP Tracker format to work over IPv6, we claim a value for the action identifier of “4″.:
|84||16-byte string||IP address|
The corresponding reply looks as follows:
|20+n*18||16-byte string||IPv6 address|
|36+n*18||16-bit integer||TCP port|
We consider those the most sane design decissions that do not deviate from existing protocol too much and hope to receive feedback on our proposal, from closed source implementations as well as the usual open source suspects.