Suppress and limit errors

An otherwise required error still has to pass the general suppression and rate gates.

• An ICMPv6 error MUST NOT be originated in response to another ICMPv6 error or an ICMPv6 Redirect (§2.4(e.1–e.2)). Informational and error classes are not interchangeable. This stops error-on-error loops.
• Errors MUST NOT normally respond to IPv6 multicast destinations, link-layer multicast, or link-layer broadcast (§2.4(e.3–e.5)). Exceptions are Packet Too Big and Parameter Problem Code 2 for an unrecognized option whose highest two Option Type bits are 10. An unknown option with different action bits does not automatically qualify.
• A packet source that does not uniquely identify one node MUST NOT trigger an error: examples are unspecified, multicast or an address known to the originator to be anycast (§2.4(e.6)). Multicast exceptions do not override this source restriction or the error-on-error ban.
• A node MUST limit the rate of ICMPv6 errors it originates (§2.4(f)). Rate-limiting forwarded ICMP messages is out of scope. A token bucket is a recommended method, not a mandated algorithm. Parameters SHOULD be configurable and permit bursts; B=10/N=10 per second are example possible defaults, not universal requirements.
• The drawing chooses a smaller illustrative bucket B=2 with N=1 token/second. Two available tokens permit a two-error burst, then the rate gate suppresses another immediate error until credit refills. This does not define a required clock, timer or deployed parameter.
• §2.4 explicitly gives these restrictions precedence over other origination requirements. Not receiving an error does not prove the original packet succeeded, or that the network is silent for only one reason.