From mailman-admin@ietf.org Sat Mar 1 10:24:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08386 for ; Sat, 1 Mar 2003 10:24:08 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h21FXAp28531 for ; Sat, 1 Mar 2003 10:33:10 -0500 Date: Sat, 01 Mar 2003 10:33:10 -0500 Message-ID: <20030301153310.26394.20378.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: nat-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: mailman-admin@ietf.org Errors-To: mailman-admin@ietf.org X-BeenThere: mailman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, nat-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. *************************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. *************************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@www1.ietf.org. Thanks! Passwords for nat-archive@lists.ietf.org: List Password // URL ---- -------- nat@ietf.org qLLL https://www1.ietf.org/mailman/options/nat/nat-archive%40lists.ietf.org From nat-admin@ietf.org Tue Mar 4 13:42:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04963 for ; Tue, 4 Mar 2003 13:42:24 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24ImE503327; Tue, 4 Mar 2003 13:48:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24Cikp32201 for ; Tue, 4 Mar 2003 07:44:46 -0500 Received: from mail.cit.ie (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15285 for ; Tue, 4 Mar 2003 07:33:47 -0500 (EST) Received: from eeb253w2k (unverified [157.190.41.56]) by cit.ie (Rockliffe SMTPRA 5.2.5) with SMTP id for ; Tue, 4 Mar 2003 12:22:50 +0000 Message-ID: <001b01c2e24a$c3d52be0$3829be9d@eeb253w2k> From: "John Paul O Grady" To: Date: Tue, 4 Mar 2003 12:37:04 -0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0018_01C2E24A.C318B9B0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: [NAT] nat implementation in ns-2 Sender: nat-admin@ietf.org Errors-To: nat-admin@ietf.org X-BeenThere: nat@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Network Address Translation List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0018_01C2E24A.C318B9B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello I am doing some research with ns-2 (network simulator) and I need to = find an implementation of nat in ns-2. ns-2 supports emulation of nat = however I cant find any information on how it can be simulated in normal = simulations. I have looked everywhere but I cant find any information.. Any suggestions?? Thanks John Paul O Grady Cork Institute of Technology Ireland = -------------------Legal Disclaimer-------------------------------------= -- The above electronic mail transmission is confidential and intended only = for the person to whom it is addressed. Its contents may be protected by = legal and/or professional privilege. Should it be received by you in erro= r please contact the sender at the above quoted email address. Any unauth= orised form of reproduction of this message is strictly prohibited. The I= nstitute does not guarantee the security of any information electronicall= y transmitted and is not liable if the information contained in this comm= unication is not a proper and complete record of the message as transmitt= ed by the sender nor for any delay in its receipt. -------------------------------------------------------------------------= ---------------= ------=_NextPart_000_0018_01C2E24A.C318B9B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello
 
I am doing some research with ns-2 = (network=20 simulator) and I need to find an implementation of nat in ns-2. ns-2 = supports=20 emulation of nat however I cant find any information on how it can be = simulated=20 in normal simulations.
 
I have looked everywhere but I cant = find any=20 information..
 
Any suggestions??
 
Thanks
 
