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