RE: [midcom] Port preservation
Pyda Srisuresh <srisuresh@yahoo.com> Mon, 26 April 2004 21:22 UTC
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24065 for <midcom-archive@odin.ietf.org>; Mon, 26 Apr 2004 17:22:39 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIDKq-0005Ze-T6 for midcom-archive@odin.ietf.org; Mon, 26 Apr 2004 17:08:17 -0400
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3QL8GFU021421 for midcom-archive@odin.ietf.org; Mon, 26 Apr 2004 17:08:16 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIDBN-0001qK-H2; Mon, 26 Apr 2004 16:58:29 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BICy5-0005wL-LC for midcom@optimus.ietf.org; Mon, 26 Apr 2004 16:44:48 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17809 for <midcom@ietf.org>; Mon, 26 Apr 2004 16:44:42 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BICy3-0007VZ-Dh for midcom@ietf.org; Mon, 26 Apr 2004 16:44:43 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BICmy-0005Wj-00 for midcom@ietf.org; Mon, 26 Apr 2004 16:33:17 -0400
Received: from web40414.mail.yahoo.com ([66.218.78.111]) by ietf-mx with smtp (Exim 4.12) id 1BICT7-0004TP-00 for midcom@ietf.org; Mon, 26 Apr 2004 16:12:45 -0400
Message-ID: <20040426201211.19836.qmail@web40414.mail.yahoo.com>
Received: from [66.224.113.194] by web40414.mail.yahoo.com via HTTP; Mon, 26 Apr 2004 13:12:11 PDT
Date: Mon, 26 Apr 2004 13:12:11 -0700
From: Pyda Srisuresh <srisuresh@yahoo.com>
Subject: RE: [midcom] Port preservation
To: Yutaka Takeda <takeday@pcrla.com>, Midcom <midcom@ietf.org>, stun@www.vovida.org
In-Reply-To: <B002AA5B97382E40935F83502A566F20010CB1@mail.kmerl.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org
X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL autolearn=no version=2.60
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-BeenThere: midcom@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/midcom>, <mailto:midcom-request@ietf.org?subject=unsubscribe>
List-Id: <midcom.ietf.org>
List-Post: <mailto:midcom@ietf.org>
List-Help: <mailto:midcom-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/midcom>, <mailto:midcom-request@ietf.org?subject=subscribe>
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 <takeday@pcrla.com> 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:srisuresh@yahoo.com] > > Sent: Friday, April 23, 2004 4:04 PM > > To: Yutaka Takeda; Midcom; stun@www.vovida.org > > 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 <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 ===== _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom
- [midcom] Port preservation Yutaka Takeda
- Re: [midcom] Port preservation Pyda Srisuresh
- RE: [midcom] Port preservation Yutaka Takeda
- Re: [midcom] Port preservation Cullen Jennings
- RE: [midcom] Port preservation Pyda Srisuresh
- RE: [midcom] Port preservation Christopher A. Martin
- Re: [midcom] Port preservation Jonathan Rosenberg
- RE: [midcom] Port preservation Christopher A. Martin
- RE: [midcom] Port preservation Christopher A. Martin
- Re: [midcom] Port preservation Cullen Jennings
- Re: [stun] Re: [midcom] Port preservation Cullen Jennings
- RE: [midcom] Port preservation Christopher A. Martin
- RE: [midcom] Port preservation Christopher A. Martin
- Re: [midcom] Port preservation Jonathan Rosenberg
- RE: [midcom] Port preservation Christopher A. Martin
- RE: [midcom] Port preservation Christopher A. Martin
- RE: [midcom] Port preservation Yutaka Takeda