Editing Universally unique identifier (section)

=== Versions of the OSF DCE variant ===

The OSF DCE variant defines eight "versions" in the standard, and each version may be more appropriate than the others in specific use cases. The version is indicated by the value of the higher [[nibble]] (higher 4 bits, or higher hexadecimal digit) of the 7th byte of the UUID. In hex, this is the character after the second dash. For example, the UUID <code>9c5b94b1-35ad-'''4'''9bb-b118-8e8fc24abf80</code> is version 4, because of the digit after the second dash is 4 in <code>...-'''4'''9bb-...</code>.

==== Versions 1 and 6 (date-time and MAC address) ====

Version 1 concatenates the 48-bit [[MAC address]] of the "node" (that is, the computer generating the UUID), with a 60-bit timestamp, being the number of 100-[[nanosecond]] intervals since midnight 15 October 1582 [[Coordinated Universal Time]] (UTC), the date on which the [[Gregorian calendar]] was first adopted by the bulk of Europe. <nowiki>RFC 4122</nowiki> states that the time value rolls over around 3400 AD,<ref name="RFC 4122" />{{rp|3|q="it is possible for values to rollover (around A.D. 3400, depending on the specific algorithm used)"}} depending on the algorithm used, which implies that the 60-bit timestamp is a signed quantity. However some software, such as the libuuid library, treats the timestamp as unsigned, putting the rollover time in 5623 AD.<ref name="e2fsprogs" /> The rollover time as defined by ITU-T Rec. X.667 is 3603 AD.<ref name="X667">{{cite web |date=October 2012 |title=Recommendation ITU-T X.667 |url=https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-X.667-201210-I!!PDF-E&type=items |access-date=19 December 2020 |website=[[ITU-T|www.itu.int]]}}</ref>{{rp|v|q="a UUID is&nbsp;[...] guaranteed to be different from all other UUIDs generated before 3603 A.D."}}

A 13-bit or 14-bit "uniquifying" clock sequence extends the timestamp in order to handle cases where the processor clock does not advance fast enough, or where there are multiple processors and UUID generators per node. When UUIDs are generated faster than the system clock could advance, the lower bits of the timestamp fields can be generated by incrementing it every time a UUID is being generated, to simulate a high-resolution timestamp.  With each version 1 UUID corresponding to a single point in space (the node) and time (intervals and clock sequence), the chance of two properly generated version-1 UUIDs being unintentionally the same is practically nil.  Since the time and clock sequence total 74 bits, 2<sup>74</sup> (1.8{{e|22}}, or 18 sextillion) version-1 UUIDs can be generated per node ID, at a maximal average rate of 163 billion per second per node ID.<ref name="RFC 4122" />

