Network Working Group B. Mottershead Internet-Draft 29 May 2026 Intended status: Standards Track Expires: 30 November 2026 Resolvable Universally Unique Identifiers (RUUID) draft-motters-ruuid-00 Abstract This document defines Resolvable Universally Unique Identifiers (RUUIDs): a UUID format encoding a 64-bit IPv6 network prefix, a 48-bit identifier, and a 10-bit type. A resolver uses reverse DNS on the network prefix to discover the associated domain and, via that domain's "UUID document", constructs a URI of the referent. Defaults for both the document location and the referent URI template mean that when URLs follow the canonical convention, nothing beyond a reverse-DNS PTR record needs to be published; resolution degrades gracefully when configuration is missing. The 64-bit network field carries an IPv6 /64 prefix directly. An IPv4 /32 is encoded as the corresponding 6to4 prefix (RFC 3056). RUUIDs are 128 bits in the standard UUID textual form. Pending a dedicated UUID version, they use the RFC 9562 experimental version 8 with variant 10, so existing UUID parsers recognise them as well- formed UUIDs. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 30 November 2026. Mottershead Expires 30 November 2026 [Page 1] Internet-Draft RUUID May 2026 Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Relation to other identifier systems . . . . . . . . . . 3 1.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 5 3. RUUID Format . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Bit layout . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. The network prefix . . . . . . . . . . . . . . . . . . . 6 3.3. Version and variant . . . . . . . . . . . . . . . . . . . 7 3.4. Type . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Resolution . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 7 4.2. Registry endpoints . . . . . . . . . . . . . . . . . . . 8 4.2.1. Endpoint configuration . . . . . . . . . . . . . . . 8 4.3. Reverse-DNS name construction . . . . . . . . . . . . . . 8 4.4. UUID document resolution . . . . . . . . . . . . . . . . 8 4.4.1. Default document URI . . . . . . . . . . . . . . . . 9 4.5. Referent URI construction . . . . . . . . . . . . . . . . 9 4.5.1. Template selection . . . . . . . . . . . . . . . . . 9 4.5.2. Default template . . . . . . . . . . . . . . . . . . 9 4.5.3. Placeholder substitution . . . . . . . . . . . . . . 9 5. TXT Record Format . . . . . . . . . . . . . . . . . . . . . . 11 6. UUID Document . . . . . . . . . . . . . . . . . . . . . . . . 11 6.1. Document fetch . . . . . . . . . . . . . . . . . . . . . 11 6.2. Document structure and evolution . . . . . . . . . . . . 11 6.3. Verification fields . . . . . . . . . . . . . . . . . . . 12 6.4. Service entries (per-type referent templates) . . . . . . 13 6.4.1. Type entry fields . . . . . . . . . . . . . . . . . . 13 7. Generation Considerations . . . . . . . . . . . . . . . . . . 14 7.1. Network prefix semantics . . . . . . . . . . . . . . . . 14 7.2. Uniqueness . . . . . . . . . . . . . . . . . . . . . . . 14 7.3. Identifier construction . . . . . . . . . . . . . . . . . 14 7.4. Collisions . . . . . . . . . . . . . . . . . . . . . . . 16 Mottershead Expires 30 November 2026 [Page 2] Internet-Draft RUUID May 2026 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 9.1. Registry endpoint trust . . . . . . . . . . . . . . . . . 16 9.2. Prefix transfer and long-term durability . . . . . . . . 17 9.3. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 18 9.4. Identifier collision . . . . . . . . . . . . . . . . . . 18 9.5. DoS surface . . . . . . . . . . . . . . . . . . . . . . . 18 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 10.1. Normative References . . . . . . . . . . . . . . . . . . 18 10.2. Informative References . . . . . . . . . . . . . . . . . 19 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 20 1. Introduction UUIDs as defined in [RFC9562] are opaque: a UUID names a thing but says nothing about where to learn more about it. This document defines a _Resolvable UUID_ (RUUID) that binds the UUID at generation time to an IP network prefix. Reverse DNS resolves that prefix to a domain, and a "UUID document" resolves the domain and the fields of the UUID to a URI of its referent, allowing the UUID to be dereferenced. The bytes of an RUUID fully specify the algorithm a resolver MUST follow; there is no fallback or probing. Resolution uses only DNS, which may include DNS-over-HTTPS, with no new infrastructure required. An RUUID parses as a normal UUID with a well-defined version and the RFC 9562 variant; code that does not understand RUUIDs SHOULD treat them as opaque. 1.1. Relation to other identifier systems RUUID builds on preexisting UUID versions and variants, and relates to several other identifier systems. The relevant prior art includes: * Preexisting UUID versions and variants ([RFC9562]), which provide coordination-free generation and enduring universal uniqueness, but whose identifiers are opaque: a UUID names a referent without indicating where to find it. An RUUID is itself a UUID (currently version 8 with variant 10) that adds resolvability to these properties, through a public and reproducible resolution method. * URNs ([RFC8141]) are URIs urn:NID:NSS, requiring an IANA- registered Namespace Identifier per namespace; resolution is not standardized at the URN layer and varies per namespace. [RFC4122] defined a URN namespace, urn:uuid:, for UUIDs. Mottershead Expires 30 November 2026 [Page 3] Internet-Draft RUUID May 2026 * W3C Decentralized Identifiers (DIDs, [W3C-DID]) are URIs did:METHOD:ID with per-method registration and per-method resolution rules; an RUUID can be expressed as a DID via the did:uuid method, which is specified separately. * Numerous numbering schemes, such as IEEE Extended Unique Identifiers (EUI), Universal Product Codes (UPC), International Article Numbers (EAN), International Standard Book Numbers (ISBNs), Vehicle Identification Numbers (VINs), Object Identifiers (OIDs), Archival Resource Keys (ARKs), Handle-based identifiers ([RFC3650]), and Digital Object Identifiers (DOIs) depend on registration with an assignment authority. Many of these are resolvable but depend on dedicated resolution infrastructure. RUUIDs differ from the prior art in the following ways. * Unlike many of the existing numbering schemes, assignment of UUIDs in general, and RUUIDs in particular, does not depend on a central registration authority. By following the specification, anybody may generate a UUID and assign it to a referent with high confidence of enduring universal uniqueness, without dependence on authority or coordination with other parties generating UUIDs. Accordingly, UUIDs from independent sources may be pooled in databases and datastreams, without coordination. * They are 128-bit UUIDs in the conventional textual form (Section 4 of [RFC9562]), not URIs. Code that does not know this specification can still parse, store, and compare them as UUIDs. * Resolution of RUUIDs runs over the existing RIR / LIR / ISP allocation chain and the DNS reverse-zone delegation chain, with no dedicated registry or central resolver. The accountability gradient is the one that already governs IP address space. 1.2. Applicability As an _identifier_, an RUUID unambiguously names its referent indefinitely, like any UUID. As a _resolvable_ identifier, it can be walked through DNS to the referent's URI which can de-referenced; this role is bounded by continued control of the network prefix and its reverse-DNS delegation (see Section 9.2). Workflows requiring coordination-free generation of structured (sortable, time-ordered) identifiers SHOULD prefer UUID version 7 ([RFC9562]); see Section 7.4. Mottershead Expires 30 November 2026 [Page 4] Internet-Draft RUUID May 2026 2. Conventions and Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. The following terms are used in this document: RUUID A 128-bit identifier conforming to this specification. Network prefix The 64-bit field of an RUUID that carries an IPv6 /64 network prefix. An IPv4 /32 is encoded as the corresponding 6to4 prefix ([RFC3056]); see Section 3.2. Identifier The 48-bit field of the RUUID that names the referent within the network prefix. See Section 3. UUID document A JSON document, identified by a URI published in DNS at _uuid., that describes how RUUIDs under a network prefix are generated, and optionally publishes cryptographic material for verifying them. The format is defined in Section 6. 3. RUUID Format 3.1. Bit layout Treating the RUUID as a 128-bit big-endian unsigned integer with bit 127 being the most significant bit: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | identifier (48) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ver | network_hi | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |var| type | | +-+-+-+-+-+-+-+-+-+-+-+-+ network_lo | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Mottershead Expires 30 November 2026 [Page 5] Internet-Draft RUUID May 2026 +============+=======+============================+ | field | width | meaning | +============+=======+============================+ | identifier | 48 | identifier of the referent | | | | within (network, type) | +------------+-------+----------------------------+ | version | 4 | UUID version, set to 8 | +------------+-------+----------------------------+ | network_hi | 12 | high 12 bits of the 64-bit | | | | network prefix | +------------+-------+----------------------------+ | variant | 2 | UUID variant, set to | | | | binary 10 | +------------+-------+----------------------------+ | type | 10 | identifier of a type entry | | | | in the UUID document | +------------+-------+----------------------------+ | network_lo | 52 | low 52 bits of the network | | | | prefix | +------------+-------+----------------------------+ Table 1 3.2. The network prefix The 64-bit _network prefix_ is the concatenation of network_hi and network_lo, treated as a single 64-bit big-endian unsigned integer. It is an IPv6 /64 network prefix. An IPv4 /32 is encoded as the corresponding IPv6 6to4 prefix ([RFC3056]), zero-padded on the right; so a single 64-bit field carries either address family; the encoding distinguishes them. Note that while [RFC3056] [RFC7526] deprecated the companion anycast- relay prefix, the 6to4 IPv6 prefix is still allocated, and no native IPv6 addresses are assigned from it. Each /64 within 2002::/16 corresponds to a specific IPv4 /32 under the 6to4 derivation, and only that IPv4 owner controls the corresponding in-addr.arpa zone. A network field beginning with 0x2002 MUST be interpreted as IPv4-encoded; an RUUID with a network field in 2002::/16 MUST encode an IPv4 /32 whose in-addr.arpa reverse zone is controlled by the RUUID's resolver. The network prefix is an administrative identifier, not the IP address of any specific service; any number of servers MAY share a single network prefix (see Section 7.1). Mottershead Expires 30 November 2026 [Page 6] Internet-Draft RUUID May 2026 3.3. Version and variant The version field MUST be 8 (RFC 9562 "experimental"); the UUID variant field MUST be binary 10. 3.4. Type The 10-bit type field identifies a type entry in the UUID document (Section 6). The 1024 type values each describe one kind of referent and can carry their own referent-URI template. Type entries appear in the UUID document as CID service entries with id = # (see Section 6.2). Type 0 is reserved for "unspecified". 4. Resolution 4.1. Overview RUUID resolution is two-phase. *Phase 1* resolves the network field to a UUID document (Section 6). *Phase 2* applies the document's per- type service template to the 48-bit identifier to produce the referent URI. The spec's normative output is the referent URI. A resolver executes: A. *Phase 1* 1. Determine address family. If the top 16 bits of the network field equal 0x2002, the next 32 bits are the IPv4 /32 (reverse zone in-addr.arpa); otherwise the full 64 bits are an IPv6 /64 network prefix (reverse zone ip6.arpa). 2. Consult a _registry endpoint_ (Section 4.2) for the domain and UUID-document URI associated with the network prefix. This is the only step that MUST succeed; later steps have documented defaults. 3. Fetch the UUID document (Section 6). On fetch failure or non- JSON body, proceed with no document. B. *Phase 2* 1. Construct the referent URI: pick the service entry from the UUID Document which corresponds to the RUUID's type (or fall back per Section 4.5) and apply placeholder substitution. Per-identifier metadata lives in the UUID document, not the registry, so registry state per domain is constant regardless of how many RUUIDs are generated under that domain. Mottershead Expires 30 November 2026 [Page 7] Internet-Draft RUUID May 2026 4.2. Registry endpoints A registry endpoint returns the domain and UUID-document URI for a given network prefix, reached over DNS. The resolver does a PTR query against the reverse-DNS name (Section 4.3) for the domain, then a URI query at _uuid. (falling back to TXT; Section 4.4) for the document URI. The system DNS resolver is the default; any DNS- protocol-speaking service with these semantics is conformant. The DNS resolver may be either traditional DNS over UDP/TCP port 53 or a DNS-over-HTTPS (DoH) service ([RFC8484]). Every public IP prefix has a reverse-DNS chain, so resolution needs no dedicated registry or new infrastructure. 4.2.1. Endpoint configuration A registry endpoint is configured by URL; the scheme determines how it is reached. A DNS-protocol endpoint uses dns://[:] ([RFC4501]; port defaults to 53). A DoH-reachable endpoint uses an https:// URL ([RFC8484]), carrying wire-format DNS messages (application/dns-message). 4.3. Reverse-DNS name construction For IPv4-encoded RUUIDs (top 16 bits = 0x2002), recover the IPv4 /32 as (network >> 16) & 0xFFFFFFFF and construct the reverse-DNS name per Section 3.5 of [RFC1035]: the four address bytes in reverse order as decimal labels, followed by in-addr.arpa. For IPv6-encoded RUUIDs, the reverse-DNS name is the standard ip6.arpa name (Section 2.5 of [RFC1035]) truncated to the first 16 nibbles (the /64 boundary). 4.4. UUID document resolution At _uuid. the resolver issues a URI query first ([RFC7553]), then a TXT query (Section 5) if no usable URI record is returned. With multiple URI records, pick the lowest priority, breaking ties by highest weight. TXT records without the RUUID prefix MUST be ignored. Type-specific queries are used rather than ANY because [RFC8482] permits recursive resolvers to return minimal answers to ANY meta- queries, silently losing published records. Mottershead Expires 30 November 2026 [Page 8] Internet-Draft RUUID May 2026 4.4.1. Default document URI If no usable record is present at _uuid., the UUID-document URI defaults to https:///.well-known/uuid-document.json (well-known suffix per [RFC8615], registered in Section 8). On a fetch failure of the default URI, the resolver applies the default referent template (Section 4.5.2). A UUID document hosted elsewhere is located by publishing a URI or TXT record at _uuid.. 4.5. Referent URI construction The referent URI is constructed by selecting a template and applying placeholder substitution. 4.5.1. Template selection The resolver picks a template by checking, in order: 1. A service entry with id = # and a string serviceEndpoint (the type-specific template). 2. A service entry with id = #0 and a string serviceEndpoint (the domain-wide default). 3. The spec-wide default template defined below. 4.5.2. Default template When no document template applies, the default is: https://// The default applies when the service array is absent, has neither a # nor #0 entry, or has only entries without serviceEndpoint; it also applies when the document cannot be fetched at all (so reverse- DNS success alone always yields a resolvable URL). When URLs already follow this convention, no UUID document need be published. 4.5.3. Placeholder substitution The resolver replaces every occurrence of the following substrings: Mottershead Expires 30 November 2026 [Page 9] Internet-Draft RUUID May 2026 +==============+===============================================+ | placeholder | substituted with | +==============+===============================================+ | | when is absent from the template, the | | | full 48-bit identifier as 12 lowercase hex | | | digits, zero-padded; when is present, | | | the low 28 bits (the sequence of Section 7.3) | | | as 7 lowercase hex digits, zero-padded | +--------------+-----------------------------------------------+ | | the high 20 bits of the identifier (the | | | day_count of Section 7.3), rendered as the | | | corresponding calendar date YYYY-MM-DD | | | (2025-01-01 + day_count days, UTC) | +--------------+-----------------------------------------------+ | | the RUUID's type as a decimal integer, no | | | padding | +--------------+-----------------------------------------------+ | | the network field as 16 lowercase hex digits, | | | zero-padded | +--------------+-----------------------------------------------+ | | the full RUUID in canonical 8-4-4-4-12 | | | lowercase form | +--------------+-----------------------------------------------+ | | the domain returned by the PTR lookup | +--------------+-----------------------------------------------+ Table 2 Substituted values are not URI-encoded; all are URL-safe by construction. A template containing is an assertion by the document publisher that identifiers under this entry are constructed per Section 7.3. The resolver does not check this and performs the substitution as defined regardless of the underlying bits; a value implausible for Section 7.3 (e.g., a date far in the future) is the publisher's misconfiguration, not the resolver's concern. The result MUST be a valid URI reference per Section 4 of [RFC3986]. A relative reference is resolved against the UUID document's fetch URI per Section 5 of [RFC3986]. UUID documents SHOULD use *absolute- path references* (a path beginning with /, no scheme, no authority) so the document can be moved between hosts without editing service entries: /-rooted references transplant the document's scheme and authority unchanged. Mottershead Expires 30 November 2026 [Page 10] Internet-Draft RUUID May 2026 5. TXT Record Format When the _uuid. query returns no URI records but does return TXT, the resolver picks a TXT record whose concatenated strings (Section 3.3.14 of [RFC1035]) match: v=ruuid1 MUST be a valid URI per Section 3 of [RFC3986]. 6. UUID Document The UUID document is the JSON document fetched at step 3 of Section 4. It is a W3C Controlled Identifiers (CID) document ([W3C-CID]) whose service array carries per-type referent-URI templates. Resolvers MUST ignore fields they do not recognise, and SHOULD treat the document as authoritative only for the domain whose DNS pointed them at it. 6.1. Document fetch The UUID document is identified by the URI established at step 3 of Section 4: either an explicitly-published URI from _uuid. or the default (Section 4.4.1). The URI MAY use any scheme the resolver can dereference to a fetchable JSON document: https: (the expected baseline), http:, data: (inline JSON), file:, or did: (where the DID resolves to a document that _is_ the UUID document; did:web:, did:plc:, and did:uuid: are all usable). UUID documents SHOULD use https: for TLS transport integrity. The document MUST be UTF-8 JSON ([RFC8259]) with an object at top level. 6.2. Document structure and evolution A conforming UUID document is a JSON object structured as a W3C Controlled Identifiers (CID) document [W3C-CID]. It is the CID document for the network prefix's controller: one document, keyed by the network prefix, covers every full RUUID under that network prefix. The UUID document's id is the URI used to dereference it (CID canonical-URL): the URI published at _uuid., or the default- document URI (Section 4.4.1) when no record is published. The URI MAY use any URL-Standard scheme. The fields used by the resolution pipeline are: Mottershead Expires 30 November 2026 [Page 11] Internet-Draft RUUID May 2026 +===========+=======+===============+==============================+ |field |type | required by | meaning | | | | this spec | | +===========+=======+===============+==============================+ |@context |string | optional | JSON-LD context. SHOULD | | |or | (recommended) | include | | |array | | "https://www.w3.org/ns/cid/ | | | | | v1". | +-----------+-------+---------------+------------------------------+ |id |string | optional | The URI at which the | | | | (recommended) | document was dereferenced. | +-----------+-------+---------------+------------------------------+ |controller |string | optional | URI(s) of the entity | | |or | | authorised to update this | | |array | | document. When omitted, CID | | | | | treats it as equal to id. | +-----------+-------+---------------+------------------------------+ |alsoKnownAs|array | optional | Additional URIs identifying | | |of | | the same subject. | | |strings| | | +-----------+-------+---------------+------------------------------+ |service |array | required for | Per-type referent templates; | | |of | type entries | see Section 6.4. | | |objects| | | +-----------+-------+---------------+------------------------------+ Table 3 No top-level field is REQUIRED: the empty object {} is processable (it just makes no RUUIDs resolvable, other than those resolvable using the default template). The schema evolves by addition; resolvers MUST ignore unknown fields. A resolver that needs a field which is absent or unparseable MUST fail that operation rather than substitute defaults. 6.3. Verification fields A UUID document MAY include prefixes (array of CIDR strings) and domains (array of domain strings) covered by the document. Consumers SHOULD verify the RUUID's network prefix against prefixes and the resolved domain against domains when present, treating a mismatch as misconfiguration (log; MAY refuse the referent URI). These fields are advisory, not security-critical: an adversary who controls the DNS path or the document can set them to any value. Their purpose is detecting honest mistakes (staging docs at prod URLs, shared infrastructure pointing at the wrong tenant, a prefix move without re-hosting the document). Mottershead Expires 30 November 2026 [Page 12] Internet-Draft RUUID May 2026 6.4. Service entries (per-type referent templates) The document's service array carries one entry per RUUID type covered by the document. Entries follow the CID service-entry schema with one convention: the entry's id is the fragment URI # (the decimal type value, "0" through "1023"), and serviceEndpoint is the referent-URI template the resolver substitutes (Section 4.5). { "@context": "https://www.w3.org/ns/cid/v1", "id": "https://example.com/.well-known/uuid-document.json", "alsoKnownAs": ["did:uuid:00000000-0000-8200-8002-c000022a0000"], "service": [ { "id": "#1", "type": "User", "serviceEndpoint": "https://example.com/u/" }, { "id": "#42", "type": "CowTag", "serviceEndpoint": "https://example.com/t/" } ] } The array is sparse; missing entries fall back to the default template (Section 4.5.2). Different types MAY use entirely different URI structures. 6.4.1. Type entry fields +=================+==============================================+ | field | meaning | +=================+==============================================+ | id | the fragment URI # (e.g. #1, #42); the | | | type value is the numeric string after # | +-----------------+----------------------------------------------+ | type | arbitrary string or set of strings. | +-----------------+----------------------------------------------+ | serviceEndpoint | URI template per Section 4.5; the default | | | template applies if absent | +-----------------+----------------------------------------------+ Table 4 Mottershead Expires 30 November 2026 [Page 13] Internet-Draft RUUID May 2026 The id field is OPTIONAL in the Controlled Identifier specification, and may be any valid URI that is unique within the list of services. However, a RUUID resolver SHOULD ignore service entries with no id, and service entries whose id does not have a numeric fragment between #0 and #1023. The Controlled Identifier specification requires the type field, but the RUUID resolver makes no use of it. A resolver MUST NOT treat a missing type field as an error, even though a service entry lacking type does not conform to the Controlled Identifier specification. If present, a resolver MAY return the type value as additional information. The serviceEndpoint field is REQUIRED in the Controlled Identifier specification. When the RUUID resolver selects a service entry because its id fragment matches the RUUID's type value, the serviceEndpoint is the template used to construct the URI of the referent. 7. Generation Considerations 7.1. Network prefix semantics The network field is an IPv6 /64 network prefix, or an IPv4 /32 6to4-encoded into the same field. It is not the IP address of any specific service. The resolution algorithm requires only that the prefix's reverse-DNS zone resolve PTR queries to the domain that publishes the UUID document; the operator of that DNS zone need not coincide with the entity that generated the RUUID nor with the operator of the service providing the referent. Any number of servers, on unrelated addresses, MAY share a single network prefix. 7.2. Uniqueness Identifiers MUST be unique within (network, type). Global uniqueness of RUUIDs follows from this property and the global uniqueness of IP allocations, provided the generating entity has control of the network prefix at generation-time and maintains that indefinitely. Once an identifier is assigned, the binding MAY be retired but the identifier value MUST NOT be reused for a different referent. 7.3. Identifier construction For an RUUID used only within the generator's local scope, the 48-bit identifier MAY be any value satisfying Section 7.2. Mottershead Expires 30 November 2026 [Page 14] Internet-Draft RUUID May 2026 For an RUUID used outside the generator's local scope, where persistent universal uniqueness is required without ongoing tenancy by the generator of the network prefix, and without ongoing coordination among independent generators, the identifier SHOULD be constructed as follows: identifier = (day_count << 28) | sequence * day_count is a 20-bit unsigned count of days since 2025-01-01 00:00:00 UTC. The value MUST be a day on which the generator held reverse-DNS authority over the network prefix, and MUST NOT be a future day. Any day satisfying these two conditions is valid; day_count need not be the day on which the RUUID is generated, and an implementation MAY reuse the same day_count for many RUUIDs (e.g., the earliest day of its tenure of the network id, advancing only when the 2^28 sequence space is exhausted). The count wraps after 2^20 days (approximately year 4896). * sequence is a 28-bit value unique within (network, type, day_count). Successive controllers of a network prefix hold disjoint sets of tenure days, so the two MUST conditions above guarantee that their day_count values do not overlap, and identifiers from different controllers cannot collide even without coordination between them. This yields 2^28 = 268,435,456 RUUIDs per (network, type, day) and, across the 1024 type values, approximately 275 billion RUUIDs per network prefix per day of tenancy. The sequence uniqueness requirement is scoped to a single day within a single (network, type); coordination across days, across types, and across network prefixes is not required. Implementations MAY satisfy it with a counter, a time-of-day component with within-period randomness, deliberate partitioning across cooperating generators, or any other scheme. Random selection from the 28-bit space achieves a 2^-14 collision probability at approximately 16,000 RUUIDs per (network, type, day) and degrades sharply at higher volumes; coordination between multiple generator "workers" of some form is required to approach the per-day maximum. Resolvers MUST NOT interpret this structure. RUUIDs constructed this way are byte-indistinguishable from RUUIDs with opaque identifiers; the convention is a generator-side discipline that helps cooperating generators avoid collisions, not a resolution input. Mottershead Expires 30 November 2026 [Page 15] Internet-Draft RUUID May 2026 7.4. Collisions The 48-bit identifier yields a ~2^24 birthday bound for random identifiers within a single (network, type) tuple, which provide uncoordinated collision avoidance via randomness. The "uniqueness durability" of RUUIDs may be less in some cases than with other UUID versions, such as those based on hashes, timestamps, or pseudo-random number generators. For example, RUUIDs generated after control of network id has passed to a different entity may be more prone to collision than other UUID versions, if they are pooled in the same databases or datastreams with RUUIDs from a previous controller of the network id. 8. IANA Considerations This document requests: 1. Assignment of a dedicated UUID version to this specification, provisionally requested as version 9 (or, if 9 is unavailable, the next unassigned UUID version). See [RFC9562]. Pending such allocation, implementations use the RFC 9562 experimental version 8. 2. Establishment of an "RUUID TXT Prefix Registry" administered under IETF Review [RFC8126], with the initial entry v=ruuid1 referencing this document. 3. Registration of uuid-document.json in the "Well-Known URIs" registry per [RFC8615], referencing this document. The well- known URI provides the default UUID-document location defined in Section 4.4.1. 9. Security Considerations 9.1. Registry endpoint trust RUUID resolution inherits its registry endpoint's trust substrate: a DNS-protocol endpoint inherits the DNS hierarchy (DNSSEC, where deployed, authenticates the _current_ operator rather than continuity across transfers; see Section 9.2). A DoH-reachable endpoint additionally relies on the TLS connection to the configured URL ([RFC9525]). Strengthening trust beyond that substrate (signed records, externally rooted continuity evidence) is out of scope. Mottershead Expires 30 November 2026 [Page 16] Internet-Draft RUUID May 2026 9.2. Prefix transfer and long-term durability An RUUID's identifier role is unconditional, but its resolution role depends on continued control of the network prefix and its reverse- DNS delegation. IP prefixes can be transferred between operators; DNS provides no notion of _continuity of identity_ across a transfer (a new operator configuring reverse DNS competently is indistinguishable from the original, even with DNSSEC). Three observable states at Phase 1: _Still valid._ PTR returns the intended domain; the binding is intact. _Detectably rotted._ The prefix is no longer maintained for RUUID purposes (NXDOMAIN, or a PTR to a domain serving no UUID document). The resolver gets a clear failure signal, better than plain UUIDs (no resolution at all) or a lapsed HTTPS URL (indistinguishable 404). _Commandeered._ The prefix has been reassigned and the new operator serves a PTR of their choosing. The resolver sees an authentic (DNSSEC-validatable) PTR leading to an unintended domain. This is the genuine new failure mode RUUID introduces; mitigating it generally is an open problem for the IETF and address-registry community. Network prefixes used in RUUIDs SHOULD be ones expected to be held for the identifiers' operational lifetime; native IPv6 from a durably held PA/PI allocation is the strongest choice. The 6to4-encoded IPv4 form inherits IPv4-transfer risk. Consumers SHOULD record the PTR target at first resolution and compare on later resolutions; this is trust-on-first-use, with the usual caveat that it offers nothing to a consumer whose first encounter is after the change. Phase 2 is plain URI resolution. This spec places no constraint on the URI scheme; RUUID inherits whatever durability properties the scheme provides. The common case is HTTPS, with the same partial trust model that governs every HTTPS link on the web. Even when resolution rots or is commandeered, the RUUID remains a valid identifier for its referent in the consumer's own records. Mottershead Expires 30 November 2026 [Page 17] Internet-Draft RUUID May 2026 9.3. Privacy An RUUID discloses a network prefix associated with its referent. This is generally similar in sensitivity to the domain itself, but in some configurations may be more revealing (e.g., a customer prefix inside a hosting provider). Consider this when choosing the network prefix for an RUUID. When the recommended construction (Section 7.3) is used, the RUUID's day_count discloses a day on which the generator held the network prefix, information of similar character to public WHOIS and reverse- DNS delegation records. To suppress even this signal, use an opaque 48-bit identifier instead, subject to Section 7.4. 9.4. Identifier collision RUUIDs do not provide cryptographic uniqueness guarantees beyond what the chosen identifier scheme provides. RUUIDs generated with small counter-style identifiers are vulnerable to identifier guessing; when this is a concern, use random identifiers filling the available width. 9.5. DoS surface Adversarial RUUIDs could direct registry queries at arbitrary network prefixes and HTTPS fetches at arbitrary URLs. Resolvers SHOULD apply standard DNS rate-limiting and HTTP client limits, and SHOULD cache UUID documents per domain so mass ingestion from one domain does not multiply fetches. 10. References 10.1. Normative References [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, . [RFC9562] Davis, K., Peabody, B., and P. Leach, "Universally Unique IDentifiers (UUIDs)", RFC 9562, DOI 10.17487/RFC9562, May 2024, . [RFC7553] Faltstrom, P. and O. Kolkman, "The Uniform Resource Identifier (URI) DNS Resource Record", RFC 7553, DOI 10.17487/RFC7553, June 2015, . Mottershead Expires 30 November 2026 [Page 18] Internet-Draft RUUID May 2026 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, . [RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019, . [RFC9525] Saint-Andre, P. and R. Salz, "Service Identity in TLS", RFC 9525, DOI 10.17487/RFC9525, November 2023, . [W3C-CID] "Controlled Identifiers v1.0", W3C Working Draft, n.d., . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, . 10.2. Informative References [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, DOI 10.17487/RFC3056, February 2001, . [RFC7526] Troan, O. and B. Carpenter, Ed., "Deprecating the Anycast Prefix for 6to4 Relay Routers", BCP 196, RFC 7526, DOI 10.17487/RFC7526, May 2015, . [RFC4501] Josefsson, S., "Domain Name System Uniform Resource Identifiers", RFC 4501, DOI 10.17487/RFC4501, May 2006, . [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, . Mottershead Expires 30 November 2026 [Page 19] Internet-Draft RUUID May 2026 [RFC8482] Abley, J., Gudmundsson, O., Majkowski, M., and E. Hunt, "Providing Minimal-Sized Responses to DNS Queries That Have QTYPE=ANY", RFC 8482, DOI 10.17487/RFC8482, January 2019, . [RFC8141] Saint-Andre, P. and J. Klensin, "Uniform Resource Names (URNs)", RFC 8141, DOI 10.17487/RFC8141, April 2017, . [RFC3650] Sun, S., Lannom, L., and B. Boesch, "Handle System Overview", RFC 3650, DOI 10.17487/RFC3650, November 2003, . [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, DOI 10.17487/RFC4122, July 2005, . [W3C-DID] "Decentralized Identifiers (DIDs) v1.0 -- Core architecture, data model, and representations", W3C Recommendation REC-did-core-20220719, 2022, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . Author's Address Brian Mottershead Email: bmotters@gmail.com Mottershead Expires 30 November 2026 [Page 20]