A Universally Unique IDentifier (UUID) URN Namespace
obsoleted by
- rfc-9562 — Universally Unique IDentifiers (UUIDs)
Extracted elements (26)
For name-based UUIDs, SHA-1 (version 5) is preferred over MD5 (version 3) when backward compatibility is not required. Both hash the namespace UUID (in network byte order) concatenated with the name, but SHA-1 provides stronger collision resistance.
For random node IDs, the unicast/multicast bit is used rather than the local/global bit for compatibility with earlier DCE specifications. This ensures generated node IDs never conflict with real IEEE 802 addresses, since the multicast bit is never set in addresses obtained from network cards.
The field name 'variant' is retained rather than the more accurate 'type' for backward compatibility with the original OSF DCE UUID specification, even though the variant field determines the interpretation of all other bits in the UUID.
The UUID generator state (timestamp, clock sequence, node ID) does not need to be written to stable storage on every UUID generation. Instead, the stable store timestamp can be periodically set to a future value; as long as generated UUIDs use timestamps less than that value, only the volatile shared copy needs updating.
The UUID timestamp epoch is October 15, 1582 (the date of Gregorian calendar reform), inherited from the OSF DCE specification. The 60-bit timestamp will roll over around A.D. 3400, depending on the algorithm used.
To support high-throughput UUID generation when the system clock resolution is coarser than 100 ns, a per-tick counter of UUIDs already generated can be added to the low-order bits of the timestamp to simulate higher resolution. Additional node identifiers can be allocated if processors frequently overrun UUID generation.
UUIDs require no central registration authority, supporting allocation rates up to 10 million per second per machine. This makes them suitable as transaction IDs and other high-frequency identifiers without coordination overhead.
For lexical equivalence, each UUID field is treated as an unsigned integer; two UUIDs are equal if and only if all corresponding fields are equal. On many systems equality can be tested by byte-order canonicalization followed by comparison as 128-bit unsigned integers.
Interoperability with UUID variants other than the one defined in this document (variant bits '10' in octet 8) is not guaranteed and is not likely to be an issue in practice. Each variant defines an independent interpretation of all other UUID bits.
If a system overruns the UUID generator by requesting too many UUIDs within a single system time interval, the UUID service MUST either return an error or stall the UUID generator until the system clock catches up.
The clock sequence MUST be originally (once in the lifetime of a system) initialized to a random number to minimize correlation across systems and provide maximum protection against rapidly moving or switching node identifiers.
The initial value of the clock sequence MUST NOT be correlated to the node identifier.
UUIDs generated at different times from the same name in the same namespace MUST be equal, ensuring deterministic and reproducible name-based UUID generation.
When a randomly generated node ID is used (no IEEE 802 address available), the multicast bit (LSB of the first octet of the node field) must be set to one so that such addresses can never conflict with real IEEE 802 MAC addresses from network cards.
For version 1 UUIDs, the node field (48 bits, octets 10–15) holds an IEEE 802 MAC address, typically the host address. If no MAC address is available or its use is undesirable, a 47-bit cryptographic-quality random value with the multicast bit set may be substituted.
For version 1 UUIDs, the timestamp is a 60-bit count of 100-nanosecond intervals since 00:00:00.00, 15 October 1582 (the Gregorian calendar reform date). For versions 3 and 5 the timestamp bits are derived from a cryptographic hash of a name; for version 4 they are randomly generated.
The clock sequence is a 14-bit value stored across clock_seq_hi_and_reserved (upper 6 bits) and clock_seq_low (lower 8 bits). For version 1 it guards against duplicate UUIDs when the system clock goes backwards or the node ID changes; for versions 3/5 it is derived from a name hash; for version 4 it is randomly generated.
The nil UUID is the special form with all 128 bits set to zero.
The UUID string representation is defined by ABNF as: time-low "-" time-mid "-" time-high-and-version "-" clock-seq-and-reserved clock-seq-low "-" node, yielding 32 hex digits in 8-4-4-4-12 grouping (e.g., urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6). Hex digits a–f are output as lowercase and are case-insensitive on input.
The variant field occupies the most significant bits of octet 8 and determines the layout of all other UUID bits. The variant defined in this document is the two-bit pattern '10' (Msb0=1, Msb1=0); other values are reserved for NCS backward compatibility, Microsoft backward compatibility, or future use.
The version number occupies the 4 most significant bits (bits 12–15) of the time_hi_and_version field. Defined versions are: 1 (time-based), 2 (DCE Security with embedded POSIX UIDs), 3 (name-based using MD5), 4 (randomly or pseudo-randomly generated), and 5 (name-based using SHA-1).
This document registers the 'UUID' URN namespace (urn:uuid:...) with declared registrant JTC 1/SC6, registration date 2003-10-01. Pre-defined namespace UUIDs are provided for DNS (6ba7b810-9dad-11d1-80b4-00c04fd430c8), URL (6ba7b811-...), ISO OID (6ba7b812-...), and X.500 DN (6ba7b814-...).
Distributed applications generating UUIDs at multiple hosts must rely on the quality of random number sources at all hosts. If this is not feasible, the name-based namespace variant should be used instead.
Humans cannot easily verify the integrity of a UUID by visual inspection, making it impossible to detect whether a UUID has been slightly transposed to redirect a reference to a different object.
UUIDs should not be used as security capabilities (identifiers whose mere possession grants access). They are not hard to guess, and a predictable random number source exacerbates this problem.
A UUID is 16 octets (128 bits) encoded with most significant byte first (network byte order), comprising: time_low (32-bit unsigned, octets 0–3), time_mid (16-bit unsigned, octets 4–5), time_hi_and_version (16-bit unsigned, octets 6–7), clock_seq_hi_and_reserved (8-bit unsigned, octet 8), clock_seq_low (8-bit unsigned, octet 9), and node (48-bit unsigned, octets 10–15).