| Internet-Draft | Agent-Aware IPv6 | July 2026 |
| He, et al. | Expires 2 January 2027 | [Page] |
The Internet of Agents (IoA) raises a question beyond IPv6 address space and end-to-end connectivity: should an IPv6 network be able to relate packet forwarding to agent capability, policy, and short-lived execution state? This informational document states the problem, sketches a framework for agent-aware IPv6 forwarding, and lists open questions for community discussion. It does not define packet formats, routing extensions, IANA allocations, or a new agent discovery protocol.¶
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 2 January 2027.¶
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 Internet is undergoing a transition from a host-centric model to an Internet of Agents (IoA). Traffic endpoints are shifting from static hosts and fixed services to AI Agents—autonomous programs that discover, invoke, and collaborate with each other to complete complex tasks. This shift fundamentally changes what a routing decision needs to consider.¶
Traditional IPv6 forwarding [RFC8200] answers a single question: is the destination prefix reachable, and via which next hop? Agent traffic demands more:¶
Capability matching — the destination must possess the required agent capability (e.g., a specific model family, tool set, or modality), not merely be reachable.¶
Context affinity — for large language model (LLM) inference, reusing an existing KV-cache across nodes is critical for reducing Time-To-First-Token (TTFT). A network that is blind to where the KV-cache resides forces redundant prefill computation and degrades user experience.¶
Short-lived state — GPU load, accelerator availability, and KV-cache residency change on the order of milliseconds to seconds, far faster than control-plane convergence.¶
Consider a simple chain: Agent A invokes Agent B, which needs a partner with a legal-domain tool and a free KV-cache for a long context. DNS or BGP may steer the request to the correct cluster, yet every instance behind it could be saturated or lack the relevant cache. The packet reaches a reachable address—but not a suitable one.¶
IPv6 is being discussed as a foundation for IoA [I-D.yc-ipv6-for-ioa] and broader AI-agent communication [I-D.yu-ai-agent-ipv6-networking-considerations]. Related work addresses agent discovery and entity discovery [I-D.mozley-aidiscovery][I-D.akhavain-moussa-dawn-problem-statement], intent routing at the Agent Gateway (AG) [I-D.sz-dmsc-iaip], and compute-aware traffic steering [I-D.ietf-cats-framework]. This document asks a narrower question:¶
Should IPv6 forwarding become agent-aware—carrying capability intent in-band and scheduling instances locally—without flooding millisecond-level state into BGP/IGP?¶
This document is a discussion starter. It is intended to expose the architectural question and a possible framework, not to standardize a mechanism. In particular, the document does not assume that ordinary Internet transit routers parse agent semantics or that dynamic agent state is advertised globally.¶
This document:¶
States the problem of agent-awareness in IPv6 networks;¶
Sketches a two-stage forwarding framework for discussion;¶
Identifies open questions for the community.¶
This document does not:¶
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.¶
Agent: An AI execution endpoint on the network (not SSH or similar uses).¶
Agent Capability: A stable or slowly changing description of what an agent can do, such as task class, model family, modality, tool set, or policy scope.¶
Agent Cluster: A group of agent instances behind a common ingress, for example an edge inference pool or an operator-managed agent domain.¶
Agent Forwarding Router (AFR): A cluster-edge router that dispatches packets to a specific agent instance.¶
Agent Forwarding Table (AFT): A local table at the AFR mapping capability and short-lived state hints to instance addresses or next hops.¶
Agent Instance: A concrete runtime that can execute an agent task.¶
Semantic Anycast: An anycast-style destination that identifies a capability, agent class, or agent cluster class, rather than a single instance.¶
Agent-Aware Metadata: In-band information in IPv6 packets (for example, extension headers) used by agent-aware forwarders within a trust domain.¶
Trust Domain: An administrative domain in which operators can authenticate agents, control metadata handling, and enforce boundary policies.¶
Context Affinity: The property of an agent instance already holding relevant execution context (e.g., KV-cache) for an incoming request, enabling incremental rather than full recomputation.¶
--L3 sees location, not capability. Multiple agents may share one prefix, and a single agent service may span many prefixes. Default IPv6 forwarding [RFC8200] cannot distinguish whether a destination instance has the required capability, policy status, or context affinity for a task.¶
--Control plane is too slow for volatile state. Publishing per-agent load, accelerator state, or KV-cache hints through IGP/BGP risks signaling storms, slow convergence, and route oscillation. Stable reachability and capability placement can remain in the control plane; highly volatile instance state (millisecond-level changes such as KV-cache eviction or GPU queue depth) is better handled locally. Attempting to increase the advertisement frequency to match this volatility would overwhelm the control plane.¶
--Discovery is not dispatch. Discovery [I-D.mozley-aidiscovery] answers what exists and how it may be described. Dispatch answers which reachable instance should run the task now. DNS-style caching or registry lookup may be useful, but it can add RTT and can cause hot spots when many flows reuse the same cached target.¶
--Identity is not the same as addressing. Agent identity, credentials, and authorization are primarily application or trust-layer concepts. IPv6 addresses can provide reachability and may carry coarse semantic structure in controlled deployments, but they should not be treated as a complete replacement for agent identity or authorization.¶
--Example: An intermediate Agent B needs a partner with a given tool and free KV-cache. DNS or BGP may reach the correct cluster while every instance behind it is saturated or lacks the relevant context cache. The network delivers the packet to a reachable address, but not to a suitable one.¶
The following model is a strawman for discussion, not a proposed standard. It is intentionally scoped to limited domains such as operator edge networks, data centers, enterprise networks, or federation points where agent-aware behavior can be authenticated and operationally controlled.¶
The packet is directed toward a Semantic Anycast destination or other cluster-level locator. The IPv6 network forwards to an appropriate Agent Cluster ingress (AFR). The control plane may advertise relatively stable information, such as which clusters offer which capability classes, without exposing per-instance state.¶
Semantic addressing is not limited to a single encoding. A future design might use an IPv6 prefix, SRv6 SID, service identifier, or gateway-mediated mapping. This document only assumes that Stage 1 selects a cluster or domain, not a final agent instance.¶
The AFR reads Agent-Aware Metadata, looks up the AFT, and forwards to a suitable instance inside the cluster. The AFT can be populated by local management systems, telemetry, instance registration, or carefully bounded in-band feedback. Fast-changing state is kept local to the cluster or trust domain, not injected into the global routing table.¶
Control plane: capability placement, cluster reachability (Stage 1).¶
Data plane: short-lived scheduling hints (Stage 2).¶
This separation is the main architectural point. It preserves normal IPv6 reachability while allowing a controlled edge to make a final selection based on information that is too dynamic or too sensitive for ordinary routing protocols.¶
To address the state synchronization lag without involving the control plane, the framework envisions a self-learning closed loop at the data-plane level. When a compute node finishes processing a request, it may piggyback updated load status and context-cache signatures onto the returning IPv6 data packets. The AFR updates its local AFT at wire speed upon forwarding these return packets, creating a localized feedback mechanism with zero control-plane overhead.¶
This in-band synchronization is conceptually related to In-band Network Telemetry (INT) but is scoped strictly to the trust domain. It does not require any modification to BGP, IGP, or DNS.¶
The AG [I-D.sz-dmsc-iaip] handles registration, authentication, capability advertisement, and intent matching at the application layer. The AFR handles local instance selection among instances already in scope. The two are complementary: the AG authorizes and interprets intent; the AFR optimizes reachability and short-lived load or locality within an authorized domain.¶
One deployment could place the AG and AFR on the same node. Another could let the AG select an agent cluster and let the AFR select a runtime instance. This draft does not require either arrangement.¶
The DAWN effort [I-D.akhavain-moussa-dawn-problem-statement] addresses the problem of discovering agents, workloads, and named entities in AI ecosystems. This draft shares the fundamental premise that AI agent traffic requires visibility beyond traditional IP reachability. However, while DAWN focuses on the discovery phase—how an entity finds out about the existence, capabilities, and attributes of other entities—this draft focuses on the dispatch phase: once a suitable agent or cluster is discovered, how does the IPv6 network forward the packet to the right instance in a timely manner?¶
The two efforts are complementary:¶
DAWN answers what exists and how to describe it for discovery purposes.¶
This draft answers how the network delivers the packet to a reachable and suitable instance, using in-band agent-aware metadata and local scheduling at the domain edge.¶
The authors seek community feedback on whether this agent-specific framing of IPv6 forwarding is useful and whether it should evolve within or alongside DAWN.¶
This document does not choose a format. Candidate IPv6 mechanisms include SRv6/SRH [RFC8986], Hop-by-Hop Options, and Destination Options, each with different transit, processing, filtering, and operational trade-offs. Which fields belong at L3 versus at the AG is left open.¶
The following categories illustrate the design space:¶
Capability hints: coarse identifiers or hashes that help select a capable cluster or instance. For example, a compact representation (such as a Bloom filter over a context-vector hash) could indicate which model families or tool sets an instance can serve.¶
Policy and trust hints: information that indicates whether agent-aware processing is permitted within a domain.¶
State hints: short-lived load or locality information, such as broad load class or context-affinity signal (e.g., a cache-residency indicator).¶
Correlation hints: bounded identifiers that help associate a packet with an authorized agent session without exposing prompts or user content.¶
Agent-aware metadata should be minimal, integrity-protected where acted upon, and removed or ignored at domain boundaries unless explicitly permitted. Highly detailed capability descriptions, prompts, credentials, and authorization decisions should remain with discovery, gateway, identity, or application-layer systems.¶
This framework is most plausible in a limited domain where the operator controls the agents, AFRs, policies, and metadata handling. It is not intended as a general-purpose semantic routing protocol for the open Internet.¶
The main goal of this document is to ask whether the separation between cluster-level semantic reachability and local instance-level dispatch is useful enough to study further, and whether the agent-specific dimensions (capability matching, context affinity) warrant dedicated work within DAWN.¶
What should the network perceive: capability class only, or also policy, load, and context-affinity attributes?¶
Is L3 agent-awareness useful when an AG already performs discovery, authorization, and intent routing?¶
How should Semantic Anycast or cluster-level selection be encoded: prefix, SRv6 SID, service identifier, gateway mapping, or another mechanism?¶
Which metadata, if any, is appropriate for IPv6 packets rather than application-layer protocols?¶
How should agent-aware metadata be authenticated, scoped, stripped, or hidden at trust-domain boundaries?¶
What measurements are needed to show that local agent-aware dispatch improves latency, cache reuse, or overload avoidance?¶
How can this work align with DAWN, APN-related discussions, SRv6 operations, and agent discovery efforts without creating a parallel architecture?¶
Is the in-band state synchronization model (return-path piggyback) feasible and safe in production agent clusters?¶
Forged Agent-Aware Metadata could misdirect traffic, bypass policy, or trigger localized overload. Routers that act on metadata should use integrity protection within the domain and should filter, strip, or ignore such metadata at untrusted boundaries. Operators should limit metadata to the minimum needed and apply rate control at the AFR. If SRv6 is used, usual SRH security practices [RFC8986] apply.¶
Agent-aware forwarding can also create privacy risks. Capability hints, load hints, cache-affinity signals, or correlation identifiers may reveal sensitive information about users, tasks, models, business relationships, or resource conditions. A future mechanism would need privacy minimization, replay protection, boundary policy, and clear rules for when metadata is visible to intermediate nodes.¶
This document has no IANA actions.¶
The authors thank colleagues at China Unicom and welcome comments from the DAWN and V6OPS communities.¶
TBD.¶