From abce41fc9b4c825e5af124b47cc2bc37fd1c8481 Mon Sep 17 00:00:00 2001 From: pstayets Date: Sun, 16 Aug 2026 19:22:48 -0700 Subject: [PATCH] =?UTF-8?q?blog:=20restore=20IETF=20Internet-Draft=20page?= =?UTF-8?q?=20=E2=80=94=202026=20reframe,=20interlinks?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Signed-off-by: pstayets --- .../a2a-agent-cards-over-pilot-tunnels.astro | 2 +- src/pages/blog/how-pilot-protocol-works.astro | 2 +- .../ietf-internet-draft-pilot-protocol.astro | 126 ++++++++++++++++++ 3 files changed, 128 insertions(+), 2 deletions(-) create mode 100644 src/pages/blog/ietf-internet-draft-pilot-protocol.astro diff --git a/src/pages/blog/a2a-agent-cards-over-pilot-tunnels.astro b/src/pages/blog/a2a-agent-cards-over-pilot-tunnels.astro index 54a3e2d2..0e46c83c 100644 --- a/src/pages/blog/a2a-agent-cards-over-pilot-tunnels.astro +++ b/src/pages/blog/a2a-agent-cards-over-pilot-tunnels.astro @@ -263,7 +263,7 @@ func main() {

Pilot's peer search narrows to agents matching the hostname prefix in the network. A2A's Agent Cards provide the semantic filter -- which of those agents can actually do the specific work needed. This two-layer filtering (network presence, semantic capability) produces better matches than any single discovery mechanism alone.

-

For more on how Pilot's network layer provides the foundation for this kind of integration, see How Pilot Protocol Works. For the complementary pattern using MCP for tool access alongside Pilot networking, see MCP + Pilot: Tools and Network. For a broader protocol comparison, see AI agent communication protocols compared. And for a deeper look at why agents need a dedicated network layer in the first place, see Why AI Agents Need Their Own Network Stack.

+

For more on how Pilot's network layer provides the foundation for this kind of integration, see How Pilot Protocol Works. For the complementary pattern using MCP for tool access alongside Pilot networking, see MCP + Pilot: Tools and Network. For a broader protocol comparison, see AI agent communication protocols compared. And for a deeper look at why agents need a dedicated network layer in the first place, see Why AI Agents Need Their Own Network Stack. For the protocol's formal specification, see Pilot Protocol's IETF Internet-Draft.

diff --git a/src/pages/blog/how-pilot-protocol-works.astro b/src/pages/blog/how-pilot-protocol-works.astro index 871aed8f..81c59dfa 100644 --- a/src/pages/blog/how-pilot-protocol-works.astro +++ b/src/pages/blog/how-pilot-protocol-works.astro @@ -7,7 +7,7 @@ const bodyContent = `

How Pilot Protocol works: it is a UDP o

The problem is that most of them cannot.

-

88% of networks involve NAT. An agent running on a developer's laptop, behind a corporate firewall, inside a Docker container, or on a mobile device has no publicly routable address. It cannot receive incoming connections. It cannot be listed in a service registry. It is invisible to every other agent in the world.

+

Most real-world networks involve NAT. An agent running on a developer's laptop, behind a corporate firewall, inside a Docker container, or on a mobile device has no publicly routable address. It cannot receive incoming connections. It cannot be listed in a service registry. It is invisible to every other agent in the world.

Pilot Protocol is the layer that fixes this. It is a UDP overlay network that gives every AI agent a permanent virtual address, encrypted tunnels through NAT, and a cryptographic trust model -- all in a single binary with no external dependencies.

diff --git a/src/pages/blog/ietf-internet-draft-pilot-protocol.astro b/src/pages/blog/ietf-internet-draft-pilot-protocol.astro new file mode 100644 index 00000000..f06a56f5 --- /dev/null +++ b/src/pages/blog/ietf-internet-draft-pilot-protocol.astro @@ -0,0 +1,126 @@ +--- +import BlogLayout from "../../layouts/BlogLayout.astro"; + +const bodyContent = ` +

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. Together they make a claim no other draft currently makes: that autonomous agents need network-layer infrastructure, and that the gap can be specified in standards form. Here is what each document covers and what filing actually means.

+ +

draft-teodor-pilot-protocol-01

+ +

What We Submitted

+ +

Two Internet-Drafts are live on the IETF Datatracker:

+ +
    +
  • Problem Statement — why agents need network-layer infrastructure (intended status: Informational)
    • +
  • Protocol Specification — the full wire spec in IETF format (intended status: Experimental)
    • +
+ +

This is an individual submission on 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 This Draft Exists: the Agent-Standards Moment

+ +

Agent protocols are having their standards moment. A2A (Agent2Agent) reached version 1.0 and moved into the Linux Foundation, which formed the Agentic AI Foundation to house open agent-interoperability projects. New Internet-Drafts keep arriving at the IETF: a draft for an Agent Name Service proposes domain-anchored identity for agents, and drafts such as aiproto-framework, agent-networks-framework, and agent-uri keep the conversation moving.

+ +

Nearly all of this work operates at the application layer. It defines what agents say to tools, what agents say to each other, and how agents are named and found — over HTTP. What no draft addresses is the layer underneath: network-layer identity, addressing, and transport for agents. That is the space Pilot Protocol occupies.

+ +

To be clear, the application-layer work is doing its job. A2A gives agents a common task lifecycle and Agent Cards; MCP gives models a uniform tool interface; the naming and directory drafts attack discoverability. Those protocols simply assume the endpoints exist. The network layer Pilot specifies is what makes endpoints exist for agents that have no public address — which is most of them.

+ +

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 running A2A Agent Cards over Pilot tunnels 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 the 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. +
  2. No P2P communication without web infrastructure. MCP and A2A require HTTP endpoints. Agents behind NAT and firewalls simply cannot participate.
    3. +
  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. +
  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. +
  5. Privacy gaps in discovery. A2A Agent Cards are designed to be publicly discoverable. For agents, the default should be invisible.
    6. +
+ +

The document defines a set of formal requirements spanning virtual addressing, NAT traversal, a bilateral trust model, lightweight encrypted transport, privacy-by-default discovery, multi-tenant isolation, and audit and compliance — and it analyzes the gaps in existing approaches: MCP, A2A, WebRTC, QUIC, libp2p, WireGuard, and LISP.

+ +

The requirements are written to be implementation-neutral: an agent needs a stable identity that survives migration, reachability without public endpoints, consent-based trust between peers, a transport that suits long-lived agent streams, discovery that defaults to private, isolation between tenants on shared infrastructure, and audit trails where compliance demands them. Taken together, they read as an outline for the protocol specification that follows.

+ +

The Protocol Specification

+ +

The spec converts our wire specification and whitepaper into IETF format. It covers:

+ +
    +
  • Addressing — virtual addresses with network and node parts, text representation, special addresses
    • +
  • Ports — port-based service multiplexing on a single address
    • +
  • Packet format — fixed header, 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, flow control
    • +
  • 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
    • +
  • Built-in services, gateway, and IPC — native services on well-known ports, an HTTP gateway bridge, and the daemon IPC protocol
    • +
  • IANA considerations — requested registries for tunnel magic values, protocol types, and well-known ports
    • +
  • Implementation status — a Go reference implementation with zero external dependencies, plus Python and Node.js SDKs
    • +
+ +

In prose, the design is straightforward. Each agent holds a permanent virtual address and exposes services on ports, like a machine on a private network. Two agents establish a session with a three-way handshake, then exchange encapsulated frames — plaintext frames for control, encrypted frames for payload, with key-exchange frames to negotiate and rotate session keys. When both sides sit behind NAT, STUN discovery and hole punching open a direct path, and a relay steps in when a direct path is impossible. Trust is established by an explicit bilateral handshake: both sides approve, and membership stays decoupled from trust, unlike a VPN where joining the network means trusting everyone on it.

+ +

For the mechanics behind the transport, see our NAT traversal deep dive and the full architecture walkthrough.

+ +

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. Drafts expire and must be revised to stay live; the point of filing is to enter the conversation, not to claim a status.

+ +

What it does:

+ +
    +
  • Public record. The problem and the solution are now on the IETF Datatracker, with formal document names 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 other draft has articulated.
    • +
  • Foundation. If the conversation gains traction, the drafts could lead to a BoF (Birds of a Feather) session at an IETF meeting, potentially a working group, and eventually an RFC.
    • +
+ +

Review and Feedback

+ +

Both drafts are in active IETF review cycles. Technical review is welcome — particularly on the security considerations, the relationship to QUIC, and whether the problem statement adequately motivates the need for a network-layer solution. The working source of truth for the protocol remains github.com/pilot-protocol.

+ +
+

Read the Drafts

+

Both Internet-Drafts are live on the IETF archive. The protocol spec is the definitive reference for Pilot Protocol in standards-track format.

+ Protocol Specification +  ·  + Problem Statement +
+ +

Running an agent? The one-command install is curl -fsSL https://pilotprotocol.network/install.sh | sh, then pilotctl appstore catalogue to see what agent apps are available.

`; +--- + + +