BEP:7
Title:IPv6 Tracker Extension
Version: 3196f6b0a8d39a0655811579b794c3ed31d6bb79
Last-Modified:Fri Jan 3 14:19:00 2020 +0100
Author: Greg Hazel <greg@bittorrent.com>, Arvid Norberg <arvid@bittorrent.com>
Status: Draft
Type:Standards Track
Created:31-Jan-2008
Post-History:07-Sep-2017 (the8472.bep@infinite-source.de), multi-homed trackers , 12-mar-2020 (arvid@libtorrent.org) discourage IP announce params and clarify announcing multiple listen interfaces

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 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.

Announcing

An announce to the tracker should be made for each local IP address:

  1. the client intends to receive incoming peer connections over (listens on)
  2. the client intends to publish to the tracker
  3. that can be used as the source address in packets sent to the tracker (at least one of the addresses the tracker hostname resolves to).

Each announce should use the corresponding local IP address as the source address of the connection.

The source address is set on a socket using the bind() call, before connecting.

This applies to TCP connections, for HTTP and HTTPS trackers, as well as UDP announces, to UDP trackers.

The client SHOULD include a key parameter in its announces. The key should remain the same for a particular infohash during a torrent session. Together with the peer_id this allows trackers to uniquely identify clients for the purpose of statistics-keeping when they announce from multiple IP .

The key should be generated so it has at least 32bits worth of entropy.

IP announce parameters

An earlier version of this BEP specified new HTTP parameters to announce an additional address of a different address family than the source IP address of the tracker connection (&ipv4= and &ipv6=). These are discouraged, as they allow an attacker to announce a victim's IP address to launch a DDoS attack.

Announce Response

In case the tracker does not support the compact response as described in BEP-23, 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 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.