Internet-Draft IPv7 Identity Protocol September 2026
Oliveira Expires 27 March 2027 [Page]
Workgroup:
Independent Submission
Internet-Draft:
draft-oliveira-ipv7-00
Published:
Intended Status:
Informational
Expires:
Author:
R. Oliveira
Independent

IPv7: Identity-Centric Network Protocol with Verifiable Origin and Rate-Limit Tokens

Abstract

This document specifies IPv7, an identity-centric network protocol that replaces purely numerical source addressing with a hierarchical identity string and a Variable-Length Identity Block (VLIB). The VLIB carries an Ephemeral Identity Token (EIT), provider and tenant identifiers, role/policy signalling, and an Origin Signature verifiable by the originating provider. Validation occurs in three layers at the first-hop router: Origin Verification, Identity Verification, and Policy Enforcement. A quantum-resistant signature option using CRYSTALS-Dilithium (ML-DSA-65) is incorporated. This document also describes an optional local extension for Rate-Limit Tokens issued by ISPs and enforced in hardware. A reference implementation in Rust is available as the arkhe-ipv7 and arkhe-ipv7-cli crates.

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 27 March 2027.

▲

Table of Contents

1. Introduction

The current Internet Protocol suite (IPv4 and IPv6) identifies endpoints by numerical addresses that carry no verifiable identity. This limitation enables a class of attacks in which malicious actors use residential proxies and compromised IoT devices to obscure their origin.

IPv7 addresses this limitation by making identity a first-class component of the network layer. Each packet carries a Variable-Length Identity Block (VLIB) that encodes a hierarchical identity string.

The protocol defines three validation layers at the first-hop router: Origin Verification, Identity Verification, and Policy Enforcement. The cryptographic foundation is quantum-resistant: CRYSTALS-Dilithium (ML-DSA-65) is specified as the signature algorithm.

A reference implementation in Rust is available as the arkhe-ipv7 and arkhe-ipv7-cli crates on crates.io.

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

2. Terminology

Variable-Length Identity Block (VLIB):
A hierarchical identity string carried in the packet header. Format: EIT/service.location.provider.tenant.role.trustlevel.reputationscope.origin_signature
Ephemeral Identity Token (EIT):
A time-bound opaque token that identifies a session. The EIT is renewed per session, typically every 24 hours. It is not a permanent identifier.
Origin Signature:
A cryptographic signature over the VLIB (excluding the signature field itself), produced by the originating provider's private key.
Source-Provider Validation (SPV):
The process of verifying the Origin Signature against the public key associated with the asserted Provider ID.
Trust Level:
An enumerated value (Low, Medium, High) that represents the current trust assessment of the origin.
Reputation Scope:
An enumerated value (Local, Regional, Global) that indicates the scope within which the origin's reputation is valid.
Role:
An enumerated value (Guest, User, Admin) that represents the asserted privilege level.

3. Protocol Architecture

3.1. Variable-Length Identity Block (VLIB)

The VLIB is the core identity structure of IPv7. It is a hierarchical string with the following canonical format:

EIT/service.location.provider.tenant.role.trustlevel.
reputationscope.origin_signature

The components are separated by a forward slash (after the EIT) and by periods (between the remaining components). The EIT is placed before the slash; all other components follow.

The canonical format without the signature contains seven components after the slash. With the signature, there are eight components.

The Origin Signature MUST cover the canonical form without the signature field. Including the signature in its own payload would create a circular dependency and is therefore forbidden.

Example VLIB:

eit_7f3a9c2b/web.nyc.exampleisp.home.guest.medium.local.
sig_abc123

3.2. Ephemeral Identity Token (EIT)

The EIT is a time-bound token with the following fields:

The EIT MUST have a non-zero time-to-live (TTL). A token with a TTL of zero is invalid. The expires_at field MUST be computed as issued_at + ttl, with overflow checking.

A router validating an EIT MUST reject it if the current time is before the issued_at timestamp (clock skew) or if the current time is at or after the expires_at timestamp.

3.3. Origin Signature

The Origin Signature is an ML-DSA-65 signature over the canonical VLIB form without the signature field. It is represented as a hexadecimal string.

The signature binds the VLIB to the originating provider's public key. A router verifying the signature MUST:

  1. Look up the public key associated with the asserted Provider ID.
  2. Reject the packet if the provider is not registered.
  3. Reject the packet if the provider has been revoked.
  4. Verify the signature against the canonical VLIB payload.

If any step fails, the packet MUST be dropped.

3.4. Role/Policy Signalling

The VLIB includes a role field that asserts the privilege level of the origin. The role values are:

Guest:
Lowest privilege. Read-only access to public resources.
User:
Read/write access to tenant resources.
Admin:
Management of tenant resources.

A router enforcing policy MUST compare the asserted role against the minimum role required by the destination. If the asserted role is lower than the required role, the packet MUST be dropped.

Resource matching MUST be exact. A policy for "web" MUST NOT apply to "webhook" or "myweb". Prefix matching, when used, MUST normalize the resource to end with a separator (e.g., "/admin/" to match "/admin/users" but not "/administration").

3.5. Rate-Limit Token (Local Extension)

The Rate-Limit Token is an optional local extension. It is issued by the ISP and carries:

A router implementing this extension MUST reject packets if the token has expired or if the provider does not match the VLIB's provider. If the token is absent and the router requires it, the packet MUST be dropped (fail-closed).

4. Router Processing Pipeline

The router processing pipeline consists of three mandatory layers and one optional layer. The pipeline is fail-closed: if any required layer fails, the packet is dropped.

4.1. Layer 1: Origin Verification

The router parses the VLIB, extracts the Origin Signature, and verifies it against the Provider ID's public key. The signature MUST cover the canonical VLIB form without the signature field.

