From owner-nat@livingston.com Mon Apr 3 19:00:23 2000 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26648 for ; Mon, 3 Apr 2000 19:00:23 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.9.3/8.9.3) with ESMTP id PAA12810; Mon, 3 Apr 2000 15:56:20 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id PAA27284 for nat-outgoing; Mon, 3 Apr 2000 15:53:34 -0700 (PDT) Message-ID: <7118259C3044D311942700508B2CA5BB2581F0@BALANCE> From: Nia Schmald To: "'nat@livingston.com'" Subject: (NAT) ALG source Date: Mon, 3 Apr 2000 15:48:56 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-nat@livingston.com Precedence: bulk Reply-To: Nia Schmald Can anyone please point me to a location to get freely usable NAT application layer gateway source code for common protocols (FTP, IRC, etc.)? Thank you, nia --- Nia Schmald nia@coactive.com Coactive Networks, Inc. http://www.coactive.com 4000 Bridgeway, Suite 303 voice:(415)289-1722 Sausilito, CA 94965 fax: (415)289-1320 - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message. From owner-nat@livingston.com Wed Apr 5 00:45:17 2000 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24793 for ; Wed, 5 Apr 2000 00:45:16 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.9.3/8.9.3) with ESMTP id VAA10797; Tue, 4 Apr 2000 21:41:38 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id VAA05116 for nat-outgoing; Tue, 4 Apr 2000 21:39:57 -0700 (PDT) Message-Id: <200001111140.GAA03746@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: nat@livingston.com From: Internet-Drafts@ietf.org Subject: (NAT) I-D ACTION:draft-ietf-nat-rsip-protocol-05.txt Date: Tue, 11 Jan 2000 06:40:10 -0500 Sender: owner-nat@livingston.com Precedence: bulk Reply-To: Internet-Drafts@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Address Translators Working Group of the IETF. Title : Realm Specific IP: Protocol Specification Author(s) : M. Borella, D. Grabelsky, J. Lo, K. Tuniguchi Filename : draft-ietf-nat-rsip-protocol-05.txt Pages : 46 Date : 10-Jan-00 This document presents a protocol with which to implement Realm Specific IP (RSIP). The protocol defined herein allows negotiation of resources between an RSIP client and server, so that the client can lease some of the server's addressing parameters in order to establish a global network presence. This protocol is designed to operate on the application layer and to use its own TCP or UDP port. In particular, the protocol allows a server to allocate addressing and control parameters to a client such that a flow policy can be enforced at the server. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nat-rsip-protocol-05.txt 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-ietf-nat-rsip-protocol-05.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-ietf-nat-rsip-protocol-05.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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000110111345.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nat-rsip-protocol-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nat-rsip-protocol-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000110111345.I-D@ietf.org> --OtherAccess-- --NextPart-- - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message. From owner-nat@livingston.com Wed Apr 5 00:45:18 2000 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24800 for ; Wed, 5 Apr 2000 00:45:18 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.9.3/8.9.3) with ESMTP id VAA10824; Tue, 4 Apr 2000 21:41:41 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id VAA05179 for nat-outgoing; Tue, 4 Apr 2000 21:40:14 -0700 (PDT) Message-Id: <200003141121.GAA20124@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: nat@livingston.com From: Internet-Drafts@ietf.org Subject: (NAT) I-D ACTION:draft-ietf-nat-rsip-protocol-06.txt Date: Tue, 14 Mar 2000 06:21:01 -0500 Sender: owner-nat@livingston.com Precedence: bulk Reply-To: Internet-Drafts@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Address Translators Working Group of the IETF. Title : Realm Specific IP: Protocol Specification Author(s) : M. Borella, D. Grabelsky, J. Lo, K. Tuniguchi Filename : draft-ietf-nat-rsip-protocol-06.txt Pages : 48 Date : 13-Mar-00 This document presents a protocol with which to implement Realm Specific IP (RSIP). The protocol defined herein allows negotiation of resources between an RSIP host and gateway, so that the host can lease some of the gateway's addressing parameters in order to establish a global network presence. This protocol is designed to operate on the application layer and to use its own TCP or UDP port. In particular, the protocol allows a gateway to allocate addressing and control parameters to a host such that a flow policy can be enforced at the gateway. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nat-rsip-protocol-06.txt 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-ietf-nat-rsip-protocol-06.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-ietf-nat-rsip-protocol-06.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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000313135949.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nat-rsip-protocol-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nat-rsip-protocol-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000313135949.I-D@ietf.org> --OtherAccess-- --NextPart-- - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message. From owner-nat@livingston.com Wed Apr 5 00:45:21 2000 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24821 for ; Wed, 5 Apr 2000 00:45:20 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.9.3/8.9.3) with ESMTP id VAA10801; Tue, 4 Apr 2000 21:41:38 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id VAA05126 for nat-outgoing; Tue, 4 Apr 2000 21:39:59 -0700 (PDT) Message-Id: <200001241141.GAA01496@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: nat@livingston.com From: Internet-Drafts@ietf.org Subject: (NAT) I-D ACTION:draft-ietf-nat-snmp-alg-03.txt Date: Mon, 24 Jan 2000 06:41:46 -0500 Sender: owner-nat@livingston.com Precedence: bulk Reply-To: Internet-Drafts@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Address Translators Working Group of the IETF. Title : An SNMP Application Level Gateway for Payload Address Translation Author(s) : D. Raz, J. Schoenwaelder, B. Sugla Filename : draft-ietf-nat-snmp-alg-03.txt Pages : 25 Date : 21-Jan-00 This document describes the Application Level Gateway (ALG) for the Simple Network Management Protocol (SNMP) by which IP addresses in the payload of SNMP packets are statically mapped from one group to another. The SNMP ALG is a specific case of an Application Level Gateway as described in [17]. An SNMP ALG allows network management stations to manage multiple networks that use conflicting IP addresses. This can be important in environments where there is a need to use SNMP with NAT in order to manage several potentially overlapping addressing realms. This document includes a detailed description of the requirements and limitations for an implementation of an SNMP Application Level Gateway. It also discusses other approaches to exchange SNMP packets across conflicting addressing realms. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nat-snmp-alg-03.txt 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-ietf-nat-snmp-alg-03.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-ietf-nat-snmp-alg-03.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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000121104432.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nat-snmp-alg-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nat-snmp-alg-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000121104432.I-D@ietf.org> --OtherAccess-- --NextPart-- - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message. From owner-nat@livingston.com Wed Apr 5 00:45:22 2000 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24823 for ; Wed, 5 Apr 2000 00:45:21 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.9.3/8.9.3) with ESMTP id VAA10813; Tue, 4 Apr 2000 21:41:40 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id VAA05139 for nat-outgoing; Tue, 4 Apr 2000 21:40:02 -0700 (PDT) Message-Id: <200002011141.GAA11376@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: nat@livingston.com From: Internet-Drafts@ietf.org Subject: (NAT) I-D ACTION:draft-ietf-nat-rsip-ipsec-02.txt Date: Tue, 01 Feb 2000 06:41:58 -0500 Sender: owner-nat@livingston.com Precedence: bulk Reply-To: Internet-Drafts@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Address Translators Working Group of the IETF. Title : RSIP Support for End-to-end IPsec Author(s) : G. Montenegro, M. Borella Filename : draft-ietf-nat-rsip-ipsec-02.txt Pages : 19 Date : 31-Jan-00 This document proposes mechanisms that enable 'Realm-Specific IP' (RSIP) to handle end-to-end IPSEC. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nat-rsip-ipsec-02.txt 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-ietf-nat-rsip-ipsec-02.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-ietf-nat-rsip-ipsec-02.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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000131134353.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nat-rsip-ipsec-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nat-rsip-ipsec-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000131134353.I-D@ietf.org> --OtherAccess-- --NextPart-- - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message. From owner-nat@livingston.com Wed Apr 5 00:45:22 2000 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24840 for ; Wed, 5 Apr 2000 00:45:21 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.9.3/8.9.3) with ESMTP id VAA10791; Tue, 4 Apr 2000 21:41:38 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id VAA05148 for nat-outgoing; Tue, 4 Apr 2000 21:40:05 -0700 (PDT) Message-Id: <200002171127.GAA09112@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: nat@livingston.com From: Internet-Drafts@ietf.org Subject: (NAT) I-D ACTION:draft-ietf-nat-rsip-slp-00.txt Date: Thu, 17 Feb 2000 06:27:52 -0500 Sender: owner-nat@livingston.com Precedence: bulk Reply-To: Internet-Drafts@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Address Translators Working Group of the IETF. Title : Finding an RSIP Server with SLP Author(s) : J. Kempf, G. Montenegro Filename : draft-ietf-nat-rsip-slp-00.txt Pages : 14 Date : 16-Feb-00 Service Location Protocol (SLP) is an IETF standards track protocol specifically designed to allow clients to find servers offering particular services. Since RSIP clients require a mechanism to discover RSIP servers, SLP is a natural match for a solution. The document contains an SLP service type template that describes the advertisements made by RSIP servers for their services. The service type template is the basis for an IANA standard definition of the advertisements offered by RSIP servers, an important step toward interoperability. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nat-rsip-slp-00.txt 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-ietf-nat-rsip-slp-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-ietf-nat-rsip-slp-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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000216123219.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nat-rsip-slp-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nat-rsip-slp-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000216123219.I-D@ietf.org> --OtherAccess-- --NextPart-- - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message. From owner-nat@livingston.com Wed Apr 5 00:56:06 2000 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24803 for ; Wed, 5 Apr 2000 00:45:18 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.9.3/8.9.3) with ESMTP id VAA10841; Tue, 4 Apr 2000 21:41:44 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id VAA05182 for nat-outgoing; Tue, 4 Apr 2000 21:40:17 -0700 (PDT) Message-Id: <200003162119.QAA23583@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: nat@livingston.com From: Internet-Drafts@ietf.org Subject: (NAT) I-D ACTION:draft-ietf-nat-rsip-ipsec-03.txt Date: Thu, 16 Mar 2000 16:19:47 -0500 Sender: owner-nat@livingston.com Precedence: bulk Reply-To: Internet-Drafts@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Address Translators Working Group of the IETF. Title : RSIP Support for End-to-end IPSEC Author(s) : G. Montenegro, M. Borella Filename : draft-ietf-nat-rsip-ipsec-03.txt Pages : 19 Date : 15-Mar-00 This document proposes mechanisms that enable 'Realm-Specific IP' (RSIP) to handle end-to-end IPSEC. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nat-rsip-ipsec-03.txt 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-ietf-nat-rsip-ipsec-03.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-ietf-nat-rsip-ipsec-03.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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000315132856.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nat-rsip-ipsec-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nat-rsip-ipsec-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000315132856.I-D@ietf.org> --OtherAccess-- --NextPart-- - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message. From owner-nat@livingston.com Wed Apr 5 00:56:06 2000 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24822 for ; Wed, 5 Apr 2000 00:45:20 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.9.3/8.9.3) with ESMTP id VAA10798; Tue, 4 Apr 2000 21:41:38 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id VAA05177 for nat-outgoing; Tue, 4 Apr 2000 21:40:13 -0700 (PDT) Message-Id: <200003141120.GAA20084@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: nat@livingston.com From: Internet-Drafts@ietf.org Subject: (NAT) I-D ACTION:draft-ietf-nat-rsip-framework-04.txt Date: Tue, 14 Mar 2000 06:20:55 -0500 Sender: owner-nat@livingston.com Precedence: bulk Reply-To: Internet-Drafts@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Address Translators Working Group of the IETF. Title : Realm Specific IP: A Framework Author(s) : M. Borella, G. Montenegro, D. Grabelsky, J. Lo Filename : draft-ietf-nat-rsip-framework-04.txt Pages : 33 Date : 13-Mar-00 This document examines the general framework of Realm Specific IP (RSIP). RSIP is intended as a alternative to NAT in which the end-to- end integrity of packets is maintained. We focus on implementation issues, deployment scenarios, and interaction with other layer-three protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nat-rsip-framework-04.txt 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-ietf-nat-rsip-framework-04.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-ietf-nat-rsip-framework-04.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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000313135941.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nat-rsip-framework-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nat-rsip-framework-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000313135941.I-D@ietf.org> --OtherAccess-- --NextPart-- - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message. From owner-nat@livingston.com Wed Apr 5 00:56:07 2000 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24820 for ; Wed, 5 Apr 2000 00:45:20 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.9.3/8.9.3) with ESMTP id VAA10812; Tue, 4 Apr 2000 21:41:40 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id VAA05175 for nat-outgoing; Tue, 4 Apr 2000 21:40:11 -0700 (PDT) Message-Id: <200003071130.GAA29501@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: nat@livingston.com From: Internet-Drafts@ietf.org Subject: (NAT) I-D ACTION:draft-ietf-nat-protocol-complications-02.txt Date: Tue, 07 Mar 2000 06:30:06 -0500 Sender: owner-nat@livingston.com Precedence: bulk Reply-To: Internet-Drafts@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Address Translators Working Group of the IETF. Title : Protocol Complications with the IP Network Address Translator (NAT) Author(s) : M. Holdrege , P. Srisuresh Filename : draft-ietf-nat-protocol-complications-02.txt Pages : 13 Date : 06-Mar-00 Many common internet applications can be adversely affected when the communicating end nodes are not in the same address realm and seek the assistance of NAT (enroute) to bridge the realms. NAT by itself cannot provide the necessary application/protocol transparency in all cases. Often, a NAT device seeks the assistance of Application Level Gateways (ALGs) to provide the transparency necessary for each application. The purpose of this document is to identify the protocols and applications that cannot function with NAT enroute. The document attempts to identify the problem cause and describe known work-arounds and the requirements on the part of ALGs to make the protocols/applications transparent with NAT enroute. It is impossible to capture all the applications and their issues with NAT in a single document. This document attempts to capture as much information as possible. We hope, the coverage provides necessary clues for applications not covered by the document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nat-protocol-complications-02.txt 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-ietf-nat-protocol-complications-02.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-ietf-nat-protocol-complications-02.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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000306120712.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nat-protocol-complications-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nat-protocol-complications-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000306120712.I-D@ietf.org> --OtherAccess-- --NextPart-- - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message. From owner-nat@livingston.com Thu Apr 13 13:30:06 2000 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08748 for ; Thu, 13 Apr 2000 13:30:05 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.9.3/8.9.3) with ESMTP id KAA29361; Thu, 13 Apr 2000 10:23:12 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id KAA20285 for nat-outgoing; Thu, 13 Apr 2000 10:13:34 -0700 (PDT) Message-Id: <3.0.2.32.20000413191727.0090ab90@nausicaa.coritel.it> X-Sender: veltri@nausicaa.coritel.it X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.2 (32) Date: Thu, 13 Apr 2000 19:17:27 +0200 To: nat@livingston.com From: Luca Veltri Subject: (NAT) h323 nat module for linux Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-nat@livingston.com Precedence: bulk Reply-To: Luca Veltri Hi all, we have just released the source code for a Linux IP masquerading module for H.323. H.323 is a standard of the ITU that defines the protocols to provide audiovisual communication sessions and it is currently implemented by various Internet real time applications as Microsoft Internet Meeting (for windows95/98/2000/NT) and Voxilla (for Linux). The H.323 masquerading module allows a Linux NAT to transparently proxy H.323 sessions. The module source code is available at the following URL: ftp://ftp.coritel.it/pub/linux/ip_masq/ ciao, luca - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message. From owner-nat@livingston.com Tue Apr 18 11:45:37 2000 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06629 for ; Tue, 18 Apr 2000 11:45:35 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.9.3/8.9.3) with ESMTP id IAA07273; Tue, 18 Apr 2000 08:38:13 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id IAA11658 for nat-outgoing; Tue, 18 Apr 2000 08:35:16 -0700 (PDT) Message-ID: <20000418153409.22197.qmail@web1405.mail.yahoo.com> Date: Tue, 18 Apr 2000 08:34:09 -0700 (PDT) From: Pyda Srisuresh Subject: (NAT) Re: interception proxies To: Vernon Schryver , wrec@cs.utk.edu Cc: nat@livingston.com, holdrege@lucent.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-nat@livingston.com Precedence: bulk Reply-To: Pyda Srisuresh --- Vernon Schryver wrote: > > From: Joe Touch > > > ... > > The only question is whether there is something similar between NATs and > > transparent proxies. Maybe "modifying IP packets considered harmful". > > The issue with NATs may best be added under "even within the same AD, > > transparent proxies are dangerous because..." including the IP ID and > > TCP port and sequence number issues there seems on-topic. (?) > > Agreed, NAT's and redirecting proxies are technically similar. > > (However, I'm not sure that 'a "transparent proxy" is a proxy that does > not modify the request or response beyond what is required for proxy > authentication and identification' is similar to a NAT box or a redirecting > proxy.) > > Is there an RFC that includes the many complaints that have been made about > NAT boxes in the main IETF list? > Not an RFC. But, a draft addressing precisely this. It is titled "Protocol Complications with the IP Network Address Translator". . The draft should be going out for an IETF-wide last call shortly(It's in Steve Coya's list of things to do). Any comments and input are most welcome. Thanks. > > vjs > cheers, suresh ===== __________________________________________________ Do You Yahoo!? Send online invitations with Yahoo! Invites. http://invites.yahoo.com - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message. From owner-nat@livingston.com Thu Apr 20 23:02:33 2000 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26519 for ; Thu, 20 Apr 2000 23:02:32 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.9.3/8.9.3) with ESMTP id TAA23590; Thu, 20 Apr 2000 19:56:00 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id TAA13634 for nat-outgoing; Thu, 20 Apr 2000 19:55:48 -0700 (PDT) Message-Id: <200004210251.LAA19174@venus.sm.sony.co.jp> To: nat@livingston.com Subject: (NAT) question about WAN->LAN masquerade Date: Fri, 21 Apr 2000 11:51:23 +0900 From: Nobuaki Asai Sender: owner-nat@livingston.com Precedence: bulk Reply-To: Nobuaki Asai Hi, I'm new to this list and I have a question about NATe extention. Are there any discussion about from WAN to LAN NAT masquerade ? For example, if I have only one global IP address from ISP and have several PC's in my house, and if I want to access my house's certain PC from my office, how can I access that PC ? If there are any pointer's and references, I will appreciatate them. Best Regards. --- Nobuaki Asai(asa@sm.sony.co.jp) - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message. From owner-nat@livingston.com Fri Apr 21 03:20:36 2000 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09737 for ; Fri, 21 Apr 2000 03:20:36 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.9.3/8.9.3) with ESMTP id AAA25716; Fri, 21 Apr 2000 00:13:56 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id AAA18832 for nat-outgoing; Fri, 21 Apr 2000 00:14:22 -0700 (PDT) Message-ID: <20000421071320.24383.qmail@web1405.mail.yahoo.com> Date: Fri, 21 Apr 2000 00:13:20 -0700 (PDT) From: Pyda Srisuresh Subject: (NAT) Re: draft-ietf-nat-protocol-complications (was Re: interception proxies) To: Vernon Schryver , nat@livingston.com, wrec@cs.utk.edu Cc: holdrege@lucent.com, srisuresh@yahoo.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-nat@livingston.com Precedence: bulk Reply-To: Pyda Srisuresh --- Vernon Schryver wrote: > > From: Pyda Srisuresh > > To: Vernon Schryver , wrec@cs.utk.edu > > Cc: nat@livingston.com, holdrege@lucent.com > > > > ... > > > Is there an RFC that includes the many complaints that have been made > about > > > NAT boxes in the main IETF list? > > > > Not an RFC. But, a draft addressing precisely this. > > It is titled "Protocol Complications with the IP Network Address > Translator". > > . ... > > > That draft does not mention anything about the IP fragmentation problem > that we were talking about in the WREC list that provoked that comment. > I dont know the exact problem you were talking about in the WREC list. But, IP fragmentation problem is listed as one of known NAT limitations in section 6.3 of as follows. We will add a note at the end of section-1 in the Complications draft, refering readers to known NAT limitations listed in RFC 2663 and the traditional-nat draft. 6.3. Translation of outbound TCP/UDP fragmented packets in NAPT setup Translation of outbound TCP/UDP fragments (i.e., those originating from private hosts) in NAPT setup are doomed to fail. The reason is as follows. Only the first fragment contains the TCP/UDP header that would be necessary to associate the packet to a session for translation purposes. Subsequent fragments do not contain TCP/UDP port information, but simply carry the same fragmentation identifier specified in the first fragment. Say, two private hosts originated fragmented TCP/UDP packets to the same destination host. And, they happened to use the same fragmentation identifier. When the target host receives the two unrelated datagrams, carrying same fragmentation id, and from the same assigned host address, it is unable to determine which of the two sessions the datagrams belong to. Consequently, both sessions will be corrupted. > Many people act on the silly superstition that a 56 Kbit/sec modem or 128 > Kbit/sec ISDN link is faster with a tiny MTU. When they do that, IP > fragmentation must occur except when Path MTU works. (Do most NAT boxes > do the right things when they see the DF bit?) (That draft doesn't list What excatly is your concern with NAT boxes and DF bit? Please elaborate. > ICMP as an application whose payloads can need to be modified; consider > the packet headers in some ICMP payloads.) > Agreed. This is part of NAT operation described in traditional-nat draft. I dont believe, this belongs in "NAT complications" draft. > NAT boxes (or perhaps "ALG" in the terms of that draft) and redirection NAT boxes are not same as ALGs. NAT boxes are those that implement a NAT type (typically NAPT or Basic-NAT, as described RFC 2663) and some number of ALGs. > proxies are likely to do the wrong things when the bits in the payload > that need to be modified are not in the first IP fragment, at least unless > they do (the equivalent) of IP fragment reassembly before forwarding. > You will need an ALG to do any kind of modification to the payload. What is the problem with IP fragments here? > Neither kind of box can even redirect incoming IP fragments to the correct > local host, since the UDP and TCP port numbers are only in the first > fragment. > When IP fragments are directed to the NAT box, NAT will need to reassemble the fragments into a single MTU prior to translation. And, NAT devices do just that. > Tiny incoming IP fragments seem most likely when both TCP hosts or more > than one UDP application (there can be >2 with multicast) are using NAT > boxes. I've seen people run servers for various applications behind > NAT boxes, including HTTP, SMTP and proprietary applications. > I believe, this is addressed in my previous comment already. > > Vernon Schryver vjs@rhyolite.com cheers, suresh __________________________________________________ Do You Yahoo!? Send online invitations with Yahoo! Invites. http://invites.yahoo.com - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message. From owner-nat@livingston.com Sat Apr 22 11:44:26 2000 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16558 for ; Sat, 22 Apr 2000 11:44:25 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.9.3/8.9.3) with ESMTP id IAA09507; Sat, 22 Apr 2000 08:36:48 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id IAA05175 for nat-outgoing; Sat, 22 Apr 2000 08:33:34 -0700 (PDT) Message-ID: <20000422153223.12768.qmail@web1406.mail.yahoo.com> Date: Sat, 22 Apr 2000 08:32:23 -0700 (PDT) From: Pyda Srisuresh Subject: (NAT) Re: draft-ietf-nat-protocol-complications To: Vernon Schryver , nat@livingston.com, wrec@cs.utk.edu MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-nat@livingston.com Precedence: bulk Reply-To: Pyda Srisuresh --- Vernon Schryver wrote: > > From: Pyda Srisuresh > > To: Vernon Schryver , nat@livingston.com, > > wrec@cs.utk.edu > > Cc: holdrege@lucent.com, srisuresh@yahoo.com > > > ... > > But, IP fragmentation problem is listed as one of known NAT limitations > > in section 6.3 of as follows. > > draft-ietf-nat-traditional-03.txt is at neither ftp.isi.edu nor > http://www.ietf.org/internet-drafts > Well, the following URL still works for me. http://www.ietf.org/internet-drafts/draft-ietf-nat-traditional-03.txt > but please don't send me a private copy. I've intentionally not > subscribed to nat@livingston.com. If you think the document says enough > about IP fragmentation, then fine. > Will do. > > > ... > > What excatly is your concern with NAT boxes and DF bit? Please elaborate. > > My guess is that many NAT boxes choose to pretend to be too-smart-by-half > bridges instead of routers and ignore the DF bit. > > I dont think so. I believe, NAT boxes do behave like standard routers with regard to DF bit. > > > ICMP as an application whose payloads can need to be modified; consider > > > the packet headers in some ICMP payloads.) > > > > Agreed. This is part of NAT operation described in traditional-nat draft. > > I dont believe, this belongs in "NAT complications" draft. > > If I were writing a document listing complications of NAT, I would > include at least a reference to descriptions of other serious problem. > > Will do. > > > NAT boxes (or perhaps "ALG" in the terms of that draft) and redirection > > > > NAT boxes are not same as ALGs. NAT boxes are those that implement a > > NAT type (typically NAPT or Basic-NAT, as described RFC 2663) and some > > number of ALGs. > > I think I now understand the very positive, even pollyannaish tone > of the document. And note again, that while I think third party > redirection proxies are somewhere between criminal and completely > unethical and immoral, I think NAT boxes have been and will continue > for at least a while to be better than any of the (un)available > alternatives, and so one might think my prejudices would cause me > to not sensitive to a overly rosey pictures. > > > > ... > > > Neither kind of box can even redirect incoming IP fragments to the > correct > > > local host, since the UDP and TCP port numbers are only in the first > > > fragment. > > > > > When IP fragments are directed to the NAT box, NAT will need to > > reassemble the fragments into a single MTU prior to translation. > > And, NAT devices do just that. > > They should, but do most? > I believe, they do. As recipients of end-node packets, they are required to confirm to RFC 1122 ("Requirements for Internet Hosts -- Communication Layers"). Beyond this, I cannot comment further on existing NAT implementations. I am not aware of DF-bit violation problems, specifically with NAT routers. > Public experience with somewhat related boxes is relevant. It was always > completely obvious that an FDDI-Ethernet bridge must act like a router > for large IP/FDDI packets, and generate IP fragments if allowed by the DF > bit and send ICMP errors if not. However, for years more than one vendor > of such bridges insisted in public simply droppping large FDDI frames was > perfectly fine, and that FDDI hosts should just know enough to not use > the FDDI MTU. The best FDDI-Ethernet bridges would IP fragment (and at > wire speed), but none sent both honored the DF bit and sent ICMP errors. > Vernon - If there exists a large-scale problem in the market with regard to violation of DF bit semantics by NAT routers, I agree, we ought to document that, just as much as we ought to document such a problem with regard to FDDI-ethernet bridges or even some routers for that matter. But, I am not aware of such a large-scale problem with NAT routers. > > Vernon Schryver vjs@rhyolite.com > regards, suresh __________________________________________________ Do You Yahoo!? Send online invitations with Yahoo! Invites. http://invites.yahoo.com - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message. From owner-nat@livingston.com Wed Apr 26 12:30:23 2000 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29575 for ; Wed, 26 Apr 2000 12:30:22 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.9.3/8.9.3) with ESMTP id JAA03927; Wed, 26 Apr 2000 09:21:55 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id JAA22382 for nat-outgoing; Wed, 26 Apr 2000 09:20:14 -0700 (PDT) Message-Id: <4.3.1.2.20000426092123.00b859b0@porky> X-Sender: mhold@porky X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Wed, 26 Apr 2000 09:21:43 -0700 To: nat@livingston.com From: Matt Holdrege Subject: (NAT) Adelaide minutes Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-nat@livingston.com Precedence: bulk Reply-To: Matt Holdrege Here are the minutes, please let us know if you see any errors or omissions. Chairs: Pyda Srisuresh - srisuresh@yahoo.com Matt Holdrege - holdrege@lucent.com Reported by: Yves Tjoens - yves.tjoens@alcatel.be Gabriel Montenegro - Gabriel.Montenegro@Eng.Sun.COM Prepared by: Suresh & Matt ___________________________________________________________________________ Mailing list: nat@livingston.com To subscribe: Send e-mail to nat-request@livingston.com with "subscribe" in the body of the message. Only messages from subscribers are posted to the list. To unsubscribe: Send e-mail to nat-request@livingston.com with "unsubscribe" in the body of the message. Mailing list: nat-digest@livingston.com (This is nat mailing list, in daily-digest format. To receive the digest, you can subscribe as follows.) To subscribe: Send e-mail to nat-digest-request@livingston.com with "subscribe" in the body of the message. To unsubscribe: Send e-mail to nat-digest-request@livingston.com with "unsubscribe" in the body of the message. ____________________________________________________________________ In order to avoid confusion, the following indentation and format legend should be used as a guide to interpreting the minutes. - "" Detailed Slides and/or Comments made by the presenter Questions from the Audience: [ - ] _________________________________________________________________________ AGENDA: 1. Base-Nat drafts * draft-iab-nat-implications-05.txt from Tony 10 mins. * draft-ietf-nat-protocol-complications-02.txt 5 mins. from Matt 2. RSIP drafts - 30 mins. * draft-ietf-nat-rsip-slp-00.txt * draft-ietf-nat-rsip-ipsec-03.txt * draft-ietf-nat-rsip-protocol-06.txt * draft-ietf-nat-rsip-framework-04.txt 3. Miscellaneous - 15 mins. -------------------- Matt - Matt proposed sending the draft to IETF for a 4-wk last call to flesh out more comments. Fred Baker: why an ietf last call for an info i-d? Matt: Because it impinges on so many things. Matt sent an e-mail to all the wg chairs yet we still need more feedback. Fred Baker: It does not hurt, but is unexpected. Matt: This was the best way the chairs and ADs think to get the required comments. Suresh: Base nat drafts are the reason this wg was formed, we need to move past them. This is a base NAT draft and we need to do whatever it takes to get the necessary input. --------------------- Mike Borella - RSIP drafts terminology changes: rsip client: client portion of rsip protocol rsip server: server portion of rsip protocol rsip client and server from before are now called rsip host and rsip gateway. minor changes in protocol. Don't care parms are now empty instead of filling with 0's. revision of query_request and query_response using indicator to disambiguate whether talking about subnets or host addresses beefed up error processing and general protocol behavior deprecated: ok and deallocate msgs (not needed or redundant) added overall length field (good for tcp) error msgs and codes separated and listed categorized: host vs. gateway mandatory vs. optional iana section + editorial work further work: minor stuff, deltas are getting smaller is protocol minimal or complete? examples? error msgs complete? clarify behavior? Should we send to last call? Elliot lear: not ready for last call just yet question on determining inside or outside hosts. Mike: basically, this might be a situation when if you can't tell, just let the user use nat and hope for the best. Suresh: Wasnt it decided in the last meeting that RSIP should simply be a replacement stack for IP? Apps shouldnt have to be redone with RSIP stack, right? Elliot: you should not specify if an app should use nat or rsip, but you should provide the mechanisms for the administrator to enforce that. Are you doing app based routing? if so apps must know about this. mike: Hopefully apps should not know whether nat or rsip is being used. matt: let's not have the "which is better" conversation here. elliot: perhaps the query should help disambiguate this, but it might require having ports in the query. matt: perhaps you could write a draft on this topic? elliot: what i need is something to help determine using nat or rsip. for example to avoid tunneling. Gabriel: you don't need to avoid rsip to avoid tunneling. we have tunneling there because we didn't want to delay,but it's simple to enable direct delivery. this is similar to MN-FA link in mobile ip (no tunneling). mike: we should avoid having to touch the application scott bradner: you suggesting that the initial handshake would have an application id? there's something like this in rsvp. suresh: make the tunnel endpoint explicit, instead of assuming that they are the src/dst addresses, it may be possible to have the resources assigned by a different box than that which is involved in the data transport, so tunnel endpoint is not necessarily the signal endpoint. mike: now you need a protocol between the rsip controller and the gateway scott: just specifying another first hop to use seems reasonable, but no more. suresh: In section 7 - Flow based logic and state terms are confusing. Why should you need this? mike: it's not mandated, you can have macro or micro or no policy. Suresh: In that case, OK. --------------- 3 sections now implementation issues deployment interaction with layer 3 protocols new sections on intserv diffserv multicast dns locating rsip gateways brief discussion on authentication further work mobile ip section will synch up Brian Carpenter: an rsip gw may be a diffserv router as defined by diffserv. pls check to make sure it's ok. suresh: Draft looks much improved. Has RSA-Ip or RSAP-IP been tested with applications that are known to have problems with NAT? mike: for relatively simple nat-unfriendly protocols, rsip just works without changing the app. suresh: Is this draft applicable for both rsa-ip and rsap-ip? mike: don't see much market for rsa-ip. people want to share one ip addr among many hosts. in that situation, just use dhcp. suresh: That is not right. RSA-IP can be useful for renumbering. RSIP data path needs to be clarified. Specifically, you need to list the catalysts for intercation between RSIP-host and RSIP-client. mike: perhaps for later with feedback from stack developer folks? suresh: more urgent than that. need convincing arguments that socket interactions would be supported by rsip stacks as well. For example, are applications required to request different sockets based on the destination address they are talking to? when does the RSIP stack request RSIP client to initiate a control session with RSIP-server? ----------------- strong recommendation that ike float the source port already allowed, for testing for example this way, no need to do i-cookie agreement. client is much easier. also solves problems with remote host rekeying suresh: does not help when you are receiver of ike initiation and you rekey phase 1. Answer(someone in Audience): you usually reuse the ports used in phase 1. so it would be ok. suresh: Even in that cae, Use of Ephemeral IKE ports would only help in the case of IKE initiation by RSIP hosts - cannot be IKE responder using ephemeral ports. mike: rsip message authentication. no encryption, just authentication related draft in dhc, redirecting to get the ip addr of your rsip server rsip on linux: rsiponlinux-request@sandelman.ottawa.on.ca ---------------- draft-ietf-nat-rsip-slp-00.txt - jim kempf allow client to find rsip server based on characteristics of server draft contains service type template for rsip service type added a service attribute for load-balancing how to use scopes for provisioning more flexibility in deployment example on using slp scopes for provisioning does the wg want this to advance to proposed/informational, other? suggest advancing along with the rest of the rsip drafts --------- draft-iab-nat-implications-05.txt - tony hain pls look through it, this one is intended to be final. --------- carmelo zaccone on generic architecture for rsip as time ran out question to the wg: is our work of interest? is it within the scope of the wg? multiroaming with isp's, general enterprise, current rsip has limitations End Of Meeting - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message.