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 6281E200ADD; Mon, 9 May 2011 08:50:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=6155; q=dns/txt; s=iport; t=1304956643; x=1306166243; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=i+7vbWabijnk4+p/EMwSwB1j04mE8YtXVOO6Ggt4OXk=; b=iMI5YPu/R0IBq9FzDwSAHBVL4QD/fEYe8tO8LzAqTrILD+M9DA7rTAEq BdFkdCGyxxfmiQbFi8OGtCovcYeH2+z5m3aabUiS1+WZMQOZx6/Rik78U 9BHLffz0Zm6k5k5sOT2ydSTHyMcYgbFfEoearURBrA1y4zvvWDRu3iK4o g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAH4OyE2rRDoG/2dsb2JhbAClf3eIcaAznXCDDIMABIZAiSWEKIpV X-IronPort-AV: E=Sophos;i="4.64,341,1301875200"; d="scan'208";a="444293086" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-1.cisco.com with ESMTP; 09 May 2011 15:57:23 +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 p49FvHO9025707; Mon, 9 May 2011 15:57:22 GMT Received: from [127.0.0.1] by stealth-10-32-244-222.cisco.com (PGP Universal service); Mon, 09 May 2011 08:57:22 -0700 X-PGP-Universal: processed; by stealth-10-32-244-222.cisco.com on Mon, 09 May 2011 08:57:22 -0700 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: Date: Mon, 9 May 2011 08:57:06 -0700 Message-Id: <6C99CF5C-88E9-4F38-9C11-CF75DD83E965@cisco.com> References: <1A32BF60-18B3-44C3-9908-4225B33E8EFD@cisco.com> To: Dave Taht X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable 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 15:50:59 -0000 On May 9, 2011, at 7:59 AM, Dave Taht wrote: > On Mon, May 9, 2011 at 2:14 AM, Fred Baker wrote: >=20 > 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? >>=20 >> 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. >>=20 >> http://www.ietf.org/rfc/rfc4291.txt >>=20 > 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. > aformentioned RFC: >=20 > 2.5.1. Interface Identifiers >=20 > 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. >=20 > "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."=20 > vs >=20 > "The same interface identifier may be used on multiple interfaces on a = single > node, as long as they are attached to different subnets." >=20 >=20 > 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. >=20 > 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". > Also: >=20 > 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.=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. > 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 ) >=20 > 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.=20 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.=20 >=20 > 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.