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
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=10,
N=10/s.
===================================================
Regards
Mukesh
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
