RE: [midcom] Port preservation

Thanks everyone for the comments.

After reading the comments and observing the actual NATs behavior,
and considering the amount of deployment of NATs that operates port 
preservation, my conclusion is that there is no solid and practical
situation where the port preservation (on dynamically created 
bindings, not the static port mapping) is 'desired' in the real network
environment.

IKE-v1 might get a benefit from the port preservation behavior (thanks
to Suresh for letting me know), however, since majority of NATs do 
not preserve the port number, I believe network admins do not depend 
on this behavior, or they do not even know about port preservation.

For NAT developers, they might feel like picking the same port
number for a new binding if available rather than generating a 
different one, might be considering retaining a 'service' associated
to the port number at best but not knowing how an application 
would use it. This seems to be convincing me why we have it today.

Thanks,
Yutaka

> -----Original Message-----
> From: Cullen Jennings [mailto:fluffy@cisco.com]
> Sent: Monday, April 26, 2004 1:41 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-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