[rbridge] Global MAC Addresses

[Radia Perlman]

I think I understand the issue Caitlin is raising. MAC addresses might 
not be globally unique, and
therefore some applications that depend on it might
fail in weird ways, (such as IP with addresses derived from MAC addresses).

I don't think this is really a problem within RBridges. I do not think 
RBridges should try to enforce uniqueness, or
flag duplicates, by trying to compare endnode data on different VLANs.

I think this problem (potential nonuniqueness of MAC addresses) should 
be addressed within the context in
which it actually causes a problem, and RBridges should just ignore the 
issue. Within a VLAN if a MAC
address appears twice, an RBridge could

a) assume the endnode is multiply connected, and not worry about it at all
b) have Designated RBridge R1 "worry" if endnode E, which R1 thinks is 
on R1's own link, gets announced
by R2 as being connected to R2, and have R1 ping E in some way, and 
periodically, to reassure R1 that
E is still connected. RBridges other than R1 or R2 will treat E as 
reachable via either R1 or R2.
c) and/or log the fact that E seems to be multiply connected.

Other than potentially doing b) or c), I don't see what else an RBridge 
should do in this case.

Radia



Caitlin Bestler wrote:

>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?
>
>
>_______________________________________________
>rbridge mailing list
>rbridge at postel.org
>http://mailman.postel.org/mailman/listinfo/rbridge
>  
>