> The traditional incrementing IP id code was recently replaced (without
> discussion) with an OpenBSD-derived pseudo-random IP id.
> 
> This change was made despite the relatively recent discussion of the
> technical issue, in which most (if not all) the following points came up:
> 
>  * Its not  clear to all of us that the "vulerability" to DNS requests
>    is widespread,[    or that randomizing the ip_id is the best way to close it.

	randomizing IP fragment ID field is independent from attacks against
	DNS ID field.  therefore the discussion on DNS ID field has nothing
	with randomizing IP fragment field.

>  * There are environments where the computational cost does not justify
>   deploying this fix.

	true.

>  * There are environments where the downside of reducing the (already small)
>    ip_id space overwhelms the alleged security gains.

	reducing?  with ip_randomid(), the *guaranteed minimum* interval between
	the generation of the same output value is 36000 calls.
	even after 36000 calls, it is highly unlikely that we see the same
	number generated from ip_randomid().  if you have concrete number
	please show me.

> I therefore intend to to make randomisation of the IP id field be a
> config-time option. Personally I beleive the default should be to not
> randomize; though i amo open to other suggestions, such as making it
> sysctl'able (changeable at low security levels), with an
> inline-function to make the test and (if using increment) return the
> increnemted global; otherwise do a full function call to get a
> pseudo-random IP id.

	as long as the default is to use ip_randomid(), i'm okay with having
	sysctl for it.  (our prefence to ship things secure by default)

itojun