Re: [BEHAVE] (no subject)

[ivan c <[e-mail]>]

On Fri, 21 Jun 2013 09:40:36 +0200, Simon Perreault
<[e-mail]> wrote:
>>
>> (1) one UDP socket (local endpoint) can have multiple communication
>> sessions. (with multiple remote endpoints)
>> (2) one TCP socket can have only one session.
>> (...)
>> Consequence:
>> Applications don't need to use more than one UDP local endpoint, but
need
>> to use many TCP local endpoints.
>> (...)
>> Consequence (1):
>> The use case for port overloading should be TCP, not UDP.
> 
> I don't understand how you jump from sockets on the host to external 
> ports on the NAT. I don't see how you reach this conclusion.
> 

We have, for all UDP communications and all outbound TCP sessions: 
- one socket is bound to one local endpoint on the host. Additionally, two
sockets have to bind to two different local endpoints.
- one internal endpoint (=local endpoint) is mapped to one external
endpoint on the NAT

As a result, if no overloading, the NAT has to allocate a new external
endpoint for every outbound TCP session.
This doesn't apply to UDP.


>> Back to NAT port overloading. A collision occurs when 2 sessions share
>> the
>> same 5-tuple.
> 
> Stop right here. Some NATs don't track sessions. Those NATs don't care 
> about 5-tuples. All they do is map internal 3-tuple to external 3-tuple.

> So for those NATs there is no conflict. They will just translate the 
> packets according to the existing mapping.
> 
> All the following doesn't make sense to me given this.
> 

Sure, *stateless* NATs also can't do much endpoint dependent filtering and
lots of other
things. They certainly can't do port overloading and are out of scope of
this discussion.
Nevertheless, NATs that do look at the full 5-tuple are free to implement
port overloading if they wish. The purpose of my text was to explain how
p2p applications interact with this, and in particular the relationship
with TCP Hole Punching.

Hope this helps.


-- 
_Ivan Chollet_