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?

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
Improve this question
3
  • ciscopress.com/articles/article.asp?p=2738463&seqNum=2 Commented Jun 3, 2017 at 10:53
  • This Question is now moot. The new Version 7 UUID invented was in 2024 in RFC 9562 to enable efficient indexing. Version 7 redefines the timestamp of Version 1, and replaces the Version 1’s use of MAC address with randomly-generated bits. This new Version 7 supplants Version 1. Postgres 18+ supports Version 7 UUIDs with a new function uuidv7(). So there is no longer any reason to use Version 1 UUIDs in Postgres. Commented Oct 13 at 4:49
  • Version 7 UUID uses a timestamp, redefined as a 48-bit big-endian unsigned number of the Unix Epoch timestamp in milliseconds. This bit-layout provides the efficient indexing. The Postgres uuidv7() function’s implementation exercises the specification-granted option of extending that timestamp by 12 more bits for sub-millisecond resolution. This detail provides monotonicity. See the post by Gwen Shapira, UUIDv7 Comes to PostgreSQL 18. Commented Oct 13 at 4:50

1 Answer 1

Reset to default
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".

Improve this answer
2
  • 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. Commented Jun 8, 2017 at 6:34
  • 1
    FYI… As of 2024-05, RFC 9562 obsoletes RFC 4122. Commented Oct 13 at 4:54

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.