John Paul O Grady
Cork Institute of = Technology
Ireland
= -------------------Legal Disclaimer-------------------------------------= -- The above electronic mail transmission is confidential and intended only = for the person to whom it is addressed. Its contents may be protected by = legal and/or professional privilege. Should it be received by you in erro= r please contact the sender at the above quoted email address. Any unauth= orised form of reproduction of this message is strictly prohibited. The I= nstitute does not guarantee the security of any information electronicall= y transmitted and is not liable if the information contained in this comm= unication is not a proper and complete record of the message as transmitt= ed by the sender nor for any delay in its receipt. -------------------------------------------------------------------------= ---------------= ------=_NextPart_000_0018_01C2E24A.C318B9B0-- _______________________________________________ nat mailing list nat@ietf.org https://www1.ietf.org/mailman/listinfo/nat From mailnull@www1.ietf.org Tue Mar 4 13:44:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05030 for ; Tue, 4 Mar 2003 13:44:12 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h24Isl103625 for nat-archive@odin.ietf.org; Tue, 4 Mar 2003 13:54:47 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24ImE503327; Tue, 4 Mar 2003 13:48:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24Cikp32201 for ; Tue, 4 Mar 2003 07:44:46 -0500 Received: from mail.cit.ie (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15285 for ; Tue, 4 Mar 2003 07:33:47 -0500 (EST) Received: from eeb253w2k (unverified [157.190.41.56]) by cit.ie (Rockliffe SMTPRA 5.2.5) with SMTP id for ; Tue, 4 Mar 2003 12:22:50 +0000 Message-ID: <001b01c2e24a$c3d52be0$3829be9d@eeb253w2k> From: "John Paul O Grady" To: Date: Tue, 4 Mar 2003 12:37:04 -0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0018_01C2E24A.C318B9B0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: [NAT] nat implementation in ns-2 Sender: nat-admin@ietf.org Errors-To: nat-admin@ietf.org X-BeenThere: nat@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Network Address Translation List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0018_01C2E24A.C318B9B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello I am doing some research with ns-2 (network simulator) and I need to = find an implementation of nat in ns-2. ns-2 supports emulation of nat = however I cant find any information on how it can be simulated in normal = simulations. I have looked everywhere but I cant find any information.. Any suggestions?? Thanks John Paul O Grady Cork Institute of Technology Ireland = -------------------Legal Disclaimer-------------------------------------= -- The above electronic mail transmission is confidential and intended only = for the person to whom it is addressed. Its contents may be protected by = legal and/or professional privilege. Should it be received by you in erro= r please contact the sender at the above quoted email address. Any unauth= orised form of reproduction of this message is strictly prohibited. The I= nstitute does not guarantee the security of any information electronicall= y transmitted and is not liable if the information contained in this comm= unication is not a proper and complete record of the message as transmitt= ed by the sender nor for any delay in its receipt. -------------------------------------------------------------------------= ---------------= ------=_NextPart_000_0018_01C2E24A.C318B9B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello
 
I am doing some research with ns-2 = (network=20 simulator) and I need to find an implementation of nat in ns-2. ns-2 = supports=20 emulation of nat however I cant find any information on how it can be = simulated=20 in normal simulations.
 
I have looked everywhere but I cant = find any=20 information..
 
Any suggestions??
 
Thanks
 
