From owner-nat@livingston.com Thu Feb 3 20:08: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 UAA03054 for ; Thu, 3 Feb 2000 20:08:25 -0500 (EST) 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 RAA19990; Thu, 3 Feb 2000 17:04:52 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id RAA01900 for nat-outgoing; Thu, 3 Feb 2000 17:03:16 -0800 (PST) Message-Id: <4.2.2.20000203170258.00b67d30@porky> X-Sender: mhold@porky X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 03 Feb 2000 17:05:09 -0800 To: nat@livingston.com From: Matt Holdrege Subject: (NAT) NAT in Adelaide 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 If anyone has any discussion topics regarding NAT WG drafts, please let us know. Tentatively, we are planning on meeting Monday from 13:00 to 15:00. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message. From owner-nat@livingston.com Wed Feb 9 04:56:01 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 EAA02844 for ; Wed, 9 Feb 2000 04:56:00 -0500 (EST) 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 BAA19081; Wed, 9 Feb 2000 01:53:51 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id BAA24841 for nat-outgoing; Wed, 9 Feb 2000 01:50:57 -0800 (PST) Message-ID: From: "Leone, Guido" To: "'nat@livingston.com'" Subject: (NAT) Tunneling Date: Wed, 9 Feb 2000 10:49:18 +0100 Importance: high X-Priority: 1 Sensitivity: Company-Confidential MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-nat@livingston.com Precedence: bulk Reply-To: "Leone, Guido" L2TP and GRE are usually not mentioned inside the list of protocols adversely affected by NAT. Does it mean that the compatibility of those protocols with NAT is always out of discussion ? Thanks in advance for any reference to documents. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message. From owner-nat@livingston.com Wed Feb 9 12:13:02 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 MAA11072 for ; Wed, 9 Feb 2000 12:13:00 -0500 (EST) 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 JAA23665; Wed, 9 Feb 2000 09:09:07 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id JAA06432 for nat-outgoing; Wed, 9 Feb 2000 09:08:08 -0800 (PST) Message-ID: <4148FEAAD879D311AC5700A0C969E8901CBF6E@orsmsx35.jf.intel.com> From: "Iyer, Prakash" To: "'Leone, Guido'" , "'nat@livingston.com'" Subject: RE: (NAT) Tunneling Date: Wed, 9 Feb 2000 09:03:13 -0800 Sensitivity: Company-Confidential MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="windows-1252" Sender: owner-nat@livingston.com Precedence: bulk Reply-To: "Iyer, Prakash" If you mean L2TP over IPsec, that should be covered by the rsip-ipsec draft. And by GRE if you mean PPTP, then again in the context of RSIP, I believe Bernard Aboba and/or someone else was planning to write a draft - this issue was raised on the mailing list before. -----Original Message----- From: Leone, Guido [mailto:guido.leone@eds.com] Sent: Wednesday, February 09, 2000 1:49 AM To: 'nat@livingston.com' Subject: (NAT) Tunneling Importance: High Sensitivity: Confidential L2TP and GRE are usually not mentioned inside the list of protocols adversely affected by NAT. Does it mean that the compatibility of those protocols with NAT is always out of discussion ? Thanks in advance for any reference to documents. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message. From owner-nat@livingston.com Thu Feb 10 17:07: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 RAA11778 for ; Thu, 10 Feb 2000 17:07:35 -0500 (EST) 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 OAA28103; Thu, 10 Feb 2000 14:04:54 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id OAA21193 for nat-outgoing; Thu, 10 Feb 2000 14:01:37 -0800 (PST) Message-Id: <4.2.2.20000210140009.00b2bba0@porky> X-Sender: mhold@porky X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 10 Feb 2000 14:01:29 -0800 To: "Leone, Guido" From: Matt Holdrege Subject: Re: (NAT) Tunneling Cc: "'nat@livingston.com'" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-nat@livingston.com Precedence: bulk Reply-To: Matt Holdrege At 10:49 AM 2/9/00 +0100, Leone, Guido wrote: >L2TP and GRE are usually not mentioned inside the list of protocols >adversely affected by NAT. Does it mean that the compatibility of those >protocols with NAT is always out of discussion ? Thanks in advance for any >reference to documents. What about the L2TP protocol is adversely affected by NAT? - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message. From owner-nat@livingston.com Mon Feb 14 08:13:16 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 IAA07174 for ; Mon, 14 Feb 2000 08:13:16 -0500 (EST) 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 FAA16853; Mon, 14 Feb 2000 05:10:51 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id FAA07016 for nat-outgoing; Mon, 14 Feb 2000 05:02:27 -0800 (PST) Message-ID: From: "Leone, Guido" To: "'Matt Holdrege'" Cc: "'nat@livingston.com'" Subject: R:(NAT) Tunneling Date: Mon, 14 Feb 2000 13:00:44 -0000 Importance: high X-Priority: 1 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by server.livingston.com id FAA07012 Sender: owner-nat@livingston.com Precedence: bulk Reply-To: "Leone, Guido" Content-Transfer-Encoding: 8bit Of course it is not (or should not be) affected. I'm looking for a more esplicit, positive and documented statement about it's compatibility with installations based on NAT. > ---------- > Da: Matt Holdrege[SMTP:matt@ascend.com] > Inviato: giovedì 10 febbraio 2000 23.01 > A: Leone, Guido > Cc: 'nat@livingston.com' > Oggetto: Re: (NAT) Tunneling > > At 10:49 AM 2/9/00 +0100, Leone, Guido wrote: > >L2TP and GRE are usually not mentioned inside the list of protocols > >adversely affected by NAT. Does it mean that the compatibility of those > >protocols with NAT is always out of discussion ? Thanks in advance for > any > >reference to documents. > > What about the L2TP protocol is adversely affected by NAT? > - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message. From owner-nat@livingston.com Tue Feb 15 05:08: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 FAA21547 for ; Tue, 15 Feb 2000 05:08:17 -0500 (EST) 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 CAA07290; Tue, 15 Feb 2000 02:06:22 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id CAA27135 for nat-outgoing; Tue, 15 Feb 2000 02:04:16 -0800 (PST) Message-ID: <38A9241D.7F0DAB46@india.hp.com> Date: Tue, 15 Feb 2000 15:32:05 +0530 From: "Ramaprasad K.R." X-Mailer: Mozilla 4.6 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: nat@livingston.com Subject: (NAT) NAT Queries Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-nat@livingston.com Precedence: bulk Reply-To: "Ramaprasad K.R." Content-Transfer-Encoding: 7bit Hello, A "stub domain" is using the 10/8 addresses for its private network. The stub border router w/ NAT has been assigned a class C globally unique address. So, even though there may be more than 255 nodes in the stub domain, at any point in time, only a maximum of 255 nodes can be communicating w/ outside hosts thru the stub router as it has a class C address for it. Am I correct ? Would that be correct irrespective of static or dynamic address translations ? TIA, Rampi - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message. From owner-nat@livingston.com Thu Feb 17 00:16:01 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 AAA24032 for ; Thu, 17 Feb 2000 00:16:00 -0500 (EST) 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 VAA13209; Wed, 16 Feb 2000 21:08:00 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id VAA09167 for nat-outgoing; Wed, 16 Feb 2000 21:05:20 -0800 (PST) Message-ID: <38AB8149.A5E76494@india.hp.com> Date: Thu, 17 Feb 2000 10:34:09 +0530 From: "Ramaprasad K.R." X-Mailer: Mozilla 4.6 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: nat@livingston.com Subject: (NAT) SNMP and NAT Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-nat@livingston.com Precedence: bulk Reply-To: "Ramaprasad K.R." Content-Transfer-Encoding: 7bit Hi, Whenver an IP address which is an index for a table is translated using SNMP-ALG, the length of the encoding could change. I wanted to confirm that in such a case, all the "length" encodings of the sequences should be updated and finally the "length" of the SNMP message encoding should also be updated, correct ? Please let me know. In draft-ietf-nat-traditional-03.txt document there is a reference to "IP Masquerade" public domain software under Linux. Could somebody tell me where I can find it ? Thanks, Rampi - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message. From owner-nat@livingston.com Thu Feb 17 03:34:48 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 DAA07718 for ; Thu, 17 Feb 2000 03:34:46 -0500 (EST) 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 AAA15154; Thu, 17 Feb 2000 00:30:17 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id AAA14225 for nat-outgoing; Thu, 17 Feb 2000 00:26:08 -0800 (PST) Date: Thu, 17 Feb 2000 09:22:28 +0100 Message-Id: <200002170822.JAA17261@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: krampi@india.hp.com CC: nat@livingston.com In-reply-to: <38AB8149.A5E76494@india.hp.com> (krampi@india.hp.com) Subject: Re: (NAT) SNMP and NAT References: <38AB8149.A5E76494@india.hp.com> Sender: owner-nat@livingston.com Precedence: bulk Reply-To: Juergen Schoenwaelder >>>>> Ramaprasad K R writes: Ramaprasad> Whenver an IP address which is an index for a table is Ramaprasad> translated using SNMP-ALG, the length of the encoding Ramaprasad> could change. Ramaprasad> I wanted to confirm that in such a case, all the "length" Ramaprasad> encodings of the sequences should be updated and finally Ramaprasad> the "length" of the SNMP message encoding should also be Ramaprasad> updated, correct ? Please let me know. Yes, the length change propagates to the outermost SEQUENCE. /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message. From owner-nat@livingston.com Thu Feb 17 23:21:14 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 XAA02565 for ; Thu, 17 Feb 2000 23:21:13 -0500 (EST) 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 UAA01575; Thu, 17 Feb 2000 20:08:53 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id UAA00477 for nat-outgoing; Thu, 17 Feb 2000 20:06:12 -0800 (PST) Message-ID: <20000218040521.8540.qmail@web1405.mail.yahoo.com> Date: Thu, 17 Feb 2000 20:05:21 -0800 (PST) From: Pyda Srisuresh Subject: Re: (NAT) NAT Queries To: "Ramaprasad K.R." , 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 Yes, if you have Basic-NAT on the stub router. Further, this is irrespective of static or dyanmic address maps. cheers, suresh --- "Ramaprasad K.R." wrote: > Hello, > > A "stub domain" is using the 10/8 addresses for its private network. > The stub border router w/ NAT has been assigned a class C > globally unique address. > > So, even though there may be more than 255 nodes in the stub domain, > at any point in time, only a maximum of 255 nodes can be > communicating w/ outside hosts thru the stub router as it has a > class C address for it. Am I correct ? > > Would that be correct irrespective of static or dynamic address > translations ? > > TIA, > Rampi > - > To unsubscribe, email 'majordomo@livingston.com' with > 'unsubscribe nat' in the body of the message. > ===== __________________________________________________ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message. From owner-nat@livingston.com Fri Feb 25 11:22: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 LAA13553 for ; Fri, 25 Feb 2000 11:22:16 -0500 (EST) 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 IAA14963; Fri, 25 Feb 2000 08:19:49 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id IAA07397 for nat-outgoing; Fri, 25 Feb 2000 08:16:34 -0800 (PST) Message-Id: <4.2.0.58.20000225102339.00d791c0@homebase.htt-consult.com> X-Sender: rgm-ietf@homebase.htt-consult.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Fri, 25 Feb 2000 10:28:04 -0500 To: nat@livingston.com From: Robert Moskowitz Subject: (NAT) Recommended reading - drafts Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-nat@livingston.com Precedence: bulk Reply-To: Robert Moskowitz I have been a NAT lurker for some time. I am now delurking. I have discussed bringing up the following with the co-chairs and ADs: In Dec '98 I started out studying why IPsec was not delivering security services to the protocols that needed privacy and/or authentication. My first opinion was it took too long; later I realized that a fundamental design of IP was central to IPsec and NAT's complexity. That is the confounding of naming and routing. I set out to design a namespace that would decouple the internetworking and transport layers (BTW, I am on the IRTF NSRG). The current result is documented in my Host Identity Payload drafts: http://www.ietf.org/internet-drafts/draft-moskowitz-hip-arch-01.txt http://www.ietf.org/internet-drafts/draft-moskowitz-hip-01.txt http://www.ietf.org/internet-drafts/draft-moskowitz-hip-impl-00.txt I will be the first to admit that these drafts need improvement in presentation. But in brief, by creating a cryptographically based host namespace that is statistically globally unique with 3 representations, I am able to use ESP 'transport layer' in place of the internetworking layer (either IPv4 or IPv6) for the transport binding. This provides NAT friendliness that boarders on transparency. There is some specific DNS configuration issues to support this, and DNSSEC is recommended to address man-in-the-middle attacks. HIP and its ESP can traverse any addressing realm boundaries; this includes IPv6/4 gateways, not just IPv4 NATs. I can appreciate that this is radical thinking, but I ask that people here look over HIP and send me comments. Has HIP met its goals? Does it offer real end-to-end services? Can it reduce the complexity in the network and even the end systems? I am working on the next set of drafts. I will not be in Adelaide, but might be able to get someone to present HIP at one of your sessions if there is interest. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message. From owner-nat@livingston.com Fri Feb 25 14:17: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 OAA18322 for ; Fri, 25 Feb 2000 14:17:14 -0500 (EST) 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 LAA18800; Fri, 25 Feb 2000 11:14:50 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id LAA17089 for nat-outgoing; Fri, 25 Feb 2000 11:14:59 -0800 (PST) From: Jim Bound Message-Id: <200002251909.OAA0000025491@yquarry.zk3.dec.com> To: Robert Moskowitz Cc: nat@livingston.com, bound@zk3.dec.com Subject: Re: (NAT) Recommended reading - drafts In-reply-to: Your message of "Fri, 25 Feb 2000 10:28:04 EST." <4.2.0.58.20000225102339.00d791c0@homebase.htt-consult.com> Date: Fri, 25 Feb 2000 14:09:58 -0500 X-Mts: smtp Sender: owner-nat@livingston.com Precedence: bulk Reply-To: Jim Bound Hi Bob, >I have discussed bringing up the following with the co-chairs and ADs: I think this discussion belongs in the IRTF for now and if in the IETF in the end-to-end group. http://www.ietf.org/internet-drafts/draft-moskowitz-hip-arch-01.txt http://www.ietf.org/internet-drafts/draft-moskowitz-hip-01.txt http://www.ietf.org/internet-drafts/draft-moskowitz-hip-impl-00.txt >I can appreciate that this is radical thinking, but I ask that people here >look over HIP and send me comments. Has HIP met its goals? Does it offer >real end-to-end services? Can it reduce the complexity in the network and >even the end systems? I read all the drafts and the ones on ESP and DNS too. First, I do not agree with two of your base assumptions: 1. That IP addresses do not identify nodes: IN fact they do in mulitple instances (multiple addresses) I also think it a good paradigm and the only problem is the lack of IPv4 address space. That is being addressed first with bandaids like NAT and RSIP. THen eventually with the IETF's recommendation for IPng which is IPv6. I believe there will be points of inflection for sure with IPv6 and the band-aids. 2. That IP addresses are not good identifiers for IPsec. I think they are very good and appropriate considering time-to-market, cost of engineering, and ability to do the job. Is it the most elegant NO. But will it work and suffice as an identifier yes (but I agree with Bruce Schneier's IPsec Critique and the issues of designing by committee, but again its all we got for now). But to reiterate I think this work needs some prototyping and implementation as a logic check. You use the word IP kernel in the arch draft and indirectly in the imp draft. As a "real" IP kernel product engineer and architect your words around the "virtual" layers I find very high-level and messing with the TCB is very very tricky business. IN fact that one aspect of HIP clearly belongs in IRTF or at a minimum in the end-to-end group. Do we really want to continue this discussion on the NAT list? regards, /jim - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message. From owner-nat@livingston.com Fri Feb 25 14:43:56 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 OAA19090 for ; Fri, 25 Feb 2000 14:43:54 -0500 (EST) 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 LAA19484; Fri, 25 Feb 2000 11:41:32 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id LAA18591 for nat-outgoing; Fri, 25 Feb 2000 11:42:02 -0800 (PST) Message-Id: <4.2.0.58.20000225141950.00a33670@homebase.htt-consult.com> X-Sender: rgm-ietf@homebase.htt-consult.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Fri, 25 Feb 2000 14:39:16 -0500 To: Jim Bound From: Robert Moskowitz Subject: Re: (NAT) Recommended reading - drafts Cc: nat@livingston.com, bound@zk3.dec.com In-Reply-To: <200002251909.OAA0000025491@yquarry.zk3.dec.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-nat@livingston.com Precedence: bulk Reply-To: Robert Moskowitz At 02:09 PM 2/25/2000 -0500, Jim Bound wrote: > >I have discussed bringing up the following with the co-chairs and ADs: > >I think this discussion belongs in the IRTF for now and if in the IETF >in the end-to-end group. It is in the NSRG IRTF. I did not know that the IETF has an end-to-end workgroup. I do know of one in the IRTF. > http://www.ietf.org/internet-drafts/draft-moskowitz-hip-arch-01.txt > http://www.ietf.org/internet-drafts/draft-moskowitz-hip-01.txt > http://www.ietf.org/internet-drafts/draft-moskowitz-hip-impl-00.txt > > >I can appreciate that this is radical thinking, but I ask that people here > >look over HIP and send me comments. Has HIP met its goals? Does it offer > >real end-to-end services? Can it reduce the complexity in the network and > >even the end systems? > >I read all the drafts and the ones on ESP and DNS too. First, I do not >agree with two of your base assumptions: > >1. That IP addresses do not identify nodes: > >IN fact they do in mulitple instances (multiple addresses) I also think >it a good paradigm and the only problem is the lack of IPv4 address >space. That is being addressed first with bandaids like NAT and RSIP. IP addresses identify interfaces. This is covered in Comer's book. He shows it very clearly in his IP state manchine. The lack of namespace size is not the only problem with IPv4. A problem, or rather, an 'engineering comprimise', that it and IPv6 share is its hierarchical assignment strategy. This puts a value on the 'names', and a history. A valuable feature in a end point name is local creation and anonymity. 128 bits is large enough for this if all the bits are available; no routing information. >THen eventually with the IETF's recommendation for IPng which is IPv6. >I believe there will be points of inflection for sure with IPv6 and the >band-aids. IPv6 serves a very important role, and HIP does not preclude it. In fact HIP works equally well with v6 and provides for some interesting transition features. >2. That IP addresses are not good identifiers for IPsec. I think they >are very good and appropriate considering time-to-market, cost of >engineering, and ability to do the job. Barely so. Only for globally addressed devices. For B2B in todays world it just doesn't work and the hacks are loaded on the hacks. Jim, my company test these products and in general terms their success is poor. Also most of today's products are solving a stop-gap problem: gateway2gateway. Many corporate people that I talk to want end2end. >Is it the most elegant NO. But >will it work and suffice as an identifier yes (but I agree with Bruce >Schneier's IPsec Critique and the issues of designing by committee, but >again its all we got for now). My critique resonates to some degree with Bruce. But for different reasons. I am busy writing my monday morning quarterback report. >But to reiterate I think this work needs some prototyping and >implementation as a logic check. Lots of agreement here. But before much prototyping is done, there is a lot of value of getting good community input. >You use the word IP kernel in the arch >draft and indirectly in the imp draft. As a "real" IP kernel product >engineer and architect your words around the "virtual" layers I find >very high-level and messing with the TCB is very very tricky business. >IN fact that one aspect of HIP clearly belongs in IRTF or at a minimum >in the end-to-end group. Again, part of the reason for airing to a larger audience. I HAVE discussed this with a few kernel architects; I've never claimed to be a system programmer. Many parts of the docs are still high-level, needing good input to add detail. Bringing this up in the IRTF's end2end makes sense, and I will approach Bob about it. What is the IETF's wg you reference, so I can contact it's chair(s). >Do we really want to continue this discussion on the NAT list? I bring it up here, as there are NAT scenarios in the implementation document. Given the way it provides mobility (I have also brought it up in MobileIP), it offers a certain elegance in NATs, be they v4-v4 or v4-v6 devices. Even IPv4-IPX (if anyone wanted to do that anymore, but i make the architectural point). So that is why I approached the chairs. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message. From owner-nat@livingston.com Fri Feb 25 15:45:46 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 PAA20334 for ; Fri, 25 Feb 2000 15:45:45 -0500 (EST) 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 MAA20851; Fri, 25 Feb 2000 12:40:25 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id MAA21399 for nat-outgoing; Fri, 25 Feb 2000 12:41:05 -0800 (PST) From: Jim Bound Message-Id: <200002252035.PAA0000028866@yquarry.zk3.dec.com> To: Robert Moskowitz Cc: Jim Bound , nat@livingston.com Subject: Re: (NAT) Recommended reading - drafts In-reply-to: Your message of "Fri, 25 Feb 2000 14:39:16 EST." <4.2.0.58.20000225141950.00a33670@homebase.htt-consult.com> Date: Fri, 25 Feb 2000 15:35:33 -0500 X-Mts: smtp Sender: owner-nat@livingston.com Precedence: bulk Reply-To: Jim Bound Hi Bob, >>I think this discussion belongs in the IRTF for now and if in the IETF >>in the end-to-end group. > >It is in the NSRG IRTF. I did not know that the IETF has an end-to-end >workgroup. I do know of one in the IRTF. Hmmm OK I thought that was part of the transport area? >> http://www.ietf.org/internet-drafts/draft-moskowitz-hip-arch-01.txt >> http://www.ietf.org/internet-drafts/draft-moskowitz-hip-01.txt >> http://www.ietf.org/internet-drafts/draft-moskowitz-hip-impl-00.txt >> >> >I can appreciate that this is radical thinking, but I ask that people here >> >look over HIP and send me comments. Has HIP met its goals? Does it offer >> >real end-to-end services? Can it reduce the complexity in the network and >> >even the end systems? >> >>I read all the drafts and the ones on ESP and DNS too. First, I do not >>agree with two of your base assumptions: >> >>1. That IP addresses do not identify nodes: >> >>IN fact they do in mulitple instances (multiple addresses) I also think >>it a good paradigm and the only problem is the lack of IPv4 address >>space. That is being addressed first with bandaids like NAT and RSIP. > >IP addresses identify interfaces. This is covered in Comer's book. He >shows it very clearly in his IP state manchine. I don't agree with Comers conclusion OK. Here is excerpt from IPv6 RFC 2373 too: 2.1 Addressing Model IPv6 addresses of all types are assigned to interfaces, not nodes. An IPv6 unicast address refers to a single interface. Since each interface belongs to a single node, any of that node's interfaces' unicast addresses may be used as an identifier for the node. The point is that an address can identify a node. Many existing applications on the Internet also use it that way. They are not going to change. The key is that each interface belongs to a single node. This permits it to identify the node. This is the point many IP pundits miss which rfc2373 got right. >The lack of namespace size is not the only problem with IPv4. A problem, >or rather, an 'engineering comprimise', that it and IPv6 share is its >hierarchical assignment strategy. This puts a value on the 'names', and a >history. A valuable feature in a end point name is local creation and >anonymity. 128 bits is large enough for this if all the bits are >available; no routing information. This sounds like the old EID argument and you know I have been there and this is definitely not a NAT topic or place to discuss IMO. >>THen eventually with the IETF's recommendation for IPng which is IPv6. >>I believe there will be points of inflection for sure with IPv6 and the >>band-aids. > >IPv6 serves a very important role, and HIP does not preclude it. In fact >HIP works equally well with v6 and provides for some interesting transition >features. HIP will not reach consensus or the light of day in the IETF unless well qualified in scope. It affects the base architecture of IP impelementation too, and why I think we need some proof of concept. I have similar proposals of great affect to IP but I would not propose them without some implementation experience if that can be found. >>2. That IP addresses are not good identifiers for IPsec. I think they >>are very good and appropriate considering time-to-market, cost of >>engineering, and ability to do the job. >Barely so. Only for globally addressed devices. For B2B in todays world >it just doesn't work and the hacks are loaded on the hacks. Jim, my >company test these products and in general terms their success is >poor. Also most of today's products are solving a stop-gap problem: >gateway2gateway. Many corporate people that I talk to want end2end. I want end2end too. >>Is it the most elegant NO. But >>will it work and suffice as an identifier yes (but I agree with Bruce >>Schneier's IPsec Critique and the issues of designing by committee, but >>again its all we got for now). >My critique resonates to some degree with Bruce. But for different >reasons. I am busy writing my monday morning quarterback report. Fair answer. >>But to reiterate I think this work needs some prototyping and >>implementation as a logic check. > >Lots of agreement here. But before much prototyping is done, there is a >lot of value of getting good community input. Thats a good point. >>You use the word IP kernel in the arch >>draft and indirectly in the imp draft. As a "real" IP kernel product >>engineer and architect your words around the "virtual" layers I find >>very high-level and messing with the TCB is very very tricky business. >>IN fact that one aspect of HIP clearly belongs in IRTF or at a minimum >>in the end-to-end group. >Again, part of the reason for airing to a larger audience. I HAVE >discussed this with a few kernel architects; I've never claimed to be a >system programmer. Many parts of the docs are still high-level, needing >good input to add detail. My input to you is not talk to kernel architects but people who work with real kernel code. I am not saying this is impossible but I will tell you the ramifications are as significant to what was done for IPv6 for impelementation. Also one can't break whats running today and that makes it even more complex. Also a nit. The TCB is just the tip of the iceburg. The real issue will be for the Protocol Control Block (PCB) and address resolution data structures for node discovery lookups. I would make this transparent to the entire kernel and have it discovered out of band in user space. It should have nothing to do with routing or tcp response paradigm or applicatiion notification as the TCB is used for that too. This way it works for UDP too. Note there is now equiv TCB for UDP!!! >Bringing this up in the IRTF's end2end makes sense, and I will approach Bob >about it. What is the IETF's wg you reference, so I can contact it's chair(s). I think your in the right Area under Scott and Vern. But HIP affects lots of stuff. I would suggest first make sure the e2e principles are agreed to then possibly its an operation issue. Why not run it by the Transport Area Directorate that way you get input from folks like Jeff Mogul and Greg Misnshall and other bright folks who worry about e2e at this level. >>Do we really want to continue this discussion on the NAT list? > >I bring it up here, as there are NAT scenarios in the implementation >document. Given the way it provides mobility (I have also brought it up in >MobileIP), it offers a certain elegance in NATs, be they v4-v4 or v4-v6 >devices. Even IPv4-IPX (if anyone wanted to do that anymore, but i make >the architectural point). Anyway I will keep discussing whereever it is to be discussed so let me know where that happens. Its not I am against it I just think it needs to be discussed. I do fear the EID wars again and those never are fruitful IMO. /jim - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message. From owner-nat@livingston.com Fri Feb 25 16:08: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 QAA20708 for ; Fri, 25 Feb 2000 16:08:22 -0500 (EST) 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 NAA21506; Fri, 25 Feb 2000 13:05:48 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id NAA23057 for nat-outgoing; Fri, 25 Feb 2000 13:06:52 -0800 (PST) Message-Id: <4.2.0.58.20000225155206.00d7ac40@homebase.htt-consult.com> X-Sender: rgm-ietf@homebase.htt-consult.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Fri, 25 Feb 2000 16:04:09 -0500 To: Jim Bound From: Robert Moskowitz Subject: Re: (NAT) Recommended reading - drafts Cc: Jim Bound , nat@livingston.com In-Reply-To: <200002252035.PAA0000028866@yquarry.zk3.dec.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-nat@livingston.com Precedence: bulk Reply-To: Robert Moskowitz At 03:35 PM 2/25/2000 -0500, Jim Bound wrote: perhaps a wrap on this little thread, and I thank you for your response, Jim. > >>I think this discussion belongs in the IRTF for now and if in the IETF > >>in the end-to-end group. > > > >It is in the NSRG IRTF. I did not know that the IETF has an end-to-end > >workgroup. I do know of one in the IRTF. I looked again. There is a transport area workgroup (tsvwg), which is a generalized wg in the transport area to take general topics. Perhaps that is what you meant. > >IP addresses identify interfaces. This is covered in Comer's book. He > >shows it very clearly in his IP state manchine. > >I don't agree with Comers conclusion OK. Here is excerpt from IPv6 RFC >2373 too: > >2.1 Addressing Model > > IPv6 addresses of all types are assigned to interfaces, not nodes. > An IPv6 unicast address refers to a single interface. Since each > interface belongs to a single node, any of that node's interfaces' > unicast addresses may be used as an identifier for the node. > >The point is that an address can identify a node. Many existing >applications on the Internet also use it that way. They are not going >to change. The key is that each interface belongs to a single node. >This permits it to identify the node. This is the point many IP pundits >miss which rfc2373 got right. But it identifies the node in light of its place in the network. that is where it got it wrong, imho. And I think we both know that we probably cannot win the other over on this point. > >The lack of namespace size is not the only problem with IPv4. A problem, > >or rather, an 'engineering comprimise', that it and IPv6 share is its > >hierarchical assignment strategy. This puts a value on the 'names', and a > >history. A valuable feature in a end point name is local creation and > >anonymity. 128 bits is large enough for this if all the bits are > >available; no routing information. > >This sounds like the old EID argument and you know I have been there and >this is definitely not a NAT topic or place to discuss IMO. It ties into EID, I was there too. It is a NAT topic because the impact an EID can have on NATs. When we had the last EID debate in '94 (the only one I really participated in), I don't think we had some of the knowledge we have now. So within a framework, it may be worth revisiting. >HIP will not reach consensus or the light of day in the IETF unless well >qualified in scope. The next cut of the docs will attempt to do this. >It affects the base architecture of IP impelementation >too, and why I think we need some proof of concept. Lining up some proof of concepters now. >I have similar proposals >of great affect to IP but I would not propose them without some implementation >experience if that can be found. > >Barely so. Only for globally addressed devices. For B2B in todays world > >it just doesn't work and the hacks are loaded on the hacks. Jim, my > >company test these products and in general terms their success is > >poor. Also most of today's products are solving a stop-gap problem: > >gateway2gateway. Many corporate people that I talk to want end2end. > >I want end2end too. I know. > >Again, part of the reason for airing to a larger audience. I HAVE > >discussed this with a few kernel architects; I've never claimed to be a > >system programmer. Many parts of the docs are still high-level, needing > >good input to add detail. > >My input to you is not talk to kernel architects but people who work >with real kernel code. Well, I did misspeak. I am talking to people that do the coding. >I am not saying this is impossible but I will >tell you the ramifications are as significant to what was done for IPv6 >for impelementation. Also one can't break whats running today and that >makes it even more complex. And part of what I need is did I break what is running now? >Also a nit. The TCB is just the tip of the iceburg. The real issue >will be for the Protocol Control Block (PCB) and address resolution data >structures for node discovery lookups. thanks. >I would make this transparent to the entire kernel and have it >discovered out of band in user space. It should have nothing to do with >routing or tcp response paradigm or applicatiion notification as the >TCB is used for that too. This way it works for UDP too. Note there is >now equiv TCB for UDP!!! actually it does work for UDP. It is just that TCP has some bigger level violations. I disagree about the user space. Partly it is because the transports are what are attackable in their current form. >I think your in the right Area under Scott and Vern. But HIP affects >lots of stuff. I would suggest first make sure the e2e principles are >agreed to then possibly its an operation issue. Why not run it by the >Transport Area Directorate that way you get input from folks like Jeff >Mogul and Greg Misnshall and other bright folks who worry about e2e at >this level. I will follow up on this. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message. From owner-nat@livingston.com Fri Feb 25 18:54:41 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 SAA23362 for ; Fri, 25 Feb 2000 18:54:40 -0500 (EST) 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 PAA24676; Fri, 25 Feb 2000 15:51:19 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id PAA02550 for nat-outgoing; Fri, 25 Feb 2000 15:51:58 -0800 (PST) From: Jim Bound Message-Id: <200002252348.SAA0000002906@yquarry.zk3.dec.com> To: Robert Moskowitz Cc: Jim Bound , nat@livingston.com Subject: Re: (NAT) Recommended reading - drafts In-reply-to: Your message of "Fri, 25 Feb 2000 16:04:09 EST." <4.2.0.58.20000225155206.00d7ac40@homebase.htt-consult.com> Date: Fri, 25 Feb 2000 18:48:46 -0500 X-Mts: smtp Sender: owner-nat@livingston.com Precedence: bulk Reply-To: Jim Bound OK bob its a wrap. I will review it more in depth and send it to you privately. As one who codes in the kernel land of IP too. Pretty maxed now so it will take me a few weeks to review it to that degree. thanks /jim - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message. From owner-nat@livingston.com Tue Feb 29 10:43:24 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 KAA21428 for ; Tue, 29 Feb 2000 10:43:21 -0500 (EST) 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 HAA10196; Tue, 29 Feb 2000 07:40:44 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id HAA08449 for nat-outgoing; Tue, 29 Feb 2000 07:40:48 -0800 (PST) Message-ID: <007201bf82ca$44db7160$2cf2cdc1@coritel.it> From: "Raffaele Pellicciotta" To: Subject: (NAT) IP_Masq module for H323 Date: Tue, 29 Feb 2000 16:32:43 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-nat@livingston.com Precedence: bulk Reply-To: "Raffaele Pellicciotta" Content-Transfer-Encoding: 7bit Hi, I am developing an ipmasq-H323 module on redhat 6.1 kernel 2.2.12 . I am testing this module and it works well when I realize a call from my masqueraded machine towards public internet. I have a bi-directional conversation !!! Now I am thinking what can I do to allow calls from Internet to my private machine. I have a big doubt: Is it right to allow that a call from public Internet arrives to my private machine??? This doubt derives from the absence of a server ( in my private lan) when a private machine talks with a public machine. A public machine can talk with a private machine without the presence of a server. Is it conceptually right which I spend my time to develop an ip_masq_h323 module to allow a public host to call a private host? Thanks a lot, Raffaele Pellicciotta - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message. From owner-nat@livingston.com Tue Feb 29 10:47:20 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 KAA21588 for ; Tue, 29 Feb 2000 10:47:18 -0500 (EST) 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 HAA10382; Tue, 29 Feb 2000 07:45:03 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id HAA08730 for nat-outgoing; Tue, 29 Feb 2000 07:48:17 -0800 (PST) Message-ID: <007f01bf82cb$52008140$2cf2cdc1@coritel.it> From: "Raffaele Pellicciotta" To: Subject: (NAT) Information about SMTP Date: Tue, 29 Feb 2000 16:40:35 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-nat@livingston.com Precedence: bulk Reply-To: "Raffaele Pellicciotta" Content-Transfer-Encoding: 7bit Hi, I desire to know what happens when I send a normal e-mail from a mail-server ( in a private LAN with private ip addresses) to public Internet!!! And what happens when I send a normal e-mail from a mail-server ( in a private LAN with private ip addresses) to public Internet through a NAT router!!! Thanks a lot, Raffaele Pellicciotta - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message. From owner-nat@livingston.com Tue Feb 29 11:33:54 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 LAA24039 for ; Tue, 29 Feb 2000 11:33:53 -0500 (EST) 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 IAA11908; Tue, 29 Feb 2000 08:31:37 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id IAA10739 for nat-outgoing; Tue, 29 Feb 2000 08:35:06 -0800 (PST) From: gmattathil@silicom.com Date: Tue, 29 Feb 2000 08:36:14 -0800 Subject: Re: (NAT) Information about SMTP To: Raffaele Pellicciotta Cc: nat@livingston.com, owner-nat@livingston.com Message-id: MIME-version: 1.0 X-Mailer: Lotus Notes Release 5.0.2a November 23, 1999 Content-type: text/plain; charset="us-ascii" X-MIMETrack: Serialize by Idle on George Mattathil/Silicom(Release 5.0.2a |November 23, 1999) at 02/29/2000 08:37:08 AM, Serialize complete at 02/29/2000 08:37:08 AM Sender: owner-nat@livingston.com Precedence: bulk Reply-To: gmattathil@silicom.com SMTP (e-mail) is an application level protocol, and is independent of the network layer. This means that address translation issues have no impact on SMTP. If the User Agent (client mail program) can connect and communicate to the SMTP (mail server) then the email transfer will work. Establishing the connection is done at the network layer (TCP/IP), where the address translation issues are involved. If the connection cannot be made, then email applications (client and server) cannot communicate, and the email transfer will not occur. Hope this answers your question. George Mattathil Note: The preceding Email took 23 Min, 12 Sec. from the time you sent to the time it reached my system. "Raffaele Pellicciotta" Sent by: owner-nat@livingston.com 02/29/00 07:40 AM Please respond to "Raffaele Pellicciotta" To: cc: Subject: (NAT) Information about SMTP Hi, I desire to know what happens when I send a normal e-mail from a mail-server ( in a private LAN with private ip addresses) to public Internet!!! And what happens when I send a normal e-mail from a mail-server ( in a private LAN with private ip addresses) to public Internet through a NAT router!!! Thanks a lot, Raffaele Pellicciotta - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message. From owner-nat@livingston.com Tue Feb 29 13:59: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 NAA29215 for ; Tue, 29 Feb 2000 13:59:16 -0500 (EST) 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 KAA14897; Tue, 29 Feb 2000 10:56:42 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id KAA18632 for nat-outgoing; Tue, 29 Feb 2000 10:59:31 -0800 (PST) From: gmattathil@silicom.com Date: Tue, 29 Feb 2000 10:56:24 -0800 Subject: Re: (NAT) Information about SMTP To: Lucy Yang Cc: nat@livingston.com, owner-nat@livingston.com, pellicciotta@coritel.it Message-id: MIME-version: 1.0 X-Mailer: Lotus Notes Release 5.0.2a November 23, 1999 Content-type: text/plain; charset="us-ascii" X-MIMETrack: Serialize by Idle on George Mattathil/Silicom(Release 5.0.2a |November 23, 1999) at 02/29/2000 10:58:23 AM, Serialize complete at 02/29/2000 10:58:23 AM Sender: owner-nat@livingston.com Precedence: bulk Reply-To: gmattathil@silicom.com CMIP and SNMP are also application level (network management) protocols. So the issues at the basic level are the same as that of SMTP. Original intention of the private addresses was that there would no need for them to communicate with "public" address nodes. So the need for "private" and "public" address nodes to communicate creates a new situation. From a protocol perspective, the address issues (for transport and connectivity) need to be preserved at the network/transport layers. But the CMIP/SNMP application needs creates another dimension to the problem. In my view, the CMIP/SNMP applications should preserve the original attributes of private and public addresses. Because changing those attributes can have unintended and/or unforeseen consequences. This reduces the issue in question to how to develop inter-operability between CMIP/SNMP nodes with private and public addresses. My suggestion is to implement a CMIP/SNMP adapter agent to make the appropriate transformations on the CMIP/SNMP user data. In this way all the application level requirements on the CMIP/SNMP protocol data will be localized to the CMIP/SNMP adapter agent. [Disclaimer: What I have expressed is my view on this issue, without considering any other approaches that may exist out there :-)] Hope this helps. George Mattathil 408 255 9800 "silicom.com - the digital ecosystem" Note: The preceding Email took 33 Min, 1 Sec. from the time you sent to the time it reached my system. Lucy Yang 02/29/00 09:07 AM To: gmattathil@silicom.com, Raffaele Pellicciotta cc: nat@livingston.com, owner-nat@livingston.com Subject: Re: (NAT) Information about SMTP Could you please also help me to figure out how 'NAT' (ALG) will support CMIP (and SNMP) applications since the addressing information may be inbedded within the user data portion which may not be looked at by traditional NAT. Thanks. Lucy Yang --- gmattathil@silicom.com wrote: > SMTP (e-mail) is an application level protocol, and > is independent of the network layer. This means that > address translation issues have no impact on SMTP. > If the User Agent (client mail program) can connect > and communicate to the SMTP (mail server) then the > email transfer will work. Establishing the > connection > is done at the network layer (TCP/IP), where the > address > translation issues are involved. If the connection > cannot be made, then email applications (client and > server) > cannot communicate, and the email transfer will not > occur. > > Hope this answers your question. > > George Mattathil > > Note: The preceding Email took 23 Min, 12 Sec. > from the time you sent to the time it reached my > system. > > > > > "Raffaele Pellicciotta" > Sent by: owner-nat@livingston.com > 02/29/00 07:40 AM > Please respond to "Raffaele Pellicciotta" > > > To: > cc: > Subject: (NAT) Information about SMTP > Hi, I desire to know what happens when I send a > normal e-mail from a > mail-server ( in a private LAN with private ip > addresses) > to public Internet!!! And what happens when I > send a normal e-mail > from > a mail-server ( in a private LAN with private ip > addresses) > to public Internet through a NAT router!!! > Thanks a lot, > Raffaele Pellicciotta > > ===== Lucy Yang Sr. Software Engineer Motorola 847-435-0744 Email: lucy@bit.edu __________________________________________________ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message. From owner-nat@livingston.com Tue Feb 29 17:10: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 RAA03680 for ; Tue, 29 Feb 2000 17:10:17 -0500 (EST) 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 OAA17957; Tue, 29 Feb 2000 14:07:56 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id OAA29116 for nat-outgoing; Tue, 29 Feb 2000 14:07:48 -0800 (PST) Message-ID: <4148FEAAD879D311AC5700A0C969E8901CC08F@orsmsx35.jf.intel.com> From: "Iyer, Prakash" To: nat@livingston.com Subject: (NAT) RSIP: comments on latest draft versions Date: Tue, 29 Feb 2000 14:03:50 -0800 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: "Iyer, Prakash" > rsip-framework-03 draft: > * In the introduction section, text says > While NAT does not require a host to be aware of its presence, it requires > the presence of a proxy module, the application layer gateway (ALG), > within the NAT router for each application that embeds addressing > information, IP address or port content, within the packet payload (e.g., > FTP). RSIP (Realm Specific IP) provides an alternative to remedy these > limitations. > > What's needed is an example to show how proxies are completely eliminated > with RSIP. Applications that use the local IP address in application PDUs > may have to use the private realm IP address for communication in the > private realm and the public IP address for communication with a node in > the public realm. An example on how this can be done should be included in > the framework draft. Consider active mode FTP and H.323 apps (e.g. > NetMeeting) as examples on the client side. On the gateway side, an H.323 > proxy in a NAT environment is an example: if an H.323 application tries to > register with a Gatekeeper, the proxy translates the source IP address to > the external (WAN) IP address before forwarding the registration packet to > an external Gatekeeper. If the proxy is eliminated, how will this continue > to work? > > * Comment on the following text, > When using RSAP-IP, an RSIP server maintains a pool of IP addresses as > well as pools of port numbers per address. RSIP clients lease an IP > address and one or more ports to use with it. Once an address / port > tuple has been allocated to a particular client, only that client may use > the tuple until it is returned to the pool(s. > In the trivial case of a pool of 1 IP address, does this imply that only 1 > client can be supported in the private realm. That is clearly not the > case. The server can allocate the same IP address to multiple clients in > the private realm and allocate a different, non-overlapping range of ports > (or other de-MUXing parameters) to each client. > > * The draft recommends an MTU size of 512 bytes for UDP datagrams to avoid > fragmentation. How will this accommodate video applications that can > generate datagrams larger than 512 bytes. > > rsip-protocol-05 draft: > * OK and DEALLOCATE messages have been dropped but not mentioned in > revision history. And is this an issue if UDP ise used as transport for > the control channel. > > * Need a section discussing how RSIP works in an environment with N hosts > in private realm and M IP addresses, where N >= M and M > 1. > > * Can an RSIP client using RSAP-IP use its own (a different set of) ports > after it requests and is allocated ports by the RSIP server. It seems like > this should be possible for communication on the local LAN but to keep the > protocol simple, this may be explicitly disallowed. For communication with > external (public) hosts, the RSIP client MUST use ports from an RSIP > server allocated range. Section 7.1 should be clear on this issue. > > * An RSIP gateway should not allocate more than one 1 IP address to an > RSIP client simultaneously. > > * Text is inconsistent in specifying handling of "Don't Care" values. > For example, section 8.1 states > a "don't care" value for an address is signified by a setting the length > field to 1 and omitting the value field. > > But in section 9.8.3, > An RSIP client may indicate that it has no preference for local address or > ports, the RSIP client may place a "don't care" value of zeros in the > respective address or ports parameters > > * QUERY_REQUEST specifies a network tuple which has a network and a > netmask field. What's the format of the network field - an example will > help. > > * Handling of port requests should be documented clearly. For example, if > a client requests 4 ports from an RSIP server, the server MAY respond with > the same or a smaller number of ports. Some or all of the ports requested > the client may be included in a response from the RSIP server. > > Also need an example of a case where a client may specify a don't care > value for a port. > > rsip-ipsec-02 draft: > * The following text is confusing: > If the RSIP client wishes to use IPsec to protect a TCP or UDP > application, it MUST use the port range parameter (see Appendix A). > Otherwise, it MUST set the port parameters to the "don't need" value. > This is accomplished by setting the length field to 0, and by > omitting both the number field and the port field. > > Looks like the first instance of MUST should be a SHOULD (the Appendix > describes the consequence if a client does not require ports). > > The second part states that fields can be omitted to specify don't need > values but the semantics are not consistent with any text in the protocol > draft. > > * ASSIGN_REQUEST_RSIPSEC is missing the Overall Length parameter. > > * The draft does not recommend the use of port mapping in IPsec transport > mode. For example, is it OK to port map for transport mode IPsec but to > not modify ports for tunnel mode IPsec. > -Prakash Iyer Intel Arch Labs - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message.