From owner-freebsd-net@FreeBSD.ORG Tue May 5 18:40:15 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 17154106566B for ; Tue, 5 May 2009 18:40:15 +0000 (UTC) (envelope-from bob@veznat.com) Received: from mail.ttora.com (mail.ttora.com [208.75.243.236]) by mx1.freebsd.org (Postfix) with ESMTP id CB91E8FC08 for ; Tue, 5 May 2009 18:40:14 +0000 (UTC) (envelope-from bob@veznat.com) DomainKey-Signature: s=two; d=veznat.com; c=nofws; q=dns; h=X-MID:X-IronPort-AV:X-IronPort-AV:Received:User-Agent: Date:Subject:From:To:Message-ID:Thread-Topic:Thread-Index: Mime-version:Content-type:Content-transfer-encoding; b=hld6PGvqg8ciEDL0uSOPKe4K7tif9A6I2sN2/Dk5AVXQmvh+hmFcSAwa LkS7ncWptQnJ0Ux3yO4pzv6szdck5xmneiqIncUKF8fT7+OTcvEwplN44 +rk6eIS9OdStchDxMDOoH/AWSbDR6pfSmbFIBfbQPEA+3FwGfTpH/3aLA c=; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=veznat.com; i=bob@veznat.com; q=dns/txt; s=one; t=1241548814; x=1273084814; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Bob=20Van=20Zant=20|Subject:=20I Pv6=20duplicate=20address=20detection|Date:=20Tue,=2005 =20May=202009=2011:40:12=20-0700|Message-ID:=20|To:=20"freebsd-net@freebsd.org"=20< freebsd-net@freebsd.org>|Mime-version:=201.0 |Content-transfer-encoding:=207bit; bh=0tHAGD/DRfwjaro2NMA/mNiRb2wzmF2dkmwQOAfMm8Q=; b=KxztPg09F+RXLZ9TMJ8iiIxeH3t5fcp9P9gqu2/Ar83CFYSHyAxgOsOG GBIHez6ISUU2pCp3ETpvYuJZGMxlwzDQYh6Qo5Ys9CnoDh40g8rcz2Cl9 58Ug+U9Nmd4UK1rzj8beuVHtWc8OcIzjM6H9k1tcoIcrv7lbZH5tmqaeI s=; X-MID: 996206 X-IronPort-AV: E=McAfee;i="5300,2777,5606"; a="996206" X-IronPort-AV: E=Sophos;i="4.40,298,1239001200"; d="scan'208";a="996206" Received: from nat.ironport.com (HELO [173.37.10.6]) ([63.251.108.100]) by mail.ttora.com with ESMTP/TLS/DES-CBC3-SHA; 05 May 2009 11:40:12 -0700 User-Agent: Microsoft-Entourage/12.12.0.080729 Date: Tue, 05 May 2009 11:40:12 -0700 From: Bob Van Zant To: "freebsd-net@freebsd.org" Message-ID: Thread-Topic: IPv6 duplicate address detection Thread-Index: AcnNsOxZqVYYjQ4OVEeimi434NkgBg== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: 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: Tue, 05 May 2009 18:40:15 -0000 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. 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. 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. An alternative view on this is that I shouldn't be sending out any packets, especially unsolicited NAs, using or referencing a tentative address. 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. -Bob [1] RFC 2461 section 7.2.6 paragraph 1: In some cases a node may be able to determine that its link-layer address has changed (e.g., hot-swap of an interface card) and may wish to inform its neighbors of the new link-layer address quickly.