In contrast to other UUID versions, version-1 and -2 UUIDs based on MAC addresses from [[network card]]s rely for their uniqueness in part on an identifier issued by a central registration authority, namely the [[Organizationally unique identifier|Organizationally Unique Identifier]] (OUI) part of the MAC address, which is issued by the [[IEEE]] to manufacturers of networking equipment.<ref name="IEEE-RA">
{{cite web |title=Registration Authority |url=http://standards.ieee.org/develop/regauth/ |archive-url=https://web.archive.org/web/20110404225440/http://standards.ieee.org/develop/regauth/ |url-status=dead |archive-date=4 April 2011 |website=[[IEEE Standards Association]]}}</ref> The uniqueness of version-1 and version-2 UUIDs based on network-card MAC addresses also depends on network-card manufacturers properly assigning unique MAC addresses to their cards, which like other manufacturing processes is subject to error. Virtual machines receive a MAC address in a range that is configurable in the hypervisor.<ref>{{cite web |title=MAC addresses for virtual machines |url=https://superuser.com/questions/932651/mac-addresses-for-virtual-machines}}</ref> Additionally some operating systems permit the end user to customise the MAC address, notably [[OpenWrt|OpenWRT]].<ref>{{Cite web |date=15 September 2021 |title=MAC Address Setup |url=https://openwrt.org/docs/guide-developer/mac.address |website=OpenWRT}}</ref>

Usage of the node's network card MAC address for the node ID means that a version-1 UUID can be tracked back to the computer that created it. Documents can sometimes be traced to the computers where they were created or edited through UUIDs embedded into them by [[word processing]] software. This [[privacy]] hole was used when locating the creator of the [[Melissa (computer virus)|Melissa virus]].<ref>{{cite web |last=Reiter |first=Luke |date=1999-04-02 |title=Tracking Melissa's Alter Egos |url=https://www.zdnet.com/article/tracking-melissas-alter-egos/ |access-date=2017-01-16 |publisher=[[ZDNet]]}}</ref>

RFC 9562{{r|RFC 9562}} does allow the MAC address in a version-1 (or 2) UUID to be replaced by a random 48-bit node ID, either because the node does not have a MAC address, or because it is not desirable to expose it. In that case, the RFC requires that the least significant bit of the first octet of the node ID should be set to 1.<ref name="RFC 4122" /> This corresponds to the [[multicast]] bit in MAC addresses, and setting it serves to differentiate UUIDs where the node ID is randomly generated from UUIDs based on MAC addresses from network cards, which typically have [[unicast]] MAC addresses.<ref name="RFC 4122" />

Version 6 is the same as version 1 except all timestamp bits are ordered from most significant to least significant. This allows systems to sort UUIDs in order of creation simply by sorting them lexically, whereas this is not possible with version 1.

==== Version 2 (date-time and MAC address, DCE security version) ====

RFC 9562{{r|RFC 9562}} reserves version 2 for "DCE security" UUIDs; but it does not provide any details. For this reason, many UUID implementations omit version 2. However, the specification of version-2 UUIDs is provided by the DCE 1.1 Authentication and Security Services specification.<ref name="dce_spec_auth" />

Version-2 UUIDs are similar to version 1, except that the least significant 8 bits of the clock sequence are replaced by a "local domain" number, and the least significant 32 bits of the timestamp are replaced by an integer identifier meaningful within the specified local domain. On [[POSIX]] systems, local-domain numbers 0 and 1 are for user ids ([[User identifier|UIDs]]) and group ids ([[Group identifier|GIDs]]) respectively, and other local-domain numbers are site-defined.<ref name="dce_spec_auth" /> On non-POSIX systems, all local domain numbers are site-defined.

The ability to include a 40-bit domain/identifier in the UUID comes with a tradeoff. On the one hand, 40 bits allow about 1&nbsp;trillion domain/identifier values per node ID.  On the other hand, with the clock value truncated to the 28 most significant bits, compared to 60 bits in version 1, the clock in a version 2 UUID will "tick" only once every 429.49&nbsp;seconds, a little more than 7&nbsp;minutes, as opposed to every 100&nbsp;nanoseconds for version 1.  And with a clock sequence of only 6&nbsp;bits, compared to 14 bits in version 1, only 64 unique UUIDs per node/domain/identifier can be generated per 7-minute clock tick, compared to 16,384 clock sequence values for version 1.<ref>{{cite web |last1=Kuchling |first1=A. M. |title=What's New in Python 2.5 |url=https://docs.python.org/3/whatsnew/2.5.html |access-date=23 January 2016 |website=Python.org |ref=Python2.5RelNotes}}</ref>

==== Versions 3 and 5 (namespace name-based) ====

Version-3 and version-5 UUIDs are generated by [[Cryptographic hash function|hashing]] a [[namespace]] identifier and name. Version 3 uses [[MD5]] as the hashing algorithm, and version 5 uses [[SHA-1]].<ref name="RFC 9562" />

The namespace identifier is itself a UUID. The specification provides UUIDs to represent the namespaces for [[Uniform Resource Locator|URL]]s, [[fully qualified domain name]]s, [[object identifier]]s, and [[X.500]] [[LDAP|distinguished name]]s; but any desired UUID may be used as a namespace designator.

To determine the version-3 UUID corresponding to a given namespace and name, the UUID of the namespace is transformed to a string of bytes, concatenated with the input name, then hashed with MD5, yielding 128 bits.  Then 6 or 7 bits are replaced by fixed values, the 4-bit version (e.g. 0011<sub>2</sub> for version 3), and the 2- or 3-bit UUID "variant" (e.g. 10<sub>2</sub> indicating an RFC 9562{{r|RFC 9562}} UUIDs, or 110<sub>2</sub> indicating a legacy Microsoft GUID). Since 6 or 7 bits are thus predetermined, only 121 or 122 bits contribute to the uniqueness of the UUID.

Version-5 UUIDs are similar, but SHA-1 is used instead of MD5. Since SHA-1 generates 160-bit digests, the digest is truncated to 128 bits before the version and variant bits are replaced.

Version-3 and version-5 UUIDs have the property that the same namespace and name will map to the same UUID. However, neither the namespace nor name can be determined from the UUID, even if one of them is specified, except by brute-force search. RFC 4122 recommends version 5 (SHA-1) over version 3 (MD5), and warns against use of UUIDs of either version as security credentials.<ref name="RFC 4122" />

==== Version 4 (random) ====

A version 4 UUID is randomly generated.  As in other UUIDs, 4 bits are used to indicate version 4, and 2 or 3 bits to indicate the variant (10<sub>2</sub> or 110<sub>2</sub> for variants 1 and 2 respectively). Thus, for variant 1 (that is, most UUIDs) a random version 4 UUID will have 6 predetermined variant and version bits, leaving 122 bits for the randomly generated part, for a total of 2<sup>122</sup>, or 5.3{{e|36}} (5.3&nbsp;[[Names of large numbers|undecillion]]) possible version-4 variant-1 UUIDs.  There are half as many possible version 4, variant 2 UUIDs (legacy GUIDs) because there is one less random bit available, 3 bits being consumed for the variant.

Per RFC 9562{{r|RFC 9562}}, the seventh octet's most significant 4 bits indicate which version the UUID adheres to. This means that the first hexadecimal digit in the third group always starts with a <code>4</code> in UUIDv4s. Visually, this looks like this <code>xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx</code>, where <code>M</code> is the UUID version field. The upper two or three bits of digit <code>N</code> encode the variant. Values are <code>8</code>, <code>9</code>, <code>A</code> or <code>B</code> for the 2 bit indication, values <code>C</code> or <code>D</code> for the 3 bit indication. For example, a random UUID version 4, variant 1 could be  <code>8D8AC610-566D-4EF0-9C22-186B2A5ED793</code>.<ref>{{Cite web |date=2023-11-06 |title=draft-ietf-uuidrev-rfc4122bis-14 |url=https://datatracker.ietf.org/doc/html/draft-ietf-uuidrev-rfc4122bis#name-version-field |url-status=live |archive-url=https://archive.today/20240417032603/https://datatracker.ietf.org/doc/html/draft-ietf-uuidrev-rfc4122bis#selection-6225.0-6239.184 |archive-date=2024-04-17 |website=[[University of Washington]]}}</ref>

==== Version 7 (timestamp and random) ====
Version 7 UUIDs (UUIDv7) are designed for keys in high-load databases and distributed systems.

UUIDv7 begins with a 48 bit big-endian Unix Epoch timestamp with approximately millisecond granularity. The timestamp can be shifted by any time shift value. Directly after the timestamp follows the version nibble, that must have a value of 7. The variant bits have to be <code>10x</code>. Remaining 74 bits are random seeded counter (optional, at least 12 bits but no longer than 42 bits) and random.

Two counter rollover handling methods can be used together:

* Zero seeded most significant, leftmost guard bit of the counter.
* Increment of the timestamp ahead of the actual time and reinitialize the counter when it overflows.

In DBMS UUIDv7 generator can be shared between threads (tied to a table or to a DBMS instance) or can be thread-local (with worse monotonicity, locality and performance).

==== Version 8 (custom) ====
Version 8 only has two requirements:

* The variant bits have to be <code>10</code>, so the nibble containing the variant must be 8 (<code>0b1000</code>), 9 (<code>0b1001</code>), A (<code>0b1010</code>), or B (<code>0b1011</code>).
* The version nibble has to be the value of 8.

Those requirements tell the system that it is a version 8 UUID. The remaining 122 bits are up to the vendor to customize. The difference with version 4 is that those 122 bits are random, but the 122 bits in UUID version 8 are not, because they follow vendor specific rules.