language agnostic - Where do UUID namespaces come from?

Question

The UUID specification defines 4 predefined namespaces which it describes as "potentially interesting" - meaning among other things, "if other people have generated UUIDs in this namespace you can verify them":

• 6ba7b810-9dad-11d1-80b4-00c04fd430c8 for DNS
• 6ba7b811-9dad-11d1-80b4-00c04fd430c8 for URL
• 6ba7b812-9dad-11d1-80b4-00c04fd430c8 for ISO OID
• 6ba7b814-9dad-11d1-80b4-00c04fd430c8 for X.500 DN

Where did these come from?

Specifically;

• If I'm generating my own namespace UUID do I need to avoid anything in particular?
• I'm aware how big the UUID space is, but does this have any implication on collisions?
• Why have they chosen the 4th octet to increase as a kind of UUID 'version number'?
• Do my questions imply that I'm missing something fundamental about UUIDs?

question from:https://stackoverflow.com/questions/7724903/where-do-uuid-namespaces-come-from

Answer 1

First, to be clear, this whole discussion is limited to version 3 & 5 UUIDs. In my (anecdotal) experience, version 4 (random) UUIDs are most commonly used.

4122's namespaced UUID generation algorithm ambiguously begins:

Allocate a UUID to use as a "name space ID"

There is no other mention of "name space ID" allocation, and neither I nor python have found any standardized spaces beyond the four listed in RFC 4122.

So the answer to your first question,

• If I'm generating my own namespace UUID do I need to avoid anything in particular?

You only need to avoid the four standard namespaces.

---

The next question,

• I'm aware how big the UUID space is, but does this have any implication on collisions?

Has two parts:

1. Will UUIDs within your namespace collide? Verbatim from 4122:

   The UUIDs generated from two different names in [your] namespace should be different (with very high probability).

2. Will your namespace UUID collide with other namespaces? I couldn't find a direct answer, since there's no standard for "name space ID" allocation, but the argument in section 4.1.1 seems relevant:

   Interoperability, in any form, with variants other than the one defined here is not guaranteed, and is not likely to be an issue in practice.

---

• Why have they chosen the 4th octet to increase as a kind of UUID 'version number'?

This one's a bit of a mystery. Luckily, we have a spec for UUIDs, so we can mine them for some insight.

Note that the (0-index) 8th octet starts with 8 in all cases, so we're dealing with RFC 4122 variant UUIDs. Phew.

Now check octet 6 for the version: 1, we're dealing with version 1 time-based UUIDs.

This answer has a handy algorithm for extracting python datetimes from version 1 UUIDs. Applying the algorithm yields a time in February 4th, 1998. I have yet to find meaning in this date. Incrementing the 3rd octet adds the smallest encodable time interval (100ns) to the date.

---

• Do my questions imply that I'm missing something fundamental about UUIDs?

Nope. There is very little discussion of UUID namespaces, since random UUIDs are so easy.