uuidrev

Internet Engineering Task Force (IETF)                          K. R. Davis
Internet-Draft
Request for Comments: 9562                                 Cisco Systems
Obsoletes: 4122 (if approved)                                               B. G. Peabody
Intended status:
Category: Standards Track                                        Uncloud
Expires: 9 May 2024
ISSN: 2070-1721                                                 P. Leach
                                                University of Washington
                                                         6 November 2023
                                                                May 2024

                 Universally Unique IDentifiers (UUID)
                    draft-ietf-uuidrev-rfc4122bis-14 (UUIDs)

Abstract

   This specification defines the UUIDs (Universally Unique IDentifiers)
   (also known as Globally Unique IDentifiers (GUIDs)) and the UUID a Uniform
   Resource Name (URN) namespace.  UUIDs are also
   known as GUIDs (Globally Unique IDentifiers). 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 and (NCS), later
   in the Open Software Foundation's (OSF) (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 "The Open Group). Group").
   Information from earlier versions of the OSF DCE specification have
   been incorporated into this document.  This document obsoletes RFC4122. RFC
   4122.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list  It represents the consensus of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid the IETF community.  It has
   received public review and has been approved for a maximum 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 six months this document, any errata,
   and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 9 May 2024.
   https://www.rfc-editor.org/info/rfc9562.

