container mac addresses should use 'locally assigned' section

[John A Meinel]

We currently always prefix container MAC addresses with:
const macAddressTemplate = "00:16:3e:%02x:%02x:%02x"

These appear to be allocated to "Xensource, Inc.".

https://en.wikipedia.org/wiki/MAC_address#Universal_vs._local

Indicates that we should be setting the second least-significant bit (eg 0x02) to indicate that we are creating these addresses as a "network admin", and not as a Manufacturer that is guaranteeing they are globally unique.

[Stéphane Graber (stgraber)]

Copy/pasting from the e-mail I just sent you:

"""
It's a reserved prefix by Xen for use by hypervisors and has been used
by a fair number of other hypervisors and container projects who didn't
get their own allocation.

So I remember someone looking into using a different prefix in the past,
including looking into local addresses, from what I remember the issues
with them were:
 - Bad rendering in dump tools as there is no OUI assignement for them
 - Has a very high probability of being a higher number than a physical
   MAC, which is a problem since on Linux bridges use the highest MAC as
   their own and a change of MAC can stop forwarding for a few seconds.

   This limitation went somewhat away with recent kernels where we can
   now force the MAC regardless of slave ports.
 - Some broken switches, at least back then (a few years ago) were
   interpreting the local bit as meaning, switch-local and so weren't
   forwarding packets coming from such a MAC (similar to if those were STP
   frames).

My personal preference was for us to register a new prefix for use by
LXC containers and switch from the Xen to our own prefix everywhere in
LXC and LXD. This would avoid the problems above and after the various
OUI databases get updated, show very clearly what those MACs are in the
various network reporting tools.

I unfortunately didn't get much traction on getting that paperwork done
(and fee paid) so we've been sticking with the Xen range for now.
"""

[Anastasia (anastasia-macmood)]

We track Juju 2.x issues in "juju" project. Re-targeting :D

[Stéphane Graber (stgraber)]

Not seeing an advantage in changing range for LXD at this point, unless we get our own reserved named range. Marking won't fix.

[John A Meinel (jameinel)]

As mentioned from Stephane, this is intentional, and trying to follow the "spec" seems like it will likely cause more problems than doing what we're currently doing.