Subject: [rbridge] Global MAC Addresses

From: jjoslin at belairnetworks.com (Jeff Joslin)
Date: Wed, 14 Feb 2007 09:44:19 -0500

I am coming late to the party, but SVL and IVL (i.e., Shared/Independent
VLAN Learning) are subjects where I have learned lessons the hard way.

SVL was introduced during the 802.1Q standardization process as a kludge
that allowed existing hardware to achieve some level of VLAN support.
SVL uses the same forwarding-table format as non-VLAN-aware bridges, but
after choosing the destination port for a frame, the bridge does an
additional lookup to verify that the destination port belongs to the
VLAN indicated on the frame. In contrast, IVL uses the (VLAN,DA) pair to
find the destination port.

SVL and IVL behave differently in two cases:
1. Devices that use the 

> -----Original Message-----
> From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org]
On
> Behalf Of Eric Gray (LO/EUS)
> Sent: 25 January 2007 7:42 PM
> To: Caitlin Bestler
> Cc: rbridge at postel.org
> Subject: Re: [rbridge] Global MAC Addresses
> 
> Caitlin,
> 
> 	I assume we are still talking about the -02 version of the
> base protocol specification.  In that document, I could not find
> any text that looked remotely like it was saying what you point
> out below.
> 
> 	I chatted briefly with one of the VLAN experts here at the
> IEEE 802.1 meeting earlier and it seems that there is a mode of
> operation (called "shared learning" or "shared VLAN learning")
> where it is possible for VLAN bridges to learn MAC addresses for
> multiple VLANs when they are heard on any of those VLANs.
> 
> 	I do not know the details of how this is configured, but
> from a preliminary sort of "poking around" it looks like it is
> configured by making multiple VLANs part of a group for shared
> VLAN learning.  So, apparently, the default is individual (or
> independent - depending on who you talk to) VLAN learning.
> 
> 	It also looks like VLAN learning and forwarding in general
> does not use quite the same logical model that you've described.
> As I said above, I haven't actually seen anywhere in the protocol
> specification that expresses a VLAN learning and forwarding model
> as you've described it, but it is possible that it does and - if
> it does - that seems to be incorrect.
> 
> 	Apparently, the VLAN learning and forwarding model uses the
> concatenation - not of VLAN ID and MAC DA - but of FID and MAC DA
> (where FID - forwarding database ID - MAY be the same for multiple
> VLANs).  Since this is a description of how a forwarding decision
> is made within an implementation, its value as a model is only to
> explain what is expected from implementations in terms of external
> visible behavior (meaning it doesn't have to actually be done that
> way, it just has to look like it is).
> 
> 	If the protocol specification describes a different model,
> it may lead to confusion.  However, I did not see any place where
> it clearly does.  For example, the statement "frame must be not be
> delivered to links in any VLAN other than the one to which they
> are addressed" is compatible with either learning mode - unless a
> broken learning mode was selected for a specific VLAN deployment.
> 
> 	Probably the most important reason why forwarding entries
> MUST be scoped in some way in VLAN bridging is to prevent one or
> more attackers from gaining access to VLANs they are not part of
> by using MAC addresses directly.
> 
> 	Finally, in order for an IPv6 address to be invalid in a
> global context as a result of deriving it from a MAC address is
> if more than one instance of the same MAC address exists within
> the same network prefix.  If the network prefixes are different,
> then the IPv6 addresses will be different.  Hence the only time
> you can have a problem with IPv6 addresses derived in this way,
> is if the MAC addresses are not even locally unique.
> 
> 	Interstingly enough, I am really sure that the IPv6 folks
> have looked at this before.  And I am also sure that at least one
> suggested solution has been considered.  I do not know if any (of
> possibly many) proposals were actually adopted but, if none were,
> it would be because the IPv6 people did not see this as a problem.
> 
> --
> Eric
> 
> > -----Original Message-----
> > From: Caitlin Bestler [mailto:caitlinb at broadcom.com]
> > Sent: Thursday, January 25, 2007 3:51 PM
> > To: Eric Gray (LO/EUS)
> > Cc: rbridge at postel.org
> > Subject: RE: [rbridge] Global MAC Addresses
> >
> > Eric Gray (LO/EUS) wrote:
> >
> > >
> > >>
> > >> Without explicitly stating it, the current draft recognizes that
> > >> because RBridges *share* data amongst themselves that they
> > will find
> > >> it challenging to do so without sharing semantics as well.
> > >> Having RBridges disagree on whether the VLAN-ID is a key
> > field or an
> > >> attribute field could create some interesting problems.
> > >> And there is certainly strong rationale for standardizing on the
> > >> VLAN-ID as key field approach.
> > >
> > > Agreed.  A specification draft cannot be ambivalent on issues
> > > of this nature.
> > >
> > > Are you saying that is what is happening here?  Can you give
> > > specific text examples where this is happening?
> > >
> >
> > If RBridge R learns of MAC X on VLAN Y that information is
explicitly
> > NOT forwarded to RBridge S unless RBridge S is not part of VLAN Y.
> >
> > If RBridge S has MAC X as belonging to VLAN Z then we would have
> > a conflict if either of the RBridges considered the "L2 Key" to
> > be just the MAC address. Nominally global IPv6 addresses which
> > actually reach *different* destinations.
> >
> > Such conflicts were much more benign when bridges merely forwarded
> > packets and didn't forward location data.
> >
> > There enumeration of RBridge retained data also states that L2
> > and L2/L3 tracking data is per-VLAN.
> >
> > The justification for this is that "global" MAC addresses are in
> > fact not global. That's counter-intuitive enough that I think it
> > at least needs to be explicitly noted.
> >
> >
> >
> >
> 
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge

---

From: jjoslin at belairnetworks.com (Jeff Joslin)
Date: Wed, 14 Feb 2007 09:52:05 -0500

Woops, hit Send by mistake. 

SVL and IVL behave differently in two cases:
1. Devices that use the same MAC address on different physical ports.
Sun workstations did this until relatively recently.

2. Certain fancy network devices change VLAN IDs. One example
application is a bridge that intercepts all inter-host communications
(i.e., communications not between a host and a router), applies
filtering rules, and forwards any passed frames on a different VLAN.

In both these (admittedly obscure) cases, SVL does the Wrong Thing. It
also opens a security hole that allows clever attackers to access VLANs
to which they should not have access. Despite all this, modern Ethernet
switch processors often support SVL mode. I can only assume this is
because the chip designers implemented the spec without really
understanding it.

I am not really sure what this means for Rbridges, except that we should
expect to encounter SVL bridges in the wild, but we should most
definitely not optimize for them.

Jeff

> From: Jeff Joslin
> Sent: 14 February 2007 9:44 AM
> To: rbridge at postel.org
SVL
> uses the same forwarding-table format as non-VLAN-aware bridges, but
after
> choosing the destination port for a frame, the bridge does an
additional
> lookup to verify that the destination port belongs to the VLAN
indicated
> on the frame. In contrast, IVL uses the (VLAN,DA) pair to find the
> destination port.
> 
On
explicitly