IPv6 Tracker Extension

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.

Copyright

This document has been placed in the public domain.

..

Local Variables:

mode: indented-text

indent-tabs-mode: nil

sentence-end-double-space: t

fill-column: 70

coding: utf-8

End: