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 60163201A4B; Mon, 9 May 2011 09:08:18 -0700 (PDT) Received: by iyi20 with SMTP id 20so6872918iyi.16 for ; Mon, 09 May 2011 09:14:42 -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=nonA/jAKMNJmrcQnITYV/79oKNiVgFlv5ZVQzRkEvi0=; b=tvpC00wCyyDDlQTtSXAwrVmBiO5gqztZ9xTNGGuoVDuoma821fyJ9W7J6HbypK4WDl 72hblW/8Fw7x6SSO7wHhfGy3Vjv8wwhWVT5sOHP/+oDy/1oswMG+9umzv1Xk3xd/hNM3 6qgHoA0nZJyIpu/Rt5QsLvr150wQJX64ws0dI= 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=xxrVVZXuTi5h73IUzigA54Usxg+X2fVwKOs6QgledXAS77ZlsPwAFI5C6t+VfKWWUY xSeKn3kYYW8SfCleclYIzdEbtGaE0dFnLL0mHswEjwCsTPJw9D7lSczjRD3vuTdxIofg FrmsIJAIbh9EEIAgV2/+lOJTPsOZI7e3onHrg= MIME-Version: 1.0 Received: by 10.43.47.195 with SMTP id ut3mr6168593icb.426.1304957681953; Mon, 09 May 2011 09:14:41 -0700 (PDT) Received: by 10.231.31.201 with HTTP; Mon, 9 May 2011 09:14:41 -0700 (PDT) In-Reply-To: <6C99CF5C-88E9-4F38-9C11-CF75DD83E965@cisco.com> References: <1A32BF60-18B3-44C3-9908-4225B33E8EFD@cisco.com> <6C99CF5C-88E9-4F38-9C11-CF75DD83E965@cisco.com> Date: Mon, 9 May 2011 10:14:41 -0600 Message-ID: From: Dave Taht To: Fred Baker Content-Type: multipart/alternative; boundary=bcaec52995911469bf04a2da23d6 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 16:08:18 -0000 --bcaec52995911469bf04a2da23d6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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. 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 subn= et > 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 cal= l. > 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. Interface Identifiers > > > > Interface identifiers in IPv6 unicast addresses are used to identify > > interfaces on a link. They are required to be unique within a subne= t > > 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" > > 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 t= he > 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 tha= n > "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, II= Ds > "are required to be unique within a subnet prefix" per the text you quote= d > 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 the > 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::/6= 4, > 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. 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 > 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. > > 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 STANDAR= D) > 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 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 tryi= ng > to get where I could actually test the IPv6 ECN patches I'd folded in acr= oss > 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.or= g > . > > --=20 Dave T=E4ht SKYPE: davetaht US Tel: 1-239-829-5608 http://the-edge.blogspot.com --bcaec52995911469bf04a2da23d6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Fred/all

See

http://www.bufferbloat.net/issues/126

which has a ip -6 addr a= nd ifconfig dump

and see if that "seems right" to you.

On Mon, May 9, 2011 at 9:57 AM, Fred Baker <= span dir=3D"ltr"><fred@cisco.com&g= t; 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
--bcaec52995911469bf04a2da23d6--