From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "sj-iport-1.cisco.com", Issuer "Cisco SSCA" (not verified)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 0A2F0201323; Mon, 9 May 2011 09:38:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=17021; q=dns/txt; s=iport; t=1304959485; x=1306169085; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=8kcbxBC21zivAUZjk7Nt1zggOLUO9f9uqUGeJMz5szk=; b=f6SUNr/Ajhw2I6ZqjUFTQSrUconuHIh5+SxaueP9fTyl4y8YW2ZWLA8c Mv5DLb7vEDX/LRZyJy+VXj8jP0TAxK96MybqQhXkKH5RY+WXw3JgS0nSc R6CZtoay4JxThhVF0h0TX3BveGCivuW/v/KJ23BaFTg7Fg0mud/M6VJrC E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAPwYyE2rRDoG/2dsb2JhbACeO4dFd4hxoE2deoMMGoJmBIZAiSWEKIpV X-IronPort-AV: E=Sophos;i="4.64,341,1301875200"; d="scan'208,217";a="444326398" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-1.cisco.com with ESMTP; 09 May 2011 16:44:44 +0000 Received: from stealth-10-32-244-222.cisco.com (stealth-10-32-244-222.cisco.com [10.32.244.222]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p49Giceb007228; Mon, 9 May 2011 16:44:43 GMT Received: from [127.0.0.1] by stealth-10-32-244-222.cisco.com (PGP Universal service); Mon, 09 May 2011 09:44:44 -0700 X-PGP-Universal: processed; by stealth-10-32-244-222.cisco.com on Mon, 09 May 2011 09:44:44 -0700 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: Date: Mon, 9 May 2011 09:44:28 -0700 Message-Id: References: <1A32BF60-18B3-44C3-9908-4225B33E8EFD@cisco.com> <6C99CF5C-88E9-4F38-9C11-CF75DD83E965@cisco.com> To: Dave Taht X-Mailer: Apple Mail (2.1084) Content-Type: multipart/alternative; boundary=Apple-Mail-137-234753835 X-Mailman-Approved-At: Mon, 09 May 2011 09:39:02 -0700 Cc: bismark-devel@lists.bufferbloat.net, bloat Subject: Re: [Bismark-devel] [Bloat] ipv6 fe80:: addresses, vlans and bridges... borked? X-BeenThere: bismark-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: BISMark related software development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2011 16:38:20 -0000 --Apple-Mail-137-234753835 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 BTW, every time I post nowadays, I get moderated on bismark-devel. Do = you think you could grandfather bloat@ emails? On May 9, 2011, at 9:14 AM, Dave Taht wrote: > Fred/all >=20 > See >=20 > http://www.bufferbloat.net/issues/126 >=20 > which has a ip -6 addr and ifconfig dump >=20 > 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. =46rom 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 of anything - = it's simply an interface-multihomed host. What are you calling a = "bridge"? It's really hard to comment on a random output without any statement of = configuration or intent.=20 > On Mon, May 9, 2011 at 9:57 AM, Fred Baker wrote: >=20 > 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 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. >=20 > 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. >=20 > > 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" >=20 > 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." >=20 > > 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. >=20 > 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? =46rom a requirements perspective, "may" = is a lot weaker than "required". >=20 > > Also: > > > > Should the bridge itself have a unique link local over the = underlying interfaces? >=20 > 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, = IIDs "are required to be unique within a subnet prefix" per the text you = quoted above. >=20 > > 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. >=20 > 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::/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. Recall that link-local addresses are what the device = develops before it has any knowledge of the world around it. >=20 > > 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. >=20 > 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)? >=20 > | 10 | > | bits | 54 bits | 64 bits | > +----------+-------------------------+----------------------------+ > |1111111011| subnet ID | interface ID | > +----------+-------------------------+----------------------------+ >=20 > You have tried to specify the "Subnet ID" and use it as a link-local. >=20 > I'll suggest you read: >=20 > http://www.ietf.org/rfc/rfc3879.txt > 3879 Deprecating Site Local Addresses. C. Huitema, B. Carpenter. > September 2004. (Format: TXT=3D24142 bytes) (Status: PROPOSED = STANDARD) > 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) >=20 > > 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 to get where I could actually test the IPv6 ECN patches I'd = folded in across the routers(s) and running into trouble. >=20 > I actually think you would do well to join = https://www.ietf.org/mailman/listinfo/ipv6 and discuss it on = ipv6@ietf.org. >=20 >=20 >=20 >=20 > --=20 > Dave T=E4ht > SKYPE: davetaht > US Tel: 1-239-829-5608 > http://the-edge.blogspot.com=20 --Apple-Mail-137-234753835 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 BTW, = every time I post nowadays, I get moderated on bismark-devel. Do you = think you could grandfather bloat@ = emails?

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. =46rom = 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 = of anything - it's simply an interface-multihomed host. What are you = calling a "bridge"?

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

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 = 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 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.

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.  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"

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? =46rom a requirements perspective, = "may" is a lot weaker 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 same 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 = 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::/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. 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 STANDARD)
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 = trying 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: = davetaht
US Tel: 1-239-829-5608
http://the-edge.blogspot.com

= --Apple-Mail-137-234753835--