Universally Unique IDentifiers (UUIDs)

The fixed bit-length dedicated counter (Method 1) for UUIDv7 monotonicity SHOULD be at least 12 bits but no longer than 42 bits. The counter must be initialized to a random value on each new timestamp tick, not sequentially from zero, to preserve unguessability of the batch while still guaranteeing sort order.

UUIDv1 embeds a MAC address in the node field, exposing hardware manufacturer details and undermining privacy. Additionally, virtual machines and containers have made MAC address uniqueness unreliable. UUIDv6 and UUIDv7 recommend pseudorandom node values with the multicast bit set to address both concerns.

privacy, security

UUIDv1 uses a 100-nanosecond Gregorian Epoch timestamp (since 15 October 1582) that is uncommon, difficult to represent accurately in IEEE 754 floating point, and requires byte-order introspection to sort. UUIDv7 replaces it with a Unix Epoch millisecond timestamp (valid to year 10889 AD) that is natively sortable as raw bytes.

UUIDv4's random layout causes poor database-index locality because successive inserts land at random locations in B-tree indexes. UUIDv6 and UUIDv7 store timestamps in the most significant bytes so new values cluster near each other in the index, with real-world performance differences of one order of magnitude or more over random UUIDs.

UUIDv6 is a field-compatible rearrangement of UUIDv1 intended only for contexts already using UUIDv1. Systems not involving legacy UUIDv1 SHOULD use UUIDv7 instead, which offers better entropy characteristics and a more widely supported Unix Epoch timestamp.

UUIDv8 was introduced to provide a standards-compliant escape hatch for experimental, vendor-specific, or application-specific designs — such as SHA-256 name-based UUIDs or custom timestamp epochs — without requiring new IANA-registered UUID versions. Only the variant and version bits are mandated.

Microsoft's Component Object Model (COM) GUIDs use little-endian encoding when saving GUIDs to binary, whereas this specification mandates big-endian. Cross-platform interoperability with COM GUIDs requires awareness of this byte-order difference, which is outside the scope of this specification.

UUIDv5 (SHA-1) SHOULD be used in lieu of UUIDv3 (MD5) wherever possible due to MD5 security weaknesses. Name-based UUIDs using SHA-256 or newer hash algorithms MUST NOT use UUIDv5 and MUST be placed within the UUIDv8 space.

crypto, security

Counter rollovers MUST be handled by the application to avoid sorting issues. Applications concerned with absolute monotonicity SHOULD freeze the counter and wait for the timestamp to advance; alternatively implementations MAY increment the timestamp ahead of actual time and reinitialize the counter.

For all UUIDs defined in this document, bits 64 and 65 of the UUID (the most significant bits of octet 8) MUST be set to 1 and 0, establishing variant 10xx. All bit and field layouts avoid use of these two bits.

For UUIDv1 and UUIDv6, if the clock is set backwards and the generator cannot guarantee no UUIDs were produced with larger timestamps, the clock sequence MUST be changed — incremented if the previous value is known, otherwise set to a random or high-quality pseudorandom value.

Implementations SHOULD utilize a cryptographically secure pseudorandom number generator (CSPRNG) for UUID random data. CSPRNG state MUST be properly reseeded upon state changes such as process forks to ensure correct operation.

crypto, security

The clock sequence MUST be originally initialized to a random number to minimize correlation across systems, and the initial value MUST NOT be correlated to the Node ID.

UUIDs SHOULD be stored within database applications as the underlying 128-bit binary value rather than as text. The text form requires 288 bits to represent a 128-bit UUID value.

When generating a random 48-bit Node ID for UUIDv1 or UUIDv6 (when no IEEE 802 MAC is available or desired), implementations MUST set the least significant bit of the first octet to 1 (the multicast bit), ensuring these node values never conflict with real hardware MAC addresses.

security, privacy

When timestamp padding is required, implementations MUST pad the most significant (leftmost) bits. When truncation is required, the lower, least significant bits MUST be used. A UUID generator MUST NOT knowingly return duplicate values due to a counter rollover.

Embedding a real MAC address in UUIDv1/UUIDv6 node fields exposes network interface hardware details and can be used to locate or fingerprint machines. Implementations generating UUIDs for external consumption SHOULD use a cryptographically random node ID with the multicast bit set rather than a real MAC address.

privacy, security

Name-based UUIDs (UUIDv3/UUIDv5) require that the same name in the same namespace always produces the same UUID, and that different names or different namespaces produce different UUIDs with high probability. Names and namespace IDs must be converted to canonical octet sequences in network byte order before hashing.

