RFC 4122
A Universally Unique IDentifier (UUID) URN Namespace
A Universally Unique IDentifier (UUID) URN Namespace 🎀
Network Working Group 🌸 this one is from July 2005, and it's on the Standards Track 👑, so implementers are actually supposed to follow it. The authors are P. Leach (Microsoft), M. Mealling (Refactored Networks, LLC), and R. Salz (DataPower Technology, Inc.). It's RFC 4122, and it's the spec that defines how UUIDs become URNs. Nothing in this excerpt says it obsoletes or updates another document, so I'm not inventing any relationships 🙈
Status of This Memo ✨
okay so this doc is an Internet standards track protocol spec for the Internet community, and it's basically asking for discussion and suggestions for improvements 💅. If you want the current standardization state, check the latest edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited, so share it with everyone 🦋
Copyright Notice 🌈
Copyright (C) The Internet Society (2005). That's the legal bit, bestie 🫶
Abstract 💜
so this spec defines a Uniform Resource Name namespace for UUIDs (Universally Unique IDentifiers), which people also call GUIDs (Globally Unique IDentifiers) 🧚. A UUID is 128 bits long and can guarantee uniqueness across space and time, which is so iconic ✨. UUIDs started out in the Apollo Network Computing System, then moved into the Open Software Foundation's (OSF) Distributed Computing Environment (DCE), and after that they showed up on Microsoft Windows platforms. Main character origin story 👑
This spec is derived from the DCE specification, used with the kind permission of the OSF (now The Open Group) 🎀. Info from earlier versions of the DCE spec was folded in too.
Table of Contents 📋
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Namespace Registration Template . . . . . . . . . . . . . . . 3
4. Specification . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Format. . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1.1. Variant. . . . . . . . . . . . . . . . . . . . . . 6
4.1.2. Layout and Byte Order. . . . . . . . . . . . . . . 6
4.1.3. Version. . . . . . . . . . . . . . . . . . . . . . 7
4.1.4. Timestamp. . . . . . . . . . . . . . . . . . . . . 8
4.1.5. Clock Sequence . . . . . . . . . . . . . . . . . . 8
4.1.6. Node . . . . . . . . . . . . . . . . . . . . . . . 9
4.1.7. Nil UUID . . . . . . . . . . . . . . . . . . . . . 9
4.2. Algorithms for Creating a Time-Based UUID . . . . . . . . 9
4.2.1. Basic Algorithm. . . . . . . . . . . . . . . . . . 10
4.2.2. Generation Details . . . . . . . . . . . . . . . . 12
4.3. Algorithm for Creating a Name-Based UUID. . . . . . . . . 13
4.4. Algorithms for Creating a UUID from Truly Random or
Pseudo-Random Numbers . . . . . . . . . . . . . . . . . . 14
4.5. Node IDs that Do Not Identify the Host. . . . . . . . . . 15
5. Community Considerations . . . . . . . . . . . . . . . . . . . 15
6. Security Considerations . . . . . . . . . . . . . . . . . . . 16
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
8. Normative References . . . . . . . . . . . . . . . . . . . . . 16
A. Appendix A - Sample Implementation . . . . . . . . . . . . . . 18
B. Appendix B - Sample Output of utest . . . . . . . . . . . . . 29
C. Appendix C - Some Name Space IDs . . . . . . . . . . . . . . . 301. Introduction ✨
okay so this spec defines a Uniform Resource Name namespace for UUIDs (Universally Unique IDentifiers), also known as GUIDs (Globally Unique IDentifiers) 💖. A UUID is 128 bits long and needs no central registration process at all, which is honestly so freeing 🦋
This doc is a concise guide for anyone who wants to build services that use UUIDs as URNs 🍓. Nothing in here is supposed to override the DCE standards that originally defined UUIDs, so those stay the source of truth 🫶
There's an ITU-T Recommendation and ISO/IEC Standard [3] that came from earlier versions of this document. Both sets of specs have been lined up and are fully technically compatible, which is a whole glow-up 🌈 On top of that, the Telecommunications Standardisation Bureau of ITU-T is running a global registration function. For details, check <http://www.itu.int/ITU-T/asn1/uuid.html>. 🎀
2. Motivation 💜
the big reason people love UUIDs is that nobody has to be in charge of handing them out 👑 (though one format uses IEEE 802 node identifiers, and the others don't). So generation can be fully automated on demand and used for all kinds of purposes ✨. The algorithm here can hit allocation rates of up to 10 million per second per machine if needed, which is so extra that they could even be used as transaction IDs 🔥
UUIDs are a fixed size (128 bits), which is pretty small compared to the alternatives 🌸. That makes them super easy to sort, order, and hash, store in databases, allocate, and program with in general 💅
Since UUIDs are unique and persistent, they make excellent Uniform Resource Names 🧚. Being able to make a brand-new UUID without any registration process means UUIDs are one of the URNs with the lowest minting cost. Literally a freebie 🦋
3. Namespace Registration Template 🎀
Namespace ID: UUID
Registration Information: the registration date is 2003-10-01.
Declared registrant of the namespace: JTC 1/SC6 (ASN.1 Rapporteur Group) 👑
Declaration of syntactic structure: a UUID is an identifier that's unique across both space and time, with respect to the space of all UUIDs. Because a UUID has a fixed size and includes a time field, the values can roll over (around A.D. 3400, depending on the specific algorithm used) 😭 A UUID can be used for everything from tagging objects with an extremely short lifetime to reliably identifying very persistent objects across a network 🌈
The internal representation of a UUID is a specific sequence of bits in memory, as described in Section 4. To represent a UUID as a URN accurately, you have to convert that bit sequence into a string 💖
Each field gets treated as an integer and printed as a zero-filled hexadecimal digit string, with the most significant digit first. The hexadecimal values "a" through "f" are output as lower case characters, but they're case insensitive on input 🫶
The formal definition of the UUID string representation is given by the following ABNF [7]:
UUID = time-low "-" time-mid "-"
time-high-and-version "-"
clock-seq-and-reserved
clock-seq-low "-" node
time-low = 4hexOctet
time-mid = 2hexOctet
time-high-and-version = 2hexOctet
clock-seq-and-reserved = hexOctet
clock-seq-low = hexOctet
node = 6hexOctet
hexOctet = hexDigit hexDigit
hexDigit =
"0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9" /
"a" / "b" / "c" / "d" / "e" / "f" /
"A" / "B" / "C" / "D" / "E" / "F"Here's an example of a UUID as a URN, so you can see the vibe 🧚
urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6Relevant ancillary documentation: [1][2]
Identifier uniqueness considerations: this doc specifies three algorithms for generating UUIDs. The first uses the unique values of 802 MAC addresses to guarantee uniqueness. The second uses pseudo-random number generators. The third uses cryptographic hashing plus application-provided text strings. Because of that, UUIDs generated with these mechanisms will be unique from all other UUIDs that have been or will be assigned 💅
Identifier persistence considerations: UUIDs are inherently very hard to resolve in a global sense 🙈. Combined with the fact that UUIDs are temporally unique within their spatial context, this makes them as persistent as possible 🦋
Process of identifier assignment: generating a UUID doesn't require contacting a registration authority. One algorithm needs a value that's unique over space for each generator. That value is typically an IEEE 802 MAC address, which is usually already available on network-connected hosts 🌸. The address can come from an address block obtained from the IEEE registration authority. If no such address is available, or privacy concerns make using one undesirable, Section 4.5 specifies two alternatives 🔒 Another approach is to use version 3 or version 4 UUIDs, as defined below ✨
Process for identifier resolution: since UUIDs aren't globally resolvable, this one doesn't apply 💀
Rules for Lexical Equivalence: treat each field of the UUID as an unsigned integer, as shown in the table in section Section 4.1.2. To compare two UUIDs, arithmetically compare the corresponding fields from each UUID in order of significance and according to their data type. Two UUIDs are equal if and only if all the corresponding fields are equal 🫶
As an implementation note, equality comparison can be done on many systems by doing the appropriate byte-order canonicalization, then treating the two UUIDs as 128-bit unsigned integers 🧚
UUIDs as defined in this document can also be ordered lexicographically. For a pair of UUIDs, the first one follows the second if the most significant field where they differ is greater for the first UUID. The second one precedes the first if the most significant field where they differ is greater for the second UUID 👑
Conformance with URN Syntax: the string representation of a UUID is fully compatible with URN syntax. When you convert a bit-oriented, in-memory representation of a UUID into a URN, you have to be careful about the byte order issues covered in the string representation section 💅
Validation mechanism: apart from checking whether the timestamp portion of the UUID is in the future (and therefore not yet assignable), there's no mechanism for determining whether a UUID is 'valid' 🙈
Scope: UUIDs are global in scope 🌍
4. Specification 🌈
4.1. Format 💖
The UUID format is 16 octets. Some bits of the eight-octet variant field, specified below, determine the finer structure 🦋
4.1.1. Variant 🎀
okay the variant field determines the layout of the UUID. That means how every other bit in the UUID gets interpreted depends on what the bits in the variant field are set to 🧚. It really should be called a type field, but we kept the original term for compatibility 🙈 The variant field is made of a variable number of the most significant bits of octet 8 of the UUID.
The table below lists the contents of the variant field, where the letter "x" means a "don't-care" value 💅
Msb0 Msb1 Msb2 Description
0 x x Reserved, NCS backward compatibility.
1 0 x The variant specified in this document.
1 1 0 Reserved, Microsoft Corporation backward
compatibility
1 1 1 Reserved for future definition.Heads up, bestie: interoperability with any variant other than the one defined here isn't guaranteed, and it's not likely to be an issue in practice 🫶
To be continued, bestie, there's more of this spec coming in the next part 🦋✨
4.1.2. Layout and Byte Order ✨
Bestie, okay, so to avoid mixing up bits inside a single octet 🫶, the UUID record is only defined using fields that fill whole octets. The fields are listed most significant first, so the one at the top matters most 💅
Field Data Type Octet Note
#
time_low unsigned 32 0-3 The low field of the
bit integer timestamp
time_mid unsigned 16 4-5 The middle field of the
bit integer timestamp
time_hi_and_version unsigned 16 6-7 The high field of the
bit integer timestamp multiplexed
with the version number
clock_seq_hi_and_rese unsigned 8 8 The high field of the
rved bit integer clock sequence
multiplexed with the
variant
clock_seq_low unsigned 8 9 The low field of the
bit integer clock sequence
node unsigned 48 10-15 The spatially unique
bit integer node identifierUnless an application or presentation protocol says otherwise, a UUID gets encoded as a 128-bit object, like this 🎀
Every field is stored in 16 octets total, with the sizes and order from the table above. Each field gets written Most Significant Byte first, which is what people call network byte order 🌐 Also, the field names (especially the multiplexed ones) stick with historical practice, so they might look a little weird. Not my fault, ngl 💀
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 | time_hi_and_version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|clk_seq_hi_res | clk_seq_low | node (0-1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| node (2-5) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+4.1.3. Version 👑
The version number lives in the top 4 bits of the timestamp, which are bits 4 through 7 of the time_hi_and_version field 🦋
Here's the table of currently-defined versions for this UUID variant. Main character energy 💜
Msb0 Msb1 Msb2 Msb3 Version Description
0 0 0 1 1 The time-based version
specified in this document.
0 0 1 0 2 DCE Security version, with
embedded POSIX UIDs.
0 0 1 1 3 The name-based version
specified in this document
that uses MD5 hashing.
0 1 0 0 4 The randomly or pseudo-
randomly generated version
specified in this document.
0 1 0 1 5 The name-based version
specified in this document
that uses SHA-1 hashing.Technically the version is more of a sub-type, but we keep the name anyway for compatibility 🌸
4.1.4. Timestamp ⏰
The timestamp is a 60-bit value. For UUID version 1, it's shown as Coordinated Universal Time (UTC), counted as 100-nanosecond intervals since 00:00:00.00 on 15 October 1582. That's the date of the Gregorian reform to the Christian calendar, so yes, it's a whole vibe 📅
If a system doesn't have UTC but does have local time, it may use local time instead, as long as it does that consistently across the whole system. Honestly though, this is not recommended, because generating UTC from local time only takes a time zone offset, so just do the UTC thing 🙃
For UUID version 3 or 5, the timestamp is a 60-bit value built from a name, as described in Section 4.3 🧚
For UUID version 4, the timestamp is a randomly or pseudo-randomly generated 60-bit value, as described in Section 4.4 🎲
4.1.5. Clock Sequence 🕰️
For UUID version 1, the clock sequence helps avoid duplicates. Those could show up when the clock gets set backwards or when the node ID changes 🙈
If the clock gets set backwards, or might have been set backwards (for example, while the system was powered off), and the UUID generator can not be sure that no UUIDs were generated with timestamps larger than the value the clock was set to, then the clock sequence has to be changed. If the previous clock sequence value is known, it can just be incremented. Otherwise, it should be set to a random or high-quality pseudo-random value 🔁
Same deal if the node ID changes, like when a network card gets moved between machines. Setting the clock sequence to a random number keeps the chance of a duplicate low, even if the machines' clocks are slightly different. If the clock sequence tied to the new node ID were known, you could just increment it, but that's unlikely to be the case 🤷♀️
The clock sequence MUST be originally (that is, once in the lifetime of a system) initialized to a random number, to minimize the correlation across systems. This gives maximum protection against node identifiers that might move or switch from system to system quickly 🔐 The initial value MUST NOT be correlated to the node identifier. No cap, this part is serious 🚫
For UUID version 3 or 5, the clock sequence is a 14-bit value built from a name, as described in Section 4.3 🧩
For UUID version 4, the clock sequence is a randomly or pseudo-randomly generated 14-bit value, as described in Section 4.4 🎲
4.1.6. Node 🖥️
For UUID version 1, the node field holds an IEEE 802 MAC address, usually the host's address. If a system has multiple IEEE 802 addresses, any one of them can be used. The lowest addressed octet (octet number 10) holds the global/local bit and the unicast/multicast bit. It's also the first octet of the address transmitted on an 802.3 LAN 📡
For systems with no IEEE address, a randomly or pseudo-randomly generated value may be used. See Section 4.5 for that. The multicast bit must be set in such addresses, so they'll never conflict with addresses that come from network cards 🛡️
For UUID version 3 or 5, the node field is a 48-bit value built from a name, as described in Section 4.3 🧁
For UUID version 4, the node field is a randomly or pseudo-randomly generated 48-bit value, as described in Section 4.4 🌈
4.1.7. Nil UUID 🕳️
The nil UUID is a special form of UUID where all 128 bits are set to zero. Zero drama, all vibes 🤍
4.2. Algorithms for Creating a Time-Based UUID 🛠️
Several parts of the algorithm for making a version 1 UUID get covered in the following sections, so buckle up 🎢
4.2.1. Basic Algorithm 🧃
The following algorithm is simple, correct, and inefficient. Ngl, it's giving honest 💅
- Obtain a system-wide global lock
- From a system-wide shared stable store (for example, a file), read the UUID generator state: the values of the timestamp, clock sequence, and node ID used to generate the last UUID.
- Get the current time as a 60-bit count of 100-nanosecond intervals since 00:00:00.00, 15 October 1582.
- Get the current node ID.
- If the state was unavailable (for example, non-existent or corrupted), or the saved node ID is different than the current node ID, generate a random clock sequence value.
- If the state was available, but the saved timestamp is later than the current timestamp, increment the clock sequence value.
- Save the state (current timestamp, clock sequence, and node ID) back to the stable store.
- Release the global lock.
- Format a UUID from the current timestamp, clock sequence, and node ID values according to the steps in Section 4.2.2.
If UUIDs don't need to be generated very often, the algorithm above might be perfectly fine 🌷 But for higher performance needs, the basic algorithm has some issues:
- Reading the state from stable storage every time is inefficient.
- The resolution of the system clock may not be 100-nanoseconds.
- Writing the state to stable storage every time is inefficient.
- Sharing the state across process boundaries may be inefficient.
Each of these can be fixed in a modular way, with local improvements to the functions that read and write the state and read the clock. We'll go through each one in the next sections, one at a time 🧠
4.2.1.1. Reading Stable Storage 📖
The state only has to be read from stable storage once, at boot time, if it gets read into a system-wide shared volatile store. It also needs to be updated whenever the stable store gets updated 🔄
If an implementation doesn't have any stable store available, it can always say the values were unavailable. This is the least desirable option, because it increases how often new clock sequence numbers get created, and that raises the chance of duplicates 😬
If the node ID can never change (for example, the net card is inseparable from the system), or if any change also resets the clock sequence to a random value, then the current node ID can be returned instead of keeping it in stable store ✨
4.2.1.2. System Clock Resolution ⏱️
The timestamp comes from the system time, and the system time's resolution might be coarser than the UUID timestamp's resolution 🙃
If UUIDs don't need to be generated very often, the timestamp can just be the system time multiplied by the number of 100-nanosecond intervals per system time interval 🧮
If a system overruns the generator by requesting too many UUIDs within a single system time interval, the UUID service MUST either return an error, or stall the UUID generator until the system clock catches up. No skipping this step, bestie 🚨
A high resolution timestamp can be simulated by keeping a count of how many UUIDs have been generated with the same system time value, then using that count to build the low order bits of the timestamp. The count will range between zero and the number of 100-nanosecond intervals per system time interval 🎯
Note: If the processors overrun the UUID generation frequently, additional node identifiers can be allocated to the system. That lets you go faster by making multiple UUIDs potentially available for each timestamp value. ⚡
4.2.1.3. Writing Stable Storage 💾
The state doesn't always need to be written to stable store every single time a UUID is generated. The timestamp in the stable store can be set, periodically, to a value larger than any used in a UUID so far. As long as the generated UUIDs have timestamps less than that value, and the clock sequence and node ID stay unchanged, only the shared volatile copy of the state needs updating 🫧 Plus, if the timestamp in stable store is in the future by less than the typical time it takes the system to reboot, a crash won't cause the clock sequence to get reinitialized. Iconic, honestly 👑
4.2.1.4. Sharing State Across Processes 🧚
okay so if it's too expensive to touch shared state every single time you make a UUID 😩, the system-wide generator can grab a whole block of time stamps each time it's called 💅. Then a per-process generator can hand out UUIDs from that block until it runs out ✨.
4.2.2. Generation Details 🎀
Version 1 UUIDs get made with this algorithm, and honestly it's giving recipe energy 🍓:
- Figure out the UTC-based timestamp and clock sequence you're gonna use, as described in Section 4.2.1 🧚
- For this algorithm, treat the timestamp as a 60-bit unsigned integer and the clock sequence as a 14-bit unsigned integer 🔢. Number the bits in a field starting at zero for the least significant bit.
- Set the time_low field equal to the least significant 32 bits (bits zero through 31) of the timestamp, in the same order of significance 💖.
- Set the time_mid field equal to bits 32 through 47 from the timestamp, in the same order of significance 🌸.
- Set the 12 least significant bits (bits zero through 11) of the time_hi_and_version field equal to bits 48 through 59 from the timestamp, in the same order of significance ✨.
- Set the four most significant bits (bits 12 through 15) of the time_hi_and_version field to the 4-bit version number for the UUID version being created, as shown in the table above 👑.
- Set the clock_seq_low field to the eight least significant bits (bits zero through 7) of the clock sequence, in the same order of significance 🦋.
- Set the 6 least significant bits (bits zero through 5) of the clock_seq_hi_and_reserved field to the 6 most significant bits (bits 8 through 13) of the clock sequence, in the same order of significance 🫶.
- Set the two most significant bits (bits 6 and 7) of the clock_seq_hi_and_reserved to zero and one, respectively 🌈.
- Set the node field to the 48-bit IEEE address, in the same order of significance as the address 💜.
4.3. Algorithm for Creating a Name-Based UUID 🌈
The version 3 or 5 UUID is meant for generating UUIDs from "names" that are drawn from, and unique within, some "name space" 🗂️. The concept of name and name space should be broadly construed, and not limited to textual names, bestie 🙈. For example, some name spaces are the domain name system, URLs, ISO Object IDs (OIDs), X.500 Distinguished Names (DNs), and reserved words in a programming language. The mechanisms or conventions used for allocating names and ensuring their uniqueness within their name spaces are beyond the scope of this specification, so we're not getting into that here 🙅♀️.
The requirements for these types of UUIDs are as follows 💖:
- The UUIDs generated at different times from the same name in the same namespace MUST be equal 🔒.
- The UUIDs generated from two different names in the same namespace should be different (with very high probability) ✨.
- The UUIDs generated from the same name in two different namespaces should be different with (very high probability) 🌸.
- If two UUIDs that were generated from names are equal, then they were generated from the same name in the same namespace (with very high probability) 💅.
The algorithm for generating a UUID from a name and a name space is as follows 🧁:
- Allocate a UUID to use as a "name space ID" for all UUIDs generated from names in that name space; see Appendix C for some pre-defined values 🆔.
- Choose either MD5 [4] or SHA-1 [8] as the hash algorithm; If backward compatibility is not an issue, SHA-1 is preferred 🔐.
- Convert the name to a canonical sequence of octets (as defined by the standards or conventions of its name space); put the name space ID in network byte order 🔢.
- Compute the hash of the name space ID concatenated with the name 🍳.
- Set octets zero through 3 of the time_low field to octets zero through 3 of the hash 🧪.
- Set octets zero and one of the time_mid field to octets 4 and 5 of the hash 🧪.
- Set octets zero and one of the time_hi_and_version field to octets 6 and 7 of the hash 🧪.
- Set the four most significant bits (bits 12 through 15) of the time_hi_and_version field to the appropriate 4-bit version number from Section 4.1.3 👑.
- Set the clock_seq_hi_and_reserved field to octet 8 of the hash 🦋.
- Set the two most significant bits (bits 6 and 7) of the clock_seq_hi_and_reserved to zero and one, respectively 🌈.
- Set the clock_seq_low field to octet 9 of the hash 🦋.
- Set octets zero through five of the node field to octets 10 through 15 of the hash 💜.
- Convert the resulting UUID to local byte order 🌍.
4.4. Algorithms for Creating a UUID from Truly Random or Pseudo-Random Numbers 🎲
The version 4 UUID is meant for generating UUIDs from truly-random or pseudo-random numbers 🎰.
The algorithm is as follows:
- Set the two most significant bits (bits 6 and 7) of the clock_seq_hi_and_reserved to zero and one, respectively 🌈.
- Set the four most significant bits (bits 12 through 15) of the time_hi_and_version field to the 4-bit version number from Section 4.1.3 👑.
- Set all the other bits to randomly (or pseudo-randomly) chosen values 🎲.
See Section 4.5 for a discussion on random numbers 🧠.
4.5. Node IDs that Do Not Identify the Host 🕵️♀️
This section describes how to generate a version 1 UUID if an IEEE 802 address is not available, or its use is not desired 🙈.
One approach is to contact the IEEE and get a separate block of addresses. At the time of writing, the application could be found at <http://standards.ieee.org/regauth/oui/pilot-ind.html>, and the cost was US$550 💸. Ouch 😭.
A better solution is to obtain a 47-bit cryptographic quality random number and use it as the low 47 bits of the node ID, with the least significant bit of the first octet of the node ID set to one 🔥. This bit is the unicast/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 🫶. (Recall that the IEEE 802 spec talks about transmission order, which is the opposite of the in-memory representation that is discussed in this document 🧠.)
For compatibility with earlier specifications, note that this document uses the unicast/multicast bit, instead of the arguably more correct local/global bit 🤓.
Advice on generating cryptographic-quality random numbers can be found in RFC1750 [5] 📚.
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 🧩. A generic approach, however, is to accumulate as many sources as possible into a buffer, use a message digest such as MD5 [4] or SHA-1 [8], take an arbitrary 6 bytes from the hash value, and set the multicast bit as described above 🍯.
5. Community Considerations 🌍
The use of UUIDs is extremely pervasive in computing 💜. They comprise the core identifier infrastructure for many operating systems (Microsoft Windows) and applications (the Mozilla browser) and in many cases, become exposed to the Web 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 🫶✨.
6. Security Considerations 🔐
Do not assume that UUIDs are hard to guess; they should not be used as security capabilities (identifiers whose mere possession grants access), for example. A predictable random number source will exacerbate the situation 💀.
Do not assume that it is easy to determine if a UUID has been slightly transposed 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 😭.
Distributed applications generating UUIDs at a variety of hosts must be willing to rely on the random number source at all hosts. If this is not feasible, the namespace variant should be used 🚨.
7. Acknowledgments 💖
This document draws heavily on the OSF DCE specification for UUIDs. Ted Ts'o provided helpful comments, especially on the byte ordering section which we mostly plagiarized from a proposed wording he supplied (all errors in that section are our responsibility, however) 🙏.
We are also grateful to the careful reading and bit-twiddling of Ralf S. Engelschall, John Larmouth, and Paul Thorpe. Professor Larmouth was also invaluable in achieving coordination with ISO/IEC 🥹🫶.
8. Normative References 📚
[1] Zahn, L., Dineen, T., and P. Leach, "Network Computing Architecture", ISBN 0-13-611674-4, January 1990.
[2] "DCE: Remote Procedure Call", Open Group CAE Specification C309, ISBN 1-85912-041-5, August 1994.
[3] ISO/IEC 9834-8:2004 Information Technology, "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" ITU-T Rec. X.667, 2004.
[4] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[5] Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[6] Moats, R., "URN Syntax", RFC 2141, May 1997.
[7] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[8] National Institute of Standards and Technology, "Secure Hash Standard", FIPS PUB 180-1, April 1995, <http://www.itl.nist.gov/fipspubs/fip180-1.htm>.
Appendix A. Appendix A - Sample Implementation 🧑💻
This implementation consists of 5 files: uuid.h, uuid.c, sysdep.h, sysdep.c and utest.c. The uuid.* files are the system independent implementation of the UUID generation algorithms described above, with all the optimizations described above except efficient state sharing across processes included. The code has been tested on Linux (Red Hat 4.0) with GCC (2.7.2), and Windows NT 4.0 with VC++ 5.0. The code assumes 64-bit integer support, which makes it much clearer 🤓✨.
All the following source files should have the following copyright notice included 📜:
copyrt.h
/*
** Copyright (c) 1990- 1993, 1996 Open Software Foundation, Inc.
** Copyright (c) 1989 by Hewlett-Packard Company, Palo Alto, Ca. &
** Digital Equipment Corporation, Maynard, Mass.
** Copyright (c) 1998 Microsoft.
** To anyone who acknowledges that this file is provided "AS IS"
** without any express or implied warranty: permission to use, copy,
** modify, and distribute this file for any purpose is hereby
** granted without fee, provided that the above copyright notices and
** this notice appears in all source code copies, and that none of
** the names of Open Software Foundation, Inc., Hewlett-Packard
** Company, Microsoft, or Digital Equipment Corporation be used in
** advertising or publicity pertaining to distribution of the software
** without specific, written prior permission. Neither Open Software
** Foundation, Inc., Hewlett-Packard Company, Microsoft, nor Digital
** Equipment Corporation makes any representations about the
** suitability of this software for any purpose.
*/uuid.h
#include "copyrt.h"
#undef uuid_tokay so the header bit wraps up with the struct and the function declarations, and then we get into the actual uuid.c implementation 🎀
typedef struct {
unsigned32 time_low;
unsigned16 time_mid;
unsigned16 time_hi_and_version;
unsigned8 clock_seq_hi_and_reserved;
unsigned8 clock_seq_low;
byte node[6];
} uuid_t;
/* uuid_create -- generate a UUID */
int uuid_create(uuid_t * uuid);
/* uuid_create_md5_from_name -- create a version 3 (MD5) UUID using a
"name" from a "name space" */
void uuid_create_md5_from_name(
uuid_t *uuid, /* resulting UUID */
uuid_t nsid, /* UUID of the namespace */
void *name, /* the name from which to generate a UUID */
int namelen /* the length of the name */
);
/* uuid_create_sha1_from_name -- create a version 5 (SHA-1) UUID
using a "name" from a "name space" */
void uuid_create_sha1_from_name(
uuid_t *uuid, /* resulting UUID */
uuid_t nsid, /* UUID of the namespace */
void *name, /* the name from which to generate a UUID */
int namelen /* the length of the name */
);
/* uuid_compare -- Compare two UUID's "lexically" and return
-1 u1 is lexically before u2
0 u1 is equal to u2
1 u1 is lexically after u2
Note that lexical ordering is not temporal ordering!
*/
int uuid_compare(uuid_t *u1, uuid_t *u2);uuid.c 💅
the main generator lives here, and it's giving full main character energy ✨
#include "copyrt.h"
#include <string.h>
#include <stdio.h>
#include <stdlib.h>
#include <time.h>
#include "sysdep.h"
#include "uuid.h"
/* various forward declarations */
static int read_state(unsigned16 *clockseq, uuid_time_t *timestamp,
uuid_node_t *node);
static void write_state(unsigned16 clockseq, uuid_time_t timestamp,
uuid_node_t node);
static void format_uuid_v1(uuid_t *uuid, unsigned16 clockseq,
uuid_time_t timestamp, uuid_node_t node);
static void format_uuid_v3or5(uuid_t *uuid, unsigned char hash[16],
int v);
static void get_current_time(uuid_time_t *timestamp);
static unsigned16 true_random(void);
/* uuid_create -- generator a UUID */
int uuid_create(uuid_t *uuid)
{
uuid_time_t timestamp, last_time;
unsigned16 clockseq;
uuid_node_t node;
uuid_node_t last_node;
int f;
/* acquire system-wide lock so we're alone */
LOCK;
/* get time, node ID, saved state from non-volatile storage */
get_current_time(×tamp);
get_ieee_node_identifier(&node);
f = read_state(&clockseq, &last_time, &last_node);
/* if no NV state, or if clock went backwards, or node ID
changed (e.g., new network card) change clockseq */
if (!f || memcmp(&node, &last_node, sizeof node))
clockseq = true_random();
else if (timestamp < last_time)
clockseq++;
/* save the state for next time */
write_state(clockseq, timestamp, node);
UNLOCK;
/* stuff fields into the UUID */
format_uuid_v1(uuid, clockseq, timestamp, node);
return 1;
}
/* format_uuid_v1 -- make a UUID from the timestamp, clockseq,
and node ID */
void format_uuid_v1(uuid_t* uuid, unsigned16 clock_seq,
uuid_time_t timestamp, uuid_node_t node)
{
/* Construct a version 1 uuid with the information we've gathered
plus a few constants. */
uuid->time_low = (unsigned long)(timestamp & 0xFFFFFFFF);
uuid->time_mid = (unsigned short)((timestamp >> 32) & 0xFFFF);
uuid->time_hi_and_version =
(unsigned short)((timestamp >> 48) & 0x0FFF);
uuid->time_hi_and_version |= (1 << 12);
uuid->clock_seq_low = clock_seq & 0xFF;
uuid->clock_seq_hi_and_reserved = (clock_seq & 0x3F00) >> 8;
uuid->clock_seq_hi_and_reserved |= 0x80;
memcpy(&uuid->node, &node, sizeof uuid->node);
}
/* data type for UUID generator persistent state */
typedef struct {
uuid_time_t ts; /* saved timestamp */
uuid_node_t node; /* saved node ID */
unsigned16 cs; /* saved clock sequence */
} uuid_state;
static uuid_state st;
/* read_state -- read UUID generator state from non-volatile store */
int read_state(unsigned16 *clockseq, uuid_time_t *timestamp,
uuid_node_t *node)
{
static int inited = 0;
FILE *fp;
/* only need to read state once per boot */
if (!inited) {
fp = fopen("state", "rb");
if (fp == NULL)
return 0;
fread(&st, sizeof st, 1, fp);
fclose(fp);
inited = 1;
}
*clockseq = st.cs;
*timestamp = st.ts;
*node = st.node;
return 1;
}
/* write_state -- save UUID generator state back to non-volatile
storage */
void write_state(unsigned16 clockseq, uuid_time_t timestamp,
uuid_node_t node)
{
static int inited = 0;
static uuid_time_t next_save;
FILE* fp;
if (!inited) {
next_save = timestamp;
inited = 1;
}
/* always save state to volatile shared state */
st.cs = clockseq;
st.ts = timestamp;
st.node = node;
if (timestamp >= next_save) {
fp = fopen("state", "wb");
fwrite(&st, sizeof st, 1, fp);
fclose(fp);
/* schedule next save for 10 seconds from now */
next_save = timestamp + (10 * 10 * 1000 * 1000);
}
}
/* get-current_time -- get time as 60-bit 100ns ticks since UUID epoch.
Compensate for the fact that real clock resolution is
less than 100ns. */
void get_current_time(uuid_time_t *timestamp)
{
static int inited = 0;
static uuid_time_t time_last;
static unsigned16 uuids_this_tick;
uuid_time_t time_now;
if (!inited) {
get_system_time(&time_now);
uuids_this_tick = UUIDS_PER_TICK;
inited = 1;
}
for ( ; ; ) {
get_system_time(&time_now);
/* if clock reading changed since last UUID generated, */
if (time_last != time_now) {
/* reset count of uuids gen'd with this clock reading */
uuids_this_tick = 0;
time_last = time_now;
break;
}
if (uuids_this_tick < UUIDS_PER_TICK) {
uuids_this_tick++;
break;
}
/* going too fast for our clock; spin */
}
/* add the count of uuids to low order bits of the clock reading */
*timestamp = time_now + uuids_this_tick;
}
/* true_random -- generate a crypto-quality random number.
**This sample doesn't do that.** */
static unsigned16 true_random(void)
{
static int inited = 0;
uuid_time_t time_now;
if (!inited) {
get_system_time(&time_now);
time_now = time_now / UUIDS_PER_TICK;
srand((unsigned int)
(((time_now >> 32) ^ time_now) & 0xffffffff));
inited = 1;
}
return rand();
}
/* uuid_create_md5_from_name -- create a version 3 (MD5) UUID using a
"name" from a "name space" */
void uuid_create_md5_from_name(uuid_t *uuid, uuid_t nsid, void *name,
int namelen)
{
MD5_CTX c;
unsigned char hash[16];
uuid_t net_nsid;
/* put name space ID in network byte order so it hashes the same
no matter what endian machine we're on */
net_nsid = nsid;
net_nsid.time_low = htonl(net_nsid.time_low);
net_nsid.time_mid = htons(net_nsid.time_mid);
net_nsid.time_hi_and_version = htons(net_nsid.time_hi_and_version);
MD5Init(&c);
MD5Update(&c, &net_nsid, sizeof net_nsid);
MD5Update(&c, name, namelen);
MD5Final(hash, &c);
/* the hash is in network byte order at this point */
format_uuid_v3or5(uuid, hash, 3);
}
void uuid_create_sha1_from_name(uuid_t *uuid, uuid_t nsid, void *name,
int namelen)
{
SHA_CTX c;
unsigned char hash[20];
uuid_t net_nsid;
/* put name space ID in network byte order so it hashes the same
no matter what endian machine we're on */
net_nsid = nsid;
net_nsid.time_low = htonl(net_nsid.time_low);
net_nsid.time_mid = htons(net_nsid.time_mid);
net_nsid.time_hi_and_version = htons(net_nsid.time_hi_and_version);
SHA1_Init(&c);
SHA1_Update(&c, &net_nsid, sizeof net_nsid);
SHA1_Update(&c, name, namelen);
SHA1_Final(hash, &c);
/* the hash is in network byte order at this point */
format_uuid_v3or5(uuid, hash, 5);
}
/* format_uuid_v3or5 -- make a UUID from a (pseudo)random 128-bit
number */
void format_uuid_v3or5(uuid_t *uuid, unsigned char hash[16], int v)
{
/* convert UUID to local byte order */
memcpy(uuid, hash, sizeof *uuid);
uuid->time_low = ntohl(uuid->time_low);
uuid->time_mid = ntohs(uuid->time_mid);
uuid->time_hi_and_version = ntohs(uuid->time_hi_and_version);
/* put in the variant and version bits */
uuid->time_hi_and_version &= 0x0FFF;
uuid->time_hi_and_version |= (v << 12);
uuid->clock_seq_hi_and_reserved &= 0x3F;
uuid->clock_seq_hi_and_reserved |= 0x80;
}
/* uuid_compare -- Compare two UUID's "lexically" and return */
#define CHECK(f1, f2) if (f1 != f2) return f1 < f2 ? -1 : 1;
int uuid_compare(uuid_t *u1, uuid_t *u2)
{
int i;
CHECK(u1->time_low, u2->time_low);
CHECK(u1->time_mid, u2->time_mid);
CHECK(u1->time_hi_and_version, u2->time_hi_and_version);
CHECK(u1->clock_seq_hi_and_reserved, u2->clock_seq_hi_and_reserved);
CHECK(u1->clock_seq_low, u2->clock_seq_low)
for (i = 0; i < 6; i++) {
if (u1->node[i] < u2->node[i])
return -1;
if (u1->node[i] > u2->node[i])
return 1;
}
return 0;
}
#undef CHECKsysdep.h 🎧
this one holds the platform-specific stuff, the typedefs, and the knobs you can tweak ✨
#include "copyrt.h"
/* remove the following define if you aren't running WIN32 */
#define WININC 0
#ifdef WININC
#include <windows.h>
#else
#include <sys/types.h>
#include <sys/time.h>
#include <sys/sysinfo.h>
#endif
#include "global.h"
/* change to point to where MD5 .h's live; RFC 1321 has sample
implementation */
#include "md5.h"
/* set the following to the number of 100ns ticks of the actual
resolution of your system's clock */
#define UUIDS_PER_TICK 1024
/* Set the following to a calls to get and release a global lock */
#define LOCK
#define UNLOCK
typedef unsigned long unsigned32;
typedef unsigned short unsigned16;
typedef unsigned char unsigned8;
typedef unsigned char byte;
/* Set this to what your compiler uses for 64-bit data type */
#ifdef WININC
#define unsigned64_t unsigned __int64
#define I64(C) C
#else
#define unsigned64_t unsigned long long
#define I64(C) C##LL
#endif
typedef unsigned64_t uuid_time_t;
typedef struct {
char nodeID[6];
} uuid_node_t;
void get_ieee_node_identifier(uuid_node_t *node);
void get_system_time(uuid_time_t *uuid_time);
void get_random_info(char seed[16]);sysdep.c 🌸
last stop for this part: the node ID and system time helpers, and it gets cut off right where the Windows branch starts, so we'll pick it up next bestie 🫶
#include "copyrt.h"
#include <stdio.h>
#include "sysdep.h"
/* system dependent call to get IEEE node ID.
This sample implementation generates a random node ID. */
void get_ieee_node_identifier(uuid_node_t *node)
{
static inited = 0;
static uuid_node_t saved_node;
char seed[16];
FILE *fp;
if (!inited) {
fp = fopen("nodeid", "rb");
if (fp) {
fread(&saved_node, sizeof saved_node, 1, fp);
fclose(fp);
}
else {
get_random_info(seed);
seed[0] |= 0x01;
memcpy(&saved_node, seed, sizeof saved_node);
fp = fopen("nodeid", "wb");
if (fp) {
fwrite(&saved_node, sizeof saved_node, 1, fp);
fclose(fp);
}
}
inited = 1;
}
*node = saved_node;
}
/* system dependent call to get the current system time. Returned as
100ns ticks since UUID epoch, but resolution may be less than
100ns. */
#ifdef _WINDOWS_
void get_system_time(uuid_time_t *uuid_time)Okay bestie, the timekeeping code is where it gets spicy 🌶️✨ Windows NT keeps time as FILETIME, so the code has to shift it over to the UUID epoch before it's usable.
ULARGE_INTEGER time;
/* NT keeps time in FILETIME format which is 100ns ticks since
Jan 1, 1601. UUIDs use time in 100ns ticks since Oct 15, 1582.
The difference is 17 Days in Oct + 30 (Nov) + 31 (Dec)
+ 18 years and 5 leap days. */
GetSystemTimeAsFileTime((FILETIME *)&time);
time.QuadPart +=
(unsigned __int64) (1000*1000*10) // seconds
* (unsigned __int64) (60 * 60 * 24) // days
* (unsigned __int64) (17+30+31+365*18+5); // # of days
*uuid_time = time.QuadPart;
}Bestie, the math here is giving main character 🧮💅 Every second is 10 million ticks, times the seconds in a day, times the total days between the two epochs. 🌸
The random seed function is labelled as sample code only, so please don't ship it to prod 🙈 It mixes a bunch of system state into an MD5 hash for the seed. Here's the NT version. 💜
/* Sample code, not for use in production; see RFC 1750 */
void get_random_info(char seed[16])
{
MD5_CTX c;
struct {
MEMORYSTATUS m;
SYSTEM_INFO s;
FILETIME t;
LARGE_INTEGER pc;
DWORD tc;
DWORD l;
char hostname[MAX_COMPUTERNAME_LENGTH + 1];
} r;
MD5Init(&c);
GlobalMemoryStatus(&r.m);
GetSystemInfo(&r.s);
GetSystemTimeAsFileTime(&r.t);
QueryPerformanceCounter(&r.pc);
r.tc = GetTickCount();
r.l = MAX_COMPUTERNAME_LENGTH + 1;
GetComputerName(r.hostname, &r.l);
MD5Update(&c, &r, sizeof r);
MD5Final(seed, &c);
}Now for the non-Windows branch 🦋 It's the same idea, just with the Unix tools: gettimeofday, sysinfo and gethostname.
#else
void get_system_time(uuid_time_t *uuid_time)
{
struct timeval tp;
gettimeofday(&tp, (struct timezone *)0);
/* Offset between UUID formatted times and Unix formatted times.
UUID UTC base time is October 15, 1582.
Unix base time is January 1, 1970.*/
*uuid_time = ((unsigned64)tp.tv_sec * 10000000)
+ ((unsigned64)tp.tv_usec * 10)
+ I64(0x01B21DD213814000);
}
/* Sample code, not for use in production; see RFC 1750 */
void get_random_info(char seed[16])
{
MD5_CTX c;
struct {
struct sysinfo s;
struct timeval t;
char hostname[257];
} r;
MD5Init(&c);
sysinfo(&r.s);
gettimeofday(&r.t, (struct timezone *)0);
gethostname(r.hostname, 256);
MD5Update(&c, &r, sizeof r);
MD5Final(seed, &c);
}
#endifNext up is the sample driver, utest.c 🍓 It shows off the whole generator, from making a random UUID to comparing UUIDs and making a name-based one.
#include "copyrt.h"
#include "sysdep.h"
#include <stdio.h>
#include "uuid.h"
uuid_t NameSpace_DNS = { /* 6ba7b810-9dad-11d1-80b4-00c04fd430c8 */
0x6ba7b810,
0x9dad,
0x11d1,
0x80, 0xb4, 0x00, 0xc0, 0x4f, 0xd4, 0x30, 0xc8
};
/* puid -- print a UUID */
void puid(uuid_t u)
{
int i;
printf("%8.8x-%4.4x-%4.4x-%2.2x%2.2x-", u.time_low, u.time_mid,
u.time_hi_and_version, u.clock_seq_hi_and_reserved,
u.clock_seq_low);
for (i = 0; i < 6; i++)
printf("%2.2x", u.node[i]);
printf("\n");
}
/* Simple driver for UUID generator */
void main(int argc, char **argv)
{
uuid_t u;
int f;
uuid_create(&u);
printf("uuid_create(): "); puid(u);
f = uuid_compare(&u, &u);
printf("uuid_compare(u,u): %d\n", f); /* should be 0 */
f = uuid_compare(&u, &NameSpace_DNS);
printf("uuid_compare(u, NameSpace_DNS): %d\n", f); /* s.b. 1 */
f = uuid_compare(&NameSpace_DNS, &u);
printf("uuid_compare(NameSpace_DNS, u): %d\n", f); /* s.b. -1 */
uuid_create_md5_from_name(&u, NameSpace_DNS, "www.widgets.com", 15);
printf("uuid_create_md5_from_name(): "); puid(u);
}Appendix B. Sample Output of utest 🧚
Here's what the driver prints out when you run it. Your UUIDs will look different since uuid_create() is random, but the comparison results should line up. ✨
uuid_create(): 7d444840-9dc0-11d1-b245-5ffdce74fad2
uuid_compare(u,u): 0
uuid_compare(u, NameSpace_DNS): 1
uuid_compare(NameSpace_DNS, u): -1
uuid_create_md5_from_name(): e902893a-9d22-3c7e-a7b8-d6e313b71d9fAppendix C. Some Name Space IDs 🌈
This appendix lists the name space IDs for some potentially interesting name spaces, both as initialized C structures and in the string representation we talked about earlier. Every one of these is its own namespace, so pick the right one for what you're hashing 💅
/* Name string is a fully-qualified domain name */
uuid_t NameSpace_DNS = { /* 6ba7b810-9dad-11d1-80b4-00c04fd430c8 */
0x6ba7b810,
0x9dad,
0x11d1,
0x80, 0xb4, 0x00, 0xc0, 0x4f, 0xd4, 0x30, 0xc8
};
/* Name string is a URL */
uuid_t NameSpace_URL = { /* 6ba7b811-9dad-11d1-80b4-00c04fd430c8 */
0x6ba7b811,
0x9dad,
0x11d1,
0x80, 0xb4, 0x00, 0xc0, 0x4f, 0xd4, 0x30, 0xc8
};
/* Name string is an ISO OID */
uuid_t NameSpace_OID = { /* 6ba7b812-9dad-11d1-80b4-00c04fd430c8 */
0x6ba7b812,
0x9dad,
0x11d1,
0x80, 0xb4, 0x00, 0xc0, 0x4f, 0xd4, 0x30, 0xc8
};
/* Name string is an X.500 DN (in DER or a text output format) */
uuid_t NameSpace_X500 = { /* 6ba7b814-9dad-11d1-80b4-00c04fd430c8 */
0x6ba7b814,
0x9dad,
0x11d1,
0x80, 0xb4, 0x00, 0xc0, 0x4f, 0xd4, 0x30, 0xc8
};Authors' Addresses 🖋️
Here's who wrote this, with their contact details exactly as they're listed. 🫶
Paul J. Leach
Microsoft
1 Microsoft Way
Redmond, WA 98052
US
Phone: +1 425-882-8080
EMail: paulle@microsoft.com Michael Mealling
Refactored Networks, LLC
1635 Old Hwy 41
Suite 112, Box 138
Kennesaw, GA 30152
US
Phone: +1-678-581-9656
EMail: michael@refactored-networks.com
URI: http://www.refactored-networks.com Rich Salz
DataPower Technology, Inc.
1 Alewife Center
Cambridge, MA 02142
US
Phone: +1 617-864-0455
EMail: rsalz@datapower.com
URI: http://www.datapower.comFull Copyright Statement ©
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property 🔐
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
Acknowledgement 🌸
Funding for the RFC Editor function is currently provided by the Internet Society. 💖
📦 where this page comes from
- ietf: rfc4122 2005-07
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms