GUID / UUID V2 - DCE Security (POSIX UID/GID)

Version status and history

GUID / UUID v2 is a DCE Security variant that was defined in the DCE 1.1 specification around 1997 and later reserved (but not fully specified) in RFC 4122 in July 2005.

In practice, GUID / UUID v2 was meant to embed operating-system level identity information into the GUID / UUID itself. Because this exposes sensitive metadata and was tightly coupled to DCE concepts, v2 never saw widespread adoption and is rarely implemented in modern GUID / UUID libraries.

V2 is effectively deprecated and not recommended for new systems due to its severe privacy concerns, lack of formal standardization and very limited library support. For modern designs, prefer v4 for randomness or v7 for time-ordered identifiers.

Advantages of GUID / UUID v2

• DCE integration: designed to work directly with DCE Security models and OS-level identity concepts.
• Partial time-correlation: contains timestamp information (derived from v1), which can be useful for understanding when the GUID / UUID was created.

Warnings for GUID / UUID v2

• Severe privacy concerns: embeds OS-level identifiers (such as UID or GID) which can leak sensitive security and user information.
• Hardware information leakage: like v1, v2 may also include MAC address information in the node field, further compromising privacy.
• Not formally standardized: there is no dedicated RFC that fully specifies UUID v2 behavior or guarantees interoperability.
• DCE-specific design: tightly coupled to legacy DCE Security concepts that are rarely used today.
• Very limited support: most GUID / UUID libraries do not generate or parse v2 UUIDs.
• Not recommended for new systems: modern GUID / UUID versions provide better privacy, portability and standardization.

Technical description

Bit layout (practical view): GUID / UUID v2 uses the same overall 128-bit structure and canonical string format as other GUIDs / UUIDs: 8-4-4-4-12. It is based on the v1 layout, but with modifications to support DCE Security.

Fields (what exists): v2 replaces the lower part of the time_low field from v1 with a local identifier (such as a POSIX UID or GID). The clock_seq_low field is repurposed to hold a local domain identifier that specifies what kind of identifier is embedded (for example, POSIX user domain or group domain). The remaining fields include timestamp information, clock sequence and node identifier, similar to v1. Exact usage varies and is not strictly specified in RFC 4122.

Field structure (DCE 1.1 / RFC 4122 reserved)

Field                        Bits  Hex Digits  Description
─────────────────────────────────────────────────────────────────────────
time_low (modified)          32    8           Local identifier (UID/GID) + partial timestamp
time_mid                     16    4           Middle 16 bits of timestamp
time_hi_and_version          16    4           High 12 bits of timestamp + 4-bit version (0010)
clock_seq_hi_and_reserved    8     2           2-bit variant (10) + 6 high bits of clock sequence
clock_seq_low (repurposed)   8     2           Local domain identifier (0=user, 1=group, 2=org)
node                         48    12          Node identifier (MAC address or random)
                

Key differences from v1: The time_low field (32 bits) is split to embed the local identifier, and clock_seq_low (8 bits) is repurposed to store the local domain type. The exact bit allocation within time_low is implementation-specific and not fully documented in RFC 4122.

Local domain values: The domain field indicates the type of local identifier: 0 = person/user (POSIX UID), 1 = group (POSIX GID), 2 = organization. This tells the system how to interpret the embedded identifier.

Ordering behavior: because v2 is derived from v1, it contains time information, but the modification of the timestamp and time_low fields means ordering behavior is implementation-dependent and should not be relied upon for sorting. In practice, v2 provides only partial sortability.

Deterministic generation: GUID / UUID v2 is not deterministic. Different systems generating v2 GUIDs / UUIDs at the same time will produce different identifiers due to differences in UID/GID, node address and clock sequence.

Try our GUID / UUID Inspector and see for yourself what fields are available.

Format and structure

GUID / UUID v2 uses the standard 8-4-4-4-12 canonical format with 32 hexadecimal digits separated by hyphens (36 characters total).

Canonical format:  8-4-4-4-12
Example (v2):      000003e8-8b86-21d0-b42d-00c04fc964ff
Layout:            xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx
                                 ^    ^
                                 |    └─ N = Variant: is typically 8, 9, a or b (RFC variant)
                                 └────── M = Version: first hex digit of the 3rd group is "2" for v2
                

Practical rule: in the canonical string, the version is encoded as the first hex digit of the third group. For v2 it is 2. The variant is indicated by the high bits of the fourth group (often rendered as 8-b in hex for the common standard variant). Other internal fields should be treated as opaque and implementation-specific.

Frequently Asked Questions

Conclusion

GUID / UUID v2 is a historical, DCE-specific variant that is rarely encountered in modern systems. While it builds on the time-based structure of v1, its lack of formal standardization, limited support and significant privacy drawbacks make it unsuitable for new applications. For modern designs.