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 source by using even the token-bucket based method ? Regards Mukesh -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of ext Fred Templin Sent: Wednesday, January 07, 2004 6:00 AM To: Savolainen Teemu (Nokia-TP/Tampere); [EMAIL PROTECTED] 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 [EMAIL PROTECTED] [EMAIL PROTECTED] 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of ext > Margaret Wasserman > Sent: 07 January, 2004 04:06 > To: Gupta Mukesh (Nokia-NET/MtView) > Cc: [EMAIL PROTECTED] > 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 > [EMAIL PROTECTED] > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------