Harold Posted February 5, 2009 Report Share Posted February 5, 2009 The DHT protocol (as per BEP 5) does not seem to allow IPv6 addresses at all. It technically didn't disallow being on IPv6 and acting as DHT node, but then you'd have to fake your IP address since it's locked at 4 bytes + 2 for port - so no one would be able to find you.So, what's the deal here? Is it not supposed to support IPv6? Will there be a new version? Is there some (un)official extension to it that I'm not aware of? Is IPv6 so rare that it's not worth the effort? Link to comment Share on other sites More sharing options...
jch Posted May 13, 2009 Report Share Posted May 13, 2009 > Is [DHT] not supposed to support IPv6?The official DHT spec only supports IPv4. This means (1) that DHT packets are only carried over IPv4 and (2) only IPv4 addresses can be published in the DHT.Extending DHT to IPv6 is somewhat tricky. The Kademlia protocol, which the DHT is based on, supposes that connectivity is transitive: if A can send a packet to B, and B can send a packet to C, then A can send a packet to B. Obviously, this is no longer true if you have IPv4, IPv6 and double-stack nodes.Obviously, we'll need to extend the DHT to IPv6 at some point, but we don't want to break the DHT, and hence we'll want to be careful to do it right. The simple approach is to run two distinct DHTs at the same time, one for IPv4, and one for IPv6. This doubles the total amount of DHT traffic, but yields a simple, clean protocol.The slightly-less-simple approach is to run two instances of the DHT, but allow leaking of information between IPv4 and IPv6. I.e. an IPv4 node can say ``by the way, I'm also reachable over IPv6'', or ``by the way, this torrent also has a number of IPv6 peers''.Finally, somebody could do some work to extend the Kademlia protocol to non-transitive networks. It is not clear to me at all how that could work -- in particular, it is not clear to me what is the right definition of ``bucket size'' in a double-stack network (do you split when you have enough IPv4 nodes? enough IPv6 nodes? you look at the sum? the max ?).My personal opinion is that the solution that is both simple and relatively efficient is the second one -- two parallel DHTs with information leaking between the two.-- Juliusz (not a µ-torrent developer) Link to comment Share on other sites More sharing options...
moogly Posted June 15, 2009 Report Share Posted June 15, 2009 Paper about Non-Transitive Connectivity and DHT:http://www.srhea.net/papers/ntr-worlds05.pdf Link to comment Share on other sites More sharing options...
Switeck Posted June 15, 2009 Report Share Posted June 15, 2009 "The Kademlia protocol, which the DHT is based on, supposes that connectivity is transitive: if A can send a packet to B, and B can send a packet to C, then A can send a packet to B."Perhaps you meant:"if A can send a packet to B, and B can send a packet to C, then A can send a packet to C."?This seems to imply that both B and C are not firewalled...but A may or may not be. Link to comment Share on other sites More sharing options...
Ultima Posted June 18, 2009 Report Share Posted June 18, 2009 *shrug* Connectivity doesn't necessarily imply bidirectionality of the connection, so that A is transitively connected to C doesn't necessarily mean C can get back to A. So A being firewalled would be irrelevant to connection transitivity Link to comment Share on other sites More sharing options...
jch Posted June 24, 2009 Report Share Posted June 24, 2009 > Perhaps you meant: "if A can send a packet to B, and B can send a packet to C, then A can send a packet to C."?Indeed.> This seems to imply that both B and C are not firewalled...but A may or may not be.Yep.But the issue we were discussing is that of different network protocols: if A is an IPv4 node, B a double-stack node, and C a pure IPv6 node, then A can communicate with B, B can communicate with C, but A cannot directly communicate with C. Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.