RFC 9562, published by the IETF in May 2024, is the current UUID standard. It obsoletes RFC 4122, which had been the definitive reference since 2005. For most developers the change is invisible — the canonical format and the widely used v4 are unchanged. But RFC 9562 adds three new versions, deprecates two old ones, and defines a new sentinel value. Here is what actually changed.
What RFC 4122 covered
RFC 4122 defined the UUID format and five versions:
- v1 — time-based, with a 60-bit timestamp and the host MAC address
- v2 — DCE Security, embedding a POSIX UID/GID; rarely implemented
- v3 — name-based, using MD5 hashing
- v4 — random, using a CSPRNG
- v5 — name-based, using SHA-1 hashing
The 8-4-4-4-12 hexadecimal string format, the variant bits, and the version field are all unchanged in RFC 9562.
New versions added by RFC 9562
UUID v6 — reordered timestamp
v6 takes the same 60-bit Gregorian timestamp as v1 and reorders the fields so that the most significant bits come first. This makes v6 lexicographically sortable, fixing the primary complaint about v1 without abandoning the timestamp format. v6 is intended as a drop-in replacement for v1 in systems that need timestamp-ordered values.
v1 timestamp layout: time_low | time_mid | time_high_and_version
v6 timestamp layout: time_high | time_mid | time_low_and_version
v6 is not the preferred new version — v7 is — but it exists as a migration path for systems already on v1.
UUID v7 — Unix millisecond timestamp
v7 is the most practically significant addition. It uses a 48-bit Unix timestamp in milliseconds as its leading bits, which gives it lexicographical sort order aligned with creation time. The remaining bits are filled from a CSPRNG with an optional monotonic counter for sub-millisecond ordering.
This is the version that PostgreSQL 18 implemented natively as uuidv7(), and it is the current recommendation for database primary keys in new projects.
UUID v8 — custom layout
v8 reserves a space for application-defined or experimental UUID formats. The only fixed fields are the version (4 bits) and variant (2 bits) — the remaining 122 bits are entirely up to the implementer. This version exists to give non-standard UUID formats a formal home within the RFC rather than creating incompatible identifiers.
Deprecations
RFC 9562 explicitly deprecates v1 and v2:
- v1 is deprecated in favour of v6 and v7. The MAC address embedded in v1 is a privacy leak, and the timestamp field ordering is not sortable. v7 supersedes it for all practical purposes.
- v2 (DCE Security) is deprecated outright. It was poorly specified in RFC 4122, rarely implemented correctly, and has no recommended replacement within the UUID standard.
The Max UUID sentinel
RFC 9562 defines a Max UUID alongside the Nil UUID:
| Sentinel | Value |
|---|---|
| Nil UUID | 00000000-0000-0000-0000-000000000000 |
| Max UUID | ffffffff-ffff-ffff-ffff-ffffffffffff |
Max UUID is all ones — the complement of Nil UUID. It is defined as a sentinel value with no version or variant interpretation. Use cases mirror those of Nil: representing an absent value at the upper bound of a range, or as a boundary marker in queries.
What does not change
Everything that worked under RFC 4122 continues to work under RFC 9562:
- The 8-4-4-4-12 string format is unchanged
- v3, v4, and v5 semantics are unchanged
- The variant bits (
10xx) identifying RFC-standard UUIDs are unchanged - All existing UUIDs remain valid
RFC 9562 is strictly additive and backwards-compatible. There is no required migration. If you are generating v4 UUIDs today, the only relevant change is that v7 is now a formally standardised option worth considering for internal database identifiers.
Summary of changes
| Change | Detail |
|---|---|
| Added v6 | Reordered v1 timestamp — sortable, v1 drop-in |
| Added v7 | Unix ms timestamp — recommended for DB keys |
| Added v8 | Custom layout for application-defined formats |
| Added Max UUID | All-ones sentinel, complement of Nil |
| Deprecated v1 | Replaced by v6 and v7 |
| Deprecated v2 | DCE Security — no replacement |
| Format unchanged | 8-4-4-4-12, variant bits, v3/v4/v5 unaffected |
Further reading
- UUID Versions — all eight RFC 9562 versions explained with use cases
- UUID v4 vs UUID v7 — choosing between the two most common versions
- What is a UUID? — the format, structure, and version field explained
Frequently asked questions
What did RFC 9562 add to the UUID standard?
RFC 9562, published in May 2024, adds UUID v6 (reordered timestamp for sortability), v7 (Unix millisecond timestamp), and v8 (custom layout). It also defines the Max UUID sentinel (all-ones complement of the Nil UUID) and deprecates v1 and v2. The existing format and v3, v4, v5 semantics are unchanged.
Is UUID v1 deprecated?
Yes. RFC 9562 explicitly deprecates v1 for new work. v1 embeds the host MAC address (a privacy leak) and its timestamp field ordering is not lexicographically sortable. UUID v7 supersedes it for time-ordered use cases, and v6 exists as a drop-in replacement for systems already on v1.
Which UUID version should I use?
For database primary keys and event IDs, use v7 — its millisecond timestamp prefix keeps B-tree inserts sequential. For externally visible identifiers like URLs and tokens, use v4 — pure randomness with no timestamp leakage. v5 is the choice when you need a deterministic UUID derived from a name or URL.
Is RFC 4122 still valid?
RFC 4122 has been obsoleted by RFC 9562, published in May 2024. Implementations conforming to RFC 4122 are still compatible — RFC 9562 is backwards-compatible and extends rather than breaks the earlier standard. However, new implementations should reference RFC 9562.
What UUID versions does RFC 9562 add?
RFC 9562 formally standardises UUID v6 (reordered timestamp for sortability), UUID v7 (Unix millisecond timestamp), and UUID v8 (custom/experimental layout). These existed as drafts before but only became an official IETF standard with RFC 9562 in May 2024.