| 31 | | A number of extensions (mostly undocumented) to the BitTorrent protocol |
| 32 | | have been defined in order to allow it to operate over IPv6. |
| 33 | | Unfortunately, these extensions only allow locating IPv6 peers by using |
| 34 | | trackers or through peer exchange -- but not from the DHT. This document |
| 35 | | describes the procedures and message formats needed to deploy an IPv6 |
| 36 | | version of the BitTorrent DHT. |
| 37 | | |
| 38 | | The extension described in this document also solves a long-standing |
| 39 | | issue with the protocol defined in BEP-5. The presence of contact |
| 40 | | information in the reply is no longer governed by the presence of |
| 41 | | a "values" key; this avoids the well-known problem of contact |
| 42 | | information being masked by peer information. While this is an |
| 43 | | incompatible change, it is believed to be properly handled by all |
| 44 | | deployed implementations. |
| | 32 | A number of extensions (mostly undocumented) to the BitTorrent |
| | 33 | protocol have been defined in order to allow it to operate over IPv6. |
| | 34 | Unfortunately, these extensions only allow locating IPv6 peers by |
| | 35 | using trackers or through peer exchange -- but not from the DHT. This |
| | 36 | document describes the procedures and message formats used in the IPv6 |
| | 37 | DHT. |
| 62 | | By default, messages only carry data in the address family implied by the |
| 63 | | network layer protocol. In the case of the "nodes" and "nodes6" arguments |
| 64 | | in replies to the find_nodes and get_peers requests, however, the requestor |
| 65 | | may request that the reply contain "nodes", "nodes6" or both fields. |
| | 55 | Usually, messages only carry data in the address family implied by the |
| | 56 | network layer protocol. In the case of the find_nodes and get_peers |
| | 57 | requests, however, the requestor may optionally request that the reply |
| | 58 | should contain IPv4 node information, IPv6 node information, or both. |
| 96 | | Once bootstrap is successful, a node should normally only request |
| 97 | | "nodes" replies from IPv4 nodes, and "nodes6" replies from IPv6 nodes. |
| 98 | | Requesting both address families in all requests is unlikely to |
| 99 | | provide useful information, and hence uselessly increases network |
| 100 | | traffic. |
| | 89 | Once bootstrap is successful, a node should normally only request IPv4 |
| | 90 | node information from IPv4 nodes, and IPv6 node information from IPv6 |
| | 91 | nodes. Requesting node information for both address families in all |
| | 92 | requests is unlikely to provide useful information, and hence |
| | 93 | increases network traffic with no benefit. |
| 158 | | applies to the address family it is carried over: a PORT message sent |
| 159 | | over IPv4 only advertises participation in the IPv4 DHT, and a PORT |
| 160 | | message sent over IPv6 only advertises participation in the IPv6 DHT. |
| | 152 | applies to the address it was sent from; this implies that a PORT |
| | 153 | message sent over IPv4 only advertises participation in the IPv4 DHT, |
| | 154 | and a PORT message sent over IPv6 only advertises participation in the |
| | 155 | IPv6 DHT. |
| | 156 | |
| | 157 | Multihomed hosts should take care to only send PORT messages over |
| | 158 | connections established from the address on which they participate in |
| | 159 | the DHT. |
| 164 | | address families, it might be possible to use the PORT message for |
| 165 | | both address families. However, since an implementation need not |
| 166 | | participate in both DHTs, nor use the same port in both DHTs, this |
| 167 | | specification leaves the role of bridging the two DHTs to the |
| 168 | | 'find_nodes' message (see below). |
| 169 | | |
| | 163 | address families, it would in principle be possible to use the PORT |
| | 164 | message for both address families. However, since an implementation |
| | 165 | need not participate in both DHTs, nor use the same port in both |
| | 166 | DHTs, this specification leaves the role of bridging the two DHTs to |
| | 167 | the 'find_nodes' message (see below). |
| 207 | | The "nodes6" parameter is analogous to the existing "nodes" parameter: |
| 208 | | when present, it carries a string containing the compact IPv6 node |
| 209 | | info for the 8 closest good nodes in the sending node's IPv6 routing |
| 210 | | table. This parameter is allowed in replies to the find_nodes and |
| 211 | | |
| | 204 | The "nodes6" parameter is analogous to the "nodes" parameter: when |
| | 205 | present, it carries a string containing the compact IPv6 node |
| | 206 | information for the 8 closest good nodes in the sending node's IPv6 |
| | 207 | routing table. This parameter is allowed in replies to the find_nodes |
| | 208 | and get_peers messages (see below). |
| 241 | | A node sending a find_nodes or get_peers request should include |
| 242 | | a "want" parameter containing one or both of the characters "4" or |
| 243 | | "6". A node replying to a find_nodes or get_peers request should |
| 244 | | include a "nodes" parameter if and only if the request's "want" |
| 245 | | parameter included a "4", and should include a "nodes6" parameter if |
| 246 | | and only if the request's "want" parameter included a "6". |
| | 238 | A node sending a find_nodes or get_peers request may include a "want" |
| | 239 | parameter containing one or both of the strings "n4" or "n6". A node |
| | 240 | replying to a find_nodes or get_peers request that includes a "want" |
| | 241 | parameter should include a "nodes" parameter if the request's "want" |
| | 242 | parameter contained the string "n4", and should include a "nodes6" |
| | 243 | parameter if the request's "want" parameter contained the string "n6". |
