]> China Unicom

Beijing China het21@chinaunicom.cn

China Unicom

Beijing China hanmy12@chinaunicom.cn

China Unicom

Beijing China wangn161@chinaunicom.cn

Internet dawn IPv6 Internet of Agents Agent-Aware Semantic Anycast Agent Discovery KV Cache Affinity DAWN 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.

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.

Motivation: Why Agent Traffic Is Different Traditional IPv6 forwarding 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.

The Question This Draft Asks IPv6 is being discussed as a foundation for IoA and broader AI-agent communication . Related work addresses agent discovery and entity discovery , intent routing at the Agent Gateway (AG) , and compute-aware traffic steering . 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.

Scope of This Document 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:

• 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.

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 when, and only when, they appear in all capitals, as shown here.

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. 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.

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 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 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.

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.

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.

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.

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.

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.

Relation to Agent Gateway The AG 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.

Relation to DAWN The DAWN effort 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.

Carrying Agent-Aware Metadata This document does not choose a format. Candidate IPv6 mechanisms include SRv6/SRH , 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.

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. 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.

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?

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 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.

IANA Considerations This document has no IANA actions.

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References This document specifies version 6 of the Internet Protocol (IPv6). It obsoletes RFC 2460. The Segment Routing over IPv6 (SRv6) Network Programming framework enables a network operator or an application to specify a packet processing program by encoding a sequence of instructions in the IPv6 packet header. Each instruction is implemented on one or several nodes in the network and identified by an SRv6 Segment Identifier in the packet. This document defines the SRv6 Network Programming concept and specifies the base set of SRv6 behaviors that enables the creation of interoperable overlays with underlay optimization. IETF n.d. IETF n.d. IETF n.d. IETF n.d. IETF n.d. IETF n.d.

Acknowledgements The authors thank colleagues at China Unicom and welcome comments from the DAWN and V6OPS communities.

Contributors TBD.