A MAC address is burned into a device by the manufacturer, and manufacturers are allocated vendor IDs (the first 3 bytes of a MAC address).
One of these is Microsoft Hyper-V, which owns all of the 00:15:5D:XX:XX:XX addresses. This led to an interesting problem a while ago, where we had enough Hyper-V hosts on a single network that virtual machines were getting assigned duplicate MAC addresses.
To fix this we needed to assign the hosts different MAC ranges to choose from, but how can you do that? I'm not a vendor, I don't have my own allocation, so how can I ensure that whatever MACs I pick won't conflict with an actual real device somewhere?
Fortunately, the MAC standard does have a solution to this, althought it doesn't seem to be that well-known or accessibly documented.
The scheme described above where the first 3 bytes are a vendor ID with centralised management is for Universally Administered Addresses, which is the common one you will see on devices in the wild. The other type of addresses are Locally Administered Addresses, which are approximately the MAC equivalent of private IP ranges.
Just like how my home router can be 192.168.0.1 and your home router can also be 192.168.0.1 and that's fine because they're on two separate networks, so too I can have a Locally Administered MAC Address on my network while you can have the exact same Locally Administered MAC Address on your network, and that's not a problem because by being on different networks they will never see each-other.
Locally Administered Addresses are defined by one particular bit out of the 6 bytes - specifically, the second-least-significant bit of the first octet. This means that you can choose any MAC addresses that you want, as long as it matches one of:
X2‑XX-XX-XX-XX-XXX6‑XX-XX-XX-XX-XXXA‑XX-XX-XX-XX-XXXE‑XX-XX-XX-XX-XX
If you want to know why you can use 2, 6, A, and E, but not 3, 7, B, or F, that's because the latter ones are reserved for Multicast whereas the former are Unicast.
