Internet Unique ID (INUID) Protocol Specification

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 19 October 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

The modern Internet continues to rely on an addressing model in which endpoint identity and routing location are fused into a single value. While this model enabled the rapid growth of packet networking, it creates structural limitations in environments that demand strong endpoint authentication, efficient mobility, persistent sessions, scalable multihoming, and bounded global routing state.¶

The Internet Unique ID (INUID) protocol addresses these issues by separating identity from location at the network layer. In INUID, a packet carries both a stable Identity Prefix and a routable Locator. The identity identifies the communicating endpoint, while the locator identifies the endpoint's current topological attachment point.¶

This separation allows transport sessions, access policies, and security associations to bind to stable identities, while the forwarding plane operates only on aggregated locators. As a result, network mobility and path changes can occur without breaking the higher-layer communication state.¶

INUID additionally requires cryptographic proof of source identity at the network edge. This design makes unauthenticated source spoofing substantially more difficult and allows access networks to enforce identity ownership before forwarding traffic into the core.¶

2. Requirements Language

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 [RFC2119] and [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

3. Terminology

• Identity Prefix: A 64-bit stable identifier assigned to an endpoint, endpoint group, or delegated identity namespace.¶

• Locator: A 48-bit routing value indicating the topological region through which traffic for an endpoint is forwarded.¶

• Tag: A 16-bit field used for attachment-specific demultiplexing, temporary sub-identities, or local policy handling.¶

• CSV: Cryptographic Source Verification, the validation mechanism by which a router confirms that a sender is authorized to use a claimed source identity.¶

• IA: Identity Advertisement, the local-link mechanism used by endpoints to announce identity material and capabilities to an access router.¶

• Edge Router: A router at an administrative boundary or access domain that validates endpoint identity and authorizes locator use.¶

• Transit Router: A router in the forwarding core that routes packets based primarily on Locator values.¶

4. Design Goals

INUID has the following design goals:¶

1. Provide a stable network-layer identifier that is independent of network attachment point.¶

2. Constrain global routing growth by advertising only locator reachability in the routing core.¶

3. Prevent unauthenticated source address spoofing through mandatory source verification at the edge.¶

4. Support session continuity during locator change events such as mobility and multihoming failover.¶

5. Maintain a simple base header suitable for line-rate forwarding in software and hardware implementations.¶

6. Permit extensibility through explicit extension headers rather than overloading the fixed header format.¶

5. Architecture Overview

INUID uses a structured 128-bit endpoint representation composed of two logical halves. The first half is the Identity Prefix, which remains stable over time and is cryptographically bound to an authorized entity. The second half is a routable suffix composed of a Locator and Tag.¶

Packets are forwarded through the core using only the Destination Locator. The Destination Identity Prefix is retained end-to-end but is not required for transit routing decisions. This division allows the forwarding plane to preserve aggregation while the endpoint identity remains meaningful to hosts, access routers, policy engines, and security systems.¶

INUID defines a mandatory edge-validation model. A packet entering an INUID administrative domain from an attached endpoint MUST be subjected to Cryptographic Source Verification before the packet is forwarded beyond the trust boundary. Transit routers are not required to re-verify identities for each hop, though domains MAY apply additional policy checks where appropriate.¶

6. Addressing Model

An INUID address consists of the following conceptual fields:¶

+-------------------------------+-------------------------------+
|     Identity Prefix (64)      |   Locator (48)   | Tag (16)  |
+-------------------------------+-------------------------------+

The Identity Prefix identifies the logical endpoint or namespace. It is intended to remain stable across movements, renumbering events, and access-network changes, unless replaced due to explicit administrative or cryptographic policy.¶

The Locator identifies a routing region and is used by forwarding systems to deliver the packet to the correct destination domain or attachment point.¶

The Tag provides local disambiguation. It MAY identify a temporary attachment instance, service endpoint, virtual interface, or short-lived session-scoping construct. The Tag MUST NOT be interpreted as a substitute for cryptographic proof of identity ownership.¶

7. INUID Base Header Format

The INUID base header is a fixed 40-byte structure optimized for alignment with common forwarding and parsing architectures.¶

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Traffic Class |           Flow Label                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Payload Length        |  Next Header  |   Hop Limit   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                    Source Identity Prefix (64)                +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Source Locator (48)                      |Source Tag (16)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                  Destination Identity Prefix (64)             +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Destination Locator (48)                   | Dest Tag (16) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

8. Extension Headers

INUID supports a chained extension-header model. Each extension header MUST begin with a Next Header field and a Header Length field unless otherwise specified by a future standards-track extension definition.¶

The following extension header categories are defined for INUID deployments:¶

9. Protocol Operations

10. Packet Processing Rules

11. Identity-to-Locator Resolution

INUID requires a mechanism by which senders obtain a currently valid Destination Locator for a given Destination Identity Prefix. This document does not mandate a single universal resolution system, but any such mechanism MUST provide authenticity, freshness, and protection against unauthorized locator publication.¶

Resolution systems MAY be DNS-based, rendezvous-based, directory-based, or domain-delegated. Regardless of mechanism, a sender MUST be able to validate that the returned Locator is authorized for the requested Identity Prefix.¶

12. Transition and Compatibility

INUID is expected to coexist with IPv4 and IPv6 during a long transition period. To support compatibility, this specification defines a Legacy Translation range at ::FFFF:0:0/96.¶

Packets entering an INUID-native network from an IPv4-only domain MAY be mapped into this range by a translation gateway. Such mapped values MUST be treated as compatibility encodings rather than as proof of native INUID identity ownership.¶

Gateways MUST preserve a clear distinction between native cryptographically bound identities and translated legacy addresses. Implementations MUST NOT infer cryptographic identity from a legacy-mapped address alone.¶

13. Deployment Considerations

14. Manageability Considerations

Implementations SHOULD expose operational counters and logs for at least the following events:¶

• CSV successes and failures¶

• Identity Advertisement acceptance and rejection events¶

• Locator update acceptance and rejection events¶

• Unsupported Next Header or extension-header processing failures¶

• Hop Limit expiration events¶

• Legacy translation mappings and failures¶

Operational tools SHOULD support visibility by Identity Prefix, Locator, interface, and policy domain, subject to privacy and retention requirements.¶

15. Error Handling

Implementations SHOULD define an error signaling mechanism analogous to existing control-message frameworks. Such a mechanism SHOULD support notification for Hop Limit exhaustion, unsupported header types, validation failure diagnostics for trusted domains, and packet size violations.¶

Error signaling MUST be rate-limited and MUST NOT create reflection, amplification, or identity disclosure vulnerabilities.¶

16. Security Considerations

INUID is designed to improve network-layer security by requiring source identity validation at the edge. This significantly reduces the feasibility of forged-source attacks and provides a stronger foundation for attribution, filtering, and trust-domain enforcement.¶

However, the protocol introduces new security considerations that implementations and operators MUST address:¶

• Verification Cost: Attackers may attempt to exhaust edge resources by sending large volumes of invalid authentication material. Implementations SHOULD use caching, batching, rate limiting, and hardware acceleration.¶

• Replay Attacks: Authentication proofs MUST include freshness protection such as timestamps, sequence values, nonces, or short-lived authorization tokens.¶

• Key Compromise: The security of an Identity Prefix depends on associated keying material. Deployments MUST define revocation, rotation, and recovery procedures.¶

• Locator Poisoning: Identity-to-locator resolution systems are security-critical and MUST protect against tampering, stale data, and unauthorized updates.¶

• Extension Header Abuse: Malicious packets may use excessive or malformed extension chains to stress parser behavior. Implementations SHOULD enforce total extension length and chain depth limits.¶

• Privacy Risk: Stable identifiers can increase linkability across networks and sessions. Implementations SHOULD support privacy-preserving modes, delegated service identities, or controlled identifier rotation where operationally appropriate.¶

Where digital signatures are used, Ed25519 or a cryptographically comparable algorithm is RECOMMENDED. Algorithm agility MUST be preserved.¶

17. Privacy Considerations

Because INUID separates identity from location and allows identity continuity across movement events, it can introduce stronger cross-session correlation than conventional ephemeral addressing. Deployments that require privacy SHOULD define policies for temporary identities, rotating tags, delegated service identities, and minimized observability of stable identity values.¶

Telemetry and logging systems SHOULD avoid collecting more identity-linked data than necessary for security and operations.¶

18. IANA Considerations

This document requests the following IANA actions:¶

1. Allocate IP Version Number 9 for INUID.¶

2. Create an "INUID Next Header Types" registry.¶

3. Allocate a Next Header value for the Authentication Extension Header.¶

4. Allocate a Next Header value for the Mobility Update Extension Header.¶

5. Allocate a Next Header value for the Telemetry Extension Header.¶

6. Allocate a Next Header value for the Legacy Translation Context Header.¶

Future registry assignments SHOULD require Standards Action or IESG Approval.¶

19. Example Deployment Scenarios

20. Future Work

Future documents are expected to define the precise wire format of the Authentication Extension Header, standardized locator-resolution procedures, mobility update message formats, an INUID control-message framework, and operational profiles for constrained environments and backbone-class deployments.¶

21. Conclusion

INUID provides a network-layer framework that separates stable endpoint identity from topological reachability while preserving efficient routing and enabling strong edge-based source validation. By combining hierarchical locators, cryptographic identity, and structured extensibility, INUID offers a foundation for more secure, mobile, and scalable internetworking.¶

Appendix A. Acknowledgements

The author acknowledges the broader networking research community for foundational work on identifier-locator split architectures, anti-spoofing systems, secure routing, mobility support, and high-performance packet forwarding design.¶

Author's Address