UUID, GUID notes

What

A UUID is a standardish way of generating and formatting a probably-universally-unique 128-bits number (practically a few bits less).

There are a few different ways of generating the value,

some of them intentionally less anonymous (e.g. contains time, and network card identifier),

others more opaque (e.g. hashing something volatile, or simply being a random number).

For example, version 1 is the idea to use your network card's MAC address (itself unique), add the current time (preferably in high resolution), and if you can, a (pseudo)random number or counter for good measure.

This is cheap to generate and (except for the counter) simple and stateless, and these two ingredients should mean it will almost necessarily

never collide with a value generated at a different time (until AD 3603)

never collide with values generated elsewhere (MAC reuse is rare except except in some counterfeited, and some DIY).

On the flipside, the ability to extract information about time of generation, and perhaps match it to a computer and place, really isn't ideal in some situations.

In which cases you generally end up on version 4, random, which is basically just a 122-bit random integer, and you're just counting on collisions being extremely rare due to the very large space of values.

Why use UUIDs

Usually used for identifiers.

Particularly when

• you want a fairly large amount of them,
• you want to be be able to generate them without checking with a central authority

and note that central authority would probably need to store everything it generated/saw before

it may be inconvenient or intractible to host such a service and/or

it may become a larger distributed system's primary bottleneck (though there are certainly ways of making it scale better than a one-big-database implementation).

Instead, you can generate numbers independently, in a very large space to have a very very high probability of being unique. If you minimize the risk of ever having colliding IDs (consider that 2¹²² is 5316911983139663491615228241121378304). then you can perfectly get away with removing that centralization.

(Yes, generating 128-bit numbers yourself is functionally almost the same (as v4) - the largest difference being that it probably won't be a valid UUID (v4 or otherwise) because of a few special bits)

How

Use a UUID library.

It's easier, more likely to stick to the standard than 5 minutes of DIY, and recent languages may well have one in their standard libary anyway.

When you do have or want to do it yourself, the simplest (and probably most common) to generate are random UUIDs, i.e. version 4. You can generate a large random number, then twiddle the bits to have it be an RFC-compliant version 4 UUID. (see the javascript mention below)

For example:

In Python: Use the uuid module (in the standard library since 2.5), for example myuuid = uuid.uuid4()

...which is still an object. You can use str(myuuid) for the hexadecimal string with dashes.

In Java, use java.util.UUID, for example UUID random_uuid = UUID.randomUUID();, quite possibly followed by toString().

In .NET, use System.Guid, for example: random_uuid = System.Guid.NewGuid(), quite possibly followed by a .ToString()

For example, JavaScript has no standard-library function. Perhaps the simplest implementation to generate a random UUID is something like this or this, but there is a potential problem in Math.random() not giving randomness guarantees, which is why there are better libraries (with their own PRNG) which you might as well use. They include:

• https://github.com/broofa/node-uuid
• http://frugalcoder.us/post/2012/01/13/javascript-guid-uuid-generator.aspx

Layout

A UUID is a 128-bit number, conventionally grouped and dashed as 32-16-16-16-48 bits (8-4-4-4-12 hex characters), which reflects the way it is parsed.

The bit layout (from RFC 4122 ):

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          time_low                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       time_mid                |         time_hi_and_version   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|clk_seq_hi_res |  clk_seq_low  |         node (0-1)            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         node (2-5)                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Note that fields vary purpose between versions, so their names are slightly messy.

For example, the 60 bits of time value can also be used to store a pseudorandom number, while the node field can be a MAC or a hash of something. (verify)

Versions and variants, a few layout details

✎ This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

The version isn't about standard version, it's the type/variant of UUID.

This is stored in the most significant four bits of time_hi_and_version (octet 6).

...which also means that, in hex representation, you can see the version right after the second dash. For example:

6e8bc430-9c3a-11d9-9669-0800200c9a66 is a version 1 UUID,

550e8400-e29b-41d4-a716-446655440000 is a version 4.

It seems there are currently:

• 0001: Version 1: Based on time + node (MAC address of any of the cards present)
• 0010: Version 2: DCE Security version (with embedded POSIX UIDs)
• 0011: Version 3: Name-based (MD5 hash)
• 0100: version 4: random
• 0101: Version 5: Name-based (SHA1 hash)

If the UUID variant is not RFC4122 based, the version value need not necessarily comply to the above; possibly because UUID itself was inspired by some things before it.

Versions 1, 3, 4, and 5 are defined in RFC 4122 (from 2005).

The variant is specified by the most significant three bits in clk_seq_hi_res (octet 8), and controls the meaning/layout of the rest of the number. Apparently:

• 001 ?
• 000 NCS (reserved for backward compatibility)
• 010 Current variant
• 011 ?
• 100 ?
• 101 ?
• 110 Microsoft (reserved for backward compatibility)
• 111 Reserved for future use

See also

• RFC 4122 (A Universally Unique IDentifier (UUID) URN Namespace)

And perhaps:

• ISO/IEC 9834-8:2005, Information technology — Procedures for the operation of object identifier registration authorities — Part 8: Generation of universally unique identifiers (UUIDs) and their use in object identifiers

• ISO/IEC 11578:1996 (Information technology -- Open Systems Interconnection -- Remote Procedure Call (RPC))

• ITU-T Rec. X.667 (Procedures for the operation of OSI Registration Authorities: Generation and registration of Universally Unique Identifiers (UUIDs) and their use as ASN.1 Object Identifier components)