dawn T. He, Ed. Internet-Draft M. Han, Ed. Intended status: Informational N. Wang, Ed. Expires: 2 January 2027 China Unicom 1 July 2026 Agent-Awareness in IPv6 Networks: Problem Statement and Framework draft-he-ipv6-agent-aware-framework-00 Abstract 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. Status of This Memo 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 Notice 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 He, et al. Expires 2 January 2027 [Page 1] Internet-Draft Agent-Aware IPv6 July 2026 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Motivation: Why Agent Traffic Is Different . . . . . . . 2 1.2. The Question This Draft Asks . . . . . . . . . . . . . . 3 1.3. Scope of This Document . . . . . . . . . . . . . . . . . 3 1.4. Requirements Language . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5 4. Framework: Two-Stage Agent-Aware Forwarding . . . . . . . . . 6 4.1. Stage 1 — Steer to the right cluster (macro) . . . . . . 6 4.2. Stage 2 — Pick the best instance (micro) . . . . . . . . 6 4.3. Control plane vs data plane . . . . . . . . . . . . . . . 6 4.4. In-band State Synchronization . . . . . . . . . . . . . . 7 4.5. Relation to Agent Gateway . . . . . . . . . . . . . . . . 7 4.6. Relation to DAWN . . . . . . . . . . . . . . . . . . . . 7 5. Carrying Agent-Aware Metadata . . . . . . . . . . . . . . . . 8 6. Applicability and Non-Goals . . . . . . . . . . . . . . . . . 8 7. Open Questions . . . . . . . . . . . . . . . . . . . . . . . 9 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 10.1. Normative References . . . . . . . . . . . . . . . . . . 10 10.2. Informative References . . . . . . . . . . . . . . . . . 10 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction 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. 1.1. Motivation: Why Agent Traffic Is Different Traditional IPv6 forwarding [RFC8200] answers a single question: _is the destination prefix reachable, and via which next hop?_ Agent traffic demands more: He, et al. Expires 2 January 2027 [Page 2] Internet-Draft Agent-Aware IPv6 July 2026 * *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. 1.2. The Question This Draft Asks 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. 1.3. Scope of This Document This document: * States the problem of agent-awareness in IPv6 networks; He, et al. Expires 2 January 2027 [Page 3] Internet-Draft Agent-Aware IPv6 July 2026 * Sketches a two-stage forwarding framework for discussion; * Identifies open questions for the community. This document does *not*: * Define a new IPv6 extension header or option; * Reserve semantic IPv6 address bits; * Require BGP, IGP, or DNS changes; * Require ordinary Internet routers to inspect agent metadata; * Replace agent discovery, identity, authentication, authorization, or application-layer intent routing. 1.4. Requirements Language 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. 2. Terminology *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. He, et al. Expires 2 January 2027 [Page 4] Internet-Draft Agent-Aware IPv6 July 2026 *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. 3. Problem Statement *--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. He, et al. Expires 2 January 2027 [Page 5] Internet-Draft Agent-Aware IPv6 July 2026 *--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. 4. Framework: Two-Stage Agent-Aware Forwarding 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. 4.1. Stage 1 — Steer to the right cluster (macro) 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. 4.2. Stage 2 — Pick the best instance (micro) 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. 4.3. Control plane vs data plane * *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. He, et al. Expires 2 January 2027 [Page 6] Internet-Draft Agent-Aware IPv6 July 2026 4.4. In-band State Synchronization 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. 4.5. Relation to Agent Gateway 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. 4.6. Relation to DAWN 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. He, et al. Expires 2 January 2027 [Page 7] Internet-Draft Agent-Aware IPv6 July 2026 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. 5. Carrying Agent-Aware Metadata 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. 6. Applicability and Non-Goals 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. He, et al. Expires 2 January 2027 [Page 8] Internet-Draft Agent-Aware IPv6 July 2026 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. 7. Open Questions 1. What should the network perceive: capability class only, or also policy, load, and context-affinity attributes? 2. Is L3 agent-awareness useful when an AG already performs discovery, authorization, and intent routing? 3. How should Semantic Anycast or cluster-level selection be encoded: prefix, SRv6 SID, service identifier, gateway mapping, or another mechanism? 4. Which metadata, if any, is appropriate for IPv6 packets rather than application-layer protocols? 5. How should agent-aware metadata be authenticated, scoped, stripped, or hidden at trust-domain boundaries? 6. What measurements are needed to show that local agent-aware dispatch improves latency, cache reuse, or overload avoidance? 7. How can this work align with DAWN, APN-related discussions, SRv6 operations, and agent discovery efforts without creating a parallel architecture? 8. Is the in-band state synchronization model (return-path piggyback) feasible and safe in production agent clusters? 8. Security Considerations 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. He, et al. Expires 2 January 2027 [Page 9] Internet-Draft Agent-Aware IPv6 July 2026 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. 9. IANA Considerations This document has no IANA actions. 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 10.2. Informative References [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, . [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 (SRv6) Network Programming", RFC 8986, DOI 10.17487/RFC8986, February 2021, . [I-D.ietf-cats-framework] IETF, "A Framework for Computing-Aware Traffic Steering (CATS)", Internet-Draft draft-ietf-cats-framework-24 , n.d., . He, et al. Expires 2 January 2027 [Page 10] Internet-Draft Agent-Aware IPv6 July 2026 [I-D.yc-ipv6-for-ioa] IETF, "Capabilities and Future Requirements of IPv6 for the Internet of Agents (IoA)", Internet-Draft draft-yc- ipv6-for-ioa-01 , n.d., . [I-D.yu-ai-agent-ipv6-networking-considerations] IETF, "IPv6 Networking Considerations for AI Agent Communication", Internet-Draft draft-yu-ai-agent-ipv6- networking-considerations-01 , n.d., . [I-D.mozley-aidiscovery] IETF, "AI Agent Discovery (AID) Problem Statement", Internet-Draft draft-mozley-aidiscovery-01 , n.d., . [I-D.sz-dmsc-iaip] IETF, "Intent-based Agent Interconnection Protocol (IAIP)", Internet-Draft draft-sz-dmsc-iaip-01 , n.d., . [I-D.akhavain-moussa-dawn-problem-statement] IETF, "Problem Statement for the Discovery of Agents, Workloads, and Named Entities (DAWN)", Internet-Draft draft-akhavain-moussa-dawn-problem-statement-04 , n.d., . Acknowledgements The authors thank colleagues at China Unicom and welcome comments from the DAWN and V6OPS communities. Contributors TBD. Authors' Addresses Tao He (editor) China Unicom Beijing China He, et al. Expires 2 January 2027 [Page 11] Internet-Draft Agent-Aware IPv6 July 2026 Email: het21@chinaunicom.cn Mengyao Han (editor) China Unicom Beijing China Email: hanmy12@chinaunicom.cn Nan Wang (editor) China Unicom Beijing China Email: wangn161@chinaunicom.cn He, et al. Expires 2 January 2027 [Page 12]