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-00.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