Changeset 11187 for dotorg/trunk

Timestamp:

11/20/09 09:16:34 (4 months ago)

Author:

bittorrent

Message:

updated bep32

Files:

• dotorg/trunk/html/beps/bep_0032.rst (modified) (17 diffs)

dotorg/trunk/html/beps/bep_0032.rst

@@ -9 +9 @@
 Content-Type: text/x-rst
 Created: 14-Oct-2009
-Post-History: 
+Post-History: 15-Oct-2009: Promote same ID in IPv6 and IPv4 nodes. Drop values6. Added some rationales
+              11-Nov-2011: Change want to be a list of flags.  Add nodes about MTU and source address selection.  Define behaviour of PORT message.
 
 
@@ -15 +16 @@
 ========
 
-This proposal describes a set of extensions to the BitTorrent DHT [#BEP-5]_
-to allow operation over IPv6.
+This document describes a set of extensions to the BitTorrent DHT
+[#BEP-5]_ to allow operation over IPv6.
 
 
@@ -29 +30 @@
 address exhaustion.
 
-A number of extensions (mostly undocumented) to the BitTorrent protocol
-have been defined in order to allow it to operate over IPv6.
-Unfortunately, these extensions only allow locating IPv6 peers by using
-trackers or through peer exchange -- but not from the DHT.  This document
-describes the procedures and message formats needed to deploy an IPv6
-version of the BitTorrent DHT.
-
-The extension described in this document also solves a long-standing
-issue with the protocol defined in BEP-5.  The presence of contact
-information in the reply is no longer governed by the presence of
-a "values" key; this avoids the well-known problem of contact
-information being masked by peer information.  While this is an
-incompatible change, it is believed to be properly handled by all
-deployed implementations.
+A number of extensions (mostly undocumented) to the BitTorrent
+protocol have been defined in order to allow it to operate over IPv6.
+Unfortunately, these extensions only allow locating IPv6 peers by
+using trackers or through peer exchange -- but not from the DHT.  This
+document describes the procedures and message formats used in the IPv6
+DHT.
 
 
@@ -48 +41 @@
 =========
 
-There are two distinct DHTs: the existing IPv4 DHT, and the new IPv6 DHT.
+There are two distinct DHTs: the IPv4 DHT, and the IPv6 DHT.
 
 The two DHTs are independent, meaning that no IPv6 data is stored in the
@@ -60 +53 @@
 mostly congruent.
 
-By default, messages only carry data in the address family implied by the
-network layer protocol.  In the case of the "nodes" and "nodes6" arguments
-in replies to the find_nodes and get_peers requests, however, the requestor
-may request that the reply contain "nodes", "nodes6" or both fields.
+Usually, messages only carry data in the address family implied by the
+network layer protocol.  In the case of the find_nodes and get_peers
+requests, however, the requestor may optionally request that the reply
+should contain IPv4 node information, IPv6 node information, or both.
 
 
@@ -80 +73 @@
 a dual-stack (IPv4 and IPv6) node can make bootstrap faster and
 improve the reliability of the protocol by "leaking" data between the
-two DHTs, as described in the following paragraphs.
+two DHTs, as described in the following sections.
 
 
@@ -88 +81 @@
 A dual-stack node that is bootstrapping its DHT will send find_nodes
 requests in order to populate its routing tables.  In order to accelerate
-this process, it should request both "nodes" and "nodes6" fields.
+this process, it should request both IPv4 and IPv6 node information.
 
 
@@ -94 +87 @@
 ''''''''''''''''''''''
 
-Once bootstrap is successful, a node should normally only request
-"nodes" replies from IPv4 nodes, and "nodes6" replies from IPv6 nodes.
-Requesting both address families in all requests is unlikely to
-provide useful information, and hence uselessly increases network
-traffic.
+Once bootstrap is successful, a node should normally only request IPv4
+node information from IPv4 nodes, and IPv6 node information from IPv6
+nodes.  Requesting node information for both address families in all
+requests is unlikely to provide useful information, and hence
+increases network traffic with no benefit.
 
 In order to increase the reliability of the DHT after a single-protocol
 network outage, however, a node may *ocasionally* send a request for
-"nodes" to an IPv6 node, or a request for "nodes6" to an IPv4 node.
+IPv4 node information to an IPv6 node, or a request for IPv6 node
+information to an IPv4 node.
 
 
@@ -145 +139 @@
 
   The same issues apply to multi-homed IPv4 hosts.  However, in IPv4
-  multi-homing is not as common in IPv6, and in the presence of NAT
+  multi-homing is not as common as in IPv6, and in the presence of NAT
   the issues are somewhat more complicated, so this specification
   refrains from making any recommendations about binding of IPv4
@@ -156 +150 @@
 The PORT message, as defined in BEP-5, is extended to work over both
 IPv4 and IPv6.  The information provided by the PORT message only
-applies to the address family it is carried over: a PORT message sent
-over IPv4 only advertises participation in the IPv4 DHT, and a PORT
-message sent over IPv6 only advertises participation in the IPv6 DHT.
+applies to the address it was sent from; this implies that a PORT
+message sent over IPv4 only advertises participation in the IPv4 DHT,
+and a PORT message sent over IPv6 only advertises participation in the
+IPv6 DHT.
+
+Multihomed hosts should take care to only send PORT messages over
+connections established from the address on which they participate in
+the DHT.
 
   **Rationale**: in the presence of the LTEP extension negotiation
   protocol [#BEP-10]_, which advertises a peer's addresses across
-  address families, it might be possible to use the PORT message for
-  both address families.  However, since an implementation need not
-  participate in both DHTs, nor use the same port in both DHTs, this
-  specification leaves the role of bridging the two DHTs to the
-  'find_nodes' message (see below).
-
+  address families, it would in principle be possible to use the PORT
+  message for both address families.  However, since an implementation
+  need not participate in both DHTs, nor use the same port in both
+  DHTs, this specification leaves the role of bridging the two DHTs to
+  the 'find_nodes' message (see below).
 
 
@@ -183 +181 @@
 information for a single peer.
 
-In a reply sent over IPv6, "values' contains a list of strings, each
+In a reply sent over IPv6, "values" contains a list of strings, each
 of which contains compact format IPv6 contact information for a single
 peer.
@@ -189 +187 @@
 Implementations of this specification must be able to properly parse
 hybrid "values" lists -- lists containing an arbitrary mixture of
-6-octet IPv4 values and 18-octet IPv6 values.  However,
-implementations should not send such hybrid lists, and must not send
-hybrid lists in a reply to an IPv4 request that doesn't contain
-a "want" parameter.
+6-octet IPv4 values and 18-octet IPv6 values.  However, implementations
+should not send such hybrid lists, and must not send hybrid lists in
+a reply to an IPv4 request that doesn't contain a "want" parameter.
 
   **Rationale**: a request sent over IPv4 with no "want" parameter
@@ -205 +202 @@
 ''''''
 
-The "nodes6" parameter is analogous to the existing "nodes" parameter:
-when present, it carries a string containing the compact IPv6 node
-info for the 8 closest good nodes in the sending node's IPv6 routing
-table.  This parameter is allowed in replies to the find_nodes and
-get_peers messages (see below).
+The "nodes6" parameter is analogous to the "nodes" parameter: when
+present, it carries a string containing the compact IPv6 node
+information for the 8 closest good nodes in the sending node's IPv6
+routing table.  This parameter is allowed in replies to the find_nodes
+and get_peers messages (see below).
 
 
@@ -230 +227 @@
    sundry flags, which can simply be included in the top-level
    dictionary of the message.  Extending the "want" parameter without
-   good reason is discouraged.
+   good reason is not recommended.
 
 
@@ -239 +236 @@
 ''''''''''''''''''''''''
 
-A node sending a find_nodes or get_peers request should include
-a "want" parameter containing one or both of the characters "4" or
-"6".  A node replying to a find_nodes or get_peers request should
-include a "nodes" parameter if and only if the request's "want"
-parameter included a "4", and should include a "nodes6" parameter if
-and only if the request's "want" parameter included a "6".
+A node sending a find_nodes or get_peers request may include a "want"
+parameter containing one or both of the strings "n4" or "n6".  A node
+replying to a find_nodes or get_peers request that includes a "want"
+parameter should include a "nodes" parameter if the request's "want"
+parameter contained the string "n4", and should include a "nodes6"
+parameter if the request's "want" parameter contained the string "n6".
 
 In the absence of a "want" parameter, the reply should include "nodes"
@@ -253 +250 @@
   defined in BEP-5, which specifies that "nodes" and "values" are
   mutually exclusive.  However, this change makes the DHT more
-  reliable, and has been deployed by most implementations for over
-  a year with no negative effects.
-
-When a node receives a get_peers request and it has contact
+  reliable, and has been deployed by most implementations with no
+  negative effects.
+
+When a node receives a get_peers request and it has peer contact
 information for the matching address family and info-hash, it should
 additionally include a "values" parameter containing a list of 6-octet
@@ -288 +285 @@
 ================
 
-I gratefully acknowledge the influence of *The 8472* and *arvid* over
-this work.
+I gratefully acknowledge the help of *The 8472* and *arvid* in
+developing this specification.