BEP:7
Title:IPv6 Tracker Extension
Version:11098
Last-Modified:2008-05-21 00:08:51 -0700 (Wed, 21 May 2008)
Author:Greg Hazel <greg at bittorrent.com>, Arvid Norberg <arvid at bittorrent.com>
Status:Draft
Type:Standards Track
Created:31-Jan-2008
Post-History:

This extension extends the tracker response to better support IPv6 peers as well as defines a way for multi homed machines to announce multiple addresses at the same time. This proposal addresses the use case where peers are either on an IPv4 network running Teredo [1] or peers are on an IPv6 network with an IPv4 tunnel interface.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in IETF RFC 2119 [2].

Announce Parameter

The client MAY add an &ipv6= parameter to the HTTP GET request it sends to the tracker. The value is either an IPv6 endpoint (address and port) or just an IPv6 address. In the case where only an address is supplied, the IPv6 port is assumed to be the same as specified by the &port= parameter.

The tracker SHOULD perform a NAT check on the IPv6 endpoint.

In case the client contacts the tracker on an IPv6 interface, it may add an &ipv4= parameter with its IPv4 address or endpoint. The value MUST be either an IPv4 endpoint (address and port) or just an IPv4 address. If only an address is supplied, the port is assumed to be the same as the &port= parameter.

The endpoints are encoded as strings as defined by RFC 2732 [3].

If both an &ipv4= and an &ipv6= parameter are specified, the tracker MAY ignore the address family that is the same as the source address of the request. i.e. If the client connects to the tracker with an IPv4 source address, the tracker MAY ignore any &ipv4= address and if the client connects to the tracker with an IPv6 source address, the tracker MAY ignore any &ipv6= parameter.

Announce Response

In case the tracker does not support the compact response as described in BEP-23 [4], no change is necessary. Since the original peers response returns peer endpoints in their expanded string form, IPv6 addresses can be passed back this way.

In case a compact response is requested, the tracker MAY add another key to the response; peers6. This key has the same layout as peers in compact mode, but instead of using 6 bytes per endpoint, 18 bytes are used. peers6 contains address-port pairs where the addresses are all IPv6.

Examples

Example announce string with 2001::53aa:64c:0:7f83:bc43:dec9 as IPv6 address:

GET /announce?peer_id=aaaaaaaaaaaaaaaaaaaa&info_hash=aaaaaaaaaaaaaaaaaaaa
&port=6881&left=0&downloaded=100&uploaded=0&compact=1
&ipv6=2001%3A%3A53Aa%3A64c%3A0%3A7f83%3Abc43%3Adec9

Example announce string with [2001::53aa:64c:0:7f83:bc43:dec9]:6882 as IPv6 endpoint:

GET /announce?peer_id=aaaaaaaaaaaaaaaaaaaa&info_hash=aaaaaaaaaaaaaaaaaaaa
&port=6881&left=0&downloaded=100&uploaded=0&compact=1
&ipv6=%5B2001%3A%3A53Aa%3A64c%3A0%3A7f83%3Abc43%3Adec9%5D%3A6882

Example announce string with 2001::53aa:64c:0:7f83:bc43:dec9 as IPv6 address and 261.52.89.12 as IPv4 address:

GET /announce?peer_id=aaaaaaaaaaaaaaaaaaaa&info_hash=aaaaaaaaaaaaaaaaaaaa
&port=6881&left=0&downloaded=100&uploaded=0&compact=1
&ipv6=2001%3A%3A53Aa%3A64c%3A0%3A7f83%3Abc43%3Adec9&ipv4=261.52.89.12

Example response:

d8:intervali1800e5:peers6:iiiipp6:peers618:iiiiiiiiiiiiiiiippe

Rationale

The naming of peers6 is chosen not to collide with the current peers response and to be backwards compatible. It is also a simple addition to the current response, using the same encoding.