In message <200510051555.12934.dimss@solutions.lv>, Dmitry Ivanov writes:
> On Wednesday 05 October 2005 15:25, Igor Sobrado wrote:
> >   map fxp0 192.168.2.0/24 -> 10.0.0.5/32 portmap tcp/udp 49152:65535
> 
> These are _source_ ports.
> 
> >    49152 - 65535   dynamic/private    used by clients to establish a
> >                    ports              connection to a server
> 
> These are _destination_ ports.
> 
> Source and destination ports are entirely different concepts. Source 
> port number is just "socket ID" (randomly) selected by OS. Destination 
> port is more important thing because TCP/UDP servers listen for 
> incoming requests on specified destination ports.
> 
> Don't worry about NAT in this case.

Hi Dmitry.

You are absolutely right.  Daemons usually allocate fixed destination
ports.  A client will have serious challenges when contacting with a
server if it is listening on a randomly choosen (or at least not fixed)
port---apart of being a real nightmare when configuring firewall rulesets!
Certainly, destination ports identify services on a IP network.

From my (limited) knowledge on networking I understand that well-known
ports and reserved ports are _destination_ ports, but dynamic/private
ports are _source_ ports allocated by clients when establishing a
connection with a server (either a local or remote server) listening
on a port in the range 0-49151 [*].  Each time we establish a connection
with a server, the client (e.g., the telnet(1) command) allocates a
randomly selected port in the range 49152-65535.

Of course, if both NAT and network clients allocate _source_ ports in
the same way (i.e., delegating on the OS) there should not be problems
in sharing the same ports range.  The OS will care about allocating
free ports when required (at most, I believe that there will be
a small scalability issue when opening ports if a lot of source ports
are currently open).

Can ports allocated by NAT and network clients collide?

If not, I suppose that using the ports range 49152-65535 for NAT
mapping is an acceptable practice.

On the other hand, I agree with Jonathan A. Kollasch about using IPv6
and avoiding NAT at all.  Sadly, IPv6 is not being widely deployed.
I have big challenges setting up 6to4 tunnels here.  I really like
IPv6 (the protocol specification is much simpler than IPv4).

-----------------
[*] for the goals of this thread, I suppose that we do not need
    to distinguish between well-known and reserved ports either
    from a political point of view (hi, IANA!) or a technical
    point of view (privileges required to open ports in range 0-1023).