UUID v2ジェネレーター
Generate DCE Security UUID v2 with local domain and ID
UUID v2 とは何ですか?
UUID v2 は DCE セキュリティ UUID バージョンで、Distributed Computing Environment(DCE)仕様の一部として標準化され、RFC 4122 で参照されています。POSIX ユーザーまたはグループ識別子(UID/GID)をタイムスタンプフィールドに埋め込むことで UUID v1 を拡張します。
構造は UUID v1 に似ていますが、32 ビットの time_low フィールドが 32 ビットのローカル識別子(例:POSIX UID)に置き換えられ、1 バイトの local_domain フィールドがどの種類のローカル ID かを識別します。結果として、タイムスタンプが切り詰められ、精度と一意性の保証が低下します。
UUID v2 は現代のソフトウェアでは極めてまれです。ほとんどの開発者はこれを生成する必要はありません。このページはフォーマットを完全性のために文書化し、レガシーシステムで遭遇する UUID v2 値のデコードを支援します。
UUID v2 の構造
UUID v2 は他の UUID バージョンと同じ 128 ビットのハイフン付きフォーマットを持ちます。フィールドは UUID v1 と次のように異なります:
| フィールド | ビット | 目的 |
|---|---|---|
| local_id | 32 | <code>local_id</code>——32 ビットローカルドメイン識別子(例:<code>/etc/passwd</code> からの POSIX UID)、UUID v1 の time_low フィールドを置き換える |
| time_mid | 16 | <code>time_mid</code>——切り詰められた UUID v1 タイムスタンプの中間 16 ビット |
| time_hi+version | 16 | <code>time_hi_and_version</code>——最上位 12 ビットのタイムスタンプ、バージョンニブルを <code>2</code> に設定 |
| variant+clock_hi | 8 | <code>clock_seq_hi_and_reserved</code>——バリアントビットとクロックシーケンスの上位部分 |
| local_domain | 8 | <code>local_domain</code>——ドメイン識別子:<code>0</code> = POSIX ユーザー(UID)、<code>1</code> = POSIX グループ(GID)、<code>2</code> = 組織 |
| node | 48 | <code>node</code>——生成ホストの 48 ビット MAC アドレス |
例:000003e8-92e0-21ef-8000-325096b39f47——local_id 0x000003e8 = UID 1000、local_domain 0x00 = POSIX ユーザー
ローカルドメイン値
local_domain バイトは UUID に埋め込まれたローカル識別子の種類を指定します:
ドメイン値は DCE 仕様で定義されています。値 3–255 は予約済みです。実際には、実際の UUID v2 値で一般的に見られるのはドメイン 0(人物/UID)のみです。
UUID v2 がほとんど使用されない理由
3 つの特性が UUID v2 を最新のほとんどのアプリケーションで非実用的にします:
粗いタイムスタンプ解像度
タイムスタンプは 28 ビットに切り詰められます(約 7.2 分の粒度)。そのウィンドウ内では、同じ local_id とドメインを持つ同じホスト上の UUID は一意ではありません——仕様は clock_seq フィールドを使用してそれらを区別し、7 分間のウィンドウあたり 64 値に一意性を制限します。
標準ライブラリのサポートなし
UUID v1 および v4 とは異なり、UUID v2 はほとんどの UUID ライブラリでサポートされていません。uuid npm パッケージ、Python の uuid モジュール、Java の java.util.UUID はすべて v2 を省略しています。カスタム実装が必要です。
POSIX 固有のセマンティクス
ローカルドメインの概念(UID/GID)は本質的に POSIX 固有であり、POSIX ユーザー ID の概念が存在しない Windows、組み込みシステム、またはクラウド環境では意味を持ちません。
歴史的背景
UUID v2 は 1990 年代初頭に Open Software Foundation の Distributed Computing Environment(DCE/RPC)の一部として定義されました。目標は認可コンテキストを持つ UUID を作成することでした——具体的には、RPC サーバーが別の認証ステップなしに呼び出しユーザーを識別できるようにすることです。
DCE セキュリティモデルは、すべてのノードが共有の UID/GID 名前空間に参加する同質の POSIX 環境を想定していました。埋め込まれた UID により、サーバーはディレクトリサービスへのラウンドトリップなしにアクセス制御リストを迅速に確認できます。
- インターネットが同質の POSIX 環境から異質なクラウドアーキテクチャへ移行した
- 現代の認証は識別子に埋め込まれた UID ではなくトークン(JWT、OAuth)を使用する
- UUID v4(完全ランダム)と UUID v7(時間順)が一意識別子の実際のユースケースをカバーする
- DCE/RPC 自体が広く使用されなくなった
RFC 4122(2005 年)は DCE 仕様への参照によって UUID v2 を含みましたが、詳細な生成アルゴリズムを意図的に省略しました——それが IETF ではなく DCE によって定義されたことを指摘しながら。
UUID 標準を更新した RFC 9562(2024 年)は歴史的な完全性のために UUID v2 を保持しましたが、その POSIX 固有の性質と IETF 標準での完全な生成アルゴリズムの欠如を引き続き指摘しました。
UUID v2 vs UUID v1
UUID v2 は UUID v1 から派生しています。比較を示します:
| 側面 | UUID v1 | UUID v2 |
|---|---|---|
| タイムスタンプビット数 | 60 ビット(〜100 ナノ秒精度) | 28 ビット(〜7.2 分精度) |
| ローカル識別子 | なし | 32 ビット POSIX UID/GID |
| ローカルドメイン | 存在しない | 0=UID、1=GID、2=組織 |
| ノードフィールド | MAC アドレス | MAC アドレス |
| ライブラリサポート | 広くサポートされている | ほとんどサポートされていない |
| 標準 | RFC 4122 / RFC 9562 | DCE 仕様(RFC 4122 で参照) |
| 実際の用途 | レガシータイムスタンプ順 ID(Cassandra) | DCE セキュリティコンテキストのみ |
UUID v2 は汎用用途で UUID v1 に対して何の優位性も提供せず、ほとんどの面で厳密に劣っています。新規開発で UUID v2 を選択する理由はありません。
コード例
UUID v2 は標準ライブラリでネイティブサポートがありません。次の例は UUID v2 値の操作方法を示します:
Python——手動実装
import uuid, struct, time
def uuid_v2(local_id: int, local_domain: int = 0) -> str:
"""
Generate a DCE Security UUID (v2).
local_domain: 0 = POSIX UID, 1 = POSIX GID, 2 = Org
local_id: 32-bit unsigned integer (e.g. os.getuid())
"""
# Get a v1 UUID for the time and node fields
v1 = uuid.uuid1()
fields = list(v1.fields) # [time_low, time_mid, time_hi_version, clock_seq_hi_variant, clock_seq_low, node]
# Replace time_low with local_id
fields[0] = local_id & 0xFFFFFFFF
# Replace version nibble: clear lower 12 bits of time_hi, set version 2
fields[2] = (fields[2] & 0x0FFF) | 0x2000
# Replace clock_seq_low with local_domain
fields[4] = local_domain & 0xFF
return str(uuid.UUID(fields=tuple(fields)))
import os
print(uuid_v2(os.getuid(), local_domain=0)) # POSIX UID
print(uuid_v2(os.getgid(), local_domain=1)) # POSIX GID
Go——注意
// The standard "github.com/google/uuid" package does NOT support v2. // You would need to implement it manually, similar to the Python example above. // Most Go developers use v4 or v7 for new projects. import "github.com/google/uuid" v4 := uuid.New() // v4 — recommended for most use cases v7, _ := uuid.NewV7() // v7 — time-ordered, ideal for database primary keys
JavaScript——フィールドの抽出
既存の UUID v2 文字列から local_id とドメインを抽出するには:
// Extracting fields from a UUID v2 string
const uuidStr = '000003e8-1234-2abc-8200-a1b2c3d4e5f6'
// ^^^^^^^^ ^^^^ ^ ^^
// local_id ver variant+clockSeqHi
// ^^ = local_domain (00 = POSIX UID)
const parts = uuidStr.split('-')
const localId = parseInt(parts[0], 16) // → 1000 (0x3e8)
const version = parseInt(parts[2][0], 16) // → 2
const localDomain = parseInt(parts[3].slice(2), 16) // low byte of octet pair
const DOMAIN_NAMES = ['POSIX UID', 'POSIX GID', 'Org']
console.log(`Local ID: ${localId}`) // Local ID: 1000
console.log(`Version: ${version}`) // Version: 2
console.log(`Domain: ${DOMAIN_NAMES[localDomain]}`) // Domain: POSIX UID
google/uuid Go パッケージは uuid.NewDCEGroup() と uuid.NewDCEPerson() を通じて UUID v2 生成をサポートしています——これをサポートする数少ないメインストリームライブラリの 1 つです。