[rbridge] Global MAC Addresses

[Eric Gray (LO/EUS)]

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