Recent Posts

Archives

Topics


« | Main | »

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 »

8 Responses to “The IPv6 situation”

  1. lalala Says:
    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.

  2. Olaf van der Spek Says:
    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? ;)

  3. Bernhard Says:
    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.

  4. Greg Hazel Says:
    February 20th, 2008 at 12:05 am

    Have you seen this? http://www.bittorrent.org/beps/bep_0007.html

  5. John Says:
    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?

  6. anonymous Says:
    May 27th, 2008 at 11:59 am

    I realize this is probably off-topic, but what about DHT?

  7. Mark Says:
    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.

  8. Jim Franklin Says:
    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.