>But, when the IP-address I try to steal is from a machine that is
>configured as an IPv6 router, the host does send out a neighbour
>solicitation for that address (to the solicited-nodes multicast
>address; i.e. :: > ff02::1:ff00:2: icmp6: neighbor sol: who has...),
>but the router never replies that it actually uses that address. This
>results in (semi-)successful theft of the address, in that the thief 
>configures the address to its interface (without the duplicated tag).
>`semi' because normally the neighbour discovery cache still has the
>entry for the real owner (the router), whcih does not get overwritten.

	the last part of the above is separate story, i believe.  first
	let us concentrate to DAD issues.

>It looks to me that this is because the router doesn't listen to the
>Solicited-Node Multicast, however it does reply to pings to that
>address.

	we do have tested DAD tons of times, including during TAHI
	conformance tests, and I'm convinced it works fine.

	first of all, what kind of ethernet card are you using?  some of the
	ethernet card comes with broken multicast packet filter (or broken
	driver).

	next, a little bit of spec issue.  we run DAD right after interface
	initialization.  some of the ethernet cards need more than seconds to
	finish its initialization.  as IPv6 layer has no way to know if the
	interface initialization is really done, DAD can be invoked before
	interface gets ready, and sometimes DAD packet will not go out,
	or thief cannot receive DAD response from victim.

	also, could you please make sure to diagnose the following:
	- during the test, DO NOT run tcpdump on victim nor the thief.
	  by running tcpdump the interface behavior will be changed (due to
	  promiscuous mode).  run tcpdump on other node.
	- are you sure that the router is not listening to the solicited
	  node multicast address? (if it is really true, your router will
	  have problem runing ND) see the result of ifmcstat(8).  also,
	  check if you see number increase in IPv6 counters (netstat -sn)
	  during DAD session.

>Another thing that seems not quite right to me, is that when I delete
>an IPv6 address from an interface, it's corrosponding (permanent)
>entry in the neighbour discovery cache is not deleted. I need to use
>ndp -d to get rid of it. Shouldn't the kernel or ifconfig take care of
>this? (This is both on NetBSD-current and 1.5).

	this was fixed in KAME tree already (with newer interface address
	removal handling in sys/netinet6/in6.c), this is not integrated
	into netbsd 1.5 nor netbsd-current yet.  the new code changes some of
	reference counting code, and i (or we) would like to be very sure that
	the new code works fine for all cases.

itojun