Date:        Mon, 21 Jul 2003 12:34:46 +0900
    From:        itojun@iijlab.net
    Message-ID:  <20030721033446.2005D13@coconut.itojun.org>

  | 	DAD code actually works.

Yes, well, kind of.

The problem I observed in the previous mail turned out to not
quite be the problem I thought it was.

First, there were and are no issues at all with the multicast
support, all of that worked perfectly.

In the earlier mail, I managed to misinterpret the results however,
DAD actually did "work" (for some definition of working) - I hadn't
checked the syslog files (or dmesg), but when I did later, I found
that the kernel had indeed logged a message indicating that it
detected a duplicate address.

And when I looked back at the ifconfig output (that I still had in
an xterm scrollback buffer) I see that it did indeed say "duplicated"
next to the address.

I put "work" in quotes above, and said "kind of" at the head of this
message, because the way all this happened, and the results of it
happening, are nothing at all like just about anyone would expect I
think.

You may have noted from my previous message that I concluded that
DAD hadn't performed correctly from two things - first, ifconfig
didn't complain when I attempted to configure the address.  And second,
the kernel sent an MLD report indicating it was joining the group
associated with the address, at about the time it would normally be
deciding the address was not a duplicate.

That was aided by seeing the address reported in ifconfig output
(and not looking closely enough at that output to notice the "duplicated"
in the middle of the relevant line).

I would have expected the following to be true

	ifconfig would issue an error message
	The duplicate address would be removed from sight
		(that is what 2462 says should happen)

I know that the DAD stuff happens async in the kernel, I would actually
prefer if the ioctl that adds an IPv6 address (via external configuration)
was to sleep until DAD completes, and then return an error if it fails.

If that really isn't possible (from a brief glance, I think it could be
made to work that way), then at a minimum, ifconfig should be hanging
about waiting for the address to stop being tentative, and then reporting
an error if it turns up duplicated.   No-one should be required to
go hunting in the kernel syslog output (dmesg) nor to run a command
again, to find out whether or not it worked.   Ever.

Further, upon failure, the address should not be anywhere in the kernel
(aside from the dmesg buffer where it might have been logged).

I'm not sure what the rationale is for keeping duplicate addresses,
and marking them IFf_DUPLICATED but it makes no sense to me at all
at the minute.

What's more, when the system is in this state, there's a route installed
aimed at lo0 for the duplicated address (so it is impossible to talk to
the other node that owns the duplicated address - the original owner of
it), but because the address doesn't really exist (IFF_DUPLICATED) packets
to it don't get answered locally either.

To make matters worse (and assuming that there is a normal EUI-64
based LL address already on the interface) - when deleting the duplicated
address
	ifconfig interface inet6 -alias ...
the kernel deletes it properly, but also deletes the fe80::%int/64 route
for the interface, meaning that LL addresses for that interface no
longer work.   (This one I don't imagine is by design, I suspect a reference
count bug - most likely duplicated addresses aren't being counted as
references to the route, but that the address was a duplicate isn't
being noticed when it is deleted, and the reference count is decreased,
of course, this is just a guess at the minute, I haven't analysed the code).

Really, no route should be being added at all for a tentative address,
it should not exist for anything other than NS/NA packets until
confirmed.   That is neither the /128 route for the specific address,
aimed at lo0, nor the /64 (/N) route for the interface, for the
tentative address prefix - but I can imagine the NS's for the DAD code
not knowing where to go if those routes weren't installed initially).
If these are needed, proper cleanup should be done as soon as the
address is detected as being a duplicate.

It is also worth noting that the kernel sends an MLD "leave" when the
(duplicated) address is removed from the interface (which is good, in
its way), but just what has the kernel been doing being a member of that
particular multicast group for all the intervening period?   What can
that possibly gain it?   As soon as the address is detected as a duplicate,
so it will never be claimed by this node, the kernel should drop out of
the group immediately.

If this stuff doesn't all get fixed before I get a chance to look
at it in more detail (which certainly won't be this week, and may be
some time into the future) I will send in a PR with some patches that
make the world behave the way I believe it should behave...

kre