I did a test of DAD (actually, what I was really doing was getting
tcpdump output of DAD occurring, to use in an example).

The tests ran on two (essentially identical) 1.6U kernels (from almost
at the end of May) on i386 based systems (both with 3c905 type ethernet
controllers on a very idle link).

This is what tcpdump tells me (with line wraps inserted manually
for readability, and blank lines between packets)

13:15:01.869365
	0:10:5a:76:e9:b4 33:33:ff:ad:be:ef 86dd 86:
	fe80::210:5aff:fe76:e9b4 > ff02::1:ffad:beef:
		HBH (padn)(rtalert: 0x0000)
		icmp6: multicast listener report
			max resp delay: 0
			addr: ff02::1:ffad:beef
	[hlim 1] (len 32)


13:15:01.869708
	0:10:5a:76:e9:b4 33:33:ff:ad:be:ef 86dd 78:
	:: > ff02::1:ffad:beef:
		icmp6: neighbor sol: who has fe80::dead:beef
	(len 24, hlim 255)


13:15:01.869761
	0:6:5b:da:45:ad 33:33:0:0:0:1 86dd 86:
	fe80::dead:beef > ff02::1:
		icmp6: neighbor adv: tgt is fe80::dead:beef
			(O)
			(tgt lladdr: 00:06:5b:da:45:ad)
	(len 32, hlim 255)


13:15:04.467898
	0:10:5a:76:e9:b4 33:33:ff:ad:be:ef 86dd 86:
	fe80::210:5aff:fe76:e9b4 > ff02::1:ffad:beef:
		HBH (padn)(rtalert: 0x0000)
		icmp6: multicast listener report
			max resp delay: 0
			addr: ff02::1:ffad:beef
	[hlim 1] (len 32)


OK, there were just two nodes (and a 100% IPv6 unaware hub/switch thing)
on the LAN at the time.   I'll call those two nodes b4 and ad (the last
octet of their MAC addresses).

Both nodes were running IPv6, both had (EUI-64 based) LL addresses
configured on the link.   Both work fine for IPv6 (including link
scope multicast at least).   There was no IPv6 router existing on the
LAN at the time (not that that should make any difference for this).

I had (a little earlier) configured the LL address "fe80::dead:beef" on
node "ad" - that went through the DAD cycle, found no conflicts, and
configured the address on the interface.

The 4 packets above some from an attempt (I had assumed before doing it,
an attempt doomed to fail) to configure the same address (fe80::dead:beef)
on node "b4".

The 4 packets above are

	MLD listener report.   That one is correct, that is "b4" joining
	the multicast group that corresponds to the "fe80::dead:beef"
	address, as the first step of setting that up as a tentative address.

	DAD probe for the tentative address, sent to the correct IPv6
	and MAC multicast addresses (correctly from the unspecified IPv6
	address).

	NA reply in response - node "ad" saying "that is my address, you
	can't have it" - correctly multicast to the "all nodes" (link scope)
	multicast address as required.

Up to this point, everything has happened on the wire exactly as it
should happen (I believe anyway).

	MLD listener report (again).   This one gives the hint of a problem.
	This one is "b4" joining the multicast address that corresponds to
	the "fe80::dead:beef" address, as it is configuring that address
	on its interface.  Note this is (almost) 3 seconds later than the
	group of 3 packets above, as if it had waited for an NA in response
	to its DAD NS, and hadn't received one.

And sure enough, configured it was.

I haven't yet attempted to look and see why that NA was ignored, instead
of causing DAD to "fail" (or "succeed" if you like, since it did manage
to detect a duplicate address), which should have caused (I believe) ifconfig
to report an error (it didn't).

Is this something that is known not to work?

kre