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 41775201A81; Mon, 9 May 2011 07:53:08 -0700 (PDT) Received: by iwn8 with SMTP id 8so6723575iwn.16 for ; Mon, 09 May 2011 07:59:31 -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=fWz5CR7afWQiD6V3nTafELTxBC/bsCpm5F1bBlkuXA4=; b=KbfiQcHJJu4XDHk7TEGpz9nPXD0rpTa6IZAnNhNER28v+Gzl5oSXclRELTMz9CyWMV Cbn5WN9UhAj/KGIUiHvk00u1Md/PWACSWbx7EtzekjWzBuzz0g/v2Eg48qYfJWCyYzZR 8GkI5fkz3aSaYd7Xu2UgAl9jn9qvubL6c+EWA= 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=nz1rsFmToPP9VxyaP/KJ5YMZeSMVNAdGXcraeEhRSSxi9IAUHKJQPJ2ryy0RDcu9E5 6Xiarek35aEwlmQ4Oa5K0v6saxbtdFuZKXtB0f2DsQgBvAb6I5QLJTT+bQ/4M+gS24TR +M9Ji5VLtcZAqdsP2FJdhjB6IIITXItxOs2VA= MIME-Version: 1.0 Received: by 10.42.131.71 with SMTP id y7mr6387650ics.292.1304953171479; Mon, 09 May 2011 07:59:31 -0700 (PDT) Received: by 10.231.31.201 with HTTP; Mon, 9 May 2011 07:59:31 -0700 (PDT) In-Reply-To: <1A32BF60-18B3-44C3-9908-4225B33E8EFD@cisco.com> References: <1A32BF60-18B3-44C3-9908-4225B33E8EFD@cisco.com> Date: Mon, 9 May 2011 08:59:31 -0600 Message-ID: From: Dave Taht To: Fred Baker Content-Type: multipart/alternative; boundary=90e6ba2121733c0bd004a2d9163a 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 14:53:09 -0000 --90e6ba2121733c0bd004a2d9163a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 onl= y > in the LAN in question. The usual approach is to give the LAN a subnet > prefix. The standard is RFC 4291. > > http://www.ietf.org/rfc/rfc4291.txt > So, there isn't a standard for using vlans and ipv6. aformentioned RFC: 2.5.1. Interface Identifiers Interface identifiers in IPv6 unicast addresses are used to identify interfaces on a link. They are required to be unique within a subnet prefix. It is recommended that the same interface identifier not be assigned to different nodes on a link. They may also be unique over a broader scope. In some cases, an interface's identifier will be derived directly from that interface's link-layer address. The same 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 to different nodes on a link" vs "The same interface identifier may be used on multiple interfaces on a sing= le 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. Also: Should the bridge itself have a unique link local over the underlying interfaces? 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. 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 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 modified unique EUI-64 should be used. A VLAN identifier is 12 bits in length, so the "V" portion of 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 addresses already on the router. I realize this is somewhat off topic for the bloat list, but I was trying t= o get where I could actually test the IPv6 ECN patches I'd folded in across the routers(s) and running into trouble. --=20 Dave T=E4ht SKYPE: davetaht US Tel: 1-239-829-5608 http://the-edge.blogspot.com --90e6ba2121733c0bd004a2d9163a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Mon, May 9, 2011 at 2:14 AM, Fred Bak= er <fred@cisco.com> wrote:

On May 8, 2011, at 8:26 PM, Dave Taht wrote:

> Is there a standard for renaming fe80:: addresses to represent they ar= e 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 subne= t prefix. The standard is RFC 4291.

http://ww= w.ietf.org/rfc/rfc4291.txt

So, there isn't a standard for using vlans and i= pv6.

aformentioned RFC:

2.5.1.  Interface Identifiers
   Interface identifiers in IPv6 unicast addresses are used to identi=
fy

   interfaces on a link.  They are required to be unique within a subnet   prefix.  It is recommended that the same interface identifier not be   assigned to different nodes on a link.  They may also be unique over
   a broader scope.  In some cases, an interface's identifier will be   derived directly from that interface's link-layer address.  The sa=
me
   interface identifier may be used on multiple interfaces on a singl=
e

   node, as long as they are attached to different subnets.
"= It is recomended that the same interface identifier not be assigned to diff= erent nodes on a link"

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 ap= proach. This strikes me as error prone - and further does not discuss the e= ffects 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 sche= me (ethX.Y) suggests they are. And a typical user might plug two different = lans together on one cable anyway.

Also:

Should the bridge itself have a unique link local over th= e underlying interfaces?

Given that we have a profusion of numbers a= vailable for link-local addresses, I can see no harm and much gain in *alwa= ys* constructing a verify-ably unique fe80::XX:VLAN:EUI-64/64 prefix on a p= er-interface and per-virtual-interface basis on a given router.

ensuring unique FE80s from a given host would be enormously less confus= ing when looking at and comparing wireshark traces of the babel protocol, f= or example.=A0 ( http://t= ools.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 modifi= ed unique EUI-64 should be used.

A VLAN identifier is 12 bits in length, so the "V" portion of= the above proposal could be dropped. (Not that I know how to extract the v= lan identifier from the interface anyway) XX would be used to distinguish b= etween interfaces that had no corresponding info but conflicted with addres= ses already on the router.

I realize this is somewhat off topic for the bloat list, but I was tryi= ng to get where I could actually test the IPv6 ECN patches I'd folded i= n across the routers(s) and running into trouble.

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