From midcom-bounces@ietf.org Wed Oct 05 16:11:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENFbz-0000mi-51; Wed, 05 Oct 2005 16:11:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENCDJ-0001OG-5M for midcom@megatron.ietf.org; Wed, 05 Oct 2005 12:33:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03074 for ; Wed, 5 Oct 2005 12:33:50 -0400 (EDT) Received: from basalt.cs.wisc.edu ([128.105.6.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENCMD-0000QY-3h for midcom@ietf.org; Wed, 05 Oct 2005 12:43:06 -0400 Received: from [128.105.185.18] (cedric.cs.wisc.edu [128.105.185.18]) by basalt.cs.wisc.edu (8.13.1/8.13.1) with ESMTP id j95GXlkv014524 for ; Wed, 5 Oct 2005 11:33:47 -0500 Message-ID: <4344006B.1020001@cs.wisc.edu> Date: Wed, 05 Oct 2005 11:33:47 -0500 From: Se-Chang Son User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en, ko-kr MIME-Version: 1.0 CC: Midcom Subject: Re: [midcom] updated TURN draft References: <42E553D5.4020009@cisco.com> <1122467155.3871.23.camel@hed040-040103.research.nokia.com> In-Reply-To: <1122467155.3871.23.camel@hed040-040103.research.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-CSL-MailScanner-Information: Please contact lab@cs.wisc.edu for more information X-CSL-MailScanner: Found to be clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: midcom.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: midcom-bounces@ietf.org Errors-To: midcom-bounces@ietf.org Hi all, Since I am a newbie to TURN and it seems that no one has answered Remi's question below, could someone explain me how a ftp will work with TURN? If somebody can explain how TURN supports the following scenario, she/he will be very appreciated. (1) ftp client behind a NAT (i.e. TURN client) makes ftp connection (control connection) to a ftp server in the public network (i.e. external client). (2) several ftp commands are exchanged between them (3) ftp client calls "put a_file" in the passive mode. In other words, the data connection is made from the ftp server to the ftp client but the data is transfered in the opposite direction. The draft says that TURN has the same effect of having address restricted NAT. With such type of NAT, I think the above scenario must be possible. Thank you. Remi Denis-Courmont wrote: > Hello again, > > I don't understand how TURN clients could receive incoming TCP > connections with the new draft 08. Maybe I'm getting it wrong. > > According to the draft, if a TCP connection is received by the TURN > server before the TURN client made a Send Request, the connection is > rejected. However, if the TURN client makes a Send Request before the > TURN server receives the TCP connection, then the TURN server will try > to establish the connection actively, instead of waiting for an incoming > connection from the specified host. > > It sounds like a vicious circle. In particular, I wonder how two TURN > clients could establish a TCP connection between themselves with the new > scheme. > > As a side note, I'm doubtful about the use of TURN server to relay > active TCP connections. Such connections should go through NATs without > the help of a TURN server, and as such, not using the TURN server would > save TURN server's bandwidth. > > There doesn't even seem to be the advantage of knowing the external > source (IP, port) tuple given the TURN server doesn't tell the TURN > client about the used "eph[me]eral port" that it has used. > > Regards, > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From midcom-bounces@ietf.org Mon Oct 17 04:39:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERQXB-0005Ey-7o; Mon, 17 Oct 2005 04:39:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERQX9-0005Et-OK for midcom@megatron.ietf.org; Mon, 17 Oct 2005 04:39:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25214 for ; Mon, 17 Oct 2005 04:39:44 -0400 (EDT) Received: from wall.ikr.uni-stuttgart.de ([129.69.170.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERQiR-0005U9-V9 for midcom@ietf.org; Mon, 17 Oct 2005 04:51:32 -0400 Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by wall.ikr.uni-stuttgart.de (Postfix) with ESMTP id 020B656D44; Mon, 17 Oct 2005 10:39:28 +0200 (CEST) Received: by netsrv1.ikr.uni-stuttgart.de (Postfix, from userid 539) id EBC96BD604; Mon, 17 Oct 2005 10:39:27 +0200 (CEST) Received: from ikr.uni-stuttgart.de (pc35 [10.21.21.35]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with SMTP id 9EC78BD602; Mon, 17 Oct 2005 10:39:27 +0200 (CEST) Received: by ikr.uni-stuttgart.de (sSMTP sendmail emulation); Mon, 17 Oct 2005 10:39:27 +0200 Date: Mon, 17 Oct 2005 10:39:27 +0200 From: Sebastian Kiesel To: midcom@ietf.org Message-ID: <20051017083927.GA15322@ikr.uni-stuttgart.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on netsrv1 X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63 X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: Martin Stiemerling Subject: [midcom] New Internet Draft on SIMCO over SCTP X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: midcom.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: midcom-bounces@ietf.org Errors-To: midcom-bounces@ietf.org Dear all, Please find below the announcement for a new Internet Draft that specifies how to transport SIMCO over SCTP. Experience with a prototype implementation has shown that this has several advantages over using TCP. Any comments are welcome. Thanks, Sebastian -- Sebastian Kiesel University of Stuttgart Tel: +49 711 685 7992 Institute of Communication Networks and Fax: +49 711 685 7983 Computer Engineering (IKR, formerly: IND) kiesel@ikr.uni-stuttgart.de Pfaffenwaldring 47, 70569 Stuttgart, Germany ----- Forwarded message from Internet-Drafts@ietf.org ----- X-Original-To: kiesel@ikr.uni-stuttgart.de Delivered-To: kiesel@ikr.uni-stuttgart.de To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Thu, 13 Oct 2005 18:50:01 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Subject: I-D ACTION:draft-kiesel-midcom-simco-sctp-00.txt X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: internet-drafts@ietf.org List-Id: i-d-announce.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: i-d-announce-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on netsrv1 X-Spam-Level: X-Spam-Status: No, hits=0.4 required=5.0 tests=MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.63 A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : SIMCO over SCTP Author(s) : S. Kiesel Filename : draft-kiesel-midcom-simco-sctp-00.txt Pages : 13 Date : 2005-10-13 This document specifies how to use SCTP for the transport of the SIMCO (Version 3.0) protocol. SIMCO (SImple Middlebox COnfiguration) is a protocol that implements the MIDCOM semantics. It can be used for controlling middleboxes such as firewalls and network address translators. SCTP (Stream Control Transmission Protocol) is a transport layer protocol that is expected to have advantages for this type of application, compared to TCP, which is the default transport layer protocol for SIMCO. The specific requirements for SIMCO when using SCTP instead of TCP are specified in this document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kiesel-midcom-simco-sctp-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-kiesel-midcom-simco-sctp-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-kiesel-midcom-simco-sctp-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce ----- End forwarded message ----- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom