| Internet-Draft | Agent Network Problem Statement | March 2026 |
| Teodor | Expires 15 September 2026 | [Page] |
AI agents --- autonomous software entities capable of reasoning, planning, and executing tasks --- are an increasingly important class of network participant. Current agent communication protocols operate exclusively at the application layer over HTTP, assuming the existence of stable endpoints, DNS names, and centralized infrastructure. No existing standard provides network-layer identity, addressing, or transport for agents. This document describes the problem space and identifies requirements for a network-layer infrastructure that would give agents first-class network citizenship, independent of the web infrastructure designed for human users.¶
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 15 September 2026.¶
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.¶
The internet's protocol stack was designed for human-operated devices with stable network attachments. IP addresses identify interfaces, DNS names identify services, and TLS certificates identify organizations. These assumptions break down for AI agents, which are transient software processes that may run behind NAT, migrate between hosts, and lack persistent network identity.¶
Recent standardization efforts for agent communication --- notably MCP [MCP] (agent-to-tool) and A2A [A2A] (agent-to-agent) --- have focused on application-layer protocols built on HTTP. These protocols define what agents say to each other but assume the underlying problem of how agents reach each other is already solved. For agents running in cloud environments with public endpoints, this assumption holds. For agents running on edge devices, behind corporate firewalls, on laptops, or in heterogeneous multi-cloud deployments, it does not.¶
The IETF has seen significant activity in AI agent protocol standardization, with over a dozen drafts filed in 2025-2026 (see [I-D.rosenberg-aiproto-framework], [I-D.zyyhl-agent-networks-framework], [I-D.narvaneni-agent-uri]). Every one of these drafts operates at the application layer over HTTP. None addresses the network or transport layer.¶
This document describes the problem of network-layer infrastructure for autonomous agent communication, identifies the gaps in existing protocols, and states requirements for a solution. It is modeled after [RFC7364], which performed a similar analysis for network virtualization overlays.¶
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.¶
An autonomous software entity capable of reasoning, planning, and executing tasks without continuous human supervision. An agent may run as a process, container, or serverless function.¶
A virtual network built on top of an existing network (the underlay). Overlay nodes communicate using encapsulated packets carried over the underlay.¶
A network address assigned within the overlay address space, independent of the underlay IP address. A virtual address identifies an agent, not a network interface.¶
A service that assigns virtual addresses, maintains an address-to-locator mapping table, and provides bootstrap information for overlay participants.¶
A protocol exchange through which two agents establish a bilateral trust relationship with explicit mutual consent.¶
In current practice, agents are identified by URLs, DNS names, or API endpoints --- all of which are tied to the infrastructure hosting the agent, not to the agent itself. When an agent migrates to a different host, changes cloud provider, or restarts behind a different NAT binding, its identity changes. There is no stable identifier that follows an agent across these transitions.¶
This is analogous to the identity/locator conflation problem in IP networking, which motivated the Locator/ID Separation Protocol (LISP) [RFC9300]. In LISP, Endpoint Identifiers (EIDs) are separated from Routing Locators (RLOCs) so that an endpoint's identity is independent of its network attachment point. Agents need the same separation: a permanent identity that is independent of the transient infrastructure hosting them.¶
The A2A protocol [A2A] identifies agents via "Agent Cards" served at well-known HTTPS URLs. This requires the agent to maintain a stable, publicly reachable web endpoint --- a requirement that excludes agents running on edge devices, behind NAT, or in ephemeral compute environments.¶
Both MCP [MCP] and A2A [A2A] require HTTP endpoints for communication. This means every agent must either have a publicly routable IP address or be fronted by a reverse proxy, load balancer, or API gateway. For two agents behind NAT to communicate, at least one must provision web infrastructure as an intermediary.¶
NAT traversal is a solved problem for specific domains: WebRTC handles it for browsers (at the cost of ICE/DTLS-SRTP/SDP negotiation complexity), and WireGuard [WIREGUARD] handles it for VPN tunnels. But no existing protocol provides NAT traversal specifically designed for agent-to-agent communication, with agent-native addressing and trust semantics.¶
An estimated 88% of real-world network environments involve some form of NAT. Agents running on laptops, IoT devices, edge servers, and mobile phones cannot participate in HTTP-based agent protocols without significant infrastructure provisioning.¶
Existing trust models were designed for different participants:¶
TLS: Trust is anchored in Certificate Authorities. Agents would need to obtain and manage X.509 certificates, adding operational complexity disproportionate to many agent interactions.¶
SSH: Trust-on-first-use (TOFU) assumes a human operator who can verify a host key fingerprint. Autonomous agents have no human in the loop.¶
OAuth/OIDC: Designed for user-to-service authorization, not peer-to-peer agent trust. Requires an authorization server as a trusted third party.¶
None of these models provide bilateral consent --- the property that both parties must explicitly agree before a communication relationship is established. For autonomous entities that may be operated by different organizations, bilateral consent is a natural trust primitive: neither agent should be reachable by the other until both have agreed.¶
TCP and QUIC [RFC9000] are general-purpose transports optimized for web traffic patterns (request-response, large transfers, multiplexed streams). Agent communication patterns differ:¶
Many agents exchange small, frequent messages (status updates, task delegations, sensor readings) where connection setup overhead dominates.¶
Agents often maintain long-lived bidirectional streams for event-driven architectures, where TCP's head-of-line blocking is problematic.¶
Agents may need port-based service multiplexing (echo on one port, task submission on another, events on a third) --- a concept that exists in TCP/UDP but has no equivalent in HTTP-based agent protocols.¶
While QUIC addresses head-of-line blocking through multiplexed streams, it does not provide agent addressing, discovery, or trust semantics. A transport designed for agents could provide these as built-in capabilities rather than requiring them to be layered on top.¶
Current agent discovery mechanisms are designed for visibility:¶
A2A Agent Cards are intended to be publicly discoverable at well-known URLs.¶
DNS-SD and mDNS broadcast service availability to all listeners on a network segment.¶
HTTP-based service registries typically allow any authenticated client to enumerate all registered services.¶
For agents, the default should be the opposite. An agent's existence and capabilities should not be disclosed to parties that have not been explicitly authorized. Mass enumeration of agent endpoints creates attack surface (reconnaissance for exploitation) and privacy risks (mapping an organization's agent infrastructure).¶
A privacy-by-default discovery model --- where agents are invisible until they explicitly opt in to specific peer relationships --- has no equivalent in current standards.¶
Based on the problems identified above, a network-layer infrastructure for agent communication should satisfy the following requirements:¶
Agents MUST receive stable virtual addresses that are independent of their underlying IP address, network attachment point, and hosting infrastructure.¶
The addressing scheme MUST support hierarchical grouping (e.g., network or topic-based segmentation) to enable scoped communication boundaries.¶
The system MUST provide automatic NAT traversal without requiring manual configuration of port forwarding, firewall rules, or relay proxies by the agent operator.¶
NAT traversal MUST support direct peer-to-peer communication where possible, with transparent relay fallback when direct communication is not achievable.¶
The transport MUST provide reliable, ordered byte stream delivery (TCP-equivalent) and unreliable datagram delivery (UDP-equivalent) over the overlay.¶
Encryption MUST be enabled by default for all data in transit, with no opt-in required from the agent developer.¶
The transport MUST support port-based service multiplexing, allowing an agent to expose multiple services on different virtual ports.¶
Agents MUST be private by default. An agent's virtual address, physical locator, and capabilities MUST NOT be disclosed to parties without an established trust relationship or shared group membership.¶
It MUST be possible to establish trust with a private agent without first knowing its physical network location (i.e., via a trusted relay or rendezvous mechanism).¶
MCP [MCP] standardizes the interface between AI models and external tools/resources. It uses JSON-RPC over HTTP with Server-Sent Events for streaming. MCP addresses agent-to-tool communication, not agent-to-agent communication, and provides no network-layer capabilities. It assumes agents can reach tool servers via HTTP.¶
A2A [A2A] defines a protocol for agent interoperability: Agent Cards for discovery, task lifecycle management, and multimodal message exchange. A2A operates entirely over HTTP/HTTPS. It provides no NAT traversal, no overlay addressing, no built-in encryption beyond TLS, and no bilateral trust model. It assumes agents have reachable HTTP endpoints.¶
WebRTC provides peer-to-peer communication with NAT traversal via ICE, encryption via DTLS-SRTP, and data channels via SCTP. However, WebRTC was designed for browser-based audio/video communication. Its complexity (ICE candidate gathering, SDP offer/answer negotiation, DTLS-SRTP key exchange) is disproportionate for agent message exchange. WebRTC also lacks agent-specific concepts like virtual addressing, bilateral trust, and privacy-by-default discovery.¶
QUIC [RFC9000] provides a modern transport with multiplexed streams, built-in encryption, and reduced connection setup latency. QUIC addresses transport-layer concerns but does not provide overlay addressing, agent identity, NAT traversal coordination, trust management, or discovery. It is a potential underlay transport for an agent overlay, not a complete solution.¶
libp2p [LIBP2P] is a modular networking stack developed for decentralized applications, particularly in the blockchain ecosystem. It provides peer identity (via cryptographic keypairs), NAT traversal, and transport multiplexing. libp2p is the closest existing system to the requirements stated above. However, it uses unstructured peer IDs (not hierarchical addresses), is heavyweight (large dependency tree), is oriented toward content-addressed distributed systems rather than agent communication patterns, and lacks built-in bilateral trust or privacy-by- default semantics.¶
WireGuard [WIREGUARD] provides encrypted point-to-point tunnels with excellent performance. It uses Curve25519 for key exchange and ChaCha20- Poly1305 for encryption. WireGuard establishes tunnels between known peers with pre-shared public keys --- it does not provide dynamic discovery, agent addressing, or trust negotiation. It is a VPN, not an agent network.¶
The Locator/ID Separation Protocol [RFC9300] [RFC9301] separates endpoint identity from network location, providing a conceptual precedent for agent addressing. LISP's EID-to-RLOC mapping system is architecturally similar to an agent registry that maps virtual addresses to physical locators. However, LISP operates at the IP layer for routing optimization, not at the application layer for agent communication. It does not provide agent-specific trust models, privacy semantics, or built-in services.¶
A network-layer infrastructure for agents introduces security considerations beyond those of traditional overlay networks:¶
A registry that assigns addresses and maintains locator mappings is a trusted third party. Compromise of the registry could allow address hijacking, locator spoofing, or metadata harvesting. The registry should support authentication, access control, and replication for high availability.¶
Even with payload encryption, overlay packet headers may expose source and destination virtual addresses, port numbers, and packet sizes. Traffic analysis on the overlay is possible even when the underlay is encrypted.¶
A bilateral trust model assumes that agents can make informed consent decisions. If an agent's trust logic is compromised (e.g., by adversarial prompt injection), it may approve trust relationships it should reject. The trust model provides a mechanism, not a policy --- the security of trust decisions depends on the agent's reasoning capability.¶
Overlay encryption requires key exchange between peers. Anonymous key exchange (without identity binding) is vulnerable to man-in-the-middle attacks. Authenticated key exchange requires a mechanism to distribute and verify public keys, which depends on the registry's integrity.¶
This document has no IANA actions.¶
The author thanks the participants of the IETF AI protocols discussions for their contributions to understanding the agent communication landscape.¶