I'm running into the same problem described in PR15662, though I
can reproduce the behavior with a simpler setup.  I believe that
the code Christos committed to fix this problem should be fixed,
not backed out.

--------------------------------------------------------------------------------
Problem:
	<boot into single user mode>
	sh$ ifconfig <etherifcN> 192.168.167.127
	sh$ ping 192.168.167.1	# some host on the local subnet
	sh$ ifconfig <etherifcN> 192.168.100.200
	sh$ ping 192.168.167.1	# same host as the first time

	Using a packet sniffer (tcpdump works fine), notice that the ping
	packets are being sent with a source address of 192.168.167.127
	(the original interface address), even though no such interface address
	exists any longer.

Release:
	I'm running NetBSD 1.5, but I also tried the NetBSD 1.6 installation
	boot floppies to see if this problem still occurs there, and it
	does indeed.

netstat -nr shows a "UHL" entry for 192.168.167.1, which automatically
showed up after I did the first ping.  I guess this routing table
entry is where the the source address is coming from, even though
netstat shows no indication of this.

According to the commit message from itojun when the code was backed
out:

	> CVS log for src/sys/netinet/in.c  Revision 1.76
	>
	> backout 1.72.  it is not correct for the kernel to remove routes
	> by itself, and the code was buggy (dereferenced null pointer when
	> IFAFREE removes the route).

Other than backing it out because it was buggy, I am not clear on
why the kernel is not *required* to remove routes which no longer
make any sense.

When an interface address is removed or changed, I don't think that
any more packets should exit the box stamped with that source
address.  This problem is clearly in the domain of the kernel to
rectify.  Those routes no longer make sense, and userland apparently
has no knowledge of which source address the kernel is going to
stamp into the outgoing packet.

-Tad