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

Mon May 9 12:14:41 EDT 2011

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 <fred at 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 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
> .
>
>

-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://the-edge.blogspot.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/bloat/attachments/20110509/4550973b/attachment-0003.html>