John Paul O Grady
Cork Institute of = Technology
Ireland
= -------------------Legal Disclaimer-------------------------------------= -- The above electronic mail transmission is confidential and intended only = for the person to whom it is addressed. Its contents may be protected by = legal and/or professional privilege. Should it be received by you in erro= r please contact the sender at the above quoted email address. Any unauth= orised form of reproduction of this message is strictly prohibited. The I= nstitute does not guarantee the security of any information electronicall= y transmitted and is not liable if the information contained in this comm= unication is not a proper and complete record of the message as transmitt= ed by the sender nor for any delay in its receipt. -------------------------------------------------------------------------= ---------------= ------=_NextPart_000_0018_01C2E24A.C318B9B0-- _______________________________________________ nat mailing list nat@ietf.org https://www1.ietf.org/mailman/listinfo/nat From nat-admin@ietf.org Mon Mar 10 01:15:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14443 for ; Mon, 10 Mar 2003 01:15:52 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2A6KvO04515; Mon, 10 Mar 2003 01:20:57 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h29L7WO05701 for ; Sun, 9 Mar 2003 16:07:32 -0500 Received: from hotmail.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03595 for ; Sun, 9 Mar 2003 15:54:21 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 9 Mar 2003 12:56:27 -0800 Received: from 217.29.140.15 by sea2fd.sea2.hotmail.msn.com with HTTP; Sun, 09 Mar 2003 20:56:25 GMT X-Originating-IP: [217.29.140.15] From: "Mohammad Awad" To: brian@hursley.ibm.com Cc: nat@ietf.org Date: Sun, 09 Mar 2003 22:56:25 +0200 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 09 Mar 2003 20:56:27.0214 (UTC) FILETIME=[5A2076E0:01C2E67E] Subject: [NAT] Re: Need More Clarification Sender: nat-admin@ietf.org Errors-To: nat-admin@ietf.org X-BeenThere: nat@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Network Address Translation List-Post: List-Help: List-Subscribe: , Hi All, According to the previous discussion with Brian, regarding evaluation of inventing new options in IPv4 for management of whatever issues, (here it was for improving NAT managability), Brian made it clear for me that IP options surely would degrade the performance of the backbone routers, and logically there's nothing to sacrifice the overall performance for. May I thank Brian very much for his respected clarification. But what I've found that some implementations (definitely CISCO 12000 series 10GB) include a functionality named (IP options selective drop), which enables the adminstrator to either 1- drop a packet containing an option or 2-"ignore the option, preserve its existence and let the packet pass". refer to (http://www.cisco.com/en/US/products/sw/iosswrel/ps1829/products_feature_guide09186a0080104376.html#35920) So, by opting the second preference, I think that such feature in the backbone type routers, could enable exploiting the IP options space with options that do not require any sort of handling by the intermediate nodes, just require routers to passively convey them to the destination points, whereby they should be handled as intended. Looking forward for any comments. Mohammad Awad. >From: Brian E Carpenter >To: Mohammad Awad >Subject: Re: Need More Clarification >Date: Wed, 05 Mar 2003 09:17:22 +0100 > >Anything to do with NAT is bad and should not be recommended. >The way ahead is IPv6, not NAT. > >The problem with IP options is that new options will force routers >to kick the packet from the fast path (hardware processing) >onto the slow path (software processing). At multi-gigabit >line speeds, this is a very bad idea- it will increase router >latency by several orders of magnitude for those packets. I'm >not aware of any measurements, but it's obvious by construction. >I don't think the IETF has written this down, it's in the class >of "everybody knows" like so much Internet folklore. > >Hope this helps > Brian > >- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - >Brian E Carpenter >Distinguished Engineer, Internet Standards & Technology, IBM >On assignment at the IBM Zurich Laboratory, Switzerland > > >Mohammad Awad wrote: > > > > Hi Brian, > > I really was interested in reading the discussion between you and >Kuniaki > > Kondo in the mail > > >(http://www1.ietf.org/mail-archive/working-groups/nat/current/msg00037.html), > > about the proposal of exploiting the IP Options in some NAT enhancement. > > I've got the point that this subject was discussed before and was not > > recommended due to some reasons. My point is: > > regarding the statement that says (IP options degrade the performance of >the > > backbone routers): > > 1- Is there any measures or studies that prove this phenomena or just > > expirementals? > > 2- Was there any directions (through a standard document) to recommend >stop > > using the IP options as a whole? > > Thanks in advance, > > Moh Awad. > > _________________________________________________________________ The new MSN 8: smart spam protection and 2 months FREE* http://join.msn.com/?page=features/junkmail _______________________________________________ nat mailing list nat@ietf.org https://www1.ietf.org/mailman/listinfo/nat From nat-admin@ietf.org Mon Mar 10 01:16:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14521 for ; Mon, 10 Mar 2003 01:16:07 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2A6NKO04572; Mon, 10 Mar 2003 01:23:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2A66GO03228 for ; Mon, 10 Mar 2003 01:06:17 -0500 Received: from hotmail.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10448 for ; Mon, 10 Mar 2003 00:52:54 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 9 Mar 2003 21:55:02 -0800 Received: from 217.29.140.15 by sea2fd.sea2.hotmail.msn.com with HTTP; Mon, 10 Mar 2003 05:55:01 GMT X-Originating-IP: [217.29.140.15] From: "Mohammad Awad" To: brian@hursley.ibm.com Cc: nat@ietf.org Date: Mon, 10 Mar 2003 07:55:01 +0200 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 10 Mar 2003 05:55:02.0092 (UTC) FILETIME=[974B88C0:01C2E6C9] Subject: [NAT] IP Options not allowed Sender: nat-admin@ietf.org Errors-To: nat-admin@ietf.org X-BeenThere: nat@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Network Address Translation List-Post: List-Help: List-Subscribe: , Hi All, According to the previous discussion with Brian, regarding evaluation of inventing new options in IPv4 for management of whatever issues, (here it was for improving NAT managability), Brian made it clear for me that IP options surely would degrade the performance of the backbone routers, and logically there's nothing to sacrifice the overall performance for. May I thank Brian very much for his respected clarification. But what I've found that some implementations (definitely CISCO 12000 series 10GB) include a functionality named (IP options selective drop), which enables the adminstrator to either 1- drop a packet containing an option or 2-"ignore the option, preserve its existence and let the packet pass". refer to (http://www.cisco.com/en/US/products/sw/iosswrel/ps1829/products_feature_guide09186a0080104376.html#35920) So, by opting the second preference, I think that such feature in the backbone type routers, could enable exploiting the IP options space with options that do not require any sort of handling by the intermediate nodes, just require routers to passively convey them to the destination points, whereby they should be handled as intended. Looking forward for any comments. Mohammad Awad. >From: Brian E Carpenter >To: Mohammad Awad >Subject: Re: Need More Clarification >Date: Wed, 05 Mar 2003 09:17:22 +0100 > >Anything to do with NAT is bad and should not be recommended. >The way ahead is IPv6, not NAT. > >The problem with IP options is that new options will force routers >to kick the packet from the fast path (hardware processing) >onto the slow path (software processing). At multi-gigabit >line speeds, this is a very bad idea- it will increase router >latency by several orders of magnitude for those packets. I'm >not aware of any measurements, but it's obvious by construction. >I don't think the IETF has written this down, it's in the class >of "everybody knows" like so much Internet folklore. > >Hope this helps > Brian > >- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - >Brian E Carpenter >Distinguished Engineer, Internet Standards & Technology, IBM >On assignment at the IBM Zurich Laboratory, Switzerland > > >Mohammad Awad wrote: > > > > Hi Brian, > > I really was interested in reading the discussion between you and >Kuniaki > > Kondo in the mail > > >(http://www1.ietf.org/mail-archive/working-groups/nat/current/msg00037.html), > > about the proposal of exploiting the IP Options in some NAT enhancement. > > I've got the point that this subject was discussed before and was not > > recommended due to some reasons. My point is: > > regarding the statement that says (IP options degrade the performance of >the > > backbone routers): > > 1- Is there any measures or studies that prove this phenomena or just > > expirementals? > > 2- Was there any directions (through a standard document) to recommend >stop > > using the IP options as a whole? > > Thanks in advance, > > Moh Awad. > > _________________________________________________________________ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ nat mailing list nat@ietf.org https://www1.ietf.org/mailman/listinfo/nat From mailnull@www1.ietf.org Mon Mar 10 02:02:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14442 for ; Mon, 10 Mar 2003 01:15:52 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2A6ShH04705 for nat-archive@odin.ietf.org; Mon, 10 Mar 2003 01:28:43 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2A6KvO04515; Mon, 10 Mar 2003 01:20:57 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h29L7WO05701 for ; Sun, 9 Mar 2003 16:07:32 -0500 Received: from hotmail.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03595 for ; Sun, 9 Mar 2003 15:54:21 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 9 Mar 2003 12:56:27 -0800 Received: from 217.29.140.15 by sea2fd.sea2.hotmail.msn.com with HTTP; Sun, 09 Mar 2003 20:56:25 GMT X-Originating-IP: [217.29.140.15] From: "Mohammad Awad" To: brian@hursley.ibm.com Cc: nat@ietf.org Date: Sun, 09 Mar 2003 22:56:25 +0200 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 09 Mar 2003 20:56:27.0214 (UTC) FILETIME=[5A2076E0:01C2E67E] Subject: [NAT] Re: Need More Clarification Sender: nat-admin@ietf.org Errors-To: nat-admin@ietf.org X-BeenThere: nat@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Network Address Translation List-Post: List-Help: List-Subscribe: , Hi All, According to the previous discussion with Brian, regarding evaluation of inventing new options in IPv4 for management of whatever issues, (here it was for improving NAT managability), Brian made it clear for me that IP options surely would degrade the performance of the backbone routers, and logically there's nothing to sacrifice the overall performance for. May I thank Brian very much for his respected clarification. But what I've found that some implementations (definitely CISCO 12000 series 10GB) include a functionality named (IP options selective drop), which enables the adminstrator to either 1- drop a packet containing an option or 2-"ignore the option, preserve its existence and let the packet pass". refer to (http://www.cisco.com/en/US/products/sw/iosswrel/ps1829/products_feature_guide09186a0080104376.html#35920) So, by opting the second preference, I think that such feature in the backbone type routers, could enable exploiting the IP options space with options that do not require any sort of handling by the intermediate nodes, just require routers to passively convey them to the destination points, whereby they should be handled as intended. Looking forward for any comments. Mohammad Awad. >From: Brian E Carpenter >To: Mohammad Awad >Subject: Re: Need More Clarification >Date: Wed, 05 Mar 2003 09:17:22 +0100 > >Anything to do with NAT is bad and should not be recommended. >The way ahead is IPv6, not NAT. > >The problem with IP options is that new options will force routers >to kick the packet from the fast path (hardware processing) >onto the slow path (software processing). At multi-gigabit >line speeds, this is a very bad idea- it will increase router >latency by several orders of magnitude for those packets. I'm >not aware of any measurements, but it's obvious by construction. >I don't think the IETF has written this down, it's in the class >of "everybody knows" like so much Internet folklore. > >Hope this helps > Brian > >- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - >Brian E Carpenter >Distinguished Engineer, Internet Standards & Technology, IBM >On assignment at the IBM Zurich Laboratory, Switzerland > > >Mohammad Awad wrote: > > > > Hi Brian, > > I really was interested in reading the discussion between you and >Kuniaki > > Kondo in the mail > > >(http://www1.ietf.org/mail-archive/working-groups/nat/current/msg00037.html), > > about the proposal of exploiting the IP Options in some NAT enhancement. > > I've got the point that this subject was discussed before and was not > > recommended due to some reasons. My point is: > > regarding the statement that says (IP options degrade the performance of >the > > backbone routers): > > 1- Is there any measures or studies that prove this phenomena or just > > expirementals? > > 2- Was there any directions (through a standard document) to recommend >stop > > using the IP options as a whole? > > Thanks in advance, > > Moh Awad. > > _________________________________________________________________ The new MSN 8: smart spam protection and 2 months FREE* http://join.msn.com/?page=features/junkmail _______________________________________________ nat mailing list nat@ietf.org https://www1.ietf.org/mailman/listinfo/nat From mailnull@www1.ietf.org Mon Mar 10 02:02:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14522 for ; Mon, 10 Mar 2003 01:16:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2A6Swr04720 for nat-archive@odin.ietf.org; Mon, 10 Mar 2003 01:28:58 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2A6NKO04572; Mon, 10 Mar 2003 01:23:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2A66GO03228 for ; Mon, 10 Mar 2003 01:06:17 -0500 Received: from hotmail.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10448 for ; Mon, 10 Mar 2003 00:52:54 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 9 Mar 2003 21:55:02 -0800 Received: from 217.29.140.15 by sea2fd.sea2.hotmail.msn.com with HTTP; Mon, 10 Mar 2003 05:55:01 GMT X-Originating-IP: [217.29.140.15] From: "Mohammad Awad" To: brian@hursley.ibm.com Cc: nat@ietf.org Date: Mon, 10 Mar 2003 07:55:01 +0200 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 10 Mar 2003 05:55:02.0092 (UTC) FILETIME=[974B88C0:01C2E6C9] Subject: [NAT] IP Options not allowed Sender: nat-admin@ietf.org Errors-To: nat-admin@ietf.org X-BeenThere: nat@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Network Address Translation List-Post: List-Help: List-Subscribe: , Hi All, According to the previous discussion with Brian, regarding evaluation of inventing new options in IPv4 for management of whatever issues, (here it was for improving NAT managability), Brian made it clear for me that IP options surely would degrade the performance of the backbone routers, and logically there's nothing to sacrifice the overall performance for. May I thank Brian very much for his respected clarification. But what I've found that some implementations (definitely CISCO 12000 series 10GB) include a functionality named (IP options selective drop), which enables the adminstrator to either 1- drop a packet containing an option or 2-"ignore the option, preserve its existence and let the packet pass". refer to (http://www.cisco.com/en/US/products/sw/iosswrel/ps1829/products_feature_guide09186a0080104376.html#35920) So, by opting the second preference, I think that such feature in the backbone type routers, could enable exploiting the IP options space with options that do not require any sort of handling by the intermediate nodes, just require routers to passively convey them to the destination points, whereby they should be handled as intended. Looking forward for any comments. Mohammad Awad. >From: Brian E Carpenter >To: Mohammad Awad >Subject: Re: Need More Clarification >Date: Wed, 05 Mar 2003 09:17:22 +0100 > >Anything to do with NAT is bad and should not be recommended. >The way ahead is IPv6, not NAT. > >The problem with IP options is that new options will force routers >to kick the packet from the fast path (hardware processing) >onto the slow path (software processing). At multi-gigabit >line speeds, this is a very bad idea- it will increase router >latency by several orders of magnitude for those packets. I'm >not aware of any measurements, but it's obvious by construction. >I don't think the IETF has written this down, it's in the class >of "everybody knows" like so much Internet folklore. > >Hope this helps > Brian > >- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - >Brian E Carpenter >Distinguished Engineer, Internet Standards & Technology, IBM >On assignment at the IBM Zurich Laboratory, Switzerland > > >Mohammad Awad wrote: > > > > Hi Brian, > > I really was interested in reading the discussion between you and >Kuniaki > > Kondo in the mail > > >(http://www1.ietf.org/mail-archive/working-groups/nat/current/msg00037.html), > > about the proposal of exploiting the IP Options in some NAT enhancement. > > I've got the point that this subject was discussed before and was not > > recommended due to some reasons. My point is: > > regarding the statement that says (IP options degrade the performance of >the > > backbone routers): > > 1- Is there any measures or studies that prove this phenomena or just > > expirementals? > > 2- Was there any directions (through a standard document) to recommend >stop > > using the IP options as a whole? > > Thanks in advance, > > Moh Awad. > > _________________________________________________________________ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ nat mailing list nat@ietf.org https://www1.ietf.org/mailman/listinfo/nat From nat-admin@ietf.org Tue Mar 25 23:41:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17678 for ; Tue, 25 Mar 2003 23:41:40 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2Q4ukO14542; Tue, 25 Mar 2003 23:56:47 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2Q4tgO14480 for ; Tue, 25 Mar 2003 23:55:42 -0500 Received: from out004.verizon.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17599; Tue, 25 Mar 2003 23:34:34 -0500 (EST) Received: from MattXP.verizon.net ([67.225.108.138]) by out004.verizon.net (InterMail vM.5.01.05.27 201-253-122-126-127-20021220) with ESMTP id <20030326043653.TFRU10550.out004.verizon.net@MattXP.verizon.net>; Tue, 25 Mar 2003 22:36:53 -0600 Message-Id: <5.1.0.14.2.20030325203208.01a651b0@localhost> X-Sender: res06gzk@incoming.verizon.net X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 25 Mar 2003 20:36:46 -0800 To: nat@ietf.org From: Matt Holdrege Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Authentication-Info: Submitted using SMTP AUTH at out004.verizon.net from [67.225.108.138] at Tue, 25 Mar 2003 22:36:52 -0600 Subject: [NAT] NAT List closure notice Sender: nat-admin@ietf.org Errors-To: nat-admin@ietf.org X-BeenThere: nat@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Network Address Translation List-Post: List-Help: List-Subscribe: , To IETF NAT list subscribers: This notice is to inform you that the IETF NAT email list is closing down. Future IETF NAT discussions include the on-going work on the NAT MIB, should take place on the IETF MIDCOM email list or other pertinent lists. All the email sent to this list is preserved in an archive at ftp://ftp.ietf.org/ietf-mail-archive/nat/ Thanks for all the great work and discussions that have taken place here over the years. - Matt Holdrege (NAT WG Co-Chair) _______________________________________________ nat mailing list nat@ietf.org https://www1.ietf.org/mailman/listinfo/nat From mailnull@www1.ietf.org Wed Mar 26 00:27:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17679 for ; Tue, 25 Mar 2003 23:41:40 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2Q52H214757 for nat-archive@odin.ietf.org; Wed, 26 Mar 2003 00:02:17 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2Q4ukO14542; Tue, 25 Mar 2003 23:56:47 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2Q4tgO14480 for ; Tue, 25 Mar 2003 23:55:42 -0500 Received: from out004.verizon.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17599; Tue, 25 Mar 2003 23:34:34 -0500 (EST) Received: from MattXP.verizon.net ([67.225.108.138]) by out004.verizon.net (InterMail vM.5.01.05.27 201-253-122-126-127-20021220) with ESMTP id <20030326043653.TFRU10550.out004.verizon.net@MattXP.verizon.net>; Tue, 25 Mar 2003 22:36:53 -0600 Message-Id: <5.1.0.14.2.20030325203208.01a651b0@localhost> X-Sender: res06gzk@incoming.verizon.net X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 25 Mar 2003 20:36:46 -0800 To: nat@ietf.org From: Matt Holdrege Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Authentication-Info: Submitted using SMTP AUTH at out004.verizon.net from [67.225.108.138] at Tue, 25 Mar 2003 22:36:52 -0600 Subject: [NAT] NAT List closure notice Sender: nat-admin@ietf.org Errors-To: nat-admin@ietf.org X-BeenThere: nat@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Network Address Translation List-Post: List-Help: List-Subscribe: , To IETF NAT list subscribers: This notice is to inform you that the IETF NAT email list is closing down. Future IETF NAT discussions include the on-going work on the NAT MIB, should take place on the IETF MIDCOM email list or other pertinent lists. All the email sent to this list is preserved in an archive at ftp://ftp.ietf.org/ietf-mail-archive/nat/ Thanks for all the great work and discussions that have taken place here over the years. - Matt Holdrege (NAT WG Co-Chair) _______________________________________________ nat mailing list nat@ietf.org https://www1.ietf.org/mailman/listinfo/nat