On Wed, 18 Aug 2004 [EMAIL PROTECTED] wrote:
> I think everyone agrees that per-interface configuration
> would be a perfect solution and will provide a fine grained
> control to the user. Is there anyone who disagrees with
> this ? (Pekka ??)
My objection to this stems from the fact that an implementation which
would like to do something like that is likely doing something wrong
in the first place (or something which is implementation-specific in
any case, and doesn't need "IETF blessing" for their approach in any
case), and I slightly disagree with per-interface configuration.
Obviously, implementors can provide whatever mechanisms they want,
even those not mentioned by the specification, so even if we don't
mention it at all, it would be OK to implement it.
Rather than first figuring out whether to use MAY or SHOULD it might
be better to try to figure how to reword the section etc. to be more
specific about the recommended method and where it applies to.
This could possibly be achived by changing "send" to "originate"
elsewhere in the spec, and reword (f) to something like:
====
(f) Finally, an IPv6 node MUST limit the rate of ICMPv6 error
messages it originates in order to limit the processing at the
node and bandwidth and forwarding costs incurred on the
network by originating ICMPv6 error messages. This
situation may occur when a source sending a stream of erroneous
packets fails to heed the resulting ICMPv6 error messages.
Rate-limiting of forwarded ICMP messages is out of scope of this
specification.
A recommended method for implementing the rate-limiting function
is a token bucket, limiting the average rate of transmission to
N packets/second, but allowing up to B error messages
to be originated 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; 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.
====
- make it clearer that the justification is also to limit the
processing on the node
- add note of non-scope of generic rate-limiting (this is also so
obvious that 2nd paragraph could possibly be removed now)
- just specify packets/second in the recommended token bucket
rate-limiter to avoid confusion with interface-specific issues. Note
that as this is just a recommended *EXAMPLE*, it's fully compliant
with the spec to provide another kind of rate-limiter as well, hence
bandwidth-based measurements don't belong here (and haven't been even
really implemented -- all the vendors I know of do pps + burst)!
> In your opinion (no reasoning please), the rate limiting
> configuration per-interface in the ICMPv6 spec should be a
>
> 1) SHOULD
> 2) MAY
> 3) Any of them is fine for you.
MAY.
Or just leave it out completely (prefable, as with Jinmei's initial
message), but that wasn't the option. :)
--
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
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
