Agent-Awareness in IPv6 Networks: Problem Statement and Framework
draft-he-dawn-ipv6-agent-aware-framework-00

dawn                                                          T. He, Ed.
Internet-Draft                                               M. Han, Ed.
Intended status: Informational                              N. Wang, Ed.
Expires: 4 January 2027                                    T. Huang, Ed.
                                                            China Unicom
                                                             3 July 2026

   Agent-Awareness in IPv6 Networks: Problem Statement and Framework
              draft-he-dawn-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 4 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

He, et al.               Expires 4 January 2027                 [Page 1]
Internet-Draft              Agent-Aware IPv6                   July 2026

   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.

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 4 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 4 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 4 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 4 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 4 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 4 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 4 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 4 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,
              <https://www.rfc-editor.org/rfc/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

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,
              <https://www.rfc-editor.org/rfc/rfc8200>.

   [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,
              <https://www.rfc-editor.org/rfc/rfc8986>.

   [I-D.ietf-cats-framework]
              IETF, "A Framework for Computing-Aware Traffic Steering
              (CATS)", Internet-Draft draft-ietf-cats-framework-24 ,
              n.d., <https://datatracker.ietf.org/doc/html/draft-ietf-
              cats-framework-24>.

He, et al.               Expires 4 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.,
              <https://datatracker.ietf.org/doc/html/draft-yc-ipv6-for-
              ioa-01>.

   [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.,
              <https://datatracker.ietf.org/doc/html/draft-yu-ai-agent-
              ipv6-networking-considerations-01>.

   [I-D.mozley-aidiscovery]
              IETF, "AI Agent Discovery (AID) Problem Statement",
              Internet-Draft draft-mozley-aidiscovery-01 , n.d.,
              <https://datatracker.ietf.org/doc/html/draft-mozley-
              aidiscovery-01>.

   [I-D.sz-dmsc-iaip]
              IETF, "Intent-based Agent Interconnection Protocol
              (IAIP)", Internet-Draft draft-sz-dmsc-iaip-01 , n.d.,
              <https://datatracker.ietf.org/doc/html/draft-sz-dmsc-iaip-
              01>.

   [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.,
              <https://datatracker.ietf.org/doc/html/draft-akhavain-
              moussa-dawn-problem-statement-04>.

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

   Tianyi Huang (editor)
   China Unicom
   Beijing
   China
   Email: kg-huangty1@chinaunicom.cn

He, et al.               Expires 4 January 2027                [Page 12]