From owner-freebsd-net@FreeBSD.ORG Wed May 6 14:27:18 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4D2361065709 for ; Wed, 6 May 2009 14:27:18 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by mx1.freebsd.org (Postfix) with ESMTP id 09F558FC12 for ; Wed, 6 May 2009 14:27:17 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.messagingengine.com (Postfix) with ESMTP id 0818C33E4F8; Wed, 6 May 2009 10:27:17 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute2.internal (MEProxy); Wed, 06 May 2009 10:27:17 -0400 X-Sasl-enc: zFycSp61tQQ9kPUhEOOUvWNf/A8yF+TUI948RZLcXMYl 1241620036 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id 4EDAC2E34E; Wed, 6 May 2009 10:27:16 -0400 (EDT) Message-ID: <4A019E40.1030606@incunabulum.net> Date: Wed, 06 May 2009 15:27:12 +0100 From: Bruce Simpson User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Bob Van Zant References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-net@freebsd.org" Subject: Re: IPv6 duplicate address detection X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 14:27:18 -0000 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