http://www.NetBSD.org/cgi-bin/query-pr-single.pl?number=4827

	The problem still exists (not sure if the kernel panics, but we can
	have bogus routing table entry easily).  The step to repeat
	the problem is like this:

	- let us assume that, my machine is on 10.0.0.2/24, exit router is
	  at 10.0.0.1.
		# ifconfig if0 10.0.0.2 netmask 0xffffff00
		# route add default 10.0.0.1
	- have a host route to 10.0.0.3, with gateway set to 10.0.0.1.
		# route add 10.0.0.3 10.0.0.1
		# netstat -rn |grep 10.0.0.3
		10.0.0.3 10.0.0.1  UGHS        0        0   1500  if0
	- if we generate outgoing packet to 10.0.0.3, we will get an ICMPv4
	  redirect packet.  the packet will cause the routing entry to get
	  updated by rtredirect().  you will get the following routing
	  entry as a result:
		10.0.0.3 10.0.0.3  UGHMS       1        1   1500  if0
	  the entry will prevent us from adding ARP cache entry, for example.
		arpresolve: can't allocate llinfo on if0 for 10.0.0.3

	now, what should we do?
	1. ignore icmp redirect if we have RTF_HOST|RTF_STATIC entry.
	   it will not cause the entry to get updated, and can cause
	   lots of icmp redirects.  but since it is the root user who asked
	   for the entry, maybe the kernel shouldn't modify it.
	2. if the rt_key is going to be equal to rt_gateway, remove the routing
	   entry once and see if cloning behavior (by interface route)
	   effectively generates the new entry.  not sure if it is correct.
	   also, if we configure the interface with incorrect netmask
	   (one that does not meet the router's configuration) we will see
	   strange behavior.
	3. ignore icmp redirect if rt_key and rt_gateway will become the same
	   value.  similar to (1), but a bit different approach.

	I believe no other *BSDs addressed this issue.

itojun