>> 	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.
>Do not think this is relevant in my case, unless I misunderstand what
>you mean, as the interfaces are already completely up and running. I
>*add* a manually configured address (the one to steal) with ifconfig
>inet6 ... alias. The interface is at that point already happily up and
>running with its auto-configured address.

	thief machine will need to update its multicast filter on interface
	address addition.  if the ethernet interface (on thief) need long
	period of time to get initialized, thief machine may miss the DAD
	reply from victim.

>> 	- 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.
>Ah! didn't know ifmcstat. quite useful, thanks. It shows it is
>listening to the solicited node multicast (also indicated by pinging
>to it). I've never seen problems with any of these machines with
>`normal' neighbour discovery or router discovery. Just this special
>case of a host trying to steal a router's address.

	there's no difference between router and host regarding to DAD.

>> 	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.
>Ok, fine. Whould be nice to have in 1.5 though. Hope that's not too
>late (it's nice for my laptop wandering between three nets on a
>regular basis, and doesn't use mobile-IP (not in NetBSD yet).

	it is way too late for major kernel changes like this.
	the only case you will have problem is:
	- your machine X uses an address A
	- X moved to some other subnet, now A is not yours
	- some other machine Y comes to the original subnet, and gets A again
	- X may have problem talking with Y
	but because of the way we do stateless autoconfiguration, the 3rd
	bullet is close to impossible.

>****
>New tcpdump results are as follows:

	please do not describe, please just attach the dump.  please have
	"-evv" flag on tcpdump so that we can know who is the real sender
	of the packet.

>This indicates I think that the problem is slightly more subtle than
>`multicast in this driver doesn't work'. However I have no clue what
>it might be. 

	or, a broken switch/hub.

itojun