| 1 | IPv6 tracker extension |
|---|
| 2 | ====================== |
|---|
| 3 | |
|---|
| 4 | This extension extends the tracker response to better support IPv6 peers as |
|---|
| 5 | well as defines a way for multi homed machines to announce multiple addresses |
|---|
| 6 | at the same time. This proposal addresses the use case where peers |
|---|
| 7 | are either on an IPv4 network running Teredo_ or peers are on |
|---|
| 8 | an IPv6 network with an IPv4 tunnel interface. |
|---|
| 9 | |
|---|
| 10 | .. _Teredo: https://www.microsoft.com/technet/network/ipv6/teredo.mspx |
|---|
| 11 | |
|---|
| 12 | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", |
|---|
| 13 | "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to |
|---|
| 14 | be interpreted as described in IETF `RFC 2119`_. |
|---|
| 15 | |
|---|
| 16 | .. _`RFC 2119`: http://tools.ietf.org/html/rfc2119 |
|---|
| 17 | |
|---|
| 18 | announce parameter |
|---|
| 19 | ------------------ |
|---|
| 20 | |
|---|
| 21 | The client MAY add an ``&ipv6=`` parameter to the HTTP GET request it sends |
|---|
| 22 | to the tracker. The value is either an IPv6 endpoint (address and port) or |
|---|
| 23 | just an IPv6 address. In the case where only an address is supplied, the IPv6 |
|---|
| 24 | port is assumed to be the same as specified by the ``&port=`` parameter. |
|---|
| 25 | |
|---|
| 26 | The tracker SHOULD perform a NAT check on the IPv6 endpoint. |
|---|
| 27 | |
|---|
| 28 | In case the client contacts the tracker on an IPv6 interface, it may add |
|---|
| 29 | an ``&ipv4=`` parameter with its IPv4 address or endpoint. The value MUST |
|---|
| 30 | be either an IPv4 endpoint (address and port) or just an IPv4 address. If only |
|---|
| 31 | an address is supplied, the port is assumed to be the same as the ``&port=`` |
|---|
| 32 | parameter. |
|---|
| 33 | |
|---|
| 34 | The endpoints are encoded as strings as defined by `RFC 2732`_. |
|---|
| 35 | |
|---|
| 36 | .. _`RFC 2732`: http://tools.ietf.org/html/rfc2732 |
|---|
| 37 | |
|---|
| 38 | If both an ``&ipv4=`` and an ``&ipv6=`` parameter are specified, the tracker |
|---|
| 39 | MAY ignore the address family that is the same as the source address of the |
|---|
| 40 | request. i.e. If the client connects to the tracker with an IPv4 source |
|---|
| 41 | address, the tracker MAY ignore any ``&ipv4=`` address and if the client |
|---|
| 42 | connects to the tracker with an IPv6 source address, the tracker MAY ignore |
|---|
| 43 | any ``&ipv6=`` parameter. |
|---|
| 44 | |
|---|
| 45 | announce response |
|---|
| 46 | ----------------- |
|---|
| 47 | |
|---|
| 48 | In case the tracker does not support the ``compact`` response, no change is |
|---|
| 49 | necessary. Since the original ``peers`` response returns peer endpoints in |
|---|
| 50 | their expanded string form, IPv6 addresses can be passed back this way. |
|---|
| 51 | |
|---|
| 52 | In case a compact response is requested, the tracker MAY add another key |
|---|
| 53 | to the response; ``peers6``. This key has the same layout as ``peers`` in |
|---|
| 54 | compact mode, but instead of using 6 bytes per endpoint, 18 bytes are used. |
|---|
| 55 | peers6 contains address-port pairs where the addresses are all IPv6. |
|---|
| 56 | |
|---|
| 57 | examples |
|---|
| 58 | -------- |
|---|
| 59 | |
|---|
| 60 | Example announce string with ``2001::53aa:64c:0:7f83:bc43:dec9`` as IPv6 |
|---|
| 61 | address:: |
|---|
| 62 | |
|---|
| 63 | GET /announce?peer_id=aaaaaaaaaaaaaaaaaaaa&info_hash=aaaaaaaaaaaaaaaaaaaa |
|---|
| 64 | &port=6881&left=0&downloaded=100&uploaded=0&compact=1 |
|---|
| 65 | &ipv6=2001%3A%3A53Aa%3A64c%3A0%3A7f83%3Abc43%3Adec9 |
|---|
| 66 | |
|---|
| 67 | Example announce string with ``[2001::53aa:64c:0:7f83:bc43:dec9]:6882`` as IPv6 endpoint:: |
|---|
| 68 | |
|---|
| 69 | GET /announce?peer_id=aaaaaaaaaaaaaaaaaaaa&info_hash=aaaaaaaaaaaaaaaaaaaa |
|---|
| 70 | &port=6881&left=0&downloaded=100&uploaded=0&compact=1 |
|---|
| 71 | &ipv6=%5B2001%3A%3A53Aa%3A64c%3A0%3A7f83%3Abc43%3Adec9%5D%3A6882 |
|---|
| 72 | |
|---|
| 73 | Example announce string with ``2001::53aa:64c:0:7f83:bc43:dec9`` as IPv6 |
|---|
| 74 | address and ``261.52.89.12`` as IPv4 address:: |
|---|
| 75 | |
|---|
| 76 | GET /announce?peer_id=aaaaaaaaaaaaaaaaaaaa&info_hash=aaaaaaaaaaaaaaaaaaaa |
|---|
| 77 | &port=6881&left=0&downloaded=100&uploaded=0&compact=1 |
|---|
| 78 | &ipv6=2001%3A%3A53Aa%3A64c%3A0%3A7f83%3Abc43%3Adec9&ipv4=261.52.89.12 |
|---|
| 79 | |
|---|
| 80 | Example response:: |
|---|
| 81 | |
|---|
| 82 | d8:intervali1800e5:peers6:iiiipp6:peers618:iiiiiiiiiiiiiiiippe |
|---|
| 83 | |
|---|
| 84 | rationale |
|---|
| 85 | --------- |
|---|
| 86 | |
|---|
| 87 | The naming of ``peers6`` is chosen not to collide with the current ``peers`` |
|---|
| 88 | response and to be backwards compatible. It is also a simple addition to the |
|---|
| 89 | current response, using the same encoding. |
|---|
| 90 | |
|---|
| 91 | authors |
|---|
| 92 | ------- |
|---|
| 93 | |
|---|
| 94 | | `Greg Hazel`__ |
|---|
| 95 | | `Arvid Norberg`__ |
|---|
| 96 | |
|---|
| 97 | .. __: mailto:greg@bittorrent.com |
|---|
| 98 | .. __: mailto:arvid@bittorrent.com |
|---|
