| Internet-Draft | AI Agent IPv6 | May 2026 |
| Yu | Expires 21 November 2026 | [Page] |
AI agents are increasingly expected to communicate across platforms, organizations, clouds, edge environments, and administrative domains. Ongoing work on agent protocols has started to address agent description, discovery, authentication, authorization, invocation, delegation, and collaboration. These functions are essential, but they generally treat the IP network as a transparent connectivity substrate.¶
This document discusses IPv6 networking considerations for AI agent communication. It focuses on networking support after an agent has been discovered by an application-layer or control-plane mechanism. It discusses how stable Agent identifiers can be associated with IPv6 locators or Agent Gateways, how agent communication requirements can be mapped to IPv6 or SRv6 forwarding policies, how limited agent-related network context can be carried within controlled deployment environments, and how network-layer telemetry can complement application-layer audit records.¶
This document does not define a new agent discovery protocol, a new application-layer agent collaboration protocol, or a new authentication or authorization mechanism. It is intended to be complementary to existing and emerging agent discovery, identity, authorization, auditing, and collaboration mechanisms.¶
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 21 November 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. Code Components 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.¶
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.¶
AI agents are moving from isolated applications toward large-scale, cross-domain collaboration. An agent may invoke tools, communicate with other agents, migrate across cloud or edge nodes, act on behalf of a user or organization, and interact through multiple application-layer protocols. In such environments, agent communication is not only an application-layer issue. It also raises questions of network reachability, locator binding, path selection, traffic isolation, observability, and operational governance.¶
Several ongoing discussions and individual Internet-Drafts explore agent registration, discovery, identity, capability advertisement, authorization, delegation, auditing, and invocation. Such work is important for enabling agents to describe themselves, discover each other, and select suitable application-layer interaction mechanisms. However, after an agent has been discovered and an application-layer protocol has been selected, the resulting communication still needs to be carried by the underlying network.¶
In large-scale deployments, the following questions remain relevant at the networking layer:¶
This document discusses IPv6 networking considerations for AI agent communication. It uses IPv6 as the basic addressing and forwarding substrate. In deployments where Segment Routing over IPv6 is available, SRv6 may be used to support policy-based path steering, service function chaining, and domain-local network programming. The IPv6 Segment Routing Header (SRH) is defined in [RFC8754], and SRv6 Network Programming is defined in [RFC8986].¶
This document does not assume that ordinary Internet routers understand agent identities, task semantics, natural language intent, or application payloads. Any processing of agent-related network context is limited to explicitly participating endpoints, Agent Gateways, policy enforcement points, or SRv6-capable nodes within controlled domains.¶
This document focuses on:¶
This document does not define:¶
Agent discovery and collaboration mechanisms can help an application identify an agent, understand its capabilities, and select an application-layer protocol for interaction. However, those mechanisms do not by themselves define how the resulting traffic should be handled by the IPv6 network. This document identifies four networking problems that become important in large-scale and cross-domain deployments.¶
An agent may be replicated, migrated, hidden behind a gateway, or deployed across multiple network domains. Its identity should remain stable, while the IPv6 locator used to reach it may change. A method is needed to associate Agent identifiers with IPv6 locators or Agent Gateways in a verifiable and operationally manageable way.¶
An agent discovery mechanism may return an endpoint, but that result does not necessarily prove that the endpoint is reachable, authorized to represent the Agent-ID, or suitable for a specific network policy. Agent communication therefore needs a way to connect discovery results with IPv6 reachability, locator selection, and policy enforcement.¶
Different agent communication flows may have different network requirements. Some flows may require low latency, some may require security inspection, some may require a compliance-aware path, and some may require audit collection. A method is needed to map structured communication requirements into IPv6 or SRv6 forwarding behavior without requiring the data plane to interpret application semantics.¶
Application-layer logs may record task execution, authorization decisions, or API invocations. Network operators may also need independently collected flow-level evidence, such as source and destination locators, Agent Gateway traversal, SRv6 policy identifiers, timestamps, and telemetry records. Such evidence can complement application-layer audit records, but does not replace them.¶
The following requirements guide the considerations discussed in this document. They are intended to constrain Agent-related use of IPv6 and SRv6 mechanisms. They do not define a new application-layer agent protocol.¶
The considerations discussed in this document can be organized into five logical functions. These functions are logical and may be implemented by different systems in different deployments.¶
This function discovers agent capabilities and endpoints through existing or emerging mechanisms, such as an Agent Directory, ARDP, A2A AgentCard, MCP-related directories, DNS-based indirection, or enterprise service discovery systems. This document does not replace this function.¶
This function maintains or queries the binding between an Agent-ID and networking information. A binding record may include:¶
The binding function may use an Agent-ID Registration Data Service, an Agent Registry, DNS-based indirection, an enterprise identity system, an operator-managed database, or a controller. This document does not require a single global registry.¶
This function selects the IPv6 locator or Agent Gateway that should be used for a specific communication. Selection may depend on network reachability, policy, trust level, service class, administrative domain, or deployment location.¶
This function maps structured communication requirements to network policies. Such policies may include default IPv6 forwarding, SRv6 path steering, service-chain insertion, security gateway traversal, compliance-aware routing, audit collection, traffic isolation, or low-latency forwarding.¶
This function carries agent communication using IPv6 and, where applicable, SRv6. It may also collect telemetry information that can be correlated with application-layer audit records.¶
This document separates Agent-ID from IPv6 locator. The Agent-ID identifies the agent as a stable entity. The IPv6 locator identifies the current network location of an agent instance, an Agent Gateway, or another network element that represents the agent.¶
An Agent-ID may be associated with one or more IPv6 locators. The relationship may be one-to-one, one-to-many, many-to-one, or dynamic:¶
Binding information SHOULD be authenticated and SHOULD include a validity period and revocation status. If an Agent Gateway represents an Agent-ID, the gateway authorization SHOULD also be verifiable.¶
IPv6 is used as the basic network-layer substrate. In simple cases, agent communication can use ordinary IPv6 forwarding. In more advanced cases, SRv6 may be used within an SRv6-capable domain to support path steering, service chaining, security inspection, or audit path selection.¶
SRv6 may be useful when agent communication needs to pass through specific network functions, such as:¶
This document avoids defining new IPv6 extension headers. [RFC8200] notes that defining new IPv6 extension headers is not recommended unless existing extension headers cannot be used, and also notes operational concerns around Hop-by-Hop options. Therefore, this document primarily considers existing mechanisms and deployment profiles.¶
Limited Agent Context may be carried in network-layer or network-adjacent mechanisms. Candidate fields include:¶
Agent Context MUST be minimized. Large semantic descriptions, natural language prompts, private user data, or sensitive application payloads MUST NOT be carried in IPv6 extension headers or other network-visible metadata fields.¶
IPv6 Destination Options may be considered when the context is intended for the final destination or an intermediate destination identified by a Routing Header. [RFC8200] specifies that a Destination Options header can appear before a Routing Header or before the upper-layer header.¶
Destination Options may be suitable only in deployment environments where participating endpoints or gateways are explicitly configured to process such options. This document does not assume that Destination Options are reliably forwarded or processed across the public Internet.¶
SRH TLVs may be considered inside an SRv6-capable domain when the information is related to SRv6 policy, service-chain context, audit path selection, or domain-local agent policy enforcement. Such TLVs are not intended to carry user prompts, full Agent identities, or sensitive payload data.¶
Because IPv6 extension header support may be inconsistent across public networks, deployments SHOULD provide fallback mechanisms. Such mechanisms may include application-layer headers, TLS-protected metadata, Agent Gateway encapsulation, controller-side policy mapping, or out-of-band policy association.¶
This document does not require routers to understand natural language, prompts, complex semantic descriptions, or agent reasoning processes. Semantic routing, if used, is understood as an indirect process:¶
User or task intent -> Agent application / Registry / Gateway -> structured Policy-ID -> IPv6 or SRv6 policy -> forwarding path or service chain¶
This design keeps semantic interpretation out of the forwarding plane and limits network-layer behavior to structured and verifiable policy identifiers.¶
IPv6 and SRv6 deployments can provide network-layer evidence that complements application-layer audit records. Examples include:¶
This document does not define a complete audit record format, legal compliance framework, or non-repudiation mechanism. Such functions may be provided by application-layer audit architectures, logging systems, transparency services, or other mechanisms. This document focuses on the network-layer evidence that can be correlated with those systems.¶
The considerations in this document can be applied incrementally. This document identifies three non-exclusive deployment models.¶
In this model, agent-related network context is processed only by agent endpoints and Agent Gateways. The public Internet or transit network forwards ordinary IPv6 traffic and does not process agent-specific metadata. This model is suitable when extension header processing is not available or when functions are implemented primarily at the edge.¶
In this model, agent-related networking functions are deployed within an enterprise, campus, data center, cloud, operator network, or dedicated interconnection environment. Participating nodes may process limited Agent Context according to local policy. This model is suitable for environments where administrative control, security policy, and extension header behavior can be managed.¶
In this model, SRv6 policies are used to steer traffic through specific service functions or network domains. Agent-related context may be associated with SRv6 policies, service chains, or domain-local telemetry collection. This model is limited to SRv6-capable domains and must follow SRv6 operational and security practices.¶
The considerations in this document are complementary to existing and emerging work on agent protocols. Agent discovery mechanisms can identify agents, advertise capabilities, and resolve endpoints. A2A and MCP focus on application-layer interaction, tool invocation, and collaboration. OAuth, OIDC, DID, SD-JWT, WIMSE, RATS, and related mechanisms may be used for identity, authorization, attestation, selective disclosure, or workload identity. OpenTelemetry and related systems may provide application-layer tracing and observability.¶
This document focuses on a different layer: IPv6-based networking support for agent communication after discovery. It can provide locator binding, network policy selection, Agent Gateway traversal, SRv6 service chaining, and network-layer telemetry that can be correlated with higher-layer identity, authorization, and audit mechanisms.¶
A common limitation of many agent discovery and collaboration mechanisms is that they stop at the point where an endpoint, protocol, credential, or capability description has been selected. They generally do not specify how the selected interaction is bound to an IPv6 locator or Agent Gateway, how the traffic is steered through an operator controlled path, or how network-layer evidence is correlated with application-layer audit records. This document addresses that gap.¶
This document also avoids placing agent semantics in ordinary routers. Any interpretation of user intent, task descriptions, or agent capabilities is expected to occur in an application, registry, controller, or gateway. The network is expected to operate on structured identifiers, locators, and policies.¶
This document raises several security considerations.¶
First, Agent-ID to IPv6 locator or Agent Gateway binding must be authenticated. An attacker must not be able to claim an Agent-ID or bind it to an unauthorized locator.¶
Second, Agent Gateway authorization must be verifiable. A gateway must not represent an agent unless it has been authorized by the responsible entity or administrative domain.¶
Third, Agent Context carried in network-visible mechanisms must be minimized and integrity-protected where necessary. Sensitive data must not be exposed in cleartext network headers.¶
Fourth, replay attacks must be considered. Context fields such as Policy-ID, Trace-ID, or Agent-ID references may need validity time, nonce, session binding, or cryptographic protection depending on the deployment.¶
Fifth, policy identifiers must not be used to bypass access control, security inspection, or authorization checks. Network policy selection must be integrated with existing security policy enforcement.¶
Sixth, this document does not assume that IPv6 extension headers are available across the public Internet. Deployment profiles must define where such mechanisms are allowed and what fallback mechanisms are used.¶
Seventh, SRv6 usage must follow SRv6 security considerations. SRv6 policies and SIDs used for agent communication must be protected against unauthorized insertion, modification, or misuse.¶
Agent-related metadata may reveal information about agent identity, task class, policy class, organizational relationships, or network path choices. Deployments must minimize exposed metadata and avoid carrying sensitive user data in network-layer headers or network-visible metadata fields.¶
Agent-ID references may be pseudonymous, scoped to a domain, or represented by opaque references. Detailed identity information should be obtained through authorized query mechanisms, rather than exposed in every packet.¶
Network telemetry used for audit support may contain sensitive operational information. Access to telemetry records should be controlled, retained only as long as necessary, and protected against unauthorized disclosure or correlation.¶
This initial version does not request any IANA action.¶
Future versions may request code points for specific Destination Options, SRH TLVs, or other identifiers if concrete encodings are standardized. Such requests are out of scope for this considerations document.¶