Subject: Re: Does IPv6 DAD actually work in the KAME stack?
To: None <tech-net@NetBSD.org>
From: Robert Elz <kre@munnari.OZ.AU>
Date: 07/21/2003 16:00:57
Date: Sun, 20 Jul 2003 22:11:31 +0200
From: Ignatios Souvatzis <email@example.com>
| Uhm... I've seen occurences of "IPv6 doesn't work" that pointed me at
| a bug in multicast address handling on a specific hardware driver.
Yes, I'd heard about that kind of thing too, which is why I noted that
(normally anyway) multicast was working - that is, it appeared as if,
most of the time anyway, multicast works fine in this driver (both systems
are using the ex driver).
| In my case it was something like "last multicast address configured doesn't
| work" or "first multicast address configured doesn't work"
But I never tested it that thoroughly.
| (The interesting difference about multicast vs. IPv6 is, that non-broadcast
| multicasts are part of the infrastructure, while in IPv4, to the end user
| they're only part of experimental protocols that are somehow expected to
| mysteriously fail, such formerly, driver bugs in handling of the multicast
| address list sometimes weren't detected for a long time.)
Yes - another advantage of IPv6!
firstname.lastname@example.org in <20030721033446.2005D13@coconut.itojun.org> said:
| DAD code actually works.
OK, fine - now I know where to start hunting (wanted to check this wasn't
just something "not yet implemented as in practice it never happens anyway"
before wasting time looking in the wrong area).
| try running tcpdump on "b4" machine (so that "b4" would receive all
| packets) and perform the same test again, then you'll see
| fe80::dead:beef marked as "duplicated".
I will do some more testing along those lines later today.
ps: in my earlier message I said "kernels were 1.6U from late May", which
was obvious nonsense, as 1.6U didn't appear till June 15. That was a
brain fade ... the kernels were really 1.6T (I have 1.6U versions waiting
to be installed on the relevant systems, but haven't done it yet)