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

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

[Dave Taht]

[-- Attachment #1: Type: text/plain, Size: 657 bytes --]

I am modestly stumped as to how to solve this properly. I think it's been
causing problems with ipv6 for a long time, but I could be wrong.

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

Basically although the underlying interfaces do have unique mac addresses
(for some reason the underlying eth0 interface is sharing a mac address with
the wlan0 interface??),

the bridged to a vlan fe80:: addresses are all the same. This strikes me as
a problem.

Is there a standard for renaming fe80:: addresses to represent they are
interfacing with different vlans?

-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://the-edge.blogspot.com

[-- Attachment #2: Type: text/html, Size: 819 bytes --]

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

[Fred Baker]

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
4291 IP Version 6 Addressing Architecture. R. Hinden, S. Deering.
     February 2006. (Format: TXT=52897 bytes) (Obsoletes RFC3513) (Updated
     by RFC5952, RFC6052) (Status: DRAFT STANDARD)

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

[Roland Bless]

Hi Dave,

On 09.05.2011 05:26, Dave Taht wrote:
> I am modestly stumped as to how to solve this properly. I think it's
> been causing problems with ipv6 for a long time, but I could be wrong.
> 
> see http://www.bufferbloat.net/issues/126
> 
> Basically although the underlying interfaces do have unique mac
> addresses (for some reason the underlying eth0 interface is sharing a
> mac address with the wlan0 interface??),
> the bridged to a vlan fe80:: addresses are all the same. This strikes me
> as a problem.

It seems that in these cases the ether/link address is also the same,
therefore the interfaces configure all the same link-local address.
Link local addresses are only unique with respect to their link,
i.e., usually you have to specify the interface in addition to the
fe80::/64 destination address, e.g., ping6 fe80::c63d:c7ff:fe8b:6e1a%vlan1

> Is there a standard for renaming fe80:: addresses to represent they are
> interfacing with different vlans?

Maybe that's the wrong question. What is the problem you are trying to
solve? Maybe link local addresses are not the right tool...

Regards,
 Roland

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

[Dave Taht]

[-- Attachment #1: Type: text/plain, Size: 3236 bytes --]

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.

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"

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.

Also:

Should the bridge itself have a unique link local over the underlying
interfaces?

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.

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.

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.

-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://the-edge.blogspot.com

[-- Attachment #2: Type: text/html, Size: 3870 bytes --]

Re: [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@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@ietf.org.

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

[Dave Taht]

[-- Attachment #1: Type: text/plain, Size: 6519 bytes --]

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@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? 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@ietf.org
> .
>
>


-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://the-edge.blogspot.com

[-- Attachment #2: Type: text/html, Size: 7890 bytes --]

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

[Fred Baker]

[-- Attachment #1: Type: text/plain, Size: 7054 bytes --]

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. From 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? 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@ietf.org.
> 
> 
> 
> 
> -- 
> Dave Täht
> SKYPE: davetaht
> US Tel: 1-239-829-5608
> http://the-edge.blogspot.com 


[-- Attachment #2: Type: text/html, Size: 9049 bytes --]

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

[Dave Taht]

[-- Attachment #1: Type: text/plain, Size: 10007 bytes --]

On Mon, May 9, 2011 at 10:44 AM, Fred Baker <fred@cisco.com> wrote:

> BTW, every time I post nowadays, I get moderated on bismark-devel. Do you
> think you could grandfather bloat@ emails?
>
>
I've added you to the bismark-devel list and set nomail on.


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

A bridge in this case is a switch that spans multiple switched interfaces,
so for example, eth0.1 is bridged to wlan0 and wlan1 (2.4ghz and 5.x ghz)

and eth0.2 is bridged to wlan2 and wlan3.

Theoretically eth0.1 and eth0.2 are vlans but this may be the source of my
problems, more on that in a bit.

Most home routers are not pure routers in any shape or form - they "route"
to the internet, but "bridge" to their local wired and wireless interfaces.

The reasons for this are historical, and not strictly necessary anymore (in
fact I vastly prefer pure routing to bridging as it makes security easier
and multicast both saner (from a performance standpoint) and slightly
harder).

But the "bridged wired/wireless" idea is deeply embedded in the marketplace.

Historically simple dhcp servers had difficulty with multiple interfaces,
and multicast (things like multicast dns) just plain didn't work properly in
the case of routing.

So if you attach to your home lan you would generally get on the IPv4 subnet
no matter if you got on via wired or any of multiple wireless interfaces,
because they were bridged into one "br-lan" interface.

Using IPv4 subnets for each of your interfaces would be a better choice
nowadays if it wasn't for the multicast and routing problems. I have no idea
of igmp works at all these days.

And then that also leaves the routing problem. Nobody's ever been able to
agree on a standard routing protocol for simple home use.






> From 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"?
>

Hopefully the above makes it more clear.


After puzzling over this some more, I think the root of the problem is that
while wlan0-wlan5 autogenerate unique mac addresses, eth0.1 and eth0.2 etc
do not...

and the bridging code picks up on the first (wired) interface to generate
it's fe80:: addresses, making them all be the same, instead of the
underlying wlan mac addr.

So if I can figure out a way to have the bridge code pick up on the wlanX
mac addresses rather than the eth0.X mac address I think life will be
sweeter. This would eliminate the need to fiddle with the upper 54 bits of a
fe80 address (which looks illegal according to the standard)

Or I can go to pure routing of both ipv4 and ipv6 traffic across each
distinct interface, but...


>
> It's really hard to comment on a random output without any statement of
> configuration or intent.
>
>
Trying to create a home router that "does the right thing" for ipv4 AND
ipv6, with local secured, guest, and mesh interfaces.


> 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? 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@ietf.org.
>>
>>
>
>
> --
> Dave Täht
> SKYPE: davetaht
> US Tel: 1-239-829-5608
> http://the-edge.blogspot.com
>
>
>


-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://the-edge.blogspot.com

[-- Attachment #2: Type: text/html, Size: 13262 bytes --]

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

[Jeremy Visser]

Dave Taht said:
> the bridged to a vlan fe80:: addresses are all the same. This strikes me
> as a problem.

You never reference link-local address by themselves anyway — they are
always referenced with their scope ID for context. So your addresses are
unique after all:

fe80::c63d:c7ff:fe8b:6e1a%br-lan
fe80::c63d:c7ff:fe8b:6e1a%br-guest
fe80::c63d:c7ff:fe8b:6e1a%br-meshlink1
fe80::c63d:c7ff:fe8b:6e1a%br-meshlink2

Forgive me if I am stating the obvious or misunderstanding your point.

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

[Dave Taht]

[-- Attachment #1: Type: text/plain, Size: 1172 bytes --]

On Tue, May 10, 2011 at 8:30 AM, Jeremy Visser <jeremy@visser.name> wrote:

> Dave Taht said:
> > the bridged to a vlan fe80:: addresses are all the same. This strikes me
> > as a problem.
>
> You never reference link-local address by themselves anyway — they are
> always referenced with their scope ID for context. So your addresses are
> unique after all:
>
> fe80::c63d:c7ff:fe8b:6e1a%br-lan
> fe80::c63d:c7ff:fe8b:6e1a%br-guest
> fe80::c63d:c7ff:fe8b:6e1a%br-meshlink1
> fe80::c63d:c7ff:fe8b:6e1a%br-meshlink2
>

1) in a wireshark analysis, the %interface part is lost
2) we have 2^64 possible choices for fe80 addresses. I don't see what having
them all be the same buys me.
3) It worries me in the babel routing protocol
4) My bridges are misbehaving over ipv6 in the general case and I'm willing
to grasp at straws.


> Forgive me if I am stating the obvious or misunderstanding your point.
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
>



-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://the-edge.blogspot.com

[-- Attachment #2: Type: text/html, Size: 1876 bytes --]

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

[Roland Bless]

Hi Dave,

On 11.05.2011 05:32, Dave Taht wrote:
> 1) in a wireshark analysis, the %interface part is lost

But your wireshark is listening on some specific interface,
isn't it? This interface is your context then and link locals are
unique on that particular link (which is assured by
Duplicate Address Detection). Are you facing the problem from the
switch's perspective (e.g., that you can determine the receiving
i/f from the destination address of received packets) or from another
another device's perspective?

> 2) we have 2^64 possible choices for fe80 addresses. I don't see what
> having them all be the same buys me.

You can assign an individual fe80:: address to an interface, e.g.,
fe80::b101 for bridge one interface 1,  fe80::b102 bridge one
interface 2 etc. if that helps. But be aware that it may create
address collisions in case you have two such bridges on the same
link :-( Therefore, using (modified) EUI-64 addresses within the
64-bit seems to be a good choice.

> 3) It worries me in the babel routing protocol

Sorry, I didn't study the spec so far. What is the
particular problem there? Maybe there is a problem
with the assumptions in the protocol.

> 4) My bridges are misbehaving over ipv6 in the general case and I'm
> willing to grasp at straws.

What is that misbehavior? That a bridge is using the same link local
address on each of its links? That's ok as long as its unique on that
particular on-link subnet.

Regards,
 Roland

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

[Dave Taht]

[-- Attachment #1: Type: text/plain, Size: 4422 bytes --]

On Tue, May 10, 2011 at 10:40 PM, Roland Bless <roland.bless@kit.edu> wrote:

> Hi Dave,
>
> On 11.05.2011 05:32, Dave Taht wrote:
> > 1) in a wireshark analysis, the %interface part is lost
>
> But your wireshark is listening on some specific interface,
> isn't it?


No. It is listening on the wildcard interface. Of which there are 8.


> This interface is your context then and link locals are
> unique on that particular link (which is assured by
> Duplicate Address Detection).


I wouldn't be so sure in the case of link-local addresses and vlans and
bridges. At least: I'm no longer sure...

After digging into the code in openwrt (very) late last night I spotted this
in base-files/files/lib/network/config.sh

                   config_get macaddr "$config" macaddr
                        [ -x /usr/sbin/brctl ] && {
                                ifconfig "br-$config" 2>/dev/null >/dev/null
&& {
                                        local newdevs devices
                                        config_get devices "$config" device
                                        for dev in $(sort_list "$devices"
"$iface"); do
                                                append newdevs "$dev"
                                        done
                                        uci_set_state network "$config"
device "$newdevs"
                                        $DEBUG ifconfig "$iface" 0.0.0.0
                                        $DEBUG do_sysctl
"net.ipv6.conf.$iface.disable_ipv6" 1
                                        $DEBUG brctl addif "br-$config"
"$iface"
                                        # Bridge existed already. No further
processing necesary
                                } || {
                                        local stp
                                        config_get_bool stp "$config" stp 0
                                        $DEBUG brctl addbr "br-$config"
                                        $DEBUG brctl setfd "br-$config" 0
                                        $DEBUG ifconfig "$iface" 0.0.0.0
                                        $DEBUG do_sysctl
"net.ipv6.conf.$iface.disable_ipv6" 1
                                        $DEBUG brctl addif "br-$config"
"$iface"
                                        $DEBUG brctl stp "br-$config" $stp
                                        $DEBUG ifconfig "br-$config" up

it looks like I can "prepend" rather than "append" in order to get the wlan*
interface first in the bridge (rather than eth*), or defer bridge creation
until the other interfaces are brought up....

Each wlan has a unique MAC id, and thus I hope will create a unique bridge
id EUI-64.

And as for why it disables ipv6 on the underlying interface...



> Are you facing the problem from the
> switch's perspective (e.g., that you can determine the receiving
> i/f from the destination address of received packets) or from another
> another device's perspective?
>
> routers' perspective.


> > 2) we have 2^64 possible choices for fe80 addresses. I don't see what
> > having them all be the same buys me.
>
> You can assign an individual fe80:: address to an interface, e.g.,
> fe80::b101 for bridge one interface 1,  fe80::b102 bridge one
> interface 2 etc. if that helps. But be aware that it may create
> address collisions in case you have two such bridges on the same
> link :-( Therefore, using (modified) EUI-64 addresses within the
> 64-bit seems to be a good choice.
>
>
I think using ::b101 is a bad idea. EUI-64 is the way to go. I wanted to use
up the extra 52 bits though in some sane manner....


> > 3) It worries me in the babel routing protocol
>
> Sorry, I didn't study the spec so far. What is the
> particular problem there? Maybe there is a problem
> with the assumptions in the protocol.
>
>
It's a new RFC. Could be. It's a neat protocol tho.


> > 4) My bridges are misbehaving over ipv6 in the general case and I'm
> > willing to grasp at straws.
>
> What is that misbehavior? That a bridge is using the same link local
> address on each of its links? That's ok as long as its unique on that
> particular on-link subnet.
>
>
They be misbehaving - multicast weirdnesses.


> Regards,
>  Roland
>



-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://the-edge.blogspot.com

[-- Attachment #2: Type: text/html, Size: 6368 bytes --]

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

[Rick Jones]

On Wed, 2011-05-11 at 07:46 -0600, Dave Taht wrote:
> 
> 
> On Tue, May 10, 2011 at 10:40 PM, Roland Bless <roland.bless@kit.edu>
> wrote:
>         Hi Dave,
>         
>         On 11.05.2011 05:32, Dave Taht wrote:
>         > 1) in a wireshark analysis, the %interface part is lost
>         
>         
>         But your wireshark is listening on some specific interface,
>         isn't it? 
> 
> No. It is listening on the wildcard interface. Of which there are 8.

Doesn't the pcap header identify the interface in that case?

There is also still the issue (perhaps) of sampled traffic (eg sFlow)
which will have only what was on the wire at the sample point.  Although
presumably there will be some way (not necessarily easy) to work one's
way back through the switch hierarchy to see which host egress port must
have been used since link-local have to be unique with the broadcast
domain and won't traverse a router.

rick jones