I do not agree. The RFC are not a law. They are recommendations.
There is nothing wrong to clone a MAC address on a virtual NIC from an internal hardware NIC.
The virtual NIC is not a hardware NIC, so it is not bound to the uniqueness of assigning MAC address.
Mac spoofing is well discussed into many topics.
In unix / linux / xxxBsd You can very easy do that with some settings to Your configuration.
As many routers, gateways, hardware firewall, repeaters or software do provide the ability to
clone a MAC from an internal host. So if some user decide to perform routing, packet filtering, intrusing detection
or even stress-security testing inside a virtual machine, he can not be excluded to do the same.
So You can discuss endless arround this matter. But my points stands.
It is a commercial disadvantage if You are excluded to make those changes, but You can with other opensource software. Of course, You
can force them to do the same as You have decided in Your policies. But this can be very easy made undone by changing the source and compiling the package by Your own.
And secondly, as said, a virtual machine does need, to 'emulate' as best as possible a real machine. So the user should and could choose,
which NIC he wants to emulate, including it's MAC address.
And if that's a violation, well, this is the responsibility of the user.
You can mention it in the EULA of Your software.
But I agree on this, those changes should and could only be done in the system-wide section,
so only a superuser can change them to protect an internal network from inside attacks.
The same superuser can decide to block communication to the public networks by firewall rules,
if he feels it is a violation of the RFC. I repeat, IF this is the case (which is NOT, in case of running routing software in a VM, etc).