Copyright Notice

   Copyright (c) 2023 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)
   (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  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Motivation  . . . . . . . . . . . . . . . . . . . . . . . . .   4
     2.1.  Update Motivation . . . . . . . . . . . . . . . . . . . .   4
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   6
     3.1.  Requirements Language . . . . . . . . . . . . . . . . . .   6
     3.2.  Abbreviations . . . . . . . . . . . . . . . . . . . . . .   7
     3.3.  Changelog . . . . . . . . . . . . . . . . . . . . . . . .   8
   4.  UUID Format . . . . . . . . . . . . . . . . . . . . . . . . .  12
     4.1.  Variant Field . . . . . . . . . . . . . . . . . . . . . .  14
     4.2.  Version Field . . . . . . . . . . . . . . . . . . . . . .  15
   5.  UUID Layouts  . . . . . . . . . . . . . . . . . . . . . . . .  17
     5.1.  UUID Version 1  . . . . . . . . . . . . . . . . . . . . .  17
     5.2.  UUID Version 2  . . . . . . . . . . . . . . . . . . . . .  19
     5.3.  UUID Version 3  . . . . . . . . . . . . . . . . . . . . .  19
     5.4.  UUID Version 4  . . . . . . . . . . . . . . . . . . . . .  20
     5.5.  UUID Version 5  . . . . . . . . . . . . . . . . . . . . .  21
     5.6.  UUID Version 6  . . . . . . . . . . . . . . . . . . . . .  23
     5.7.  UUID Version 7  . . . . . . . . . . . . . . . . . . . . .  25
     5.8.  UUID Version 8  . . . . . . . . . . . . . . . . . . . . .  26
     5.9.  Nil UUID  . . . . . . . . . . . . . . . . . . . . . . . .  27
     5.10. Max UUID  . . . . . . . . . . . . . . . . . . . . . . . .  28
   6.  UUID Best Practices . . . . . . . . . . . . . . . . . . . . .  28
     6.1.  Timestamp Considerations  . . . . . . . . . . . . . . . .  28
     6.2.  Monotonicity and Counters . . . . . . . . . . . . . . . .  30
     6.3.  UUID Generator States . . . . . . . . . . . . . . . . . .  34
     6.4.  Distributed UUID Generation . . . . . . . . . . . . . . .  35
     6.5.  Name-Based UUID Generation  . . . . . . . . . . . . . . .  36
     6.6.  Namespace ID Usage and Allocation . . . . . . . . . . . .  37
     6.7.  Collision Resistance  . . . . . . . . . . . . . . . . . .  39
     6.8.  Global and Local Uniqueness . . . . . . . . . . . . . . .  40
     6.9.  Unguessability  . . . . . . . . . . . . . . . . . . . . .  40
     6.10. UUIDs That Do Not Identify the Host . . . . . . . . . . .  40
     6.11. Sorting . . . . . . . . . . . . . . . . . . . . . . . . .  41
     6.12. Opacity . . . . . . . . . . . . . . . . . . . . . . . . .  42
     6.13. DBMS and Database Considerations  . . . . . . . . . . . .  42
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  43
     7.1.  IANA UUID Subtype Registry and Registration . . . . . . .  43
     7.2.  IANA UUID Namespace ID Registry and Registration  . . . .  45
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  45
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  46
   10.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  46
     10.1.
     9.1.  Normative References . . . . . . . . . . . . . . . . . .  46
     10.2.
     9.2.  Informative References . . . . . . . . . . . . . . . . .  47
   Appendix A.  Test Vectors . . . . . . . . . . . . . . . . . . . .  51
     A.1.  Example of a UUIDv1 Value . . . . . . . . . . . . . . . .  52
     A.2.  Example of a UUIDv3 Value . . . . . . . . . . . . . . . .  52
     A.3.  Example of a UUIDv4 Value . . . . . . . . . . . . . . . .  53
     A.4.  Example of a UUIDv5 Value . . . . . . . . . . . . . . . .  53
     A.5.  Example of a UUIDv6 Value . . . . . . . . . . . . . . . .  54
     A.6.  Example of a UUIDv7 Value . . . . . . . . . . . . . . . .  55
   Appendix B.  Illustrative Examples  . . . . . . . . . . . . . . .  55
     B.1.  Example of a UUIDv8 Value (time-based)  . . . . . . . . .  55 (Time-Based)
     B.2.  Example of a UUIDv8 Value (name-based)  . . . . . . . . .  56 (Name-Based)
   Acknowledgements
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  57

1.  Introduction

   This specification defines the UUIDs (Universally Unique IDentifiers)
   and the UUID a Uniform Resource Name (URN) namespace.  UUIDs are also namespace for
   Universally Unique IDentifiers (UUIDs) (also known as GUIDs (Globally Globally Unique IDentifiers).
   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
   and 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 identifiers, 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 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, sorts; storing in databases, databases; simple
   allocation,
   allocation; and ease of programming in general.

   Since UUIDs are unique and persistent, they make excellent Uniform
   Resource Names. 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" "auto-increment" schemes that are often
   used by databases do not work well, as 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:
   characteristics, such as:

   1.  Non-time-ordered  UUID versions that are not time ordered, such as UUIDv4
       (described in Section 5.4) 5.4), have poor database index database-index locality.
       This means that new values created in succession are not close to
       each other in the index and thus 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.

   2.  The 100-nanosecond Gregorian epoch Epoch used in UUIDv1 timestamps
       (described in Section 5.1) timestamps is uncommon and difficult to represent
       accurately using a standard number format such as that described
       in [IEEE754].

   3.  Introspection/parsing is required to order by time sequence, as
       opposed to being able to perform a simple byte-by-byte
       comparison.

   4.  Privacy and network security issues arise from using a MAC Media
       Access Control (MAC) address in the node field of UUID version 1. UUIDv1.
       Exposed MAC addresses can be used as an attack surface to locate
       network interfaces and reveal various other information about
       such machines (minimally manufacturer, potentially (minimally, the manufacturer and, potentially,
       other details).  Additionally, with the advent of virtual
       machines and containers, uniqueness of the MAC address uniqueness is no
       longer guaranteed.

   5.  Many of the implementation details specified in [RFC4122]
       involved trade offs trade-offs that are neither possible to specify for all
       applications nor necessary to produce interoperable
       implementations.

   6.  [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/encoding, formatting and encoding, timestamp type, timestamp
   format, timestamp accuracy, node format/components, format and components, collision
   handling, and multi-timestamp tick generation sequencing:

   1.   [ULID] by A.  Feerasta
   2.   [LexicalUUID] by Twitter
   3.   [Snowflake] by Twitter
   4.   [Flake] by Boundary
   5.   [ShardingID] by Instagram
   6.   [KSUID] by Segment
   7.   [Elasticflake] by P.  Pearcy
   8.   [FlakeID] by T.  Pawlak
   9.   [Sonyflake] by Sony
   10.  [orderedUuid] by IT.  Cabrera
   11.  [COMBGUID] by R.  Tallent
   12.  [SID] by A.  Chilton
   13.  [pushID] by Google
   14.  [XID] by O.  Poitrey
   15.  [ObjectID] by MongoDB
   16.  [CUID] by E.  Elliott

   An inspection of these implementations and the issues described above
   has led to this document document, in which intends to adapt 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 as, but not limited to to, the following:

   1.  Miscellaneous erratas.  Implementation of miscellaneous errata reports.  Mostly around bit layout clarifications
       bit-layout clarifications, which lead to inconsistent implementations.
       implementations [Err1957], [Err3546], [Err4975], [Err4976],
       [Err5560], etc.

   2.  Decouple  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 non-time-based UUID that is not time based while also providing "UUIDv1 like"
       definition sections similar to that for UUIDv1 for UUIDv3,
       UUIDv4, and UUIDv5.

   3.  Provide  Providing implementation best practices around many real-world
       scenarios and corner cases observed by existing and prototype
       implementations.

   4.  Update the document to address  Addressing security best practices and considerations for the
       modern age as it pertains to MAC addresses, hashing algorithms,
       secure randomness, and other topics.

   5.  Provide  Providing implementations a standard-based option for
       implementation specific
       implementation-specific and/or experimental UUID designs.

   6.  Provide  Providing more test vectors that illustrate real UUIDs created as
       per the specification.

3.  Terminology

3.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

3.2.  Abbreviations

   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

   CSPRNG        Cryptographically Secure Pseudo-Random Pseudorandom Number Generator

   MAC           Media Access Control

   MSB           Most Significant Bit

   DBMS          Database Management System

   IEEE          Institute of Electrical and Electronics Engineers, Inc. Engineers

   ITU           International Telecommunication Union

   MAC           Media Access Control

   MD5           Message Digest 5

   MSB           Most Significant Bit

   OID           Object Identifier

   SHA           Secure Hash Algorithm

   SHA-1         Secure Hash Algorithm 1 with (with message digest of 160 bits
                 bits)

   SHA-3         Secure Hash Algorithm 3 (arbitrary size)

   SHA-224       Secure Hash Algorithm 2 with message digest size of 224
                 bits

   SHA-256       Secure Hash Algorithm 2 with message digest size of 256
                 bits

   SHA-512       Secure Hash Algorithm 2 with message digest size of 512
                 bits

   SHA-3         Secure Hash Algorithm 3

   SHAKE         Secure Hash Algorithm 3 based on the KECCAK algorithm

   URN           Uniform Resource Names

   UTC           Coordinated Universal Time

   OID           Object 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
   draft-06

   *  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
   *  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          Universally Unique Identifier

   UUIDv1        Universally Unique Identifier version 1

   UUIDv2        Universally Unique Identifier version construct is for the variant
      in this doc #83
   *  Provided further clarification for local/global bit vs multicast
      bit #83

   draft-03

   *  Revised IANA Considerations #71
   *  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

   *  Change md5_high in SHA-1 section to sha1_mid #59
   *  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

   *  Mixed Case Spelling error #18
   *  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

   UUIDv3        Universally Unique Identifier version 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

   UUIDv4        Universally Unique Identifier 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

   UUIDv5        Universally Unique Identifier version 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
   *  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        Universally Unique Identifier version 6

   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        Universally Unique Identifier version 7

   UUIDv8        Universally Unique Identifier version 8

4.  UUID Format

   The UUID format is 16 octets (128 bits) in size; the variant bits in
   conjunction with the version bits described in the next sections
   determine finer structure.  While discussing  In terms of these UUID formats and
   layout, bit definitions start at 0 and end at 127 127, while octet
   definitions start at 0 and end at 15.

   In the absence of explicit application or presentation protocol
   specification to the contrary, each field is encoded with the Most
   Significant Byte most
   significant byte first (known as network "network byte order). order").

   Saving UUIDs to binary format is done by sequencing all fields in
   big-endian format.  However  However, there is a known caveat that Microsoft's
   Component Object Model (COM) GUIDs leverage little-endian when saving
   GUIDs.  The discussion of this [MS_COM_GUID] (see [MS_COM_GUID]) is outside the
   scope of this specification.

   UUIDs MAY be represented as binary data or integers.  When in use
   with URNs or as text in applications, any given UUID should be
   represented by the "hex-and-dash" string format consisting of
   multiple groups of upper uppercase or lowercase alphanumeric hexadecimal
   characters separated by single dashes/hyphens.  When used with
   databases
   databases, please refer to Section 6.13.

   The formal definition of the UUID string representation is provided
   by the following (ABNF) [RFC5234]. ABNF [RFC5234]:

   UUID     = 4hexOctet "-"
              2hexOctet "-"
              2hexOctet "-"
              2hexOctet "-"
              6hexOctet
   hexOctet = HEXDIG HEXDIG
   DIGIT    = %x30-39
   HEXDIG   = DIGIT / "A" / "B" / "C" / "D" / "E" / "F"

   Note that the alphabetic characters may be all uppercase, all
   lowercase, or mixed case, as per [RFC5234], Section 2.3. 2.3 of [RFC5234].  An
   example UUID using this textual representation from the above ABNF is
   shown in Figure 1.

   f81d4fae-7dec-11d0-a765-00a0c91e6bf6

                    Figure 1: Example String UUID format Format

   The same UUID from Figure 1 is represented in Binary binary (Figure 2),
   Unsigned Integer as
   an unsigned integer (Figure 3) 3), and as a URN (Figure 4) defined by
   [RFC8141].

   111110000001110101001111101011100111110111101100000100011101000\
   01010011101100101000000001010000011001001000111100110101111110110

                       Figure 2: Example Binary UUID

   329800735698586629295641978511506172918

    Figure 3: Example Unsigned Integer UUID (shown (Shown as a decimal number) Decimal Number)

   urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6

                  Figure 4: Example URN Namespace for UUID

   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
   is only provided for informational purposes.

   *  Some UUID implementations, such as those found in [Python] and
      [Microsoft], will output UUID with the string format, including
      dashes, enclosed in curly braces.

   *  [X667] provides UUID format definitions for use of UUID with an
      OID.

   *  The legacy  [IBM_NCS] is a legacy implementation that produces a unique UUID
      format compatible with Variant 0xx of Table 1.

4.1.  Variant Field

   The variant field determines the layout of the UUID.  That is, the
   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
   be called a type "type" field; we retain the original term for
   compatibility.  The variant field consists of a variable number of
   the most significant bits of octet 8 of the UUID.

   Table 1 lists the contents of the variant field, where the letter "x"
   indicates a "don't-care" value.

     +======+======+======+======+=========+========================+

     +======+======+======+======+=========+=========================+
     | Msb0 MSB0 | Msb1 MSB1 | Msb2 MSB2 | Msb3 MSB3 | Variant | Description             |
     +======+======+======+======+=========+========================+
     +======+======+======+======+=========+=========================+
     | 0    | x    | x    | x    | 1-7     | Reserved, NCS backward Reserved.  Network      |
     |      |      |      |      |         | compatibility and Computing System (NCS)  |
     |      |      |      |      |         | backward compatibility, |
     |      |      |      |      |         | and includes Nil UUID as   |
     |      |      |      |      |         | as per Section 5.9.     |
     +------+------+------+------+---------+------------------------+
     +------+------+------+------+---------+-------------------------+
     | 1    | 0    | x    | x    | 8-9,A-B | The variant specified   |
     |      |      |      |      |         | in this document.       |
     +------+------+------+------+---------+------------------------+
     +------+------+------+------+---------+-------------------------+
     | 1    | 1    | 0    | x    | C-D     | Reserved, Reserved.  Microsoft    |
     |      |      |      |      |         | Corporation backward    |
     |      |      |      |      |         | compatibility.          |
     +------+------+------+------+---------+------------------------+
     +------+------+------+------+---------+-------------------------+
     | 1    | 1    | 1    | x    | E-F     | Reserved for future     |
     |      |      |      |      |         | definition and includes |
     |      |      |      |      |         | includes Max UUID as per         |
     |      |      |      |      |         | per Section 5.10.           |
     +------+------+------+------+---------+------------------------+
     +------+------+------+------+---------+-------------------------+

                           Table 1: UUID Variants

   Interoperability, in any form, with variants other than the one
   defined here is not guaranteed but is not likely to be an issue in
   practice.

   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
   2 of Table 1.  Accordingly, all bit and field layouts avoid the use
   of these bits.

4.2.  Version Field

   The version number is in the most significant 4 bits of octet 6 (bits
   48 through 51 of the UUID).

   Table 2 lists all of the versions for this UUID variant 10xx
   specified in this document.

   +======+======+======+======+=========+=============================+

   +======+======+======+======+=========+============================+
   | Msb0 MSB0 | Msb1 MSB1 | Msb2 MSB2 | Msb3 MSB3 | Version | Description                |
   +======+======+======+======+=========+=============================+
   +======+======+======+======+=========+============================+
   | 0    | 0    | 0    | 0    | 0       | Unused Unused.                    |
   +------+------+------+------+---------+-----------------------------+
   +------+------+------+------+---------+----------------------------+
   | 0    | 0    | 0    | 1    | 1       | The Gregorian time-based   |
   |      |      |      |      |         | UUID specified in this     |
   |      |      |      |      |         | document.                  |
   +------+------+------+------+---------+-----------------------------+
   +------+------+------+------+---------+----------------------------+
   | 0    | 0    | 1    | 0    | 2       | Reserved for DCE Security  |
   |      |      |      |      |         | version, with embedded     |
   |      |      |      |      |         | POSIX UUIDs.               |
   +------+------+------+------+---------+-----------------------------+
   +------+------+------+------+---------+----------------------------+
   | 0    | 0    | 1    | 1    | 3       | The name-based version     |
   |      |      |      |      |         | specified in this document |
   |      |      |      |      |         | that uses MD5 hashing.     |
   +------+------+------+------+---------+-----------------------------+
   +------+------+------+------+---------+----------------------------+
   | 0    | 1    | 0    | 0    | 4       | The randomly or pseudo-            |
   |      |      |      |      |         | randomly pseudorandomly generated version   |
   |      |      |      |      |         | version specified in this  |
   |      |      |      |      |         | document.                  |
   +------+------+------+------+---------+-----------------------------+
   +------+------+------+------+---------+----------------------------+
   | 0    | 1    | 0    | 1    | 5       | The name-based version     |
   |      |      |      |      |         | specified in this document |
   |      |      |      |      |         | that uses SHA-1 hashing.   |
   +------+------+------+------+---------+-----------------------------+
   +------+------+------+------+---------+----------------------------+
   | 0    | 1    | 1    | 0    | 6       | Reordered Gregorian time-  |
   |      |      |      |      |         | based UUID specified in    |
   |      |      |      |      |         | this document.             |
   +------+------+------+------+---------+-----------------------------+
   +------+------+------+------+---------+----------------------------+
   | 0    | 1    | 1    | 1    | 7       | Unix Epoch time-based UUID |
   |      |      |      |      |         | specified in this          |
   |      |      |      |      |         | document.                  |
   +------+------+------+------+---------+-----------------------------+
   +------+------+------+------+---------+----------------------------+
   | 1    | 0    | 0    | 0    | 8       | Reserved for custom UUID   |
   |      |      |      |      |         | formats specified in this  |
   |      |      |      |      |         | document.                  |
   +------+------+------+------+---------+-----------------------------+
   +------+------+------+------+---------+----------------------------+
   | 1    | 0    | 0    | 1    | 9       | Reserved for future        |
   |      |      |      |      |         | definition.                |
   +------+------+------+------+---------+-----------------------------+
   +------+------+------+------+---------+----------------------------+
   | 1    | 0    | 1    | 0    | 10      | Reserved for future        |
   |      |      |      |      |         | definition.                |
   +------+------+------+------+---------+-----------------------------+
   +------+------+------+------+---------+----------------------------+
   | 1    | 0    | 1    | 1    | 11      | Reserved for future        |
   |      |      |      |      |         | definition.                |
   +------+------+------+------+---------+-----------------------------+
   +------+------+------+------+---------+----------------------------+
   | 1    | 1    | 0    | 0    | 12      | Reserved for future        |
   |      |      |      |      |         | definition.                |
   +------+------+------+------+---------+-----------------------------+
   +------+------+------+------+---------+----------------------------+
   | 1    | 1    | 0    | 1    | 13      | Reserved for future        |
   |      |      |      |      |         | definition.                |
   +------+------+------+------+---------+-----------------------------+
   +------+------+------+------+---------+----------------------------+
   | 1    | 1    | 1    | 0    | 14      | Reserved for future        |
   |      |      |      |      |         | definition.                |
   +------+------+------+------+---------+-----------------------------+
   +------+------+------+------+---------+----------------------------+
   | 1    | 1    | 1    | 1    | 15      | Reserved for future        |
   |      |      |      |      |         | definition.                |
   +------+------+------+------+---------+-----------------------------+
   +------+------+------+------+---------+----------------------------+

    Table 2: UUID variant Variant 10xx versions defined Versions Defined by this specification This Specification

   An example version/variant layout for UUIDv4 follows the table where
   M
   "M" represents the version placement for the hexadecimal
   representation of 0x4 (0b0100) and the N "N" represents the variant
   placement for one of the four possible hexadecimal representation of
   variant 10xx: 0x8 (0b1000), 0x9 (0b1001), 0xA (0b1010), 0xB (0b1011) (0b1011).

   00000000-0000-4000-8000-000000000000
   00000000-0000-4000-9000-000000000000
   00000000-0000-4000-A000-000000000000
   00000000-0000-4000-B000-000000000000
   xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx

                     Figure 5: UUIDv4 Variant Examples

   It should be noted that the other remaining UUID variants found in
   Table 1 leverage different sub-typing/versioning sub-typing or versioning mechanisms.  The
   recording and definition of the remaining UUID variant and sub-typing
   combinations are outside of the scope of this document.

5.  UUID Layouts

   To minimize confusion about bit assignments within octets and among
   differing versions, the UUID record definition is provided as a
   grouping of fields within a bit layout consisting of four octets per
   row.  The fields are presented with the most significant one first.

5.1.  UUID Version 1

   UUID version 1

   UUIDv1 is a time-based UUID featuring a 60 bit 60-bit timestamp represented
   by Coordinated Universal Time (UTC) as a count of 100-
   nanosecond 100-nanosecond
   intervals since 00:00:00.00, 15 October 1582 (the date of Gregorian
   reform to the Christian calendar).

   UUIDv1 also features a clock sequence field which that is used to help
   avoid duplicates that could arise when the clock is set backwards in
   time or if the node Node ID changes.

   The node field consists of an IEEE 802 MAC address, usually the host
   address or a randomly derived value per Section Sections 6.9 and Section 6.10.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           time_low                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           time_mid            |  ver  |       time_high       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |var|         clock_seq         |             node              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              node                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 6: UUIDv1 Field and Bit Layout

   time_low:
      The least significant 32 bits of the 60 bit 60-bit starting timestamp.
      Occupies bits 0 through 31 (octets 0-3).

   time_mid:
      The middle 16 bits of the 60 bit 60-bit starting timestamp.  Occupies
      bits 32 through 47 (octets 4-5).

   ver:
      The 4 bit 4-bit version field as defined by Section 4.2, set to 0b0001
      (1).  Occupies bits 48 through 51 of octet 6.

   time_high:
      12 bits that will contain the most
      The least significant 12 bits from the 60
      bit 60-bit starting timestamp.
      Occupies bits 52 through 63 (octets 6-7).

   var:
      The 2 bit 2-bit variant field as defined by Section 4.1, set to 0b10.
      Occupies bits 64 and 65 of octet 8.

   clock_seq:
      The 14 bits containing the clock sequence.  Occupies bits 66
      through 79 (octets 8-9).

   node:
      48 bit
      48-bit spatially unique identifier.  Occupies bits 80 through 127
      (octets 10-15).

   For systems that do not have UTC available, available but do have the local
   time, they may use that instead of UTC, UTC as long as they do so
   consistently throughout the system.  However, this is not recommended
   since generating the UTC from local time only needs a time zone time-zone
   offset.

   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
   not
   cannot be sure that no UUIDs were generated with timestamps larger
   than the value to which the clock was set, then the clock sequence
   MUST be changed.  If the previous value of the clock sequence is
   known, it MAY be incremented; otherwise it SHOULD be set to a random
   or high-
   quality pseudo-random high-quality pseudorandom value.

   Similarly, if the node Node ID changes (e.g., because a network card has
   been moved between machines), setting the clock sequence to a random
   number minimizes the probability of a duplicate due to slight
   differences in the clock settings of the machines.  If the value of
   the clock sequence associated with the changed node Node ID were known,
   then the clock sequence MAY be incremented, but that is unlikely.

   The clock sequence MUST be originally (i.e., once in the lifetime of
   a system) initialized to a random number to minimize the correlation
   across systems.  This provides maximum protection against node
   identifiers Node IDs
   that may move or switch from system to system rapidly.  The initial
   value MUST NOT be correlated to the node identifier. Node ID.

   Notes about IEEE 802 nodes derived nodes: from IEEE 802:

   *  On systems with multiple IEEE 802 addresses, any available one MAY
      be used.

   *  On systems with no IEEE address, a randomly or pseudo-randomly pseudorandomly
      generated value MUST be used; see Section Sections 6.9 and Section 6.10.

   *  On systems utilizing a 64 bit 64-bit MAC address address, the least significant,
      right-most
      rightmost 48 bits MAY be used.

   *  On systems  Systems utilizing an IEEE 802.15.4 16 bit 16-bit address SHOULD instead
      utilize their 64 bit 64-bit MAC address where the least significant,
      right-most
      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 16-bit MAC
      address to create a 48 bit 48-bit value.

5.2.  UUID Version 2

   UUID version 2

   UUIDv2 is known as for DCE Security UUIDs (see [C309] and [C311]. [C311]).  As such,
   the definition of these UUIDs is outside the scope of this
   specification.

5.3.  UUID Version 3

   UUID version 3

   UUIDv3 is meant for generating UUIDs from "names" names that are drawn from,
   and unique within, some "namespace" namespace as per Section 6.5.

   UUIDv3 values are created by computing an MD5 [RFC1321] hash [RFC1321] over a
   given namespace Namespace ID value (Section 6.6) concatenated with the desired
   name value after both have been converted to a canonical sequence of
   octets, as defined by the standards or conventions of its namespace,
   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
   replace the respective bits as defined by Section Sections 4.2 and
   Section 4.1.  An
   example of this bit substitution can be found in Appendix A.2.

   Information around selecting a desired name's canonical format within
   a given namespace can be found in Section 6.5, 6.5 under the heading "A
   note on names".

   Where possible possible, UUIDv5 SHOULD be used in lieu of UUIDv3.  For more
   information on MD5 security considerations considerations, see [RFC6151].

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            md5_high                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          md5_high             |  ver  |       md5_mid         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |var|                        md5_low                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            md5_low                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 7: UUIDv3 Field and Bit Layout

   md5_high:
      The first 48 bits of the layout are filled with the most
      significant, left-most leftmost 48 bits from the computed MD5 value.
      Occupies bits 0 through 47 (octets 0-5).

   ver:
      The 4 bit 4-bit version field as defined by Section 4.2, set to 0b0011
      (3).  Occupies bits 48 through 51 of octet 6.

   md5_mid:
      12 more bits of the layout consisting of the least significant,
      right-most
      rightmost 12 bits of 16 bits immediately following md5_high from
      the computed MD5 value.  Occupies bits 52 through 63 (octets 6-7).

   var:
      The 2 bit 2-bit variant field as defined by Section 4.1, set to 0b10.
      Occupies bits 64 and 65 of octet 8.

   md5_low:
      The final 62 bits of the layout immediately following the var
      field to be filled with the least-significant, right-most least significant, rightmost bits of
      the final 64 bits from the computed MD5 value.  Occupies bits 66
      through 127 (octets 8-15)

5.4.  UUID Version 4

   UUID version 4

   UUIDv4 is meant for generating UUIDs from truly-random truly random or
   pseudo-random
   pseudorandom numbers.

   An implementation may generate 128 bits of random data which that is used
   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 Sections 4.1
   and Section 4.1. 4.2.

   Alternatively, an implementation MAY choose to randomly generate the
   exact required number of bits for random_a, random_b, and random_c
   (122 bits total), total) and then concatenate the version and variant in the
   required position.

   For guidelines on random data generation generation, see Section 6.9.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           random_a                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          random_a             |  ver  |       random_b        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |var|                       random_c                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           random_c                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 8: UUIDv4 Field and Bit Layout

   random_a:
      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
      (octets 0-5).

   ver:
      The 4 bit 4-bit version field as defined by Section 4.2, set to 0b0100
      (4).  Occupies bits 48 through 51 of octet 6.

   random_b:
      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).

   var:
      The 2 bit 2-bit variant field as defined by Section 4.1, set to 0b10.
      Occupies bits 64 and 65 of octet 8.

   random_c:
      The final 62 bits of the layout immediately following the var
      field to be filled with random data as per Section 6.9.  Occupies
      bits 66 through 127 (octets 8-15).

