Show
Ignore:
Timestamp:
10/29/09 16:47:15 (4 months ago)
Author:
bittorrent
Message:

updated bep32 html

Files:
1 modified

Legend:

Unmodified
Added
Removed

  • dotorg/trunk/html/beps/bep_0032.html

    r11183 r11186  
    3939<tr class="field"><th class="field-name">Title:</th><td class="field-body">BitTorrent DHT Extensions for IPv6</td> 
    4040</tr> 
    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> 
     41<tr class="field"><th class="field-name">Version:</th><td class="field-body">11185</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-29 23:46:53 +0000 (Thu, 29 Oct 2009)</a></td> 
    4444</tr> 
    4545<tr class="field"><th class="field-name">Author:</th><td class="field-body">Juliusz Chroboczek &lt;jch&#32;&#97;t&#32;pps.jussieu.fr&gt;</td> 
    … …  
    5555<tr class="field"><th class="field-name">Created:</th><td class="field-body">14-Oct-2009</td> 
    5656</tr> 
    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> 
     57<tr class="field"><th class="field-name">Post-History:</th><td class="field-body"></td> 
    5858</tr> 
    5959</tbody> 
    … …  
    6363<p class="topic-title first">Contents</p> 
    6464<ul class="simple"> 
    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> 
     65<li><a class="reference internal" href="#abstract" id="id5">Abstract</a></li> 
     66<li><a class="reference internal" href="#introduction" id="id6">Introduction</a></li> 
     67<li><a class="reference internal" href="#operation" id="id7">Operation</a><ul> 
     68<li><a class="reference internal" href="#single-protocol-nodes" id="id8">Single-protocol nodes</a></li> 
     69<li><a class="reference internal" href="#dual-stack-nodes" id="id9">Dual-stack nodes</a><ul> 
     70<li><a class="reference internal" href="#bootstrapping" id="id10">Bootstrapping</a></li> 
     71<li><a class="reference internal" href="#steady-state-operation" id="id11">Steady-state operation</a></li> 
     72</ul> 
     73</li> 
     74<li><a class="reference internal" href="#maximum-packet-size" id="id12">Maximum packet size</a></li> 
     75<li><a class="reference internal" href="#source-address-selection" id="id13">Source address selection</a></li> 
     76</ul> 
     77</li> 
     78<li><a class="reference internal" href="#changes-to-the-bittorrent-protocol" id="id14">Changes to the BitTorrent protocol</a></li> 
     79<li><a class="reference internal" href="#changes-and-extensions-to-existing-messages" id="id15">Changes and extensions to existing messages</a><ul> 
     80<li><a class="reference internal" href="#changes-to-existing-parameters" id="id16">Changes to existing parameters</a><ul> 
     81<li><a class="reference internal" href="#values" id="id17">values</a></li> 
     82</ul> 
     83</li> 
     84<li><a class="reference internal" href="#new-parameters" id="id18">New parameters</a><ul> 
     85<li><a class="reference internal" href="#nodes6" id="id19">nodes6</a></li> 
     86<li><a class="reference internal" href="#want" id="id20">want</a></li> 
     87</ul> 
     88</li> 
     89<li><a class="reference internal" href="#changes-to-message-semantics" id="id21">Changes to message semantics</a><ul> 
     90<li><a class="reference internal" href="#find-nodes-and-get-peers" id="id22">find_nodes and get_peers</a></li> 
     91<li><a class="reference internal" href="#announce-peers" id="id23">announce_peers</a></li> 
     92</ul> 
     93</li> 
     94</ul> 
     95</li> 
     96<li><a class="reference internal" href="#acknowledgements" id="id24">Acknowledgements</a></li> 
     97<li><a class="reference internal" href="#references" id="id25">References</a></li> 
     98<li><a class="reference internal" href="#copyright" id="id26">Copyright</a></li> 
    9699</ul> 
    97100</div> 
    … …  
    100103<p>This proposal describes a set of extensions to the BitTorrent DHT <a class="footnote-reference" href="#bep-5" id="id1">[1]</a> 
    101104to allow operation over IPv6.</p> 
    102 <p><strong>This is a very early draft</strong>, and <strong>not suitable for implementation</strong>.  Yet.</p> 
    103105</div> 
    104106<div class="section" id="introduction"> 
    … …  
    145147data provided by default is exactly what it needs.</p> 
    146148</div> 
    147 <div class="section" id="double-stack-nodes"> 
    148 <h2>Double-stack nodes</h2> 
     149<div class="section" id="dual-stack-nodes"> 
     150<h2>Dual-stack nodes</h2> 
    149151<p>While conceptually equivalent to a pair of single-protocol nodes, 
    150 a double-stack (IPv4 and IPv6) node can make bootstrap faster and 
     152a dual-stack (IPv4 and IPv6) node can make bootstrap faster and 
    151153improve the reliability of the protocol by &quot;leaking&quot; data between the 
    152154two DHTs, as described in the following paragraphs.</p> 
    153155<div class="section" id="bootstrapping"> 
    154156<h3>Bootstrapping</h3> 
    155 <p>A double-stack node that is bootstrapping its DHT will send find_nodes 
     157<p>A dual-stack node that is bootstrapping its DHT will send find_nodes 
    156158requests in order to populate its routing tables.  In order to accelerate 
    157159this process, it should request both &quot;nodes&quot; and &quot;nodes6&quot; fields.</p> 
    … …  
    169171</div> 
    170172</div> 
     173<div class="section" id="maximum-packet-size"> 
     174<h2>Maximum packet size</h2> 
     175<p>A node obeying this specification must not send UDP datagrams with 
     176a payload larger than 1024 octets, and must be able to receive UDP 
     177datagrams with a payload of 1024 octets or less.  (In the interest of 
     178robustness, a node should be able to receive datagrams with larger 
     179payloads.)</p> 
     180<blockquote> 
     181<p><strong>Rationale</strong>: a UDP datagram with a payload of 1024 octets easily 
     182fits within the IPv6 minimum maximum packet size, which is 1280 
     183octets <a class="footnote-reference" href="#ipv6" id="id2">[3]</a>.  In particular, such a packet will cross a Teredo 
     184tunnel with no fragmentation.</p> 
     185<p>In principle, IPv4 nodes might be unable to reassemble packets 
     186larger than 576 octets <a class="footnote-reference" href="#ipv4" id="id3">[4]</a>; in practice, however, due to the 
     187predominance of Ethernet networks, all IPv4 nodes are able to 
     188reassemble packets up to 1500 octets.</p> 
     189</blockquote> 
     190</div> 
     191<div class="section" id="source-address-selection"> 
     192<h2>Source address selection</h2> 
     193<p>The IPv6 DHT should use a socket bound to one of the host's global 
     194unicast IPv6 addresses rather than the &quot;unspecified address&quot; (::/128). 
     195When selecting to which address to bind, Teredo addresses (addresses 
     196in 2001:0000::/32) should be avoided if other global unicast addresses 
     197are available.</p> 
     198<blockquote> 
     199<p><strong>Rationale</strong>: The DHT relies on the publicly visible IP address of 
     200each node to remain constant.  Since multi-homing is common in IPv6, 
     201it is particularly important to bind the IPv6 socket to a well-defined 
     202address.</p> 
     203<p>While Teredo traffic can, in principle, be more efficient than 
     204native traffic, especially when speaking to other Teredo hosts, 
     205experience shows that Teredo routing tends to be brittle; hence, 
     206Teredo addresses should be avoided whenever possible.</p> 
     207<p>The same issues apply to multi-homed IPv4 hosts.  However, in IPv4 
     208multi-homing is not as common in IPv6, and in the presence of NAT 
     209the issues are somewhat more complicated, so this specification 
     210refrains from making any recommendations about binding of IPv4 
     211sockets.</p> 
     212</blockquote> 
     213</div> 
     214</div> 
     215<div class="section" id="changes-to-the-bittorrent-protocol"> 
     216<h1>Changes to the BitTorrent protocol</h1> 
     217<p>The PORT message, as defined in BEP-5, is extended to work over both 
     218IPv4 and IPv6.  The information provided by the PORT message only 
     219applies to the address family it is carried over: a PORT message sent 
     220over IPv4 only advertises participation in the IPv4 DHT, and a PORT 
     221message sent over IPv6 only advertises participation in the IPv6 DHT.</p> 
     222<blockquote> 
     223<strong>Rationale</strong>: in the presence of the LTEP extension negotiation 
     224protocol <a class="footnote-reference" href="#bep-10" id="id4">[2]</a>, which advertises a peer's addresses across 
     225address families, it might be possible to use the PORT message for 
     226both address families.  However, since an implementation need not 
     227participate in both DHTs, nor use the same port in both DHTs, this 
     228specification leaves the role of bridging the two DHTs to the 
     229'find_nodes' message (see below).</blockquote> 
    171230</div> 
    172231<div class="section" id="changes-and-extensions-to-existing-messages"> 
    … …  
    208267<p>The &quot;want&quot; parameter is allowed in the find_nodes and get_peers requests, 
    209268and governs the presence or absence of the &quot;nodes&quot; and &quot;nodes6&quot; parameters 
    210 in the requested reply.  Its value is a string of one or more characters, 
    211 which may include</p> 
     269in the requested reply.  Its value is a list of one or more strings, which 
     270may include</p> 
    212271<blockquote> 
    213272<ul class="simple"> 
    214 <li>&quot;4&quot;: the node requests the presence of a &quot;nodes&quot; key;</li> 
    215 <li>&quot;6&quot;: the node requests the presence of a &quot;nodes6&quot; key.</li> 
     273<li>&quot;n4&quot;: the node requests the presence of a &quot;nodes&quot; key;</li> 
     274<li>&quot;n6&quot;: the node requests the presence of a &quot;nodes6&quot; key.</li> 
    216275</ul> 
    217276</blockquote> 
    218 <p>For future extensibility, other characters may be present in the string, 
     277<p>For future extensibility, other strings may be present in the list, 
    219278and must be silently ignored on reception.</p> 
    220279<blockquote> 
    221 <strong>Note</strong>: the &quot;want&quot; parameter is currently under discussion.  It 
    222 has been suggested that it should be renamed to &quot;flags&quot;, and that 
    223 it should be a list of flags rather than a string.  This author 
    224 is not convinced yet.</blockquote> 
     280<strong>Rationale</strong>: the &quot;want&quot; parameter is not intended to carry random 
     281sundry flags, which can simply be included in the top-level 
     282dictionary of the message.  Extending the &quot;want&quot; parameter without 
     283good reason is discouraged.</blockquote> 
    225284</div> 
    226285</div> 
    … …  
    240299<blockquote> 
    241300<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 &quot;nodes&quot; and 
    243 &quot;values&quot; 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> 
     301defined in BEP-5, which specifies that &quot;nodes&quot; and &quot;values&quot; are 
     302mutually exclusive.  However, this change makes the DHT more 
     303reliable, and has been deployed by most implementations for over 
     304a year with no negative effects.</blockquote> 
    246305<p>When a node receives a get_peers request and it has contact 
    247306information for the matching address family and info-hash, it should 
    … …  
    257316<strong>Rationale</strong>: if the requesting node is a single-stack node, it has 
    258317no interest in values of the other address family.  If the 
    259 requesting node is a double-stack node, then it must perform the two 
     318requesting node is a dual-stack node, then it must perform the two 
    260319announces in parallel; providing both sets of data in both sets of 
    261320replies merely increases the amount of traffic without giving any 
    … …  
    281340<colgroup><col class="label" /><col /></colgroup> 
    282341<tbody valign="top"> 
    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. 
     342<tr><td class="label"><a class="fn-backref" href="#id1">[1]</a></td><td>BEP_0005.  DHT Protocol. 
    284343(<a class="reference external" href="http://www.bittorrent.org/beps/bep_0005.html">http://www.bittorrent.org/beps/bep_0005.html</a>)</td></tr> 
     344</tbody> 
     345</table> 
     346<table class="docutils footnote" frame="void" id="bep-10" rules="none"> 
     347<colgroup><col class="label" /><col /></colgroup> 
     348<tbody valign="top"> 
     349<tr><td class="label"><a class="fn-backref" href="#id4">[2]</a></td><td>BEP_0010.  Extension Protocol. 
     350(<a class="reference external" href="http://www.bittorrent.org/beps/bep_0010.html">http://www.bittorrent.org/beps/bep_0010.html</a>)</td></tr> 
     351</tbody> 
     352</table> 
     353<table class="docutils footnote" frame="void" id="ipv6" rules="none"> 
     354<colgroup><col class="label" /><col /></colgroup> 
     355<tbody valign="top"> 
     356<tr><td class="label"><a class="fn-backref" href="#id2">[3]</a></td><td><a class="reference external" href="http://www.faqs.org/rfcs/rfc2460.html">RFC 2460</a>.  Internet Protocol, Version 6 (IPv6) Specification. 
     357S. Deering, R. Hinden. December 1998.</td></tr> 
     358</tbody> 
     359</table> 
     360<table class="docutils footnote" frame="void" id="ipv4" rules="none"> 
     361<colgroup><col class="label" /><col /></colgroup> 
     362<tbody valign="top"> 
     363<tr><td class="label"><a class="fn-backref" href="#id3">[4]</a></td><td><a class="reference external" href="http://www.faqs.org/rfcs/rfc791.html">RFC 791</a>.  Internet Protocol.  J. Postel.  September 1981.</td></tr> 
    285364</tbody> 
    286365</table> 
    … …  
    288367<div class="section" id="copyright"> 
    289368<h1>Copyright</h1> 
    290 <p>This document has been placed in the public domain.</p> 
     369<p>This document is in the public domain.</p> 
    291370<!-- Local Variables: 
    292371mode: indented-text