A UUID is an identifier that is unique across both space and time1, with respect to the space of all UUIDs. A UUID can be used for multiple purposes, from tagging objects with an extremely short lifetime, to reliably identifying very persistent objects across a network.
The generation of UUIDs does not require a registration authority for each single identifier. Instead, it requires a unique value over space for each UUID generator. This spatially unique value is specified as an IEEE 802 address, which is usually already applied to network-connected systems. This 48-bit address can be assigned based on an address block obtained through the IEEE registration authority. This UUID specification assumes the availability of an IEEE 802 address.
|Field||NDR Data Type||Octet #||Note|
|time_low||unsigned long||0-3||The low field of the timestamp.|
|time_mid||unsigned short||4-5||The middle field of the timestamp.|
|time_hi_and_version||unsigned short||6-7||The high field of the timestamp multiplexed with the version number.|
|clock_seq_hi_and_reserved||unsigned small||8||The high field of the clock sequence multiplexed with the variant.|
|clock_seq_low||unsigned small||9||The low field of the clock sequence.|
|node||character||10-15||The spatially unique node identifier.|
The UUID consists of a record of 16 octets and must not contain padding between fields. The total size is 128 bits.
To minimise confusion about bit assignments within octets, the UUID record definition is defined only in terms of fields that are integral numbers of octets. The version number is multiplexed with the time stamp (time_high), and the variant field is multiplexed with the clock sequence (clock_seq_high).
The timestamp is a 60 bit value. For UUID version 1, this is represented by Coordinated Universal Time (UTC) as a count of 100-nanosecond intervals since 00:00:00.00, 15 October 1582 (the date of Gregorian reform to the Christian calendar).
The version number is multiplexed in the 4 most significant bits
of the time_hi_and_version field.
|0||0||0||1||1||DCE version, as specified herein.|
|0||0||1||0||2||DCE Security version, with embedded POSIX UIDs.|
The variant field determines the layout of the UUID. The structure of
DCE UUIDs is fixed across different versions. Other UUID variants may
not interoperate with DCE UUIDs. Interoperability of UUIDs is defined
as the applicability of operations such as string conversion,
comparison, and lexical ordering across different systems. The
variant field consists of a variable number of the msbs of the
|0||-||-||Reserved, NCS backward compatibility.|
|1||1||0||Reserved, Microsoft Corporation GUID.|
|1||1||1||Reserved for future definition.|
The clock sequence is required to detect potential losses of
monotonicity of the clock. Thus, this value marks discontinuities and
prevents duplicates. An algorithm for generating this value is
The node field consists of the IEEE address, usually the host address. For systems with multiple IEEE 802 nodes, any available node address 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.
Depending on the network data representation, the multi-octet unsigned integer fields are subject to byte swapping when communicated between different endian machines.
The nil UUID is special form of UUID that is specified to have all 128 bits set to 0 (zero).
Various aspects of the algorithm for creating a UUID are discussed in the following sections. UUID generation requires a guarantee of uniqueness within the node ID for a given variant and version. Interoperability is provided by complying with the specified data structure. To prevent possible UUID collisions, which could be caused by different implementations on the same node, compliance with the algorithms specified here is required.
The clock sequence value must be changed whenever:
While a node is operational, the UUID service always saves the last UTC used to create a UUID. Each time a new UUID is created, the current UTC is compared to the saved value and if either the current value is less (the non-monotonic clock case) or the saved value was lost, then the clock sequence is incremented modulo 16,384, thus avoiding production of duplicate UUIDs.
The clock sequence must be initialised to a random number to minimise the correlation across systems. This provides maximum protection against node identifiers that may move or switch from system to system rapidly. The initial value shall not be correlated to the node identifier.
The rule of initialising the clock sequence to a random value is waived if, and only if all of the following are true:
In other words, the system constraints prevent duplicates caused by possible migration of the IEEE address, while the operational system itself can protect against non-monotonic clocks, except in the case of field service intervention. At manufacturing time, such a system may initialise the clock sequence to any convenient value.
There are two possibilities when rebooting a system:
If the state variables have been restored, the UUID generator just continues as normal. Alternatively, if the state variables cannot be restored, they are reinitialised, and the clock sequence is changed. If the clock sequence is stored in non-volatile store, it is incremented; otherwise, it is reinitialised to a new random value.
UUIDs may be created at a rate greater than the system clock resolution. Therefore, the system must also maintain an adjustment value to be added to the lower-order bits of the time. Logically, each time the system clock ticks, the adjustment value is cleared. Every time a UUID is generated, the current adjustment value is read and incremented atomically, then added to the UTC time field of the UUID.
The 100 nanosecond granularity of time should prove sufficient even for bursts of UUID creation in the next generation of high-performance multiprocessors. If a system overruns the clock adjustment by requesting too many UUIDs within a single system clock tick, the UUID service may raise an exception, handled in a system or process-dependent manner either by:
If the processors overrun the UUID generation frequently, additional node identifiers and clocks may need to be added.
UUIDs are generated according to the following algorithm:
|Bit 7||Bit 6|
For use in human readable text, a UUID string representation is specified as a sequence of fields, some of which are separated by single dashes.
Each field is treated as an integer and has its value printed as a zero-filled hexadecimal digit string with the most significant digit first. The hexadecimal values a to f inclusive are output as lower case characters, and are case insensitive on input. The sequence is the same as the UUID constructed type.
The formal definition of the UUID string representation is
provided by the following extended BNF:
UUID = <time_low> <hyphen> <time_mid> <hyphen>
<clock_seq_low> <hyphen> <node>
time_low = <hexOctet> <hexOctet> <hexOctet> <hexOctet>
time_mid = <hexOctet> <hexOctet>
time_high_and_version = <hexOctet> <hexOctet>
clock_seq_and_reserved = <hexOctet>
clock_seq_low = <hexOctet>
node = <hexOctet><hexOctet><hexOctet>
hexOctet = <hexDigit> <hexDigit>
hexDigit = <digit> | <a> | <b> | <c> | <d> | <e> | <f>
digit = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" |
"8" | "9"
hyphen = "-"
a = "a" | "A"
b = "b" | "B"
c = "c" | "C"
d = "d" | "D"
e = "e" | "E"
f = "f" | "F"
The following is an example of the string representation of a UUID:
|time_low||Unsigned 32-bit integer|
|time_mid||Unsigned 16-bit integer|
|time_hi_and_version||Unsigned 16-bit integer|
|clock_seq_hi_and_reserved||Unsigned 8-bit integer|
|clock_seq_low||Unsigned 8-bit integer|
|node||Unsigned 48-bit integer|
Consider each field to be an unsigned integer as shown in
Please note that the html version of this specification may contain formatting aberrations. The definitive version is available as an electronic publication on CD-ROM from The Open Group.