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


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?

Example data from calling uuid_generate_v1mc repeatedly, with UUID values in first column:

e2a03f96-0e7f-11ea-9838-6bba9e946aa0    Bird    2019-11-24 06:01:41.394401
e30c64be-0e7f-11ea-8540-9b38c7ef1573    Bird    2019-11-24 06:01:42.108340
e33037ea-0e7f-11ea-ab4b-abc4bdb5ea40    Bird    2019-11-24 06:01:42.342973
e3495cca-0e7f-11ea-8070-03c037680e82    Bird    2019-11-24 06:01:42.507537
e3668dd6-0e7f-11ea-b4e7-87c2c65a3777    Bird    2019-11-24 06:01:42.699283

1 Answer 1


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:


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.


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

  • 1
    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. Jun 8, 2017 at 6:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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