From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-iw0-f171.google.com (mail-iw0-f171.google.com [209.85.214.171]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 07952201759 for ; Wed, 11 May 2011 06:39:23 -0700 (PDT) Received: by iwn8 with SMTP id 8so767238iwn.16 for ; Wed, 11 May 2011 06:46:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=QrX/nsNZuVCHv4LfeNScfzaWMRGnfrNBgZyvxRoeKr8=; b=Tki5PVsAOR35O14cvNB95o/NqVUclffTs2sStaWUptFqUgrUXq9BM9Ggf7MydbhQ5j eW/MMHeJGF6daE5mn7+Bi3KTmhK8AugI0MmSgWtZudOPdzsHgjOxdDLcpJqlJYi5nDBX DpVdvBfFyfj8o4C1cm3qh06hCAu/bL/B9KNCs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=jR89ZMUD2Xrh4OC/H6noM00V3hgHp0Bh4x1SvQZvVoEU+wjLLbalc0T+gtrghSMbtH lG4V2FTyOnZJFRul6Lo3v5Mqb7VZv3ns4UFWQ/txo8HuNKytqDvAvPgg8LpNbwKg1/+Q WL6+OXJumU/cKp77uf3mLIHB6AreMI0LpOKbg= MIME-Version: 1.0 Received: by 10.231.92.206 with SMTP id s14mr6397480ibm.106.1305121601323; Wed, 11 May 2011 06:46:41 -0700 (PDT) Received: by 10.231.31.201 with HTTP; Wed, 11 May 2011 06:46:41 -0700 (PDT) In-Reply-To: <4DCA1339.1010409@kit.edu> References: <4DC94BF6.5060302@visser.name> <4DCA1339.1010409@kit.edu> Date: Wed, 11 May 2011 07:46:41 -0600 Message-ID: From: Dave Taht To: Roland Bless Content-Type: multipart/alternative; boundary=bcaec543204a6f82ca04a3004d2a 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 13:39:24 -0000 --bcaec543204a6f82ca04a3004d2a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, May 10, 2011 at 10:40 PM, Roland Bless wrote= : > 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? No. It is listening on the wildcard interface. Of which there are 8. > This interface is your context then and link locals are > unique on that particular link (which is assured by > Duplicate Address Detection). I wouldn't be so sure in the case of link-local addresses and vlans and bridges. At least: I'm no longer sure... After digging into the code in openwrt (very) late last night I spotted thi= s in base-files/files/lib/network/config.sh config_get macaddr "$config" macaddr [ -x /usr/sbin/brctl ] && { ifconfig "br-$config" 2>/dev/null >/dev/nul= l && { local newdevs devices config_get devices "$config" device for dev in $(sort_list "$devices" "$iface"); do append newdevs "$dev" done uci_set_state network "$config" device "$newdevs" $DEBUG ifconfig "$iface" 0.0.0.0 $DEBUG do_sysctl "net.ipv6.conf.$iface.disable_ipv6" 1 $DEBUG brctl addif "br-$config" "$iface" # Bridge existed already. No furthe= r processing necesary } || { local stp config_get_bool stp "$config" stp 0 $DEBUG brctl addbr "br-$config" $DEBUG brctl setfd "br-$config" 0 $DEBUG ifconfig "$iface" 0.0.0.0 $DEBUG do_sysctl "net.ipv6.conf.$iface.disable_ipv6" 1 $DEBUG brctl addif "br-$config" "$iface" $DEBUG brctl stp "br-$config" $stp $DEBUG ifconfig "br-$config" up it looks like I can "prepend" rather than "append" in order to get the wlan= * interface first in the bridge (rather than eth*), or defer bridge creation until the other interfaces are brought up.... Each wlan has a unique MAC id, and thus I hope will create a unique bridge id EUI-64. And as for why it disables ipv6 on the underlying interface... > 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? > > routers' 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. > > I think using ::b101 is a bad idea. EUI-64 is the way to go. I wanted to us= e up the extra 52 bits though in some sane manner.... > > 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. > > It's a new RFC. Could be. It's a neat protocol tho. > > 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. > > They be misbehaving - multicast weirdnesses. > Regards, > Roland > --=20 Dave T=E4ht SKYPE: davetaht US Tel: 1-239-829-5608 http://the-edge.blogspot.com --bcaec543204a6f82ca04a3004d2a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, May 10, 2011 at 10:40 PM, Roland= Bless <roland= .bless@kit.edu> wrote:
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?

No. It is listening on the wildcard int= erface. Of which there are 8.
=A0
This interface is your context then and link locals are
unique on that particular link (which is assured by
Duplicate Address Detection).

I wouldn't be so su= re in the case of link-local addresses and vlans and bridges. At least: I&#= 39;m no longer sure...

After digging into the code in openwrt (very)= late last night I spotted this in base-files/files/lib/network/config.sh
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 config_get macad= dr "$config" macaddr
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 [ -x /usr/sbin/brctl ] && {
=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 ifconfig "br-$config" 2>/dev/null >/dev/nul= l && {
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 local newdevs devices
=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 config_get devices "$config"= device
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 for dev in $(sort_li= st "$devices" "$iface"); do
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 append n= ewdevs "$dev"
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 done<= br>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 uci_set_state network "$= config" device "$newdevs"
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 $DEBUG ifconfig "$iface&quo= t; 0.0.0.0
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 $DEBUG do_sysctl = "net.ipv6.conf.$iface.disable_ipv6" 1
=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0 $DEBUG brctl addif "br-$config" "$iface&q= uot;
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 # Bridge existed already. No fur= ther processing necesary
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 } || {
=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0 local stp
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0 config_get_bool stp "$config" stp 0
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 $DEBUG brctl addbr "br-$con= fig"
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 $DEBUG brctl setf= d "br-$config" 0
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 $D= EBUG ifconfig "$iface" 0.0.0.0
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 $DEBUG do_sysctl "net.ipv6.= conf.$iface.disable_ipv6" 1
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 $DEBUG brctl addif "br-$config" "$iface"
=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 $DEBUG brctl stp "br-$config"= ; $stp
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 $DEBUG ifconfig "br-$config= " up

it looks like I can "prepend" rather than "= append" in order to get the wlan* interface first in the bridge (rathe= r than eth*), or defer bridge creation until the other interfaces are broug= ht up....

Each wlan has a unique MAC id, and thus I hope will create a unique bri= dge id EUI-64.

And as for why it disables ipv6 on the underlying int= erface...

=A0
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?

routers' perspective.
=A0
> 2) we have 2^64 possible choices for fe80 addresses. I don't see w= hat
> 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, =A0fe80::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.


I think using ::b101 is a= bad idea. EUI-64 is the way to go. I wanted to use up the extra 52 bits th= ough in some sane manner....
=A0
> 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.


It's a new RFC. Could= be. It's a neat protocol tho.
=A0
> 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<= br> address on each of its links? That's ok as long as its unique on that particular on-link subnet.


They be misbehaving - multicast weirdnesses.
= =A0
Regards,
=A0Roland



--
Dave T=E4ht
S= KYPE: davetaht
US Tel: 1-239-829-5608
http://the-edge.blogspot.com
--bcaec543204a6f82ca04a3004d2a--