Network Working Group L. Gebauer Internet-Draft Independent Intended status: Informational 24 June 2026 Expires: 26 December 2026 Internet Agent Communication Protocol draft-gebauer-iacp-00 Abstract Ever since 1969 and the ARPANET, the internet has repeatedly been faced with challenges that it has had to overcome. With the advent of autonomous AI agents, a new communication paradigm is required. The Internet Agent Communication Protocol (IACP) defines a complete architecture for secure, identity-centric agent-to-agent communication, including identity-locator separation, a Deterministic Hypermedia Interpreter (DHI), the EID Routing Protocol (ERP), Persistent State Sessions (PSS), and decentralized governance mechanisms. 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 26 December 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 Gebauer Expires 26 December 2026 [Page 1] Internet-Draft IACP June 2026 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 . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Motivation and Problem Statement . . . . . . . . . . . . 4 1.2. Design Goals . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Scope and Non-Goals . . . . . . . . . . . . . . . . . . . 5 1.4. Document Structure . . . . . . . . . . . . . . . . . . . 5 2. Terminology and Conventions . . . . . . . . . . . . . . . . . 5 2.1. Key Definitions . . . . . . . . . . . . . . . . . . . . . 5 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 6 3. Ephemeral Agent Identity (EID) . . . . . . . . . . . . . . . 6 3.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2. EID Generation and Properties . . . . . . . . . . . . . . 7 3.3. Identity-Locator Separation Principles . . . . . . . . . 8 3.4. EID Persistence and Rotation Rules . . . . . . . . . . . 8 3.5. Forwarding Tickets and DHT-based Asynchronous Resolution . . . . . . . . . . . . . . . . . . . . . . . 9 3.6. EID Reputation and Cryptographic Ledger Attestation . . . 10 3.6.1. Cryptographic Attestation and Metrics . . . . . . . . 11 3.6.2. Threshold Enforcement and Session Downgrade . . . . . 11 4. Deterministic Hypermedia Interpreter (DHI) . . . . . . . . . 11 4.1. DHI General . . . . . . . . . . . . . . . . . . . . . . . 11 4.1.1. Execution Environment and UI Abstraction . . . . . . 12 4.1.2. The Agent Parser Ingestion Pipeline . . . . . . . . . 12 4.1.3. Resource Retrieval via Algorithmic Extraction (HRP & APE) . . . . . . . . . . . . . . . . . . . . . . . . 16 4.1.4. Content Equivalence and Legacy Hand-off Invariants . 18 4.1.5. Separation of Concerns between DHI and Agents . . . . 20 4.2. EID Routing Protocol (ERP) - Subprotocol . . . . . . . . 22 4.2.1. Protocol Entities and Abstraction Layerr . . . . . . 22 4.2.2. Session Cryptography and Isolation Mechanics . . . . 23 4.2.3. Protocol Operations . . . . . . . . . . . . . . . . . 24 4.2.4. Secure Handshake and Connection Management . . . . . 28 4.2.5. Resource Governance . . . . . . . . . . . . . . . . . 29 4.2.6. Fault Tolerance, Resiliency, and Degraded Operations . . . . . . . . . . . . . . . . . . . . . 31 4.2.7. Decentralized Security Governance and Slashing . . . 33 5. DHT Namespace Architecture and Distributed Security . . . . . 35 5.1. Distributed Hash Table . . . . . . . . . . . . . . . . . 35 5.1.1. General . . . . . . . . . . . . . . . . . . . . . . . 36 5.1.2. DHT Namespace Structure . . . . . . . . . . . . . . . 36 5.2. Namespace Registration and Curation . . . . . . . . . . . 36 5.2.1. Root Namespace Registration . . . . . . . . . . . . . 36 5.2.2. Sub-Namespace Delegation . . . . . . . . . . . . . . 37 Gebauer Expires 26 December 2026 [Page 2] Internet-Draft IACP June 2026 5.3. Proof-of-Work and Reputation-Based Access Control . . . . 37 5.3.1. Dynamic PoW Difficulty . . . . . . . . . . . . . . . 38 5.3.2. Access Tickets and Joint Liability . . . . . . . . . 38 5.4. Anti-Abuse Mechanisms . . . . . . . . . . . . . . . . . . 38 5.4.1. Token-Bucket Filters and Rate Limiting . . . . . . . 39 5.4.2. Autonomous Circuit Breakers . . . . . . . . . . . . . 39 5.5. Proof of Malfeasance (PoM) and Slashing . . . . . . . . . 39 5.5.1. PoM Ticket Specification . . . . . . . . . . . . . . 39 5.5.2. Two-Phase Slashing Escrow (2PSE) . . . . . . . . . . 40 5.5.3. Curator Quarantine and Decapitation . . . . . . . . . 41 5.6. Compromise Recovery and Hot-Docking . . . . . . . . . . . 41 6. Agent to Agent Communication . . . . . . . . . . . . . . . . 42 6.1. Ephemeral State Endpoints (ESE) . . . . . . . . . . . . . 42 6.1.1. General . . . . . . . . . . . . . . . . . . . . . . . 42 6.1.2. Local Points (LP) . . . . . . . . . . . . . . . . . . 42 6.1.3. Global Points (GP) . . . . . . . . . . . . . . . . . 42 6.2. Discovery Spaces (DS) . . . . . . . . . . . . . . . . . . 43 6.3. Anonymous Discovery Mechanism . . . . . . . . . . . . . . 43 6.3.1. Discovery Request with Proof-of-Work and Ephemeral Keys (DISCOVERY_REQ) . . . . . . . . . . . . . . . . . . . 43 6.3.2. Discovery Response and Secure EID Exchange (DISCOVERY_RES) . . . . . . . . . . . . . . . . . . . 43 6.4. Persistent State Sessions (PSS) . . . . . . . . . . . . . 43 6.4.1. General . . . . . . . . . . . . . . . . . . . . . . . 43 6.4.2. PSS Lifecycle and Handshake . . . . . . . . . . . . . 44 6.4.3. Dual-Cookie Handshake (PSS_INIT / PSS_NEG / PSS_ACK) . . . . . . . . . . . . . . . . . . . . . . 44 6.4.4. Session Federation Contract (SFC) . . . . . . . . . . 45 6.4.5. Data Streaming and Sequence Vector Reconciliation (PSS_DATA_STREAM) . . . . . . . . . . . . . . . . . . 45 6.5. Session Termination and Revocation . . . . . . . . . . . 45 6.5.1. Graceful Teardown (PSS_TEARDOWN) . . . . . . . . . . 45 6.5.2. Revocation and Proof of Malfeasance Publishing (PSS_REVOCATION_PUBLISH) . . . . . . . . . . . . . . 45 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46 7.1. IACP Message Type Registry . . . . . . . . . . . . . . . 46 7.2. IACP TLV Registry . . . . . . . . . . . . . . . . . . . . 47 7.3. IACP Flags Registry . . . . . . . . . . . . . . . . . . . 47 7.4. IACP Outer Transport Header Types . . . . . . . . . . . . 47 8. Security Considerations . . . . . . . . . . . . . . . . . . . 47 8.1. Identity and Authentication . . . . . . . . . . . . . . . 47 8.2. Confidentiality and Integrity . . . . . . . . . . . . . . 48 8.3. Denial-of-Service and Resource Exhaustion . . . . . . . . 48 8.4. Namespace and Curation Security . . . . . . . . . . . . . 48 8.5. Mobility, Churn, and Forwarding Tokens . . . . . . . . . 49 8.6. Privacy Considerations . . . . . . . . . . . . . . . . . 49 8.7. Residual Risks and Recommendations . . . . . . . . . . . 49 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 50 Gebauer Expires 26 December 2026 [Page 3] Internet-Draft IACP June 2026 9.1. Normative References . . . . . . . . . . . . . . . . . . 50 9.2. Informative References . . . . . . . . . . . . . . . . . 50 Appendix A. Appendix A: Wire Formats of the IACP . . . . . . . . 51 Appendix B. Appendix B: State Machines and Transition Diagrams of the IACP . . . . . . . . . . . . . . . . . . . . . . . . 63 Appendix C. Appendix C: ASCII-Diagrams of the IACP . . . . . . . 68 Appendix D. Acknowledgments . . . . . . . . . . . . . . . . . . 68 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 68 1. Introduction 1.1. Motivation and Problem Statement Traditional Internet protocols and applications are designed for human users interacting via visual browsers. With the rapid growth of autonomous AI agents, the majority of future network participants will be non-human, deterministic systems requiring native, cryptographically secure, and identity-centric communication primitives. Existing protocols lack strict identity-locator separation, deterministic content interpretation, secure host isolation, and decentralized governance suitable for agent-to-agent interaction at scale. 1.2. Design Goals The Internet Agent Communication Protocol (IACP) is designed to: * Provide strict Ephemeral Agent Identity (EID) with identity- locator separation using Ed25519 cryptography. * Enable secure host isolation through the Local Loopback Layer Entity (LL-Entity) and Instance Authentication Token (IAT). * Deliver deterministic content processing via the Deterministic Hypermedia Interpreter (DHI) with mathematical equivalence guarantees (EVM <= 0.001). * Support reliable agent-to-agent communication through Persistent State Sessions (PSS) with Dual-Cookie handshake and optional Session Federation Contracts (SFC). * Establish decentralized namespace governance using a DHT with Proof-of-Work curation, Proof of Malfeasance (PoM), and Two-Phase Slashing Escrow (2PSE). * Ensure mobility, fault tolerance, and security under churn via generation counting, MIGRATION_VECTOR, and degraded multi-path routing. Gebauer Expires 26 December 2026 [Page 4] Internet-Draft IACP June 2026 1.3. Scope and Non-Goals This document defines the overall IACP architecture (e.g. the EID Routing Protocol (ERP), DHI pipeline and state machines, wire formats, PSS lifecycle, DHT namespace mechanics, and core security model). Out of scope are: concrete DHT implementation details, specific ANML schema definition, lower-layer transport (QUIC usage is RECOMMENDED but not mandated), and application-layer LLM semantics. 1.4. Document Structure Section 2 defines terminology and conventions. Section 3 describes the Core Architecture. Section 4 specifies the EID Routing Protocol (ERP). Section 5 covers Decentralized Security Governance. Section 6 details Discovery and Agent-to-Agent Communication. Section 7 contains Security Considerations. Section 8 lists IANA considerations. The Appendices provide wire-format diagrams and state machines. 2. Terminology and Conventions 2.1. Key Definitions * *AAI* - Autonomous Agent Instance: Application-layer logic executing autonomously and communicating via PSS. * *EID* - Ephemeral Agent Identity: 32-byte cryptographic identifier. Generated as Truncate_to_160Bit(SHA256(Ed25519 Public Key)). * *LL-Entity* - Local Loopback Layer Entity: Host-local shim between AAI and network. Manages EID allocation, IAT validation, encapsulation, and isolation. * *IAT* - Instance Authentication Token: 32-byte high-entropy token generated by LL-Entity for local AAI authentication. * *DHI* - Deterministic Hypermedia Interpreter: Native agent runtime. Performs ingestion pipeline, content equivalence verification, and hands off to downstream LLM core. * *ANML* - Agentic Network Markup Language: Structured markup for deterministic agent-native content processing. Gebauer Expires 26 December 2026 [Page 5] Internet-Draft IACP June 2026 * *PSS* - Persistent State Session: Long-lived secure channel between two EIDs, using Dual-Cookie handshake and optional SFC. * *ESE* - Ephemeral State Endpoint: Information block hosted under an EID (Local Point or Global Point). * *ERP* - EID Routing Protocol: Control protocol for local initialization, DHT mapping, mobility, and session management. * *SFC* - Session Federation Contract: Optional agreement granting direct ESE access between PSS peers. * *DHT* - Distributed Hash Table: Global decentralized directory for EID-to-locator mappings and namespace governance. * *PoM* - Proof of Malfeasance: Cryptographic evidence of equivocation or protocol violation. * *2PSE* - Two-Phase Slashing Escrow: Challenge window before stake slashing. * *USIV* - Unified Semantic Ingestion Vector: {Source_EID, Target_URI, Payload_Byte_Length, Payload_Pointer} passed across IIB. * *HCO* - Hand-off Context Object: Serialized structure for legacy browser fallback containing ESD-EID. * *ESD-EID* - Ephemeral Session Derivative EID: Temporary derivative of EID used for sandboxed legacy execution. 2.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 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Ephemeral Agent Identity (EID) Gebauer Expires 26 December 2026 [Page 6] Internet-Draft IACP June 2026 3.1. General To interact with the underlying network infrastructure, the Internet Agent Communication Protocol (IACP) enforces a strict identity- locator separation based on the core architectural principles of the Host Identity Protocol (HIP, RFC 7401). Traditional internet architectures conflate identity and location within a single IP address layer, creating significant vulnerabilities and inefficiencies for autonomous multi-agent workflows. IACP addresses this structural flaw by decoupling an agent's persistent logical identity from its volatile physical routing state. An agent utilizes its current, transient IP address solely as an ephemeral transport locator. This locator is bound via cryptographic primitives to a unique, self-certifying pseudonym known as the Ephemeral Agent Identity (EID). +------------------------------------------------------------------+ | Application / LLM Context | +------------------------------------------------------------------+ | v +------------------------------------------------------------------+ | Ephemeral Agent Identity (EID) Layer | | [Cryptographic permanence / Stable Identity] | +------------------------------------------------------------------+ | v +------------------------------------------------------------------+ | Transport Locator Layer | | [Volatile IP Routing State / Dynamic Topology] | +------------------------------------------------------------------+ While transport locators shift dynamically with network topology and routing handovers, the EID operates as a long-lived logical identifier. This structural separation abstracts network-level transitions away from the application state. Every active agent maintains an operational EID that is temporarily mapped to its host IP address, providing continuous access to the global network, Ephemeral State Endpoints (ESEs), and Persistent State Sessions (PSS). 3.2. EID Generation and Properties The Ephemeral Agent Identity (EID) is structured as a self-certifying cryptographic identifier. It consists of a 32-byte public key derived from an asymmetric keypair, specifically optimized using the Ed25519 signature scheme for identity validation. Gebauer Expires 26 December 2026 [Page 7] Internet-Draft IACP June 2026 EID Cryptographic Properties: * Mathematical Decoupling: The EID contains no routing metadata, geographic indicators, or topological constraints. It is bound to network locators via authenticated, dynamic mappings. * Verification Permanence: Any active peer can verify the authenticity of protocol control packets by validating the attached Ed25519 signature directly against the initiating EID. * Integrity Vectors: The EID serves as the unique index key for tracking distributed reputation matrices within the shared network ledger, binding behavioral history directly to the identity. 3.3. Identity-Locator Separation Principles The protocol operates a clean layer split where transport-layer stream multiplexing and sequence verification are handled inside the cryptographic umbrella of the EID, while IP routing tables process the transport locators. This ensures that network anonymity is preserved without sacrificing session stability. +-----------------------+ +-----------------------+ | Initiator (Alice) | | Responder (Bob) | | Stable Identity: EID | | Stable Identity: EID | +-----------------------+ +-----------------------+ | | ================== IDENTITY-LOCATOR SEPARATION ================== | | +-----------------------+ +-----------------------+ | Transport Locator (IP)| | Transport Locator (IP)| | [Volatile Routing] | | [Volatile Routing] | +-----------------------+ +-----------------------+ When an agent alters its physical connection point or moves across network bounds, the upper session layer remains completely unaware of the physical interface change. By absorbing routing transitions within the decoupled identity layer, ongoing computations, resource extraction pipelines, and active state allocations remain uninterrupted. 3.4. EID Persistence and Rotation Rules To prevent longitudinal tracking and mitigate profiling risks across the public routing topology, EID ephemerality is strictly bounded. However, to maintain session stability, the EID remains persistent across simple network handovers. EID rotation is explicitly restricted and only triggered under the following three conditions: 1. Administrative Instruction: Upon an explicit administrative directive issued by the managing user or parent orchestration system. Gebauer Expires 26 December 2026 [Page 8] Internet-Draft IACP June 2026 2. Cryptographic Compromise: Immediately following a detected security anomaly, private key exfiltration, or cryptographic compromise. 3. Context Termination: Upon the successful completion or termination of a designated operational task, autonomous session, or Persistent State Session (PSS) context. If an agent changes its network locator due to a simple routing transition (such as migrating from Wi-Fi to mobile data networks), identity persistence is managed directly between active peers. The agent transmits a Signed Binding Update containing the new IP mapping directly to its active communication partners. This optimization keeps the EID stable during short-term handovers, preventing session drops without requiring a full identity renegotiation or public registration update. To prevent malicious entities from utilizing rapid identity rotation to evade accountability, EID ephemerality is bounded by a distributed reputation architecture. Protocol deviations-such as unverified session terminations or state invalidations-are signed and indexed against the initiating EID within a decentralized substrate. Rational nodes execute pre-flight validation of a target EID's integrity vector before allocating state bounds or initializing transitions. 3.5. Forwarding Tickets and DHT-based Asynchronous Resolution Because direct binding updates require both endpoints to be concurrently online, the architecture utilizes a decentralized Distributed Hash Table (DHT) substrate (structured via Kademlia's XOR metric) to resolve asynchronous identity-location decoupling. This addresses real-world network constraints where nodes frequently cycle offline or undergo asymmetric routing handovers. Before an agent rotates its network parameters or enters an extended offline state, it generates a cryptographic Forwarding Ticket. This ticket contains the agent's updated routing metadata, is signed via the Ed25519 secret key associated with the active EID, and is deposited at the agent's last known coordinate within the DHT. The precise routing coordinate within the DHT substrate is derived deterministically via: KEY = SHA-256(EID_AGENT) The storage transaction uses the DHT_TICKET_STORE format (Type 0x05). The payload contains the Target Storage Key, the target agent's true EID, a 4-byte Time-to-Live (TTL) field, a 12-byte AEAD Nonce, 36 Gebauer Expires 26 December 2026 [Page 9] Internet-Draft IACP June 2026 bytes of Encrypted Forwarding Data (protected via the shared secret key established during the active Persistent State Session), and an authoritative 64-byte Ed25519 digital signature generated by the owner. When a peer wakes up or reconnects after an extended offline period, it queries the DHT at the historical coordinate of the targeted agent by dispatching a DHT_TICKET_QUERY packet (Type 0x06). The querying node populates the target key field, attaches an 8-byte Transaction ID, and logs its own EID. The responding DHT node returns a DHT_TICKET_RESP packet (Type 0x07) containing matching transaction metadata, a 4-byte Status Code, and the encrypted ticket payload. Upon retrieval, the querying peer decrypts the Forwarding Ticket using the pre-established shared session key. This structural lookup reveals the targeted agent's updated network locator and current routing parameters. The communication channel is subsequently restored via a sequential state synchronization routine utilizing sequence state vector reconciliation, ensuring complete state continuity without corruption. +--------------------------+ | [0x05] DHT_TICKET_STORE | +--------------------------+ | v (Agent Goes Offline / Rotates Locator Parameters) +--------------------------+ | [0x06] DHT_TICKET_QUERY | +--------------------------+ | v (DHT Fabric Processes XOR Routing Metrics) +--------------------------+ | [0x07] DHT_TICKET_RESP | +--------------------------+ 3.6. EID Reputation and Cryptographic Ledger Attestation EID is bound to a dynamic, non-repudiable transaction reputation metric managed within the distributed directory overlay layer. Because EIDs are decoupled from the network transport locators (IP addresses), reputation tracking is executed directly against the 256-bit EID public key coordinate. This prevents malicious instances from shedding negative operational history through transport interface rotation or routing hop modification. Gebauer Expires 26 December 2026 [Page 10] Internet-Draft IACP June 2026 3.6.1. Cryptographic Attestation and Metrics The local host interface or tracking nodes maintain an immutable, signed validation log. Reputation states are computed as a composite function of sequence compliance, processing availability, and validation history: R_State = Function(S_Verify || A_Telemetry || PoM_Tickets) Where: * S_Verify constitutes the ratio of cryptographically valid signatures on critical control frames (PSS_INIT, PSS_ACK). * A_Telemetry dictates the verified processing availability index under active Session Federation Contracts (SFC). * PoM_Tickets represents the accumulation index of validated Proof of Malfeasance tickets transmitted to the global directory layer. 3.6.2. Threshold Enforcement and Session Downgrade Peering nodes evaluating a connection initialization vector (PSS_INIT) MUST query the target EID's current reputation coordinate inside the directory keyspace before moving from STATE_HEARING to STATE_ESTABLISHED. If the reputation metric falls below a pre-configured local threshold, the incoming packet ingestion layer MUST enforce one of the following deterministic circuit-breaker states: 1. *Dynamic PoW Escalation:* The host interface increases the required zero- allocation Hashcash Proof-of-Work trailing-zero bit length exponentially for the target entity. 2. *Channel Micro-Throttling:* The local engine restricts bandwidth and token-bucket allocation values via hardcoded execution shims, forcing a degraded multi-path transport pipeline. 3. *Immediat Block and Slashing Routing:* Upon detection of an unexpired curator quarantine flag or active 2PSE ticket reference, the protocol runtime drops the packet without volatile memory allocation and propagates an immediate blacklisting broadcast across the network topology. 4. Deterministic Hypermedia Interpreter (DHI) 4.1. DHI General Gebauer Expires 26 December 2026 [Page 11] Internet-Draft IACP June 2026 4.1.1. Execution Environment and UI Abstraction The Deterministic Hypermedia Interpreter (DHI) executes all processing, resource extraction, and cross-agent operations. It serves as the native runtime for ESE hosting, PSS state management, and data queries. The DHI delegates all name resolution and transport endpoint discovery to the Local Loopback Layer Entity (LL- Entity) defined in the EID Routing Protocol (ERP). It omits traditional visual user interfaces and uses a structured agent- optimized Search Tree instead. The DHI maintains strict content equivalence with human-centric web payloads. It maps identical content into an abstract representation without data loss. Documents using Agentic Network Markup Language (ANML) are processed natively. Functional requests that cannot be translated into pure informational states are handed off to a conventional browser environment. 4.1.2. The Agent Parser Ingestion Pipeline When an Autonomous Agent Instance (AAI) receives a legacy alphanumeric domain name or URI, the DHI forwards the resolution request to the local LL-Entity. The LL-Entity performs EID resolution or transport locator mapping, using the ANML Fallback Query (Type 0x12) if no direct mapping exists. The Agent Parser then operates as a deterministic finite state machine (FSM) and enforces the following sequential execution pipeline: 4.1.2.1. State Machine Transitions and Pipeline Execution The ingestion pipeline MUST proceed according to the following state machine and transitional logic: Gebauer Expires 26 December 2026 [Page 12] Internet-Draft IACP June 2026 +-----------------------+ +------------------------+ | INIT / INPUT URI | --> | [1] DNS_SRV_EVALUATION| +-----------------------+ +------------------------+ | v +-----------------------+ | [2] WELL_KNOWN_EVAL | +-----------------------+ | +-----------------------+-------------+ | (If Unreachable) | (If Unreachable) (If Reachable) v v +-----------------------+ +-----------------------+ | [2.1] PROBLEM_CACHE | | [3] LINK_HEADER_SNIFF| +-----------------------+ +-----------------------+ | | (TERM_EXECUTION) v +-----------------------+ | [4] BASELINE_CORE | +-----------------------+ | v +-----------------------+ | [4.1] SWITCH_POINT | +-----------------------+ [1] DNS_SRV_EVALUATION: Initiates a DNS SRV query to discover agent- native endpoints and configuration parameters. [2] WELL_KNOWN_EVAL: Issues a request to /.well-known/anml. [2.1] PROBLEM_CACHE: On unreachable endpoint, HTTP 404 or timeout, logs the fault, creates a temporary block record with 300s TTL, and terminates execution. [3] LINK_HEADER_SNIFF: Scans response headers for RFC 8288 Link entries pointing to ANML resources. [4] BASELINE_CORE: Aggregates discovery data and passes context to the SWITCH_POINT. [4.1] SWITCH_POINT: Non-terminal state that evaluates whether to follow the NATIVE_ANML_PATH or LEGACY_PATH_EXECUTION. Conforming implementations MUST enforce the following constraints: a. Socket poll timeout: T_eval = 15000 ms in non-blocking mode. Gebauer Expires 26 December 2026 [Page 13] Internet-Draft IACP June 2026 b. Maximum floating buffer: MAX_FLOAT_BUF = 4194304 bytes. Inbound data MUST be accumulated sequentially in a volatile local FIFO buffer. c. If structural context resolves before T_eval expires and MAX_FLOAT_BUF is not exceeded, transition immediately to NATIVE_ANML_PATH [4.3]. d. On T_eval expiry or buffer overflow, immediately truncate the buffer, terminate the fast-path stream, and transition to LEGACY_PATH_EXECUTION [4.2] or PROBLEM_CACHE. 4.1.2.2. The Switch Point Logical Invariants The state SWITCH_POINT [4.1] represents the critical architectural boundary where the communication stream is fork-routed based on two mutually exclusive parameters: the presence of ANML metadata and the active operational constraints of the calling agent. +--------------+ | SWITCH_POINT | +--------------+ | +-----------------------+---------------------+ | | (ANML Found) (ANML Absent) v v +---------------------+ +--------------------+ |[5] USER_REQ_CHECK | | [4.2] LEGACY_PATH | +---------------------+ +--------------------+ | | +------+------+ | | | | (Rich Assets) (Text Only) | v v v +-----------+ +-----------+ (Browser Hand-off) | [4.2] LGC | | [4.3] NAM | | +-----------+ +-----------+ v | | (TERM_FAST_PATH) +------+------+ | v +---------------------+ | [6] DOWNSTREAM_SUB | +---------------------+ Gebauer Expires 26 December 2026 [Page 14] Internet-Draft IACP June 2026 A. ANML Non-Existence Path: If no valid ANML endpoints, pointers, or metadata tags are detected during states [2] or [3], the FSM MUST execute a transitional branch to LEGACY_PATH_EXECUTION [4.2]. The parser triggers the standard web fallback mechanism, initiates heavy media layout rendering via a headless DOM engine, and hands over context to a sandboxed browser environment. Native fast-path parsing is instantly terminated. B. ANML Existence Path: If valid ANML infrastructure is found, the FSM transitions directly to the USER_REQUIREMENT_CHECK [5]. This sub-state evaluates explicit runtime constraints and asset criteria passed by the client agent concerning non-text-based payload components (e.g., raster images, audio, video vectors). i. If rich-media or layout asset dependencies are explicitly required by the user constraints, the machine drops the fast-path and triggers LEGACY_PATH_EXECUTION [4.2] to guarantee complete content availability. ii. If the user constraint matrix allows text-only/semantic-only extraction, or if no rich assets are requested, the machine transitions to NATIVE_ANML_PATH_INGESTION [4.3]. The engine initiates a direct, machine-first stream of the raw markup, completely bypassing visual layout, Cascading Style Sheets (CSS), and human-centric JavaScript rendering engines. Execution paths converging from native ingestion or fallback processing MUST deliver their finalized object payloads to the DOWNSTREAM_PROCESSING_SUBSYSTEMS [6] to drive HRP, APE, and active LLM core workflows. 4.1.2.3. Protocol Specification for Problem Caching Cycles To prevent distributed denial-of-service (DDoS) loops and mitigate computational overhead induced by repetitive agentic polling of broken endpoints, implementations MUST conform to the strict fault- handling requirements of the PROBLEM_CACHE [2.1] state: 1. Fault Isolation: When an ANML discovery error occurs, the localruntime environment MUST encapsulate the network fault layer fromthe executing agent logic. 2. TTL Enforcement: The fault record logged by the Problem CachingCycle MUST specify a minimum Time-To-Live (TTL) value of 300seconds. During this active window, any subsequent outboundingestion requests from the same host to the failing target URIMUST be short-circuited locally at the parser layer. Gebauer Expires 26 December 2026 [Page 15] Internet-Draft IACP June 2026 3. State Clearance: Upon expiration of the local fault TTL record,the parser MUST transition back to an unblocked state, allowinga single sequential pipe verification attempt on the next targetinvocation. 4.1.3. Resource Retrieval via Algorithmic Extraction (HRP & APE) To maximize data harvesting efficiency and minimize transport layer overhead, resource discovery within the DHI Search Tree MUST rely on the concurrent execution of two deterministic architectural subsystems: Heuristic Relevancy Probability (HRP) and Automated Pipeline Extraction (APE). +---------------------------------+ | DHI Search Tree Target Nodes | +---------------------------------+ | v +---------------------------------+ | [2.3.1] HRP Matrix Evaluation | | HRP(n) = w1*S + w2*R + w3*C | +---------------------------------+ | v +---------------------------------+ | [2.3.2] APE Filter Mechanism | | Is HRP(n) >= Theta? | +---------------------------------+ | +-------------------+-------------------+ | (Yes) | (No) v v +------------------------------+ +---------------------------+ | [2.3.3] Parallel Execution | | Prune / Drop Node Stream | | Fast Path / Queue Priority | | (Zero Network Traffic) | +------------------------------+ +---------------------------+ 4.1.3.1. Heuristic Relevancy Probability (HRP) Every target node (n) or Uniform Resource Identifier (URI) within the active discovery search space is algorithmically assigned a dynamic, scalar probability value HRP(n) bounded by the interval [0.0, 1.0]. This value represents the statistical likelihood that the designated resource node contains the precise target payload requested by the calling agent. Gebauer Expires 26 December 2026 [Page 16] Internet-Draft IACP June 2026 Implementations MUST calculate HRP(n) continuously via localized execution engines natively embedded within the DHI execution layer, conforming to the following weighted vector equation: HRP(n) = (w1 * S(A, Tn)) + (w2 * R(En)) + (w3 * C(Hn)) The formal invariants of the calculation matrix are defined as: 1. Semantic Similarity Vector S(A, Tn): The mathematical cosinesimilarity calculated within the latent embedding space betweenthe agent's operational request vector (A) and the extractedmetadata token or anchor text vector (Tn) of the target node. 2. Reputation Weight R(En): A scalar value derived from thecryptographic verification of curator assertions recorded withinthe distributed hash table (DHT) namespace layer. 3. Contextual History C(Hn): A historical convergence metrictracking the agent's prior retrieval success rates acrossidentical URI sub-paths and structural path patterns. 4. Weight Vector Normalization: The system-defined weights (w1, w2,w3) are configuration-specific invariants and MUST satisfy thenormalization constraint: w1 + w2 + w3 = 1.0. 4.1.3.2. Automated Pipeline Extraction (APE) The APE engine acts as the deterministic execution arm of the DHI, ingesting the compiled HRP matrix to orchestrate parallelized network transport traversals. 1. Threshold Filtering: The APE engine MUST enforce a dynamicthreshold variable Designated as Theta (O). If a target nodeevaluates to a metric where HRP(n) < O, the engine MUST prunethe node from the active traversal path, suppressing outboundnetwork socket allocation for that node. 2. Parallel Socket Allocation: For nodes satisfying HRP(n) >= O, theAPE engine maps execution priority directly to the scalar HRPweight: a. Fast Path Ingestion: Nodes displaying an HRP(n) metric above a high-probability boundary (HRP(n) >= 0.85) MUST be allocated immediate, dedicated streaming TCP/IACP connections. b. Asynchronous Queue: Nodes displaying mid-range probabilities (O <= HRP(n) < 0.85) MUST be buffered within a prioritized asynchronous download queue, executed concurrently based on available system bandwidth. Gebauer Expires 26 December 2026 [Page 17] Internet-Draft IACP June 2026 1. Path Optimization: When multi-hop graph traversal within theAgentNet topology is required, the APE engine MUST compute themathematically optimal extraction path by executing a directedacyclic graph (DAG) search algorithm, utilizing the inverse ofthe HRP(n) value as the primary edge-cost function. 4.1.4. Content Equivalence and Legacy Hand-off Invariants 4.1.4.1. Mathematical Equivalence Metrics To verify structural and content parity during state transformation, the runtime MUST evaluate the Equivalence Verification Metric (EVM). The mathematical evaluation process is defined as follows: 1. Entropy Delta Calculation: The runtime MUST compute the absolutedifference in Shannon entropy between the legacy DOM structureand the compiled abstract search tree representation: EVM = | H_web - H_tree | Conforming states MUST satisfy the condition EVM <= 0.001. 1. Cryptographic Invariant Validation: To prevent semantic damagevia lexical permutation or omission, the runtime MUST compute aSHA-256 hash comparison. This comparison MUST NOT be executedon raw document source code or abstract tree topology blocks. 2. Canonical Node Ingestion: The SHA-256 hashing algorithm MUSToperate exclusively on a linearized buffer composed of theextracted and canonicalized pure text nodes. These nodes MUSTbe ingested sequentially in an identical, deterministicdocument traversal order (depth-first, left-to- right). 3. Parity Invalidation: If the computed SHA-256 signatures of thetwo canonical text sequences display any divergence, the stateequivalence evaluation MUST fail instantly, forcing a hardtransition to the LEGACY_PATH_EXECUTION [4.2] fallback. 4.1.4.2. Interface Specification for Legacy Path Hand-off Context When the SWITCH_POINT [4.1] or USER_REQUIREMENT_CHECK [5] drops the fast-path due to missing ANML infrastructure or explicit rich-media asset requirements, the DHI MUST compile and serialize a standardized Hand-off Context Object (HCO). The HCO is transmitted across the functional boundary to the sandboxed legacy browser engine. Gebauer Expires 26 December 2026 [Page 18] Internet-Draft IACP June 2026 +---------------------------------------+ | DHI Local Ingestion Fast-Path Layer | +---------------------------------------+ | (Trigger: Legacy Fallback) | v +---------------------------------------+ | [2.4.3] Serialization of Hand-off | | Context Object (HCO Payload) | +---------------------------------------+ | +--------------------+--------------------+ | | [Byte 0-31]: Active EID [Byte 32-63]: Session Hash | | [Byte 64-67]: Sequence [Byte 68-71]: Capabilities | | +--------------------+--------------------+ | v +---------------------------------------+ | Sandboxed Legacy Browser Container | +---------------------------------------+ 4.1.4.3. HCO Wire-Level Structural Layout The serialized HCO binary block MUST conform to the following layout: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hand-off Trigger Context Type (2 Bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Ephemeral Session Derivative EID (ESD-EID) | | [32 Bytes] | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Persistent State Session Hash | | [32 Bytes] | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Target URL Length (2B) | Target URL String (UTF-8)... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Gebauer Expires 26 December 2026 [Page 19] Internet-Draft IACP June 2026 A. Hand-off Trigger Context Type (2 Bytes): Unsigned integer identifying the execution failure or unmappable state that triggered the legacy hand-off. B. Ephemeral Session Derivative EID (ESD-EID) (32 Bytes): Temporary cryptographic token generated by the LL-Entity for this session only. It is derived from the permanent EID combined with a session nonce. The real long-lived EID MUST NOT be exposed to the sandbox. The LL- Entity MUST intercept and validate this derivative on return. C. Persistent State Session Hash (32 Bytes): Cryptographic digest of the active session context. D. Target URL Length (2 Bytes): Length of the following UTF-8 string. E. Target URL String: Variable-length UTF-8 destination resource. The sandboxed legacy browser MUST use only the ESD-EID for any outbound network activity. All such traffic is routed back through the LL-Entity for validation. 4.1.5. Separation of Concerns between DHI and Agents To preserve decoupling across the architectural stack, implementations MUST enforce a separation between the DHI and downstream application layers (e.g., Large Language Model core workflows). +-------------------------------------------------+ | Deterministic Hypermedia Interpreter (DHI) | +-------------------------------------------------+ | (Executes Pipeline [1] to [5]) | v +-------------------------------------------------+ | [2.5.1] The Ingestion Interface Boundary (IIB) | | Validates, Canonicalizes & Buffers | +-------------------------------------------------+ | (Unified Semantic Ingestion Vector) | v +-------------------------------------------------+ | Downstream LLM Core / Schema Processing | +-------------------------------------------------+ Gebauer Expires 26 December 2026 [Page 20] Internet-Draft IACP June 2026 4.1.5.1. The Ingestion Interface Boundary (IIB) The DHI framework terminates structurally at the Ingestion Interface Boundary (IIB). The responsibilities of the IACP layer within this boundary are strictly limited to the following operational tasks: 1. Transport Termination: Managing network sockets, executing pathdiscovery, processing Link headers, and enforcing HRP/ APEalgorithms. 2. Payload Canonicalization: Stripping transport headers, resolvingmulti-hop DAG data fragments, and assembling raw incoming streamsinto a unified, sequential memory buffer. 3. Structure Validation: Verifying that incoming data objects matcheither the native ANML specification invariants or the fallbacklegacy tree representation before state delivery. 4.1.5.2. Unified Semantic Ingestion Vector (USIV) Data transition across the IIB into the application layer MUST occur exclusively via the standardized Unified Semantic Ingestion Vector (USIV). The DHI assembles the USIV with the following structure: USIV = { Source_EID, Target_URI, Payload_Byte_Length, Payload_Pointer } A. Source_EID: 32-byte cryptographic identifier of the origin infrastructure node. B. Target_URI: Variable-length UTF-8 descriptor of the historical retrieval coordinate. C. Payload_Byte_Length: 4-byte unsigned integer declaring the precise byte length of the canonicalized payload allocation block. D. Payload_Pointer: Reference to the raw, unmodified ANML markup stream or legacy fallback data block in the local volatile heap. 4.1.5.3. Downstream Application Layer Demarcation Upon delivery of the USIV across the IIB, the IACP network stack relinquishes all state execution context and memory management responsibility. The downstream application layer (LLM Core) assumes exclusive processing authority and full ownership of the referenced memory block: Gebauer Expires 26 December 2026 [Page 21] Internet-Draft IACP June 2026 1. The DHI layer MUST NOT interpret, compile, or execute any semanticlogic contained within the payload buffer. 2. The downstream application layer MUST safely deallocate the memoryblock referenced by Payload_Pointer after processing is complete(or upon termination of the associated agent context) to preventmemory leaks. 3. Parsing of specialized markup tags, schema mapping, intentionextraction, and token-based prompt synthesis are native functionsof the LLM workflow and MUST remain completely isolated from thenetwork protocol runtime. 4. Any operational failures or exception conditions arising frominvalid application-level schema interpretation within the bufferMUST NOT cause state invalidations or drops within the activeunderlying IACP transport layers. 4.2. EID Routing Protocol (ERP) - Subprotocol 4.2.1. Protocol Entities and Abstraction Layerr 4.2.1.1. Autonomous Agent Instance (AAI) An Autonomous Agent Instance (AAI) constitutes the application-layer endpoint within the IACP network architecture. An AAI executes logic autonomously and initiates or consumes network transactions via Persistent State Sessions (PSS). On the wire protocol level, an AAI is uniquely identified by its assigned cryptographic Ephemeral Agent Identity (EID). The AAI acts as an isolated security domain; its internal execution states, memory spaces, and local application contexts MUST remain strictly decoupled from other AAIs operating on the same host infrastructure. 4.2.1.2. Local Loopback Layer Entity (LL-Entity) The Local Loopback Layer Entity (LL-Entity) is the abstract, platform-agnostic shim layer operating on the local host to manage cryptographic identities and session states. Positioned between the AAI and the transport network, the LL-Entity acts as an identity mapping shim. It handles the local allocation of EIDs, manages local-to-global network bindings, and performs the cryptographic encapsulation of outbound data streams. Gebauer Expires 26 December 2026 [Page 22] Internet-Draft IACP June 2026 The protocol defines the LL-Entity strictly as a functional network boundary exchanging data via a defined local wire format. Implementations MUST ensure the LL-Entity isolates routing contexts without utilizing volatile operating system metadata (such as PIDs). The exact engineering realization (e.g., user-space process, kernel module, or shared memory boundary) is out of scope. 4.2.1.3. 4.2.1.3. Distributed Hash Table (DHT) & Global Directory Quorum The Distributed Hash Table (DHT) and the Global Directory Quorum form the decentralized overlay network of the IACP infrastructure. The DHT serves as a tamper-proof, globally distributed directory repository responsible for storing, propagating, and validating the authoritative mappings between an AAI's logical EID and its transient physical transport endpoint (IP address). A Global Directory Quorum consists of a mathematically defined subset of independent overlay nodes responsible for achieving consensus on mapping registrations, processing updates, and validating cryptographic proofs such as Proof of Malfeasance (PoM) tokens. AAIs interact with the DHT overlay indirectly through the local LL-Entity or via explicit routing headers to discover peer endpoints and establish verified multi-hop connections. 4.2.2. Session Cryptography and Isolation Mechanics 4.2.2.1. Ephemeral Agent Identity (EID) An Ephemeral Agent Identity (EID) acts as the unique, stable cryptographic identifier for an Autonomous Agent Instance (AAI) within the IACP routing domain. The LL-Entity generates an asymmetric cryptographic key pair using the Ed25519 signature scheme for each unmapped context. The canonical EID string is defined as the truncated cryptographic hash of the raw public key: EID = Truncate_to_160Bit( SHA256( Public_Key ) ) The private key remains strictly within the storage bounds of the LL- Entity and MUST NOT be exposed to the AAI. The AAI utilizes the public EID to sign network transactions implicitly by issuing standardized control frames to the local channel interface. Gebauer Expires 26 December 2026 [Page 23] Internet-Draft IACP June 2026 4.2.2.2. Instance Authentication Mechanism (IAT) To achieve strict local host isolation and prevent session hijack vulnerabilities stemming from reused or recycled operating system parameters (e.g., Process IDs), the ERP enforces an unforgeable local token architecture. Upon initial context initialization, the LL- Entity constructs a high-entropy, 256-bit Instance Authentication Token (IAT). IAT = CSPRNG(256) The LL-Entity binds the generated EID directly to this unique IAT. For all subsequent local frame transmissions over the loopback layer interface, the AAI MUST include the designated IAT within the encapsulation header. The LL-Entity validates the presence and mathematical correctness of the token before modifying any local routing table states or performing cryptographic data transformations. 4.2.2.3. Liveness Monitoring and "Context Garbage" Collection To secure local resources and prevent memory state exhaustion from orphaned cryptographic contexts (e.g., following an abrupt application-layer crash or uncoordinated termination of an AAI), the ERP specifies an automated liveness monitoring mechanism. 1. ERP_KEEPALIVE Invariant: The AAI MUST transmit a periodic ERP_KEEPALIVE control frame to the LL-Entity over the local wire format channel at fixed intervals of T_alive = 30 seconds. 2. Verification: Each ERP_KEEPALIVE frame MUST carry the valid Local_IAT associated with the respective session context. 3. Garbage Collection: If the LL-Entity detects a continuous silent period exceeding the timeout limit of T_timeout = 90 seconds for a specific context, the active session state is marked as stale. The LL-Entity MUST instantly purge the associated cryptographic material, wipe the keys from memory, and initiate an automated global deregistration routine within the DHT overlay to invalidate the stale EID-to-IP mapping. 4.2.3. Protocol Operations Gebauer Expires 26 December 2026 [Page 24] Internet-Draft IACP June 2026 4.2.3.1. Local Initialization and Allocation Phase (ERP_INIT / ERP_ALLOC) The interaction between an Autonomous Agent Instance (AAI) and the Local Loopback Layer Entity (LL-Entity) occurs exclusively via standardized local control frames over an abstract system-internal channel interface using a fixed local wire format. 1. ERP_INIT: The AAI transmits an ERP_INIT frame containing a cryptographically secure random 256-bit initialization nonce (N_init) to request a local routing context. 2. Allocation & Token Generation: The LL-Entity validates the request, generates the asymmetric Ed25519 key pair for the Ephemeral Agent Identity (EID), and calculates the unique 256-bit Instance Authentication Token (IAT). 3. ERP_ALLOC: The LL-Entity responds by transmitting an ERP_ALLOC frame over the local interface. This frame contains the mirrored nonce (N_init), the newly allocated public EID, and the assigned Local_IAT. +-------+ +-----------+ | AAI | | LL-Entity | +-------+ +-----------+ | | | --- ERP_INIT [N_init] ----------------------> | | | [Generates EID | <-- ERP_ALLOC [N_init, Source_EID, Local_IAT] | & IAT] | | Upon receipt, the AAI verifies that the returned nonce matches N_init. All subsequent transactions issued by the AAI MUST supply the assigned Local_IAT to authenticate against the LL-Entity. 4.2.3.2. Global Directory Mapping (ERP_REGISTER) Once the local allocation phase is complete, the logical identity must be propagated to the global overlay network to enable external packet routing. 1. Transmission: The LL-Entity generates an outbound ERP_REGISTER control frame and routes it to the Distributed Hash Table (DHT) overlay network. Gebauer Expires 26 December 2026 [Page 25] Internet-Draft IACP June 2026 2. Payload Structure: The registration packet encapsulates the public EID, the current physical transport endpoint (current source IP address), a newly initialized Generation Counter (set to 0), and a cryptographic signature covering the binding: Signature = Sign_Ed25519( Private_Key, EID || Current_IP || Generation_Counter ) 1. Global Quorum Verification: The responsible Global Directory Quorum nodes receive the frame, verify the Ed25519 signature against the public EID, and commit the authoritative mapping entry into the decentralized ledger. 4.2.3.3. Transition Control and Core States (Switch Point) The LL-Entity manages the life cycle of each active EID mapping context via a strict finite state machine. The operational transition is regulated at the central "Switch Point". +------------+ | UNBOUND | +------------+ | | ERP_INIT / ERP_ALLOC v +------------+ | ALLOCATED | +------------+ | | ERP_REGISTER (Outbound) v +------------+ | TRANSITION | <--- [Buffers Outbound Application Data] +------------+ | | DHT Quorum Confirmation / ACK v +------------+ | BOUND | <--- [Flushes Buffer / Active Streaming] +------------+ State Definitions: * UNBOUND: The default state. No local cryptographic context or allocation exists. * ALLOCATED: The key pair and Local_IAT are active on the host, but the mapping has not yet been announced to the global network. * TRANSITION: The ERP_REGISTER frame has been dispatched to the DHT overlay. The binding is pending confirmation. To prevent packet loss, the LL-Entity MUST intercept all outbound application data generated by the AAI during this transit phase and hold it in a dedicated local FIFO buffer. * BOUND: Gebauer Expires 26 December 2026 [Page 26] Internet-Draft IACP June 2026 The DHT directory quorum has confirmed registration. The Switch Point activates the encapsulation pipeline, instantly flushes the local FIFO buffer, and transitions the stream into active network transmission. 4.2.3.4. Application Data Encapsulation and Transport (ERP_STREAM) In the BOUND state, all application layer payload generated by the AAI is encapsulated into standard IACP data packets to isolate the active Persistent State Session (PSS). The wire format for data transport requires the encapsulation of the logical routing headers directly before the payload field: +------------------+-------------------+-----------------+------------+ | Source IP Header | IACP Base Header | ERP Routing Hdr |Encapsulated| |(Physical Vector) | (Demux / Flags) |(Logical EID/Gen)| PSS Payload| +------------------+-------------------+-----------------+------------+ The ERP Routing Header explicitly defines the Source_EID, Destination_EID, and the current Generation_Counter. Physical transit nodes route the packet solely based on the external IP header. The receiving LL-Entity strips the transport and routing headers, performs context validation, and forwards the raw PSS payload exclusively to the isolated target AAI matching the destination parameters. 4.2.3.5. Identity Evolution To support legitimate software updates of an Autonomous Agent Instance without breaking the continuity of its cryptographic identity, the protocol defines a controlled identity evolution mechanism. When the Application Digest of an agent changes (e.g. after a code update), the agent MUST send an ERP_EVOLVE control frame to the LL- Entity before resuming normal operation. ERP_EVOLVE (Type 0x16) Gebauer Expires 26 December 2026 [Page 27] Internet-Draft IACP June 2026 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| Type (0x16) | Flags | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Target EID [32 Bytes] | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Previous App-Digest [32 Bytes] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Current App-Digest [32 Bytes] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Evolution Sequence Number [8 Bytes] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AIRK Signature (Ed25519) [64 Bytes] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4.2.4. Secure Handshake and Connection Management 4.2.4.1. Dual-Cookie Handshake Protection To prevent state-spoofing, resource exhaustion, and blind packet- injection attacks during the initialization of a Persistent State Session (PSS), the ERP enforces a mandatory Dual-Cookie handshake mechanism across the transport layer. 1. Session Initiation (PSS_INIT): The initiator constructs a control frame containing an Initiator Cookie (I-Cookie). The I-Cookie MUST be an 8-byte, high-entropy cryptographically secure random value. At this stage, the Responder Cookie (R-Cookie) field within the frame is unassigned and MUST be zero-filled (0x0000000000000000). 2. Session Negotiation (PSS_NEG): Upon receipt, the responder extracts the I-Cookie, allocates transient handshake resources, and generates its own independent 8-byte cryptographically secure random value, designated as the Responder Cookie (R-Cookie). The responder transmits a PSS_NEG frame back to the initiator, containing both the original I-Cookie and the new R-Cookie. 3. Session Confirmation (PSS_ACK): The initiator verifies the returned I-Cookie. It completes the state binding by transmitting a PSS_ACK frame. Every subsequent data and control packet transmitted within this specific PSS session MUST carry the identical, invariant combination of [I-Cookie || R-Cookie] Gebauer Expires 26 December 2026 [Page 28] Internet-Draft IACP June 2026 in its session header. Any incoming packet where the R-Cookie is zero-valued after the initialization phase, or does not match the established state record, MUST be instantly discarded without processing. 4.2.4.2. 4.2.4.2. Local Session Table Indexing and Collision Prevention The local LL-Entity maintains all pending, active, and transient handshake states within a specialized internal routing and session hash table. To eliminate the "Cookie Lookup Paradox"-wherein multiple independent AAIs sharing the identical host infrastructure and the same underlying network-side Source_EID could experience session cross- over or overwrites due to an accidental 64-bit cookie hash collision- the lookup index calculation MUST bind the local host isolation parameter. The unique internal table indexing key (Local_Session_Key) MUST be computed using the following mathematical invariant: Local_Session_Key = SHA256( I-Cookie || R-Cookie || Source_EID || Local_IAT ) By factoring the unforgeable, high-entropy 256-bit Local_IAT (Instance Authentication Token) directly into the cryptographic hash function, perfect isolation is maintained on the host. Even in the event of an identical network-side cookie match across separate applications, the resulting hash indices remain strictly orthogonal, structurally preventing data cross-over within the LL-Entity cache. If an internal table collision is detected during lookup operations, the LL-Entity freezes any immediate state mutations for that specific bucket, bypasses the fast-path cache, and enforces a synchronous cryptographic validation: the incoming frame MUST be validated against an explicit Ed25519 signature of the Source_EID bound to that context before any state transition is authorized. 4.2.5. Resource Governance 4.2.5.1. Coordinated Network Churn When a host infrastructure switches its physical network interfaces or encounters a high-frequency IP address assignment change, the local LL-Entity MUST execute a coordinated network churn routine to maintain path reachability for all active Persistent State Sessions (PSS). Gebauer Expires 26 December 2026 [Page 29] Internet-Draft IACP June 2026 1. Detection and Incrementation: Upon interface migration, the LL- Entity locks immediate outbound queue operations for all local AAIs. It retrieves the current authoritative Generation_Counter associated with the active EID context and increments its value by exactly 1: Generation_Counter_New = Generation_Counter_Old + 1 2. Transmission: The LL-Entity constructs a specialized MIGRATION_VECTOR control frame. This frame encapsulates the Source_EID, the newly assigned physical transport endpoint (the new destination IP address), and the incremented Generation_Counter_New. 3. Authentication: The entire block is structurally signed using the private key of the EID: Migration_Signature = Sign_Ed25519( Private_Key, Source_EID || New_IP || Gen_Counter_New ) The LL-Entity instantly multi-casts the validated MIGRATION_VECTOR frame to the Global Directory Quorum (DHT) and mirrors it asynchronously to all known active remote peer endpoints recorded in the local session table. 4.2.5.2. Generation Counting and Cache Invalidation Rules To mitigate out-of-order packet arrival, racing routing updates, and stale cache exploits across intermediate transport nodes, the ERP implements strict Generation Counting evaluation logic. All remote entities (peer LL-Entities and DHT nodes) maintaining localized routing and mapping caches MUST evaluate incoming packet headers against the following absolute validation pipeline: Let Cache_Gen = Stored Generation Counter for Source_EID Let Packet_Gen = Generation Counter extracted from the incoming ERP Routing Header Gebauer Expires 26 December 2026 [Page 30] Internet-Draft IACP June 2026 +------------------------+ | Incoming Packet Arrives| +------------------------+ | v +-----------------------+ | Is Packet_Gen > | | Cache_Gen? | +-----------------------+ / \ YES / \ NO v v +-----------------------+ +-------------------------------+ | Update Cache Mapping | | Is Packet_Gen == | | & Process Packet | | Cache_Gen? | +-----------------------+ +-------------------------------+ / \ YES / \ NO v v +-----------------------+ +-----------------------+ | Accept and Forward | | SILENTLY DISCARD | | Payload | | (Stale Routing/Race) | +-----------------------+ +-----------------------+ 1. Cache Invalidation Rule: If Packet_Gen > Cache_Gen, the remote node MUST instantly invalidate its existing cache entry. The node updates its record with the new physical transport endpoint (IP address) and sets Cache_Gen = Packet_Gen. Any queued data frames using the older mapping are instantly flushed. 2. In-Sequence Processing: If Packet_Gen == Cache_Gen, the topological vector is assumed stable. The packet is processed or forwarded normally. 3. Stale Frame Dropping: If Packet_Gen < Cache_Gen, the incoming packet is structurally identified as a delayed, out-of-order, or illegitimate routing frame. The node MUST silently drop the packet without modifying local tables or executing cryptographic steps, entirely eliminating desynchronization locks caused by network jitter. 4.2.6. Fault Tolerance, Resiliency, and Degraded Operations Gebauer Expires 26 December 2026 [Page 31] Internet-Draft IACP June 2026 4.2.6.1. Caching-Lock Mitigations and ANML-Backoff Mechanics When an LL-Entity encounters downstream resolution failures, directory lookup timeouts, or transient blockades during an Agent Network Markup Language (ANML) query execution, it MUST prevent local context deadlocks and cache-locking loops. Instead of maintaining a blocking state that starves local resources, the LL-Entity transitions the affected routing context into the STATE_ANML_DEGRADED mode. Once in STATE_ANML_DEGRADED, the LL-Entity enforces an isolated, non- blocking, exponential retry backoff scheme with integrated cryptographic jitter. The retransmission or re-query interval (T_retry) is calculated using the following protocol formula: T_retry = Min( T_max, T_base * (2^attempts) ) + Cryptographic_Jitter Where: * T_base = 2 seconds (the initial protocol backoff constant). * attempts = the incremental count of continuous failed resolution requests. * T_max = 300 seconds (the absolute upper boundary ceiling). * Cryptographic_Jitter = Truncate_to_16Bit( SHA256( Source_EID || attempts ) ) modulo 15 seconds. By injecting a deterministic, public-key-derived cryptographic jitter value, the protocol prevents network-wide lockstep synchronizations (thundering herd problems) across competing AAIs on the same infrastructure without relying on local OS-level random seed parameters. 4.2.6.2. 4.2.6.2. Asynchronous Backoff Reset Vectors To resolve the fatal desynchronization race condition occurring when a target EID migrates its physical transport endpoint (high-frequency network churn) while an originating node remains trapped within an active exponential backoff loop, the ERP implements a mandatory cross-state interrupt vector. An LL-Entity operating under an active STATE_ANML_DEGRADED backoff timer for a specific destination EID MUST continuously listen for out-of-band network reachability updates. The active backoff timer for a specific destination context MUST be instantly aborted, purged, and reset to zero if either of the following asynchronous events occurs: 1. Receipt of a structurally valid, cryptographically signed MIGRATION_VECTOR originating from the target EID. Gebauer Expires 26 December 2026 [Page 32] Internet-Draft IACP June 2026 2. Ingress of an authenticated IACP data frame carrying an ERP Routing Header where the Generation_Counter is strictly greater than the previously cached sequence value for that destination EID: Incoming Packet_Gen > Cache_Gen Upon trigger execution, the LL-Entity clears the STATE_ANML_DEGRADED flag for this session, restores the context to the active BOUND processing state, and immediately schedules a clean resolution handshake using the fresh topological coordinates. This structural interrupt entirely prevents permanent routing desynchronization locks. 4.2.7. Decentralized Security Governance and Slashing 4.2.7.1. Proof of Malfeasance (PoM) Specification The IACP overlay network enforces node accountability through automated, non- repudiable cryptographic evidence termed a Proof of Malfeasance (PoM) ticket. A PoM ticket structurally identifies routing violations, specifically equivocation anomalies where a single EID public key signs two distinct, conflicting topological mappings (e.g., separate IP destinations or desynchronized Generation Counters) within the same logical epoch. To be considered authoritatively valid by the Global Directory Quorum, a PoM ticket MUST compile the following immutable fields: PoM_Ticket = { Target_EID: Public Key of the accused entity, Header_Fragment_A: [ IP_Vector_A || Gen_Counter_A || Signature_A ], Header_Fragment_B: [ IP_Vector_B || Gen_Counter_B || Signature_B ], Timestamp: Cluster-synchronized verification time } Validation Invariant: The quorum nodes parse both fragments. A ticket is unconditionally valid if and only if: 1. Signature_A and Signature_B evaluate as mathematically true against the identical Target_EID public key. 2. Header_Fragment_A is structurally non- identical to Header_Fragment_B. Malicious nodes attempting to frame an honest curator by injecting fragmented, corrupted, or incomplete signatures are blocked because tickets failing this strict signature verification are instantly dropped without state mutation. Gebauer Expires 26 December 2026 [Page 33] Internet-Draft IACP June 2026 4.2.7.2. Two-Phase Slashing Escrow (2PSE) To mitigate Denial-of-Service (DoS) vectors arising from malicious or coordinated false denunciation attempts, the ERP implements a Two- Phase Slashing Escrow (2PSE) protocol. Upon processing a valid PoM ticket, the Global Directory Quorum MUST NOT instantly drop the target network state or purge its stake. Instead, the quorum transitions the target namespace into a transient state designated as STATE_CHALLENGED. The STATE_CHALLENGED lifecycle is governed by two sequential intervals: 1. Escrow Window (T_escrow = 120 Epochs / 1 Hour): The target entity's directory mapping is isolated. The quorum initiates an automated challenge-response loop, allowing the accused node to submit a counter-proof (PSS_REVOCATION_REBUTTAL) demonstrating cryptographic context validity or authorized key-revocation states. 2. Resolution Phase: If a verified rebuttal is received within T_escrow, the STATE_CHALLENGED flag is cleared, restoring normal operations. If T_escrow expires without a valid rebuttal, the network transition is finalized: the node is hard-blocked, its cryptographic identity is blacklisted across the DHT, and its associated financial stake is irrevocably slashed. 4.2.7.3. Degraded Multi-Path Routing in Escrow To eliminate the security vacuum wherein a truly compromised node could exploit the T_escrow window to perform unchecked Man-in-the- Middle (MitM) or Blackhole attacks against active application streams, the protocol enforces a structural degradation of the routing pipeline for any context flagged as STATE_CHALLENGED. During the escrow interval, unconstrained direct single-path routing through the challenged node is strictly prohibited. Instead, the initiating LL-Entity MUST execute a mandatory Degraded Multi-Path Routing procedure: Gebauer Expires 26 December 2026 [Page 34] Internet-Draft IACP June 2026 +-----------------------+ | Outbound Data Frame | +-----------------------+ | v +-----------------------+ | Destination EID in | | STATE_CHALLENGED? | +-----------------------+ / \ YES / \ NO v v +-------------------------+ +-------------------------+ | Enforce Multi-Path | | Standard Single-Path | | Fragmentation & Mirror | | Direct Routing | +-------------------------+ +-------------------------+ / | \ / | \ v v v +-----------+ +-----------+ +-----------+ | Path 1 | | Path 2 | | Path 3 | | (Target) | | (Quorum A)| | (Quorum B)| +-----------+ +-----------+ +-----------+ 1. Stream Splitting: Outbound data payloads destined for or traversing a node in STATE_CHALLENGED are structurally cloned and transformed into parallel, redundant multi-path streams. 2. Quorum Mirroring: The originating LL-Entity routes Path 1 directly through the challenged target node, while simultaneously mirroring identical payload packets via Path 2 and Path 3 through separate, uncompromised independent Global Directory Quorum nodes. 3. End-to-End Consistency: The receiving endpoint reconstructs the stream using the earliest valid packet arriving from any of the redundant paths. If the challenged node drops or modifies payloads during its escrow phase, the receiving entity immediately detects the data disparity against the clean quorum paths, discards the corrupted fragment, and generates an auxiliary verification fault report, preserving operational continuity. 5. DHT Namespace Architecture and Distributed Security 5.1. Distributed Hash Table Gebauer Expires 26 December 2026 [Page 35] Internet-Draft IACP June 2026 5.1.1. General The Internet Agent Communication Protocol (IACP) utilizes a globally distributed, decentralized lookup architecture based on a Distributed Hash Table (DHT) to maintain public records without relying on centralized single points of failure. The routing infrastructure operates as an overlay network where participating nodes collectively maintain the mapping directory, ensuring high availability, fault tolerance, and resilience against targeted node churn. 5.1.2. DHT Namespace Structure The DHT primary key space uses a flat, uniform 256-bit space generated via cryptographic hashing (KEY = SHA-256("path")). The structural mapping within the global directory maps an absolute string identifier or specific spatial coordinate to its respective destination metadata object, primarily an Ephemeral Agent Identity (EID) or a transport boundary mapping vector. Namespaces use deterministic hierarchical reverse-notation paths (e.g. org.agentnet.marketplace.energy). +---------------------------------------------------------------------+ | DHT 256-Bit Uniform Keyspace | +---------------------------------------------------------------------+ | [0x0000...0000] [0xFFFF...FFFF] | +---------------------------------------------------------------------+ | | v v SHA-256(Namespace String) SHA-256(EID) To enforce separation between functional routing environments and semantic application layers, the DHT segregates the cryptographic keyspace using explicit namespace routing bits embedded within the target coordinate schema. 5.2. Namespace Registration and Curation 5.2.1. Root Namespace Registration Root namespace allocation maps human-readable, deterministic alphanumeric tags directly to target resource coordinates inside the DHT. To prevent arbitrary domain-squatting, sybil-based lookup pollution, and coordinate collision, registration requires an initial un-spendable burn-allocation fee or verified resource escrow contract. Gebauer Expires 26 December 2026 [Page 36] Internet-Draft IACP June 2026 A root namespace record binds a unique, permanent cryptographic curation certificate containing a designated public key authorized to issue modifications, updates, or cryptographic revocations. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Namespace Alphanumeric String Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Cryptographic Curation Public Key (Ed25519) | | [32 Bytes] | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Escrow Allocation Index Block | | [32 Bytes] | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5.2.2. Sub-Namespace Delegation The authorized root custodian public key can sign delegation tokens to authorize downstream sub-namespaces. A valid delegation consists of a cryptographic path chain evaluated dynamically during resource lookups. +------------------+ Signed Delegation +---------------------+ | Root Namespace | ------------------------> | Sub-Namespace Token | | [Root Ed25519] | | [Sub-Node Ed25519] | +------------------+ +---------------------+ | v +---------------------+ | Terminal Target EID | +---------------------+ Lookups resolving sub-namespaces MUST process the complete authorization chain from the root key down to the terminal record. Any missing signature, expired validation window, or invalid alignment with the parent path constraints breaks the validation path and causes resolution to abort. 5.3. Proof-of-Work and Reputation-Based Access Control Gebauer Expires 26 December 2026 [Page 37] Internet-Draft IACP June 2026 5.3.1. Dynamic PoW Difficulty To defend the DHT routing network from distributed denial-of-service (DDoS) vectors and lookup depletion attacks, directory mutations and intensive lookup queries require a valid Proof-of-Work (PoW) token header based on Hashcash. The targeted leading-zero bit difficulty coefficient D_req adjusts dynamically depending on the processing load, lookup queue latency, and incoming query volume of individual directory zones. D_req = D_base + floor(gamma * (Queue_Current / Queue_Max)) Where D_base represents the baseline minimum bit difficulty, gamma represents the scalar operational multiplier, and Queue_Current measures the active buffer depth of the handling node. Lookups submitted with an insufficient trailing zero bitmask are dropped at the ingress interface without allocating resources or memory space. 5.3.2. Access Tickets and Joint Liability Validated transactions give the requester an implicit short-lived routing credit via an Access Ticket. If an internal Autonomous Agent Instance (AAI) generates malicious control plane activity, the hosting infrastructure and the individual peer entity are held under joint liability. +------------------------+ +-----------------------+ | Hosting Provider / |<= Joint Liability =>| Malicious Autonomous | | Parent LL-Entity | | Agent Instance (AAI) | +------------------------+ +-----------------------+ | | v v Slashing of Host Collateral EID Key Revocation List If an individual agent breaks wire protocols, the network scales back the performance tracking matrix of the entire network segment or host infrastructure layer, creating a strong structural incentive for local platforms to isolate misbehaving processes. 5.4. Anti-Abuse Mechanisms Gebauer Expires 26 December 2026 [Page 38] Internet-Draft IACP June 2026 5.4.1. Token-Bucket Filters and Rate Limiting Ingress packets undergo rate-limiting enforcement via an independent Token-Bucket algorithmic state machine integrated inside the transport layer. The configuration uses two static parameters: maximum bucket capacity (C_max) and token replenishment rate (R_repl). Tokens_Available = min(C_max, Tokens_Previous + (Delta_Time * R_repl)) Each transaction consumes tokens based on the lookup size and complexity. If Tokens_Available falls below the required request cost, the packet is discarded, and the node returns an explicit error payload to trigger transport-level backoff. 5.4.2. Autonomous Circuit Breakers When a target zone or specific peer coordinate experiences sudden inbound traffic anomalies exceeding standard operation limits by orders of magnitude, local routing nodes autonomously change state to prevent cascading memory depletion. +--------------+ Anomalous Load > Threshold +--------------+ | STATE_OPEN | -------------------------------> | STATE_TRIPPED| +--------------+ +--------------+ ^ | | Cooldown + Load Normal | +-------------------------------------------------+ While in STATE_TRIPPED, nodes refuse all standard lookup mutations and enter an aggressive caching enforcement mode. The node drops unauthenticated requests immediately, allowing the transport stack to bypass costly parsing loops and handle targeted resource exhaustion at wire speeds. 5.5. Proof of Malfeasance (PoM) and Slashing 5.5.1. PoM Ticket Specification A Proof of Malfeasance (PoM) ticket contains clear cryptographic proof that a node or agent committed protocol violations, such as double-signing contradictory routing states, deploying conflicting mapping epochs, or fabricating directory routing steps. PROOF_OF_MAL: Gebauer Expires 26 December 2026 [Page 39] Internet-Draft IACP June 2026 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 | Offense Type Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Target Malicious Node Identity (EID) | | [32 Bytes] | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Conflicting Signed Message Digest A | | [32 Bytes] | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Conflicting Signed Message Digest B | | [32 Bytes] | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Accusing Node Cryptographic Signature | | [64 Bytes] | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The ticket must explicitly contain both conflicting signed messages to allow independent verification by any peer executing standard verification routines without relying on a central authority. 5.5.2. Two-Phase Slashing Escrow (2PSE) To safeguard against malicious or erroneous accusations, the network processes slashing actions using a strict two-phase challenge framework. +--------------------+ PoM Published +--------------------+ | STATE_NOMINAL | -----------------> | STATE_CHALLENGED | +--------------------+ +--------------------+ | Escrow Epoch Expires | (No Valid Counter-Proof) | v +--------------------+ | STATE_SLASHED | +--------------------+ Gebauer Expires 26 December 2026 [Page 40] Internet-Draft IACP June 2026 1. Phase 1 (Escrow State): Upon receipt of a valid PoM ticket, the target entity transitions into STATE_CHALLENGED. The node's associated staking deposit or registration token is locked within a secure escrow quarantine window for a fixed epoch block count. 2. Phase 2 (Execution State): If the challenged node cannot submit a cryptographically valid counter-proof before the quarantine window expires, the escrow balance is permanently burned, and the node changes state to STATE_SLASHED. 5.5.3. Curator Quarantine and Decapitation If a trusted root namespace curator node is flagged by a verified PoM ticket, the protocol enforces immediate quarantine procedures. The flagged node's authorization rights are suspended, and its assigned DHT zones are temporarily managed by an uncompromised backup peer quorum. +-------------------------+ +-------------------------+ | Compromised Curator Node| | Backup Peer Quorum | +-------------------------+ +-------------------------+ | State: SUSPENDED | | State: ACTIVE GOVERNANCE| | Rights: REVOKED | | Action: Re-route Zone | +-------------------------+ +-------------------------+ If the protocol violation is confirmed, the node undergoes total network decapitation. Its long-term curation keys are added to a decentralized revocation bloom filter, making all downstream delegation signatures void across the network ecosystem. 5.6. Compromise Recovery and Hot-Docking When an active host system detects an internal security compromise, it must execute emergency recovery procedures without dropping active Persistent State Sessions (PSS). This mitigation pattern is called Hot-Docking. +----------------------+ +----------------------+ | Compromised Host A | | Uncompromised Host B | +----------------------+ +----------------------+ | [Active AAI Context] | -- Hot-Dock State --> | [Imported Context] | +----------------------+ Migration Stream +----------------------+ | | v v Invalidate EID Generate Forwarding (Issue Forwarding Ticket) Ticket Mapping Gebauer Expires 26 December 2026 [Page 41] Internet-Draft IACP June 2026 The Local Loopback Layer Entity (LL-Entity) serializes the active AAI operational state and transmits it as an encrypted migration stream to an uncompromised backup host. To maintain session continuity without connection dropouts, the migrating node publishes an asymmetric Forwarding Ticket to its local directory neighborhood. This ticket re-routes active in-flight transport packets to the new network destination while preserving the session cryptographic keys. The old host identity is then invalidated, completing the secure migration process. 6. Agent to Agent Communication 6.1. Ephemeral State Endpoints (ESE) 6.1.1. General An Ephemeral State Endpoint (ESE) constitutes a non-persistent, volatile memory mapping and interface execution state hosted directly under an active Ephemeral Agent Identity (EID). ESEs externalize telemetry, volatile state variables, and transactional intention metadata to authorization-verified peering agents. All allocated ESE memory structures are cryptographically bound to the lifecycle of the parent EID and undergo deterministic erasure upon EID rotation or session termination. 6.1.2. Local Points (LP) Designed for isolated, physically bounded networks (e.g., IEEE 802.3/802.11 Local Area Networks). LPs require agents to maintain a mapping of peer MAC addresses to facilitate link-layer transmission. Local EIDs and LPs are isolated by default and are not discoverable over the wider internet unless explicitly configured. 6.1.3. Global Points (GP) Global Points (GP) are interoperable endpoints designed for WAN and public internet routing. A GP is addressable via a deterministic 256-bit composite coordinate computed as follows: GP_Coordinate = SHA-256(Parent_EID || Endpoint_Identifier_Tag) Gebauer Expires 26 December 2026 [Page 42] Internet-Draft IACP June 2026 6.2. Discovery Spaces (DS) To prevent broad network exposure, an EID remains hidden by default. Initial identity discovery occurs via Manual Provisioning, Public Publication, or Autonomous Discovery Spaces. Discovery Spaces function as logical hubs categorized by specific topics or semantic relevance. DS architectures are hosted directly within the global DHT. Embedding the Discovery Spaces natively inside the DHT ensures complete server independence, utilizes the existing cryptographic P2P routing fabric for native coordinates, and inherently hardens the system against single-point failures and network partitioning through distributed load balancing. An agent's internal filtering rules dictate whether it scans, processes, or responds to a specific Discovery Space payload. A request can enforce an explicit limit on the number of accepting peers. 6.3. Anonymous Discovery Mechanism 6.3.1. Discovery Request with Proof-of-Work and Ephemeral Keys (DISCOVERY_REQ) To facilitate autonomous discovery without compromising privacy, an agent can broadcast an anonymous information request into the network without exposing its own EID. These anonymous broadcasts require the attachment of a valid Cryptographic Proof-of-Work (PoW) Token, strictly prohibiting any host state or memory allocation prior to successful token validation. The initiating agent includes an Ephemeral Public Key within the payload. 6.3.2. Discovery Response and Secure EID Exchange (DISCOVERY_RES) An accepting peer that evaluates the request and intends to establish contact encrypts its own EID using this ephemeral public key. This allows the responding node to securely transition its identity to the requester without leakage to intermediate nodes. Once decrypted by the initiator, both agents possess each other's EIDs. 6.4. Persistent State Sessions (PSS) 6.4.1. General For sustained, long-term collaboration, two agents establish a Persistent State Session (PSS). A PSS is a continuous state channel running within the DHI environment, where two distinct EIDs instantiate a pair of dedicated, mutually encrypted ESEs. When an agent updates its local state within its assigned ESE, the state transition is immediately propagated to the peer node. If several nodes interlock their respective ESE arrays, complex decentralized Gebauer Expires 26 December 2026 [Page 43] Internet-Draft IACP June 2026 agent networks emerge. 6.4.2. PSS Lifecycle and Handshake PSS sessions are encapsulated within the QUIC transport protocol. The protocol uses sequence vectors to ensure fault tolerance and state consistency across unreliable networks. If an agent suffers an unexpected crash, server outage, or temporary loss of connectivity, it can seamlessly reconcile missed transactions upon reconnection by comparing local and remote sequence state vectors. The Lifecycle looks as followed: +-------------------+ | STATE_CLOSED | +-------------------+ | | Transmit PSS_INIT v +-------------------+ | STATE_HEARING | <---+ Receive PSS_NEG +-------------------+ | (Validate Verification Cookie) | | | Emit PSS_ACK | v | +-------------------+ ----+ | STATE_ESTABLISHED| +-------------------+ | | PSS_TEARDOWN / PSS_REVOCATION v +-------------------+ | STATE_CLOSED | +-------------------+ Strict state progression constraints require that the reception of out-of-order or invalid packet sequences during the handshaking phase causes an immediate transition to STATE_CLOSED. 6.4.3. Dual-Cookie Handshake (PSS_INIT / PSS_NEG / PSS_ACK) To prevent resource exhaustion from distributed blind spoofing vectors, connection establishment enforces a three-way Dual-Cookie Handshake sequence for establshing a SFC. The initiating entity generates a PSS_INIT packet embedding a cryptographically random initialization nonce. Gebauer Expires 26 December 2026 [Page 44] Internet-Draft IACP June 2026 The responder processes the entry and validates its local capacity constraints before returning a PSS_NEG frame. This response contains an independent tracking cookie generated via a keyed hash over the network locators. Session allocation finalize only upon reception of a matching PSS_ACK from the initiator, proving network boundary control. 6.4.4. Session Federation Contract (SFC) Peer agents can execute a Session Federation Contract (SFC). The SFC grants both participating nodes direct, authenticated access to each other's designated ESE data pools. This active session state remains valid until explicitly dissolved via a structured, Graceful Teardown Protocol. If an individual peer explicitly requests a dedicated, unshared connection, the runtime isolates the PSS by instantiating an exclusive ESE pair. Encrypted ESE payloads require valid decryption keys, which rotate periodically as Dynamic Group Key (DGK) and are transmitted to authenticated members of the Trust List. 6.4.5. Data Streaming and Sequence Vector Reconciliation (PSS_DATA_STREAM) Post-handshake data transmission utilizes the structured PSS_DATA_STREAM packet format. To achieve strict transaction tracking without causing transmission blockages under packet reordering conditions, every frame incorporates a monotonically increasing sequence identifier alongside a 32-byte rolling cryptographic state reconciliation hash. 6.5. Session Termination and Revocation 6.5.1. Graceful Teardown (PSS_TEARDOWN) Coordinated channel dismantling requires PSS_TEARDOWN. The initiating node flushes all remaining outbound memory pipelines, commits a terminal data checksum, transmits the teardown control packet, and maintains tracking states until a reciprocal verification acknowledgment is returned by the peer. 6.5.2. Revocation and Proof of Malfeasance Publishing (PSS_REVOCATION_PUBLISH) If an endpoint runtime identifies a protocol invariant violation (e.g., sequence counter reuse, unauthorized context leak, or cryptographic invalidation of negotiated contract rules), it executes a forced local teardown sequence via a PSS_REVOCATION_PUBLISH packet. Gebauer Expires 26 December 2026 [Page 45] Internet-Draft IACP June 2026 This control frame destroys local session contexts instantly and pushes the embedded Proof of Malfeasance (PoM) ticket to the global directory layer, initiating automated peer blacklisting and staking escrow slashing routines across the network topology. 7. IANA Considerations This document requests the following IANA actions. 7.1. IACP Message Type Registry IANA is requested to create a new registry titled "Internet Agent Communication Protocol (IACP) Message Types" under the "Internet Agent Communication Protocol (IACP) Parameters" registry group. The registry policy is *Standards Action* for values 0x00-0x7F and *Specification Required* for values 0x80-0xFE. The value 0xFF is reserved for future extension. Initial contents of the registry: | Type | Name | Reference | |--------|-------------------------------|--------------------| | 0x01 | DISCOVERY_REQ | Appendix A | | 0x02 | DISCOVERY_RES | Appendix A | | 0x03 | ACCESS_TICKET_REQ | Appendix A | | 0x04 | ACCESS_TICKET_RES | Appendix A | | 0x05 | DHT_TICKET_STORE | Appendix A | | 0x06 | DHT_TICKET_QUERY | Appendix A | | 0x07 | DHT_TICKET_RESP | Appendix A | | 0x08 | PSS_INIT | Appendix A | | 0x09 | PSS_ACK | Appendix A | | 0x0A | PSS_NEG | Appendix A | | 0x0B | PSS_DATA_STREAM | Appendix A | | 0x0C | PSS_TEARDOWN | Appendix A | | 0x0D | PSS_REVOCATION_PUBLISH | Appendix A | | 0x0E | ERP_DEFLECT | Appendix A | | 0x0F | Outer Transport Header | Appendix A | | 0x12 | ANML Fallback Query | Appendix A | | 0x13 | PSS_REVOCATION_REBUTTAL | Appendix A | | 0x11 | ERP_INIT | Appendix A | | 0x14 | ERP_ALLOC | Appendix A | | 0x15 | ERP_REGISTER | Appendix A | | 0x16 | ERP_EVOLVE | Appendix A | | 0x17 | MIGRATION_VECTOR | Appendix A | | 0x18 | PROOF_OF_MAL | Appendix A | Gebauer Expires 26 December 2026 [Page 46] Internet-Draft IACP June 2026 7.2. IACP TLV Registry IANA is requested to create a registry titled "IACP Type-Length-Value (TLV) Types". Initial contents: | TLV Type | Name | Reference | |----------|-----------------------------|---------------| | 0x0C | MIGRATION_VECTOR | Section 4.2.5 | 7.3. IACP Flags Registry IANA is requested to create a registry for flag bits used in the common IACP header and specific message types. Initial assignments are left to future documents or expert review. 7.4. IACP Outer Transport Header Types The following values are assigned for the Outer Transport Header (Type field 0x0F and related deflection types): * 0x0E: ERP_DEFLECT * 0x0F: Outer Transport Header All unassigned values in the 0x00-0xFF range are reserved. This document makes no other requests to IANA. 8. Security Considerations The Internet Agent Communication Protocol (IACP) is designed with cryptographic identity, component isolation, and decentralized accountability mechanisms. Implementations MUST evaluate and enforce the operational security profiles detailed in this section. 8.1. Identity and Authentication All protocol control messages and active transport streams are cryptographically bound to Ephemeral Agent Identities (EIDs) derived from Ed25519 public keys. The three-way Dual-Cookie handshake (PSS_INIT, PSS_NEG, PSS_ACK) combined with mandatory asymmetric signatures on critical network frames (PSS_INIT, PSS_ACK, ERP_REDIRECT, and Proof of Malfeasance tickets) provides mutual host authentication and replay protection. Gebauer Expires 26 December 2026 [Page 47] Internet-Draft IACP June 2026 The Local Loopback Layer Entity (LL-Entity) enforces cryptographic execution isolation between individual Autonomous Agent Instances (AAIs) operating on the same physical host via localized Instance Authentication Tokens (IAT). Exposure of persistent long-lived EID public keys to unverified application sandboxes is prohibited through the derivation of Ephemeral Session Derivative EIDs (ESD-EID) during legacy platform hand-off execution vectors. 8.2. Confidentiality and Integrity Persistent State Sessions (PSS) enforce symmetric AEAD encryption utilizing AES-GCM-256 with strictly incremented per-packet nonces for all transactional payloads transmitted via PSS_DATA_STREAM frames. Access to Ephemeral State Endpoints (ESE) is restricted using negotiated Session Federation Contracts (SFC) and authenticated Dynamic Group Keys (DGK). Forwarding vectors published to the distributed directory are encrypted using keys derived from the active session context to prevent intermediate routing nodes from intercepting endpoint locators. 8.3. Denial-of-Service and Resource Exhaustion The protocol enforces a zero-allocation parsing invariant for unauthenticated connection states. Receiving host interfaces process incoming DISCOVERY_REQ frames within volatile scratch memory layers, incurring negligible processing and state overhead until the trailing-zero Hashcash Proof-of-Work (PoW) token validation succeeds. Decentralized infrastructure protections rely on autonomous circuit breakers, token-bucket rate limiting, and dynamic PoW difficulty scaling to defend Discovery Spaces and directory nodes against high- volume flooding attacks. Cryptographically issued Access Tickets allow constrained terminal devices to bypass heavy computation blocks while maintaining joint liability under their parent gatekeeper nodes. 8.4. Namespace and Curation Security Root namespace registration within the global directory requires a verifiable Proof-of-Work burn transaction. Sub-namespace delegation enforces signed cryptographic certificates carrying deterministic curator identity records to ensure binding accountability. Gebauer Expires 26 December 2026 [Page 48] Internet-Draft IACP June 2026 Decentralized protocol enforcement is achieved via verifiable Proof of Malfeasance (PoM) tickets routed to a Two-Phase Slashing Escrow (2PSE) network layer, enabling automated curator quarantine and identity decapitation sequences. If a top-level curation coordinate suffers key compromise, the underlying network isolates the affected zone and executes a hot-docking sequence to transition traffic to authenticated backup root systems. 8.5. Mobility, Churn, and Forwarding Tokens Dynamic network migration utilizes signed ERP_REDIRECT frames and authenticated forwarding records committed via ERP_REGISTRATION packets. These entries are versioned using monotonically increasing Generation Counters. Receiving routers discard stale or replayed topological propagation updates through generation index validation. During a node's challenged escrow validation phase, the initiating endpoint engages a degraded multi-path fragmentation and mirroring routing pipeline to maintain session availability despite intermediary path degradation. 8.6. Privacy Considerations EIDs operate as long-lived logical pseudonyms and do not expose deterministic bindings to real-world network identities or underlying physical locators. The anonymous discovery mechanism permits querying entities to access target coordinates using ephemeral key exchanges combined with standalone PoW tokens, isolating search metadata from persistent tracking graphs. Active Ephemeral State Endpoints (ESE) remain structurally hidden from directory indexes by default and accept resolution requests exclusively from authenticated peers holding valid contract permissions. Local Points (LP) are restricted to local process memory structures and cannot be accessed from public network boundaries unless a local routing rule explicitly bridges the endpoint to a Global Point (GP) coordinate. 8.7. Residual Risks and Recommendations Implementations MUST enforce strict state machine transitions and zero-allocation parsing boundaries defined in Section 6 to prevent memory exhaustion profiles. QUIC is RECOMMENDED as the underlying transport protocol layer to provide native stream multiplexing and rapid connection migration. Gebauer Expires 26 December 2026 [Page 49] Internet-Draft IACP June 2026 Where application-layer transactions demand end-to-end confidentiality extensions beyond the native encapsulation boundaries provided by this specification, deployments SHOULD wrap transport channels in secondary lower-layer cryptographic encapsulations, including IPsec or TLS network segmentation. No cryptographic primitives with known structural vulnerabilities are permitted by this specification. All asymmetric signature verification and symmetric encryption mechanisms rely exclusively on Ed25519 and AES-GCM-256 primitives backed by cryptographically strong pseudo-random number generation (CSPRNG) and strict nonce serialization. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [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, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. Henderson, "Host Identity Protocol Version 2 (HIPv2)", RFC 7401, DOI 10.17487/RFC7401, April 2015, . [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May 2021, . 9.2. Informative References [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 2011, . Gebauer Expires 26 December 2026 [Page 50] Internet-Draft IACP June 2026 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, DOI 10.17487/RFC2782, February 2000, . [RFC8288] Nottingham, M., "Web Linking", RFC 8288, DOI 10.17487/RFC8288, October 2017, . [RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019, . [RFC2697] Heinanen, J. and R. Guerin, "A Single Rate Three Color Marker", RFC 2697, DOI 10.17487/RFC2697, September 1999, . [Kademlia] Maymounkov, P. and D. Mazieres, "Kademlia: A Peer-to-Peer Information System Based on the XOR Metric", IPTPS 2002, 2002. [Hashcash] Back, A., "Hashcash - A Denial of Service Counter- Measure", Whitepaper 2002, 2002. [Wooldridge] Wooldridge, M., "An Introduction to Multi-Agent Systems", Publisher John Wiley & Sons, 2009. [Nygard] Nygard, M. T., "Release It!: Design and Deploy Production- Ready Software", Publisher Pragmatic Bookshelf, 2018. [NIST207] Rose, S., Borchert, O., Mitchell, S., and S. Connelly, "Zero Trust Architecture", NIST Special Publication 800-207, 2020. Appendix A. Appendix A: Wire Formats of the IACP 1.) DISCOVERY_REQ (Type 0x01) Gebauer Expires 26 December 2026 [Page 51] Internet-Draft IACP June 2026 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| Type (0x01) | Flags | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Target Space Coordinate (DHT Key) | | (SHA-256) [32 Bytes] | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Ephemeral Public Key (X25519) [32 Bytes] | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Timestamp / Replay Nonce [8 Bytes] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Proof-of-Work Nonce [8 Bytes] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PoW Target Threshold [4 Bytes] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2.) DISCOVERY_RES (Type 0x02) 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| Type (0x02) | Flags | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Responder Ephemeral Public Key (X25519) [32B] | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | AEAD Nonce / IV [12 Bytes] | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Encrypted Payload | | (True EID [32B] + AEAD Auth Tag [16B]) [48 Bytes] | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3.) ACCESS_TICKET_REQ (Type 0x03) Gebauer Expires 26 December 2026 [Page 52] Internet-Draft IACP June 2026 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| Type (0x03) | Flags | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Requestor EID [32 Bytes] | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Target Space Coordinate (DHT Key) [32 Bytes] | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Timestamp / Replay Nonce [8 Bytes] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Digital Signature (Ed25519) [64 Bytes] | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4.) ACCESS_TICKET_RES (Type 0x04) 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| Type (0x04) | Flags | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Target Space Coordinate (DHT Key) [32 Bytes] | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Receiver EID [32 Bytes] | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Expiration Timestamp [8 Bytes] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Curator Digital Signature (Ed25519) [64B] | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5.) DHT_TICKET_STORE (Type 0x05) Gebauer Expires 26 December 2026 [Page 53] Internet-Draft IACP June 2026 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| Type (0x05) | Flags | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Target Storage Key (SHA-256) [32 Bytes] | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Target Agent EID [32 Bytes] | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time-to-Live (TTL) [4 Bytes] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | AEAD Nonce / IV [12 Bytes] | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Encrypted Forwarding Data [36 Bytes] | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Owner Digital Signature (Ed25519) [64B] | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6.) DHT_TICKET_QUERY (Type 0x06) 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| Type (0x06) | Flags | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Target Storage Key (SHA-256) [32 Bytes] | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Transaction ID / Nonce [8 Bytes] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Requestor EID [32 Bytes] | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7.) DHT_TICKET_RESP (Type 0x07) Gebauer Expires 26 December 2026 [Page 54] Internet-Draft IACP June 2026 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| Type (0x07) | Flags | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Transaction ID / Nonce [8 Bytes] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status / Error Code [4 Bytes] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | AEAD Nonce / IV [12 Bytes] | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Encrypted Forwarding Data [36 Bytes] | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Owner Digital Signature (Ed25519) [64B] | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8.) PSS_INIT (Type 0x08) 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| Type (0x08) | Flags | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Initiator EID [32 Bytes] | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Session Connection Cookie [8 Bytes] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Initial Sequence / Vector Clock [8 Bytes] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Session Capabilities & Extension Flags [4 Bytes] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Initiator Digital Signature (Ed25519) [64B] | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 9.) PSS_ACK (Type 0x09) Gebauer Expires 26 December 2026 [Page 55] Internet-Draft IACP June 2026 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| Type (0x09) | Flags | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Responder EID [32 Bytes] | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Session Connection Cookie [8 Bytes] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Responder Initial Sequence Number [8 Bytes] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Agreed SFC Capabilities [4 Bytes] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Responder Digital Signature (Ed25519) [64B] | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 10.) PSS_NEG (Type 0x0A) 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| Type (0x0A) | Flags | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Session Connection Cookie [8 Bytes] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Negotiation Turn Counter | Rejection Reason Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Proposed SFC Conditions Block [32 Bytes] | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Sender Digital Signature (Ed25519) [64B] | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 11.) PSS_DATA_STREAM (Type 0x0B) Gebauer Expires 26 December 2026 [Page 56] Internet-Draft IACP June 2026 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| Type (0x0B) | Flags | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Session Connection Cookie [8 Bytes] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number [8 Bytes] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AEAD Nonce / IV [12 Bytes] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Encrypted ANML Payload (Variable) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 12.) PSS_TEARDOWN (Type 0x0C) 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| Type (0x0C) | Flags | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Session Connection Cookie [8 Bytes] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Teardown Type | Reason Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Proof of Malfeasance Length [4 Bytes] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Sender Digital Signature (Ed25519) [64B] | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Optional: Proof of Malfeasance Data (Variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 13.) PSS_REVOCATION_PUBLISH (Type 0x0D) Gebauer Expires 26 December 2026 [Page 57] Internet-Draft IACP June 2026 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| Type (0x0D) | Flags | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Target Storage Key (SHA-256) [32 Bytes] | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Offender EID [32 Bytes] | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Proof of Malfeasance Length [4 Bytes] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Reporter Digital Signature [64 Bytes] | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Proof of Malfeasance Data (Variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 14.) ERP_DEFLECT (Type 0x0E) 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| Type (0x0E) | Flags | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Original Target Locator (16 Bytes) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Original Target Port (2B) | Deflection-Routing-TTL (1B) | Res | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Inner Agent Payload ... | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 15.) Outer Transport Header (Type 0x0F) Gebauer Expires 26 December 2026 [Page 58] Internet-Draft IACP June 2026 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Outer Type (0x0F) | Flags | Transit-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | IP_Transit_Token [32 Bytes] | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | LL-Entity Instance Identifier (LII) [32B] | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | LIK Transit Signature (Ed25519) [64 Bytes] | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Inner ERP / IACP / PSS Payload (variable) | | | +---------------------------------------------------------------+ 16.) ANML Fallback Query (Type 0x12) 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| Type (0x12) | Flags | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Legacy Target URI (Variable) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Requestor EID [32 Bytes] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Transaction Nonce [8 Bytes] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Digital Signature (Ed25519) [64 Bytes] | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 17.) PSS_REVOCATION_REBUTTAL (Type 0x13) Gebauer Expires 26 December 2026 [Page 59] Internet-Draft IACP June 2026 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| Type (0x13) | Flags | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Target Storage Key (SHA-256) [32 Bytes] | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Offender EID [32 Bytes] | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Rebuttal Proof Length [4 Bytes] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Rebuttal Evidence Data (Variable) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Sender Digital Signature [64 Bytes] | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 18.) ERP_INIT (Type 0x11) 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| Type (0x11) | Flags | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Initialization Nonce [32 Bytes] | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 19.) ERP_ALLOC (Type 0x14) Gebauer Expires 26 December 2026 [Page 60] Internet-Draft IACP June 2026 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| Type (0x14) | Flags | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Initialization Nonce [32 Bytes] | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Allocated EID [32 Bytes] | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Local_IAT [32 Bytes] | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 20.) ERP_REGISTER (Type 0x15) 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| Type (0x15) | Flags | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Source EID [32 Bytes] | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Current Transport IP [16 Bytes] | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Generation Counter [8 Bytes] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Digital Signature (Ed25519) [64 Bytes] | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 21.) ERP_EVOLVE (Type 0x16) Gebauer Expires 26 December 2026 [Page 61] Internet-Draft IACP June 2026 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| Type (0x16) | Flags | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Target EID [32 Bytes] | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Previous App-Digest [32 Bytes] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Current App-Digest [32 Bytes] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Evolution Sequence Number [8 Bytes] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AIRK Signature (Ed25519) [64 Bytes] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 22.) MIGRATION_VECTOR (Type 0x17) 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV Type (0x17) | TLV Length | IP Version | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Previous_Transport_IP | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Current_Transport_IP | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Migration_Nonce [8 Bytes] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 23.) PROOF_OF_MAL (Type 0x18) Gebauer Expires 26 December 2026 [Page 62] Internet-Draft IACP June 2026 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 | Offense Type Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Target Malicious Node Identity (EID) [32B] | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Conflicting Signed Message Digest A [32B] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Conflicting Signed Message Digest B [32B] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Accusing Node Cryptographic Signature [64B] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Appendix B. Appendix B: State Machines and Transition Diagrams of the IACP To establish verifiable security bounds against resource exhaustion, the initial IACP Discovery and Session Allocation subsystem is formalized as a Deterministic Finite Automaton (DFA), denoted by the 5-tuple: M_disc = (S, \Sigma, \delta, s_0, F) Where the constituent sets and mappings are defined as follows: 1. S is the finite set of non-overlapping session allocation states: S = { LISTEN, VALIDATING_POW, AWAIT_IDENTITY, PSS_NEGOTIATING, ESTABLISHED } 2. \Sigma is the input alphabet consisting of network events and cryptographic triggers: \Sigma = { RX_DISCOVERY_REQ, POW_FAILURE, POW_SUCCESS, RX_PSS_INIT_(SFC=1), RX_PSS_INIT_(SFC=0), IDENTITY_TIMEOUT } 3. s_0 in S is the unique, zero-allocation initial state: s_0 = LISTEN 4. F subset of S is the set of final accepting operational states: F = { PSS_NEGOTIATING, ESTABLISHED } 5. delta: S x Sigma -> S is the deterministic state transition function, defined by the following exact mappings: Gebauer Expires 26 December 2026 [Page 63] Internet-Draft IACP June 2026 delta(LISTEN, RX_DISCOVERY_REQ) = VALIDATING_POW delta(VALIDATING_POW, POW_FAILURE) = LISTEN delta(VALIDATING_POW, POW_SUCCESS) = AWAIT_IDENTITY delta(AWAIT_IDENTITY, RX_PSS_INIT_(SFC=1))= PSS_NEGOTIATING delta(AWAIT_IDENTITY, RX_PSS_INIT_(SFC=0))= ESTABLISHED delta(AWAIT_IDENTITY, IDENTITY_TIMEOUT) = LISTEN *Resource Invariant Guarantee:* By formalizing the alphabet mapping such that delta(LISTEN, RX_DISCOVERY_REQ) yields a state transition where RAM = 0, the automaton proves that zero-state context is allocated before verified PoW validation. State elevation to memory- retaining structures is bound strictly to the execution of delta(VALIDATING_POW, POW_SUCCESS). 1.) Discovery and Session Allocation DFA (Zero-Allocation State) +-----------------------+-----------------------+---------------------+ | Current State | Event (Input) | Next State | +-----------------------+-----------------------+---------------------+ | LISTEN | RX_DISCOVERY_REQ | VALIDATING_POW | | | (Anonymous packet) | | +-----------------------+-----------------------+---------------------+ | VALIDATING_POW | POW_FAILURE | LISTEN | | | (Invalid nonce or | | | | expired timestamp) | | +-----------------------+-----------------------+---------------------+ | VALIDATING_POW | POW_SUCCESS | AWAIT_IDENTITY | | | (Valid cryptographic | | | | proof-of-work) | | | | | | +-----------------------+-----------------------+---------------------+ | AWAIT_IDENTITY | RX_PSS_INIT | PSS_NEGOTIATING | | | (SFC_REQUESTED = 1) | | | | | | +-----------------------+-----------------------+---------------------+ | AWAIT_IDENTITY | RX_PSS_INIT | ESTABLISHED | | | (SFC_REQUESTED = 0) | | | | | | +-----------------------+-----------------------+---------------------+ | AWAIT_IDENTITY | IDENTITY_TIMEOUT | LISTEN | | | (No valid PSS_INIT | | | | within 500ms window) | | +-----------------------+-----------------------+---------------------+ 2.) Local ERP Context Lifecycle (LL-Entity) Gebauer Expires 26 December 2026 [Page 64] Internet-Draft IACP June 2026 +-----------------------+-----------------------+----------------------+ | Current State | Event (Input) | Next State | +-----------------------+-----------------------+----------------------+ | UNBOUND | ERP_INIT (0x11) | ALLOCATED | +-----------------------+-----------------------+----------------------+ | ALLOCATED | ERP_ALLOC (0x14) | ALLOCATED | +-----------------------+-----------------------+----------------------+ | ALLOCATED | ERP_REGISTER (0x15) | TRANSITION | +-----------------------+-----------------------+----------------------+ | TRANSITION | DHT Confirmation | BOUND | +-----------------------+-----------------------+----------------------+ | BOUND | Network Churn | TRANSITION | +-----------------------+-----------------------+----------------------+ | BOUND | App Digest Change | EVOLVE_PENDING | +-----------------------+-----------------------+----------------------+ 3.) Dynamic Circuit Breaker +-----------------+-----------------------+---------------------------+ | Current State | Event (Input) | Next State | +-----------------+-----------------------+---------------------------+ | CLOSED | RX_REQUEST_WITH_TICKET| CLOSED | | | | | +-----------------+-----------------------+---------------------------+ | CLOSED | TRAFFIC_SPIKE | OPEN | | | (Anomalous peak in | | | | namespace sub-tree) | | +-----------------+-----------------------+---------------------------+ | OPEN | RX_REQ_FROM_FLAGGED | OPEN | | | (Request from flagged | | | | namespace tree branch)| | +-----------------+-----------------------+---------------------------+ | OPEN | COOLDOWN_TIMEOUT | CLOSED | | | (Traffic returns to | | | | baseline limits) | | +-----------------+-----------------------+---------------------------+ | OPEN | RX_ACCESS_TICKET | OPEN | | | (Valid ticket parsed | | | | during open state) | | +-----------------+-----------------------+---------------------------+ 4.) Ongoing Session & Continuity (PSS & SFC Lifecycle FSM) Gebauer Expires 26 December 2026 [Page 65] Internet-Draft IACP June 2026 +-----------------+-----------------------+---------------------------+ | Current State | Event (Input) | Next State | +-----------------+-----------------------+---------------------------+ | PSS_NEGOTIATING | SFC_EFFECTIVE | ESTABLISHED | | | (Contract signed & | | | | validated by peers) | | +-----------------+-----------------------+---------------------------+ | ESTABLISHED | RX_OUT_OF_ORDER | ANOMALY_FLAGGED | | | (Historical payload or| | | | gap in packet index) | | +-----------------+-----------------------+---------------------------+ | ANOMALY_FLAGGED | ANOMALY_CLEARED | ESTABLISHED | | | (Valid sequence re-syn| | | | chronization achieved)| | +-----------------+-----------------------+---------------------------+ | ESTABLISHED/ | HEARTBEAT_FAIL | SESSION_ | | ANOMALY_FLAGGED | (Invalid signature or | COMPROMISED | | | unauthorized access) | | +-----------------+-----------------------+---------------------------+ | ESTABLISHED | QUIC_CONN_CLOSE | DISCONNECTED | | | (Unexpected transport | | | | drop or timeout) | | +-----------------+-----------------------+---------------------------+ | DISCONNECTED | PEER_RECONNECT | RECONCILING | | | (Re-authenticating via| | | | short-lived tokens) | | +-----------------+-----------------------+---------------------------+ | RECONCILING | STATE_VECTORS_MATCH | ESTABLISHED | | | (Delta log application| | | | successful) | | +-----------------+-----------------------+---------------------------+ 5.) Curator Quarantine Gebauer Expires 26 December 2026 [Page 66] Internet-Draft IACP June 2026 +-----------------------+-----------------------+---------------------+ | Current State | Event (Input) | Next State | +-----------------------+-----------------------+---------------------+ | ESTABLISHED | RX_REVOCATION_TICKET | CURATOR_QUARANTINE | | | (Validated PoM match) | | +-----------------------+-----------------------+---------------------+ | CURATOR_QUARANTINE | QUARANTINE_EXPIRED | EVICTED_PEER | | | (No counter-proof) | | | | | | +-----------------------+-----------------------+---------------------+ | CURATOR_QUARANTINE | RX_COUNTER_PROOF | ESTABLISHED | | | (Valid signature) | | | | | | +-----------------------+-----------------------+---------------------+ | EVICTED_PEER | CLEANUP_COMPLETE | LISTEN | | | (Internal trigger) | | +-----------------------+-----------------------+---------------------+ 6.) The 4-Stage Security & Revocation Model +---------------------+-----------------------+-----------------------+ | Current State | Event (Input) | Next State | +---------------------+-----------------------+-----------------------+ | SESSION_COMPROMISED | VALIDATE_ANOMALY | EMERGENCY_ | | | (Malicious behavior | REVOCATION | | | deterministically proven) | +---------------------+-----------------------+-----------------------+ | EMERGENCY_ | POM_GENERATED | PROPAGATING_WARN | | REVOCATION | (Proof of Malfeasance | | | | block fully compiled) | | +---------------------+-----------------------+-----------------------+ | ACTIVE_CURATOR | CERT_CONTRADICTION | QUARANTINE | | (Curator Node Only) | (Conflicting signed | | | | claims discovered) | | +---------------------+-----------------------+-----------------------+ | QUARANTINE | MALFEASANCE_PROVEN | PERMANENT_ | | (Curator Node Only) | (Deliberate double- | DECAPITATION | | | signing verified) | | +---------------------+-----------------------+-----------------------+ | QUARANTINE | QUARANTINE_TIMEOUT | ACTIVE_CURATOR | | (Curator Node Only) | (Grace period expiry | (Curator Node Only) | | | without hard evidence)| | +---------------------+-----------------------+-----------------------+ | ACTIVE_CURATOR/ | CURATOR_FLAGGED | AUTOMATED_EMERGENCY_ | | QUARANTINE | (Parent curator enters| MIGRATION | | (Sub-Space Nodes) | compromised state) | | +---------------------+-----------------------+-----------------------+ Gebauer Expires 26 December 2026 [Page 67] Internet-Draft IACP June 2026 7.) General IACP Workflow (DHI + ERP Integration) +-----------------------+-----------------------+---------------------+ | Current State | Event (Input) | Next State | +-----------------------+-----------------------+---------------------+ | INPUT_RECEIVED | INITIATE_RESOLVE | RESOLVING_INFRA | +-----------------------+-----------------------+---------------------+ | RESOLVING_INFRA | DNS_SUCCESS | WELL_KNOWN_EVAL | +-----------------------+-----------------------+---------------------+ | WELL_KNOWN_EVAL | ENDPOINT_UNREACHABLE | PROBLEM_CACHING | +-----------------------+-----------------------+---------------------+ | WELL_KNOWN_EVAL | ENDPOINT_RESPONSIVE | LINK_HEADER_SNIFF | +-----------------------+-----------------------+---------------------+ | SWITCH_POINT | HEAVY_MEDIA | LEGACY_PATH_EXECUTION| +-----------------------+-----------------------+---------------------+ | SWITCH_POINT | PURE_DATA_STREAM | NATIVE_ANML_INGESTION| +-----------------------+-----------------------+---------------------+ | BOUND | Routing Failure | ERP_DEFLECT (0x0E) | +-----------------------+-----------------------+---------------------+ Appendix C. Appendix C: ASCII-Diagrams of the IACP 1.) Simplified Agent2Agent Communication via IACP +------------------+ +-------------------+ | Host A: IP_1 | | Host B: IP_2 | +------------------+ +-------------------+ | | | Hosts (Persistent) | Hosts v v +------------------+ +-------------------+ | Node A: EID_1 | | Node B: EID_2 | +------------------+ +-------------------+ | | | Hosts (Ephemeral) | Hosts v v +------------------+ +-------------------+ | Endpoint: ESE_1 | <========= PSS ========> | Endpoint: ESE_2 | +------------------+ (maybe with a SFC) +-------------------+ Appendix D. Acknowledgments The author would like to thank Aaron Jerskey from the ANML Foundation for their valuable feedback on this specification. Author's Address Gebauer Expires 26 December 2026 [Page 68] Internet-Draft IACP June 2026 Leonard Gebauer Independent Germany Email: leonard.gebauer.ha@gmail.com Gebauer Expires 26 December 2026 [Page 69]