BEP42 and address translation about bittorrent.org HOT 3 CLOSED

There are several faulty assumptions:

• generally address translation does not affect the the remote addresses, only the local ones
• v4 and v6 are treated as separate networks in the DHT, they do not talk to each other directly (directly here means ignoring the potential dual-stack nature of some nodes)
• A network comprised of only 4 nodes where 3 are behind a shared NAT and a 4th is on the other side is not a realistic scenario.
• BEP42 does not restrict the total amount of available IDs per IP/subnet, it only restricts an ID prefix

from bittorrent.org.

Thanks for the quick reply!

generally address translation does not affect the the remote addresses, only the local ones

Right. But a client is supposed to only choose one node ID, right? If I'm behind a NAT, but I'm trying to communicate with other nodes both behind the NAT with me and on the other side of the NAT, different nodes see a different IP address for me. If I can only choose one node ID, half the network won't be able to validate my node ID with my IP address.

v4 and v6 are treated as separate networks in the DHT, they do not talk to each other directly (directly here means ignoring the potential dual-stack nature of some nodes)

Right. But if I'm on an IPv6 network (of which there are currently few right now), and I'm trying to communicate with the IPv4 DHT, most of the IPv4 clients are going to be on the other side of a gateway. The gateway is going to have a (very) limited number of v4 addresses it can assign to traffic coming from the v6 side to the v4 side. With only a few prefixes, it will pigeonhole all the clients on the v6 side into a very small number of prefixes.

Sorry I didn't make that more clear.

A network comprised of only 4 nodes where 3 are behind a shared NAT and a 4th is on the other side is not a realistic scenario.

Hmm. I'm confused. I mentioned a scenario with 3 nodes, 2 of which are behind a NAT. Is this what you're referring to? If so, I meant this as an illustration of the problem. A client on one side of the NAT will present different addresses to other clients on their side versus clients on the other side. That's 3 parties: the sender, and two different types of recipients. Does that make sense?

BEP42 does not restrict the total amount of available IDs per IP/subnet, it only restricts an ID prefix

Right.

But this doesn't fix the validation problem from two sides of a gateway.

Also, it means that users on one side of a gateway trying to communicate with users on the other side of a gateway will always be pigeonholed into a very limited number of prefixes. That is, they won't be uniformly distributed as the BEP claims. This will impact the DHT performance.

from bittorrent.org.

If I'm behind a NAT, but I'm trying to communicate with other nodes both behind the NAT with me and on the other side of the NAT, different nodes see a different IP address for me

A client on one side of the NAT will present different addresses to other clients on their side versus clients on the other side.

• communication with nodes behind a NAT is preferably done via LSD (BEP14).
• nodes behind a NAT generally use lan-local addresses. they're exempt from BEP42 anyway
• lan-local addresses are quite troublesome in the DHT and, in my opion, ought to be filtered out or segregated into a subsidiary routing table so they don't pollute results for outsiders

But if I'm on an IPv6 network (of which there are currently few right now), and I'm trying to communicate with the IPv4 DHT, most of the IPv4 clients are going to be on the other side of a gateway.

Also, it means that users on one side of a gateway trying to communicate with users on the other side of a gateway will always be pigeonholed into a very limited number of prefixes.

In my experience those kinds of nodes are of no service to the DHT anyway. Large-scale NATs just suck. Let me put this clearly: CGNATs range from ugly warts (those compliant with the relevant RFCs and supporting NAT-PMP) to utter horseshit (those that don't) from the perspective of p2p networks.

Their port mappings don't stay consistent. Sometimes replies not only come from the inconsistent ports, they come from different IPs belonging to the same NAT pool[1]. This renders them useless for the purpose of DHT routing or as contactable BT peers.

In fact, trying to participate in the DHT under such circumstances is a disservice to everyone else. They would better operate in read-only mode (BEP43) to not pollute everyone's routing tables. Although I don't know of any client that implements BEP43.

Note that i'm not a big fan of BEP42 (although I do see its advantages), but IPv4 exhaustion is not a good argument against it. It's just an argument for improving IPv6 support.

[1] log excerpt, note the last mismatch where it comes from a different IP. It belongs to some chinese mobile service, so I think CGNAT being the culprit here is highly likely:

[2016-05-05T23:51:43.620299Z][Error] mtid matched, socket address did not, ignoring message, request: /74.65.0.106:39627 -> response: /74.65.0.106:39546 v:LT��/0x4C540101
[2016-05-05T23:51:44.204634Z][Error] mtid matched, socket address did not, ignoring message, request: /123.186.13.84:13440 -> response: /123.186.21.84:15361 v:LT��/0x4C540100
[2016-05-05T23:51:44.315066Z][Error] mtid matched, socket address did not, ignoring message, request: /41.138.99.171:43611 -> response: /41.138.99.171:14388 v:UT��/0x5554A403
[2016-05-05T23:51:44.403397Z][Error] mtid matched, socket address did not, ignoring message, request: /74.96.242.74:6889 -> response: /74.96.242.74:1026 v:LT��/0x4C540010
[2016-05-05T23:51:44.515607Z][Error] mtid matched, socket address did not, ignoring message, request: /223.66.234.93:7728 -> response: /223.66.233.85:47421 v:LT��/0x4C540100

from bittorrent.org.