Subject: RE: draft-ietf-ipngwg-icmp-v3-02.txt: Rate Limiting Methods

From: [email-masked]
Date: Wed, 7 Jan 2004 11:34:21 -0600

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).
> 
> 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 
problem i.e. it breaks traceroute.

Regards
Mukesh

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Bob Hinden <[email-masked]>
Date: Wed, 07 Jan 2004 15:03:10 -0800

Mukesh,

>"There are a variety of ways of implementing the rate-limiting function,

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.

>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

---

From: Tim Chown <[email-masked]>
Date: Thu, 8 Jan 2004 23:29:43 +0000

> build a rate-limiting function that is appropriate for their implementation.

This sounds good.

Tim