Date: Wed, 06 May 2009 15:27:12 +0100 From: Bruce Simpson <bms@incunabulum.net> To: Bob Van Zant <bob@veznat.com> Cc: "freebsd-net@freebsd.org" <freebsd-net@freebsd.org> Subject: Re: IPv6 duplicate address detection Message-ID: <4A019E40.1030606@incunabulum.net> In-Reply-To: <C625D61C.224AD%bob@veznat.com> References: <C625D61C.224AD%bob@veznat.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Bob Van Zant wrote: > I'm working on a piece of software that, among other things, allows an > administrator to easily configure IPv6 interfaces on a FreeBSD host. I've > run into a problem where whenever I reconfigure an interface with an IPv6 > address FreeBSD marks the new address as being a duplicate. > > The problem is that I'm following RFC 2461 [1] in that I send an unsolicited > neighbor advertisement to ff02::1 immediately after configuring the > interface. > How are you doing this? Do you do this from the kernel or from your own userland code? Normally the kernel does DAD for you when a new IPv6 address is configured, and you shouldn't need to do it manually. However, I would agree that there should probably be more run-time, user-space controls over how the IPv6 stack behaves. > This unsolicited neighbor advertisement is interpreted by FreeBSD as being a > response to the neighbor solicitation it sends around the same time as part > of duplicate address detection (DAD). This leads FreeBSD to think that the > address is already in use, it doesn't notice that it is the one already > using it. > It sounds like what you are trying to do is useful (a bit like gratuitous ARP) but I wonder exactly what conditions it's triggering in nd6_nbr.c which would cause it to interpret what you send in this way. One problem with trying to ape what the kernel does is in userland is that unless there's a unique ID in the datagram(s) thus sent that you can key off, it's difficult to catch it in the act and figure out what to do; there's also scheduler jitter to contend with. > I want this to mean that there's a bug in the IPv6 implementation in that it > shouldn't trigger a DAD failure if it sees an unsolicited NA from itself > when sent from the same physical interface. > This seems like a bug. Have you looked in the KAME repo to see if it got fixed there? Perhaps NetBSD have already fixed it in their import of KAME? > An alternative view on this is that I shouldn't be sending out any packets, > especially unsolicited NAs, using or referencing a tentative address. > That can be tricky to implement. There is a function in6ifa_ifpforlinklocal() which takes various flags. It is told to skip tentative addresses or duplicates by passing IN6_IFF_NOTREADY. Normally this will return the ifa pointer to the link-local address which was auto-configured on the inerface. Currently the MLDv2 code in HEAD will use the unspecified address (::) as a source address if the IFA match returned by this function is NULL, this is allowed by the MLDv2 spec. > I'm writing to freebsd-net to ask what others think. > > If people agree that the address shouldn't be marked as a duplicate then I > have a python script that reproduces the problem and a patch to nd6_nbr.c to > attach to a problem report that I'll file. > Can you try HEAD sources and disable IPv6 multicast loopback by default (net.inet6.ip6.mcast.loop, off the top of my head) ? It is possible that your ff02::1 packet is being looped back and somehow the NA/NS code is interpreting it as on-wire traffic. 7.x will loop back by default. You could even try just setting IPV6_MULTICAST_LOOP to 0 in your userland DAD code. That should help establish how the NA/NS code is seeing your locally originated control traffic... cheers, BMS
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4A019E40.1030606>