The Nil UUID (00000000-0000-0000-0000-000000000000) has all 128 bits set to zero and signals the absence of a UUID. The Max UUID (FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF) has all 128 bits set to one and serves as a sentinel (e.g., 'end of UUID list'). Both fall outside the variant 10xx space.

The variant field occupies the most significant bits of octet 8. Variant 10xx (bits 64-65 of the UUID set to '1' and '0') identifies the UUID format defined by this document. Variants 0xxx (NCS), 110x (Microsoft), and 111x (future) are reserved.

The version field occupies the most significant 4 bits of octet 6 (bits 48-51). This specification defines versions 1 through 8; versions 0 and 9-15 are unused or reserved for future definition.

UUIDv7 provides three optional methods for intra-millisecond monotonicity: Method 1 (fixed bit-length dedicated counter in rand_a, at least 12 bits, positioned immediately after the timestamp), Method 2 (monotonic randomly-seeded counter in rand_b incremented per UUID), and Method 3 (sub-millisecond clock precision bits replacing leftmost rand_a bits).

IANA 'UUID Namespace IDs' registry defines four pre-assigned Namespace IDs: DNS (6ba7b810-9dad-11d1-80b4-00c04fd430c8), URL (6ba7b811-...), OID (6ba7b812-...), X500 (6ba7b814-...). New entries use Specification Required policy; sequential allocation increments the least significant bit of time_low while freezing the remaining fields. Custom/vendor namespace IDs SHOULD use UUIDv4 or UUIDv7 values.

registry

IANA 'UUID Subtypes' registry created by this document lists versions 1-8 under the OSF DCE / IETF variant. Extended by Standards Action only. Vendor-specific, application-specific, and deployment-specific values cannot be registered. Version IDs range 0-15 for the OSF DCE / IETF variant.

registry

Implementations SHOULD NOT assume that UUIDs are hard to guess. UUIDs MUST NOT be used as security capabilities (identifiers whose mere possession grants access). Discovery of predictability in a random number source will result in a vulnerability.

security

A UUID is 128 bits (16 octets) in size, encoded in big-endian (network byte order). The canonical text form is 'hex-and-dash': groups of 8-4-4-4-12 hexadecimal characters separated by hyphens, e.g., f81d4fae-7dec-11d0-a765-00a0c91e6bf6. Alphabetic hex digits may be uppercase, lowercase, or mixed.

UUIDv1 layout: time_low (32-bit, bits 0-31), time_mid (16-bit, bits 32-47), ver=0b0001 (4-bit, bits 48-51), time_high (12-bit, bits 52-63), var=0b10 (2-bit, bits 64-65), clock_seq (14-bit, bits 66-79), node (48-bit IEEE 802 MAC or random, bits 80-127). Timestamp is 60-bit count of 100-nanosecond intervals since 15 October 1582 (Gregorian Epoch).

UUIDv4 layout: random_a (48-bit, bits 0-47), ver=0b0100 (4-bit, bits 48-51), random_b (12-bit, bits 52-63), var=0b10 (2-bit, bits 64-65), random_c (62-bit, bits 66-127). Provides 122 bits of random or pseudorandom data.

UUIDv6 layout reorders UUIDv1 timestamp bytes for lexicographic sortability: time_high (32-bit most significant timestamp bits, bits 0-31), time_mid (16-bit, bits 32-47), ver=0b0110 (4-bit, bits 48-51), time_low (12-bit least significant timestamp bits, bits 52-63), var=0b10 (2-bit, bits 64-65), clock_seq (14-bit, bits 66-79), node (48-bit, bits 80-127).

UUIDv7 layout: unix_ts_ms (48-bit big-endian unsigned milliseconds since Unix Epoch, bits 0-47), ver=0b0111 (4-bit, bits 48-51), rand_a (12-bit random or counter, bits 52-63), var=0b10 (2-bit, bits 64-65), rand_b (62-bit random or counter, bits 66-127). UUIDv7 is valid until year 10889 AD.

UUIDv8 layout: custom_a (48-bit, bits 0-47), ver=0b1000 (4-bit, bits 48-51), custom_b (12-bit, bits 52-63), var=0b10 (2-bit, bits 64-65), custom_c (62-bit, bits 66-127). The 122 non-ver/var bits are fully implementation-defined; UUIDv8 uniqueness MUST NOT be assumed.