Changeset 11183
- Timestamp:
- 10/15/09 19:42:35 (10 months ago)
- File:
-
- 1 edited
-
dotorg/trunk/html/beps/bep_0032.html (modified) (13 diffs)
Legend:
- Unmodified
- Added
- Removed
-
dotorg/trunk/html/beps/bep_0032.html
r11179 r11183 39 39 <tr class="field"><th class="field-name">Title:</th><td class="field-body">BitTorrent DHT Extensions for IPv6</td> 40 40 </tr> 41 <tr class="field"><th class="field-name">Version:</th><td class="field-body">111 78</td>42 </tr> 43 <tr class="field"><th class="field-name">Last-Modified:</th><td class="field-body"><a class="reference external" href="http://bittorrent.org/trac/browser/dotorg/trunk/html/beps/bep_0032.rst">2009-10-1 5 21:57:32 +0000 (Thu, 15Oct 2009)</a></td>41 <tr class="field"><th class="field-name">Version:</th><td class="field-body">11182</td> 42 </tr> 43 <tr class="field"><th class="field-name">Last-Modified:</th><td class="field-body"><a class="reference external" href="http://bittorrent.org/trac/browser/dotorg/trunk/html/beps/bep_0032.rst">2009-10-16 02:42:16 +0000 (Fri, 16 Oct 2009)</a></td> 44 44 </tr> 45 45 <tr class="field"><th class="field-name">Author:</th><td class="field-body">Juliusz Chroboczek <jch at pps.jussieu.fr></td> … … 55 55 <tr class="field"><th class="field-name">Created:</th><td class="field-body">14-Oct-2009</td> 56 56 </tr> 57 <tr class="field"><th class="field-name">Post-History:</th><td class="field-body"> </td>57 <tr class="field"><th class="field-name">Post-History:</th><td class="field-body">15-Oct-2009: Promote same ID in IPv6 and IPv4 nodes. Drop values6. Added some rationales</td> 58 58 </tr> 59 59 </tbody> … … 63 63 <p class="topic-title first">Contents</p> 64 64 <ul class="simple"> 65 <li><a class="reference internal" href="#abstract" id="id2">Abstract</a></li> 66 <li><a class="reference internal" href="#introduction" id="id3">Introduction</a></li> 67 <li><a class="reference internal" href="#operation" id="id4">Operation</a><ul> 68 <li><a class="reference internal" href="#single-protocol-nodes" id="id5">Single-protocol nodes</a></li> 69 <li><a class="reference internal" href="#double-stack-nodes" id="id6">Double-stack nodes</a><ul> 70 <li><a class="reference internal" href="#bootstrapping" id="id7">Bootstrapping</a></li> 71 <li><a class="reference internal" href="#stationary-operation" id="id8">Stationary operation</a></li> 72 </ul> 73 </li> 74 </ul> 75 </li> 76 <li><a class="reference internal" href="#changes-and-extensions-to-existing-messages" id="id9">Changes and extensions to existing messages</a><ul> 77 <li><a class="reference internal" href="#new-parameters" id="id10">New parameters</a><ul> 78 <li><a class="reference internal" href="#nodes6" id="id11">nodes6</a></li> 79 <li><a class="reference internal" href="#values6" id="id12">values6</a></li> 80 <li><a class="reference internal" href="#want" id="id13">want</a></li> 81 </ul> 82 </li> 83 <li><a class="reference internal" href="#changes-to-message-semantics" id="id14">Changes to message semantics</a><ul> 84 <li><a class="reference internal" href="#find-nodes-and-get-peers" id="id15">find_nodes and get_peers</a></li> 85 <li><a class="reference internal" href="#announce-peers" id="id16">announce_peers</a></li> 86 </ul> 87 </li> 88 </ul> 89 </li> 90 <li><a class="reference internal" href="#acknowledgements" id="id17">Acknowledgements</a></li> 91 <li><a class="reference internal" href="#references" id="id18">References</a></li> 92 <li><a class="reference internal" href="#copyright" id="id19">Copyright</a></li> 65 <li><a class="reference internal" href="#abstract" id="id3">Abstract</a></li> 66 <li><a class="reference internal" href="#introduction" id="id4">Introduction</a></li> 67 <li><a class="reference internal" href="#operation" id="id5">Operation</a><ul> 68 <li><a class="reference internal" href="#single-protocol-nodes" id="id6">Single-protocol nodes</a></li> 69 <li><a class="reference internal" href="#double-stack-nodes" id="id7">Double-stack nodes</a><ul> 70 <li><a class="reference internal" href="#bootstrapping" id="id8">Bootstrapping</a></li> 71 <li><a class="reference internal" href="#steady-state-operation" id="id9">Steady-state operation</a></li> 72 </ul> 73 </li> 74 </ul> 75 </li> 76 <li><a class="reference internal" href="#changes-and-extensions-to-existing-messages" id="id10">Changes and extensions to existing messages</a><ul> 77 <li><a class="reference internal" href="#changes-to-existing-parameters" id="id11">Changes to existing parameters</a><ul> 78 <li><a class="reference internal" href="#values" id="id12">values</a></li> 79 </ul> 80 </li> 81 <li><a class="reference internal" href="#new-parameters" id="id13">New parameters</a><ul> 82 <li><a class="reference internal" href="#nodes6" id="id14">nodes6</a></li> 83 <li><a class="reference internal" href="#want" id="id15">want</a></li> 84 </ul> 85 </li> 86 <li><a class="reference internal" href="#changes-to-message-semantics" id="id16">Changes to message semantics</a><ul> 87 <li><a class="reference internal" href="#find-nodes-and-get-peers" id="id17">find_nodes and get_peers</a></li> 88 <li><a class="reference internal" href="#announce-peers" id="id18">announce_peers</a></li> 89 </ul> 90 </li> 91 </ul> 92 </li> 93 <li><a class="reference internal" href="#acknowledgements" id="id19">Acknowledgements</a></li> 94 <li><a class="reference internal" href="#references" id="id20">References</a></li> 95 <li><a class="reference internal" href="#copyright" id="id21">Copyright</a></li> 93 96 </ul> 94 97 </div> … … 97 100 <p>This proposal describes a set of extensions to the BitTorrent DHT <a class="footnote-reference" href="#bep-5" id="id1">[1]</a> 98 101 to allow operation over IPv6.</p> 99 <p><strong>This is a very early draft</strong>, and not suitable for implementation. Yet.</p>102 <p><strong>This is a very early draft</strong>, and <strong>not suitable for implementation</strong>. Yet.</p> 100 103 </div> 101 104 <div class="section" id="introduction"> … … 113 116 describes the procedures and message formats needed to deploy an IPv6 114 117 version of the BitTorrent DHT.</p> 115 <p>The extension described in this document also solves a long-standing issue 116 with the protocol defined in BEP-5, and does so without endangering 117 compatibility. When a get_peers request is sent with an explicit request 118 for an address family, the presence of contact information in the reply is 119 no longer governed by the presence of a "values" key; this avoids the 120 well-known problem of contact information being masked by peer information.</p> 118 <p>The extension described in this document also solves a long-standing 119 issue with the protocol defined in BEP-5. The presence of contact 120 information in the reply is no longer governed by the presence of 121 a "values" key; this avoids the well-known problem of contact 122 information being masked by peer information. While this is an 123 incompatible change, it is believed to be properly handled by all 124 deployed implementations.</p> 121 125 </div> 122 126 <div class="section" id="operation"> … … 126 130 IPv4 DHT, and, conversely, no IPv4 data is stored in the IPv6 DHT. A node 127 131 wishing to participate in both DHTs must maintain two distinct routing 128 tables, one for IPv4 and one for IPv6. A node may choose to use the same 129 node id in both tables, or distinct node ids.</p> 130 <p>Most KRPC messages have the same semantics when carried over IPv4 and IPv6. 131 In particular, no IPv6 addresses are ever carried in the existing "nodes" 132 and "peers" keys of KRPC messages -- instead, new keys "nodes6" and 133 "peers6" are defined.</p> 132 tables, one for IPv4 and one for IPv6.</p> 133 <p>While this is not strictly necessary, a node should use the same node 134 id in both tables. This simplifies implementation and debugging, and 135 slightly increases efficiency in the case where the two DHTs are 136 mostly congruent.</p> 134 137 <p>By default, messages only carry data in the address family implied by the 135 138 network layer protocol. In the case of the "nodes" and "nodes6" arguments … … 140 143 <p>A single-protocol node (IPv4 or IPv6) only participates in one DHT. Such 141 144 a node does not need to explicitly request data in a given family -- the 142 data provided by default is sufficient.</p>145 data provided by default is exactly what it needs.</p> 143 146 </div> 144 147 <div class="section" id="double-stack-nodes"> 145 148 <h2>Double-stack nodes</h2> 146 149 <p>While conceptually equivalent to a pair of single-protocol nodes, 147 a double-stack (IPv4 and IPv6) node can make use of a number of features of148 the protocol to make its operation more efficient and to generally improve149 t he reliability of the DHT.</p>150 a double-stack (IPv4 and IPv6) node can make bootstrap faster and 151 improve the reliability of the protocol by "leaking" data between the 152 two DHTs, as described in the following paragraphs.</p> 150 153 <div class="section" id="bootstrapping"> 151 154 <h3>Bootstrapping</h3> … … 154 157 this process, it should request both "nodes" and "nodes6" fields.</p> 155 158 </div> 156 <div class="section" id="st ationary-operation">157 <h3>St ationaryoperation</h3>158 <p>Once bootstrap is successful, a node should no t request data in both159 address families; it should only request "nodes" replies from IPv4 nodes, 160 and "nodes6" replies from IPv6 nodes. Requesting both address families is 161 unlikely to provide any useful information, and unnecessarily increases 162 networktraffic.</p>159 <div class="section" id="steady-state-operation"> 160 <h3>Steady-state operation</h3> 161 <p>Once bootstrap is successful, a node should normally only request 162 "nodes" replies from IPv4 nodes, and "nodes6" replies from IPv6 nodes. 163 Requesting both address families in all requests is unlikely to 164 provide useful information, and hence uselessly increases network 165 traffic.</p> 163 166 <p>In order to increase the reliability of the DHT after a single-protocol 164 network outage, a node may <em>ocasionally</em> send a request for "nodes" to an165 IPv6 node, or a request for "nodes6" to an IPv4 node.</p>167 network outage, however, a node may <em>ocasionally</em> send a request for 168 "nodes" to an IPv6 node, or a request for "nodes6" to an IPv4 node.</p> 166 169 </div> 167 170 </div> … … 169 172 <div class="section" id="changes-and-extensions-to-existing-messages"> 170 173 <h1>Changes and extensions to existing messages</h1> 174 <div class="section" id="changes-to-existing-parameters"> 175 <h2>Changes to existing parameters</h2> 176 <div class="section" id="values"> 177 <h3>values</h3> 178 <p>In a reply sent over IPv4, the "values" parameter contains a list of 179 strings, each of which contains compact format IPv4 contact 180 information for a single peer.</p> 181 <p>In a reply sent over IPv6, "values' contains a list of strings, each 182 of which contains compact format IPv6 contact information for a single 183 peer.</p> 184 <p>Implementations of this specification must be able to properly parse 185 hybrid "values" lists -- lists containing an arbitrary mixture of 186 6-octet IPv4 values and 18-octet IPv6 values. However, 187 implementations should not send such hybrid lists, and must not send 188 hybrid lists in a reply to an IPv4 request that doesn't contain 189 a "want" parameter.</p> 190 <blockquote> 191 <strong>Rationale</strong>: a request sent over IPv4 with no "want" parameter 192 could originate from a node that implements plain BEP-5, and which 193 might therefore be unable to parse a hybrid list.</blockquote> 194 </div> 195 </div> 171 196 <div class="section" id="new-parameters"> 172 197 <h2>New parameters</h2> 173 198 <div class="section" id="nodes6"> 174 199 <h3>nodes6</h3> 175 <p>The "nodes6" parameter is allowed in replies to the find_nodes and 176 get_peers messages. When present, it carries a string containing the 177 compact IPv6 node info for the 8 closest good nodes in the sending node's 178 IPv6 routing table.</p> 179 </div> 180 <div class="section" id="values6"> 181 <h3>values6</h3> 182 <p>The "values6" parameter is allowed in replies to the get_peers message 183 being sent over IPv6. Its value is a list of strings, each of which 184 contains compact format IPv6 contact information for a single peer.</p> 200 <p>The "nodes6" parameter is analogous to the existing "nodes" parameter: 201 when present, it carries a string containing the compact IPv6 node 202 info for the 8 closest good nodes in the sending node's IPv6 routing 203 table. This parameter is allowed in replies to the find_nodes and 204 get_peers messages (see below).</p> 185 205 </div> 186 206 <div class="section" id="want"> … … 198 218 <p>For future extensibility, other characters may be present in the string, 199 219 and must be silently ignored on reception.</p> 220 <blockquote> 221 <strong>Note</strong>: the "want" parameter is currently under discussion. It 222 has been suggested that it should be renamed to "flags", and that 223 it should be a list of flags rather than a string. This author 224 is not convinced yet.</blockquote> 200 225 </div> 201 226 </div> … … 204 229 <div class="section" id="find-nodes-and-get-peers"> 205 230 <h3>find_nodes and get_peers</h3> 206 <p>A node sending a find_nodes or get_peers request should include a "want" 207 parameter containing one or both of the characters "4" or "6". A node 208 replying to a find_nodes or get_peers request must include a "nodes" 209 parameter if the request's "want" parameter included a "4", and a "nodes6" 210 parameter if the request's "want" parameter included a "6".</p> 211 <p>In the absence of a "want" parameter, the behaviour of the replying node is 212 more involved. For a reply to a find_nodes request, the node should 213 include "nodes" if the request was sent over IPv4, and include "nodes6" if 214 the request was sent over IPv6.</p> 215 <p>For a get_peers request with no "want" parameter, value should only be 216 included if there is no "values" or "values6" parameter. If no "values" or 217 "values6" parameter is being sent, the presence of "nodes" or "nodes6" is 218 governed by the network-layer protocol of the request, as above.</p> 219 <blockquote> 220 <strong>Rationale</strong>: it has been suggested that the reply to a get_peers 221 request should always include a "nodes" or "nodes6" parameter, 222 independently of the presence of a "values" or "values6" parameter. 223 While this is clearly a better semantics, it is not backward-compatible, 224 and it is not known whether it breaks any deployed implementations.</blockquote> 225 <p>When a node receives a get_peers request and it has contact information for 226 the matching address family and info-hash, it should include either 227 a "values" parameter (if the request was sent over IPv4) or a "values6" 228 parameter in the reply.</p> 229 <p>A reply sent over IPv4 must not contain a "values6" parameter, and a reply 230 sent over IPv6 must not contain a "values" parameter. In other words, the 231 "want" parameter only governs the presence of the "nodes" and "nodes6" 232 parameters.</p> 231 <p>A node sending a find_nodes or get_peers request should include 232 a "want" parameter containing one or both of the characters "4" or 233 "6". A node replying to a find_nodes or get_peers request should 234 include a "nodes" parameter if and only if the request's "want" 235 parameter included a "4", and should include a "nodes6" parameter if 236 and only if the request's "want" parameter included a "6".</p> 237 <p>In the absence of a "want" parameter, the reply should include "nodes" 238 if the request was sent over IPv4, and should include "nodes6" if the 239 request was sent over IPv6.</p> 240 <blockquote> 241 <strong>Rationale</strong>: this is an incompatible change to the protocol 242 defined in BEP-5 <a class="footnote-reference" href="#bep-5" id="id2">[1]</a>, which specifies that "nodes" and 243 "values" are mutually exclusive. However, this change makes the DHT 244 more reliable, and has been deployed by most implementations for 245 over a year with no negative effects.</blockquote> 246 <p>When a node receives a get_peers request and it has contact 247 information for the matching address family and info-hash, it should 248 additionally include a "values" parameter containing a list of 6-octet 249 strings if the request was sent over IPv4, and a list of 18-octet 250 strings if the request was sent over IPv6.</p> 251 <p>A reply sent over IPv4 should not contain 18-octet IPv6 contact 252 information, and a reply sent over IPv6 should not contain 6-octet 253 IPv4 contact information. In other words, the "want" parameter only 254 governs the presence of the "nodes" and "nodes6" parameters, not the 255 interpretation of "values".</p> 256 <blockquote> 257 <strong>Rationale</strong>: if the requesting node is a single-stack node, it has 258 no interest in values of the other address family. If the 259 requesting node is a double-stack node, then it must perform the two 260 announces in parallel; providing both sets of data in both sets of 261 replies merely increases the amount of traffic without giving any 262 extra information.</blockquote> 233 263 </div> 234 264 <div class="section" id="announce-peers"> … … 243 273 <div class="section" id="acknowledgements"> 244 274 <h1>Acknowledgements</h1> 245 <p>I gratefully acknowledge the influence of <em>The 8472</em> over this work.</p> 275 <p>I gratefully acknowledge the influence of <em>The 8472</em> and <em>arvid</em> over 276 this work.</p> 246 277 </div> 247 278 <div class="section" id="references"> … … 250 281 <colgroup><col class="label" /><col /></colgroup> 251 282 <tbody valign="top"> 252 <tr><td class="label"> <a class="fn-backref" href="#id1">[1]</a></td><td>BEP_0005. DHT Protocol.283 <tr><td class="label">[1]</td><td><em>(<a class="fn-backref" href="#id1">1</a>, <a class="fn-backref" href="#id2">2</a>)</em> BEP_0005. DHT Protocol. 253 284 (<a class="reference external" href="http://www.bittorrent.org/beps/bep_0005.html">http://www.bittorrent.org/beps/bep_0005.html</a>)</td></tr> 254 285 </tbody>
Note: See TracChangeset
for help on using the changeset viewer.
