> > This does of course not prevent an equipment vendor to provide > > and an administrator to configure his router to defend against > > the situation in his network by implementing an optional rate > > limiter on an interface. > > If the router has traffic management per interface, and many if > not most nowadays do, the ICMP traffic shaping is not different > than shaping any other traffic.
True. > > Such a rate limiter should of course be > > different from the rate limiter used for locally originated > > traffic. > > Why should? Because one should (I'd say MUST) differentiate between shaping locally originated ICMP datagrams and forwarded ICMP datagrams (the latter which should be outside the scope of this spec, per Pekka's latest text which I agree with). > If the router implements ICMP rate limiting per interface, > without any differentiation between local ICMP and forwarded > ICMP the effect is still the same, and none need call the ICMP > protocol police (-:. I disagree. If origination of ICMP is vital to some function or other (it would be for PMTUD in IPv4), a host could spew ICMP messages to be forwarded and prevent or significantly hamper a router along the path from originating any ICMP traffic of it's own if both the forwarded and the originating traffic uses the same rate limiter, and the originated rate exceeds the rate specified by the rate limiter. > Who cares that the process may incure dropping some internally > generated ICMP messages? See above. Regards, - Håvard -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
