[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ICMPv6: Rate Limiting Configuration Per-Node or Per-Interfaces

On Fri, 20 Aug 2004, Brian Haberman wrote:
> >     (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.
> I don't agree with this last addition.  Rate-limiting transit ICMP
> traffic is useful in several ways.  One key area for rate-limiting
> in routers is when ICMP messages are sent in response to multicast
> data packets.
> Putting this in a separate document seems like a waste of time.  It
> would be a section in the ICMP spec as it relates to rate-limiting.

But multicast data packets are already rate-limited by the senders,
the same way as unicast!  Or do you want to set more aggressive limits
to multicast packets?

I don't think anyone disagrees that rate-limiting transiting ICMP 
packets might be beneficial especially under certain situations.

The issue just is that it's an *operational* decision, not a 
*protocol* decision.  Every operator is likely to have entirely 
different set of requirements.  I know a large number of them which 
*do not* want to rate-limit anything -- they just want to forward the 
packets, and that's it.  Likewise, even if some would not object to 
preferring it, there could be no agreement on the exact values, and 
having to configure the values on all your routers (or disable the 
limiting if you don't want it) takes a lot of time.

And what does rate-limiting in transit help?  People can just send
ICMP echo replys/request or other informational ICMP messages instead
which wouldn't be rate-limited: it doesn't seem to protect from

The fact is, that there are dozens of protocols out there that are not
rate-limited *in transit* by the protocol specification -- in fact, I
can't recall even one such protocol!  I.e., rate-limiting transit
traffic is an operational procedure, not a protocol procedure.  IMHO,
protocol specs have no business specifying what happens to the packets
when they're forwarded: the packets are just plain IP.

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
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6