]>
Commit | Line | Data |
---|---|---|
4744bd90 | 1 | |
2 | ||
3 | ||
4 | ||
5 | ||
6 | ||
7 | Network Working Group P. Leach | |
8 | Request for Comments: 4122 Microsoft | |
9 | Category: Standards Track M. Mealling | |
10 | Refactored Networks, LLC | |
11 | R. Salz | |
12 | DataPower Technology, Inc. | |
13 | July 2005 | |
14 | ||
15 | ||
16 | A Universally Unique IDentifier (UUID) URN Namespace | |
17 | ||
18 | Status of This Memo | |
19 | ||
20 | This document specifies an Internet standards track protocol for the | |
21 | Internet community, and requests discussion and suggestions for | |
22 | improvements. Please refer to the current edition of the "Internet | |
23 | Official Protocol Standards" (STD 1) for the standardization state | |
24 | and status of this protocol. Distribution of this memo is unlimited. | |
25 | ||
26 | Copyright Notice | |
27 | ||
28 | Copyright (C) The Internet Society (2005). | |
29 | ||
30 | Abstract | |
31 | ||
32 | This specification defines a Uniform Resource Name namespace for | |
33 | UUIDs (Universally Unique IDentifier), also known as GUIDs (Globally | |
34 | Unique IDentifier). A UUID is 128 bits long, and can guarantee | |
35 | uniqueness across space and time. UUIDs were originally used in the | |
36 | Apollo Network Computing System and later in the Open Software | |
37 | Foundation's (OSF) Distributed Computing Environment (DCE), and then | |
38 | in Microsoft Windows platforms. | |
39 | ||
40 | This specification is derived from the DCE specification with the | |
41 | kind permission of the OSF (now known as The Open Group). | |
42 | Information from earlier versions of the DCE specification have been | |
43 | incorporated into this document. | |
44 | ||
45 | ||
46 | ||
47 | ||
48 | ||
49 | ||
50 | ||
51 | ||
52 | ||
53 | ||
54 | ||
55 | ||
56 | ||
57 | ||
58 | Leach, et al. Standards Track [Page 1] | |
59 | \f | |
60 | RFC 4122 A UUID URN Namespace July 2005 | |
61 | ||
62 | ||
63 | Table of Contents | |
64 | ||
65 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 | |
66 | 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 | |
67 | 3. Namespace Registration Template . . . . . . . . . . . . . . . 3 | |
68 | 4. Specification . . . . . . . . . . . . . . . . . . . . . . . . 5 | |
69 | 4.1. Format. . . . . . . . . . . . . . . . . . . . . . . . . . 5 | |
70 | 4.1.1. Variant. . . . . . . . . . . . . . . . . . . . . . 6 | |
71 | 4.1.2. Layout and Byte Order. . . . . . . . . . . . . . . 6 | |
72 | 4.1.3. Version. . . . . . . . . . . . . . . . . . . . . . 7 | |
73 | 4.1.4. Timestamp. . . . . . . . . . . . . . . . . . . . . 8 | |
74 | 4.1.5. Clock Sequence . . . . . . . . . . . . . . . . . . 8 | |
75 | 4.1.6. Node . . . . . . . . . . . . . . . . . . . . . . . 9 | |
76 | 4.1.7. Nil UUID . . . . . . . . . . . . . . . . . . . . . 9 | |
77 | 4.2. Algorithms for Creating a Time-Based UUID . . . . . . . . 9 | |
78 | 4.2.1. Basic Algorithm. . . . . . . . . . . . . . . . . . 10 | |
79 | 4.2.2. Generation Details . . . . . . . . . . . . . . . . 12 | |
80 | 4.3. Algorithm for Creating a Name-Based UUID. . . . . . . . . 13 | |
81 | 4.4. Algorithms for Creating a UUID from Truly Random or | |
82 | Pseudo-Random Numbers . . . . . . . . . . . . . . . . . . 14 | |
83 | 4.5. Node IDs that Do Not Identify the Host. . . . . . . . . . 15 | |
84 | 5. Community Considerations . . . . . . . . . . . . . . . . . . . 15 | |
85 | 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 | |
86 | 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 | |
87 | 8. Normative References . . . . . . . . . . . . . . . . . . . . . 16 | |
88 | A. Appendix A - Sample Implementation . . . . . . . . . . . . . . 18 | |
89 | B. Appendix B - Sample Output of utest . . . . . . . . . . . . . 29 | |
90 | C. Appendix C - Some Name Space IDs . . . . . . . . . . . . . . . 30 | |
91 | ||
92 | 1. Introduction | |
93 | ||
94 | This specification defines a Uniform Resource Name namespace for | |
95 | UUIDs (Universally Unique IDentifier), also known as GUIDs (Globally | |
96 | Unique IDentifier). A UUID is 128 bits long, and requires no central | |
97 | registration process. | |
98 | ||
99 | The information here is meant to be a concise guide for those wishing | |
100 | to implement services using UUIDs as URNs. Nothing in this document | |
101 | should be construed to override the DCE standards that defined UUIDs. | |
102 | ||
103 | There is an ITU-T Recommendation and ISO/IEC Standard [3] that are | |
104 | derived from earlier versions of this document. Both sets of | |
105 | specifications have been aligned, and are fully technically | |
106 | compatible. In addition, a global registration function is being | |
107 | provided by the Telecommunications Standardisation Bureau of ITU-T; | |
108 | for details see <http://www.itu.int/ITU-T/asn1/uuid.html>. | |
109 | ||
110 | ||
111 | ||
112 | ||
113 | ||
114 | Leach, et al. Standards Track [Page 2] | |
115 | \f | |
116 | RFC 4122 A UUID URN Namespace July 2005 | |
117 | ||
118 | ||
119 | 2. Motivation | |
120 | ||
121 | One of the main reasons for using UUIDs is that no centralized | |
122 | authority is required to administer them (although one format uses | |
123 | IEEE 802 node identifiers, others do not). As a result, generation | |
124 | on demand can be completely automated, and used for a variety of | |
125 | purposes. The UUID generation algorithm described here supports very | |
126 | high allocation rates of up to 10 million per second per machine if | |
127 | necessary, so that they could even be used as transaction IDs. | |
128 | ||
129 | UUIDs are of a fixed size (128 bits) which is reasonably small | |
130 | compared to other alternatives. This lends itself well to sorting, | |
131 | ordering, and hashing of all sorts, storing in databases, simple | |
132 | allocation, and ease of programming in general. | |
133 | ||
134 | Since UUIDs are unique and persistent, they make excellent Uniform | |
135 | Resource Names. The unique ability to generate a new UUID without a | |
136 | registration process allows for UUIDs to be one of the URNs with the | |
137 | lowest minting cost. | |
138 | ||
139 | 3. Namespace Registration Template | |
140 | ||
141 | Namespace ID: UUID | |
142 | Registration Information: | |
143 | Registration date: 2003-10-01 | |
144 | ||
145 | Declared registrant of the namespace: | |
146 | JTC 1/SC6 (ASN.1 Rapporteur Group) | |
147 | ||
148 | Declaration of syntactic structure: | |
149 | A UUID is an identifier that is unique across both space and time, | |
150 | with respect to the space of all UUIDs. Since a UUID is a fixed | |
151 | size and contains a time field, it is possible for values to | |
152 | rollover (around A.D. 3400, depending on the specific algorithm | |
153 | used). A UUID can be used for multiple purposes, from tagging | |
154 | objects with an extremely short lifetime, to reliably identifying | |
155 | very persistent objects across a network. | |
156 | ||
157 | The internal representation of a UUID is a specific sequence of | |
158 | bits in memory, as described in Section 4. To accurately | |
159 | represent a UUID as a URN, it is necessary to convert the bit | |
160 | sequence to a string representation. | |
161 | ||
162 | Each field is treated as an integer and has its value printed as a | |
163 | zero-filled hexadecimal digit string with the most significant | |
164 | digit first. The hexadecimal values "a" through "f" are output as | |
165 | lower case characters and are case insensitive on input. | |
166 | ||
167 | ||
168 | ||
169 | ||
170 | Leach, et al. Standards Track [Page 3] | |
171 | \f | |
172 | RFC 4122 A UUID URN Namespace July 2005 | |
173 | ||
174 | ||
175 | The formal definition of the UUID string representation is | |
176 | provided by the following ABNF [7]: | |
177 | ||
178 | UUID = time-low "-" time-mid "-" | |
179 | time-high-and-version "-" | |
180 | clock-seq-and-reserved | |
181 | clock-seq-low "-" node | |
182 | time-low = 4hexOctet | |
183 | time-mid = 2hexOctet | |
184 | time-high-and-version = 2hexOctet | |
185 | clock-seq-and-reserved = hexOctet | |
186 | clock-seq-low = hexOctet | |
187 | node = 6hexOctet | |
188 | hexOctet = hexDigit hexDigit | |
189 | hexDigit = | |
190 | "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9" / | |
191 | "a" / "b" / "c" / "d" / "e" / "f" / | |
192 | "A" / "B" / "C" / "D" / "E" / "F" | |
193 | ||
194 | The following is an example of the string representation of a UUID as | |
195 | a URN: | |
196 | ||
197 | urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 | |
198 | ||
199 | Relevant ancillary documentation: | |
200 | [1][2] | |
201 | Identifier uniqueness considerations: | |
202 | This document specifies three algorithms to generate UUIDs: the | |
203 | first leverages the unique values of 802 MAC addresses to | |
204 | guarantee uniqueness, the second uses pseudo-random number | |
205 | generators, and the third uses cryptographic hashing and | |
206 | application-provided text strings. As a result, the UUIDs | |
207 | generated according to the mechanisms here will be unique from all | |
208 | other UUIDs that have been or will be assigned. | |
209 | ||
210 | Identifier persistence considerations: | |
211 | UUIDs are inherently very difficult to resolve in a global sense. | |
212 | This, coupled with the fact that UUIDs are temporally unique | |
213 | within their spatial context, ensures that UUIDs will remain as | |
214 | persistent as possible. | |
215 | ||
216 | Process of identifier assignment: | |
217 | Generating a UUID does not require that a registration authority | |
218 | be contacted. One algorithm requires a unique value over space | |
219 | for each generator. This value is typically an IEEE 802 MAC | |
220 | address, usually already available on network-connected hosts. | |
221 | The address can be assigned from an address block obtained from | |
222 | the IEEE registration authority. If no such address is available, | |
223 | ||
224 | ||
225 | ||
226 | Leach, et al. Standards Track [Page 4] | |
227 | \f | |
228 | RFC 4122 A UUID URN Namespace July 2005 | |
229 | ||
230 | ||
231 | or privacy concerns make its use undesirable, Section 4.5 | |
232 | specifies two alternatives. Another approach is to use version 3 | |
233 | or version 4 UUIDs as defined below. | |
234 | ||
235 | Process for identifier resolution: | |
236 | Since UUIDs are not globally resolvable, this is not applicable. | |
237 | ||
238 | Rules for Lexical Equivalence: | |
239 | Consider each field of the UUID to be an unsigned integer as shown | |
240 | in the table in section Section 4.1.2. Then, to compare a pair of | |
241 | UUIDs, arithmetically compare the corresponding fields from each | |
242 | UUID in order of significance and according to their data type. | |
243 | Two UUIDs are equal if and only if all the corresponding fields | |
244 | are equal. | |
245 | ||
246 | As an implementation note, equality comparison can be performed on | |
247 | many systems by doing the appropriate byte-order canonicalization, | |
248 | and then treating the two UUIDs as 128-bit unsigned integers. | |
249 | ||
250 | UUIDs, as defined in this document, can also be ordered | |
251 | lexicographically. For a pair of UUIDs, the first one follows the | |
252 | second if the most significant field in which the UUIDs differ is | |
253 | greater for the first UUID. The second precedes the first if the | |
254 | most significant field in which the UUIDs differ is greater for | |
255 | the second UUID. | |
256 | ||
257 | Conformance with URN Syntax: | |
258 | The string representation of a UUID is fully compatible with the | |
259 | URN syntax. When converting from a bit-oriented, in-memory | |
260 | representation of a UUID into a URN, care must be taken to | |
261 | strictly adhere to the byte order issues mentioned in the string | |
262 | representation section. | |
263 | ||
264 | Validation mechanism: | |
265 | Apart from determining whether the timestamp portion of the UUID | |
266 | is in the future and therefore not yet assignable, there is no | |
267 | mechanism for determining whether a UUID is 'valid'. | |
268 | ||
269 | Scope: | |
270 | UUIDs are global in scope. | |
271 | ||
272 | 4. Specification | |
273 | ||
274 | 4.1. Format | |
275 | ||
276 | The UUID format is 16 octets; some bits of the eight octet variant | |
277 | field specified below determine finer structure. | |
278 | ||
279 | ||
280 | ||
281 | ||
282 | Leach, et al. Standards Track [Page 5] | |
283 | \f | |
284 | RFC 4122 A UUID URN Namespace July 2005 | |
285 | ||
286 | ||
287 | 4.1.1. Variant | |
288 | ||
289 | The variant field determines the layout of the UUID. That is, the | |
290 | interpretation of all other bits in the UUID depends on the setting | |
291 | of the bits in the variant field. As such, it could more accurately | |
292 | be called a type field; we retain the original term for | |
293 | compatibility. The variant field consists of a variable number of | |
294 | the most significant bits of octet 8 of the UUID. | |
295 | ||
296 | The following table lists the contents of the variant field, where | |
297 | the letter "x" indicates a "don't-care" value. | |
298 | ||
299 | Msb0 Msb1 Msb2 Description | |
300 | ||
301 | 0 x x Reserved, NCS backward compatibility. | |
302 | ||
303 | 1 0 x The variant specified in this document. | |
304 | ||
305 | 1 1 0 Reserved, Microsoft Corporation backward | |
306 | compatibility | |
307 | ||
308 | 1 1 1 Reserved for future definition. | |
309 | ||
310 | Interoperability, in any form, with variants other than the one | |
311 | defined here is not guaranteed, and is not likely to be an issue in | |
312 | practice. | |
313 | ||
314 | 4.1.2. Layout and Byte Order | |
315 | ||
316 | To minimize confusion about bit assignments within octets, the UUID | |
317 | record definition is defined only in terms of fields that are | |
318 | integral numbers of octets. The fields are presented with the most | |
319 | significant one first. | |
320 | ||
321 | Field Data Type Octet Note | |
322 | # | |
323 | ||
324 | time_low unsigned 32 0-3 The low field of the | |
325 | bit integer timestamp | |
326 | ||
327 | time_mid unsigned 16 4-5 The middle field of the | |
328 | bit integer timestamp | |
329 | ||
330 | time_hi_and_version unsigned 16 6-7 The high field of the | |
331 | bit integer timestamp multiplexed | |
332 | with the version number | |
333 | ||
334 | ||
335 | ||
336 | ||
337 | ||
338 | Leach, et al. Standards Track [Page 6] | |
339 | \f | |
340 | RFC 4122 A UUID URN Namespace July 2005 | |
341 | ||
342 | ||
343 | clock_seq_hi_and_rese unsigned 8 8 The high field of the | |
344 | rved bit integer clock sequence | |
345 | multiplexed with the | |
346 | variant | |
347 | ||
348 | clock_seq_low unsigned 8 9 The low field of the | |
349 | bit integer clock sequence | |
350 | ||
351 | node unsigned 48 10-15 The spatially unique | |
352 | bit integer node identifier | |
353 | ||
354 | In the absence of explicit application or presentation protocol | |
355 | specification to the contrary, a UUID is encoded as a 128-bit object, | |
356 | as follows: | |
357 | ||
358 | The fields are encoded as 16 octets, with the sizes and order of the | |
359 | fields defined above, and with each field encoded with the Most | |
360 | Significant Byte first (known as network byte order). Note that the | |
361 | field names, particularly for multiplexed fields, follow historical | |
362 | practice. | |
363 | ||
364 | 0 1 2 3 | |
365 | 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 | |
366 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
367 | | time_low | | |
368 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
369 | | time_mid | time_hi_and_version | | |
370 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
371 | |clk_seq_hi_res | clk_seq_low | node (0-1) | | |
372 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
373 | | node (2-5) | | |
374 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
375 | ||
376 | 4.1.3. Version | |
377 | ||
378 | The version number is in the most significant 4 bits of the time | |
379 | stamp (bits 4 through 7 of the time_hi_and_version field). | |
380 | ||
381 | The following table lists the currently-defined versions for this | |
382 | UUID variant. | |
383 | ||
384 | Msb0 Msb1 Msb2 Msb3 Version Description | |
385 | ||
386 | 0 0 0 1 1 The time-based version | |
387 | specified in this document. | |
388 | ||
389 | 0 0 1 0 2 DCE Security version, with | |
390 | embedded POSIX UIDs. | |
391 | ||
392 | ||
393 | ||
394 | Leach, et al. Standards Track [Page 7] | |
395 | \f | |
396 | RFC 4122 A UUID URN Namespace July 2005 | |
397 | ||
398 | ||
399 | 0 0 1 1 3 The name-based version | |
400 | specified in this document | |
401 | that uses MD5 hashing. | |
402 | ||
403 | 0 1 0 0 4 The randomly or pseudo- | |
404 | randomly generated version | |
405 | specified in this document. | |
406 | ||
407 | 0 1 0 1 5 The name-based version | |
408 | specified in this document | |
409 | that uses SHA-1 hashing. | |
410 | ||
411 | The version is more accurately a sub-type; again, we retain the term | |
412 | for compatibility. | |
413 | ||
414 | 4.1.4. Timestamp | |
415 | ||
416 | The timestamp is a 60-bit value. For UUID version 1, this is | |
417 | represented by Coordinated Universal Time (UTC) as a count of 100- | |
418 | nanosecond intervals since 00:00:00.00, 15 October 1582 (the date of | |
419 | Gregorian reform to the Christian calendar). | |
420 | ||
421 | For systems that do not have UTC available, but do have the local | |
422 | time, they may use that instead of UTC, as long as they do so | |
423 | consistently throughout the system. However, this is not recommended | |
424 | since generating the UTC from local time only needs a time zone | |
425 | offset. | |
426 | ||
427 | For UUID version 3 or 5, the timestamp is a 60-bit value constructed | |
428 | from a name as described in Section 4.3. | |
429 | ||
430 | For UUID version 4, the timestamp is a randomly or pseudo-randomly | |
431 | generated 60-bit value, as described in Section 4.4. | |
432 | ||
433 | 4.1.5. Clock Sequence | |
434 | ||
435 | For UUID version 1, the clock sequence is used to help avoid | |
436 | duplicates that could arise when the clock is set backwards in time | |
437 | or if the node ID changes. | |
438 | ||
439 | If the clock is set backwards, or might have been set backwards | |
440 | (e.g., while the system was powered off), and the UUID generator can | |
441 | not be sure that no UUIDs were generated with timestamps larger than | |
442 | the value to which the clock was set, then the clock sequence has to | |
443 | be changed. If the previous value of the clock sequence is known, it | |
444 | can just be incremented; otherwise it should be set to a random or | |
445 | high-quality pseudo-random value. | |
446 | ||
447 | ||
448 | ||
449 | ||
450 | Leach, et al. Standards Track [Page 8] | |
451 | \f | |
452 | RFC 4122 A UUID URN Namespace July 2005 | |
453 | ||
454 | ||
455 | Similarly, if the node ID changes (e.g., because a network card has | |
456 | been moved between machines), setting the clock sequence to a random | |
457 | number minimizes the probability of a duplicate due to slight | |
458 | differences in the clock settings of the machines. If the value of | |
459 | clock sequence associated with the changed node ID were known, then | |
460 | the clock sequence could just be incremented, but that is unlikely. | |
461 | ||
462 | The clock sequence MUST be originally (i.e., once in the lifetime of | |
463 | a system) initialized to a random number to minimize the correlation | |
464 | across systems. This provides maximum protection against node | |
465 | identifiers that may move or switch from system to system rapidly. | |
466 | The initial value MUST NOT be correlated to the node identifier. | |
467 | ||
468 | For UUID version 3 or 5, the clock sequence is a 14-bit value | |
469 | constructed from a name as described in Section 4.3. | |
470 | ||
471 | For UUID version 4, clock sequence is a randomly or pseudo-randomly | |
472 | generated 14-bit value as described in Section 4.4. | |
473 | ||
474 | 4.1.6. Node | |
475 | ||
476 | For UUID version 1, the node field consists of an IEEE 802 MAC | |
477 | address, usually the host address. For systems with multiple IEEE | |
478 | 802 addresses, any available one can be used. The lowest addressed | |
479 | octet (octet number 10) contains the global/local bit and the | |
480 | unicast/multicast bit, and is the first octet of the address | |
481 | transmitted on an 802.3 LAN. | |
482 | ||
483 | For systems with no IEEE address, a randomly or pseudo-randomly | |
484 | generated value may be used; see Section 4.5. The multicast bit must | |
485 | be set in such addresses, in order that they will never conflict with | |
486 | addresses obtained from network cards. | |
487 | ||
488 | For UUID version 3 or 5, the node field is a 48-bit value constructed | |
489 | from a name as described in Section 4.3. | |
490 | ||
491 | For UUID version 4, the node field is a randomly or pseudo-randomly | |
492 | generated 48-bit value as described in Section 4.4. | |
493 | ||
494 | 4.1.7. Nil UUID | |
495 | ||
496 | The nil UUID is special form of UUID that is specified to have all | |
497 | 128 bits set to zero. | |
498 | ||
499 | 4.2. Algorithms for Creating a Time-Based UUID | |
500 | ||
501 | Various aspects of the algorithm for creating a version 1 UUID are | |
502 | discussed in the following sections. | |
503 | ||
504 | ||
505 | ||
506 | Leach, et al. Standards Track [Page 9] | |
507 | \f | |
508 | RFC 4122 A UUID URN Namespace July 2005 | |
509 | ||
510 | ||
511 | 4.2.1. Basic Algorithm | |
512 | ||
513 | The following algorithm is simple, correct, and inefficient: | |
514 | ||
515 | o Obtain a system-wide global lock | |
516 | ||
517 | o From a system-wide shared stable store (e.g., a file), read the | |
518 | UUID generator state: the values of the timestamp, clock sequence, | |
519 | and node ID used to generate the last UUID. | |
520 | ||
521 | o Get the current time as a 60-bit count of 100-nanosecond intervals | |
522 | since 00:00:00.00, 15 October 1582. | |
523 | ||
524 | o Get the current node ID. | |
525 | ||
526 | o If the state was unavailable (e.g., non-existent or corrupted), or | |
527 | the saved node ID is different than the current node ID, generate | |
528 | a random clock sequence value. | |
529 | ||
530 | o If the state was available, but the saved timestamp is later than | |
531 | the current timestamp, increment the clock sequence value. | |
532 | ||
533 | o Save the state (current timestamp, clock sequence, and node ID) | |
534 | back to the stable store. | |
535 | ||
536 | o Release the global lock. | |
537 | ||
538 | o Format a UUID from the current timestamp, clock sequence, and node | |
539 | ID values according to the steps in Section 4.2.2. | |
540 | ||
541 | If UUIDs do not need to be frequently generated, the above algorithm | |
542 | may be perfectly adequate. For higher performance requirements, | |
543 | however, issues with the basic algorithm include: | |
544 | ||
545 | o Reading the state from stable storage each time is inefficient. | |
546 | ||
547 | o The resolution of the system clock may not be 100-nanoseconds. | |
548 | ||
549 | o Writing the state to stable storage each time is inefficient. | |
550 | ||
551 | o Sharing the state across process boundaries may be inefficient. | |
552 | ||
553 | Each of these issues can be addressed in a modular fashion by local | |
554 | improvements in the functions that read and write the state and read | |
555 | the clock. We address each of them in turn in the following | |
556 | sections. | |
557 | ||
558 | ||
559 | ||
560 | ||
561 | ||
562 | Leach, et al. Standards Track [Page 10] | |
563 | \f | |
564 | RFC 4122 A UUID URN Namespace July 2005 | |
565 | ||
566 | ||
567 | 4.2.1.1. Reading Stable Storage | |
568 | ||
569 | The state only needs to be read from stable storage once at boot | |
570 | time, if it is read into a system-wide shared volatile store (and | |
571 | updated whenever the stable store is updated). | |
572 | ||
573 | If an implementation does not have any stable store available, then | |
574 | it can always say that the values were unavailable. This is the | |
575 | least desirable implementation because it will increase the frequency | |
576 | of creation of new clock sequence numbers, which increases the | |
577 | probability of duplicates. | |
578 | ||
579 | If the node ID can never change (e.g., the net card is inseparable | |
580 | from the system), or if any change also reinitializes the clock | |
581 | sequence to a random value, then instead of keeping it in stable | |
582 | store, the current node ID may be returned. | |
583 | ||
584 | 4.2.1.2. System Clock Resolution | |
585 | ||
586 | The timestamp is generated from the system time, whose resolution may | |
587 | be less than the resolution of the UUID timestamp. | |
588 | ||
589 | If UUIDs do not need to be frequently generated, the timestamp can | |
590 | simply be the system time multiplied by the number of 100-nanosecond | |
591 | intervals per system time interval. | |
592 | ||
593 | If a system overruns the generator by requesting too many UUIDs | |
594 | within a single system time interval, the UUID service MUST either | |
595 | return an error, or stall the UUID generator until the system clock | |
596 | catches up. | |
597 | ||
598 | A high resolution timestamp can be simulated by keeping a count of | |
599 | the number of UUIDs that have been generated with the same value of | |
600 | the system time, and using it to construct the low order bits of the | |
601 | timestamp. The count will range between zero and the number of | |
602 | 100-nanosecond intervals per system time interval. | |
603 | ||
604 | Note: If the processors overrun the UUID generation frequently, | |
605 | additional node identifiers can be allocated to the system, which | |
606 | will permit higher speed allocation by making multiple UUIDs | |
607 | potentially available for each time stamp value. | |
608 | ||
609 | 4.2.1.3. Writing Stable Storage | |
610 | ||
611 | The state does not always need to be written to stable store every | |
612 | time a UUID is generated. The timestamp in the stable store can be | |
613 | periodically set to a value larger than any yet used in a UUID. As | |
614 | long as the generated UUIDs have timestamps less than that value, and | |
615 | ||
616 | ||
617 | ||
618 | Leach, et al. Standards Track [Page 11] | |
619 | \f | |
620 | RFC 4122 A UUID URN Namespace July 2005 | |
621 | ||
622 | ||
623 | the clock sequence and node ID remain unchanged, only the shared | |
624 | volatile copy of the state needs to be updated. Furthermore, if the | |
625 | timestamp value in stable store is in the future by less than the | |
626 | typical time it takes the system to reboot, a crash will not cause a | |
627 | reinitialization of the clock sequence. | |
628 | ||
629 | 4.2.1.4. Sharing State Across Processes | |
630 | ||
631 | If it is too expensive to access shared state each time a UUID is | |
632 | generated, then the system-wide generator can be implemented to | |
633 | allocate a block of time stamps each time it is called; a per- | |
634 | process generator can allocate from that block until it is exhausted. | |
635 | ||
636 | 4.2.2. Generation Details | |
637 | ||
638 | Version 1 UUIDs are generated according to the following algorithm: | |
639 | ||
640 | o Determine the values for the UTC-based timestamp and clock | |
641 | sequence to be used in the UUID, as described in Section 4.2.1. | |
642 | ||
643 | o For the purposes of this algorithm, consider the timestamp to be a | |
644 | 60-bit unsigned integer and the clock sequence to be a 14-bit | |
645 | unsigned integer. Sequentially number the bits in a field, | |
646 | starting with zero for the least significant bit. | |
647 | ||
648 | o Set the time_low field equal to the least significant 32 bits | |
649 | (bits zero through 31) of the timestamp in the same order of | |
650 | significance. | |
651 | ||
652 | o Set the time_mid field equal to bits 32 through 47 from the | |
653 | timestamp in the same order of significance. | |
654 | ||
655 | o Set the 12 least significant bits (bits zero through 11) of the | |
656 | time_hi_and_version field equal to bits 48 through 59 from the | |
657 | timestamp in the same order of significance. | |
658 | ||
659 | o Set the four most significant bits (bits 12 through 15) of the | |
660 | time_hi_and_version field to the 4-bit version number | |
661 | corresponding to the UUID version being created, as shown in the | |
662 | table above. | |
663 | ||
664 | o Set the clock_seq_low field to the eight least significant bits | |
665 | (bits zero through 7) of the clock sequence in the same order of | |
666 | significance. | |
667 | ||
668 | ||
669 | ||
670 | ||
671 | ||
672 | ||
673 | ||
674 | Leach, et al. Standards Track [Page 12] | |
675 | \f | |
676 | RFC 4122 A UUID URN Namespace July 2005 | |
677 | ||
678 | ||
679 | o Set the 6 least significant bits (bits zero through 5) of the | |
680 | clock_seq_hi_and_reserved field to the 6 most significant bits | |
681 | (bits 8 through 13) of the clock sequence in the same order of | |
682 | significance. | |
683 | ||
684 | o Set the two most significant bits (bits 6 and 7) of the | |
685 | clock_seq_hi_and_reserved to zero and one, respectively. | |
686 | ||
687 | o Set the node field to the 48-bit IEEE address in the same order of | |
688 | significance as the address. | |
689 | ||
690 | 4.3. Algorithm for Creating a Name-Based UUID | |
691 | ||
692 | The version 3 or 5 UUID is meant for generating UUIDs from "names" | |
693 | that are drawn from, and unique within, some "name space". The | |
694 | concept of name and name space should be broadly construed, and not | |
695 | limited to textual names. For example, some name spaces are the | |
696 | domain name system, URLs, ISO Object IDs (OIDs), X.500 Distinguished | |
697 | Names (DNs), and reserved words in a programming language. The | |
698 | mechanisms or conventions used for allocating names and ensuring | |
699 | their uniqueness within their name spaces are beyond the scope of | |
700 | this specification. | |
701 | ||
702 | The requirements for these types of UUIDs are as follows: | |
703 | ||
704 | o The UUIDs generated at different times from the same name in the | |
705 | same namespace MUST be equal. | |
706 | ||
707 | o The UUIDs generated from two different names in the same namespace | |
708 | should be different (with very high probability). | |
709 | ||
710 | o The UUIDs generated from the same name in two different namespaces | |
711 | should be different with (very high probability). | |
712 | ||
713 | o If two UUIDs that were generated from names are equal, then they | |
714 | were generated from the same name in the same namespace (with very | |
715 | high probability). | |
716 | ||
717 | The algorithm for generating a UUID from a name and a name space are | |
718 | as follows: | |
719 | ||
720 | o Allocate a UUID to use as a "name space ID" for all UUIDs | |
721 | generated from names in that name space; see Appendix C for some | |
722 | pre-defined values. | |
723 | ||
724 | o Choose either MD5 [4] or SHA-1 [8] as the hash algorithm; If | |
725 | backward compatibility is not an issue, SHA-1 is preferred. | |
726 | ||
727 | ||
728 | ||
729 | ||
730 | Leach, et al. Standards Track [Page 13] | |
731 | \f | |
732 | RFC 4122 A UUID URN Namespace July 2005 | |
733 | ||
734 | ||
735 | o Convert the name to a canonical sequence of octets (as defined by | |
736 | the standards or conventions of its name space); put the name | |
737 | space ID in network byte order. | |
738 | ||
739 | o Compute the hash of the name space ID concatenated with the name. | |
740 | ||
741 | o Set octets zero through 3 of the time_low field to octets zero | |
742 | through 3 of the hash. | |
743 | ||
744 | o Set octets zero and one of the time_mid field to octets 4 and 5 of | |
745 | the hash. | |
746 | ||
747 | o Set octets zero and one of the time_hi_and_version field to octets | |
748 | 6 and 7 of the hash. | |
749 | ||
750 | o Set the four most significant bits (bits 12 through 15) of the | |
751 | time_hi_and_version field to the appropriate 4-bit version number | |
752 | from Section 4.1.3. | |
753 | ||
754 | o Set the clock_seq_hi_and_reserved field to octet 8 of the hash. | |
755 | ||
756 | o Set the two most significant bits (bits 6 and 7) of the | |
757 | clock_seq_hi_and_reserved to zero and one, respectively. | |
758 | ||
759 | o Set the clock_seq_low field to octet 9 of the hash. | |
760 | ||
761 | o Set octets zero through five of the node field to octets 10 | |
762 | through 15 of the hash. | |
763 | ||
764 | o Convert the resulting UUID to local byte order. | |
765 | ||
766 | 4.4. Algorithms for Creating a UUID from Truly Random or | |
767 | Pseudo-Random Numbers | |
768 | ||
769 | The version 4 UUID is meant for generating UUIDs from truly-random or | |
770 | pseudo-random numbers. | |
771 | ||
772 | The algorithm is as follows: | |
773 | ||
774 | o Set the two most significant bits (bits 6 and 7) of the | |
775 | clock_seq_hi_and_reserved to zero and one, respectively. | |
776 | ||
777 | o Set the four most significant bits (bits 12 through 15) of the | |
778 | time_hi_and_version field to the 4-bit version number from | |
779 | Section 4.1.3. | |
780 | ||
781 | o Set all the other bits to randomly (or pseudo-randomly) chosen | |
782 | values. | |
783 | ||
784 | ||
785 | ||
786 | Leach, et al. Standards Track [Page 14] | |
787 | \f | |
788 | RFC 4122 A UUID URN Namespace July 2005 | |
789 | ||
790 | ||
791 | See Section 4.5 for a discussion on random numbers. | |
792 | ||
793 | 4.5. Node IDs that Do Not Identify the Host | |
794 | ||
795 | This section describes how to generate a version 1 UUID if an IEEE | |
796 | 802 address is not available, or its use is not desired. | |
797 | ||
798 | One approach is to contact the IEEE and get a separate block of | |
799 | addresses. At the time of writing, the application could be found at | |
800 | <http://standards.ieee.org/regauth/oui/pilot-ind.html>, and the cost | |
801 | was US$550. | |
802 | ||
803 | A better solution is to obtain a 47-bit cryptographic quality random | |
804 | number and use it as the low 47 bits of the node ID, with the least | |
805 | significant bit of the first octet of the node ID set to one. This | |
806 | bit is the unicast/multicast bit, which will never be set in IEEE 802 | |
807 | addresses obtained from network cards. Hence, there can never be a | |
808 | conflict between UUIDs generated by machines with and without network | |
809 | cards. (Recall that the IEEE 802 spec talks about transmission | |
810 | order, which is the opposite of the in-memory representation that is | |
811 | discussed in this document.) | |
812 | ||
813 | For compatibility with earlier specifications, note that this | |
814 | document uses the unicast/multicast bit, instead of the arguably more | |
815 | correct local/global bit. | |
816 | ||
817 | Advice on generating cryptographic-quality random numbers can be | |
818 | found in RFC1750 [5]. | |
819 | ||
820 | In addition, items such as the computer's name and the name of the | |
821 | operating system, while not strictly speaking random, will help | |
822 | differentiate the results from those obtained by other systems. | |
823 | ||
824 | The exact algorithm to generate a node ID using these data is system | |
825 | specific, because both the data available and the functions to obtain | |
826 | them are often very system specific. A generic approach, however, is | |
827 | to accumulate as many sources as possible into a buffer, use a | |
828 | message digest such as MD5 [4] or SHA-1 [8], take an arbitrary 6 | |
829 | bytes from the hash value, and set the multicast bit as described | |
830 | above. | |
831 | ||
832 | 5. Community Considerations | |
833 | ||
834 | The use of UUIDs is extremely pervasive in computing. They comprise | |
835 | the core identifier infrastructure for many operating systems | |
836 | (Microsoft Windows) and applications (the Mozilla browser) and in | |
837 | many cases, become exposed to the Web in many non-standard ways. | |
838 | ||
839 | ||
840 | ||
841 | ||
842 | Leach, et al. Standards Track [Page 15] | |
843 | \f | |
844 | RFC 4122 A UUID URN Namespace July 2005 | |
845 | ||
846 | ||
847 | This specification attempts to standardize that practice as openly as | |
848 | possible and in a way that attempts to benefit the entire Internet. | |
849 | ||
850 | 6. Security Considerations | |
851 | ||
852 | Do not assume that UUIDs are hard to guess; they should not be used | |
853 | as security capabilities (identifiers whose mere possession grants | |
854 | access), for example. A predictable random number source will | |
855 | exacerbate the situation. | |
856 | ||
857 | Do not assume that it is easy to determine if a UUID has been | |
858 | slightly transposed in order to redirect a reference to another | |
859 | object. Humans do not have the ability to easily check the integrity | |
860 | of a UUID by simply glancing at it. | |
861 | ||
862 | Distributed applications generating UUIDs at a variety of hosts must | |
863 | be willing to rely on the random number source at all hosts. If this | |
864 | is not feasible, the namespace variant should be used. | |
865 | ||
866 | 7. Acknowledgments | |
867 | ||
868 | This document draws heavily on the OSF DCE specification for UUIDs. | |
869 | Ted Ts'o provided helpful comments, especially on the byte ordering | |
870 | section which we mostly plagiarized from a proposed wording he | |
871 | supplied (all errors in that section are our responsibility, | |
872 | however). | |
873 | ||
874 | We are also grateful to the careful reading and bit-twiddling of Ralf | |
875 | S. Engelschall, John Larmouth, and Paul Thorpe. Professor Larmouth | |
876 | was also invaluable in achieving coordination with ISO/IEC. | |
877 | ||
878 | 8. Normative References | |
879 | ||
880 | [1] Zahn, L., Dineen, T., and P. Leach, "Network Computing | |
881 | Architecture", ISBN 0-13-611674-4, January 1990. | |
882 | ||
883 | [2] "DCE: Remote Procedure Call", Open Group CAE Specification C309, | |
884 | ISBN 1-85912-041-5, August 1994. | |
885 | ||
886 | [3] ISO/IEC 9834-8:2004 Information Technology, "Procedures for the | |
887 | operation of OSI Registration Authorities: Generation and | |
888 | registration of Universally Unique Identifiers (UUIDs) and their | |
889 | use as ASN.1 Object Identifier components" ITU-T Rec. X.667, | |
890 | 2004. | |
891 | ||
892 | [4] Rivest, R., "The MD5 Message-Digest Algorithm ", RFC 1321, April | |
893 | 1992. | |
894 | ||
895 | ||
896 | ||
897 | ||
898 | Leach, et al. Standards Track [Page 16] | |
899 | \f | |
900 | RFC 4122 A UUID URN Namespace July 2005 | |
901 | ||
902 | ||
903 | [5] Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness | |
904 | Requirements for Security", BCP 106, RFC 4086, June 2005. | |
905 | ||
906 | [6] Moats, R., "URN Syntax", RFC 2141, May 1997. | |
907 | ||
908 | [7] Crocker, D. and P. Overell, "Augmented BNF for Syntax | |
909 | Specifications: ABNF", RFC 2234, November 1997. | |
910 | ||
911 | [8] National Institute of Standards and Technology, "Secure Hash | |
912 | Standard", FIPS PUB 180-1, April 1995, | |
913 | <http://www.itl.nist.gov/fipspubs/fip180-1.htm>. | |
914 | ||
915 | ||
916 | ||
917 | ||
918 | ||
919 | ||
920 | ||
921 | ||
922 | ||
923 | ||
924 | ||
925 | ||
926 | ||
927 | ||
928 | ||
929 | ||
930 | ||
931 | ||
932 | ||
933 | ||
934 | ||
935 | ||
936 | ||
937 | ||
938 | ||
939 | ||
940 | ||
941 | ||
942 | ||
943 | ||
944 | ||
945 | ||
946 | ||
947 | ||
948 | ||
949 | ||
950 | ||
951 | ||
952 | ||
953 | ||
954 | Leach, et al. Standards Track [Page 17] | |
955 | \f | |
956 | RFC 4122 A UUID URN Namespace July 2005 | |
957 | ||
958 | ||
959 | Appendix A. Appendix A - Sample Implementation | |
960 | ||
961 | This implementation consists of 5 files: uuid.h, uuid.c, sysdep.h, | |
962 | sysdep.c and utest.c. The uuid.* files are the system independent | |
963 | implementation of the UUID generation algorithms described above, | |
964 | with all the optimizations described above except efficient state | |
965 | sharing across processes included. The code has been tested on Linux | |
966 | (Red Hat 4.0) with GCC (2.7.2), and Windows NT 4.0 with VC++ 5.0. | |
967 | The code assumes 64-bit integer support, which makes it much clearer. | |
968 | ||
969 | All the following source files should have the following copyright | |
970 | notice included: | |
971 | ||
972 | copyrt.h | |
973 | ||
974 | /* | |
975 | ** Copyright (c) 1990- 1993, 1996 Open Software Foundation, Inc. | |
976 | ** Copyright (c) 1989 by Hewlett-Packard Company, Palo Alto, Ca. & | |
977 | ** Digital Equipment Corporation, Maynard, Mass. | |
978 | ** Copyright (c) 1998 Microsoft. | |
979 | ** To anyone who acknowledges that this file is provided "AS IS" | |
980 | ** without any express or implied warranty: permission to use, copy, | |
981 | ** modify, and distribute this file for any purpose is hereby | |
982 | ** granted without fee, provided that the above copyright notices and | |
983 | ** this notice appears in all source code copies, and that none of | |
984 | ** the names of Open Software Foundation, Inc., Hewlett-Packard | |
985 | ** Company, Microsoft, or Digital Equipment Corporation be used in | |
986 | ** advertising or publicity pertaining to distribution of the software | |
987 | ** without specific, written prior permission. Neither Open Software | |
988 | ** Foundation, Inc., Hewlett-Packard Company, Microsoft, nor Digital | |
989 | ** Equipment Corporation makes any representations about the | |
990 | ** suitability of this software for any purpose. | |
991 | */ | |
992 | ||
993 | ||
994 | uuid.h | |
995 | ||
996 | #include "copyrt.h" | |
997 | #undef uuid_t | |
998 | typedef struct { | |
999 | unsigned32 time_low; | |
1000 | unsigned16 time_mid; | |
1001 | unsigned16 time_hi_and_version; | |
1002 | unsigned8 clock_seq_hi_and_reserved; | |
1003 | unsigned8 clock_seq_low; | |
1004 | byte node[6]; | |
1005 | } uuid_t; | |
1006 | ||
1007 | ||
1008 | ||
1009 | ||
1010 | Leach, et al. Standards Track [Page 18] | |
1011 | \f | |
1012 | RFC 4122 A UUID URN Namespace July 2005 | |
1013 | ||
1014 | ||
1015 | /* uuid_create -- generate a UUID */ | |
1016 | int uuid_create(uuid_t * uuid); | |
1017 | ||
1018 | /* uuid_create_md5_from_name -- create a version 3 (MD5) UUID using a | |
1019 | "name" from a "name space" */ | |
1020 | void uuid_create_md5_from_name( | |
1021 | uuid_t *uuid, /* resulting UUID */ | |
1022 | uuid_t nsid, /* UUID of the namespace */ | |
1023 | void *name, /* the name from which to generate a UUID */ | |
1024 | int namelen /* the length of the name */ | |
1025 | ); | |
1026 | ||
1027 | /* uuid_create_sha1_from_name -- create a version 5 (SHA-1) UUID | |
1028 | using a "name" from a "name space" */ | |
1029 | void uuid_create_sha1_from_name( | |
1030 | ||
1031 | uuid_t *uuid, /* resulting UUID */ | |
1032 | uuid_t nsid, /* UUID of the namespace */ | |
1033 | void *name, /* the name from which to generate a UUID */ | |
1034 | int namelen /* the length of the name */ | |
1035 | ); | |
1036 | ||
1037 | /* uuid_compare -- Compare two UUID's "lexically" and return | |
1038 | -1 u1 is lexically before u2 | |
1039 | 0 u1 is equal to u2 | |
1040 | 1 u1 is lexically after u2 | |
1041 | Note that lexical ordering is not temporal ordering! | |
1042 | */ | |
1043 | int uuid_compare(uuid_t *u1, uuid_t *u2); | |
1044 | ||
1045 | ||
1046 | uuid.c | |
1047 | ||
1048 | #include "copyrt.h" | |
1049 | #include <string.h> | |
1050 | #include <stdio.h> | |
1051 | #include <stdlib.h> | |
1052 | #include <time.h> | |
1053 | #include "sysdep.h" | |
1054 | #include "uuid.h" | |
1055 | ||
1056 | /* various forward declarations */ | |
1057 | static int read_state(unsigned16 *clockseq, uuid_time_t *timestamp, | |
1058 | uuid_node_t *node); | |
1059 | static void write_state(unsigned16 clockseq, uuid_time_t timestamp, | |
1060 | uuid_node_t node); | |
1061 | static void format_uuid_v1(uuid_t *uuid, unsigned16 clockseq, | |
1062 | uuid_time_t timestamp, uuid_node_t node); | |
1063 | ||
1064 | ||
1065 | ||
1066 | Leach, et al. Standards Track [Page 19] | |
1067 | \f | |
1068 | RFC 4122 A UUID URN Namespace July 2005 | |
1069 | ||
1070 | ||
1071 | static void format_uuid_v3or5(uuid_t *uuid, unsigned char hash[16], | |
1072 | int v); | |
1073 | static void get_current_time(uuid_time_t *timestamp); | |
1074 | static unsigned16 true_random(void); | |
1075 | ||
1076 | /* uuid_create -- generator a UUID */ | |
1077 | int uuid_create(uuid_t *uuid) | |
1078 | { | |
1079 | uuid_time_t timestamp, last_time; | |
1080 | unsigned16 clockseq; | |
1081 | uuid_node_t node; | |
1082 | uuid_node_t last_node; | |
1083 | int f; | |
1084 | ||
1085 | /* acquire system-wide lock so we're alone */ | |
1086 | LOCK; | |
1087 | /* get time, node ID, saved state from non-volatile storage */ | |
1088 | get_current_time(×tamp); | |
1089 | get_ieee_node_identifier(&node); | |
1090 | f = read_state(&clockseq, &last_time, &last_node); | |
1091 | ||
1092 | /* if no NV state, or if clock went backwards, or node ID | |
1093 | changed (e.g., new network card) change clockseq */ | |
1094 | if (!f || memcmp(&node, &last_node, sizeof node)) | |
1095 | clockseq = true_random(); | |
1096 | else if (timestamp < last_time) | |
1097 | clockseq++; | |
1098 | ||
1099 | /* save the state for next time */ | |
1100 | write_state(clockseq, timestamp, node); | |
1101 | ||
1102 | UNLOCK; | |
1103 | ||
1104 | /* stuff fields into the UUID */ | |
1105 | format_uuid_v1(uuid, clockseq, timestamp, node); | |
1106 | return 1; | |
1107 | } | |
1108 | ||
1109 | /* format_uuid_v1 -- make a UUID from the timestamp, clockseq, | |
1110 | and node ID */ | |
1111 | void format_uuid_v1(uuid_t* uuid, unsigned16 clock_seq, | |
1112 | uuid_time_t timestamp, uuid_node_t node) | |
1113 | { | |
1114 | /* Construct a version 1 uuid with the information we've gathered | |
1115 | plus a few constants. */ | |
1116 | uuid->time_low = (unsigned long)(timestamp & 0xFFFFFFFF); | |
1117 | uuid->time_mid = (unsigned short)((timestamp >> 32) & 0xFFFF); | |
1118 | uuid->time_hi_and_version = | |
1119 | ||
1120 | ||
1121 | ||
1122 | Leach, et al. Standards Track [Page 20] | |
1123 | \f | |
1124 | RFC 4122 A UUID URN Namespace July 2005 | |
1125 | ||
1126 | ||
1127 | (unsigned short)((timestamp >> 48) & 0x0FFF); | |
1128 | uuid->time_hi_and_version |= (1 << 12); | |
1129 | uuid->clock_seq_low = clock_seq & 0xFF; | |
1130 | uuid->clock_seq_hi_and_reserved = (clock_seq & 0x3F00) >> 8; | |
1131 | uuid->clock_seq_hi_and_reserved |= 0x80; | |
1132 | memcpy(&uuid->node, &node, sizeof uuid->node); | |
1133 | } | |
1134 | ||
1135 | /* data type for UUID generator persistent state */ | |
1136 | typedef struct { | |
1137 | uuid_time_t ts; /* saved timestamp */ | |
1138 | uuid_node_t node; /* saved node ID */ | |
1139 | unsigned16 cs; /* saved clock sequence */ | |
1140 | } uuid_state; | |
1141 | ||
1142 | static uuid_state st; | |
1143 | ||
1144 | /* read_state -- read UUID generator state from non-volatile store */ | |
1145 | int read_state(unsigned16 *clockseq, uuid_time_t *timestamp, | |
1146 | uuid_node_t *node) | |
1147 | { | |
1148 | static int inited = 0; | |
1149 | FILE *fp; | |
1150 | ||
1151 | /* only need to read state once per boot */ | |
1152 | if (!inited) { | |
1153 | fp = fopen("state", "rb"); | |
1154 | if (fp == NULL) | |
1155 | return 0; | |
1156 | fread(&st, sizeof st, 1, fp); | |
1157 | fclose(fp); | |
1158 | inited = 1; | |
1159 | } | |
1160 | *clockseq = st.cs; | |
1161 | *timestamp = st.ts; | |
1162 | *node = st.node; | |
1163 | return 1; | |
1164 | } | |
1165 | ||
1166 | /* write_state -- save UUID generator state back to non-volatile | |
1167 | storage */ | |
1168 | void write_state(unsigned16 clockseq, uuid_time_t timestamp, | |
1169 | uuid_node_t node) | |
1170 | { | |
1171 | static int inited = 0; | |
1172 | static uuid_time_t next_save; | |
1173 | FILE* fp; | |
1174 | ||
1175 | ||
1176 | ||
1177 | ||
1178 | Leach, et al. Standards Track [Page 21] | |
1179 | \f | |
1180 | RFC 4122 A UUID URN Namespace July 2005 | |
1181 | ||
1182 | ||
1183 | if (!inited) { | |
1184 | next_save = timestamp; | |
1185 | inited = 1; | |
1186 | } | |
1187 | ||
1188 | /* always save state to volatile shared state */ | |
1189 | st.cs = clockseq; | |
1190 | st.ts = timestamp; | |
1191 | st.node = node; | |
1192 | if (timestamp >= next_save) { | |
1193 | fp = fopen("state", "wb"); | |
1194 | fwrite(&st, sizeof st, 1, fp); | |
1195 | fclose(fp); | |
1196 | /* schedule next save for 10 seconds from now */ | |
1197 | next_save = timestamp + (10 * 10 * 1000 * 1000); | |
1198 | } | |
1199 | } | |
1200 | ||
1201 | /* get-current_time -- get time as 60-bit 100ns ticks since UUID epoch. | |
1202 | Compensate for the fact that real clock resolution is | |
1203 | less than 100ns. */ | |
1204 | void get_current_time(uuid_time_t *timestamp) | |
1205 | { | |
1206 | static int inited = 0; | |
1207 | static uuid_time_t time_last; | |
1208 | static unsigned16 uuids_this_tick; | |
1209 | uuid_time_t time_now; | |
1210 | ||
1211 | if (!inited) { | |
1212 | get_system_time(&time_now); | |
1213 | uuids_this_tick = UUIDS_PER_TICK; | |
1214 | inited = 1; | |
1215 | } | |
1216 | ||
1217 | for ( ; ; ) { | |
1218 | get_system_time(&time_now); | |
1219 | ||
1220 | /* if clock reading changed since last UUID generated, */ | |
1221 | if (time_last != time_now) { | |
1222 | /* reset count of uuids gen'd with this clock reading */ | |
1223 | uuids_this_tick = 0; | |
1224 | time_last = time_now; | |
1225 | break; | |
1226 | } | |
1227 | if (uuids_this_tick < UUIDS_PER_TICK) { | |
1228 | uuids_this_tick++; | |
1229 | break; | |
1230 | } | |
1231 | ||
1232 | ||
1233 | ||
1234 | Leach, et al. Standards Track [Page 22] | |
1235 | \f | |
1236 | RFC 4122 A UUID URN Namespace July 2005 | |
1237 | ||
1238 | ||
1239 | /* going too fast for our clock; spin */ | |
1240 | } | |
1241 | /* add the count of uuids to low order bits of the clock reading */ | |
1242 | *timestamp = time_now + uuids_this_tick; | |
1243 | } | |
1244 | ||
1245 | /* true_random -- generate a crypto-quality random number. | |
1246 | **This sample doesn't do that.** */ | |
1247 | static unsigned16 true_random(void) | |
1248 | { | |
1249 | static int inited = 0; | |
1250 | uuid_time_t time_now; | |
1251 | ||
1252 | if (!inited) { | |
1253 | get_system_time(&time_now); | |
1254 | time_now = time_now / UUIDS_PER_TICK; | |
1255 | srand((unsigned int) | |
1256 | (((time_now >> 32) ^ time_now) & 0xffffffff)); | |
1257 | inited = 1; | |
1258 | } | |
1259 | ||
1260 | return rand(); | |
1261 | } | |
1262 | ||
1263 | /* uuid_create_md5_from_name -- create a version 3 (MD5) UUID using a | |
1264 | "name" from a "name space" */ | |
1265 | void uuid_create_md5_from_name(uuid_t *uuid, uuid_t nsid, void *name, | |
1266 | int namelen) | |
1267 | { | |
1268 | MD5_CTX c; | |
1269 | unsigned char hash[16]; | |
1270 | uuid_t net_nsid; | |
1271 | ||
1272 | /* put name space ID in network byte order so it hashes the same | |
1273 | no matter what endian machine we're on */ | |
1274 | net_nsid = nsid; | |
1275 | net_nsid.time_low = htonl(net_nsid.time_low); | |
1276 | net_nsid.time_mid = htons(net_nsid.time_mid); | |
1277 | net_nsid.time_hi_and_version = htons(net_nsid.time_hi_and_version); | |
1278 | ||
1279 | MD5Init(&c); | |
1280 | MD5Update(&c, &net_nsid, sizeof net_nsid); | |
1281 | MD5Update(&c, name, namelen); | |
1282 | MD5Final(hash, &c); | |
1283 | ||
1284 | /* the hash is in network byte order at this point */ | |
1285 | format_uuid_v3or5(uuid, hash, 3); | |
1286 | } | |
1287 | ||
1288 | ||
1289 | ||
1290 | Leach, et al. Standards Track [Page 23] | |
1291 | \f | |
1292 | RFC 4122 A UUID URN Namespace July 2005 | |
1293 | ||
1294 | ||
1295 | void uuid_create_sha1_from_name(uuid_t *uuid, uuid_t nsid, void *name, | |
1296 | int namelen) | |
1297 | { | |
1298 | SHA_CTX c; | |
1299 | unsigned char hash[20]; | |
1300 | uuid_t net_nsid; | |
1301 | ||
1302 | /* put name space ID in network byte order so it hashes the same | |
1303 | no matter what endian machine we're on */ | |
1304 | net_nsid = nsid; | |
1305 | net_nsid.time_low = htonl(net_nsid.time_low); | |
1306 | net_nsid.time_mid = htons(net_nsid.time_mid); | |
1307 | net_nsid.time_hi_and_version = htons(net_nsid.time_hi_and_version); | |
1308 | ||
1309 | SHA1_Init(&c); | |
1310 | SHA1_Update(&c, &net_nsid, sizeof net_nsid); | |
1311 | SHA1_Update(&c, name, namelen); | |
1312 | SHA1_Final(hash, &c); | |
1313 | ||
1314 | /* the hash is in network byte order at this point */ | |
1315 | format_uuid_v3or5(uuid, hash, 5); | |
1316 | } | |
1317 | ||
1318 | /* format_uuid_v3or5 -- make a UUID from a (pseudo)random 128-bit | |
1319 | number */ | |
1320 | void format_uuid_v3or5(uuid_t *uuid, unsigned char hash[16], int v) | |
1321 | { | |
1322 | /* convert UUID to local byte order */ | |
1323 | memcpy(uuid, hash, sizeof *uuid); | |
1324 | uuid->time_low = ntohl(uuid->time_low); | |
1325 | uuid->time_mid = ntohs(uuid->time_mid); | |
1326 | uuid->time_hi_and_version = ntohs(uuid->time_hi_and_version); | |
1327 | ||
1328 | /* put in the variant and version bits */ | |
1329 | uuid->time_hi_and_version &= 0x0FFF; | |
1330 | uuid->time_hi_and_version |= (v << 12); | |
1331 | uuid->clock_seq_hi_and_reserved &= 0x3F; | |
1332 | uuid->clock_seq_hi_and_reserved |= 0x80; | |
1333 | } | |
1334 | ||
1335 | /* uuid_compare -- Compare two UUID's "lexically" and return */ | |
1336 | #define CHECK(f1, f2) if (f1 != f2) return f1 < f2 ? -1 : 1; | |
1337 | int uuid_compare(uuid_t *u1, uuid_t *u2) | |
1338 | { | |
1339 | int i; | |
1340 | ||
1341 | CHECK(u1->time_low, u2->time_low); | |
1342 | CHECK(u1->time_mid, u2->time_mid); | |
1343 | ||
1344 | ||
1345 | ||
1346 | Leach, et al. Standards Track [Page 24] | |
1347 | \f | |
1348 | RFC 4122 A UUID URN Namespace July 2005 | |
1349 | ||
1350 | ||
1351 | CHECK(u1->time_hi_and_version, u2->time_hi_and_version); | |
1352 | CHECK(u1->clock_seq_hi_and_reserved, u2->clock_seq_hi_and_reserved); | |
1353 | CHECK(u1->clock_seq_low, u2->clock_seq_low) | |
1354 | for (i = 0; i < 6; i++) { | |
1355 | if (u1->node[i] < u2->node[i]) | |
1356 | return -1; | |
1357 | if (u1->node[i] > u2->node[i]) | |
1358 | return 1; | |
1359 | } | |
1360 | return 0; | |
1361 | } | |
1362 | #undef CHECK | |
1363 | ||
1364 | ||
1365 | sysdep.h | |
1366 | ||
1367 | #include "copyrt.h" | |
1368 | /* remove the following define if you aren't running WIN32 */ | |
1369 | #define WININC 0 | |
1370 | ||
1371 | #ifdef WININC | |
1372 | #include <windows.h> | |
1373 | #else | |
1374 | #include <sys/types.h> | |
1375 | #include <sys/time.h> | |
1376 | #include <sys/sysinfo.h> | |
1377 | #endif | |
1378 | ||
1379 | #include "global.h" | |
1380 | /* change to point to where MD5 .h's live; RFC 1321 has sample | |
1381 | implementation */ | |
1382 | #include "md5.h" | |
1383 | ||
1384 | /* set the following to the number of 100ns ticks of the actual | |
1385 | resolution of your system's clock */ | |
1386 | #define UUIDS_PER_TICK 1024 | |
1387 | ||
1388 | /* Set the following to a calls to get and release a global lock */ | |
1389 | #define LOCK | |
1390 | #define UNLOCK | |
1391 | ||
1392 | typedef unsigned long unsigned32; | |
1393 | typedef unsigned short unsigned16; | |
1394 | typedef unsigned char unsigned8; | |
1395 | typedef unsigned char byte; | |
1396 | ||
1397 | /* Set this to what your compiler uses for 64-bit data type */ | |
1398 | #ifdef WININC | |
1399 | ||
1400 | ||
1401 | ||
1402 | Leach, et al. Standards Track [Page 25] | |
1403 | \f | |
1404 | RFC 4122 A UUID URN Namespace July 2005 | |
1405 | ||
1406 | ||
1407 | #define unsigned64_t unsigned __int64 | |
1408 | #define I64(C) C | |
1409 | #else | |
1410 | #define unsigned64_t unsigned long long | |
1411 | #define I64(C) C##LL | |
1412 | #endif | |
1413 | ||
1414 | typedef unsigned64_t uuid_time_t; | |
1415 | typedef struct { | |
1416 | char nodeID[6]; | |
1417 | } uuid_node_t; | |
1418 | ||
1419 | void get_ieee_node_identifier(uuid_node_t *node); | |
1420 | void get_system_time(uuid_time_t *uuid_time); | |
1421 | void get_random_info(char seed[16]); | |
1422 | ||
1423 | ||
1424 | sysdep.c | |
1425 | ||
1426 | #include "copyrt.h" | |
1427 | #include <stdio.h> | |
1428 | #include "sysdep.h" | |
1429 | ||
1430 | /* system dependent call to get IEEE node ID. | |
1431 | This sample implementation generates a random node ID. */ | |
1432 | void get_ieee_node_identifier(uuid_node_t *node) | |
1433 | { | |
1434 | static inited = 0; | |
1435 | static uuid_node_t saved_node; | |
1436 | char seed[16]; | |
1437 | FILE *fp; | |
1438 | ||
1439 | if (!inited) { | |
1440 | fp = fopen("nodeid", "rb"); | |
1441 | if (fp) { | |
1442 | fread(&saved_node, sizeof saved_node, 1, fp); | |
1443 | fclose(fp); | |
1444 | } | |
1445 | else { | |
1446 | get_random_info(seed); | |
1447 | seed[0] |= 0x01; | |
1448 | memcpy(&saved_node, seed, sizeof saved_node); | |
1449 | fp = fopen("nodeid", "wb"); | |
1450 | if (fp) { | |
1451 | fwrite(&saved_node, sizeof saved_node, 1, fp); | |
1452 | fclose(fp); | |
1453 | } | |
1454 | } | |
1455 | ||
1456 | ||
1457 | ||
1458 | Leach, et al. Standards Track [Page 26] | |
1459 | \f | |
1460 | RFC 4122 A UUID URN Namespace July 2005 | |
1461 | ||
1462 | ||
1463 | inited = 1; | |
1464 | } | |
1465 | ||
1466 | *node = saved_node; | |
1467 | } | |
1468 | ||
1469 | /* system dependent call to get the current system time. Returned as | |
1470 | 100ns ticks since UUID epoch, but resolution may be less than | |
1471 | 100ns. */ | |
1472 | #ifdef _WINDOWS_ | |
1473 | ||
1474 | void get_system_time(uuid_time_t *uuid_time) | |
1475 | { | |
1476 | ULARGE_INTEGER time; | |
1477 | ||
1478 | /* NT keeps time in FILETIME format which is 100ns ticks since | |
1479 | Jan 1, 1601. UUIDs use time in 100ns ticks since Oct 15, 1582. | |
1480 | The difference is 17 Days in Oct + 30 (Nov) + 31 (Dec) | |
1481 | + 18 years and 5 leap days. */ | |
1482 | GetSystemTimeAsFileTime((FILETIME *)&time); | |
1483 | time.QuadPart += | |
1484 | ||
1485 | (unsigned __int64) (1000*1000*10) // seconds | |
1486 | * (unsigned __int64) (60 * 60 * 24) // days | |
1487 | * (unsigned __int64) (17+30+31+365*18+5); // # of days | |
1488 | *uuid_time = time.QuadPart; | |
1489 | } | |
1490 | ||
1491 | /* Sample code, not for use in production; see RFC 1750 */ | |
1492 | void get_random_info(char seed[16]) | |
1493 | { | |
1494 | MD5_CTX c; | |
1495 | struct { | |
1496 | MEMORYSTATUS m; | |
1497 | SYSTEM_INFO s; | |
1498 | FILETIME t; | |
1499 | LARGE_INTEGER pc; | |
1500 | DWORD tc; | |
1501 | DWORD l; | |
1502 | char hostname[MAX_COMPUTERNAME_LENGTH + 1]; | |
1503 | } r; | |
1504 | ||
1505 | MD5Init(&c); | |
1506 | GlobalMemoryStatus(&r.m); | |
1507 | GetSystemInfo(&r.s); | |
1508 | GetSystemTimeAsFileTime(&r.t); | |
1509 | QueryPerformanceCounter(&r.pc); | |
1510 | r.tc = GetTickCount(); | |
1511 | ||
1512 | ||
1513 | ||
1514 | Leach, et al. Standards Track [Page 27] | |
1515 | \f | |
1516 | RFC 4122 A UUID URN Namespace July 2005 | |
1517 | ||
1518 | ||
1519 | r.l = MAX_COMPUTERNAME_LENGTH + 1; | |
1520 | GetComputerName(r.hostname, &r.l); | |
1521 | MD5Update(&c, &r, sizeof r); | |
1522 | MD5Final(seed, &c); | |
1523 | } | |
1524 | ||
1525 | #else | |
1526 | ||
1527 | void get_system_time(uuid_time_t *uuid_time) | |
1528 | { | |
1529 | struct timeval tp; | |
1530 | ||
1531 | gettimeofday(&tp, (struct timezone *)0); | |
1532 | ||
1533 | /* Offset between UUID formatted times and Unix formatted times. | |
1534 | UUID UTC base time is October 15, 1582. | |
1535 | Unix base time is January 1, 1970.*/ | |
1536 | *uuid_time = ((unsigned64)tp.tv_sec * 10000000) | |
1537 | + ((unsigned64)tp.tv_usec * 10) | |
1538 | + I64(0x01B21DD213814000); | |
1539 | } | |
1540 | ||
1541 | /* Sample code, not for use in production; see RFC 1750 */ | |
1542 | void get_random_info(char seed[16]) | |
1543 | { | |
1544 | MD5_CTX c; | |
1545 | struct { | |
1546 | struct sysinfo s; | |
1547 | struct timeval t; | |
1548 | char hostname[257]; | |
1549 | } r; | |
1550 | ||
1551 | MD5Init(&c); | |
1552 | sysinfo(&r.s); | |
1553 | gettimeofday(&r.t, (struct timezone *)0); | |
1554 | gethostname(r.hostname, 256); | |
1555 | MD5Update(&c, &r, sizeof r); | |
1556 | MD5Final(seed, &c); | |
1557 | } | |
1558 | ||
1559 | #endif | |
1560 | ||
1561 | utest.c | |
1562 | ||
1563 | #include "copyrt.h" | |
1564 | #include "sysdep.h" | |
1565 | #include <stdio.h> | |
1566 | #include "uuid.h" | |
1567 | ||
1568 | ||
1569 | ||
1570 | Leach, et al. Standards Track [Page 28] | |
1571 | \f | |
1572 | RFC 4122 A UUID URN Namespace July 2005 | |
1573 | ||
1574 | ||
1575 | uuid_t NameSpace_DNS = { /* 6ba7b810-9dad-11d1-80b4-00c04fd430c8 */ | |
1576 | 0x6ba7b810, | |
1577 | 0x9dad, | |
1578 | 0x11d1, | |
1579 | 0x80, 0xb4, 0x00, 0xc0, 0x4f, 0xd4, 0x30, 0xc8 | |
1580 | }; | |
1581 | ||
1582 | /* puid -- print a UUID */ | |
1583 | void puid(uuid_t u) | |
1584 | { | |
1585 | int i; | |
1586 | ||
1587 | printf("%8.8x-%4.4x-%4.4x-%2.2x%2.2x-", u.time_low, u.time_mid, | |
1588 | u.time_hi_and_version, u.clock_seq_hi_and_reserved, | |
1589 | u.clock_seq_low); | |
1590 | for (i = 0; i < 6; i++) | |
1591 | printf("%2.2x", u.node[i]); | |
1592 | printf("\n"); | |
1593 | } | |
1594 | ||
1595 | /* Simple driver for UUID generator */ | |
1596 | void main(int argc, char **argv) | |
1597 | { | |
1598 | uuid_t u; | |
1599 | int f; | |
1600 | ||
1601 | uuid_create(&u); | |
1602 | printf("uuid_create(): "); puid(u); | |
1603 | ||
1604 | f = uuid_compare(&u, &u); | |
1605 | printf("uuid_compare(u,u): %d\n", f); /* should be 0 */ | |
1606 | f = uuid_compare(&u, &NameSpace_DNS); | |
1607 | printf("uuid_compare(u, NameSpace_DNS): %d\n", f); /* s.b. 1 */ | |
1608 | f = uuid_compare(&NameSpace_DNS, &u); | |
1609 | printf("uuid_compare(NameSpace_DNS, u): %d\n", f); /* s.b. -1 */ | |
1610 | uuid_create_md5_from_name(&u, NameSpace_DNS, "www.widgets.com", 15); | |
1611 | printf("uuid_create_md5_from_name(): "); puid(u); | |
1612 | } | |
1613 | ||
1614 | Appendix B. Appendix B - Sample Output of utest | |
1615 | ||
1616 | uuid_create(): 7d444840-9dc0-11d1-b245-5ffdce74fad2 | |
1617 | uuid_compare(u,u): 0 | |
1618 | uuid_compare(u, NameSpace_DNS): 1 | |
1619 | uuid_compare(NameSpace_DNS, u): -1 | |
1620 | uuid_create_md5_from_name(): e902893a-9d22-3c7e-a7b8-d6e313b71d9f | |
1621 | ||
1622 | ||
1623 | ||
1624 | ||
1625 | ||
1626 | Leach, et al. Standards Track [Page 29] | |
1627 | \f | |
1628 | RFC 4122 A UUID URN Namespace July 2005 | |
1629 | ||
1630 | ||
1631 | Appendix C. Appendix C - Some Name Space IDs | |
1632 | ||
1633 | This appendix lists the name space IDs for some potentially | |
1634 | interesting name spaces, as initialized C structures and in the | |
1635 | string representation defined above. | |
1636 | ||
1637 | /* Name string is a fully-qualified domain name */ | |
1638 | uuid_t NameSpace_DNS = { /* 6ba7b810-9dad-11d1-80b4-00c04fd430c8 */ | |
1639 | 0x6ba7b810, | |
1640 | 0x9dad, | |
1641 | 0x11d1, | |
1642 | 0x80, 0xb4, 0x00, 0xc0, 0x4f, 0xd4, 0x30, 0xc8 | |
1643 | }; | |
1644 | ||
1645 | /* Name string is a URL */ | |
1646 | uuid_t NameSpace_URL = { /* 6ba7b811-9dad-11d1-80b4-00c04fd430c8 */ | |
1647 | 0x6ba7b811, | |
1648 | 0x9dad, | |
1649 | 0x11d1, | |
1650 | 0x80, 0xb4, 0x00, 0xc0, 0x4f, 0xd4, 0x30, 0xc8 | |
1651 | }; | |
1652 | ||
1653 | /* Name string is an ISO OID */ | |
1654 | uuid_t NameSpace_OID = { /* 6ba7b812-9dad-11d1-80b4-00c04fd430c8 */ | |
1655 | 0x6ba7b812, | |
1656 | 0x9dad, | |
1657 | 0x11d1, | |
1658 | 0x80, 0xb4, 0x00, 0xc0, 0x4f, 0xd4, 0x30, 0xc8 | |
1659 | }; | |
1660 | ||
1661 | /* Name string is an X.500 DN (in DER or a text output format) */ | |
1662 | uuid_t NameSpace_X500 = { /* 6ba7b814-9dad-11d1-80b4-00c04fd430c8 */ | |
1663 | 0x6ba7b814, | |
1664 | 0x9dad, | |
1665 | 0x11d1, | |
1666 | 0x80, 0xb4, 0x00, 0xc0, 0x4f, 0xd4, 0x30, 0xc8 | |
1667 | }; | |
1668 | ||
1669 | ||
1670 | ||
1671 | ||
1672 | ||
1673 | ||
1674 | ||
1675 | ||
1676 | ||
1677 | ||
1678 | ||
1679 | ||
1680 | ||
1681 | ||
1682 | Leach, et al. Standards Track [Page 30] | |
1683 | \f | |
1684 | RFC 4122 A UUID URN Namespace July 2005 | |
1685 | ||
1686 | ||
1687 | Authors' Addresses | |
1688 | ||
1689 | Paul J. Leach | |
1690 | Microsoft | |
1691 | 1 Microsoft Way | |
1692 | Redmond, WA 98052 | |
1693 | US | |
1694 | ||
1695 | Phone: +1 425-882-8080 | |
1696 | EMail: paulle@microsoft.com | |
1697 | ||
1698 | ||
1699 | Michael Mealling | |
1700 | Refactored Networks, LLC | |
1701 | 1635 Old Hwy 41 | |
1702 | Suite 112, Box 138 | |
1703 | Kennesaw, GA 30152 | |
1704 | US | |
1705 | ||
1706 | Phone: +1-678-581-9656 | |
1707 | EMail: michael@refactored-networks.com | |
1708 | URI: http://www.refactored-networks.com | |
1709 | ||
1710 | ||
1711 | Rich Salz | |
1712 | DataPower Technology, Inc. | |
1713 | 1 Alewife Center | |
1714 | Cambridge, MA 02142 | |
1715 | US | |
1716 | ||
1717 | Phone: +1 617-864-0455 | |
1718 | EMail: rsalz@datapower.com | |
1719 | URI: http://www.datapower.com | |
1720 | ||
1721 | ||
1722 | ||
1723 | ||
1724 | ||
1725 | ||
1726 | ||
1727 | ||
1728 | ||
1729 | ||
1730 | ||
1731 | ||
1732 | ||
1733 | ||
1734 | ||
1735 | ||
1736 | ||
1737 | ||
1738 | Leach, et al. Standards Track [Page 31] | |
1739 | \f | |
1740 | RFC 4122 A UUID URN Namespace July 2005 | |
1741 | ||
1742 | ||
1743 | Full Copyright Statement | |
1744 | ||
1745 | Copyright (C) The Internet Society (2005). | |
1746 | ||
1747 | This document is subject to the rights, licenses and restrictions | |
1748 | contained in BCP 78, and except as set forth therein, the authors | |
1749 | retain all their rights. | |
1750 | ||
1751 | This document and the information contained herein are provided on an | |
1752 | "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS | |
1753 | OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET | |
1754 | ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, | |
1755 | INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE | |
1756 | INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED | |
1757 | WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | |
1758 | ||
1759 | Intellectual Property | |
1760 | ||
1761 | The IETF takes no position regarding the validity or scope of any | |
1762 | Intellectual Property Rights or other rights that might be claimed to | |
1763 | pertain to the implementation or use of the technology described in | |
1764 | this document or the extent to which any license under such rights | |
1765 | might or might not be available; nor does it represent that it has | |
1766 | made any independent effort to identify any such rights. Information | |
1767 | on the procedures with respect to rights in RFC documents can be | |
1768 | found in BCP 78 and BCP 79. | |
1769 | ||
1770 | Copies of IPR disclosures made to the IETF Secretariat and any | |
1771 | assurances of licenses to be made available, or the result of an | |
1772 | attempt made to obtain a general license or permission for the use of | |
1773 | such proprietary rights by implementers or users of this | |
1774 | specification can be obtained from the IETF on-line IPR repository at | |
1775 | http://www.ietf.org/ipr. | |
1776 | ||
1777 | The IETF invites any interested party to bring to its attention any | |
1778 | copyrights, patents or patent applications, or other proprietary | |
1779 | rights that may cover technology that may be required to implement | |
1780 | this standard. Please address the information to the IETF at ietf- | |
1781 | ipr@ietf.org. | |
1782 | ||
1783 | Acknowledgement | |
1784 | ||
1785 | Funding for the RFC Editor function is currently provided by the | |
1786 | Internet Society. | |
1787 | ||
1788 | ||
1789 | ||
1790 | ||
1791 | ||
1792 | ||
1793 | ||
1794 | Leach, et al. Standards Track [Page 32] | |
1795 | \f |