RE: [midcom] Port preservation

Hi all,
The only reason that I can think of, that may be a good reason, is to
provide the appearance that a client is communicating directly with a
server on a standard server port (for that professional, I'm a big
organization look and feel). Some applications do check for this for
paranoid security reasons, but they are less common.

We typically call this a static port translation, irregardless of
vendor, and it can be configured on many of the popular enterprise class
firewalls.

The other common type of configuration used for the same reason would be
a static IP NAT translation, which provides the server with a whole
range of ports that it can be listening on.

Chris

-----Original Message-----
From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org] On Behalf Of
Cullen Jennings
Sent: Monday, April 26, 2004 3:42 PM
To: Yutaka Takeda; Midcom; stun@www.vovida.org
Subject: Re: [midcom] Port preservation

There may be many but the two reasons I have heard are below - neither
of
which make much sense to me.

Makes debugging easier by not switching the port traffic is on. This
allows
network sniffers and such guess the type of traffic from the port.
(Personally I find this argument a little hard to buy given it is the
source
port that is being preserved and using ports for traffic type
determination
is usually based on the destination port)

Higher odds of interoperability for protocols. The argument goes that A
sends though a NAT to B. B may reply expecting to go to a certain port
number so if that does not change life will be better. I suspect that
most
applications that reply to the correct IP, are likely to also reply to
port
the packet came from but who knows.

The most common answer I get to this questions and the one that seems
most
believable ... "Because vendor X's NAT worked that way so we made ours
do
the same"

I don't know - it is a good questions. Can others provide any insight
into
this?

On 4/23/04 11:19 AM, "Yutaka Takeda" <takeday@pcrla.com> wrote:

> 
> Does anyone know what the real motivation for NAT designers to
> implement the port preservation[1] is? Is there an actual service
> or application that depends on this behavior? I just realized that
> I know such NATs exist but why...
> 
> [1] 
>
http://www.ietf.org/internet-drafts/draft-jennings-midcom-stun-results-0
0.txt
> 
> Yutaka
> 
> _______________________________________________
> midcom mailing list
> midcom@ietf.org
> https://www1.ietf.org/mailman/listinfo/midcom
> 

_______________________________________________
midcom mailing list
midcom@ietf.org
https://www1.ietf.org/mailman/listinfo/midcom

_______________________________________________
midcom mailing list
midcom@ietf.org
https://www1.ietf.org/mailman/listinfo/midcom