硬盘分区的UUID
原文：https://blog.csdn.net/smstong/article/details/46417213
Universally Unique IDentifier, 是一种获取全局唯一命名的标准。
1 UUID的来历
要为一个对象进行命名，并要求这个名字在时间和空间上都是唯一的，这在计算机领域是一个很重要的问题。目前已经存在很多成熟的解决方案，例如IP地址，MAC地址，DNS域名等。但这些方案都存在一个问题，那就是需要一个中央管理机构来批准和统一管理。这样就会带来两个问题：（1）需要一定费用；（2）数量受限。
为了解决这个问题，UUID诞生了。它采用128位长度来表示一个名字，且同时考虑了时间和空间的唯一性，最重要的是它不需要申请注册，任何人都可以使用本地计算机运行程序自动生成。
UUID最早出现在Apollo Network Computing System，后来被用到了OSF的DCE环境，然后被微软拿去使用，并改名GUID。相信大家都记得微软注册表里的奇怪长串数字吧，还有COM组件的名字，都是GUID。
2 硬盘分区命名现状
2.1 卷标名存在的问题
大多数文件系统的元数据部分都会记录硬盘分区的名字。对于如何命名这个分区，也有很多方法，如采用卷标。
这里写图片描述
上面的“系统”，“软件”，“文档”就是分区的卷标名。几乎所有的文件系统类型都对卷标名进行支持。然而卷标名长度有限，并且重复的可能性比较大。可能很多人都给自己的系统分区命名为“系统”。
名字重复会导致一些问题，例如把当把一个硬盘HD1，转移到另外一台带有硬盘HD2的机器上时，如果HD1和HD2存在卷标名相同的分区，那么就会给依赖于卷标名的程序带来问题。
2.2 Linux对分区命名的问题
Linux系统对识别出的硬盘分区采用类似 /dev/sda1，/dev/sdb1这样的格式进行动态命名。假设机器装有两块串口硬盘，Linux会按照识别顺序对第一个识别出的硬盘命名为/dev/sda，对第二块识别出的硬盘命名为/dev/sdb。而问题是识别顺序是随机的，所以启动机器之前不能确定/dev/sda到底是哪块硬盘。
最常见的使用这种名称的地方就是/etc/fstab文件，它被用来设置自动挂载硬盘分区。下面是一个真实系统中的fstab文件中的一行：
/dev/sda1 /store ext4 defaults 0 0
如果系统有多块硬盘，那么下次启动的时候，/store就不能确定到底挂载了哪个硬盘的第一分区，如果这个挂载点对系统运行非常重要，那么就有可能出现问题。
2.3 GRUB对分区命名的问题
GRUB对分区命名与Linux类似，hd0表示发现的第一块硬盘，hd1表示第二块。存在的问题也与Linux相同。
2.4 UUID在文件系统中的使用
为解决上述问题，UUID被文件系统设计者采用，使其可以持久唯一标识一个硬盘分区。其实方式很简单，就是在文件系统的超级块中使用128位存放UUID。这个UUID是在使用文件系统格式化分区时计算生成的，例如Linux下的文件系统工具mkfs就在格式化分区的同时，生成UUID并把它记录到超级块的固定区域中。
下面是ext2文件系统超级块结构：
struct ext2_super_block{ __u32 s_inodes_count; /* 文件系统中索引节点总数 */__u32 s_blocks_count; /*文件系统中总块数 */__u32 s_r_blocks_count; /* 为超级用户保留的块数 */__u32 s_free_blocks_count; /*文件系统中空闲块总数 */__u32 s_free_inodes_count; /*文件系统中空闲索引节点总数*/__u32 s_first_data_block; /* 文件系统中第一个数据块 */__u32 s_log_block_size; /* 用于计算逻辑块大小 */__s32 s_log_frag_size; /* 用于计算片大小 */__u32 s_blocks_per_group; /* 每组中块数 */__u32 s_frags_per_group; /* 每组中片数 */__u32 s_inodes_per_group; /* 每组中索引节点数 */__u32 s_mtime; /*最后一次安装操作的时间 */__u32 s_wtime; /*最后一次对该超级块进行写操作的时间 */__u16 s_mnt_count; /* 安装计数 */__s16 s_max_mnt_count; /* 最大可安装计数 */__u16 s_magic; /* 用于确定文件系统版本的标志 */__u16 s_state; /* 文件系统的状态*/__u16 s_errors; /* 当检测到有错误时如何处理 */__u16 s_minor_rev_level; /* 次版本号 */__u32 s_lastcheck; /* 最后一次检测文件系统状态的时间 */__u32 s_checkinterval; /* 两次对文件系统状态进行检测的间隔时间 */__u32 s_rev_level; /* 版本号 */__u16 s_def_resuid; /* 保留块的默认用户标识号 */__u16 s_def_resgid; /* 保留块的默认用户组标识号*/ /** These fields are for EXT2_DYNAMIC_REV superblocks only.** Note: the difference between the compatible feature set and* the incompatible feature set is that if there is a bit set* in the incompatible feature set that the kernel doesn't* know about, it should refuse to mount the filesystem.** e2fsck's requirements are more strict; if it doesn't know* about a feature in either the compatible or incompatible* feature set, it must abort and not try to meddle with* things it doesn't understand...*/
__u32 s_first_ino; /* 第一个非保留的索引节点 */
__u16 s_inode_size; /* 索引节点的大小 */__u16 s_block_group_nr; /* 该超级块的块组号 */__u32 s_feature_compat; /* 兼容特点的位图*/__u32 s_feature_incompat; /* 非兼容特点的位图 */__u32 s_feature_ro_compat; /* 只读兼容特点的位图*/__u8 s_uuid[16]; /* 128位的文件系统标识号*/char s_volume_name[16]; /* 卷名 */char s_last_mounted[64]; /* 最后一个安装点的路径名 */__u32 s_algorithm_usage_bitmap; /* 用于压缩*//** Performance hints. Directory preallocation should only* happen if the EXT2_COMPAT_PREALLOC flag is on.*/__u8 s_prealloc_blocks; /* 预分配的块数*/__u8 s_prealloc_dir_blocks; /* 给目录预分配的块数 */__u16 s_padding1; __u32 s_reserved[204]; /* 用null填充块的末尾 */};
可以看到s_uuid[16]就是存放分区UUID的地方。
这样，无论硬盘分区的标识就永远不会重复，而且只要分区没有被重新格式化，那么标识此分区的UUID永远不变。
当然并不是所有的文件系统类型都支持UUID，例如微软的NTFS就不支持，而是采用了一个类似的其他机制。微软永远不走正路，真拿他没办法。
3 GRUB, Linux对硬盘分区UUID的支持
3.1 实例
目前最新版本的GRUB和Linux系统都对硬盘分区的UUID机制提供了良好的支持。
下面是CentOS6系统中/boot/grub/grub.conf配置文件的一部分：
title CentOS (2.6.32-504.el6.x86_64)root (hd0,0)kernel /boot/vmlinuz-2.6.32-504.el6.x86_64 ro root=UUID=ec2c1241-2c17-46ea-8cc6-a6a850df3e94 rd_NO_LUKS rd_NO_LVM LANG=en_US.UTF-8 rd_NO_MD SYSFONT=latarcyrheb-sun16 crashkernel=auto KEYBOARDTYPE=pc KEYTABLE=us rd_NO_DM rhgb quietinitrd /boot/initramfs-2.6.32-504.el6.x86_64.img
可以看出，GRUB本身仍采用(hd0,0)的传统方式寻找分区，而为其启动的linux提供了UUID的方式。
下面是CentOS7系统中/boot/grub2/grub.cfg配置文件一部分：
menuentry 'CentOS Linux, with Linux 3.10.0-123.el7.x86_64' --class centos --class gnu-linux --class gnu --class os --unrestricted $menuentry_id_option 'gnulinux-3.10.0-123.el7.x86_64-advanced-b1e99de2-d388-4882-9b3a-5ced68992ee0' {load_videoset gfxpayload=keepinsmod gzioinsmod part_msdosinsmod xfsset root='hd0,msdos1'if [ x$feature_platform_search_hint = xy ]; thensearch --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 --hint='hd0,msdos1' 49224d20-43a6-44f2-8cf5-cfa11758a3a7elsesearch --no-floppy --fs-uuid --set=root 49224d20-43a6-44f2-8cf5-cfa11758a3a7filinux16 /vmlinuz-3.10.0-123.el7.x86_64 root=UUID=b1e99de2-d388-4882-9b3a-5ced68992ee0 ro rd.lvm.lv=centos/swap vconsole.font=latarcyrheb-sun16 rd.lvm.lv=centos/root crashkernel=auto vconsole.keymap=us rhgb quiet LANG=en_US.UTF-8initrd16 /initramfs-3.10.0-123.el7.x86_64.img
可见，GRUB和LINUX均采用了UUID来寻找硬盘分区。
下面是fstab的一部分：
UUID=49224d20-43a6-44f2-8cf5-cfa11758a3a7 /boot xfs defaults 1 2
显然也是采用了UUID来定位硬盘分区。
3.2 注意事项
- 重新格式化分区时，分区的UUID会变更
所以格式化分区后，需要修改对应的配置文件，更新其UUID。
- NTFS文件系统不支持UUID
虽然NTFS不支持UUID，但是其支持一种较短的ID，也可以拿来凑合用。
既然UUID有这么多优势，毫无疑问只要系统支持，就要充分使用它。
4 UUID工具程序
- 如何查看硬盘分区的UUID
分区的UUID是mkfs工具自动写入的，我们可以使用blkid来查看之。
[root@db001 ~]# blkid
/dev/sda1: UUID="33141ba9-acd3-4021-9de3-bf7460f7c77c" TYPE="ext3"
/dev/sdc1: UUID="ec2c1241-2c17-46ea-8cc6-a6a850df3e94" TYPE="ext4"
/dev/sdc2: UUID="a1dc0e52-777e-450a-8fac-62d7966ff619" TYPE="swap"
- 生成UUID和分析UUID
为方便大家学习和理解UUID，uuid这个工具提供了很好的实践。它不仅可以用来生成UUID，而且可以对已有的UUID进行分析。
[root@db001 ~]# uuid
3f3418ce-0e79-11e5-b477-00e081de9b4a
[root@db001 ~]# blkid
/dev/sda1: UUID="33141ba9-acd3-4021-9de3-bf7460f7c77c" TYPE="ext3"
/dev/sdc1: UUID="ec2c1241-2c17-46ea-8cc6-a6a850df3e94" TYPE="ext4"
/dev/sdc2: UUID="a1dc0e52-777e-450a-8fac-62d7966ff619" TYPE="swap"
[root@db001 ~]# uuid -d 33141ba9-acd3-4021-9de3-bf7460f7c77c
encode: STR: 33141ba9-acd3-4021-9de3-bf7460f7c77cSIV: 67895034790306977465223914142060496764
decode: variant: DCE 1.1, ISO/IEC 11578:1996version: 4 (random data based)content: 33:14:1B:A9:AC:D3:00:21:1D:E3:BF:74:60:F7:C7:7C(no semantics: random data only)
附录 UUID指导文档 RFC4122
[Docs] [txt|pdf] [draft-mealling-uu...] [Diff1] [Diff2] [Errata] PROPOSED STANDARDErrata Exist
Network Working Group P. Leach
Request for Comments: 4122 Microsoft
Category: Standards Track M. MeallingRefactored Networks, LLCR. SalzDataPower Technology, Inc.July 2005A Universally Unique IDentifier (UUID) URN NamespaceStatus of This MemoThis document specifies an Internet standards track protocol for theInternet community, and requests discussion and suggestions forimprovements. Please refer to the current edition of the "InternetOfficial Protocol Standards" (STD 1) for the standardization stateand status of this protocol. Distribution of this memo is unlimited.Copyright NoticeCopyright (C) The Internet Society (2005).AbstractThis specification defines a Uniform Resource Name namespace forUUIDs (Universally Unique IDentifier), also known as GUIDs (GloballyUnique IDentifier). A UUID is 128 bits long, and can guaranteeuniqueness across space and time. UUIDs were originally used in theApollo Network Computing System and later in the Open SoftwareFoundation's (OSF) Distributed Computing Environment (DCE), and thenin Microsoft Windows platforms.This specification is derived from the DCE specification with thekind permission of the OSF (now known as The Open Group).Information from earlier versions of the DCE specification have beenincorporated into this document.Leach, et al. Standards Track [Page 1]RFC 4122 A UUID URN Namespace July 2005Table of Contents1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 22. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 33. Namespace Registration Template . . . . . . . . . . . . . . . 34. Specification . . . . . . . . . . . . . . . . . . . . . . . . 54.1. Format. . . . . . . . . . . . . . . . . . . . . . . . . . 54.1.1. Variant. . . . . . . . . . . . . . . . . . . . . . 64.1.2. Layout and Byte Order. . . . . . . . . . . . . . . 64.1.3. Version. . . . . . . . . . . . . . . . . . . . . . 74.1.4. Timestamp. . . . . . . . . . . . . . . . . . . . . 84.1.5. Clock Sequence . . . . . . . . . . . . . . . . . . 84.1.6. Node . . . . . . . . . . . . . . . . . . . . . . . 94.1.7. Nil UUID . . . . . . . . . . . . . . . . . . . . . 94.2. Algorithms for Creating a Time-Based UUID . . . . . . . . 94.2.1. Basic Algorithm. . . . . . . . . . . . . . . . . . 104.2.2. Generation Details . . . . . . . . . . . . . . . . 124.3. Algorithm for Creating a Name-Based UUID. . . . . . . . . 134.4. Algorithms for Creating a UUID from Truly Random orPseudo-Random Numbers . . . . . . . . . . . . . . . . . . 144.5. Node IDs that Do Not Identify the Host. . . . . . . . . . 155. Community Considerations . . . . . . . . . . . . . . . . . . . 156. Security Considerations . . . . . . . . . . . . . . . . . . . 167. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 168. Normative References . . . . . . . . . . . . . . . . . . . . . 16A. Appendix A - Sample Implementation . . . . . . . . . . . . . . 18B. Appendix B - Sample Output of utest . . . . . . . . . . . . . 29C. Appendix C - Some Name Space IDs . . . . . . . . . . . . . . . 301. IntroductionThis specification defines a Uniform Resource Name namespace forUUIDs (Universally Unique IDentifier), also known as GUIDs (GloballyUnique IDentifier). A UUID is 128 bits long, and requires no centralregistration process.The information here is meant to be a concise guide for those wishingto implement services using UUIDs as URNs. Nothing in this documentshould be construed to override the DCE standards that defined UUIDs.There is an ITU-T Recommendation and ISO/IEC Standard [3] that arederived from earlier versions of this document. Both sets ofspecifications have been aligned, and are fully technicallycompatible. In addition, a global registration function is beingprovided by the Telecommunications Standardisation Bureau of ITU-T;for details see <http://www.itu.int/ITU-T/asn1/uuid.html>.Leach, et al. Standards Track [Page 2]RFC 4122 A UUID URN Namespace July 20052. MotivationOne of the main reasons for using UUIDs is that no centralizedauthority is required to administer them (although one format usesIEEE 802 node identifiers, others do not). As a result, generationon demand can be completely automated, and used for a variety ofpurposes. The UUID generation algorithm described here supports veryhigh allocation rates of up to 10 million per second per machine ifnecessary, so that they could even be used as transaction IDs.UUIDs are of a fixed size (128 bits) which is reasonably smallcompared to other alternatives. This lends itself well to sorting,ordering, and hashing of all sorts, storing in databases, simpleallocation, and ease of programming in general.Since UUIDs are unique and persistent, they make excellent UniformResource Names. The unique ability to generate a new UUID without aregistration process allows for UUIDs to be one of the URNs with thelowest minting cost.3. Namespace Registration TemplateNamespace ID: UUIDRegistration Information:Registration date: 2003-10-01Declared registrant of the namespace:JTC 1/SC6 (ASN.1 Rapporteur Group)Declaration of syntactic structure:A UUID is an identifier that is unique across both space and time,with respect to the space of all UUIDs. Since a UUID is a fixedsize and contains a time field, it is possible for values torollover (around A.D. 3400, depending on the specific algorithmused). A UUID can be used for multiple purposes, from taggingobjects with an extremely short lifetime, to reliably identifyingvery persistent objects across a network.The internal representation of a UUID is a specific sequence ofbits in memory, as described in Section 4. To accuratelyrepresent a UUID as a URN, it is necessary to convert the bitsequence to a string representation.Each field is treated as an integer and has its value printed as azero-filled hexadecimal digit string with the most significantdigit first. The hexadecimal values "a" through "f" are output aslower case characters and are case insensitive on input.Leach, et al. Standards Track [Page 3]RFC 4122 A UUID URN Namespace July 2005The formal definition of the UUID string representation isprovided by the following ABNF [7]:UUID = time-low "-" time-mid "-"time-high-and-version "-"clock-seq-and-reservedclock-seq-low "-" nodetime-low = 4hexOctettime-mid = 2hexOctettime-high-and-version = 2hexOctetclock-seq-and-reserved = hexOctetclock-seq-low = hexOctetnode = 6hexOctethexOctet = hexDigit hexDigithexDigit ="0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9" /"a" / "b" / "c" / "d" / "e" / "f" /"A" / "B" / "C" / "D" / "E" / "F"The following is an example of the string representation of a UUID asa URN:urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6Relevant ancillary documentation:[1][2]Identifier uniqueness considerations:This document specifies three algorithms to generate UUIDs: thefirst leverages the unique values of 802 MAC addresses toguarantee uniqueness, the second uses pseudo-random numbergenerators, and the third uses cryptographic hashing andapplication-provided text strings. As a result, the UUIDsgenerated according to the mechanisms here will be unique from allother UUIDs that have been or will be assigned.Identifier persistence considerations:UUIDs are inherently very difficult to resolve in a global sense.This, coupled with the fact that UUIDs are temporally uniquewithin their spatial context, ensures that UUIDs will remain aspersistent as possible.Process of identifier assignment:Generating a UUID does not require that a registration authoritybe contacted. One algorithm requires a unique value over spacefor each generator. This value is typically an IEEE 802 MACaddress, usually already available on network-connected hosts.The address can be assigned from an address block obtained fromthe IEEE registration authority. If no such address is available,Leach, et al. Standards Track [Page 4]RFC 4122 A UUID URN Namespace July 2005or privacy concerns make its use undesirable, Section 4.5specifies two alternatives. Another approach is to use version 3or version 4 UUIDs as defined below.Process for identifier resolution:Since UUIDs are not globally resolvable, this is not applicable.Rules for Lexical Equivalence:Consider each field of the UUID to be an unsigned integer as shownin the table in section Section 4.1.2. Then, to compare a pair ofUUIDs, arithmetically compare the corresponding fields from eachUUID in order of significance and according to their data type.Two UUIDs are equal if and only if all the corresponding fieldsare equal.As an implementation note, equality comparison can be performed onmany systems by doing the appropriate byte-order canonicalization,and then treating the two UUIDs as 128-bit unsigned integers.UUIDs, as defined in this document, can also be orderedlexicographically. For a pair of UUIDs, the first one follows thesecond if the most significant field in which the UUIDs differ isgreater for the first UUID. The second precedes the first if themost significant field in which the UUIDs differ is greater forthe second UUID.Conformance with URN Syntax:The string representation of a UUID is fully compatible with theURN syntax. When converting from a bit-oriented, in-memoryrepresentation of a UUID into a URN, care must be taken tostrictly adhere to the byte order issues mentioned in the stringrepresentation section.Validation mechanism:Apart from determining whether the timestamp portion of the UUIDis in the future and therefore not yet assignable, there is nomechanism for determining whether a UUID is 'valid'.Scope:UUIDs are global in scope.4. Specification4.1. FormatThe UUID format is 16 octets; some bits of the eight octet variantfield specified below determine finer structure.Leach, et al. Standards Track [Page 5]RFC 4122 A UUID URN Namespace July 20054.1.1. VariantThe variant field determines the layout of the UUID. That is, theinterpretation of all other bits in the UUID depends on the settingof the bits in the variant field. As such, it could more accuratelybe called a type field; we retain the original term forcompatibility. The variant field consists of a variable number ofthe most significant bits of octet 8 of the UUID.The following table lists the contents of the variant field, wherethe letter "x" indicates a "don't-care" value.Msb0 Msb1 Msb2 Description0 x x Reserved, NCS backward compatibility.1 0 x The variant specified in this document.1 1 0 Reserved, Microsoft Corporation backwardcompatibility1 1 1 Reserved for future definition.Interoperability, in any form, with variants other than the onedefined here is not guaranteed, and is not likely to be an issue inpractice.4.1.2. Layout and Byte OrderTo minimize confusion about bit assignments within octets, the UUIDrecord definition is defined only in terms of fields that areintegral numbers of octets. The fields are presented with the mostsignificant one first.Field Data Type Octet Note#time_low unsigned 32 0-3 The low field of thebit integer timestamptime_mid unsigned 16 4-5 The middle field of thebit integer timestamptime_hi_and_version unsigned 16 6-7 The high field of thebit integer timestamp multiplexedwith the version numberLeach, et al. Standards Track [Page 6]RFC 4122 A UUID URN Namespace July 2005clock_seq_hi_and_rese unsigned 8 8 The high field of therved bit integer clock sequencemultiplexed with thevariantclock_seq_low unsigned 8 9 The low field of thebit integer clock sequencenode unsigned 48 10-15 The spatially uniquebit integer node identifierIn the absence of explicit application or presentation protocolspecification to the contrary, a UUID is encoded as a 128-bit object,as follows:The fields are encoded as 16 octets, with the sizes and order of thefields defined above, and with each field encoded with the MostSignificant Byte first (known as network byte order). Note that thefield names, particularly for multiplexed fields, follow historicalpractice.0 1 2 30 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. VersionThe version number is in the most significant 4 bits of the timestamp (bits 4 through 7 of the time_hi_and_version field).The following table lists the currently-defined versions for thisUUID variant.Msb0 Msb1 Msb2 Msb3 Version Description0 0 0 1 1 The time-based versionspecified in this document.0 0 1 0 2 DCE Security version, withembedded POSIX UIDs.Leach, et al. Standards Track [Page 7]RFC 4122 A UUID URN Namespace July 20050 0 1 1 3 The name-based versionspecified in this documentthat uses MD5 hashing.0 1 0 0 4 The randomly or pseudo-randomly generated versionspecified in this document.0 1 0 1 5 The name-based versionspecified in this documentthat uses SHA-1 hashing.The version is more accurately a sub-type; again, we retain the termfor compatibility.4.1.4. TimestampThe timestamp is a 60-bit value. For UUID version 1, this isrepresented by Coordinated Universal Time (UTC) as a count of 100-nanosecond intervals since 00:00:00.00, 15 October 1582 (the date ofGregorian reform to the Christian calendar).For systems that do not have UTC available, but do have the localtime, they may use that instead of UTC, as long as they do soconsistently throughout the system. However, this is not recommendedsince generating the UTC from local time only needs a time zoneoffset.For UUID version 3 or 5, the timestamp is a 60-bit value constructedfrom a name as described in Section 4.3.For UUID version 4, the timestamp is a randomly or pseudo-randomlygenerated 60-bit value, as described in Section 4.4.4.1.5. Clock SequenceFor UUID version 1, the clock sequence is used to help avoidduplicates that could arise when the clock is set backwards in timeor if the node ID changes.If the clock is set backwards, or might have been set backwards(e.g., while the system was powered off), and the UUID generator cannot be sure that no UUIDs were generated with timestamps larger thanthe value to which the clock was set, then the clock sequence has tobe changed. If the previous value of the clock sequence is known, itcan just be incremented; otherwise it should be set to a random orhigh-quality pseudo-random value.Leach, et al. Standards Track [Page 8]RFC 4122 A UUID URN Namespace July 2005Similarly, if the node ID changes (e.g., because a network card hasbeen moved between machines), setting the clock sequence to a randomnumber minimizes the probability of a duplicate due to slightdifferences in the clock settings of the machines. If the value ofclock sequence associated with the changed node ID were known, thenthe clock sequence could just be incremented, but that is unlikely.The clock sequence MUST be originally (i.e., once in the lifetime ofa system) initialized to a random number to minimize the correlationacross systems. This provides maximum protection against nodeidentifiers that may move or switch from system to system rapidly.The initial value MUST NOT be correlated to the node identifier.For UUID version 3 or 5, the clock sequence is a 14-bit valueconstructed from a name as described in Section 4.3.For UUID version 4, clock sequence is a randomly or pseudo-randomlygenerated 14-bit value as described in Section 4.4.4.1.6. NodeFor UUID version 1, the node field consists of an IEEE 802 MACaddress, usually the host address. For systems with multiple IEEE802 addresses, any available one can be used. The lowest addressedoctet (octet number 10) contains the global/local bit and theunicast/multicast bit, and is the first octet of the addresstransmitted on an 802.3 LAN.For systems with no IEEE address, a randomly or pseudo-randomlygenerated value may be used; see Section 4.5. The multicast bit mustbe set in such addresses, in order that they will never conflict withaddresses obtained from network cards.For UUID version 3 or 5, the node field is a 48-bit value constructedfrom a name as described in Section 4.3.For UUID version 4, the node field is a randomly or pseudo-randomlygenerated 48-bit value as described in Section 4.4.4.1.7. Nil UUIDThe nil UUID is special form of UUID that is specified to have all128 bits set to zero.4.2. Algorithms for Creating a Time-Based UUIDVarious aspects of the algorithm for creating a version 1 UUID arediscussed in the following sections.Leach, et al. Standards Track [Page 9]RFC 4122 A UUID URN Namespace July 20054.2.1. Basic AlgorithmThe following algorithm is simple, correct, and inefficient:o Obtain a system-wide global locko From a system-wide shared stable store (e.g., a file), read theUUID generator state: the values of the timestamp, clock sequence,and node ID used to generate the last UUID.o Get the current time as a 60-bit count of 100-nanosecond intervalssince 00:00:00.00, 15 October 1582.o Get the current node ID.o If the state was unavailable (e.g., non-existent or corrupted), orthe saved node ID is different than the current node ID, generatea random clock sequence value.o If the state was available, but the saved timestamp is later thanthe current timestamp, increment the clock sequence value.o Save the state (current timestamp, clock sequence, and node ID)back to the stable store.o Release the global lock.o Format a UUID from the current timestamp, clock sequence, and nodeID values according to the steps in Section 4.2.2.If UUIDs do not need to be frequently generated, the above algorithmmay be perfectly adequate. For higher performance requirements,however, issues with the basic algorithm include:o Reading the state from stable storage each time is inefficient.o The resolution of the system clock may not be 100-nanoseconds.o Writing the state to stable storage each time is inefficient.o Sharing the state across process boundaries may be inefficient.Each of these issues can be addressed in a modular fashion by localimprovements in the functions that read and write the state and readthe clock. We address each of them in turn in the followingsections.Leach, et al. Standards Track [Page 10]RFC 4122 A UUID URN Namespace July 20054.2.1.1. Reading Stable StorageThe state only needs to be read from stable storage once at boottime, if it is read into a system-wide shared volatile store (andupdated whenever the stable store is updated).If an implementation does not have any stable store available, thenit can always say that the values were unavailable. This is theleast desirable implementation because it will increase the frequencyof creation of new clock sequence numbers, which increases theprobability of duplicates.If the node ID can never change (e.g., the net card is inseparablefrom the system), or if any change also reinitializes the clocksequence to a random value, then instead of keeping it in stablestore, the current node ID may be returned.4.2.1.2. System Clock ResolutionThe timestamp is generated from the system time, whose resolution maybe less than the resolution of the UUID timestamp.If UUIDs do not need to be frequently generated, the timestamp cansimply be the system time multiplied by the number of 100-nanosecondintervals per system time interval.If a system overruns the generator by requesting too many UUIDswithin a single system time interval, the UUID service MUST eitherreturn an error, or stall the UUID generator until the system clockcatches up.A high resolution timestamp can be simulated by keeping a count ofthe number of UUIDs that have been generated with the same value ofthe system time, and using it to construct the low order bits of thetimestamp. The count will range between zero and the number of100-nanosecond intervals per system time interval.Note: If the processors overrun the UUID generation frequently,additional node identifiers can be allocated to the system, whichwill permit higher speed allocation by making multiple UUIDspotentially available for each time stamp value.4.2.1.3. Writing Stable StorageThe state does not always need to be written to stable store everytime a UUID is generated. The timestamp in the stable store can beperiodically set to a value larger than any yet used in a UUID. Aslong as the generated UUIDs have timestamps less than that value, andLeach, et al. Standards Track [Page 11]RFC 4122 A UUID URN Namespace July 2005the clock sequence and node ID remain unchanged, only the sharedvolatile copy of the state needs to be updated. Furthermore, if thetimestamp value in stable store is in the future by less than thetypical time it takes the system to reboot, a crash will not cause areinitialization of the clock sequence.4.2.1.4. Sharing State Across ProcessesIf it is too expensive to access shared state each time a UUID isgenerated, then the system-wide generator can be implemented toallocate a block of time stamps each time it is called; a per-process generator can allocate from that block until it is exhausted.4.2.2. Generation DetailsVersion 1 UUIDs are generated according to the following algorithm:o Determine the values for the UTC-based timestamp and clocksequence to be used in the UUID, as described in Section 4.2.1.o For the purposes of this algorithm, consider the timestamp to be a60-bit unsigned integer and the clock sequence to be a 14-bitunsigned integer. Sequentially number the bits in a field,starting with zero for the least significant bit.o Set the time_low field equal to the least significant 32 bits(bits zero through 31) of the timestamp in the same order ofsignificance.o Set the time_mid field equal to bits 32 through 47 from thetimestamp in the same order of significance.o Set the 12 least significant bits (bits zero through 11) of thetime_hi_and_version field equal to bits 48 through 59 from thetimestamp in the same order of significance.o Set the four most significant bits (bits 12 through 15) of thetime_hi_and_version field to the 4-bit version numbercorresponding to the UUID version being created, as shown in thetable above.o Set the clock_seq_low field to the eight least significant bits(bits zero through 7) of the clock sequence in the same order ofsignificance.Leach, et al. Standards Track [Page 12]RFC 4122 A UUID URN Namespace July 2005o Set the 6 least significant bits (bits zero through 5) of theclock_seq_hi_and_reserved field to the 6 most significant bits(bits 8 through 13) of the clock sequence in the same order ofsignificance.o Set the two most significant bits (bits 6 and 7) of theclock_seq_hi_and_reserved to zero and one, respectively.o Set the node field to the 48-bit IEEE address in the same order ofsignificance as the address.4.3. Algorithm for Creating a Name-Based UUIDThe version 3 or 5 UUID is meant for generating UUIDs from "names"that are drawn from, and unique within, some "name space". Theconcept of name and name space should be broadly construed, and notlimited to textual names. For example, some name spaces are thedomain name system, URLs, ISO Object IDs (OIDs), X.500 DistinguishedNames (DNs), and reserved words in a programming language. Themechanisms or conventions used for allocating names and ensuringtheir uniqueness within their name spaces are beyond the scope ofthis specification.The requirements for these types of UUIDs are as follows:o The UUIDs generated at different times from the same name in thesame namespace MUST be equal.o The UUIDs generated from two different names in the same namespaceshould be different (with very high probability).o The UUIDs generated from the same name in two different namespacesshould be different with (very high probability).o If two UUIDs that were generated from names are equal, then theywere generated from the same name in the same namespace (with veryhigh probability).The algorithm for generating a UUID from a name and a name space areas follows:o Allocate a UUID to use as a "name space ID" for all UUIDsgenerated from names in that name space; see Appendix C for somepre-defined values.o Choose either MD5 [4] or SHA-1 [8] as the hash algorithm; Ifbackward compatibility is not an issue, SHA-1 is preferred.Leach, et al. Standards Track [Page 13]RFC 4122 A UUID URN Namespace July 2005o Convert the name to a canonical sequence of octets (as defined bythe standards or conventions of its name space); put the namespace ID in network byte order.o Compute the hash of the name space ID concatenated with the name.o Set octets zero through 3 of the time_low field to octets zerothrough 3 of the hash.o Set octets zero and one of the time_mid field to octets 4 and 5 ofthe hash.o Set octets zero and one of the time_hi_and_version field to octets6 and 7 of the hash.o Set the four most significant bits (bits 12 through 15) of thetime_hi_and_version field to the appropriate 4-bit version numberfrom Section 4.1.3.o Set the clock_seq_hi_and_reserved field to octet 8 of the hash.o Set the two most significant bits (bits 6 and 7) of theclock_seq_hi_and_reserved to zero and one, respectively.o Set the clock_seq_low field to octet 9 of the hash.o Set octets zero through five of the node field to octets 10through 15 of the hash.o Convert the resulting UUID to local byte order.4.4. Algorithms for Creating a UUID from Truly Random orPseudo-Random NumbersThe version 4 UUID is meant for generating UUIDs from truly-random orpseudo-random numbers.The algorithm is as follows:o Set the two most significant bits (bits 6 and 7) of theclock_seq_hi_and_reserved to zero and one, respectively.o Set the four most significant bits (bits 12 through 15) of thetime_hi_and_version field to the 4-bit version number fromSection 4.1.3.o Set all the other bits to randomly (or pseudo-randomly) chosenvalues.Leach, et al. Standards Track [Page 14]RFC 4122 A UUID URN Namespace July 2005See Section 4.5 for a discussion on random numbers.4.5. Node IDs that Do Not Identify the HostThis section describes how to generate a version 1 UUID if an IEEE802 address is not available, or its use is not desired.One approach is to contact the IEEE and get a separate block ofaddresses. At the time of writing, the application could be found at<http://standards.ieee.org/regauth/oui/pilot-ind.html>, and the costwas US$550.A better solution is to obtain a 47-bit cryptographic quality randomnumber and use it as the low 47 bits of the node ID, with the leastsignificant bit of the first octet of the node ID set to one. Thisbit is the unicast/multicast bit, which will never be set in IEEE 802addresses obtained from network cards. Hence, there can never be aconflict between UUIDs generated by machines with and without networkcards. (Recall that the IEEE 802 spec talks about transmissionorder, which is the opposite of the in-memory representation that isdiscussed in this document.)For compatibility with earlier specifications, note that thisdocument uses the unicast/multicast bit, instead of the arguably morecorrect local/global bit.Advice on generating cryptographic-quality random numbers can befound in RFC1750 [5].In addition, items such as the computer's name and the name of theoperating system, while not strictly speaking random, will helpdifferentiate the results from those obtained by other systems.The exact algorithm to generate a node ID using these data is systemspecific, because both the data available and the functions to obtainthem are often very system specific. A generic approach, however, isto accumulate as many sources as possible into a buffer, use amessage digest such as MD5 [4] or SHA-1 [8], take an arbitrary 6bytes from the hash value, and set the multicast bit as describedabove.5. Community ConsiderationsThe use of UUIDs is extremely pervasive in computing. They comprisethe core identifier infrastructure for many operating systems(Microsoft Windows) and applications (the Mozilla browser) and inmany cases, become exposed to the Web in many non-standard ways.Leach, et al. Standards Track [Page 15]RFC 4122 A UUID URN Namespace July 2005This specification attempts to standardize that practice as openly aspossible and in a way that attempts to benefit the entire Internet.6. Security ConsiderationsDo not assume that UUIDs are hard to guess; they should not be usedas security capabilities (identifiers whose mere possession grantsaccess), for example. A predictable random number source willexacerbate the situation.Do not assume that it is easy to determine if a UUID has beenslightly transposed in order to redirect a reference to anotherobject. Humans do not have the ability to easily check the integrityof a UUID by simply glancing at it.Distributed applications generating UUIDs at a variety of hosts mustbe willing to rely on the random number source at all hosts. If thisis not feasible, the namespace variant should be used.7. AcknowledgmentsThis document draws heavily on the OSF DCE specification for UUIDs.Ted Ts'o provided helpful comments, especially on the byte orderingsection which we mostly plagiarized from a proposed wording hesupplied (all errors in that section are our responsibility,however).We are also grateful to the careful reading and bit-twiddling of RalfS. Engelschall, John Larmouth, and Paul Thorpe. Professor Larmouthwas also invaluable in achieving coordination with ISO/IEC.8. Normative References[1] Zahn, L., Dineen, T., and P. Leach, "Network ComputingArchitecture", 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 theoperation of OSI Registration Authorities: Generation andregistration of Universally Unique Identifiers (UUIDs) and theiruse as ASN.1 Object Identifier components" ITU-T Rec. X.667,2004.[4] Rivest, R., "The MD5 Message-Digest Algorithm ", RFC 1321, April1992.Leach, et al. Standards Track [Page 16]RFC 4122 A UUID URN Namespace July 2005[5] Eastlake, D., 3rd, Schiller, J., and S. Crocker, "RandomnessRequirements 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 SyntaxSpecifications: ABNF", RFC 2234, November 1997.[8] National Institute of Standards and Technology, "Secure HashStandard", FIPS PUB 180-1, April 1995,<http://www.itl.nist.gov/fipspubs/fip180-1.htm>.Leach, et al. Standards Track [Page 17]RFC 4122 A UUID URN Namespace July 2005Appendix A. Appendix A - Sample ImplementationThis implementation consists of 5 files: uuid.h, uuid.c, sysdep.h,sysdep.c and utest.c. The uuid.* files are the system independentimplementation of the UUID generation algorithms described above,with all the optimizations described above except efficient statesharing 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 copyrightnotice 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_t
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;Leach, et al. Standards Track [Page 18]RFC 4122 A UUID URN Namespace July 2005/* 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) UUIDusing 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 u20 u1 is equal to u21 u1 is lexically after u2Note that lexical ordering is not temporal ordering!
*/
int uuid_compare(uuid_t *u1, uuid_t *u2);uuid.c#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);Leach, et al. Standards Track [Page 19]RFC 4122 A UUID URN Namespace July 2005static 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 IDchanged (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 gatheredplus a few constants. */uuid->time_low = (unsigned long)(timestamp & 0xFFFFFFFF);uuid->time_mid = (unsigned short)((timestamp >> 32) & 0xFFFF);uuid->time_hi_and_version =Leach, et al. Standards Track [Page 20]RFC 4122 A UUID URN Namespace July 2005(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-volatilestorage */
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;Leach, et al. Standards Track [Page 21]RFC 4122 A UUID URN Namespace July 2005if (!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 isless 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;}Leach, et al. Standards Track [Page 22]RFC 4122 A UUID URN Namespace July 2005/* 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 sameno 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);
}Leach, et al. Standards Track [Page 23]RFC 4122 A UUID URN Namespace July 2005void 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 sameno 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-bitnumber */
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);Leach, et al. Standards Track [Page 24]RFC 4122 A UUID URN Namespace July 2005CHECK(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#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 sampleimplementation */
#include "md5.h"/* set the following to the number of 100ns ticks of the actualresolution 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 UNLOCKtypedef 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 WININCLeach, et al. Standards Track [Page 25]RFC 4122 A UUID URN Namespace July 2005#define unsigned64_t unsigned __int64
#define I64(C) C
#else
#define unsigned64_t unsigned long long
#define I64(C) C##LL
#endiftypedef 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#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);}}Leach, et al. Standards Track [Page 26]RFC 4122 A UUID URN Namespace July 2005inited = 1;}*node = saved_node;
}/* system dependent call to get the current system time. Returned as100ns ticks since UUID epoch, but resolution may be less than100ns. */
#ifdef _WINDOWS_void get_system_time(uuid_time_t *uuid_time)
{ULARGE_INTEGER time;/* NT keeps time in FILETIME format which is 100ns ticks sinceJan 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;
}/* 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();Leach, et al. Standards Track [Page 27]RFC 4122 A UUID URN Namespace July 2005r.l = MAX_COMPUTERNAME_LENGTH + 1;GetComputerName(r.hostname, &r.l);MD5Update(&c, &r, sizeof r);MD5Final(seed, &c);
}#elsevoid 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);
}#endifutest.c#include "copyrt.h"
#include "sysdep.h"
#include <stdio.h>
#include "uuid.h"Leach, et al. Standards Track [Page 28]RFC 4122 A UUID URN Namespace July 2005uuid_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. Appendix B - Sample Output of utestuuid_create(): 7d444840-9dc0-11d1-b245-5ffdce74fad2uuid_compare(u,u): 0uuid_compare(u, NameSpace_DNS): 1uuid_compare(NameSpace_DNS, u): -1uuid_create_md5_from_name(): e902893a-9d22-3c7e-a7b8-d6e313b71d9fLeach, et al. Standards Track [Page 29]RFC 4122 A UUID URN Namespace July 2005Appendix C. Appendix C - Some Name Space IDsThis appendix lists the name space IDs for some potentiallyinteresting name spaces, as initialized C structures and in thestring representation defined above./* 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};Leach, et al. Standards Track [Page 30]RFC 4122 A UUID URN Namespace July 2005Authors' AddressesPaul J. LeachMicrosoft1 Microsoft WayRedmond, WA 98052USPhone: +1 425-882-8080EMail: paulle@microsoft.comMichael MeallingRefactored Networks, LLC1635 Old Hwy 41Suite 112, Box 138Kennesaw, GA 30152USPhone: +1-678-581-9656EMail: michael@refactored-networks.comURI: http://www.refactored-networks.comRich SalzDataPower Technology, Inc.1 Alewife CenterCambridge, MA 02142USPhone: +1 617-864-0455EMail: rsalz@datapower.comURI: http://www.datapower.comLeach, et al. Standards Track [Page 31]RFC 4122 A UUID URN Namespace July 2005Full Copyright StatementCopyright (C) The Internet Society (2005).This document is subject to the rights, licenses and restrictionscontained in BCP 78, and except as set forth therein, the authorsretain all their rights.This document and the information contained herein are provided on an"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTSOR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNETENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THEINFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIEDWARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.Intellectual PropertyThe IETF takes no position regarding the validity or scope of anyIntellectual Property Rights or other rights that might be claimed topertain to the implementation or use of the technology described inthis document or the extent to which any license under such rightsmight or might not be available; nor does it represent that it hasmade any independent effort to identify any such rights. Informationon the procedures with respect to rights in RFC documents can befound in BCP 78 and BCP 79.Copies of IPR disclosures made to the IETF Secretariat and anyassurances of licenses to be made available, or the result of anattempt made to obtain a general license or permission for the use ofsuch proprietary rights by implementers or users of thisspecification can be obtained from the IETF on-line IPR repository athttp://www.ietf.org/ipr.The IETF invites any interested party to bring to its attention anycopyrights, patents or patent applications, or other proprietaryrights that may cover technology that may be required to implementthis standard. Please address the information to the IETF at ietf-ipr@ietf.org.AcknowledgementFunding for the RFC Editor function is currently provided by theInternet Society.Leach, et al. Standards Track [Page 32]Html markup produced by rfcmarkup 1.114, available from https://tools.ietf.org/tools/rfcmarkup/