From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id A4891201A6F for ; Tue, 10 May 2011 21:52:40 -0700 (PDT) Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps port 25 id 1QK1WN-0006Sd-AX; Wed, 11 May 2011 06:59:45 +0200 Received: from i72vorta.tm.uni-karlsruhe.de ([141.3.71.26] helo=vorta.tm.kit.edu) by irams1.ira.uni-karlsruhe.de with esmtp port 25 id 1QK1WN-0002ly-6f; Wed, 11 May 2011 06:59:39 +0200 Received: from [IPv6:::1] (localhost [127.0.0.1]) by vorta.tm.kit.edu (Postfix) with ESMTPS id 584AA101; Wed, 11 May 2011 06:59:36 +0200 (CEST) Message-ID: <4DCA1339.1010409@kit.edu> Date: Wed, 11 May 2011 06:40:25 +0200 From: Roland Bless Organization: Institute of Telematics, Karlsruhe Institute of Technology (KIT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: Dave Taht References: <4DC94BF6.5060302@visser.name> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ATIS-AV: ClamAV (irams1.ira.uni-karlsruhe.de) X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de) X-ATIS-AV: Kaspersky (iramx2.ira.uni-karlsruhe.de) X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1305089985.547801000 Cc: bloat@lists.bufferbloat.net Subject: Re: [Bloat] ipv6 fe80:: addresses, vlans and bridges... borked? X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2011 04:52:41 -0000 Hi Dave, On 11.05.2011 05:32, Dave Taht wrote: > 1) in a wireshark analysis, the %interface part is lost But your wireshark is listening on some specific interface, isn't it? This interface is your context then and link locals are unique on that particular link (which is assured by Duplicate Address Detection). Are you facing the problem from the switch's perspective (e.g., that you can determine the receiving i/f from the destination address of received packets) or from another another device's perspective? > 2) we have 2^64 possible choices for fe80 addresses. I don't see what > having them all be the same buys me. You can assign an individual fe80:: address to an interface, e.g., fe80::b101 for bridge one interface 1, fe80::b102 bridge one interface 2 etc. if that helps. But be aware that it may create address collisions in case you have two such bridges on the same link :-( Therefore, using (modified) EUI-64 addresses within the 64-bit seems to be a good choice. > 3) It worries me in the babel routing protocol Sorry, I didn't study the spec so far. What is the particular problem there? Maybe there is a problem with the assumptions in the protocol. > 4) My bridges are misbehaving over ipv6 in the general case and I'm > willing to grasp at straws. What is that misbehavior? That a bridge is using the same link local address on each of its links? That's ok as long as its unique on that particular on-link subnet. Regards, Roland