From exim@www1.ietf.org Sun Jan 4 00:13:19 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24697 for ; Sun, 4 Jan 2004 00:13:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ad0ZH-0005B3-IY for ipv6-archive@odin.ietf.org; Sun, 04 Jan 2004 00:12:51 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i045Cp3r019895 for ipv6-archive@odin.ietf.org; Sun, 4 Jan 2004 00:12:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ad0ZH-0005Ao-DB for ipv6-web-archive@optimus.ietf.org; Sun, 04 Jan 2004 00:12:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24627 for ; Sun, 4 Jan 2004 00:12:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ad0ZF-0004g5-00 for ipv6-web-archive@ietf.org; Sun, 04 Jan 2004 00:12:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ad0XJ-0004Yn-00 for ipv6-web-archive@ietf.org; Sun, 04 Jan 2004 00:10:50 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ad0Ve-0004Ru-00 for ipv6-web-archive@ietf.org; Sun, 04 Jan 2004 00:09:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ad0Ub-0004os-UG; Sun, 04 Jan 2004 00:08:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ad0UL-0004lb-Ek for ipv6@optimus.ietf.org; Sun, 04 Jan 2004 00:07:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24502 for ; Sun, 4 Jan 2004 00:07:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ad0U4-0004Pl-00 for ipv6@ietf.org; Sun, 04 Jan 2004 00:07:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ad0Rc-0004Kd-00 for ipv6@ietf.org; Sun, 04 Jan 2004 00:04:57 -0500 Received: from dsl092-066-068.bos1.dsl.speakeasy.net ([66.92.66.68] helo=cyteen.hactrn.net) by ietf-mx with esmtp (Exim 4.12) id 1Ad0OC-0004AQ-00 for ipv6@ietf.org; Sun, 04 Jan 2004 00:01:24 -0500 Received: from hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id B870E489 for ; Sun, 4 Jan 2004 00:00:29 -0500 (EST) To: ipv6@ietf.org Subject: Weekly posting summary for ipv6@ietf.org From: Rob Austein Date: Sun, 04 Jan 2004 00:00:29 -0500 Message-Id: <20040104050029.B870E489@cyteen.hactrn.net> Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Messages | Bytes | Who --------+------+--------+----------+------------------------ 23.08% | 3 | 22.97% | 13449 | narten@us.ibm.com 15.38% | 2 | 17.62% | 10319 | john.loughney@nokia.com 15.38% | 2 | 15.83% | 9267 | mansaxel@sunet.se 7.69% | 1 | 9.07% | 5312 | mark.andrews@isc.org 7.69% | 1 | 8.16% | 4776 | ftemplin@iprg.nokia.com 7.69% | 1 | 7.62% | 4461 | jari.arkko@kolumbus.fi 7.69% | 1 | 6.90% | 4039 | pekkas@netcore.fi 7.69% | 1 | 6.66% | 3899 | sra+ipng@hactrn.net 7.69% | 1 | 5.17% | 3029 | robert@digi-data.com --------+------+--------+----------+------------------------ 100.00% | 13 |100.00% | 58551 | Total Grunchweather Associates provides this automatic summary on an at-whim basis at the request of the IPv6 WG chairs. Your mileage may vary. We decline responsibilities, all shapes, all sizes, all colors. If this script produces broken output, you get to keep both pieces. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Jan 5 11:12:06 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22266 for ; Mon, 5 Jan 2004 11:12:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdXKO-0000mO-AI for ipv6-archive@odin.ietf.org; Mon, 05 Jan 2004 11:11:40 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i05GBe2h002992 for ipv6-archive@odin.ietf.org; Mon, 5 Jan 2004 11:11:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdXKO-0000mB-4v for ipv6-web-archive@optimus.ietf.org; Mon, 05 Jan 2004 11:11:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22248 for ; Mon, 5 Jan 2004 11:11:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdXKG-0000mw-00 for ipv6-web-archive@ietf.org; Mon, 05 Jan 2004 11:11:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdXEn-0000bk-00 for ipv6-web-archive@ietf.org; Mon, 05 Jan 2004 11:05:54 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AdXAS-0000SU-00 for ipv6-web-archive@ietf.org; Mon, 05 Jan 2004 11:01:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdX9A-0008L4-7U; Mon, 05 Jan 2004 11:00:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdX8N-0008Ii-7R for ipv6@optimus.ietf.org; Mon, 05 Jan 2004 10:59:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22022 for ; Mon, 5 Jan 2004 10:59:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdX8K-0000Nd-00 for ipv6@ietf.org; Mon, 05 Jan 2004 10:59:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdX6Q-0000HB-00 for ipv6@ietf.org; Mon, 05 Jan 2004 10:57:15 -0500 Received: from mtagate1.de.ibm.com ([195.212.29.150]) by ietf-mx with esmtp (Exim 4.12) id 1AdX4a-00005S-00 for ipv6@ietf.org; Mon, 05 Jan 2004 10:55:20 -0500 Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196]) by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id i05FsnpS074846 for ; Mon, 5 Jan 2004 15:54:49 GMT Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by d12relay02.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i05Fsmkl198680 for ; Mon, 5 Jan 2004 16:54:48 +0100 Received: from zurich.ibm.com (gsine08.us.sine.ibm.com [9.14.6.48]) by collon.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with SMTP id QAA45508 for ; Mon, 5 Jan 2004 16:54:46 +0100 Message-ID: <3FF98884.D53ECEAF@zurich.ibm.com> Date: Mon, 05 Jan 2004 16:53:40 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: comments on draft-ietf-ipv6-addr-arch-v4-00.txt References: <3FDA9143.8080408@ieee.org> <20031215072640.07E70A0@coconut.itojun.org> <3FDEE34B.E36C19B9@zurich.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit JINMEI Tatuya / 神明達哉 wrote: > > >>>>> On Tue, 16 Dec 2003 11:49:47 +0100, > >>>>> Brian E Carpenter said: > > >> textual representation > >> 2.2 (1) has to state how many digits are permitted as "x" > >> (one component between colon). my personal preference is that > >> "x" has to be 1 to 4 digits (5 digits or more is invalid). > > > I think an informative reference to draft-main-ipaddr-text-rep-00.txt > > is needed. > > In Minneapolis, I made a similar comment and Bob said the reference > from addr-arch to ipaddr-text is not necessary (see > http://www.ietf.org/proceedings/03nov/minutes/ipv6.htm and search for > "ABNF") I understood he was saying we should not have a *normative* reference, because that would block the document. An *informative* reference to an I-D is OK, because the RFC Editor can publish it as a "work in progress" reference. Apart from that we seem to agree! Brian > > I myself does not have a particular opinion, but would like to see a > consensus. I'm currently revising the scoping architecture draft, and > the consensus might affect the references section there, too. > > > I agree that the limit should be 4 digits (optionally including > > leading zeros) and the draft-main- syntax specifies that. > > Regarding this part, I agree. It should also be noted that we had the > same discussion in this April to June (at the ipngwg ML with the > subject "IPv6 Address validation"). Unfortunately, we did not reach a > consensus at that time as far as I can see. It's nice if we can make > it this time. > > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center, Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM NEW ADDRESS PLEASE UPDATE ADDRESS BOOK -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Jan 5 20:32:15 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17336 for ; Mon, 5 Jan 2004 20:32:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Adg4R-0000So-99 for ipv6-archive@odin.ietf.org; Mon, 05 Jan 2004 20:31:47 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i061VlMo001782 for ipv6-archive@odin.ietf.org; Mon, 5 Jan 2004 20:31:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Adg4R-0000Sf-3l for ipv6-web-archive@optimus.ietf.org; Mon, 05 Jan 2004 20:31:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17319 for ; Mon, 5 Jan 2004 20:31:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Adg4O-0000Kt-00 for ipv6-web-archive@ietf.org; Mon, 05 Jan 2004 20:31:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Adg2h-0000Ec-00 for ipv6-web-archive@ietf.org; Mon, 05 Jan 2004 20:29:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Adg1N-00006u-00 for ipv6-web-archive@ietf.org; Mon, 05 Jan 2004 20:28:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Adg0o-00005t-Ax; Mon, 05 Jan 2004 20:28:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Adg0S-0008WC-RS for ipv6@optimus.ietf.org; Mon, 05 Jan 2004 20:27:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17101 for ; Mon, 5 Jan 2004 20:27:38 -0500 (EST) From: Mukesh.Gupta@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Adg0Q-00003k-00 for ipv6@ietf.org; Mon, 05 Jan 2004 20:27:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdfyY-0007lY-00 for ipv6@ietf.org; Mon, 05 Jan 2004 20:25:43 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1Adfy0-0007ea-00 for ipv6@ietf.org; Mon, 05 Jan 2004 20:25:08 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i061P8426593 for ; Tue, 6 Jan 2004 03:25:08 +0200 (EET) Received: from daebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 6 Jan 2004 03:25:07 +0200 Received: from daebe009.NOE.Nokia.com ([10.241.35.109]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 5 Jan 2004 19:25:03 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: draft-ietf-ipngwg-icmp-v3-02.txt: Rate Limiting Methods Date: Mon, 5 Jan 2004 19:25:03 -0600 Message-ID: <8D260779A766FB4A9C1739A476F84FA42ABE4C@daebe009.americas.nokia.com> Thread-Topic: draft-ietf-ipngwg-icmp-v3-02.txt: Rate Limiting Methods Thread-Index: AcPT8+l5JnfRkwZCRrGkdbG78OVrDw== To: X-OriginalArrivalTime: 06 Jan 2004 01:25:03.0317 (UTC) FILETIME=[E8D32050:01C3D3F3] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi All, I have taken the responsibility of being the editor for the draft draft-ietf-ipngwg-icmp-v3-02.txt and I am trying to address the issues raised by Thomas. One of the issues raised was about rate limiting methods suggested by the draft. The draft suggests Timer-based, Bandwidth-based and Token-bucket based methods for limiting the rate of the ICMP messages. After going through the discussion about this in the archive and thinking about this a little bit, I propose that we=20 remove the Timer-based and Bandwidth-based methods and just=20 keep the Token-bucket based method in the draft. (look at the arguments at the end of this mail) I would like to hear from people who would like to keep the Timer-based and Bandwidth-based methods with logical reasons. Regards Mukesh PS: Here are the snippets from the archive just to refresh everyone. Thomas Narten: =3D=3D=3D=3D=3D=3D=3D=3D=3D T=3D 0.5 seems fairly high. Why not .1 or .01 (on today's links). It might also be useful to point out that having too much rate limiting (in routers) causes problems for traceroute, since this has been experienced in practice. Indeed, if routers rate limit to one message every .5 seconds, today's traceroute would seem to become unusable in practice. Indeed, even at .1 seconds, traceroute won't hardly work anymore. I.e., the first probe will get trigger an ICMP error, the second one (some 20-30 ms later) will not, due to rate limiting, etc. Would it be better to move away completely from fixed time intervals and just say as a percentage of the link traffic? at least in the case of routers? =3D=3D=3D=3D=3D=3D=3D=3D=3D Pekka Savola: =3D=3D=3D=3D=3D=3D=3D=3D=3D Well, I brought up the issue with traceroute when I noticed some major=20 router vendors implemented timer-based mechanisms, and proposed the=20 token-bucket mechanism (which is used quite often). Personally, I'm a bit unsatisfied how the examples are portrayed; IMO,=20 timer-based should definitely go away, be put in last, huge disclaimers=20 printed or whatever. Bandwidth-based does not really scale: same implementation could be used = over 64kbit/s or 10Gbit/s links. What's the percentage there? Assuming = sending ICMP errors require processor cycles, the latter might still use = up too much CPU even with 0.01% ;-)=20 Also personally, token bucket is IMO the only sensible way to handle = this. =3D=3D=3D=3D=3D=3D=3D=3D=3D Robert Elz: =3D=3D=3D=3D=3D=3D=3D=3D=3D It should be revised, but should be specified as token bucket type specifications - that is, it should be possible to send a burst of ICMPs if they're needed, just as long as the long term rate doesn't get above N (N can be pkts/sec, or percentage of packets processed). The link traffic percentage model (alone) breaks down if there has been no traffic (N% of 0 is 0, no matter what N is). Make all rate limits be specified with a rate/second (and 2/sec, or = T=3D0.5) as a nice conservative default (just default) I can handle, but with a burst count of about 20 (as dedfault) (10 seconds with none, and 20 can be sent very quickly again). =3D=3D=3D=3D=3D=3D=3D=3D=3D Francis Dupont: =3D=3D=3D=3D=3D=3D=3D=3D=3D I agree because T should be in milliseconds (f.1) and is against back-to-back erroneous packets. I propose 20ms (50Hz). =3D=3D=3D=3D=3D=3D=3D=3D=3D -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Jan 6 03:42:10 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10811 for ; Tue, 6 Jan 2004 03:42:10 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdmmT-0008Gl-Im for ipv6-archive@odin.ietf.org; Tue, 06 Jan 2004 03:41:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i068ffGh031788 for ipv6-archive@odin.ietf.org; Tue, 6 Jan 2004 03:41:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdmmT-0008Gd-8n for ipv6-web-archive@optimus.ietf.org; Tue, 06 Jan 2004 03:41:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10780 for ; Tue, 6 Jan 2004 03:41:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdmmQ-000174-00 for ipv6-web-archive@ietf.org; Tue, 06 Jan 2004 03:41:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdmkV-00012f-00 for ipv6-web-archive@ietf.org; Tue, 06 Jan 2004 03:39:40 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AdmjU-0000z2-00 for ipv6-web-archive@ietf.org; Tue, 06 Jan 2004 03:38:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Admiy-0007mp-LW; Tue, 06 Jan 2004 03:38:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdmiV-0007hT-CJ for ipv6@optimus.ietf.org; Tue, 06 Jan 2004 03:37:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10686 for ; Tue, 6 Jan 2004 03:37:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdmiS-0000xM-00 for ipv6@ietf.org; Tue, 06 Jan 2004 03:37:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Admgf-0000uM-00 for ipv6@ietf.org; Tue, 06 Jan 2004 03:35:41 -0500 Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx with esmtp (Exim 4.12) id 1AdmfX-0000rW-00 for ipv6@ietf.org; Tue, 06 Jan 2004 03:34:31 -0500 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id i068XvG20674; Tue, 6 Jan 2004 09:33:57 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i068XvSj025817; Tue, 6 Jan 2004 09:33:57 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200401060833.i068XvSj025817@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Mukesh.Gupta@nokia.com cc: ipv6@ietf.org Subject: Re: draft-ietf-ipngwg-icmp-v3-02.txt: Rate Limiting Methods In-reply-to: Your message of Mon, 05 Jan 2004 19:25:03 CST. <8D260779A766FB4A9C1739A476F84FA42ABE4C@daebe009.americas.nokia.com> Date: Tue, 06 Jan 2004 09:33:57 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 In your previous mail you wrote: I would like to hear from people who would like to keep the Timer-based and Bandwidth-based methods with logical reasons. => Even if Token-based is the best method it can be a bit expensive to implement (code size and memory requirements) on very small devices so I am not convinced we should remove simpler methods... IMHO the Timer-based method with proper parameters (i.e., one ICMP per tick with a 50Hz clock) should be kept. Note that very small devices are not router in general (and never core routers, cf traceroute concerns). Regards Francis.Dupont@enst-bretagne.fr PS: this topics seems more a v6ops one, doesn't it? -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Jan 6 04:28:13 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12026 for ; Tue, 6 Jan 2004 04:28:13 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdnV3-000274-P8 for ipv6-archive@odin.ietf.org; Tue, 06 Jan 2004 04:27:46 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i069RjnK008115 for ipv6-archive@odin.ietf.org; Tue, 6 Jan 2004 04:27:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdnV3-00026l-9A for ipv6-web-archive@optimus.ietf.org; Tue, 06 Jan 2004 04:27:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11976 for ; Tue, 6 Jan 2004 04:27:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdnV0-0002kq-00 for ipv6-web-archive@ietf.org; Tue, 06 Jan 2004 04:27:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdnTA-0002em-00 for ipv6-web-archive@ietf.org; Tue, 06 Jan 2004 04:25:48 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AdnRk-0002Zf-00 for ipv6-web-archive@ietf.org; Tue, 06 Jan 2004 04:24:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdnRT-0001iA-5D; Tue, 06 Jan 2004 04:24:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdnR1-0001eo-Te for ipv6@optimus.ietf.org; Tue, 06 Jan 2004 04:23:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11820 for ; Tue, 6 Jan 2004 04:23:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdnQz-0002V4-00 for ipv6@ietf.org; Tue, 06 Jan 2004 04:23:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdnPu-0002Q4-00 for ipv6@ietf.org; Tue, 06 Jan 2004 04:22:27 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdnMa-0002Ht-00 for ipv6@ietf.org; Tue, 06 Jan 2004 04:19:00 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i069Hlp06783; Tue, 6 Jan 2004 11:17:47 +0200 Date: Tue, 6 Jan 2004 11:17:47 +0200 (EET) From: Pekka Savola To: Francis Dupont cc: Mukesh.Gupta@nokia.com, Subject: Re: draft-ietf-ipngwg-icmp-v3-02.txt: Rate Limiting Methods In-Reply-To: <200401060833.i068XvSj025817@givry.rennes.enst-bretagne.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 On Tue, 6 Jan 2004, Francis Dupont wrote: > In your previous mail you wrote: > > I would like to hear from people who would like to keep the > Timer-based and Bandwidth-based methods with logical reasons. > > => Even if Token-based is the best method it can be a bit expensive > to implement (code size and memory requirements) on very small devices > so I am not convinced we should remove simpler methods... IMHO the > Timer-based method with proper parameters (i.e., one ICMP per tick > with a 50Hz clock) should be kept. Note that very small devices are > not router in general (and never core routers, cf traceroute concerns). I have to disagree here. Even if a very small device was not a router, it would have to respond to traceroutes etc., even though with lower probability that multiple ones would be happening simultaneously. But still, if e.g. a "dumb" host is connected to a network, and someone close by (e.g. 3-4 hops) sends a traceroute, the packets could be sent e.g. 1 ms apart. Any timer-based mechanism is inappropriate, unless it has some kind of "burst allowance", which was what Robert Elz also argued for -- but that's token-based filter just with different words. So, I'd say, keep only token-based filter as an example, but if it seems important one could explain, e.g. in an appendix, why timer/bandwidth -based mechanisms aren't sufficient on their own. In any case, I believe it's important to document that being able to send the packets in burst is an important characteristic of the filter. > PS: this topics seems more a v6ops one, doesn't it? The operational requirements (traceroute, etc.), yes, but this is being revised at this WG so it should probably be OK.. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Jan 6 05:26:19 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13450 for ; Tue, 6 Jan 2004 05:26:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdoPI-00047j-KP for ipv6-archive@odin.ietf.org; Tue, 06 Jan 2004 05:25:52 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i06APqmS015852 for ipv6-archive@odin.ietf.org; Tue, 6 Jan 2004 05:25:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdoPH-00047b-Vd for ipv6-web-archive@optimus.ietf.org; Tue, 06 Jan 2004 05:25:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13405 for ; Tue, 6 Jan 2004 05:25:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdoPE-00056A-00 for ipv6-web-archive@ietf.org; Tue, 06 Jan 2004 05:25:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdoNQ-0004wq-00 for ipv6-web-archive@ietf.org; Tue, 06 Jan 2004 05:23:58 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AdoKe-0004lP-00 for ipv6-web-archive@ietf.org; Tue, 06 Jan 2004 05:21:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdoJk-0003lb-E8; Tue, 06 Jan 2004 05:20:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdoJ5-0003kW-Ji for ipv6@optimus.ietf.org; Tue, 06 Jan 2004 05:19:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13207 for ; Tue, 6 Jan 2004 05:19:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdoIx-0004ga-00 for ipv6@ietf.org; Tue, 06 Jan 2004 05:19:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdoBZ-0004Vn-00 for ipv6@ietf.org; Tue, 06 Jan 2004 05:11:41 -0500 Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx with esmtp (Exim 4.12) id 1Ado9V-0004LS-00 for ipv6@ietf.org; Tue, 06 Jan 2004 05:09:33 -0500 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id i06A8ZG25789; Tue, 6 Jan 2004 11:08:35 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i06A8ZSj026203; Tue, 6 Jan 2004 11:08:35 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200401061008.i06A8ZSj026203@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Pekka Savola cc: Mukesh.Gupta@nokia.com, ipv6@ietf.org Subject: Re: draft-ietf-ipngwg-icmp-v3-02.txt: Rate Limiting Methods In-reply-to: Your message of Tue, 06 Jan 2004 11:17:47 +0200. Date: Tue, 06 Jan 2004 11:08:35 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 In your previous mail you wrote: On Tue, 6 Jan 2004, Francis Dupont wrote: > In your previous mail you wrote: > > I would like to hear from people who would like to keep the > Timer-based and Bandwidth-based methods with logical reasons. > > => Even if Token-based is the best method it can be a bit expensive > to implement (code size and memory requirements) on very small devices > so I am not convinced we should remove simpler methods... IMHO the > Timer-based method with proper parameters (i.e., one ICMP per tick > with a 50Hz clock) should be kept. Note that very small devices are > not router in general (and never core routers, cf traceroute concerns). I have to disagree here. Even if a very small device was not a router, it would have to respond to traceroutes etc., even though with lower probability that multiple ones would be happening simultaneously. But still, if e.g. a "dumb" host is connected to a network, and someone close by (e.g. 3-4 hops) sends a traceroute, the packets could be sent e.g. 1 ms apart. Any timer-based mechanism is inappropriate, unless it has some kind of "burst allowance", which was what Robert Elz also argued for -- but that's token-based filter just with different words. => it seems you are confusing ping and traceroute: even a (too) stupid rate-limiting device is never a problem on the target of a traceroute because when one'd like to test reachability one uses ping (with the standard one second delay between probes). So, I'd say, keep only token-based filter as an example, but if it seems important one could explain, e.g. in an appendix, why timer/bandwidth -based mechanisms aren't sufficient on their own. In any case, I believe it's important to document that being able to send the packets in burst is an important characteristic of the filter. => IMHO traceroute is not the good argument here. > PS: this topics seems more a v6ops one, doesn't it? The operational requirements (traceroute, etc.), yes, but this is being revised at this WG so it should probably be OK.. => this is an operational issue so the requirements should come from the v6ops WG and then we could see if token-based method should be made mandatory. Because today the only argument we have is for rate-limitation using any reasonable method. Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Jan 6 06:32:16 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14937 for ; Tue, 6 Jan 2004 06:32:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdpR8-0006Go-0L for ipv6-archive@odin.ietf.org; Tue, 06 Jan 2004 06:31:50 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i06BVn6K024099 for ipv6-archive@odin.ietf.org; Tue, 6 Jan 2004 06:31:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdpR7-0006Ga-PP for ipv6-web-archive@optimus.ietf.org; Tue, 06 Jan 2004 06:31:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14893 for ; Tue, 6 Jan 2004 06:31:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdpR3-0007X3-00 for ipv6-web-archive@ietf.org; Tue, 06 Jan 2004 06:31:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdpPL-0007RD-00 for ipv6-web-archive@ietf.org; Tue, 06 Jan 2004 06:29:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AdpNs-0007LC-00 for ipv6-web-archive@ietf.org; Tue, 06 Jan 2004 06:28:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdpNS-0005tw-Iw; Tue, 06 Jan 2004 06:28:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdpN4-0005rf-EL for ipv6@optimus.ietf.org; Tue, 06 Jan 2004 06:27:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14693 for ; Tue, 6 Jan 2004 06:27:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdpN0-0007Fy-00 for ipv6@ietf.org; Tue, 06 Jan 2004 06:27:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdpIL-00076D-00 for ipv6@ietf.org; Tue, 06 Jan 2004 06:22:46 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdpGH-0006xw-00 for ipv6@ietf.org; Tue, 06 Jan 2004 06:20:37 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i06BJQT07685; Tue, 6 Jan 2004 13:19:26 +0200 Date: Tue, 6 Jan 2004 13:19:26 +0200 (EET) From: Pekka Savola To: Francis Dupont cc: Mukesh.Gupta@nokia.com, Subject: Re: draft-ietf-ipngwg-icmp-v3-02.txt: Rate Limiting Methods In-Reply-To: <200401061008.i06A8ZSj026203@givry.rennes.enst-bretagne.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 On Tue, 6 Jan 2004, Francis Dupont wrote: > I have to disagree here. Even if a very small device was not a > router, it would have to respond to traceroutes etc., even though with > lower probability that multiple ones would be happening > simultaneously. But still, if e.g. a "dumb" host is connected to a > network, and someone close by (e.g. 3-4 hops) sends a traceroute, the > packets could be sent e.g. 1 ms apart. Any timer-based mechanism is > inappropriate, unless it has some kind of "burst allowance", which was > what Robert Elz also argued for -- but that's token-based filter just > with different words. > > => it seems you are confusing ping and traceroute: even a (too) stupid > rate-limiting device is never a problem on the target of a traceroute > because when one'd like to test reachability one uses ping (with the > standard one second delay between probes). Even the target of the traceroute replies with ICMP unreachables. 13:16:09.430527 192.88.99.1 > 80.186.174.139: 2001:670:86:3001::1.58692 > 2002:50ba:ae8b::1.33434: udp 16 [hlim 1] 13:16:09.430806 80.186.174.139 > 192.88.99.1: 2002:50ba:ae8b::1 > 2001:670:86:3001::1: icmp6: 2002:50ba:ae8b::1 udp port 33434 unreachable 13:16:09.464535 192.88.99.1 > 80.186.174.139: 2001:670:86:3001::1.58692 > 2002:50ba:ae8b::1.33434: udp 16 [hlim 1] 13:16:09.464726 80.186.174.139 > 192.88.99.1: 2002:50ba:ae8b::1 > 2001:670:86:3001::1: icmp6: 2002:50ba:ae8b::1 udp port 33434 unreachable 13:16:09.494352 192.88.99.1 > 80.186.174.139: 2001:670:86:3001::1.58692 > 2002:50ba:ae8b::1.33434: udp 16 [hlim 1] 13:16:09.494545 80.186.174.139 > 192.88.99.1: 2002:50ba:ae8b::1 > 2001:670:86:3001::1: icmp6: 2002:50ba:ae8b::1 udp port 33434 unreachable So, if such a dumb box is the target of traceroute, an "asterisk" does appear if the limiting is not implemented properly, i.e. there is no allowance for the bursts. > => this is an operational issue so the requirements should come from > the v6ops WG and then we could see if token-based method should be made > mandatory. Because today the only argument we have is for rate-limitation > using any reasonable method. If it's not enough that at least one member of v6ops says traceroute is a must, and rate-limiting must take that into an account, one could take the thread there explicitly.. depending on how formally that would be done it might cause none or a lot of delay. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Jan 6 10:46:08 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22786 for ; Tue, 6 Jan 2004 10:46:07 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdtOm-0006NP-Md for ipv6-archive@odin.ietf.org; Tue, 06 Jan 2004 10:45:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i06FjeVY024507 for ipv6-archive@odin.ietf.org; Tue, 6 Jan 2004 10:45:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdtOm-0006NC-Fe for ipv6-web-archive@optimus.ietf.org; Tue, 06 Jan 2004 10:45:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22773 for ; Tue, 6 Jan 2004 10:45:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdtOk-0002QN-00 for ipv6-web-archive@ietf.org; Tue, 06 Jan 2004 10:45:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdtMp-0002O6-00 for ipv6-web-archive@ietf.org; Tue, 06 Jan 2004 10:43:40 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AdtM0-0002ME-00 for ipv6-web-archive@ietf.org; Tue, 06 Jan 2004 10:42:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdtLF-00064h-Bk; Tue, 06 Jan 2004 10:42:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdtKz-000641-VX for ipv6@optimus.ietf.org; Tue, 06 Jan 2004 10:41:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22694 for ; Tue, 6 Jan 2004 10:41:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdtKx-0002LQ-00 for ipv6@ietf.org; Tue, 06 Jan 2004 10:41:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdtJ5-0002Ik-00 for ipv6@ietf.org; Tue, 06 Jan 2004 10:39:47 -0500 Received: from web80508.mail.yahoo.com ([66.218.79.78]) by ietf-mx with smtp (Exim 4.12) id 1AdtIo-0002Fo-00 for ipv6@ietf.org; Tue, 06 Jan 2004 10:39:30 -0500 Message-ID: <20040106153859.20950.qmail@web80508.mail.yahoo.com> Received: from [63.197.18.101] by web80508.mail.yahoo.com via HTTP; Tue, 06 Jan 2004 07:38:59 PST Date: Tue, 6 Jan 2004 07:38:59 -0800 (PST) From: Fred Templin Subject: Re: draft-ietf-ipngwg-icmp-v3-02.txt: Rate Limiting Methods To: Pekka Savola , Francis Dupont Cc: Mukesh.Gupta@nokia.com, ipv6@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-620113764-1073403539=:19453" Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.9 required=5.0 tests=FROM_ENDS_IN_NUMS,HTML_MESSAGE, MAILTO_TO_SPAM_ADDR autolearn=no version=2.60 --0-620113764-1073403539=:19453 Content-Type: text/plain; charset=us-ascii Pekka, Asterisks already appear all the time using 'traceroute'. That is why three responses are solicited from each hop and the process proceeds to the next hop even if only one response is received. (Indeed, many of the traceroutes I have seen will "knock three times" repeatedly when a non-responsive hop is encountered.) I agree that the traceroute example is a weak one, and not sufficient reason to exclude valid implementation alternatives. Fred osprey67@yahoo.com Pekka Savola wrote: So, if such a dumb box is the target of traceroute, an "asterisk" does appear if the limiting is not implemented properly, i.e. there is no allowance for the bursts. --0-620113764-1073403539=:19453 Content-Type: text/html; charset=us-ascii
Pekka,
 
Asterisks already appear all the time using 'traceroute'. That is why
three responses are solicited from each hop and the process proceeds
to the next hop even if only one response is received. (Indeed, many of
the traceroutes I have seen will "knock three times" repeatedly when a
non-responsive hop is encountered.)
 
I agree that the traceroute example is a weak one, and not sufficient
reason to exclude valid implementation alternatives.
 
Fred
osprey67@yahoo.com

Pekka Savola <pekkas@netcore.fi> wrote:
So, if such a dumb box is the target of traceroute, an "asterisk" does
appear if the limiting is not implemented properly, i.e. there is no
allowance for the bursts.
--0-620113764-1073403539=:19453-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Jan 6 12:52:17 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26919 for ; Tue, 6 Jan 2004 12:52:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdvMs-0002Qr-8U for ipv6-archive@odin.ietf.org; Tue, 06 Jan 2004 12:51:50 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i06Hpogm009343 for ipv6-archive@odin.ietf.org; Tue, 6 Jan 2004 12:51:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdvMs-0002Qc-0S for ipv6-web-archive@optimus.ietf.org; Tue, 06 Jan 2004 12:51:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26913 for ; Tue, 6 Jan 2004 12:51:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdvMq-0007jh-00 for ipv6-web-archive@ietf.org; Tue, 06 Jan 2004 12:51:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdvKv-0007g1-00 for ipv6-web-archive@ietf.org; Tue, 06 Jan 2004 12:49:50 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AdvKe-0007ck-00 for ipv6-web-archive@ietf.org; Tue, 06 Jan 2004 12:49:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdvJC-00023y-7E; Tue, 06 Jan 2004 12:48:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdvJ4-00023Z-Ms for ipv6@optimus.ietf.org; Tue, 06 Jan 2004 12:47:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26699 for ; Tue, 6 Jan 2004 12:47:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdvJ2-0007aP-00 for ipv6@ietf.org; Tue, 06 Jan 2004 12:47:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdvHL-0007Ty-00 for ipv6@ietf.org; Tue, 06 Jan 2004 12:46:08 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdvFX-0007J9-00 for ipv6@ietf.org; Tue, 06 Jan 2004 12:44:15 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i06HhXQ11668; Tue, 6 Jan 2004 19:43:33 +0200 Date: Tue, 6 Jan 2004 19:43:33 +0200 (EET) From: Pekka Savola To: Fred Templin cc: Francis Dupont , , Subject: Re: draft-ietf-ipngwg-icmp-v3-02.txt: Rate Limiting Methods In-Reply-To: <20040106153859.20950.qmail@web80508.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 On Tue, 6 Jan 2004, Fred Templin wrote: > Asterisks already appear all the time using 'traceroute'. That is why > three responses are solicited from each hop and the process proceeds > to the next hop even if only one response is received. (Indeed, many of > the traceroutes I have seen will "knock three times" repeatedly when a > non-responsive hop is encountered.) Right. But in my opinion, we want to optimize for the case that we don't have to fall back to the timeouts unnecessarily. Multiple seconds' delay at each misbehaving hop is inappropriate. > I agree that the traceroute example is a weak one, and not sufficient > reason to exclude valid implementation alternatives. We'll just have to disagree on this. Internet traffic is characteristically rather bursty. The rate-limitng functions have to be able to deal with that. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Jan 6 13:13:06 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27409 for ; Tue, 6 Jan 2004 13:13:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Advh2-0003G1-Fm for ipv6-archive@odin.ietf.org; Tue, 06 Jan 2004 13:12:40 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i06ICeR7012515 for ipv6-archive@odin.ietf.org; Tue, 6 Jan 2004 13:12:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Advh2-0003Fm-Ad for ipv6-web-archive@optimus.ietf.org; Tue, 06 Jan 2004 13:12:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27403 for ; Tue, 6 Jan 2004 13:12:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Advgv-0000iL-00 for ipv6-web-archive@ietf.org; Tue, 06 Jan 2004 13:12:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdveQ-0000Zi-00 for ipv6-web-archive@ietf.org; Tue, 06 Jan 2004 13:09:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AdvaB-0000ND-00 for ipv6-web-archive@ietf.org; Tue, 06 Jan 2004 13:05:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdvZf-0002an-FE; Tue, 06 Jan 2004 13:05:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdvZT-0002a4-Ot for ipv6@optimus.ietf.org; Tue, 06 Jan 2004 13:04:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27253 for ; Tue, 6 Jan 2004 13:04:42 -0500 (EST) From: Mukesh.Gupta@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdvZH-0000Km-00 for ipv6@ietf.org; Tue, 06 Jan 2004 13:04:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdvUe-0000Fg-00 for ipv6@ietf.org; Tue, 06 Jan 2004 12:59:52 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AdvTs-0000Bu-00 for ipv6@ietf.org; Tue, 06 Jan 2004 12:59:04 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i06Hx2602767 for ; Tue, 6 Jan 2004 19:59:02 +0200 (EET) Received: from daebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 6 Jan 2004 19:59:02 +0200 Received: from daebe009.NOE.Nokia.com ([10.241.35.109]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 6 Jan 2004 09:58:57 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: draft-ietf-ipngwg-icmp-v3-02.txt: Rate Limiting Methods Date: Tue, 6 Jan 2004 11:58:56 -0600 Message-ID: <8D260779A766FB4A9C1739A476F84FA42ABE4E@daebe009.americas.nokia.com> Thread-Topic: draft-ietf-ipngwg-icmp-v3-02.txt: Rate Limiting Methods Thread-Index: AcPUfKLFpXRO8bf3Tt+cUSX4R1wdqgAANp9A To: , Cc: , X-OriginalArrivalTime: 06 Jan 2004 17:58:57.0679 (UTC) FILETIME=[C1ACA1F0:01C3D47E] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable If we decide to keep the Timer-based method, another problem is to decide the value of T (not more than one icmp to a given source every T milliseconds). 1 ms might be overwhelming for a 64 kpbs link and 100 ms will be over-restricting for 10=20 gbps link. What about we keep the Timer-based method, discuss the=20 advantages and disadvantages and suggest keeping the value of T configurable per link so that the administrator can decide the correct value of T based on the bandwidth of the link. Do we all agree to remove the Bandwidth-based method ?? Regards Mukesh > -----Original Message----- > From: ext Pekka Savola [mailto:pekkas@netcore.fi] > Sent: Tuesday, January 06, 2004 9:44 AM > To: Fred Templin > Cc: Francis Dupont; Gupta Mukesh (Nokia-NET/MtView); ipv6@ietf.org > Subject: Re: draft-ietf-ipngwg-icmp-v3-02.txt: Rate Limiting Methods=20 >=20 >=20 > On Tue, 6 Jan 2004, Fred Templin wrote: > > Asterisks already appear all the time using 'traceroute'.=20 > That is why > > three responses are solicited from each hop and the process proceeds > > to the next hop even if only one response is received.=20 > (Indeed, many of > > the traceroutes I have seen will "knock three times"=20 > repeatedly when a > > non-responsive hop is encountered.) >=20 > Right. But in my opinion, we want to optimize for the case that we=20 > don't have to fall back to the timeouts unnecessarily. Multiple=20 > seconds' delay at each misbehaving hop is inappropriate. > =20 > > I agree that the traceroute example is a weak one, and not=20 > sufficient > > reason to exclude valid implementation alternatives. >=20 > We'll just have to disagree on this. Internet traffic is > characteristically rather bursty. The rate-limitng functions have to > be able to deal with that. >=20 > --=20 > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings >=20 >=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Jan 6 14:36:29 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00226 for ; Tue, 6 Jan 2004 14:36:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Adwzi-00061z-1x for ipv6-archive@odin.ietf.org; Tue, 06 Jan 2004 14:36:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i06Ja29L023183 for ipv6-archive@odin.ietf.org; Tue, 6 Jan 2004 14:36:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Adwzh-00061q-R2 for ipv6-web-archive@optimus.ietf.org; Tue, 06 Jan 2004 14:36:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00220 for ; Tue, 6 Jan 2004 14:35:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Adwzf-00059a-00 for ipv6-web-archive@ietf.org; Tue, 06 Jan 2004 14:35:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Adwxl-00054b-00 for ipv6-web-archive@ietf.org; Tue, 06 Jan 2004 14:34:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AdwxA-00050e-00 for ipv6-web-archive@ietf.org; Tue, 06 Jan 2004 14:33:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Adwwo-0005iB-3z; Tue, 06 Jan 2004 14:33:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Adww9-0005h9-4q for ipv6@optimus.ietf.org; Tue, 06 Jan 2004 14:32:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00004 for ; Tue, 6 Jan 2004 14:32:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Adww6-0004yw-00 for ipv6@ietf.org; Tue, 06 Jan 2004 14:32:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdwuN-0004sz-00 for ipv6@ietf.org; Tue, 06 Jan 2004 14:30:32 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1Adwt5-0004kc-00 for ipv6@ietf.org; Tue, 06 Jan 2004 14:29:11 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i06JSHM01692; Tue, 6 Jan 2004 11:28:17 -0800 X-mProtect: <200401061928> Nokia Silicon Valley Messaging Protection Received: from ftemplin.iprg.nokia.com (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd30CPPA; Tue, 06 Jan 2004 11:28:16 PST Message-ID: <3FFB0C53.5080903@iprg.nokia.com> Date: Tue, 06 Jan 2004 11:28:19 -0800 From: Fred Templin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mukesh.Gupta@nokia.com CC: pekkas@netcore.fi, osprey67@yahoo.com, Francis.Dupont@enst-bretagne.fr, ipv6@ietf.org Subject: Re: draft-ietf-ipngwg-icmp-v3-02.txt: Rate Limiting Methods References: <8D260779A766FB4A9C1739A476F84FA42ABE4E@daebe009.americas.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Generally speaking, it seems appropriate to exclude implementation alternatives only if they are known to cause operational issues. One case of concern is that of a reflection attack in which an anonymous attacker (A) using a spoofed source address (C) sends a stream of malicious packets to a middle node (B) that would cause B to generate ICMPv6 errors. If B sends the ICMPv6 errors on a high-speed link (e.g., 1Gbps Ethernet), but the victim node C is at the far end of a long, thin link (e.g., 56Kbps modem, GPRS; 1xRTT wireless, etc) A can effectively deny service to C with a relatively low-bandwith stream of malicious packets. Based on the reflection attack case, it seems unlikely to me that any of the rate limiting alternatives in section 2.4(f) can on their own provide sufficient assurance that nodes with low-bandwidth links will be protected from ICMPv6 error message DoS attacks (w/o defeating legitimate mechanisms that rely on ICMPv6 error messages, that is). Therefore, I see no value in seeking exclusion of any of the rate limiting alternatives at this point in time. Instead, the reflection attack case (and perhaps others) suggests that other measures are needed - in particular, it seems to me that authentication of source addresses in received IPv6 packets should be mandatory. Fred ftemplin@iprg.nokia.com Mukesh.Gupta@nokia.com wrote: >If we decide to keep the Timer-based method, another problem >is to decide the value of T (not more than one icmp to a given >source every T milliseconds). 1 ms might be overwhelming for >a 64 kpbs link and 100 ms will be over-restricting for 10 >gbps link. > >What about we keep the Timer-based method, discuss the >advantages and disadvantages and suggest keeping the value >of T configurable per link so that the administrator can >decide the correct value of T based on the bandwidth of the >link. > >Do we all agree to remove the Bandwidth-based method ?? > >Regards >Mukesh > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Jan 6 15:28:14 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02720 for ; Tue, 6 Jan 2004 15:28:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Adxnl-0008HS-Vo for ipv6-archive@odin.ietf.org; Tue, 06 Jan 2004 15:27:45 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i06KRjhw031829 for ipv6-archive@odin.ietf.org; Tue, 6 Jan 2004 15:27:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Adxnl-0008HI-JG for ipv6-web-archive@optimus.ietf.org; Tue, 06 Jan 2004 15:27:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02659 for ; Tue, 6 Jan 2004 15:27:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Adxnk-0006vd-00 for ipv6-web-archive@ietf.org; Tue, 06 Jan 2004 15:27:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Adxlp-0006pX-00 for ipv6-web-archive@ietf.org; Tue, 06 Jan 2004 15:25:46 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Adxke-0006j1-00 for ipv6-web-archive@ietf.org; Tue, 06 Jan 2004 15:24:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Adxk9-0007tI-W9; Tue, 06 Jan 2004 15:24:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdxjJ-0007s3-JB for ipv6@optimus.ietf.org; Tue, 06 Jan 2004 15:23:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02438 for ; Tue, 6 Jan 2004 15:23:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdxjD-0006fT-00 for ipv6@ietf.org; Tue, 06 Jan 2004 15:23:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdxgN-0006Yz-00 for ipv6@ietf.org; Tue, 06 Jan 2004 15:20:08 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdxaK-0006Ni-00 for ipv6@ietf.org; Tue, 06 Jan 2004 15:13:52 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i06KCcM13661; Tue, 6 Jan 2004 22:12:38 +0200 Date: Tue, 6 Jan 2004 22:12:38 +0200 (EET) From: Pekka Savola To: Fred Templin cc: Mukesh.Gupta@nokia.com, , , Subject: Re: draft-ietf-ipngwg-icmp-v3-02.txt: Rate Limiting Methods In-Reply-To: <3FFB0C53.5080903@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 On Tue, 6 Jan 2004, Fred Templin wrote: > Generally speaking, it seems appropriate to exclude implementation > alternatives only if they are known to cause operational issues. [...] Traceroute not working (without unnecessary delays) is a serious operational issue, IMHO. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Jan 6 16:44:23 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05331 for ; Tue, 6 Jan 2004 16:44:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdyzT-0003QC-Kn for ipv6-archive@odin.ietf.org; Tue, 06 Jan 2004 16:43:55 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i06LhtgS013149 for ipv6-archive@odin.ietf.org; Tue, 6 Jan 2004 16:43:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdyzT-0003Pv-2K for ipv6-web-archive@optimus.ietf.org; Tue, 06 Jan 2004 16:43:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05317 for ; Tue, 6 Jan 2004 16:43:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdyzR-00027v-00 for ipv6-web-archive@ietf.org; Tue, 06 Jan 2004 16:43:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Adyxi-00023v-00 for ipv6-web-archive@ietf.org; Tue, 06 Jan 2004 16:42:07 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AdywB-0001xg-00 for ipv6-web-archive@ietf.org; Tue, 06 Jan 2004 16:40:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Adyvn-00034Z-NG; Tue, 06 Jan 2004 16:40:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdyvT-000322-4D for ipv6@optimus.ietf.org; Tue, 06 Jan 2004 16:39:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05121 for ; Tue, 6 Jan 2004 16:39:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdyvR-0001s3-00 for ipv6@ietf.org; Tue, 06 Jan 2004 16:39:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Adytb-0001no-00 for ipv6@ietf.org; Tue, 06 Jan 2004 16:37:51 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1Adyrq-0001gt-00 for ipv6@ietf.org; Tue, 06 Jan 2004 16:36:02 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i06LZBN26872; Tue, 6 Jan 2004 13:35:11 -0800 X-mProtect: <200401062135> Nokia Silicon Valley Messaging Protection Received: from ftemplin.iprg.nokia.com (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdx1HFb1; Tue, 06 Jan 2004 13:35:10 PST Message-ID: <3FFB2A12.50306@iprg.nokia.com> Date: Tue, 06 Jan 2004 13:35:14 -0800 From: Fred Templin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola CC: Mukesh.Gupta@nokia.com, osprey67@yahoo.com, Francis.Dupont@enst-bretagne.fr, ipv6@ietf.org Subject: Re: draft-ietf-ipngwg-icmp-v3-02.txt: Rate Limiting Methods References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Pekka, Pekka Savola wrote: >On Tue, 6 Jan 2004, Fred Templin wrote: > > >>Generally speaking, it seems appropriate to exclude implementation >>alternatives only if they are known to cause operational issues. >> >> >[...] > >Traceroute not working (without unnecessary delays) is a serious >operational issue, IMHO. > I'm not quite as concerned about traceroute as you seem to be, but I do agree that other mechanisms that rely on ICMPv6 might suffer from a poor choice of rate limiting schemes. (Well, OK; traceroute is a useful tool too.) I'll give some consideration to the token-bucket thing; my main concern is that min/max values for the rate-limiting parameters 'B' and 'N' are not currently specified. If reasonable values can be determined, perhaps I will revise my opinion about exclusion of the other schemes. Fred ftemplin@iprg.nokia.com -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Jan 6 21:24:28 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16670 for ; Tue, 6 Jan 2004 21:24:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ae3MX-0006SD-Bp for ipv6-archive@odin.ietf.org; Tue, 06 Jan 2004 21:24:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i072O1L5024803 for ipv6-archive@odin.ietf.org; Tue, 6 Jan 2004 21:24:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ae3MW-0006Rr-W3 for ipv6-web-archive@optimus.ietf.org; Tue, 06 Jan 2004 21:24:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16619 for ; Tue, 6 Jan 2004 21:23:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ae3MU-0006zp-00 for ipv6-web-archive@ietf.org; Tue, 06 Jan 2004 21:23:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ae3Kj-0006ti-00 for ipv6-web-archive@ietf.org; Tue, 06 Jan 2004 21:22:10 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ae3J9-0006oc-00 for ipv6-web-archive@ietf.org; Tue, 06 Jan 2004 21:20:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ae3Ii-00066h-GX; Tue, 06 Jan 2004 21:20:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ae3IU-000657-7f for ipv6@optimus.ietf.org; Tue, 06 Jan 2004 21:19:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16519 for ; Tue, 6 Jan 2004 21:19:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ae3IR-0006lk-00 for ipv6@ietf.org; Tue, 06 Jan 2004 21:19:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ae3Ga-0006iE-00 for ipv6@ietf.org; Tue, 06 Jan 2004 21:17:53 -0500 Received: from smtp.exodus.net ([66.35.230.236]) by ietf-mx with esmtp (Exim 4.12) id 1Ae3FA-0006dy-00 for ipv6@ietf.org; Tue, 06 Jan 2004 21:16:24 -0500 Received: from ms101.mail1.com (ms101.mail1.com [209.1.5.174]) by smtp.exodus.net (8.12.8/8.12.8) with ESMTP id i073trw3000361 for ; Tue, 6 Jan 2004 19:55:53 -0800 Received: from ala-mrwtemp.thingmagic.com (unverified [24.61.30.237]) by accounting.espmail.com (Rockliffe SMTPRA 5.2.5) with ESMTP id ; Tue, 6 Jan 2004 18:15:55 -0800 Message-Id: <5.1.0.14.2.20040106210337.0316d600@ms101.mail1.com> X-Sender: margaret@thingmagic.com@ms101.mail1.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 06 Jan 2004 21:06:21 -0500 To: Mukesh.Gupta@nokia.com From: Margaret Wasserman Subject: Re: draft-ietf-ipngwg-icmp-v3-02.txt: Rate Limiting Methods Cc: In-Reply-To: <8D260779A766FB4A9C1739A476F84FA42ABE4C@daebe009.americas.n okia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Hi Mukesh, >One of the issues raised was about rate limiting methods >suggested by the draft. The draft suggests Timer-based, >Bandwidth-based and Token-bucket based methods for limiting >the rate of the ICMP messages. > >After going through the discussion about this in the archive >and thinking about this a little bit, I propose that we >remove the Timer-based and Bandwidth-based methods and just >keep the Token-bucket based method in the draft. (look at >the arguments at the end of this mail) > >I would like to hear from people who would like to keep the >Timer-based and Bandwidth-based methods with logical reasons. I'm not sure if these are logical reasons, but... I am concerned about making a change that will invalidate any existing ICMPv6 implementations, unless that change is absolutely necessary (e.g. to block a serious security hole or to prevent a significant operational problem). Would it work to state in the new draft that implementations SHOULD implement the Token-bucket method, but MAY implement the other methods? I think that would appropriately encourage implementation of the Token-bucket method without invalidating existing implementations that use one of the others. Thoughts? Margaret -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Jan 7 06:48:31 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05745 for ; Wed, 7 Jan 2004 06:48:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeCAO-0007Rt-Gg for ipv6-archive@odin.ietf.org; Wed, 07 Jan 2004 06:48:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i07Bm4uK028627 for ipv6-archive@odin.ietf.org; Wed, 7 Jan 2004 06:48:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeCAO-0007Re-8X for ipv6-web-archive@optimus.ietf.org; Wed, 07 Jan 2004 06:48:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05559 for ; Wed, 7 Jan 2004 06:47:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeCAK-00056T-00 for ipv6-web-archive@ietf.org; Wed, 07 Jan 2004 06:48:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeC8U-0004t9-00 for ipv6-web-archive@ietf.org; Wed, 07 Jan 2004 06:46:07 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AeC6q-0004pH-01 for ipv6-web-archive@ietf.org; Wed, 07 Jan 2004 06:44:24 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1AeC3n-0001CG-UK for ipv6-web-archive@ietf.org; Wed, 07 Jan 2004 06:41:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeC3a-00070C-WA; Wed, 07 Jan 2004 06:41:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeC2b-0006yT-4g for ipv6@optimus.ietf.org; Wed, 07 Jan 2004 06:40:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05405 for ; Wed, 7 Jan 2004 06:39:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeC2W-0004fv-00 for ipv6@ietf.org; Wed, 07 Jan 2004 06:39:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeC0o-0004e0-00 for ipv6@ietf.org; Wed, 07 Jan 2004 06:38:11 -0500 Received: from uillean.fuaim.com ([206.197.161.140]) by ietf-mx with esmtp (Exim 4.12) id 1AeBzy-0004aC-00 for ipv6@ietf.org; Wed, 07 Jan 2004 06:37:18 -0500 Received: from clairseach.fuaim.com (clairseach.fuaim.com [206.197.161.141]) by uillean.fuaim.com (8.11.6/8.11.6) with ESMTP id i07BamV02543; Wed, 7 Jan 2004 03:36:48 -0800 Received: from innovationslab.net (md-wmnsmd-cuda2-c6a-a-4.chvlva.adelphia.net [68.65.120.4]) (authenticated bits=0) by clairseach.fuaim.com (8.12.8/8.12.8) with ESMTP id i07BirbS014479 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 7 Jan 2004 03:44:57 -0800 Message-ID: <3FFBEF0B.7050105@innovationslab.net> Date: Wed, 07 Jan 2004 06:35:39 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Margaret Wasserman CC: Mukesh.Gupta@nokia.com, ipv6@ietf.org Subject: Re: draft-ietf-ipngwg-icmp-v3-02.txt: Rate Limiting Methods References: <5.1.0.14.2.20040106210337.0316d600@ms101.mail1.com> In-Reply-To: <5.1.0.14.2.20040106210337.0316d600@ms101.mail1.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Margaret Wasserman wrote: > > Hi Mukesh, > >> One of the issues raised was about rate limiting methods >> suggested by the draft. The draft suggests Timer-based, >> Bandwidth-based and Token-bucket based methods for limiting >> the rate of the ICMP messages. >> >> After going through the discussion about this in the archive >> and thinking about this a little bit, I propose that we >> remove the Timer-based and Bandwidth-based methods and just >> keep the Token-bucket based method in the draft. (look at >> the arguments at the end of this mail) >> >> I would like to hear from people who would like to keep the >> Timer-based and Bandwidth-based methods with logical reasons. > > > I'm not sure if these are logical reasons, but... I am > concerned about making a change that will invalidate any > existing ICMPv6 implementations, unless that change is > absolutely necessary (e.g. to block a serious security > hole or to prevent a significant operational problem). > > Would it work to state in the new draft that implementations > SHOULD implement the Token-bucket method, but MAY implement > the other methods? > > I think that would appropriately encourage implementation of > the Token-bucket method without invalidating existing > implementations that use one of the others. I agree with the sentiment here. Changes to this document should not affect backwards compatability. So, I would be opposed to making the proposed change unless we can determine that noone has implemented the timer-based or bandwidth-based mechanisms. Regards, Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Jan 7 06:48:41 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05833 for ; Wed, 7 Jan 2004 06:48:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeCAZ-0007Sw-Ja for ipv6-archive@odin.ietf.org; Wed, 07 Jan 2004 06:48:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i07BmFX6028692 for ipv6-archive@odin.ietf.org; Wed, 7 Jan 2004 06:48:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeCAZ-0007Sh-Fo for ipv6-web-archive@optimus.ietf.org; Wed, 07 Jan 2004 06:48:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05629 for ; Wed, 7 Jan 2004 06:48:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeCAV-00058Y-00 for ipv6-web-archive@ietf.org; Wed, 07 Jan 2004 06:48:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeC8k-0004vj-00 for ipv6-web-archive@ietf.org; Wed, 07 Jan 2004 06:46:23 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AeC72-0004pH-00 for ipv6-web-archive@ietf.org; Wed, 07 Jan 2004 06:44:36 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1AeBwa-0000Vh-GL for ipv6-web-archive@ietf.org; Wed, 07 Jan 2004 06:33:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeBvr-0006EL-Cc; Wed, 07 Jan 2004 06:33:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeBv3-000687-Md for ipv6@optimus.ietf.org; Wed, 07 Jan 2004 06:32:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04974 for ; Wed, 7 Jan 2004 06:32:09 -0500 (EST) From: teemu.savolainen@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeBuz-0004M9-00 for ipv6@ietf.org; Wed, 07 Jan 2004 06:32:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeBtO-0004CP-00 for ipv6@ietf.org; Wed, 07 Jan 2004 06:30:30 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AeBrd-0003xC-00 for ipv6@ietf.org; Wed, 07 Jan 2004 06:28:41 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i07BSg417986 for ; Wed, 7 Jan 2004 13:28:42 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 7 Jan 2004 13:28:41 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 7 Jan 2004 13:28:40 +0200 Received: from trebe004.NOE.Nokia.com ([172.22.232.177]) by esebe023.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 7 Jan 2004 13:28:33 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: draft-ietf-ipngwg-icmp-v3-02.txt: Rate Limiting Methods Date: Wed, 7 Jan 2004 13:28:35 +0200 Message-ID: Thread-Topic: draft-ietf-ipngwg-icmp-v3-02.txt: Rate Limiting Methods Thread-Index: AcPUxOVzbFan9SwjS4WKu0bOu8RZUAASnYvQ To: X-OriginalArrivalTime: 07 Jan 2004 11:28:33.0297 (UTC) FILETIME=[62115810:01C3D511] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi, I have a question/clarification about the Token-bucket based method I = couldn't clearly figure out from draft or mail discussions I found.=20 If there is a situation like this: - Node A is already sending loads of ICMPv6 to the Node B for any reason = (Node B flooding A with echo requests for example). - Node C sends something to Node A that causes ICMPv6 message to be sent = to Node C - Now wouldn't Node A very likely drop the single response for Node C = because Node B has already caused A's Token-bucket to fill up and over? = Wouldn't this be a bit unfair for Node C, particularily if the Node B is = deliberately flooding A? So should Token-bucket based method also look for source/destination = address like Timer-based method says? Or is this fully implementation = specific issue as the draft states that those three methods = (f.1/f.2/f.3) are examples anyway?=20 Thanks, Teemu > -----Original Message----- > From: ipv6-admin@ietf.org [mailto:ipv6-admin@ietf.org]On Behalf Of ext > Margaret Wasserman > Sent: 07 January, 2004 04:06 > To: Gupta Mukesh (Nokia-NET/MtView) > Cc: ipv6@ietf.org > Subject: Re: draft-ietf-ipngwg-icmp-v3-02.txt: Rate Limiting Methods >=20 >=20 >=20 > Hi Mukesh, >=20 > >One of the issues raised was about rate limiting methods > >suggested by the draft. The draft suggests Timer-based, > >Bandwidth-based and Token-bucket based methods for limiting > >the rate of the ICMP messages. > > > >After going through the discussion about this in the archive > >and thinking about this a little bit, I propose that we > >remove the Timer-based and Bandwidth-based methods and just > >keep the Token-bucket based method in the draft. (look at > >the arguments at the end of this mail) > > > >I would like to hear from people who would like to keep the > >Timer-based and Bandwidth-based methods with logical reasons. >=20 > I'm not sure if these are logical reasons, but... I am > concerned about making a change that will invalidate any > existing ICMPv6 implementations, unless that change is > absolutely necessary (e.g. to block a serious security > hole or to prevent a significant operational problem). >=20 > Would it work to state in the new draft that implementations > SHOULD implement the Token-bucket method, but MAY implement > the other methods? >=20 > I think that would appropriately encourage implementation of > the Token-bucket method without invalidating existing > implementations that use one of the others. >=20 > Thoughts? >=20 > Margaret >=20 >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Jan 7 07:12:31 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06506 for ; Wed, 7 Jan 2004 07:12:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeCXa-0000N5-TV for ipv6-archive@odin.ietf.org; Wed, 07 Jan 2004 07:12:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i07CC23m001421 for ipv6-archive@odin.ietf.org; Wed, 7 Jan 2004 07:12:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeCXa-0000Mq-OU for ipv6-web-archive@optimus.ietf.org; Wed, 07 Jan 2004 07:12:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06462 for ; Wed, 7 Jan 2004 07:12:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeCXY-0006Be-00 for ipv6-web-archive@ietf.org; Wed, 07 Jan 2004 07:12:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeCVj-00065w-00 for ipv6-web-archive@ietf.org; Wed, 07 Jan 2004 07:10:07 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AeCTr-00060k-00 for ipv6-web-archive@ietf.org; Wed, 07 Jan 2004 07:08:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeCTi-0008Ge-7P; Wed, 07 Jan 2004 07:08:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeCTf-0008Fv-E0 for ipv6@optimus.ietf.org; Wed, 07 Jan 2004 07:07:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06361 for ; Wed, 7 Jan 2004 07:07:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeCTb-0005xk-00 for ipv6@ietf.org; Wed, 07 Jan 2004 07:07:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeCRf-0005tx-00 for ipv6@ietf.org; Wed, 07 Jan 2004 07:05:55 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeCPz-0005oU-00 for ipv6@ietf.org; Wed, 07 Jan 2004 07:04:11 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i07C3IZ23861; Wed, 7 Jan 2004 14:03:18 +0200 Date: Wed, 7 Jan 2004 14:03:18 +0200 (EET) From: Pekka Savola To: Brian Haberman cc: Margaret Wasserman , , Subject: Re: draft-ietf-ipngwg-icmp-v3-02.txt: Rate Limiting Methods In-Reply-To: <3FFBEF0B.7050105@innovationslab.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 On Wed, 7 Jan 2004, Brian Haberman wrote: > > I think that would appropriately encourage implementation of > > the Token-bucket method without invalidating existing > > implementations that use one of the others. > > I agree with the sentiment here. Changes to this document should > not affect backwards compatability. So, I would be opposed to > making the proposed change unless we can determine that noone has > implemented the timer-based or bandwidth-based mechanisms. Timer-based methods have, unfortunately, been implemented and deploying. IMHO, those should definitely be changed, but I have some sympathy for those who see this as something like "yeah, it's broken, but we don't care about this strongly enough to make them fix it." Remember that in the current text, we're talking about *examples* of possibilities to implement the rate-limiter. We'd just be removing bad examples, and probably adding some non-normative text on why token-based mechanism is recommended. This might be a different situation if we said that token-based rate-limiting MUST be implemented.. but at least I'm not arguing for going that far. As for the different values of token-bucket (or timer-based, or whatever) mechanisms, I'm not sure if that matters that much, it could be an implementation detail as long as it's reasonable. At most one could give a "SHOULD be at least XXXX" implementation hint.. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Jan 7 08:40:36 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08898 for ; Wed, 7 Jan 2004 08:40:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeDup-0003Y8-Bp for ipv6-archive@odin.ietf.org; Wed, 07 Jan 2004 08:40:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i07De7eU013641 for ipv6-archive@odin.ietf.org; Wed, 7 Jan 2004 08:40:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeDuo-0003Xw-Hw for ipv6-web-archive@optimus.ietf.org; Wed, 07 Jan 2004 08:40:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08884 for ; Wed, 7 Jan 2004 08:40:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeDun-0002gG-00 for ipv6-web-archive@ietf.org; Wed, 07 Jan 2004 08:40:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeDt3-0002cQ-00 for ipv6-web-archive@ietf.org; Wed, 07 Jan 2004 08:38:18 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AeDsS-0002Xg-00 for ipv6-web-archive@ietf.org; Wed, 07 Jan 2004 08:37:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeDrq-0002wG-7L; Wed, 07 Jan 2004 08:37:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeDqv-0002vD-Ut for ipv6@optimus.ietf.org; Wed, 07 Jan 2004 08:36:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08697 for ; Wed, 7 Jan 2004 08:36:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeDqu-0002U7-00 for ipv6@ietf.org; Wed, 07 Jan 2004 08:36:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeDp8-0002Oj-00 for ipv6@ietf.org; Wed, 07 Jan 2004 08:34:15 -0500 Received: from web80505.mail.yahoo.com ([66.218.79.75]) by ietf-mx with smtp (Exim 4.12) id 1AeDns-0002Js-00 for ipv6@ietf.org; Wed, 07 Jan 2004 08:32:56 -0500 Message-ID: <20040107133224.44364.qmail@web80505.mail.yahoo.com> Received: from [63.197.18.101] by web80505.mail.yahoo.com via HTTP; Wed, 07 Jan 2004 05:32:24 PST Date: Wed, 7 Jan 2004 05:32:24 -0800 (PST) From: Fred Templin Subject: Re: draft-ietf-ipngwg-icmp-v3-02.txt: Rate Limiting Methods To: Margaret Wasserman , Mukesh.Gupta@nokia.com Cc: ipv6@ietf.org In-Reply-To: <5.1.0.14.2.20040106210337.0316d600@ms101.mail1.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-918908376-1073482344=:43849" Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.9 required=5.0 tests=AWL,FROM_ENDS_IN_NUMS, HTML_MESSAGE,MAILTO_TO_SPAM_ADDR autolearn=no version=2.60 --0-918908376-1073482344=:43849 Content-Type: text/plain; charset=us-ascii Margaret, On further consideration, I think the bandwidth-based method might actually be dangerous in some situations. Suppose there were asymmetric paths between nodes A and B; the path A->B consisting of all 1Gbps links and the path B->A consisting of at least one long, thin link (56Kb modem, 3GPP wireless, etc.) Even if B is able to authenticate the source addresses in packets it receives from A, if the bandwidth-based method is used based on a percentage of the bandwith of B's outgoing 1Gbps interface the queue on a router at the head of a long thin link on the path B->A will overflow. In other words, B might cause harmful denial-of-service if it blindly uses a bandwidth-based estimate, since it has no way of knowing whether long, thin links will occur on the return path. As to timer-based, I think Mukesh has already given a good reason as to why it is suboptimal; I think an arguement could also be constructed that shows it to cause interoperability problems in some cases. So, I find myself in the rare position of agreeing with Pekka on this subject. Fred osprey67@yahoo.com Margaret Wasserman wrote: Hi Mukesh, >One of the issues raised was about rate limiting methods >suggested by the draft. The draft suggests Timer-based, >Bandwidth-based and Token-bucket based methods for limiting >the rate of the ICMP messages. > >After going through the discussion about this in the archive >and thinking about this a little bit, I propose that we >remove the Timer-based and Bandwidth-based methods and just >keep the Token-bucket based method in the draft. (look at >the arguments at the end of this mail) > >I would like to hear from people who would like to keep the >Timer-based and Bandwidth-based methods with logical reasons. I'm not sure if these are logical reasons, but... I am concerned about making a change that will invalidate any existing ICMPv6 implementations, unless that change is absolutely necessary (e.g. to block a serious security hole or to prevent a significant operational problem). Would it work to state in the new draft that implementations SHOULD implement the Token-bucket method, but MAY implement the other methods? I think that would appropriately encourage implementation of the Token-bucket method without invalidating existing implementations that use one of the others. Thoughts? Margaret -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --0-918908376-1073482344=:43849 Content-Type: text/html; charset=us-ascii
Margaret,
 
On further consideration, I think the bandwidth-based method might actually
be dangerous in some situations. Suppose there were asymmetric paths
between nodes A and B; the path A->B consisting of all 1Gbps links and
the path B->A consisting of at least one long, thin link (56Kb modem, 3GPP
wireless, etc.) Even if B is able to authenticate the source addresses in
packets it receives from A, if the bandwidth-based method is used based
on a percentage of the bandwith of B's outgoing 1Gbps interface the queue
on a router at the head of a long thin link on the path B->A will overflow. In
other words, B might cause harmful denial-of-service if it blindly uses a
bandwidth-based estimate, since it has no way of knowing whether long,
thin links will occur on the return path.
 
As to timer-based, I think Mukesh has already given a good reason as to
why it is suboptimal; I think an arguement could also be constructed that
shows it to cause interoperability problems in some cases. So, I find
myself in the rare position of agreeing with Pekka on this subject.
 
Fred


Margaret Wasserman <margaret@thingmagic.com> wrote:

Hi Mukesh,

>One of the issues raised was about rate limiting methods
>suggested by the draft. The draft suggests Timer-based,
>Bandwidth-based and Token-bucket based methods for limiting
>the rate of the ICMP messages.
>
>After going through the discussion about this in the archive
>and thinking about this a little bit, I propose that we
>remove the Timer-based and Bandwidth-based methods and just
>keep the Token-bucket based method in the draft. (look at
>the arguments at the end of this mail)
>
>I would like to hear from people who would like to keep the
>Timer-based and Bandwidth-based methods with logical reasons.

I'm not sure if these are logical reasons, but... I am
concerned about making a change that will invalidate any
existing ICMPv6 implementations, unless that change is
absolutely necessary (e.g. to block a serious security
hole or to prevent a significant operational problem).

Would it work to state in the new draft that implementations
SHOULD implement the Token-bucket method, but MAY implement
the other methods?

I think that would appropriately encourage implementation of
the Token-bucket method without invalidating existing
implementations that use one of the others.

Thoughts?

Margaret



--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--0-918908376-1073482344=:43849-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Jan 7 09:08:47 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10055 for ; Wed, 7 Jan 2004 09:08:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeEM6-00050C-P5 for ipv6-archive@odin.ietf.org; Wed, 07 Jan 2004 09:08:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i07E8I2Z019225 for ipv6-archive@odin.ietf.org; Wed, 7 Jan 2004 09:08:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeEM6-000500-CM for ipv6-web-archive@optimus.ietf.org; Wed, 07 Jan 2004 09:08:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10028 for ; Wed, 7 Jan 2004 09:08:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeEM4-00043v-00 for ipv6-web-archive@ietf.org; Wed, 07 Jan 2004 09:08:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeEKJ-0003y5-00 for ipv6-web-archive@ietf.org; Wed, 07 Jan 2004 09:06:28 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AeEJ8-0003rT-00 for ipv6-web-archive@ietf.org; Wed, 07 Jan 2004 09:05:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeEIx-0004If-IN; Wed, 07 Jan 2004 09:05:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeEHw-0004Go-LR for ipv6@optimus.ietf.org; Wed, 07 Jan 2004 09:04:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09807 for ; Wed, 7 Jan 2004 09:03:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeEHv-0003mQ-00 for ipv6@ietf.org; Wed, 07 Jan 2004 09:03:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeEG0-0003gI-00 for ipv6@ietf.org; Wed, 07 Jan 2004 09:02:01 -0500 Received: from web80502.mail.yahoo.com ([66.218.79.72]) by ietf-mx with smtp (Exim 4.12) id 1AeEEE-0003Xv-00 for ipv6@ietf.org; Wed, 07 Jan 2004 09:00:10 -0500 Message-ID: <20040107135939.77524.qmail@web80502.mail.yahoo.com> Received: from [63.197.18.101] by web80502.mail.yahoo.com via HTTP; Wed, 07 Jan 2004 05:59:39 PST Date: Wed, 7 Jan 2004 05:59:39 -0800 (PST) From: Fred Templin Subject: RE: draft-ietf-ipngwg-icmp-v3-02.txt: Rate Limiting Methods To: teemu.savolainen@nokia.com, ipv6@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1958591321-1073483979=:75898" Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.9 required=5.0 tests=AWL,FROM_ENDS_IN_NUMS, HTML_MESSAGE,MAILTO_TO_SPAM_ADDR autolearn=no version=2.60 --0-1958591321-1073483979=:75898 Content-Type: text/plain; charset=us-ascii Teemu, ICMPv6 echo request/reply don't count, because they're not ICMPv6 errors. If a well-behaved A is sending packets that cause B to generate ICMPv6 errors, A will adapt its behavior and the ICMPv6 messages from B to A will naturally subside. Can B be reasonably assured that A will be well behaved if B has a security association with A? I certainly think so. Must B maintain state to avoid the problem you are describing for any A with which it does not have a security association? Perhaps. Under the assumption of well-behaved nodes, Pekka's point about token bucket being well-suited for bursty traffic was a good one; once the burst of messages from A causing B to send errors subsides, other nodes such as C will receive the ICMPv6 error messages they need from B so that they can also naturally adapt their behavior. Fred osprey67@yahoo.com teemu.savolainen@nokia.com wrote: Hi, I have a question/clarification about the Token-bucket based method I couldn't clearly figure out from draft or mail discussions I found. If there is a situation like this: - Node A is already sending loads of ICMPv6 to the Node B for any reason (Node B flooding A with echo requests for example). - Node C sends something to Node A that causes ICMPv6 message to be sent to Node C - Now wouldn't Node A very likely drop the single response for Node C because Node B has already caused A's Token-bucket to fill up and over? Wouldn't this be a bit unfair for Node C, particularily if the Node B is deliberately flooding A? So should Token-bucket based method also look for source/destination address like Timer-based method says? Or is this fully implementation specific issue as the draft states that those three methods (f.1/f.2/f.3) are examples anyway? Thanks, Teemu > -----Original Message----- > From: ipv6-admin@ietf.org [mailto:ipv6-admin@ietf.org]On Behalf Of ext > Margaret Wasserman > Sent: 07 January, 2004 04:06 > To: Gupta Mukesh (Nokia-NET/MtView) > Cc: ipv6@ietf.org > Subject: Re: draft-ietf-ipngwg-icmp-v3-02.txt: Rate Limiting Methods > > > > Hi Mukesh, > > >One of the issues raised was about rate limiting methods > >suggested by the draft. The draft suggests Timer-based, > >Bandwidth-based and Token-bucket based methods for limiting > >the rate of the ICMP messages. > > > >After going through the discussion about this in the archive > >and thinking about this a little bit, I propose that we > >remove the Timer-based and Bandwidth-based methods and just > >keep the Token-bucket based method in the draft. (look at > >the arguments at the end of this mail) > > > >I would like to hear from people who would like to keep the > >Timer-based and Bandwidth-based methods with logical reasons. > > I'm not sure if these are logical reasons, but... I am > concerned about making a change that will invalidate any > existing ICMPv6 implementations, unless that change is > absolutely necessary (e.g. to block a serious security > hole or to prevent a significant operational problem). > > Would it work to state in the new draft that implementations > SHOULD implement the Token-bucket method, but MAY implement > the other methods? > > I think that would appropriately encourage implementation of > the Token-bucket method without invalidating existing > implementations that use one of the others. > > Thoughts? > > Margaret > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --0-1958591321-1073483979=:75898 Content-Type: text/html; charset=us-ascii
Teemu,
 
ICMPv6 echo request/reply don't count, because they're not ICMPv6 errors.
If a well-behaved A is sending packets that cause B to generate ICMPv6 errors,
A will adapt its behavior and the ICMPv6 messages from B to A will naturally
subside. Can B be reasonably assured that A will be well behaved if B has
a security association with A? I certainly think so. Must B maintain state to
avoid the problem you are describing for any A with which it does not have
a security association? Perhaps.
 
Under the assumption of well-behaved nodes, Pekka's point about token
bucket being well-suited for bursty traffic was a good one; once the burst
of messages from A causing B to send errors subsides, other nodes such
as C will receive the ICMPv6 error messages they need from B so that they
can also naturally adapt their behavior.
 
Fred
osprey67@yahoo.com

teemu.savolainen@nokia.com wrote:
Hi,

I have a question/clarification about the Token-bucket based method I couldn't clearly figure out from draft or mail discussions I found.

If there is a situation like this:
- Node A is already sending loads of ICMPv6 to the Node B for any reason (Node B flooding A with echo requests for example).

- Node C sends something to Node A that causes ICMPv6 message to be sent to Node C

- Now wouldn't Node A very likely drop the single response for Node C because Node B has already caused A's Token-bucket to fill up and over? Wouldn't this be a bit unfair for Node C, particularily if the Node B is deliberately flooding A?

So should Token-bucket based method also look for source/destination address like Timer-based method says? Or is this fully implementation specific issue as the draft states that those three methods (f.1/f.2/f.3) are example! s anyway?

Thanks,

Teemu

> -----Original Message-----
> From: ipv6-admin@ietf.org [mailto:ipv6-admin@ietf.org]On Behalf Of ext
> Margaret Wasserman
> Sent: 07 January, 2004 04:06
> To: Gupta Mukesh (Nokia-NET/MtView)
> Cc: ipv6@ietf.org
> Subject: Re: draft-ietf-ipngwg-icmp-v3-02.txt: Rate Limiting Methods
>
>
>
> Hi Mukesh,
>
> >One of the issues raised was about rate limiting methods
> >suggested by the draft. The draft suggests Timer-based,
> >Bandwidth-based and Token-bucket based methods for limiting
> >the rate of the ICMP messages.
> >
> >After going through the discussion about this in the archive
> >and thinking about this a little bit, I propose that we
> >remove the Timer-based and Bandwidth-based methods and just
> >keep the Token-bucket based method in the draft. (look at
> >the arguments a! t the end of this mail)
> >
> >I would like to hear from people who would like to keep the
> >Timer-based and Bandwidth-based methods with logical reasons.
>
> I'm not sure if these are logical reasons, but... I am
> concerned about making a change that will invalidate any
> existing ICMPv6 implementations, unless that change is
> absolutely necessary (e.g. to block a serious security
> hole or to prevent a significant operational problem).
>
> Would it work to state in the new draft that implementations
> SHOULD implement the Token-bucket method, but MAY implement
> the other methods?
>
> I think that would appropriately encourage implementation of
> the Token-bucket method without invalidating existing
> implementations that use one of the others.
>
> Thoughts?
>
> Margaret
>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--0-1958591321-1073483979=:75898-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Jan 7 09:20:51 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10931 for ; Wed, 7 Jan 2004 09:20:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeEXm-0005hb-As for ipv6-archive@odin.ietf.org; Wed, 07 Jan 2004 09:20:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i07EKLUe021907 for ipv6-archive@odin.ietf.org; Wed, 7 Jan 2004 09:20:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeEXj-0005hF-Uc for ipv6-web-archive@optimus.ietf.org; Wed, 07 Jan 2004 09:20:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10898 for ; Wed, 7 Jan 2004 09:20:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeEXi-0004w0-00 for ipv6-web-archive@ietf.org; Wed, 07 Jan 2004 09:20:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeEVx-0004q7-00 for ipv6-web-archive@ietf.org; Wed, 07 Jan 2004 09:18:30 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AeEUw-0004jr-00 for ipv6-web-archive@ietf.org; Wed, 07 Jan 2004 09:17:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeEUb-0005G5-4e; Wed, 07 Jan 2004 09:17:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeETw-0005DR-TK for ipv6@optimus.ietf.org; Wed, 07 Jan 2004 09:16:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10615 for ; Wed, 7 Jan 2004 09:16:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeETv-0004iH-00 for ipv6@ietf.org; Wed, 07 Jan 2004 09:16:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeESg-0004bu-00 for ipv6@ietf.org; Wed, 07 Jan 2004 09:15:07 -0500 Received: from web80508.mail.yahoo.com ([66.218.79.78]) by ietf-mx with smtp (Exim 4.12) id 1AeERD-0004Qt-00 for ipv6@ietf.org; Wed, 07 Jan 2004 09:13:35 -0500 Message-ID: <20040107141303.57072.qmail@web80508.mail.yahoo.com> Received: from [63.197.18.101] by web80508.mail.yahoo.com via HTTP; Wed, 07 Jan 2004 06:13:03 PST Date: Wed, 7 Jan 2004 06:13:03 -0800 (PST) From: Fred Templin Subject: Re: draft-ietf-ipngwg-icmp-v3-02.txt: Rate Limiting Methods To: Pekka Savola , Brian Haberman Cc: Margaret Wasserman , Mukesh.Gupta@nokia.com, ipv6@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-63183525-1073484783=:56947" Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.9 required=5.0 tests=FROM_ENDS_IN_NUMS,HTML_MESSAGE, MAILTO_TO_SPAM_ADDR autolearn=no version=2.60 --0-63183525-1073484783=:56947 Content-Type: text/plain; charset=us-ascii Pekka, Mostly agree, except with the final paragraph where you say that the parameters for token bucket, timer, etc. mechanisms don't matter that much. ICMPv6 says that errors should include up to the IPv6 min-MTU bytes of the packet that caused the error. That's 1280 bytes, but on some long, thin links the store-and-forward time for such a large packet can be on the order of 1 second! (Remember also the asymmetric path case I referred to in a previous message.) So, it seems to me that it does matter that suitible values are chosen for the parameters - am I wrong? Fred osprey67@yahoo.com Pekka Savola wrote: On Wed, 7 Jan 2004, Brian Haberman wrote: > > I think that would appropriately encourage implementation of > > the Token-bucket method without invalidating existing > > implementations that use one of the others. > > I agree with the sentiment here. Changes to this document should > not affect backwards compatability. So, I would be opposed to > making the proposed change unless we can determine that noone has > implemented the timer-based or bandwidth-based mechanisms. Timer-based methods have, unfortunately, been implemented and deploying. IMHO, those should definitely be changed, but I have some sympathy for those who see this as something like "yeah, it's broken, but we don't care about this strongly enough to make them fix it." Remember that in the current text, we're talking about *examples* of possibilities to implement the rate-limiter. We'd just be removing bad examples, and probably adding some non-normative text on why token-based mechanism is recommended. This might be a different situation if we said that token-based rate-limiting MUST be implemented.. but at least I'm not arguing for going that far. As for the different values of token-bucket (or timer-based, or whatever) mechanisms, I'm not sure if that matters that much, it could be an implementation detail as long as it's reasonable. At most one could give a "SHOULD be at least XXXX" implementation hint.. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --0-63183525-1073484783=:56947 Content-Type: text/html; charset=us-ascii
Pekka,
 
Mostly agree, except with the final paragraph where you say that
the parameters for token bucket, timer, etc. mechanisms don't
matter that much. ICMPv6 says that errors should include up to
the IPv6 min-MTU bytes of the packet that caused the error. That's
1280 bytes, but on some long, thin links the store-and-forward time
for such a large packet can be on the order of 1 second! (Remember
also the asymmetric path case I referred to in a previous message.)
 
So, it seems to me that it does matter that suitible values are chosen
for the parameters - am I wrong?
 
Fred
osprey67@yahoo.com

Pekka Savola <pekkas@netcore.fi> wrote:
On Wed, 7 Jan 2004, Brian Haberman wrote:
> > I think that would appropriately encourage implementation of
> > the Token-bucket method without invalidating existing
> > implementations that use one of the others.
>
> I agree with the sentiment here. Changes to this document should
> not affect backwards compatability. So, I would be opposed to
> making the proposed change unless we can determine that noone has
> implemented the timer-based or bandwidth-based mechanisms.

Timer-based methods have, unfortunately, been implemented and
deploying. IMHO, those should definitely be changed, but I have some
sympathy for those who see this as something like "yeah, it's broken,
but we don't care about this strongly enough to make them fix it."

Remember that in the current text, we're talking about *examples! * of
possibilities to implement the rate-limiter. We'd just be removing
bad examples, and probably adding some non-normative text on why
token-based mechanism is recommended.

This might be a different situation if we said that token-based
rate-limiting MUST be implemented.. but at least I'm not arguing for
going that far.

As for the different values of token-bucket (or timer-based, or
whatever) mechanisms, I'm not sure if that matters that much, it could
be an implementation detail as long as it's reasonable. At most one
could give a "SHOULD be at least XXXX" implementation hint..

--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings



--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--0-63183525-1073484783=:56947-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Jan 7 12:45:24 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21976 for ; Wed, 7 Jan 2004 12:45:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeHjl-0007of-87 for ipv6-archive@odin.ietf.org; Wed, 07 Jan 2004 12:44:57 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i07HivnA030039 for ipv6-archive@odin.ietf.org; Wed, 7 Jan 2004 12:44:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeHjl-0007oQ-0Z for ipv6-web-archive@optimus.ietf.org; Wed, 07 Jan 2004 12:44:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21973 for ; Wed, 7 Jan 2004 12:44:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeHjj-0002Ev-00 for ipv6-web-archive@ietf.org; Wed, 07 Jan 2004 12:44:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeHiI-00026k-00 for ipv6-web-archive@ietf.org; Wed, 07 Jan 2004 12:43:26 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AeHgu-0001mz-00 for ipv6-web-archive@ietf.org; Wed, 07 Jan 2004 12:42:00 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1AeHgu-0006GX-BV for ipv6-web-archive@ietf.org; Wed, 07 Jan 2004 12:42:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeHfy-0007KO-HV; Wed, 07 Jan 2004 12:41:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeHfh-0007Jg-H5 for ipv6@optimus.ietf.org; Wed, 07 Jan 2004 12:40:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21134 for ; Wed, 7 Jan 2004 12:40:41 -0500 (EST) From: Mukesh.Gupta@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeHff-0001Z5-00 for ipv6@ietf.org; Wed, 07 Jan 2004 12:40:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeHcH-0000uE-00 for ipv6@ietf.org; Wed, 07 Jan 2004 12:37:14 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AeHZo-0000N3-00 for ipv6@ietf.org; Wed, 07 Jan 2004 12:34:40 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i07HYc428580 for ; Wed, 7 Jan 2004 19:34:38 +0200 (EET) Received: from daebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 7 Jan 2004 19:34:37 +0200 Received: from daebe009.NOE.Nokia.com ([10.241.35.109]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 7 Jan 2004 09:34:21 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: draft-ietf-ipngwg-icmp-v3-02.txt: Rate Limiting Methods Date: Wed, 7 Jan 2004 11:34:21 -0600 Message-ID: <8D260779A766FB4A9C1739A476F84FA42ABE50@daebe009.americas.nokia.com> Thread-Topic: draft-ietf-ipngwg-icmp-v3-02.txt: Rate Limiting Methods Thread-Index: AcPUxDr3yW8dAQAsQ9COXI/xCt4BTAAf5sxA To: Cc: X-OriginalArrivalTime: 07 Jan 2004 17:34:21.0885 (UTC) FILETIME=[7C7216D0:01C3D544] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Margaret, > I'm not sure if these are logical reasons, but... I am > concerned about making a change that will invalidate any > existing ICMPv6 implementations, unless that change is > absolutely necessary (e.g. to block a serious security > hole or to prevent a significant operational problem). >=20 > Would it work to state in the new draft that implementations > SHOULD implement the Token-bucket method, but MAY implement > the other methods? As Pekka already pointed out, all the three methods are provided as examples. The draft mandates the rate limiting by saying: "an IPv6 node MUST limit the rate of ICMPv6 error messages it sends" and then it provides examples by saying: "There are a variety of ways of implementing the rate-limiting function, for example:" So I don't think we will be doing anything bad by removing the bad examples. The Timer-based method does create an significant operational=20 problem i.e. it breaks traceroute. Regards Mukesh -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Jan 7 12:58:43 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22590 for ; Wed, 7 Jan 2004 12:58:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeHwe-00005r-A5 for ipv6-archive@odin.ietf.org; Wed, 07 Jan 2004 12:58:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i07HwGHn000353 for ipv6-archive@odin.ietf.org; Wed, 7 Jan 2004 12:58:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeHwe-00005c-4X for ipv6-web-archive@optimus.ietf.org; Wed, 07 Jan 2004 12:58:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22563 for ; Wed, 7 Jan 2004 12:58:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeHwc-0002rC-00 for ipv6-web-archive@ietf.org; Wed, 07 Jan 2004 12:58:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeHuj-0002nC-00 for ipv6-web-archive@ietf.org; Wed, 07 Jan 2004 12:56:18 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AeHu0-0002ix-00 for ipv6-web-archive@ietf.org; Wed, 07 Jan 2004 12:55:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeHtY-0008ES-4A; Wed, 07 Jan 2004 12:55:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeHsf-0008De-2d for ipv6@optimus.ietf.org; Wed, 07 Jan 2004 12:54:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22459 for ; Wed, 7 Jan 2004 12:54:05 -0500 (EST) From: Mukesh.Gupta@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeHsd-0002gg-00 for ipv6@ietf.org; Wed, 07 Jan 2004 12:54:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeHqj-0002dx-00 for ipv6@ietf.org; Wed, 07 Jan 2004 12:52:10 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AeHpW-0002b8-00 for ipv6@ietf.org; Wed, 07 Jan 2004 12:50:55 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i07Hor620237 for ; Wed, 7 Jan 2004 19:50:53 +0200 (EET) Received: from daebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 7 Jan 2004 19:50:53 +0200 Received: from daebe009.NOE.Nokia.com ([10.241.35.109]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 7 Jan 2004 09:50:52 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: draft-ietf-ipngwg-icmp-v3-02.txt: Rate Limiting Methods Date: Wed, 7 Jan 2004 11:50:51 -0600 Message-ID: <8D260779A766FB4A9C1739A476F84FA42ABE51@daebe009.americas.nokia.com> Thread-Topic: draft-ietf-ipngwg-icmp-v3-02.txt: Rate Limiting Methods Thread-Index: AcPVJ1GoFHkA+WYdQwqNZ3NoC5J5BgAHezYA To: , , X-OriginalArrivalTime: 07 Jan 2004 17:50:52.0262 (UTC) FILETIME=[CAC1A060:01C3D546] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.9 required=5.0 tests=AWL,MAILTO_TO_SPAM_ADDR, NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Fred, I don't quite understand why the Timer-based method need to consider the source but Token-bucket based method or the Bandwidth-based method don't (as the draft suggests). Why not limit the rate of ICMPv6 error messages to a particular=20 source by using even the token-bucket based method ? Regards Mukesh -----Original Message----- From: ipv6-admin@ietf.org [mailto:ipv6-admin@ietf.org]On Behalf Of ext = Fred Templin Sent: Wednesday, January 07, 2004 6:00 AM To: Savolainen Teemu (Nokia-TP/Tampere); ipv6@ietf.org Subject: RE: draft-ietf-ipngwg-icmp-v3-02.txt: Rate Limiting Methods Teemu, ICMPv6 echo request/reply don't count, because they're not ICMPv6 = errors. If a well-behaved A is sending packets that cause B to generate ICMPv6 = errors, A will adapt its behavior and the ICMPv6 messages from B to A will = naturally subside. Can B be reasonably assured that A will be well behaved if B = has a security association with A? I certainly think so. Must B maintain = state to avoid the problem you are describing for any A with which it does not = have a security association? Perhaps. Under the assumption of well-behaved nodes, Pekka's point about token bucket being well-suited for bursty traffic was a good one; once the = burst of messages from A causing B to send errors subsides, other nodes such as C will receive the ICMPv6 error messages they need from B so that = they can also naturally adapt their behavior. Fred osprey67@yahoo.com teemu.savolainen@nokia.com wrote: Hi, I have a question/clarification about the Token-bucket based method I = couldn't clearly figure out from draft or mail discussions I found.=20 If there is a situation like this: - Node A is already sending loads of ICMPv6 to the Node B for any reason = (Node B flooding A with echo requests for example). - Node C sends something to Node A that causes ICMPv6 message to be sent = to Node C - Now wouldn't Node A very likely drop the single response for Node C = because Node B has already caused A's Token-bucket to fill up and over? = Wouldn't this be a bit unfair for Node C, particularily if the Node B is = deliberately flooding A? So should Token-bucket based method also look for source/destination = address like Timer-based method says? Or is this fully implementation = specific issue as the draft states that those three methods = (f.1/f.2/f.3) are example! s anyway?=20 Thanks, Teemu > -----Original Message----- > From: ipv6-admin@ietf.org [mailto:ipv6-admin@ietf.org]On Behalf Of ext > Margaret Wasserman > Sent: 07 January, 2004 04:06 > To: Gupta Mukesh (Nokia-NET/MtView) > Cc: ipv6@ietf.org > Subject: Re: draft-ietf-ipngwg-icmp-v3-02.txt: Rate Limiting Methods >=20 >=20 >=20 > Hi Mukesh, >=20 > >One of the issues raised was about rate limiting methods > >suggested by the draft. The draft suggests Timer-based, > >Bandwidth-based and Token-bucket based methods for limiting > >the rate of the ICMP messages. > > > >After going through the discussion about this in the archive > >and thinking about this a little bit, I propose that we > >remove the Timer-based and Bandwidth-based methods and just > >keep the Token-bucket based method in the draft. (look at > >the arguments a! t the end of this mail) > > > >I would like to hear from people who would like to keep the > >Timer-based and Bandwidth-based methods with logical reasons. >=20 > I'm not sure if these are logical reasons, but... I am > concerned about making a change that will invalidate any > existing ICMPv6 implementations, unless that change is > absolutely necessary (e.g. to block a serious security > hole or to prevent a significant operational problem). >=20 > Would it work to state in the new draft that implementations > SHOULD implement the Token-bucket method, but MAY implement > the other methods? >=20 > I think that would appropriately encourage implementation of > the Token-bucket method without invalidating existing > implementations that use one of the others. >=20 > Thoughts? >=20 > Margaret >=20 >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Jan 7 13:02:44 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22793 for ; Wed, 7 Jan 2004 13:02:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeI0X-0000TR-K2 for ipv6-archive@odin.ietf.org; Wed, 07 Jan 2004 13:02:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i07I2HPL001818 for ipv6-archive@odin.ietf.org; Wed, 7 Jan 2004 13:02:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeI0X-0000TF-At for ipv6-web-archive@optimus.ietf.org; Wed, 07 Jan 2004 13:02:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22774 for ; Wed, 7 Jan 2004 13:02:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeI0V-000335-00 for ipv6-web-archive@ietf.org; Wed, 07 Jan 2004 13:02:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeHyh-0002yV-00 for ipv6-web-archive@ietf.org; Wed, 07 Jan 2004 13:00:23 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AeHxQ-0002tJ-00 for ipv6-web-archive@ietf.org; Wed, 07 Jan 2004 12:59:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeHxO-00006v-4y; Wed, 07 Jan 2004 12:59:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeHwY-00005S-VH for ipv6@optimus.ietf.org; Wed, 07 Jan 2004 12:58:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22548 for ; Wed, 7 Jan 2004 12:58:07 -0500 (EST) From: Mukesh.Gupta@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeHwW-0002qL-00 for ipv6@ietf.org; Wed, 07 Jan 2004 12:58:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeHud-0002mC-00 for ipv6@ietf.org; Wed, 07 Jan 2004 12:56:12 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AeHst-0002ih-00 for ipv6@ietf.org; Wed, 07 Jan 2004 12:54:23 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i07HsM623155 for ; Wed, 7 Jan 2004 19:54:22 +0200 (EET) Received: from daebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 7 Jan 2004 19:54:22 +0200 Received: from daebe009.NOE.Nokia.com ([10.241.35.109]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 7 Jan 2004 09:54:19 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: draft-ietf-ipngwg-icmp-v3-02.txt: Rate Limiting Methods Date: Wed, 7 Jan 2004 11:54:18 -0600 Message-ID: <8D260779A766FB4A9C1739A476F84FA4015470BD@daebe009.americas.nokia.com> Thread-Topic: draft-ietf-ipngwg-icmp-v3-02.txt: Rate Limiting Methods Thread-Index: AcPVKF+xzrjmU9b3RN+m6XU2m3imLgAHnTug To: , , Cc: , X-OriginalArrivalTime: 07 Jan 2004 17:54:19.0527 (UTC) FILETIME=[464BC170:01C3D547] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.9 required=5.0 tests=AWL,MAILTO_TO_SPAM_ADDR, NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Fred, I agree that the parameters do matter and should be chosen wisely. As the methods are being listed as examples, the draft can only "suggest" suitable values and can not mandate them. I think, even Pekka agrees that we could provide some hint to the implementors by listing some suitable values in the draft. Regards Mukesh -----Original Message----- From: ext Fred Templin [mailto:osprey67@yahoo.com] Sent: Wednesday, January 07, 2004 6:13 AM To: Pekka Savola; Brian Haberman Cc: Margaret Wasserman; Gupta Mukesh (Nokia-NET/MtView); ipv6@ietf.org Subject: Re: draft-ietf-ipngwg-icmp-v3-02.txt: Rate Limiting Methods Pekka, Mostly agree, except with the final paragraph where you say that the parameters for token bucket, timer, etc. mechanisms don't matter that much. ICMPv6 says that errors should include up to the IPv6 min-MTU bytes of the packet that caused the error. That's 1280 bytes, but on some long, thin links the store-and-forward time for such a large packet can be on the order of 1 second! (Remember also the asymmetric path case I referred to in a previous message.) So, it seems to me that it does matter that suitible values are chosen for the parameters - am I wrong? Fred osprey67@yahoo.com Pekka Savola wrote: On Wed, 7 Jan 2004, Brian Haberman wrote: > > I think that would appropriately encourage implementation of > > the Token-bucket method without invalidating existing > > implementations that use one of the others. >=20 > I agree with the sentiment here. Changes to this document should > not affect backwards compatability. So, I would be opposed to > making the proposed change unless we can determine that noone has > implemented the timer-based or bandwidth-based mechanisms. Timer-based methods have, unfortunately, been implemented and deploying. IMHO, those should definitely be changed, but I have some sympathy for those who see this as something like "yeah, it's broken, but we don't care about this strongly enough to make them fix it." Remember that in the current text, we're talking about *examples! * of=20 possibilities to implement the rate-limiter. We'd just be removing=20 bad examples, and probably adding some non-normative text on why=20 token-based mechanism is recommended. This might be a different situation if we said that token-based=20 rate-limiting MUST be implemented.. but at least I'm not arguing for=20 going that far. As for the different values of token-bucket (or timer-based, or=20 whatever) mechanisms, I'm not sure if that matters that much, it could=20 be an implementation detail as long as it's reasonable. At most one=20 could give a "SHOULD be at least XXXX" implementation hint.. --=20 Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Jan 7 13:19:54 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23331 for ; Wed, 7 Jan 2004 13:19:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeIH8-0001VY-NW for ipv6-archive@odin.ietf.org; Wed, 07 Jan 2004 13:19:27 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i07IJQwk005790 for ipv6-archive@odin.ietf.org; Wed, 7 Jan 2004 13:19:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeIH8-0001VJ-I7 for ipv6-web-archive@optimus.ietf.org; Wed, 07 Jan 2004 13:19:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23295 for ; Wed, 7 Jan 2004 13:19:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeIH1-0003l0-00 for ipv6-web-archive@ietf.org; Wed, 07 Jan 2004 13:19:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeICB-0003fB-00 for ipv6-web-archive@ietf.org; Wed, 07 Jan 2004 13:14:20 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AeIAz-0003ai-00 for ipv6-web-archive@ietf.org; Wed, 07 Jan 2004 13:13:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeIAv-00010y-I3; Wed, 07 Jan 2004 13:13:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeIA5-0000zg-J1 for ipv6@optimus.ietf.org; Wed, 07 Jan 2004 13:12:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23078 for ; Wed, 7 Jan 2004 13:12:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeIA3-0003Xz-00 for ipv6@ietf.org; Wed, 07 Jan 2004 13:12:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeI8G-0003Sw-00 for ipv6@ietf.org; Wed, 07 Jan 2004 13:10:17 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AeI6T-0003Hn-00 for ipv6@ietf.org; Wed, 07 Jan 2004 13:08:25 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i07I7ls00407; Wed, 7 Jan 2004 10:07:47 -0800 X-mProtect: <200401071807> Nokia Silicon Valley Messaging Protection Received: from ftemplin.iprg.nokia.com (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdiRu5Lh; Wed, 07 Jan 2004 10:07:45 PST Message-ID: <3FFC4AF9.9080800@iprg.nokia.com> Date: Wed, 07 Jan 2004 10:07:53 -0800 From: Fred Templin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mukesh.Gupta@nokia.com CC: osprey67@yahoo.com, teemu.savolainen@nokia.com, ipv6@ietf.org Subject: Re: draft-ietf-ipngwg-icmp-v3-02.txt: Rate Limiting Methods References: <8D260779A766FB4A9C1739A476F84FA42ABE51@daebe009.americas.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,MAILTO_TO_SPAM_ADDR autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Mukesh, Mukesh.Gupta@nokia.com wrote: >Fred, > >I don't quite understand why the Timer-based method need to >consider the source but Token-bucket based method or the >Bandwidth-based method don't (as the draft suggests). > The text says: (f.1) Timer-based - for example, limiting the rate of transmission of error messages to a given source, or to any source, to at most once every T milliseconds. The key phrase is: "to a given source, or to any source", so it doesn't seem that the timer-based method *needs* to consider the source. BTW, I cut-and-pasted the above text out of RFC 1885 (published in December 1995 and obsoleted by RFC 2463) so we are talking about very old history here. >Why not limit the rate of ICMPv6 error messages to a particular >source by using even the token-bucket based method ? > I would be concerned about the overhead for caching per-source information, especially in low-end routers. But, that's just an off-the-cuff remark and not well thought out in terms of all the implications. Fred ftemplin@iprg.nokia.com >Regards >Mukesh > >-----Original Message----- >From: ipv6-admin@ietf.org [mailto:ipv6-admin@ietf.org]On Behalf Of ext Fred Templin >Sent: Wednesday, January 07, 2004 6:00 AM >To: Savolainen Teemu (Nokia-TP/Tampere); ipv6@ietf.org >Subject: RE: draft-ietf-ipngwg-icmp-v3-02.txt: Rate Limiting Methods > > >Teemu, > >ICMPv6 echo request/reply don't count, because they're not ICMPv6 errors. >If a well-behaved A is sending packets that cause B to generate ICMPv6 errors, >A will adapt its behavior and the ICMPv6 messages from B to A will naturally >subside. Can B be reasonably assured that A will be well behaved if B has >a security association with A? I certainly think so. Must B maintain state to >avoid the problem you are describing for any A with which it does not have >a security association? Perhaps. > >Under the assumption of well-behaved nodes, Pekka's point about token >bucket being well-suited for bursty traffic was a good one; once the burst >of messages from A causing B to send errors subsides, other nodes such >as C will receive the ICMPv6 error messages they need from B so that they >can also naturally adapt their behavior. > >Fred >osprey67@yahoo.com > >teemu.savolainen@nokia.com wrote: >Hi, > >I have a question/clarification about the Token-bucket based method I couldn't clearly figure out from draft or mail discussions I found. > >If there is a situation like this: >- Node A is already sending loads of ICMPv6 to the Node B for any reason (Node B flooding A with echo requests for example). > >- Node C sends something to Node A that causes ICMPv6 message to be sent to Node C > >- Now wouldn't Node A very likely drop the single response for Node C because Node B has already caused A's Token-bucket to fill up and over? Wouldn't this be a bit unfair for Node C, particularily if the Node B is deliberately flooding A? > >So should Token-bucket based method also look for source/destination address like Timer-based method says? Or is this fully implementation specific issue as the draft states that those three methods (f.1/f.2/f.3) are example! s anyway? > >Thanks, > >Teemu > > > >>-----Original Message----- >>From: ipv6-admin@ietf.org [mailto:ipv6-admin@ietf.org]On Behalf Of ext >>Margaret Wasserman >>Sent: 07 January, 2004 04:06 >>To: Gupta Mukesh (Nokia-NET/MtView) >>Cc: ipv6@ietf.org >>Subject: Re: draft-ietf-ipngwg-icmp-v3-02.txt: Rate Limiting Methods >> >> >> >>Hi Mukesh, >> >> >> >>>One of the issues raised was about rate limiting methods >>>suggested by the draft. The draft suggests Timer-based, >>>Bandwidth-based and Token-bucket based methods for limiting >>>the rate of the ICMP messages. >>> >>>After going through the discussion about this in the archive >>>and thinking about this a little bit, I propose that we >>>remove the Timer-based and Bandwidth-based methods and just >>>keep the Token-bucket based method in the draft. (look at >>>the arguments a! t the end of this mail) >>> >>>I would like to hear from people who would like to keep the >>>Timer-based and Bandwidth-based methods with logical reasons. >>> >>> >>I'm not sure if these are logical reasons, but... I am >>concerned about making a change that will invalidate any >>existing ICMPv6 implementations, unless that change is >>absolutely necessary (e.g. to block a serious security >>hole or to prevent a significant operational problem). >> >>Would it work to state in the new draft that implementations >>SHOULD implement the Token-bucket method, but MAY implement >>the other methods? >> >>I think that would appropriately encourage implementation of >>the Token-bucket method without invalidating existing >>implementations that use one of the others. >> >>Thoughts? >> >>Margaret >> >> >> >>-------------------------------------------------------------------- >>IETF IPv6 working group mailing list >>ipv6@ietf.org >>Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >>-------------------------------------------------------------------- >> >> >> > >-------------------------------------------------------------------- >IETF IPv6 working group mailing list >ipv6@ietf.org >Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- > >-------------------------------------------------------------------- >IETF IPv6 working group mailing list >ipv6@ietf.org >Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Jan 7 13:40:35 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23964 for ; Wed, 7 Jan 2004 13:40:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeIb9-0002m0-Ix for ipv6-archive@odin.ietf.org; Wed, 07 Jan 2004 13:40:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i07Ie7sR010661 for ipv6-archive@odin.ietf.org; Wed, 7 Jan 2004 13:40:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeIb8-0002la-Em for ipv6-web-archive@optimus.ietf.org; Wed, 07 Jan 2004 13:40:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23901 for ; Wed, 7 Jan 2004 13:40:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeIb6-0004X9-00 for ipv6-web-archive@ietf.org; Wed, 07 Jan 2004 13:40:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeIXl-0004O6-00 for ipv6-web-archive@ietf.org; Wed, 07 Jan 2004 13:36:38 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AeIUo-0004Eo-00 for ipv6-web-archive@ietf.org; Wed, 07 Jan 2004 13:33:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeIUI-0001yQ-3z; Wed, 07 Jan 2004 13:33:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeIU1-0001xq-Oq for ipv6@optimus.ietf.org; Wed, 07 Jan 2004 13:32:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23736 for ; Wed, 7 Jan 2004 13:32:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeITu-0004E4-00 for ipv6@ietf.org; Wed, 07 Jan 2004 13:32:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeIOl-00044A-00 for ipv6@ietf.org; Wed, 07 Jan 2004 13:27:19 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeIKq-0003tz-00 for ipv6@ietf.org; Wed, 07 Jan 2004 13:23:16 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i07IMFx28713 for ; Wed, 7 Jan 2004 20:22:15 +0200 Date: Wed, 7 Jan 2004 20:22:15 +0200 (EET) From: Pekka Savola To: ipv6@ietf.org Subject: Re: draft-ietf-ipngwg-icmp-v3-02.txt: Rate Limiting Methods In-Reply-To: <3FFC4AF9.9080800@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 (Tailed down the cc:) On Wed, 7 Jan 2004, Fred Templin wrote: > >Why not limit the rate of ICMPv6 error messages to a particular > >source by using even the token-bucket based method ? > > I would be concerned about the overhead for caching per-source > information, especially in low-end routers. But, that's just an > off-the-cuff remark and not well thought out in terms of all > the implications. I'm worried about the same thing -- and I don't think source-based token-bucket is justified. Sure, feel free to do so, but a regular one should work just as well with sufficiently large burst allowance (e.g., 50-100 packets). If someone is DoS'ing you it may actually be a feature that you don't consider the source .. you can't overload the box by spoofing different source addresses :-) W.r.t. the other thread, I don't have objections to giving an implementation hint on the parameters -- it's just that I don't think it's really needed. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Jan 7 14:11:02 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25253 for ; Wed, 7 Jan 2004 14:11:02 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeJ4c-0004gb-2H for ipv6-archive@odin.ietf.org; Wed, 07 Jan 2004 14:10:34 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i07JAYTJ018007 for ipv6-archive@odin.ietf.org; Wed, 7 Jan 2004 14:10:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeJ4b-0004gM-T6 for ipv6-web-archive@optimus.ietf.org; Wed, 07 Jan 2004 14:10:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25190 for ; Wed, 7 Jan 2004 14:10:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeJ4Z-00068d-00 for ipv6-web-archive@ietf.org; Wed, 07 Jan 2004 14:10:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeJ2l-0005zQ-00 for ipv6-web-archive@ietf.org; Wed, 07 Jan 2004 14:08:40 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AeJ1R-0005r5-00 for ipv6-web-archive@ietf.org; Wed, 07 Jan 2004 14:07:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeJ1B-0003vA-6t; Wed, 07 Jan 2004 14:07:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeJ0Z-0003tp-2p for ipv6@optimus.ietf.org; Wed, 07 Jan 2004 14:06:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24878 for ; Wed, 7 Jan 2004 14:06:20 -0500 (EST) From: Mukesh.Gupta@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeJ0W-0005mJ-00 for ipv6@ietf.org; Wed, 07 Jan 2004 14:06:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeIyV-0005gq-00 for ipv6@ietf.org; Wed, 07 Jan 2004 14:04:15 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AeIwl-0005cd-00 for ipv6@ietf.org; Wed, 07 Jan 2004 14:02:27 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i07J2Q416896 for ; Wed, 7 Jan 2004 21:02:26 +0200 (EET) Received: from daebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 7 Jan 2004 21:02:21 +0200 Received: from daebe009.NOE.Nokia.com ([10.241.35.109]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 7 Jan 2004 13:01:48 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: draft-ietf-ipngwg-icmp-v3-02.txt: Rate Limiting Methods Date: Wed, 7 Jan 2004 13:01:47 -0600 Message-ID: <8D260779A766FB4A9C1739A476F84FA42ABE52@daebe009.americas.nokia.com> Thread-Topic: draft-ietf-ipngwg-icmp-v3-02.txt: Rate Limiting Methods Thread-Index: AcPVTLeAXLnkMJEuT2C6sZDxUbaMxAAAsrRw To: , X-OriginalArrivalTime: 07 Jan 2004 19:01:48.0358 (UTC) FILETIME=[B3965660:01C3D550] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > I'm worried about the same thing -- and I don't think source-based > token-bucket is justified. Sure, feel free to do so, but a regular > one should work just as well with sufficiently large burst allowance > (e.g., 50-100 packets). >=20 > If someone is DoS'ing you it may actually be a feature that you don't=20 > consider the source .. you can't overload the box by spoofing=20 > different source addresses :-) Makes sense :) > W.r.t. the other thread, I don't have objections to giving an=20 > implementation hint on the parameters -- it's just that I don't think=20 > it's really needed. If we were to provide such a hint, what would be the suitable values for B and N ?? (allowing up to B back-to-back error messages to be transmitted in a=20 burst, but limiting the average rate of transmission to N messages per second.) Regards Mukesh -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Jan 7 18:15:56 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12742 for ; Wed, 7 Jan 2004 18:15:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeMtd-0008Qq-Rc for ipv6-archive@odin.ietf.org; Wed, 07 Jan 2004 18:15:29 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i07NFT5g032408 for ipv6-archive@odin.ietf.org; Wed, 7 Jan 2004 18:15:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeMtb-0008Qc-Hq for ipv6-web-archive@optimus.ietf.org; Wed, 07 Jan 2004 18:15:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12674 for ; Wed, 7 Jan 2004 18:15:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeMtT-0007F0-00 for ipv6-web-archive@ietf.org; Wed, 07 Jan 2004 18:15:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeMqb-0007AH-00 for ipv6-web-archive@ietf.org; Wed, 07 Jan 2004 18:12:22 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AeMpj-000769-00 for ipv6-web-archive@ietf.org; Wed, 07 Jan 2004 18:11:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeMpL-0007z5-1z; Wed, 07 Jan 2004 18:11:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeMoV-0007vJ-01 for ipv6@optimus.ietf.org; Wed, 07 Jan 2004 18:10:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12150 for ; Wed, 7 Jan 2004 18:10:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeMoS-00072a-00 for ipv6@ietf.org; Wed, 07 Jan 2004 18:10:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeMmW-0006yI-00 for ipv6@ietf.org; Wed, 07 Jan 2004 18:08:09 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AeMkb-0006ro-00 for ipv6@ietf.org; Wed, 07 Jan 2004 18:06:10 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i07N5bg29472; Wed, 7 Jan 2004 15:05:37 -0800 X-mProtect: <200401072305> Nokia Silicon Valley Messaging Protection Received: from walnut2.iprg.nokia.com (205.226.9.199, claiming to be "spruce.nokia.com") by darkstar.iprg.nokia.com smtpdeYo3Pk; Wed, 07 Jan 2004 15:05:34 PST Message-Id: <4.3.2.7.2.20040107134344.02410408@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 07 Jan 2004 15:03:10 -0800 To: Mukesh.Gupta@nokia.com From: Bob Hinden Subject: RE: draft-ietf-ipngwg-icmp-v3-02.txt: Rate Limiting Methods Cc: margaret@thingmagic.com, ipv6@ietf.org In-Reply-To: <8D260779A766FB4A9C1739A476F84FA42ABE50@daebe009.americas.n okia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Mukesh, >As Pekka already pointed out, all the three methods are provided >as examples. The draft mandates the rate limiting by saying: > >"an IPv6 node MUST limit the rate of ICMPv6 error messages it sends" > >and then it provides examples by saying: > >"There are a variety of ways of implementing the rate-limiting function, >for example:" It's worth noting that the change in this section from RFC2463 (which icmp-v3-** will be replacing) was to add token bucket to the list of examples. RFC2463 only lists the timer and bandwidth methods. I think most people agree that token bucket is preferable. >So I don't think we will be doing anything bad by removing the >bad examples. > >The Timer-based method does create an significant operational >problem i.e. it breaks traceroute. I would be happy if the text was expanded to say that token bucket is the preferred approach and describe the limitations of the other two. I think this would give the people implementing ICMPv6 the guidance they need to build a rate-limiting function that is appropriate for their implementation. Bob -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Jan 7 19:36:44 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15751 for ; Wed, 7 Jan 2004 19:36:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeO9o-000458-Qj for ipv6-archive@odin.ietf.org; Wed, 07 Jan 2004 19:36:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i080aGoM015689 for ipv6-archive@odin.ietf.org; Wed, 7 Jan 2004 19:36:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeO9o-00044t-HQ for ipv6-web-archive@optimus.ietf.org; Wed, 07 Jan 2004 19:36:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15681 for ; Wed, 7 Jan 2004 19:36:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeO9l-00037v-00 for ipv6-web-archive@ietf.org; Wed, 07 Jan 2004 19:36:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeO88-0002zi-00 for ipv6-web-archive@ietf.org; Wed, 07 Jan 2004 19:34:33 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AeO4k-0002qg-00 for ipv6-web-archive@ietf.org; Wed, 07 Jan 2004 19:31:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeO3o-0003Jo-2Q; Wed, 07 Jan 2004 19:30:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeO3V-0003J9-R8 for ipv6@optimus.ietf.org; Wed, 07 Jan 2004 19:29:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15507 for ; Wed, 7 Jan 2004 19:29:37 -0500 (EST) From: Mukesh.Gupta@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeO3K-0002nh-00 for ipv6@ietf.org; Wed, 07 Jan 2004 19:29:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeNyJ-0002d1-00 for ipv6@ietf.org; Wed, 07 Jan 2004 19:24:25 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AeNtU-0002QQ-00 for ipv6@ietf.org; Wed, 07 Jan 2004 19:19:24 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i080JE629813 for ; Thu, 8 Jan 2004 02:19:14 +0200 (EET) Received: from daebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 8 Jan 2004 02:19:14 +0200 Received: from daebe009.NOE.Nokia.com ([10.241.35.109]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 7 Jan 2004 18:19:12 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3D57D.0A7B37C1" Subject: RE: draft-ietf-ipngwg-icmp-v3-02.txt: Rate Limiting Methods Date: Wed, 7 Jan 2004 18:19:11 -0600 Message-ID: <8D260779A766FB4A9C1739A476F84FA42ABE53@daebe009.americas.nokia.com> Thread-Topic: draft-ietf-ipngwg-icmp-v3-02.txt: Rate Limiting Methods Thread-Index: AcPVIsr3NT6N0RoTTjuJKzFblXi0egAWUvFA To: Cc: X-OriginalArrivalTime: 08 Jan 2004 00:19:12.0306 (UTC) FILETIME=[0AAA3120:01C3D57D] Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.3 required=5.0 tests=AWL,HTML_40_50, HTML_FONTCOLOR_BLUE,HTML_MESSAGE,MAILTO_TO_SPAM_ADDR,NO_REAL_NAME autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C3D57D.0A7B37C1 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Fred, =20 Rethinking about the following example of yours. Do we need to consider the asymmetric paths between A and B ? I guess, the problem can be seen with even symmetric path. Let say the network is like =20 A <--- 1gig ---> C <--- 56 kbps --> D <--- 1 gig ---> B =20 Now A starts sending some packets and B generates ICMPv6 error=20 messages. If B is using bandwidth-based function for limiting the rate, it would calculate the percentage using 1 gig link's bandwidth and will=20 overload the thin link between C & D. =20 Am I missing something ? =20 Regards Mukesh -----Original Message----- From: ext Fred Templin [mailto:osprey67@yahoo.com] Sent: Wednesday, January 07, 2004 5:32 AM To: Margaret Wasserman; Gupta Mukesh (Nokia-NET/MtView) Cc: ipv6@ietf.org Subject: Re: draft-ietf-ipngwg-icmp-v3-02.txt: Rate Limiting Methods Margaret, =20 On further consideration, I think the bandwidth-based method might = actually be dangerous in some situations. Suppose there were asymmetric paths between nodes A and B; the path A->B consisting of all 1Gbps links and the path B->A consisting of at least one long, thin link (56Kb modem, = 3GPP wireless, etc.) Even if B is able to authenticate the source addresses = in packets it receives from A, if the bandwidth-based method is used based on a percentage of the bandwith of B's outgoing 1Gbps interface the = queue on a router at the head of a long thin link on the path B->A will = overflow. In other words, B might cause harmful denial-of-service if it blindly uses = a bandwidth-based estimate, since it has no way of knowing whether long, thin links will occur on the return path. =20 As to timer-based, I think Mukesh has already given a good reason as to why it is suboptimal; I think an arguement could also be constructed = that shows it to cause interoperability problems in some cases. So, I find myself in the rare position of agreeing with Pekka on this subject. =20 Fred osprey67@yahoo.com =20 ------_=_NextPart_001_01C3D57D.0A7B37C1 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Fred,
 
Rethinking about the following example of yours. Do we need to=20 consider
the=20 asymmetric paths between A and B ? I guess, the problem can be=20 seen
with even=20 symmetric path. Let say the network is=20 like
 
A <---=20 1gig ---> C <--- 56 kbps --> D <--- 1 gig --->=20 B
 
Now A=20 starts sending some packets and B generates ICMPv6 error=20
messages.=20 If B is using bandwidth-based function for limiting the=20 rate,
it would=20 calculate the percentage using 1 gig link's bandwidth and will=20
overload=20 the thin link between C & = D.
 
Am I=20 missing something ?
 
Regards
Mukesh
-----Original Message-----
From: ext Fred Templin=20 [mailto:osprey67@yahoo.com]
Sent: Wednesday, January 07, = 2004 5:32=20 AM
To: Margaret Wasserman; Gupta Mukesh=20 (Nokia-NET/MtView)
Cc: ipv6@ietf.org
Subject: Re:=20 draft-ietf-ipngwg-icmp-v3-02.txt: Rate Limiting = Methods

Margaret,
 
On further consideration, I think the bandwidth-based method = might=20 actually
be dangerous in some situations. Suppose there were = asymmetric=20 paths
between nodes A and B; the path A->B consisting of all 1Gbps = links=20 and
the path B->A consisting of at least one long, thin link (56Kb = modem,=20 3GPP
wireless, etc.) Even if B is able to authenticate the source = addresses=20 in
packets it receives from A, if the bandwidth-based method is used = based
on a percentage of the bandwith of B's outgoing 1Gbps interface = the=20 queue
on a router at the head of a long thin link on the path = B->A will=20 overflow. In
other words, B might cause harmful denial-of-service if = it=20 blindly uses a
bandwidth-based estimate, since it has no way of knowing whether=20 long,
thin links will occur on the return path.
 
As to timer-based, I think Mukesh has already given a good reason = as=20 to
why it is suboptimal; I think an arguement could = also be=20 constructed that
shows it to cause interoperability problems in some cases. So, I=20 find
myself in the rare position of agreeing with Pekka on this = subject.
 
Fred
------_=_NextPart_001_01C3D57D.0A7B37C1-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Jan 7 19:38:50 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15901 for ; Wed, 7 Jan 2004 19:38:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeOBr-0004V5-8I for ipv6-archive@odin.ietf.org; Wed, 07 Jan 2004 19:38:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i080cNkm017293 for ipv6-archive@odin.ietf.org; Wed, 7 Jan 2004 19:38:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeOBq-0004Uq-VD for ipv6-web-archive@optimus.ietf.org; Wed, 07 Jan 2004 19:38:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15876 for ; Wed, 7 Jan 2004 19:38:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeOBp-0003Hw-00 for ipv6-web-archive@ietf.org; Wed, 07 Jan 2004 19:38:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeOAJ-0003CH-00 for ipv6-web-archive@ietf.org; Wed, 07 Jan 2004 19:36:48 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AeO8g-00034b-00 for ipv6-web-archive@ietf.org; Wed, 07 Jan 2004 19:35:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeO8d-0003kR-WC; Wed, 07 Jan 2004 19:35:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeO8O-0003je-DP for ipv6@optimus.ietf.org; Wed, 07 Jan 2004 19:34:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15630 for ; Wed, 7 Jan 2004 19:34:45 -0500 (EST) From: Mukesh.Gupta@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeO8L-00031m-00 for ipv6@ietf.org; Wed, 07 Jan 2004 19:34:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeO5e-0002sm-00 for ipv6@ietf.org; Wed, 07 Jan 2004 19:32:00 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AeO11-0002iw-00 for ipv6@ietf.org; Wed, 07 Jan 2004 19:27:11 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i080R0429190 for ; Thu, 8 Jan 2004 02:27:00 +0200 (EET) Received: from daebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 8 Jan 2004 02:26:59 +0200 Received: from daebe009.NOE.Nokia.com ([10.241.35.109]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 7 Jan 2004 16:26:44 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3D57E.17EE1F44" Subject: RE: draft-ietf-ipngwg-icmp-v3-02.txt: Rate Limiting Methods Date: Wed, 7 Jan 2004 18:26:44 -0600 Message-ID: <8D260779A766FB4A9C1739A476F84FA42ABE54@daebe009.americas.nokia.com> Thread-Topic: draft-ietf-ipngwg-icmp-v3-02.txt: Rate Limiting Methods Thread-Index: AcPVIsr3NT6N0RoTTjuJKzFblXi0egAWUvFAAABW4hA= To: Cc: X-OriginalArrivalTime: 08 Jan 2004 00:26:44.0797 (UTC) FILETIME=[185ED6D0:01C3D57E] Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.3 required=5.0 tests=AWL,HTML_40_50,HTML_MESSAGE, MAILTO_TO_SPAM_ADDR,NO_REAL_NAME autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C3D57E.17EE1F44 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Oops !! stupid mistake of mine :) =20 The number of packets from A to B will be limited by the thin link and = thus B won't have to send ICMP back at a higher rate. =20 Regards Mukesh -----Original Message----- From: Gupta Mukesh (Nokia-NET/MtView)=20 Sent: Wednesday, January 07, 2004 4:19 PM To: 'ext Fred Templin' Cc: ipv6@ietf.org Subject: RE: draft-ietf-ipngwg-icmp-v3-02.txt: Rate Limiting Methods Fred, =20 Rethinking about the following example of yours. Do we need to consider the asymmetric paths between A and B ? I guess, the problem can be seen with even symmetric path. Let say the network is like =20 A <--- 1gig ---> C <--- 56 kbps --> D <--- 1 gig ---> B =20 Now A starts sending some packets and B generates ICMPv6 error=20 messages. If B is using bandwidth-based function for limiting the rate, it would calculate the percentage using 1 gig link's bandwidth and will=20 overload the thin link between C & D. =20 Am I missing something ? =20 Regards Mukesh -----Original Message----- From: ext Fred Templin [mailto:osprey67@yahoo.com] Sent: Wednesday, January 07, 2004 5:32 AM To: Margaret Wasserman; Gupta Mukesh (Nokia-NET/MtView) Cc: ipv6@ietf.org Subject: Re: draft-ietf-ipngwg-icmp-v3-02.txt: Rate Limiting Methods Margaret, =20 On further consideration, I think the bandwidth-based method might = actually be dangerous in some situations. Suppose there were asymmetric paths between nodes A and B; the path A->B consisting of all 1Gbps links and the path B->A consisting of at least one long, thin link (56Kb modem, = 3GPP wireless, etc.) Even if B is able to authenticate the source addresses = in packets it receives from A, if the bandwidth-based method is used based on a percentage of the bandwith of B's outgoing 1Gbps interface the = queue on a router at the head of a long thin link on the path B->A will = overflow. In other words, B might cause harmful denial-of-service if it blindly uses = a bandwidth-based estimate, since it has no way of knowing whether long, thin links will occur on the return path. =20 As to timer-based, I think Mukesh has already given a good reason as to why it is suboptimal; I think an arguement could also be constructed = that shows it to cause interoperability problems in some cases. So, I find myself in the rare position of agreeing with Pekka on this subject. =20 Fred osprey67@yahoo.com =20 ------_=_NextPart_001_01C3D57E.17EE1F44 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Oops = !! stupid=20 mistake of mine :)
 
The = number of=20 packets from A to B will be limited by the thin link and=20 thus
B = won't have to send=20 ICMP back at a higher rate.
 
Regards
Mukesh
-----Original Message-----
From: Gupta Mukesh=20 (Nokia-NET/MtView)
Sent: Wednesday, January 07, 2004 4:19=20 PM
To: 'ext Fred Templin'
Cc:=20 ipv6@ietf.org
Subject: RE: draft-ietf-ipngwg-icmp-v3-02.txt: = Rate=20 Limiting Methods

Fred,
 
Rethinking about the following example of yours. Do we need to=20 consider
the=20 asymmetric paths between A and B ? I guess, the problem can be=20 seen
with even=20 symmetric path. Let say the network is=20 like
 
A <---=20 1gig ---> C <--- 56 kbps --> D <--- 1 gig --->=20 B
 
Now A=20 starts sending some packets and B generates ICMPv6 error=20
messages.=20 If B is using bandwidth-based function for limiting the=20 rate,
it would=20 calculate the percentage using 1 gig link's bandwidth and will=20
overload=20 the thin link between C & = D.
 
Am I=20 missing something ?
 
Regards
Mukesh
-----Original Message-----
From: ext Fred Templin = [mailto:osprey67@yahoo.com]
Sent: Wednesday, January 07, = 2004 5:32=20 AM
To: Margaret Wasserman; Gupta Mukesh=20 (Nokia-NET/MtView)
Cc: ipv6@ietf.org
Subject: = Re:=20 draft-ietf-ipngwg-icmp-v3-02.txt: Rate Limiting = Methods

Margaret,
 
On further consideration, I think the bandwidth-based method = might=20 actually
be dangerous in some situations. Suppose there were = asymmetric=20 paths
between nodes A and B; the path A->B consisting of all 1Gbps = links=20 and
the path B->A consisting of at least one long, thin link = (56Kb=20 modem, 3GPP
wireless, etc.) Even if B is able to authenticate the source = addresses=20 in
packets it receives from A, if the bandwidth-based method is = used=20 based
on a percentage of the bandwith of B's outgoing 1Gbps interface = the=20 queue
on a router at the head of a long thin link on the path = B->A=20 will overflow. In
other words, B might cause harmful = denial-of-service if it=20 blindly uses a
bandwidth-based estimate, since it has no way of knowing = whether=20 long,
thin links will occur on the return path.
 
As to timer-based, I think Mukesh has already given a good = reason as=20 to
why it is suboptimal; I think an arguement could = also be=20 constructed that
shows it to cause interoperability problems in some cases. So, = I=20 find
myself in the rare position of agreeing with Pekka on this=20 subject.
 
Fred
------_=_NextPart_001_01C3D57E.17EE1F44-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Jan 7 23:52:53 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23937 for ; Wed, 7 Jan 2004 23:52:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeS9h-00071p-JW for ipv6-archive@odin.ietf.org; Wed, 07 Jan 2004 23:52:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i084qPLY027011 for ipv6-archive@odin.ietf.org; Wed, 7 Jan 2004 23:52:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeS9h-00071a-F9 for ipv6-web-archive@optimus.ietf.org; Wed, 07 Jan 2004 23:52:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23867 for ; Wed, 7 Jan 2004 23:52:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeS9f-0000aJ-00 for ipv6-web-archive@ietf.org; Wed, 07 Jan 2004 23:52:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeS86-0000Sc-00 for ipv6-web-archive@ietf.org; Wed, 07 Jan 2004 23:50:46 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AeS5u-0000HJ-00 for ipv6-web-archive@ietf.org; Wed, 07 Jan 2004 23:48:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeS5R-0006eI-Sk; Wed, 07 Jan 2004 23:48:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeS4x-0006cg-2w for ipv6@optimus.ietf.org; Wed, 07 Jan 2004 23:47:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23770 for ; Wed, 7 Jan 2004 23:47:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeS4u-0000Cd-00 for ipv6@ietf.org; Wed, 07 Jan 2004 23:47:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeS2p-00001u-00 for ipv6@ietf.org; Wed, 07 Jan 2004 23:45:19 -0500 Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx with esmtp (Exim 4.12) id 1AeS15-0007fP-00 for ipv6@ietf.org; Wed, 07 Jan 2004 23:43:31 -0500 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HR500J01MFJW9@mailout2.samsung.com> for ipv6@ietf.org; Thu, 08 Jan 2004 13:42:55 +0900 (KST) Received: from ep_mmp2 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HR500447MFJXK@mailout2.samsung.com> for ipv6@ietf.org; Thu, 08 Jan 2004 13:42:55 +0900 (KST) Received: from LocalHost ([168.219.203.183]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HR5002CJMFI6O@mmp2.samsung.com> for ipv6@ietf.org; Thu, 08 Jan 2004 13:42:54 +0900 (KST) Date: Thu, 08 Jan 2004 13:42:39 +0900 From: Soohong Daniel Park Subject: Update IPv6 over ppp To: IPv6 WG Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Hi IPv6 WG added this work into the current work list. - Update IPv6 over PPP (RFC2472) and publish (may be done in PPP Extension w.g.). Could somebody let me know what I-D is for this work ? I failed in finding it both IPv6 w.g. and PPPEXT w.g. Best wishes... Daniel (Soohong Daniel Park) Mobile Platform Laboratory, SAMSUNG Electronics. spamcontrol -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Jan 8 00:13:08 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24600 for ; Thu, 8 Jan 2004 00:13:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeSTJ-0008C4-9N for ipv6-archive@odin.ietf.org; Thu, 08 Jan 2004 00:12:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i085CfB0031494 for ipv6-archive@odin.ietf.org; Thu, 8 Jan 2004 00:12:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeSTJ-0008Bt-0P for ipv6-web-archive@optimus.ietf.org; Thu, 08 Jan 2004 00:12:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24571 for ; Thu, 8 Jan 2004 00:12:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeSTG-0001lm-00 for ipv6-web-archive@ietf.org; Thu, 08 Jan 2004 00:12:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeSRH-0001eu-00 for ipv6-web-archive@ietf.org; Thu, 08 Jan 2004 00:10:36 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AeSPt-0001ZV-00 for ipv6-web-archive@ietf.org; Thu, 08 Jan 2004 00:09:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeSPm-0007qr-Ft; Thu, 08 Jan 2004 00:09:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeSPA-0007pu-It for ipv6@optimus.ietf.org; Thu, 08 Jan 2004 00:08:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24442 for ; Thu, 8 Jan 2004 00:08:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeSP8-0001XB-00 for ipv6@ietf.org; Thu, 08 Jan 2004 00:08:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeSNT-0001Tu-00 for ipv6@ietf.org; Thu, 08 Jan 2004 00:06:41 -0500 Received: from web80502.mail.yahoo.com ([66.218.79.72]) by ietf-mx with smtp (Exim 4.12) id 1AeSMk-0001Nx-00 for ipv6@ietf.org; Thu, 08 Jan 2004 00:05:54 -0500 Message-ID: <20040108050525.59186.qmail@web80502.mail.yahoo.com> Received: from [63.197.18.101] by web80502.mail.yahoo.com via HTTP; Wed, 07 Jan 2004 21:05:25 PST Date: Wed, 7 Jan 2004 21:05:25 -0800 (PST) From: Fred Templin Subject: RE: draft-ietf-ipngwg-icmp-v3-02.txt: Rate Limiting Methods To: Mukesh.Gupta@nokia.com Cc: ipv6@ietf.org In-Reply-To: <8D260779A766FB4A9C1739A476F84FA42ABE54@daebe009.americas.nokia.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-886898233-1073538325=:58280" Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.2 required=5.0 tests=AWL,FROM_ENDS_IN_NUMS, HTML_40_50,HTML_MESSAGE,MAILTO_TO_SPAM_ADDR autolearn=no version=2.60 --0-886898233-1073538325=:58280 Content-Type: text/plain; charset=us-ascii No worries; I also had a mistake in my earlier messages when I failed to mention the active queue management for last-hop routers in front slow links recommended by the RFC 3150 BCP. (I don't know if the recommendation extends to the case of the slow link occurring somewhere in the *middle* of the network, however.) Active queue management (i.e., RED) deals with bursts much better than the de facto tail-drop, which would seem to fit well with our current leaning toward the token bucket rate-limiting scheme. Fred osprey67@yahoo.com Mukesh.Gupta@nokia.com wrote: Oops !! stupid mistake of mine :) The number of packets from A to B will be limited by the thin link and thus B won't have to send ICMP back at a higher rate. Regards Mukesh -----Original Message----- From: Gupta Mukesh (Nokia-NET/MtView) Sent: Wednesday, January 07, 2004 4:19 PM To: 'ext Fred Templin' Cc: ipv6@ietf.org Subject: RE: draft-ietf-ipngwg-icmp-v3-02.txt: Rate Limiting Methods Fred, Rethinking about the following example of yours. Do we need to consider the asymmetric paths between A and B ? I guess, the problem can be seen with even symmetric path. Let say the network is like A <--- 1gig ---> C <--- 56 kbps --> D <--- 1 gig ---> B Now A starts sending some packets and B generates ICMPv6 error messages. If B is using bandwidth-based function for limiting the rate, it would calculate the percentage using 1 gig link's bandwidth and will overload the thin link between C & D. Am I missing something ? Regards Mukesh -----Original Message----- From: ext Fred Templin [mailto:osprey67@yahoo.com] Sent: Wednesday, January 07, 2004 5:32 AM To: Margaret Wasserman; Gupta Mukesh (Nokia-NET/MtView) Cc: ipv6@ietf.org Subject: Re: draft-ietf-ipngwg-icmp-v3-02.txt: Rate Limiting Methods Margaret, On further consideration, I think the bandwidth-based method might actually be dangerous in some situations. Suppose there were asymmetric paths between nodes A and B; the path A->B consisting of all 1Gbps links and the path B->A consisting of at least one long, thin link (56Kb modem, 3GPP wireless, etc.) Even if B is able to authenticate the source addresses in packets it receives from A, if the bandwidth-based method is used based on a percentage of the bandwith of B's outgoing 1Gbps interface the queue on a router at the head of a long thin link on the path B->A will overflow. In other words, B might cause harmful denial-of-service if it blindly uses a bandwidth-based estimate, since it has no way of knowing whether long, thin links will occur on the return path. As to timer-based, I think Mukesh has already given a good reason as to why it is suboptimal; I think an arguement could also be constructed that shows it to cause interoperability problems in some cases. So, I find myself in the rare position of agreeing with Pekka on this subject. Fred osprey67@yahoo.com --0-886898233-1073538325=:58280 Content-Type: text/html; charset=us-ascii
No worries; I also had a mistake in my earlier messages when I failed to
mention the active queue management for last-hop routers in front slow links
recommended by the RFC 3150 BCP. (I don't know if the recommendation
extends to the case of the slow link occurring somewhere in the *middle*
of the network, however.) Active queue management (i.e., RED) deals with
bursts much better than the de facto tail-drop, which would seem to fit well
with our current leaning toward the token bucket rate-limiting scheme.
 
Fred
 


Mukesh.Gupta@nokia.com wrote:
Oops !! stupid mistake of mine :)
 
The number of packets from A to B will be limited by the thin link and thus
B won't have to send ICMP back at a higher rate.
 
Regards
Mukesh
-----Original Message-----
From: Gupta Mukesh (Nokia-NET/MtView)
Sent: Wednesday, January 07, 2004 4:19 PM
To: 'ext Fred Templin'
Cc: ipv6@ietf.org
Subject: RE: draft-ietf-ipngwg-icmp-v3-02.txt: Rate Limiting Methods

Fred,
 
Rethinking about the following example of yours. Do we need to consider
the asymmetric paths between A and B ? I guess, the problem can be seen
with even symmetric path. Let say the network is like
 
A <--- 1gig ---> C <--- 56 kbps --> D <--- 1 gig ---> B
 
Now A starts sending some packets and B generates ICMPv6 error
messages. If B is using bandwidth-based function for limiting the rate,
it would calculate the percentage using 1 gig link's bandwidth and will
overload the thin link between C & D.
 
Am I missing something ?
 
Regards
Mukesh
-----Original Message-----
From: ext Fred Templin [mailto:osprey67@yahoo.com]
Sent: Wednesday, January 07, 2004 5:32 AM
To: Margaret Wasserman; Gupta Mukesh (Nokia-NET/MtView)
Cc: ipv6@ietf.org
Subject: Re: draft-ietf-ipngwg-icmp-v3-02.txt: Rate Limiting Methods

Margaret,
 
On further consideration, I think the bandwidth-based method might actually
be dangerous in some situations. Suppose there were asymmetric paths
between nodes A and B; the path A->B consisting of all 1Gbps links and
the path B->A consisting of at least one long, thin link (56Kb modem, 3GPP
wireless, etc.) Even if B is able to authenticate the source addresses in
packets it receives from A, if the bandwidth-based method is used based
on a percentage of the bandwith of B's outgoing 1Gbps interface the queue
on a router at the head of a long thin link on the path B->A will overflow. In
other words, B might cause harmful denial-of-service if it blindly uses a
bandwidth-based estimate, since it has no way of knowing whether long,
thin links will occur on the return path.
 
As to timer-based, I think Mukesh has already given a good reason as to
why it is suboptimal; I think an arguement could also be constructed that
shows it to cause interoperability problems in some cases. So, I find
myself in the rare position of agreeing with Pekka on this subject.
 
Fred
--0-886898233-1073538325=:58280-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Jan 8 06:41:52 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18305 for ; Thu, 8 Jan 2004 06:41:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeYXV-0002F3-Ar for ipv6-archive@odin.ietf.org; Thu, 08 Jan 2004 06:41:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i08BfPAZ008613 for ipv6-archive@odin.ietf.org; Thu, 8 Jan 2004 06:41:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeYXU-0002Eq-P6 for ipv6-web-archive@optimus.ietf.org; Thu, 08 Jan 2004 06:41:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18173 for ; Thu, 8 Jan 2004 06:41:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeYXQ-0003Zo-00 for ipv6-web-archive@ietf.org; Thu, 08 Jan 2004 06:41:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeYV7-0003Jn-00 for ipv6-web-archive@ietf.org; Thu, 08 Jan 2004 06:38:57 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AeYU8-000329-00 for ipv6-web-archive@ietf.org; Thu, 08 Jan 2004 06:37:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeYTG-0001Ue-IK; Thu, 08 Jan 2004 06:37:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeYS9-0001TB-KN for ipv6@optimus.ietf.org; Thu, 08 Jan 2004 06:36:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17849 for ; Thu, 8 Jan 2004 06:35:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeYS0-0002xA-00 for ipv6@ietf.org; Thu, 08 Jan 2004 06:35:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeYO7-0002fp-00 for ipv6@ietf.org; Thu, 08 Jan 2004 06:31:43 -0500 Received: from uillean.fuaim.com ([206.197.161.140]) by ietf-mx with esmtp (Exim 4.12) id 1AeYJC-0002Sz-00 for ipv6@ietf.org; Thu, 08 Jan 2004 06:26:39 -0500 Received: from clairseach.fuaim.com (clairseach.fuaim.com [206.197.161.141]) by uillean.fuaim.com (8.11.6/8.11.6) with ESMTP id i08BPiV10416; Thu, 8 Jan 2004 03:25:44 -0800 Received: from innovationslab.net (md-wmnsmd-cuda2-c6a-a-4.chvlva.adelphia.net [68.65.120.4]) (authenticated bits=0) by clairseach.fuaim.com (8.12.8/8.12.8) with ESMTP id i08BXsbS018521 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 8 Jan 2004 03:33:57 -0800 Message-ID: <3FFD3DE0.3080901@innovationslab.net> Date: Thu, 08 Jan 2004 06:24:16 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Soohong Daniel Park CC: ipv6@ietf.org Subject: Re: Update IPv6 over ppp References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Daniel, An I-D has not been released for this work as of yet. Srihari Varada (varada@txc.com) is the editor for the doc and is in the process of collecting update information. Regards, Brian Soohong Daniel Park wrote: > Hi > > IPv6 WG added this work into the current work list. > - Update IPv6 over PPP (RFC2472) and publish > (may be done in PPP Extension w.g.). > > Could somebody let me know what I-D is for this work ? > I failed in finding it both IPv6 w.g. and PPPEXT w.g. > > > Best wishes... > > Daniel (Soohong Daniel Park) > Mobile Platform Laboratory, SAMSUNG Electronics. > > > > spamcontrol > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Jan 8 10:48:43 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28888 for ; Thu, 8 Jan 2004 10:48:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AecOO-0006wR-3M for ipv6-archive@odin.ietf.org; Thu, 08 Jan 2004 10:48:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i08FmG8Z026677 for ipv6-archive@odin.ietf.org; Thu, 8 Jan 2004 10:48:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AecON-0006wC-VU for ipv6-web-archive@optimus.ietf.org; Thu, 08 Jan 2004 10:48:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28751 for ; Thu, 8 Jan 2004 10:48:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AecOG-0002Wp-00 for ipv6-web-archive@ietf.org; Thu, 08 Jan 2004 10:48:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AecH8-00026z-00 for ipv6-web-archive@ietf.org; Thu, 08 Jan 2004 10:40:47 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AecBL-0001l1-00 for ipv6-web-archive@ietf.org; Thu, 08 Jan 2004 10:34:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AecAb-0005Ug-Nc; Thu, 08 Jan 2004 10:34:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aec9u-0005TP-22 for ipv6@optimus.ietf.org; Thu, 08 Jan 2004 10:33:18 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27954; Thu, 8 Jan 2004 10:33:13 -0500 (EST) Message-Id: <200401081533.KAA27954@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipv6@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipv6-rfc2011-update-05.txt Date: Thu, 08 Jan 2004 10:33:12 -0500 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Version 6 Working Group Working Group of the IETF. Title : Management Information Base for the Internet Protocol (IP) Author(s) : S. Routhier Filename : draft-ietf-ipv6-rfc2011-update-05.txt Pages : 124 Date : 2004-1-7 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for implementations of the Internet Protocol (IP) in an IP version independent manner. This memo obsoletes RFCs 2011, 2465 and 2466. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-rfc2011-update-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipv6-rfc2011-update-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipv6-rfc2011-update-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-1-7161141.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-rfc2011-update-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-rfc2011-update-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-1-7161141.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Jan 8 17:29:07 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15016 for ; Thu, 8 Jan 2004 17:29:07 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aeidr-0001Tp-EI for ipv6-archive@odin.ietf.org; Thu, 08 Jan 2004 17:28:40 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i08MSdfh005689 for ipv6-archive@odin.ietf.org; Thu, 8 Jan 2004 17:28:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aeidq-0001Tf-Qx for ipv6-web-archive@optimus.ietf.org; Thu, 08 Jan 2004 17:28:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14971 for ; Thu, 8 Jan 2004 17:28:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aeidn-0003Ss-00 for ipv6-web-archive@ietf.org; Thu, 08 Jan 2004 17:28:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aeibp-0003I9-00 for ipv6-web-archive@ietf.org; Thu, 08 Jan 2004 17:26:34 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Aeia2-000350-00 for ipv6-web-archive@ietf.org; Thu, 08 Jan 2004 17:24:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeiZP-0000yF-5j; Thu, 08 Jan 2004 17:24:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeiYy-0000x3-CM for ipv6@optimus.ietf.org; Thu, 08 Jan 2004 17:23:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14463 for ; Thu, 8 Jan 2004 17:23:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeiYv-0002uO-00 for ipv6@ietf.org; Thu, 08 Jan 2004 17:23:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeiUv-0002Zj-00 for ipv6@ietf.org; Thu, 08 Jan 2004 17:19:26 -0500 Received: from plant.sfc.wide.ad.jp ([203.178.143.91]) by ietf-mx with esmtp (Exim 4.12) id 1AeiPM-000251-00 for ipv6@ietf.org; Thu, 08 Jan 2004 17:13:40 -0500 Received: from localhost (localhost [127.0.0.1]) by plant.sfc.wide.ad.jp (Postfix) with ESMTP id 8980A1B56B; Fri, 9 Jan 2004 07:13:10 +0900 (JST) Date: Fri, 09 Jan 2004 07:13:10 +0900 (JST) Message-Id: <20040109.071310.52184121.yasu@sfc.wide.ad.jp> To: osprey67@yahoo.com Cc: margaret@thingmagic.com, Mukesh.Gupta@nokia.com, ipv6@ietf.org Subject: Re: draft-ietf-ipngwg-icmp-v3-02.txt: Rate Limiting Methods From: Yasuhiro Ohara In-Reply-To: <20040107133224.44364.qmail@web80505.mail.yahoo.com> References: <5.1.0.14.2.20040106210337.0316d600@ms101.mail1.com> <20040107133224.44364.qmail@web80505.mail.yahoo.com> X-Mailer: Mew version 3.1 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, only roughly going through this thread but ... > On further consideration, I think the bandwidth-based method might actually > be dangerous in some situations. Suppose there were asymmetric paths > between nodes A and B; the path A->B consisting of all 1Gbps links and > the path B->A consisting of at least one long, thin link (56Kb modem, 3GPP > wireless, etc.) Even if B is able to authenticate the source addresses in > packets it receives from A, if the bandwidth-based method is used based > on a percentage of the bandwith of B's outgoing 1Gbps interface the queue > on a router at the head of a long thin link on the path B->A will overflow. In > other words, B might cause harmful denial-of-service if it blindly uses a > bandwidth-based estimate, since it has no way of knowing whether long, > thin links will occur on the return path. Only being dangerous in some situations do not necessarily mean that it should be deleted completely. If there's still cases where the feature can be used sufficiently, the feature should survive, No ? regards, yasu -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Jan 8 18:37:10 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18686 for ; Thu, 8 Jan 2004 18:37:10 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aejhk-0004KF-Jy for ipv6-archive@odin.ietf.org; Thu, 08 Jan 2004 18:36:44 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i08NaiHa016624 for ipv6-archive@odin.ietf.org; Thu, 8 Jan 2004 18:36:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aejhk-0004K3-Dq for ipv6-web-archive@optimus.ietf.org; Thu, 08 Jan 2004 18:36:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18679 for ; Thu, 8 Jan 2004 18:36:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aejhh-00005g-00 for ipv6-web-archive@ietf.org; Thu, 08 Jan 2004 18:36:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aejfy-0007n2-00 for ipv6-web-archive@ietf.org; Thu, 08 Jan 2004 18:34:55 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Aejfb-0007gl-00 for ipv6-web-archive@ietf.org; Thu, 08 Jan 2004 18:34:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aejf7-0003zz-9N; Thu, 08 Jan 2004 18:34:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aejed-0003zX-De for ipv6@optimus.ietf.org; Thu, 08 Jan 2004 18:33:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18405 for ; Thu, 8 Jan 2004 18:33:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AejeX-0007d9-00 for ipv6@ietf.org; Thu, 08 Jan 2004 18:33:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aejcb-0007NL-00 for ipv6@ietf.org; Thu, 08 Jan 2004 18:31:26 -0500 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aejb6-00079o-00 for ipv6@ietf.org; Thu, 08 Jan 2004 18:29:52 -0500 Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id XAA10803 for ; Thu, 8 Jan 2004 23:29:51 GMT Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id XAA21487 for ; Thu, 8 Jan 2004 23:29:41 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i08NThI15375 for ipv6@ietf.org; Thu, 8 Jan 2004 23:29:43 GMT Date: Thu, 8 Jan 2004 23:29:43 +0000 From: Tim Chown To: ipv6@ietf.org Subject: Re: draft-ietf-ipngwg-icmp-v3-02.txt: Rate Limiting Methods Message-ID: <20040108232943.GR14398@login.ecs.soton.ac.uk> Mail-Followup-To: ipv6@ietf.org References: <8D260779A766FB4A9C1739A476F84FA42ABE50@daebe009.americas.nokia.com> <4.3.2.7.2.20040107134344.02410408@mailhost.iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4.3.2.7.2.20040107134344.02410408@mailhost.iprg.nokia.com> User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 On Wed, Jan 07, 2004 at 03:03:10PM -0800, Bob Hinden wrote: > > I would be happy if the text was expanded to say that token bucket is the > preferred approach and describe the limitations of the other two. I think > this would give the people implementing ICMPv6 the guidance they need to > build a rate-limiting function that is appropriate for their implementation. This sounds good. Tim -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Jan 8 19:27:12 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20019 for ; Thu, 8 Jan 2004 19:27:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AekU9-0006Mn-GS for ipv6-archive@odin.ietf.org; Thu, 08 Jan 2004 19:26:45 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i090Qj4O024467 for ipv6-archive@odin.ietf.org; Thu, 8 Jan 2004 19:26:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AekU9-0006MY-CV for ipv6-web-archive@optimus.ietf.org; Thu, 08 Jan 2004 19:26:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19966 for ; Thu, 8 Jan 2004 19:26:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AekU7-0002i3-00 for ipv6-web-archive@ietf.org; Thu, 08 Jan 2004 19:26:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AekS9-0002V7-00 for ipv6-web-archive@ietf.org; Thu, 08 Jan 2004 19:24:42 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AekO4-0002Gb-00 for ipv6-web-archive@ietf.org; Thu, 08 Jan 2004 19:20:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AekNf-0005un-UA; Thu, 08 Jan 2004 19:20:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AekMh-0005tV-8f for ipv6@optimus.ietf.org; Thu, 08 Jan 2004 19:19:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19659 for ; Thu, 8 Jan 2004 19:18:55 -0500 (EST) From: Mukesh.Gupta@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AekMV-0002FB-00 for ipv6@ietf.org; Thu, 08 Jan 2004 19:18:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AekH1-0001yc-00 for ipv6@ietf.org; Thu, 08 Jan 2004 19:13:13 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AekCn-0001lt-00 for ipv6@ietf.org; Thu, 08 Jan 2004 19:08:49 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i0908d419666 for ; Fri, 9 Jan 2004 02:08:39 +0200 (EET) Received: from daebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 9 Jan 2004 02:08:39 +0200 Received: from daebe009.NOE.Nokia.com ([10.241.35.109]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 8 Jan 2004 16:08:36 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: ICMPv6 Rate Limiting Methods: Revised Text Date: Thu, 8 Jan 2004 18:08:36 -0600 Message-ID: <8D260779A766FB4A9C1739A476F84FA42ABE56@daebe009.americas.nokia.com> Thread-Topic: draft-ietf-ipngwg-icmp-v3-02.txt: Rate Limiting Methods Thread-Index: AcPWP/0cShQBx9aZQ4uLFuei3qF+rQAA0SlA To: X-OriginalArrivalTime: 09 Jan 2004 00:08:36.0745 (UTC) FILETIME=[BA410790:01C3D644] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi All, As I sensed after all the discussion we had, the WG will prefer to expand the text to prefer token-bucket method and describe the limitations of the other two. If my conclusion is wrong, feel free to scream :) Otherwise, here is the revised text. Please review the text and let me know if we need to=20 add/modify/correct anything. If you want something to be=20 changed, please send me the new proposed text. I couldn't decide what the correct default values of the=20 parameters should be. So I haven't mentioned anything. If anyone wants to add, please send me the values. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D (f) Finally, in order to limit the bandwidth and forwarding costs incurred sending ICMPv6 error messages, an IPv6 node MUST limit the rate of ICMPv6 error messages it sends. This situation may occur when a source sending a stream of erroneous packets fails to heed the resulting ICMPv6 error messages. There are a variety of ways of implementing the rate-limiting function, for example: (f.1) Timer-based - for example, limiting the rate of transmission of error messages to at most once every T milliseconds. (f.2) Bandwidth-based - for example, limiting the rate at which error messages are sent from a particular interface to some fraction F of the attached link's bandwidth. (f.3) Token-bucket based - for example, allowing up to B back- to-back error messages to be transmitted in a burst, but limiting the average rate of transmission to N where N can either be packets/seconds or a fraction of the attached link's bandwidth. The limit parameters (e.g., T, F, B and N in the above examples) MUST be configurable for the node. Token-bucket based function should be preferrable over the other two. If Timer-based or Bandwidth-based function is chosen because of the simplicity of implementation, proper care must be taken in choosing the value of T or F. Values of T that are higher than 20-30 might break traceroute. A global value of F per node might not be appropriate for all the links attached to the node. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D Regards Mukesh -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Jan 8 21:41:07 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25130 for ; Thu, 8 Jan 2004 21:41:07 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AemZj-00042P-Ue for ipv6-archive@odin.ietf.org; Thu, 08 Jan 2004 21:40:40 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i092edm4015518 for ipv6-archive@odin.ietf.org; Thu, 8 Jan 2004 21:40:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AemZj-00042D-K0 for ipv6-web-archive@optimus.ietf.org; Thu, 08 Jan 2004 21:40:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25065 for ; Thu, 8 Jan 2004 21:40:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AemZg-0004Yo-00 for ipv6-web-archive@ietf.org; Thu, 08 Jan 2004 21:40:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AemXj-0004PU-00 for ipv6-web-archive@ietf.org; Thu, 08 Jan 2004 21:38:36 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AemVs-0004JC-00 for ipv6-web-archive@ietf.org; Thu, 08 Jan 2004 21:36:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AemVG-0003Oa-I1; Thu, 08 Jan 2004 21:36:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AemUM-0003Lo-2N for ipv6@optimus.ietf.org; Thu, 08 Jan 2004 21:35:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24933 for ; Thu, 8 Jan 2004 21:35:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AemUI-0004E2-00 for ipv6@ietf.org; Thu, 08 Jan 2004 21:35:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AemSD-000474-00 for ipv6@ietf.org; Thu, 08 Jan 2004 21:32:53 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AemQj-000411-00 for ipv6@ietf.org; Thu, 08 Jan 2004 21:31:21 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i092Unr05314; Thu, 8 Jan 2004 18:30:49 -0800 X-mProtect: <200401090230> Nokia Silicon Valley Messaging Protection Received: from ftemplin.iprg.nokia.com (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdVBJlLU; Thu, 08 Jan 2004 18:30:48 PST Message-ID: <3FFE1268.3010902@iprg.nokia.com> Date: Thu, 08 Jan 2004 18:31:04 -0800 From: Fred Templin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mukesh.Gupta@nokia.com CC: ipv6@ietf.org Subject: Re: ICMPv6 Rate Limiting Methods: Revised Text References: <8D260779A766FB4A9C1739A476F84FA42ABE56@daebe009.americas.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Mukesh.Gupta@nokia.com wrote: > If Timer-based or Bandwidth-based function is chosen because of > the simplicity of implementation, proper care must be taken in > choosing the value of T or F. Values of T that are higher than > 20-30 might break traceroute. A global value of F per node might > not be appropriate for all the links attached to the node. > Small change suggestion for the second sentence of the above paragraph: Values of T that are higher than 20-30 might break legitimate functionality that requires timely delivery of ICMPv6 error messages (e.g., traceroute), while smaller values might cause saturation of slow links. I'm also not entirely sure about your cautions regarding "a global value of F per node"; the text of f.2 says: "limiting the rate at which error messages are sent from a particular interface to some fraction F of the attached link's bandwidth" - it doesn't say anything about a global value of F for the node. Thanks - Fred ftemplin@iprg.nokia.com -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Jan 9 16:02:49 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15323 for ; Fri, 9 Jan 2004 16:02:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Af3lt-0006sO-Fq for ipv6-archive@odin.ietf.org; Fri, 09 Jan 2004 16:02:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i09L2LuG026426 for ipv6-archive@odin.ietf.org; Fri, 9 Jan 2004 16:02:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Af3lt-0006s8-Af for ipv6-web-archive@optimus.ietf.org; Fri, 09 Jan 2004 16:02:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15173 for ; Fri, 9 Jan 2004 16:02:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Af3lr-0005wS-00 for ipv6-web-archive@ietf.org; Fri, 09 Jan 2004 16:02:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Af3kA-0005ji-00 for ipv6-web-archive@ietf.org; Fri, 09 Jan 2004 16:00:35 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Af3iR-0005ac-01 for ipv6-web-archive@ietf.org; Fri, 09 Jan 2004 15:58:47 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1Af3bg-0006SJ-8H for ipv6-web-archive@ietf.org; Fri, 09 Jan 2004 15:51:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Af3aw-0006NQ-Ex; Fri, 09 Jan 2004 15:51:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Af3Zw-0006M4-K5 for ipv6@optimus.ietf.org; Fri, 09 Jan 2004 15:50:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14756 for ; Fri, 9 Jan 2004 15:49:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Af3Zv-0005BI-00 for ipv6@ietf.org; Fri, 09 Jan 2004 15:49:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Af3YB-00056U-00 for ipv6@ietf.org; Fri, 09 Jan 2004 15:48:12 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1Af3XC-0004uj-00 for ipv6@ietf.org; Fri, 09 Jan 2004 15:47:10 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 09 Jan 2004 12:47:49 +0000 Received: from cisco.com (dhcp-171-71-254-178.cisco.com [171.71.254.178]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id i09KkbGN009252 for ; Fri, 9 Jan 2004 12:46:38 -0800 (PST) Message-ID: <3FFF1328.9050709@cisco.com> Date: Fri, 09 Jan 2004 12:46:32 -0800 From: Zachary Amsden Organization: Cisco Systems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031208 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: ICMPv6 Rate Limiting Methods: Revised Text References: <8D260779A766FB4A9C1739A476F84FA42ABE56@daebe009.americas.nokia.com> In-Reply-To: <8D260779A766FB4A9C1739A476F84FA42ABE56@daebe009.americas.nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit It seems to me that "back to back" is ill-defined. It is highly unlikely that the ICMP error packets will be transmitted with no other transmissions in between, which "back to back" seems to imply. The burst allowance should probably be defined as "allowing a burst of N packets over Ts seconds", or something along these lines. Also, there had been much discussion about how certain methods are lacking and should be omitted. I don't think any should be omitted - consider the possibility of combining all three methods to clamp the ICMP rate in different domains. In the presence of asymmetric bandwidth (consider ADSL), or asymmetric routing, the token bucket method can cause floods that would be prevented if the bandwidth method was used as an additional clamping mechanism. Perhaps something like this should be mentioned in the text as well. One other thing - "values greater than 20-30 might break traceroute" is stated with no explanation as to why, and it seems that 20-30 is an arbitrary number (with no explicit units) that will change in the future as bandwidth capacity increases. I agree with the sentiment of the statement, but think there should be some explanation as to how an implementor might compute this value (perhaps how the 20-30 was derived). Zachary Amsden zamsden@cisco.com Mukesh.Gupta@nokia.com wrote: >Hi All, > >As I sensed after all the discussion we had, the WG will prefer >to expand the text to prefer token-bucket method and describe >the limitations of the other two. If my conclusion is wrong, >feel free to scream :) Otherwise, here is the revised text. > >Please review the text and let me know if we need to >add/modify/correct anything. If you want something to be >changed, please send me the new proposed text. > >I couldn't decide what the correct default values of the >parameters should be. So I haven't mentioned anything. If >anyone wants to add, please send me the values. > >======================================================= > (f) Finally, in order to limit the bandwidth and forwarding costs > incurred sending ICMPv6 error messages, an IPv6 node MUST limit > the rate of ICMPv6 error messages it sends. This situation may > occur when a source sending a stream of erroneous packets fails > to heed the resulting ICMPv6 error messages. There are a variety > of ways of implementing the rate-limiting function, for example: > > (f.1) Timer-based - for example, limiting the rate of > transmission of error messages to at most once every T > milliseconds. > > (f.2) Bandwidth-based - for example, limiting the rate at which > error messages are sent from a particular interface to > some fraction F of the attached link's bandwidth. > > (f.3) Token-bucket based - for example, allowing up to B back- > to-back error messages to be transmitted in a burst, but > limiting the average rate of transmission to N where N > can either be packets/seconds or a fraction of the > attached link's bandwidth. > > The limit parameters (e.g., T, F, B and N in the above examples) > MUST be configurable for the node. > > Token-bucket based function should be preferrable over the other > two. > > If Timer-based or Bandwidth-based function is chosen because of > the simplicity of implementation, proper care must be taken in > choosing the value of T or F. Values of T that are higher than > 20-30 might break traceroute. A global value of F per node might > not be appropriate for all the links attached to the node. >======================================================= > >Regards >Mukesh > >-------------------------------------------------------------------- >IETF IPv6 working group mailing list >ipv6@ietf.org >Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Jan 9 18:32:31 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28865 for ; Fri, 9 Jan 2004 18:32:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Af66m-0005Xp-FH for ipv6-archive@odin.ietf.org; Fri, 09 Jan 2004 18:32:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i09NW40T021312 for ipv6-archive@odin.ietf.org; Fri, 9 Jan 2004 18:32:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Af66m-0005Xf-5r for ipv6-web-archive@optimus.ietf.org; Fri, 09 Jan 2004 18:32:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28836 for ; Fri, 9 Jan 2004 18:32:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Af66j-0004FC-00 for ipv6-web-archive@ietf.org; Fri, 09 Jan 2004 18:32:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Af64s-00049T-00 for ipv6-web-archive@ietf.org; Fri, 09 Jan 2004 18:30:07 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Af63Y-00044T-00 for ipv6-web-archive@ietf.org; Fri, 09 Jan 2004 18:28:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Af62r-0005BI-HD; Fri, 09 Jan 2004 18:28:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Af3Kp-0005IK-OZ for ipv6@optimus.ietf.org; Fri, 09 Jan 2004 15:34:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11284 for ; Fri, 9 Jan 2004 15:34:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Af3Kn-0002KP-00 for ipv6@ietf.org; Fri, 09 Jan 2004 15:34:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Af3El-0000vW-00 for ipv6@ietf.org; Fri, 09 Jan 2004 15:28:08 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1Af2uV-00062r-00 for ipv6@ietf.org; Fri, 09 Jan 2004 15:07:11 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 09 Jan 2004 12:07:25 +0000 Received: from cisco.com (dhcp-171-71-254-178.cisco.com [171.71.254.178]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id i09K6BGN016011; Fri, 9 Jan 2004 12:06:13 -0800 (PST) Message-ID: <3FFF09AF.80903@cisco.com> Date: Fri, 09 Jan 2004 12:06:07 -0800 From: Zachary Amsden Organization: Cisco Systems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031208 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mukesh.Gupta@nokia.com CC: ipv6@ietf.org Subject: Re: ICMPv6 Rate Limiting Methods: Revised Text References: <8D260779A766FB4A9C1739A476F84FA42ABE56@daebe009.americas.nokia.com> In-Reply-To: <8D260779A766FB4A9C1739A476F84FA42ABE56@daebe009.americas.nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit It seems to me that "back to back" is ill-defined. It is highly unlikely that the ICMP error packets will be transmitted with no other transmissions in between, which "back to back" seems to imply. The burst allowance should probably be defined as "allowing a burst of N packets over Ts seconds", or something along these lines. Also, there had been much discussion about how certain methods are lacking and should be omitted. I don't think any should be omitted - consider the possibility of combining all three methods to clamp the ICMP rate in different domains. In the presence of asymmetric bandwidth (consider ADSL), or asymmetric routing, the token bucket method can cause floods that would be prevented if the bandwidth method was used as an additional clamping mechanism. Perhaps something like this should be mentioned in the text as well. One other thing - "values greater than 20-30 might break traceroute" is stated with no explanation as to why, and it seems that 20-30 is an arbitrary number (with no explicit units) that will change in the future as bandwidth capacity increases. I agree with the sentiment of the statement, but think there should be some explanation as to how an implementor might compute this value (perhaps how the 20-30 was derived). Zachary Amsden zamsden@cisco.com Mukesh.Gupta@nokia.com wrote: >Hi All, > >As I sensed after all the discussion we had, the WG will prefer >to expand the text to prefer token-bucket method and describe >the limitations of the other two. If my conclusion is wrong, >feel free to scream :) Otherwise, here is the revised text. > >Please review the text and let me know if we need to >add/modify/correct anything. If you want something to be >changed, please send me the new proposed text. > >I couldn't decide what the correct default values of the >parameters should be. So I haven't mentioned anything. If >anyone wants to add, please send me the values. > >======================================================= > (f) Finally, in order to limit the bandwidth and forwarding costs > incurred sending ICMPv6 error messages, an IPv6 node MUST limit > the rate of ICMPv6 error messages it sends. This situation may > occur when a source sending a stream of erroneous packets fails > to heed the resulting ICMPv6 error messages. There are a variety > of ways of implementing the rate-limiting function, for example: > > (f.1) Timer-based - for example, limiting the rate of > transmission of error messages to at most once every T > milliseconds. > > (f.2) Bandwidth-based - for example, limiting the rate at which > error messages are sent from a particular interface to > some fraction F of the attached link's bandwidth. > > (f.3) Token-bucket based - for example, allowing up to B back- > to-back error messages to be transmitted in a burst, but > limiting the average rate of transmission to N where N > can either be packets/seconds or a fraction of the > attached link's bandwidth. > > The limit parameters (e.g., T, F, B and N in the above examples) > MUST be configurable for the node. > > Token-bucket based function should be preferrable over the other > two. > > If Timer-based or Bandwidth-based function is chosen because of > the simplicity of implementation, proper care must be taken in > choosing the value of T or F. Values of T that are higher than > 20-30 might break traceroute. A global value of F per node might > not be appropriate for all the links attached to the node. >======================================================= > >Regards >Mukesh > >-------------------------------------------------------------------- >IETF IPv6 working group mailing list >ipv6@ietf.org >Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Jan 9 18:44:27 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29404 for ; Fri, 9 Jan 2004 18:44:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Af6IK-0006NX-DP for ipv6-archive@odin.ietf.org; Fri, 09 Jan 2004 18:44:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i09Ni0tm024513 for ipv6-archive@odin.ietf.org; Fri, 9 Jan 2004 18:44:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Af6IK-0006NI-8U for ipv6-web-archive@optimus.ietf.org; Fri, 09 Jan 2004 18:44:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29366 for ; Fri, 9 Jan 2004 18:43:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Af6IH-0004rP-00 for ipv6-web-archive@ietf.org; Fri, 09 Jan 2004 18:43:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Af6GS-0004lw-00 for ipv6-web-archive@ietf.org; Fri, 09 Jan 2004 18:42:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Af6Ef-0004h4-00 for ipv6-web-archive@ietf.org; Fri, 09 Jan 2004 18:40:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Af6EX-00061a-Dg; Fri, 09 Jan 2004 18:40:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Af6EO-000603-Am for ipv6@optimus.ietf.org; Fri, 09 Jan 2004 18:39:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29164 for ; Fri, 9 Jan 2004 18:39:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Af6EL-0004da-00 for ipv6@ietf.org; Fri, 09 Jan 2004 18:39:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Af6Cb-0004Zc-00 for ipv6@ietf.org; Fri, 09 Jan 2004 18:38:05 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1Af6BJ-0004V3-00 for ipv6@ietf.org; Fri, 09 Jan 2004 18:36:45 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i09Na7L16656; Fri, 9 Jan 2004 15:36:07 -0800 X-mProtect: <200401092336> Nokia Silicon Valley Messaging Protection Received: from ftemplin.iprg.nokia.com (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd9Y08Hw; Fri, 09 Jan 2004 15:36:06 PST Message-ID: <3FFF3AFB.6090600@iprg.nokia.com> Date: Fri, 09 Jan 2004 15:36:27 -0800 From: Fred Templin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Zachary Amsden CC: ipv6@ietf.org Subject: Re: ICMPv6 Rate Limiting Methods: Revised Text References: <8D260779A766FB4A9C1739A476F84FA42ABE56@daebe009.americas.nokia.com> <3FFF1328.9050709@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Zachary Amsden wrote: > > It seems to me that "back to back" is ill-defined. It is highly > unlikely that the ICMP error packets will be transmitted with no other > transmissions in between, which "back to back" seems to imply. I am reading that text in a different way, and I believe the way in which it was originally intended. The text says: "back to back _error_ messages"; it is not intended to imply that there will be no other packet transmissions in between the ICMPv6 error packets. The rate of ordinary packet transmissions, and whether/not the ordinary packets may be interleaved between the ICMPv6 error packets comprising the burst, has no relevance for B. Fred ftemplin@iprg.nokia.com > Also, there had been much discussion about how certain methods are > lacking and should be omitted. I don't think any should be omitted - > consider the possibility of combining all three methods to clamp the > ICMP rate in different domains. In the presence of asymmetric > bandwidth (consider ADSL), or asymmetric routing, the token bucket > method can cause floods that would be prevented if the bandwidth > method was used as an additional clamping mechanism. > > Perhaps something like this should be mentioned in the text as well. > > One other thing - "values greater than 20-30 might break traceroute" > is stated with no explanation as to why, and it seems that 20-30 is an > arbitrary number (with no explicit units) that will change in the > future as bandwidth capacity increases. I agree with the sentiment of > the statement, but think there should be some explanation as to how an > implementor might compute this value (perhaps how the 20-30 was derived). > > Zachary Amsden > zamsden@cisco.com > > Mukesh.Gupta@nokia.com wrote: > >> Hi All, >> >> As I sensed after all the discussion we had, the WG will prefer >> to expand the text to prefer token-bucket method and describe >> the limitations of the other two. If my conclusion is wrong, >> feel free to scream :) Otherwise, here is the revised text. >> >> Please review the text and let me know if we need to >> add/modify/correct anything. If you want something to be changed, >> please send me the new proposed text. >> >> I couldn't decide what the correct default values of the parameters >> should be. So I haven't mentioned anything. If >> anyone wants to add, please send me the values. >> >> ======================================================= >> (f) Finally, in order to limit the bandwidth and forwarding costs >> incurred sending ICMPv6 error messages, an IPv6 node MUST limit >> the rate of ICMPv6 error messages it sends. This situation may >> occur when a source sending a stream of erroneous packets fails >> to heed the resulting ICMPv6 error messages. There are a variety >> of ways of implementing the rate-limiting function, for example: >> >> (f.1) Timer-based - for example, limiting the rate of >> transmission of error messages to at most once every T >> milliseconds. >> >> (f.2) Bandwidth-based - for example, limiting the rate at which >> error messages are sent from a particular interface to >> some fraction F of the attached link's bandwidth. >> >> (f.3) Token-bucket based - for example, allowing up to B back- >> to-back error messages to be transmitted in a burst, but >> limiting the average rate of transmission to N where N >> can either be packets/seconds or a fraction of the >> attached link's bandwidth. >> >> The limit parameters (e.g., T, F, B and N in the above examples) >> MUST be configurable for the node. >> >> Token-bucket based function should be preferrable over the other >> two. >> >> If Timer-based or Bandwidth-based function is chosen because of >> the simplicity of implementation, proper care must be taken in >> choosing the value of T or F. Values of T that are higher than >> 20-30 might break traceroute. A global value of F per node might >> not be appropriate for all the links attached to the node. >> ======================================================= >> >> Regards >> Mukesh >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> >> > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Jan 9 18:56:42 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00048 for ; Fri, 9 Jan 2004 18:56:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Af6UC-0006w0-FN for ipv6-archive@odin.ietf.org; Fri, 09 Jan 2004 18:56:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i09NuGBd026650 for ipv6-archive@odin.ietf.org; Fri, 9 Jan 2004 18:56:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Af6UC-0006vl-B6 for ipv6-web-archive@optimus.ietf.org; Fri, 09 Jan 2004 18:56:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00004 for ; Fri, 9 Jan 2004 18:56:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Af6U9-0005gE-00 for ipv6-web-archive@ietf.org; Fri, 09 Jan 2004 18:56:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Af6SP-0005Yh-00 for ipv6-web-archive@ietf.org; Fri, 09 Jan 2004 18:54:25 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Af6RF-0005Qa-00 for ipv6-web-archive@ietf.org; Fri, 09 Jan 2004 18:53:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Af6R3-0006Zp-QP; Fri, 09 Jan 2004 18:53:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Af6Q4-0006Yw-Jz for ipv6@optimus.ietf.org; Fri, 09 Jan 2004 18:52:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29718 for ; Fri, 9 Jan 2004 18:51:56 -0500 (EST) From: Mukesh.Gupta@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Af6Q1-0005JV-00 for ipv6@ietf.org; Fri, 09 Jan 2004 18:51:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Af6OH-0005DT-00 for ipv6@ietf.org; Fri, 09 Jan 2004 18:50:09 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1Af6Mw-00058a-00 for ipv6@ietf.org; Fri, 09 Jan 2004 18:48:46 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i09Nmj405049 for ; Sat, 10 Jan 2004 01:48:45 +0200 (EET) Received: from daebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Sat, 10 Jan 2004 01:48:42 +0200 Received: from daebe009.NOE.Nokia.com ([10.241.35.109]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 9 Jan 2004 17:48:36 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: ICMPv6 Rate Limiting Methods: Revised Text Date: Fri, 9 Jan 2004 17:48:36 -0600 Message-ID: <8D260779A766FB4A9C1739A476F84FA42ABE57@daebe009.americas.nokia.com> Thread-Topic: ICMPv6 Rate Limiting Methods: Revised Text Thread-Index: AcPWWJtKcewzLJE0SRKV515J4FtEDAAsRP3A To: Cc: X-OriginalArrivalTime: 09 Jan 2004 23:48:36.0911 (UTC) FILETIME=[1982A3F0:01C3D70B] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > Values of T that are higher than 20-30 might break legitimate > functionality that requires timely delivery of ICMPv6 error > messages (e.g., traceroute), while smaller values might cause > saturation of slow links. The text definitely looks better than mine. I will use the above text. > I'm also not entirely sure about your cautions regarding "a global > value of F per node"; the text of f.2 says: "limiting the=20 > rate at which > error messages are sent from a particular interface to some fraction > F of the attached link's bandwidth" - it doesn't say anything about > a global value of F for the node. The line "The limit parameters (e.g., T, F, B and N in the above = examples) MUST be configurable for the node." implies that F is configured as a global value for the node. What I wanted to point out was that if the = admin was allowed to configure the value of F per interface, we will not have=20 the scalability problem that Pekka had pointed out. (we will still have=20 the problem in asymmetric path topology that you described). I would be happy to put any text that will describe the limitations of = the=20 bandwidth-based method in a better way ? Regards Mukesh -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Jan 9 19:18:36 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00982 for ; Fri, 9 Jan 2004 19:18:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Af6pN-0008At-2y for ipv6-archive@odin.ietf.org; Fri, 09 Jan 2004 19:18:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0A0I9oi031423 for ipv6-archive@odin.ietf.org; Fri, 9 Jan 2004 19:18:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Af6pM-0008Ak-SW for ipv6-web-archive@optimus.ietf.org; Fri, 09 Jan 2004 19:18:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00976 for ; Fri, 9 Jan 2004 19:18:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Af6pL-00070U-00 for ipv6-web-archive@ietf.org; Fri, 09 Jan 2004 19:18:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Af6nR-0006uS-00 for ipv6-web-archive@ietf.org; Fri, 09 Jan 2004 19:16:10 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Af6mq-0006pI-00 for ipv6-web-archive@ietf.org; Fri, 09 Jan 2004 19:15:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Af6mN-0007Zu-S8; Fri, 09 Jan 2004 19:15:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Af6lQ-0007Yl-CP for ipv6@optimus.ietf.org; Fri, 09 Jan 2004 19:14:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00872 for ; Fri, 9 Jan 2004 19:14:01 -0500 (EST) From: Mukesh.Gupta@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Af6lO-0006nL-00 for ipv6@ietf.org; Fri, 09 Jan 2004 19:14:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Af6jb-0006j4-00 for ipv6@ietf.org; Fri, 09 Jan 2004 19:12:12 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1Af6ix-0006dv-00 for ipv6@ietf.org; Fri, 09 Jan 2004 19:11:31 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i0A0BV606041 for ; Sat, 10 Jan 2004 02:11:31 +0200 (EET) Received: from daebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Sat, 10 Jan 2004 02:11:28 +0200 Received: from daebe009.NOE.Nokia.com ([10.241.35.109]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 9 Jan 2004 18:11:14 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: ICMPv6 Rate Limiting Methods: Revised Text Date: Fri, 9 Jan 2004 18:11:14 -0600 Message-ID: <8D260779A766FB4A9C1739A476F84FA42ABE58@daebe009.americas.nokia.com> Thread-Topic: ICMPv6 Rate Limiting Methods: Revised Text Thread-Index: AcPW7Axu+xFUJPAlTYm7wyW9enSr1gAHxS2Q To: Cc: X-OriginalArrivalTime: 10 Jan 2004 00:11:14.0497 (UTC) FILETIME=[42B1D310:01C3D70E] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Zachary, > It seems to me that "back to back" is ill-defined. It is highly=20 > unlikely that the ICMP error packets will be transmitted with=20 > no other=20 > transmissions in between, which "back to back" seems to imply. The=20 > burst allowance should probably be defined as "allowing a burst of N=20 > packets over Ts seconds", or something along these lines. I agree with Fred's explaination about this one. We could make it even clearer by adding word "ICMP" before error messages. =3D=3D=3D=3D ... allowing up to B back-to-back ICMP error messages to be ... =3D=3D=3D=3D Is that going to help ?? > Also, there had been much discussion about how certain methods are=20 > lacking and should be omitted. I don't think any should be omitted -=20 > consider the possibility of combining all three methods to clamp the=20 > ICMP rate in different domains. In the presence of asymmetric = bandwidth=20 > (consider ADSL), or asymmetric routing, the token bucket method can=20 > cause floods that would be prevented if the bandwidth method=20 > was used as an additional clamping mechanism. > > Perhaps something like this should be mentioned in the text as well. How about we add the following text with the line which says that the token-bucket based functions should be preferred. =3D=3D=3D=3D=3D A combination of more than one functions can also be used if required. =3D=3D=3D=3D=3D > One other thing - "values greater than 20-30 might break traceroute"=20 > is stated with no explanation as to why, and it seems that 20-30 is an = > arbitrary number (with no explicit units) that will change in=20 > the future as bandwidth capacity increases. point (f.1) describes that the unit of T is milliseconds. I had copied number 20-30 from an old mail of Thomas Narten where he described how the Timer-based functions will break traceroute. This is the time between 2 probes of traceroute. Does anyone has a better view of what this number should be ? If not, do you think, we should not put this number and just say that higher values of T might break traceroute ?? Regards Mukesh -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sat Jan 10 09:46:48 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06847 for ; Sat, 10 Jan 2004 09:46:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AfKNZ-0001ZD-4q for ipv6-archive@odin.ietf.org; Sat, 10 Jan 2004 09:46:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0AEkLNA006017 for ipv6-archive@odin.ietf.org; Sat, 10 Jan 2004 09:46:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AfKNY-0001Yy-SH for ipv6-web-archive@optimus.ietf.org; Sat, 10 Jan 2004 09:46:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06787 for ; Sat, 10 Jan 2004 09:46:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AfKNX-0003QK-00 for ipv6-web-archive@ietf.org; Sat, 10 Jan 2004 09:46:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AfKMV-0003GC-00 for ipv6-web-archive@ietf.org; Sat, 10 Jan 2004 09:45:20 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AfKGE-0002yB-00 for ipv6-web-archive@ietf.org; Sat, 10 Jan 2004 09:38:47 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1AfKFn-0004Jh-Vf for ipv6-web-archive@ietf.org; Sat, 10 Jan 2004 09:38:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AfKEY-0000r9-EN; Sat, 10 Jan 2004 09:37:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AfKEK-0000qT-11 for ipv6@optimus.ietf.org; Sat, 10 Jan 2004 09:36:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06405 for ; Sat, 10 Jan 2004 09:36:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AfKED-0002qq-00 for ipv6@ietf.org; Sat, 10 Jan 2004 09:36:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AfKAp-0002fO-00 for ipv6@ietf.org; Sat, 10 Jan 2004 09:33:12 -0500 Received: from web80504.mail.yahoo.com ([66.218.79.74]) by ietf-mx with smtp (Exim 4.12) id 1AfK7F-0002UA-00 for ipv6@ietf.org; Sat, 10 Jan 2004 09:29:29 -0500 Message-ID: <20040110142830.108.qmail@web80504.mail.yahoo.com> Received: from [63.197.18.101] by web80504.mail.yahoo.com via HTTP; Sat, 10 Jan 2004 06:28:30 PST Date: Sat, 10 Jan 2004 06:28:30 -0800 (PST) From: Fred Templin Subject: RE: ICMPv6 Rate Limiting Methods: Revised Text To: Mukesh.Gupta@nokia.com Cc: ipv6@ietf.org In-Reply-To: <8D260779A766FB4A9C1739A476F84FA42ABE57@daebe009.americas.nokia.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1891106453-1073744910=:97456" Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.0 required=5.0 tests=AWL,FROM_ENDS_IN_NUMS, HTML_MESSAGE,MAILTO_TO_SPAM_ADDR autolearn=no version=2.60 --0-1891106453-1073744910=:97456 Content-Type: text/plain; charset=us-ascii On further thought, the key words in the entire section of text we are talking about are: "attached link's bandwidth". For interfaces that attach to the global Internet, the "attached link" is the Internet itself and can be viewed as a variable-bandwidth link with a wide range of bandwidth possibilities based on the return path to a particular source node to which the ICMP error messages will be sent. The bandwidth of a return path to a particular source node is determined by the slowest physical link encountered at any hop along the path, and I believe we can expect to see physical links as slow as 10Kbps in wide deployment for the forseeable future. So, any rate limiting parameters we recommend would need to limit the ICMPs to an acceptably-low bandwidth below 10Kbps when the node sending the ICMPs cannot determine the bandwidth of the return path to the source of packets causing the errors. In order to send ICMP messages at both and effective and safe rates, nodes that send the ICMPs would need to determine the bandwidths of the return paths to the sources of packets causing errors. Because the growing trend toward path asymmetry gives us no guarantee that the bandwidths in both directions will be the same (or even similar), the bandwidths of the return paths can only be determined by direct measurement, This also implies that nodes that generate ICMPs would need to keep per-source state information and (since the bandwidth along a particular path may vary over time) repeat the bandwidth measurements periodically. The inevitable conclusion of all of this is that nodes that do not maintain state and do not have a means for determining the bandwidth along the return paths to source nodes will not be able to determine when it is OK to send ICMP error messages without the possibility of causing harmful congestion. Or, if they do decide to send ICMP error messages anyway, will need to do so at a rate that is acceptable for the worst-case bandwidth for any physical links that might occur in the Internet. In the case of physical links as slow as 10Kbps, such an acceptable rate would be far too low to provide any useful benefit in most cases. Fred L. Templin osprey67@yahoo.com ftemplin@iprg.nokia.com Mukesh.Gupta@nokia.com wrote: > Values of T that are higher than 20-30 might break legitimate > functionality that requires timely delivery of ICMPv6 error > messages (e.g., traceroute), while smaller values might cause > saturation of slow links. The text definitely looks better than mine. I will use the above text. > I'm also not entirely sure about your cautions regarding "a global > value of F per node"; the text of f.2 says: "limiting the > rate at which > error messages are sent from a particular interface to some fraction > F of the attached link's bandwidth" - it doesn't say anything about > a global value of F for the node. The line "The limit parameters (e.g., T, F, B and N in the above examples) MUST be configurable for the node." implies that F is configured as a global value for the node. What I wanted to point out was that if the admin was allowed to configure the value of F per interface, we will not have the scalability problem that Pekka had pointed out. (we will still have the problem in asymmetric path topology that you described). I would be happy to put any text that will describe the limitations of the bandwidth-based method in a better way ? Regards Mukesh -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --0-1891106453-1073744910=:97456 Content-Type: text/html; charset=us-ascii
On further thought, the key words in the entire section of text we are talking
about are: "attached link's bandwidth". For interfaces that attach to the global
Internet, the "attached link" is the Internet itself and can be viewed as a
variable-bandwidth link with a wide range of bandwidth possibilities based
on the return path to a particular source node to which the ICMP error
messages will be sent.
 
The bandwidth of a return path to a particular source node is determined
by the slowest physical link encountered at any hop along the path, and
I believe we can expect to see physical links as slow as 10Kbps in wide
deployment for the forseeable future. So, any rate limiting parameters we
recommend would need to limit the ICMPs to an acceptably-low bandwidth
below 10Kbps when the node sending the ICMPs cannot determine the
bandwidth of the return path to the source of packets causing the errors.
 
In order to send ICMP messages at both and effective and safe rates, nodes
that send the ICMPs would need to determine the bandwidths of the return
paths to the sources of packets causing errors. Because the growing trend
toward path asymmetry gives us no guarantee that the bandwidths in both
directions will be the same (or even similar), the bandwidths of the return paths
can only be determined by direct measurement, This also implies that nodes
that generate ICMPs would need to keep per-source state information and
(since the bandwidth along a particular path may vary over time) repeat the
bandwidth measurements periodically.
 
The inevitable conclusion of all of this is that nodes that do not maintain
state and do not have a means for determining the bandwidth along the
return paths to source nodes will not be able to determine when it is OK
to send ICMP error messages without the possibility of causing harmful
congestion. Or, if they do decide to send ICMP error messages anyway,
will need to do so at a rate that is acceptable for the worst-case bandwidth
for any physical links that might occur in the Internet. In the case of
physical links as slow as 10Kbps, such an acceptable rate would be
far too low to provide any useful benefit in most cases.
 
Fred L. Templin
 

Mukesh.Gupta@nokia.com wrote:
> Values of T that are higher than 20-30 might break legitimate
> functionality that requires timely delivery of ICMPv6 error
> messages (e.g., traceroute), while smaller values might cause
> saturation of slow links.

The text definitely looks better than mine. I will use the above
text.

> I'm also not entirely sure about your cautions regarding "a global
> value of F per node"; the text of f.2 says: "limiting the
> rate at which
> error messages are sent from a particular interface to some fraction
> F of the attached link's bandwidth" - it doesn't say anything about
> a global value of F for the node.

The line "The limit parameters (e.g., T, F, B and N in the above examples)
MUST be configurable for the node." implies that F is configured as a
global value for the node. What I wanted to poi! nt out was that if the admin
was allowed to configure the value of F per interface, we will not have
the scalability problem that Pekka had pointed out. (we will still have
the problem in asymmetric path topology that you described).

I would be happy to put any text that will describe the limitations of the
bandwidth-based method in a better way ?

Regards
Mukesh

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--0-1891106453-1073744910=:97456-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sun Jan 11 00:09:18 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02826 for ; Sun, 11 Jan 2004 00:09:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AfXqG-0006YZ-6f for ipv6-archive@odin.ietf.org; Sun, 11 Jan 2004 00:08:52 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0B58qVm025199 for ipv6-archive@odin.ietf.org; Sun, 11 Jan 2004 00:08:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AfXqG-0006YM-26 for ipv6-web-archive@optimus.ietf.org; Sun, 11 Jan 2004 00:08:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02811 for ; Sun, 11 Jan 2004 00:08:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AfXqD-0002sX-00 for ipv6-web-archive@ietf.org; Sun, 11 Jan 2004 00:08:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AfXoI-0002l6-00 for ipv6-web-archive@ietf.org; Sun, 11 Jan 2004 00:06:50 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AfXnI-0002eg-00 for ipv6-web-archive@ietf.org; Sun, 11 Jan 2004 00:05:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AfXma-0005cG-6b; Sun, 11 Jan 2004 00:05:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AfXmJ-0005bC-FL for ipv6@optimus.ietf.org; Sun, 11 Jan 2004 00:04:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02535 for ; Sun, 11 Jan 2004 00:04:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AfXmH-0002a6-00 for ipv6@ietf.org; Sun, 11 Jan 2004 00:04:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AfXkM-0002Pn-00 for ipv6@ietf.org; Sun, 11 Jan 2004 00:02:46 -0500 Received: from cyteen.hactrn.net ([66.92.66.68]) by ietf-mx with esmtp (Exim 4.12) id 1AfXif-0002CS-00 for ipv6@ietf.org; Sun, 11 Jan 2004 00:01:01 -0500 Received: from hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id 19395646 for ; Sun, 11 Jan 2004 00:00:31 -0500 (EST) To: ipv6@ietf.org Subject: Weekly posting summary for ipv6@ietf.org From: Rob Austein Date: Sun, 11 Jan 2004 00:00:30 -0500 Message-Id: <20040111050031.19395646@cyteen.hactrn.net> Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,MAILTO_TO_SPAM_ADDR autolearn=no version=2.60 Messages | Bytes | Who --------+------+--------+----------+------------------------ 25.00% | 11 | 28.74% | 78545 | mukesh.gupta@nokia.com 13.64% | 6 | 21.83% | 59671 | osprey67@yahoo.com 13.64% | 6 | 9.47% | 25894 | pekkas@netcore.fi 11.36% | 5 | 11.12% | 30386 | ftemplin@iprg.nokia.com 4.55% | 2 | 5.33% | 14567 | zamsden@cisco.com 4.55% | 2 | 3.59% | 9808 | francis.dupont@enst-bretagne.fr 4.55% | 2 | 3.34% | 9140 | brian@innovationslab.net 2.27% | 1 | 2.36% | 6462 | teemu.savolainen@nokia.com 2.27% | 1 | 2.11% | 5780 | brc@zurich.ibm.com 2.27% | 1 | 1.94% | 5313 | internet-drafts@ietf.org 2.27% | 1 | 1.62% | 4426 | margaret@thingmagic.com 2.27% | 1 | 1.57% | 4283 | bob.hinden@nokia.com 2.27% | 1 | 1.50% | 4109 | yasu@sfc.wide.ad.jp 2.27% | 1 | 1.42% | 3877 | tjc@ecs.soton.ac.uk 2.27% | 1 | 1.41% | 3843 | soohong.park@samsung.com 2.27% | 1 | 1.37% | 3745 | sra+ipng@hactrn.net 2.27% | 1 | 1.27% | 3478 | mailman-owner@www1.ietf.org --------+------+--------+----------+------------------------ 100.00% | 44 |100.00% | 273327 | Total Grunchweather Associates provides this automatic summary on an at-whim basis at the request of the IPv6 WG chairs. Your mileage may vary. We decline responsibilities, all shapes, all sizes, all colors. If this script produces broken output, you get to keep both pieces. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sun Jan 11 17:33:42 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19305 for ; Sun, 11 Jan 2004 17:33:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Afo8w-000598-Pt for ipv6-archive@odin.ietf.org; Sun, 11 Jan 2004 17:33:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0BMXEPv019781 for ipv6-archive@odin.ietf.org; Sun, 11 Jan 2004 17:33:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Afo8w-00058y-If for ipv6-web-archive@optimus.ietf.org; Sun, 11 Jan 2004 17:33:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19298 for ; Sun, 11 Jan 2004 17:33:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Afo8p-0000aD-00 for ipv6-web-archive@ietf.org; Sun, 11 Jan 2004 17:33:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Afo56-0000Ub-00 for ipv6-web-archive@ietf.org; Sun, 11 Jan 2004 17:29:17 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Afo3k-0000Qg-00 for ipv6-web-archive@ietf.org; Sun, 11 Jan 2004 17:27:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Afo2v-0004jR-Ue; Sun, 11 Jan 2004 17:27:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Afo2F-0004ic-2I for ipv6@optimus.ietf.org; Sun, 11 Jan 2004 17:26:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19211 for ; Sun, 11 Jan 2004 17:26:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Afo21-0000Od-00 for ipv6@ietf.org; Sun, 11 Jan 2004 17:26:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Afnyi-0000K7-00 for ipv6@ietf.org; Sun, 11 Jan 2004 17:22:42 -0500 Received: from zmamail03.zma.compaq.com ([161.114.64.103]) by ietf-mx with esmtp (Exim 4.12) id 1AfnxD-00009g-00 for ipv6@ietf.org; Sun, 11 Jan 2004 17:21:07 -0500 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id D5C58111CE; Sun, 11 Jan 2004 17:21:07 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Sun, 11 Jan 2004 17:21:07 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3D891.352D2762" Subject: RE: ICMPv6 Rate Limiting Methods: Revised Text Date: Sun, 11 Jan 2004 17:21:07 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B05836947@tayexc13.americas.cpqcorp.net> Thread-Topic: ICMPv6 Rate Limiting Methods: Revised Text Thread-Index: AcPXh2BwBCpULlQmTwadHmBwA/slMQBCY0Ww From: "Bound, Jim" To: "Fred Templin" , Cc: X-OriginalArrivalTime: 11 Jan 2004 22:21:07.0563 (UTC) FILETIME=[357B33B0:01C3D891] Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,HTML_FONTCOLOR_BLUE, HTML_MESSAGE,MAILTO_TO_SPAM_ADDR autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C3D891.352D2762 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, =20 Interesting discussion. I agree with Fred and his line of logic and that just leave all three in tact and all will work for different conditions and why they are there. We have no need to pull any of the options out for rate-limiting. If some one wants to add one or enhance one then that is a different matter and subject. Suggest sending with specific case in the subject line. =20 /jim -----Original Message----- From: ipv6-admin@ietf.org [mailto:ipv6-admin@ietf.org] On Behalf Of Fred Templin Sent: Saturday, January 10, 2004 9:29 AM To: Mukesh.Gupta@nokia.com Cc: ipv6@ietf.org Subject: RE: ICMPv6 Rate Limiting Methods: Revised Text =09 =09 On further thought, the key words in the entire section of text we are talking about are: "attached link's bandwidth". For interfaces that attach to the global Internet, the "attached link" is the Internet itself and can be viewed as a variable-bandwidth link with a wide range of bandwidth possibilities based on the return path to a particular source node to which the ICMP error messages will be sent. =20 The bandwidth of a return path to a particular source node is determined by the slowest physical link encountered at any hop along the path, and I believe we can expect to see physical links as slow as 10Kbps in wide deployment for the forseeable future. So, any rate limiting parameters we recommend would need to limit the ICMPs to an acceptably-low bandwidth below 10Kbps when the node sending the ICMPs cannot determine the bandwidth of the return path to the source of packets causing the errors. =20 In order to send ICMP messages at both and effective and safe rates, nodes that send the ICMPs would need to determine the bandwidths of the return paths to the sources of packets causing errors. Because the growing trend toward path asymmetry gives us no guarantee that the bandwidths in both directions will be the same (or even similar), the bandwidths of the return paths can only be determined by direct measurement, This also implies that nodes that generate ICMPs would need to keep per-source state information and (since the bandwidth along a particular path may vary over time) repeat the bandwidth measurements periodically. =20 The inevitable conclusion of all of this is that nodes that do not maintain state and do not have a means for determining the bandwidth along the return paths to source nodes will not be able to determine when it is OK to send ICMP error messages without the possibility of causing harmful congestion. Or, if they do decide to send ICMP error messages anyway, will need to do so at a rate that is acceptable for the worst-case bandwidth for any physical links that might occur in the Internet. In the case of physical links as slow as 10Kbps, such an acceptable rate would be far too low to provide any useful benefit in most cases. =20 Fred L. Templin osprey67@yahoo.com ftemplin@iprg.nokia.com Mukesh.Gupta@nokia.com wrote: > Values of T that are higher than 20-30 might break legitimate > functionality that requires timely delivery of ICMPv6 error > messages (e.g., traceroute), while smaller values might cause > saturation of slow links. =09 The text definitely looks better than mine. I will use the above text. =09 > I'm also not entirely sure about your cautions regarding "a global > value of F per node"; the text of f.2 says: "limiting the=20 > rate at which > error messages are sent from a particular interface to some fraction > F of the attached link's bandwidth" - it doesn't say anything about > a global value of F for the node. =09 The line "The limit parameters (e.g., T, F, B and N in the above examples) MUST be configurable for the node." implies that F is configured as a global value for the node. What I wanted to poi! nt out was that if the admin was allowed to configure the value of F per interface, we will not have=20 the scalability problem that Pekka had pointed out. (we will still have=20 the problem in asymmetric path topology that you described). =09 I would be happy to put any text that will describe the limitations of the=20 bandwidth-based method in a better way ? =09 Regards Mukesh =09 =09 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 =09 -------------------------------------------------------------------- ------_=_NextPart_001_01C3D891.352D2762 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Folks,
 
Interesting discussion.  I agree with = Fred and his=20 line of logic and that just leave all three in tact and all will work = for=20 different conditions and why they are there.  We have no need to = pull any=20 of the options out for rate-limiting.  If some one wants to add one = or=20 enhance one then that is a different matter and subject.  Suggest = sending=20 with specific case in the subject line.
 
/jim
-----Original Message-----
From:=20 ipv6-admin@ietf.org [mailto:ipv6-admin@ietf.org] On Behalf Of = Fred=20 Templin
Sent: Saturday, January 10, 2004 9:29 = AM
To:=20 Mukesh.Gupta@nokia.com
Cc: ipv6@ietf.org
Subject: = RE:=20 ICMPv6 Rate Limiting Methods: Revised Text

On further thought, the key words in the entire section of text = we are=20 talking
about are: "attached link's bandwidth". For interfaces that = attach to the=20 global
Internet, the "attached link" is the Internet itself and can be = viewed as=20 a
variable-bandwidth link with a wide range of bandwidth = possibilities=20 based
on the return path to a particular source node to which = the=20 ICMP error
messages will be sent.
 
The bandwidth of a return path to a particular source = node is=20 determined
by the slowest physical link encountered at any hop = along the=20 path, and
I believe we can expect to see physical links as slow = as 10Kbps=20 in wide
deployment for the forseeable future. So, any rate=20 limiting parameters we
recommend would need to limit the ICMPs to an acceptably-low=20 bandwidth
below 10Kbps when the node sending the ICMPs cannot = determine=20 the
bandwidth of the return path to the source of packets causing the = errors.
 
In order to send ICMP messages at both and effective and = safe rates,=20 nodes
that send the ICMPs would need to determine the bandwidths = of the=20 return
paths to the sources of packets causing errors. Because the = growing=20 trend
toward path asymmetry gives us no guarantee that the = bandwidths in=20 both
directions will be the same (or even similar), the bandwidths of = the=20 return paths
can only be determined by direct measurement, This also = implies that=20 nodes
that generate ICMPs would need to keep per-source state = information and
(since the bandwidth along a particular path may vary over time) = repeat=20 the
bandwidth measurements periodically.
 
The inevitable conclusion of all of this is that nodes that do = not=20 maintain
state and do not have a means for determining the bandwidth along = the
return paths to source nodes will not be able to determine when = it is=20 OK
to send ICMP error messages without the possibility of causing=20 harmful
congestion. Or, if they do decide to send ICMP error messages=20 anyway,
will need to do so at a rate that is acceptable for the = worst-case=20 bandwidth
for any physical links that might occur in the Internet. In the = case=20 of
physical links as slow as 10Kbps, such an acceptable rate would = be
far too low to provide any useful benefit in most = cases.
 
Fred L. Templin
ftemplin@iprg.nokia.com
=


Mukesh.Gupta@nokia.com wrote:
>=20 Values of T that are higher than 20-30 might break = legitimate
>=20 functionality that requires timely delivery of ICMPv6 error
> = messages=20 (e.g., traceroute), while smaller values might cause
> = saturation of=20 slow links.

The text definitely looks better than mine. I = will use=20 the above
text.

> I'm also not entirely sure about your = cautions regarding "a global
> value of F per node"; the text = of f.2=20 says: "limiting the
> rate at which
> error messages = are sent=20 from a particular interface to some fraction
> F of the = attached=20 link's bandwidth" - it doesn't say anything about
> a global = value of=20 F for the node.

The line "The limit parameters (e.g., T, F, B = and N=20 in the above examples)
MUST be configurable for the node." = implies that F=20 is configured as a
global value for the node. What I wanted to = poi! nt=20 out was that if the admin
was allowed to configure the value of F = per=20 interface, we will not have
the scalability problem that Pekka = had=20 pointed out. (we will still have
the problem in asymmetric path = topology=20 that you described).

I would be happy to put any text that = will=20 describe the limitations of the
bandwidth-based method in a = better way=20 = ?

Regards
Mukesh

---------------------------------------= -----------------------------
IETF=20 IPv6 working group mailing list
ipv6@ietf.org
Administrative = Requests:=20 = https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------= ------------------------------------------

=00 ------_=_NextPart_001_01C3D891.352D2762-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Jan 12 20:26:41 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04436 for ; Mon, 12 Jan 2004 20:26:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgDJs-0005ns-7L for ipv6-archive@odin.ietf.org; Mon, 12 Jan 2004 20:26:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0D1QCaA022306 for ipv6-archive@odin.ietf.org; Mon, 12 Jan 2004 20:26:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgDJs-0005ne-0i for ipv6-web-archive@optimus.ietf.org; Mon, 12 Jan 2004 20:26:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04338 for ; Mon, 12 Jan 2004 20:26:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgDJp-0007ex-00 for ipv6-web-archive@ietf.org; Mon, 12 Jan 2004 20:26:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgDHq-0007M8-00 for ipv6-web-archive@ietf.org; Mon, 12 Jan 2004 20:24:07 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AgDFr-00071G-00 for ipv6-web-archive@ietf.org; Mon, 12 Jan 2004 20:22:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgDEs-00059m-CI; Mon, 12 Jan 2004 20:21:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgDE5-00058d-Ns for ipv6@optimus.ietf.org; Mon, 12 Jan 2004 20:20:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03555 for ; Mon, 12 Jan 2004 20:20:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgDE3-0006sk-00 for ipv6@ietf.org; Mon, 12 Jan 2004 20:20:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgDCM-0006oK-00 for ipv6@ietf.org; Mon, 12 Jan 2004 20:18:27 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AgDBS-0006iU-00 for ipv6@ietf.org; Mon, 12 Jan 2004 20:17:31 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i0D1GxI28476; Mon, 12 Jan 2004 17:16:59 -0800 X-mProtect: <200401130116> Nokia Silicon Valley Messaging Protection Received: from ftemplin.iprg.nokia.com (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd0HNm14; Mon, 12 Jan 2004 17:16:57 PST Message-ID: <40034708.1090904@iprg.nokia.com> Date: Mon, 12 Jan 2004 17:16:56 -0800 From: Fred Templin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipv6@ietf.org CC: ftemplin Subject: Proposal for rate limiting parameters References: <9C422444DE99BC46B3AD3C6EAFC9711B05836947@tayexc13.americas.cpqcorp.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello, Based on the concensus that appears to be emerging from the "ICMPv6 Rate Limiting Methods: Revised Text" thread, it seems to me (please correct me if I am wrong) that there is no real compelling reason to make any changes to the existing text of section 2.4 (f) found in the current document: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-icmp-v3-02.txt However, I believe that in order to avoid interoperability issues while allowing maximum flexibility, some additional text is needed at the end of that section to specify operational requirements for setting rate limit parameter values. I would like to propose the following (the 1st paragraph already appears in the current document; the 2nd and 3rd paragraphs are new): The limit parameters (e.g., T or F in the above examples) MUST be configurable for the node, with a conservative default value (e.g., T = 0.5 second, NOT 0 seconds, or F = 2 percent, NOT 100 percent). Nodes MUST NOT configure limit values that would permit sustained error rates high enough to monopolize a 10Kbps link over any interface attached to the global Internet - either directly, or through a gateway that does not implement rate limiting. (The 10Kbps value reflects the worst-case link speed anticipated along any potential path in ther Internet.) Nodes that keep extra state information MAY maintain per (interface/source) limit values. Nodes that also dynamically measure the bandwidth along return paths to specific sources MAY maintain dynamic per source limit values based on the measured bandwidths, rather than 10Kbps. Comments? Fred ftemplin@iprg.nokia.com -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Jan 13 13:17:54 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01190 for ; Tue, 13 Jan 2004 13:17:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgT6V-0001uc-7Y for ipv6-archive@odin.ietf.org; Tue, 13 Jan 2004 13:17:27 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0DIHRGY007344 for ipv6-archive@odin.ietf.org; Tue, 13 Jan 2004 13:17:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgT6V-0001uN-2d for ipv6-web-archive@optimus.ietf.org; Tue, 13 Jan 2004 13:17:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01175 for ; Tue, 13 Jan 2004 13:17:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgT6T-0002qH-00 for ipv6-web-archive@ietf.org; Tue, 13 Jan 2004 13:17:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgT4U-0002gM-00 for ipv6-web-archive@ietf.org; Tue, 13 Jan 2004 13:15:22 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AgT3K-0002VR-00 for ipv6-web-archive@ietf.org; Tue, 13 Jan 2004 13:14:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgT2D-0001UW-QM; Tue, 13 Jan 2004 13:13:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgT1b-0001S7-6b for ipv6@optimus.ietf.org; Tue, 13 Jan 2004 13:12:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00749 for ; Tue, 13 Jan 2004 13:12:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgT1Z-0002O3-00 for ipv6@ietf.org; Tue, 13 Jan 2004 13:12:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgSzm-0002H3-00 for ipv6@ietf.org; Tue, 13 Jan 2004 13:10:31 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgSyB-000263-00 for ipv6@ietf.org; Tue, 13 Jan 2004 13:08:52 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i0DI89t17988; Tue, 13 Jan 2004 20:08:09 +0200 Date: Tue, 13 Jan 2004 20:08:09 +0200 (EET) From: Pekka Savola To: Fred Templin cc: ipv6@ietf.org Subject: Re: Proposal for rate limiting parameters In-Reply-To: <40034708.1090904@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 On Mon, 12 Jan 2004, Fred Templin wrote: > Nodes MUST NOT configure limit values that would permit > sustained error rates high enough to monopolize a 10Kbps link > over any interface attached to the global Internet - either directly, > or through a gateway that does not implement rate limiting. (The > 10Kbps value reflects the worst-case link speed anticipated along > any potential path in ther Internet.) > > Nodes that keep extra state information MAY maintain per > (interface/source) limit values. Nodes that also dynamically > measure the bandwidth along return paths to specific sources > MAY maintain dynamic per source limit values based on the > measured bandwidths, rather than 10Kbps. I really don't understand this specific "overloading" concern. You can equally ping a router with 1500 byte packets, and the responses will be 1500 bytes in size. There is no rate-limit for such messages. Designing for this kind of "vastly different capacities in each direction" just don't seem to be worth considering here. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Jan 13 13:45:07 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02701 for ; Tue, 13 Jan 2004 13:45:07 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgTWo-000490-VB for ipv6-archive@odin.ietf.org; Tue, 13 Jan 2004 13:44:38 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0DIicis015924 for ipv6-archive@odin.ietf.org; Tue, 13 Jan 2004 13:44:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgTWo-00048l-Rf for ipv6-web-archive@optimus.ietf.org; Tue, 13 Jan 2004 13:44:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02637 for ; Tue, 13 Jan 2004 13:44:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgTWm-0004MQ-00 for ipv6-web-archive@ietf.org; Tue, 13 Jan 2004 13:44:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgTV1-0004Cq-00 for ipv6-web-archive@ietf.org; Tue, 13 Jan 2004 13:42:48 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AgTTW-00046h-00 for ipv6-web-archive@ietf.org; Tue, 13 Jan 2004 13:41:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgTTK-0003jE-MH; Tue, 13 Jan 2004 13:41:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgTSo-0003fk-2a for ipv6@optimus.ietf.org; Tue, 13 Jan 2004 13:40:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02309 for ; Tue, 13 Jan 2004 13:40:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgTSl-00041d-00 for ipv6@ietf.org; Tue, 13 Jan 2004 13:40:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgTR3-0003s6-00 for ipv6@ietf.org; Tue, 13 Jan 2004 13:38:42 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgTPA-0003hZ-00 for ipv6@ietf.org; Tue, 13 Jan 2004 13:36:44 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i0DIaDp18415 for ; Tue, 13 Jan 2004 20:36:13 +0200 Date: Tue, 13 Jan 2004 20:36:13 +0200 (EET) From: Pekka Savola To: ipv6@ietf.org Subject: Re: ICMPv6 Rate Limiting Methods: Revised Text (2) In-Reply-To: <8D260779A766FB4A9C1739A476F84FA42ABE56@daebe009.americas.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 On Thu, 8 Jan 2004 Mukesh.Gupta@nokia.com wrote: Let me take my stab at trying the wording of this text: ===== (f) Finally, in order to limit the bandwidth and forwarding costs incurred sending ICMPv6 error messages, an IPv6 node MUST limit the rate of ICMPv6 error messages it sends. This situation may occur when a source sending a stream of erroneous packets fails to heed the resulting ICMPv6 error messages. One good way to implement the rate-limiting function is a token bucket, allowing up to B back-to-back error messages to be transmitted in a burst, but limiting the average rate of transmission to N, where N can either be packets/seconds or a fraction of the attached link's bandwidth. Rate-limiting mechanisms which cannot cope with bursty traffic (e.g., traceroute) are not recommended; thus a simple timer-based implementation, allowing an error message every T milliseconds (even with low values for T), is not reasonable. The rate-limiting parameters SHOULD be configurable. In the case of a token-bucket implementation, the best defaults depend on where the implementation is expected to be deployed (e.g., a high-end router vs. an embedded host). For example, in a small/mid -sized device, the possible defaults could be B=10, N=10/s. ===== Reasoning: - RFC1918 states rate-limiting SHOULD be configurable. A MUST seems too heavy in case the implementation and the defaults have been chosen properly. - Pure bandwidth-based mechanism doesn't seem to be useful at all, so for simplicit, omit it from here (can be coupled with a token bucket still). - It's rather difficult to recommend good values for B and N, as different kinds of nodes may have entirely different deployment scenarios. I don't feel particularly strongly on this, just invented some values which would probably be OK for all but the biggest routers. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Jan 13 14:46:46 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07258 for ; Tue, 13 Jan 2004 14:46:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgUUU-0007QO-NB for ipv6-archive@odin.ietf.org; Tue, 13 Jan 2004 14:46:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0DJkIWi028534 for ipv6-archive@odin.ietf.org; Tue, 13 Jan 2004 14:46:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgUUU-0007Q9-J0 for ipv6-web-archive@optimus.ietf.org; Tue, 13 Jan 2004 14:46:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07145 for ; Tue, 13 Jan 2004 14:46:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgUUR-0000o1-00 for ipv6-web-archive@ietf.org; Tue, 13 Jan 2004 14:46:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgUSW-0000fl-00 for ipv6-web-archive@ietf.org; Tue, 13 Jan 2004 14:44:17 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AgUQe-0000Zt-00 for ipv6-web-archive@ietf.org; Tue, 13 Jan 2004 14:42:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgUQL-0006wh-Q5; Tue, 13 Jan 2004 14:42:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgUPr-0006w3-4z for ipv6@optimus.ietf.org; Tue, 13 Jan 2004 14:41:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06899 for ; Tue, 13 Jan 2004 14:41:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgUPo-0000YH-00 for ipv6@ietf.org; Tue, 13 Jan 2004 14:41:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgUOC-0000NL-00 for ipv6@ietf.org; Tue, 13 Jan 2004 14:39:49 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AgUMW-00008M-00 for ipv6@ietf.org; Tue, 13 Jan 2004 14:38:05 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i0DJbJr05492; Tue, 13 Jan 2004 11:37:19 -0800 X-mProtect: <200401131937> Nokia Silicon Valley Messaging Protection Received: from ftemplin.iprg.nokia.com (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdflvErd; Tue, 13 Jan 2004 11:37:17 PST Message-ID: <400448F1.2040004@iprg.nokia.com> Date: Tue, 13 Jan 2004 11:37:21 -0800 From: Fred Templin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola CC: ipv6@ietf.org Subject: Re: Proposal for rate limiting parameters References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Pekka Savola wrote: > Designing for this kind of "vastly different capacities in > each direction" just don't seem to be worth considering here. I have to disagree; I believe there is a clear need to design for diverse link bandwidths to support near-term deployments and to foster future innovation. 10Kbps seems the best value for LCD, given commonly-deployed links that will see continued use into the future (see BCP documents produced by the PILC working group). 10Kbps also provides the useful characteristic that it is the bandwidth required to realize a 1 second delay budget for transmitting a 1280 byte packet. Would be interested to hear other opinions on this. Fred L. Templin ftemplin@iprg.nokia.com -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Jan 13 18:03:10 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19920 for ; Tue, 13 Jan 2004 18:03:10 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgXYZ-0000SF-KG for ipv6-archive@odin.ietf.org; Tue, 13 Jan 2004 18:02:43 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0DN2h0Q001747 for ipv6-archive@odin.ietf.org; Tue, 13 Jan 2004 18:02:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgXYZ-0000S6-F4 for ipv6-web-archive@optimus.ietf.org; Tue, 13 Jan 2004 18:02:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19890 for ; Tue, 13 Jan 2004 18:02:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgXYK-0004PW-00 for ipv6-web-archive@ietf.org; Tue, 13 Jan 2004 18:02:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgXWW-0004NI-00 for ipv6-web-archive@ietf.org; Tue, 13 Jan 2004 18:00:37 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AgXVV-0004KG-00 for ipv6-web-archive@ietf.org; Tue, 13 Jan 2004 17:59:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgXUz-00006D-QS; Tue, 13 Jan 2004 17:59:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgXUY-00005V-FJ for ipv6@optimus.ietf.org; Tue, 13 Jan 2004 17:58:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19746 for ; Tue, 13 Jan 2004 17:58:28 -0500 (EST) From: Mukesh.Gupta@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgXUT-0004Ic-00 for ipv6@ietf.org; Tue, 13 Jan 2004 17:58:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgXSd-0004Gc-00 for ipv6@ietf.org; Tue, 13 Jan 2004 17:56:36 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AgXS2-0004Dd-00 for ipv6@ietf.org; Tue, 13 Jan 2004 17:55:59 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i0DMtv202933 for ; Wed, 14 Jan 2004 00:55:57 +0200 (EET) Received: from daebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 14 Jan 2004 00:55:57 +0200 Received: from daebe009.NOE.Nokia.com ([10.241.35.109]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 13 Jan 2004 14:55:54 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Proposal for rate limiting parameters Date: Tue, 13 Jan 2004 16:55:54 -0600 Message-ID: <8D260779A766FB4A9C1739A476F84FA42ABE5D@daebe009.americas.nokia.com> Thread-Topic: Proposal for rate limiting parameters Thread-Index: AcPaDWOb/kmEG5alRbe9s4jZ4leF0QAGhCtg To: , Cc: X-OriginalArrivalTime: 13 Jan 2004 22:55:54.0813 (UTC) FILETIME=[6667C6D0:01C3DA28] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Fred, I agree with Pekka here. The text you suggested does look like=20 a little too much overconcerned. The text that Pekka suggested, sounds agreeable to me. I think talking about Rate Limiting a little bit and making some=20 suggestions to the implementor should be enough. There are too many variables involved in choosing the right method and the=20 appropriate default values and this does not affect any=20 interoperability. So we should let each vendor decide what to do. Regards Mukesh > -----Original Message----- > From: ipv6-admin@ietf.org [mailto:ipv6-admin@ietf.org]On Behalf Of ext > Fred Templin > Sent: Tuesday, January 13, 2004 11:37 AM > To: Pekka Savola > Cc: ipv6@ietf.org > Subject: Re: Proposal for rate limiting parameters >=20 >=20 >=20 > Pekka Savola wrote: >=20 > > Designing for this kind of "vastly different capacities in > > each direction" just don't seem to be worth considering here. >=20 > I have to disagree; I believe there is a clear need to design > for diverse link bandwidths to support near-term deployments > and to foster future innovation. >=20 > 10Kbps seems the best value for LCD, given commonly-deployed > links that will see continued use into the future (see BCP > documents produced by the PILC working group). 10Kbps also > provides the useful characteristic that it is the bandwidth > required to realize a 1 second delay budget for transmitting > a 1280 byte packet. >=20 > Would be interested to hear other opinions on this. >=20 > Fred L. Templin > ftemplin@iprg.nokia.com >=20 >=20 >=20 >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Jan 14 14:37:17 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05398 for ; Wed, 14 Jan 2004 14:37:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Agqoq-0002gG-Pr for ipv6-archive@odin.ietf.org; Wed, 14 Jan 2004 14:36:49 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0EJamZ9010300 for ipv6-archive@odin.ietf.org; Wed, 14 Jan 2004 14:36:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Agqoq-0002g3-Jb for ipv6-web-archive@optimus.ietf.org; Wed, 14 Jan 2004 14:36:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05250 for ; Wed, 14 Jan 2004 14:36:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Agqoa-0004Mf-00 for ipv6-web-archive@ietf.org; Wed, 14 Jan 2004 14:36:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Agqnh-0004Fu-00 for ipv6-web-archive@ietf.org; Wed, 14 Jan 2004 14:35:37 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Agqmk-00049X-00 for ipv6-web-archive@ietf.org; Wed, 14 Jan 2004 14:34:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgqlB-0002NV-Io; Wed, 14 Jan 2004 14:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgqkD-0002LV-KT for ipv6@optimus.ietf.org; Wed, 14 Jan 2004 14:32:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04780 for ; Wed, 14 Jan 2004 14:31:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgqkA-00040Z-00 for ipv6@ietf.org; Wed, 14 Jan 2004 14:31:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgqjV-0003yM-00 for ipv6@ietf.org; Wed, 14 Jan 2004 14:31:18 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AgqiT-0003r2-00 for ipv6@ietf.org; Wed, 14 Jan 2004 14:30:13 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i0EJTWc17650; Wed, 14 Jan 2004 11:29:32 -0800 X-mProtect: <200401141929> Nokia Silicon Valley Messaging Protection Received: from pc-b194.wlan.inet.fi (194.89.117.194, claiming to be "spruce.nokia.com") by darkstar.iprg.nokia.com smtpdsBc1w8; Wed, 14 Jan 2004 11:29:30 PST Message-Id: <4.3.2.7.2.20040114112615.00b669f8@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 14 Jan 2004 11:26:55 -0800 To: Mukesh.Gupta@nokia.com From: Bob Hinden Subject: RE: Proposal for rate limiting parameters Cc: ftemplin@iprg.nokia.com, , ipv6@ietf.org In-Reply-To: <8D260779A766FB4A9C1739A476F84FA42ABE5D@daebe009.americas.n okia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Mukesh, >I agree with Pekka here. The text you suggested does look like >a little too much overconcerned. > >The text that Pekka suggested, sounds agreeable to me. > >I think talking about Rate Limiting a little bit and making some >suggestions to the implementor should be enough. There are too >many variables involved in choosing the right method and the >appropriate default values and this does not affect any >interoperability. So we should let each vendor decide what >to do. Works for me. Bob -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Jan 14 14:44:23 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05991 for ; Wed, 14 Jan 2004 14:44:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Agqvj-0003nM-LF for ipv6-archive@odin.ietf.org; Wed, 14 Jan 2004 14:43:55 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0EJhtec014582 for ipv6-archive@odin.ietf.org; Wed, 14 Jan 2004 14:43:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Agqvj-0003n7-CS for ipv6-web-archive@optimus.ietf.org; Wed, 14 Jan 2004 14:43:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05976 for ; Wed, 14 Jan 2004 14:43:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Agqvg-0004si-00 for ipv6-web-archive@ietf.org; Wed, 14 Jan 2004 14:43:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Agqun-0004rF-00 for ipv6-web-archive@ietf.org; Wed, 14 Jan 2004 14:42:57 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Agqtx-0004pZ-00 for ipv6-web-archive@ietf.org; Wed, 14 Jan 2004 14:42:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Agqtt-0003Kj-I9; Wed, 14 Jan 2004 14:42:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Agqt9-0003K6-Ts for ipv6@optimus.ietf.org; Wed, 14 Jan 2004 14:41:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05828 for ; Wed, 14 Jan 2004 14:41:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Agqt7-0004mN-00 for ipv6@ietf.org; Wed, 14 Jan 2004 14:41:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgqsV-0004iE-00 for ipv6@ietf.org; Wed, 14 Jan 2004 14:40:35 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgqrV-0004XZ-00 for ipv6@ietf.org; Wed, 14 Jan 2004 14:39:33 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i0EJcxc03373; Wed, 14 Jan 2004 21:38:59 +0200 Date: Wed, 14 Jan 2004 21:38:59 +0200 (EET) From: Pekka Savola To: Fred Templin cc: ipv6@ietf.org Subject: Re: Proposal for rate limiting parameters In-Reply-To: <400448F1.2040004@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Hi, On Tue, 13 Jan 2004, Fred Templin wrote: > Pekka Savola wrote: > > Designing for this kind of "vastly different capacities in > > each direction" just don't seem to be worth considering here. > > I have to disagree; I believe there is a clear need to design > for diverse link bandwidths to support near-term deployments > and to foster future innovation. There is a different perspective to supporting near-term deployments and fostering innovation.. > 10Kbps seems the best value for LCD, given commonly-deployed > links that will see continued use into the future (see BCP > documents produced by the PILC working group). .. that is, restricting mechanisms based on the least common denominator of Internet does not cut it. As we have up-to 10 Gbit/s links in our network, why again we should limit our use of resources to 10 Kbit/s? :-) One should note that such very constrained environments, like 10 Kbit/s, have to restrict the traffic somehow in any case -- for example, provide the rate-limiting at the edge of such a link. That is, I don't think solving the problem of restricting traffic to fit into these restricted links belongs in this specification. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Jan 14 17:52:35 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18739 for ; Wed, 14 Jan 2004 17:52:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Agtrs-00060T-Tf for ipv6-archive@odin.ietf.org; Wed, 14 Jan 2004 17:52:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0EMq8cv023085 for ipv6-archive@odin.ietf.org; Wed, 14 Jan 2004 17:52:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Agtrs-00060G-Pg for ipv6-web-archive@optimus.ietf.org; Wed, 14 Jan 2004 17:52:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18726 for ; Wed, 14 Jan 2004 17:52:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Agtrq-0007Vu-00 for ipv6-web-archive@ietf.org; Wed, 14 Jan 2004 17:52:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Agtqy-0007TN-00 for ipv6-web-archive@ietf.org; Wed, 14 Jan 2004 17:51:13 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AgtqD-0007QZ-00 for ipv6-web-archive@ietf.org; Wed, 14 Jan 2004 17:50:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Agtpr-0005hi-Nd; Wed, 14 Jan 2004 17:50:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Agtoq-0005gg-BV for ipv6@optimus.ietf.org; Wed, 14 Jan 2004 17:49:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18616 for ; Wed, 14 Jan 2004 17:48:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Agton-0007MX-00 for ipv6@ietf.org; Wed, 14 Jan 2004 17:48:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Agtnq-0007LE-00 for ipv6@ietf.org; Wed, 14 Jan 2004 17:47:59 -0500 Received: from usea-naimss3.unisys.com ([192.61.61.105]) by ietf-mx with esmtp (Exim 4.12) id 1Agtnd-0007K1-00 for ipv6@ietf.org; Wed, 14 Jan 2004 17:47:45 -0500 Received: from usea-nagw2.na.uis.unisys.com ([129.224.72.18]unverified) by 192.61.61.105 with InterScan Messaging Security Suite; Wed, 14 Jan 2004 16:53:45 -0600 Received: from usea-nagw2.na.uis.unisys.com ([129.224.72.53]) by usea-nagw2.na.uis.unisys.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 14 Jan 2004 16:47:13 -0600 Received: from USRV-EXCH2.na.uis.unisys.com ([192.61.245.210]) by usea-nagw2.na.uis.unisys.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 14 Jan 2004 16:47:13 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: ICMPv6 Rate Limiting Methods: Revised Text (2) Date: Wed, 14 Jan 2004 16:47:13 -0600 Message-ID: Thread-Topic: Re: ICMPv6 Rate Limiting Methods: Revised Text (2) Thread-Index: AcPa8FnZ+oj3bd7dQq+EofQ5DpBBqQ== From: "Sellers, Julian P" To: X-OriginalArrivalTime: 14 Jan 2004 22:47:13.0374 (UTC) FILETIME=[5A043FE0:01C3DAF0] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=EXCUSE_16 autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable >From Pekka's text: One good way to implement the rate-limiting function is a token bucket, allowing up to B back-to-back error messages to=20 be transmitted in a burst, but limiting the average rate of=20 transmission to N, where N can either be packets/seconds or a=20 fraction of the attached link's bandwidth. >From an earlier message from Zachary Amsden: It seems to me that "back to back" is ill-defined. It is highly = unlikely that the ICMP error packets will be transmitted with no = other=20 transmissions in between, which "back to back" seems to imply. = The=20 burst allowance should probably be defined as "allowing a burst = of N=20 packets over Ts seconds", or something along these lines. Zachary is right--"back-to-back" adds nothing but confusion. Please = remove "back-to-back." Julian THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY = MATERIAL and is thus for use only by the intended recipient. If you = received this in error, please contact the sender and delete the e-mail = and its attachments from all computers. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Jan 14 21:27:36 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26812 for ; Wed, 14 Jan 2004 21:27:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgxDw-0008Hv-TX for ipv6-archive@odin.ietf.org; Wed, 14 Jan 2004 21:27:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0F2R8hu031847 for ipv6-archive@odin.ietf.org; Wed, 14 Jan 2004 21:27:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgxDw-0008Ha-Nu for ipv6-web-archive@optimus.ietf.org; Wed, 14 Jan 2004 21:27:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26791 for ; Wed, 14 Jan 2004 21:27:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgxDu-0007h7-00 for ipv6-web-archive@ietf.org; Wed, 14 Jan 2004 21:27:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgxCz-0007ez-00 for ipv6-web-archive@ietf.org; Wed, 14 Jan 2004 21:26:10 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AgxCM-0007dA-00 for ipv6-web-archive@ietf.org; Wed, 14 Jan 2004 21:25:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgxBx-0007ie-6k; Wed, 14 Jan 2004 21:25:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgxB5-0007hS-6d for ipv6@optimus.ietf.org; Wed, 14 Jan 2004 21:24:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26701 for ; Wed, 14 Jan 2004 21:24:08 -0500 (EST) From: Mukesh.Gupta@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgxB2-0007aX-00 for ipv6@ietf.org; Wed, 14 Jan 2004 21:24:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgxA5-0007Z9-00 for ipv6@ietf.org; Wed, 14 Jan 2004 21:23:10 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1Agx9Z-0007XS-00 for ipv6@ietf.org; Wed, 14 Jan 2004 21:22:37 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i0F2MS208422 for ; Thu, 15 Jan 2004 04:22:35 +0200 (EET) Received: from daebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 15 Jan 2004 04:22:26 +0200 Received: from daebe009.NOE.Nokia.com ([10.241.35.109]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 14 Jan 2004 20:22:23 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: ICMPv6 Rate Limiting Methods: Revised Text (2) Date: Wed, 14 Jan 2004 20:22:23 -0600 Message-ID: <8D260779A766FB4A9C1739A476F84FA401547110@daebe009.americas.nokia.com> Thread-Topic: Re: ICMPv6 Rate Limiting Methods: Revised Text (2) Thread-Index: AcPa8FnZ+oj3bd7dQq+EofQ5DpBBqQAHczQg To: , X-OriginalArrivalTime: 15 Jan 2004 02:22:23.0186 (UTC) FILETIME=[68DD3B20:01C3DB0E] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,EXCUSE_16,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Julian, do you completely want to remove back-to-back or "..back-to-back=20 ICMP error messages.." will be agreeable ?? I don't mind removing back-to-back if it is creating confusion ? Let me know. Regards Mukesh > -----Original Message----- > From: ipv6-admin@ietf.org [mailto:ipv6-admin@ietf.org]On Behalf Of ext > Sellers, Julian P > Sent: Wednesday, January 14, 2004 2:47 PM > To: ipv6@ietf.org > Subject: Re: ICMPv6 Rate Limiting Methods: Revised Text (2) >=20 >=20 > From Pekka's text: >=20 > One good way to implement the rate-limiting function=20 > is a token > bucket, allowing up to B back-to-back error messages to=20 > be transmitted in a burst, but limiting the average rate of=20 > transmission to N, where N can either be packets/seconds or a=20 > fraction of the attached link's bandwidth. >=20 > From an earlier message from Zachary Amsden: >=20 > It seems to me that "back to back" is ill-defined. =20 > It is highly=20 > unlikely that the ICMP error packets will be=20 > transmitted with no other=20 > transmissions in between, which "back to back" seems=20 > to imply. The=20 > burst allowance should probably be defined as=20 > "allowing a burst of N=20 > packets over Ts seconds", or something along these lines. >=20 > Zachary is right--"back-to-back" adds nothing but confusion. =20 > Please remove "back-to-back." >=20 > Julian >=20 > THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE=20 > PROPRIETARY MATERIAL and is thus for use only by the intended=20 > recipient. If you received this in error, please contact the=20 > sender and delete the e-mail and its attachments from all computers. >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Jan 15 03:10:47 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18047 for ; Thu, 15 Jan 2004 03:10:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ah2a3-0001SX-1f for ipv6-archive@odin.ietf.org; Thu, 15 Jan 2004 03:10:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0F8AIp2005603 for ipv6-archive@odin.ietf.org; Thu, 15 Jan 2004 03:10:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ah2a2-0001SI-DT for ipv6-web-archive@optimus.ietf.org; Thu, 15 Jan 2004 03:10:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18028 for ; Thu, 15 Jan 2004 03:10:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ah2Zy-000313-00 for ipv6-web-archive@ietf.org; Thu, 15 Jan 2004 03:10:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ah2Z1-0002zA-00 for ipv6-web-archive@ietf.org; Thu, 15 Jan 2004 03:09:16 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ah2YF-0002xp-00 for ipv6-web-archive@ietf.org; Thu, 15 Jan 2004 03:08:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ah2Xq-0000xn-HO; Thu, 15 Jan 2004 03:08:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ah2XF-0000rW-ST for ipv6@optimus.ietf.org; Thu, 15 Jan 2004 03:07:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17961 for ; Thu, 15 Jan 2004 03:07:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ah2XB-0002vl-00 for ipv6@ietf.org; Thu, 15 Jan 2004 03:07:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ah2WE-0002tz-00 for ipv6@ietf.org; Thu, 15 Jan 2004 03:06:23 -0500 Received: from coconut.itojun.org ([219.101.47.130]) by ietf-mx with esmtp (Exim 4.12) id 1Ah2Vr-0002s6-00 for ipv6@ietf.org; Thu, 15 Jan 2004 03:05:59 -0500 Received: by coconut.itojun.org (Postfix, from userid 1001) id BC9BFA4; Thu, 15 Jan 2004 17:05:58 +0900 (JST) To: ipv6@ietf.org Subject: Re: getnameinfo and various protocol types In-Reply-To: Your message of "Tue, 30 Dec 2003 12:49:11 -0500" <200312301749.hBUHnBHd010502@rotala.raleigh.ibm.com> References: <200312301749.hBUHnBHd010502@rotala.raleigh.ibm.com> X-Mailer: Cue version 0.6 (031125-1130/itojun) Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="NextPart-20040115170515-0380300" Message-Id: <20040115080558.BC9BFA4@coconut.itojun.org> Date: Thu, 15 Jan 2004 17:05:58 +0900 (JST) From: itojun@itojun.org (Jun-ichiro itojun Hagino) Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,MIME_BOUND_NEXTPART autolearn=no version=2.60 --NextPart-20040115170515-0380300 Content-Type: Text/Plain; charset=us-ascii Here is a rough draft (in i-d format) of my proposal. Since getnameinfo API is defined in POSIX (not in IETF), i would like to collect comments from here, reflect them into the draft, and then send it out to POSIX community. any comments are welcome. (i'll send it out to internet-drafts@ietf too) itojun --NextPart-20040115170515-0380300 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="draft-ietf-ipv6-getnameinfo-multiproto-00.txt" Internet Engineering Task Force Jun-ichiro itojun Hagino INTERNET-DRAFT IIJ Research Laboratory Expires: July 15, 2004 January 15, 2004 Multiple protocol support in getnameinfo API draft-ietf-ipv6-getnameinfo-multiproto-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' To view the list Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. Distribution of this memo is unlimited. The internet-draft will expire in 6 months. The date of expiration will be July 15, 2004. Abstract IPv6 basic API [Gilligan, 2003] defines protocol-independent API for address-to-string conversion, i.e. getnameinfo(3). Current specification, however, assumes that there are two transport-layer protocols - TCP (SOCK_STREAM) and UDP (SOCK_DGRAM), specifically in port number-to-service name conversion. The assumption prohibits getnameinfo(3) from supporting other transport-layer protocols, such as SCTP or DCCP. This document proposes a backward-compatible update to getnameinfo(3) specification to allow the use of other transport-layer protocol in port number-to-service name conversion. This document does not define any new (wire-level) protocol. HAGINO Expires: July 15, 2004 [Page 1] ^L DRAFT multiprotocol getnameinfo January 2004 1. Background getnameinfo(3) API is defined in IPv6 basic API as well as POSIX standard. Under RFC3493 definition, for port number-to-service name conversion, it has two operation modes: the default mode where getservbyport(3) will be called from getnameinfo(3) with "tcp" as 2nd argument, and NI_DGRAM mode where getservbyport(3) will be called with "udp" as 2nd argument. The mode is chosen by the last argument ("flags") to getnameinfo(3). Supposedly, the default mode is for SOCK_STREAM case and NI_DGRAM mode is for SOCK_DGRAM case Here RFC3493 makes a wild assumption - that SOCK_STREAM implies the use of TCP, and SOCK_DGRAM implies the use of UDP. However, the assumption does not hold due to multiple reasons, such as (1) there are other transport protocols coming up like SCTP and DCCP and SOCK_xx and IPPROTO_xx has no 1-by-1 mapping, (2) getnameinfo(3) could be used for non-Internet protocols as well. In this draft we would like to correct the getnameinfo(3) API with respect to the Internet protocol, in a backward-compatible manner. The use of getnameinfo(3) API with non-Internet protocol (and port number- to-service name lookup) needs further study. 2. Updates to getnameinfo(3) API We define the following flag bits, indicating which protocol (instead of socket type) to be used for getservbyport(3) lookup. We also define NI_DGRAM to be same as NI_UDP, and NI_TCP to be 0, for backward compatibility. Note that the value of NI_UDP has to be the same as NI_DGRAM in the past implementation, for backward compatibility reasons. #define NI_TCP 0 #define NI_UDP 0x100 /* the value can vary by implementation */ #define NI_DCCP 0x200 /* the value can vary by implementation */ #define NI_SCTP 0x400 /* the value can vary by implementation */ #define NI_DGRAM NI_UDP The caller of getnameinfo(3) would pass the flag bit. It is encouraged to always specify the proper flag bit, as shown in the following example: HAGINO Expires: July 15, 2004 [Page 2] ^L DRAFT multiprotocol getnameinfo January 2004 int flags, proto; struct sockaddr *sa; char sbuf[NI_MAXSERV]; switch (proto) { case IPPROTO_TCP: flags = NI_TCP; break; case IPPROTO_UDP: flags = NI_UDP; break; case IPPROTO_DCCP: flags = NI_DCCP; break; case IPPROTO_SCTP: flags = NI_SCTP; break; default: flags = NI_NUMERICSERV; break; } if (getnameinfo(sa, sa->sa_len, NULL, 0, sbuf, sizeof(sbuf), flags) != 0) die(); /* error */ /* sbuf has the string representation of service name */ 3. Open issues o How should we handle non-Internet service name lookups? Is it always okay to use NI_NUMERICSRV, or should we provide some way to specify non-Internet service name lookup? (we basically need some example of the usage) 4. Security considerations This document introduces no new security issues. References Gilligan, 2003. R. Gilligan, S. Thomson, J. Bound, J. McCann, and W. R. Stevens, "Basic Socket Interface Extensions for IPv6" in RFC3493 (February 2003). ftp://ftp.isi.edu/in-notes/rfc3493.txt. HAGINO Expires: July 15, 2004 [Page 3] ^L DRAFT multiprotocol getnameinfo January 2004 Change history TBD Acknowledgements This draft was written based on discussions with Japanese IPv6 users and help from the WIDE research group. Author's address Jun-ichiro itojun HAGINO Senior Researcher, Research Laboratory, Internet Initiative Japan Inc. 1-105, Kanda Jinbo-cho, Chiyoda-ku,Tokyo 101-0051, JAPAN Tel: +81-3-5205-6464 Fax: +81-3-5205-6466 Email: itojun@iijlab.net HAGINO Expires: July 15, 2004 [Page 4] ^L --NextPart-20040115170515-0380300-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Jan 15 03:13:46 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18146 for ; Thu, 15 Jan 2004 03:13:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ah2cv-0001r7-3a for ipv6-archive@odin.ietf.org; Thu, 15 Jan 2004 03:13:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0F8DHO5007127 for ipv6-archive@odin.ietf.org; Thu, 15 Jan 2004 03:13:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ah2cu-0001qs-L5 for ipv6-web-archive@optimus.ietf.org; Thu, 15 Jan 2004 03:13:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18139 for ; Thu, 15 Jan 2004 03:13:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ah2cs-00037V-00 for ipv6-web-archive@ietf.org; Thu, 15 Jan 2004 03:13:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ah2c0-00036O-00 for ipv6-web-archive@ietf.org; Thu, 15 Jan 2004 03:12:21 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ah2bi-00034v-00 for ipv6-web-archive@ietf.org; Thu, 15 Jan 2004 03:12:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ah2bg-0001VB-Vr; Thu, 15 Jan 2004 03:12:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ah2b3-0001US-Pi for ipv6@optimus.ietf.org; Thu, 15 Jan 2004 03:11:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18090 for ; Thu, 15 Jan 2004 03:11:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ah2az-00033K-00 for ipv6@ietf.org; Thu, 15 Jan 2004 03:11:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ah2a4-00031z-00 for ipv6@ietf.org; Thu, 15 Jan 2004 03:10:21 -0500 Received: from coconut.itojun.org ([219.101.47.130]) by ietf-mx with esmtp (Exim 4.12) id 1Ah2Zl-00030J-00 for ipv6@ietf.org; Thu, 15 Jan 2004 03:10:01 -0500 Received: by coconut.itojun.org (Postfix, from userid 1001) id DBBB2A6; Thu, 15 Jan 2004 17:10:01 +0900 (JST) To: ipv6@ietf.org Subject: Re: getnameinfo and various protocol types In-Reply-To: Your message of "Thu, 15 Jan 2004 17:05:58 +0900 (JST)" <20040115080558.BC9BFA4@coconut.itojun.org> References: <20040115080558.BC9BFA4@coconut.itojun.org> X-Mailer: Cue version 0.6 (031125-1130/itojun) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20040115081001.DBBB2A6@coconut.itojun.org> Date: Thu, 15 Jan 2004 17:10:01 +0900 (JST) From: itojun@itojun.org (Jun-ichiro itojun Hagino) Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 > Here is a rough draft (in i-d format) of my proposal. Since > getnameinfo API is defined in POSIX (not in IETF), i would like to > collect comments from here, reflect them into the draft, and then send > it out to POSIX community. any comments are welcome. > (i'll send it out to internet-drafts@ietf too) oops, the name of draft is wrong. it should be draft-itojun-xx. i've sent it with corrected name to internet-drafts@ietf. itojun -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Jan 15 03:27:21 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18732 for ; Thu, 15 Jan 2004 03:27:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ah2pY-0002i1-Un for ipv6-archive@odin.ietf.org; Thu, 15 Jan 2004 03:26:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0F8QKoZ010414 for ipv6-archive@odin.ietf.org; Thu, 15 Jan 2004 03:26:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ah2pX-0002hp-Lz for ipv6-web-archive@optimus.ietf.org; Thu, 15 Jan 2004 03:26:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18704 for ; Thu, 15 Jan 2004 03:26:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ah2pV-0003my-00 for ipv6-web-archive@ietf.org; Thu, 15 Jan 2004 03:26:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ah2oe-0003lU-00 for ipv6-web-archive@ietf.org; Thu, 15 Jan 2004 03:25:24 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ah2oO-0003jZ-00 for ipv6-web-archive@ietf.org; Thu, 15 Jan 2004 03:25:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ah2oJ-0002OW-Ic; Thu, 15 Jan 2004 03:25:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ah2ng-0002NK-6E for ipv6@optimus.ietf.org; Thu, 15 Jan 2004 03:24:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18620 for ; Thu, 15 Jan 2004 03:24:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ah2nd-0003iJ-00 for ipv6@ietf.org; Thu, 15 Jan 2004 03:24:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ah2me-0003gj-00 for ipv6@ietf.org; Thu, 15 Jan 2004 03:23:20 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ah2mJ-0003en-00 for ipv6@ietf.org; Thu, 15 Jan 2004 03:23:00 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i0F8MSN11643; Thu, 15 Jan 2004 10:22:28 +0200 Date: Thu, 15 Jan 2004 10:22:28 +0200 (EET) From: Pekka Savola To: "Sellers, Julian P" cc: ipv6@ietf.org Subject: Re: ICMPv6 Rate Limiting Methods: Revised Text (2) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 On Wed, 14 Jan 2004, Sellers, Julian P wrote: > One good way to implement the rate-limiting function is a token > bucket, allowing up to B back-to-back error messages to > be transmitted in a burst, but limiting the average rate of > transmission to N, where N can either be packets/seconds or a > fraction of the attached link's bandwidth. Let's rephrase this then, e.g: One good way to implement the rate-limiting function is a token bucket, limiting the average rate of transmission to N, where N can either be packets/second or a fraction of the attached link's bandwidth, but allowing up to B additional error messages to be transmitted in a burst, as long as a long-term average is not exceeded. (the last line could probably be enhanced a bit more though.) > >From an earlier message from Zachary Amsden: > > It seems to me that "back to back" is ill-defined. It is highly > unlikely that the ICMP error packets will be transmitted with no other > transmissions in between, which "back to back" seems to imply. The > burst allowance should probably be defined as "allowing a burst of N > packets over Ts seconds", or something along these lines. > > Zachary is right--"back-to-back" adds nothing but confusion. > Please remove "back-to-back." Back to back wasn't meant like that, that's right. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Jan 15 08:31:53 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04849 for ; Thu, 15 Jan 2004 08:31:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ah7am-00072O-Ev for ipv6-archive@odin.ietf.org; Thu, 15 Jan 2004 08:31:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0FDVOSN027046 for ipv6-archive@odin.ietf.org; Thu, 15 Jan 2004 08:31:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ah7am-000729-AU for ipv6-web-archive@optimus.ietf.org; Thu, 15 Jan 2004 08:31:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04843 for ; Thu, 15 Jan 2004 08:31:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ah7ag-0000Rb-00 for ipv6-web-archive@ietf.org; Thu, 15 Jan 2004 08:31:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ah7Y0-0000OH-00 for ipv6-web-archive@ietf.org; Thu, 15 Jan 2004 08:28:33 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ah7Xp-0000Md-00 for ipv6-web-archive@ietf.org; Thu, 15 Jan 2004 08:28:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ah7XV-0006fV-Hi; Thu, 15 Jan 2004 08:28:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ah7Wx-0006f5-El for ipv6@optimus.ietf.org; Thu, 15 Jan 2004 08:27:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04773 for ; Thu, 15 Jan 2004 08:27:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ah7Ww-0000LY-00 for ipv6@ietf.org; Thu, 15 Jan 2004 08:27:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ah7Vz-0000KS-00 for ipv6@ietf.org; Thu, 15 Jan 2004 08:26:28 -0500 Received: from web80506.mail.yahoo.com ([66.218.79.76]) by ietf-mx with smtp (Exim 4.12) id 1Ah7Vl-0000JZ-00 for ipv6@ietf.org; Thu, 15 Jan 2004 08:26:14 -0500 Message-ID: <20040115132542.94180.qmail@web80506.mail.yahoo.com> Received: from [63.197.18.101] by web80506.mail.yahoo.com via HTTP; Thu, 15 Jan 2004 05:25:42 PST Date: Thu, 15 Jan 2004 05:25:42 -0800 (PST) From: Fred Templin Subject: Re: Proposal for rate limiting parameters To: Pekka Savola , Fred Templin Cc: ipv6@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-405288307-1074173142=:90407" Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.0 required=5.0 tests=AWL,FROM_ENDS_IN_NUMS, HTML_MESSAGE,MAILTO_TO_SPAM_ADDR autolearn=no version=2.60 --0-405288307-1074173142=:90407 Content-Type: text/plain; charset=us-ascii Pekka Savola wrote: > On Tue, 13 Jan 2004, Fred Templin wrote: > > 10Kbps seems the best value for LCD, given commonly-deployed > > links that will see continued use into the future (see BCP > > documents produced by the PILC working group). > > .. that is, restricting mechanisms based on the least common > denominator of Internet does not cut it. As we have up-to 10 Gbit/s > links in our network, why again we should limit our use of resources > to 10 Kbit/s? :-) No; not seeking to constrain high-speed links based on LCD at all. But, the important point that you seem to be agreeing with is that there will be a wide diversity of link bandwidths in the Internet both now and into the future. > One should note that such very constrained environments, like 10 > Kbit/s, have to restrict the traffic somehow in any case -- for > example, provide the rate-limiting at the edge of such a link. I must agree on this point as being well supported by the BCP documents. The active queue management recommendation for forwarding nodes in front of slow links seems particularly important. Fred L. Templin osprey67@yahoo.com --0-405288307-1074173142=:90407 Content-Type: text/html; charset=us-ascii
Pekka Savola <pekkas@netcore.fi> wrote:
 
> On Tue, 13 Jan 2004, Fred Templin wrote:
> > 10Kbps seems the best value for LCD, given commonly-deployed
> > links that will see continued use into the future (see BCP
> > documents produced by the PILC working group).
>
> .. that is, restricting mechanisms based on the least common
> denominator of Internet does not cut it. As we have up-to 10 Gbit/s
> links in our network, why again we should limit our use of resources
> to 10 Kbit/s? :-)
 
No; not seeking to constrain high-speed links based on LCD at all.
But, the important point that you seem to be agreeing with is that
there will be a wide diversity of link bandwidths in the Internet both
now and into the future.  

> One should note that such very constrained environments, like 10
> Kbit/s, have to restrict the traffic somehow in any case -- for
> example, provide the rate-limiting at the edge of such a link.
I must agree on this point as being well supported by the BCP
documents. The active queue management recommendation for
forwarding nodes in front of slow links seems particularly important.
 
Fred L. Templin
--0-405288307-1074173142=:90407-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Jan 15 09:04:58 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06103 for ; Thu, 15 Jan 2004 09:04:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ah86m-0000qA-4W for ipv6-archive@odin.ietf.org; Thu, 15 Jan 2004 09:04:28 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0FE4ShF003224 for ipv6-archive@odin.ietf.org; Thu, 15 Jan 2004 09:04:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ah86m-0000pv-0J for ipv6-web-archive@optimus.ietf.org; Thu, 15 Jan 2004 09:04:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06051 for ; Thu, 15 Jan 2004 09:04:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ah86k-0002DD-00 for ipv6-web-archive@ietf.org; Thu, 15 Jan 2004 09:04:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ah85m-00027C-00 for ipv6-web-archive@ietf.org; Thu, 15 Jan 2004 09:03:26 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ah84o-0001zg-00 for ipv6-web-archive@ietf.org; Thu, 15 Jan 2004 09:02:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ah84V-0000M0-9r; Thu, 15 Jan 2004 09:02:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ah84M-0000JJ-SA for ipv6@optimus.ietf.org; Thu, 15 Jan 2004 09:01:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05861 for ; Thu, 15 Jan 2004 09:01:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ah84L-0001wj-00 for ipv6@ietf.org; Thu, 15 Jan 2004 09:01:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ah83U-0001pg-00 for ipv6@ietf.org; Thu, 15 Jan 2004 09:01:05 -0500 Received: from web80509.mail.yahoo.com ([66.218.79.79]) by ietf-mx with smtp (Exim 4.12) id 1Ah82Z-0001dt-00 for ipv6@ietf.org; Thu, 15 Jan 2004 09:00:07 -0500 Message-ID: <20040115135932.49763.qmail@web80509.mail.yahoo.com> Received: from [63.197.18.101] by web80509.mail.yahoo.com via HTTP; Thu, 15 Jan 2004 05:59:32 PST Date: Thu, 15 Jan 2004 05:59:32 -0800 (PST) From: Fred Templin Subject: Re: ICMPv6 Rate Limiting Methods: Revised Text (2) To: Pekka Savola , "Sellers, Julian P" Cc: ipv6@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-742139760-1074175172=:49717" Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.2 required=5.0 tests=AWL,FROM_ENDS_IN_NUMS, HTML_20_30,HTML_MESSAGE,MAILTO_TO_SPAM_ADDR autolearn=no version=2.60 --0-742139760-1074175172=:49717 Content-Type: text/plain; charset=us-ascii Pekka Savola wrote: > Let's rephrase this then, e.g: > > One good way to implement the rate-limiting function is a token > bucket, limiting the average rate of transmission to N, where N > can either be packets/second or a fraction of the attached > link's bandwidth, but allowing up to B additional error > messages to be transmitted in a burst, as long as a long-term > average is not exceeded. I didn't mind the "back-to-back" text, but am fine with what you are proposing here. I must admit that I tried wordsmithing the text a bit, but could not find a combination that clearly improved readability. Fred L. Templin osprey67@yahoo.com --0-742139760-1074175172=:49717 Content-Type: text/html; charset=us-ascii
Pekka Savola <pekkas@netcore.fi> wrote:

> Let's rephrase this then, e.g:
>
>         One good way to implement the rate-limiting function is a token
>         bucket, limiting the average rate of transmission to N, where N
>         can either be packets/second or a fraction of the attached
>         link's bandwidth, but allowing up to B additional error
>         messages to be transmitted in a burst, as long as a long-term
>        average is not exceeded.
 
I didn't mind the "back-to-back" text, but am fine with what
you are proposing here. I must admit that I tried wordsmithing
the text a bit, but could not find a combination that clearly
improved readability.
 
Fred L. Templin
--0-742139760-1074175172=:49717-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Jan 15 09:38:10 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08413 for ; Thu, 15 Jan 2004 09:38:10 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ah8cv-00039F-Kn for ipv6-archive@odin.ietf.org; Thu, 15 Jan 2004 09:37:42 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0FEbfLc012098 for ipv6-archive@odin.ietf.org; Thu, 15 Jan 2004 09:37:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ah8cu-00038n-Qm for ipv6-web-archive@optimus.ietf.org; Thu, 15 Jan 2004 09:37:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08406 for ; Thu, 15 Jan 2004 09:37:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ah8ct-0005C5-00 for ipv6-web-archive@ietf.org; Thu, 15 Jan 2004 09:37:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ah8by-00058l-00 for ipv6-web-archive@ietf.org; Thu, 15 Jan 2004 09:36:43 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ah8bf-00055l-00 for ipv6-web-archive@ietf.org; Thu, 15 Jan 2004 09:36:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ah8bK-0002dU-F8; Thu, 15 Jan 2004 09:36:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ah8ar-0002at-9Q for ipv6@optimus.ietf.org; Thu, 15 Jan 2004 09:35:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08288 for ; Thu, 15 Jan 2004 09:35:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ah8ap-000539-00 for ipv6@ietf.org; Thu, 15 Jan 2004 09:35:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ah8Zw-000509-00 for ipv6@ietf.org; Thu, 15 Jan 2004 09:34:37 -0500 Received: from usea-naimss2.unisys.com ([192.61.61.104]) by ietf-mx with esmtp (Exim 4.12) id 1Ah8ZF-0004uD-00 for ipv6@ietf.org; Thu, 15 Jan 2004 09:33:53 -0500 Received: from usea-nagw3.na.uis.unisys.com ([129.224.72.20]unverified) by 192.61.61.104 with InterScan Messaging Security Suite; Thu, 15 Jan 2004 08:32:29 -0600 Received: from usea-nagw3.na.uis.unisys.com ([129.224.72.55]) by usea-nagw3.na.uis.unisys.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 15 Jan 2004 08:33:08 -0600 Received: from USRV-EXCH2.na.uis.unisys.com ([192.61.245.210]) by usea-nagw3.na.uis.unisys.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 15 Jan 2004 08:33:08 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3DB74.7E6E9CC1" Subject: RE: ICMPv6 Rate Limiting Methods: Revised Text (2) Date: Thu, 15 Jan 2004 08:33:08 -0600 Message-ID: Thread-Topic: ICMPv6 Rate Limiting Methods: Revised Text (2) Thread-Index: AcPbb84CkQGpd0F2SoSACkBEi/8LvAAAu9GA From: "Sellers, Julian P" To: "Fred Templin" , "Pekka Savola" Cc: X-OriginalArrivalTime: 15 Jan 2004 14:33:08.0151 (UTC) FILETIME=[7E7FF470:01C3DB74] Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.4 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_BLUE,HTML_MESSAGE,MAILTO_TO_SPAM_ADDR autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C3DB74.7E6E9CC1 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I think Pekka's rephrasing is good. (I would remove the word = "additional.") =20 Julian -----Original Message----- From: Fred Templin [mailto:osprey67@yahoo.com] Sent: Thursday, January 15, 2004 8:00 AM To: Pekka Savola; Sellers, Julian P Cc: ipv6@ietf.org Subject: Re: ICMPv6 Rate Limiting Methods: Revised Text (2) Pekka Savola wrote: > Let's rephrase this then, e.g: >=20 > One good way to implement the rate-limiting function is a = token > bucket, limiting the average rate of transmission to N, where = N=20 > can either be packets/second or a fraction of the attached=20 > link's bandwidth, but allowing up to B additional error=20 > messages to be transmitted in a burst, as long as a long-term > average is not exceeded. =20 I didn't mind the "back-to-back" text, but am fine with what you are proposing here. I must admit that I tried wordsmithing the text a bit, but could not find a combination that clearly improved readability. =20 Fred L. Templin osprey67@yahoo.com ------_=_NextPart_001_01C3DB74.7E6E9CC1 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I think=20 Pekka's rephrasing is good.  (I would remove the word=20 "additional.")
 
Julian
-----Original Message-----
From: Fred Templin=20 [mailto:osprey67@yahoo.com]
Sent: Thursday, January 15, 2004 = 8:00=20 AM
To: Pekka Savola; Sellers, Julian P
Cc:=20 ipv6@ietf.org
Subject: Re: ICMPv6 Rate Limiting Methods: = Revised=20 Text (2)

Pekka Savola <pekkas@netcore.fi> wrote:

> Let's rephrase this then, e.g:
>
>=20         One good way to implement = the=20 rate-limiting function is a token
>=20         bucket, limiting the = average rate=20 of transmission to N, where N
>=20         can either be = packets/second or a=20 fraction of the attached
> =        =20 link's bandwidth, but allowing up to B additional error
>=20         messages to be transmitted = in a=20 burst, as long as a long-term
> =       =20 average is not exceeded.
 
I didn't mind the "back-to-back" text, but am fine with = what
you are proposing here. I must admit that I tried = wordsmithing
the text a bit, but could not find a combination that = clearly
improved readability.
 
Fred L. Templin
osprey67@yahoo.com
------_=_NextPart_001_01C3DB74.7E6E9CC1-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Jan 15 18:20:16 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08282 for ; Thu, 15 Jan 2004 18:20:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhGmD-0001yf-9s for ipv6-archive@odin.ietf.org; Thu, 15 Jan 2004 18:19:49 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0FNJnEm007595 for ipv6-archive@odin.ietf.org; Thu, 15 Jan 2004 18:19:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhGmD-0001yQ-1p for ipv6-web-archive@optimus.ietf.org; Thu, 15 Jan 2004 18:19:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08278 for ; Thu, 15 Jan 2004 18:19:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhGmA-0004dm-00 for ipv6-web-archive@ietf.org; Thu, 15 Jan 2004 18:19:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhGlD-0004cI-00 for ipv6-web-archive@ietf.org; Thu, 15 Jan 2004 18:18:48 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AhGl8-0004ay-00 for ipv6-web-archive@ietf.org; Thu, 15 Jan 2004 18:18:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhGkU-0001kc-0r; Thu, 15 Jan 2004 18:18:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhGkK-0001kL-PT for ipv6@optimus.ietf.org; Thu, 15 Jan 2004 18:17:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08183 for ; Thu, 15 Jan 2004 18:17:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhGkH-0004aM-00 for ipv6@ietf.org; Thu, 15 Jan 2004 18:17:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhGjK-0004Yf-00 for ipv6@ietf.org; Thu, 15 Jan 2004 18:16:50 -0500 Received: from transfire.txc.com ([208.5.237.254] helo=pguin2.txc.com) by ietf-mx with esmtp (Exim 4.12) id 1AhGj6-0004Wr-00 for ipv6@ietf.org; Thu, 15 Jan 2004 18:16:36 -0500 Received: from txc.com ([172.17.0.173]) by pguin2.txc.com (8.11.2/8.11.2) with ESMTP id i0FNGa011014 for ; Thu, 15 Jan 2004 18:16:36 -0500 Message-ID: <40071F53.D66A63DC@txc.com> Date: Thu, 15 Jan 2004 18:16:35 -0500 From: srihari varada X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ipv6@ietf.org Subject: IPv6 over PPP Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Dear all: I am tasked to update the IPv6 over PPP spec. (RFC 2472). In that regard, I am soliciting comments that you may have on the spec. They could be from implementation experience or as simple as textual clarifications to induce right inference. Please provide your input at your convenience. I appreciate those that have supplied the input already. Regards, Srihari Varada -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Jan 16 10:05:37 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16522 for ; Fri, 16 Jan 2004 10:05:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhVX3-0005kT-TO for ipv6-archive@odin.ietf.org; Fri, 16 Jan 2004 10:05:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0GF59VD022096 for ipv6-archive@odin.ietf.org; Fri, 16 Jan 2004 10:05:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhVWy-0005k7-Nk for ipv6-web-archive@optimus.ietf.org; Fri, 16 Jan 2004 10:05:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16458 for ; Fri, 16 Jan 2004 10:04:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhVWq-0001Dt-00 for ipv6-web-archive@ietf.org; Fri, 16 Jan 2004 10:04:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhVUz-000178-00 for ipv6-web-archive@ietf.org; Fri, 16 Jan 2004 10:03:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AhVSy-00011L-00 for ipv6-web-archive@ietf.org; Fri, 16 Jan 2004 10:00:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhVS9-0005JZ-5B; Fri, 16 Jan 2004 10:00:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhVR4-0005E3-Ej for ipv6@optimus.ietf.org; Fri, 16 Jan 2004 09:59:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16199 for ; Fri, 16 Jan 2004 09:58:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhVQq-0000vD-00 for ipv6@ietf.org; Fri, 16 Jan 2004 09:58:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhVMf-0000mn-00 for ipv6@ietf.org; Fri, 16 Jan 2004 09:54:25 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhVLW-0000db-00 for ipv6@ietf.org; Fri, 16 Jan 2004 09:53:15 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i0GEq3K32635; Fri, 16 Jan 2004 16:52:03 +0200 Date: Fri, 16 Jan 2004 16:52:03 +0200 (EET) From: Pekka Savola To: "Sellers, Julian P" cc: Fred Templin , Subject: RE: ICMPv6 Rate Limiting Methods: Revised Text (2) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MAILTO_TO_SPAM_ADDR autolearn=no version=2.60 (Sorry, this wound up in my "probably-spam" folder as it contained HTML markups..) On Thu, 15 Jan 2004, Sellers, Julian P wrote: > I think Pekka's rephrasing is good. (I would remove the word > "additional.") Yes, I agree "additional" is unnecessary there. > Pekka Savola wrote: > > Let's rephrase this then, e.g: > > > > One good way to implement the rate-limiting function is a token > > bucket, limiting the average rate of transmission to N, where N > > can either be packets/second or a fraction of the attached > > link's bandwidth, but allowing up to B additional error > > messages to be transmitted in a burst, as long as a long-term > > average is not exceeded. > > I didn't mind the "back-to-back" text, but am fine with what > you are proposing here. I must admit that I tried wordsmithing > the text a bit, but could not find a combination that clearly > improved readability. > > Fred L. Templin > osprey67@yahoo.com > > -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sun Jan 18 00:08:59 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27398 for ; Sun, 18 Jan 2004 00:08:59 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ai5Am-00021A-CW for ipv6-archive@odin.ietf.org; Sun, 18 Jan 2004 00:08:32 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0I58Wbg007753 for ipv6-archive@odin.ietf.org; Sun, 18 Jan 2004 00:08:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ai5Am-00020y-5D for ipv6-web-archive@optimus.ietf.org; Sun, 18 Jan 2004 00:08:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27387 for ; Sun, 18 Jan 2004 00:08:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ai5Aj-0000XI-00 for ipv6-web-archive@ietf.org; Sun, 18 Jan 2004 00:08:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ai59r-0000Uz-00 for ipv6-web-archive@ietf.org; Sun, 18 Jan 2004 00:07:36 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ai59M-0000So-00 for ipv6-web-archive@ietf.org; Sun, 18 Jan 2004 00:07:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ai58M-0001PF-8P; Sun, 18 Jan 2004 00:06:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ai57m-0001OO-01 for ipv6@optimus.ietf.org; Sun, 18 Jan 2004 00:05:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27268 for ; Sun, 18 Jan 2004 00:05:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ai57j-0000M9-00 for ipv6@ietf.org; Sun, 18 Jan 2004 00:05:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ai56G-0000Ih-00 for ipv6@ietf.org; Sun, 18 Jan 2004 00:03:52 -0500 Received: from cyteen.hactrn.net ([66.92.66.68]) by ietf-mx with esmtp (Exim 4.12) id 1Ai53h-00007x-00 for ipv6@ietf.org; Sun, 18 Jan 2004 00:01:14 -0500 Received: from hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id 305DC88E for ; Sun, 18 Jan 2004 00:00:14 -0500 (EST) To: ipv6@ietf.org Subject: Weekly posting summary for ipv6@ietf.org From: Rob Austein Date: Sun, 18 Jan 2004 00:00:14 -0500 Message-Id: <20040118050014.305DC88E@cyteen.hactrn.net> Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.7 required=5.0 tests=AWL,MAILTO_TO_SPAM_ADDR autolearn=no version=2.60 Messages | Bytes | Who --------+------+--------+----------+------------------------ 26.32% | 5 | 21.15% | 21727 | pekkas@netcore.fi 10.53% | 2 | 12.51% | 12852 | itojun@itojun.org 10.53% | 2 | 11.46% | 11771 | julian.sellers@unisys.com 10.53% | 2 | 10.55% | 10838 | osprey67@yahoo.com 10.53% | 2 | 10.55% | 10837 | mukesh.gupta@nokia.com 5.26% | 1 | 14.59% | 14992 | jim.bound@hp.com 10.53% | 2 | 8.46% | 8692 | ftemplin@iprg.nokia.com 5.26% | 1 | 4.09% | 4199 | sra+ipng@hactrn.net 5.26% | 1 | 3.59% | 3692 | bob.hinden@nokia.com 5.26% | 1 | 3.04% | 3125 | varada@txc.com --------+------+--------+----------+------------------------ 100.00% | 19 |100.00% | 102725 | Total Grunchweather Associates provides this automatic summary on an at-whim basis at the request of the IPv6 WG chairs. Your mileage may vary. We decline responsibilities, all shapes, all sizes, all colors. If this script produces broken output, you get to keep both pieces. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sun Jan 18 15:29:36 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01322 for ; Sun, 18 Jan 2004 15:29:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AiJXf-0006Fe-B9 for ipv6-archive@odin.ietf.org; Sun, 18 Jan 2004 15:29:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0IKT7cl024027 for ipv6-archive@odin.ietf.org; Sun, 18 Jan 2004 15:29:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AiJXf-0006FS-4X for ipv6-web-archive@optimus.ietf.org; Sun, 18 Jan 2004 15:29:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01311 for ; Sun, 18 Jan 2004 15:29:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AiJXd-00075D-00 for ipv6-web-archive@ietf.org; Sun, 18 Jan 2004 15:29:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AiJWf-00071z-00 for ipv6-web-archive@ietf.org; Sun, 18 Jan 2004 15:28:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AiJW6-0006zb-00 for ipv6-web-archive@ietf.org; Sun, 18 Jan 2004 15:27:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AiJVc-0005vA-RR; Sun, 18 Jan 2004 15:27:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AiJUv-0005uW-WC for ipv6@optimus.ietf.org; Sun, 18 Jan 2004 15:26:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01127 for ; Sun, 18 Jan 2004 15:26:16 -0500 (EST) From: Mukesh.Gupta@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AiJUu-0006u7-00 for ipv6@ietf.org; Sun, 18 Jan 2004 15:26:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AiJTr-0006pW-00 for ipv6@ietf.org; Sun, 18 Jan 2004 15:25:12 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AiJTQ-0006ml-00 for ipv6@ietf.org; Sun, 18 Jan 2004 15:24:44 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i0IKOfV02520 for ; Sun, 18 Jan 2004 22:24:42 +0200 (EET) Received: from daebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Sun, 18 Jan 2004 22:24:41 +0200 Received: from daebe009.NOE.Nokia.com ([10.241.35.109]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Sun, 18 Jan 2004 14:24:39 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: ICMPv6 Rate Limiting Methods: Revised Test (final ??) Date: Sun, 18 Jan 2004 14:24:38 -0600 Message-ID: <8D260779A766FB4A9C1739A476F84FA401547125@daebe009.americas.nokia.com> Thread-Topic: ICMPv6 Rate Limiting Methods: Revised Test (final ??) Thread-Index: AcPeARlYbf+uu4qnQqOhKuuvaNe2DA== To: X-OriginalArrivalTime: 18 Jan 2004 20:24:39.0990 (UTC) FILETIME=[19746D60:01C3DE01] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Here is the final revision of the text that everyone seems to agree upon. I will put this in the draft. Please let me know if anyone has anymore comments on this. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D (f) Finally, in order to limit the bandwidth and forwarding costs incurred sending ICMPv6 error messages, an IPv6 node MUST limit the rate of ICMPv6 error messages it sends. This situation may occur when a source sending a stream of erroneous packets fails to heed the resulting ICMPv6 error messages. One good way to implement the rate-limiting function is a token bucket, limiting the average rate of transmission to N, where N can either be packets/second or a fraction of the attached link's bandwidth, but allowing up to B error messages to be transmitted in a burst, as long as the long-term average is not exceeded. Rate-limiting mechanisms which cannot cope with bursty traffic (e.g., traceroute) are not recommended; thus a simple timer- based implementation, allowing an error message every T milliseconds (even with low values for T), is not reasonable. The rate-limiting parameters SHOULD be configurable. In the case of a token-bucket implementation, the best defaults depend on where the implementation is expected to be deployed (e.g., a high-end router vs. an embedded host). For example, in a small/mid -sized device, the possible defaults could be B=3D10, N=3D10/s. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Regards Mukesh -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sun Jan 18 18:28:45 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07664 for ; Sun, 18 Jan 2004 18:28:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AiML2-0003HI-9K for ipv6-archive@odin.ietf.org; Sun, 18 Jan 2004 18:28:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0INSGRj012597 for ipv6-archive@odin.ietf.org; Sun, 18 Jan 2004 18:28:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AiML2-0003H5-0u for ipv6-web-archive@optimus.ietf.org; Sun, 18 Jan 2004 18:28:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07652 for ; Sun, 18 Jan 2004 18:28:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AiMKz-0007SV-00 for ipv6-web-archive@ietf.org; Sun, 18 Jan 2004 18:28:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AiMK6-0007Pd-00 for ipv6-web-archive@ietf.org; Sun, 18 Jan 2004 18:27:19 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AiMJV-0007MT-00 for ipv6-web-archive@ietf.org; Sun, 18 Jan 2004 18:26:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AiMIs-0002xr-IB; Sun, 18 Jan 2004 18:26:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AiMHz-0002wR-BJ for ipv6@optimus.ietf.org; Sun, 18 Jan 2004 18:25:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07504 for ; Sun, 18 Jan 2004 18:25:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AiMHw-0007GP-00 for ipv6@ietf.org; Sun, 18 Jan 2004 18:25:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AiMH2-0007FK-00 for ipv6@ietf.org; Sun, 18 Jan 2004 18:24:09 -0500 Received: from web80502.mail.yahoo.com ([66.218.79.72]) by ietf-mx with smtp (Exim 4.12) id 1AiMGc-0007DZ-00 for ipv6@ietf.org; Sun, 18 Jan 2004 18:23:42 -0500 Message-ID: <20040118232307.55752.qmail@web80502.mail.yahoo.com> Received: from [63.197.18.101] by web80502.mail.yahoo.com via HTTP; Sun, 18 Jan 2004 15:23:07 PST Date: Sun, 18 Jan 2004 15:23:07 -0800 (PST) From: Fred Templin Subject: Re: ICMPv6 Rate Limiting Methods: Revised Test (final ??) To: Mukesh.Gupta@nokia.com, ipv6@ietf.org In-Reply-To: <8D260779A766FB4A9C1739A476F84FA401547125@daebe009.americas.nokia.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1826410497-1074468187=:54591" Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.0 required=5.0 tests=AWL,FROM_ENDS_IN_NUMS, HTML_MESSAGE,MAILTO_TO_SPAM_ADDR autolearn=no version=2.60 --0-1826410497-1074468187=:54591 Content-Type: text/plain; charset=us-ascii Mukesh, See comments below: Mukesh.Gupta@nokia.com wrote: > Here is the final revision of the text that everyone seems to agree > upon. I will put this in the draft. Please let me know if anyone has > anymore comments on this. > > =================================================== > (f) Finally, in order to limit the bandwidth and forwarding costs > incurred sending ICMPv6 error messages, an IPv6 node MUST limit > the rate of ICMPv6 error messages it sends. This situation may > occur when a source sending a stream of erroneous packets fails > to heed the resulting ICMPv6 error messages. > > One good way to implement the rate-limiting function is a token Something about the phrase: "One good way" seems a bit unusual to appear in standards documents; I prefer something like: "A suggested method". > bucket, limiting the average rate of transmission to N, where N > can either be packets/second or a fraction of the attached > link's bandwidth, but allowing up to B error messages to be > transmitted in a burst, as long as the long-term average is not > exceeded. I think we may have glossed over this in earlier discussion, but I believe 'B' should be allowed as an expression of either messages OR bytes. Size *does* matter in certain cases, and expressing 'B' only in terms of a number of messages is too limiting. I think this can be fixed rather simply by changing the phrase: "B error messages" to "B error messages/bytes". > Rate-limiting mechanisms which cannot cope with bursty traffic > (e.g., traceroute) are not recommended; thus a simple timer- > based implementation, allowing an error message every T > milliseconds (even with low values for T), is not reasonable. I don't see the purpose in dis-recommending a particular scheme, (i.e., the simple timer), since there are infinitely many other possibilities that would be equally bad (or worse). Suggest shortening this paragraph to a single sentence such as: "Rate-limiting mechanisms which cannot cope with bursty traffic (e.g., traceroute) are not recommended." > The rate-limiting parameters SHOULD be configurable. In the > case of a token-bucket implementation, the best defaults depend > on where the implementation is expected to be deployed (e.g., a > high-end router vs. an embedded host). For example, in a > small/mid -sized device, the possible defaults could be B=10, > N=10/s. I may have missed this in earlier discussion, but the "SHOULD" above used to be a "MUST" in the earlier text - is there any reason we are now saying "SHOULD" instead of "MUST"? Also, I no longer see the value in listing possible default values for B/N. Since B/N can be used to represent either packets or bytes, simple scalar values like "10" have no meaning. Suggest dropping the entire sentence beginning: "For example, in a...". Fred L. Templin osprey67@yahoo.com --0-1826410497-1074468187=:54591 Content-Type: text/html; charset=us-ascii
Mukesh,
 
See comments below:

Mukesh.Gupta@nokia.com wrote:
 
> Here is the final revision of the text that everyone seems to agree
> upon. I will put this in the draft. Please let me know if anyone has
> anymore comments on this.
>
> ===================================================
>     (f) Finally, in order to limit the bandwidth and forwarding costs
>         incurred sending ICMPv6 error messages, an IPv6 node MUST limit
>         the rate of ICMPv6 error messages it sends.  This situation may
>         occur when a source sending a stream of erroneous packets fails
>         to heed the resulting ICMPv6 error messages.
>
>         One good way to implement the rate-limiting function is a token
 
Something about the phrase: "One good way" seems a bit unusual
to appear in standards documents; I prefer something like:
"A suggested method".

>         bucket, limiting the average rate of transmission to N, where N
>         can either be packets/second or a fraction of the attached
>         link's bandwidth, but allowing up to B error messages to be
>         transmitted in a burst, as long as the long-term average is not
>         exceeded.
 
I think we may have glossed over this in earlier discussion, but I believe
'B' should be allowed as an expression of either messages OR bytes.
Size *does* matter in certain cases, and expressing 'B' only in terms
of a number of messages is too limiting. I think this can be fixed rather
simply by changing the phrase: "B error messages" to
"B error messages/bytes".

>         Rate-limiting mechanisms which cannot cope with bursty traffic
>         (e.g., traceroute) are not recommended; thus a simple timer-
>         based implementation, allowing an error message every T
>         milliseconds (even with low values for T), is not reasonable.
 
I don't see the purpose in dis-recommending a particular scheme,
(i.e., the simple timer), since there are infinitely many other
possibilities that would be equally bad (or worse). Suggest
shortening this paragraph to a single sentence such as:
 
   "Rate-limiting mechanisms which cannot cope with bursty traffic
   (e.g., traceroute) are not recommended."

>         The rate-limiting parameters SHOULD be configurable.  In the
>         case of a token-bucket implementation, the best defaults depend
>         on where the implementation is expected to be deployed (e.g., a
>         high-end router vs. an embedded host).  For example, in a
>         small/mid -sized device, the possible defaults could be B=10,
>         N=10/s.
 
I may have missed this in earlier discussion, but the "SHOULD"
above used to be a "MUST" in the earlier text - is there any reason
we are now saying "SHOULD" instead of "MUST"?
 
Also, I no longer see the value in listing possible default values for
B/N. Since B/N can be used to represent either packets or bytes,
simple scalar values like "10" have no meaning. Suggest dropping
the entire sentence beginning: "For example, in a...".
 
Fred L. Templin
--0-1826410497-1074468187=:54591-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Jan 19 02:38:00 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03985 for ; Mon, 19 Jan 2004 02:38:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AiTyV-0007JL-D3 for ipv6-archive@odin.ietf.org; Mon, 19 Jan 2004 02:37:32 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0J7bViq028060 for ipv6-archive@odin.ietf.org; Mon, 19 Jan 2004 02:37:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AiTyQ-0007II-BV for ipv6-web-archive@optimus.ietf.org; Mon, 19 Jan 2004 02:37:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03979 for ; Mon, 19 Jan 2004 02:37:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AiTyM-0007SF-00 for ipv6-web-archive@ietf.org; Mon, 19 Jan 2004 02:37:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AiTxR-0007QO-00 for ipv6-web-archive@ietf.org; Mon, 19 Jan 2004 02:36:26 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AiTwu-0007O7-00 for ipv6-web-archive@ietf.org; Mon, 19 Jan 2004 02:35:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AiTw8-0006re-A3; Mon, 19 Jan 2004 02:35:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AiTvR-0006q1-0v for ipv6@optimus.ietf.org; Mon, 19 Jan 2004 02:34:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03888 for ; Mon, 19 Jan 2004 02:34:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AiTvN-0007KM-00 for ipv6@ietf.org; Mon, 19 Jan 2004 02:34:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AiTuP-0007IP-00 for ipv6@ietf.org; Mon, 19 Jan 2004 02:33:17 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1AiTtV-0007F2-00 for ipv6@ietf.org; Mon, 19 Jan 2004 02:32:21 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i0J7Qjf08102; Mon, 19 Jan 2004 09:26:45 +0200 Date: Mon, 19 Jan 2004 09:26:45 +0200 (EET) From: Pekka Savola To: Fred Templin cc: Mukesh.Gupta@nokia.com, Subject: Re: ICMPv6 Rate Limiting Methods: Revised Test (final ??) In-Reply-To: <20040118232307.55752.qmail@web80502.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Sun, 18 Jan 2004, Fred Templin wrote: > > =================================================== > > (f) Finally, in order to limit the bandwidth and forwarding costs > > incurred sending ICMPv6 error messages, an IPv6 node MUST limit > > the rate of ICMPv6 error messages it sends. This situation may > > occur when a source sending a stream of erroneous packets fails > > to heed the resulting ICMPv6 error messages. > > > > One good way to implement the rate-limiting function is a token > > Something about the phrase: "One good way" seems a bit unusual > to appear in standards documents; I prefer something like: > "A suggested method". Fine by me, even though it's weaker. > > bucket, limiting the average rate of transmission to N, where N > > can either be packets/second or a fraction of the attached > > link's bandwidth, but allowing up to B error messages to be > > transmitted in a burst, as long as the long-term average is not > > exceeded. > > I think we may have glossed over this in earlier discussion, but I believe > 'B' should be allowed as an expression of either messages OR bytes. > Size *does* matter in certain cases, and expressing 'B' only in terms > of a number of messages is too limiting. I think this can be fixed rather > simply by changing the phrase: "B error messages" to > "B error messages/bytes". I don't think is a good idea. This complicates the text, and for most implementations, counting the error bytes doesn't really make sense. In addition, this is still a suggestion or "one good way". > > Rate-limiting mechanisms which cannot cope with bursty traffic > > (e.g., traceroute) are not recommended; thus a simple timer- > > based implementation, allowing an error message every T > > milliseconds (even with low values for T), is not reasonable. > > I don't see the purpose in dis-recommending a particular scheme, > (i.e., the simple timer), since there are infinitely many other > possibilities that would be equally bad (or worse). Suggest > shortening this paragraph to a single sentence such as: IMHO, it makes sense to dis-recommend an approach, because it's actually deployed out there, and thus it seems to be a good idea to specifically say that it is NOT a good idea. I'm not aware of other, "really broken" mechanisms which would have been deployed. Moreover, this was suggested in the previous RFC, so recommending against it explicitly seems like a good idea. The text could use a bit sharpening up, to say that timer-based discouragement is just and example, though, like: Rate-limiting mechanisms which cannot cope with bursty traffic (e.g., traceroute) are not recommended; for example, a simple timer-based implementation, allowing an error message every T milliseconds (even with low values for T), is not reasonable. > > The rate-limiting parameters SHOULD be configurable. In the > > case of a token-bucket implementation, the best defaults depend > > on where the implementation is expected to be deployed (e.g., a > > high-end router vs. an embedded host). For example, in a > > small/mid -sized device, the possible defaults could be B=10, > > N=10/s. > > I may have missed this in earlier discussion, but the "SHOULD" > above used to be a "MUST" in the earlier text - is there any reason > we are now saying "SHOULD" instead of "MUST"? I thought that was appropriate due to the reasons listed in the mail where I proposed the text. I do not think it makes sense to require the values MUST be configurable on every kind of device -- take e.g. a mobile phone which implements an IPv6 stack. MUST seems too strong here. SHOULD seems more appropriate. Changing the values is typically very useful especially in the cases where the implementation may be used in small devices and bigger routers as well. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Jan 19 04:23:02 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08169 for ; Mon, 19 Jan 2004 04:23:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AiVc9-0005Uq-SK for ipv6-archive@odin.ietf.org; Mon, 19 Jan 2004 04:22:34 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0J9MXq4021125 for ipv6-archive@odin.ietf.org; Mon, 19 Jan 2004 04:22:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AiVc9-0005Ue-1V for ipv6-web-archive@optimus.ietf.org; Mon, 19 Jan 2004 04:22:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08158 for ; Mon, 19 Jan 2004 04:22:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AiVc6-000654-00 for ipv6-web-archive@ietf.org; Mon, 19 Jan 2004 04:22:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AiVb0-00060x-00 for ipv6-web-archive@ietf.org; Mon, 19 Jan 2004 04:21:23 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AiVaE-0005zY-00 for ipv6-web-archive@ietf.org; Mon, 19 Jan 2004 04:20:34 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1AiVaC-0002XG-5X for ipv6-web-archive@ietf.org; Mon, 19 Jan 2004 04:20:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AiVZj-0005Ai-QA; Mon, 19 Jan 2004 04:20:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AiVZE-00058P-7F for ipv6@optimus.ietf.org; Mon, 19 Jan 2004 04:19:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08079 for ; Mon, 19 Jan 2004 04:19:29 -0500 (EST) From: Mukesh.Gupta@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AiVZB-0005wv-00 for ipv6@ietf.org; Mon, 19 Jan 2004 04:19:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AiVYH-0005uF-00 for ipv6@ietf.org; Mon, 19 Jan 2004 04:18:33 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AiVY1-0005rO-00 for ipv6@ietf.org; Mon, 19 Jan 2004 04:18:17 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i0J9IHY01520 for ; Mon, 19 Jan 2004 11:18:17 +0200 (EET) Received: from daebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 19 Jan 2004 11:18:16 +0200 Received: from daebe009.NOE.Nokia.com ([10.241.35.109]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 19 Jan 2004 03:18:17 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: ICMPv6 Rate Limiting Methods: Revised Test (final ??) Date: Mon, 19 Jan 2004 03:18:16 -0600 Message-ID: <8D260779A766FB4A9C1739A476F84FA42ABE65@daebe009.americas.nokia.com> Thread-Topic: ICMPv6 Rate Limiting Methods: Revised Test (final ??) Thread-Index: AcPeXk9WgahOjB1iR2CAp/TJi4H2UgADQ0Ug To: , Cc: X-OriginalArrivalTime: 19 Jan 2004 09:18:17.0048 (UTC) FILETIME=[2C2D6580:01C3DE6D] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Fred, I mostly agree with Pekka here. Specific comments inline: > > I think we may have glossed over this in earlier discussion,=20 > > but I believe > > 'B' should be allowed as an expression of either messages OR bytes. > > Size *does* matter in certain cases, and expressing 'B'=20 > only in terms > > of a number of messages is too limiting. I think this can=20 > be fixed rather > > simply by changing the phrase: "B error messages" to > > "B error messages/bytes". I agree with Pekka that this compllicates the text and the=20 implementation. Moreover, N (the long-term average) can be in number of packets per seconds or a fraction of the attached link's bandwidth. Don't you think, the size of the packet will be covered if N is specified as the fraction of the bandwidth ? > > Rate-limiting mechanisms which cannot cope with bursty traffic > > (e.g., traceroute) are not recommended; thus a simple timer- > > based implementation, allowing an error message every T > > milliseconds (even with low values for T), is not reasonable. > > =20 > > I don't see the purpose in dis-recommending a particular scheme, > > (i.e., the simple timer), since there are infinitely many other > > possibilities that would be equally bad (or worse). Suggest > > shortening this paragraph to a single sentence such as: >=20 > IMHO, it makes sense to dis-recommend an approach, because it's > actually deployed out there, and thus it seems to be a good idea to > specifically say that it is NOT a good idea. I'm not aware of other,=20 > "really broken" mechanisms which would have been deployed. Moreover,=20 > this was suggested in the previous RFC, so recommending against it=20 > explicitly seems like a good idea. =20 Agree. We even considered removing it. So dis-recomending is softer than that. > The text could use a bit sharpening up, to say that timer-based=20 > discouragement is just and example, though, like: >=20 > Rate-limiting mechanisms which cannot cope with bursty traffic > (e.g., traceroute) are not recommended; for example, a simple > timer-based implementation, allowing an error message every T > milliseconds (even with low values for T), is not reasonable. Sounds better. > > The rate-limiting parameters SHOULD be configurable. In the > > case of a token-bucket implementation, the best defaults depend > > on where the implementation is expected to be deployed (e.g., a > > high-end router vs. an embedded host). For example, in a > > small/mid -sized device, the possible defaults could be B=3D10, > > N=3D10/s. > > =20 > > I may have missed this in earlier discussion, but the "SHOULD" > > above used to be a "MUST" in the earlier text - is there any reason > > we are now saying "SHOULD" instead of "MUST"? >=20 > I thought that was appropriate due to the reasons listed in the mail > where I proposed the text. I do not think it makes sense to require > the values MUST be configurable on every kind of device -- take e.g. a > mobile phone which implements an IPv6 stack. MUST seems too strong > here. SHOULD seems more appropriate. Changing the values is > typically very useful especially in the cases where the implementation > may be used in small devices and bigger routers as well. Agree. If it is possible for the implementation to clearly choose=20 appropriate default values based on the capacity of the links and=20 the devices where the implementation is going to be used, there is=20 no point in exposing this to the user. Regards Mukesh -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Jan 19 09:56:13 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18937 for ; Mon, 19 Jan 2004 09:56:13 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aiaoa-0008ST-QW for ipv6-archive@odin.ietf.org; Mon, 19 Jan 2004 09:55:45 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0JEtiRD032512 for ipv6-archive@odin.ietf.org; Mon, 19 Jan 2004 09:55:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aiaoa-0008SJ-Ku for ipv6-web-archive@optimus.ietf.org; Mon, 19 Jan 2004 09:55:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18926 for ; Mon, 19 Jan 2004 09:55:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AiaoY-0001Uh-00 for ipv6-web-archive@ietf.org; Mon, 19 Jan 2004 09:55:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AianZ-0001Qe-00 for ipv6-web-archive@ietf.org; Mon, 19 Jan 2004 09:54:42 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Aiamp-0001Nk-00 for ipv6-web-archive@ietf.org; Mon, 19 Jan 2004 09:53:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aialy-00081Q-Va; Mon, 19 Jan 2004 09:53:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aiali-00080l-4R for ipv6@optimus.ietf.org; Mon, 19 Jan 2004 09:52:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18818 for ; Mon, 19 Jan 2004 09:52:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aialb-0001JM-00 for ipv6@ietf.org; Mon, 19 Jan 2004 09:52:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aiaki-0001Gc-00 for ipv6@ietf.org; Mon, 19 Jan 2004 09:51:45 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AiakL-0001Cb-00 for ipv6@ietf.org; Mon, 19 Jan 2004 09:51:22 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i0JEodC18160; Mon, 19 Jan 2004 06:50:39 -0800 X-mProtect: <200401191450> Nokia Silicon Valley Messaging Protection Received: from ftemplin.iprg.nokia.com (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdxAdkZP; Mon, 19 Jan 2004 06:50:38 PST Message-ID: <400BEEBA.1040700@iprg.nokia.com> Date: Mon, 19 Jan 2004 06:50:34 -0800 From: Fred Templin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola CC: ipv6@ietf.org Subject: Re: ICMPv6 Rate Limiting Methods: Revised Test (final ??) References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Pekka Savola wrote: >On Sun, 18 Jan 2004, Fred Templin wrote: > > >>>=================================================== >>> (f) Finally, in order to limit the bandwidth and forwarding costs >>> incurred sending ICMPv6 error messages, an IPv6 node MUST limit >>> the rate of ICMPv6 error messages it sends. This situation may >>> occur when a source sending a stream of erroneous packets fails >>> to heed the resulting ICMPv6 error messages. >>> >>> One good way to implement the rate-limiting function is a token >>> >>> >> >>Something about the phrase: "One good way" seems a bit unusual >>to appear in standards documents; I prefer something like: >>"A suggested method". >> >> > >Fine by me, even though it's weaker. > OK; how about: "A recommended method for implementing...". Fred ftemplin@iprg.nokia.com -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Jan 19 11:50:20 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26843 for ; Mon, 19 Jan 2004 11:50:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aicb2-0004dE-N7 for ipv6-archive@odin.ietf.org; Mon, 19 Jan 2004 11:49:53 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0JGnqD7017798 for ipv6-archive@odin.ietf.org; Mon, 19 Jan 2004 11:49:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aicb2-0004cz-IS for ipv6-web-archive@optimus.ietf.org; Mon, 19 Jan 2004 11:49:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26777 for ; Mon, 19 Jan 2004 11:49:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aicb1-0003Pt-00 for ipv6-web-archive@ietf.org; Mon, 19 Jan 2004 11:49:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AicZK-000342-00 for ipv6-web-archive@ietf.org; Mon, 19 Jan 2004 11:48:08 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AicXA-0002bz-00 for ipv6-web-archive@ietf.org; Mon, 19 Jan 2004 11:45:53 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1AicX7-0001Tv-Kj for ipv6-web-archive@ietf.org; Mon, 19 Jan 2004 11:45:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AicWO-0003mp-Ui; Mon, 19 Jan 2004 11:45:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AicVl-0003hx-UL for ipv6@optimus.ietf.org; Mon, 19 Jan 2004 11:44:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25817 for ; Mon, 19 Jan 2004 11:44:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AicVk-0002Fm-00 for ipv6@ietf.org; Mon, 19 Jan 2004 11:44:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AicPZ-0001De-00 for ipv6@ietf.org; Mon, 19 Jan 2004 11:38:03 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AicGi-0000Em-00 for ipv6@ietf.org; Mon, 19 Jan 2004 11:28:53 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AicEG-0000Ok-Gv for ipv6@ietf.org; Mon, 19 Jan 2004 11:26:20 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i0JGPHD06651; Mon, 19 Jan 2004 08:25:17 -0800 X-mProtect: <200401191625> Nokia Silicon Valley Messaging Protection Received: from ftemplin.iprg.nokia.com (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdCHJ23l; Mon, 19 Jan 2004 08:25:16 PST Message-ID: <400C04E9.1000308@iprg.nokia.com> Date: Mon, 19 Jan 2004 08:25:13 -0800 From: Fred Templin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mukesh.Gupta@nokia.com CC: ipv6@ietf.org Subject: Re: ICMPv6 Rate Limiting Methods: Revised Test (final ??) References: <8D260779A766FB4A9C1739A476F84FA42ABE65@daebe009.americas.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Mukesh.Gupta@nokia.com wrote: > I agree with Pekka that this compllicates the text and the > implementation. Moreover, N (the long-term average) can be > in number of packets per seconds or a fraction of the attached > link's bandwidth. Don't you think, the size of the packet > will be covered if N is specified as the fraction of the > bandwidth ? I'll let the other stuff go for now, but the above is a very important point and in need of a bit more discussion. The token bucket text we are discussing essentially recommends that nodes implement a virtual queue for outgoing ICMPv6 error messages and perform active queue management on that queue based on the parameters N and B. RFC 2309 recommends active queue management for *routers*, but the text we are talking about correctly goes the extra measure of recommending active queue management at the source of the ICMPv6 error messages itself, i.e., the "0th hop router". RFC 2309, section 3(b) says: Note: the decision whether or not to drop an incoming packet can be made in "packet mode", ignoring packet sizes, or in "byte mode", taking into account the size of the incoming packet. The performance implications of the choice between packet mode or byte mode is discussed further in [Floyd97]. So IMO (and based on the RFC 2309 text) an active queue management recommendation that neglects "byte mode" and fails to cite RFC 2309 as informative text would be omitting important considerations that implementors should take into account. As such, I suggest the following: A recommended method for implementing the rate-limiting function is a token bucket, limiting the average rate of transmission to N, where N can either be packets/second or a fraction of the attached link's bandwidth, but allowing up to B error messages/bytes to be transmitted in a burst, as long as the long-term average is not exceeded. Other methods that provide effective active queue management [RFC2309] for outgoing ICMPv6 error messages are also acceptable. Fred L. Templin ftemplin@iprg.nokia.com -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Jan 19 13:00:14 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00033 for ; Mon, 19 Jan 2004 13:00:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aidgf-0000XQ-1m for ipv6-archive@odin.ietf.org; Mon, 19 Jan 2004 12:59:48 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0JHxjEi002067 for ipv6-archive@odin.ietf.org; Mon, 19 Jan 2004 12:59:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aidge-0000XG-Ri for ipv6-web-archive@optimus.ietf.org; Mon, 19 Jan 2004 12:59:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29999 for ; Mon, 19 Jan 2004 12:59:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aidgd-0000Lq-00 for ipv6-web-archive@ietf.org; Mon, 19 Jan 2004 12:59:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aidfm-0000JQ-00 for ipv6-web-archive@ietf.org; Mon, 19 Jan 2004 12:58:50 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AidfO-0000GZ-00 for ipv6-web-archive@ietf.org; Mon, 19 Jan 2004 12:58:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aidez-0000HK-RY; Mon, 19 Jan 2004 12:58:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aidef-0000Gh-GA for ipv6@optimus.ietf.org; Mon, 19 Jan 2004 12:57:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29877 for ; Mon, 19 Jan 2004 12:57:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aided-0000DN-00 for ipv6@ietf.org; Mon, 19 Jan 2004 12:57:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aiddg-00008p-00 for ipv6@ietf.org; Mon, 19 Jan 2004 12:56:41 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aidci-00003S-00 for ipv6@ietf.org; Mon, 19 Jan 2004 12:55:41 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i0JHt4S15946; Mon, 19 Jan 2004 19:55:04 +0200 Date: Mon, 19 Jan 2004 19:55:04 +0200 (EET) From: Pekka Savola To: Fred Templin cc: Mukesh.Gupta@nokia.com, Subject: Re: ICMPv6 Rate Limiting Methods: Revised Test (final ??) In-Reply-To: <400C04E9.1000308@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Mon, 19 Jan 2004, Fred Templin wrote: > Note: the decision whether or not to drop an incoming packet > can be made in "packet mode", ignoring packet sizes, or in > "byte mode", taking into account the size of the incoming > packet. The performance implications of the choice between > packet mode or byte mode is discussed further in [Floyd97]. > > So IMO (and based on the RFC 2309 text) an active queue > management recommendation that neglects "byte mode" and fails > to cite RFC 2309 as informative text would be omitting important > considerations that implementors should take into account. The background paper, Floyd97, states that the assumption is that bandwidth is the scarce resource. This may very well be the case for the regular case of active queue management for packets that pass through the router. However, I do not think this is the case here -- the scarce resource should be assumed to be the pps of error messages generated by the router, in which case the byte mode is inappropriate. The threat model here is assumed to be that an attacker forces the router to respond to packets with ICMP, overloading the CPU or other resources of the router. Again, the scarce resource could be the bandwidth in cases where the links are very low bandwidth, either close to the error-sending router or somewhere along the path -- but this is an issue which calls for strict AQM for all kinds of packets, and no special action should be needed for ICMPv6 error messages. > As such, I suggest the following: > > A recommended method for implementing the rate-limiting > function is a token bucket, limiting the average rate of > transmission to N, where N can either be packets/second or a > fraction of the attached link's bandwidth, but allowing up to > B error messages/bytes to be transmitted in a burst, as long > as the long-term average is not exceeded. Other methods that > provide effective active queue management [RFC2309] for > outgoing ICMPv6 error messages are also acceptable. I have to disagree here, on the grounds that it adds a bit complexity, and may confuse the reader because the reference to active queue management was written to talk about AQM of the forwarding path -- not error generation path -- and as may be misleading or inappropriate. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Jan 19 14:38:55 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04032 for ; Mon, 19 Jan 2004 14:38:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AifE7-0007Ge-P1 for ipv6-archive@odin.ietf.org; Mon, 19 Jan 2004 14:38:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0JJcN8L027932 for ipv6-archive@odin.ietf.org; Mon, 19 Jan 2004 14:38:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AifE7-0007GR-KQ for ipv6-web-archive@optimus.ietf.org; Mon, 19 Jan 2004 14:38:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04016 for ; Mon, 19 Jan 2004 14:38:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AifDz-0006vy-00 for ipv6-web-archive@ietf.org; Mon, 19 Jan 2004 14:38:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AifAr-0006gr-00 for ipv6-web-archive@ietf.org; Mon, 19 Jan 2004 14:35:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Aif7j-0006Qp-00 for ipv6-web-archive@ietf.org; Mon, 19 Jan 2004 14:31:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aif71-0006O7-0W; Mon, 19 Jan 2004 14:31:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aif65-0006MT-T1 for ipv6@optimus.ietf.org; Mon, 19 Jan 2004 14:30:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03659 for ; Mon, 19 Jan 2004 14:30:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aif5y-0006LM-00 for ipv6@ietf.org; Mon, 19 Jan 2004 14:29:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aif20-000617-00 for ipv6@ietf.org; Mon, 19 Jan 2004 14:25:53 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1Aiewt-0005WS-00 for ipv6@ietf.org; Mon, 19 Jan 2004 14:20:36 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i0JJJVL21701; Mon, 19 Jan 2004 11:19:31 -0800 X-mProtect: <200401191919> Nokia Silicon Valley Messaging Protection Received: from ftemplin.iprg.nokia.com (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdlYhKzs; Mon, 19 Jan 2004 11:19:29 PST Message-ID: <400C2DBE.4020809@iprg.nokia.com> Date: Mon, 19 Jan 2004 11:19:26 -0800 From: Fred Templin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola CC: ipv6@ietf.org Subject: Re: ICMPv6 Rate Limiting Methods: Revised Test (final ??) References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Pekka Savola wrote: >On Mon, 19 Jan 2004, Fred Templin wrote: > > >> Note: the decision whether or not to drop an incoming packet >> can be made in "packet mode", ignoring packet sizes, or in >> "byte mode", taking into account the size of the incoming >> packet. The performance implications of the choice between >> packet mode or byte mode is discussed further in [Floyd97]. >> >>So IMO (and based on the RFC 2309 text) an active queue >>management recommendation that neglects "byte mode" and fails >>to cite RFC 2309 as informative text would be omitting important >>considerations that implementors should take into account. >> >> > >The background paper, Floyd97, states that the assumption is that >bandwidth is the scarce resource. This may very well be the case for >the regular case of active queue management for packets that pass >through the router. However, I do not think this is the case here -- >the scarce resource should be assumed to be the pps of error messages >generated by the router, in which case the byte mode is inappropriate. > Pekka, Let's be clear first on what node you are referring to by "the router". Let's assume node A sends packets to node B that causes B to send ICMPv6 error messages to node C (where, A and C may/may not be the same nodes and/or the network path A->B may/may not have similar congestion/bandwidth/delay characteristics to the path B->C). The "router" in this case is node B - correct? Assuming we are on the same page, there are two worst-case threat models to consider: Threat model 1: ************* Node B (i.e., "the router") is congested in terms of CPU load, memory utilization, etc, while the network path from B->C is uncongested and uses only fast links. Threat model 2: ************* The router is uncongested, but the network path from B->C is congested and/or has low-bandwidth links. >The threat model here is assumed to be that an attacker forces the >router to respond to packets with ICMP, overloading the CPU or other >resources of the router. > This is threat model 1. This threat model applies to the "leading edge" of the router's algorithm for generating ICMPv6 errors, i.e., if the router knows a priori that local resources are too congested, it will selectively refrain from generating the error messages in the first place (i.e., using the rate limiting parameters B and B). But, if the constraining resources are available buffer space, it could well be that bytes (rather than number of packets) would be the more appropriate metric. >Again, the scarce resource could be the bandwidth in cases where the >links are very low bandwidth, either close to the error-sending router >or somewhere along the path -- but this is an issue which calls for >strict AQM for all kinds of packets, and no special action should be >needed for ICMPv6 error messages. > This is threat model 2. This threat model would apply to the "trailing edge" of the router's algorithm for generating ICMPv6 errors, i.e., if the router's local resources are uncongested it will generate the errors, forward them to the network for transmission, but will then have no way of knowing whether a congested/bandwidth-constrained link occurs on the path B->C (unless the congested link occurs on the 1st hop) and should therefore use AQM on ICMPv6 errors sent on the outgoing attached link. I agree that this issue calls for AQM for all kinds of packets, and indeed this is well supported by the BCP documents. But, I disagree that no special action should be needed for ICMPv6 error messages. For example, suppose node X at the head of a slow link X->Y on the path from B->C is using AQM and operating near the queue's high water mark. If the traffic passing through X->Y is mostly due to well behaved sessions, a high arrival rate of ICMPv6 error messages from B at X will result in an equal likelihood of dropping the legitimate traffic as dropping the ICMPv6 messages. Also, we have only the BCP recommendations that network nodes implement AQM; we have no guarantees that network nodes along all forwarding paths will comply. Finally, I have looked at the RED queue management documents at: http://www.icir.org/floyd/red.htm and so far I have not seen any conclusive evidence that shows either packet mode vs. byte mode as the clearly superior model. As such, I see it as beyond the scope of the document in question to promote one of the models over the other. Thanks - Fred ftemplin@iprg.nokia.com >>As such, I suggest the following: >> >> A recommended method for implementing the rate-limiting >> function is a token bucket, limiting the average rate of >> transmission to N, where N can either be packets/second or a >> fraction of the attached link's bandwidth, but allowing up to >> B error messages/bytes to be transmitted in a burst, as long >> as the long-term average is not exceeded. Other methods that >> provide effective active queue management [RFC2309] for >> outgoing ICMPv6 error messages are also acceptable. >> >> > >I have to disagree here, on the grounds that it adds a bit complexity, >and may confuse the reader because the reference to active queue >management was written to talk about AQM of the forwarding path -- not >error generation path -- and as may be misleading or inappropriate. > > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Jan 20 15:49:06 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21377 for ; Tue, 20 Jan 2004 15:49:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aj2ne-0000Ya-Ec for ipv6-archive@odin.ietf.org; Tue, 20 Jan 2004 15:48:38 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0KKmcoF002134 for ipv6-archive@odin.ietf.org; Tue, 20 Jan 2004 15:48:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aj2ne-0000YL-AV for ipv6-web-archive@optimus.ietf.org; Tue, 20 Jan 2004 15:48:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21340 for ; Tue, 20 Jan 2004 15:48:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aj2nc-0000sD-00 for ipv6-web-archive@ietf.org; Tue, 20 Jan 2004 15:48:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aj2mf-0000mL-00 for ipv6-web-archive@ietf.org; Tue, 20 Jan 2004 15:47:38 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Aj2lk-0000g0-00 for ipv6-web-archive@ietf.org; Tue, 20 Jan 2004 15:46:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aj2kB-0008Cg-C5; Tue, 20 Jan 2004 15:45:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aj2jY-00084K-Vz for ipv6@optimus.ietf.org; Tue, 20 Jan 2004 15:44:25 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20646; Tue, 20 Jan 2004 15:44:22 -0500 (EST) Message-Id: <200401202044.PAA20646@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipv6@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipv6-inet-tunnel-mib-00.txt Date: Tue, 20 Jan 2004 15:44:22 -0500 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Version 6 Working Group Working Group of the IETF. Title : IP Tunnel MIB Author(s) : D. Thaler Filename : draft-ietf-ipv6-inet-tunnel-mib-00.txt Pages : 26 Date : 2004-1-20 This memo defines a Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing tunnels of any type over IPv4 and IPv6 networks. Extension MIBs may be designed for managing protocol-specific objects. Likewise, extension MIBs may be designed for managing security-specific objects. This MIB does not support tunnels over non-IP networks. Management of such tunnels may be supported by other MIBs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-inet-tunnel-mib-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipv6-inet-tunnel-mib-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipv6-inet-tunnel-mib-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-1-20142740.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-inet-tunnel-mib-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-inet-tunnel-mib-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-1-20142741.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Jan 21 16:29:57 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09808 for ; Wed, 21 Jan 2004 16:29:57 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjPuj-0005wN-LV for ipv6-archive@odin.ietf.org; Wed, 21 Jan 2004 16:29:29 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0LLTTjF022829 for ipv6-archive@odin.ietf.org; Wed, 21 Jan 2004 16:29:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjPuj-0005w8-II for ipv6-web-archive@optimus.ietf.org; Wed, 21 Jan 2004 16:29:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09770 for ; Wed, 21 Jan 2004 16:29:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjPuh-0002Ug-00 for ipv6-web-archive@ietf.org; Wed, 21 Jan 2004 16:29:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjPtm-0002Rs-00 for ipv6-web-archive@ietf.org; Wed, 21 Jan 2004 16:28:30 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AjPtT-0002Ox-00 for ipv6-web-archive@ietf.org; Wed, 21 Jan 2004 16:28:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjPsO-0005Kz-3g; Wed, 21 Jan 2004 16:27:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjPry-0005JB-P1 for ipv6@optimus.ietf.org; Wed, 21 Jan 2004 16:26:38 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09486; Wed, 21 Jan 2004 16:26:35 -0500 (EST) Message-Id: <200401212126.QAA09486@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipv6@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipv6-unique-local-addr-02.txt Date: Wed, 21 Jan 2004 16:26:35 -0500 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Version 6 Working Group Working Group of the IETF. Title : Unique Local IPv6 Unicast Addresses Author(s) : R. Hinden, B. Haberman Filename : draft-ietf-ipv6-unique-local-addr-02.txt Pages : 16 Date : 2004-1-21 This document defines an unicast address format that is globally unique and is intended for local communications, usually inside of a site. They are not expected to be routable on the global Internet given current routing technology. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-unique-local-addr-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipv6-unique-local-addr-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipv6-unique-local-addr-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-1-21164233.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-unique-local-addr-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-unique-local-addr-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-1-21164233.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Jan 22 03:17:09 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13017 for ; Thu, 22 Jan 2004 03:17:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aja12-0000I0-1P for ipv6-archive@odin.ietf.org; Thu, 22 Jan 2004 03:16:40 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0M8Gext001112 for ipv6-archive@odin.ietf.org; Thu, 22 Jan 2004 03:16:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aja11-0000Hr-LA for ipv6-web-archive@optimus.ietf.org; Thu, 22 Jan 2004 03:16:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13014 for ; Thu, 22 Jan 2004 03:16:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aja0z-0005sO-00 for ipv6-web-archive@ietf.org; Thu, 22 Jan 2004 03:16:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aja04-0005r5-00 for ipv6-web-archive@ietf.org; Thu, 22 Jan 2004 03:15:41 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AjZzp-0005pm-00 for ipv6-web-archive@ietf.org; Thu, 22 Jan 2004 03:15:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjZzU-0008Sh-JF; Thu, 22 Jan 2004 03:15:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjZzC-0008Rt-Re for ipv6@optimus.ietf.org; Thu, 22 Jan 2004 03:14:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12948 for ; Thu, 22 Jan 2004 03:14:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjZzA-0005p7-00 for ipv6@ietf.org; Thu, 22 Jan 2004 03:14:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjZy5-0005ng-00 for ipv6@ietf.org; Thu, 22 Jan 2004 03:13:39 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjZxB-0005lK-00 for ipv6@ietf.org; Thu, 22 Jan 2004 03:12:41 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i0M8C8j31775; Thu, 22 Jan 2004 10:12:08 +0200 Date: Thu, 22 Jan 2004 10:12:08 +0200 (EET) From: Pekka Savola To: Fred Templin cc: ipv6@ietf.org Subject: Re: ICMPv6 Rate Limiting Methods: Revised Test (final ??) In-Reply-To: <400C2DBE.4020809@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Mon, 19 Jan 2004, Fred Templin wrote: [...] > Assuming we are on the same page, Yep. > there are two worst-case threat > models to consider: > > Threat model 1: > ************* > Node B (i.e., "the router") is congested in terms of CPU load, memory > utilization, etc, while the network path from B->C is uncongested and > uses only fast links. > > Threat model 2: > ************* > The router is uncongested, but the network path from B->C is congested > and/or has low-bandwidth links. I disagree that we should be concerned about threat model 2 in this specification. The rate-limiting of ICMP error generation is seems totally irrelevant when you consider the big pictuare of model 2: you can perform the same overloading with ICMP echo reply/request messages, any traffic you want (e.g. UDP streams), etc. -- the point is that if your network is congested (or low-bandwidth), you have to deal with it in your network anyway -- no amount of changes to ICMP rate-limiting is going to change that in any significant way. > This is threat model 2. This threat model would apply to the "trailing > edge" of the router's algorithm for generating ICMPv6 errors, i.e., > if the router's local resources are uncongested it will generate the > errors, forward them to the network for transmission, but will then > have no way of knowing whether a congested/bandwidth-constrained > link occurs on the path B->C (unless the congested link occurs on the > 1st hop) Yes, the router has no way of knowing about the congestion or bandwidth constrains anywhere along the path.. > and should therefore use AQM on ICMPv6 errors sent on > the outgoing attached link. But I disagree with this conclusion, as discussed above. > I agree that this issue calls for AQM for all kinds of packets, and > indeed this is well supported by the BCP documents. But, I disagree > that no special action should be needed for ICMPv6 error messages. > For example, suppose node X at the head of a slow link X->Y on the > path from B->C is using AQM and operating near the queue's high > water mark. If the traffic passing through X->Y is mostly due to well > behaved sessions, a high arrival rate of ICMPv6 error messages from > B at X will result in an equal likelihood of dropping the legitimate > traffic as dropping the ICMPv6 messages. Also, we have only the BCP > recommendations that network nodes implement AQM; we have no > guarantees that network nodes along all forwarding paths will comply. I have to disagree with this reasoning. ICMPv6 is not special. If we had a community consensus that we must immediately adapt all the protocols out there to cater for the case where there may be congestion or low bandwidth links on the path, I'd probably agree that the behaviour needs to be changed. But there is no such consensus, and inserting changes to ICMPv6 to accommodate this model is irrelevant and unnecessary in the big picture of bandwidth constraints and low bandwidth links. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Jan 22 21:22:39 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25051 for ; Thu, 22 Jan 2004 21:22:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjqxY-0006Mw-5U for ipv6-archive@odin.ietf.org; Thu, 22 Jan 2004 21:22:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0N2MCwI024476 for ipv6-archive@odin.ietf.org; Thu, 22 Jan 2004 21:22:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjqxY-0006Mh-1t for ipv6-web-archive@optimus.ietf.org; Thu, 22 Jan 2004 21:22:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25035 for ; Thu, 22 Jan 2004 21:22:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjqxQ-00055L-00 for ipv6-web-archive@ietf.org; Thu, 22 Jan 2004 21:22:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ajqus-0004yt-00 for ipv6-web-archive@ietf.org; Thu, 22 Jan 2004 21:19:27 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AjqsX-0004sQ-00 for ipv6-web-archive@ietf.org; Thu, 22 Jan 2004 21:17:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajqrb-0005my-R0; Thu, 22 Jan 2004 21:16:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajqqq-0005kJ-Pb for ipv6@optimus.ietf.org; Thu, 22 Jan 2004 21:15:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24809 for ; Thu, 22 Jan 2004 21:15:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ajqqj-0004qM-00 for ipv6@ietf.org; Thu, 22 Jan 2004 21:15:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ajqor-0004mr-00 for ipv6@ietf.org; Thu, 22 Jan 2004 21:13:16 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AjqmR-0004jE-00 for ipv6@ietf.org; Thu, 22 Jan 2004 21:10:43 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i0N29wD04524; Thu, 22 Jan 2004 18:09:58 -0800 X-mProtect: <200401230209> Nokia Silicon Valley Messaging Protection Received: from pc-b198.wlan.inet.fi (194.89.117.198, claiming to be "spruce.nokia.com") by darkstar.iprg.nokia.com smtpd1s1MQc; Thu, 22 Jan 2004 12:16:11 PST Message-Id: <4.3.2.7.2.20040122121229.039a8888@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 22 Jan 2004 12:12:59 -0800 To: ipv6@ietf.org From: Bob Hinden Subject: Re: I-D ACTION:draft-ietf-ipv6-unique-local-addr-02.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 A diff with the previous draft can be found at: http://people.nokia.net/~hinden/draft-ietf-ipv6-unique-local-addr-02.html The changes include: o Removed mention of 10 euro charge and changed text in section 3.2.1 and IANA considerations to restate the requirement for low cost allocations and added specific requirement to prevent hoarding. o Added need to send ICMPv6 destination unreachable messages if packets are filtered or dropped at site boundaries. o Changed format section to list prefix sizes and definition, and changed discussion of prefix sizes to new background section. o Added Table of Contents. o Various editorial changes. Bob At 01:26 PM 1/21/2004, Internet-Drafts@ietf.org wrote: >A New Internet-Draft is available from the on-line Internet-Drafts >directories. >This draft is a work item of the IP Version 6 Working Group Working Group >of the IETF. > > Title : Unique Local IPv6 Unicast Addresses > Author(s) : R. Hinden, B. Haberman > Filename : draft-ietf-ipv6-unique-local-addr-02.txt > Pages : 16 > Date : 2004-1-21 > >This document defines an unicast address format that is globally >unique and is intended for local communications, usually inside of a >site. They are not expected to be routable on the global Internet >given current routing technology. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-ipv6-unique-local-addr-02.txt > >To remove yourself from the IETF Announcement list, send a message to >ietf-announce-request with the word unsubscribe in the body of the message. > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-ietf-ipv6-unique-local-addr-02.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-ietf-ipv6-unique-local-addr-02.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. >Content-Type: text/plain >Content-ID: <2004-1-21164233.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-ietf-ipv6-unique-local-addr-02.txt > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Jan 23 13:42:17 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15636 for ; Fri, 23 Jan 2004 13:42:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak6FZ-0001Mj-5Q for ipv6-archive@odin.ietf.org; Fri, 23 Jan 2004 13:41:49 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0NIfnOt005243 for ipv6-archive@odin.ietf.org; Fri, 23 Jan 2004 13:41:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak6FZ-0001MU-0G for ipv6-web-archive@optimus.ietf.org; Fri, 23 Jan 2004 13:41:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15627 for ; Fri, 23 Jan 2004 13:41:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak6FW-0006D2-00 for ipv6-web-archive@ietf.org; Fri, 23 Jan 2004 13:41:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak6Ec-0006Bn-00 for ipv6-web-archive@ietf.org; Fri, 23 Jan 2004 13:40:51 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ak6E7-0006Ad-00 for ipv6-web-archive@ietf.org; Fri, 23 Jan 2004 13:40:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak6Cs-00017e-6b; Fri, 23 Jan 2004 13:39:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak6Cd-00016u-RH for ipv6@optimus.ietf.org; Fri, 23 Jan 2004 13:38:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15518 for ; Fri, 23 Jan 2004 13:38:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak6Cb-00067m-00 for ipv6@ietf.org; Fri, 23 Jan 2004 13:38:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak6Bi-00065T-00 for ipv6@ietf.org; Fri, 23 Jan 2004 13:37:51 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1Ak6Al-00061k-00 for ipv6@ietf.org; Fri, 23 Jan 2004 13:36:52 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i0NIaCZ18795; Fri, 23 Jan 2004 10:36:12 -0800 X-mProtect: <200401231836> Nokia Silicon Valley Messaging Protection Received: from ftemplin.iprg.nokia.com (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdgz7lT7; Fri, 23 Jan 2004 10:36:10 PST Message-ID: <401169AA.9010304@iprg.nokia.com> Date: Fri, 23 Jan 2004 10:36:26 -0800 From: Fred Templin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola CC: ipv6@ietf.org Subject: Re: ICMPv6 Rate Limiting Methods: Revised Test (final ??) References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Pekka, Sorry for the delayed response, but I've been off pondering this one. It seems to me that the question is more of a philisophical/operational nature and not readily tackled from a theoretical perspective. The point comes down to whom do you trust? Do you trust hosts to be well behaved, or do you trust networks to provision mechanisms to protect others against poorly-behaved hosts? An analogy would be vehicles and highways. There are laws about how drivers should operate their vehicles, but drivers break them all the time. Highway authorities can set a maximum speed limit of 65mph, but drivers routinely cruise at 80mph without remorse. The Dept. of Motor Vehicles can state that vehicles must meet certain performance criterion, but drivers frequently modify their vehicles to make them perform more like race cars. On the other hand, if the highway authority took away stop lights from dangerous intersections, let potholes develop in roads, etc. etc., drivers would be outraged and immediately begin using other roads. Anyway, this line of discussion is really outside of my area of expertise. It would be best to hear other opinions on this, but I'm also respectful of the more practical/operational aspects that you bring to the discussion. Any suggestions on how to proceed from here would be welcome. Fred ftemplin@iprg.nokia.com Pekka Savola wrote: >On Mon, 19 Jan 2004, Fred Templin wrote: >[...] > > >>Assuming we are on the same page, >> >> > >Yep. > > > >>there are two worst-case threat >>models to consider: >> >> > > > >> Threat model 1: >> ************* >> Node B (i.e., "the router") is congested in terms of CPU load, memory >> utilization, etc, while the network path from B->C is uncongested and >> uses only fast links. >> >> Threat model 2: >> ************* >> The router is uncongested, but the network path from B->C is congested >> and/or has low-bandwidth links. >> >> > >I disagree that we should be concerned about threat model 2 in this >specification. The rate-limiting of ICMP error generation is seems >totally irrelevant when you consider the big pictuare of model 2: >you can perform the same overloading with ICMP echo reply/request >messages, any traffic you want (e.g. UDP streams), etc. -- the point >is that if your network is congested (or low-bandwidth), you have to >deal with it in your network anyway -- no amount of changes to ICMP >rate-limiting is going to change that in any significant way. > > > >>This is threat model 2. This threat model would apply to the "trailing >>edge" of the router's algorithm for generating ICMPv6 errors, i.e., >>if the router's local resources are uncongested it will generate the >>errors, forward them to the network for transmission, but will then >>have no way of knowing whether a congested/bandwidth-constrained >>link occurs on the path B->C (unless the congested link occurs on the >>1st hop) >> >> > >Yes, the router has no way of knowing about the congestion or >bandwidth constrains anywhere along the path.. > > > >>and should therefore use AQM on ICMPv6 errors sent on >>the outgoing attached link. >> >> > >But I disagree with this conclusion, as discussed above. > > > >>I agree that this issue calls for AQM for all kinds of packets, and >>indeed this is well supported by the BCP documents. But, I disagree >>that no special action should be needed for ICMPv6 error messages. >>For example, suppose node X at the head of a slow link X->Y on the >>path from B->C is using AQM and operating near the queue's high >>water mark. If the traffic passing through X->Y is mostly due to well >>behaved sessions, a high arrival rate of ICMPv6 error messages from >>B at X will result in an equal likelihood of dropping the legitimate >>traffic as dropping the ICMPv6 messages. Also, we have only the BCP >>recommendations that network nodes implement AQM; we have no >>guarantees that network nodes along all forwarding paths will comply. >> >> > >I have to disagree with this reasoning. ICMPv6 is not special. If we >had a community consensus that we must immediately adapt all the >protocols out there to cater for the case where there may be >congestion or low bandwidth links on the path, I'd probably agree >that the behaviour needs to be changed. But there is no such >consensus, and inserting changes to ICMPv6 to accommodate this model >is irrelevant and unnecessary in the big picture of bandwidth >constraints and low bandwidth links. > > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sun Jan 25 00:05:22 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06277 for ; Sun, 25 Jan 2004 00:05:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AkcS7-0003F4-4K for ipv6-archive@odin.ietf.org; Sun, 25 Jan 2004 00:04:55 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0P54tL0012456 for ipv6-archive@odin.ietf.org; Sun, 25 Jan 2004 00:04:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AkcS6-0003Ep-SB for ipv6-web-archive@optimus.ietf.org; Sun, 25 Jan 2004 00:04:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06259 for ; Sun, 25 Jan 2004 00:04:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AkcS4-0007n9-00 for ipv6-web-archive@ietf.org; Sun, 25 Jan 2004 00:04:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AkcR7-0007lX-00 for ipv6-web-archive@ietf.org; Sun, 25 Jan 2004 00:03:53 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AkcQE-0007k5-00 for ipv6-web-archive@ietf.org; Sun, 25 Jan 2004 00:02:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AkcPJ-00030e-Vh; Sun, 25 Jan 2004 00:02:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AkcPC-0002xq-9x for ipv6@optimus.ietf.org; Sun, 25 Jan 2004 00:01:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06219 for ; Sun, 25 Jan 2004 00:01:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AkcPA-0007il-00 for ipv6@ietf.org; Sun, 25 Jan 2004 00:01:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AkcOE-0007eh-00 for ipv6@ietf.org; Sun, 25 Jan 2004 00:00:54 -0500 Received: from cyteen.hactrn.net ([66.92.66.68]) by ietf-mx with esmtp (Exim 4.12) id 1AkcO4-0007dK-00 for ipv6@ietf.org; Sun, 25 Jan 2004 00:00:44 -0500 Received: from hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id 96562640 for ; Sun, 25 Jan 2004 00:00:12 -0500 (EST) To: ipv6@ietf.org Subject: Weekly posting summary for ipv6@ietf.org From: Rob Austein Date: Sun, 25 Jan 2004 00:00:12 -0500 Message-Id: <20040125050012.96562640@cyteen.hactrn.net> Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL,MAILTO_TO_SPAM_ADDR autolearn=no version=2.60 Messages | Bytes | Who --------+------+--------+----------+------------------------ 28.57% | 4 | 29.23% | 25763 | ftemplin@iprg.nokia.com 21.43% | 3 | 20.89% | 18408 | pekkas@netcore.fi 14.29% | 2 | 14.07% | 12398 | mukesh.gupta@nokia.com 14.29% | 2 | 12.08% | 10643 | internet-drafts@ietf.org 7.14% | 1 | 12.30% | 10840 | osprey67@yahoo.com 7.14% | 1 | 7.19% | 6335 | bob.hinden@nokia.com 7.14% | 1 | 4.25% | 3750 | sra+ipng@hactrn.net --------+------+--------+----------+------------------------ 100.00% | 14 |100.00% | 88137 | Total Grunchweather Associates provides this automatic summary on an at-whim basis at the request of the IPv6 WG chairs. Your mileage may vary. We decline responsibilities, all shapes, all sizes, all colors. If this script produces broken output, you get to keep both pieces. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Jan 27 19:36:13 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05259 for ; Tue, 27 Jan 2004 19:36:13 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AldgH-0006mF-Tx for ipv6-archive@odin.ietf.org; Tue, 27 Jan 2004 19:35:46 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0S0ZjQ5026045 for ipv6-archive@odin.ietf.org; Tue, 27 Jan 2004 19:35:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AldgH-0006m0-Q1 for ipv6-web-archive@optimus.ietf.org; Tue, 27 Jan 2004 19:35:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05198 for ; Tue, 27 Jan 2004 19:35:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AldgG-0001wM-00 for ipv6-web-archive@ietf.org; Tue, 27 Jan 2004 19:35:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Alddl-0001Lz-00 for ipv6-web-archive@ietf.org; Tue, 27 Jan 2004 19:33:10 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Aldch-00015C-00 for ipv6-web-archive@ietf.org; Tue, 27 Jan 2004 19:32:03 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1AldRQ-00065H-Gu for ipv6-web-archive@ietf.org; Tue, 27 Jan 2004 19:20:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AldHu-0001j8-O5; Tue, 27 Jan 2004 19:10:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlDtx-0008WH-Vf for ipv6@optimus.ietf.org; Mon, 26 Jan 2004 16:04:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20237 for ; Mon, 26 Jan 2004 16:04:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlDtw-00040r-00 for ipv6@ietf.org; Mon, 26 Jan 2004 16:04:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlDsy-0003y8-00 for ipv6@ietf.org; Mon, 26 Jan 2004 16:03:09 -0500 Received: from uillean.fuaim.com ([206.197.161.140]) by ietf-mx with esmtp (Exim 4.12) id 1AlDs2-0003th-00 for ipv6@ietf.org; Mon, 26 Jan 2004 16:02:11 -0500 Received: from clairseach.fuaim.com (clairseach.fuaim.com [206.197.161.141]) by uillean.fuaim.com (8.11.6/8.11.6) with ESMTP id i0QL1bV26428 for ; Mon, 26 Jan 2004 13:01:37 -0800 Received: from innovationslab.net (md-wmnsmd-cuda2-c6a-a-4.chvlva.adelphia.net [68.65.120.4]) (authenticated bits=0) by clairseach.fuaim.com (8.12.8/8.12.8) with ESMTP id i0QLB3lN027937 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 26 Jan 2004 13:11:13 -0800 Message-ID: <40158002.6060801@innovationslab.net> Date: Mon, 26 Jan 2004 16:00:50 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: ICMPv6 Rate Limiting Methods: Revised Test (final ??) References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I agree with Pekka's assessment on the issues with changing the text on rate-limiting. Adding complicated scenarios is not in the best interest of this document. So, unless someone can show evidence of a reason to do so, let's keep the text straightforward and as simple as possible. Regards, Brian Pekka Savola wrote: > On Mon, 19 Jan 2004, Fred Templin wrote: > [...] > >>Assuming we are on the same page, > > > Yep. > > >>there are two worst-case threat >>models to consider: > > >> Threat model 1: >> ************* >> Node B (i.e., "the router") is congested in terms of CPU load, memory >> utilization, etc, while the network path from B->C is uncongested and >> uses only fast links. >> >> Threat model 2: >> ************* >> The router is uncongested, but the network path from B->C is congested >> and/or has low-bandwidth links. > > > I disagree that we should be concerned about threat model 2 in this > specification. The rate-limiting of ICMP error generation is seems > totally irrelevant when you consider the big pictuare of model 2: > you can perform the same overloading with ICMP echo reply/request > messages, any traffic you want (e.g. UDP streams), etc. -- the point > is that if your network is congested (or low-bandwidth), you have to > deal with it in your network anyway -- no amount of changes to ICMP > rate-limiting is going to change that in any significant way. > > >>This is threat model 2. This threat model would apply to the "trailing >>edge" of the router's algorithm for generating ICMPv6 errors, i.e., >>if the router's local resources are uncongested it will generate the >>errors, forward them to the network for transmission, but will then >>have no way of knowing whether a congested/bandwidth-constrained >>link occurs on the path B->C (unless the congested link occurs on the >>1st hop) > > > Yes, the router has no way of knowing about the congestion or > bandwidth constrains anywhere along the path.. > > >>and should therefore use AQM on ICMPv6 errors sent on >>the outgoing attached link. > > > But I disagree with this conclusion, as discussed above. > > >>I agree that this issue calls for AQM for all kinds of packets, and >>indeed this is well supported by the BCP documents. But, I disagree >>that no special action should be needed for ICMPv6 error messages. >>For example, suppose node X at the head of a slow link X->Y on the >>path from B->C is using AQM and operating near the queue's high >>water mark. If the traffic passing through X->Y is mostly due to well >>behaved sessions, a high arrival rate of ICMPv6 error messages from >>B at X will result in an equal likelihood of dropping the legitimate >>traffic as dropping the ICMPv6 messages. Also, we have only the BCP >>recommendations that network nodes implement AQM; we have no >>guarantees that network nodes along all forwarding paths will comply. > > > I have to disagree with this reasoning. ICMPv6 is not special. If we > had a community consensus that we must immediately adapt all the > protocols out there to cater for the case where there may be > congestion or low bandwidth links on the path, I'd probably agree > that the behaviour needs to be changed. But there is no such > consensus, and inserting changes to ICMPv6 to accommodate this model > is irrelevant and unnecessary in the big picture of bandwidth > constraints and low bandwidth links. > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Jan 27 19:39:18 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05906 for ; Tue, 27 Jan 2004 19:39:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AldjH-0007Ky-2v for ipv6-archive@odin.ietf.org; Tue, 27 Jan 2004 19:38:51 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0S0coRm028170 for ipv6-archive@odin.ietf.org; Tue, 27 Jan 2004 19:38:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AldjG-0007K7-6F for ipv6-web-archive@optimus.ietf.org; Tue, 27 Jan 2004 19:38:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05722 for ; Tue, 27 Jan 2004 19:38:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AldjE-0002gG-00 for ipv6-web-archive@ietf.org; Tue, 27 Jan 2004 19:38:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aldg9-0001vH-00 for ipv6-web-archive@ietf.org; Tue, 27 Jan 2004 19:35:38 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Alddi-0001LG-00 for ipv6-web-archive@ietf.org; Tue, 27 Jan 2004 19:33:06 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1AldRQ-00062U-Jp for ipv6-web-archive@ietf.org; Tue, 27 Jan 2004 19:20:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AldIP-0001zN-2Y; Tue, 27 Jan 2004 19:11:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlEGF-0001GA-80 for ipv6@optimus.ietf.org; Mon, 26 Jan 2004 16:27:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20766 for ; Mon, 26 Jan 2004 16:27:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlEG8-00051a-00 for ipv6@ietf.org; Mon, 26 Jan 2004 16:27:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlEEa-0004zI-00 for ipv6@ietf.org; Mon, 26 Jan 2004 16:25:28 -0500 Received: from uillean.fuaim.com ([206.197.161.140]) by ietf-mx with esmtp (Exim 4.12) id 1AlEDc-0004ux-00 for ipv6@ietf.org; Mon, 26 Jan 2004 16:24:29 -0500 Received: from clairseach.fuaim.com (clairseach.fuaim.com [206.197.161.141]) by uillean.fuaim.com (8.11.6/8.11.6) with ESMTP id i0QLNlV26639 for ; Mon, 26 Jan 2004 13:23:47 -0800 Received: from innovationslab.net (md-wmnsmd-cuda2-c6a-a-4.chvlva.adelphia.net [68.65.120.4]) (authenticated bits=0) by clairseach.fuaim.com (8.12.8/8.12.8) with ESMTP id i0QLX2lN028055 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 26 Jan 2004 13:33:22 -0800 Message-ID: <40158529.2090805@innovationslab.net> Date: Mon, 26 Jan 2004 16:22:49 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipv6@ietf.org Subject: IPv6 WG Last Call:draft-ietf-ipv6-unique-local-addr-02.txt Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit All, This is the start of an IPv6 working group last call on: > Title : Unique Local IPv6 Unicast Addresses > Author(s) : R. Hinden, B. Haberman > Filename : draft-ietf-ipv6-unique-local-addr-02.txt > Pages : 16 > Date : 2004-1-21 This Last Call will end on Feb 2, 2004. This document is being submitted as a Proposed Standard. This last call is to verify consensus on the text changes made in response to the previous last call. Substantive comments should be directed to the mailing list and editorial comments to the authors. Regards, Brian & Bob IPv6 WG co-chairs -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Jan 27 19:45:37 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06552 for ; Tue, 27 Jan 2004 19:45:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AldpO-0007re-Km for ipv6-archive@odin.ietf.org; Tue, 27 Jan 2004 19:45:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0S0jAv5030224 for ipv6-archive@odin.ietf.org; Tue, 27 Jan 2004 19:45:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AldpO-0007rP-Fl for ipv6-web-archive@optimus.ietf.org; Tue, 27 Jan 2004 19:45:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06509 for ; Tue, 27 Jan 2004 19:45:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AldpM-0003Pt-00 for ipv6-web-archive@ietf.org; Tue, 27 Jan 2004 19:45:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AldoS-0003MQ-00 for ipv6-web-archive@ietf.org; Tue, 27 Jan 2004 19:44:13 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Aldnl-0003If-00 for ipv6-web-archive@ietf.org; Tue, 27 Jan 2004 19:43:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AldII-0001we-3I; Tue, 27 Jan 2004 19:10:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlE2g-0000Zj-SC for ipv6@optimus.ietf.org; Mon, 26 Jan 2004 16:13:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20585 for ; Mon, 26 Jan 2004 16:13:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlE2f-0004Uk-00 for ipv6@ietf.org; Mon, 26 Jan 2004 16:13:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlE1i-0004TK-00 for ipv6@ietf.org; Mon, 26 Jan 2004 16:12:11 -0500 Received: from uillean.fuaim.com ([206.197.161.140]) by ietf-mx with esmtp (Exim 4.12) id 1AlE10-0004PW-00 for ipv6@ietf.org; Mon, 26 Jan 2004 16:11:27 -0500 Received: from clairseach.fuaim.com (clairseach.fuaim.com [206.197.161.141]) by uillean.fuaim.com (8.11.6/8.11.6) with ESMTP id i0QLAjV26519; Mon, 26 Jan 2004 13:10:45 -0800 Received: from innovationslab.net (md-wmnsmd-cuda2-c6a-a-4.chvlva.adelphia.net [68.65.120.4]) (authenticated bits=0) by clairseach.fuaim.com (8.12.8/8.12.8) with ESMTP id i0QLKBlN027975 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 26 Jan 2004 13:20:20 -0800 Message-ID: <40158226.4010700@innovationslab.net> Date: Mon, 26 Jan 2004 16:09:58 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipv6@ietf.org CC: ietf-ppp@merit.edu Subject: IPv6 Work Group Last Call:draft-ietf-ipv6-inet-tunnel-mib-00.txt Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit All, This begins the IPv6 WG Last Call on: Title : IP Tunnel MIB Author(s) : D. Thaler Filename : draft-ietf-ipv6-inet-tunnel-mib-00.txt Pages : 26 Date : 2004-1-20 This document is being submitted as a Proposed Standard. The Last Call will end on Feb 9, 2004. Please direct substantive comments to the IPv6 mailing list. Editorial comments can be directed to the author. Regards, Bob & Brian IPv6 WG co-chairs -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Jan 28 05:43:54 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24546 for ; Wed, 28 Jan 2004 05:43:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlnAO-0002ut-4x for ipv6-archive@odin.ietf.org; Wed, 28 Jan 2004 05:43:28 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0SAhSWd011207 for ipv6-archive@odin.ietf.org; Wed, 28 Jan 2004 05:43:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlnAN-0002ug-VT for ipv6-web-archive@optimus.ietf.org; Wed, 28 Jan 2004 05:43:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24516 for ; Wed, 28 Jan 2004 05:43:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlnAK-0002zE-00 for ipv6-web-archive@ietf.org; Wed, 28 Jan 2004 05:43:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aln9P-0002tl-00 for ipv6-web-archive@ietf.org; Wed, 28 Jan 2004 05:42:28 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Aln8V-0002nW-00 for ipv6-web-archive@ietf.org; Wed, 28 Jan 2004 05:41:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aln83-0002Ux-CQ; Wed, 28 Jan 2004 05:41:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aln7X-0002Ts-Ll for ipv6@optimus.ietf.org; Wed, 28 Jan 2004 05:40:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24363 for ; Wed, 28 Jan 2004 05:40:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aln7U-0002gk-00 for ipv6@ietf.org; Wed, 28 Jan 2004 05:40:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aln6b-0002cX-00 for ipv6@ietf.org; Wed, 28 Jan 2004 05:39:33 -0500 Received: from mtagate3.de.ibm.com ([195.212.29.152]) by ietf-mx with esmtp (Exim 4.12) id 1Aln6G-0002Xg-00 for ipv6@ietf.org; Wed, 28 Jan 2004 05:39:12 -0500 Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196]) by mtagate3.de.ibm.com (8.12.10/8.12.10) with ESMTP id i0SAcgHI029368 for ; Wed, 28 Jan 2004 10:38:42 GMT Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by d12relay02.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0SAcfco246336 for ; Wed, 28 Jan 2004 11:38:42 +0100 Received: from zurich.ibm.com (sig-9-145-246-215.de.ibm.com [9.145.246.215]) by collon.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id LAA62212 for ; Wed, 28 Jan 2004 11:38:40 +0100 Message-ID: <401790E8.E1331180@zurich.ibm.com> Date: Wed, 28 Jan 2004 11:37:28 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: IPv6 WG Last Call:draft-ietf-ipv6-unique-local-addr-02.txt References: <40158529.2090805@innovationslab.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I think this is vitally necessary and ready to go to the IESG. If proof be needed, I heard yesterday something that I found extraordinary until I thought about it. It seems that major companies considering selling a division are now routinely renumbering the entire division into Net 10 prior to the sale, so that it can be snipped off from the corporate network in a few seconds, and NATted onto the purchaser's network just as quickly. (Please don't shoot the messenger - this is reality, to be dealt with.) We need to offer a similar ability in IPv6 without creating ambiguous addresses and requiring NATs as a result. Brian - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM *** I will be on vacation February 3-25, 2004 *** Brian Haberman wrote: > > All, > This is the start of an IPv6 working group last call on: > > > Title : Unique Local IPv6 Unicast Addresses > > Author(s) : R. Hinden, B. Haberman > > Filename : draft-ietf-ipv6-unique-local-addr-02.txt > > Pages : 16 > > Date : 2004-1-21 > > This Last Call will end on Feb 2, 2004. This document is being > submitted as a Proposed Standard. This last call is to verify > consensus on the text changes made in response to the previous > last call. Substantive comments should be directed to the mailing > list and editorial comments to the authors. > > Regards, > Brian & Bob > IPv6 WG co-chairs > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Jan 28 15:14:34 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25309 for ; Wed, 28 Jan 2004 15:14:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Alw4c-0002if-1M for ipv6-archive@odin.ietf.org; Wed, 28 Jan 2004 15:14:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0SKE6lO010450 for ipv6-archive@odin.ietf.org; Wed, 28 Jan 2004 15:14:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Alw4b-0002iT-Qz for ipv6-web-archive@optimus.ietf.org; Wed, 28 Jan 2004 15:14:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25267 for ; Wed, 28 Jan 2004 15:14:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Alw4a-0005KJ-00 for ipv6-web-archive@ietf.org; Wed, 28 Jan 2004 15:14:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Alw3e-0005CC-00 for ipv6-web-archive@ietf.org; Wed, 28 Jan 2004 15:13:07 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Alw37-00054A-00 for ipv6-web-archive@ietf.org; Wed, 28 Jan 2004 15:12:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Alw2a-0001kI-6J; Wed, 28 Jan 2004 15:12:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Alw2T-0001hi-TL for ipv6@optimus.ietf.org; Wed, 28 Jan 2004 15:11:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24888 for ; Wed, 28 Jan 2004 15:11:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Alw2Q-00052u-00 for ipv6@ietf.org; Wed, 28 Jan 2004 15:11:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Alw1T-0004xU-00 for ipv6@ietf.org; Wed, 28 Jan 2004 15:10:52 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1Alw0u-0004qo-00 for ipv6@ietf.org; Wed, 28 Jan 2004 15:10:16 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i0SK9Z916542; Wed, 28 Jan 2004 12:09:35 -0800 X-mProtect: <200401282009> Nokia Silicon Valley Messaging Protection Received: from ftemplin.iprg.nokia.com (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdM5Egni; Wed, 28 Jan 2004 12:09:31 PST Message-ID: <40181705.5050702@iprg.nokia.com> Date: Wed, 28 Jan 2004 12:09:41 -0800 From: Fred Templin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Haberman CC: ipv6@ietf.org Subject: Re: ICMPv6 Rate Limiting Methods: Revised Test (final ??) References: <40158002.6060801@innovationslab.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Brian, Based on the analysis in my last message, I also agree with Pekka. But, I would still prefer to see the rate limiting text include the term "messages/bytes" instead of just "messages". If it is too complicated I'm just not seeing it; if it is problematic, that is a different story. I'm interested to know others' thoughts on this, but also recognize the need for closure. Thanks - Fred ftemplin@iprg.nokia.com Brian Haberman wrote: > > > I agree with Pekka's assessment on the issues with changing the > text on rate-limiting. Adding complicated scenarios is not in > the best interest of this document. So, unless someone can show > evidence of a reason to do so, let's keep the text straightforward > and as simple as possible. > > Regards, > Brian > > Pekka Savola wrote: > >> On Mon, 19 Jan 2004, Fred Templin wrote: >> [...] >> >>> Assuming we are on the same page, >> >> >> >> Yep. >> >> >>> there are two worst-case threat >>> models to consider: >> >> >> >>> Threat model 1: >>> ************* >>> Node B (i.e., "the router") is congested in terms of CPU load, memory >>> utilization, etc, while the network path from B->C is uncongested and >>> uses only fast links. >>> >>> Threat model 2: >>> ************* >>> The router is uncongested, but the network path from B->C is congested >>> and/or has low-bandwidth links. >> >> >> >> I disagree that we should be concerned about threat model 2 in this >> specification. The rate-limiting of ICMP error generation is seems >> totally irrelevant when you consider the big pictuare of model 2: >> you can perform the same overloading with ICMP echo reply/request >> messages, any traffic you want (e.g. UDP streams), etc. -- the point >> is that if your network is congested (or low-bandwidth), you have to >> deal with it in your network anyway -- no amount of changes to ICMP >> rate-limiting is going to change that in any significant way. >> >> >>> This is threat model 2. This threat model would apply to the "trailing >>> edge" of the router's algorithm for generating ICMPv6 errors, i.e., >>> if the router's local resources are uncongested it will generate the >>> errors, forward them to the network for transmission, but will then >>> have no way of knowing whether a congested/bandwidth-constrained >>> link occurs on the path B->C (unless the congested link occurs on the >>> 1st hop) >> >> >> >> Yes, the router has no way of knowing about the congestion or >> bandwidth constrains anywhere along the path.. >> >> >>> and should therefore use AQM on ICMPv6 errors sent on >>> the outgoing attached link. >> >> >> >> But I disagree with this conclusion, as discussed above. >> >> >>> I agree that this issue calls for AQM for all kinds of packets, and >>> indeed this is well supported by the BCP documents. But, I disagree >>> that no special action should be needed for ICMPv6 error messages. >>> For example, suppose node X at the head of a slow link X->Y on the >>> path from B->C is using AQM and operating near the queue's high >>> water mark. If the traffic passing through X->Y is mostly due to well >>> behaved sessions, a high arrival rate of ICMPv6 error messages from >>> B at X will result in an equal likelihood of dropping the legitimate >>> traffic as dropping the ICMPv6 messages. Also, we have only the BCP >>> recommendations that network nodes implement AQM; we have no >>> guarantees that network nodes along all forwarding paths will comply. >> >> >> >> I have to disagree with this reasoning. ICMPv6 is not special. If we >> had a community consensus that we must immediately adapt all the >> protocols out there to cater for the case where there may be >> congestion or low bandwidth links on the path, I'd probably agree >> that the behaviour needs to be changed. But there is no such >> consensus, and inserting changes to ICMPv6 to accommodate this model >> is irrelevant and unnecessary in the big picture of bandwidth >> constraints and low bandwidth links. >> > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Jan 28 17:23:15 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03139 for ; Wed, 28 Jan 2004 17:23:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aly5A-0006jL-N5 for ipv6-archive@odin.ietf.org; Wed, 28 Jan 2004 17:22:49 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0SMMmri025871 for ipv6-archive@odin.ietf.org; Wed, 28 Jan 2004 17:22:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aly5A-0006jC-Jl for ipv6-web-archive@optimus.ietf.org; Wed, 28 Jan 2004 17:22:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03105 for ; Wed, 28 Jan 2004 17:22:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aly58-0004RM-00 for ipv6-web-archive@ietf.org; Wed, 28 Jan 2004 17:22:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aly4A-0004LH-00 for ipv6-web-archive@ietf.org; Wed, 28 Jan 2004 17:21:47 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Aly3D-0004Fi-00 for ipv6-web-archive@ietf.org; Wed, 28 Jan 2004 17:20:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aly2h-0006LB-VZ; Wed, 28 Jan 2004 17:20:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aly2L-0006Gp-GG for ipv6@optimus.ietf.org; Wed, 28 Jan 2004 17:19:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03016 for ; Wed, 28 Jan 2004 17:19:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aly2J-0004Ac-00 for ipv6@ietf.org; Wed, 28 Jan 2004 17:19:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aly1P-00042F-00 for ipv6@ietf.org; Wed, 28 Jan 2004 17:18:56 -0500 Received: from kahuna.telstra.net ([203.50.0.6]) by ietf-mx with esmtp (Exim 4.12) id 1Aly0S-0003lZ-00 for ipv6@ietf.org; Wed, 28 Jan 2004 17:17:56 -0500 Received: from gih505.telstra.net (kahuna.telstra.net [203.50.0.6]) by kahuna.telstra.net (8.12.3/8.11.3) with ESMTP id i0SMHIua057689 for ; Thu, 29 Jan 2004 09:17:23 +1100 (EST) (envelope-from gih@telstra.net) Message-Id: <6.0.1.1.2.20040129091259.01d3a428@localhost> X-Sender: gih@localhost X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Thu, 29 Jan 2004 09:17:17 +1100 To: ipv6@ietf.org From: Geoff Huston Subject: Re: IPv6 WG Last Call:draft-ietf-ipv6-unique-local-addr-02.txt In-Reply-To: <40158529.2090805@innovationslab.net> References: <40158529.2090805@innovationslab.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 I had raised a number of issues with pervious versions of this draft, and subsequently I've worked with the draft's authors on this. I'd like to provide the WG with the comment that this draft resolves the issues I've raised and I support it moving forward. thanks, Geoff At 08:22 AM 27/01/2004, Brian Haberman wrote: >All, > This is the start of an IPv6 working group last call on: > >> Title : Unique Local IPv6 Unicast Addresses >> Author(s) : R. Hinden, B. Haberman >> Filename : draft-ietf-ipv6-unique-local-addr-02.txt >> Pages : 16 >> Date : 2004-1-21 > >-------------------------------------------------------------------- >IETF IPv6 working group mailing list >ipv6@ietf.org >Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Jan 28 19:25:20 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08945 for ; Wed, 28 Jan 2004 19:25:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlzzJ-00050r-HI for ipv6-archive@odin.ietf.org; Wed, 28 Jan 2004 19:24:53 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0T0Or6F019265 for ipv6-archive@odin.ietf.org; Wed, 28 Jan 2004 19:24:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlzzJ-00050c-DB for ipv6-web-archive@optimus.ietf.org; Wed, 28 Jan 2004 19:24:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08900 for ; Wed, 28 Jan 2004 19:24:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlzzH-0001Bf-00 for ipv6-web-archive@ietf.org; Wed, 28 Jan 2004 19:24:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlzyJ-00015K-00 for ipv6-web-archive@ietf.org; Wed, 28 Jan 2004 19:23:51 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AlzxP-0000zk-00 for ipv6-web-archive@ietf.org; Wed, 28 Jan 2004 19:22:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlzwZ-0004ZY-8B; Wed, 28 Jan 2004 19:22:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlzvZ-0004U5-5K for ipv6@optimus.ietf.org; Wed, 28 Jan 2004 19:21:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08783 for ; Wed, 28 Jan 2004 19:20:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlzvX-0000mp-00 for ipv6@ietf.org; Wed, 28 Jan 2004 19:20:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Alzub-0000gg-00 for ipv6@ietf.org; Wed, 28 Jan 2004 19:20:02 -0500 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx with esmtp (Exim 4.12) id 1Alztw-0000aG-00 for ipv6@ietf.org; Wed, 28 Jan 2004 19:19:20 -0500 Received: from esunmail ([129.147.156.34]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i0T0JKqV012550 for ; Wed, 28 Jan 2004 17:19:20 -0700 (MST) Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0HS8001D7688W7@edgemail1.Central.Sun.COM> for ipv6@ietf.org; Wed, 28 Jan 2004 17:19:20 -0700 (MST) Received: from sun.com ([192.18.45.134]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0HS8004FZ6878J@mail.sun.net> for ipv6@ietf.org; Wed, 28 Jan 2004 17:19:20 -0700 (MST) Date: Wed, 28 Jan 2004 16:22:05 -0800 From: Alain Durand Subject: Re: IPv6 WG Last Call:draft-ietf-ipv6-unique-local-addr-02.txt In-reply-to: <40158529.2090805@innovationslab.net> To: Brian Haberman Cc: ipv6@ietf.org Message-id: <4018522D.1030603@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) References: <40158529.2090805@innovationslab.net> Content-Transfer-Encoding: 7BIT Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Brian Haberman wrote: > All, > This is the start of an IPv6 working group last call on: > >> Title : Unique Local IPv6 Unicast Addresses >> Author(s) : R. Hinden, B. Haberman >> Filename : draft-ietf-ipv6-unique-local-addr-02.txt >> Pages : 16 >> Date : 2004-1-21 > This draft is a good improvement on the previous revision. However, there is an issue that was discussed and that is not capture here. The draft says: Locally assigned global IDs MUST be generated with a pseudo-random algorithm consistent with [RANDOM]. I would have like to see some stronger wording to explain that, in the self assigned case, choosing FD00::/48 is a very bad idea. - Alain. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Jan 28 19:35:32 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09291 for ; Wed, 28 Jan 2004 19:35:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Am09B-0005oI-Ob for ipv6-archive@odin.ietf.org; Wed, 28 Jan 2004 19:35:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0T0Z51W022328 for ipv6-archive@odin.ietf.org; Wed, 28 Jan 2004 19:35:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Am09B-0005o3-KC for ipv6-web-archive@optimus.ietf.org; Wed, 28 Jan 2004 19:35:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09247 for ; Wed, 28 Jan 2004 19:35:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Am099-00027p-00 for ipv6-web-archive@ietf.org; Wed, 28 Jan 2004 19:35:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Am083-00020p-00 for ipv6-web-archive@ietf.org; Wed, 28 Jan 2004 19:33:56 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Am07M-0001vB-00 for ipv6-web-archive@ietf.org; Wed, 28 Jan 2004 19:33:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Am07C-0005UR-73; Wed, 28 Jan 2004 19:33:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Am070-0005Tv-UZ for ipv6@optimus.ietf.org; Wed, 28 Jan 2004 19:32:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09181 for ; Wed, 28 Jan 2004 19:32:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Am06z-0001tl-00 for ipv6@ietf.org; Wed, 28 Jan 2004 19:32:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Am060-0001oA-00 for ipv6@ietf.org; Wed, 28 Jan 2004 19:31:49 -0500 Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx with esmtp (Exim 4.12) id 1Am052-0001ex-00 for ipv6@ietf.org; Wed, 28 Jan 2004 19:30:48 -0500 Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 28 Jan 2004 16:30:02 -0800 Received: from 157.54.5.25 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 28 Jan 2004 16:30:12 -0800 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 28 Jan 2004 16:30:17 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 28 Jan 2004 16:30:16 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Wed, 28 Jan 2004 16:30:15 -0800 X-MIMEOLE: Produced By Microsoft Exchange V6.5.7165.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: IPv6 WG Last Call:draft-ietf-ipv6-unique-local-addr-02.txt Date: Wed, 28 Jan 2004 16:30:13 -0800 Message-ID: Thread-Topic: IPv6 WG Last Call:draft-ietf-ipv6-unique-local-addr-02.txt Thread-Index: AcPl/h5lfh4edAoGTPu4GSJrtzXGjwAAH49w From: "Christian Huitema" To: "Alain Durand" , "Brian Haberman" Cc: X-OriginalArrivalTime: 29 Jan 2004 00:30:15.0602 (UTC) FILETIME=[10B1E120:01C3E5FF] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > Locally assigned global IDs MUST be generated with a pseudo-random > algorithm consistent with [RANDOM]. >=20 > I would have like to see some stronger wording to explain that, in the > self assigned case, > choosing FD00::/48 is a very bad idea. The draft already says that we MUST assign these numbers exactly one way. Why on earth would we need to enumerate the 25 ways that should not be used? -- Christian Huitema -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Jan 28 19:54:27 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09985 for ; Wed, 28 Jan 2004 19:54:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Am0RS-0007XS-IC for ipv6-archive@odin.ietf.org; Wed, 28 Jan 2004 19:53:58 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0T0rwSR028972 for ipv6-archive@odin.ietf.org; Wed, 28 Jan 2004 19:53:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Am0RS-0007XD-CV for ipv6-web-archive@optimus.ietf.org; Wed, 28 Jan 2004 19:53:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09973 for ; Wed, 28 Jan 2004 19:53:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Am0RQ-00047I-00 for ipv6-web-archive@ietf.org; Wed, 28 Jan 2004 19:53:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Am0QU-00041o-00 for ipv6-web-archive@ietf.org; Wed, 28 Jan 2004 19:52:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Am0Pl-0003wE-00 for ipv6-web-archive@ietf.org; Wed, 28 Jan 2004 19:52:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Am0Pa-0007Cr-9v; Wed, 28 Jan 2004 19:52:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Am0Op-0007Al-2v for ipv6@optimus.ietf.org; Wed, 28 Jan 2004 19:51:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09857 for ; Wed, 28 Jan 2004 19:51:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Am0On-0003p2-00 for ipv6@ietf.org; Wed, 28 Jan 2004 19:51:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Am0Nl-0003hu-00 for ipv6@ietf.org; Wed, 28 Jan 2004 19:50:10 -0500 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by ietf-mx with esmtp (Exim 4.12) id 1Am0Mw-0003ai-00 for ipv6@ietf.org; Wed, 28 Jan 2004 19:49:18 -0500 Received: from esunmail ([129.147.156.34]) by brmea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i0T0nIbm022529 for ; Wed, 28 Jan 2004 17:49:18 -0700 (MST) Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0HS8000ZP7M5R8@edgemail1.Central.Sun.COM> for ipv6@ietf.org; Wed, 28 Jan 2004 17:49:18 -0700 (MST) Received: from sun.com ([192.18.45.134]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0HS800MG07M21P@mail.sun.net> for ipv6@ietf.org; Wed, 28 Jan 2004 17:49:17 -0700 (MST) Date: Wed, 28 Jan 2004 16:52:00 -0800 From: Alain Durand Subject: Re: IPv6 WG Last Call:draft-ietf-ipv6-unique-local-addr-02.txt In-reply-to: To: Christian Huitema Cc: Brian Haberman , ipv6@ietf.org Message-id: <40185930.2030206@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) References: Content-Transfer-Encoding: 7BIT Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Christian Huitema wrote: >> Locally assigned global IDs MUST be generated with a pseudo-random >> algorithm consistent with [RANDOM]. >> >>I would have like to see some stronger wording to explain that, in the >>self assigned case, >>choosing FD00::/48 is a very bad idea. >> >> > >The draft already says that we MUST assign these numbers exactly one >way. Why on earth would we need to enumerate the 25 ways that should not >be used? > Because there is one of those 25 ways that is very tempting and is known to be problematic. - Alain. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Jan 29 20:36:12 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04888 for ; Thu, 29 Jan 2004 20:36:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmNZP-0001Zn-N0 for ipv6-archive@odin.ietf.org; Thu, 29 Jan 2004 20:35:44 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0U1ZhZT006055 for ipv6-archive@odin.ietf.org; Thu, 29 Jan 2004 20:35:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmNZP-0001Za-J4 for ipv6-web-archive@optimus.ietf.org; Thu, 29 Jan 2004 20:35:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04869 for ; Thu, 29 Jan 2004 20:35:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmNZN-0001Ky-00 for ipv6-web-archive@ietf.org; Thu, 29 Jan 2004 20:35:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmNYQ-0001Eh-00 for ipv6-web-archive@ietf.org; Thu, 29 Jan 2004 20:34:42 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AmNXV-000193-00 for ipv6-web-archive@ietf.org; Thu, 29 Jan 2004 20:33:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmNWo-0001JO-3x; Thu, 29 Jan 2004 20:33:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmNWb-0001IQ-Vq for ipv6@optimus.ietf.org; Thu, 29 Jan 2004 20:32:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04791 for ; Thu, 29 Jan 2004 20:32:47 -0500 (EST) From: Mukesh.Gupta@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmNWZ-00012S-00 for ipv6@ietf.org; Thu, 29 Jan 2004 20:32:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmNVd-0000vF-00 for ipv6@ietf.org; Thu, 29 Jan 2004 20:31:50 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AmNV5-0000oh-00 for ipv6@ietf.org; Thu, 29 Jan 2004 20:31:15 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i0U1VE206879 for ; Fri, 30 Jan 2004 03:31:14 +0200 (EET) Received: from daebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 30 Jan 2004 03:31:14 +0200 Received: from daebe009.NOE.Nokia.com ([10.241.35.109]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 29 Jan 2004 19:31:13 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: ICMPv6: New destination unreachable codes Date: Thu, 29 Jan 2004 19:31:12 -0600 Message-ID: <8D260779A766FB4A9C1739A476F84FA42ABE7D@daebe009.americas.nokia.com> Thread-Topic: ICMPv6: New destination unreachable codes Thread-Index: AcPm0LhtxWF6DaQjT2ulHw+NwRSoSA== To: X-OriginalArrivalTime: 30 Jan 2004 01:31:13.0373 (UTC) FILETIME=[BF4F30D0:01C3E6D0] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi, I have added 2 new destination unreachable codes that Bob suggested in the ICMPv6 draft. (me and Bob had a discussion offline and the text is=20 outcome of that) Here is the new text. I would appreciate everyone's=20 comments. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ICMPv6 Fields: Type 1 Code 0 - no route to destination 1 - communication with destination administratively prohibited 2 - beyond scope of source address 3 - address unreachable 4 - port unreachable 5 - source address failed ingress policy 6 - reject route to destination Unused This field is unused for all code values. It must be initialized to zero by the sender and ignored by the receiver. Description A Destination Unreachable message SHOULD be generated by a router, or by the IPv6 layer in the originating node, in response to a packet that cannot be delivered to its destination address for reasons other than congestion. (An ICMPv6 message MUST NOT be generated if a packet is dropped due to congestion.) If the reason for the failure to deliver is lack of a matching entry in the forwarding node's routing table, the Code field is set to 0 (NOTE: this error can occur only in nodes that do not hold a "default route" in their routing tables). If the reason for the failure to deliver is administrative prohibition, e.g., a "firewall filter", the Code field is set to 1. If the reason for the failure to deliver is that the destination is beyond the scope of the source address, the Code field is set to 2. This condition can occur only when the scope of the source address is smaller than the scope of the destination address (e.g., when a packet has a link-local source address and a global-scope destination address) and the packet cannot be delivered to the destination without leaving the scope of the source address. If the reason for the failure to deliver can not be mapped to any of the specific codes listed above, the Code field is set to 3. The example of such cases are inability to resolve the IPv6 destination address into a corresponding link address, or a link-specific problem of some sort. One specific case in which a Destination Unreachable message with a code 3 is sent is in response to a packet received by a router from a point-to-point link, destined to an address within a subnet assigned to that same link (other than one of the receiving router's own addresses). In such a case, the packet MUST NOT be forwarded back onto the arrival link. A destination node SHOULD send a Destination Unreachable message with Code 4 in response to a packet for which the transport protocol (e.g., UDP) has no listener, if that transport protocol has no alternative means to inform the sender. If the reason for the failure to deliver is that packets with this source address is not allowed due to ingress filtering policies, the Code field is set to 5. If the reason for the failure to deliver is that the route to the destination is a reject route, the Code field is set to 6. This may occur if the router has been configured to reject all the traffic for a specific prefix. Upper layer notification A node receiving the ICMPv6 Destination Unreachable message MUST notify the upper-layer process. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Regards Mukesh -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Jan 29 20:43:17 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05232 for ; Thu, 29 Jan 2004 20:43:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmNgH-0002o4-9P for ipv6-archive@odin.ietf.org; Thu, 29 Jan 2004 20:42:49 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0U1gnhH010782 for ipv6-archive@odin.ietf.org; Thu, 29 Jan 2004 20:42:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmNgH-0002np-57 for ipv6-web-archive@optimus.ietf.org; Thu, 29 Jan 2004 20:42:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05209 for ; Thu, 29 Jan 2004 20:42:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmNgE-0002E9-00 for ipv6-web-archive@ietf.org; Thu, 29 Jan 2004 20:42:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmNfG-00026a-00 for ipv6-web-archive@ietf.org; Thu, 29 Jan 2004 20:41:47 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AmNeZ-00020S-00 for ipv6-web-archive@ietf.org; Thu, 29 Jan 2004 20:41:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmNeX-0002Ii-OK; Thu, 29 Jan 2004 20:41:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmNeN-0002I5-51 for ipv6@optimus.ietf.org; Thu, 29 Jan 2004 20:40:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05125 for ; Thu, 29 Jan 2004 20:40:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmNeK-0001zq-00 for ipv6@ietf.org; Thu, 29 Jan 2004 20:40:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmNdR-0001tT-00 for ipv6@ietf.org; Thu, 29 Jan 2004 20:39:53 -0500 Received: from usen-221x249x121x227.ap-us01.usen.ad.jp ([221.249.121.227] helo=coconut.itojun.org) by ietf-mx with esmtp (Exim 4.12) id 1AmNd7-0001mP-00 for ipv6@ietf.org; Thu, 29 Jan 2004 20:39:33 -0500 Received: by coconut.itojun.org (Postfix, from userid 1001) id E970DA5; Fri, 30 Jan 2004 10:39:09 +0900 (JST) To: Mukesh.Gupta@nokia.com Cc: ipv6@ietf.org Subject: Re: ICMPv6: New destination unreachable codes In-Reply-To: Your message of "Thu, 29 Jan 2004 19:31:12 -0600" <8D260779A766FB4A9C1739A476F84FA42ABE7D@daebe009.americas.nokia.com> References: <8D260779A766FB4A9C1739A476F84FA42ABE7D@daebe009.americas.nokia.com> X-Mailer: Cue version 0.6 (031125-1130/itojun) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20040130013909.E970DA5@coconut.itojun.org> Date: Fri, 30 Jan 2004 10:39:09 +0900 (JST) From: itojun@itojun.org (Jun-ichiro itojun Hagino) Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 > I have added 2 new destination unreachable codes that > Bob suggested in the ICMPv6 draft. > (me and Bob had a discussion offline and the text is > outcome of that) > Here is the new text. I would appreciate everyone's > comments. > ============== > ICMPv6 Fields: > > Type 1 > > Code 0 - no route to destination > 1 - communication with destination > administratively prohibited > 2 - beyond scope of source address > 3 - address unreachable > 4 - port unreachable > 5 - source address failed ingress policy > 6 - reject route to destination i'm not sure if code 6 (reject route to destintion) is useful. normally ISPs want to immitate "address unreachable" when they install reject route. if what kind of case in which code 6 is useful? itojun -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Jan 29 20:59:14 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05789 for ; Thu, 29 Jan 2004 20:59:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmNvi-0003hV-7l for ipv6-archive@odin.ietf.org; Thu, 29 Jan 2004 20:58:46 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0U1wk6r014225 for ipv6-archive@odin.ietf.org; Thu, 29 Jan 2004 20:58:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmNvh-0003hM-Qf for ipv6-web-archive@optimus.ietf.org; Thu, 29 Jan 2004 20:58:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05773 for ; Thu, 29 Jan 2004 20:58:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmNvf-00049w-00 for ipv6-web-archive@ietf.org; Thu, 29 Jan 2004 20:58:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmNuj-00043n-00 for ipv6-web-archive@ietf.org; Thu, 29 Jan 2004 20:57:46 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AmNu4-0003wp-00 for ipv6-web-archive@ietf.org; Thu, 29 Jan 2004 20:57:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmNu1-0003PM-Vp; Thu, 29 Jan 2004 20:57:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmNtu-0003Ow-Tn for ipv6@optimus.ietf.org; Thu, 29 Jan 2004 20:56:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05732 for ; Thu, 29 Jan 2004 20:56:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmNts-0003w2-00 for ipv6@ietf.org; Thu, 29 Jan 2004 20:56:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmNsv-0003pD-00 for ipv6@ietf.org; Thu, 29 Jan 2004 20:55:54 -0500 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx with esmtp (Exim 4.12) id 1AmNsX-0003hr-00 for ipv6@ietf.org; Thu, 29 Jan 2004 20:55:29 -0500 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i0U1sxj4029568; Thu, 29 Jan 2004 17:54:59 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i0U1sxjM028347; Thu, 29 Jan 2004 20:54:59 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.10+Sun/8.12.10) with ESMTP id i0U1sxe7009070; Thu, 29 Jan 2004 20:54:59 -0500 (EST) Message-Id: <200401300154.i0U1sxe7009070@thunk.east.sun.com> From: Bill Sommerfeld To: Mukesh.Gupta@nokia.com cc: ipv6@ietf.org Subject: Re: ICMPv6: New destination unreachable codes In-Reply-To: Your message of "Thu, 29 Jan 2004 19:31:12 CST." <8D260779A766FB4A9C1739A476F84FA42ABE7D@daebe009.americas.nokia.com> Reply-to: sommerfeld@east.sun.com Date: Thu, 29 Jan 2004 20:54:59 -0500 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 If the reason for the failure to deliver is administrative prohibition, e.g., a "firewall filter", the Code field is set to 1. If the reason for the failure to deliver is that packets with this source address is not allowed due to ingress filtering policies, the Code field is set to 5. If the reason for the failure to deliver is that the route to the destination is a reject route, the Code field is set to 6. This may occur if the router has been configured to reject all the traffic for a specific prefix. Isn't a reject route just a simple type of firewall/administrative prohibition? Likewise for ingress filtering? Is the intent to distinguish between "packet was dropped because policy says packets from that source should be dropped" and "packet was dropped because policy says that packets to that destination should be dropped"? - Bill -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Jan 29 21:26:20 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06952 for ; Thu, 29 Jan 2004 21:26:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmOLw-0006WC-QY for ipv6-archive@odin.ietf.org; Thu, 29 Jan 2004 21:25:52 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0U2Pqwl025056 for ipv6-archive@odin.ietf.org; Thu, 29 Jan 2004 21:25:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmOLw-0006W3-LA for ipv6-web-archive@optimus.ietf.org; Thu, 29 Jan 2004 21:25:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06943 for ; Thu, 29 Jan 2004 21:25:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmOLu-0007QM-00 for ipv6-web-archive@ietf.org; Thu, 29 Jan 2004 21:25:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmOL3-0007Jc-00 for ipv6-web-archive@ietf.org; Thu, 29 Jan 2004 21:24:58 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AmOKE-0007Cb-00 for ipv6-web-archive@ietf.org; Thu, 29 Jan 2004 21:24:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmOK9-0006Bh-EP; Thu, 29 Jan 2004 21:24:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmOK0-0006As-Oc for ipv6@optimus.ietf.org; Thu, 29 Jan 2004 21:23:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06883 for ; Thu, 29 Jan 2004 21:23:49 -0500 (EST) From: Mukesh.Gupta@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmOJy-0007Bw-00 for ipv6@ietf.org; Thu, 29 Jan 2004 21:23:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmOJC-00075O-00 for ipv6@ietf.org; Thu, 29 Jan 2004 21:23:02 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AmOII-0006x8-00 for ipv6@ietf.org; Thu, 29 Jan 2004 21:22:06 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i0U2M3207857 for ; Fri, 30 Jan 2004 04:22:05 +0200 (EET) Received: from daebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 30 Jan 2004 04:21:58 +0200 Received: from daebe009.NOE.Nokia.com ([10.241.35.109]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 29 Jan 2004 20:21:56 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: ICMPv6: New destination unreachable codes Date: Thu, 29 Jan 2004 20:21:56 -0600 Message-ID: <8D260779A766FB4A9C1739A476F84FA42ABE7F@daebe009.americas.nokia.com> Thread-Topic: ICMPv6: New destination unreachable codes Thread-Index: AcPm1C+CjHsXgduoQkCXQBfZ2dhmpwAAlt5w To: Cc: X-OriginalArrivalTime: 30 Jan 2004 02:21:56.0858 (UTC) FILETIME=[D55E25A0:01C3E6D7] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Reject Route case is a specific case of the more general=20 "administrative prohibition". The administrative prohibition case might include other reasons like "source not allowed", "destination not allowed", "protocol=20 not allowed", "port not allowed", "in-secure packets not allowed", etc. Second paragraph of section 6.0 in draft=20 draft-ietf-ipv6-unique-local-addr-02.txt talks about a black hole=20 route for Local IPv6 prefix FC00::/7 and an appropriate ICMPv6 destination unreachable message. The new code "reject route to destination" is supposed to fulfill that need. I changed the name to "reject route" from "black hole route" because a "black hole route", as per the name, should drop the=20 packet silently without notifying the sender. Regards Mukesh > -----Original Message----- > From: sommerfeld@east.sun.com [mailto:sommerfeld@east.sun.com] > Sent: Thursday, January 29, 2004 5:55 PM > To: Gupta Mukesh (Nokia-NET/MtView) > Cc: ipv6@ietf.org > Subject: Re: ICMPv6: New destination unreachable codes=20 >=20 >=20 > If the reason for the failure to deliver is administrative > prohibition, e.g., a "firewall filter", the Code field is set to 1. >=20 > If the reason for the failure to deliver is that packets with this > source address is not allowed due to ingress filtering=20 > policies, the > Code field is set to 5. >=20 > If the reason for the failure to deliver is that the route to the > destination is a reject route, the Code field is set to 6.=20 > This may > occur if the router has been configured to reject all the=20 > traffic for > a specific prefix. >=20 > Isn't a reject route just a simple type of firewall/administrative > prohibition? Likewise for ingress filtering? =20 >=20 > Is the intent to distinguish between "packet was dropped because > policy says packets from that source should be dropped" and "packet > was dropped because policy says that packets to that destination > should be dropped"? =20 >=20 > - Bill >=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Jan 30 06:52:45 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10562 for ; Fri, 30 Jan 2004 06:52:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmXC6-0002AF-Vb for ipv6-archive@odin.ietf.org; Fri, 30 Jan 2004 06:52:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0UBqITe008315 for ipv6-archive@odin.ietf.org; Fri, 30 Jan 2004 06:52:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmXC6-0002A2-RH for ipv6-web-archive@optimus.ietf.org; Fri, 30 Jan 2004 06:52:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10550 for ; Fri, 30 Jan 2004 06:52:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmXC2-0005h0-00 for ipv6-web-archive@ietf.org; Fri, 30 Jan 2004 06:52:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmXB5-0005Yy-00 for ipv6-web-archive@ietf.org; Fri, 30 Jan 2004 06:51:16 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AmXAY-0005SB-00 for ipv6-web-archive@ietf.org; Fri, 30 Jan 2004 06:50:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmX9v-0001nv-OM; Fri, 30 Jan 2004 06:50:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmX3E-0001c8-Sr for ipv6@optimus.ietf.org; Fri, 30 Jan 2004 06:43:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10292 for ; Fri, 30 Jan 2004 06:43:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmX3A-0004fb-00 for ipv6@ietf.org; Fri, 30 Jan 2004 06:43:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmX2G-0004Xz-00 for ipv6@ietf.org; Fri, 30 Jan 2004 06:42:09 -0500 Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx with esmtp (Exim 4.12) id 1AmX1h-0004Qs-00 for ipv6@ietf.org; Fri, 30 Jan 2004 06:41:33 -0500 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 083EE838A; Fri, 30 Jan 2004 12:41:04 +0100 (CET) Received: from lolo (lolo.it.uc3m.es [163.117.139.223]) by smtp01.uc3m.es (Postfix) with SMTP id EB7C88404; Fri, 30 Jan 2004 12:41:03 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: , Subject: RE: ICMPv6: New destination unreachable codes Date: Fri, 30 Jan 2004 12:39:51 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <8D260779A766FB4A9C1739A476F84FA42ABE7D@daebe009.americas.nokia.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, i have a question about code 5 error: would the ICMP error message contain the suggested source address (or prefix that has to containe the source address) I mean, in the case that the packet is discarded becuase the source address is not compatible with the ingress filtering, the router that discards the packets probably knows which are the accepted prefixes, so it would be interesting to use the message error to inform the host about the correct prefix to use for this particular destination. Have you considered something about this? thanks, marcelo > -----Mensaje original----- > De: ipv6-admin@ietf.org [mailto:ipv6-admin@ietf.org]En nombre de > Mukesh.Gupta@nokia.com > Enviado el: viernes, 30 de enero de 2004 2:31 > Para: ipv6@ietf.org > Asunto: ICMPv6: New destination unreachable codes > > > Hi, > > I have added 2 new destination unreachable codes that > Bob suggested in the ICMPv6 draft. > > (me and Bob had a discussion offline and the text is > outcome of that) > > Here is the new text. I would appreciate everyone's > comments. > > ============== > ICMPv6 Fields: > > Type 1 > > Code 0 - no route to destination > 1 - communication with destination > administratively prohibited > 2 - beyond scope of source address > 3 - address unreachable > 4 - port unreachable > 5 - source address failed ingress policy > 6 - reject route to destination > > Unused This field is unused for all code values. > It must be initialized to zero by the sender > and ignored by the receiver. > Description > > A Destination Unreachable message SHOULD be generated by a router, or > by the IPv6 layer in the originating node, in response to a packet > that cannot be delivered to its destination address for reasons other > than congestion. (An ICMPv6 message MUST NOT be generated if a > packet is dropped due to congestion.) > > If the reason for the failure to deliver is lack of a matching entry > in the forwarding node's routing table, the Code field is set to 0 > (NOTE: this error can occur only in nodes that do not hold a "default > route" in their routing tables). > > If the reason for the failure to deliver is administrative > prohibition, e.g., a "firewall filter", the Code field is set to 1. > > If the reason for the failure to deliver is that the destination is > beyond the scope of the source address, the Code field is set to 2. > This condition can occur only when the scope of the source address is > smaller than the scope of the destination address (e.g., when a > packet has a link-local source address and a global-scope destination > address) and the packet cannot be delivered to the destination > without leaving the scope of the source address. > > If the reason for the failure to deliver can not be mapped to any of > the specific codes listed above, the Code field is set to 3. The > example of such cases are inability to resolve the IPv6 destination > address into a corresponding link address, or a link-specific problem > of some sort. > > One specific case in which a Destination Unreachable message with a > code 3 is sent is in response to a packet received by a router from a > point-to-point link, destined to an address within a subnet assigned > to that same link (other than one of the receiving router's own > addresses). In such a case, the packet MUST NOT be forwarded back > onto the arrival link. > > A destination node SHOULD send a Destination Unreachable message with > Code 4 in response to a packet for which the transport protocol > (e.g., UDP) has no listener, if that transport protocol has no > alternative means to inform the sender. > > If the reason for the failure to deliver is that packets with this > source address is not allowed due to ingress filtering policies, the > Code field is set to 5. > > If the reason for the failure to deliver is that the route to the > destination is a reject route, the Code field is set to 6. This may > occur if the router has been configured to reject all the traffic for > a specific prefix. > > Upper layer notification > > A node receiving the ICMPv6 Destination Unreachable message MUST > notify the upper-layer process. > ============== > > Regards > Mukesh > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Jan 30 09:41:44 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18710 for ; Fri, 30 Jan 2004 09:41:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmZpc-0003ii-Tp for ipv6-archive@odin.ietf.org; Fri, 30 Jan 2004 09:41:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0UEfGko014294 for ipv6-archive@odin.ietf.org; Fri, 30 Jan 2004 09:41:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmZpc-0003iT-Mi for ipv6-web-archive@optimus.ietf.org; Fri, 30 Jan 2004 09:41:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18670 for ; Fri, 30 Jan 2004 09:41:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmZpa-0004Zj-00 for ipv6-web-archive@ietf.org; Fri, 30 Jan 2004 09:41:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmZoh-0004Sc-00 for ipv6-web-archive@ietf.org; Fri, 30 Jan 2004 09:40:20 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AmZns-0004Li-00 for ipv6-web-archive@ietf.org; Fri, 30 Jan 2004 09:39:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmZnR-0003DK-Ch; Fri, 30 Jan 2004 09:39:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmZmc-00039R-N2 for ipv6@optimus.ietf.org; Fri, 30 Jan 2004 09:38:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18585 for ; Fri, 30 Jan 2004 09:38:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmZma-0004DT-00 for ipv6@ietf.org; Fri, 30 Jan 2004 09:38:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmZlh-00046N-00 for ipv6@ietf.org; Fri, 30 Jan 2004 09:37:13 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmZkn-0003uI-00 for ipv6@ietf.org; Fri, 30 Jan 2004 09:36:18 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i0UEZMO22317; Fri, 30 Jan 2004 16:35:22 +0200 Date: Fri, 30 Jan 2004 16:35:22 +0200 (EET) From: Pekka Savola To: marcelo bagnulo cc: Mukesh.Gupta@nokia.com, Subject: RE: ICMPv6: New destination unreachable codes In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Fri, 30 Jan 2004, marcelo bagnulo wrote: > I mean, in the case that the packet is discarded becuase the source address > is not compatible with the ingress filtering, the router that discards the > packets probably knows which are the accepted prefixes, so it would be > interesting to use the message error to inform the host about the correct > prefix to use for this particular destination. In general, the router does know the accepted prefixes, but the list might be even hundreds of prefixes long, not just one prefix. So, in general, embedding this information is not possible or feasible. The case of just one accepted prefix is special. Different question is whether it makes sense to add this information. In any case it could not be stronger than a MAY (IMHO), so you couldn't depend anyone adding it, so you'd have to devise the other mechanisms anyway. So, it seems a bit like adding the information is not worth the effort for the special case. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Jan 30 10:09:42 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20248 for ; Fri, 30 Jan 2004 10:09:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmaGh-0000ue-0I for ipv6-archive@odin.ietf.org; Fri, 30 Jan 2004 10:09:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0UF9Eca003498 for ipv6-archive@odin.ietf.org; Fri, 30 Jan 2004 10:09:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmaGg-0000uL-Qv for ipv6-web-archive@optimus.ietf.org; Fri, 30 Jan 2004 10:09:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20173 for ; Fri, 30 Jan 2004 10:09:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmaGe-00005u-00 for ipv6-web-archive@ietf.org; Fri, 30 Jan 2004 10:09:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmaFe-0007ll-00 for ipv6-web-archive@ietf.org; Fri, 30 Jan 2004 10:08:11 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AmaEi-0007e5-00 for ipv6-web-archive@ietf.org; Fri, 30 Jan 2004 10:07:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmaEY-0008Lm-1S; Fri, 30 Jan 2004 10:07:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmaDk-00089Q-Kn for ipv6@optimus.ietf.org; Fri, 30 Jan 2004 10:06:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19855 for ; Fri, 30 Jan 2004 10:06:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmaDi-0007X5-00 for ipv6@ietf.org; Fri, 30 Jan 2004 10:06:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmaCs-0007Qn-00 for ipv6@ietf.org; Fri, 30 Jan 2004 10:05:19 -0500 Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx with esmtp (Exim 4.12) id 1AmaC8-0007Ec-00 for ipv6@ietf.org; Fri, 30 Jan 2004 10:04:32 -0500 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 4C1BA8948; Fri, 30 Jan 2004 16:04:02 +0100 (CET) Received: from lolo (lolo.it.uc3m.es [163.117.139.223]) by smtp01.uc3m.es (Postfix) with SMTP id 34E458904; Fri, 30 Jan 2004 16:04:02 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "Pekka Savola" Cc: , Subject: RE: ICMPv6: New destination unreachable codes Date: Fri, 30 Jan 2004 16:02:49 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Pekka, I think i was too focussed in the site multihoming case :-) However, in the particular case of multihoming, the accepted source prefix is likely to be only one, i think. So in this case it would be useful to include it to allow the host to discover the appropriate prefix to be inlcuded in the source address. So, for the multihoming case, this would be IMHO pretty useful and it would worth the effort, i think. I agree that a MAY would do it, so that exit routers at multihomed sites can be configured to support this and hosts within the multihomed site are upgraded to understand the message regards, marcelo > -----Mensaje original----- > De: ipv6-admin@ietf.org [mailto:ipv6-admin@ietf.org]En nombre de Pekka > Savola > Enviado el: viernes, 30 de enero de 2004 15:35 > Para: marcelo bagnulo > CC: Mukesh.Gupta@nokia.com; ipv6@ietf.org > Asunto: RE: ICMPv6: New destination unreachable codes > > > On Fri, 30 Jan 2004, marcelo bagnulo wrote: > > I mean, in the case that the packet is discarded becuase the > source address > > is not compatible with the ingress filtering, the router that > discards the > > packets probably knows which are the accepted prefixes, so it would be > > interesting to use the message error to inform the host about > the correct > > prefix to use for this particular destination. > > In general, the router does know the accepted prefixes, but the list > might be even hundreds of prefixes long, not just one prefix. > > So, in general, embedding this information is not possible or > feasible. The case of just one accepted prefix is special. Different > question is whether it makes sense to add this information. In any > case it could not be stronger than a MAY (IMHO), so you couldn't > depend anyone adding it, so you'd have to devise the other mechanisms > anyway. > > So, it seems a bit like adding the information is not worth the effort > for the special case. > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Jan 30 10:18:41 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21215 for ; Fri, 30 Jan 2004 10:18:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmaPO-0003Xu-BM for ipv6-archive@odin.ietf.org; Fri, 30 Jan 2004 10:18:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0UFIElF013624 for ipv6-archive@odin.ietf.org; Fri, 30 Jan 2004 10:18:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmaPO-0003Xf-6r for ipv6-web-archive@optimus.ietf.org; Fri, 30 Jan 2004 10:18:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21117 for ; Fri, 30 Jan 2004 10:18:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmaPL-0001Gc-00 for ipv6-web-archive@ietf.org; Fri, 30 Jan 2004 10:18:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmaOL-00016F-00 for ipv6-web-archive@ietf.org; Fri, 30 Jan 2004 10:17:09 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AmaNL-0000tg-00 for ipv6-web-archive@ietf.org; Fri, 30 Jan 2004 10:16:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmaNG-0002jT-Qe; Fri, 30 Jan 2004 10:16:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmaMZ-0002az-CW for ipv6@optimus.ietf.org; Fri, 30 Jan 2004 10:15:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20833 for ; Fri, 30 Jan 2004 10:15:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmaMX-0000rV-00 for ipv6@ietf.org; Fri, 30 Jan 2004 10:15:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmaLf-0000kf-00 for ipv6@ietf.org; Fri, 30 Jan 2004 10:14:23 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmaL0-0000b7-00 for ipv6@ietf.org; Fri, 30 Jan 2004 10:13:42 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i0UFD9A23058; Fri, 30 Jan 2004 17:13:09 +0200 Date: Fri, 30 Jan 2004 17:13:09 +0200 (EET) From: Pekka Savola To: marcelo bagnulo cc: Mukesh.Gupta@nokia.com, Subject: RE: ICMPv6: New destination unreachable codes In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Fri, 30 Jan 2004, marcelo bagnulo wrote: [..] > I agree that a MAY would do it, so that exit routers at multihomed sites can > be configured to support this and hosts within the multihomed site are > upgraded to understand the message But what do you do when the routers will NOT supply this message? In general, I think only few routers would report this, as it would require an entirely new kind of logical "interface" between ingress filtering and ICMP in the implementation (when generating the ICMP message, look up the ingress filtering table in a new way, again) -- especially the products which do not generate these messages on software would unlikely be upgraded. Note that you have to add different code in the hosts for the major case when this supplemental information is NOT supplied as well. This would be just an optimization, and an unnecessary one for a dual-homed network (if it fails, just try the other address :), which is probably (unless you subscribe to ohta-san's DFZ model :) the common case. So this would seem to be an optimization for the case that: - routers in fact do supply the information, - just one prefix is used per router, - the site/host is multihomed to at least 3 providers. Is it really worth it? :-) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Jan 30 10:59:45 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22995 for ; Fri, 30 Jan 2004 10:59:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Amb38-000768-Ky for ipv6-archive@odin.ietf.org; Fri, 30 Jan 2004 10:59:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0UFxIPM027285 for ipv6-archive@odin.ietf.org; Fri, 30 Jan 2004 10:59:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Amb38-000760-Cu for ipv6-web-archive@optimus.ietf.org; Fri, 30 Jan 2004 10:59:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22969 for ; Fri, 30 Jan 2004 10:59:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Amb35-0006N6-00 for ipv6-web-archive@ietf.org; Fri, 30 Jan 2004 10:59:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Amb25-0006FX-00 for ipv6-web-archive@ietf.org; Fri, 30 Jan 2004 10:58:13 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Amb1M-00068Q-00 for ipv6-web-archive@ietf.org; Fri, 30 Jan 2004 10:57:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Amb0v-0006mg-BK; Fri, 30 Jan 2004 10:57:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Amb0D-0006m9-5h for ipv6@optimus.ietf.org; Fri, 30 Jan 2004 10:56:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22915 for ; Fri, 30 Jan 2004 10:56:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Amb0A-00062B-00 for ipv6@ietf.org; Fri, 30 Jan 2004 10:56:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmazC-0005w5-00 for ipv6@ietf.org; Fri, 30 Jan 2004 10:55:14 -0500 Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx with esmtp (Exim 4.12) id 1AmayJ-0005kY-00 for ipv6@ietf.org; Fri, 30 Jan 2004 10:54:19 -0500 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id D9CB88C46; Fri, 30 Jan 2004 16:53:48 +0100 (CET) Received: from lolo (lolo.it.uc3m.es [163.117.139.223]) by smtp01.uc3m.es (Postfix) with SMTP id C36B58C3F; Fri, 30 Jan 2004 16:53:48 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "Pekka Savola" Cc: , Subject: RE: ICMPv6: New destination unreachable codes Date: Fri, 30 Jan 2004 16:52:35 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > But what do you do when the routers will NOT supply this message? Well, if you are trying to implement a multihomed solution and this solution involves multiple elements, i guess that you need all of them working properly. I mean, when you adopt this solution in a multihomed site, you have to make sure that both the router part and the host part of the solution is working. > > In general, I think only few routers would report this, as it would > require an entirely new kind of logical "interface" between ingress > filtering and ICMP in the implementation (when generating the ICMP > message, look up the ingress filtering table in a new way, again) -- > especially the products which do not generate these messages on > software would unlikely be upgraded. > OTOH, which routers do you think that will send a ICMP error back to the source?. My understanding is that edge routers are likely to send this message but core routers don't. So i don't expect that core routers will implement this but it is not needed for the multihoming solution, since for this multihoming solution to work, it only requires exit routers to support this. the bottom line is that, if we end up building a solution that is optimized with this message, i would expect that routers will implement it, becuase it would be useful. That is why, i think that a MAY would be OK > Note that you have to add different code in the hosts for the major > case when this supplemental information is NOT supplied as well. > This would be just an optimization, and an unnecessary one for a > dual-homed network (if it fails, just try the other address :), which > is probably (unless you subscribe to ohta-san's DFZ model :) the > common case. I fully agree with you. But the major case (as you call it) would be addressed by simply picking a random source address (different from the one included in the icmp error) So this would be an optimiztion, but imho a powerful one in some cases. For instance, consider a multihoming solution for medium size sites that have multiple providers and that run bgp with their isps. In this case, the internal routing system knows which path is available towards the selected destination, but the source address may be incompatible with the exit isp. In this case you need a mechanism to communicate the correct source address to the the host. If multiple prefixes are available at the site, the retrial process may be take a ling time. So this optimization would enable a much better performance. > > So this would seem to be an optimization for the case that: > > - routers in fact do supply the information, As i mentioned, if this is part of your multihoming solution, i guess you could assume this > - just one prefix is used per router, Well, the site exit router can connect with more than one provider implying more than one prefix, and there is no problem here, just choose one of the accepted prefixes > - the site/host is multihomed to at least 3 providers. Yes. While i agree that dual homing would be the most common case, i guess that there will be lots of site that multihome to more than 2 isp, so it is case that has to be considered also. regards, marcelo > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Jan 30 11:53:45 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27366 for ; Fri, 30 Jan 2004 11:53:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmbtO-0001MJ-54 for ipv6-archive@odin.ietf.org; Fri, 30 Jan 2004 11:53:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0UGrIDv005222 for ipv6-archive@odin.ietf.org; Fri, 30 Jan 2004 11:53:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmbtO-0001M9-1f for ipv6-web-archive@optimus.ietf.org; Fri, 30 Jan 2004 11:53:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27233 for ; Fri, 30 Jan 2004 11:53:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmbtM-0006V3-00 for ipv6-web-archive@ietf.org; Fri, 30 Jan 2004 11:53:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmbsQ-0006KN-00 for ipv6-web-archive@ietf.org; Fri, 30 Jan 2004 11:52:19 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AmbrS-0006BE-00 for ipv6-web-archive@ietf.org; Fri, 30 Jan 2004 11:51:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmbrC-0000Y6-R1; Fri, 30 Jan 2004 11:51:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmbqO-0000UW-3c for ipv6@optimus.ietf.org; Fri, 30 Jan 2004 11:50:12 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26852; Fri, 30 Jan 2004 11:50:08 -0500 (EST) Message-Id: <200401301650.LAA26852@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipv6@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipv6-rfc2096-update-06.txt Date: Fri, 30 Jan 2004 11:50:08 -0500 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Version 6 Working Group Working Group of the IETF. Title : IP Forwarding Table MIB Author(s) : M. Wasserman, B. Haberman Filename : draft-ietf-ipv6-rfc2096-update-06.txt Pages : 36 Date : 2004-1-29 This document defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects related to the forwarding of Internet Protocol (IP) packets in an IP version- independent manner. This document obsoletes RFC 2096. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-rfc2096-update-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipv6-rfc2096-update-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipv6-rfc2096-update-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-1-30121049.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-rfc2096-update-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-rfc2096-update-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-1-30121049.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Jan 30 12:56:46 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04251 for ; Fri, 30 Jan 2004 12:56:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmcsN-0006iz-Jt for ipv6-archive@odin.ietf.org; Fri, 30 Jan 2004 12:56:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0UHuJRJ025848 for ipv6-archive@odin.ietf.org; Fri, 30 Jan 2004 12:56:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmcsN-0006ip-Ev for ipv6-web-archive@optimus.ietf.org; Fri, 30 Jan 2004 12:56:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04189 for ; Fri, 30 Jan 2004 12:56:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmcsL-0002rm-00 for ipv6-web-archive@ietf.org; Fri, 30 Jan 2004 12:56:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmcrO-0002i3-00 for ipv6-web-archive@ietf.org; Fri, 30 Jan 2004 12:55:19 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AmcqU-0002ZO-00 for ipv6-web-archive@ietf.org; Fri, 30 Jan 2004 12:54:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Amcq9-0006IJ-ST; Fri, 30 Jan 2004 12:54:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmcpW-0006GB-IA for ipv6@optimus.ietf.org; Fri, 30 Jan 2004 12:53:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03971 for ; Fri, 30 Jan 2004 12:53:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmcpU-0002Ni-00 for ipv6@ietf.org; Fri, 30 Jan 2004 12:53:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmcoY-0002Ao-00 for ipv6@ietf.org; Fri, 30 Jan 2004 12:52:23 -0500 Received: from mail4.microsoft.com ([131.107.3.122]) by ietf-mx with esmtp (Exim 4.12) id 1Amcnh-0001qB-00 for ipv6@ietf.org; Fri, 30 Jan 2004 12:51:29 -0500 Received: from mail6.microsoft.com ([157.54.6.196]) by mail4.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 30 Jan 2004 09:51:03 -0800 Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Fri, 30 Jan 2004 09:50:57 -0800 Received: from 157.54.6.150 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 30 Jan 2004 09:50:57 -0800 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 30 Jan 2004 09:52:09 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Fri, 30 Jan 2004 09:51:18 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Fri, 30 Jan 2004 09:50:56 -0800 X-MIMEOLE: Produced By Microsoft Exchange V6.5.7165.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: ICMPv6: New destination unreachable codes Date: Fri, 30 Jan 2004 09:50:52 -0800 Message-ID: Thread-Topic: ICMPv6: New destination unreachable codes Thread-Index: AcPnSdgPlOlaGqDXS6OUeQ6JvU9ntAADL2qw From: "Christian Huitema" To: , "Pekka Savola" Cc: , X-OriginalArrivalTime: 30 Jan 2004 17:50:56.0110 (UTC) FILETIME=[9C8D08E0:01C3E759] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable =20 > > But what do you do when the routers will NOT supply this message? >=20 > Well, if you are trying to implement a multihomed solution and this > solution > involves multiple elements, i guess that you need all of them working > properly. I mean, when you adopt this solution in a multihomed site, you > have to make sure that both the router part and the host part of the > solution is working. In the site multi-homing case, the host has a choice of several possible source addresses. When a communication is requested, the host will choose a source/destination pair according to the Default Address Selection rules for IPv6 (RFC 3484). In some cases, the initial choice will be the wrong one, the connection will fail, and a smart host will want to retry with a new address pair.=20 The default algorithm will be to retry after a time-out without any information from the network. This default is necessary, because there will indeed be many cases where the network does not provide any explicit information. The question is then whether we can do better when the network does provide information, by means of an ICMP message. (Obviously, we have to be aware of security issues with ICMP messages.) The ICMP "destination unreachable" code allow for some help in the decision making. In the case of code 0, no route to destination, code 1, communication with destination administratively prohibited, and code 3, address unreachable the host should try another destination address if one is available. In the case of code 4, port unreachable, the communication probably just failed, although it might perhaps succeed with a different destination address. In the case of code 2 and code 5, the host should normally try a different source address. Marcelo's question is whether the code 5 message can be made just a bit more helpful than "try a new source address if you can", and whether it should give a hint about which new source address can be tried in preference. I understand the reluctance to add more parameters to an ICMP message. However, simply choosing an appropriate source address for the ICMP message might help.=20 In a site exit scenario, ingress filtering is performed either at the ingress interface of a router, or at one of the exit interfaces on the router. I suggest that the source address of the router's ICMP message should be one of the global scope addresses associated to that specific interface. This gives a strong hint to the host: among the source addresses that can be tried, pick the one that is the best match for the router's interface. -- Christian Huitema -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Jan 30 13:39:47 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07472 for ; Fri, 30 Jan 2004 13:39:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmdXz-0004hW-7t for ipv6-archive@odin.ietf.org; Fri, 30 Jan 2004 13:39:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0UIdJQG018064 for ipv6-archive@odin.ietf.org; Fri, 30 Jan 2004 13:39:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmdXy-0004hH-Ut for ipv6-web-archive@optimus.ietf.org; Fri, 30 Jan 2004 13:39:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07337 for ; Fri, 30 Jan 2004 13:39:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmdXw-0001cw-00 for ipv6-web-archive@ietf.org; Fri, 30 Jan 2004 13:39:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmdWz-0001TB-00 for ipv6-web-archive@ietf.org; Fri, 30 Jan 2004 13:38:18 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AmdW3-0001KW-00 for ipv6-web-archive@ietf.org; Fri, 30 Jan 2004 13:37:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmdVo-0003yY-OU; Fri, 30 Jan 2004 13:37:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmdVE-0003wl-0T for ipv6@optimus.ietf.org; Fri, 30 Jan 2004 13:36:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07229 for ; Fri, 30 Jan 2004 13:36:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmdVB-0001DW-00 for ipv6@ietf.org; Fri, 30 Jan 2004 13:36:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmdUI-00016h-00 for ipv6@ietf.org; Fri, 30 Jan 2004 13:35:30 -0500 Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx with esmtp (Exim 4.12) id 1AmdTv-0000z1-00 for ipv6@ietf.org; Fri, 30 Jan 2004 13:35:07 -0500 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id B08AC8B84; Fri, 30 Jan 2004 19:34:33 +0100 (CET) Received: from lolo (lolo.it.uc3m.es [163.117.139.223]) by smtp01.uc3m.es (Postfix) with SMTP id 9B1B081D1; Fri, 30 Jan 2004 19:34:33 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "Christian Huitema" , "Pekka Savola" Cc: , Subject: RE: ICMPv6: New destination unreachable codes Date: Fri, 30 Jan 2004 19:33:20 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > However, simply choosing an appropriate source address for > the ICMP message might help. > > In a site exit scenario, ingress filtering is performed either at the > ingress interface of a router, or at one of the exit interfaces on the > router. I suggest that the source address of the router's ICMP message > should be one of the global scope addresses associated to that specific > interface. This gives a strong hint to the host: among the source > addresses that can be tried, pick the one that is the best match for the > router's interface. very good point thanks, marcelo > > -- Christian Huitema > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Jan 30 13:45:02 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07799 for ; Fri, 30 Jan 2004 13:45:02 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Amdd5-0005MD-0a for ipv6-archive@odin.ietf.org; Fri, 30 Jan 2004 13:44:35 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0UIiYWt020587 for ipv6-archive@odin.ietf.org; Fri, 30 Jan 2004 13:44:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Amdd4-0005Ly-Qs for ipv6-web-archive@optimus.ietf.org; Fri, 30 Jan 2004 13:44:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07787 for ; Fri, 30 Jan 2004 13:44:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Amdd2-0002RI-00 for ipv6-web-archive@ietf.org; Fri, 30 Jan 2004 13:44:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Amdc9-0002JH-00 for ipv6-web-archive@ietf.org; Fri, 30 Jan 2004 13:43:37 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Amdbe-0002Ab-00 for ipv6-web-archive@ietf.org; Fri, 30 Jan 2004 13:43:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Amdba-0004un-TS; Fri, 30 Jan 2004 13:43:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Amdb5-0004tn-8e for ipv6@optimus.ietf.org; Fri, 30 Jan 2004 13:42:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07664 for ; Fri, 30 Jan 2004 13:42:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Amdb3-00026y-00 for ipv6@ietf.org; Fri, 30 Jan 2004 13:42:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmdaG-0001z0-00 for ipv6@ietf.org; Fri, 30 Jan 2004 13:41:40 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmdZJ-0001gw-00 for ipv6@ietf.org; Fri, 30 Jan 2004 13:40:41 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i0UIe6N28377; Fri, 30 Jan 2004 20:40:06 +0200 Date: Fri, 30 Jan 2004 20:40:06 +0200 (EET) From: Pekka Savola To: Christian Huitema cc: mbagnulo@ing.uc3m.es, , Subject: RE: ICMPv6: New destination unreachable codes In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 FWIW, I have no objection to specifying a new code, but I don't think adding a "working address" option is feasible or useful. On Fri, 30 Jan 2004, Christian Huitema wrote: > In a site exit scenario, ingress filtering is performed either at the > ingress interface of a router, or at one of the exit interfaces on the > router. I suggest that the source address of the router's ICMP message > should be one of the global scope addresses associated to that specific > interface. This gives a strong hint to the host: among the source > addresses that can be tried, pick the one that is the best match for the > router's interface. I believe that all router implementations pick the source address of the generated ICMP error messages based on the outgoing interface of the message: this would be toward the site's internal infrastructure, and would very likely include addresses from all the prefixes. So this would probably not help in this specific case, unless you want to make a specific exception (which might have some obvious problems). -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Jan 30 15:14:58 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13743 for ; Fri, 30 Jan 2004 15:14:58 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Amf26-00044M-1V for ipv6-archive@odin.ietf.org; Fri, 30 Jan 2004 15:14:30 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0UKETB2015635 for ipv6-archive@odin.ietf.org; Fri, 30 Jan 2004 15:14:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Amf25-000445-PL for ipv6-web-archive@optimus.ietf.org; Fri, 30 Jan 2004 15:14:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13663 for ; Fri, 30 Jan 2004 15:14:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Amf24-00002F-00 for ipv6-web-archive@ietf.org; Fri, 30 Jan 2004 15:14:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Amf19-0007hT-00 for ipv6-web-archive@ietf.org; Fri, 30 Jan 2004 15:13:32 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Amf0E-0007YY-00 for ipv6-web-archive@ietf.org; Fri, 30 Jan 2004 15:12:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Amezg-00033Z-9F; Fri, 30 Jan 2004 15:12:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmezH-0002xC-GK for ipv6@optimus.ietf.org; Fri, 30 Jan 2004 15:11:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13336 for ; Fri, 30 Jan 2004 15:11:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmezE-0007Pb-00 for ipv6@ietf.org; Fri, 30 Jan 2004 15:11:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmeyL-0007Hj-00 for ipv6@ietf.org; Fri, 30 Jan 2004 15:10:38 -0500 Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx with esmtp (Exim 4.12) id 1Amexc-00076u-00 for ipv6@ietf.org; Fri, 30 Jan 2004 15:09:52 -0500 Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 30 Jan 2004 12:08:39 -0800 Received: from 157.54.8.155 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 30 Jan 2004 12:09:21 -0800 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 30 Jan 2004 12:09:19 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Fri, 30 Jan 2004 12:09:26 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Fri, 30 Jan 2004 12:09:20 -0800 X-MIMEOLE: Produced By Microsoft Exchange V6.5.7165.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: ICMPv6: New destination unreachable codes Date: Fri, 30 Jan 2004 12:09:16 -0800 Message-ID: Thread-Topic: ICMPv6: New destination unreachable codes Thread-Index: AcPnYJLC3L4W5/M9QYukcyCC7whlEQAC/Clg From: "Christian Huitema" To: "Pekka Savola" Cc: , , X-OriginalArrivalTime: 30 Jan 2004 20:09:20.0075 (UTC) FILETIME=[F21989B0:01C3E76C] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > FWIW, I have no objection to specifying a new code, but I don't think > adding a "working address" option is feasible or useful. I understand that adding a new option is much harder than adding a new code point. I am fine with the new code point. > On Fri, 30 Jan 2004, Christian Huitema wrote: > > In a site exit scenario, ingress filtering is performed either at the > > ingress interface of a router, or at one of the exit interfaces on the > > router. I suggest that the source address of the router's ICMP message > > should be one of the global scope addresses associated to that specific > > interface. This gives a strong hint to the host: among the source > > addresses that can be tried, pick the one that is the best match for the > > router's interface. >=20 > I believe that all router implementations pick the source address of > the generated ICMP error messages based on the outgoing interface of > the message: this would be toward the site's internal infrastructure, > and would very likely include addresses from all the prefixes. >=20 > So this would probably not help in this specific case, unless you want > to make a specific exception (which might have some obvious problems). If the site is multi-addressed, the exit router link may or may not be multi-addressed. If it is not, then the global scope address probably matches the egress that the router is managing, and that is fine. If the router link happens to be multi-addressed, then it would be nice to pick the address that is most likely to match filtering. -- Christian Huitema -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Jan 30 15:25:00 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14723 for ; Fri, 30 Jan 2004 15:25:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmfBo-00064o-4e for ipv6-archive@odin.ietf.org; Fri, 30 Jan 2004 15:24:32 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0UKOWur023352 for ipv6-archive@odin.ietf.org; Fri, 30 Jan 2004 15:24:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmfBn-00064Z-Sw for ipv6-web-archive@optimus.ietf.org; Fri, 30 Jan 2004 15:24:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14719 for ; Fri, 30 Jan 2004 15:24:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmfBm-0001W9-00 for ipv6-web-archive@ietf.org; Fri, 30 Jan 2004 15:24:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmfAz-0001Ox-00 for ipv6-web-archive@ietf.org; Fri, 30 Jan 2004 15:23:42 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AmfAR-0001GN-00 for ipv6-web-archive@ietf.org; Fri, 30 Jan 2004 15:23:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmfAM-0005k2-5Y; Fri, 30 Jan 2004 15:23:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Amf9i-0005j3-K4 for ipv6@optimus.ietf.org; Fri, 30 Jan 2004 15:22:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14548 for ; Fri, 30 Jan 2004 15:22:20 -0500 (EST) From: Mukesh.Gupta@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Amf9h-0001Ak-00 for ipv6@ietf.org; Fri, 30 Jan 2004 15:22:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Amf8m-00013B-00 for ipv6@ietf.org; Fri, 30 Jan 2004 15:21:25 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1Amf7w-0000vV-00 for ipv6@ietf.org; Fri, 30 Jan 2004 15:20:32 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i0UKJwM14146 for ; Fri, 30 Jan 2004 22:20:29 +0200 (EET) Received: from daebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 30 Jan 2004 22:19:30 +0200 Received: from daebe009.NOE.Nokia.com ([10.241.35.109]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 30 Jan 2004 12:19:23 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: ICMPv6: New destination unreachable codes Date: Fri, 30 Jan 2004 14:19:22 -0600 Message-ID: <8D260779A766FB4A9C1739A476F84FA4015471B8@daebe009.americas.nokia.com> Thread-Topic: ICMPv6: New destination unreachable codes Thread-Index: AcPnYJLC3L4W5/M9QYukcyCC7whlEQAC/ClgAABM75A= To: , Cc: , X-OriginalArrivalTime: 30 Jan 2004 20:19:23.0137 (UTC) FILETIME=[598D7F10:01C3E76E] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable If I am not wrong, if we wanted the router to send the correct prefix to the host in the ICMP message, we will have to change the format of the ICMPv6 Destination Unreachable message. Currently, we just have 4 bytes unused in the message format and this prefix can't fit in there. So the question is: is it worth changing the format of the message for this optimization ?? Regards Mukesh > -----Original Message----- > From: ext Christian Huitema [mailto:huitema@windows.microsoft.com] > Sent: Friday, January 30, 2004 12:09 PM > To: Pekka Savola > Cc: mbagnulo@ing.uc3m.es; Gupta Mukesh (Nokia-NET/MtView);=20 > ipv6@ietf.org > Subject: RE: ICMPv6: New destination unreachable codes >=20 >=20 > > FWIW, I have no objection to specifying a new code, but I=20 > don't think > > adding a "working address" option is feasible or useful. >=20 > I understand that adding a new option is much harder than adding a new > code point. I am fine with the new code point. >=20 > > On Fri, 30 Jan 2004, Christian Huitema wrote: > > > In a site exit scenario, ingress filtering is performed either at > the > > > ingress interface of a router, or at one of the exit interfaces on > the > > > router. I suggest that the source address of the router's ICMP > message > > > should be one of the global scope addresses associated to that > specific > > > interface. This gives a strong hint to the host: among the source > > > addresses that can be tried, pick the one that is the=20 > best match for > the > > > router's interface. > >=20 > > I believe that all router implementations pick the source address of > > the generated ICMP error messages based on the outgoing interface of > > the message: this would be toward the site's internal=20 > infrastructure, > > and would very likely include addresses from all the prefixes. > >=20 > > So this would probably not help in this specific case,=20 > unless you want > > to make a specific exception (which might have some obvious=20 > problems). >=20 > If the site is multi-addressed, the exit router link may or may not be > multi-addressed. If it is not, then the global scope address probably > matches the egress that the router is managing, and that is=20 > fine. If the > router link happens to be multi-addressed, then it would be=20 > nice to pick > the address that is most likely to match filtering. >=20 > -- Christian Huitema >=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Jan 30 16:58:00 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06897 for ; Fri, 30 Jan 2004 16:58:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Amgdp-0004y5-2K for ipv6-archive@odin.ietf.org; Fri, 30 Jan 2004 16:57:33 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0ULvXgW019096 for ipv6-archive@odin.ietf.org; Fri, 30 Jan 2004 16:57:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Amgdo-0004xv-Rg for ipv6-web-archive@optimus.ietf.org; Fri, 30 Jan 2004 16:57:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06248 for ; Fri, 30 Jan 2004 16:57:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Amgdm-0006Br-00 for ipv6-web-archive@ietf.org; Fri, 30 Jan 2004 16:57:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Amgco-00061v-00 for ipv6-web-archive@ietf.org; Fri, 30 Jan 2004 16:56:30 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Amgbt-0005u1-00 for ipv6-web-archive@ietf.org; Fri, 30 Jan 2004 16:55:33 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1Amgbs-0001uw-AJ for ipv6-web-archive@ietf.org; Fri, 30 Jan 2004 16:55:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmgbQ-0004UF-F2; Fri, 30 Jan 2004 16:55:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Amgao-0004R5-KV for ipv6@optimus.ietf.org; Fri, 30 Jan 2004 16:54:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02509 for ; Fri, 30 Jan 2004 16:54:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Amgam-0005ij-00 for ipv6@ietf.org; Fri, 30 Jan 2004 16:54:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmgZo-0005X9-00 for ipv6@ietf.org; Fri, 30 Jan 2004 16:53:25 -0500 Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx with esmtp (Exim 4.12) id 1AmgYw-0005Eg-00 for ipv6@ietf.org; Fri, 30 Jan 2004 16:52:30 -0500 Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 30 Jan 2004 13:52:01 -0800 Received: from 157.54.8.23 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 30 Jan 2004 13:51:59 -0800 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 30 Jan 2004 13:52:34 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 30 Jan 2004 13:51:59 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Fri, 30 Jan 2004 13:51:55 -0800 X-MIMEOLE: Produced By Microsoft Exchange V6.5.7165.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: ICMPv6: New destination unreachable codes Date: Fri, 30 Jan 2004 13:51:54 -0800 Message-ID: Thread-Topic: ICMPv6: New destination unreachable codes Thread-Index: AcPnYJLC3L4W5/M9QYukcyCC7whlEQAC/ClgAABM75AAA1mPAA== From: "Christian Huitema" To: , Cc: , X-OriginalArrivalTime: 30 Jan 2004 21:51:55.0217 (UTC) FILETIME=[46D9AC10:01C3E77B] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > If I am not wrong, if we wanted the router to send the correct > prefix to the host in the ICMP message, we will have to change > the format of the ICMPv6 Destination Unreachable message. >=20 > Currently, we just have 4 bytes unused in the message format and > this prefix can't fit in there. >=20 > So the question is: is it worth changing the format of the message > for this optimization ?? Probably not. Having the proper code is a really nice first step. -- Christian Huitema -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Jan 30 20:06:11 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28513 for ; Fri, 30 Jan 2004 20:06:10 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmjZu-0006Hc-74 for ipv6-archive@odin.ietf.org; Fri, 30 Jan 2004 20:05:42 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0V15gDG024152 for ipv6-archive@odin.ietf.org; Fri, 30 Jan 2004 20:05:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmjZu-0006HT-0K for ipv6-web-archive@optimus.ietf.org; Fri, 30 Jan 2004 20:05:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28025 for ; Fri, 30 Jan 2004 20:05:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmjZs-0007gp-00 for ipv6-web-archive@ietf.org; Fri, 30 Jan 2004 20:05:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmjXG-00074C-00 for ipv6-web-archive@ietf.org; Fri, 30 Jan 2004 20:03:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AmjVN-0006bK-00 for ipv6-web-archive@ietf.org; Fri, 30 Jan 2004 20:01:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmjUX-0005oJ-Ct; Fri, 30 Jan 2004 20:00:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmjU3-0005mb-Dy for ipv6@optimus.ietf.org; Fri, 30 Jan 2004 19:59:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22385 for ; Fri, 30 Jan 2004 19:59:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmjU1-0006Np-00 for ipv6@ietf.org; Fri, 30 Jan 2004 19:59:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmjT8-0006HC-00 for ipv6@ietf.org; Fri, 30 Jan 2004 19:58:43 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AmjSV-00066a-00 for ipv6@ietf.org; Fri, 30 Jan 2004 19:58:03 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i0V0vV411402; Fri, 30 Jan 2004 16:57:31 -0800 X-mProtect: <200401310057> Nokia Silicon Valley Messaging Protection Received: from walnut2.iprg.nokia.com (205.226.9.199, claiming to be "spruce.nokia.com") by darkstar.iprg.nokia.com smtpd3bnoEB; Fri, 30 Jan 2004 16:57:29 PST Message-Id: <4.3.2.7.2.20040130163401.031c1a08@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 30 Jan 2004 16:54:24 -0800 To: Christian Huitema From: Bob Hinden Subject: RE: ICMPv6: New destination unreachable codes Cc: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Christian, >Probably not. Having the proper code is a really nice first step. I agree. To respond to some of the other discussion, the purpose of the new codes was to provide more feedback to address selection. As I think Pekka said in an earlier discussion, relying on transport layer timeouts to get this feedback is not a good idea. I think for all of the new destination unreachable codes, if the source node has only a few addresses to choose from this feedback will very useful as there won't be many alternatives to try. If the source node has many addresses to try, then it is less beneficial. However, I don't think the latter is likely to be the case in common practice. Overall I think that providing this additional feedback is useful and I don't think it does any harm. The ICMP destination unreachable messages are a SHOULD so the router has considerable choice if it wants to send them or not. Bob -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sat Jan 31 05:21:25 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16046 for ; Sat, 31 Jan 2004 05:21:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmsFF-000571-GS for ipv6-archive@odin.ietf.org; Sat, 31 Jan 2004 05:20:58 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0VAKvKi019648 for ipv6-archive@odin.ietf.org; Sat, 31 Jan 2004 05:20:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmsFF-00056p-84 for ipv6-web-archive@optimus.ietf.org; Sat, 31 Jan 2004 05:20:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16040 for ; Sat, 31 Jan 2004 05:20:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmsFB-0003OR-00 for ipv6-web-archive@ietf.org; Sat, 31 Jan 2004 05:20:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmsEH-0003Hy-00 for ipv6-web-archive@ietf.org; Sat, 31 Jan 2004 05:19:58 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AmsDy-0003BS-00 for ipv6-web-archive@ietf.org; Sat, 31 Jan 2004 05:19:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmsDO-0004q6-03; Sat, 31 Jan 2004 05:19:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmsDH-0004pZ-Gv for ipv6@optimus.ietf.org; Sat, 31 Jan 2004 05:18:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15960 for ; Sat, 31 Jan 2004 05:18:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmsDE-0003AV-00 for ipv6@ietf.org; Sat, 31 Jan 2004 05:18:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmsCL-000343-00 for ipv6@ietf.org; Sat, 31 Jan 2004 05:17:58 -0500 Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx with esmtp (Exim 4.12) id 1AmsBm-0002vJ-00 for ipv6@ietf.org; Sat, 31 Jan 2004 05:17:22 -0500 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id E3F8D8A68; Sat, 31 Jan 2004 11:16:52 +0100 (CET) Received: from lolo (vpn-252-71.uc3m.es [163.117.252.71]) by smtp01.uc3m.es (Postfix) with SMTP id 4F8398A6E; Sat, 31 Jan 2004 11:16:51 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: , , Cc: Subject: RE: ICMPv6: New destination unreachable codes Date: Sat, 31 Jan 2004 11:15:37 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <8D260779A766FB4A9C1739A476F84FA4015471B8@daebe009.americas.nokia.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit IMHO, it is possible that a multihoming solution will end up requiring a message that informs the host about the correct address to use. It would be good if we didn't have to define an additional message for this and we could just use this one. I think that Christian's proposal doesn't change the packet format, since the router just has to be smart enough to pick the right source address. So all that it is needed is to state that the router has to pick one of its own addresses that its ingress filters would allow to flow towards the selected destination. I fail to see why do you think this is not feasible Regards, marcelo > -----Mensaje original----- > De: Mukesh.Gupta@nokia.com [mailto:Mukesh.Gupta@nokia.com] > Enviado el: viernes, 30 de enero de 2004 21:19 > Para: huitema@windows.microsoft.com; pekkas@netcore.fi > CC: mbagnulo@ing.uc3m.es; ipv6@ietf.org > Asunto: RE: ICMPv6: New destination unreachable codes > > > If I am not wrong, if we wanted the router to send the correct > prefix to the host in the ICMP message, we will have to change > the format of the ICMPv6 Destination Unreachable message. > > Currently, we just have 4 bytes unused in the message format and > this prefix can't fit in there. > > So the question is: is it worth changing the format of the message > for this optimization ?? > > Regards > Mukesh > > > -----Original Message----- > > From: ext Christian Huitema [mailto:huitema@windows.microsoft.com] > > Sent: Friday, January 30, 2004 12:09 PM > > To: Pekka Savola > > Cc: mbagnulo@ing.uc3m.es; Gupta Mukesh (Nokia-NET/MtView); > > ipv6@ietf.org > > Subject: RE: ICMPv6: New destination unreachable codes > > > > > > > FWIW, I have no objection to specifying a new code, but I > > don't think > > > adding a "working address" option is feasible or useful. > > > > I understand that adding a new option is much harder than adding a new > > code point. I am fine with the new code point. > > > > > On Fri, 30 Jan 2004, Christian Huitema wrote: > > > > In a site exit scenario, ingress filtering is performed either at > > the > > > > ingress interface of a router, or at one of the exit interfaces on > > the > > > > router. I suggest that the source address of the router's ICMP > > message > > > > should be one of the global scope addresses associated to that > > specific > > > > interface. This gives a strong hint to the host: among the source > > > > addresses that can be tried, pick the one that is the > > best match for > > the > > > > router's interface. > > > > > > I believe that all router implementations pick the source address of > > > the generated ICMP error messages based on the outgoing interface of > > > the message: this would be toward the site's internal > > infrastructure, > > > and would very likely include addresses from all the prefixes. > > > > > > So this would probably not help in this specific case, > > unless you want > > > to make a specific exception (which might have some obvious > > problems). > > > > If the site is multi-addressed, the exit router link may or may not be > > multi-addressed. If it is not, then the global scope address probably > > matches the egress that the router is managing, and that is > > fine. If the > > router link happens to be multi-addressed, then it would be > > nice to pick > > the address that is most likely to match filtering. > > > > -- Christian Huitema > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sat Jan 31 10:10:34 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24129 for ; Sat, 31 Jan 2004 10:10:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Amwl3-0006WT-0j for ipv6-archive@odin.ietf.org; Sat, 31 Jan 2004 10:10:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0VFA4rF025061 for ipv6-archive@odin.ietf.org; Sat, 31 Jan 2004 10:10:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Amwl1-0006Vp-I4 for ipv6-web-archive@optimus.ietf.org; Sat, 31 Jan 2004 10:10:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24086 for ; Sat, 31 Jan 2004 10:10:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Amwkz-00051j-00 for ipv6-web-archive@ietf.org; Sat, 31 Jan 2004 10:10:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Amwk1-0004vD-00 for ipv6-web-archive@ietf.org; Sat, 31 Jan 2004 10:09:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AmwjV-0004pc-00 for ipv6-web-archive@ietf.org; Sat, 31 Jan 2004 10:08:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Amwj7-0005kc-38; Sat, 31 Jan 2004 10:08:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Amwi9-0005N7-Jq for ipv6@optimus.ietf.org; Sat, 31 Jan 2004 10:07:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23841 for ; Sat, 31 Jan 2004 10:07:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Amwi7-0004ia-00 for ipv6@ietf.org; Sat, 31 Jan 2004 10:07:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmwhC-0004ci-00 for ipv6@ietf.org; Sat, 31 Jan 2004 10:06:07 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1Amwgi-0004Vw-00 for ipv6@ietf.org; Sat, 31 Jan 2004 10:05:37 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i0VF50l17011; Sat, 31 Jan 2004 17:05:00 +0200 Date: Sat, 31 Jan 2004 17:05:00 +0200 (EET) From: Pekka Savola To: marcelo bagnulo cc: Mukesh.Gupta@nokia.com, , Subject: RE: ICMPv6: New destination unreachable codes In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Sat, 31 Jan 2004, marcelo bagnulo wrote: > I think that Christian's proposal doesn't change the packet format, since > the router just has to be smart enough to pick the right source address. > > So all that it is needed is to state that the router has to pick one of its > own addresses that its ingress filters would allow to flow towards the > selected destination. These kind of statements do not belong in the ICMPv6 spec. > I fail to see why do you think this is not feasible Simply because that's not how routers select addresses for ICMP errors they send. They take an address from the interface which is used for the outgoing packet. And that in itself doesn't really help anything. Now -- at least one vendor allows you to choose the "preferred" [nothing to do with the ND spec term] address on each interface, if there are multiple ones. Setting the ingress-wise correct address preferred on the interface towards the site's infrastructure will give the "ingress-wise" correct source address to the ICMP error message. But this is just an operational procedure, which needs to be stated in the multihoming solution documents, but something that IMHO must not be added to the ICMPv6 spec, as it's really out of scope from ICMP perspective. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sat Jan 31 16:09:44 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05379 for ; Sat, 31 Jan 2004 16:09:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1An2Md-0002HI-S5 for ipv6-archive@odin.ietf.org; Sat, 31 Jan 2004 16:09:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0VL9FXV008752 for ipv6-archive@odin.ietf.org; Sat, 31 Jan 2004 16:09:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1An2Md-0002H5-Js for ipv6-web-archive@optimus.ietf.org; Sat, 31 Jan 2004 16:09:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05334 for ; Sat, 31 Jan 2004 16:09:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1An2Mc-0005nl-00 for ipv6-web-archive@ietf.org; Sat, 31 Jan 2004 16:09:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1An2Li-0005gn-00 for ipv6-web-archive@ietf.org; Sat, 31 Jan 2004 16:08:18 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1An2L0-0005Zh-00 for ipv6-web-archive@ietf.org; Sat, 31 Jan 2004 16:07:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1An2KV-0001gZ-K3; Sat, 31 Jan 2004 16:07:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1An2Ji-0001fS-DF for ipv6@optimus.ietf.org; Sat, 31 Jan 2004 16:06:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05220 for ; Sat, 31 Jan 2004 16:06:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1An2Jg-0005SF-00 for ipv6@ietf.org; Sat, 31 Jan 2004 16:06:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1An2Ip-0005Mj-00 for ipv6@ietf.org; Sat, 31 Jan 2004 16:05:20 -0500 Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx with esmtp (Exim 4.12) id 1An2I0-0005A1-00 for ipv6@ietf.org; Sat, 31 Jan 2004 16:04:28 -0500 Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sat, 31 Jan 2004 13:03:49 -0800 Received: from 157.54.6.150 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Sat, 31 Jan 2004 13:04:02 -0800 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sat, 31 Jan 2004 13:03:56 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sat, 31 Jan 2004 13:03:57 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Sat, 31 Jan 2004 13:04:01 -0800 X-MIMEOLE: Produced By Microsoft Exchange V6.5.7165.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: ICMPv6: New destination unreachable codes Date: Sat, 31 Jan 2004 13:03:49 -0800 Message-ID: Thread-Topic: ICMPv6: New destination unreachable codes Thread-Index: AcPoC5hYsuV2yWhKRWeCTg37cTOmTAAMHxgQ From: "Christian Huitema" To: "Pekka Savola" , "marcelo bagnulo" Cc: , X-OriginalArrivalTime: 31 Jan 2004 21:04:01.0971 (UTC) FILETIME=[C0ACE030:01C3E83D] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > But this is just an operational procedure, which needs to be stated in > the multihoming solution documents, but something that IMHO must not > be added to the ICMPv6 spec, as it's really out of scope from ICMP > perspective. I agree with Pekka. The purpose of the ICMPv6 document is to reserve the code and define the format. As Marcelo said, the MH code can work with this code and format. Let's just go with it. I understand Marcelo's concern. He (and I) would like to make life as good as possible for hosts in multi-homed sites. This will require operational rules for hosts and for routers. As I mentioned in a previous message, the code definition is a nice first step. It tells the host that it should try another source address. It is only a first step, because it does not tell which one. The host will have to use some heuristic. In some cases, e.g. when there are just two addresses, the heuristic is trivial. In more complex cases, having more information might help. But it may be a bit early to determine how this information should be passed. We could pass it in ICMP messages, but we could just as well use a yet-to-be-defined information protocol associating exit routers with allowed prefixes, or even let hosts use some cached knowledge from previous connections. Given the wide choices, I would rather not try to mess around with the ICMPv6 specification. -- Christian Huitema -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------