[Bismark-devel] [Bloat] ipv6 fe80:: addresses, vlans and bridges... borked?

[Fred Baker]

On May 9, 2011, at 7:59 AM, Dave Taht wrote:
> On Mon, May 9, 2011 at 2:14 AM, Fred Baker <fred at 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? From 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=24142 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=35908 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 at ietf.org.