doc: Add RFC documents

1 files changed, 2485 insertions, 0 deletions

diff --git a/doc/rfc/rfc9562.txt b/doc/rfc/rfc9562.txt
new file mode 100644
index 0000000..32215b8
--- /dev/null
+++ b/doc/rfc/rfc9562.txt
@@ -0,0 +1,2485 @@
+
+
+
+
+Internet Engineering Task Force (IETF)                          K. Davis
+Request for Comments: 9562                                 Cisco Systems
+Obsoletes: 4122                                               B. Peabody
+Category: Standards Track                                        Uncloud
+ISSN: 2070-1721                                                 P. Leach
+                                                University of Washington
+                                                                May 2024
+
+
+                 Universally Unique IDentifiers (UUIDs)
+
+Abstract
+
+   This specification defines UUIDs (Universally Unique IDentifiers) --
+   also known as GUIDs (Globally Unique IDentifiers) -- and a Uniform
+   Resource Name namespace for UUIDs.  A UUID is 128 bits long and is
+   intended to guarantee uniqueness across space and time.  UUIDs were
+   originally used in the Apollo Network Computing System (NCS), later
+   in the Open Software Foundation's (OSF's) Distributed Computing
+   Environment (DCE), and then in Microsoft Windows platforms.
+
+   This specification is derived from the OSF DCE specification with the
+   kind permission of the OSF (now known as "The Open Group").
+   Information from earlier versions of the OSF DCE specification have
+   been incorporated into this document.  This document obsoletes RFC
+   4122.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   https://www.rfc-editor.org/info/rfc9562.
+
+Copyright Notice
+
+   Copyright (c) 2024 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (https://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Revised BSD License text as described in Section 4.e of the
+   Trust Legal Provisions and are provided without warranty as described
+   in the Revised BSD License.
+
+Table of Contents
+
+   1.  Introduction
+   2.  Motivation
+     2.1.  Update Motivation
+   3.  Terminology
+     3.1.  Requirements Language
+     3.2.  Abbreviations
+   4.  UUID Format
+     4.1.  Variant Field
+     4.2.  Version Field
+   5.  UUID Layouts
+     5.1.  UUID Version 1
+     5.2.  UUID Version 2
+     5.3.  UUID Version 3
+     5.4.  UUID Version 4
+     5.5.  UUID Version 5
+     5.6.  UUID Version 6
+     5.7.  UUID Version 7
+     5.8.  UUID Version 8
+     5.9.  Nil UUID
+     5.10. Max UUID
+   6.  UUID Best Practices
+     6.1.  Timestamp Considerations
+     6.2.  Monotonicity and Counters
+     6.3.  UUID Generator States
+     6.4.  Distributed UUID Generation
+     6.5.  Name-Based UUID Generation
+     6.6.  Namespace ID Usage and Allocation
+     6.7.  Collision Resistance
+     6.8.  Global and Local Uniqueness
+     6.9.  Unguessability
+     6.10. UUIDs That Do Not Identify the Host
+     6.11. Sorting
+     6.12. Opacity
+     6.13. DBMS and Database Considerations
+   7.  IANA Considerations
+     7.1.  IANA UUID Subtype Registry and Registration
+     7.2.  IANA UUID Namespace ID Registry and Registration
+   8.  Security Considerations
+   9.  References
+     9.1.  Normative References
+     9.2.  Informative References
+   Appendix A.  Test Vectors
+     A.1.  Example of a UUIDv1 Value
+     A.2.  Example of a UUIDv3 Value
+     A.3.  Example of a UUIDv4 Value
+     A.4.  Example of a UUIDv5 Value
+     A.5.  Example of a UUIDv6 Value
+     A.6.  Example of a UUIDv7 Value
+   Appendix B.  Illustrative Examples
+     B.1.  Example of a UUIDv8 Value (Time-Based)
+     B.2.  Example of a UUIDv8 Value (Name-Based)
+   Acknowledgements
+   Authors' Addresses
+
+1.  Introduction
+
+   This specification defines a Uniform Resource Name namespace for
+   Universally Unique IDentifiers (UUIDs), also known as Globally Unique
+   IDentifiers (GUIDs).  A UUID is 128 bits long and requires no central
+   registration process.
+
+   The use of UUIDs is extremely pervasive in computing.  They comprise
+   the core identifier infrastructure for many operating systems such as
+   Microsoft Windows and applications such as the Mozilla Web browser;
+   in many cases, they can become exposed in many non-standard ways.
+
+   This specification attempts to standardize that practice as openly as
+   possible and in a way that attempts to benefit the entire Internet.
+   The information here is meant to be a concise guide for those wishing
+   to implement services using UUIDs either in combination with URNs
+   [RFC8141] or otherwise.
+
+   There is an ITU-T Recommendation and an ISO/IEC Standard [X667] that
+   are derived from [RFC4122].  Both sets of specifications have been
+   aligned and are fully technically compatible.  Nothing in this
+   document should be construed to override the DCE standards that
+   defined UUIDs.
+
+2.  Motivation
+
+   One of the main reasons for using UUIDs is that no centralized
+   authority is required to administer them (although two formats may
+   leverage optional IEEE 802 Node IDs, others do not).  As a result,
+   generation on demand can be completely automated and used for a
+   variety of purposes.  The UUID generation algorithm described here
+   supports very high allocation rates of 10 million per second per
+   machine or more, if necessary, so that they could even be used as
+   transaction IDs.
+
+   UUIDs are of a fixed size (128 bits), which is reasonably small
+   compared to other alternatives.  This lends itself well to sorting,
+   ordering, and hashing of all sorts; storing in databases; simple
+   allocation; and ease of programming in general.
+
+   Since UUIDs are unique and persistent, they make excellent URNs.  The
+   unique ability to generate a new UUID without a registration process
+   allows for UUIDs to be one of the URNs with the lowest minting cost.
+
+2.1.  Update Motivation
+
+   Many things have changed in the time since UUIDs were originally
+   created.  Modern applications have a need to create and utilize UUIDs
+   as the primary identifier for a variety of different items in complex
+   computational systems, including but not limited to database keys,
+   file names, machine or system names, and identifiers for event-driven
+   transactions.
+
+   One area in which UUIDs have gained popularity is database keys.
+   This stems from the increasingly distributed nature of modern
+   applications.  In such cases, "auto-increment" schemes that are often
+   used by databases do not work well: the effort required to coordinate
+   sequential numeric identifiers across a network can easily become a
+   burden.  The fact that UUIDs can be used to create unique, reasonably
+   short values in distributed systems without requiring coordination
+   makes them a good alternative, but UUID versions 1-5, which were
+   originally defined by [RFC4122], lack certain other desirable
+   characteristics, such as:
+
+   1.  UUID versions that are not time ordered, such as UUIDv4
+       (described in Section 5.4), have poor database-index locality.
+       This means that new values created in succession are not close to
+       each other in the index; thus, they require inserts to be
+       performed at random locations.  The resulting negative
+       performance effects on the common structures used for this
+       (B-tree and its variants) can be dramatic.
+
+   2.  The 100-nanosecond Gregorian Epoch used in UUIDv1 timestamps
+       (described in Section 5.1) is uncommon and difficult to represent
+       accurately using a standard number format such as that described
+       in [IEEE754].
+
+   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 Media
+       Access Control (MAC) address in the node field of UUIDv1.
+       Exposed MAC addresses can be used as an attack surface to locate
+       network interfaces and reveal various other information about
+       such machines (minimally, the manufacturer and, potentially,
+       other details).  Additionally, with the advent of virtual
+       machines and containers, uniqueness of the MAC address is no
+       longer guaranteed.
+
+   5.  Many of the implementation details specified in [RFC4122]
+       involved trade-offs that are neither possible to specify for all
+       applications nor necessary to produce interoperable
+       implementations.
+
+   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 and encoding, timestamp type, timestamp
+   format, timestamp accuracy, node format and components, collision
+   handling, and multi-timestamp tick generation sequencing:
+
+   1.   [ULID]
+   2.   [LexicalUUID]
+   3.   [Snowflake]
+   4.   [Flake]
+   5.   [ShardingID]
+   6.   [KSUID]
+   7.   [Elasticflake]
+   8.   [FlakeID]
+   9.   [Sonyflake]
+   10.  [orderedUuid]
+   11.  [COMBGUID]
+   12.  [SID]
+   13.  [pushID]
+   14.  [XID]
+   15.  [ObjectID]
+   16.  [CUID]
+
+   An inspection of these implementations and the issues described above
+   has led to this document, in which new UUIDs are adapted to address
+   these issues.
+
+   Further, [RFC4122] itself was in need of an overhaul to address a
+   number of topics such as, but not limited to, the following:
+
+   1.  Implementation of miscellaneous errata reports.  Mostly around
+       bit-layout clarifications, which lead to inconsistent
+       implementations [Err1957], [Err3546], [Err4975], [Err4976],
+       [Err5560], etc.
+
+   2.  Decoupling other UUID versions from the UUIDv1 bit layout so that
+       fields like "time_hi_and_version" do not need to be referenced
+       within a UUID that is not time based while also providing
+       definition sections similar to that for UUIDv1 for UUIDv3,
+       UUIDv4, and UUIDv5.
+
+   3.  Providing implementation best practices around many real-world
+       scenarios and corner cases observed by existing and prototype
+       implementations.
+
+   4.  Addressing security best practices and considerations for the
+       modern age as it pertains to MAC addresses, hashing algorithms,
+       secure randomness, and other topics.
+
+   5.  Providing implementations a standard-based option for
+       implementation-specific and/or experimental UUID designs.
+
+   6.  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:
+
+   ABNF          Augmented Backus-Naur Form
+
+   CSPRNG        Cryptographically Secure Pseudorandom Number Generator
+
+   DBMS          Database Management System
+
+   IEEE          Institute of Electrical and Electronics 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 message digest of 160
+                 bits)
+
+   SHA-3         Secure Hash Algorithm 3 (arbitrary size)
+
+   SHA-224       Secure Hash Algorithm 2 with message digest size of 224
+                 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
+
+   SHAKE         Secure Hash Algorithm 3 based on the KECCAK algorithm
+
+   URN           Uniform Resource Names
+
+   UTC           Coordinated Universal Time
+
+   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
+
+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.  In terms of these UUID formats and
+   layout, bit definitions start at 0 and end at 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 first (known as "network byte order").
+
+   Saving UUIDs to binary format is done by sequencing all fields in
+   big-endian format.  However, there is a known caveat that Microsoft's
+   Component Object Model (COM) GUIDs leverage little-endian when saving
+   GUIDs.  The discussion of this (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 uppercase or lowercase alphanumeric hexadecimal
+   characters separated by single dashes/hyphens.  When used with
+   databases, please refer to Section 6.13.
+
+   The formal definition of the UUID string representation is provided
+   by the following 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 Section 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
+
+   The same UUID from Figure 1 is represented in binary (Figure 2), as
+   an unsigned integer (Figure 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 as a 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.
+
+   *  [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" 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 | MSB1 | MSB2 | MSB3 | Variant | Description             |
+     +======+======+======+======+=========+=========================+
+     | 0    | x    | x    | x    | 1-7     | Reserved.  Network      |
+     |      |      |      |      |         | Computing System (NCS)  |
+     |      |      |      |      |         | backward compatibility, |
+     |      |      |      |      |         | and includes Nil UUID   |
+     |      |      |      |      |         | 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.  Microsoft    |
+     |      |      |      |      |         | Corporation backward    |
+     |      |      |      |      |         | compatibility.          |
+     +------+------+------+------+---------+-------------------------+
+     | 1    | 1    | 1    | x    | E-F     | Reserved for future     |
+     |      |      |      |      |         | definition and includes |
+     |      |      |      |      |         | Max UUID as 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 | MSB1 | MSB2 | MSB3 | Version | Description                |
+   +======+======+======+======+=========+============================+
+   | 0    | 0    | 0    | 0    | 0       | 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            |
+   |      |      |      |      |         | pseudorandomly generated   |
+   |      |      |      |      |         | 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 10xx Versions Defined by This Specification
+
+   An example version/variant layout for UUIDv4 follows the table where
+   "M" represents the version placement for the hexadecimal
+   representation of 0x4 (0b0100) and the "N" represents the variant
+   placement for one of the four possible hexadecimal representation of
+   variant 10xx: 0x8 (0b1000), 0x9 (0b1001), 0xA (0b1010), 0xB (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 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
+
+   UUIDv1 is a time-based UUID featuring a 60-bit timestamp represented
+   by Coordinated Universal Time (UTC) as a count of 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 that is used to help
+   avoid duplicates that could arise when the clock is set backwards in
+   time or if the Node ID changes.
+
+   The node field consists of an IEEE 802 MAC address, usually the host
+   address or a randomly derived value per Sections 6.9 and 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 starting timestamp.
+      Occupies bits 0 through 31 (octets 0-3).
+
+   time_mid:
+      The middle 16 bits of the 60-bit starting timestamp.  Occupies
+      bits 32 through 47 (octets 4-5).
+
+   ver:
+      The 4-bit version field as defined by Section 4.2, set to 0b0001
+      (1).  Occupies bits 48 through 51 of octet 6.
+
+   time_high:
+      The least significant 12 bits from the 60-bit starting timestamp.
+      Occupies bits 52 through 63 (octets 6-7).
+
+   var:
+      The 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 spatially unique identifier.  Occupies bits 80 through 127
+      (octets 10-15).
+
+   For systems that do not have UTC available but do have the local
+   time, they may use that instead of UTC as long as they do so
+   consistently throughout the system.  However, this is not recommended
+   since generating the UTC from local time only needs a 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
+   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 pseudorandom value.
+
+   Similarly, if the 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 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 IDs
+   that may move or switch from system to system rapidly.  The initial
+   value MUST NOT be correlated to the Node ID.
+
+   Notes about nodes derived 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 pseudorandomly
+      generated value MUST be used; see Sections 6.9 and 6.10.
+
+   *  On systems utilizing a 64-bit MAC address, the least significant,
+      rightmost 48 bits MAY be used.
+
+   *  Systems utilizing an IEEE 802.15.4 16-bit address SHOULD instead
+      utilize their 64-bit MAC address where the least significant,
+      rightmost 48 bits MAY be used.  An alternative is to generate 32
+      bits of random data and postfix at the end of the 16-bit MAC
+      address to create a 48-bit value.
+
+5.2.  UUID Version 2
+
+   UUIDv2 is for DCE Security UUIDs (see [C309] and [C311]).  As such,
+   the definition of these UUIDs is outside the scope of this
+   specification.
+
+5.3.  UUID Version 3
+
+   UUIDv3 is meant for generating UUIDs from names that are drawn from,
+   and unique within, some namespace as per Section 6.5.
+
+   UUIDv3 values are created by computing an MD5 hash [RFC1321] over a
+   given 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 Sections 4.2 and 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 under the heading "A
+   note on names".
+
+   Where possible, UUIDv5 SHOULD be used in lieu of UUIDv3.  For more
+   information on MD5 security 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, leftmost 48 bits from the computed MD5 value.
+      Occupies bits 0 through 47 (octets 0-5).
+
+   ver:
+      The 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,
+      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 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, 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
+
+   UUIDv4 is meant for generating UUIDs from truly random or
+   pseudorandom numbers.
+
+   An implementation may generate 128 bits of random data that is used
+   to fill out the UUID fields in Figure 8.  The UUID version and
+   variant then replace the respective bits as defined by Sections 4.1
+   and 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) and then concatenate the version and variant in the
+   required position.
+
+   For guidelines on random data 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 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 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
+
+   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 hash [FIPS180-4] over
+   a given 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, leftmost 128
+   bits of the SHA-1 value are then used to populate all 128 bits of the
+   UUID layout, and the remaining 32 least significant, rightmost bits
+   of SHA-1 output are discarded.  The UUID version and variant then
+   replace the respective bits as defined by Sections 4.2 and 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 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 UUIDs is provided in Appendix B.2.
+
+   For more information on SHA-1 security 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, leftmost 48 bits from the computed SHA-1 value.
+      Occupies bits 0 through 47 (octets 0-5).
+
+   ver:
+      The 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,
+      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 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 two most significant, leftmost
+      bits of the remaining SHA-1 hash and then using the next 62 most
+      significant, leftmost bits.  Any leftover SHA-1 bits are discarded
+      and unused.  Occupies bits 66 through 127 (octets 8-15).
+
+5.6.  UUID Version 6
+
+   UUIDv6 is a field-compatible version of UUIDv1 (Section 5.1),
+   reordered for improved DB locality.  It is expected that UUIDv6 will
+   primarily be implemented in contexts where UUIDv1 is used.  Systems
+   that do not involve legacy UUIDv1 SHOULD use UUIDv7 (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
+   timestamp value as specified for UUIDv1 in Section 5.1, for UUIDv6
+   the first 48 most significant bits are stored first, followed by the
+   4-bit version (same position), followed by the remaining 12 bits of
+   the original 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 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,
+   see the Section 8.
+
+   The format for the 16-byte, 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 starting timestamp.
+      Occupies bits 0 through 31 (octets 0-3).
+
+   time_mid:
+      The middle 16 bits of the 60-bit starting timestamp.  Occupies
+      bits 32 through 47 (octets 4-5).
+
+   ver:
+      The 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 starting timestamp.  Occupies bits 52 through 63 (octets
+      6-7).
+
+   var:
+      The 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 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
+
+   UUIDv7 features a time-ordered value field derived from the widely
+   implemented and well-known Unix Epoch timestamp source, the number of
+   milliseconds since midnight 1 Jan 1970 UTC, leap seconds excluded.
+   Generally, UUIDv7 has improved entropy characteristics over UUIDv1
+   (Section 5.1) or UUIDv6 (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 big-endian unsigned number of the Unix Epoch timestamp in
+      milliseconds as per Section 6.1.  Occupies bits 0 through 47
+      (octets 0-5).
+
+   ver:
+      The 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 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 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 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
+
+   UUIDv8 provides 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 Sections 4.1 and 4.2.  UUIDv8's uniqueness
+   will be 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 UUIDs.  To be
+   clear, UUIDv8 is not a replacement for UUIDv4 (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 and/or language
+      restrictions that inhibit the use of one of the current UUIDs.
+
+   Appendix 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 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 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 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 UUID.  A Nil UUID can express the concept "no such value
+   here".  Thus, it is reserved for such use as needed for
+   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 UUID is required, but a concept such as "end of UUID list"
+   needs to be expressed and is reserved for such use as needed for
+   implementation-specific situations.
+
+   Note that the Max UUID value falls within the range of the "yet-to-be
+   defined" future UUID variant as per the last row of Table 1 rather
+   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.  Everything else is an implementation
+   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 were topics of great
+   debate while creating UUIDv7 for this specification.  Choosing the
+   right timestamp for your application is very important.  This section
+   will detail some of the most common points on this issue.
+
+   Reliability:
+      Implementations acquire the current timestamp from a reliable
+      source to provide values that are 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, Fuzzing, or Smearing" below.)
+
+   Source:
+      UUIDv1 and UUIDv6 both utilize a Gregorian Epoch timestamp, while
+      UUIDv7 utilizes a Unix Epoch timestamp.  If other timestamp
+      sources or a custom timestamp 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, 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, which is frequently less than the precision offered
+      by the operating system.  With UUIDv1 and UUIDv6, 100 nanoseconds
+      of precision are present, while UUIDv7 features a millisecond
+      level of precision by default within the Unix Epoch that does not
+      exceed the granularity capable in most modern systems.  For other
+      levels of precision, UUIDv8 is available.  Similar to Section 6.2,
+      with UUIDv1 or UUIDv6, a 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 and using that
+      count to construct the low order bits of the timestamp.  The count
+      of the high-resolution timestamp will range between zero and the
+      number of 100-nanosecond intervals per 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.  UUIDv1
+      and UUIDv6 utilize a 60-bit timestamp valid until 5623 AD; UUIDv7
+      features a 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
+      value within a UUID to 1) correct inaccurate clocks, 2) handle
+      leap seconds, or 3) obtain a millisecond value by dividing by 1024
+      (or some other value) for performance 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 interval.
+
+   Padding:
+      When timestamp padding is required, implementations MUST pad the
+      most significant bits (leftmost) with data.  An example for this
+      padding data is to fill the most significant, leftmost bits of a
+      Unix timestamp with zeroes to complete the 48-bit timestamp in
+      UUIDv7.  An alternative approach for padding data is to fill the
+      most significant, leftmost bits with the number of 32-bit Unix
+      timestamp 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 Unix
+      timestamp to the least significant, rightmost 48 bits for UUIDv7.
+
+   Error Handling:
+      If a system overruns the generator by requesting too many UUIDs
+      within a single system-time interval, the UUID service can return
+      an error or stall the UUID generator until the system clock
+      catches up and MUST NOT knowingly return duplicate values due to a
+      counter rollover.  Note that if the processors overrun the UUID
+      generation frequently, additional Node IDs can be allocated to the
+      system, which will permit higher speed allocation by making
+      multiple UUIDs potentially available for each 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 UUIDv6 and 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 or are
+   otherwise concerned about monotonicity with high-frequency UUID
+   generation.
+
+   Fixed Bit-Length Dedicated Counter (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.  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 leftmost bits) of UUIDv7 is
+      used as a fixed bit-length dedicated counter that 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 (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" 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 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 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 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,
+      which sorts monotonically based on time.  Each increasing
+      fractional value will result in an increasing bit field 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 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 or 2^12), multiply it by our
+      millisecond fraction value of 0.4567, and truncate the result to
+      an integer, which gives an integer value of 1870.  Expressed as
+      hexadecimal, it is 0x74E or the binary bits 0b011101001110.  One
+      can then use those 12 bits as the most significant (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; 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; 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.  Then, if any bits are to be used as a clock
+      sequence, they would follow next.
+
+   The following sub-topics cover issues related solely to creating
+   reliable fixed bit-length dedicated counters:
+
+   Fixed Bit-Length Dedicated Counter Seeding:
+      Implementations utilizing the 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 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
+      counter could have the 23 bits in least significant, rightmost
+      position randomly initialized.  The remaining most significant,
+      leftmost counter bit is initialized as zero for the sole purpose
+      of guarding against counter rollovers.
+
+   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 Bit-Length Dedicated Counter Seeding"
+      above that describes allocating a segment of the 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, rightmost position is
+      less than the total length of the random value being incremented.
+      As such, the most significant, 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, 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, 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, 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 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 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 ID can never change (e.g., the
+   network interface card from which the 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 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 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 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 timestamps each time it is called; a per-process
+   generator can allocate from that block until it is exhausted.
+
+6.4.  Distributed UUID Generation
+
+   Some implementations MAY desire the utilization of multi-node,
+   clustered, applications 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
+   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
+   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 pseudorandom Node ID value is placed within
+      the UUID layout.  This identifier helps ensure the 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
+      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, 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 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 term "name-based" in order to maintain consistency
+   with 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 or define such a canonical form for
+      the namespace if it does not exist.  For example, at the time of
+      writing, Domain Name System (DNS) [RFC9499] has three conveyance
+      formats: common (www.example.com), presentation
+      (www.example.com.), and wire format (3www7example3com0).  Looking
+      at [X500] Distinguished Names (DNs), [RFC4122] allowed either
+      text-based or binary DER-based names as inputs.  For Uniform
+      Resource Locators (URLs) [RFC1738], one could provide a Fully
+      Qualified Domain Name (FQDN) with or without the protocol
+      identifier www.example.com or https://www.example.com.  When it
+      comes to Object Identifiers (OIDs) [X660], one could choose dot
+      notation without the leading dot (2.999), choose to include the
+      leading dot (.2.999), or select one of the many formats from
+      [X680] such as OID Internationalized Resource Identifier (OID-IRI)
+      (/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, and dot notation without a leading dot for OID, name-based
+      UUID implementations generally SHOULD allow arbitrary input that
+      will compute 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 details the namespace IDs for some potentially
+   interesting namespaces such as those for DNS [RFC9499], URLs
+   [RFC1738], OIDs [X660], and DNs [X500].
+
+   Further, this section also details allocation, IANA registration, and
+   other details pertinent to Namespace IDs.
+
+   +=========+====================================+=========+==========+
+   |Namespace|Namespace ID Value                  |Name     |Namespace |
+   |         |                                    |Reference|ID        |
+   |         |                                    |         |Reference |
+   +=========+====================================+=========+==========+
+   |DNS      |6ba7b810-9dad-11d1-80b4-00c04fd430c8|[RFC9499]|[RFC4122],|
+   |         |                                    |         |RFC 9562  |
+   +---------+------------------------------------+---------+----------+
+   |URL      |6ba7b811-9dad-11d1-80b4-00c04fd430c8|[RFC1738]|[RFC4122],|
+   |         |                                    |         |RFC 9562  |
+   +---------+------------------------------------+---------+----------+
+   |OID      |6ba7b812-9dad-11d1-80b4-00c04fd430c8|[X660]   |[RFC4122],|
+   |         |                                    |         |RFC 9562  |
+   +---------+------------------------------------+---------+----------+
+   |X500     |6ba7b814-9dad-11d1-80b4-00c04fd430c8|[X500]   |[RFC4122],|
+   |         |                                    |         |RFC 9562  |
+   +---------+------------------------------------+---------+----------+
+
+                           Table 3: Namespace IDs
+
+   Items may be added to this registry using the Specification Required
+   policy as per [RFC8126].
+
+   For designated experts, generally speaking, Namespace IDs are
+   allocated as follows:
+
+   *  The first Namespace ID value, for DNS, was calculated from a time-
+      based UUIDv1 and "6ba7b810-9dad-11d1-80b4-00c04fd430c8", used as a
+      starting point.
+
+   *  Subsequent Namespace ID values increment the least significant,
+      rightmost bit of time_low "6ba7b810" while freezing the rest of
+      the UUID to "9dad-11d1-80b4-00c04fd430c8".
+
+   *  New 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 ID
+      values, is "ffffffff" or "ffffffff-9dad-11d1-80b4-00c04fd430c8",
+      which should be sufficient space for future Namespace ID values.
+
+   Note that the Namespace ID value "6ba7b813-9dad-
+   11d1-80b4-00c04fd430c8" and its usage are not defined by this
+   document or by [RFC4122]; thus, it SHOULD NOT be used as a Namespace
+   ID value.
+
+   New Namespace ID values MUST be documented as per Section 7 if they
+   are to be globally available and fully interoperable.
+   Implementations MAY continue to use vendor-specific, application-
+   specific, and deployment-specific Namespace ID values; but know that
+   interoperability is not guaranteed.  These custom Namespace ID values
+   MUST NOT use the logic above; instead, generating a UUIDv4 or UUIDv7
+   Namespace ID value is RECOMMENDED.  If collision probability
+   (Section 6.7) and uniqueness (Section 6.8) of the final name-based
+   UUID are not a 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-
+   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
+   Sections 6.1 and 6.2.  This is especially true for distributed node
+   collision resistance as defined by Section 6.4.
+
+   There are two example scenarios below that help illustrate the
+   varying seriousness of a collision within an application.
+
+   Low Impact:
+      A UUID collision generated a duplicate log 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 UUIDs defined in this document.
+
+   High Impact:
+      A duplicate key causes an airplane to receive the wrong course,
+      which puts people's lives at risk.  In this scenario, there is no
+      margin for error.  Collisions must be 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 use a shared knowledge scheme, introduced in
+   Section 6.4, as they see fit to extend the uniqueness guaranteed by
+   this specification.
+
+6.9.  Unguessability
+
+   Implementations SHOULD utilize a cryptographically secure
+   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
+   Sections 6.7 and 8 are present in modern UUIDs.
+
+   Further advice on generating cryptographic-quality random numbers can
+   be found in [RFC4086], [RFC8937], and [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 or its use is not desired.
+
+   Implementations MAY leverage MAC address randomization techniques
+   [IEEE802.11bh] as an alternative to the pseudorandom logic provided
+   in this section.
+
+   Alternatively, implementations MAY elect to obtain a 48-bit
+   cryptographic-quality random number as per Section 6.9 to use as the
+   Node ID.  After generating the 48-bit fully randomized node value,
+   implementations MUST set the least significant bit of the first octet
+   of the Node ID to 1.  This bit is the 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 node value and the subsequent bit modification is
+   detailed in Appendix A.  For more information about IEEE 802 address
+   and the unicast or multicast or local/global bits, please review
+   [RFC9542].
+
+   For compatibility with earlier specifications, note that this
+   document uses the unicast or multicast bit instead of the arguably
+   more correct local/global bit because MAC addresses with the local/
+   global bit set or not set are both possible in a network.  This is
+   not the case with the 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 ID using these data is system
+   specific because both the data available and the functions to obtain
+   them are often very system specific.  However, a generic 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 without the
+   need for parsing or introspection.
+
+   Time-ordered monotonic UUIDs benefit from greater database-index
+   locality because the new values are near each other in the index.  As
+   a result, objects are more easily clustered together for better
+   performance.  The real-world differences in this approach of index
+   locality 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, avoiding parsing UUID values unnecessarily is
+   recommended; instead, treat UUIDs as opaquely as possible.  Although
+   application-specific concerns could, of course, require some degree
+   of introspection (e.g., to examine 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 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 UUID
+   values.  Thus, where feasible, UUIDs SHOULD be stored within database
+   applications as the underlying 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 as follows:
+
+   *  Storing 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 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-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 (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 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 -- only later 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, 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,
+   to utilize time-based UUID surrogate keys based on the aforementioned
+   problems detailed in this section.
+
+7.  IANA Considerations
+
+   All references to [RFC4122] in IANA registries (outside of those
+   created by this document) have been replaced with references to this
+   document, including the IANA URN namespace registration
+   [URNNamespaces] for UUID.  References to Section 4.1.2 of [RFC4122]
+   have been updated to refer to Section 4 of this document.
+
+   Finally, IANA should track UUID Subtypes and Special Case "Namespace
+   IDs Values" as specified in Sections 7.1 and 7.2 at the following
+   location: <https://www.iana.org/assignments/uuid>.
+
+   When evaluating requests, the designated expert should consider
+   community feedback, how well-defined the reference 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, located with a URL) but need not be
+   standards.  The designated expert will either approve or deny the
+   registration request and communicate 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 Subtypes" registry for common
+   widely used UUID standards.
+
+   +======================+====+=========+================+============+
+   | Name                 | ID | Subtype | Variant        | Reference  |
+   +======================+====+=========+================+============+
+   | Gregorian Time-based | 1  | version | OSF DCE        | [RFC4122], |
+   |                      |    |         | / IETF         | RFC 9562   |
+   +----------------------+----+---------+----------------+------------+
+   | DCE Security         | 2  | version | OSF DCE        | [C309],    |
+   |                      |    |         | / IETF         | [C311]     |
+   +----------------------+----+---------+----------------+------------+
+   | MD5 Name-based       | 3  | version | OSF DCE        | [RFC4122], |
+   |                      |    |         | / IETF         | RFC 9562   |
+   +----------------------+----+---------+----------------+------------+
+   | Random               | 4  | version | OSF DCE        | [RFC4122], |
+   |                      |    |         | / IETF         | RFC 9562   |
+   +----------------------+----+---------+----------------+------------+
+   | SHA-1 Name-based     | 5  | version | OSF DCE        | [RFC4122], |
+   |                      |    |         | / IETF         | RFC 9562   |
+   +----------------------+----+---------+----------------+------------+
+   | Reordered Gregorian  | 6  | version | OSF DCE        | RFC 9562   |
+   | Time-based           |    |         | / IETF         |            |
+   +----------------------+----+---------+----------------+------------+
+   | Unix Time-based      | 7  | version | OSF DCE        | RFC 9562   |
+   |                      |    |         | / IETF         |            |
+   +----------------------+----+---------+----------------+------------+
+   | Custom               | 8  | version | OSF DCE        | RFC 9562   |
+   |                      |    |         | / IETF         |            |
+   +----------------------+----+---------+----------------+------------+
+
+                        Table 4: IANA UUID Subtypes
+
+   This table may be extended by 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
+      within Table 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, at the time of
+      publication, "version" and "family" are the only known UUID
+      subtypes.  The "family" subtype is part of the "Apollo NCS"
+      variant space (both are outside the scope of this specification).
+      The Microsoft variant may have subtyping mechanisms 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 is, an ID of
+      "1" may exist in multiple variant spaces.
+
+   *  The "Variant" column is free-form text.  However, it is likely
+      that one of four values will be included: the first three are "OSF
+      DCE / IETF", "Apollo NCS", 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 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 Sections 6.9 and 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, then UUIDv4
+   (Section 5.4) SHOULD be utilized.
+
+   See [RFC6151] for MD5 security considerations and [RFC6194] for SHA-1
+   security considerations.
+
+9.  References
+
+9.1.  Normative References
+
+   [C309]     X/Open Company Limited, "X/Open DCE: Remote Procedure
+              Call", ISBN 1-85912-041-5, Open CAE Specification C309,
+              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 (NIST),
+              "Secure Hash 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 (NIST),
+              "SHA-3 Standard: Permutation-Based Hash and 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/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/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/info/rfc8174>.
+
+   [X667]     ITU-T, "Information 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", ISO/IEC 9834-8:2004,
+              ITU-T Recommendation X.667, September 2004.
+
+9.2.  Informative References
+
+   [COMBGUID] "Creating sequential GUIDs in C# for MSSQL or PostgreSql",
+              commit 2759820, December 2020,
+              <https://github.com/richardtallent/RT.Comb>.
+
+   [CUID]     "Collision-resistant ids optimized for horizontal scaling
+              and performance.", commit 215b27b, October 2020,
+              <https://github.com/ericelliott/cuid>.
+
+   [Elasticflake]
+              Pearcy, P., "Sequential UUID / Flake ID generator pulled
+              out of elasticsearch common", 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 15c933a, February 2017,
+              <https://github.com/boundary/flake>.
+
+   [FlakeID]  "Flake ID Generator", commit fcd6a2f, April 2020,
+              <https://github.com/T-PWK/flake-idgen>.
+
+   [IBM_NCS]  IBM, "uuid_gen Command (NCS)", 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.", 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 bf376a7,
+              July 2020, <https://github.com/segmentio/ksuid>.
+
+   [LexicalUUID]
+              Twitter, "Cassie", commit f6da4e0, November 2012,
+              <https://github.com/twitter-archive/cassie>.
+
+   [Microsoft]
+              Microsoft, "2.3.4.3 GUID - Curly Braced String
+              Representation", April 2023, <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 it just pick a side
+              and stick with it?", September 2022,
+              <https://devblogs.microsoft.com/
+              oldnewthing/20220928-00/?p=107221>.
+
+   [ObjectID] MongoDB, "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]   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>.
+
+   [Python]   Python, "uuid - UUID objects according to 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/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/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/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/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/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/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/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/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/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]      "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 ec40836, May 2014,
+              <https://github.com/twitter-archive/snowflake>.
+
+   [Sonyflake]
+              Sony, "A distributed unique ID generator inspired by
+              Twitter's Snowflake", commit 848d664, August 2020,
+              <https://github.com/sony/sonyflake>.
+
+   [ULID]     "Universally Unique Lexicographically Sortable
+              Identifier", Commit d0c7170, May 2019,
+              <https://github.com/ulid/spec>.
+
+   [URNNamespaces]
+              IANA, "Uniform Resource Names (URN) Namespaces",
+              <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
+              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
+              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 Recommendation X.680, February 2021.
+
+   [XID]      "Globally Unique ID Generator", commit efa678f, October
+              2020, <https://github.com/rs/xid>.
+
+Appendix A.  Test Vectors
+
+   Both UUIDv1 and UUIDv6 test vectors utilize the same 60-bit
+   timestamp: 0x1EC9414C232AB00 (138648505420000000) Tuesday, February
+   22, 2022 2:22:22.000000 PM GMT-05:00.
+
+   Both UUIDv1 and UUIDv6 utilize the same values in clock_seq and 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, the starting value
+   0x9E6BDECED846 was changed to 0x9F6BDECED846.
+
+   The pseudocode used for converting from a 64-bit Unix timestamp to a
+   100 ns Gregorian timestamp value has been left in the document for
+   reference purposes.
+
+   # Gregorian-to-Unix Offset:
+   # The number of 100 ns intervals between the
+   # UUID Epoch 1582-10-15 00:00:00
+   # and the Unix Epoch 1970-01-01 00:00:00
+   # Greg_Unix_offset = 0x01b21dd213814000 or 122192928000000000
+
+   # Unix 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 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".  The field mapping
+   and all values are illustrated in Figure 18.  Finally, to further
+   illustrate the bit swapping for version and 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
+
+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, to further illustrate the bit swapping for version and
+   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
+
+A.4.  Example of a UUIDv5 Value
+
+   The SHA-1 computation form is detailed in Figure 22, using the DNS
+   Namespace ID value and the Name "www.example.com".  The field mapping
+   and all values are illustrated in Figure 23.  Finally, to further
+   illustrate the bit swapping for version and variant and the unused/
+   discarded part of the SHA-1 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 and Discarded SHA-1
+                                  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
+   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,
+   represented as 0x017F22E279B0 or 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 that serve to
+   show how one may use UUIDv8 (Section 5.8) for custom and/or
+   experimental 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 encourage implementers to create their own UUIDv8 algorithm
+   rather than use the items defined in this section.
+
+B.1.  Example of a UUIDv8 Value (Time-Based)
+
+   This example UUIDv8 test vector utilizes a well-known 64-bit Unix
+   Epoch timestamp with 10 ns precision, truncated to the least
+   significant, rightmost bits to fill the first 60 bits of custom_a and
+   custom_b, while setting the version bits between these two segments
+   to the version value of 8.
+
+   The variant bits are 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,
+   represented as 0x2489E9AD2EE2E00 or 164555774200000000 (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 Illustrative Example
+
+B.2.  Example of a UUIDv8 Value (Name-Based)
+
+   As per Section 5.5, name-based UUIDs that 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]), SHA-3 or SHAKE (as defined by [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, to further illustrate the bit swapping for version and
+   variant and the unused/discarded part of the SHA-256 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 and Discarded SHA-256
+                               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,
+      which must be overwritten.
+
+   *  Line C details the final value after the ver and var have been
+      overwritten.
+
+   *  Line D details the 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
+
+
+   Paul J. Leach
+   University of Washington
+   Email: pjl7@uw.edu