[rbridge] Global MAC Addresses

[Eric Gray (LO/EUS)]

Caitlin,

	As a general observation, my previous reply was intended
only to address the questions in your third paragraph.  I did
not see that there was anything to address in you comments on
concatenating VLAN + MAC or derivation of globally unique IPv6
addresses from potentially locally unique L2 addresses.

	Please see additional comments below...

--
Eric

> -----Original Message-----
> From: Caitlin Bestler [mailto:caitlinb at broadcom.com] 
> Sent: Wednesday, January 24, 2007 11:40 AM
> To: Eric Gray (LO/EUS)
> Cc: rbridge at postel.org
> Subject: RE: [rbridge] Global MAC Addresses
> 
> 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]).

Note the liberal use of the word "may".  I believe that - if you
check with the IPv6 experts - you'll find that nobody assumes a
MAC address MUST be unique.

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

It's possibly misleading to refer to the treatment of VLANs 
as "being totally independent" as a "practice".

The behavior that distinguishes VLAN forwarding from bridge
forwarding is the use of concatenated VLAN + MAC.  It is 
also possible that other information may be used as well.

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

I suspect that you agree that it is not necessary for TRILL to
include such warnings as they belong to the definition of VLAN
as defined in appropriate SDO(s).  TRILL is not redefining the
term VLAN, as far as I know, in any way that produces this as 
a new problem.

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

You may be right, but I suspect that it is only previously existing 
bridges that are "allowed" to ignore per-VLAN forwarding information
and that so-called VLAN-aware bridges are in fact encouraged (if not
actually required) to derive and/or retain per-VLAN forwarding data
- explicitly assuming that MAC addresses are scoped by VLAN.

If they don't, then there are plenty of scenarios in which VLANs 
may not work correctly.

This is true - for example - where VLAN IDs are used explicitly to
distinguish forwarding paths on the basis of resource use.

At the same time, however, where people expect VLANs to work, they
are less likely to mix VLAN-aware and VLAN-unaware equipment in the
same network.

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

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

This seems to be out of scope for us.  If you're saying that it
may be necessary for us to specify how to derive globally unique
IPv6 addresses when it is possible that MAC addresses may not be
globally unique, then it is DEFINITELY out of scope for us.

I personally don't see this as a problem, but - even if it is -
it isn't our problem.

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

These may be general problems that either have been addressed
or will be addressed, generally - and elsewhere.

>