Subject: [BEHAVE] Degree of compatibility of BitTorrent with endpoint-independent mapping?

From: Rémi Després <[email-masked]>
Date: Mon, 26 May 2008 10:32:24 +0200

There seems to be no doubt that BitTorrent is a major source of 
consumption of address-port couples in NATs.

No disagreement either, it seems, that if endpoint-dependent mapping 
could be allowed in NATs for a large subset of BitTorrent connections, 
this would nicely mitigate the risk of address-port exhaustion in NATs 
where such risk exists.

Then the following questions are IMHO relevant:

1. Are many BitTorrent connections established with a 6881-6889 
destination port in their first packet?
(YES IMU, but an expert would be better placed to tell.)

2. Is there a risk of simultenous open (TCP-SO) on these connections?
(NO IMU, but idem)

3. Independently of 1. and 2., is there a technical objection to
*NATs MAY use endpoint-dependent mapping IF AND ONLY IF destination 
ports of packets that trigger mappings are endorsed by IETF as 
compatible with such mapping*?
(NO IMU)

NOTE that the *MAY* in the sentence is such that some suppliers MAY keep 
forever an "endpoint-independent mapping for all" behavior.
They MAY also choose just a few initial ports of the list for 
endpoint-dependent mapping, and remain indefinitely like that, even if 
many more ports become endorsed in the list.

Here is a first (short) list that, if endorsed, could IMU do a lot of good:
HTTP, HTTPS, DNS, POP3, IMAP, SNMP... and BitTorrent if anwers

Regards.

Rémi
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Bruce Lowekamp <[email-masked]>
Date: Mon, 26 May 2008 21:32:10 -0400

I think there are major differences between BitTorrent applications as 
they exist now and as they would have to exist if NATs become even more 
common.

To the best of my knowledge (and I have not studied BitTorrent 
implementations extensively), they don't try to make any allowances for 
NAT behavior because there are enough hosts for which that is not an 
issue that the applications work if they try enough connections.

If NATs become even more common than they are now, BitTorrent 
applications may need to do more NAT traversal, so then TCP-SO would be 
more important.

However, regardless of that, I don't think that
- all BitTorrent applications use a particular range of ports
or
- only BitTorrent applications use those ports
or
- there is reason to believe that 5 years from now BitTorrent will be 
the common agreed use of those ports

so I don't think the BitTorrent ports are a good candidate for being a 
special case (if any are).

Currently, I think if BitTorrent applications opening ports is too big 
of a problem, I think rate limiting or per-host limiting the number of 
new connections accepted (as many nats already do) is the right solution.

Bruce

---

From: Rémi Després <[email-masked]>
Date: Tue, 27 May 2008 09:31:07 +0200

Thanks for the detailed answer.
More comments below.

> applications may need to do more NAT traversal, so then TCP-SO would be 

I am not a BitTorrent expert either but, IMU, a host behind a NAT can 
act, as far as BitTorrent is concerned, as though it would NOT be behind 
a NAT.

It suffices to activate the Port Mapping function of the NAT so that 
incoming connections on BitTorrent ports 6881-6889 go to this host.

Provided enough users do it, BiTorrent still works even if all users are 
behind NATs.

Also, to the best of my knowledge, BotTorrent works without any TCP-SO.

> - all BitTorrent applications use a particular range of ports

For the proposal at hand to be useful, it is not necessary that ALL  do it.
A significant proportion of them is sufficient.

> - only BitTorrent applications use those ports

So far,I have heard of no other application using these ports,  but I 
undrestand that there might be be some.

Should they exist, I doubt that, in addition to their using one of the 
nine BitTorrent ports, they would NEED endpoint-independent mapping.

In any case, if they exist, they should be fixed, or at least documented 
so that their case can be examined.

> the common agreed use of those ports

I don't see why you believe that BitTorrent ports should be used also 
for other applications.

Besides, in 5 years from now, I do hope that BitTorrent, like many other 
applications will use IPv6, withoiut any NAT.

> new connections accepted (as many nats already do) is the right solution.

If "per-host limiting the number of new connections" is seen as 
necessary, this IMO strongly reinforces the point that IETF must PERMIT 
a sparing use of address port couples, in particular for applications 
that use a lot of them. (The point is not to make it mandatory.)

Rémi

>> NOTE that the *MAY* in the sentence is such that some suppliers MAY 
>> keep forever an "endpoint-independent mapping for all" behavior.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 27 May 2008 21:08:09 -0300

> issue that the applications work if they try enough connections.

No, that's not exactly true. In practice, you get much lower download  
speeds with BitTorrent if you can't accept incoming connections. So  
(some) clients implement UPnP and NAT-PMP to open up ports for  
incoming sessions in the NAT, if present. It's also very common for  
BitTorrent users to set up a mapping manually.

So BitTorrent does often use NAT traversal, just not with any of the  
mechanisms that the IETF is familiar with.  :-)

> applications may need to do more NAT traversal, so then TCP-SO would  

I don't see simultaneous open happen for BitTorrent very soon. They  
may switch to UDP instead.

> new connections accepted (as many nats already do) is the right  

IMO, that needs to happen regardless. But that doesn't address the  
exact same issues as port-dependent behavior. The two could be  
complimentary.
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave