Para ambas variantes 1 y 2, se definen cinco «versiones» en los estándares, y cada versión puede ser más apropiada que las demás en casos de uso específicos. La versión se indica con el M en la representación de cadena.

Los UUID de la versión 1 se generan a partir de un ID de hora y de nodo (normalmente la dirección MAC); los UUID de la versión 2 se generan a partir de un identificador (normalmente un ID de grupo o de usuario), una hora y un ID de nodo; las versiones 3 y 5 producen UUID deterministas generados mediante el hashing de un identificador de espacio de nombres; y los UUID de la versión 4 se generan utilizando un número aleatorio o pseudoaleatorio.

Nil UUIDEdit

El UUID «nil», un caso especial, es el UUID 00000000-0000-0000-0000-000000000000; es decir, todos los bits puestos a cero.

Versión 1 (fecha-hora y dirección MAC)Editar

La versión 1 concatena la dirección MAC de 48 bits del «nodo» (es decir, la computadora que genera el UUID), con una marca de tiempo de 60 bits, siendo el número de intervalos de 100 nanosegundos desde la medianoche del 15 de octubre de 1582, Hora Universal Coordinada (UTC), la fecha en la que se adoptó por primera vez el calendario Gregoriano. RFC 4122 establece que el valor de tiempo se extiende alrededor de 3400 AD,: 3 dependiendo del algoritmo utilizado, lo que implica que la marca de tiempo de 60 bits es una cantidad con signo. Sin embargo, algunos programas, como la biblioteca libuuid, tratan la marca de tiempo como sin firmar, poniendo el tiempo de reinicio en 5236 AD. El tiempo de vuelco definido en la Rec ITU-T. X. 667 es 3603 DC.: v

Una secuencia de reloj «uniquificadora» de 13 o 14 bits extiende la marca de tiempo para manejar casos en los que el reloj del procesador no avanza lo suficientemente rápido, o donde hay varios procesadores y generadores de UUID por nodo. Cuando los UUID se generan más rápido de lo que el reloj del sistema podría avanzar, los bits más bajos de los campos de marca de tiempo se pueden generar aumentando cada vez que se genera un UUID, para simular una marca de tiempo de alta resolución. Con cada UUID versión 1 correspondiente a un único punto en el espacio (el nodo) y el tiempo (intervalos y secuencia de reloj), la posibilidad de que dos UUID versión-1 generados correctamente sean involuntariamente los mismos es prácticamente nula. Dado que la secuencia de tiempo y reloj totaliza 74 bits, 274 (1.8×1022, o 18 sextillones) los UUID de la versión 1 se pueden generar por ID de nodo, a una tasa media máxima de 163 mil millones por segundo por ID de nodo.

A diferencia de otras versiones de UUID, las versiones-1 y -2 de UUID basadas en direcciones MAC de tarjetas de red dependen, por su singularidad, en parte de un identificador emitido por una autoridad de registro central, a saber, el Identificador Único Organizacional (OUI), parte de la dirección MAC, que es emitido por el IEEE a los fabricantes de equipos de red. La singularidad de los UUID versión 1 y versión 2 basados en direcciones MAC de tarjetas de red también depende de que los fabricantes de tarjetas de red asignen correctamente direcciones MAC únicas a sus tarjetas, lo que, al igual que otros procesos de fabricación, está sujeto a errores.

El uso de la dirección MAC de la tarjeta de red del nodo para el ID de nodo significa que se puede rastrear un UUID versión 1 hasta el equipo que lo creó. Los documentos a veces se pueden rastrear hasta las computadoras donde se crearon o editaron a través de UUID incrustados en ellos por un software de procesamiento de textos. Este agujero de privacidad se usó para localizar al creador del virus Melissa.

RFC 4122 permite que la dirección MAC de un UUID de versión 1 (o 2) sea reemplazada por un ID de nodo aleatorio de 48 bits, ya sea porque el nodo no tiene una dirección MAC o porque no es deseable exponerla. En ese caso, el RFC requiere que el bit menos significativo del primer octeto del ID de nodo se establezca en 1. Esto corresponde al bit de multidifusión en direcciones MAC, y configurarlo sirve para diferenciar UUID donde el ID de nodo se genera aleatoriamente a partir de UUID basados en direcciones MAC de tarjetas de red, que normalmente tienen direcciones MAC de unidifusión.

Versión 2 (fecha, hora y dirección MAC, versión de seguridad de DCE)Editar

