« Going social | Main | The UDP situation »
The IPv6 situation
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″.:
Request:
| Offset | Size | Name | Value |
| 0 | 64-bit integer | connection_id | |
| 8 | 32-bit integer | action | 4 |
| 12 | 32-bit integer | transaction_id | |
| 16 | 20-byte string | info_hash | |
| 36 | 20-byte string | peer_id | |
| 56 | 64-bit integer | downloaded | |
| 64 | 64-bit integer | left | |
| 72 | 64-bit integer | uploaded | |
| 80 | 32-bit integer | event | |
| 84 | 16-byte string | IP address | |
| 100 | 32-bit integer | key | |
| 104 | 32-bit integer | num_want | -1 |
| 108 | 16-bit integer | port |
The corresponding reply looks as follows:
Response:
| Offset | Size | Name | Value |
| 0 | 32-bit integer | action | 4 |
| 4 | 32-bit integer | transaction_id | |
| 8 | 32-bit integer | interval | |
| 12 | 32-bit integer | leechers | |
| 16 | 32-bit integer | seeders | |
| 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.
Topics: coding, tech | 8 Comments »
February 2nd, 2008 at 10:26 pm
what do you mean “No consumer DSL has it”. Lie LIE LIE. From ENTA to France and widely in CHINA they are developed and run.. Open your eyes.
February 13th, 2008 at 4:16 pm
> Proposed extension to the UDP Tracker format to work over IPv6, we claim a value for the action identifier of “4″
You do know it would’ve been nice to discuss this first, right?
February 17th, 2008 at 8:03 pm
Azureus has added some sort of compact mode for IPv6 in the latest Beta for 3.0.4.3. I could not find any specs for it though.
February 20th, 2008 at 12:05 am
Have you seen this? http://www.bittorrent.org/beps/bep_0007.html
April 3rd, 2008 at 10:22 pm
I spent the last 18 years behind a C-64, and I know what IPv6 is. Weird, huh?
May 27th, 2008 at 11:59 am
I realize this is probably off-topic, but what about DHT?
June 22nd, 2009 at 10:21 am
i have build latest opentracker IPv6 enabled, but no bittorrent client work with it. i tested bittornado, transmission, qBitorrent without success ):
i get : invalid reply: d8:completei1e10:downloadi0e8:intervali1878e12:min intervali939e5:peers618:……
i ran (IPv6) opentracker over onioncat (IPv6 tunnel over onion)
stats at: http://fd87:d87e:eb43:f20d:6d4f:239:ab70:1793:6677/stats
announce url is : http://fd87:d87e:eb43:f20d:6d4f:239:ab70:1793:6677/announce
any solution ?
Thanks.
August 28th, 2009 at 10:31 pm
Hi folks, how about building an onsite tolken ring to handle interaction between IPv6 and IPv4 users and clouds? Although I’m not sure if this would be applicable or cause more headaches than you started with.