5.5.  UUID Version 5

   UUID version 5

   UUIDv5 is meant for generating UUIDs from "names" that are drawn
   from, and unique within, some "namespace" as per Section 6.5.

   UUIDv5 values are created by computing an SHA-1 [FIPS180-4] hash [FIPS180-4] over
   a given namespace Namespace ID value (Section 6.6) concatenated with the
   desired name value after both have been converted to a canonical
   sequence of octets, as defined by the standards or conventions of its
   namespace, in network byte order.  The most significant, left-most leftmost 128
   bits of the SHA-1 value is are then used to populate all 128 bits of the
   UUID layout layout, and the remaining 32 least significant, right-most rightmost bits
   of SHA-1 output are discarded.  The UUID version and variant then
   replace the respective bits as defined by Section Sections 4.2 and
   Section 4.1.  An
   example of this bit substitution and discarding excess bits can be
   found in Appendix A.4.

   Information around selecting a desired name's canonical format within
   a given namespace can be found in Section 6.5, 6.5 under the heading "A
   note on names".

   There may be scenarios, usually depending on organizational security
   policies, where SHA-1 libraries may not be available or may be deemed
   unsafe for use.  As such, it may be desirable to generate name-based
   UUIDs derived from SHA-256 or newer SHA methods.  These name-based
   UUIDs MUST NOT utilize UUIDv5 and MUST be within the UUIDv8 space
   defined by Section 5.8.  An illustrative example of UUIDv8 for
   SHA-256 name-
   based name-based UUIDs is provided in the appendix Appendix B.2.

   For more information on SHA-1 security considerations considerations, see [RFC6194].

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           sha1_high                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         sha1_high             |  ver  |      sha1_mid         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |var|                       sha1_low                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           sha1_low                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 9: UUIDv5 Field and Bit Layout

   sha1_high:
      The first 48 bits of the layout are filled with the most
      significant, left-most leftmost 48 bits from the computed SHA-1 value.
      Occupies bits 0 through 47 (octets 0-5).

   ver:
      The 4 bit 4-bit version field as defined by Section 4.2, set to 0b0101
      (5).  Occupies bits 48 through 51 of octet 6.

   sha1_mid:
      12 more bits of the layout consisting of the least significant,
      right-most
      rightmost 12 bits of 16 bits immediately following sha1_high from
      the computed SHA-1 value.  Occupies bits 52 through 63 (octets
      6-7).

   var:
      The 2 bit 2-bit variant field as defined by Section 4.1, set to 0b10.
      Occupies bits 64 and 65 of octet 8.

   sha1_low:
      The final 62 bits of the layout immediately following the var
      field to be filled by skipping the 2 two most significant, left-most leftmost
      bits of the remaining SHA-1 hash and then using the next 62 most
      significant, left-most leftmost bits.  Any leftover SHA-1 bits are discarded
      and unused.  Occupies bits 66 through 127 (octets 8-15).

5.6.  UUID Version 6

   UUID version 6

   UUIDv6 is a field-compatible version of UUIDv1 Section 5.1, (Section 5.1),
   reordered for improved DB locality.  It is expected that UUIDv6 will
   primarily be used implemented in contexts where UUIDv1 is used.  Systems
   that do not involve legacy UUIDv1 SHOULD use UUIDv7 Section 5.7 (Section 5.7)
   instead.

   Instead of splitting the timestamp into the low, mid, and high
   sections from UUIDv1, UUIDv6 changes this sequence so timestamp bytes
   are stored from most to least significant.  That is, given a 60 bit 60-bit
   timestamp value as specified for UUIDv1 in Section 5.1, for UUIDv6, UUIDv6
   the first 48 most significant bits are stored first, followed by the
   4 bit
   4-bit version (same position), followed by the remaining 12 bits of
   the original 60 bit 60-bit timestamp.

   The clock sequence and node bits remain unchanged from their position
   in Section 5.1.

   The clock sequence and node bits SHOULD be reset to a pseudo-random pseudorandom
   value for each new UUIDv6 generated; however, implementations MAY
   choose to retain the old clock sequence and MAC address behavior from
   Section 5.1.  For more information on MAC address usage within UUIDs UUIDs,
   see the Section 8.

   The format for the 16-byte, 128 bit 128-bit UUIDv6 is shown in Figure 10.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           time_high                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           time_mid            |  ver  |       time_low        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |var|         clock_seq         |             node              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              node                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 10: UUIDv6 Field and Bit Layout

   time_high:
      The most significant 32 bits of the 60 bit 60-bit starting timestamp.
      Occupies bits 0 through 31 (octets 0-3).

   time_mid:
      The middle 16 bits of the 60 bit 60-bit starting timestamp.  Occupies
      bits 32 through 47 (octets 4-5).

   ver:
      The 4 bit 4-bit version field as defined by Section 4.2, set to 0b0110
      (6).  Occupies bits 48 through 51 of octet 6.

   time_low:
      12 bits that will contain the least significant 12 bits from the
      60 bit
      60-bit starting timestamp.  Occupies bits 52 through 63 (octets
      6-7).

   var:
      The 2 bit 2-bit variant field as defined by Section 4.1, set to 0b10.
      Occupies bits 64 and 65 of octet 8.

   clock_seq:
      The 14 bits containing the clock sequence.  Occupies bits 66
      through 79 (octets 8-9).

   node:
      48 bit
      48-bit spatially unique identifier.  Occupies bits 80 through 127
      (octets 10-15).

   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
   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
   significant 16 bits proves useful when reusing an existing UUIDv1
   implementation.

5.7.  UUID Version 7

   UUID version 7

   UUIDv7 features a time-ordered value field derived from the widely
   implemented and well known well-known Unix Epoch timestamp source, the number of
   milliseconds since midnight 1 Jan 1970 UTC, leap seconds excluded.
   Generally, UUIDv7 generally has improved entropy characteristics over UUIDv1 Section 5.1
   (Section 5.1) or UUIDv6 Section 5.6. (Section 5.6).

   UUIDv7 values are created by allocating a Unix timestamp in
   milliseconds in the most significant 48 bits and filling the
   remaining 74 bits, excluding the required version and variant bits,
   with random bits for each new UUIDv7 generated to provide uniqueness
   as per Section 6.9.  Alternatively, implementations MAY fill the 74
   bits, jointly, with a combination of the following subfields, in this
   order from the most significant bits to the least, to guarantee
   additional monotonicity within a millisecond:

   1.  An OPTIONAL sub-millisecond timestamp fraction (12 bits at
       maximum) as per Section 6.2 (Method 3).

   2.  An OPTIONAL carefully seeded counter as per Section 6.2 (Method 1
       or 2).

   3.  Random data for each new UUIDv7 generated for any remaining
       space.

   Implementations SHOULD utilize UUIDv7 instead of UUIDv1 and UUIDv6 if
   possible.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           unix_ts_ms                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          unix_ts_ms           |  ver  |       rand_a          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |var|                        rand_b                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            rand_b                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 11: UUIDv7 Field and Bit Layout

   unix_ts_ms:
      48 bit
      48-bit big-endian unsigned number of the Unix epoch Epoch timestamp in
      milliseconds as per Section 6.1.  Occupies bits 0 through 47
      (octets 0-5).

   ver:
      The 4 bit 4-bit version field as defined by Section 4.2, set to 0b0111
      (7).  Occupies bits 48 through 51 of octet 6.

   rand_a:
      12 bits pseudo-random of pseudorandom data to provide uniqueness as per
      Section 6.9 and/or optional constructs to guarantee additional
      monotonicity as per Section 6.2.  Occupies bits 52 through 63
      (octets 6-7).

   var:
      The 2 bit 2-bit variant field as defined by Section 4.1, set to 0b10.
      Occupies bits 64 and 65 of octet 8.

   rand_b:
      The final 62 bits of pseudo-random pseudorandom data to provide uniqueness as
      per Section 6.9 and/or an optional counter to guarantee additional
      monotonicity as per Section 6.2.  Occupies bits 66 through 127
      (octets 8-15).

