IPv6 duplicate address detection

[Bruce Simpson]

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