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
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