If the provider is unknown, the packet is quarantined. If the signature is invalid, the packet is dropped.

4.2. Layer 2: Identity Verification

The router validates the EIT:

  1. The EIT MUST not be expired.
  2. The EIT's issued_at MUST not be in the future.
  3. The EIT's token MUST match the VLIB's EIT field.
  4. The EIT's provider MUST match the VLIB's provider.
  5. The EIT's tenant MUST match the VLIB's tenant.

If any check fails, the packet is dropped.

4.3. Layer 3: Policy Enforcement

The router extracts the asserted role from the VLIB and compares it against the destination's ACL. The comparison uses exact resource matching or explicitly configured prefix matching.

If no policy matches the destination resource, the packet is allowed by default (fail-open for unconfigured resources). If a policy matches but the role is insufficient, the packet is dropped.

If the router is configured to require at least one policy (require_policy = true), then the absence of any policy causes the packet to be dropped (fail-closed).

5. Packet Format

5.1. IPv7 Header

The IPv7 header is 40 bytes, structured as follows:

+--------+--------+--------+--------+
|Version |  TC   |    Flow Label    |  (4 bytes)
+--------+--------+--------+--------+
|         Payload Length           |  (2 bytes)
+--------+--------+--------+--------+
| Next   |  Hop   |    Reserved     |  (4 bytes)
| Header | Limit  |                 |
+--------+--------+--------+--------+
|         Source VLIB (16 bytes)   |
+-----------------------------------+
|      Destination VLIB (16 bytes) |
+-----------------------------------+
|         Extensions (variable)     |
+-----------------------------------+
|            Payload               |
+-----------------------------------+
Version:
4 bits. MUST be 7.
Traffic Class:
8 bits.
Flow Label:
20 bits.
Payload Length:
16 bits. Length of the payload in bytes.
Next Header:
8 bits. Identifies the first extension header.
Hop Limit:
8 bits. Decremented by each router.
Source VLIB:
16 bytes. The sender's identity block.
Destination VLIB:
16 bytes. The receiver's identity block.

5.2. Extension Headers

Extension headers are TLV-encoded. The following Next Header values are defined:

NH_ORIGIN_SIGNATURE (60):
Origin Signature extension.
NH_EIT (61):
EIT extension.
NH_RATE_LIMIT (62):
Rate-Limit extension.
NH_ROLE_POLICY (63):
Role/Policy extension.
NH_PAYLOAD (59):
Opaque payload (no extension).

Each extension header has the format:

+--------+--------+--------+--------+
|         Extension Length         |  (2 bytes)
+-----------------------------------+
|         Extension Data            |
+-----------------------------------+
|         Next Header               |  (1 byte)
+-----------------------------------+

6. Deployment Considerations

IPv7 is expected to be deployed incrementally. Early deployment models include:

  1. Dual-stack hosts and routers that support IPv7 alongside IPv4/IPv6.
  2. IPv7-in-IPv6 encapsulation for transit across legacy networks.
  3. IPv7-in-IPv4 encapsulation for edge deployments.

The protocol is designed to be backward-compatible at the application layer: applications continue to use existing transport protocols (TCP, UDP, QUIC) over IPv7.

7. Security Considerations

The security of IPv7 depends on the following:

Origin Signature Strength:
ML-DSA-65 provides 128-bit post-quantum security. Public keys are 1952 bytes; signatures are 3309 bytes.
EIT Privacy:
The EIT is an opaque token. Intermediate routers cannot determine the user's identity between sessions.
Replay Protection:
The EIT's TTL limits replay windows. Routers MUST reject expired tokens.
Role Escalation:
The Role/Policy layer is fail-closed when policies are configured. A Guest cannot access Admin resources.
Provider Compromise:
Revocation of a Provider ID causes all packets signed by that provider to be rejected.
Implementation Risks:
The reference implementation uses the ml-dsa Rust crate. Versions before 0.1.0-rc.5 are affected by RUSTSEC-2025-0144, CVE-2026-24850, and GHSA-h37v-hp6w-2pp8. Implementations MUST use ml-dsa >= 0.1.0-rc.5.

8. IANA Considerations

This document has no IANA actions.

Note to RFC Editor: If this document is published as an RFC, the Next Header values (60, 61, 62, 63) may require IANA registration in the "Assigned Internet Protocol Numbers" registry.

9. Normative References

[FIPS204]
National Institute of Standards and Technology, "Module-Lattice-Based Digital Signature Standard", FIPS 204, , <https://csrc.nist.gov/pubs/fips/204/final>.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>.

10. Informative References

[ARKHE-IPV7]
Oliveira, R., "arkhe-ipv7: IPv7 validation library", crates.io arkhe-ipv7, , <https://crates.io/crates/arkhe-ipv7>.
[ARKHE-IPV7-CLI]
Oliveira, R., "arkhe-ipv7-cli: CLI for IPv7 validation", crates.io arkhe-ipv7-cli, , <https://crates.io/crates/arkhe-ipv7-cli>.
[RFC5378]
Bradner, S. and J. Contreras, "Rights Contributors Provide to the IETF Trust", BCP 78, RFC 5378, DOI 10.17487/RFC5378, , <https://www.rfc-editor.org/info/rfc5378>.
[RFC7991]
Hoffman, P., "The "xml2rfc" Version 3 Vocabulary", RFC 7991, DOI 10.17487/RFC7991, , <https://www.rfc-editor.org/info/rfc7991>.
[RUSTSEC-2025-0144]
RustSec Advisory Database, "RUSTSEC-2025-0144: Timing side-channel in ml-dsa", , <https://rustsec.org/advisories/RUSTSEC-2025-0144>.

Author's Address

Rafael Oliveira
Independent