From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-iy0-f171.google.com (mail-iy0-f171.google.com [209.85.210.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 8100120175B; Mon, 9 May 2011 11:49:35 -0700 (PDT) Received: by iyi20 with SMTP id 20so7081213iyi.16 for ; Mon, 09 May 2011 11:56:02 -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=D38I+cenveJ0JljSH7QhMtN9ObjWqSZngH/isdCIMc4=; b=gCJgeZhPPTPP1W4LL0ZIpyMaedRYA7KEnJrz1lLWBK/XOtD/5OCCyAnphTKzO5kr4V E3TWA9DUijz//WOd2JCUb/pfs0qsBihRxliqv/Fwva2rt3MXmdwP15qhYKQdabjyWnrK AWnixrC7ED4CuUd3kdYDg/QGrTcDnL7V7nIf0= 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=Isq1oLcr7no8FBBTThIIRD1Gl+Es7wZNWP1ZiW4TZyE3rYbOdHEwWP40TYA3Eg4GNk g0zvhgt1djrY0R/63rup03AUlltqqTSLxclAuALXQswZb0LwMlqq8ftHxY3pmMIQ7hls EjlpCBxYleWO9J3TV+vyvrTWeOrgo7kC7sPFk= MIME-Version: 1.0 Received: by 10.231.188.140 with SMTP id da12mr4775515ibb.131.1304967362663; Mon, 09 May 2011 11:56:02 -0700 (PDT) Received: by 10.231.31.201 with HTTP; Mon, 9 May 2011 11:56:02 -0700 (PDT) In-Reply-To: References: <1A32BF60-18B3-44C3-9908-4225B33E8EFD@cisco.com> <6C99CF5C-88E9-4F38-9C11-CF75DD83E965@cisco.com> Date: Mon, 9 May 2011 12:56:02 -0600 Message-ID: From: Dave Taht To: Fred Baker Content-Type: multipart/alternative; boundary=001636c925f218553004a2dc641a Cc: bismark-devel@lists.bufferbloat.net, bloat 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: Mon, 09 May 2011 18:49:35 -0000 --001636c925f218553004a2dc641a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, May 9, 2011 at 10:44 AM, Fred Baker wrote: > BTW, every time I post nowadays, I get moderated on bismark-devel. Do you > think you could grandfather bloat@ emails? > > I've added you to the bismark-devel list and set nomail on. > On May 9, 2011, at 9:14 AM, Dave Taht wrote: > > Fred/all > > See > > http://www.bufferbloat.net/issues/126 > > which has a ip -6 addr and ifconfig dump > > and see if that "seems right" to you. > > > > First, please define "bridge". To me, it's another term for an Ethernet > switch, although I'm probably showing my age. > A bridge in this case is a switch that spans multiple switched interfaces, so for example, eth0.1 is bridged to wlan0 and wlan1 (2.4ghz and 5.x ghz) and eth0.2 is bridged to wlan2 and wlan3. Theoretically eth0.1 and eth0.2 are vlans but this may be the source of my problems, more on that in a bit. Most home routers are not pure routers in any shape or form - they "route" to the internet, but "bridge" to their local wired and wireless interfaces. The reasons for this are historical, and not strictly necessary anymore (in fact I vastly prefer pure routing to bridging as it makes security easier and multicast both saner (from a performance standpoint) and slightly harder). But the "bridged wired/wireless" idea is deeply embedded in the marketplace= . Historically simple dhcp servers had difficulty with multiple interfaces, and multicast (things like multicast dns) just plain didn't work properly i= n the case of routing. So if you attach to your home lan you would generally get on the IPv4 subne= t no matter if you got on via wired or any of multiple wireless interfaces, because they were bridged into one "br-lan" interface. Using IPv4 subnets for each of your interfaces would be a better choice nowadays if it wasn't for the multicast and routing problems. I have no ide= a of igmp works at all these days. And then that also leaves the routing problem. Nobody's ever been able to agree on a standard routing protocol for simple home use. > From your previous email, I understand it to mean a Linux system that has > IPv6 enabled on each of its interfaces. That isn't going to bridge much o= f > anything - it's simply an interface-multihomed host. What are you calling= a > "bridge"? > Hopefully the above makes it more clear. After puzzling over this some more, I think the root of the problem is that while wlan0-wlan5 autogenerate unique mac addresses, eth0.1 and eth0.2 etc do not... and the bridging code picks up on the first (wired) interface to generate it's fe80:: addresses, making them all be the same, instead of the underlying wlan mac addr. So if I can figure out a way to have the bridge code pick up on the wlanX mac addresses rather than the eth0.X mac address I think life will be sweeter. This would eliminate the need to fiddle with the upper 54 bits of = a fe80 address (which looks illegal according to the standard) Or I can go to pure routing of both ipv4 and ipv6 traffic across each distinct interface, but... > > It's really hard to comment on a random output without any statement of > configuration or intent. > > Trying to create a home router that "does the right thing" for ipv4 AND ipv6, with local secured, guest, and mesh interfaces. > On Mon, May 9, 2011 at 9:57 AM, Fred Baker wrote: > >> >> On May 9, 2011, at 7:59 AM, Dave Taht wrote: >> > On Mon, May 9, 2011 at 2:14 AM, Fred Baker wrote: >> > >> > On May 8, 2011, at 8:26 PM, Dave Taht wrote: >> >> > Is there a standard for renaming fe80:: addresses to represent they >> are interfacing with different vlans? >> >> >> >> well, yes. Link-local addresses (FE80::/10) areas you say interpreted >> only in the LAN in question. The usual approach is to give the LAN a sub= net >> prefix. The standard is RFC 4291. >> >> >> >> http://www.ietf.org/rfc/rfc4291.txt >> >> >> > So, there isn't a standard for using vlans and ipv6. >> >> There is one for IPv6. How you use it in your addressing plan is your >> call. You could map subnet numbers to vlan numbers of that made sense fo= r >> you, but I'd be surprised if folks generally wanted to do that; believe = it >> or not, not all networks are built around vlans. Many are built around M= PLS, >> and many use neither - they simply use IP subnets. >> >> > aformentioned RFC: >> > >> > 2.5.1. Interface Identifiers >> > >> > Interface identifiers in IPv6 unicast addresses are used to identif= y >> > interfaces on a link. They are required to be unique within a subn= et >> > prefix. It is recommended that the same interface identifier not b= e >> > assigned to different nodes on a link. They may also be unique ove= r >> > a broader scope. In some cases, an interface's identifier will be >> > derived directly from that interface's link-layer address. The sam= e >> > interface identifier may be used on multiple interfaces on a single >> > node, as long as they are attached to different subnets. >> > >> > "It is recomended that the same interface identifier not be assigned t= o >> different nodes on a link" >> >> There is a stronger statement than the one in 2.5.1; the text above says >> that "They are required to be unique within a subnet prefix." >> >> > vs >> > >> > "The same interface identifier may be used on multiple interfaces on a >> single >> > node, as long as they are attached to different subnets." >> > >> > >> > Linux - or at least the defaults inside of openwrt - take the latter >> approach. This strikes me as error prone - and further does not discuss = the >> effects of what a bridge should look like. >> > >> > For error prone-ness - it is possible in my case, the vlans are not >> vlans! although their naming scheme (ethX.Y) suggests they are. And a >> typical user might plug two different lans together on one cable anyway. >> >> So you're concerned that two interfaces might have the same interface >> identifier but different supporting MAC addresses within the same subnet= ? >> Yes, in this model that is possible. I personally would suggest that one >> uses duplicate address detection to detect and avoid the situation. Does >> Linux do that? From a requirements perspective, "may" is a lot weaker th= an >> "required". >> >> > Also: >> > >> > Should the bridge itself have a unique link local over the underlying >> interfaces? >> >> I'm not sure what "bridge" you're talking about. If by "bridge" you're >> referring to a linux system using the same IID on multiple interfaces, I= IDs >> "are required to be unique within a subnet prefix" per the text you quot= ed >> above. >> >> > Given that we have a profusion of numbers available for link-local >> addresses, I can see no harm and much gain in *always* constructing a >> verify-ably unique fe80::XX:VLAN:EUI-64/64 prefix on a per-interface and >> per-virtual-interface basis on a given router. >> >> That's certainly your choice; it doesn't map to any address format in th= e >> spec; 2.5.6 very specifically sets those bits to zero in a link-local >> address (I would argue it should therefore specify the prefix as FE80::/= 64, >> not FE80::/10). How do the hosts know what VLAN they are on? That's >> generally either information known by the switch and used on trunk ports= , or >> configured data. The host generally has no idea what VLAN it's on. Recal= l >> that link-local addresses are what the device develops before it has any >> knowledge of the world around it. >> >> > ensuring unique FE80s from a given host would be enormously less >> confusing when looking at and comparing wireshark traces of the babel >> protocol, for example. ( http://tools.ietf.org/html/rfc6126 ) >> > >> > What's not clear to me after reading RFC4291 twice this morning is tha= t >> although a fe80:: is a /10, is if the bits above the interface id (as pe= r >> the above "XX:VLAN:") truly are legit to be used, or a modified unique >> EUI-64 should be used. >> >> What you're describing is essentially a site-local address, although the >> format uses FEC0::/10. Did you read the part about site-local addresses >> (2.5.7)? >> >> | 10 | >> | bits | 54 bits | 64 bits | >> +----------+-------------------------+----------------------------+ >> |1111111011| subnet ID | interface ID | >> +----------+-------------------------+----------------------------+ >> >> You have tried to specify the "Subnet ID" and use it as a link-local. >> >> I'll suggest you read: >> >> http://www.ietf.org/rfc/rfc3879.txt >> 3879 Deprecating Site Local Addresses. C. Huitema, B. Carpenter. >> September 2004. (Format: TXT=3D24142 bytes) (Status: PROPOSED STANDA= RD) >> and >> http://www.ietf.org/rfc/rfc4193.txt >> 4193 Unique Local IPv6 Unicast Addresses. R. Hinden, B. Haberman. >> October 2005. (Format: TXT=3D35908 bytes) (Status: PROPOSED STANDARD= ) >> >> > A VLAN identifier is 12 bits in length, so the "V" portion of the abov= e >> proposal could be dropped. (Not that I know how to extract the vlan >> identifier from the interface anyway) XX would be used to distinguish >> between interfaces that had no corresponding info but conflicted with >> addresses already on the router. >> > >> > I realize this is somewhat off topic for the bloat list, but I was >> trying to get where I could actually test the IPv6 ECN patches I'd folde= d in >> across the routers(s) and running into trouble. >> >> I actually think you would do well to join >> https://www.ietf.org/mailman/listinfo/ipv6 and discuss it on >> ipv6@ietf.org. >> >> > > > -- > Dave T=E4ht > SKYPE: davetaht > US Tel: 1-239-829-5608 > http://the-edge.blogspot.com > > > --=20 Dave T=E4ht SKYPE: davetaht US Tel: 1-239-829-5608 http://the-edge.blogspot.com --001636c925f218553004a2dc641a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Mon, May 9, 2011 at 10:44 AM, Fred Ba= ker <fred@cisco.com<= /a>> wrote:
BTW, every time I post nowadays, I ge= t moderated on bismark-devel. Do you think you could grandfather bloat@ ema= ils?


I've added you to the bi= smark-devel list and set nomail on.
=A0
On May 9, 2011, at 9:14 AM, Dave Taht wrote:

Fred/all

See

http://www.bufferbloat.ne= t/issues/126

which has a ip -6 addr and ifconfig dump

and= see if that "seems right" to you.


=A0
First, please define &quo= t;bridge". To me, it's another term for an Ethernet switch, althou= gh I'm probably showing my age.

A bridge in this case is a switch that spans multiple switched int= erfaces, so for example, eth0.1 is bridged to wlan0 and wlan1 (2.4ghz and 5= .x ghz)

and eth0.2 is bridged to wlan2 and wlan3.

Theoretical= ly eth0.1 and eth0.2 are vlans but this may be the source of my problems, m= ore on that in a bit.

Most home routers are not pure routers in any shape or form - they &quo= t;route" to the internet, but "bridge" to their local wired = and wireless interfaces.

The reasons for this are historical, and no= t strictly necessary anymore (in fact I vastly prefer pure routing to bridg= ing as it makes security easier and multicast both saner (from a performanc= e standpoint) and slightly harder).

But the "bridged wired/wireless" idea is deeply embedded in t= he marketplace.

Historically simple dhcp servers had difficulty with= multiple interfaces, and multicast (things like multicast dns) just plain = didn't work properly in the case of routing.

So if you attach to your home lan you would generally get on the IPv4 s= ubnet no matter if you got on via wired or any of multiple wireless interfa= ces, because they were bridged into one "br-lan" interface.

Using IPv4 subnets for each of your interfaces would be a better choice= nowadays if it wasn't for the multicast and routing problems. I have n= o idea of igmp works at all these days.

And then that also leaves t= he routing problem. Nobody's ever been able to agree on a standard rout= ing protocol for simple home use.




=A0
From your = previous email, I understand it to mean a Linux system that has IPv6 enable= d on each of its interfaces. That isn't going to bridge much of anythin= g - it's simply an interface-multihomed host. What are you calling a &q= uot;bridge"?

Hopefully the above makes it more c= lear.


After puzzling over this some more, I think the root of the problem is=20 that while wlan0-wlan5 autogenerate unique mac addresses, eth0.1 and=20 eth0.2 etc do not...

and the bridging code picks up on the first (wired) interface to=20 generate it's fe80:: addresses, making them all be the same, instead of= =20 the underlying wlan mac addr.

So if I can figure out a way to have the bridge code pick up on the=20 wlanX mac addresses rather than the eth0.X mac address I think life will be sweeter. This would eliminate the need to fiddle with the upper 54=20 bits of a fe80 address (which looks illegal according to the standard)

Or I can go to pure routing of both ipv4 and ipv6 traffic across each disti= nct interface, but...
=A0

It'= s really hard to comment on a random output without any statement of config= uration or intent.=A0


Trying to create a home route= r that "does the right thing" for ipv4 AND ipv6, with local secur= ed, guest, and mesh interfaces.
=A0
On Mon, May 9, = 2011 at 9:57 AM, Fred Baker <fred@cisco.com> wrote:

On May 9, 2011, at 7:59 AM, Dave Taht wrote:
> On Mon, May 9, 2011 at 2:14 AM, Fred Baker <fred@cisco.com> wrote:
>
> On May 8, 2011, at 8:26 PM, Dave Taht wrote:
>> > Is there a standard for renaming fe80:: addresses to represen= t they are interfacing with different vlans?
>>
>> well, yes. Link-local addresses (FE80::/10) areas you say interpre= ted only in the LAN in question. The usual approach is to give the LAN a su= bnet prefix. The standard is RFC 4291.
>>
>> = http://www.ietf.org/rfc/rfc4291.txt
>>
> So, there isn't a standard for using vlans and ipv6.

There is one for IPv6. How you use it in your addressing plan is your= call. You could map subnet numbers to vlan numbers of that made sense for = you, but I'd be surprised if folks generally wanted to do that; believe= it or not, not all networks are built around vlans. Many are built around = MPLS, and many use neither - they simply use IP subnets.

> aformentioned RFC:
>
> 2.5.1. =A0Interface Identifiers
>
> =A0 =A0Interface identifiers in IPv6 unicast addresses are used to ide= ntify
> =A0 =A0interfaces on a link. =A0They are required to be unique within = a subnet
> =A0 =A0prefix. =A0It is recommended that the same interface identifier= not be
> =A0 =A0assigned to different nodes on a link. =A0They may also be uniq= ue over
> =A0 =A0a broader scope. =A0In some cases, an interface's identifie= r will be
> =A0 =A0derived directly from that interface's link-layer address. = =A0The same
> =A0 =A0interface identifier may be used on multiple interfaces on a si= ngle
> =A0 =A0node, as long as they are attached to different subnets.
>
> "It is recomended that the same interface identifier not be assig= ned to different nodes on a link"

There is a stronger statement than the one in 2.5.1; the text above s= ays that "They are required to be unique within a subnet prefix."=

> vs
>
> "The same interface identifier may be used on multiple interfaces= on a single
> =A0 =A0node, as long as they are attached to different subnets."<= br> >
>
> Linux - or at least the defaults inside of openwrt - take the latter a= pproach. This strikes me as error prone - and further does not discuss the = effects of what a bridge should look like.
>
> For error prone-ness - it is possible in my case, the vlans are not vl= ans! although their naming scheme (ethX.Y) suggests they are. And a typical= user might plug two different lans together on one cable anyway.

So you're concerned that two interfaces might have the same inter= face identifier but different supporting MAC addresses within the same subn= et? Yes, in this model that is possible. I personally would suggest that on= e uses duplicate address detection to detect and avoid the situation. Does = Linux do that? From a requirements perspective, "may" is a lot we= aker than "required".

> Also:
>
> Should the bridge itself have a unique link local over the underlying = interfaces?

I'm not sure what "bridge" you're talking about. If= by "bridge" you're referring to a linux system using the sam= e IID on multiple interfaces, IIDs "are required to be unique within a= subnet prefix" per the text you quoted above.

> Given that we have a profusion of numbers available for link-local add= resses, I can see no harm and much gain in *always* constructing a verify-a= bly unique fe80::XX:VLAN:EUI-64/64 prefix on a per-interface and per-virtua= l-interface basis on a given router.

That's certainly your choice; it doesn't map to any address f= ormat in the spec; 2.5.6 very specifically sets those bits to zero in a lin= k-local address (I would argue it should therefore specify the prefix as FE= 80::/64, not FE80::/10). How do the hosts know what VLAN they are on? That&= #39;s generally either information known by the switch and used on trunk po= rts, or configured data. The host generally has no idea what VLAN it's = on. Recall that link-local addresses are what the device develops before it= has any knowledge of the world around it.

> ensuring unique FE80s from a given host would be enormously less confu= sing when looking at and comparing wireshark traces of the babel protocol, = for example. =A0( http://tools.ietf.org/html/rfc6126 )
>
> What's not clear to me after reading RFC4291 twice this morning is= that although a fe80:: is a /10, is if the bits above the interface id (as= per the above "XX:VLAN:") truly are legit to be used, or a modif= ied unique EUI-64 should be used.

What you're describing is essentially a site-local address, altho= ugh the format uses FEC0::/10. Did you read the part about site-local addre= sses (2.5.7)?

=A0 | =A0 10 =A0 =A0 |
=A0 | =A0bits =A0 =A0| =A0 =A0 =A0 =A0 54 bits =A0 =A0 =A0 =A0 | =A0 =A0 = =A0 =A0 64 bits =A0 =A0 =A0 =A0 =A0 =A0|
=A0 +----------+-------------------------+----------------------------+ =A0 |1111111011| =A0 =A0 =A0 =A0subnet ID =A0 =A0 =A0 =A0| =A0 =A0 =A0 int= erface ID =A0 =A0 =A0 =A0 |
=A0 +----------+-------------------------+----------------------------+
You have tried to specify the "Subnet ID" and use it as a link-lo= cal.

I'll suggest you read:

http://ww= w.ietf.org/rfc/rfc3879.txt
3879 Deprecating Site Local Addresses. C. Huitema, B. Carpenter.
=A0 =A0 September 2004. (Format: TXT=3D24142 bytes) (Status: PROPOSED STAN= DARD)
and
http://ww= w.ietf.org/rfc/rfc4193.txt
4193 Unique Local IPv6 Unicast Addresses. R. Hinden, B. Haberman.
=A0 =A0 October 2005. (Format: TXT=3D35908 bytes) (Status: PROPOSED STANDA= RD)

> A VLAN identifier is 12 bits in length, so the "V" portion o= f the above proposal could be dropped. (Not that I know how to extract the = vlan identifier from the interface anyway) XX would be used to distinguish = between interfaces that had no corresponding info but conflicted with addre= sses already on the router.
>
> I realize this is somewhat off topic for the bloat list, but I was try= ing to get where I could actually test the IPv6 ECN patches I'd folded = in across the routers(s) and running into trouble.

I actually think you would do well to join https://www.ietf.org/mailman= /listinfo/ipv6 and discuss it on ipv6@ietf.org.




--
Dave T=E4ht
SKYPE: d= avetaht
US Tel: 1-239-829-5608
http://the-edge.blogspot.com




--
Dave T=E4ht
SKYPE: davetaht
US Tel: 1-239-829= -5608
http://= the-edge.blogspot.com
--001636c925f218553004a2dc641a--