From owner-freebsd-net@FreeBSD.ORG Wed May 6 22:49:51 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 C0D281065672 for ; Wed, 6 May 2009 22:49:51 +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 7BC928FC0A for ; Wed, 6 May 2009 22:49:51 +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:CC:Message-ID:Thread-Topic: Thread-Index:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding; b=L1iKW49wvmh3kzjtSjR5g4KO6s58yv+H15HS43IH1KpSKZNk6+VK0RZk GA90fYOaxjHEFlGkbpoJ8ecyWQWbJdXC7pnnf0DIeRItPHWvsFO4SWoFy 3eTCZRITP9xa2NgKMREqyvytOfaegoUwvgKo0dcVYmcH9p6YyC6uNcE9H Q=; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=veznat.com; i=bob@veznat.com; q=dns/txt; s=one; t=1241650191; x=1273186191; 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:=20R e:=20IPv6=20duplicate=20address=20detection|Date:=20Wed, =2006=20May=202009=2015:49:45=20-0700|Message-ID:=20|To:=20=20JINMEI=20Tatuya=20/ =20=3D?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=3D?=3D=0D=0A=20< Jinmei_Tatuya@isc.org>|CC:=20"freebsd-net@freebsd.org"=20 |Mime-version:=201.0 |Content-transfer-encoding:=207bit|In-Reply-To:=20; bh=4a2u6dVxFGvE+Z+78u/rO7EwziHF/haZthMumwVB+bg=; b=UnLR4jjgIDn0F0Qx93Szi8PyzhHL5WZkF1qPGufQg2H3xLHHHJ6b98YG EIW7lUiAYJqniii5Uqa72u1UGJSO3JexEx3qhfaladbaYTZ0goFgCIG+/ /whBmFCXP5AuAcfLSrJMiDkIqwlirpiJRVqXqFWZ6yQKuIMzm+CFteicS o=; X-MID: 1016190 X-IronPort-AV: E=McAfee;i="5300,2777,5607"; a="1016190" X-IronPort-AV: E=Sophos;i="4.40,305,1239001200"; d="scan'208";a="1016190" Received: from nat.ironport.com (HELO [173.37.10.6]) ([63.251.108.100]) by mail.ttora.com with ESMTP/TLS/DES-CBC3-SHA; 06 May 2009 15:49:49 -0700 User-Agent: Microsoft-Entourage/12.12.0.080729 Date: Wed, 06 May 2009 15:49:45 -0700 From: Bob Van Zant To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Message-ID: Thread-Topic: IPv6 duplicate address detection Thread-Index: AcnOnPNdQBRY1ktUrkWYPE80CEXaSA== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-2022-JP" 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 22:49:52 -0000 On 5/6/09 3:06 PM, "JINMEI Tatuya / 神明達哉" wrote: > I'm afraid we need clarification first...what do you mean by > "reconfigure an interface with an IPv6 address"? Do you mean adding a > new IPv6 address to an interface? If so, I'm not sure why you > referred to the following part of RFC2461 (btw the RFC was updated by > RFC4861): We have a crude form of NIC pairing in our software. We allow someone to logically pair two interfaces together. This is implemented by `ifconfig down` both interfaces, configure them both the same, then `ifconfig up` the primary interface. We then monitor the link state of the primary interface. If the state goes to down, we `ifconfig down` the primary NIC and then `ifconfig up` the secondary NIC. This has the effect of changing the link layer address associated with a given IPv6 address. After we do this we send out the unsolicited NA to update whatever switch we're plugged into. We do this today with IPv4 and ARP and it works fine. >> [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. > > this example talks about the case where the link-layer address changes > for an existing address, not where a new address is configured. I hope the example I gave above helps to clarify that I am trying to handle a case where the link-layer address has changed. However, I'll admit that I had been planning on sending the unsolicited NA after any ifconfig commands were executed. So long as I'm not flooding the network it doesn't seem harmful and potentially seems useful to avoid a few seconds of downtime while the network figures things out. -Bob