>2. I agree with jhawk: the current state is symptomatic of a design flaw.   
>   i think we should fix it.

	which part is a design flaw?  jhawk raised couple of issues, including
	lack of type-based rate limiting (which i still not 100% convinced),
	N event per M second interface, and minimal-interval only icmp{,6}
	filter.

>3.   If we are going to do rate limiting, let's do it properly:
>     define a leaky-bucket filter, with maximum-depth
>     and fill-rate parameters, scaled by hz; and perhaps with a
>     scale-factor argument.

	we can integrate ALTQ (alternate queueing framework,
	http://www.csl.sony.co.jp/person/kjc/) if we all agree.  we don't need
	to do it from scratch.  we still need to figure out how we can
	use ALTQ for icmp{,6} rate limitation (how to configure, or how
	we should modify it).

itojun