Herramientas de desarrollo · UUID generador
RFC 4122 vs RFC 9562: Qué cambió en el estándar 2024 UUID
· Antecedentes
uuid criptografía APIS del navegador
Se citan dos RFC para UUID y no dicen exactamente lo mismo. Esta publicación explica lo que RFC 9562 agregó, aclaró y desaprobó en relación con RFC 4122.
¿Qué RFC cito? — la confusión cuando la documentación y las bibliotecas hacen referencia a diferentes estándares
Se citan habitualmente dos RFC en la documentación UUID y no dicen cosas idénticas. RFC 4122, publicado en 2005, definió los UUID y sus cinco versiones (v1 a v5). RFC 9562, publicado en 2024, deja obsoleto por completo el RFC 4122, aclara ambigüedades que los profesionales solucionaron, agrega tres nuevas versiones (v6, v7, v8) y actualiza la guía sobre la implementación de la aleatoriedad. Cuando una biblioteca cita el RFC 4122, no está mal: es posible que esa biblioteca se haya publicado antes de que se publicara el RFC 9562 o que los mantenedores no hayan actualizado la documentación. La verificación de las citas RFC le indica cuándo se actualizó significativamente una biblioteca por última vez. Al escribir nuevas especificaciones o evaluar implementaciones, el RFC 9562 es la referencia normativa.
Obsoleto, no reemplaza el formato: todo lo válido según RFC 4122 sigue siendo válido; el diseño y los bits de variante no cambian
RFC 9562 obsoleta formalmente el RFC 4122 como documento de referencia actual, al tiempo que conserva la conocida representación de 128 bits, los grupos hexadecimales, la posición de la versión y el diseño de la variante principal. No es necesario volver a emitir las cadenas UUID almacenadas existentes simplemente porque existe un RFC más nuevo. La migración práctica está en la documentación, los generadores y la política de validación: cite el estándar actual, comprenda las versiones agregadas y verifique si el código antiguo se basaba en una ambigüedad que la revisión aclaró. La compatibilidad aún debe probarse en los límites del sistema, especialmente cuando una biblioteca serializa estructuras GUID de Microsoft o impone un conjunto de versiones más limitado que el que describe el estándar.
Tres nuevas versiones: v6 (tiempo reordenado), v7 (ordenado por tiempo de época Unix) y v8 (definido por implementación)
RFC 9562 agrega tres nuevas versiones al estándar. La versión 6 reordena los bits de marca de tiempo v1 para producir identificadores ordenables lexicográficamente para un mejor rendimiento de la base de datos. La versión 7 utiliza una marca de tiempo de milisegundos Unix de 48 bits seguida de bits aleatorios, lo que proporciona una generación ordenada en el tiempo sin las preocupaciones de privacidad de la v1. La versión 8 es una trampilla de escape para diseños definidos por la implementación. Ninguna de estas versiones altera el funcionamiento de las versiones 1 a 5 ni su significado. Una v1 UUID de 2005 y una v7 UUID de 2024 pueden coexistir en la misma base de datos, cada una con sus bits de versión identificando su método de generación. Las tres nuevas versiones abordan patrones comunes que surgieron en la práctica.
Max UUID se une a Nil: el valor totalmente F definido junto con el valor totalmente cero
RFC 4122 documentó el Nil UUID (todos bits cero) como un valor de referencia especial en ejemplos y documentación. RFC 9562 incluye la misma definición Nil pero define formalmente el Max UUID (todos los bits establecidos en uno) para los límites del rango. Ni Nil ni Max son una versión 4 aleatoria UUID porque no tienen la versión correcta ni los bits de variante. Max UUID es útil como límite de rango superior en consultas de bases de datos: WHERE uuid_column <= MAX_UUID coincide con todos los UUID posibles. Nil es útil como centinela para columnas no asignadas que aceptan valores NULL UUID. RFC 9562 documenta ambos sin exigir su uso en los datos de la aplicación.
Orientación aclarada: consejos explícitos para utilizar un CSPRNG para campos aleatorios, en contadores monótonos dentro de un milisegundo y sobre la preferencia de versiones ordenadas por tiempo para la localidad de la base de datos. La guía de mejores prácticas de
RFC 9562 distingue la resistencia a la colisión de la indiscutible. Los campos aleatorios deben utilizar una fuente adecuada al modelo de amenaza de la aplicación, y la opacidad sensible a la seguridad requiere un CSPRNG. Los generadores basados en el tiempo tienen un problema de monotonicidad separado cuando varios identificadores comparten un tick de marca de tiempo; el estándar describe contadores y precisión de marca de tiempo adicional como métodos posibles, cada uno con reglas de estado y de rollover. Las versiones basadas en nombres siguen siendo identificadores deterministas, no pruebas de autenticidad. Estas aclaraciones son importantes porque un analizador UUID puede aceptar todos los diseños aunque sus requisitos de generación y propiedades de divulgación de información difieran.
Dónde aparecen las ideas de ULID: cómo el formato de la comunidad influyó en el diseño de v7
RFC 9562 dice que sus autores analizaron varios esquemas de identificadores ordenables existentes, incluidos ULID, Snowflake y KSUID, mientras desarrollaban los nuevos diseños. Eso respalda una conclusión modesta: la demanda operativa de identificadores distribuidos ordenados en el tiempo informó la revisión. No prueba que un formato comunitario haya donado un diseño de campo exacto a la versión 7. La similitud práctica es suficiente para el trabajo de arquitectura: estas familias colocan la información temporal cerca del frente para que el orden ordinario pueda preservar un orden de creación amplio, luego difieren en codificación, coordinación y comportamiento dentro de los ticks. Elija entre ellos según la compatibilidad del ecosistema y las garantías documentadas en lugar de una afirmación de ascendencia directa.
Lo que esto no cubre: una diferencia línea por línea; Esta publicación sigue las consecuencias prácticas para los implementadores.
Esta publicación integral sigue las consecuencias prácticas y la implementación de RFC 9562 para implementadores y usuarios, no diferencias línea por línea contra RFC 4122. Las especificaciones completas están disponibles en los organismos de normalización y vale la pena leerlas para implementar el manejo de UUID en idiomas o plataformas; el texto proporciona detalles autorizados más allá de lo que puede cubrir una descripción general. Esta publicación no describe la mecánica a nivel de bits de cómo v6 reordena los bytes de v1 o cómo v7 codifica milisegundos de Unix. Tanto los estándares como las guías de implementación siguen siendo la principal referencia autorizada para cualquier pregunta de implementación relacionada con el diseño de bits, la codificación o la verificación del cumplimiento.
Conclusión: actualice sus citas y sus valores predeterminados: el generador ToolAcre sigue la guía CSPRNG que ambos RFC comparten
Para cualquier trabajo nuevo, actualice la documentación y las especificaciones para citar el RFC 9562. Cada UUID del RFC 4122 sigue siendo válido según el RFC 9562; la migración es puramente prospectiva y de naturaleza administrativa. La guía aclarada sobre aleatoriedad criptográfica refuerza que los identificadores deben provenir de fuentes criptográficamente seguras en los sistemas de producción. ToolAcre sigue la guía de aleatoriedad criptográfica de ambos RFC, utilizando exclusivamente la Web Crypto API del navegador. Cuando encuentra un UUID de registros, exportaciones de bases de datos o respuestas de API, la verificación bien formada de ToolAcre informa su versión y variante contra RFC 9562. RFC 9562 es la aclaración y modernización de un estándar ya estable.