rfc9562v3.txt   rfc9562.txt 
skipping to change at line 221 skipping to change at line 221
Due to the aforementioned issues, many widely distributed database Due to the aforementioned issues, many widely distributed database
applications and large application vendors have sought to solve the applications and large application vendors have sought to solve the
problem of creating a better time-based, sortable unique identifier problem of creating a better time-based, sortable unique identifier
for use as a database key. This has led to numerous implementations for use as a database key. This has led to numerous implementations
over the past 10+ years solving the same problem in slightly over the past 10+ years solving the same problem in slightly
different ways. different ways.
While preparing this specification, the following 16 different While preparing this specification, the following 16 different
implementations were analyzed for trends in total ID length, bit implementations were analyzed for trends in total ID length, bit
layout, lexical formatting/encoding, timestamp type, timestamp layout, lexical formatting and encoding, timestamp type, timestamp
format, timestamp accuracy, node format/components, collision format, timestamp accuracy, node format and components, collision
handling, and multi-timestamp tick generation sequencing: handling, and multi-timestamp tick generation sequencing:
1. [ULID] 1. [ULID]
2. [LexicalUUID] 2. [LexicalUUID]
3. [Snowflake] 3. [Snowflake]
4. [Flake] 4. [Flake]
5. [ShardingID] 5. [ShardingID]
6. [KSUID] 6. [KSUID]
7. [Elasticflake] 7. [Elasticflake]
8. [FlakeID] 8. [FlakeID]
skipping to change at line 251 skipping to change at line 251
An inspection of these implementations and the issues described above An inspection of these implementations and the issues described above
has led to this document, in which new UUIDs are adapted to address has led to this document, in which new UUIDs are adapted to address
these issues. these issues.
Further, [RFC4122] itself was in need of an overhaul to address a Further, [RFC4122] itself was in need of an overhaul to address a
number of topics such as, but not limited to, the following: number of topics such as, but not limited to, the following:
1. Implementation of miscellaneous errata reports. Mostly around 1. Implementation of miscellaneous errata reports. Mostly around
bit-layout clarifications, which lead to inconsistent bit-layout clarifications, which lead to inconsistent
implementations [Err1957], [Err3546], [Err4975], [Err4976], implementations [Err1957], [Err3546], [Err4976], etc.
[Err5560], etc.
2. Decoupling other UUID versions from the UUIDv1 bit layout so that 2. Decoupling other UUID versions from the UUIDv1 bit layout so that
fields like "time_hi_and_version" do not need to be referenced fields like "time_hi_and_version" do not need to be referenced
within a UUID that is not time based while also providing within a UUID that is not time based while also providing
definition sections similar to that for UUIDv1 for UUIDv3, definition sections similar to that for UUIDv1 for UUIDv3,
UUIDv4, and UUIDv5. UUIDv4, and UUIDv5.
3. Providing implementation best practices around many real-world 3. Providing implementation best practices around many real-world
scenarios and corner cases observed by existing and prototype scenarios and corner cases observed by existing and prototype
implementations. implementations.
skipping to change at line 553 skipping to change at line 552
00000000-0000-4000-8000-000000000000 00000000-0000-4000-8000-000000000000
00000000-0000-4000-9000-000000000000 00000000-0000-4000-9000-000000000000
00000000-0000-4000-A000-000000000000 00000000-0000-4000-A000-000000000000
00000000-0000-4000-B000-000000000000 00000000-0000-4000-B000-000000000000
xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx
Figure 5: UUIDv4 Variant Examples Figure 5: UUIDv4 Variant Examples
It should be noted that the other remaining UUID variants found in It should be noted that the other remaining UUID variants found in
Table 1 leverage different sub-typing/versioning mechanisms. The Table 1 leverage different sub-typing or versioning mechanisms. The
recording and definition of the remaining UUID variant and sub-typing recording and definition of the remaining UUID variant and sub-typing
combinations are outside of the scope of this document. combinations are outside of the scope of this document.
5. UUID Layouts 5. UUID Layouts
To minimize confusion about bit assignments within octets and among To minimize confusion about bit assignments within octets and among
differing versions, the UUID record definition is provided as a differing versions, the UUID record definition is provided as a
grouping of fields within a bit layout consisting of four octets per grouping of fields within a bit layout consisting of four octets per
row. The fields are presented with the most significant one first. row. The fields are presented with the most significant one first.
skipping to change at line 1015 skipping to change at line 1014
The only explicitly defined bits are those of the version and variant The only explicitly defined bits are those of the version and variant
fields, leaving 122 bits for implementation-specific UUIDs. To be fields, leaving 122 bits for implementation-specific UUIDs. To be
clear, UUIDv8 is not a replacement for UUIDv4 (Section 5.4) where all clear, UUIDv8 is not a replacement for UUIDv4 (Section 5.4) where all
122 extra bits are filled with random data. 122 extra bits are filled with random data.
Some example situations in which UUIDv8 usage could occur: Some example situations in which UUIDv8 usage could occur:
* An implementation would like to embed extra information within the * An implementation would like to embed extra information within the
UUID other than what is defined in this document. UUID other than what is defined in this document.
* An implementation has other application/language restrictions that * An implementation has other application and/or language
inhibit the use of one of the current UUIDs. restrictions that inhibit the use of one of the current UUIDs.
Appendix B provides two illustrative examples of custom UUIDv8 Appendix B provides two illustrative examples of custom UUIDv8
algorithms to address two example scenarios. algorithms to address two example scenarios.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| custom_a | | custom_a |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| custom_a | ver | custom_b | | custom_a | ver | custom_b |
skipping to change at line 1218 skipping to change at line 1217
batches of UUIDs, the embedded timestamp within UUIDv6 and UUIDv7 can batches of UUIDs, the embedded timestamp within UUIDv6 and UUIDv7 can
provide sufficient monotonicity guarantees by simply ensuring that provide sufficient monotonicity guarantees by simply ensuring that
timestamp increments before creating a new UUID. Distributed nodes timestamp increments before creating a new UUID. Distributed nodes
are discussed in Section 6.4. are discussed in Section 6.4.
Implementations SHOULD employ the following methods for single-node Implementations SHOULD employ the following methods for single-node
UUID implementations that require batch UUID creation or are UUID implementations that require batch UUID creation or are
otherwise concerned about monotonicity with high-frequency UUID otherwise concerned about monotonicity with high-frequency UUID
generation. generation.
Fixed Bit-Length Dedicated Counter Bits (Method 1): Fixed Bit-Length Dedicated Counter (Method 1):
Some implementations allocate a specific number of bits in the Some implementations allocate a specific number of bits in the
UUID layout to the sole purpose of tallying the total number of UUID layout to the sole purpose of tallying the total number of
UUIDs created during a given UUID timestamp tick. If present, a UUIDs created during a given UUID timestamp tick. If present, a
fixed bit-length counter MUST be positioned immediately after the fixed bit-length counter MUST be positioned immediately after the
embedded timestamp. This promotes sortability and allows random embedded timestamp. This promotes sortability and allows random
data generation for each counter increment. With this method, the data generation for each counter increment. With this method, the
rand_a section (or a subset of its leftmost bits) of UUIDv7 is rand_a section (or a subset of its leftmost bits) of UUIDv7 is
used as the fixed bit-length dedicated counter bits that are used as a fixed bit-length dedicated counter that is incremented
incremented for every UUID generation. The trailing random bits for every UUID generation. The trailing random bits generated for
generated for each new UUID in rand_b can help produce unguessable each new UUID in rand_b can help produce unguessable UUIDs. In
UUIDs. In the event that more counter bits are required, the most the event that more counter bits are required, the most
significant (leftmost) bits of rand_b MAY be used as additional significant (leftmost) bits of rand_b MAY be used as additional
counter bits. counter bits.
Monotonic Random (Method 2): Monotonic Random (Method 2):
With this method, the random data is extended to also function as With this method, the random data is extended to also function as
a counter. This monotonic value can be thought of as a "randomly a counter. This monotonic value can be thought of as a "randomly
seeded counter" that MUST be incremented in the least significant seeded counter" that MUST be incremented in the least significant
position for each UUID created on a given timestamp tick. position for each UUID created on a given timestamp tick.
UUIDv7's rand_b section SHOULD be utilized with this method to UUIDv7's rand_b section SHOULD be utilized with this method to
handle batch UUID generation during a single timestamp tick. The handle batch UUID generation during a single timestamp tick. The
skipping to change at line 1615 skipping to change at line 1614
Sections 6.1 and 6.2. This is especially true for distributed node Sections 6.1 and 6.2. This is especially true for distributed node
collision resistance as defined by Section 6.4. collision resistance as defined by Section 6.4.
There are two example scenarios below that help illustrate the There are two example scenarios below that help illustrate the
varying seriousness of a collision within an application. varying seriousness of a collision within an application.
Low Impact: Low Impact:
A UUID collision generated a duplicate log entry, which results in A UUID collision generated a duplicate log entry, which results in
incorrect statistics derived from the data. Implementations that incorrect statistics derived from the data. Implementations that
are not negatively affected by collisions may continue with the are not negatively affected by collisions may continue with the
entropy and uniqueness provided by UUIDs defined in this entropy and uniqueness provided by UUIDs defined in this document.
document..
High Impact: High Impact:
A duplicate key causes an airplane to receive the wrong course, A duplicate key causes an airplane to receive the wrong course,
which puts people's lives at risk. In this scenario, there is no which puts people's lives at risk. In this scenario, there is no
margin for error. Collisions must be avoided: failure is margin for error. Collisions must be avoided: failure is
unacceptable. Applications dealing with this type of scenario unacceptable. Applications dealing with this type of scenario
must employ as much collision resistance as possible within the must employ as much collision resistance as possible within the
given application context. given application context.
6.8. Global and Local Uniqueness 6.8. Global and Local Uniqueness
skipping to change at line 1669 skipping to change at line 1667
IEEE 802 address is not available or its use is not desired. IEEE 802 address is not available or its use is not desired.
Implementations MAY leverage MAC address randomization techniques Implementations MAY leverage MAC address randomization techniques
[IEEE802.11bh] as an alternative to the pseudorandom logic provided [IEEE802.11bh] as an alternative to the pseudorandom logic provided
in this section. in this section.
Alternatively, implementations MAY elect to obtain a 48-bit Alternatively, implementations MAY elect to obtain a 48-bit
cryptographic-quality random number as per Section 6.9 to use as the cryptographic-quality random number as per Section 6.9 to use as the
Node ID. After generating the 48-bit fully randomized node value, Node ID. After generating the 48-bit fully randomized node value,
implementations MUST set the least significant bit of the first octet implementations MUST set the least significant bit of the first octet
of the Node ID to 1. This bit is the unicast/multicast bit, which 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. will never be set in IEEE 802 addresses obtained from network cards.
Hence, there can never be a conflict between UUIDs generated by Hence, there can never be a conflict between UUIDs generated by
machines with and without network cards. An example of generating a machines with and without network cards. An example of generating a
randomized 48-bit node value and the subsequent bit modification is randomized 48-bit node value and the subsequent bit modification is
detailed in Appendix A. For more information about IEEE 802 address detailed in Appendix A. For more information about IEEE 802 address
and the unicast/multicast or local/global bits, please review and the unicast or multicast or local/global bits, please review
[RFC9542]. [RFC9542].
For compatibility with earlier specifications, note that this For compatibility with earlier specifications, note that this
document uses the unicast/multicast bit instead of the arguably more document uses the unicast or multicast bit instead of the arguably
correct local/global bit because MAC addresses with the local/global more correct local/global bit because MAC addresses with the local/
bit set or not set are both possible in a network. This is not the global bit set or not set are both possible in a network. This is
case with the unicast/multicast bit. One node cannot have a MAC not the case with the unicast or multicast bit. One node cannot have
address that multicasts to multiple nodes. a MAC address that multicasts to multiple nodes.
In addition, items such as the computer's name and the name of the In addition, items such as the computer's name and the name of the
operating system, while not strictly speaking random, will help operating system, while not strictly speaking random, will help
differentiate the results from those obtained by other systems. differentiate the results from those obtained by other systems.
The exact algorithm to generate a Node ID using these data is system The exact algorithm to generate a Node ID using these data is system
specific because both the data available and the functions to obtain specific because both the data available and the functions to obtain
them are often very system specific. However, a generic approach is them are often very system specific. However, a generic approach is
to accumulate as many sources as possible into a buffer, use a to accumulate as many sources as possible into a buffer, use a
message digest (such as SHA-256 or SHA-512 defined by [FIPS180-4]), message digest (such as SHA-256 or SHA-512 defined by [FIPS180-4]),
skipping to change at line 1782 skipping to change at line 1780
7. IANA Considerations 7. IANA Considerations
All references to [RFC4122] in IANA registries (outside of those All references to [RFC4122] in IANA registries (outside of those
created by this document) have been replaced with references to this created by this document) have been replaced with references to this
document, including the IANA URN namespace registration document, including the IANA URN namespace registration
[URNNamespaces] for UUID. References to Section 4.1.2 of [RFC4122] [URNNamespaces] for UUID. References to Section 4.1.2 of [RFC4122]
have been updated to refer to Section 4 of this document. have been updated to refer to Section 4 of this document.
Finally, IANA should track UUID Subtypes and Special Case "Namespace Finally, IANA should track UUID Subtypes and Special Case "Namespace
IDs Values" as specified in Sections 7.1 and 7.2. IDs Values" as specified in Sections 7.1 and 7.2 at the following
location: <https://www.iana.org/assignments/uuid>.
When evaluating requests, the designated expert should consider When evaluating requests, the designated expert should consider
community feedback, how well-defined the reference specification is, community feedback, how well-defined the reference specification is,
and this specification's requirements. Vendor-specific, application- and this specification's requirements. Vendor-specific, application-
specific, and deployment-specific values are unable to be registered. specific, and deployment-specific values are unable to be registered.
Specification documents should be published in a stable, freely Specification documents should be published in a stable, freely
available manner (ideally, located with a URL) but need not be available manner (ideally, located with a URL) but need not be
standards. The designated expert will either approve or deny the standards. The designated expert will either approve or deny the
registration request and communicate this decision to IANA. Denials registration request and communicate this decision to IANA. Denials
should include an explanation and, if applicable, suggestions as to should include an explanation and, if applicable, suggestions as to
skipping to change at line 1964 skipping to change at line 1963
Pearcy, P., "Sequential UUID / Flake ID generator pulled Pearcy, P., "Sequential UUID / Flake ID generator pulled
out of elasticsearch common", commit dd71c21, January out of elasticsearch common", commit dd71c21, January
2015, <https://github.com/ppearcy/elasticflake>. 2015, <https://github.com/ppearcy/elasticflake>.
[Err1957] RFC Errata, Erratum ID 1957, RFC 4122, [Err1957] RFC Errata, Erratum ID 1957, RFC 4122,
<https://www.rfc-editor.org/errata/eid1957>. <https://www.rfc-editor.org/errata/eid1957>.
[Err3546] RFC Errata, Erratum ID 3546, RFC 4122, [Err3546] RFC Errata, Erratum ID 3546, RFC 4122,
<https://www.rfc-editor.org/errata/eid3546>. <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, [Err4976] RFC Errata, Erratum ID 4976, RFC 4122,
<https://www.rfc-editor.org/errata/eid4976>. <https://www.rfc-editor.org/errata/eid4976>.
[Err5560] RFC Errata, Erratum ID 5560, RFC 4122,
<https://www.rfc-editor.org/errata/eid5560>.
[Flake] Boundary, "Flake: A decentralized, k-ordered id generation [Flake] Boundary, "Flake: A decentralized, k-ordered id generation
service in Erlang", commit 15c933a, February 2017, service in Erlang", commit 15c933a, February 2017,
<https://github.com/boundary/flake>. <https://github.com/boundary/flake>.
[FlakeID] "Flake ID Generator", commit fcd6a2f, April 2020, [FlakeID] "Flake ID Generator", commit fcd6a2f, April 2020,
<https://github.com/T-PWK/flake-idgen>. <https://github.com/T-PWK/flake-idgen>.
[IBM_NCS] IBM, "uuid_gen Command (NCS)", March 2023, [IBM_NCS] IBM, "uuid_gen Command (NCS)", March 2023,
<https://www.ibm.com/docs/en/aix/7.1?topic=u-uuid-gen- <https://www.ibm.com/docs/en/aix/7.1?topic=u-uuid-gen-
command-ncs>. command-ncs>.
 End of changes. 13 change blocks. 
28 lines changed or deleted 21 lines changed or added

This html diff was produced by rfcdiff 1.48.