RE: Port preservation

The following text from draft-ford-midcom-p2p-02.txt might be a good way to
answer this.

cheers,
suresh

5.3.1. Preserving port numbers


   Some NATs, when establishing a new UDP session, attempt to assign the
   same public port number as the corresponding private port number, if
   that port number happens to be available.  For example, if client A
   at address 10.0.0.1 initiates an outgoing UDP session with a datagram
   from port number 1234, and the NAT's public port number 1234 happens
   to be available, then the NAT uses port number 1234 at the NAT's
   public IP address as the translated endpoint address for the session.
   This behavior might be beneficial to some legacy UDP applications
   that expect to communicate only using specific UDP port numbers, but
   it is not recommended that applications depend on this behavior since
   it is only possible for a NAT to preserve the port number if at most
   one node on the internal network is using that port number.


   In addition, a NAT should NOT try to preserve the port number in a
   new session if doing so would conflict with an existing port
   binding. For example, suppose client A at internal port 1234 has
   established a session with external server S, and NAT A has created
   a port binding to public port 62000, because public port number 
   1234 on the NAT was not available at the time. Now, suppose port
   number 1234 on the NAT subsequently becomes available, and while the
   session between A and S is still active, client A initiates a new
   session from the same internal port (1234) to a different external
   node B. In this case, because a port binding has already been
   established between client A's port 1234 and the NAT's public port
   62000, this binding should be preserved and the new session should
   reuse the port binding (to port 62000).  The NAT should not assign
   public port 1234 to this new session just because port 1234 has
   become available. Such a behavior would not be likely to benefit the
   application in any way since the application has already been
   operating with a translated port number, and it would break any
   attempts the application might make to establish peer-to-peer
   connections using the UDP hole punching technique.

--- Yutaka Takeda <[email protected]> wrote:
> I see.
> 
> There is one more question.
> Looking at the Cullen's STUN test result, all the port preservation 
> NATs are of a cone NAT as primary behavior. Do you think there is
> a reason for that? I mean, if it is 'desirable' to have a certain
> port number on the NAT, and a host can talk to *multiple* hosts on 
> the port number...?
> 
> Thanks,
> Yutaka
> 
> 
> > -----Original Message-----
> > From: Pyda Srisuresh [mailto:[email protected]]
> > Sent: Friday, April 23, 2004 4:04 PM
> > To: Yutaka Takeda; Midcom; [email protected]
> > Subject: Re: [midcom] Port preservation
> > 
> > 
> > Port preservation is desirable in some limited cases where 
> > applications and
> > protocols require a certain number to be used for source 
> > and/or destination.
> > ex: IKE-v1 assumes UDP port 500 on both src and dest.
> > 
> > cheers,
> > suresh
> >  
> > --- Yutaka Takeda <[email protected]> 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
> > > [email protected]
> > > https://www1.ietf.org/mailman/listinfo/midcom
> > 
> > 
> > =====
> > 
> > 
> 
> _______________________________________________
> midcom mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/midcom


=====