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