From owner-nat@livingston.com Mon Jul 10 12:13:59 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 MAA15036 for ; Mon, 10 Jul 2000 12:13:58 -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 JAA02479; Mon, 10 Jul 2000 09:04:01 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/1.0) id IAA17347 for nat-outgoing; Mon, 10 Jul 2000 08:56:12 -0700 (PDT) X-Authentication-Warning: server.livingston.com: majordom set sender to owner-nat@livingston.com using -f Message-Id: <200007101033.GAA02272@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-03.txt Date: Mon, 10 Jul 2000 06:33:31 -0400 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-03.txt Pages : 14 Date : 07-Jul-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-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-protocol-complications-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-protocol-complications-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: <20000707143846.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nat-protocol-complications-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nat-protocol-complications-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000707143846.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 Tue Jul 11 12:22: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 MAA07359 for ; Tue, 11 Jul 2000 12:22: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 JAA20605; Tue, 11 Jul 2000 09:13:49 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/1.0) id JAA19616 for nat-outgoing; Tue, 11 Jul 2000 09:07:29 -0700 (PDT) X-Authentication-Warning: server.livingston.com: majordom set sender to owner-nat@livingston.com using -f Message-Id: <200007111033.GAA23897@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-05.txt Date: Tue, 11 Jul 2000 06:33:28 -0400 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-05.txt Pages : 19 Date : 10-Jul-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-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-snmp-alg-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-snmp-alg-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: <20000710152643.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nat-snmp-alg-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nat-snmp-alg-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000710152643.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 Tue Jul 11 12:25: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 MAA07462 for ; Tue, 11 Jul 2000 12:25: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 JAA20608; Tue, 11 Jul 2000 09:13:52 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/1.0) id JAA19586 for nat-outgoing; Tue, 11 Jul 2000 09:07:21 -0700 (PDT) X-Authentication-Warning: server.livingston.com: majordom set sender to owner-nat@livingston.com using -f Message-Id: <200007111033.GAA23911@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-app-guide-03.txt Date: Tue, 11 Jul 2000 06:33:35 -0400 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 : NAT Friendly Application Design Guidelines Author(s) : D. Senie Filename : draft-ietf-nat-app-guide-03.txt Pages : 9 Date : 10-Jul-00 While many common Internet applications will operate cleanly in the presence of Network Address Translators, others suffer from a variety of problems when crossing these devices. This document discusses those things which application designers might wish to consider when designing new protocols. Guidelines are presented herein to help ensure new protocols and applications will, to the extent possible, be compatible with NAT. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nat-app-guide-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-app-guide-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-app-guide-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: <20000710152657.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nat-app-guide-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nat-app-guide-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000710152657.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 Jul 12 12:31:29 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 MAA01143 for ; Wed, 12 Jul 2000 12:31:28 -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 JAA09164; Wed, 12 Jul 2000 09:22:31 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/1.0) id JAA03066 for nat-outgoing; Wed, 12 Jul 2000 09:13:11 -0700 (PDT) X-Authentication-Warning: server.livingston.com: majordom set sender to owner-nat@livingston.com using -f Message-Id: <200007121032.GAA15185@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-07.txt Date: Wed, 12 Jul 2000 06:32:00 -0400 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-07.txt Pages : 54 Date : 11-Jul-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-07.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-07.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-07.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: <20000711135052.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nat-rsip-protocol-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nat-rsip-protocol-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000711135052.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 Jul 13 11:47:15 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 LAA25047 for ; Thu, 13 Jul 2000 11:47:14 -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 IAA26343; Thu, 13 Jul 2000 08:37:41 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/1.0) id IAA11987 for nat-outgoing; Thu, 13 Jul 2000 08:29:17 -0700 (PDT) X-Authentication-Warning: server.livingston.com: majordom set sender to owner-nat@livingston.com using -f Message-Id: <200007131029.GAA11440@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-interface-framework-01.txt Date: Thu, 13 Jul 2000 06:29:16 -0400 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 : Framework for interfacing with Network Address Translator Author(s) : P. Srisuresh Filename : draft-ietf-nat-interface-framework-01.txt Pages : 27 Date : 12-Jul-00 NAT provides routing transparency for hosts in disparate address realms to communicate with each other. However, external agents such as Application Level Gateways (ALGs), Realm Specific IP RSIP) clients and Management applications need to interact with NAT and influence its operations. The document identifies NAT managed resources and ways by which these resources may be controlled from external agents. The resource control mechanism is illustrated functionally through an Application Programming Interface (API). However, it is not the intent of this document to standardize the API. Rather, use the API as basis to illustrate and provide a basis for the development of one or more protocols by which external agents could interact with NAT. Identification of NAT controlled resources also provides a basis to generate NAT Management Information Base (MIB). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nat-interface-framework-01.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-interface-framework-01.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-interface-framework-01.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: <20000712140746.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nat-interface-framework-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nat-interface-framework-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000712140746.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 Sat Jul 15 13:52:05 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 NAA23485 for ; Sat, 15 Jul 2000 13:52:04 -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 KAA25171; Sat, 15 Jul 2000 10:42:32 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/1.0) id KAA05886 for nat-outgoing; Sat, 15 Jul 2000 10:39:06 -0700 (PDT) X-Authentication-Warning: server.livingston.com: majordom set sender to owner-nat@livingston.com using -f Message-Id: <4.3.1.2.20000715100923.00c7d8b0@pop3.ipverse.com> X-Sender: matt@ipverse.com@pop3.ipverse.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Sat, 15 Jul 2000 10:17:33 -0700 To: nat@livingston.com From: Matt Holdrege Subject: (NAT) Pittsburgh Cc: srisuresh@yahoo.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-nat@livingston.com Precedence: bulk Reply-To: Matt Holdrege OK folks, here is a first stab at the Agenda for our upcoming meeting in Pittsburgh. We are planning on meeting Thursday morning from 9-11:30, but the final IETF agenda isn't set in stone yet. We will discuss... draft-iab-nat-implications-08.txt draft-ietf-nat-protocol-complications-04.txt draft-aboba-nat-ipsec-02.txt And we will go over the latest developments in the RSIP drafts. Does anyone else have any suggested agenda items? - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message. From owner-nat@livingston.com Mon Jul 17 10:43:25 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 KAA08034 for ; Mon, 17 Jul 2000 10:43: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 HAA07369; Mon, 17 Jul 2000 07:33:32 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/1.0) id HAA16015 for nat-outgoing; Mon, 17 Jul 2000 07:26:50 -0700 (PDT) X-Authentication-Warning: server.livingston.com: majordom set sender to owner-nat@livingston.com using -f Message-Id: <200007171042.GAA25959@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-05.txt Date: Mon, 17 Jul 2000 06:42:16 -0400 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, J. Lo, D. Grabelsky, G. Montenegro Filename : draft-ietf-nat-rsip-framework-05.txt Pages : 31 Date : 14-Jul-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-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-framework-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-framework-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: <20000714143827.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nat-rsip-framework-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nat-rsip-framework-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000714143827.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 Jul 20 10:40:59 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 KAA15400 for ; Thu, 20 Jul 2000 10:40:58 -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 HAA00407; Thu, 20 Jul 2000 07:27:02 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/1.0) id HAA17002 for nat-outgoing; Thu, 20 Jul 2000 07:20:57 -0700 (PDT) X-Authentication-Warning: server.livingston.com: majordom set sender to owner-nat@livingston.com using -f Message-ID: <20000720142356.29727.qmail@web1403.mail.yahoo.com> Date: Thu, 20 Jul 2000 07:23:56 -0700 (PDT) From: Pyda Srisuresh Subject: (NAT) Comments on draft-iab-nat-implications-08.txt To: tonyhain@microsoft.com Cc: nat@livingston.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-nat@livingston.com Precedence: bulk Reply-To: Pyda Srisuresh Tony, Some general comments. 1. There seem to be lot of spurious characters - Italicized "AE". "u^" spread throught the text. 2. As an architectural document, I believe, you should have a section citing the limitations of NAT - topological limitations or what have you, architecturally speaking. For example, NAT function should be run on a border router unique to a stub domain, where all packets either originate from the domain or are destined to the domain. I dont know, if you meant "Scope" (section 3) to be that. It certainly doesnt come across that way. The closest observation I found was a sentence in the last paragraph of "Introduction" (section 1) which states that a NAT device should not be viewed as a simple router replacement. 3. I appreciate your concern about misleading marketing literature, implementation errors/violations and misconfigurations with respect to some NAT deployments. However, I find it misleading to mention these in the same tone as NAT functionality to illutrate disadvantages. Below are my detailed comments. regards, suresh > 1. Introduction <... stuff deleted> > > The architectural intent of NAT is to divide the Internet into ^^^^^^ Just the opposite. The intent of NAT is to bridge independent address realms. NAT doesnt create the realms. The realms are already there. NAT is used to bridge them. <... stuff deleted> > addresses were guaranteed to be ambiguous. For example, when NATs > are inserted into the network, the process of resolving names to or > from addresses becomes dependent on where the question was asked. > The result of this division is to enforce a client/server > architecture (vs. peer/peer) where the servers need to exist in the > public address realm. The last sentence sounds like a non-sequitor to me. How does one infer this from the previous sentence? I can have Bi-directional NAT and still have peer-to-peer architecture between realms. What is the problem? <... stuff deleted> > NAT devices (particularly the NAPT variety) undermine most of these, > basic advantages of the end-to-end model, reducing overall > flexibility, while often increasing operational complexity and > impeding diagnostic capabilities. It must be noted here that there is a paradigm shift in IP networking in today's world. Stateful managment of end-sessions within the network is a trend being pursued with policy based security gateways, web-caching devices, QOS enforcement devices, firewalls and Network Address Translators. A basic property/requirement of the stateful networks is that packets pertaining to a session traverse the same node in both directions. Further, stateful networks do require carefully orchestrated network topology to ensure the networks are operational. While you mention this as a undesirable consequence of NAT deployment, you do not mention other elements that also contribute to the statefulness in networks in the same breath). <... stuff deletd> > 2. Terminology > > Recognizing that many of these terms are defined in detail in RFC > 2663 [3], the following are summaries as used in this document. > > NAT - Network Address Translation in simple form is a method by > which IP addresses are mapped from one address administration to > another. The NAT function is unaware of the applications traversing > it, as it only looks at the IP headers. > > ALG - Application Layer Gateway: inserted between application peers > to simulate a direct connection when some intervening protocol or > device prevents direct access. It terminates the transport > protocol, and may modify the data stream before forwarding. ALG does not terminate the transport protocol. A Proxy does. <... stuff deleted> > Firewall - access control point that may be a special case of an > ALG, or routing filter. Firewall is not a special case of an ALG, or a routing filter. By routing filter, did you mean one that filters routing PDU content or one that filters data papckets? > Proxy - Special case of an ALG that is a simple relay service > designed into a protocol, rather than arbitrarily inserted. I dont understand this definition. As far as I can tell, Proxy terminates a session. One of the application ends know about the existence of Proxy enroute. This unlike an ALG. <... stuff deleted> > 6. Problems with NATs > While RSIP addresses the transparency and ALG issues, for the > specific case of an individual private host needing public access, > there is still a node with state required to maintain the > connection. Dynamic NAT and RSIP will eventually violate higher > layer assumptions about address/port number reuse as defined in RFC- > 793 [10] RFC-1323 [11]. The TCP state, TCP_TIME_WAIT, is > specifically designed to prevent replay of packets between the 4- > tuple of IP and port for a given IP address pair. Since the TCP > state machine of a node is unaware of any previous use of RSIP, its > attempt to connect to the same remote service that its neighbor just > released (which is still in TCP_TIME_WAIT) may fail, or with a > larger sequence number may open the prior connection directly from > TCP_TIME_WAIT state, at the loss of the protection afforded by the > TCP_TIME_WAIT state. This is a problem only when implementations recycle port numbers without a wait time. This is not the recommended practice. Please refer section 2.6 of RFC 2663. <... stuff deleted> > In particular, it is sometimes erroneously believed that NATs serve > to provide routing isolation. In fact, if someone were to define an > OSPF ALG it would actually be possible to route across a NAT > boundary. Rather than NAT providing the boundary, it is the > experienced operators who know how to limit network topology that > serve to avoid leaking addresses across a NAT. This is an > operational necessity given the potential for leaked addresses to > introduce inconsistencies into the public infrastructure. By the very nature of address realms, and the NAT devices that support them, there are restrictions on routing advertisements (refer section 4 in RFC 2663). So, why would you want to do an OSPF-ALG? It is technically possible to do an OSPF_ALG, only if you had one-to-one static address mapping for all routing nodes and the subnets they support. In such a case, why would you have leaked addresses? <... stuff deleted> > 7.3. TCP state violations > Host A completes its transaction and closes the web service on TCP > port 80, and the RSIP releases the public side address used for Host > A. Host B attempts to open a connection to the same web service, > and the NAT assigns then next free public side address which is the > same one A just released. The source port selection rules on Host B > happen to lead it to the same choice that A used. The connect > request from Host B is rejected because the web server, conforming > to the TCP specifications, has that 4-tuple in TIME WAIT for 4 > minutes. By the time a call from Host B gets through to the > helpdesk complaining about no access, the requested retry will work, > so the issue is marked as resolved, when it in fact is an on-going, > but intermittent, problem. How is this different from dynamic IP address assignment strategies pursued by remote Access devices and DHCP servers? <... stuff deleted> > > 7.4. Symmetric state management > To preserve a consistent view of routing, the best path to the > Internet for Routers 1 & 2 is via NAT1, while the Internet is told > the path to the address pool managed by the NATs is best found > through NAT1. When the path X1 breaks, Router 2 would attempt to > switch to NAT2, but the external return path would still be through > NAT1. This is because the NAT1 device is advertising availability of > a pool of addresses. So is NAT2. Depending upon the address block provides by the respective ISPs, NAT1 and NAT2 would be advertising different address blocks. I believe, there was a draft some time back from Praveen and Yakov on the subject - describing the opposite view point - i.e., benefit of multihoming with NAT devices. Sounds like, it is a matter of configuring the device correctly. > Directly connected routers in this same > situation would advertise the specific routes that existed after the > loss. In this case, redundancy was useless. I dont understand what you say about directly connected routers. Could you elaborate? > > Consider the case that the path between Router 1 & 2 is up, and some > remote link in the network X2 is down. It is also assumed that DNS > returns addresses for both NATs when queried for Hosts A or B. When > Host D tries to contact Host B, the request goes through NAT2, but > due to the internal routing, the reply is through NAT1. If X2 is broken, there is a routing issue of how Host-D can be accessed through NAT1. The NAT1 service provider lost connectivity to Host-D. This is a problem independent of NAT, with ay multi-homing scenario. <... stuff deletd> > In a third case, both Host A & B want to contact Host D, when the > remote link X2 in the Internet breaks. As long as the path X1 is > down, Host B is able to connect, but Host A is cut off. Once again, sounds like a routing problem to me. If X2 and X1 are broken, there is no routing connectivity between Host-A and Host-D. This is nothing to do with NAT1 or NAT2. <... stuff deleted> > Illustration 5 > > Everything in this simple example will work until an application > embeds a name. For example, a Web service running on Host D might > present embedded URLÆs of the form http://D/bar.html, which would > work from Host C, but would thoroughly confuse Host A. But, shouldnt this be a FQDN? This would be a problem in general to resolve a name that is not FQDN across a global betwork. I dont see the relation to NATs. For example, there may be multiple nodes called "ROCKY", but each is unique to a domain. (ex: rocky.altos.com, rocky.zagros.com etc.) <... stuff deletd> > --------------- ---------------- > | 10.10.10.10 |--------L2TP-------| Assigned by A | > | Host A | --- --- | Host B | > | 10.1.1.1 |--|NAT|-----|NAT|--| 10.10.10.10 | > --------------- --- --- ---------------- > > -------- > Illustration 6 This brings out a problem concerning PPP/L2TP address assignment, when the assigned address could collide with the user's private address space. How is this a NAT issue? <... stuff deleted> > 9. Security Considerations > > NAT (particularly NAPT) actually has the potential to lower overall > security because it creates the illusion of a security barrier, but > does so without the managed intent of a firewall. NAT and firewall functions are different. So, one is not a replacement for the other. On the other hand, there are many deployments that have both functions on the same device co-existant. <.. stuff deleted> > 10. Deployment Guidelines <... stuff deleted> > - Assure that applications used both internally and externally avoid > embedding names, or use globally unique ones. Using names that are not globally unique would fail independent of NAT being enroute. > - For RSIP, determine the probability of TCP_Time_Wait collisions > when subsequent private side hosts attempt to contact a recently > disconnected public side service. I dont believe, this is limited to RSIP or NAT. This guideline applies to all IP stack implementors(for socket assignment) and PPP/DHCP servers (for dynamic address asignment). __________________________________________________ Do You Yahoo!? Get Yahoo! Mail – Free email you can access from anywhere! http://mail.yahoo.com/ - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message. From owner-nat@livingston.com Fri Jul 21 11:27:47 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 LAA27238 for ; Fri, 21 Jul 2000 11:27:46 -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 IAA17459; Fri, 21 Jul 2000 08:17:25 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/1.0) id IAA20451 for nat-outgoing; Fri, 21 Jul 2000 08:12:55 -0700 (PDT) X-Authentication-Warning: server.livingston.com: majordom set sender to owner-nat@livingston.com using -f Message-Id: <200007211340.JAA12886@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-04.txt Date: Fri, 21 Jul 2000 09:40:43 -0400 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-04.txt Pages : 19 Date : 20-Jul-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-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-ipsec-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-ipsec-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: <20000720141951.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nat-rsip-ipsec-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nat-rsip-ipsec-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000720141951.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 Sun Jul 23 18:46:03 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 SAA05737 for ; Sun, 23 Jul 2000 18:46:02 -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 PAA05897; Sun, 23 Jul 2000 15:36:55 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/1.0) id PAA08217 for nat-outgoing; Sun, 23 Jul 2000 15:29:48 -0700 (PDT) X-Authentication-Warning: server.livingston.com: majordom set sender to owner-nat@livingston.com using -f Message-ID: <20000723222901.485.qmail@web1401.mail.yahoo.com> Date: Sun, 23 Jul 2000 15:29:01 -0700 (PDT) From: Pyda Srisuresh Subject: (NAT) Pittsburg NAT WG agenda To: nat@livingston.com Cc: matt@ipverse.com, agenda@ietf.org, Scott Bradner , Allison Mankin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-nat@livingston.com Precedence: bulk Reply-To: Pyda Srisuresh Folks, Here is the final NAt WG agenda. Do let me or Matt know, if we missed something. Thanks. NAT WG agenda (Thursday 08/03/00, 09:00-11:30) --------------------------------------------- 1. Status of Base NAT drafts - draft-iab-nat-implications-08.txt - Tony - draft-ietf-nat-protocol-complications-04.txt - Matt&Suresh - draft-ietf-nat-traditional-04.txt - suresh 2. Status of RSIP drafts - Gabriel, Jeffrey etc. -draft-ietf-nat-rsip-framework-05.txt -draft-ietf-nat-rsip-protocol-07.txt -draft-ietf-nat-rsip-ipsec-04.txt -draft-ietf-nat-rsip-slp-00.txt 3. Remaining NAT drafts - draft-ietf-nat-app-guide-03.txt - Daniel - draft-ietf-nat-interface-framework-01.txt - suresh 4. NAT WG revised milestones 5. Discussion only on proposed changes to IPsec to be NAT friendly (NOTE: The following documents are not NAT WG items) - draft-aboba-nat-ipsec-02.txt - draft-stenberg-ipsec-nat-traversal-00.txt cheers, suresh & Matt __________________________________________________ Do You Yahoo!? Get Yahoo! Mail – Free email you can access from anywhere! http://mail.yahoo.com/ - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message.