5.8.  UUID Version 8

   UUID version 8

   UUIDv8 provides an RFC-compatible a format for experimental or vendor-specific use
   cases.  The only requirement is that the variant and version bits
   MUST be set as defined in Section Sections 4.1 and
   Section 4.2.  UUIDv8's uniqueness
   will be implementation-specific implementation specific and MUST NOT be assumed.

   The only explicitly defined bits are those of the version and variant
   fields, leaving 122 bits for implementation specific implementation-specific UUIDs.  To be
   clear:
   clear, UUIDv8 is not a replacement for UUIDv4 Section 5.4 (Section 5.4) where all
   122 extra bits are filled with random data.

   Some example situations in which UUIDv8 usage could occur:

   *  An implementation would like to embed extra information within the
      UUID other than what is defined in this document.

   *  An implementation has other application/language application and/or language
      restrictions
      which that inhibit the use of one of the current UUIDs.

   The appendix,

   Appendix B, B provides two illustrative examples of custom UUIDv8
   algorithms to address two example scenarios.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           custom_a                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          custom_a             |  ver  |       custom_b        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |var|                       custom_c                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           custom_c                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 12: UUIDv8 Field and Bit Layout

   custom_a:
      The first 48 bits of the layout that can be filled as an
      implementation sees fit.  Occupies bits 0 through 47 (octets 0-5).

   ver:
      The 4 bit 4-bit version field as defined by Section 4.2, set to 0b1000
      (8).  Occupies bits 48 through 51 of octet 6.

   custom_b:
      12 more bits of the layout that can be filled as an implementation
      sees fit.  Occupies bits 52 through 63 (octets 6-7).

   var:
      The 2 bit 2-bit variant field as defined by Section 4.1, set to 0b10.
      Occupies bits 64 and 65 of octet 8.

   custom_c:
      The final 62 bits of the layout immediately following the var
      field to be filled as an implementation sees fit.  Occupies bits
      66 through 127 (octets 8-15).

5.9.  Nil UUID

   The nil Nil UUID is special form of UUID that is specified to have all
   128 bits set to zero.

   00000000-0000-0000-0000-000000000000

                         Figure 13: Nil UUID Format

   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
   bit
   128-bit UUID.  A Nil UUID can express the concept "no such value
   here".
   Thus  Thus, it is reserved for such use as needed for implementation-
   specific
   implementation-specific situations.

   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
   defined by this document.

5.10.  Max UUID

   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 the
   Nil UUID defined in Section 5.9.

   FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF

                         Figure 14: Max UUID Format

   A Max UUID value can be used as a sentinel value in situations where
   a 128 bit 128-bit UUID is required required, but a concept such as "end of UUID list"
   needs to be expressed, expressed and is reserved for such use as needed for
   implementation-specific situations.

   Note that the Max UUID value falls within the range of the "yet to be "yet-to-be
   defined" future UUID variant as per the last row of Table 1 rather
   than the variant defined by this document.

6.  UUID Best Practices

   The minimum requirements for generating UUIDs of each version are
   described in this
   document for each version. document.  Everything else is an implementation
   detail
   detail, and it is up to the implementer to decide what is appropriate
   for a given implementation.  Various relevant factors are covered
   below to help guide an implementer through the different trade-offs
   among differing UUID implementations.

6.1.  Timestamp Considerations

   UUID timestamp source, precision, and length was the topic were topics of great
   debate while creating UUIDv7 for this specification.  Choosing the
   right timestamp for your application is a very important topic. important.  This section
   will detail some of the most common points on this topic. issue.

   Reliability:
      Implementations acquire the current timestamp from a reliable
      source to provide values that are time-ordered time ordered and continually
      increasing.  Care must be taken to ensure that timestamp changes
      from the environment or operating system are handled in a way that
      is consistent with implementation requirements.  For example, if
      it is possible for the system clock to move backward due to either
      manual adjustment or corrections from a time synchronization
      protocol, implementations need to determine how to handle such
      cases.  (See Altering, "Altering, Fuzzing, or Smearing Smearing" below.)

   Source:
      UUID version 1
      UUIDv1 and 6 UUIDv6 both utilize a Gregorian epoch timestamp Epoch timestamp, while
      UUIDv7 utilizes a Unix Epoch timestamp.  If other timestamp
      sources or a custom timestamp epoch Epoch are required, UUIDv8 MUST be
      used.

   Sub-second Precision and Accuracy:
      Many levels of precision exist for timestamps: milliseconds,
      microseconds, nanoseconds, and beyond.  Additionally  Additionally, fractional
      representations of sub-second precision may be desired to mix
      various levels of precision in a time-ordered manner.
      Furthermore, system clocks themselves have an underlying
      granularity and it
      granularity, which is frequently less than the precision offered
      by the operating system.  With UUID version 1 UUIDv1 and 6,
      100-nanoseconds UUIDv6, 100 nanoseconds
      of precision are present present, while UUIDv7 features a millisecond
      level of precision by default within the Unix epoch Epoch that does not
      exceed the granularity capable in most modern systems.  For other
      levels of precision precision, UUIDv8 is available.  Similar to Section 6.2,
      with UUIDv1 or UUIDv6, a high resolution high-resolution timestamp can be
      simulated by keeping a count of the number of UUIDs that have been
      generated with the same value of the system
      time, time and using it that
      count to construct the low order bits of the timestamp.  The count
      of the high resolution high-resolution timestamp will range between zero and the
      number of 100-nanosecond intervals per system
      time system-time interval.

   Length:
      The length of a given timestamp directly impacts how many
      timestamp ticks can be contained in a UUID before the maximum
      value for the timestamp field is reached.  Take care to ensure
      that the proper length is selected for a given timestamp.  UUID
      version 1  UUIDv1
      and 6 UUIDv6 utilize a 60 bit 60-bit timestamp valid until 5623 AD and AD; UUIDv7
      features a 48 bit 48-bit timestamp valid until the year 10889 AD.

   Altering, Fuzzing, or Smearing:
      Implementations MAY alter the actual timestamp.  Some examples
      include security considerations around providing a real clock real-clock
      value within a UUID, UUID to 1) correct inaccurate clocks, to 2) handle
      leap seconds, or instead of dividing a number of microseconds by 1000
      to 3) obtain a millisecond value; value by dividing by 1024
      (or some other value) for performance reasons. reasons (instead of dividing
      a number of microseconds by 1000).  This specification makes no
      requirement or guarantee about how close the clock value needs to
      be to the actual time.  If UUIDs do not need to be frequently
      generated, the UUIDv1 or UUIDv6 timestamp can simply be the system
      time multiplied by the number of 100-nanosecond intervals per
      system time
      system-time interval.

   Padding:
      When timestamp padding is required, implementations MUST pad the
      most significant bits (left-most) bits (leftmost) with data.  An example for this
      padding data is to fill the most significant, left-most leftmost bits of a
      Unix timestamp with zeroes to complete the 48 bit 48-bit timestamp in
      UUIDv7.  An alternative approach for padding data is to fill the
      most significant, left-most leftmost bits with the number of 32 bit 32-bit Unix
      timestamp roll-overs rollovers after 2038-01-19.

   Truncating:
      When timestamps need to be truncated, the lower, least significant
      bits MUST be used.  An example would be truncating a 64 bit 64-bit Unix
      timestamp to the least significant, right-most rightmost 48 bits for UUIDv7.

   Error Handling:
      If a system overruns the generator by requesting too many UUIDs
      within a single system time system-time interval, the UUID service can return
      an error, error or stall the UUID generator until the system clock
      catches up, up and MUST NOT return knowingly return duplicate values due to a
      counter rollover.  Note that if the processors overrun the UUID
      generation frequently, additional node identifiers Node IDs can be allocated to the
      system, which will permit higher speed allocation by making
      multiple UUIDs potentially available for each time stamp timestamp value.
      Similar techniques are discussed in Section 6.4.

