[rbridge] Global MAC Addresses

[Caitlin Bestler]

Eric Gray (LO/EUS) wrote:
> Caitlin,
> 
> 	Please see one comment in-line below...
> 
> 
>> -----Original Message-----
>> From: rbridge-bounces at postel.org
>> [mailto:rbridge-bounces at postel.org] On Behalf Of Caitlin Bestler
>> Sent: Tuesday, January 23, 2007 2:23 PM
>> To: rbridge at postel.org
>> Subject: [rbridge] Global MAC Addresses
>> 
>> Reading through draft-ietf-trill-rbridge-protocol-02 I can spot many
>> places where it is assumed that a globally unique
>> L2 identifier can only be formed by concatenating the VLAN ID and
>> the MAC Address. 
>> 
>> This may be a very realistic assessment, but it raises issues
>> concerning global scope IPv6 addresses derived from the MAC Address.
>> 
>> Has the IETF addressed the issues of "global" MAC Addresses that are
>> not global? In particular that IP routing should not be performed
>> between two subnets that have different concepts of what a "global"
>> MAC address is? 
>> 
> 
> This is not an issue.  IP Routers are L2 endstations at each
> LAN attachment point and can have locally unique MAC
> addresses in each LAN to which they are attached.  IP Routers
> (at least, when acting as routers) don't transparently
> forward MAC frames either.  Consequently, the MAC address (of
> an IP router) that is visible on any LAN is a MAC address
> that is appropriate for that LAN.
> 
> Consequently, there is no reason why "IP routing should not
> be performed between subnets that have different concepts of
> what a 'global' MAC adress is"...
> 

RFC3513 (IPV6 Addressing Architecture) states:

   Modified EUI-64 format based Interface identifiers may have global
   scope when derived from a global token (e.g., IEEE 802 48-bit MAC or
   IEEE EUI-64 identifiers [EUI64]) or may have local scope where a
   global token is not available (e.g., serial links, tunnel end-points,
   etc.) or where global tokens are undesirable (e.g., temporary tokens
   for privacy [PRIV]).

Effectively, the practice of treating each VLAN as being
totally independent means that even when the Interface ID is derived
from a global IEEE EUI-64 that in fact there is no "global token"
available.

At the minimum this is counter-intuitive and worthy of warnings.

My understanding of the relevant 802.1 definitions is that a global
MAC address *is* global, but that bridges are explicitly allowed
to keep per-VLAN data and not enforce global scoping. On the other
hand, they are allowed to do so. Effectively, you can have an
interoperable mix of bridges that do global MAC address learning
(where the VLAN-ID is an *attribute*) and per-VLAN MAC address
learning (where the VLAN-ID is a *key*).

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.

But to the best of my knowledge, no prior IETF document has
actually crossed this line. Which raises the need to clarify
the semantics of MAC-derived IPv6 addresses. Otherwise certain
network services might rely on these global addresses being
truly global and create problems.

For example, when I was working on CMTS (cable modem head
end equipment) the MAC addresses of the cable modems actually
were guaranteed to be unique. So if the same MAC address showed
up on a new frequency, or in a new location, it was either a 
clone or it indicated that the box had migrated (on frequency
and/or location). There was a need to determine which report
would be believed (generally the newer one) and to ignore or
remove the other.

That scenario obviously does not apply here, but could there
be others? Might a duplicate MAC address trigger a network
intrusion alert? Might a host assume that Link Local MAC X
for VLAN 3 and Link Local MAC X for VLAN 4 (where VLAN 3 and
VLAN 4 are on the same physical link) represent the same
device that has enabled itself for two VLANs?