IETF Internet-Draft: Pilot Protocol Files Agent Network Spec

Pilot Protocol has an IETF Internet-Draft on file. Two documents - a problem statement and a full protocol specification - are live on the IETF Datatracker, the formal record for internet protocol proposals. Here is what each one covers and what filing actually means.

draft-teodor-pilot-protocol-01

What We Submitted

We submitted two Internet-Drafts to the IETF (Internet Engineering Task Force) - the organization that standardizes protocols like TCP, HTTP, TLS, and QUIC. Both are now live on the IETF Datatracker:

• Problem Statement - why agents need network-layer infrastructure (Informational)
• Protocol Specification - full wire spec in IETF format (Experimental)

This is an individual submission to the independent stream. It does not (yet) carry IETF consensus - it is a formal public statement that this problem exists and here is one solution.

Why the IETF

The IETF has seen a surge of AI agent protocol drafts in 2025-2026. Over a dozen have been filed - rosenberg-aiproto-framework, zyyhl-agent-networks-framework, narvaneni-agent-uri, and others. Every single one operates at the application layer over HTTP.

Nobody is addressing the network and transport layer for agents. That is the exact space Pilot Protocol occupies. We are the only protocol that gives agents virtual addresses, encrypted UDP tunnels, NAT traversal, port-based services, and a bilateral trust model - below the application layer, where MCP and A2A operate.

The positioning is simple: A2A defines what agents say to each other. Pilot defines how they reach each other. See how this plays out concretely in connecting MCP servers across agents and in our comparison of Pilot against TCP, gRPC, and NATS.

The Problem Statement

Modeled after RFC 7364 (the NVO3 Problem Statement that led to VXLAN and GENEVE), our problem statement identifies five gaps:

1. Agent identity is coupled to infrastructure. Agents are identified by URLs and DNS names - tied to servers, not to the agent itself. When an agent migrates, its identity breaks.
2. No P2P communication without web infrastructure. MCP and A2A require HTTP endpoints. 88% of real-world networks involve NAT. Agents behind firewalls simply cannot participate.
3. No agent-native trust model. TLS trusts CAs. SSH trusts on first use (with a human verifying). Neither fits autonomous entities that need bilateral consent.
4. No lightweight transport for agent streams. TCP and QUIC are designed for web traffic patterns. Agents need long-lived streams, port-based service multiplexing, and low connection overhead.
5. Privacy gaps in discovery. A2A Agent Cards are designed to be publicly discoverable. For agents, the default should be invisible.

The document defines 11 formal requirements (REQ-1 through REQ-11) and analyzes gaps in seven existing approaches: MCP, A2A, WebRTC, QUIC, libp2p, WireGuard, and LISP.

The Protocol Specification

The protocol spec is a 45-page document that converts our wire specification and whitepaper into IETF format. It covers:

• Addressing - 48-bit virtual addresses (16-bit network + 32-bit node), text representation, special addresses
• Packet format - 34-byte fixed header with ASCII art diagrams, field definitions, protocol types, flag definitions
• Tunnel encapsulation - four frame types (PILT plaintext, PILS encrypted, PILK key exchange, PILA authenticated key exchange)
• Session layer - connection state machine, three-way handshake, reliable delivery with sliding window, SACK, congestion control (AIMD per RFC 5681/6298/6928), flow control, Nagle's algorithm
• NAT traversal - STUN-based discovery, hole punching, transparent relay fallback
• Security - Ed25519 identities, X25519 + AES-256-GCM tunnel encryption, authenticated key exchange, bilateral trust handshake, privacy-by-default discovery
• Nonce management - random prefix + monotonic counter construction, session lifecycle, counter exhaustion analysis
• Version negotiation - SYN version handshake, unknown version handling, future extensibility
• Path MTU considerations - encapsulation overhead calculation, effective payload analysis, MSS recommendations
• IANA considerations - requested registries for tunnel magic values, protocol types, and well-known ports
• Implementation status - Go reference implementation (226+ tests, 5 GCP regions), Python SDK on PyPI

What This Means

Filing an Internet-Draft does not make Pilot an IETF standard. The path from I-D to RFC is long - it requires external reviews, IESG conflict review, and typically multiple revisions over months to years.

What it does:

• Public record. The problem and the solution are now on the IETF Datatracker, permanently, with a formal document name that can be cited by other drafts and papers.
• Visibility. Anyone working on AI agent protocols at the IETF will find these documents. The problem statement frames why a network-layer solution is needed - which no one else has articulated.
• Credibility. "We submitted an IETF Internet-Draft" is a different conversation than "we built a thing." The IETF process demands rigor - proper references, security considerations, IANA registrations.
• Foundation. If this gains traction, it could lead to a BoF (Birds of a Feather) session at an IETF meeting, potentially a working group, and eventually an RFC.

Spec Improvements

Preparing the IETF drafts revealed three gaps in our specification that we've now addressed:

• Version negotiation - how nodes handle version mismatches in SYN packets, what to do with unknown versions, future extensibility rules
• Path MTU considerations - encapsulation overhead calculation (70 bytes for encrypted frames), effective payload per MTU, MSS recommendations for different deployment environments
• Nonce management - formal documentation of the random-prefix + monotonic-counter nonce construction, session lifecycle, and counter exhaustion bounds (2^64 packets per session)

These sections are now part of the wire specification (Sections 8, 9, and 10).

Review and Feedback

We welcome technical review of both drafts. If you have expertise in overlay networking, agent communication protocols, or IETF process, we'd appreciate your feedback:

• Email: teodor@vulturelabs.com
• Subject line: draft-teodor-pilot-protocol review or draft-teodor-pilot-problem-statement review

We're particularly interested in feedback on the security considerations, the relationship to QUIC, and whether the problem statement adequately motivates the need for a network-layer solution.

For the underlying mechanics referenced across both drafts, see how NAT traversal works in practice in our NAT traversal deep dive.