6.2.  Monotonicity and Counters

   Monotonicity (each subsequent value being greater than the last) is
   the backbone of time-based sortable UUIDs.  Normally, time-based
   UUIDs from this document will be monotonic due to an embedded
   timestamp; however, implementations can guarantee additional
   monotonicity via the concepts covered in this section.

   Take care to ensure UUIDs generated in batches are also monotonic.
   That is, if one thousand UUIDs are generated for the same timestamp,
   there should be sufficient logic for organizing the creation order of
   those one thousand UUIDs.  Batch UUID creation implementations MAY
   utilize a monotonic counter that increments for each UUID created
   during a given timestamp.

   For single-node UUID implementations that do not need to create
   batches of UUIDs, the embedded timestamp within UUID version 6 UUIDv6 and 7 UUIDv7 can
   provide sufficient monotonicity guarantees by simply ensuring that
   timestamp increments before creating a new UUID.  Distributed nodes
   are discussed in Section 6.4.

   Implementations SHOULD employ the following methods for single-node
   UUID implementations that require batch UUID creation, creation or are
   otherwise concerned about monotonicity with high frequency high-frequency UUID
   generation.

   Fixed-Length

   Fixed Bit-Length Dedicated Counter Bits (Method 1):
      Some implementations allocate a specific number of bits in the
      UUID layout to the sole purpose of tallying the total number of
      UUIDs created during a given UUID timestamp tick.  A fixed bit-
      length counter, if  If present, a
      fixed bit-length counter MUST be positioned immediately after the
      embedded timestamp.  This promotes sortability and allows random
      data generation for each counter increment.  With this method, the
      rand_a section (or a subset of its left-most leftmost bits) of UUIDv7 is
      used as fixed-length a fixed bit-length dedicated counter bits that are is incremented
      for every UUID generation.  The trailing random bits generated for
      each new UUID in rand_b can help produce unguessable UUIDs.  In
      the event that more counter bits are required, the most
      significant (left-most) (leftmost) bits of rand_b MAY be used as additional
      counter bits.

   Monotonic Random (Method 2):
      With this method, the random data is extended to also function as
      a counter.  This monotonic value can be thought of as a "randomly
      seeded counter" which that MUST be incremented in the least significant
      position for each UUID created on a given timestamp tick.
      UUIDv7's rand_b section SHOULD be utilized with this method to
      handle batch UUID generation during a single timestamp tick.  The
      increment value for every UUID generation is a random integer of
      any desired length larger than zero.  It ensures that the UUIDs
      retain the required level of unguessability provided by the
      underlying entropy.  The increment value MAY be 1 when the number
      of UUIDs generated in a particular period of time is important and
      guessability is not an issue.  However, incrementing the counter
      by 1 SHOULD NOT be used by implementations that favor
      unguessability, as the resulting values are easily guessable.

   Replace Left-Most Leftmost Random Bits with Increased Clock Precision
   (Method 3):
      For UUIDv7, which has millisecond timestamp precision, it is
      possible to use additional clock precision available on the system
      to substitute for up to 12 random bits immediately following the
      timestamp.  This can provide values that are time-ordered time ordered with
      sub-millisecond precision, using however many bits are appropriate
      in the implementation environment.  With this method, the
      additional time precision bits MUST follow the timestamp as the
      next available bit, bit in the rand_a field for UUIDv7.

      To calculate this value, start with the portion of the timestamp
      expressed as a fraction of the clock's tick value (fraction of a
      millisecond for UUIDv7).  Compute the count of possible values
      that can be represented in the available bit space, 4096 for the
      UUIDv7 rand_a field.  Using floating point or scaled integer
      arithmetic, multiply this fraction of a millisecond value by 4096
      and round down (toward zero) to an integer result to arrive at a
      number between 0 and the maximum allowed for the indicated bits bits,
      which sorts monotonically based on time.  Each increasing
      fractional value will result in an increasing bit field value, value to
      the precision available with these bits.

      For example, let's assume a system timestamp of 1 Jan 2023
      12:34:56.1234567.  Taking the precision greater than 1ms 1 ms gives us
      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
      that fit in those bits (4096, (4096 or 2 to the 12th power) and 2^12), multiply it by our
      millisecond fraction value of 0.4567 0.4567, and truncate the result to
      an integer, which gives an integer value of 1870.  Expressed as hexadecimal
      hexadecimal, it is 0x74E, 0x74E or the binary bits 0b011101001110.  One
      can then use those 12 bits as the most significant (left-most) (leftmost)
      portion of the random section of the UUID (e.g., the rand_a field
      in UUIDv7).  This works for any desired bit length that fits into
      a UUID, and applications can decide the appropriate length based
      on available clock precision, but precision; for UUIDv7, it is limited to 12 bits
      at maximum to reserve sufficient space for random bits.

      The main benefit to encoding additional timestamp precision is
      that it utilizes additional time precision already available in
      the system clock to provide values that are more likely to be
      unique, and thus
      unique; thus, it may simplify certain implementations.  This
      technique can also be used in conjunction with one of the other
      methods, where this additional time precision would immediately
      follow the timestamp, and then timestamp.  Then, if any bits are to be used as a clock
      sequence
      sequence, they would follow next.

   The following sub-topics cover topics issues related solely with to creating
   reliable fixed-length fixed bit-length dedicated counters:

   Fixed-Length

   Fixed Bit-Length Dedicated Counter Seeding:
      Implementations utilizing the fixed-length fixed bit-length counter method
      randomly initialize the counter with each new timestamp tick.
      However, when the timestamp has not increased, the counter is
      instead incremented by the desired increment logic.  When
      utilizing a randomly seeded counter alongside Method 1, the random
      value MAY be regenerated with each counter increment without
      impacting sortability.  The downside is that Method 1 is prone to
      overflows if a counter of adequate length is not selected or the
      random data generated leaves little room for the required number
      of increments.  Implementations utilizing fixed-length fixed bit-length counter
      method MAY also choose to randomly initialize a portion of the
      counter rather than the entire counter.  For example, a 24 bit 24-bit
      counter could have the 23 bits in least-significant, right-most, least significant, rightmost
      position randomly initialized.  The remaining most significant, left-most
      leftmost counter bit is initialized as zero for the sole purpose
      of guarding against counter rollovers.

   Fixed-Length

   Fixed Bit-Length Dedicated Counter Length:
      Select a counter bit-length that can properly handle the level of
      timestamp precision in use.  For example, millisecond precision
      generally requires a larger counter than a timestamp with
      nanosecond precision.  General guidance is that the counter SHOULD
      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
      sufficient entropy in the random portion of the UUID after the
      counter.  This entropy helps improve the unguessability
      characteristics of UUIDs created within the batch.

   The following sub-topics cover rollover handling with either type of
   counter method:

   Counter Rollover Guards:
      The technique from Fixed-Length "Fixed Bit-Length Dedicated Counter Seeding Seeding"
      above that describes allocating a segment of the fixed-length fixed bit-length
      counter as a rollover guard is also helpful to mitigate counter
      rollover issues.  This same technique can be used with monotonic
      random counter methods by ensuring that the total length of a
      possible increment in the least significant, right most rightmost position is
      less than the total length of the random value being incremented.
      As such, the most significant, left-most, leftmost bits can be incremented as
      rollover guarding.

   Counter Rollover Handling:
      Counter rollovers MUST be handled by the application to avoid
      sorting issues.  The general guidance is that applications that
      care about absolute monotonicity and sortability should freeze the
      counter and wait for the timestamp to advance advance, which ensures
      monotonicity is not broken.  Alternatively, implementations MAY
      increment the timestamp ahead of the actual time and reinitialize
      the counter.

   Implementations MAY use the following logic to ensure UUIDs featuring
   embedded counters are monotonic in nature:

   1.  Compare the current timestamp against the previously stored
       timestamp.

   2.  If the current timestamp is equal to the previous timestamp,
       increment the counter according to the desired method.

   3.  If the current timestamp is greater than the previous timestamp,
       re-initialize the desired counter method to the new timestamp and
       generate new random bytes (if the bytes were frozen or being used
       as the seed for a monotonic counter).

   Monotonic Error Checking:
      Implementations SHOULD check if the currently generated UUID is
      greater than the previously generated UUID.  If this is not the
      case
      case, then any number of things could have occurred, such as clock
      rollbacks, leap second handling, and counter rollovers.
      Applications SHOULD embed sufficient logic to catch these
      scenarios and correct the problem to ensure that the next UUID
      generated is greater than the previous, or they should at least
      report an appropriate error.  To handle this scenario, the general
      guidance is that the application MAY reuse the previous timestamp
      and increment the previous counter method.

6.3.  UUID Generator States

   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
   volatile store (and updated whenever the stable store is updated).

   This stable storage MAY be used to record various portions of the
   UUID generation generation, which prove useful for batch UUID generation
   purposes and monotonic error checking with UUIDv6 and UUIDv7.  These
   stored values include but are not limited to last known timestamp,
   clock sequence, counters, and random data.

   If an implementation does not have any stable store available, then
   it MAY proceed with UUID generation as if this was were the first UUID
   created within a batch.  This is the least desirable implementation
   because it will increase the frequency of creation of values such as
   clock sequence, counters, or random data, which increases the
   probability of duplicates.  Further, frequent generation of random
   numbers also puts more stress on any entropy source and or and/or entropy
   pool being used as the basis for such random numbers.

   An implementation MAY also return an application error in the event
   that collision resistance is of the utmost concern.  The semantics of
   this error are up to the application and implementation.  See
   Section 6.7 for more information on weighting collision tolerance in
   applications.

   For UUIDv1 and UUIDv6, if the node Node ID can never change (e.g., the
   network interface card from which the node Node ID is derived is
   inseparable from the system), or if any change also re-initializes
   the clock sequence to a random value, then instead of keeping it in
   stable store, the current node Node ID may be returned.

   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
   stable store can be periodically be set to a value larger than any yet
   used in a UUID.  As long as the generated UUIDs have timestamps less
   than that value, and the clock sequence and node Node ID remain unchanged,
   only the shared volatile copy of the state needs to be updated.
   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
   will not cause a re-initialization of the clock sequence.

   If it is too expensive to access shared state each time a UUID is
   generated, then the system-wide generator can be implemented to
   allocate a block of time stamps timestamps each time it is called; a per-
   process per-process
   generator can allocate from that block until it is exhausted.

6.4.  Distributed UUID Generation

   Some implementations MAY desire to utilize the utilization of multi-node,
   clustered, applications which that involve two or more nodes independently
   generating UUIDs that will be stored in a common location.  While
   UUIDs already feature sufficient entropy to ensure that the chances
   of collision are low, as the total number of UUID generating nodes increase;
   increases, so does the likelihood of a collision.

   This section will detail the two additional collision resistance
   approaches that have been observed by multi-node UUID implementations
   in distributed environments.

   It should be noted that, although this section details two methods
   for the sake of completeness, implementations should utilize the
   pseudo-random
   pseudorandom Node ID option if additional collision resistance for
   distributed UUID generation is a requirement.  Likewise, utilization
   of either method is not required for implementing UUID generation in
   distributed environments.

   Node IDs:
      With this method, a pseudo-random pseudorandom Node ID value is placed within
      the UUID layout.  This identifier helps ensure the bit-space bit space for a
      given node is unique, resulting in UUIDs that do not conflict with
      any other UUID created by another node with a different node id.
      Implementations that choose to leverage an embedded node id SHOULD
      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
      implementations and are outside the scope of this specification.
      Furthermore, the creation and negotiation of unique node ids among
      nodes is also out of scope for this specification.

   Centralized Registry:
      With this method method, all nodes tasked with creating UUIDs consult a
      central registry and confirm the generated value is unique.  As
      applications scale, the communication with the central registry
      could become a bottleneck and impact UUID generation in a negative
      way.  Shared knowledge schemes with central/global registries are
      outside the scope of this specification and is are NOT RECOMMENDED.

   Distributed applications generating UUIDs at a variety of hosts MUST
   be willing to rely on the random number source at all hosts.

