RFC 9562 - Universally Unique IDentifiers (UUIDs) Light Dark Auto RFC 9562 Proposed Standard Title Universally Unique IDentifiers (UUIDs) Document Document type RFC - Proposed Standard May 2024 View errata Report errata IPR Obsoletes RFC 4122 Was draft-ietf-uuidrev-rfc4122bis (uuidrev WG) Select version 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 RFC 9562 Compare versions RFC 9562 draft-ietf-uuidrev-rfc4122bis-14 draft-ietf-uuidrev-rfc4122bis-13 draft-ietf-uuidrev-rfc4122bis-12 draft-ietf-uuidrev-rfc4122bis-11 draft-ietf-uuidrev-rfc4122bis-10 draft-ietf-uuidrev-rfc4122bis-09 draft-ietf-uuidrev-rfc4122bis-08 draft-ietf-uuidrev-rfc4122bis-07 draft-ietf-uuidrev-rfc4122bis-06 draft-ietf-uuidrev-rfc4122bis-05 draft-ietf-uuidrev-rfc4122bis-04 draft-ietf-uuidrev-rfc4122bis-03 draft-ietf-uuidrev-rfc4122bis-02 draft-ietf-uuidrev-rfc4122bis-01 draft-ietf-uuidrev-rfc4122bis-00 RFC 9562 draft-ietf-uuidrev-rfc4122bis-14 draft-ietf-uuidrev-rfc4122bis-13 draft-ietf-uuidrev-rfc4122bis-12 draft-ietf-uuidrev-rfc4122bis-11 draft-ietf-uuidrev-rfc4122bis-10 draft-ietf-uuidrev-rfc4122bis-09 draft-ietf-uuidrev-rfc4122bis-08 draft-ietf-uuidrev-rfc4122bis-07 draft-ietf-uuidrev-rfc4122bis-06 draft-ietf-uuidrev-rfc4122bis-05 draft-ietf-uuidrev-rfc4122bis-04 draft-ietf-uuidrev-rfc4122bis-03 draft-ietf-uuidrev-rfc4122bis-02 draft-ietf-uuidrev-rfc4122bis-01 draft-ietf-uuidrev-rfc4122bis-00 Side-by-side Inline Authors K. Davis , B. Peabody , P. Leach Email authors RFC stream Other formats txt html xml pdf w/errata bibtex Additional resources Mailing list discussion Report a bug RFC 9562 UUIDs May 2024 Davis, et al. Standards Track [Page] Stream: Internet Engineering Task Force (IETF) RFC: 9562 Obsoletes: 4122 Category: Standards Track Published: May 2024 ISSN: 2070-1721 Authors: K. Davis Cisco Systems B. Peabody Uncloud P. Leach University of Washington RFC 9562 Universally Unique IDentifiers (UUIDs) Abstract This specification defines UUIDs (Universally Unique IDentifiers) -- also known as GUIDs (Globally Unique IDentifiers) -- and a Uniform Resource Name namespace for UUIDs. A UUID is 128 bits long and is intended to guarantee uniqueness across space and time. UUIDs were originally used in the Apollo Network Computing System (NCS), later in the Open Software Foundation's (OSF's) Distributed Computing Environment (DCE), and then in Microsoft Windows platforms.¶ This specification is derived from the OSF DCE specification with the kind permission of the OSF (now known as "The Open Group"). Information from earlier versions of the OSF DCE specification have been incorporated into this document. This document obsoletes RFC 4122.¶ Status of This Memo This is an Internet Standards Track document.¶ This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.¶ 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 (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.¶ This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶ ▲ Table of Contents 1.  Introduction 2.  Motivation 2.1.  Update Motivation 3.  Terminology 3.1.  Requirements Language 3.2.  Abbreviations 4.  UUID Format 4.1.  Variant Field 4.2.  Version Field 5.  UUID Layouts 5.1.  UUID Version 1 5.2.  UUID Version 2 5.3.  UUID Version 3 5.4.  UUID Version 4 5.5.  UUID Version 5 5.6.  UUID Version 6 5.7.  UUID Version 7 5.8.  UUID Version 8 5.9.  Nil UUID 5.10. Max UUID 6.  UUID Best Practices 6.1.  Timestamp Considerations 6.2.  Monotonicity and Counters 6.3.  UUID Generator States 6.4.  Distributed UUID Generation 6.5.  Name-Based UUID Generation 6.6.  Namespace ID Usage and Allocation 6.7.  Collision Resistance 6.8.  Global and Local Uniqueness 6.9.  Unguessability 6.10. UUIDs That Do Not Identify the Host 6.11. Sorting 6.12. Opacity 6.13. DBMS and Database Considerations 7.  IANA Considerations 7.1.  IANA UUID Subtype Registry and Registration 7.2.  IANA UUID Namespace ID Registry and Registration 8.  Security Considerations 9.  References 9.1.  Normative References 9.2.  Informative References Appendix A.  Test Vectors A.1.  Example of a UUIDv1 Value A.2.  Example of a UUIDv3 Value A.3.  Example of a UUIDv4 Value A.4.  Example of a UUIDv5 Value A.5.  Example of a UUIDv6 Value A.6.  Example of a UUIDv7 Value Appendix B.  Illustrative Examples B.1.  Example of a UUIDv8 Value (Time-Based) B.2.  Example of a UUIDv8 Value (Name-Based) Acknowledgements Authors' Addresses 1. Introduction This specification defines a Uniform Resource Name namespace for Universally Unique IDentifiers (UUIDs), also known as Globally Unique IDentifiers (GUIDs). A UUID is 128 bits long and requires no central registration process.¶ The use of UUIDs is extremely pervasive in computing. They comprise the core identifier infrastructure for many operating systems such as Microsoft Windows and applications such as the Mozilla Web browser; in many cases, they can become exposed in many non-standard ways.¶ This specification attempts to standardize that practice as openly as 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 to implement services using UUIDs either in combination with URNs [RFC8141] or otherwise.¶ There is an ITU-T Recommendation and an ISO/IEC Standard [X667] that are derived from [RFC4122]. Both sets of specifications have been aligned and are fully technically compatible. Nothing in this document should be construed to override the DCE standards that defined UUIDs.¶ 2. Motivation One of the main reasons for using UUIDs is that no centralized authority is required to administer them (although two formats may leverage optional IEEE 802 Node IDs, others do not). As a result, generation on demand can be completely automated and used for a variety of purposes. The UUID generation algorithm described here supports very high allocation rates of 10 million per second per machine or more, if necessary, so that they could even be used as transaction IDs.¶ UUIDs are of a fixed size (128 bits), which is reasonably small compared to other alternatives. This lends itself well to sorting, ordering, and hashing of all sorts; storing in databases; simple allocation; and ease of programming in general.¶ Since UUIDs are unique and persistent, they make excellent URNs. The unique ability to generate a new UUID without a registration process allows for UUIDs to be one of the URNs with the lowest minting cost.¶ 2.1. Update Motivation Many things have changed in the time since UUIDs were originally created. Modern applications have a need to create and utilize UUIDs as the primary identifier for a variety of different items in complex computational systems, including but not limited to database keys, file names, machine or system names, and identifiers for event-driven transactions.¶ One area in which UUIDs have gained popularity is database keys. This stems from the increasingly distributed nature of modern applications. In such cases, "auto-increment" schemes that are often used by databases do not work well: the effort required to coordinate sequential numeric identifiers across a network can easily become a burden. The fact that UUIDs can be used to create unique, reasonably short values in distributed systems without requiring coordination makes them a good alternative, but UUID versions 1-5, which were originally defined by [RFC4122], lack certain other desirable characteristics, such as:¶ UUID versions that are not time ordered, such as UUIDv4 (described in Section 5.4), have poor database-index locality. This means that new values created in succession are not close to each other in the index; thus, they require inserts to be performed at random locations. The resulting negative performance effects on the common structures used for this (B-tree and its variants) can be dramatic.¶ The 100-nanosecond Gregorian Epoch used in UUIDv1 timestamps (described in Section 5.1) is uncommon and difficult to represent accurately using a standard number format such as that described in [IEEE754].¶ Introspection/parsing is required to order by time sequence, as opposed to being able to perform a simple byte-by-byte comparison.¶ Privacy and network security issues arise from using a Media Access Control (MAC) address in the node field of UUIDv1. Exposed MAC addresses can be used as an attack surface to locate network interfaces and reveal various other information about such machines (minimally, the manufacturer and, potentially, other details). Additionally, with the advent of virtual machines and containers, uniqueness of the MAC address is no longer guaranteed.¶ Many of the implementation details specified in [RFC4122] involved trade-offs that are neither possible to specify for all applications nor necessary to produce interoperable implementations.¶ [RFC4122] did not distinguish between the requirements for generating a UUID and those for simply storing one, although they are often different.¶ Due to the aforementioned issues, many widely distributed database applications and large application vendors have sought to solve the problem of creating a better time-based, sortable unique identifier for use as a database key. This has led to numerous implementations over the past 10+ years solving the same problem in slightly different ways.¶ While preparing this specification, the following 16 different implementations were analyzed for trends in total ID length, bit layout, lexical formatting and encoding, timestamp type, timestamp format, timestamp accuracy, node format and components, collision handling, and multi-timestamp tick generation sequencing:¶ [ULID]¶ [LexicalUUID]¶ [Snowflake]¶ [Flake]¶ [ShardingID]¶ [KSUID]¶ [Elasticflake]¶ [FlakeID]¶ [Sonyflake]¶ [orderedUuid]¶ [COMBGUID]¶ [SID]¶ [pushID]¶ [XID]¶ [ObjectID]¶ [CUID]¶ An inspection of these implementations and the issues described above has led to this document, in which new UUIDs are adapted to address these issues.¶ Further, [RFC4122] itself was in need of an overhaul to address a number of topics such as, but not limited to, the following:¶ Implementation of miscellaneous errata reports. Mostly around bit-layout clarifications, which lead to inconsistent implementations [Err1957], [Err3546], [Err4975], [Err4976], [Err5560], etc.¶ Decoupling other UUID versions from the UUIDv1 bit layout so that fields like "time_hi_and_version" do not need to be referenced within a UUID that is not time based while also providing definition sections similar to that for UUIDv1 for UUIDv3, UUIDv4, and UUIDv5.¶ Providing implementation best practices around many real-world scenarios and corner cases observed by existing and prototype implementations.¶ Addressing security best practices and considerations for the modern age as it pertains to MAC addresses, hashing algorithms, secure randomness, and other topics.¶ Providing implementations a standard-based option for implementation-specific and/or experimental UUID designs.¶ P…