<?xml version="1.0" encoding="UTF-8"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" category="info" docName="draft-oliveira-ipv7-00" submissionType="independent" version="3" sortRefs="true" symRefs="true" tocInclude="true" tocDepth="3">
  <front>
    <title abbrev="IPv7 Identity Protocol">IPv7: Identity-Centric Network Protocol with Verifiable Origin and Rate-Limit Tokens</title>
    <seriesInfo name="Internet-Draft" value="draft-oliveira-ipv7-00"/>
    <author fullname="Rafael Oliveira" initials="R." surname="Oliveira">
      <organization>Independent</organization>
      <address>
        <email>lemestua@hotmail.com</email>
      </address>
    </author>
    <date year="2026" month="9" day="23"/>
    <area>Internet</area>
    <workgroup>Independent Submission</workgroup>
    <abstract>
      <t>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.</t>
    </abstract>
  </front>
  <middle>
    <section numbered="true" toc="default">
      <name>Introduction</name>
      <t>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.</t>
      <t>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.</t>
      <t>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.</t>
      <t>A reference implementation in Rust is available as the arkhe-ipv7 and arkhe-ipv7-cli crates on crates.io.</t>
      <section numbered="true" toc="default">
        <name>Requirements Language</name>
        <t>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 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shown here.</t>
      </section>
    </section>
    <section numbered="true" toc="default">
      <name>Terminology</name>
      <dl>
        <dt>Variable-Length Identity Block (VLIB):</dt>
        <dd>A hierarchical identity string carried in the packet header. Format: EIT/service.location.provider.tenant.role.trustlevel.reputationscope.origin_signature</dd>
        <dt>Ephemeral Identity Token (EIT):</dt>
        <dd>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.</dd>
        <dt>Origin Signature:</dt>
        <dd>A cryptographic signature over the VLIB (excluding the signature field itself), produced by the originating provider's private key.</dd>
        <dt>Source-Provider Validation (SPV):</dt>
        <dd>The process of verifying the Origin Signature against the public key associated with the asserted Provider ID.</dd>
        <dt>Trust Level:</dt>
        <dd>An enumerated value (Low, Medium, High) that represents the current trust assessment of the origin.</dd>
        <dt>Reputation Scope:</dt>
        <dd>An enumerated value (Local, Regional, Global) that indicates the scope within which the origin's reputation is valid.</dd>
        <dt>Role:</dt>
        <dd>An enumerated value (Guest, User, Admin) that represents the asserted privilege level.</dd>
      </dl>
    </section>
    <section numbered="true" toc="default">
      <name>Protocol Architecture</name>
      <section numbered="true" toc="default">
        <name>Variable-Length Identity Block (VLIB)</name>
        <t>The VLIB is the core identity structure of IPv7. It is a hierarchical string with the following canonical format:</t>
        <artwork type="ascii-art"><![CDATA[
EIT/service.location.provider.tenant.role.trustlevel.
reputationscope.origin_signature
        ]]></artwork>
        <t>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.</t>
        <t>The canonical format without the signature contains seven components after the slash. With the signature, there are eight components.</t>
        <t>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.</t>
        <t>Example VLIB:</t>
        <artwork type="ascii-art"><![CDATA[
eit_7f3a9c2b/web.nyc.exampleisp.home.guest.medium.local.
sig_abc123
        ]]></artwork>
      </section>
      <section numbered="true" toc="default">
        <name>Ephemeral Identity Token (EIT)</name>
        <t>The EIT is a time-bound token with the following fields:</t>
        <ul>
          <li>Token: An opaque value generated by the provider.</li>
          <li>Issued At: A Unix timestamp indicating when the token was issued.</li>
          <li>Expires At: A Unix timestamp indicating when the token expires.</li>
          <li>Provider: The Provider ID that issued the token.</li>
          <li>Tenant: The tenant associated with the token.</li>
        </ul>
        <t>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.</t>
        <t>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.</t>
      </section>
      <section numbered="true" toc="default">
        <name>Origin Signature</name>
        <t>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.</t>
        <t>The signature binds the VLIB to the originating provider's public key. A router verifying the signature MUST:</t>
        <ol>
          <li>Look up the public key associated with the asserted Provider ID.</li>
          <li>Reject the packet if the provider is not registered.</li>
          <li>Reject the packet if the provider has been revoked.</li>
          <li>Verify the signature against the canonical VLIB payload.</li>
        </ol>
        <t>If any step fails, the packet MUST be dropped.</t>
      </section>
      <section numbered="true" toc="default">
        <name>Role/Policy Signalling</name>
        <t>The VLIB includes a role field that asserts the privilege level of the origin. The role values are:</t>
        <dl>
          <dt>Guest:</dt>
          <dd>Lowest privilege. Read-only access to public resources.</dd>
          <dt>User:</dt>
          <dd>Read/write access to tenant resources.</dd>
          <dt>Admin:</dt>
          <dd>Management of tenant resources.</dd>
        </dl>
        <t>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.</t>
        <t>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").</t>
      </section>
      <section numbered="true" toc="default">
        <name>Rate-Limit Token (Local Extension)</name>
        <t>The Rate-Limit Token is an optional local extension. It is issued by the ISP and carries:</t>
        <ul>
          <li>Token: An opaque identifier.</li>
          <li>Provider: The issuing provider.</li>
          <li>Packets Per Second: The maximum permitted rate.</li>
          <li>Expires At: A Unix timestamp indicating expiration.</li>
        </ul>
        <t>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).</t>
      </section>
    </section>
    <section numbered="true" toc="default">
      <name>Router Processing Pipeline</name>
      <t>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.</t>
      <section numbered="true" toc="default">
        <name>Layer 1: Origin Verification</name>
        <t>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.</t>
        <t>If the provider is unknown, the packet is quarantined. If the signature is invalid, the packet is dropped.</t>
      </section>
      <section numbered="true" toc="default">
        <name>Layer 2: Identity Verification</name>
        <t>The router validates the EIT:</t>
        <ol>
          <li>The EIT MUST not be expired.</li>
          <li>The EIT's issued_at MUST not be in the future.</li>
          <li>The EIT's token MUST match the VLIB's EIT field.</li>
          <li>The EIT's provider MUST match the VLIB's provider.</li>
          <li>The EIT's tenant MUST match the VLIB's tenant.</li>
        </ol>
        <t>If any check fails, the packet is dropped.</t>
      </section>
      <section numbered="true" toc="default">
        <name>Layer 3: Policy Enforcement</name>
        <t>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.</t>
        <t>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.</t>
        <t>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).</t>
      </section>
    </section>
    <section numbered="true" toc="default">
      <name>Packet Format</name>
      <section numbered="true" toc="default">
        <name>IPv7 Header</name>
        <t>The IPv7 header is 40 bytes, structured as follows:</t>
        <artwork type="ascii-art"><![CDATA[
+--------+--------+--------+--------+
|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               |
+-----------------------------------+
        ]]></artwork>
        <dl>
          <dt>Version:</dt>
          <dd>4 bits. MUST be 7.</dd>
          <dt>Traffic Class:</dt>
          <dd>8 bits.</dd>
          <dt>Flow Label:</dt>
          <dd>20 bits.</dd>
          <dt>Payload Length:</dt>
          <dd>16 bits. Length of the payload in bytes.</dd>
          <dt>Next Header:</dt>
          <dd>8 bits. Identifies the first extension header.</dd>
          <dt>Hop Limit:</dt>
          <dd>8 bits. Decremented by each router.</dd>
          <dt>Source VLIB:</dt>
          <dd>16 bytes. The sender's identity block.</dd>
          <dt>Destination VLIB:</dt>
          <dd>16 bytes. The receiver's identity block.</dd>
        </dl>
      </section>
      <section numbered="true" toc="default">
        <name>Extension Headers</name>
        <t>Extension headers are TLV-encoded. The following Next Header values are defined:</t>
        <dl>
          <dt>NH_ORIGIN_SIGNATURE (60):</dt>
          <dd>Origin Signature extension.</dd>
          <dt>NH_EIT (61):</dt>
          <dd>EIT extension.</dd>
          <dt>NH_RATE_LIMIT (62):</dt>
          <dd>Rate-Limit extension.</dd>
          <dt>NH_ROLE_POLICY (63):</dt>
          <dd>Role/Policy extension.</dd>
          <dt>NH_PAYLOAD (59):</dt>
          <dd>Opaque payload (no extension).</dd>
        </dl>
        <t>Each extension header has the format:</t>
        <artwork type="ascii-art"><![CDATA[
+--------+--------+--------+--------+
|         Extension Length         |  (2 bytes)
+-----------------------------------+
|         Extension Data            |
+-----------------------------------+
|         Next Header               |  (1 byte)
+-----------------------------------+
        ]]></artwork>
      </section>
    </section>
    <section numbered="true" toc="default">
      <name>Deployment Considerations</name>
      <t>IPv7 is expected to be deployed incrementally. Early deployment models include:</t>
      <ol>
        <li>Dual-stack hosts and routers that support IPv7 alongside IPv4/IPv6.</li>
        <li>IPv7-in-IPv6 encapsulation for transit across legacy networks.</li>
        <li>IPv7-in-IPv4 encapsulation for edge deployments.</li>
      </ol>
      <t>The protocol is designed to be backward-compatible at the application layer: applications continue to use existing transport protocols (TCP, UDP, QUIC) over IPv7.</t>
    </section>
    <section numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>The security of IPv7 depends on the following:</t>
      <dl>
        <dt>Origin Signature Strength:</dt>
        <dd>ML-DSA-65 provides 128-bit post-quantum security. Public keys are 1952 bytes; signatures are 3309 bytes.</dd>
        <dt>EIT Privacy:</dt>
        <dd>The EIT is an opaque token. Intermediate routers cannot determine the user's identity between sessions.</dd>
        <dt>Replay Protection:</dt>
        <dd>The EIT's TTL limits replay windows. Routers MUST reject expired tokens.</dd>
        <dt>Role Escalation:</dt>
        <dd>The Role/Policy layer is fail-closed when policies are configured. A Guest cannot access Admin resources.</dd>
        <dt>Provider Compromise:</dt>
        <dd>Revocation of a Provider ID causes all packets signed by that provider to be rejected.</dd>
        <dt>Implementation Risks:</dt>
        <dd>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 &gt;= 0.1.0-rc.5.</dd>
      </dl>
    </section>
    <section numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>This document has no IANA actions.</t>
      <t>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.</t>
    </section>
  </middle>
  <back>
    <references>
      <name>Normative References</name>
      <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119">
        <front>
          <title>Key words for use in RFCs to Indicate Requirement Levels</title>
          <author initials="S." surname="Bradner" fullname="Scott Bradner"/>
          <date year="1997" month="3"/>
        </front>
        <seriesInfo name="BCP" value="14"/>
        <seriesInfo name="RFC" value="2119"/>
        <seriesInfo name="DOI" value="10.17487/RFC2119"/>
      </reference>
      <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174">
        <front>
          <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
          <author initials="B." surname="Leiba" fullname="Barry Leiba"/>
          <date year="2017" month="5"/>
        </front>
        <seriesInfo name="BCP" value="14"/>
        <seriesInfo name="RFC" value="8174"/>
        <seriesInfo name="DOI" value="10.17487/RFC8174"/>
      </reference>
      <reference anchor="FIPS204" target="https://csrc.nist.gov/pubs/fips/204/final">
        <front>
          <title>Module-Lattice-Based Digital Signature Standard</title>
          <author>
            <organization>National Institute of Standards and Technology</organization>
          </author>
          <date year="2024" month="8"/>
        </front>
        <seriesInfo name="FIPS" value="204"/>
      </reference>
    </references>
    <references>
      <name>Informative References</name>
      <reference anchor="RFC5378" target="https://www.rfc-editor.org/info/rfc5378">
        <front>
          <title>Rights Contributors Provide to the IETF Trust</title>
          <author initials="S." surname="Bradner" fullname="Scott Bradner"/>
          <author initials="J." surname="Contreras" fullname="Jorge Contreras"/>
          <date year="2008" month="11"/>
        </front>
        <seriesInfo name="BCP" value="78"/>
        <seriesInfo name="RFC" value="5378"/>
        <seriesInfo name="DOI" value="10.17487/RFC5378"/>
      </reference>
      <reference anchor="RFC7991" target="https://www.rfc-editor.org/info/rfc7991">
        <front>
          <title>The "xml2rfc" Version 3 Vocabulary</title>
          <author initials="P." surname="Hoffman" fullname="Paul Hoffman"/>
          <date year="2016" month="12"/>
        </front>
        <seriesInfo name="RFC" value="7991"/>
        <seriesInfo name="DOI" value="10.17487/RFC7991"/>
      </reference>
      <reference anchor="RUSTSEC-2025-0144" target="https://rustsec.org/advisories/RUSTSEC-2025-0144">
        <front>
          <title>RUSTSEC-2025-0144: Timing side-channel in ml-dsa</title>
          <author>
            <organization>RustSec Advisory Database</organization>
          </author>
          <date year="2025"/>
        </front>
      </reference>
      <reference anchor="ARKHE-IPV7" target="https://crates.io/crates/arkhe-ipv7">
        <front>
          <title>arkhe-ipv7: IPv7 validation library</title>
          <author initials="R." surname="Oliveira" fullname="Rafael Oliveira"/>
          <date year="2026"/>
        </front>
        <seriesInfo name="crates.io" value="arkhe-ipv7"/>
      </reference>
      <reference anchor="ARKHE-IPV7-CLI" target="https://crates.io/crates/arkhe-ipv7-cli">
        <front>
          <title>arkhe-ipv7-cli: CLI for IPv7 validation</title>
          <author initials="R." surname="Oliveira" fullname="Rafael Oliveira"/>
          <date year="2026"/>
        </front>
        <seriesInfo name="crates.io" value="arkhe-ipv7-cli"/>
      </reference>
    </references>
  </back>
</rfc>