6.5.  Name-Based UUID Generation

   Although some prefer to use the word "hash-based" to describe UUIDs
   featuring hashing algorithms (MD5 or SHA-1), this document retains
   the usage of the adjective term "name-based" in order to maintain consistency
   with historical previously published documents and existing implementations.

   The requirements for name-based UUIDs are as follows:

   *  UUIDs generated at different times from the same name (using the
      same canonical format) in the same namespace MUST be equal.

   *  UUIDs generated from two different names (same or differing
      canonical format) in the same namespace should be different (with
      very high probability).

   *  UUIDs generated from the same name (same or differing canonical
      format) in two different namespaces should be different (with very
      high probability).

   *  If two UUIDs that were generated from names (using the same
      canonical format) are equal, then they were generated from the
      same name in the same namespace (with very high probability).

   A note on names:

      The concept of name (and namespace) should be broadly construed
      and not limited to textual names.  A canonical sequence of octets
      is one that conforms to the specification for that name form's
      canonical representation.  A name can have many usual forms, only
      one of which can be canonical.  An implementer of new namespaces
      for UUIDs needs to reference the specification for the canonical
      form of names in that space, space or define such a canonical form for
      the namespace if it does not exist.  For example, at the time of this
      specification, [RFC8499] domain name system
      writing, Domain Name System (DNS) [RFC9499] has three conveyance
      formats: common (www.example.com), presentation
      (www.example.com.)
      (www.example.com.), and wire format (3www7example3com0).  Looking
      at [X500] distinguished names Distinguished Names (DNs), the previous version of this
      specification [RFC4122] allowed either text based
      text-based or binary distinguished
      encoding rules (DER) based DER-based names as inputs.  For [RFC1738] uniform
      resource locators (URLs), Uniform
      Resource Locators (URLs) [RFC1738], one could provide a fully-qualified
      domain-name Fully
      Qualified Domain Name (FQDN) with or without the protocol
      identifier
      (www.example.com) www.example.com or (https://www.example.com). https://www.example.com.  When it
      comes to
      [X660] object identifiers Object Identifiers (OIDs) [X660], one could choose dot-notation dot
      notation without the leading dot (2.999), choose to include the
      leading dot
      (.2.999) (.2.999), or select one of the many formats from
      [X680] such as OID Internationalized Resource Identifier (OID-IRI) (/Joint-ISO-ITU-T/
      Example).
      (/Joint-ISO-ITU-T/Example).  While most users may default to the
      common format for DNS, FQDN format for a URL, text format for X.500
      X.500, and dot-notation dot notation without a leading dot for OID; OID, name-based
      UUID implementations generally SHOULD allow arbitrary input which that
      will compute name-
      based name-based UUIDs for any of the aforementioned
      example names and others not defined here.  Each name format
      within a namespace will output different UUIDs.  As such, the
      mechanisms or conventions used for allocating names and ensuring
      their uniqueness within their namespaces are beyond the scope of
      this specification.

6.6.  Namespace ID Usage and Allocation

   This section and table, Table 3, details the namespace IDs for some potentially
   interesting namespaces such as those for [RFC8499] domain
   name system (DNS), [RFC1738] uniform resource locators (URLs), [X660]
   object identifiers (OIDs), DNS [RFC9499], URLs
   [RFC1738], OIDs [X660], and [X500] distinguished names (DNs). DNs [X500].

   Further, this section also details allocation, IANA registration registration, and
   other details pertinent to Namespace IDs.  IANA may use the table
   Table 3 as-is replacing "This Document" replaced as required.

   +=========+====================================+=========+==========+
   |Namespace|Namespace ID Value                  |Name     |Namespace |
   |         |                                    |Reference|ID        |
   |         |                                    |         |Reference |
   +=========+====================================+=========+==========+
   |DNS      |6ba7b810-9dad-11d1-80b4-00c04fd430c8|[RFC8499]|[RFC4122],|      |6ba7b810-9dad-11d1-80b4-00c04fd430c8|[RFC9499]|[RFC4122],|
   |         |                                    |         |This      |
   |         |                                    |         |document         |RFC 9562  |
   +---------+------------------------------------+---------+----------+
   |URL      |6ba7b811-9dad-11d1-80b4-00c04fd430c8|[RFC1738]|[RFC4122],|
   |         |                                    |         |This      |
   |         |                                    |         |document         |RFC 9562  |
   +---------+------------------------------------+---------+----------+
   |OID      |6ba7b812-9dad-11d1-80b4-00c04fd430c8|[X660]   |[RFC4122],|
   |         |                                    |         |This      |
   |         |                                    |         |document         |RFC 9562  |
   +---------+------------------------------------+---------+----------+
   |X500     |6ba7b814-9dad-11d1-80b4-00c04fd430c8|[X500]   |[RFC4122],|
   |         |                                    |         |This      |
   |         |                                    |         |document         |RFC 9562  |
   +---------+------------------------------------+---------+----------+

                           Table 3: Namespace IDs

   Items may be added to this table registry using "Specification Required" the Specification Required
   policy as per [RFC8126].

   For designated experts, generally speaking, Namespace IDs are
   allocated as follows:

   *  The first namespace Namespace ID value, for DNS, was calculated from a time-
      based UUIDv1 and "6ba7b810-9dad-11d1-80b4-00c04fd430c8" "6ba7b810-9dad-11d1-80b4-00c04fd430c8", used as a
      starting point.

   *  Subsequent namespace Namespace ID values increment the least-significant,
      right-most least significant,
      rightmost bit of time_low "6ba7b810" while freezing the rest of
      the UUID to "9dad-11d1-80b4-00c04fd430c8".

   *  New namespace Namespace ID values MUST use this same logic and MUST NOT use
      a previously used Namespace ID value.

   *  Thus, "6ba7b815" is the next available time_low for a new
      Namespace ID value with the full ID being "6ba7b815-9dad-
      11d1-80b4-00c04fd430c8".

   *  The upper bound for time_low in this special use, namespace Namespace ID
      values, is "ffffffff" or "ffffffff-9dad-11d1-80b4-00c04fd430c8" "ffffffff-9dad-11d1-80b4-00c04fd430c8",
      which should be sufficient space for future namespace Namespace ID values.

   Note that the namespace Namespace ID value "6ba7b813-9dad-
   11d1-80b4-00c04fd430c8" and its usage is are not defined by this
   document or by [RFC4122], as such [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
   are to be globally available and fully interoperable.
   Implementations MAY continue to use vendor-specific, application-
   specific, and deployment-specific Namespace ID values values; but know that
   interoperability is not guaranteed.  These custom Namespace ID values
   MUST NOT use the logic above and instead are RECOMMENDED to generate above; instead, generating a UUIDv4 or UUIDv7
   Namespace ID value. value is RECOMMENDED.  If collision probability
   (Section 6.7) and uniqueness (Section 6.8) of the final name-based
   UUID are not a problem; problem, an implementation MAY also leverage UUIDv8
   instead to create a custom, application-specific Namespace ID value.

   Implementations SHOULD provide the ability to input a custom
   namespace to account for newly registered IANA Namespace ID values
   outside of those listed in this section or custom, application application-
   specific Namespace ID values.

6.7.  Collision Resistance

   Implementations should weigh the consequences of UUID collisions
   within their application and when deciding between UUID versions that
   use entropy (randomness) versus the other components such as those in
   Section
   Sections 6.1 and Section 6.2.  This is especially true for distributed node
   collision resistance as defined by Section 6.4.

   There are two example scenarios below which that help illustrate the
   varying seriousness of a collision within an application.

   Low Impact:
      A UUID collision generated a duplicate log entry entry, which results in
      incorrect statistics derived from the data.  Implementations that
      are not negatively affected by collisions may continue with the
      entropy and uniqueness provided by the traditional UUID format. UUIDs defined in this document.

   High Impact:
      A duplicate key causes an airplane to receive the wrong course course,
      which puts people's lives at risk.  In this scenario scenario, there is no
      margin for error.  Collisions must be avoided and avoided: failure is
      unacceptable.  Applications dealing with this type of scenario
      must employ as much collision resistance as possible within the
      given application context.

6.8.  Global and Local Uniqueness

   UUIDs created by this specification MAY be used to provide local
   uniqueness guarantees.  For example, ensuring UUIDs created within a
   local application context are unique within a database MAY be
   sufficient for some implementations where global uniqueness outside
   of the application context, in other applications, or around the
   world is not required.

   Although true global uniqueness is impossible to guarantee without a
   shared knowledge scheme, a shared knowledge scheme is not required by
   a UUID to provide uniqueness for practical implementation purposes.
   Implementations MAY implement use a shared knowledge scheme scheme, introduced in
   Section 6.4 6.4, as they see fit to extend the uniqueness guaranteed by
   this specification.

6.9.  Unguessability

   Implementations SHOULD utilize a cryptographically secure pseudo-
   random
   pseudorandom number generator (CSPRNG) to provide values that are
   both difficult to predict ("unguessable") and have a low likelihood
   of collision ("unique").  The exception is when a suitable CSPRNG is
   unavailable in the execution environment.  Take care to ensure the
   CSPRNG state is properly reseeded upon state changes, such as process
   forks, to ensure proper CSPRNG operation.  CSPRNG ensures the best of
   Section
   Sections 6.7 and Section 8 are present in modern UUIDs.

   Further advice on generating cryptographic-quality random numbers can
   be found in [RFC4086], [RFC8937] [RFC8937], and in [RANDOM].

6.10.  UUIDs That Do Not Identify the Host

   This section describes how to generate a UUIDv1 or UUIDv6 value if an
   IEEE 802 address is not available, available or its use is not desired.

   Implementations MAY leverage MAC address randomization techniques
   (IEEE 802.11bh)
   [IEEE802.11bh] as an alternative to the pseudo-random pseudorandom logic provided
   in this section.

   Alternatively, implementations MAY elect to obtain a 48 bit 48-bit
   cryptographic-quality random number as per Section 6.9 to use it as the node
   Node ID.  After generating the 48 bit 48-bit fully randomized node value,
   implementations MUST set the least significant bit of the first octet
   of the node Node ID set to 1.  This bit is the unicast/ unicast or multicast bit, which
   will never be set in IEEE 802 addresses obtained from network cards.
   Hence, there can never be a conflict between UUIDs generated by
   machines with and without network cards.  An example of generating a
   randomized 48 bit 48-bit node value and the subsequent bit modification is
   detailed in the Appendix A appendix. A.  For more information about IEEE 802 address
   and the unicast/multicast unicast or multicast or local/global bits bits, please review [RFC7042].
   [RFC9542].

   For compatibility with earlier specifications, note that this
   document uses the unicast/multicast bit, unicast or multicast bit instead of the arguably
   more correct local/global bit because MAC addresses with the local/global local/
   global bit set or not set are both possible in a network.  This is
   not the case with the unicast/multicast unicast or multicast bit.  One node cannot have
   a MAC address that multicasts to multiple nodes.

   In addition, items such as the computer's name and the name of the
   operating system, while not strictly speaking random, will help
   differentiate the results from those obtained by other systems.

   The exact algorithm to generate a node Node ID using these data is system
   specific,
   specific because both the data available and the functions to obtain
   them are often very system specific.  A  However, a generic approach, however, approach is
   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]),
   take an arbitrary 6 bytes from the hash value, and set the multicast
   bit as described above.

6.11.  Sorting

   UUIDv6 and UUIDv7 are designed so that implementations that require
   sorting (e.g., database indexes) sort as opaque raw bytes, bytes without the
   need for parsing or introspection.

   Time ordered

   Time-ordered monotonic UUIDs benefit from greater database index database-index
   locality because the new values are near each other in the index.  As
   a result result, objects are more easily clustered together for better
   performance.  The real-world differences in this approach of index
   locality vs versus random data inserts can be one order of magnitude or
   more.

   UUID formats created by this specification are intended to be
   lexicographically sortable while in the textual representation.

   UUIDs created by this specification are crafted with big-endian byte
   order (network byte order) in mind.  If little-endian style is
   required, UUIDv8 is available for custom UUID formats.

6.12.  Opacity

   As general guidance, it is recommend to avoid avoiding parsing UUID values
   unnecessarily, and instead treating unnecessarily is
   recommended; instead, treat UUIDs as opaquely as possible.  Although
   application-specific concerns could could, of course course, require some degree
   of introspection (e.g., to examine the Section 4.1,
   Section Sections 4.1 or 4.2 or perhaps the
   timestamp of a UUID), the advice here is to avoid this or other
   parsing unless absolutely necessary.  Applications typically tend to
   be simpler, be more interoperable, and perform better, better when this
   advice is followed.