RFC 4122 reserva la versión 2 para UUID de «seguridad de DCE»; pero no proporciona ningún detalle. Por esta razón, muchas implementaciones de UUID omiten la versión 2. Sin embargo, la especificación de los UUID de la versión 2 es proporcionada por la especificación de Servicios de Autenticación y Seguridad DCE 1.1.

Los UUID de la versión 2 son similares a la versión 1, excepto que los 8 bits menos significativos de la secuencia de reloj se reemplazan por un número de «dominio local», y los 32 bits menos significativos de la marca de tiempo se reemplazan por un identificador entero significativo dentro del dominio local especificado. En los sistemas POSIX, los números de dominio local 0 y 1 son para id de usuario (UID) e id de grupo (GID) respectivamente, y otros números de dominio local están definidos por el sitio. En sistemas que no son POSIX, todos los números de dominio locales están definidos por el sitio.

La capacidad de incluir un dominio / identificador de 40 bits en el UUID viene con una compensación. Por un lado, 40 bits permiten aproximadamente 1 billón de valores de dominio/identificador por ID de nodo. Por otro lado, con el valor del reloj truncado a los 28 bits más significativos, en comparación con los 60 bits de la versión 1, el reloj en un UUID de la versión 2 «marcará» solo una vez cada 429,49 segundos, un poco más de 7 minutos, en lugar de cada 100 nanosegundos para la versión 1. Y con una secuencia de reloj de solo 6 bits, en comparación con 14 bits en la versión 1, solo se pueden generar 64 UUID únicos por nodo/dominio/identificador por tick de reloj de 7 minutos, en comparación con 16.384 valores de secuencia de reloj para la versión 1. Por lo tanto, la versión 2 puede no ser adecuada para casos en los que se requieren UUID, por nodo/dominio/identificador, a una velocidad superior a aproximadamente uno cada siete segundos.

Las versiones 3 y 5 (basadas en nombres de espacio de nombres)Editar

Los UUID de la versión 3 y la versión 5 se generan mediante el hashing de un identificador de espacio de nombres y un nombre. La versión 3 usa MD5 como algoritmo de hash, y la versión 5 usa SHA-1.

El identificador de espacio de nombres es en sí mismo un UUID. La especificación proporciona UUID para representar los espacios de nombres para direcciones URL, nombres de dominio completos, identificadores de objetos y nombres distinguidos X. 500; pero cualquier UUID deseado se puede usar como designador de espacio de nombres.

Para determinar el UUID de la versión-3 correspondiente a un espacio de nombres y un nombre dados, el UUID del espacio de nombres se transforma en una cadena de bytes, concatenada con el nombre de entrada, y luego se hash con MD5, produciendo 128 bits. A continuación, se sustituyen 6 o 7 bits por valores fijos, la versión de 4 bits (p. ej. 00112 para la versión 3), y la «variante» UUID de 2 o 3 bits (por ejemplo, 102 que indica un UUID RFC 4122, o 1102 que indica un GUID de Microsoft heredado). Dado que 6 o 7 bits están predeterminados, solo 121 o 122 bits contribuyen a la singularidad del UUID.

Los UUID de la versión 5 son similares, pero se usa SHA-1 en lugar de MD5. Dado que SHA-1 genera resúmenes de 160 bits, el resumen se trunca a 128 bits antes de reemplazar los bits de versión y variante.

Los UUID de la versión 3 y la versión 5 tienen la propiedad de que el mismo espacio de nombres y el mismo nombre se asignarán al mismo UUID. Sin embargo, ni el espacio de nombres ni el nombre se pueden determinar a partir del UUID, incluso si se especifica uno de ellos, excepto mediante búsqueda por fuerza bruta. RFC 4122 recomienda la versión 5 (SHA-1) sobre la versión 3 (MD5), y advierte contra el uso de UUID de cualquiera de las versiones como credenciales de seguridad.

Edición de la versión 4 (aleatoria)

Se genera aleatoriamente un UUID de la versión 4. Como en otros UUID, se usan 4 bits para indicar la versión 4, y 2 o 3 bits para indicar la variante (102 o 1102 para las variantes 1 y 2 respectivamente). Por lo tanto, para la variante 1 (es decir, la mayoría de los UUID), un UUID de versión aleatoria-4 tendrá 6 bits predeterminados de variante y versión, dejando 122 bits para la parte generada aleatoriamente, para un total de 2122, o 5.3×1036 (5.3 undecillion) posibles UUID de variante-4-1. Hay la mitad de UUID posibles versión-4 variante-2 (GUID heredados) porque hay un bit aleatorio menos disponible, se consumen 3 bits para la variante.