rfc9562.original   rfc9562.txt 
uuidrev K. R. Davis Internet Engineering Task Force (IETF) K. Davis
Internet-Draft Cisco Systems Request for Comments: 9562 Cisco Systems
Obsoletes: 4122 (if approved) B. G. Peabody Obsoletes: 4122 B. Peabody
Intended status: Standards Track Uncloud Category: Standards Track Uncloud
Expires: 9 May 2024 P. Leach ISSN: 2070-1721 P. Leach
University of Washington University of Washington
6 November 2023 May 2024
Universally Unique IDentifiers (UUID) Universally Unique IDentifiers (UUIDs)
draft-ietf-uuidrev-rfc4122bis-14
Abstract Abstract
This specification defines the UUIDs (Universally Unique IDentifiers) This specification defines UUIDs (Universally Unique IDentifiers)
and the UUID Uniform Resource Name (URN) namespace. UUIDs are also (also known as Globally Unique IDentifiers (GUIDs)) and a Uniform
known as GUIDs (Globally Unique IDentifiers). A UUID is 128 bits Resource Name namespace for UUIDs. A UUID is 128 bits long and is
long and is intended to guarantee uniqueness across space and time. intended to guarantee uniqueness across space and time. UUIDs were
UUIDs were originally used in the Apollo Network Computing System and originally used in the Apollo Network Computing System (NCS), later
later in the Open Software Foundation's (OSF) Distributed Computing in the Open Software Foundation's (OSF's) Distributed Computing
Environment (DCE), and then in Microsoft Windows platforms. Environment (DCE), and then in Microsoft Windows platforms.
This specification is derived from the DCE specification with the This specification is derived from the OSF DCE specification with the
kind permission of the OSF (now known as The Open Group). kind permission of the OSF (now known as "The Open Group").
Information from earlier versions of the DCE specification have been Information from earlier versions of the OSF DCE specification have
incorporated into this document. This document obsoletes RFC4122. been incorporated into this document. This document obsoletes RFC
4122.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 9 May 2024. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9562.
Copyright Notice Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Motivation
2.1. Update Motivation . . . . . . . . . . . . . . . . . . . . 4 2.1. Update Motivation
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Terminology
3.1. Requirements Language . . . . . . . . . . . . . . . . . . 6 3.1. Requirements Language
3.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 7 3.2. Abbreviations
3.3. Changelog . . . . . . . . . . . . . . . . . . . . . . . . 8 4. UUID Format
4. UUID Format . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.1. Variant Field
4.1. Variant Field . . . . . . . . . . . . . . . . . . . . . . 14 4.2. Version Field
4.2. Version Field . . . . . . . . . . . . . . . . . . . . . . 15 5. UUID Layouts
5. UUID Layouts . . . . . . . . . . . . . . . . . . . . . . . . 17 5.1. UUID Version 1
5.1. UUID Version 1 . . . . . . . . . . . . . . . . . . . . . 17 5.2. UUID Version 2
5.2. UUID Version 2 . . . . . . . . . . . . . . . . . . . . . 19 5.3. UUID Version 3
5.3. UUID Version 3 . . . . . . . . . . . . . . . . . . . . . 19 5.4. UUID Version 4
5.4. UUID Version 4 . . . . . . . . . . . . . . . . . . . . . 20 5.5. UUID Version 5
5.5. UUID Version 5 . . . . . . . . . . . . . . . . . . . . . 21 5.6. UUID Version 6
5.6. UUID Version 6 . . . . . . . . . . . . . . . . . . . . . 23 5.7. UUID Version 7
5.7. UUID Version 7 . . . . . . . . . . . . . . . . . . . . . 25 5.8. UUID Version 8
5.8. UUID Version 8 . . . . . . . . . . . . . . . . . . . . . 26 5.9. Nil UUID
5.9. Nil UUID . . . . . . . . . . . . . . . . . . . . . . . . 27 5.10. Max UUID
5.10. Max UUID . . . . . . . . . . . . . . . . . . . . . . . . 28 6. UUID Best Practices
6. UUID Best Practices . . . . . . . . . . . . . . . . . . . . . 28 6.1. Timestamp Considerations
6.1. Timestamp Considerations . . . . . . . . . . . . . . . . 28 6.2. Monotonicity and Counters
6.2. Monotonicity and Counters . . . . . . . . . . . . . . . . 30 6.3. UUID Generator States
6.3. UUID Generator States . . . . . . . . . . . . . . . . . . 34 6.4. Distributed UUID Generation
6.4. Distributed UUID Generation . . . . . . . . . . . . . . . 35 6.5. Name-Based UUID Generation
6.5. Name-Based UUID Generation . . . . . . . . . . . . . . . 36 6.6. Namespace ID Usage and Allocation
6.6. Namespace ID Usage and Allocation . . . . . . . . . . . . 37 6.7. Collision Resistance
6.7. Collision Resistance . . . . . . . . . . . . . . . . . . 39 6.8. Global and Local Uniqueness
6.8. Global and Local Uniqueness . . . . . . . . . . . . . . . 40 6.9. Unguessability
6.9. Unguessability . . . . . . . . . . . . . . . . . . . . . 40 6.10. UUIDs That Do Not Identify the Host
6.10. UUIDs That Do Not Identify the Host . . . . . . . . . . . 40 6.11. Sorting
6.11. Sorting . . . . . . . . . . . . . . . . . . . . . . . . . 41 6.12. Opacity
6.12. Opacity . . . . . . . . . . . . . . . . . . . . . . . . . 42 6.13. DBMS and Database Considerations
6.13. DBMS and Database Considerations . . . . . . . . . . . . 42 7. IANA Considerations
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 7.1. IANA UUID Subtype Registry and Registration
7.1. IANA UUID Subtype Registry and Registration . . . . . . . 43 7.2. IANA UUID Namespace ID Registry and Registration
7.2. IANA UUID Namespace ID Registry and Registration . . . . 45 8. Security Considerations
8. Security Considerations . . . . . . . . . . . . . . . . . . . 45 9. References
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 46 9.1. Normative References
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 46 9.2. Informative References
10.1. Normative References . . . . . . . . . . . . . . . . . . 46 Appendix A. Test Vectors
10.2. Informative References . . . . . . . . . . . . . . . . . 47 A.1. Example of a UUIDv1 Value
Appendix A. Test Vectors . . . . . . . . . . . . . . . . . . . . 51 A.2. Example of a UUIDv3 Value
A.1. Example of a UUIDv1 Value . . . . . . . . . . . . . . . . 52 A.3. Example of a UUIDv4 Value
A.2. Example of a UUIDv3 Value . . . . . . . . . . . . . . . . 52 A.4. Example of a UUIDv5 Value
A.3. Example of a UUIDv4 Value . . . . . . . . . . . . . . . . 53 A.5. Example of a UUIDv6 Value
A.4. Example of a UUIDv5 Value . . . . . . . . . . . . . . . . 53 A.6. Example of a UUIDv7 Value
A.5. Example of a UUIDv6 Value . . . . . . . . . . . . . . . . 54 Appendix B. Illustrative Examples
A.6. Example of a UUIDv7 Value . . . . . . . . . . . . . . . . 55 B.1. Example of a UUIDv8 Value (Time-Based)
Appendix B. Illustrative Examples . . . . . . . . . . . . . . . 55 B.2. Example of a UUIDv8 Value (Name-Based)
B.1. Example of a UUIDv8 Value (time-based) . . . . . . . . . 55 Acknowledgements
B.2. Example of a UUIDv8 Value (name-based) . . . . . . . . . 56 Authors' Addresses
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 57
1. Introduction 1. Introduction
This specification defines the UUIDs (Universally Unique IDentifiers) This specification defines a Uniform Resource Name namespace for
and the UUID Uniform Resource Name (URN) namespace. UUIDs are also Universally Unique IDentifiers (UUIDs) (also known as Globally Unique
known as GUIDs (Globally Unique IDentifiers). A UUID is 128 bits IDentifiers (GUIDs)). A UUID is 128 bits long and requires no
long and requires no central registration process. central registration process.
The use of UUIDs is extremely pervasive in computing. They comprise The use of UUIDs is extremely pervasive in computing. They comprise
the core identifier infrastructure for many operating systems such as the core identifier infrastructure for many operating systems such as
Microsoft Windows and applications such as the Mozilla Web browser Microsoft Windows and applications such as the Mozilla Web browser;
and in many cases, become exposed in many non-standard ways. in many cases, they can become exposed in many non-standard ways.
This specification attempts to standardize that practice as openly as This specification attempts to standardize that practice as openly as
possible and in a way that attempts to benefit the entire Internet. possible and in a way that attempts to benefit the entire Internet.
The information here is meant to be a concise guide for those wishing The information here is meant to be a concise guide for those wishing
to implement services using UUIDs either in combination with URNs to implement services using UUIDs either in combination with URNs
[RFC8141] or otherwise. [RFC8141] or otherwise.
There is an ITU-T Recommendation and an ISO/IEC Standard [X667] that There is an ITU-T Recommendation and an ISO/IEC Standard [X667] that
are derived from [RFC4122]. Both sets of specifications have been are derived from [RFC4122]. Both sets of specifications have been
aligned and are fully technically compatible. Nothing in this aligned and are fully technically compatible. Nothing in this
document should be construed to override the DCE standards that document should be construed to override the DCE standards that
defined UUIDs. defined UUIDs.
2. Motivation 2. Motivation
One of the main reasons for using UUIDs is that no centralized One of the main reasons for using UUIDs is that no centralized
authority is required to administer them (although two formats may authority is required to administer them (although two formats may
leverage optional IEEE 802 node identifiers, others do not). As a leverage optional IEEE 802 Node IDs, others do not). As a result,
result, generation on demand can be completely automated and used for generation on demand can be completely automated and used for a
a variety of purposes. The UUID generation algorithm described here variety of purposes. The UUID generation algorithm described here
supports very high allocation rates of 10 million per second per supports very high allocation rates of 10 million per second per
machine or more if necessary, so that they could even be used as machine or more, if necessary, so that they could even be used as
transaction IDs. transaction IDs.
UUIDs are of a fixed size (128 bits), which is reasonably small UUIDs are of a fixed size (128 bits), which is reasonably small
compared to other alternatives. This lends itself well to sorting, compared to other alternatives. This lends itself well to sorting,
ordering, and hashing of all sorts, storing in databases, simple ordering, and hashing of all sorts; storing in databases; simple
allocation, and ease of programming in general. allocation; and ease of programming in general.
Since UUIDs are unique and persistent, they make excellent Uniform Since UUIDs are unique and persistent, they make excellent URNs. The
Resource Names. The unique ability to generate a new UUID without a unique ability to generate a new UUID without a registration process
registration process allows for UUIDs to be one of the URNs with the allows for UUIDs to be one of the URNs with the lowest minting cost.
lowest minting cost.
2.1. Update Motivation 2.1. Update Motivation
Many things have changed in the time since UUIDs were originally Many things have changed in the time since UUIDs were originally
created. Modern applications have a need to create and utilize UUIDs created. Modern applications have a need to create and utilize UUIDs
as the primary identifier for a variety of different items in complex as the primary identifier for a variety of different items in complex
computational systems, including but not limited to database keys, computational systems, including but not limited to database keys,
file names, machine or system names, and identifiers for event-driven file names, machine or system names, and identifiers for event-driven
transactions. transactions.
One area in which UUIDs have gained popularity is database keys. One area in which UUIDs have gained popularity is database keys.
This stems from the increasingly distributed nature of modern This stems from the increasingly distributed nature of modern
applications. In such cases, "auto increment" schemes often used by applications. In such cases, "auto-increment" schemes that are often
databases do not work well, as the effort required to coordinate used by databases do not work well: the effort required to coordinate
sequential numeric identifiers across a network can easily become a sequential numeric identifiers across a network can easily become a
burden. The fact that UUIDs can be used to create unique, reasonably burden. The fact that UUIDs can be used to create unique, reasonably
short values in distributed systems without requiring coordination short values in distributed systems without requiring coordination
makes them a good alternative, but UUID versions 1-5, which were makes them a good alternative, but UUID versions 1-5, which were
originally defined by [RFC4122], lack certain other desirable originally defined by [RFC4122], lack certain other desirable
characteristics: characteristics, such as:
1. Non-time-ordered UUID versions such as UUIDv4 (described in 1. UUID versions that are not time ordered, such as UUIDv4
Section 5.4) have poor database index locality. This means that (described in Section 5.4), have poor database-index locality.
new values created in succession are not close to each other in This means that new values created in succession are not close to
the index and thus require inserts to be performed at random each other in the index; thus, they require inserts to be
locations. The resulting negative performance effects on common performed at random locations. The resulting negative
structures used for this (B-tree and its variants) can be performance effects on the common structures used for this
dramatic. (B-tree and its variants) can be dramatic.
2. The 100-nanosecond Gregorian epoch used in UUIDv1 (described in 2. The 100-nanosecond Gregorian Epoch used in UUIDv1 timestamps
Section 5.1) timestamps is uncommon and difficult to represent (described in Section 5.1) is uncommon and difficult to represent
accurately using a standard number format such as [IEEE754]. accurately using a standard number format such as that described
in [IEEE754].
3. Introspection/parsing is required to order by time sequence, as 3. Introspection/parsing is required to order by time sequence, as
opposed to being able to perform a simple byte-by-byte opposed to being able to perform a simple byte-by-byte
comparison. comparison.
4. Privacy and network security issues arise from using a MAC 4. Privacy and network security issues arise from using a Media
address in the node field of UUID version 1. Exposed MAC Access Control (MAC) address in the node field of UUIDv1.
addresses can be used as an attack surface to locate network Exposed MAC addresses can be used as an attack surface to locate
interfaces and reveal various other information about such network interfaces and reveal various other information about
machines (minimally manufacturer, potentially other details). such machines (minimally, the manufacturer and, potentially,
Additionally, with the advent of virtual machines and containers, other details). Additionally, with the advent of virtual
MAC address uniqueness is no longer guaranteed. machines and containers, uniqueness of the MAC address is no
longer guaranteed.
5. Many of the implementation details specified in [RFC4122] 5. Many of the implementation details specified in [RFC4122]
involved trade offs that are neither possible to specify for all involved trade-offs that are neither possible to specify for all
applications nor necessary to produce interoperable applications nor necessary to produce interoperable
implementations. implementations.
6. [RFC4122] did not distinguish between the requirements for 6. [RFC4122] did not distinguish between the requirements for
generating a UUID and those for simply storing one, although they generating a UUID and those for simply storing one, although they
are often different. are often different.
Due to the aforementioned issues, many widely distributed database Due to the aforementioned issues, many widely distributed database
applications and large application vendors have sought to solve the applications and large application vendors have sought to solve the
problem of creating a better time-based, sortable unique identifier problem of creating a better time-based, sortable unique identifier
for use as a database key. This has led to numerous implementations for use as a database key. This has led to numerous implementations
over the past 10+ years solving the same problem in slightly over the past 10+ years solving the same problem in slightly
different ways. different ways.
While preparing this specification, the following 16 different While preparing this specification, the following 16 different
implementations were analyzed for trends in total ID length, bit implementations were analyzed for trends in total ID length, bit
layout, lexical formatting/encoding, timestamp type, timestamp layout, lexical formatting and encoding, timestamp type, timestamp
format, timestamp accuracy, node format/components, collision format, timestamp accuracy, node format and components, collision
handling, and multi-timestamp tick generation sequencing: handling, and multi-timestamp tick generation sequencing:
1. [ULID] by A. Feerasta 1. [ULID]
2. [LexicalUUID] by Twitter 2. [LexicalUUID]
3. [Snowflake] by Twitter 3. [Snowflake]
4. [Flake] by Boundary 4. [Flake]
5. [ShardingID] by Instagram 5. [ShardingID]
6. [KSUID] by Segment 6. [KSUID]
7. [Elasticflake] by P. Pearcy 7. [Elasticflake]
8. [FlakeID] by T. Pawlak 8. [FlakeID]
9. [Sonyflake] by Sony 9. [Sonyflake]
10. [orderedUuid] by IT. Cabrera 10. [orderedUuid]
11. [COMBGUID] by R. Tallent 11. [COMBGUID]
12. [SID] by A. Chilton 12. [SID]
13. [pushID] by Google 13. [pushID]
14. [XID] by O. Poitrey 14. [XID]
15. [ObjectID] by MongoDB 15. [ObjectID]
16. [CUID] by E. Elliott 16. [CUID]
An inspection of these implementations and the issues described above An inspection of these implementations and the issues described above
has led to this document which intends to adapt new UUIDs to address has led to this document, in which new UUIDs are adapted to address
these issues. these issues.
Further, [RFC4122] itself was in need an overhaul to address a number Further, [RFC4122] itself was in need of an overhaul to address a
of topics such as but not limited to the following: number of topics such as, but not limited to, the following:
1. Miscellaneous erratas. Mostly around bit layout clarifications 1. Implementation of miscellaneous errata reports. Mostly around
which lead to inconsistent implementations. bit-layout clarifications, which lead to inconsistent
implementations [Err1957], [Err3546], [Err4975], [Err4976],
[Err5560], etc.
2. Decouple other UUID versions from UUIDv1 bit layout so that 2. Decoupling other UUID versions from the UUIDv1 bit layout so that
fields like "time_hi_and_version" do not need to be referenced fields like "time_hi_and_version" do not need to be referenced
within a non-time-based UUID while also providing "UUIDv1 like" within a UUID that is not time based while also providing
definition sections for UUIDv3, UUIDv4, and UUIDv5. definition sections similar to that for UUIDv1 for UUIDv3,
UUIDv4, and UUIDv5.
3. Provide implementation best practices around many real-world 3. Providing implementation best practices around many real-world
scenarios and corner cases observed by existing and prototype scenarios and corner cases observed by existing and prototype
implementations. implementations.
4. Update the document to address security best practices and 4. Addressing security best practices and considerations for the
considerations for the modern age as it pertains MAC addresses, modern age as it pertains to MAC addresses, hashing algorithms,
hashing algorithms, secure randomness, and other topics. secure randomness, and other topics.
5. Provide implementations a standard-based option for 5. Providing implementations a standard-based option for
implementation specific and/or experimental UUID designs. implementation-specific and/or experimental UUID designs.
6. Provide more test vectors that illustrate real UUIDs created as 6. Providing more test vectors that illustrate real UUIDs created as
per the specification. per the specification.
3. Terminology 3. Terminology
3.1. Requirements Language 3.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3.2. Abbreviations 3.2. Abbreviations
The following abbreviations are used in this document: The following abbreviations are used in this document:
UUID Universally Unique Identifier
UUIDv1 Universally Unique Identifier Version 1
UUIDv2 Universally Unique Identifier Version 2
UUIDv3 Universally Unique Identifier Version 3
UUIDv4 Universally Unique Identifier Version 4
UUIDv5 Universally Unique Identifier Version 5
UUIDv6 Universally Unique Identifier Version 6
UUIDv7 Universally Unique Identifier Version 7
UUIDv8 Universally Unique Identifier Version 8
URN Uniform Resource Names
ABNF Augmented Backus-Naur Form ABNF Augmented Backus-Naur Form
CSPRNG Cryptographically Secure Pseudo-Random Number Generator CSPRNG Cryptographically Secure Pseudorandom Number Generator
MAC Media Access Control
MSB Most Significant Bit
DBMS Database Management System DBMS Database Management System
IEEE Institute of Electrical and Electronics Engineers, Inc. IEEE Institute of Electrical and Electronics Engineers
ITU International Telecommunication Union ITU International Telecommunication Union
MAC Media Access Control
MD5 Message Digest 5 MD5 Message Digest 5
MSB Most Significant Bit
OID Object Identifier
SHA Secure Hash Algorithm SHA Secure Hash Algorithm
SHA-1 Secure Hash Algorithm 1 with message digest of 160 bits SHA-1 Secure Hash Algorithm 1 (with message digest of 160
bits)
SHA-3 Secure Hash Algorithm 3 (arbitrary size)
SHA-224 Secure Hash Algorithm 2 with message digest size of 224 SHA-224 Secure Hash Algorithm 2 with message digest size of 224
bits bits
SHA-256 Secure Hash Algorithm 2 with message digest size of 256 SHA-256 Secure Hash Algorithm 2 with message digest size of 256
bits bits
SHA-512 Secure Hash Algorithm 2 with message digest size of 512 SHA-512 Secure Hash Algorithm 2 with message digest size of 512
bits bits
SHA-3 Secure Hash Algorithm 3 SHAKE Secure Hash Algorithm 3 based on the KECCAK algorithm
SHAKE Secure Hash Algorithm 3 based on KECCAK algorithm URN Uniform Resource Names
UTC Coordinated Universal Time UTC Coordinated Universal Time
OID Object Identifier UUID Universally Unique Identifier
3.3. Changelog
This section is to be removed before publishing as an RFC.
draft-14
* AD Review #2: IANA Subtype Modifications #170
* AD Review #2: Specify Values for Variant/Subtype Column #171
* AD Review #2: Grammar change at the end of 5.1 #172
* SHA and Integer Verbiage clarifications #174
* Disclaimer in nil/max that these do not fall into IETF variants
#175
* Fix v1/v6 final UUID in test vector #176
draft-13
* Request IANA Registry #144
* Describe allocation logic of Namespace ID #161
* Move citation of Namesapce ID up to first instance in v3/v5 #167
* Further normalize Namespace verbiage #166
* Fix Timestamp of Time-Based UUIDv8 Example #164
* Change RFC8937 and RFC4086 to Informative References #163
* Discuss why v3/v5 are bad for Database Usage #155
draft-12
* Typos #148 #156
* SECDIR Review #141
* SECDIR Review 2 #142
* OPSDIR Review #145
* INDIR Review 2 #140
* IESG Grammar #146
* Revise 16-bit MAC Node Usage #149
* Add MSB3 to Variant Table #153
* Additional Update Motivations #157
* Expand v8 Time-based Example to larger timestamp #159
* Fix Randomized Node value's mcast bit in Appendix #151
* Clarify "Name-Based" is the same as "Hash-Based" #154
* Move UUIDv8 Examples out of Test Vectors #150
* Simplify UUIDv8 Hash-based Example #147
draft-11
* Normalize "name space" to "namespace" everywhere #137
* IANA Review: Verbiage to update RFC4122 references #134
* DNSDIR re-review: Better Define "a canonical sequence of octets"
#136
* Crosspost: Typo in Approximate UUID timestamp calculations #135
* INTDIR Review #139
draft-10
* ARTART Review and Feedback #130
* Clarify Hash Space IDs listed are not the only options #132
* Add example to timestamp fuzzing #133
draft-09
* Late addition of IETF reference for CSPRNG guidance #123
* DNSDIR Review: Typos! #122
* DNSDIR Review: DNS Considerations Update #121
* Error in UUIDv8 Name-based Test Vector #129
* Improve consistency of layout field definitions #128
draft-08
* Fix typos #113
* Fix errata 6225 (again) #117 #118
* AD Review: BCP 14 - SHOULD #114
* AD Review: Add proper references to v1 and v6 #116
* AD Review: Remove SHOULD in section 4 #120
* Discuss "front-loaded rollover counter" for 32-bit epoch with
Padding method #115
draft-07
* Even more grammar tweaks! #109
* Remove unnecessary "32 bit" in UUIDv7 example #108
* Change "fixed millisecond" -> "millisecond by default" relating to
v7 #110
* Revert Max UUID Naming #107
* Author Changes
* More Grammar edits! #102
* Tweak v7 description to de-emphasize optional components #103
* Better Clarify Case in ABNF #104
* Verbiage change in 6.2 #105
draft-05
* Changed Max UUID to Max UUID to better complement Latin Nil UUID
verbiage. #95
* Align Method 3 text with the 12 bits limitation #96
* Make Version/version casing consistent across 5. UUID Layouts #97
* Cite MS COM GUID as little-endian #95
draft-04
* Remove extra words #82, #88, and #93 UUIDv1 Universally Unique Identifier version 1
* Punctuation and minor style fixes #84
* Change rounding mode of Method 4 Section 6.2 #90 (from #86)
* Add verbal description of v7 generation to 5.7. UUID Version 7
#91
* Remove Re-randomize Until Monotonic (Method 3) from Monotonicity
and Counters #92
* Fix ambiguous text around UUIDv6 clock sequence #89
* Move endianness statement from layout to format section #85
* Further modified abstract to separate URN topic from UUID
definition #83
* Provided three more UUID format examples #83
* Added text further clarifying version construct is for the variant
in this doc #83
* Provided further clarification for local/global bit vs multicast
bit #83
draft-03 UUIDv2 Universally Unique Identifier version 2
* Revised IANA Considerations #71 UUIDv3 Universally Unique Identifier version 3
* Fix "integral numbers of octets" verbiage #67
* Transpose UUID Namespaces to match UUID Hashspaces #70
* Reference all Hash Algorithms. #69
* Normalize SHA abbreviation formats #66
* Add other Hash Abbreviations #65
* Remove URN from title #73
* Move Community Considerations to Introduction #68
* Move some Normative Reference to Informative #74
* Misc formatting changes to address IDNITS feedback
* Downgrade MUST NOT to SHOULD NOT for guessability of UUIDs #75
* Misc. text formatting, typo fixes #78
* Misc. text clarifications #79
* Misc. SHOULD/MUST adjustments #80
* Method 3 and 4 added to monotonic section #81
draft-02 UUIDv4 Universally Unique Identifier version 4
* Change md5_high in SHA-1 section to sha1_mid #59 UUIDv5 Universally Unique Identifier version 5
* Describe Nil/Max UUID in variant table #16
* Further Clarify that non-descript node IDs are the preferred
method in distributed UUID Generation #49
* Appendix B, consistent naming #55
* Remove duplicate ABNF from IANA considerations #56
* Monotonic Error Checking missing newline #57
* More Security Considerations Randomness #26
* SHA-256 UUID Generation #50
* Expand multiplexed fields within v1 and v6 bit definitions #43
* Clean up text in UUIDs that Do Not Identify the Host #61
* Revise UUID Generator States section #47
* Expand upon why unix epoch rollover is not a problem #44
* Delete Sample Code Appendix #62
draft-01 UUIDv6 Universally Unique Identifier version 6
* Mixed Case Spelling error #18 UUIDv7 Universally Unique Identifier version 7
* Add "UUIDs that Do Not Identify the Host as well" reference to
security considerations #19
* Out of Place Distributed node text #20
* v6 clock_seq and node usage ambiguity #21
* Figure 2 and 3 Fix Title #22
* Move Namespace Registration Template to IANA Considerations #23
* Verify ABNF formatting against RFC5234 #24
* Bump ABNF reference to RFC 5234 #25
* Modify v8 SHOULD NOT to MUST NOT #27
* Remove "time-based" constraint from version 8 UUID #29
* Further clarify v7 field description #125 #30
* Typo: Section 4.2, Version Field, "UUID from in this" #33
* Create better ABNF to represent Hex Digit #39
* Break Binary form of UUID into two lines. #40
* Move octet text from section 4 to section 5 #41
* Add forward reference to UUIDv1 and UUIDv4 in Section 2 #42
* Erroneous reference to v1 in monotonicity #45
* Add Label for "Monotonic Error Checking" paragraph to frame the
topic #46
* Remove IEEE paragraph from "uuids that do not identify the host"
#48
* Grammar Review #52
draft-00 UUIDv8 Universally Unique Identifier version 8
* Merge RFC4122 with draft-peabody-dispatch-new-uuid-format-04.md
* Change: Reference RFC1321 to RFC6151
* Change: Reference RFC2141 to RFC8141
* Change: Reference RFC2234 to RFC5234
* Change: Reference FIPS 180-1 to FIPS 180-4 for SHA-1
* Change: Converted UUIDv1 to match UUIDv6 section from Draft 04
* Change: Trimmed down the ABNF representation
* Change: http websites to https equivalent
* Errata: Bad Reference to RFC1750 | 3641 #4
* Errata: Change MD5 website to example.com | 3476 #6 (Also Fixes
Errata: Fix uuid_create_md5_from_name() | 1352 #2)
* Errata: Typo in code comment | 6665 #11
* Errata: Fix BAD OID acronym | 6225 #9
* Errata: Incorrect Parenthesis usage Section 4.3 | 184 #5
* Errata: Lexicographically Sorting Paragraph Fix | 1428 #3
* Errata: Fix 4.1.3 reference to the correct bits | 1957 #13
* Errata: Fix reference to variant in octet 8 | 4975 #7
* Errata: Further clarify 3rd/last bit of Variant for spec | 5560 #8
* Errata: Fix clock_seq_hi_and_reserved most-significant bit
verbiage | 4976 #10
* Errata: Better Clarify network byte order when referencing most
significant bits | 3546 #12
* Draft 05: B.2. Example of a UUIDv7 Value two "var" in table #120
* Draft 05: MUST verbiage in Reliability of 6.1 #121
* Draft 05: Further discourage centralized registry for distributed
UUID Generation.
* New: Further Clarity of exact octet and bit of var/ver in this
spec
* New: Block diagram, bit layout, test vectors for UUIDv4
* New: Block diagram, bit layout, test vectors for UUIDv3
* New: Block diagram, bit layout, test vectors for UUIDv5
* New: Add MD5 Security Considerations reference, RFC6151
* New: Add SHA-1 Security Considerations reference, RFC6194
4. UUID Format 4. UUID Format
The UUID format is 16 octets (128 bits) in size; the variant bits in The UUID format is 16 octets (128 bits) in size; the variant bits in
conjunction with the version bits described in the next sections conjunction with the version bits described in the next sections
determine finer structure. While discussing UUID formats and layout, determine finer structure. In terms of these UUID formats and
bit definitions start at 0 and end at 127 while octet definitions layout, bit definitions start at 0 and end at 127, while octet
start at 0 and end at 15. definitions start at 0 and end at 15.
In the absence of explicit application or presentation protocol In the absence of explicit application or presentation protocol
specification to the contrary, each field is encoded with the Most specification to the contrary, each field is encoded with the most
Significant Byte first (known as network byte order). significant byte first (known as "network byte order").
Saving UUIDs to binary format is done by sequencing all fields in Saving UUIDs to binary format is done by sequencing all fields in
big-endian format. However there is a known caveat that Microsoft's big-endian format. However, there is a known caveat that Microsoft's
Component Object Model (COM) GUIDs leverage little-endian when saving Component Object Model (COM) GUIDs leverage little-endian when saving
GUIDs. The discussion of this [MS_COM_GUID] is outside the scope of GUIDs. The discussion of this (see [MS_COM_GUID]) is outside the
this specification. scope of this specification.
UUIDs MAY be represented as binary data or integers. When in use UUIDs MAY be represented as binary data or integers. When in use
with URNs or as text in applications, any given UUID should be with URNs or as text in applications, any given UUID should be
represented by the "hex-and-dash" string format consisting of represented by the "hex-and-dash" string format consisting of
multiple groups of upper or lowercase alphanumeric hexadecimal multiple groups of uppercase or lowercase alphanumeric hexadecimal
characters separated by single dashes/hyphens. When used with characters separated by single dashes/hyphens. When used with
databases please refer to Section 6.13. databases, please refer to Section 6.13.
The formal definition of the UUID string representation is provided The formal definition of the UUID string representation is provided
by the following (ABNF) [RFC5234]. by the following ABNF [RFC5234]:
UUID = 4hexOctet "-" UUID = 4hexOctet "-"
2hexOctet "-" 2hexOctet "-"
2hexOctet "-" 2hexOctet "-"
2hexOctet "-" 2hexOctet "-"
6hexOctet 6hexOctet
hexOctet = HEXDIG HEXDIG hexOctet = HEXDIG HEXDIG
DIGIT = %x30-39 DIGIT = %x30-39
HEXDIG = DIGIT / "A" / "B" / "C" / "D" / "E" / "F" HEXDIG = DIGIT / "A" / "B" / "C" / "D" / "E" / "F"
Note that the alphabetic characters may be all uppercase, all Note that the alphabetic characters may be all uppercase, all
lowercase, or mixed case, as per [RFC5234], Section 2.3. An example lowercase, or mixed case, as per Section 2.3 of [RFC5234]. An
UUID using this textual representation from the above ABNF is shown example UUID using this textual representation from the above ABNF is
in Figure 1. shown in Figure 1.
f81d4fae-7dec-11d0-a765-00a0c91e6bf6 f81d4fae-7dec-11d0-a765-00a0c91e6bf6
Figure 1: Example String UUID format Figure 1: Example String UUID Format
The same UUID from Figure 1 is represented in Binary (Figure 2), The same UUID from Figure 1 is represented in binary (Figure 2), as
Unsigned Integer (Figure 3) and as a URN (Figure 4) defined by an unsigned integer (Figure 3), and as a URN (Figure 4) defined by
[RFC8141]. [RFC8141].
111110000001110101001111101011100111110111101100000100011101000\ 111110000001110101001111101011100111110111101100000100011101000\
01010011101100101000000001010000011001001000111100110101111110110 01010011101100101000000001010000011001001000111100110101111110110
Figure 2: Example Binary UUID Figure 2: Example Binary UUID
329800735698586629295641978511506172918 329800735698586629295641978511506172918
Figure 3: Example Unsigned Integer UUID (shown as a decimal number) Figure 3: Example Unsigned Integer UUID (Shown as a Decimal Number)
urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6
Figure 4: Example URN UUID
Figure 4: Example URN Namespace for UUID
There are many other ways to define a UUID format; some examples are There are many other ways to define a UUID format; some examples are
detailed below. Please note that this is not an exhaustive list and detailed below. Please note that this is not an exhaustive list and
is only provided for informational purposes. is only provided for informational purposes.
* Some UUID implementations, such as those found in [Python] and * Some UUID implementations, such as those found in [Python] and
[Microsoft], will output UUID with the string format, including [Microsoft], will output UUID with the string format, including
dashes, enclosed in curly braces. dashes, enclosed in curly braces.
* [X667] provides UUID format definitions for use of UUID with an * [X667] provides UUID format definitions for use of UUID with an
OID. OID.
* The legacy [IBM_NCS] implementation produces a unique UUID format
compatible with Variant 0xx of Table 1. * [IBM_NCS] is a legacy implementation that produces a unique UUID
format compatible with Variant 0xx of Table 1.
4.1. Variant Field 4.1. Variant Field
The variant field determines the layout of the UUID. That is, the The variant field determines the layout of the UUID. That is, the
interpretation of all other bits in the UUID depends on the setting interpretation of all other bits in the UUID depends on the setting
of the bits in the variant field. As such, it could more accurately of the bits in the variant field. As such, it could more accurately
be called a type field; we retain the original term for be called a "type" field; we retain the original term for
compatibility. The variant field consists of a variable number of compatibility. The variant field consists of a variable number of
the most significant bits of octet 8 of the UUID. the most significant bits of octet 8 of the UUID.
Table 1 lists the contents of the variant field, where the letter "x" Table 1 lists the contents of the variant field, where the letter "x"
indicates a "don't-care" value. indicates a "don't-care" value.
+======+======+======+======+=========+========================+ +======+======+======+======+=========+=========================+
| Msb0 | Msb1 | Msb2 | Msb3 | Variant | Description | | MSB0 | MSB1 | MSB2 | MSB3 | Variant | Description |
+======+======+======+======+=========+========================+ +======+======+======+======+=========+=========================+
| 0 | x | x | x | 1-7 | Reserved, NCS backward | | 0 | x | x | x | 1-7 | Reserved. Network |
| | | | | | compatibility and | | | | | | | Computing System (NCS) |
| | | | | | includes Nil UUID as | | | | | | | backward compatibility, |
| | | | | | per Section 5.9. | | | | | | | and includes Nil UUID |
+------+------+------+------+---------+------------------------+ | | | | | | as per Section 5.9. |
| 1 | 0 | x | x | 8-9,A-B | The variant specified | +------+------+------+------+---------+-------------------------+
| | | | | | in this document. | | 1 | 0 | x | x | 8-9,A-B | The variant specified |
+------+------+------+------+---------+------------------------+ | | | | | | in this document. |
| 1 | 1 | 0 | x | C-D | Reserved, Microsoft | +------+------+------+------+---------+-------------------------+
| | | | | | Corporation backward | | 1 | 1 | 0 | x | C-D | Reserved. Microsoft |
| | | | | | compatibility. | | | | | | | Corporation backward |
+------+------+------+------+---------+------------------------+ | | | | | | compatibility. |
| 1 | 1 | 1 | x | E-F | Reserved for future | +------+------+------+------+---------+-------------------------+
| | | | | | definition and | | 1 | 1 | 1 | x | E-F | Reserved for future |
| | | | | | includes Max UUID as | | | | | | | definition and includes |
| | | | | | per Section 5.10. | | | | | | | Max UUID as per |
+------+------+------+------+---------+------------------------+ | | | | | | Section 5.10. |
+------+------+------+------+---------+-------------------------+
Table 1: UUID Variants Table 1: UUID Variants
Interoperability, in any form, with variants other than the one Interoperability, in any form, with variants other than the one
defined here is not guaranteed but is not likely to be an issue in defined here is not guaranteed but is not likely to be an issue in
practice. practice.
Specifically for UUIDs in this document, bits 64 and 65 of the UUID Specifically for UUIDs in this document, bits 64 and 65 of the UUID
(bits 0 and 1 of octet 8) MUST be set to 1 and 0 as specified in row (bits 0 and 1 of octet 8) MUST be set to 1 and 0 as specified in row
2 of Table 1. Accordingly, all bit and field layouts avoid the use 2 of Table 1. Accordingly, all bit and field layouts avoid the use
of these bits. of these bits.
4.2. Version Field 4.2. Version Field
The version number is in the most significant 4 bits of octet 6 (bits The version number is in the most significant 4 bits of octet 6 (bits
48 through 51 of the UUID). 48 through 51 of the UUID).
Table 2 lists all of the versions for this UUID variant 10xx Table 2 lists all of the versions for this UUID variant 10xx
specified in this document. specified in this document.
+======+======+======+======+=========+=============================+ +======+======+======+======+=========+============================+
| Msb0 | Msb1 | Msb2 | Msb3 | Version | Description | | MSB0 | MSB1 | MSB2 | MSB3 | Version | Description |
+======+======+======+======+=========+=============================+ +======+======+======+======+=========+============================+
| 0 | 0 | 0 | 0 | 0 | Unused | | 0 | 0 | 0 | 0 | 0 | Unused. |
+------+------+------+------+---------+-----------------------------+ +------+------+------+------+---------+----------------------------+
| 0 | 0 | 0 | 1 | 1 | The Gregorian time-based | | 0 | 0 | 0 | 1 | 1 | The Gregorian time-based |
| | | | | | UUID specified in this | | | | | | | UUID specified in this |
| | | | | | document. | | | | | | | document. |
+------+------+------+------+---------+-----------------------------+ +------+------+------+------+---------+----------------------------+
| 0 | 0 | 1 | 0 | 2 | Reserved for DCE Security | | 0 | 0 | 1 | 0 | 2 | Reserved for DCE Security |
| | | | | | version, with embedded | | | | | | | version, with embedded |
| | | | | | POSIX UUIDs. | | | | | | | POSIX UUIDs. |
+------+------+------+------+---------+-----------------------------+ +------+------+------+------+---------+----------------------------+
| 0 | 0 | 1 | 1 | 3 | The name-based version | | 0 | 0 | 1 | 1 | 3 | The name-based version |
| | | | | | specified in this document | | | | | | | specified in this document |
| | | | | | that uses MD5 hashing. | | | | | | | that uses MD5 hashing. |
+------+------+------+------+---------+-----------------------------+ +------+------+------+------+---------+----------------------------+
| 0 | 1 | 0 | 0 | 4 | The randomly or pseudo- | | 0 | 1 | 0 | 0 | 4 | The randomly or |
| | | | | | randomly generated version | | | | | | | pseudorandomly generated |
| | | | | | specified in this | | | | | | | version specified in this |
| | | | | | document. | | | | | | | document. |
+------+------+------+------+---------+-----------------------------+ +------+------+------+------+---------+----------------------------+
| 0 | 1 | 0 | 1 | 5 | The name-based version | | 0 | 1 | 0 | 1 | 5 | The name-based version |
| | | | | | specified in this document | | | | | | | specified in this document |
| | | | | | that uses SHA-1 hashing. | | | | | | | that uses SHA-1 hashing. |
+------+------+------+------+---------+-----------------------------+ +------+------+------+------+---------+----------------------------+
| 0 | 1 | 1 | 0 | 6 | Reordered Gregorian time- | | 0 | 1 | 1 | 0 | 6 | Reordered Gregorian time- |
| | | | | | based UUID specified in | | | | | | | based UUID specified in |
| | | | | | this document. | | | | | | | this document. |
+------+------+------+------+---------+-----------------------------+ +------+------+------+------+---------+----------------------------+
| 0 | 1 | 1 | 1 | 7 | Unix Epoch time-based UUID | | 0 | 1 | 1 | 1 | 7 | Unix Epoch time-based UUID |
| | | | | | specified in this | | | | | | | specified in this |
| | | | | | document. | | | | | | | document. |
+------+------+------+------+---------+-----------------------------+ +------+------+------+------+---------+----------------------------+
| 1 | 0 | 0 | 0 | 8 | Reserved for custom UUID | | 1 | 0 | 0 | 0 | 8 | Reserved for custom UUID |
| | | | | | formats specified in this | | | | | | | formats specified in this |
| | | | | | document. | | | | | | | document. |
+------+------+------+------+---------+-----------------------------+ +------+------+------+------+---------+----------------------------+
| 1 | 0 | 0 | 1 | 9 | Reserved for future | | 1 | 0 | 0 | 1 | 9 | Reserved for future |
| | | | | | definition. | | | | | | | definition. |
+------+------+------+------+---------+-----------------------------+ +------+------+------+------+---------+----------------------------+
| 1 | 0 | 1 | 0 | 10 | Reserved for future | | 1 | 0 | 1 | 0 | 10 | Reserved for future |
| | | | | | definition. | | | | | | | definition. |
+------+------+------+------+---------+-----------------------------+ +------+------+------+------+---------+----------------------------+
| 1 | 0 | 1 | 1 | 11 | Reserved for future | | 1 | 0 | 1 | 1 | 11 | Reserved for future |
| | | | | | definition. | | | | | | | definition. |
+------+------+------+------+---------+-----------------------------+ +------+------+------+------+---------+----------------------------+
| 1 | 1 | 0 | 0 | 12 | Reserved for future | | 1 | 1 | 0 | 0 | 12 | Reserved for future |
| | | | | | definition. | | | | | | | definition. |
+------+------+------+------+---------+-----------------------------+ +------+------+------+------+---------+----------------------------+
| 1 | 1 | 0 | 1 | 13 | Reserved for future | | 1 | 1 | 0 | 1 | 13 | Reserved for future |
| | | | | | definition. | | | | | | | definition. |
+------+------+------+------+---------+-----------------------------+ +------+------+------+------+---------+----------------------------+
| 1 | 1 | 1 | 0 | 14 | Reserved for future | | 1 | 1 | 1 | 0 | 14 | Reserved for future |
| | | | | | definition. | | | | | | | definition. |
+------+------+------+------+---------+-----------------------------+ +------+------+------+------+---------+----------------------------+
| 1 | 1 | 1 | 1 | 15 | Reserved for future | | 1 | 1 | 1 | 1 | 15 | Reserved for future |
| | | | | | definition. | | | | | | | definition. |
+------+------+------+------+---------+-----------------------------+ +------+------+------+------+---------+----------------------------+
Table 2: UUID variant 10xx versions defined by this specification Table 2: UUID Variant 10xx Versions Defined by This Specification
An example version/variant layout for UUIDv4 follows the table where An example version/variant layout for UUIDv4 follows the table where
M represents the version placement for the hexadecimal representation "M" represents the version placement for the hexadecimal
of 0x4 (0b0100) and the N represents the variant placement for one of representation of 0x4 (0b0100) and the "N" represents the variant
the four possible hexadecimal representation of variant 10xx: 0x8 placement for one of the four possible hexadecimal representation of
(0b1000), 0x9 (0b1001), 0xA (0b1010), 0xB (0b1011) variant 10xx: 0x8 (0b1000), 0x9 (0b1001), 0xA (0b1010), 0xB (0b1011).
00000000-0000-4000-8000-000000000000 00000000-0000-4000-8000-000000000000
00000000-0000-4000-9000-000000000000 00000000-0000-4000-9000-000000000000
00000000-0000-4000-A000-000000000000 00000000-0000-4000-A000-000000000000
00000000-0000-4000-B000-000000000000 00000000-0000-4000-B000-000000000000
xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx
Figure 5: UUIDv4 Variant Examples Figure 5: UUIDv4 Variant Examples
It should be noted that the other remaining UUID variants found in It should be noted that the other remaining UUID variants found in
Table 1 leverage different sub-typing/versioning mechanisms. The Table 1 leverage different sub-typing or versioning mechanisms. The
recording and definition of the remaining UUID variant and sub-typing recording and definition of the remaining UUID variant and sub-typing
combinations are outside of the scope of this document. combinations are outside of the scope of this document.
5. UUID Layouts 5. UUID Layouts
To minimize confusion about bit assignments within octets and among To minimize confusion about bit assignments within octets and among
differing versions, the UUID record definition is provided as a differing versions, the UUID record definition is provided as a
grouping of fields within a bit layout consisting of four octets per grouping of fields within a bit layout consisting of four octets per
row. The fields are presented with the most significant one first. row. The fields are presented with the most significant one first.
5.1. UUID Version 1 5.1. UUID Version 1
UUID version 1 is a time-based UUID featuring a 60 bit timestamp UUIDv1 is a time-based UUID featuring a 60-bit timestamp represented
represented by Coordinated Universal Time (UTC) as a count of 100- by Coordinated Universal Time (UTC) as a count of 100-nanosecond
nanosecond intervals since 00:00:00.00, 15 October 1582 (the date of intervals since 00:00:00.00, 15 October 1582 (the date of Gregorian
Gregorian reform to the Christian calendar). reform to the Christian calendar).
UUIDv1 also features a clock sequence field which is used to help UUIDv1 also features a clock sequence field that is used to help
avoid duplicates that could arise when the clock is set backwards in avoid duplicates that could arise when the clock is set backwards in
time or if the node ID changes. time or if the Node ID changes.
The node field consists of an IEEE 802 MAC address, usually the host The node field consists of an IEEE 802 MAC address, usually the host
address or a randomly derived value per Section 6.9 and Section 6.10. address or a randomly derived value per Sections 6.9 and 6.10.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| time_low | | time_low |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| time_mid | ver | time_high | | time_mid | ver | time_high |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|var| clock_seq | node | |var| clock_seq | node |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| node | | node |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: UUIDv1 Field and Bit Layout Figure 6: UUIDv1 Field and Bit Layout
time_low: time_low:
The least significant 32 bits of the 60 bit starting timestamp. The least significant 32 bits of the 60-bit starting timestamp.
Occupies bits 0 through 31 (octets 0-3). Occupies bits 0 through 31 (octets 0-3).
time_mid: time_mid:
The middle 16 bits of the 60 bit starting timestamp. Occupies The middle 16 bits of the 60-bit starting timestamp. Occupies
bits 32 through 47 (octets 4-5). bits 32 through 47 (octets 4-5).
ver: ver:
The 4 bit version field as defined by Section 4.2, set to 0b0001 The 4-bit version field as defined by Section 4.2, set to 0b0001
(1). Occupies bits 48 through 51 of octet 6. (1). Occupies bits 48 through 51 of octet 6.
time_high: time_high:
12 bits that will contain the most significant 12 bits from the 60 The least significant 12 bits from the 60-bit starting timestamp.
bit starting timestamp. Occupies bits 52 through 63 (octets 6-7). Occupies bits 52 through 63 (octets 6-7).
var: var:
The 2 bit variant field as defined by Section 4.1, set to 0b10. The 2-bit variant field as defined by Section 4.1, set to 0b10.
Occupies bits 64 and 65 of octet 8. Occupies bits 64 and 65 of octet 8.
clock_seq: clock_seq:
The 14 bits containing the clock sequence. Occupies bits 66 The 14 bits containing the clock sequence. Occupies bits 66
through 79 (octets 8-9). through 79 (octets 8-9).
node: node:
48 bit spatially unique identifier. Occupies bits 80 through 127 48-bit spatially unique identifier. Occupies bits 80 through 127
(octets 10-15). (octets 10-15).
For systems that do not have UTC available, but do have the local For systems that do not have UTC available but do have the local
time, they may use that instead of UTC, as long as they do so time, they may use that instead of UTC as long as they do so
consistently throughout the system. However, this is not recommended consistently throughout the system. However, this is not recommended
since generating the UTC from local time only needs a time zone since generating the UTC from local time only needs a time-zone
offset. offset.
If the clock is set backwards, or might have been set backwards If the clock is set backwards, or if it might have been set backwards
(e.g., while the system was powered off), and the UUID generator can (e.g., while the system was powered off), and the UUID generator
not be sure that no UUIDs were generated with timestamps larger than cannot be sure that no UUIDs were generated with timestamps larger
the value to which the clock was set, then the clock sequence MUST be than the value to which the clock was set, then the clock sequence
changed. If the previous value of the clock sequence is known, it MUST be changed. If the previous value of the clock sequence is
MAY be incremented; otherwise it SHOULD be set to a random or high- known, it MAY be incremented; otherwise it SHOULD be set to a random
quality pseudo-random value. or high-quality pseudorandom value.
Similarly, if the node ID changes (e.g., because a network card has Similarly, if the Node ID changes (e.g., because a network card has
been moved between machines), setting the clock sequence to a random been moved between machines), setting the clock sequence to a random
number minimizes the probability of a duplicate due to slight number minimizes the probability of a duplicate due to slight
differences in the clock settings of the machines. If the value of differences in the clock settings of the machines. If the value of
the clock sequence associated with the changed node ID were known, the clock sequence associated with the changed Node ID were known,
then the clock sequence MAY be incremented, but that is unlikely. then the clock sequence MAY be incremented, but that is unlikely.
The clock sequence MUST be originally (i.e., once in the lifetime of The clock sequence MUST be originally (i.e., once in the lifetime of
a system) initialized to a random number to minimize the correlation a system) initialized to a random number to minimize the correlation
across systems. This provides maximum protection against node across systems. This provides maximum protection against Node IDs
identifiers that may move or switch from system to system rapidly. that may move or switch from system to system rapidly. The initial
The initial value MUST NOT be correlated to the node identifier. value MUST NOT be correlated to the Node ID.
Notes about IEEE 802 derived nodes: Notes about nodes derived from IEEE 802:
* On systems with multiple IEEE 802 addresses, any available one MAY * On systems with multiple IEEE 802 addresses, any available one MAY
be used. be used.
* On systems with no IEEE address, a randomly or pseudo-randomly
generated value MUST be used; see Section 6.9 and Section 6.10. * On systems with no IEEE address, a randomly or pseudorandomly
* On systems utilizing a 64 bit MAC address the least significant, generated value MUST be used; see Sections 6.9 and 6.10.
right-most 48 bits MAY be used.
* On systems utilizing an IEEE 802.15.4 16 bit address SHOULD * On systems utilizing a 64-bit MAC address, the least significant,
instead utilize their 64 bit MAC address where least significant, rightmost 48 bits MAY be used.
right-most 48 bits MAY be used. An alternative is to generate 32
bits of random data and postfix at the end of the 16 bit MAC * Systems utilizing an IEEE 802.15.4 16-bit address SHOULD instead
address to create a 48 bit value. utilize their 64-bit MAC address where the least significant,
rightmost 48 bits MAY be used. An alternative is to generate 32
bits of random data and postfix at the end of the 16-bit MAC
address to create a 48-bit value.
5.2. UUID Version 2 5.2. UUID Version 2
UUID version 2 is known as DCE Security UUIDs [C309] and [C311]. As UUIDv2 is for DCE Security UUIDs (see [C309] and [C311]). As such,
such, the definition of these UUIDs is outside the scope of this the definition of these UUIDs is outside the scope of this
specification. specification.
5.3. UUID Version 3 5.3. UUID Version 3
UUID version 3 is meant for generating UUIDs from "names" that are UUIDv3 is meant for generating UUIDs from names that are drawn from,
drawn from, and unique within, some "namespace" as per Section 6.5. and unique within, some namespace as per Section 6.5.
UUIDv3 values are created by computing an MD5 [RFC1321] hash over a UUIDv3 values are created by computing an MD5 hash [RFC1321] over a
given namespace ID value (Section 6.6) concatenated with the desired given Namespace ID value (Section 6.6) concatenated with the desired
name value after both have been converted to a canonical sequence of name value after both have been converted to a canonical sequence of
octets, as defined by the standards or conventions of its namespace, octets, as defined by the standards or conventions of its namespace,
in network byte order. This MD5 value is then used to populate all in network byte order. This MD5 value is then used to populate all
128 bits of the UUID layout. The UUID version and variant then 128 bits of the UUID layout. The UUID version and variant then
replace the respective bits as defined by Section 4.2 and replace the respective bits as defined by Sections 4.2 and 4.1. An
Section 4.1. An example of this bit substitution can be found in example of this bit substitution can be found in Appendix A.2.
Appendix A.2.
Information around selecting a desired name's canonical format within Information around selecting a desired name's canonical format within
a given namespace can be found in Section 6.5, "A note on names". a given namespace can be found in Section 6.5 under the heading "A
note on names".
Where possible UUIDv5 SHOULD be used in lieu of UUIDv3. For more Where possible, UUIDv5 SHOULD be used in lieu of UUIDv3. For more
information on MD5 security considerations see [RFC6151]. information on MD5 security considerations, see [RFC6151].
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| md5_high | | md5_high |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| md5_high | ver | md5_mid | | md5_high | ver | md5_mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|var| md5_low | |var| md5_low |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| md5_low | | md5_low |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: UUIDv3 Field and Bit Layout Figure 7: UUIDv3 Field and Bit Layout
md5_high: md5_high:
The first 48 bits of the layout are filled with the most The first 48 bits of the layout are filled with the most
significant, left-most 48 bits from the computed MD5 value. significant, leftmost 48 bits from the computed MD5 value.
Occupies bits 0 through 47 (octets 0-5). Occupies bits 0 through 47 (octets 0-5).
ver: ver:
The 4 bit version field as defined by Section 4.2, set to 0b0011 The 4-bit version field as defined by Section 4.2, set to 0b0011
(3). Occupies bits 48 through 51 of octet 6. (3). Occupies bits 48 through 51 of octet 6.
md5_mid: md5_mid:
12 more bits of the layout consisting of the least significant, 12 more bits of the layout consisting of the least significant,
right-most 12 bits of 16 bits immediately following md5_high from rightmost 12 bits of 16 bits immediately following md5_high from
the computed MD5 value. Occupies bits 52 through 63 (octets 6-7). the computed MD5 value. Occupies bits 52 through 63 (octets 6-7).
var: var:
The 2 bit variant field as defined by Section 4.1, set to 0b10. The 2-bit variant field as defined by Section 4.1, set to 0b10.
Occupies bits 64 and 65 of octet 8. Occupies bits 64 and 65 of octet 8.
md5_low: md5_low:
The final 62 bits of the layout immediately following the var The final 62 bits of the layout immediately following the var
field to be filled with the least-significant, right-most bits of field to be filled with the least significant, rightmost bits of
the final 64 bits from the computed MD5 value. Occupies bits 66 the final 64 bits from the computed MD5 value. Occupies bits 66
through 127 (octets 8-15) through 127 (octets 8-15)
5.4. UUID Version 4 5.4. UUID Version 4
UUID version 4 is meant for generating UUIDs from truly-random or UUIDv4 is meant for generating UUIDs from truly random or
pseudo-random numbers. pseudorandom numbers.
An implementation may generate 128 bits of random data which is used An implementation may generate 128 bits of random data that is used
to fill out the UUID fields in Figure 8. The UUID version and to fill out the UUID fields in Figure 8. The UUID version and
variant then replace the respective bits as defined by Section 4.2 variant then replace the respective bits as defined by Sections 4.1
and Section 4.1. and 4.2.
Alternatively, an implementation MAY choose to randomly generate the Alternatively, an implementation MAY choose to randomly generate the
exact required number of bits for random_a, random_b, and random_c exact required number of bits for random_a, random_b, and random_c
(122 bits total), and then concatenate the version and variant in the (122 bits total) and then concatenate the version and variant in the
required position. required position.
For guidelines on random data generation see Section 6.9. For guidelines on random data generation, see Section 6.9.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| random_a | | random_a |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| random_a | ver | random_b | | random_a | ver | random_b |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|var| random_c | |var| random_c |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 21, line 32 skipping to change at line 766
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: UUIDv4 Field and Bit Layout Figure 8: UUIDv4 Field and Bit Layout
random_a: random_a:
The first 48 bits of the layout that can be filled with random The first 48 bits of the layout that can be filled with random
data as specified in Section 6.9. Occupies bits 0 through 47 data as specified in Section 6.9. Occupies bits 0 through 47
(octets 0-5). (octets 0-5).
ver: ver:
The 4 bit version field as defined by Section 4.2, set to 0b0100 The 4-bit version field as defined by Section 4.2, set to 0b0100
(4). Occupies bits 48 through 51 of octet 6. (4). Occupies bits 48 through 51 of octet 6.
random_b: random_b:
12 more bits of the layout that can be filled random data as per 12 more bits of the layout that can be filled random data as per
Section 6.9. Occupies bits 52 through 63 (octets 6-7). Section 6.9. Occupies bits 52 through 63 (octets 6-7).
var: var:
The 2 bit variant field as defined by Section 4.1, set to 0b10. The 2-bit variant field as defined by Section 4.1, set to 0b10.
Occupies bits 64 and 65 of octet 8. Occupies bits 64 and 65 of octet 8.
random_c: random_c:
The final 62 bits of the layout immediately following the var The final 62 bits of the layout immediately following the var
field to be filled with random data as per Section 6.9. Occupies field to be filled with random data as per Section 6.9. Occupies
bits 66 through 127 (octets 8-15). bits 66 through 127 (octets 8-15).
5.5. UUID Version 5 5.5. UUID Version 5
UUID version 5 is meant for generating UUIDs from "names" that are UUIDv5 is meant for generating UUIDs from "names" that are drawn
drawn from, and unique within, some "namespace" as per Section 6.5. from, and unique within, some "namespace" as per Section 6.5.
UUIDv5 values are created by computing an SHA-1 [FIPS180-4] hash over UUIDv5 values are created by computing an SHA-1 hash [FIPS180-4] over
a given namespace ID value (Section 6.6) concatenated with the a given Namespace ID value (Section 6.6) concatenated with the
desired name value after both have been converted to a canonical desired name value after both have been converted to a canonical
sequence of octets, as defined by the standards or conventions of its sequence of octets, as defined by the standards or conventions of its
namespace, in network byte order. The most significant, left-most namespace, in network byte order. The most significant, leftmost 128
128 bits of the SHA-1 value is then used to populate all 128 bits of bits of the SHA-1 value are then used to populate all 128 bits of the
the UUID layout and the remaining 32 least significant, right-most UUID layout, and the remaining 32 least significant, rightmost bits
bits of SHA-1 output are discarded. The UUID version and variant of SHA-1 output are discarded. The UUID version and variant then
then replace the respective bits as defined by Section 4.2 and replace the respective bits as defined by Sections 4.2 and 4.1. An
Section 4.1. An example of this bit substitution and discarding example of this bit substitution and discarding excess bits can be
excess bits can be found in Appendix A.4. found in Appendix A.4.
Information around selecting a desired name's canonical format within Information around selecting a desired name's canonical format within
a given namespace can be found in Section 6.5, "A note on names". a given namespace can be found in Section 6.5 under the heading "A
note on names".
There may be scenarios, usually depending on organizational security There may be scenarios, usually depending on organizational security
policies, where SHA-1 libraries may not be available or deemed unsafe policies, where SHA-1 libraries may not be available or may be deemed
for use. As such, it may be desirable to generate name-based UUIDs unsafe for use. As such, it may be desirable to generate name-based
derived from SHA-256 or newer SHA methods. These name-based UUIDs UUIDs derived from SHA-256 or newer SHA methods. These name-based
MUST NOT utilize UUIDv5 and MUST be within the UUIDv8 space defined UUIDs MUST NOT utilize UUIDv5 and MUST be within the UUIDv8 space
by Section 5.8. An illustrative example of UUIDv8 for SHA-256 name- defined by Section 5.8. An illustrative example of UUIDv8 for
based UUIDs is provided in the appendix Appendix B.2. SHA-256 name-based UUIDs is provided in Appendix B.2.
For more information on SHA-1 security considerations see [RFC6194]. For more information on SHA-1 security considerations, see [RFC6194].
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sha1_high | | sha1_high |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sha1_high | ver | sha1_mid | | sha1_high | ver | sha1_mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|var| sha1_low | |var| sha1_low |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sha1_low | | sha1_low |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: UUIDv5 Field and Bit Layout Figure 9: UUIDv5 Field and Bit Layout
sha1_high: sha1_high:
The first 48 bits of the layout are filled with the most The first 48 bits of the layout are filled with the most
significant, left-most 48 bits from the computed SHA-1 value. significant, leftmost 48 bits from the computed SHA-1 value.
Occupies bits 0 through 47 (octets 0-5). Occupies bits 0 through 47 (octets 0-5).
ver: ver:
The 4 bit version field as defined by Section 4.2, set to 0b0101 The 4-bit version field as defined by Section 4.2, set to 0b0101
(5). Occupies bits 48 through 51 of octet 6. (5). Occupies bits 48 through 51 of octet 6.
sha1_mid: sha1_mid:
12 more bits of the layout consisting of the least significant, 12 more bits of the layout consisting of the least significant,
right-most 12 bits of 16 bits immediately following sha1_high from rightmost 12 bits of 16 bits immediately following sha1_high from
the computed SHA-1 value. Occupies bits 52 through 63 (octets the computed SHA-1 value. Occupies bits 52 through 63 (octets
6-7). 6-7).
var: var:
The 2 bit variant field as defined by Section 4.1, set to 0b10. The 2-bit variant field as defined by Section 4.1, set to 0b10.
Occupies bits 64 and 65 of octet 8. Occupies bits 64 and 65 of octet 8.
sha1_low: sha1_low:
The final 62 bits of the layout immediately following the var The final 62 bits of the layout immediately following the var
field to be filled by skipping the 2 most significant, left-most field to be filled by skipping the two most significant, leftmost
bits of the remaining SHA-1 hash and then using the next 62 most bits of the remaining SHA-1 hash and then using the next 62 most
significant, left-most bits. Any leftover SHA-1 bits are significant, leftmost bits. Any leftover SHA-1 bits are discarded
discarded and unused. Occupies bits 66 through 127 (octets 8-15). and unused. Occupies bits 66 through 127 (octets 8-15).
5.6. UUID Version 6 5.6. UUID Version 6
UUID version 6 is a field-compatible version of UUIDv1 Section 5.1, UUIDv6 is a field-compatible version of UUIDv1 (Section 5.1),
reordered for improved DB locality. It is expected that UUIDv6 will reordered for improved DB locality. It is expected that UUIDv6 will
primarily be used in contexts where UUIDv1 is used. Systems that do primarily be implemented in contexts where UUIDv1 is used. Systems
not involve legacy UUIDv1 SHOULD use UUIDv7 Section 5.7 instead. that do not involve legacy UUIDv1 SHOULD use UUIDv7 (Section 5.7)
instead.
Instead of splitting the timestamp into the low, mid, and high Instead of splitting the timestamp into the low, mid, and high
sections from UUIDv1, UUIDv6 changes this sequence so timestamp bytes sections from UUIDv1, UUIDv6 changes this sequence so timestamp bytes
are stored from most to least significant. That is, given a 60 bit are stored from most to least significant. That is, given a 60-bit
timestamp value as specified for UUIDv1 in Section 5.1, for UUIDv6, timestamp value as specified for UUIDv1 in Section 5.1, for UUIDv6
the first 48 most significant bits are stored first, followed by the the first 48 most significant bits are stored first, followed by the
4 bit version (same position), followed by the remaining 12 bits of 4-bit version (same position), followed by the remaining 12 bits of
the original 60 bit timestamp. the original 60-bit timestamp.
The clock sequence and node bits remain unchanged from their position The clock sequence and node bits remain unchanged from their position
in Section 5.1. in Section 5.1.
The clock sequence and node bits SHOULD be reset to a pseudo-random The clock sequence and node bits SHOULD be reset to a pseudorandom
value for each new UUIDv6 generated; however, implementations MAY value for each new UUIDv6 generated; however, implementations MAY
choose to retain the old clock sequence and MAC address behavior from choose to retain the old clock sequence and MAC address behavior from
Section 5.1. For more information on MAC address usage within UUIDs Section 5.1. For more information on MAC address usage within UUIDs,
see the Section 8. see the Section 8.
The format for the 16-byte, 128 bit UUIDv6 is shown in Figure 10. The format for the 16-byte, 128-bit UUIDv6 is shown in Figure 10.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| time_high | | time_high |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| time_mid | ver | time_low | | time_mid | ver | time_low |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|var| clock_seq | node | |var| clock_seq | node |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| node | | node |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: UUIDv6 Field and Bit Layout Figure 10: UUIDv6 Field and Bit Layout
time_high: time_high:
The most significant 32 bits of the 60 bit starting timestamp. The most significant 32 bits of the 60-bit starting timestamp.
Occupies bits 0 through 31 (octets 0-3). Occupies bits 0 through 31 (octets 0-3).
time_mid: time_mid:
The middle 16 bits of the 60 bit starting timestamp. Occupies The middle 16 bits of the 60-bit starting timestamp. Occupies
bits 32 through 47 (octets 4-5). bits 32 through 47 (octets 4-5).
ver: ver:
The 4 bit version field as defined by Section 4.2, set to 0b0110 The 4-bit version field as defined by Section 4.2, set to 0b0110
(6). Occupies bits 48 through 51 of octet 6. (6). Occupies bits 48 through 51 of octet 6.
time_low: time_low:
12 bits that will contain the least significant 12 bits from the 12 bits that will contain the least significant 12 bits from the
60 bit starting timestamp. Occupies bits 52 through 63 (octets 60-bit starting timestamp. Occupies bits 52 through 63 (octets
6-7). 6-7).
var: var:
The 2 bit variant field as defined by Section 4.1, set to 0b10. The 2-bit variant field as defined by Section 4.1, set to 0b10.
Occupies bits 64 and 65 of octet 8. Occupies bits 64 and 65 of octet 8.
clock_seq: clock_seq:
The 14 bits containing the clock sequence. Occupies bits 66 The 14 bits containing the clock sequence. Occupies bits 66
through 79 (octets 8-9). through 79 (octets 8-9).
node: node:
48 bit spatially unique identifier. Occupies bits 80 through 127 48-bit spatially unique identifier. Occupies bits 80 through 127
(octets 10-15). (octets 10-15).
With UUIDv6, the steps for splitting the timestamp into time_high and With UUIDv6, the steps for splitting the timestamp into time_high and
time_mid are OPTIONAL since the 48 bits of time_high and time_mid time_mid are OPTIONAL since the 48 bits of time_high and time_mid
will remain in the same order. An extra step of splitting the first will remain in the same order. An extra step of splitting the first
48 bits of the timestamp into the most significant 32 bits and least 48 bits of the timestamp into the most significant 32 bits and least
significant 16 bits proves useful when reusing an existing UUIDv1 significant 16 bits proves useful when reusing an existing UUIDv1
implementation. implementation.
5.7. UUID Version 7 5.7. UUID Version 7
UUID version 7 features a time-ordered value field derived from the UUIDv7 features a time-ordered value field derived from the widely
widely implemented and well known Unix Epoch timestamp source, the implemented and well-known Unix Epoch timestamp source, the number of
number of milliseconds since midnight 1 Jan 1970 UTC, leap seconds milliseconds since midnight 1 Jan 1970 UTC, leap seconds excluded.
excluded. UUIDv7 generally has improved entropy characteristics over Generally, UUIDv7 has improved entropy characteristics over UUIDv1
UUIDv1 Section 5.1 or UUIDv6 Section 5.6. (Section 5.1) or UUIDv6 (Section 5.6).
UUIDv7 values are created by allocating a Unix timestamp in UUIDv7 values are created by allocating a Unix timestamp in
milliseconds in the most significant 48 bits and filling the milliseconds in the most significant 48 bits and filling the
remaining 74 bits, excluding the required version and variant bits, remaining 74 bits, excluding the required version and variant bits,
with random bits for each new UUIDv7 generated to provide uniqueness with random bits for each new UUIDv7 generated to provide uniqueness
as per Section 6.9. Alternatively, implementations MAY fill the 74 as per Section 6.9. Alternatively, implementations MAY fill the 74
bits, jointly, with a combination of the following subfields, in this bits, jointly, with a combination of the following subfields, in this
order from the most significant bits to the least, to guarantee order from the most significant bits to the least, to guarantee
additional monotonicity within a millisecond: additional monotonicity within a millisecond:
skipping to change at page 26, line 4 skipping to change at line 970
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| unix_ts_ms | | unix_ts_ms |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| unix_ts_ms | ver | rand_a | | unix_ts_ms | ver | rand_a |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|var| rand_b | |var| rand_b |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| rand_b | | rand_b |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: UUIDv7 Field and Bit Layout Figure 11: UUIDv7 Field and Bit Layout
unix_ts_ms: unix_ts_ms:
48 bit big-endian unsigned number of Unix epoch timestamp in 48-bit big-endian unsigned number of the Unix Epoch timestamp in
milliseconds as per Section 6.1. Occupies bits 0 through 47 milliseconds as per Section 6.1. Occupies bits 0 through 47
(octets 0-5). (octets 0-5).
ver: ver:
The 4 bit version field as defined by Section 4.2, set to 0b0111 The 4-bit version field as defined by Section 4.2, set to 0b0111
(7). Occupies bits 48 through 51 of octet 6. (7). Occupies bits 48 through 51 of octet 6.
rand_a: rand_a:
12 bits pseudo-random data to provide uniqueness as per 12 bits of pseudorandom data to provide uniqueness as per
Section 6.9 and/or optional constructs to guarantee additional Section 6.9 and/or optional constructs to guarantee additional
monotonicity as per Section 6.2. Occupies bits 52 through 63 monotonicity as per Section 6.2. Occupies bits 52 through 63
(octets 6-7). (octets 6-7).
var: var:
The 2 bit variant field as defined by Section 4.1, set to 0b10. The 2-bit variant field as defined by Section 4.1, set to 0b10.
Occupies bits 64 and 65 of octet 8. Occupies bits 64 and 65 of octet 8.
rand_b: rand_b:
The final 62 bits of pseudo-random data to provide uniqueness as The final 62 bits of pseudorandom data to provide uniqueness as
per Section 6.9 and/or an optional counter to guarantee additional per Section 6.9 and/or an optional counter to guarantee additional
monotonicity as per Section 6.2. Occupies bits 66 through 127 monotonicity as per Section 6.2. Occupies bits 66 through 127
(octets 8-15). (octets 8-15).
5.8. UUID Version 8 5.8. UUID Version 8
UUID version 8 provides an RFC-compatible format for experimental or UUIDv8 provides a format for experimental or vendor-specific use
vendor-specific use cases. The only requirement is that the variant cases. The only requirement is that the variant and version bits
and version bits MUST be set as defined in Section 4.1 and MUST be set as defined in Sections 4.1 and 4.2. UUIDv8's uniqueness
Section 4.2. UUIDv8's uniqueness will be implementation-specific and will be implementation specific and MUST NOT be assumed.
MUST NOT be assumed.
The only explicitly defined bits are those of the version and variant The only explicitly defined bits are those of the version and variant
fields, leaving 122 bits for implementation specific UUIDs. To be fields, leaving 122 bits for implementation-specific UUIDs. To be
clear: UUIDv8 is not a replacement for UUIDv4 Section 5.4 where all clear, UUIDv8 is not a replacement for UUIDv4 (Section 5.4) where all
122 extra bits are filled with random data. 122 extra bits are filled with random data.
Some example situations in which UUIDv8 usage could occur: Some example situations in which UUIDv8 usage could occur:
* An implementation would like to embed extra information within the * An implementation would like to embed extra information within the
UUID other than what is defined in this document. UUID other than what is defined in this document.
* An implementation has other application/language restrictions * An implementation has other application and/or language
which inhibit the use of one of the current UUIDs. restrictions that inhibit the use of one of the current UUIDs.
The appendix, Appendix B, provides two illustrative examples of Appendix B provides two illustrative examples of custom UUIDv8
custom UUIDv8 algorithms to address two example scenarios. algorithms to address two example scenarios.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| custom_a | | custom_a |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| custom_a | ver | custom_b | | custom_a | ver | custom_b |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|var| custom_c | |var| custom_c |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| custom_c | | custom_c |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: UUIDv8 Field and Bit Layout Figure 12: UUIDv8 Field and Bit Layout
custom_a: custom_a:
The first 48 bits of the layout that can be filled as an The first 48 bits of the layout that can be filled as an
implementation sees fit. Occupies bits 0 through 47 (octets 0-5). implementation sees fit. Occupies bits 0 through 47 (octets 0-5).
ver: ver:
The 4 bit version field as defined by Section 4.2, set to 0b1000 The 4-bit version field as defined by Section 4.2, set to 0b1000
(8). Occupies bits 48 through 51 of octet 6. (8). Occupies bits 48 through 51 of octet 6.
custom_b: custom_b:
12 more bits of the layout that can be filled as an implementation 12 more bits of the layout that can be filled as an implementation
sees fit. Occupies bits 52 through 63 (octets 6-7). sees fit. Occupies bits 52 through 63 (octets 6-7).
var: var:
The 2 bit variant field as defined by Section 4.1, set to 0b10. The 2-bit variant field as defined by Section 4.1, set to 0b10.
Occupies bits 64 and 65 of octet 8. Occupies bits 64 and 65 of octet 8.
custom_c: custom_c:
The final 62 bits of the layout immediately following the var The final 62 bits of the layout immediately following the var
field to be filled as an implementation sees fit. Occupies bits field to be filled as an implementation sees fit. Occupies bits
66 through 127 (octets 8-15). 66 through 127 (octets 8-15).
5.9. Nil UUID 5.9. Nil UUID
The nil UUID is special form of UUID that is specified to have all The Nil UUID is special form of UUID that is specified to have all
128 bits set to zero. 128 bits set to zero.
00000000-0000-0000-0000-000000000000 00000000-0000-0000-0000-000000000000
Figure 13: Nil UUID Format Figure 13: Nil UUID Format
A Nil UUID value can be useful to communicate the absence of any A Nil UUID value can be useful to communicate the absence of any
other UUID value in situations that otherwise require or use a 128 other UUID value in situations that otherwise require or use a
bit UUID. A Nil UUID can express the concept "no such value here". 128-bit UUID. A Nil UUID can express the concept "no such value
Thus it is reserved for such use as needed for implementation- here". Thus, it is reserved for such use as needed for
specific situations. implementation-specific situations.
Note that the Nil UUID value falls within the range of the Apollo NCS Note that the Nil UUID value falls within the range of the Apollo NCS
variant as per the first row of Table 1 rather than the variant variant as per the first row of Table 1 rather than the variant
defined by this document. defined by this document.
5.10. Max UUID 5.10. Max UUID
The Max UUID is a special form of UUID that is specified to have all The Max UUID is a special form of UUID that is specified to have all
128 bits set to 1. This UUID can be thought of as the inverse of Nil 128 bits set to 1. This UUID can be thought of as the inverse of the
UUID defined in Section 5.9. Nil UUID defined in Section 5.9.
FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF
Figure 14: Max UUID Format Figure 14: Max UUID Format
A Max UUID value can be used as a sentinel value in situations where A Max UUID value can be used as a sentinel value in situations where
a 128 bit UUID is required but a concept such as "end of UUID list" a 128-bit UUID is required, but a concept such as "end of UUID list"
needs to be expressed, and is reserved for such use as needed for needs to be expressed and is reserved for such use as needed for
implementation-specific situations. implementation-specific situations.
Note that the Max UUID value falls within the range of the "yet to be Note that the Max UUID value falls within the range of the "yet-to-be
defined" future UUID variant as per the last row of Table 1 rather defined" future UUID variant as per the last row of Table 1 rather
than the variant defined by this document. than the variant defined by this document.
6. UUID Best Practices 6. UUID Best Practices
The minimum requirements for generating UUIDs are described in this The minimum requirements for generating UUIDs of each version are
document for each version. Everything else is an implementation described in this document. Everything else is an implementation
detail and it is up to the implementer to decide what is appropriate detail, and it is up to the implementer to decide what is appropriate
for a given implementation. Various relevant factors are covered for a given implementation. Various relevant factors are covered
below to help guide an implementer through the different trade-offs below to help guide an implementer through the different trade-offs
among differing UUID implementations. among differing UUID implementations.
6.1. Timestamp Considerations 6.1. Timestamp Considerations
UUID timestamp source, precision, and length was the topic of great UUID timestamp source, precision, and length were topics of great
debate while creating UUIDv7 for this specification. Choosing the debate while creating UUIDv7 for this specification. Choosing the
right timestamp for your application is a very important topic. This right timestamp for your application is very important. This section
section will detail some of the most common points on this topic. will detail some of the most common points on this issue.
Reliability: Reliability:
Implementations acquire the current timestamp from a reliable Implementations acquire the current timestamp from a reliable
source to provide values that are time-ordered and continually source to provide values that are time ordered and continually
increasing. Care must be taken to ensure that timestamp changes increasing. Care must be taken to ensure that timestamp changes
from the environment or operating system are handled in a way that from the environment or operating system are handled in a way that
is consistent with implementation requirements. For example, if is consistent with implementation requirements. For example, if
it is possible for the system clock to move backward due to either it is possible for the system clock to move backward due to either
manual adjustment or corrections from a time synchronization manual adjustment or corrections from a time synchronization
protocol, implementations need to determine how to handle such protocol, implementations need to determine how to handle such
cases. (See Altering, Fuzzing, or Smearing below.) cases. (See "Altering, Fuzzing, or Smearing" below.)
Source: Source:
UUID version 1 and 6 both utilize a Gregorian epoch timestamp UUIDv1 and UUIDv6 both utilize a Gregorian Epoch timestamp, while
while UUIDv7 utilizes a Unix Epoch timestamp. If other timestamp UUIDv7 utilizes a Unix Epoch timestamp. If other timestamp
sources or a custom timestamp epoch are required, UUIDv8 MUST be sources or a custom timestamp Epoch are required, UUIDv8 MUST be
used. used.
Sub-second Precision and Accuracy: Sub-second Precision and Accuracy:
Many levels of precision exist for timestamps: milliseconds, Many levels of precision exist for timestamps: milliseconds,
microseconds, nanoseconds, and beyond. Additionally fractional microseconds, nanoseconds, and beyond. Additionally, fractional
representations of sub-second precision may be desired to mix representations of sub-second precision may be desired to mix
various levels of precision in a time-ordered manner. various levels of precision in a time-ordered manner.
Furthermore, system clocks themselves have an underlying Furthermore, system clocks themselves have an underlying
granularity and it is frequently less than the precision offered granularity, which is frequently less than the precision offered
by the operating system. With UUID version 1 and 6, by the operating system. With UUIDv1 and UUIDv6, 100 nanoseconds
100-nanoseconds of precision are present while UUIDv7 features of precision are present, while UUIDv7 features a millisecond
millisecond level of precision by default within the Unix epoch level of precision by default within the Unix Epoch that does not
that does not exceed the granularity capable in most modern exceed the granularity capable in most modern systems. For other
systems. For other levels of precision UUIDv8 is available. levels of precision, UUIDv8 is available. Similar to Section 6.2,
Similar to Section 6.2, with UUIDv1 or UUIDv6, a high resolution with UUIDv1 or UUIDv6, a high-resolution timestamp can be
timestamp can be simulated by keeping a count of the number of simulated by keeping a count of the number of UUIDs that have been
UUIDs that have been generated with the same value of the system generated with the same value of the system time and using that
time, and using it to construct the low order bits of the count to construct the low order bits of the timestamp. The count
timestamp. The count of the high resolution timestamp will range of the high-resolution timestamp will range between zero and the
between zero and the number of 100-nanosecond intervals per system number of 100-nanosecond intervals per system-time interval.
time interval.
Length: Length:
The length of a given timestamp directly impacts how many The length of a given timestamp directly impacts how many
timestamp ticks can be contained in a UUID before the maximum timestamp ticks can be contained in a UUID before the maximum
value for the timestamp field is reached. Take care to ensure value for the timestamp field is reached. Take care to ensure
that the proper length is selected for a given timestamp. UUID that the proper length is selected for a given timestamp. UUIDv1
version 1 and 6 utilize a 60 bit timestamp valid until 5623 AD and and UUIDv6 utilize a 60-bit timestamp valid until 5623 AD; UUIDv7
UUIDv7 features a 48 bit timestamp valid until the year 10889 AD. features a 48-bit timestamp valid until the year 10889 AD.
Altering, Fuzzing, or Smearing: Altering, Fuzzing, or Smearing:
Implementations MAY alter the actual timestamp. Some examples Implementations MAY alter the actual timestamp. Some examples
include security considerations around providing a real clock include security considerations around providing a real-clock
value within a UUID, to correct inaccurate clocks, to handle leap value within a UUID to 1) correct inaccurate clocks, 2) handle
seconds, or instead of dividing a number of microseconds by 1000 leap seconds, or 3) obtain a millisecond value by dividing by 1024
to obtain a millisecond value; dividing by 1024 (or some other (or some other value) for performance reasons (instead of dividing
value) for performance reasons. This specification makes no a number of microseconds by 1000). This specification makes no
requirement or guarantee about how close the clock value needs to requirement or guarantee about how close the clock value needs to
be to the actual time. If UUIDs do not need to be frequently be to the actual time. If UUIDs do not need to be frequently
generated, the UUIDv1 or UUIDv6 timestamp can simply be the system generated, the UUIDv1 or UUIDv6 timestamp can simply be the system
time multiplied by the number of 100-nanosecond intervals per time multiplied by the number of 100-nanosecond intervals per
system time interval. system-time interval.
Padding: Padding:
When timestamp padding is required, implementations MUST pad the When timestamp padding is required, implementations MUST pad the
most significant bits (left-most) bits with data. An example for most significant bits (leftmost) with data. An example for this
this padding data is to fill the most significant, left-most bits padding data is to fill the most significant, leftmost bits of a
of a Unix timestamp with zeroes to complete the 48 bit timestamp Unix timestamp with zeroes to complete the 48-bit timestamp in
in UUIDv7. An alternative approach for padding data is to fill UUIDv7. An alternative approach for padding data is to fill the
the most significant, left-most bits with the number of 32 bit most significant, leftmost bits with the number of 32-bit Unix
Unix timestamp roll-overs after 2038-01-19. timestamp rollovers after 2038-01-19.
Truncating: Truncating:
When timestamps need to be truncated, the lower, least significant When timestamps need to be truncated, the lower, least significant
bits MUST be used. An example would be truncating a 64 bit Unix bits MUST be used. An example would be truncating a 64-bit Unix
timestamp to the least significant, right-most 48 bits for UUIDv7. timestamp to the least significant, rightmost 48 bits for UUIDv7.
Error Handling: Error Handling:
If a system overruns the generator by requesting too many UUIDs If a system overruns the generator by requesting too many UUIDs
within a single system time interval, the UUID service can return within a single system-time interval, the UUID service can return
an error, or stall the UUID generator until the system clock an error or stall the UUID generator until the system clock
catches up, and MUST NOT return knowingly duplicate values due to catches up and MUST NOT knowingly return duplicate values due to a
a counter rollover. Note that if the processors overrun the UUID counter rollover. Note that if the processors overrun the UUID
generation frequently, additional node identifiers can be generation frequently, additional Node IDs can be allocated to the
allocated to the system, which will permit higher speed allocation system, which will permit higher speed allocation by making
by making multiple UUIDs potentially available for each time stamp multiple UUIDs potentially available for each timestamp value.
value. Similar techniques are discussed in Section 6.4. Similar techniques are discussed in Section 6.4.
6.2. Monotonicity and Counters 6.2. Monotonicity and Counters
Monotonicity (each subsequent value being greater than the last) is Monotonicity (each subsequent value being greater than the last) is
the backbone of time-based sortable UUIDs. Normally, time-based the backbone of time-based sortable UUIDs. Normally, time-based
UUIDs from this document will be monotonic due to an embedded UUIDs from this document will be monotonic due to an embedded
timestamp; however, implementations can guarantee additional timestamp; however, implementations can guarantee additional
monotonicity via the concepts covered in this section. monotonicity via the concepts covered in this section.
Take care to ensure UUIDs generated in batches are also monotonic. Take care to ensure UUIDs generated in batches are also monotonic.
That is, if one thousand UUIDs are generated for the same timestamp, That is, if one thousand UUIDs are generated for the same timestamp,
there should be sufficient logic for organizing the creation order of there should be sufficient logic for organizing the creation order of
those one thousand UUIDs. Batch UUID creation implementations MAY those one thousand UUIDs. Batch UUID creation implementations MAY
utilize a monotonic counter that increments for each UUID created utilize a monotonic counter that increments for each UUID created
during a given timestamp. during a given timestamp.
For single-node UUID implementations that do not need to create For single-node UUID implementations that do not need to create
batches of UUIDs, the embedded timestamp within UUID version 6 and 7 batches of UUIDs, the embedded timestamp within UUIDv6 and UUIDv7 can
can provide sufficient monotonicity guarantees by simply ensuring provide sufficient monotonicity guarantees by simply ensuring that
that timestamp increments before creating a new UUID. Distributed timestamp increments before creating a new UUID. Distributed nodes
nodes are discussed in Section 6.4. are discussed in Section 6.4.
Implementations SHOULD employ the following methods for single-node Implementations SHOULD employ the following methods for single-node
UUID implementations that require batch UUID creation, or are UUID implementations that require batch UUID creation or are
otherwise concerned about monotonicity with high frequency UUID otherwise concerned about monotonicity with high-frequency UUID
generation. generation.
Fixed-Length Dedicated Counter Bits (Method 1): Fixed Bit-Length Dedicated Counter (Method 1):
Some implementations allocate a specific number of bits in the Some implementations allocate a specific number of bits in the
UUID layout to the sole purpose of tallying the total number of UUID layout to the sole purpose of tallying the total number of
UUIDs created during a given UUID timestamp tick. A fixed bit- UUIDs created during a given UUID timestamp tick. If present, a
length counter, if present, MUST be positioned immediately after fixed bit-length counter MUST be positioned immediately after the
the embedded timestamp. This promotes sortability and allows embedded timestamp. This promotes sortability and allows random
random data generation for each counter increment. With this data generation for each counter increment. With this method, the
method, the rand_a section (or a subset of its left-most bits) of rand_a section (or a subset of its leftmost bits) of UUIDv7 is
UUIDv7 is used as fixed-length dedicated counter bits that are used as a fixed bit-length dedicated counter that is incremented
incremented for every UUID generation. The trailing random bits for every UUID generation. The trailing random bits generated for
generated for each new UUID in rand_b can help produce unguessable each new UUID in rand_b can help produce unguessable UUIDs. In
UUIDs. In the event more counter bits are required, the most the event that more counter bits are required, the most
significant (left-most) bits of rand_b MAY be used as additional significant (leftmost) bits of rand_b MAY be used as additional
counter bits. counter bits.
Monotonic Random (Method 2): Monotonic Random (Method 2):
With this method, the random data is extended to also function as With this method, the random data is extended to also function as
a counter. This monotonic value can be thought of as a "randomly a counter. This monotonic value can be thought of as a "randomly
seeded counter" which MUST be incremented in the least significant seeded counter" that MUST be incremented in the least significant
position for each UUID created on a given timestamp tick. position for each UUID created on a given timestamp tick.
UUIDv7's rand_b section SHOULD be utilized with this method to UUIDv7's rand_b section SHOULD be utilized with this method to
handle batch UUID generation during a single timestamp tick. The handle batch UUID generation during a single timestamp tick. The
increment value for every UUID generation is a random integer of increment value for every UUID generation is a random integer of
any desired length larger than zero. It ensures the UUIDs retain any desired length larger than zero. It ensures that the UUIDs
the required level of unguessability provided by the underlying retain the required level of unguessability provided by the
entropy. The increment value MAY be 1 when the number of UUIDs underlying entropy. The increment value MAY be 1 when the number
generated in a particular period of time is important and of UUIDs generated in a particular period of time is important and
guessability is not an issue. However, incrementing the counter guessability is not an issue. However, incrementing the counter
by 1 SHOULD NOT be used by implementations that favor by 1 SHOULD NOT be used by implementations that favor
unguessability, as the resulting values are easily guessable. unguessability, as the resulting values are easily guessable.
Replace Left-Most Random Bits with Increased Clock Precision Replace Leftmost Random Bits with Increased Clock Precision
(Method 3): (Method 3):
For UUIDv7, which has millisecond timestamp precision, it is For UUIDv7, which has millisecond timestamp precision, it is
possible to use additional clock precision available on the system possible to use additional clock precision available on the system
to substitute for up to 12 random bits immediately following the to substitute for up to 12 random bits immediately following the
timestamp. This can provide values that are time-ordered with timestamp. This can provide values that are time ordered with
sub-millisecond precision, using however many bits are appropriate sub-millisecond precision, using however many bits are appropriate
in the implementation environment. With this method, the in the implementation environment. With this method, the
additional time precision bits MUST follow the timestamp as the additional time precision bits MUST follow the timestamp as the
next available bit, in the rand_a field for UUIDv7. next available bit in the rand_a field for UUIDv7.
To calculate this value, start with the portion of the timestamp To calculate this value, start with the portion of the timestamp
expressed as a fraction of clock's tick value (fraction of a expressed as a fraction of the clock's tick value (fraction of a
millisecond for UUIDv7). Compute the count of possible values millisecond for UUIDv7). Compute the count of possible values
that can be represented in the available bit space, 4096 for the that can be represented in the available bit space, 4096 for the
UUIDv7 rand_a field. Using floating point or scaled integer UUIDv7 rand_a field. Using floating point or scaled integer
arithmetic, multiply this fraction of a millisecond value by 4096 arithmetic, multiply this fraction of a millisecond value by 4096
and round down (toward zero) to an integer result to arrive at a and round down (toward zero) to an integer result to arrive at a
number between 0 and the maximum allowed for the indicated bits number between 0 and the maximum allowed for the indicated bits,
which sorts monotonically based on time. Each increasing which sorts monotonically based on time. Each increasing
fractional value will result in an increasing bit field value, to fractional value will result in an increasing bit field value to
the precision available with these bits. the precision available with these bits.
For example, let's assume a system timestamp of 1 Jan 2023 For example, let's assume a system timestamp of 1 Jan 2023
12:34:56.1234567. Taking the precision greater than 1ms gives us 12:34:56.1234567. Taking the precision greater than 1 ms gives us
a value of 0.4567, as a fraction of a millisecond. If we wish to a value of 0.4567, as a fraction of a millisecond. If we wish to
encode this as 12 bits, we can take the count of possible values encode this as 12 bits, we can take the count of possible values
that fit in those bits (4096, or 2 to the 12th power) and multiply that fit in those bits (4096 or 2^12), multiply it by our
it by our millisecond fraction value of 0.4567 and truncate the millisecond fraction value of 0.4567, and truncate the result to
result to an integer, which gives an integer value of 1870. an integer, which gives an integer value of 1870. Expressed as
Expressed as hexadecimal it is 0x74E, or the binary bits hexadecimal, it is 0x74E or the binary bits 0b011101001110. One
0b011101001110. One can then use those 12 bits as the most can then use those 12 bits as the most significant (leftmost)
significant (left-most) portion of the random section of the UUID portion of the random section of the UUID (e.g., the rand_a field
(e.g., the rand_a field in UUIDv7). This works for any desired in UUIDv7). This works for any desired bit length that fits into
bit length that fits into a UUID, and applications can decide the a UUID, and applications can decide the appropriate length based
appropriate length based on available clock precision, but for on available clock precision; for UUIDv7, it is limited to 12 bits
UUIDv7, it is limited to 12 bits at maximum to reserve sufficient at maximum to reserve sufficient space for random bits.
space for random bits.
The main benefit to encoding additional timestamp precision is The main benefit to encoding additional timestamp precision is
that it utilizes additional time precision already available in that it utilizes additional time precision already available in
the system clock to provide values that are more likely to be the system clock to provide values that are more likely to be
unique, and thus may simplify certain implementations. This unique; thus, it may simplify certain implementations. This
technique can also be used in conjunction with one of the other technique can also be used in conjunction with one of the other
methods, where this additional time precision would immediately methods, where this additional time precision would immediately
follow the timestamp, and then if any bits are to be used as clock follow the timestamp. Then, if any bits are to be used as a clock
sequence they would follow next. sequence, they would follow next.
The following sub-topics cover topics related solely with creating
reliable fixed-length dedicated counters:
Fixed-Length Dedicated Counter Seeding: The following sub-topics cover issues related solely to creating
reliable fixed bit-length dedicated counters:
Implementations utilizing the fixed-length counter method randomly Fixed Bit-Length Dedicated Counter Seeding:
initialize the counter with each new timestamp tick. However, Implementations utilizing the fixed bit-length counter method
when the timestamp has not increased, the counter is instead randomly initialize the counter with each new timestamp tick.
incremented by the desired increment logic. When utilizing a However, when the timestamp has not increased, the counter is
randomly seeded counter alongside Method 1, the random value MAY instead incremented by the desired increment logic. When
be regenerated with each counter increment without impacting utilizing a randomly seeded counter alongside Method 1, the random
sortability. The downside is that Method 1 is prone to overflows value MAY be regenerated with each counter increment without
if a counter of adequate length is not selected or the random data impacting sortability. The downside is that Method 1 is prone to
generated leaves little room for the required number of overflows if a counter of adequate length is not selected or the
increments. Implementations utilizing fixed-length counter method random data generated leaves little room for the required number
MAY also choose to randomly initialize a portion of the counter of increments. Implementations utilizing fixed bit-length counter
rather than the entire counter. For example, a 24 bit counter method MAY also choose to randomly initialize a portion of the
could have the 23 bits in least-significant, right-most, position counter rather than the entire counter. For example, a 24-bit
randomly initialized. The remaining most significant, left-most counter could have the 23 bits in least significant, rightmost
counter bit is initialized as zero for the sole purpose of position randomly initialized. The remaining most significant,
guarding against counter rollovers. leftmost counter bit is initialized as zero for the sole purpose
of guarding against counter rollovers.
Fixed-Length Dedicated Counter Length: Fixed Bit-Length Dedicated Counter Length:
Select a counter bit-length that can properly handle the level of Select a counter bit-length that can properly handle the level of
timestamp precision in use. For example, millisecond precision timestamp precision in use. For example, millisecond precision
generally requires a larger counter than a timestamp with generally requires a larger counter than a timestamp with
nanosecond precision. General guidance is that the counter SHOULD nanosecond precision. General guidance is that the counter SHOULD
be at least 12 bits but no longer than 42 bits. Care must be be at least 12 bits but no longer than 42 bits. Care must be
taken to ensure that the counter length selected leaves room for taken to ensure that the counter length selected leaves room for
sufficient entropy in the random portion of the UUID after the sufficient entropy in the random portion of the UUID after the
counter. This entropy helps improve the unguessability counter. This entropy helps improve the unguessability
characteristics of UUIDs created within the batch. characteristics of UUIDs created within the batch.
The following sub-topics cover rollover handling with either type of The following sub-topics cover rollover handling with either type of
counter method: counter method:
Counter Rollover Guards: Counter Rollover Guards:
The technique from Fixed-Length Dedicated Counter Seeding that The technique from "Fixed Bit-Length Dedicated Counter Seeding"
describes allocating a segment of the fixed-length counter as a above that describes allocating a segment of the fixed bit-length
rollover guard is also helpful to mitigate counter rollover counter as a rollover guard is also helpful to mitigate counter
issues. This same technique can be used with monotonic random rollover issues. This same technique can be used with monotonic
counter methods by ensuring that the total length of a possible random counter methods by ensuring that the total length of a
increment in the least significant, right most position is less possible increment in the least significant, rightmost position is
than the total length of the random value being incremented. As less than the total length of the random value being incremented.
such, the most significant, left-most, bits can be incremented as As such, the most significant, leftmost bits can be incremented as
rollover guarding. rollover guarding.
Counter Rollover Handling: Counter Rollover Handling:
Counter rollovers MUST be handled by the application to avoid Counter rollovers MUST be handled by the application to avoid
sorting issues. The general guidance is that applications that sorting issues. The general guidance is that applications that
care about absolute monotonicity and sortability should freeze the care about absolute monotonicity and sortability should freeze the
counter and wait for the timestamp to advance which ensures counter and wait for the timestamp to advance, which ensures
monotonicity is not broken. Alternatively, implementations MAY monotonicity is not broken. Alternatively, implementations MAY
increment the timestamp ahead of the actual time and reinitialize increment the timestamp ahead of the actual time and reinitialize
the counter. the counter.
Implementations MAY use the following logic to ensure UUIDs featuring Implementations MAY use the following logic to ensure UUIDs featuring
embedded counters are monotonic in nature: embedded counters are monotonic in nature:
1. Compare the current timestamp against the previously stored 1. Compare the current timestamp against the previously stored
timestamp. timestamp.
skipping to change at page 34, line 30 skipping to change at line 1368
increment the counter according to the desired method. increment the counter according to the desired method.
3. If the current timestamp is greater than the previous timestamp, 3. If the current timestamp is greater than the previous timestamp,
re-initialize the desired counter method to the new timestamp and re-initialize the desired counter method to the new timestamp and
generate new random bytes (if the bytes were frozen or being used generate new random bytes (if the bytes were frozen or being used
as the seed for a monotonic counter). as the seed for a monotonic counter).
Monotonic Error Checking: Monotonic Error Checking:
Implementations SHOULD check if the currently generated UUID is Implementations SHOULD check if the currently generated UUID is
greater than the previously generated UUID. If this is not the greater than the previously generated UUID. If this is not the
case then any number of things could have occurred, such as clock case, then any number of things could have occurred, such as clock
rollbacks, leap second handling, and counter rollovers. rollbacks, leap second handling, and counter rollovers.
Applications SHOULD embed sufficient logic to catch these Applications SHOULD embed sufficient logic to catch these
scenarios and correct the problem to ensure that the next UUID scenarios and correct the problem to ensure that the next UUID
generated is greater than the previous, or at least report an generated is greater than the previous, or they should at least
appropriate error. To handle this scenario, the general guidance report an appropriate error. To handle this scenario, the general
is that application MAY reuse the previous timestamp and increment guidance is that the application MAY reuse the previous timestamp
the previous counter method. and increment the previous counter method.
6.3. UUID Generator States 6.3. UUID Generator States
The (optional) UUID generator state only needs to be read from stable The (optional) UUID generator state only needs to be read from stable
storage once at boot time, if it is read into a system-wide shared storage once at boot time, if it is read into a system-wide shared
volatile store (and updated whenever the stable store is updated). volatile store (and updated whenever the stable store is updated).
This stable storage MAY be used to record various portions of the This stable storage MAY be used to record various portions of the
UUID generation which prove useful for batch UUID generation purposes UUID generation, which prove useful for batch UUID generation
and monotonic error checking with UUIDv6 and UUIDv7. These stored purposes and monotonic error checking with UUIDv6 and UUIDv7. These
values include but are not limited to last known timestamp, clock stored values include but are not limited to last known timestamp,
sequence, counters, and random data. clock sequence, counters, and random data.
If an implementation does not have any stable store available, then If an implementation does not have any stable store available, then
it MAY proceed with UUID generation as if this was the first UUID it MAY proceed with UUID generation as if this were the first UUID
created within a batch. This is the least desirable implementation created within a batch. This is the least desirable implementation
because it will increase the frequency of creation of values such as because it will increase the frequency of creation of values such as
clock sequence, counters, or random data, which increases the clock sequence, counters, or random data, which increases the
probability of duplicates. Further, frequent generation of random probability of duplicates. Further, frequent generation of random
numbers also puts more stress on any entropy source and or entropy numbers also puts more stress on any entropy source and/or entropy
pool being used as the basis for such random numbers. pool being used as the basis for such random numbers.
An implementation MAY also return an application error in the event An implementation MAY also return an application error in the event
that collision resistance is of the utmost concern. The semantics of that collision resistance is of the utmost concern. The semantics of
this error are up to the application and implementation. See this error are up to the application and implementation. See
Section 6.7 for more information on weighting collision tolerance in Section 6.7 for more information on weighting collision tolerance in
applications. applications.
For UUIDv1 and UUIDv6, if the node ID can never change (e.g., the For UUIDv1 and UUIDv6, if the Node ID can never change (e.g., the
network interface card from which the node ID is derived is network interface card from which the Node ID is derived is
inseparable from the system), or if any change also re-initializes inseparable from the system), or if any change also re-initializes
the clock sequence to a random value, then instead of keeping it in the clock sequence to a random value, then instead of keeping it in
stable store, the current node ID may be returned. stable store, the current Node ID may be returned.
For UUIDv1 and UUIDv6, the state does not always need to be written For UUIDv1 and UUIDv6, the state does not always need to be written
to stable store every time a UUID is generated. The timestamp in the to stable store every time a UUID is generated. The timestamp in the
stable store can be periodically set to a value larger than any yet stable store can periodically be set to a value larger than any yet
used in a UUID. As long as the generated UUIDs have timestamps less used in a UUID. As long as the generated UUIDs have timestamps less
than that value, and the clock sequence and node ID remain unchanged, than that value, and the clock sequence and Node ID remain unchanged,
only the shared volatile copy of the state needs to be updated. only the shared volatile copy of the state needs to be updated.
Furthermore, if the timestamp value in stable store is in the future Furthermore, if the timestamp value in stable store is in the future
by less than the typical time it takes the system to reboot, a crash by less than the typical time it takes the system to reboot, a crash
will not cause a re-initialization of the clock sequence. will not cause a re-initialization of the clock sequence.
If it is too expensive to access shared state each time a UUID is If it is too expensive to access shared state each time a UUID is
generated, then the system-wide generator can be implemented to generated, then the system-wide generator can be implemented to
allocate a block of time stamps each time it is called; a per- allocate a block of timestamps each time it is called; a per-process
process generator can allocate from that block until it is exhausted. generator can allocate from that block until it is exhausted.
6.4. Distributed UUID Generation 6.4. Distributed UUID Generation
Some implementations MAY desire to utilize multi-node, clustered, Some implementations MAY desire the utilization of multi-node,
applications which involve two or more nodes independently generating clustered, applications that involve two or more nodes independently
UUIDs that will be stored in a common location. While UUIDs already generating UUIDs that will be stored in a common location. While
feature sufficient entropy to ensure that the chances of collision UUIDs already feature sufficient entropy to ensure that the chances
are low, as the total number of UUID generating nodes increase; so of collision are low, as the total number of UUID generating nodes
does the likelihood of a collision. increases, so does the likelihood of a collision.
This section will detail the two additional collision resistance This section will detail the two additional collision resistance
approaches that have been observed by multi-node UUID implementations approaches that have been observed by multi-node UUID implementations
in distributed environments. in distributed environments.
It should be noted that, although this section details two methods It should be noted that, although this section details two methods
for the sake of completeness, implementations should utilize the for the sake of completeness, implementations should utilize the
pseudo-random Node ID option if additional collision resistance for pseudorandom Node ID option if additional collision resistance for
distributed UUID generation is a requirement. Likewise, utilization distributed UUID generation is a requirement. Likewise, utilization
of either method is not required for implementing UUID generation in of either method is not required for implementing UUID generation in
distributed environments. distributed environments.
Node IDs: Node IDs:
With this method, a pseudo-random Node ID value is placed within With this method, a pseudorandom Node ID value is placed within
the UUID layout. This identifier helps ensure the bit-space for a the UUID layout. This identifier helps ensure the bit space for a
given node is unique, resulting in UUIDs that do not conflict with given node is unique, resulting in UUIDs that do not conflict with
any other UUID created by another node with a different node id. any other UUID created by another node with a different node id.
Implementations that choose to leverage an embedded node id SHOULD Implementations that choose to leverage an embedded node id SHOULD
utilize UUIDv8. The node id SHOULD NOT be an IEEE 802 MAC address utilize UUIDv8. The node id SHOULD NOT be an IEEE 802 MAC address
as per Section 8. The location and bit length are left to per Section 8. The location and bit length are left to
implementations and are outside the scope of this specification. implementations and are outside the scope of this specification.
Furthermore, the creation and negotiation of unique node ids among Furthermore, the creation and negotiation of unique node ids among
nodes is also out of scope for this specification. nodes is also out of scope for this specification.
Centralized Registry: Centralized Registry:
With this method all nodes tasked with creating UUIDs consult a With this method, all nodes tasked with creating UUIDs consult a
central registry and confirm the generated value is unique. As central registry and confirm the generated value is unique. As
applications scale, the communication with the central registry applications scale, the communication with the central registry
could become a bottleneck and impact UUID generation in a negative could become a bottleneck and impact UUID generation in a negative
way. Shared knowledge schemes with central/global registries are way. Shared knowledge schemes with central/global registries are
outside the scope of this specification and is NOT RECOMMENDED. outside the scope of this specification and are NOT RECOMMENDED.
Distributed applications generating UUIDs at a variety of hosts MUST Distributed applications generating UUIDs at a variety of hosts MUST
be willing to rely on the random number source at all hosts. be willing to rely on the random number source at all hosts.
6.5. Name-Based UUID Generation 6.5. Name-Based UUID Generation
Although some prefer to use the word "hash-based" to describe UUIDs Although some prefer to use the word "hash-based" to describe UUIDs
featuring hashing algorithms (MD5 or SHA-1), this document retains featuring hashing algorithms (MD5 or SHA-1), this document retains
the usage of the adjective "name-based" in order to maintain the usage of the term "name-based" in order to maintain consistency
consistency with historical documents and existing implementations. with previously published documents and existing implementations.
The requirements for name-based UUIDs are as follows: The requirements for name-based UUIDs are as follows:
* UUIDs generated at different times from the same name (using the * UUIDs generated at different times from the same name (using the
same canonical format) in the same namespace MUST be equal. same canonical format) in the same namespace MUST be equal.
* UUIDs generated from two different names (same or differing * UUIDs generated from two different names (same or differing
canonical format) in the same namespace should be different (with canonical format) in the same namespace should be different (with
very high probability). very high probability).
skipping to change at page 37, line 14 skipping to change at line 1493
* UUIDs generated from the same name (same or differing canonical * UUIDs generated from the same name (same or differing canonical
format) in two different namespaces should be different (with very format) in two different namespaces should be different (with very
high probability). high probability).
* If two UUIDs that were generated from names (using the same * If two UUIDs that were generated from names (using the same
canonical format) are equal, then they were generated from the canonical format) are equal, then they were generated from the
same name in the same namespace (with very high probability). same name in the same namespace (with very high probability).
A note on names: A note on names:
The concept of name (and namespace) should be broadly construed The concept of name (and namespace) should be broadly construed
and not limited to textual names. A canonical sequence of octets and not limited to textual names. A canonical sequence of octets
is one that conforms to the specification for that name form's is one that conforms to the specification for that name form's
canonical representation. A name can have many usual forms, only canonical representation. A name can have many usual forms, only
one of which can be canonical. An implementer of new namespaces one of which can be canonical. An implementer of new namespaces
for UUIDs needs to reference the specification for the canonical for UUIDs needs to reference the specification for the canonical
form of names in that space, or define such a canonical for the form of names in that space or define such a canonical form for
namespace if it does not exist. For example, at the time of this the namespace if it does not exist. For example, at the time of
specification, [RFC8499] domain name system (DNS) has three writing, Domain Name System (DNS) [RFC9499] has three conveyance
conveyance formats: common (www.example.com), presentation formats: common (www.example.com), presentation
(www.example.com.) and wire format (3www7example3com0). Looking (www.example.com.), and wire format (3www7example3com0). Looking
at [X500] distinguished names (DNs), the previous version of this at [X500] Distinguished Names (DNs), [RFC4122] allowed either
specification allowed either text based or binary distinguished text-based or binary DER-based names as inputs. For Uniform
encoding rules (DER) based names as inputs. For [RFC1738] uniform Resource Locators (URLs) [RFC1738], one could provide a Fully
resource locators (URLs), one could provide a fully-qualified Qualified Domain Name (FQDN) with or without the protocol
domain-name (FQDN) with or without the protocol identifier identifier www.example.com or https://www.example.com. When it
(www.example.com) or (https://www.example.com). When it comes to comes to Object Identifiers (OIDs) [X660], one could choose dot
[X660] object identifiers (OIDs) one could choose dot-notation notation without the leading dot (2.999), choose to include the
without the leading dot (2.999), choose to include the leading dot leading dot (.2.999), or select one of the many formats from
(.2.999) or select one of the many formats from [X680] such as OID [X680] such as OID Internationalized Resource Identifier (OID-IRI)
Internationalized Resource Identifier (OID-IRI) (/Joint-ISO-ITU-T/ (/Joint-ISO-ITU-T/Example). While most users may default to the
Example). While most users may default to the common format for common format for DNS, FQDN format for a URL, text format for
DNS, FQDN format for a URL, text format for X.500 and dot-notation X.500, and dot notation without a leading dot for OID, name-based
without a leading dot for OID; name-based UUID implementations UUID implementations generally SHOULD allow arbitrary input that
generally SHOULD allow arbitrary input which will compute name- will compute name-based UUIDs for any of the aforementioned
based UUIDs for any of the aforementioned example names and others example names and others not defined here. Each name format
not defined here. Each name format within a namespace will output within a namespace will output different UUIDs. As such, the
different UUIDs. As such, the mechanisms or conventions used for mechanisms or conventions used for allocating names and ensuring
allocating names and ensuring their uniqueness within their their uniqueness within their namespaces are beyond the scope of
namespaces are beyond the scope of this specification. this specification.
6.6. Namespace ID Usage and Allocation 6.6. Namespace ID Usage and Allocation
This section and table, Table 3, details the namespace IDs for some This section details the namespace IDs for some potentially
potentially interesting namespaces such those for [RFC8499] domain interesting namespaces such as those for DNS [RFC9499], URLs
name system (DNS), [RFC1738] uniform resource locators (URLs), [X660] [RFC1738], OIDs [X660], and DNs [X500].
object identifiers (OIDs), and [X500] distinguished names (DNs).
Further, this section also details allocation, IANA registration and Further, this section also details allocation, IANA registration, and
other details pertinent to Namespace IDs. IANA may use the table other details pertinent to Namespace IDs.
Table 3 as-is replacing "This Document" replaced as required.
+=========+====================================+=========+==========+ +=========+====================================+=========+==========+
|Namespace|Namespace ID Value |Name |Namespace | |Namespace|Namespace ID Value |Name |Namespace |
| | |Reference|ID | | | |Reference|ID |
| | | |Reference | | | | |Reference |
+=========+====================================+=========+==========+ +=========+====================================+=========+==========+
|DNS |6ba7b810-9dad-11d1-80b4-00c04fd430c8|[RFC8499]|[RFC4122],| |DNS |6ba7b810-9dad-11d1-80b4-00c04fd430c8|[RFC9499]|[RFC4122],|
| | | |This | | | | |RFC 9562 |
| | | |document |
+---------+------------------------------------+---------+----------+ +---------+------------------------------------+---------+----------+
|URL |6ba7b811-9dad-11d1-80b4-00c04fd430c8|[RFC1738]|[RFC4122],| |URL |6ba7b811-9dad-11d1-80b4-00c04fd430c8|[RFC1738]|[RFC4122],|
| | | |This | | | | |RFC 9562 |
| | | |document |
+---------+------------------------------------+---------+----------+ +---------+------------------------------------+---------+----------+
|OID |6ba7b812-9dad-11d1-80b4-00c04fd430c8|[X660] |[RFC4122],| |OID |6ba7b812-9dad-11d1-80b4-00c04fd430c8|[X660] |[RFC4122],|
| | | |This | | | | |RFC 9562 |
| | | |document |
+---------+------------------------------------+---------+----------+ +---------+------------------------------------+---------+----------+
|X500 |6ba7b814-9dad-11d1-80b4-00c04fd430c8|[X500] |[RFC4122],| |X500 |6ba7b814-9dad-11d1-80b4-00c04fd430c8|[X500] |[RFC4122],|
| | | |This | | | | |RFC 9562 |
| | | |document |
+---------+------------------------------------+---------+----------+ +---------+------------------------------------+---------+----------+
Table 3: Namespace IDs Table 3: Namespace IDs
Items may be added to this table using "Specification Required" Items may be added to this registry using the Specification Required
policy as per [RFC8126]. policy as per [RFC8126].
For designated experts, generally speaking, Namespace IDs are For designated experts, generally speaking, Namespace IDs are
allocated as follows: allocated as follows:
* The first namespace ID value, for DNS, was calculated from a time- * The first Namespace ID value, for DNS, was calculated from a time-
based UUIDv1 and "6ba7b810-9dad-11d1-80b4-00c04fd430c8" used as a based UUIDv1 and "6ba7b810-9dad-11d1-80b4-00c04fd430c8", used as a
starting point. starting point.
* Subsequent namespace ID values increment the least-significant,
right-most bit of time_low "6ba7b810" while freezing the rest of * Subsequent Namespace ID values increment the least significant,
rightmost bit of time_low "6ba7b810" while freezing the rest of
the UUID to "9dad-11d1-80b4-00c04fd430c8". the UUID to "9dad-11d1-80b4-00c04fd430c8".
* New namespace ID values MUST use this same logic and MUST NOT use
* New Namespace ID values MUST use this same logic and MUST NOT use
a previously used Namespace ID value. a previously used Namespace ID value.
* Thus, "6ba7b815" is the next available time_low for a new * Thus, "6ba7b815" is the next available time_low for a new
Namespace ID value with the full ID being "6ba7b815-9dad- Namespace ID value with the full ID being "6ba7b815-9dad-
11d1-80b4-00c04fd430c8". 11d1-80b4-00c04fd430c8".
* The upper bound for time_low in this special use, namespace ID
values, is "ffffffff" or "ffffffff-9dad-11d1-80b4-00c04fd430c8"
which should be sufficient space for future namespace ID values.
Note that the namespace ID value "6ba7b813-9dad- * The upper bound for time_low in this special use, Namespace ID
11d1-80b4-00c04fd430c8" and its usage is not defined by this document values, is "ffffffff" or "ffffffff-9dad-11d1-80b4-00c04fd430c8",
or by [RFC4122], as such it SHOULD NOT be used as a Namespace ID which should be sufficient space for future Namespace ID values.
value.
Note that the Namespace ID value "6ba7b813-9dad-
11d1-80b4-00c04fd430c8" and its usage are not defined by this
document or by [RFC4122]; thus, it SHOULD NOT be used as a Namespace
ID value.
New Namespace ID values MUST be documented as per Section 7 if they New Namespace ID values MUST be documented as per Section 7 if they
are to be globally available and fully interoperable. are to be globally available and fully interoperable.
Implementations MAY continue to use vendor-specific, application- Implementations MAY continue to use vendor-specific, application-
specific, and deployment-specific Namespace ID values but know that specific, and deployment-specific Namespace ID values; but know that
interoperability is not guaranteed. These custom Namespace ID values interoperability is not guaranteed. These custom Namespace ID values
MUST NOT use the logic above and instead are RECOMMENDED to generate MUST NOT use the logic above; instead, generating a UUIDv4 or UUIDv7
a UUIDv4 or UUIDv7 Namespace ID value. If collision probability Namespace ID value is RECOMMENDED. If collision probability
(Section 6.7) and uniqueness (Section 6.8) of the final name-based (Section 6.7) and uniqueness (Section 6.8) of the final name-based
UUID are not a problem; an implementation MAY also leverage UUIDv8 UUID are not a problem, an implementation MAY also leverage UUIDv8
instead to create a custom, application-specific Namespace ID value. instead to create a custom, application-specific Namespace ID value.
Implementations SHOULD provide the ability to input a custom Implementations SHOULD provide the ability to input a custom
namespace to account for newly registered IANA Namespace ID values namespace to account for newly registered IANA Namespace ID values
outside of those listed in this section or custom, application outside of those listed in this section or custom, application-
specific Namespace ID values. specific Namespace ID values.
6.7. Collision Resistance 6.7. Collision Resistance
Implementations should weigh the consequences of UUID collisions Implementations should weigh the consequences of UUID collisions
within their application and when deciding between UUID versions that within their application and when deciding between UUID versions that
use entropy (randomness) versus the other components such as those in use entropy (randomness) versus the other components such as those in
Section 6.1 and Section 6.2. This is especially true for distributed Sections 6.1 and 6.2. This is especially true for distributed node
node collision resistance as defined by Section 6.4. collision resistance as defined by Section 6.4.
There are two example scenarios below which help illustrate the There are two example scenarios below that help illustrate the
varying seriousness of a collision within an application. varying seriousness of a collision within an application.
Low Impact: Low Impact:
A UUID collision generated a duplicate log entry which results in A UUID collision generated a duplicate log entry, which results in
incorrect statistics derived from the data. Implementations that incorrect statistics derived from the data. Implementations that
are not negatively affected by collisions may continue with the are not negatively affected by collisions may continue with the
entropy and uniqueness provided by the traditional UUID format. entropy and uniqueness provided by UUIDs defined in this document.
High Impact: High Impact:
A duplicate key causes an airplane to receive the wrong course A duplicate key causes an airplane to receive the wrong course,
which puts people's lives at risk. In this scenario there is no which puts people's lives at risk. In this scenario, there is no
margin for error. Collisions must be avoided and failure is margin for error. Collisions must be avoided: failure is
unacceptable. Applications dealing with this type of scenario unacceptable. Applications dealing with this type of scenario
must employ as much collision resistance as possible within the must employ as much collision resistance as possible within the
given application context. given application context.
6.8. Global and Local Uniqueness 6.8. Global and Local Uniqueness
UUIDs created by this specification MAY be used to provide local UUIDs created by this specification MAY be used to provide local
uniqueness guarantees. For example, ensuring UUIDs created within a uniqueness guarantees. For example, ensuring UUIDs created within a
local application context are unique within a database MAY be local application context are unique within a database MAY be
sufficient for some implementations where global uniqueness outside sufficient for some implementations where global uniqueness outside
of the application context, in other applications, or around the of the application context, in other applications, or around the
world is not required. world is not required.
Although true global uniqueness is impossible to guarantee without a Although true global uniqueness is impossible to guarantee without a
shared knowledge scheme, a shared knowledge scheme is not required by shared knowledge scheme, a shared knowledge scheme is not required by
UUID to provide uniqueness for practical implementation purposes. a UUID to provide uniqueness for practical implementation purposes.
Implementations MAY implement a shared knowledge scheme introduced in Implementations MAY use a shared knowledge scheme, introduced in
Section 6.4 as they see fit to extend the uniqueness guaranteed by Section 6.4, as they see fit to extend the uniqueness guaranteed by
this specification. this specification.
6.9. Unguessability 6.9. Unguessability
Implementations SHOULD utilize a cryptographically secure pseudo- Implementations SHOULD utilize a cryptographically secure
random number generator (CSPRNG) to provide values that are both pseudorandom number generator (CSPRNG) to provide values that are
difficult to predict ("unguessable") and have a low likelihood of both difficult to predict ("unguessable") and have a low likelihood
collision ("unique"). The exception is when a suitable CSPRNG is of collision ("unique"). The exception is when a suitable CSPRNG is
unavailable in the execution environment. Take care to ensure the unavailable in the execution environment. Take care to ensure the
CSPRNG state is properly reseeded upon state changes, such as process CSPRNG state is properly reseeded upon state changes, such as process
forks, to ensure proper CSPRNG operation. CSPRNG ensures the best of forks, to ensure proper CSPRNG operation. CSPRNG ensures the best of
Section 6.7 and Section 8 are present in modern UUIDs. Sections 6.7 and 8 are present in modern UUIDs.
Further advice on generating cryptographic-quality random numbers can Further advice on generating cryptographic-quality random numbers can
be found in [RFC4086], [RFC8937] and in [RANDOM]. be found in [RFC4086], [RFC8937], and [RANDOM].
6.10. UUIDs That Do Not Identify the Host 6.10. UUIDs That Do Not Identify the Host
This section describes how to generate a UUIDv1 or UUIDv6 value if an This section describes how to generate a UUIDv1 or UUIDv6 value if an
IEEE 802 address is not available, or its use is not desired. IEEE 802 address is not available or its use is not desired.
Implementations MAY leverage MAC address randomization techniques Implementations MAY leverage MAC address randomization techniques
(IEEE 802.11bh) as an alternative to the pseudo-random logic provided [IEEE802.11bh] as an alternative to the pseudorandom logic provided
in this section. in this section.
Alternatively, implementations MAY elect to obtain a 48 bit Alternatively, implementations MAY elect to obtain a 48-bit
cryptographic-quality random number as per Section 6.9 to use it as cryptographic-quality random number as per Section 6.9 to use as the
the node ID. After generating the 48 bit fully randomized node Node ID. After generating the 48-bit fully randomized node value,
value, implementations MUST set the least significant bit of the implementations MUST set the least significant bit of the first octet
first octet of the node ID set to 1. This bit is the unicast/ of the Node ID to 1. This bit is the unicast or multicast bit, which
multicast bit, which will never be set in IEEE 802 addresses obtained will never be set in IEEE 802 addresses obtained from network cards.
from network cards. Hence, there can never be a conflict between Hence, there can never be a conflict between UUIDs generated by
UUIDs generated by machines with and without network cards. An machines with and without network cards. An example of generating a
example of generating a randomized 48 bit node value and the randomized 48-bit node value and the subsequent bit modification is
subsequent bit modification is detailed in the Appendix A appendix. detailed in Appendix A. For more information about IEEE 802 address
For more information about IEEE 802 address and the unicast/multicast and the unicast or multicast or local/global bits, please review
or local/global bits please review [RFC7042]. [RFC9542].
For compatibility with earlier specifications, note that this For compatibility with earlier specifications, note that this
document uses the unicast/multicast bit, instead of the arguably more document uses the unicast or multicast bit instead of the arguably
correct local/global bit because MAC addresses with the local/global more correct local/global bit because MAC addresses with the local/
bit set or not are both possible in a network. This is not the case global bit set or not set are both possible in a network. This is
with the unicast/multicast bit. One node cannot have a MAC address not the case with the unicast or multicast bit. One node cannot have
that multicasts to multiple nodes. a MAC address that multicasts to multiple nodes.
In addition, items such as the computer's name and the name of the In addition, items such as the computer's name and the name of the
operating system, while not strictly speaking random, will help operating system, while not strictly speaking random, will help
differentiate the results from those obtained by other systems. differentiate the results from those obtained by other systems.
The exact algorithm to generate a node ID using these data is system The exact algorithm to generate a Node ID using these data is system
specific, because both the data available and the functions to obtain specific because both the data available and the functions to obtain
them are often very system specific. A generic approach, however, is them are often very system specific. However, a generic approach is
to accumulate as many sources as possible into a buffer, use a to accumulate as many sources as possible into a buffer, use a
message digest (such as SHA-256 or SHA-512 defined by [FIPS180-4]), message digest (such as SHA-256 or SHA-512 defined by [FIPS180-4]),
take an arbitrary 6 bytes from the hash value, and set the multicast take an arbitrary 6 bytes from the hash value, and set the multicast
bit as described above. bit as described above.
6.11. Sorting 6.11. Sorting
UUIDv6 and UUIDv7 are designed so that implementations that require UUIDv6 and UUIDv7 are designed so that implementations that require
sorting (e.g., database indexes) sort as opaque raw bytes, without sorting (e.g., database indexes) sort as opaque raw bytes without the
need for parsing or introspection. need for parsing or introspection.
Time ordered monotonic UUIDs benefit from greater database index Time-ordered monotonic UUIDs benefit from greater database-index
locality because the new values are near each other in the index. As locality because the new values are near each other in the index. As
a result objects are more easily clustered together for better a result, objects are more easily clustered together for better
performance. The real-world differences in this approach of index performance. The real-world differences in this approach of index
locality vs random data inserts can be one order of magnitude or locality versus random data inserts can be one order of magnitude or
more. more.
UUID formats created by this specification are intended to be UUID formats created by this specification are intended to be
lexicographically sortable while in the textual representation. lexicographically sortable while in the textual representation.
UUIDs created by this specification are crafted with big-endian byte UUIDs created by this specification are crafted with big-endian byte
order (network byte order) in mind. If little-endian style is order (network byte order) in mind. If little-endian style is
required, UUIDv8 is available for custom UUID formats. required, UUIDv8 is available for custom UUID formats.
6.12. Opacity 6.12. Opacity
As general guidance, it is recommend to avoid parsing UUID values As general guidance, avoiding parsing UUID values unnecessarily is
unnecessarily, and instead treating UUIDs as opaquely as possible. recommended; instead, treat UUIDs as opaquely as possible. Although
Although application-specific concerns could of course require some application-specific concerns could, of course, require some degree
degree of introspection (e.g., to examine the Section 4.1, of introspection (e.g., to examine Sections 4.1 or 4.2 or perhaps the
Section 4.2 or perhaps the timestamp of a UUID), the advice here is timestamp of a UUID), the advice here is to avoid this or other
to avoid this or other parsing unless absolutely necessary. parsing unless absolutely necessary. Applications typically tend to
Applications typically tend to be simpler, more interoperable, and be simpler, be more interoperable, and perform better when this
perform better, when this advice is followed. advice is followed.
6.13. DBMS and Database Considerations 6.13. DBMS and Database Considerations
For many applications, such as databases, storing UUIDs as text is For many applications, such as databases, storing UUIDs as text is
unnecessarily verbose, requiring 288 bits to represent 128 bit UUID unnecessarily verbose, requiring 288 bits to represent 128-bit UUID
values. Thus, where feasible, UUIDs SHOULD be stored within database values. Thus, where feasible, UUIDs SHOULD be stored within database
applications as the underlying 128 bit binary value. applications as the underlying 128-bit binary value.
For other systems, UUIDs MAY be stored in binary form or as text, as For other systems, UUIDs MAY be stored in binary form or as text, as
appropriate. The trade-offs to both approaches are: appropriate. The trade-offs to both approaches are as follows:
* Storing as binary requires less space and may result in faster * Storing in binary form requires less space and may result in
data access. faster data access.
* Storing as text requires more space but may require less * Storing as text requires more space but may require less
translation if the resulting text form is to be used after translation if the resulting text form is to be used after
retrieval, which thus may make it simpler to implement. retrieval, which may make it simpler to implement.
DBMS vendors are encouraged to provide functionality to generate and DBMS vendors are encouraged to provide functionality to generate and
store UUID formats defined by this specification for use as store UUID formats defined by this specification for use as
identifiers or left parts of identifiers such as, but not limited to, identifiers or left parts of identifiers such as, but not limited to,
primary keys, surrogate keys for temporal databases, foreign keys primary keys, surrogate keys for temporal databases, foreign keys
included in polymorphic relationships, and keys for key-value pairs included in polymorphic relationships, and keys for key-value pairs
in JSON columns and key-value databases. Applications using a in JSON columns and key-value databases. Applications using a
monolithic database may find using database-generated UUIDs (as monolithic database may find using database-generated UUIDs (as
opposed to client-generate UUIDs) provides the best UUID opposed to client-generated UUIDs) provides the best UUID
monotonicity. In addition to UUIDs, additional identifiers MAY be monotonicity. In addition to UUIDs, additional identifiers MAY be
used to ensure integrity and feedback. used to ensure integrity and feedback.
Designers of database schema are cautioned against using name-based Designers of database schema are cautioned against using name-based
UUIDs (Section 5.3/Section 5.5) as primary keys in tables. A common UUIDs (see Sections 5.3 and 5.5) as primary keys in tables. A common
issue observed in database schema design is the assumption that a issue observed in database schema design is the assumption that a
particular value will never change, which then later turns out to be particular value will never change, which later turns out to be an
an incorrect assumption. Postal codes, license or other incorrect assumption. Postal codes, license or other identification
identification numbers, and numerous other such identifiers seem numbers, and numerous other such identifiers seem unique and
unique and unchanging at a given point time; only to later turn out unchanging at a given point time -- only later to have edge cases
to have edge cases where they need to change. The subsequent change where they need to change. The subsequent change of the identifier,
of the identifier, used as a "name" input for name-based UUIDs, can used as a "name" input for name-based UUIDs, can invalidate a given
invalidate a given database structure. In such scenarios it is database structure. In such scenarios, it is observed that using any
observed that using any non-name-based UUID version would have non-name-based UUID version would have resulted in the field in
resulted in the field in question being placed somewhere that would question being placed somewhere that would have been easier to adapt
have been easier to adapt to such changes (primary key excluded from to such changes (primary key excluded from this statement). The
this statement). The general advice is to avoid name-based UUID general advice is to avoid name-based UUID natural keys and, instead,
natural keys and instead utilize time-based UUID surrogate keys based to utilize time-based UUID surrogate keys based on the aforementioned
on the aforementioned problems detailed in this section. problems detailed in this section.
7. IANA Considerations 7. IANA Considerations
All references to [RFC4122] in the IANA registries should be replaced All references to [RFC4122] in IANA registries (outside of those
with references to this document. References to [RFC4122] document's created by this document) have been replaced with references to this
Section 4.1.2 should be updated to refer to this document's document, including the IANA URN namespace registration
Section 4. [URNNamespaces] for UUID. References to Section 4.1.2 of [RFC4122]
have been updated to refer to Section 4 of this document.
The IANA URN namespace registration [URNNamespaces] for UUID filed in
[RFC4122] should be updated to reference this document.
Finally IANA should track UUID Subtypes and Special Case "Namespace Finally, IANA should track UUID Subtypes and Special Case "Namespace
IDs Values" as specified in Section 7.1 and Section 7.2. IDs Values" as specified in Sections 7.1 and 7.2 at the following
location: <https://www.iana.org/assignments/uuid>.
When evaluating requests, the designated expert(s) should consider When evaluating requests, the designated expert should consider
community feedback, how well-defined is the reference specification, community feedback, how well-defined the reference specification is,
and this specification's requirements. Vendor-specific, application- and this specification's requirements. Vendor-specific, application-
specific, and deployment-specific values are unable to be registered. specific, and deployment-specific values are unable to be registered.
Specification documents should be published in a stable, freely Specification documents should be published in a stable, freely
available manner (ideally located with a URL) but need not be available manner (ideally, located with a URL) but need not be
standards. The designated experts will either approve or deny the standards. The designated expert will either approve or deny the
registration request, and communicate their decision to IANA. registration request and communicate this decision to IANA. Denials
Denials should include an explanation and, if applicable, suggestions should include an explanation and, if applicable, suggestions as to
as to how to make the request successful. how to make the request successful.
7.1. IANA UUID Subtype Registry and Registration 7.1. IANA UUID Subtype Registry and Registration
This specification defines the "UUID Subtype" registry for common, This specification defines the "UUID Subtypes" registry for common
widely used UUID standards. widely used UUID standards.
Table 4 should be used as-is for this registry with "This document" +======================+====+=========+================+============+
replaced as required. | Name | ID | Subtype | Variant | Reference |
+======================+====+=========+================+============+
+======================+====+=========+=========+===============+ | Gregorian Time-based | 1 | version | OSF DCE | [RFC4122], |
| Name | ID | Subtype | Variant | Reference | | | | | / IETF | RFC 9562 |
+======================+====+=========+=========+===============+ +----------------------+----+---------+----------------+------------+
| Gregorian Time-based | 1 | version | OSF DCE | [RFC4122], | | DCE Security | 2 | version | OSF DCE | [C309], |
| | | | / IETF | This document | | | | | / IETF | [C311] |
+----------------------+----+---------+---------+---------------+ +----------------------+----+---------+----------------+------------+
| DCE Security | 2 | version | OSF DCE | [C309], | | MD5 Name-based | 3 | version | OSF DCE | [RFC4122], |
| | | | / IETF | [C311] | | | | | / IETF | RFC 9562 |
+----------------------+----+---------+---------+---------------+ +----------------------+----+---------+----------------+------------+
| MD5 Name-based | 3 | version | OSF DCE | [RFC4122], | | Random | 4 | version | OSF DCE | [RFC4122], |
| | | | / IETF | This document | | | | | / IETF | RFC 9562 |
+----------------------+----+---------+---------+---------------+ +----------------------+----+---------+----------------+------------+
| Random | 4 | version | OSF DCE | [RFC4122], | | SHA-1 Name-based | 5 | version | OSF DCE | [RFC4122], |
| | | | / IETF | This document | | | | | / IETF | RFC 9562 |
+----------------------+----+---------+---------+---------------+ +----------------------+----+---------+----------------+------------+
| SHA-1 Name-based | 5 | version | OSF DCE | [RFC4122], | | Reordered Gregorian | 6 | version | OSF DCE | RFC 9562 |
| | | | / IETF | This document | | Time-based | | | / IETF | |
+----------------------+----+---------+---------+---------------+ +----------------------+----+---------+----------------+------------+
| Reordered Gregorian | 6 | version | OSF DCE | This document | | Unix Time-based | 7 | version | OSF DCE | RFC 9562 |
| Time-based | | | / IETF | | | | | | / IETF | |
+----------------------+----+---------+---------+---------------+ +----------------------+----+---------+----------------+------------+
| Unix Time-based | 7 | version | OSF DCE | This document | | Custom | 8 | version | OSF DCE | RFC 9562 |
| | | | / IETF | | | | | | / IETF | |
+----------------------+----+---------+---------+---------------+ +----------------------+----+---------+----------------+------------+
| Custom | 8 | version | OSF DCE | This document |
| | | | / IETF | |
+----------------------+----+---------+---------+---------------+
Table 4: IANA UUID Subtypes Table 4: IANA UUID Subtypes
This table may be extended by the "Standards Action" policy, per This table may be extended by Standards Action as per [RFC8126].
[RFC8126].
For designated experts: For designated experts:
* The minimum and maximum "ID" value for the subtype "version" * The minimum and maximum "ID" value for the subtype "version"
within the "OSF DCE / IETF" variant is 0 through 15. The within the "OSF DCE / IETF" variant is 0 through 15. The versions
versions, within Table 1, described as "Reserved for future within Table 1 described as "Reserved for future definition" or
definition" or "unused" are omitted from this IANA registry until "unused" are omitted from this IANA registry until properly
properly defined. defined.
* The "Subtype" column is free-form text however at the time of this * The "Subtype" column is free-form text. However, at the time of
publication only "version" and "family" are known UUID subtypes. publication, "version" and "family" are the only known UUID
The "family" subtype is part of the "Apollo NCS" variant space subtypes. The "family" subtype is part of the "Apollo NCS"
(Both are outside the scope of this specification). The Microsoft variant space (both are outside the scope of this specification).
variant may have subtyping mechanisms defined however they are The Microsoft variant may have subtyping mechanisms defined;
unknown and outside of the scope of this specification. however, they are unknown and outside of the scope of this
Similarly, the final "Reserved for future definition" variant may specification. Similarly, the final "Reserved for future
introduce new subtyping logic at a future date. Subtype IDs are definition" variant may introduce new subtyping logic at a future
permitted to overlap, that is, an ID of "1" may exist in multiple date. Subtype IDs are permitted to overlap. That is, an ID of
variant spaces. "1" may exist in multiple variant spaces.
* The "Variant" column is free-form text however it is likely one of
four values will be included. The first three are "OSF DCE / * The "Variant" column is free-form text. However, it is likely
IETF", "Apollo NCS", "Microsoft". The final variant value belongs that one of four values will be included: the first three are "OSF
to the "Reserved for future definition" variant and may introduce DCE / IETF", "Apollo NCS", and "Microsoft", and the final variant
a new name at a future date. value belongs to the "Reserved for future definition" variant and
may introduce a new name at a future date.
7.2. IANA UUID Namespace ID Registry and Registration 7.2. IANA UUID Namespace ID Registry and Registration
This specification defines the "UUID Namespace ID" registry for This specification defines the "UUID Namespace IDs" registry for
common, widely used Namespace ID values. common, widely used Namespace ID values.
The full details of this registration, including information for The full details of this registration, including information for
designated experts, can be found in Section 6.6. designated experts, can be found in Section 6.6.
8. Security Considerations 8. Security Considerations
Implementations SHOULD NOT assume that UUIDs are hard to guess. For Implementations SHOULD NOT assume that UUIDs are hard to guess. For
example, they MUST NOT be used as security capabilities (identifiers example, they MUST NOT be used as security capabilities (identifiers
whose mere possession grants access). Discovery of predictability in whose mere possession grants access). Discovery of predictability in
a random number source will result in a vulnerability. a random number source will result in a vulnerability.
Implementations MUST NOT assume that it is easy to determine if a Implementations MUST NOT assume that it is easy to determine if a
UUID has been slightly modified in order to redirect a reference to UUID has been slightly modified in order to redirect a reference to
another object. Humans do not have the ability to easily check the another object. Humans do not have the ability to easily check the
integrity of a UUID by simply glancing at it. integrity of a UUID by simply glancing at it.
MAC addresses pose inherent security risks around privacy and SHOULD MAC addresses pose inherent security risks around privacy and SHOULD
NOT be used within a UUID. Instead CSPRNG data SHOULD be selected NOT be used within a UUID. Instead CSPRNG data SHOULD be selected
from a source with sufficient entropy to ensure guaranteed uniqueness from a source with sufficient entropy to ensure guaranteed uniqueness
among UUID generation. See Section 6.9 and Section 6.10 for more among UUID generation. See Sections 6.9 and 6.10 for more
information. information.
Timestamps embedded in the UUID do pose a very small attack surface. Timestamps embedded in the UUID do pose a very small attack surface.
The timestamp in conjunction with an embedded counter does signal the The timestamp in conjunction with an embedded counter does signal the
order of creation for a given UUID and its corresponding data but order of creation for a given UUID and its corresponding data but
does not define anything about the data itself or the application as does not define anything about the data itself or the application as
a whole. If UUIDs are required for use with any security operation a whole. If UUIDs are required for use with any security operation
within an application context in any shape or form then UUIDv4, within an application context in any shape or form, then UUIDv4
Section 5.4 SHOULD be utilized. (Section 5.4) SHOULD be utilized.
See [RFC6151] for MD5 Security Considerations and [RFC6194] for SHA-1 See [RFC6151] for MD5 security considerations and [RFC6194] for SHA-1
security considerations. security considerations.
9. Acknowledgements 9. References
The authors gratefully acknowledge the contributions of Rich Salz,
Michael Mealling, Ben Campbell, Ben Ramsey, Fabio Lima, Gonzalo
Salgueiro, Martin Thomson, Murray S. Kucherawy, Rick van Rein, Rob
Wilton, Sean Leonard, Theodore Y. Ts'o, Robert Kieffer, Sergey
Prokhorenko, LiosK.
As well as all of those in the IETF community and on GitHub to who
contributed to the discussions which resulted in this document.
This document draws heavily on the OSF DCE specification for UUIDs.
Ted Ts'o provided helpful comments, especially on the byte ordering
section which we mostly plagiarized from a proposed wording he
supplied (all errors in that section are our responsibility,
however).
We are also grateful to the careful reading and bit-twiddling of Ralf
S. Engelschall, John Larmouth, and Paul Thorpe. Professor Larmouth
was also invaluable in achieving coordination with ISO/IEC.
10. References
10.1. Normative References 9.1. Normative References
[C309] "DCE: Remote Procedure Call", Open Group CAE Specification [C309] X/Open Company Limited, "X/Open DCE: Remote Procedure
C309, ISBN 1-85912-041-5, August 1994, Call", ISBN 1-85912-041-5, Open CAE Specification C309,
August 1994,
<https://pubs.opengroup.org/onlinepubs/9696999099/ <https://pubs.opengroup.org/onlinepubs/9696999099/
toc.pdf>. toc.pdf>.
[C311] "DCE 1.1: Authentication and Security Services", Open [C311] The Open Group, "DCE 1.1: Authentication and Security
Group CAE Specification C311, 1997, Services", Open Group CAE Specification C311, August 1997,
<https://pubs.opengroup.org/onlinepubs/9696989899/ <https://pubs.opengroup.org/onlinepubs/9696989899/
toc.pdf>. toc.pdf>.
[FIPS180-4] [FIPS180-4]
National Institute of Standards and Technology, "Secure National Institute of Standards and Technology (NIST),
Hash Standard", FIPS PUB 180-4, August 2015, "Secure Hash Standard (SHS)", FIPS PUB 180-4,
DOI 10.6028/NIST.FIPS.180-4, August 2015,
<https://nvlpubs.nist.gov/nistpubs/FIPS/ <https://nvlpubs.nist.gov/nistpubs/FIPS/
NIST.FIPS.180-4.pdf>. NIST.FIPS.180-4.pdf>.
[FIPS202] National Institute of Standards and Technology, "SHA-3 [FIPS202] National Institute of Standards and Technology (NIST),
Standard: Permutation-Based Hash and Extendable-Output "SHA-3 Standard: Permutation-Based Hash and Extendable-
Functions", FIPS PUB 202, August 2015, Output Functions", FIPS PUB 202,
DOI 10.6028/NIST.FIPS.202, August 2015,
<https://nvlpubs.nist.gov/nistpubs/FIPS/ <https://nvlpubs.nist.gov/nistpubs/FIPS/
NIST.FIPS.202.pdf>. NIST.FIPS.202.pdf>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC8141] Saint-Andre, P. and J. Klensin, "Uniform Resource Names [RFC8141] Saint-Andre, P. and J. Klensin, "Uniform Resource Names
(URNs)", RFC 8141, DOI 10.17487/RFC8141, April 2017, (URNs)", RFC 8141, DOI 10.17487/RFC8141, April 2017,
<https://www.rfc-editor.org/rfc/rfc8141>. <https://www.rfc-editor.org/info/rfc8141>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[X667] "Information Technology, "Procedures for the operation of [X667] ITU-T, "Information technology - Open Systems
OSI Registration Authorities: Generation and registration Interconnection - Procedures for the operation of OSI
of Universally Unique Identifiers (UUIDs) and their use as Registration Authorities: Generation and registration of
ASN.1 Object Identifier components"", ISO/IEC 9834-8:2004, Universally Unique Identifiers (UUIDs) and their use as
ITU-T Rec. X.667, 2004. ASN.1 object identifier components", ISO/IEC 9834-8:2004,
ITU-T Recommendation X.667, September 2004.
10.2. Informative References 9.2. Informative References
[COMBGUID] Tallent, R., "Creating sequential GUIDs in C# for MSSQL or [COMBGUID] "Creating sequential GUIDs in C# for MSSQL or PostgreSql",
PostgreSql", Commit 2759820, December 2020, commit 2759820, December 2020,
<https://github.com/richardtallent/RT.Comb>. <https://github.com/richardtallent/RT.Comb>.
[CUID] Elliott, E., "Collision-resistant ids optimized for [CUID] "Collision-resistant ids optimized for horizontal scaling
horizontal scaling and performance.", Commit 215b27b, and performance.", commit 215b27b, October 2020,
October 2020, <https://github.com/ericelliott/cuid>. <https://github.com/ericelliott/cuid>.
[Elasticflake] [Elasticflake]
Pearcy, P., "Sequential UUID / Flake ID generator pulled Pearcy, P., "Sequential UUID / Flake ID generator pulled
out of elasticsearch common", Commit dd71c21, January out of elasticsearch common", commit dd71c21, January
2015, <https://github.com/ppearcy/elasticflake>. 2015, <https://github.com/ppearcy/elasticflake>.
[Err1957] RFC Errata, Erratum ID 1957, RFC 4122,
<https://www.rfc-editor.org/errata/eid1957>.
[Err3546] RFC Errata, Erratum ID 3546, RFC 4122,
<https://www.rfc-editor.org/errata/eid3546>.
[Err4975] RFC Errata, Erratum ID 4975, RFC 4122,
<https://www.rfc-editor.org/errata/eid4975>.
[Err4976] RFC Errata, Erratum ID 4976, RFC 4122,
<https://www.rfc-editor.org/errata/eid4976>.
[Err5560] RFC Errata, Erratum ID 5560, RFC 4122,
<https://www.rfc-editor.org/errata/eid5560>.
[Flake] Boundary, "Flake: A decentralized, k-ordered id generation [Flake] Boundary, "Flake: A decentralized, k-ordered id generation
service in Erlang", Commit 15c933a, February 2017, service in Erlang", commit 15c933a, February 2017,
<https://github.com/boundary/flake>. <https://github.com/boundary/flake>.
[FlakeID] Pawlak, T., "Flake ID Generator", Commit fcd6a2f, April [FlakeID] "Flake ID Generator", commit fcd6a2f, April 2020,
2020, <https://github.com/T-PWK/flake-idgen>. <https://github.com/T-PWK/flake-idgen>.
[IBM_NCS] IBM, "uuid_gen Command (NCS)", 23 March 2023, [IBM_NCS] IBM, "uuid_gen Command (NCS)", March 2023,
<https://www.ibm.com/docs/en/aix/7.1?topic=u-uuid-gen- <https://www.ibm.com/docs/en/aix/7.1?topic=u-uuid-gen-
command-ncs>. command-ncs>.
[IEEE754] IEEE, "IEEE Standard for Floating-Point Arithmetic.", [IEEE754] IEEE, "IEEE Standard for Floating-Point Arithmetic.", IEEE
Series 754-2019, July 2019, Std 754-2019, DOI 10.1109/IEEESTD.2019.8766229, July 2019,
<https://standards.ieee.org/ieee/754/6210/>. <https://standards.ieee.org/ieee/754/6210/>.
[KSUID] Segment, "K-Sortable Globally Unique IDs", Commit bf376a7, [IEEE802.11bh]
IEEE, "IEEE Draft Standard for Information technology--
Telecommunications and information exchange between
systems Local and metropolitan area networks--Specific
requirements - Part 11: Wireless LAN Medium Access Control
(MAC) and Physical Layer (PHY) Specifications Amendment:
Enhancements for Extremely High Throughput (EHT)",
Electronic ISBN 978-1-5044-9520-2, March 2023,
<https://standards.ieee.org/ieee/802.11bh/10525/>.
[KSUID] Segment, "K-Sortable Globally Unique IDs", commit bf376a7,
July 2020, <https://github.com/segmentio/ksuid>. July 2020, <https://github.com/segmentio/ksuid>.
[LexicalUUID] [LexicalUUID]
Twitter, "A Scala client for Cassandra", commit f6da4e0, Twitter, "Cassie", commit f6da4e0, November 2012,
November 2012,
<https://github.com/twitter-archive/cassie>. <https://github.com/twitter-archive/cassie>.
[Microsoft] [Microsoft]
Microsoft, "curly braced GUID string", 3 April 2023, Microsoft, "2.3.4.3 GUID - Curly Braced String
<https://learn.microsoft.com/en- Representation", April 2023, <https://learn.microsoft.com/
us/openspecs/windows_protocols/ms-dtyp/a66edeb1-52a0-4d64- en-us/openspecs/windows_protocols/ms-
a93b-2f5c833d7d92>. dtyp/222af2d3-5c00-4899-bc87-ed4c6515e80d>.
[MS_COM_GUID] [MS_COM_GUID]
Chen, R., "Why does COM express GUIDs in a mix of big- Chen, R., "Why does COM express GUIDs in a mix of big-
endian and little-endian? Why can’t it just pick a side endian and little-endian? Why can't it just pick a side
and stick with it?", 28 September 2022, and stick with it?", September 2022,
<https://devblogs.microsoft.com/ <https://devblogs.microsoft.com/
oldnewthing/20220928-00/?p=107221>. oldnewthing/20220928-00/?p=107221>.
[ObjectID] MongoDB, "ObjectId - MongoDB Manual", [ObjectID] MongoDB, "ObjectId",
<https://docs.mongodb.com/manual/reference/method/ <https://docs.mongodb.com/manual/reference/method/
ObjectId/>. ObjectId/>.
[orderedUuid] [orderedUuid]
Cabrera, I. B., "Laravel: The mysterious "Ordered UUID"", Cabrera, I. B., "Laravel: The mysterious "Ordered UUID"",
January 2020, <https://itnext.io/laravel-the-mysterious- January 2020, <https://itnext.io/laravel-the-mysterious-
ordered-uuid-29e7500b4f8>. ordered-uuid-29e7500b4f8>.
[pushID] Google, "The 2^120 Ways to Ensure Unique Identifiers", [pushID] Lehenbauer, M., "The 2^120 Ways to Ensure Unique
February 2015, <https://firebase.googleblog.com/2015/02/ Identifiers", February 2015,
the-2120-ways-to-ensure-unique_68.html>. <https://firebase.googleblog.com/2015/02/the-2120-ways-to-
ensure-unique_68.html>.
[Python] Python, "UUID objects according to RFC", 23 May 2023, [Python] Python, "uuid - UUID objects according to RFC 4122",
<https://docs.python.org/3/library/uuid.html>. <https://docs.python.org/3/library/uuid.html>.
[RANDOM] Occil, P., "Random Number Generator Recommendations for [RANDOM] Occil, P., "Random Number Generator Recommendations for
Applications", 2023, Applications", June 2023,
<https://peteroupc.github.io/random.html>. <https://peteroupc.github.io/random.html>.
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
DOI 10.17487/RFC1321, April 1992, DOI 10.17487/RFC1321, April 1992,
<https://www.rfc-editor.org/rfc/rfc1321>. <https://www.rfc-editor.org/info/rfc1321>.
[RFC1738] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform [RFC1738] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform
Resource Locators (URL)", RFC 1738, DOI 10.17487/RFC1738, Resource Locators (URL)", RFC 1738, DOI 10.17487/RFC1738,
December 1994, <https://www.rfc-editor.org/rfc/rfc1738>. December 1994, <https://www.rfc-editor.org/info/rfc1738>.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086, "Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005, DOI 10.17487/RFC4086, June 2005,
<https://www.rfc-editor.org/rfc/rfc4086>. <https://www.rfc-editor.org/info/rfc4086>.
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
Unique IDentifier (UUID) URN Namespace", RFC 4122, Unique IDentifier (UUID) URN Namespace", RFC 4122,
DOI 10.17487/RFC4122, July 2005, DOI 10.17487/RFC4122, July 2005,
<https://www.rfc-editor.org/rfc/rfc4122>. <https://www.rfc-editor.org/info/rfc4122>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008, DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/rfc/rfc5234>. <https://www.rfc-editor.org/info/rfc5234>.
[RFC6151] Turner, S. and L. Chen, "Updated Security Considerations [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations
for the MD5 Message-Digest and the HMAC-MD5 Algorithms", for the MD5 Message-Digest and the HMAC-MD5 Algorithms",
RFC 6151, DOI 10.17487/RFC6151, March 2011, RFC 6151, DOI 10.17487/RFC6151, March 2011,
<https://www.rfc-editor.org/rfc/rfc6151>. <https://www.rfc-editor.org/info/rfc6151>.
[RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security [RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security
Considerations for the SHA-0 and SHA-1 Message-Digest Considerations for the SHA-0 and SHA-1 Message-Digest
Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011, Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011,
<https://www.rfc-editor.org/rfc/rfc6194>. <https://www.rfc-editor.org/info/rfc6194>.
[RFC7042] Eastlake 3rd, D. and J. Abley, "IANA Considerations and
IETF Protocol and Documentation Usage for IEEE 802
Parameters", BCP 141, RFC 7042, DOI 10.17487/RFC7042,
October 2013, <https://www.rfc-editor.org/rfc/rfc7042>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/rfc/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
[RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499,
January 2019, <https://www.rfc-editor.org/rfc/rfc8499>.
[RFC8937] Cremers, C., Garratt, L., Smyshlyaev, S., Sullivan, N., [RFC8937] Cremers, C., Garratt, L., Smyshlyaev, S., Sullivan, N.,
and C. Wood, "Randomness Improvements for Security and C. Wood, "Randomness Improvements for Security
Protocols", RFC 8937, DOI 10.17487/RFC8937, October 2020, Protocols", RFC 8937, DOI 10.17487/RFC8937, October 2020,
<https://www.rfc-editor.org/rfc/rfc8937>. <https://www.rfc-editor.org/info/rfc8937>.
[RFC9499] Hoffman, P. and K. Fujiwara, "DNS Terminology", BCP 219,
RFC 9499, DOI 10.17487/RFC9499, March 2024,
<https://www.rfc-editor.org/info/rfc9499>.
[RFC9542] Eastlake 3rd, D., Abley, J., and Y. Li, "IANA
Considerations and IETF Protocol and Documentation Usage
for IEEE 802 Parameters", BCP 141, RFC 9542,
DOI 10.17487/RFC9542, April 2024,
<https://www.rfc-editor.org/info/rfc9542>.
[ShardingID] [ShardingID]
Instagram Engineering, "Sharding & IDs at Instagram", Instagram Engineering, "Sharding & IDs at Instagram",
December 2012, <https://instagram-engineering.com/ December 2012, <https://instagram-engineering.com/
sharding-ids-at-instagram-1cf5a71e5a5c>. sharding-ids-at-instagram-1cf5a71e5a5c>.
[SID] Chilton, A., "sid : generate sortable identifiers", [SID] "sid : generate sortable identifiers", Commit 660e947,
Commit 660e947, June 2019, June 2019, <https://github.com/chilts/sid>.
<https://github.com/chilts/sid>.
[Snowflake] [Snowflake]
Twitter, "Snowflake is a network service for generating Twitter, "Snowflake is a network service for generating
unique ID numbers at high scale with some simple unique ID numbers at high scale with some simple
guarantees.", Commit b3f6a3c, May 2014, guarantees.", commit ec40836, May 2014,
<https://github.com/twitter- <https://github.com/twitter-archive/snowflake>.
archive/snowflake/releases/tag/snowflake-2010>.
[Sonyflake] [Sonyflake]
Sony, "A distributed unique ID generator inspired by Sony, "A distributed unique ID generator inspired by
Twitter's Snowflake", Commit 848d664, August 2020, Twitter's Snowflake", commit 848d664, August 2020,
<https://github.com/sony/sonyflake>. <https://github.com/sony/sonyflake>.
[ULID] Feerasta, A., "Universally Unique Lexicographically [ULID] "Universally Unique Lexicographically Sortable
Sortable Identifier", Commit d0c7170, May 2019, Identifier", Commit d0c7170, May 2019,
<https://github.com/ulid/spec>. <https://github.com/ulid/spec>.
[URNNamespaces] [URNNamespaces]
IANA, "Uniform Resource Names (URN) Namespaces", 18 IANA, "Uniform Resource Names (URN) Namespaces",
November 2022, <https://www.iana.org/assignments/urn- <https://www.iana.org/assignments/urn-namespaces/>.
namespaces/urn-namespaces.xhtml>.
[X500] "Information technology – Open Systems Interconnection – [X500] ITU-T, "Information technology - Open Systems
The Directory: Overview of concepts, models and services", Interconnection - The Directory: Overview of concepts,
ISO/IEC 9594-1, ITU-T Rec. X.500, 2019. models and services", ISO/IEC 9594-1, ITU-T
Recommendation X.500, October 2019.
[X660] "Information technology – Procedures for the operation of [X660] ITU-T, "Information technology - Procedures for the
object identifier registration authorities: General operation of object identifier registration authorities:
procedures and top arcs of the international object General procedures and top arcs of the international
identifier tree", ISO/IEC 9834-1, ITU-T Rec. X.660, 2011. object identifier tree", ISO/IEC 9834-1, ITU-T
Recommendation X.660, July 2011.
[X680] "Information Technology - Abstract Syntax Notation One [X680] ITU-T, "Information Technology - Abstract Syntax Notation
(ASN.1) & ASN.1 encoding rules", ISO/IEC 8824-1:2021, One (ASN.1) & ASN.1 encoding rules", ISO/IEC 8824-1:2021,
ITU-T Rec. X.680, 2021. ITU-T Recommendation X.680, February 2021.
[XID] Poitrey, O., "Globally Unique ID Generator", [XID] "Globally Unique ID Generator", commit efa678f, October
Commit efa678f, October 2020, <https://github.com/rs/xid>. 2020, <https://github.com/rs/xid>.
Appendix A. Test Vectors Appendix A. Test Vectors
Both UUIDv1 and UUIDv6 test vectors utilize the same 60 bit Both UUIDv1 and UUIDv6 test vectors utilize the same 60-bit
timestamp: 0x1EC9414C232AB00 (138648505420000000) Tuesday, February timestamp: 0x1EC9414C232AB00 (138648505420000000) Tuesday, February
22, 2022 2:22:22.000000 PM GMT-05:00 22, 2022 2:22:22.000000 PM GMT-05:00.
Both UUIDv1 and UUIDv6 utilize the same values in clock_seq, and Both UUIDv1 and UUIDv6 utilize the same values in clock_seq and node;
node. All of which have been generated with random data. For the all of which have been generated with random data. For the
randomized node, the least significant bit of the first octet is set randomized node, the least significant bit of the first octet is set
to a value of 1 as per Section 6.10. Thus the starting value to a value of 1 as per Section 6.10. Thus, the starting value
0x9E6BDECED846 was changed to 0x9F6BDECED846. 0x9E6BDECED846 was changed to 0x9F6BDECED846.
The pseudocode used for converting from a 64 bit Unix timestamp to a The pseudocode used for converting from a 64-bit Unix timestamp to a
100ns Gregorian timestamp value has been left in the document for 100 ns Gregorian timestamp value has been left in the document for
reference purposes. reference purposes.
# Gregorian to Unix Offset: # Gregorian-to-Unix Offset:
# The number of 100-ns intervals between the # The number of 100 ns intervals between the
# UUID epoch 1582-10-15 00:00:00 # UUID Epoch 1582-10-15 00:00:00
# and the Unix epoch 1970-01-01 00:00:00 # and the Unix Epoch 1970-01-01 00:00:00
# Greg_Unix_offset = 0x01b21dd213814000 or 122192928000000000 # Greg_Unix_offset = 0x01b21dd213814000 or 122192928000000000
# Unix 64 bit Nanosecond Timestamp: # Unix 64-bit Nanosecond Timestamp:
# Unix NS: Tuesday, February 22, 2022 2:22:22 PM GMT-05:00 # Unix NS: Tuesday, February 22, 2022 2:22:22 PM GMT-05:00
# Unix_64_bit_ns = 0x16D6320C3D4DCC00 or 1645557742000000000 # Unix_64_bit_ns = 0x16D6320C3D4DCC00 or 1645557742000000000
# Unix Nanosecond precision to Gregorian 100-nanosecond intervals # Unix Nanosecond precision to Gregorian 100-nanosecond intervals
# Greg_100_ns = (Unix_64_bit_ns/100)+Greg_Unix_offset # Greg_100_ns = (Unix_64_bit_ns/100)+Greg_Unix_offset
# Work: # Work:
# Greg_100_ns = (1645557742000000000/100)+122192928000000000 # Greg_100_ns = (1645557742000000000/100)+122192928000000000
# Unix_64_bit_ns = (138648505420000000-122192928000000000)*100 # Unix_64_bit_ns = (138648505420000000-122192928000000000)*100
# Final: # Final:
# Greg_100_ns = 0x1EC9414C232AB00 or 138648505420000000 # Greg_100_ns = 0x1EC9414C232AB00 or 138648505420000000
Figure 15: Test Vector Timestamp Pseudo-code
Figure 15: Test Vector Timestamp Pseudocode
A.1. Example of a UUIDv1 Value A.1. Example of a UUIDv1 Value
------------------------------------------- -------------------------------------------
field bits value field bits value
------------------------------------------- -------------------------------------------
time_low 32 0xC232AB00 time_low 32 0xC232AB00
time_mid 16 0x9414 time_mid 16 0x9414
ver 4 0x1 ver 4 0x1
time_high 12 0x1EC time_high 12 0x1EC
skipping to change at page 52, line 28 skipping to change at line 2197
------------------------------------------- -------------------------------------------
total 128 total 128
------------------------------------------- -------------------------------------------
final: C232AB00-9414-11EC-B3C8-9F6BDECED846 final: C232AB00-9414-11EC-B3C8-9F6BDECED846
Figure 16: UUIDv1 Example Test Vector Figure 16: UUIDv1 Example Test Vector
A.2. Example of a UUIDv3 Value A.2. Example of a UUIDv3 Value
The MD5 computation from is detailed in Figure 17 using the DNS The MD5 computation from is detailed in Figure 17 using the DNS
Namespace ID value and the Name "www.example.com". while the field Namespace ID value and the Name "www.example.com". The field mapping
mapping and all values are illustrated in Figure 18. Finally to and all values are illustrated in Figure 18. Finally, to further
further illustrate the bit swapping for version and variant see illustrate the bit swapping for version and variant, see Figure 19.
Figure 19.
Namespace (DNS): 6ba7b810-9dad-11d1-80b4-00c04fd430c8 Namespace (DNS): 6ba7b810-9dad-11d1-80b4-00c04fd430c8
Name: www.example.com Name: www.example.com
------------------------------------------------------ ------------------------------------------------------
MD5: 5df418813aed051548a72f4a814cf09e MD5: 5df418813aed051548a72f4a814cf09e
Figure 17: UUIDv3 Example MD5 Figure 17: UUIDv3 Example MD5
------------------------------------------- -------------------------------------------
field bits value field bits value
skipping to change at page 53, line 4 skipping to change at line 2220
------------------------------------------- -------------------------------------------
md5_high 48 0x5df418813aed md5_high 48 0x5df418813aed
ver 4 0x3 ver 4 0x3
md5_mid 12 0x515 md5_mid 12 0x515
var 2 0b10 var 2 0b10
md5_low 62 0b00, 0x8a72f4a814cf09e md5_low 62 0b00, 0x8a72f4a814cf09e
------------------------------------------- -------------------------------------------
total 128 total 128
------------------------------------------- -------------------------------------------
final: 5df41881-3aed-3515-88a7-2f4a814cf09e final: 5df41881-3aed-3515-88a7-2f4a814cf09e
Figure 18: UUIDv3 Example Test Vector Figure 18: UUIDv3 Example Test Vector
MD5 hex and dash: 5df41881-3aed-0515-48a7-2f4a814cf09e MD5 hex and dash: 5df41881-3aed-0515-48a7-2f4a814cf09e
Ver and Var Overwrite: xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx Ver and Var Overwrite: xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx
Final: 5df41881-3aed-3515-88a7-2f4a814cf09e Final: 5df41881-3aed-3515-88a7-2f4a814cf09e
Figure 19: UUIDv3 Example Ver Var bit swaps Figure 19: UUIDv3 Example Ver/Var Bit Swaps
A.3. Example of a UUIDv4 Value A.3. Example of a UUIDv4 Value
This UUIDv4 example was created by generating 16 bytes of random data This UUIDv4 example was created by generating 16 bytes of random data
resulting in the hexadecimal value of resulting in the hexadecimal value of
919108F752D133205BACF847DB4148A8. This is then used to fill out the 919108F752D133205BACF847DB4148A8. This is then used to fill out the
fields as shown in Figure 20. fields as shown in Figure 20.
Finally to further illustrate the bit swapping for version and Finally, to further illustrate the bit swapping for version and
variant see Figure 21. variant, see Figure 21.
------------------------------------------- -------------------------------------------
field bits value field bits value
------------------------------------------- -------------------------------------------
random_a 48 0x919108f752d1 random_a 48 0x919108f752d1
ver 4 0x4 ver 4 0x4
random_b 12 0x320 random_b 12 0x320
var 2 0b10 var 2 0b10
random_c 62 0b01, 0xbacf847db4148a8 random_c 62 0b01, 0xbacf847db4148a8
------------------------------------------- -------------------------------------------
skipping to change at page 53, line 42 skipping to change at line 2259
------------------------------------------- -------------------------------------------
final: 919108f7-52d1-4320-9bac-f847db4148a8 final: 919108f7-52d1-4320-9bac-f847db4148a8
Figure 20: UUIDv4 Example Test Vector Figure 20: UUIDv4 Example Test Vector
Random hex: 919108f752d133205bacf847db4148a8 Random hex: 919108f752d133205bacf847db4148a8
Random hex and dash: 919108f7-52d1-3320-5bac-f847db4148a8 Random hex and dash: 919108f7-52d1-3320-5bac-f847db4148a8
Ver and Var Overwrite: xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx Ver and Var Overwrite: xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx
Final: 919108f7-52d1-4320-9bac-f847db4148a8 Final: 919108f7-52d1-4320-9bac-f847db4148a8
Figure 21: UUIDv4 Example Ver/Var bit swaps Figure 21: UUIDv4 Example Ver/Var Bit Swaps
A.4. Example of a UUIDv5 Value A.4. Example of a UUIDv5 Value
The SHA-1 computation from is detailed in Figure 22 using the DNS The SHA-1 computation form is detailed in Figure 22, using the DNS
Namespace ID value and the Name "www.example.com". while the field Namespace ID value and the Name "www.example.com". The field mapping
mapping and all values are illustrated in Figure 23. Finally to and all values are illustrated in Figure 23. Finally, to further
further illustrate the bit swapping for version and variant and the illustrate the bit swapping for version and variant and the unused/
unused/discarded part of the SHA-1 value see Figure 24. discarded part of the SHA-1 value, see Figure 24.
Namespace (DNS): 6ba7b810-9dad-11d1-80b4-00c04fd430c8 Namespace (DNS): 6ba7b810-9dad-11d1-80b4-00c04fd430c8
Name: www.example.com Name: www.example.com
---------------------------------------------------------- ----------------------------------------------------------
SHA-1: 2ed6657de927468b55e12665a8aea6a22dee3e35 SHA-1: 2ed6657de927468b55e12665a8aea6a22dee3e35
Figure 22: UUIDv5 Example SHA-1 Figure 22: UUIDv5 Example SHA-1
------------------------------------------- -------------------------------------------
field bits value field bits value
skipping to change at page 54, line 32 skipping to change at line 2296
------------------------------------------- -------------------------------------------
final: 2ed6657d-e927-568b-95e1-2665a8aea6a2 final: 2ed6657d-e927-568b-95e1-2665a8aea6a2
Figure 23: UUIDv5 Example Test Vector Figure 23: UUIDv5 Example Test Vector
SHA-1 hex and dash: 2ed6657d-e927-468b-55e1-2665a8aea6a2-2dee3e35 SHA-1 hex and dash: 2ed6657d-e927-468b-55e1-2665a8aea6a2-2dee3e35
Ver and Var Overwrite: xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx Ver and Var Overwrite: xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx
Final: 2ed6657d-e927-568b-95e1-2665a8aea6a2 Final: 2ed6657d-e927-568b-95e1-2665a8aea6a2
Discarded: -2dee3e35 Discarded: -2dee3e35
Figure 24: UUIDv5 Example Ver/Var bit swaps and discarded SHA-1 Figure 24: UUIDv5 Example Ver/Var Bit Swaps and Discarded SHA-1
segment Segment
A.5. Example of a UUIDv6 Value A.5. Example of a UUIDv6 Value
------------------------------------------- -------------------------------------------
field bits value field bits value
------------------------------------------- -------------------------------------------
time_high 32 0x1EC9414C time_high 32 0x1EC9414C
time_mid 16 0x232A time_mid 16 0x232A
ver 4 0x6 ver 4 0x6
time_high 12 0xB00 time_high 12 0xB00
skipping to change at page 55, line 7 skipping to change at line 2320
node 48 0x9F6BDECED846 node 48 0x9F6BDECED846
------------------------------------------- -------------------------------------------
total 128 total 128
------------------------------------------- -------------------------------------------
final: 1EC9414C-232A-6B00-B3C8-9F6BDECED846 final: 1EC9414C-232A-6B00-B3C8-9F6BDECED846
Figure 25: UUIDv6 Example Test Vector Figure 25: UUIDv6 Example Test Vector
A.6. Example of a UUIDv7 Value A.6. Example of a UUIDv7 Value
This example UUIDv7 test vector utilizes a well-known Unix epoch This example UUIDv7 test vector utilizes a well-known Unix Epoch
timestamp with millisecond precision to fill the first 48 bits. timestamp with millisecond precision to fill the first 48 bits.
rand_a and rand_b are filled with random data. rand_a and rand_b are filled with random data.
The timestamp is Tuesday, February 22, 2022 2:22:22.00 PM GMT-05:00 The timestamp is Tuesday, February 22, 2022 2:22:22.00 PM GMT-05:00,
represented as 0x017F22E279B0 or 1645557742000 represented as 0x017F22E279B0 or 1645557742000.
------------------------------------------- -------------------------------------------
field bits value field bits value
------------------------------------------- -------------------------------------------
unix_ts_ms 48 0x017F22E279B0 unix_ts_ms 48 0x017F22E279B0
ver 4 0x7 ver 4 0x7
rand_a 12 0xCC3 rand_a 12 0xCC3
var 2 0b10 var 2 0b10
rand_b 62 0b01, 0x8C4DC0C0C07398F rand_b 62 0b01, 0x8C4DC0C0C07398F
------------------------------------------- -------------------------------------------
total 128 total 128
------------------------------------------- -------------------------------------------
final: 017F22E2-79B0-7CC3-98C4-DC0C0C07398F final: 017F22E2-79B0-7CC3-98C4-DC0C0C07398F
Figure 26: UUIDv7 Example Test Vector Figure 26: UUIDv7 Example Test Vector
Appendix B. Illustrative Examples Appendix B. Illustrative Examples
The following sections contain illustrative examples which serve to The following sections contain illustrative examples that serve to
show how one may use UUIDv8 Section 5.8 for custom and/or show how one may use UUIDv8 (Section 5.8) for custom and/or
experimental application based logic. The examples below have not experimental application-based logic. The examples below have not
been through the same rigorous testing, prototyping, and feedback been through the same rigorous testing, prototyping, and feedback
loop that other algorithms in this document have undergone. The loop that other algorithms in this document have undergone. The
authors encouraged implementors to create your own UUIDv8 algorithm authors encourage implementers to create their own UUIDv8 algorithm
rather than use the items defined in this section. rather than use the items defined in this section.
B.1. Example of a UUIDv8 Value (time-based) B.1. Example of a UUIDv8 Value (Time-Based)
This example UUIDv8 test vector utilizes a well-known 64 bit Unix This example UUIDv8 test vector utilizes a well-known 64-bit Unix
epoch timestamp with 10ns precision, truncated to the least- Epoch timestamp with 10 ns precision, truncated to the least
significant, right-most, bits to fill the first 60 bits of custom_a significant, rightmost bits to fill the first 60 bits of custom_a and
and custom_b while setting the version bits between these two custom_b, while setting the version bits between these two segments
segments to the version value of 8. to the version value of 8.
The variant bits are set and the final segment, custom_c, is filled The variant bits are set; and the final segment, custom_c, is filled
with random data. with random data.
Timestamp is Tuesday, February 22, 2022 2:22:22.000000 PM GMT-05:00 Timestamp is Tuesday, February 22, 2022 2:22:22.000000 PM GMT-05:00,
represented as 0x2489E9AD2EE2E00 or 164555774200000000 (10ns-steps). represented as 0x2489E9AD2EE2E00 or 164555774200000000 (10 ns-steps).
------------------------------------------- -------------------------------------------
field bits value field bits value
------------------------------------------- -------------------------------------------
custom_a 48 0x2489E9AD2EE2 custom_a 48 0x2489E9AD2EE2
ver 4 0x8 ver 4 0x8
custom_b 12 0xE00 custom_b 12 0xE00
var 2 0b10 var 2 0b10
custom_c 62 0b00, 0xEC932D5F69181C0 custom_c 62 0b00, 0xEC932D5F69181C0
------------------------------------------- -------------------------------------------
total 128 total 128
------------------------------------------- -------------------------------------------
final: 2489E9AD-2EE2-8E00-8EC9-32D5F69181C0 final: 2489E9AD-2EE2-8E00-8EC9-32D5F69181C0
Figure 27: UUIDv8 Example Time-based Illustrative Example Figure 27: UUIDv8 Example Time-Based Illustrative Example
B.2. Example of a UUIDv8 Value (name-based) B.2. Example of a UUIDv8 Value (Name-Based)
As per Section 5.5 name-based UUIDs that desire to use modern hashing As per Section 5.5, name-based UUIDs that want to use modern hashing
algorithms MUST be created within the UUIDv8 space. These MAY algorithms MUST be created within the UUIDv8 space. These MAY
leverage newer hashing algorithms such as SHA-256 or SHA-512 defined leverage newer hashing algorithms such as SHA-256 or SHA-512 (as
by [FIPS180-4], SHA-3 or SHAKE defined by [FIPS202], or even defined by [FIPS180-4]), SHA-3 or SHAKE (as defined by [FIPS202]), or
algorithms that have not been defined yet. even algorithms that have not been defined yet.
A SHA-256 version of Appendix A.4 is detailed in Figure 28 as an A SHA-256 version of the SHA-1 computation in Appendix A.4 is
illustrative example detailing how this can be achieved. The detailed in Figure 28 as an illustrative example detailing how this
creation of the name-based UUIDv8 value in this section follows the can be achieved. The creation of the name-based UUIDv8 value in this
same logic defined in Section 5.5 with the difference being SHA-256 section follows the same logic defined in Section 5.5 with the
in place of SHA-1. difference being SHA-256 in place of SHA-1.
The field mapping and all values are illustrated in Figure 29. The field mapping and all values are illustrated in Figure 29.
Finally to further illustrate the bit swapping for version and Finally, to further illustrate the bit swapping for version and
variant and the unused/discarded part of the SHA-256 value see variant and the unused/discarded part of the SHA-256 value, see
Figure 30. An important note for secure hashing algorithms that Figure 30. An important note for secure hashing algorithms that
produce outputs of an arbitrary size, such as those found in SHAKE, produce outputs of an arbitrary size, such as those found in SHAKE,
the output hash MUST be 128 bits or larger. is that the output hash MUST be 128 bits or larger.
Namespace (DNS): 6ba7b810-9dad-11d1-80b4-00c04fd430c8 Namespace (DNS): 6ba7b810-9dad-11d1-80b4-00c04fd430c8
Name: www.example.com Name: www.example.com
---------------------------------------------------------------- ----------------------------------------------------------------
SHA-256: SHA-256:
5c146b143c524afd938a375d0df1fbf6fe12a66b645f72f6158759387e51f3c8 5c146b143c524afd938a375d0df1fbf6fe12a66b645f72f6158759387e51f3c8
Figure 28: UUIDv8 Example SHA256 Figure 28: UUIDv8 Example SHA256
------------------------------------------- -------------------------------------------
skipping to change at page 57, line 25 skipping to change at line 2431
------------------------------------------- -------------------------------------------
final: 5c146b14-3c52-8afd-938a-375d0df1fbf6 final: 5c146b14-3c52-8afd-938a-375d0df1fbf6
Figure 29: UUIDv8 Example Name-Based SHA-256 Illustrative Example Figure 29: UUIDv8 Example Name-Based SHA-256 Illustrative Example
A: 5c146b14-3c52-4afd-938a-375d0df1fbf6-fe12a66b645f72f6158759387e51f3c8 A: 5c146b14-3c52-4afd-938a-375d0df1fbf6-fe12a66b645f72f6158759387e51f3c8
B: xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx B: xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx
C: 5c146b14-3c52-8afd-938a-375d0df1fbf6 C: 5c146b14-3c52-8afd-938a-375d0df1fbf6
D: -fe12a66b645f72f6158759387e51f3c8 D: -fe12a66b645f72f6158759387e51f3c8
Figure 30: UUIDv8 Example Ver/Var bit swaps and discarded SHA-256 Figure 30: UUIDv8 Example Ver/Var Bit Swaps and Discarded SHA-256
segment Segment
Examining Figure 30: Examining Figure 30:
* Line A details the full SHA-256 as a hexadecimal value with the * Line A details the full SHA-256 as a hexadecimal value with the
dashes inserted. dashes inserted.
* Line B details the version and variant hexadecimal positions which
must be overwritten. * Line B details the version and variant hexadecimal positions,
* Line C details the final value after the ver/var have been which must be overwritten.
* Line C details the final value after the ver and var have been
overwritten. overwritten.
* Line D details the discarded, leftover values from the original
* Line D details the discarded leftover values from the original
SHA-256 computation. SHA-256 computation.
Acknowledgements
The authors gratefully acknowledge the contributions of Rich Salz,
Michael Mealling, Ben Campbell, Ben Ramsey, Fabio Lima, Gonzalo
Salgueiro, Martin Thomson, Murray S. Kucherawy, Rick van Rein, Rob
Wilton, Sean Leonard, Theodore Y. Ts'o, Robert Kieffer, Sergey
Prokhorenko, and LiosK.
As well as all of those in the IETF community and on GitHub to who
contributed to the discussions that resulted in this document.
This document draws heavily on the OSF DCE specification (Appendix A
of [C309]) for UUIDs. Ted Ts'o provided helpful comments.
We are also grateful to the careful reading and bit-twiddling of Ralf
S. Engelschall, John Larmouth, and Paul Thorpe. Professor Larmouth
was also invaluable in achieving coordination with ISO/IEC.
Authors' Addresses Authors' Addresses
Kyzer R. Davis Kyzer R. Davis
Cisco Systems Cisco Systems
Email: kydavis@cisco.com Email: kydavis@cisco.com
Brad G. Peabody Brad G. Peabody
Uncloud Uncloud
Email: brad@peabody.io Email: brad@peabody.io
 End of changes. 343 change blocks. 
1176 lines changed or deleted 997 lines changed or added

This html diff was produced by rfcdiff 1.48.