6.13.  DBMS and Database Considerations

   For many applications, such as databases, storing UUIDs as text is
   unnecessarily verbose, requiring 288 bits to represent 128 bit 128-bit UUID
   values.  Thus, where feasible, UUIDs SHOULD be stored within database
   applications as the underlying 128 bit 128-bit binary value.

   For other systems, UUIDs MAY be stored in binary form or as text, as
   appropriate.  The trade-offs to both approaches are: are as follows:

   *  Storing as in binary form requires less space and may result in
      faster data access.

   *  Storing as text requires more space but may require less
      translation if the resulting text form is to be used after
      retrieval, which thus may make it simpler to implement.

   DBMS vendors are encouraged to provide functionality to generate and
   store UUID formats defined by this specification for use as
   identifiers or left parts of identifiers such as, but not limited to,
   primary keys, surrogate keys for temporal databases, foreign keys
   included in polymorphic relationships, and keys for key-value pairs
   in JSON columns and key-value databases.  Applications using a
   monolithic database may find using database-generated UUIDs (as
   opposed to client-generate client-generated UUIDs) provides the best UUID
   monotonicity.  In addition to UUIDs, additional identifiers MAY be
   used to ensure integrity and feedback.

   Designers of database schema are cautioned against using name-based
   UUIDs (Section 5.3/Section (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
   particular value will never change, which then later turns out to be an
   incorrect assumption.  Postal codes, license or other identification
   numbers, and numerous other such identifiers seem unique and
   unchanging at a given point time; time -- only to later turn out to have edge cases
   where they need to change.  The subsequent change of the identifier,
   used as a "name" input for name-based UUIDs, can invalidate a given
   database structure.  In such scenarios scenarios, it is observed that using any
   non-name-based UUID version would have resulted in the field in
   question being placed somewhere that would have been easier to adapt
   to such changes (primary key excluded from this statement).  The
   general advice is to avoid name-based UUID natural keys and instead and, instead,
   to utilize time-based UUID surrogate keys based on the aforementioned
   problems detailed in this section.

7.  IANA Considerations

   All references to [RFC4122] in the IANA registries should be (outside of those
   created by this document) have been replaced with references to this document.  References to [RFC4122] document's
   Section 4.1.2 should be updated to refer to this document's
   Section 4.

   The
   document, including the IANA URN namespace registration
   [URNNamespaces] for UUID filed in UUID.  References to Section 4.1.2 of [RFC4122] should be
   have been updated to reference refer to Section 4 of this document.

   Finally

   Finally, IANA should track UUID Subtypes and Special Case "Namespace
   IDs Values" as specified in Section Sections 7.1 and Section 7.2. 7.2 at the following
   location: <https://www.iana.org/assignments/uuid>.

   When evaluating requests, the designated expert(s) expert should consider
   community feedback, how well-defined is the reference specification, specification is,
   and this specification's requirements.  Vendor-specific, application-
   specific, and deployment-specific values are unable to be registered.
   Specification documents should be published in a stable, freely
   available manner (ideally (ideally, located with a URL) but need not be
   standards.  The designated experts expert will either approve or deny the
   registration request, request and communicate their this decision to IANA.  Denials
   should include an explanation and, if applicable, suggestions as to
   how to make the request successful.

7.1.  IANA UUID Subtype Registry and Registration

   This specification defines the "UUID Subtype" Subtypes" registry for common, common
   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], |
   |                      |    |         | / IETF         | This document RFC 9562   |
     +----------------------+----+---------+---------+---------------+
   +----------------------+----+---------+----------------+------------+
   | DCE Security         | 2  | version | OSF DCE        | [C309],    |
   |                      |    |         | / IETF         | [C311]     |
     +----------------------+----+---------+---------+---------------+
   +----------------------+----+---------+----------------+------------+
   | MD5 Name-based       | 3  | version | OSF DCE        | [RFC4122], |
   |                      |    |         | / IETF         | This document RFC 9562   |
     +----------------------+----+---------+---------+---------------+
   +----------------------+----+---------+----------------+------------+
   | Random               | 4  | version | OSF DCE        | [RFC4122], |
   |                      |    |         | / IETF         | This document RFC 9562   |
     +----------------------+----+---------+---------+---------------+
   +----------------------+----+---------+----------------+------------+
   | SHA-1 Name-based     | 5  | version | OSF DCE        | [RFC4122], |
   |                      |    |         | / IETF         | This document RFC 9562   |
     +----------------------+----+---------+---------+---------------+
   +----------------------+----+---------+----------------+------------+
   | Reordered Gregorian  | 6  | version | OSF DCE        | This document RFC 9562   |
   | Time-based           |    |         | / IETF         |            |
     +----------------------+----+---------+---------+---------------+
   +----------------------+----+---------+----------------+------------+
   | Unix Time-based      | 7  | version | OSF DCE        | This document RFC 9562   |
   |                      |    |         | / IETF         |            |
     +----------------------+----+---------+---------+---------------+
   +----------------------+----+---------+----------------+------------+
   | Custom               | 8  | version | OSF DCE        | This document RFC 9562   |
   |                      |    |         | / IETF         |            |
     +----------------------+----+---------+---------+---------------+
   +----------------------+----+---------+----------------+------------+

                        Table 4: IANA UUID Subtypes

   This table may be extended by the "Standards Action" policy, Standards Action as per [RFC8126].

   For designated experts:

   *  The minimum and maximum "ID" value for the subtype "version"
      within the "OSF DCE / IETF" variant is 0 through 15.  The
      versions, versions
      within Table 1, 1 described as "Reserved for future definition" or
      "unused" are omitted from this IANA registry until properly
      defined.

   *  The "Subtype" column is free-form text however text.  However, at the time of this
      publication only
      publication, "version" and "family" are the only known UUID
      subtypes.  The "family" subtype is part of the "Apollo NCS"
      variant space
      (Both (both are outside the scope of this specification).
      The Microsoft variant may have subtyping mechanisms defined however defined;
      however, they are unknown and outside of the scope of this
      specification.  Similarly, the final "Reserved for future
      definition" variant may introduce new subtyping logic at a future
      date.  Subtype IDs are permitted to overlap, that overlap.  That is, an ID of
      "1" may exist in multiple variant spaces.

   *  The "Variant" column is free-form text however text.  However, it is likely
      that one of four values will be included.  The included: the first three are "OSF
      DCE / IETF", "Apollo NCS", "Microsoft".  The and "Microsoft", and the final variant
      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

   This specification defines the "UUID Namespace ID" IDs" registry for
   common, widely used Namespace ID values.

   The full details of this registration, including information for
   designated experts, can be found in Section 6.6.

8.  Security Considerations

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

   Implementations MUST NOT assume that it is easy to determine if a
   UUID has been slightly modified in order to redirect a reference to
   another object.  Humans do not have the ability to easily check the
   integrity of a UUID by simply glancing at it.

   MAC addresses pose inherent security risks around privacy and SHOULD
   NOT be used within a UUID.  Instead CSPRNG data SHOULD be selected
   from a source with sufficient entropy to ensure guaranteed uniqueness
   among UUID generation.  See Section Sections 6.9 and Section 6.10 for more
   information.

   Timestamps embedded in the UUID do pose a very small attack surface.
   The timestamp in conjunction with an embedded counter does signal the
   order of creation for a given UUID and its corresponding data but
   does not define anything about the data itself or the application as
   a whole.  If UUIDs are required for use with any security operation
   within an application context in any shape or form form, then UUIDv4,
   Section 5.4 UUIDv4
   (Section 5.4) SHOULD be utilized.

   See [RFC6151] for MD5 Security Considerations security considerations and [RFC6194] for SHA-1
   security considerations.

9.  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, 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.

9.1.  Normative References

   [C309]     "DCE:     X/Open Company Limited, "X/Open DCE: Remote Procedure
              Call", ISBN 1-85912-041-5, Open Group CAE Specification C309, ISBN 1-85912-041-5,
              August 1994,
              <https://pubs.opengroup.org/onlinepubs/9696999099/
              toc.pdf>.

   [C311]     The Open Group, "DCE 1.1: Authentication and Security
              Services", Open Group CAE Specification C311, August 1997,
              <https://pubs.opengroup.org/onlinepubs/9696989899/
              toc.pdf>.

   [FIPS180-4]
              National Institute of Standards and Technology, Technology (NIST),
              "Secure Hash Standard", Standard (SHS)", FIPS PUB 180-4,
              DOI 10.6028/NIST.FIPS.180-4, August 2015,
              <https://nvlpubs.nist.gov/nistpubs/FIPS/
              NIST.FIPS.180-4.pdf>.

   [FIPS202]  National Institute of Standards and Technology, Technology (NIST),
              "SHA-3 Standard: Permutation-Based Hash and Extendable-Output Extendable-
              Output Functions", FIPS PUB 202,
              DOI 10.6028/NIST.FIPS.202, August 2015,
              <https://nvlpubs.nist.gov/nistpubs/FIPS/
              NIST.FIPS.202.pdf>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              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
              (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
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>. <https://www.rfc-editor.org/info/rfc8174>.

   [X667]     ITU-T, "Information Technology, "Procedures technology - Open Systems
              Interconnection - Procedures for the operation of OSI
              Registration Authorities: Generation and registration of
              Universally Unique Identifiers (UUIDs) and their use as
              ASN.1 Object Identifier components"", object identifier components", ISO/IEC 9834-8:2004,
              ITU-T Rec. Recommendation X.667, September 2004.

10.2.

9.2.  Informative References

   [COMBGUID] Tallent, R., "Creating sequential GUIDs in C# for MSSQL or PostgreSql", Commit
              commit 2759820, December 2020,
              <https://github.com/richardtallent/RT.Comb>.

   [CUID]     Elliott, E.,     "Collision-resistant ids optimized for horizontal scaling
              and performance.", Commit commit 215b27b, October 2020,
              <https://github.com/ericelliott/cuid>.

   [Elasticflake]
              Pearcy, P., "Sequential UUID / Flake ID generator pulled
              out of elasticsearch common", Commit commit dd71c21, January
              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
              service in Erlang", Commit commit 15c933a, February 2017,
              <https://github.com/boundary/flake>.

   [FlakeID]  Pawlak, T.,  "Flake ID Generator", Commit commit fcd6a2f, April 2020,
              <https://github.com/T-PWK/flake-idgen>.

   [IBM_NCS]  IBM, "uuid_gen Command (NCS)", 23 March 2023,
              <https://www.ibm.com/docs/en/aix/7.1?topic=u-uuid-gen-
              command-ncs>.

   [IEEE754]  IEEE, "IEEE Standard for Floating-Point Arithmetic.",
              Series IEEE
              Std 754-2019, DOI 10.1109/IEEESTD.2019.8766229, July 2019,
              <https://standards.ieee.org/ieee/754/6210/>.

   [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 commit bf376a7,
              July 2020, <https://github.com/segmentio/ksuid>.

   [LexicalUUID]
              Twitter, "A Scala client for Cassandra", "Cassie", commit f6da4e0, November 2012,
              <https://github.com/twitter-archive/cassie>.

   [Microsoft]
              Microsoft, "curly braced "2.3.4.3 GUID string", 3 - Curly Braced String
              Representation", April 2023,
              <https://learn.microsoft.com/en-
              us/openspecs/windows_protocols/ms-dtyp/a66edeb1-52a0-4d64-
              a93b-2f5c833d7d92>. <https://learn.microsoft.com/
              en-us/openspecs/windows_protocols/ms-
              dtyp/222af2d3-5c00-4899-bc87-ed4c6515e80d>.

   [MS_COM_GUID]
              Chen, R., "Why does COM express GUIDs in a mix of big-
              endian and little-endian? Why can’t can't it just pick a side
              and stick with it?", 28 September 2022,
              <https://devblogs.microsoft.com/
              oldnewthing/20220928-00/?p=107221>.

   [ObjectID] MongoDB, "ObjectId - MongoDB Manual", "ObjectId",
              <https://docs.mongodb.com/manual/reference/method/
              ObjectId/>.

   [orderedUuid]
              Cabrera, I. B., "Laravel: The mysterious "Ordered UUID"",
              January 2020, <https://itnext.io/laravel-the-mysterious-
              ordered-uuid-29e7500b4f8>.

   [pushID]   Google,   Lehenbauer, M., "The 2^120 Ways to Ensure Unique
              Identifiers", February 2015, <https://firebase.googleblog.com/2015/02/
              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 "uuid - UUID objects according to RFC", 23 May 2023, RFC 4122",
              <https://docs.python.org/3/library/uuid.html>.

   [RANDOM]   Occil, P., "Random Number Generator Recommendations for
              Applications", June 2023,
              <https://peteroupc.github.io/random.html>.

   [RFC1321]  Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
              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
              Resource Locators (URL)", RFC 1738, DOI 10.17487/RFC1738,
              December 1994, <https://www.rfc-editor.org/rfc/rfc1738>. <https://www.rfc-editor.org/info/rfc1738>.

   [RFC4086]  Eastlake 3rd, D., Schiller, J., and S. Crocker,
              "Randomness Requirements for Security", BCP 106, RFC 4086,
              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
              Unique IDentifier (UUID) URN Namespace", RFC 4122,
              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
              Specifications: ABNF", STD 68, RFC 5234,
              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
              for the MD5 Message-Digest and the HMAC-MD5 Algorithms",
              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
              Considerations for the SHA-0 and SHA-1 Message-Digest
              Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011,
              <https://www.rfc-editor.org/rfc/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>.
              <https://www.rfc-editor.org/info/rfc6194>.

   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
              Writing an IANA Considerations Section in RFCs", BCP 26,
              RFC 8126, DOI 10.17487/RFC8126, June 2017,
              <https://www.rfc-editor.org/rfc/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>.
              <https://www.rfc-editor.org/info/rfc8126>.

   [RFC8937]  Cremers, C., Garratt, L., Smyshlyaev, S., Sullivan, N.,
              and C. Wood, "Randomness Improvements for Security
              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]
              Instagram Engineering, "Sharding & IDs at Instagram",
              December 2012, <https://instagram-engineering.com/
              sharding-ids-at-instagram-1cf5a71e5a5c>.

   [SID]      Chilton, A.,      "sid : generate sortable identifiers", Commit 660e947,
              June 2019, <https://github.com/chilts/sid>.

   [Snowflake]
              Twitter, "Snowflake is a network service for generating
              unique ID numbers at high scale with some simple
              guarantees.", Commit b3f6a3c, commit ec40836, May 2014,
              <https://github.com/twitter-
              archive/snowflake/releases/tag/snowflake-2010>.
              <https://github.com/twitter-archive/snowflake>.

   [Sonyflake]
              Sony, "A distributed unique ID generator inspired by
              Twitter's Snowflake", Commit commit 848d664, August 2020,
              <https://github.com/sony/sonyflake>.

   [ULID]     Feerasta, A.,     "Universally Unique Lexicographically Sortable
              Identifier", Commit d0c7170, May 2019,
              <https://github.com/ulid/spec>.

   [URNNamespaces]
              IANA, "Uniform Resource Names (URN) Namespaces", 18
              November 2022, <https://www.iana.org/assignments/urn-
              namespaces/urn-namespaces.xhtml>.
              <https://www.iana.org/assignments/urn-namespaces/>.

   [X500]     ITU-T, "Information technology  - Open Systems
              Interconnection  - The Directory: Overview of concepts,
              models and services", ISO/IEC 9594-1, ITU-T Rec.
              Recommendation X.500, October 2019.

   [X660]     ITU-T, "Information technology  - Procedures for the
              operation of object identifier registration authorities:
              General procedures and top arcs of the international
              object identifier tree", ISO/IEC 9834-1, ITU-T Rec.
              Recommendation X.660, July 2011.

   [X680]     ITU-T, "Information Technology - Abstract Syntax Notation
              One (ASN.1) & ASN.1 encoding rules", ISO/IEC 8824-1:2021,
              ITU-T Rec. Recommendation X.680, February 2021.

   [XID]      Poitrey, O.,      "Globally Unique ID Generator",
              Commit commit efa678f, October
              2020, <https://github.com/rs/xid>.

Appendix A.  Test Vectors

   Both UUIDv1 and UUIDv6 test vectors utilize the same 60 bit 60-bit
   timestamp: 0x1EC9414C232AB00 (138648505420000000) Tuesday, February
   22, 2022 2:22:22.000000 PM GMT-05:00 GMT-05:00.

   Both UUIDv1 and UUIDv6 utilize the same values in clock_seq, clock_seq and
   node.  All node;
   all of which have been generated with random data.  For the
   randomized node, the least significant bit of the first octet is set
   to a value of 1 as per Section 6.10.  Thus  Thus, the starting value
   0x9E6BDECED846 was changed to 0x9F6BDECED846.

   The pseudocode used for converting from a 64 bit 64-bit Unix timestamp to a
   100ns
   100 ns Gregorian timestamp value has been left in the document for
   reference purposes.

   # Gregorian to Unix Gregorian-to-Unix Offset:
   # The number of 100-ns 100 ns intervals between the
   # UUID epoch Epoch 1582-10-15 00:00:00
   # and the Unix epoch Epoch 1970-01-01 00:00:00
   # Greg_Unix_offset = 0x01b21dd213814000 or 122192928000000000

   # Unix 64 bit 64-bit Nanosecond Timestamp:
   # Unix NS: Tuesday, February 22, 2022 2:22:22 PM GMT-05:00
   # Unix_64_bit_ns = 0x16D6320C3D4DCC00 or 1645557742000000000

   # Unix Nanosecond precision to Gregorian 100-nanosecond intervals
   # Greg_100_ns = (Unix_64_bit_ns/100)+Greg_Unix_offset

   # Work:
   # Greg_100_ns = (1645557742000000000/100)+122192928000000000
   # Unix_64_bit_ns = (138648505420000000-122192928000000000)*100

   # Final:
   # Greg_100_ns = 0x1EC9414C232AB00 or 138648505420000000

                Figure 15: Test Vector Timestamp Pseudo-code Pseudocode

A.1.  Example of a UUIDv1 Value

   -------------------------------------------
   field      bits value
   -------------------------------------------
   time_low   32   0xC232AB00
   time_mid   16   0x9414
   ver         4   0x1
   time_high  12   0x1EC
   var         2   0b10
   clock_seq  14   0b11, 0x3C8
   node       48   0x9F6BDECED846
   -------------------------------------------
   total      128
   -------------------------------------------
   final: C232AB00-9414-11EC-B3C8-9F6BDECED846

                   Figure 16: UUIDv1 Example Test Vector

A.2.  Example of a UUIDv3 Value

   The MD5 computation from is detailed in Figure 17 using the DNS
   Namespace ID value and the Name "www.example.com". while the  The field mapping
   and all values are illustrated in Figure 18.  Finally  Finally, to further
   illustrate the bit swapping for version and variant variant, see Figure 19.

   Namespace (DNS):  6ba7b810-9dad-11d1-80b4-00c04fd430c8
   Name:             www.example.com
   ------------------------------------------------------
   MD5:              5df418813aed051548a72f4a814cf09e

                       Figure 17: UUIDv3 Example MD5

   -------------------------------------------
   field     bits value
   -------------------------------------------
   md5_high  48   0x5df418813aed
   ver        4   0x3
   md5_mid   12   0x515
   var        2   0b10
   md5_low   62   0b00, 0x8a72f4a814cf09e
   -------------------------------------------
   total     128
   -------------------------------------------
   final: 5df41881-3aed-3515-88a7-2f4a814cf09e

                   Figure 18: UUIDv3 Example Test Vector

   MD5 hex and dash:      5df41881-3aed-0515-48a7-2f4a814cf09e
   Ver and Var Overwrite: xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx
   Final:                 5df41881-3aed-3515-88a7-2f4a814cf09e

                Figure 19: UUIDv3 Example Ver Var bit swaps Ver/Var Bit Swaps

A.3.  Example of a UUIDv4 Value

   This UUIDv4 example was created by generating 16 bytes of random data
   resulting in the hexadecimal value of
   919108F752D133205BACF847DB4148A8.  This is then used to fill out the
   fields as shown in Figure 20.

   Finally

   Finally, to further illustrate the bit swapping for version and
   variant
   variant, see Figure 21.

   -------------------------------------------
   field     bits value
   -------------------------------------------
   random_a  48   0x919108f752d1
   ver        4   0x4
   random_b  12   0x320
   var        2   0b10
   random_c  62   0b01, 0xbacf847db4148a8
   -------------------------------------------
   total     128
   -------------------------------------------
   final: 919108f7-52d1-4320-9bac-f847db4148a8

                   Figure 20: UUIDv4 Example Test Vector

   Random hex:            919108f752d133205bacf847db4148a8
   Random hex and dash:   919108f7-52d1-3320-5bac-f847db4148a8
   Ver and Var Overwrite: xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx
   Final:                 919108f7-52d1-4320-9bac-f847db4148a8

                Figure 21: UUIDv4 Example Ver/Var bit swaps Bit Swaps

A.4.  Example of a UUIDv5 Value

   The SHA-1 computation from form is detailed in Figure 22 22, using the DNS
   Namespace ID value and the Name "www.example.com". while the  The field mapping
   and all values are illustrated in Figure 23.  Finally  Finally, to further
   illustrate the bit swapping for version and variant and the
   unused/discarded unused/
   discarded part of the SHA-1 value value, see Figure 24.

   Namespace (DNS):  6ba7b810-9dad-11d1-80b4-00c04fd430c8
   Name:             www.example.com
   ----------------------------------------------------------
   SHA-1:            2ed6657de927468b55e12665a8aea6a22dee3e35

                      Figure 22: UUIDv5 Example SHA-1

   -------------------------------------------
   field      bits value
   -------------------------------------------
   sha1_high  48   0x2ed6657de927
   ver         4   0x5
   sha1_mid   12   0x68b
   var         2   0b10
   sha1_low   62   0b01, 0x5e12665a8aea6a2
   -------------------------------------------
   total      128
   -------------------------------------------
   final: 2ed6657d-e927-568b-95e1-2665a8aea6a2

                   Figure 23: UUIDv5 Example Test Vector

   SHA-1 hex and dash:    2ed6657d-e927-468b-55e1-2665a8aea6a2-2dee3e35
   Ver and Var Overwrite: xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx
   Final:                 2ed6657d-e927-568b-95e1-2665a8aea6a2
   Discarded:                                                 -2dee3e35

      Figure 24: UUIDv5 Example Ver/Var bit swaps Bit Swaps and discarded Discarded SHA-1
                                  segment
                                  Segment

A.5.  Example of a UUIDv6 Value

   -------------------------------------------
   field       bits value
   -------------------------------------------
   time_high   32   0x1EC9414C
   time_mid    16   0x232A
   ver          4   0x6
   time_high   12   0xB00
   var          2   0b10
   clock_seq   14   0b11, 0x3C8
   node        48   0x9F6BDECED846
   -------------------------------------------
   total       128
   -------------------------------------------
   final: 1EC9414C-232A-6B00-B3C8-9F6BDECED846

                   Figure 25: UUIDv6 Example Test Vector

A.6.  Example of a UUIDv7 Value

   This example UUIDv7 test vector utilizes a well-known Unix epoch Epoch
   timestamp with millisecond precision to fill the first 48 bits.

   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 GMT-05:00,
   represented as 0x017F22E279B0 or 1645557742000 1645557742000.

   -------------------------------------------
   field       bits value
   -------------------------------------------
   unix_ts_ms  48   0x017F22E279B0
   ver          4   0x7
   rand_a      12   0xCC3
   var          2   0b10
   rand_b      62   0b01, 0x8C4DC0C0C07398F
   -------------------------------------------
   total       128
   -------------------------------------------
   final: 017F22E2-79B0-7CC3-98C4-DC0C0C07398F

                   Figure 26: UUIDv7 Example Test Vector

Appendix B.  Illustrative Examples

   The following sections contain illustrative examples which that serve to
   show how one may use UUIDv8 Section 5.8 (Section 5.8) for custom and/or
   experimental application based application-based logic.  The examples below have not
   been through the same rigorous testing, prototyping, and feedback
   loop that other algorithms in this document have undergone.  The
   authors encouraged implementors encourage implementers to create your their own UUIDv8 algorithm
   rather than use the items defined in this section.

B.1.  Example of a UUIDv8 Value (time-based) (Time-Based)

   This example UUIDv8 test vector utilizes a well-known 64 bit 64-bit Unix
   epoch
   Epoch timestamp with 10ns 10 ns precision, truncated to the least- least
   significant, right-most, rightmost bits to fill the first 60 bits of custom_a and custom_b
   custom_b, while setting the version bits between these two segments
   to the version value of 8.

   The variant bits are set set; and the final segment, custom_c, is filled
   with random data.

   Timestamp is Tuesday, February 22, 2022 2:22:22.000000 PM GMT-05:00 GMT-05:00,
   represented as 0x2489E9AD2EE2E00 or 164555774200000000 (10ns-steps). (10 ns-steps).

   -------------------------------------------
   field     bits value
   -------------------------------------------
   custom_a  48   0x2489E9AD2EE2
   ver        4   0x8
   custom_b  12   0xE00
   var        2   0b10
   custom_c  62   0b00, 0xEC932D5F69181C0
   -------------------------------------------
   total     128
   -------------------------------------------
   final: 2489E9AD-2EE2-8E00-8EC9-32D5F69181C0

         Figure 27: UUIDv8 Example Time-based Time-Based Illustrative Example

B.2.  Example of a UUIDv8 Value (name-based) (Name-Based)

   As per Section 5.5 5.5, name-based UUIDs that desire want to use modern hashing
   algorithms MUST be created within the UUIDv8 space.  These MAY
   leverage newer hashing algorithms such as SHA-256 or SHA-512 (as
   defined by [FIPS180-4], [FIPS180-4]), SHA-3 or SHAKE (as defined by [FIPS202], [FIPS202]), or
   even algorithms that have not been defined yet.

   A SHA-256 version of the SHA-1 computation in Appendix A.4 is
   detailed in Figure 28 as an illustrative example detailing how this
   can be achieved.  The creation of the name-based UUIDv8 value in this
   section follows the same logic defined in Section 5.5 with the
   difference being SHA-256 in place of SHA-1.

   The field mapping and all values are illustrated in Figure 29.
   Finally
   Finally, to further illustrate the bit swapping for version and
   variant and the unused/discarded part of the SHA-256 value value, see
   Figure 30.  An important note for secure hashing algorithms that
   produce outputs of an arbitrary size, such as those found in SHAKE,
   is that the output hash MUST be 128 bits or larger.

   Namespace (DNS):       6ba7b810-9dad-11d1-80b4-00c04fd430c8
   Name:                  www.example.com
   ----------------------------------------------------------------
   SHA-256:
   5c146b143c524afd938a375d0df1fbf6fe12a66b645f72f6158759387e51f3c8

                      Figure 28: UUIDv8 Example SHA256

   -------------------------------------------
   field     bits value
   -------------------------------------------
   custom_a  48   0x5c146b143c52
   ver        4   0x8
   custom_b  12   0xafd
   var        2   0b10
   custom_c  62   0b00, 0x38a375d0df1fbf6
   -------------------------------------------
   total     128
   -------------------------------------------
   final: 5c146b14-3c52-8afd-938a-375d0df1fbf6

     Figure 29: UUIDv8 Example Name-Based SHA-256 Illustrative Example

A: 5c146b14-3c52-4afd-938a-375d0df1fbf6-fe12a66b645f72f6158759387e51f3c8
B: xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx
C: 5c146b14-3c52-8afd-938a-375d0df1fbf6
D:                                     -fe12a66b645f72f6158759387e51f3c8

  Figure 30: UUIDv8 Example Ver/Var bit swaps Bit Swaps and discarded Discarded SHA-256
                               segment
                               Segment

   Examining Figure 30:

   *  Line A details the full SHA-256 as a hexadecimal value with the
      dashes inserted.

   *  Line B details the version and variant hexadecimal positions positions,
      which must be overwritten.

   *  Line C details the final value after the ver/var ver and var have been
      overwritten.

   *  Line D details the discarded, discarded leftover values from the original
      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

   Kyzer R. Davis
   Cisco Systems
   Email: kydavis@cisco.com

   Brad G. Peabody
   Uncloud
   Email: brad@peabody.io

   P. Leach
   University of Washington
   Email: pjl7@uw.edu