3

The uuid-ossp module extension (plugin) for Postgres offers this alternative method for generating a UUID value.

uuid_generate_v1mc()

This function generates a version 1 UUID but uses a random multicast MAC address instead of the real MAC address of the computer.

I assume the intent here is to address a security concern about recording the MAC address of the database server. So instead we want to use another alternate MAC address in its place as a part of generating a Version 1 UUID value.

My question is: What exactly is this “random multicast MAC address” to be used in place of the db server’s own MAC?

I have googled/binged but found no good explanation. Is this some other MAC currently in use being found on the db server’s local network?

What are the practical issues involved in using this command, in the context of a primary key in Postgres?

  • Why are you using version 1 anyway. it's less secure, and less portable. Just use uuid_v4. There is no reason to use uuidv1 – Evan Carroll Jun 3 '17 at 16:40
  • @EvanCarroll "less secure" is an imprecise statement without knowing the context and requirements. And while the version 4 (all random) is practical in most situations, the other versions virtually eliminate what little chance of collision might occur with v4. There is a reason v1 was invented before v4. – Basil Bourque Jun 3 '17 at 16:59
  • "Virtually eliminate" something that is practically non-existent anyway. – Evan Carroll Jun 3 '17 at 17:06
  • @EvanCarroll Your claim assumes a cryptographically string random number generator properly implemented, and less than extreme volumes, and no concern for performance. Furthermore, my Question is specifically not about Version 4. – Basil Bourque Jun 3 '17 at 17:12
3

RFC4122 documentation (section 4.1.6) specifies:

For UUID version 1, the node field consists of an IEEE 802 MAC address, usually the host address. For systems with multiple IEEE 802 addresses, any available one can be used. The lowest addressed octet (octet number 10) contains the global/local bit and the unicast/multicast bit, and is the first octet of the address transmitted on an 802.3 LAN.

For systems with no IEEE address, a randomly or pseudo-randomly generated value may be used; see Section 4.5. The multicast bit must be set in such addresses, in order that they will never conflict with addresses obtained from network cards.

If I interpret this correctly, I'd say: a random Multicast address is any randomly generated MAC adress which has just the multicast bit set. The multicast bit is just one of the bits from the node part of a UUID (for all practical purposes, this just forces one specific bit of the UUID to be set).


Side Notes

I don't think you actually can specify a MAC address to the PostgreSQL function. If it follows the RFC, the function(s) must either use any of the MAC addresses available in your system, or a random one (with a specific bit set).

Whether this random value is always the same for a specific machine (which wouldn't look very random to me) or is just purely (pseudo)random and changing every time, is not clear from this explanation... but can be very easily tested:

SELECT uuid_generate_v1mc() AS u1, uuid_generate_v1mc() AS u2

gets me right now:

'91ccbe0c-488c-11e7-8d61-b7a8bb0bd0e3','91cd902a-488c-11e7-8d61-8bdf8f55ae02'

This translates (using the PERL program from https://stackoverflow.com/questions/1709600/what-kind-of-data-can-you-extract-from-a-uuid) to

time: Sat Jun  3 20:43:43 2017 +682.51ms
clock id: 36193
Mac: b7:a8:bb:0b:d0:e3
broadcast/multicast bit set.

and

time: Sat Jun  3 20:43:43 2017 +687.889ms
clock id: 36193
Mac: 8b:df:8f:55:ae:02
broadcast/multicast bit set.

... so, the MAC are actually completely (pseudo)random.

As pointed out by @EvanCarrol: I also think you're better off with v4 UUIDs, I don't think you'll get less collision risk with a randomly generated MAC.

Besides, very many network devices (routers, switches, etc.) have programmable MAC addresses (this is very handy when you want to replace one broken device by another, and make sure all the other devices don't notice any difference at all). This, somehow, makes the MACs not as unique as you probably thought.

Alternatvies: If you work with Windows, may be this tool can let you fake a MAC address. I've not tried it myself, so, "no strings attached".

  • Not just that, but if the MAC address isn't random you reduce your total randomness by that amt, increasing your chance for collision not decreasing it. – Evan Carroll Jun 4 '17 at 3:12
  • @EvanCarroll: if MAC addresses were actually absolutely guaranteed to be unique and you wouldn't mind exposing your MAC address to the world, you would not have a risk of collision, so, no need for randomness. The problem being the conditions don't hold ;-( – joanolo Jun 4 '17 at 9:18
  • I disagree about preferring Version 4 (random). Version 1 (and its multicast variant) use the current moment (plus a ‘clock sequence’ changed when clock is reset). The idea here is to be unique over space (MAC) and time (current moment + clock sequence ). When properly formed, you have eliminated all but the most astronomically-scaled chance of a duplicate. With the all-random, you have not leveraged either space or time. For most practical usages with all but extreme number of UUIDs being generated, v4 is practical and safe if properly implemented… but v1 is even better. – Basil Bourque Jun 8 '17 at 6:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.