Agent Attachment Protocol
draft-dunbar-agent-attachment-01
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Linda Dunbar , Kausik Majumdar | ||
| Last updated | 2026-05-01 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-dunbar-agent-attachment-01
Network Working Group L. Dunbar
Internet Draft Futurewei
Intended status: Informational K. Majumdar
Expires: November 1, 2026 Oracle
May 1, 2026
Agent Attachment Protocol
draft-dunbar-agent-attachment-01
Abstract
This document describes the Agent Attachment Protocol (AAP)
that enables AI agents to establish attachment to an edge
node and derive communication and attachment-related
properties. These properties include endpoint identifiers,
supported communication mechanisms, and attachment context
information that can be exposed to discovery systems. AAP
focuses on how agents obtain and maintain attachment state
and how attachment-derived properties can be represented in a
consistent and interoperable manner. These properties can be
used by forwarding functions at edge nodes and by routing or
control-plane mechanisms to support communication between
agents.
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), its areas, and its working
groups. Note that other groups may also distribute working
documents as Internet-Drafts.
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."
xxx, et al. Expires November 1, 2026 [Page 1]
Internet-Draft Agent-Attachment
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed
at http://www.ietf.org/shadow.html
This Internet-Draft will expire on November 1, 2026 .
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
(http://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 Simplified BSD
License text as described in Section 4.e of the Trust Legal
Provisions and are provided without warranty as described in
the Simplified BSD License.
Table of Contents
1. Introduction..............................................3
2. Conventions used in this document.........................4
3. Problem Statement.........................................5
4. Use Cases.................................................6
4.1. Smart Factory Control Agent..........................7
4.2. Private 5G/6G Service Agent..........................7
4.3. Industrial IoT Monitoring Agent......................8
4.4. Key Characteristics..................................9
5. Architecture Overview.....................................9
6. Agent Gateway Bootstrap and Attachment...................13
6.1. Bootstrap Mechanisms................................14
6.1.1. Anycast-Based Discovery........................14
6.1.2. DHCP-Based Bootstrapping.......................14
6.1.3. DNS-Based Bootstrap............................14
6.2. Gateway Offer and Selection.........................15
6.3. Handshake and Registration..........................15
6.4. Attachment Property Derivation......................15
Dunbar, et al. Expires Dec 1, 2026 [Page 2]
Internet-Draft Agent-Attachment
6.5. Exposure of Attachment Properties...................16
7. Use of Attachment State (Informative)....................16
7.1. Attachment State Representation.....................16
7.2. Use of Attachment State by External Systems.........17
7.3. Forwarding Using Attachment State (Example).........17
7.4. Transport Header (Example)..........................18
7.5. Role in Routing and Control Plane...................18
7.6. Payload Confidentiality.............................19
8. Attachment State Maintenance and Teardown................19
8.1. Stateful Attachment Model...........................19
8.2. Stateless (Soft-State) Attachment Model.............20
8.3. Interoperability Considerations.....................20
9. Security Considerations..................................20
9.1. Authentication and Identity Binding.................20
9.2. Integrity of Attachment State.......................21
9.3. Protection of Attachment Exchanges..................21
9.4. Exposure of Attachment Properties...................22
9.5. Relationship to End-to-End Security.................22
10. Manageability Considerations............................22
11. IANA Considerations.....................................22
12. References..............................................23
12.1. Normative References...............................23
12.2. Informative References.............................23
13. Acknowledgments.........................................23
Appendix A:.................................................23
1. Introduction
The Agent Attachment Protocol (AAP) defines a mechanism for
agents to establish attachment to an edge node and to derive
communication and attachment-related properties associated
with that attachment.
Some AI agents, such as those managed by OpenClaw, operate in
cloud environments, while others run on devices connected
through private networks, such as smart-factory control agents
and AI agents hosted on user equipment (UE) in 5G/6G systems.
Those device-hosted agents are typically associated with
physical devices or edge infrastructure, such as industrial
equipment, vehicles, sensors, or user equipment (UE), and
operate within a controlled administrative domain where:
o connectivity is restricted and not globally reachable,
Dunbar, et al. Expires Dec 1, 2026 [Page 3]
Internet-Draft Agent-Attachment
o naming and addressing may be private or domain-specific,
and
o security and policy enforcement depend on local network
context.
In these settings, an agent is identified by a stable,
location-independent identifier (e.g., AgentID), but its
ability to communicate depends on its current network
attachment. An agent may attach to different access routers,
gateways, or edge nodes over time due to mobility, scaling,
failover, or operational policies.
As a result, static endpoint information or identifiers alone
are insufficient to support efficient and policy-compliant
communication. Instead, it is necessary to understand where
and how an agent is currently attached, including its
attachment point, access domain, and associated communication
properties.
AAP addresses this gap by defining how agents:
o attach to a local network edge node,
o establish an attachment context, and
o derive communication properties associated with that
attachment.
These attachment derived properties may include endpoint
identifiers, supported protocols, attachment point
identifiers, and domain information. Such properties can be
made available to other systems, such as discovery services,
forwarding functions, or control-plane mechanisms, to support
efficient, secure, and policy-aware communication.
2. Conventions used in this document
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 BCP14 [RFC2119] [RFC8174]
when, and only when, they appear in all capitals, as shown
here.
Dunbar, et al. Expires Dec 1, 2026 [Page 4]
Internet-Draft Agent-Attachment
The following acronyms and terms are used in this document:
AI Agent: A software entity that uses artificial intelligence
techniques to interpret context, make decisions,
and take actions toward achieving one or more
goals, possibly by interacting with users and by
invoking other agents, tools, or services, rather
than only executing fixed pre-programmed
functions.
Attachment Context: The set of properties describing an
agent's current network attachment (e.g.,
attachment point, domain, protocols).
Agent Gateway (GW): An edge node that serves as an attachment
anchor for an Agent within a provider-managed or
private network.
Attachment State: The maintained representation of an agent's
attachment context at an Agent Gateway.
Directory Service: A service or registry that enables
discovery of agents based on their capabilities
and returns information associated with those
agents, such as Agent Identifiers (AgentIDs),
endpoints, or metadata. One example is a registry
based on A2A Agent Cards, where an agent
publishes a card describing its capabilities,
skills, and endpoint.
Message Forwarding Table (MFT): A forwarding table mapping
Agent ID prefixes to local interfaces or next-hop
Gateways.
3. Problem Statement
Some AI agents operate on devices or edge infrastructure
connected through private networks, such as smart-factory
control agents and AI agents hosted on user equipment (UE) in
5G/6G systems. In these environments, communication depends
not only on an agent's identity, but also on its current
network attachment.
Dunbar, et al. Expires Dec 1, 2026 [Page 5]
Internet-Draft Agent-Attachment
These environments typically have limited reachability,
private or domain-specific naming and addressing, and
security and policy requirements tied to local network
context. As a result, an agent identifier alone (e.g.,
AgentID) is often insufficient to determine how the agent can
be reached or how it should interact with other entities.
Effective communication depends on attachment-related
context, such as the access domain, attachment point, and
associated communication properties.
An agent's attachment may change over time due to mobility,
scaling, failover, or operational policies. Existing
discovery systems, such as services based on A2A Agent Cards,
can identify entities and return basic information, such as
identifiers and capability descriptions, but they typically
lack a standardized way to represent and expose attachment-
related properties that reflect where and how an agent is
currently attached within a given administrative domain.
Without a consistent mechanism for deriving and representing
such properties, discovery information may be incomplete or
outdated, communication may be suboptimal or fail because of
topology or policy constraints, and control-plane mechanisms
lack a common basis for exchanging attachment-related
information across network elements.
This document addresses the need for a standardized mechanism
by which agents can derive and expose attachment-related
communication properties that reflect their current network
attachment within a controlled administrative domain. These
properties can then be made available to other systems, such
as discovery services or control-plane mechanisms, to support
efficient, policy-compliant, and secure communication.
4. Use Cases
This section provides illustrative examples of agents that
are attached to edge nodes within provider-managed
environments, highlighting how they differ from conventional
application deployments and why attachment-related properties
are required.
Dunbar, et al. Expires Dec 1, 2026 [Page 6]
Internet-Draft Agent-Attachment
4.1. Smart Factory Control Agent
In a smart factory environment, industrial robots and control
systems operate within a standalone private network managed
by the factory operator.
An AI agent associated with a worker's AR (Augmented Reality)
glasses may assist with inspection, maintenance, or repair
tasks by invoking multiple tools or services available within
the factory network. For example, the agent may:
o retrieve telemetry from nearby machines or sensors,
o invoke a diagnostic tool hosted on a local edge server,
o query an inventory or parts database,
o obtain repair procedures from an enterprise application,
and
o request real-time visual or language assistance from a
local inference service.
To complete such tasks, the agent may need to discover and
interact with services that are available only within the
factory domain and reachable through the worker's current
point of attachment. The agent's communication and behavior
may therefore depend on the specific gateway, edge node, or
factory segment to which the AR glasses are connected.
Unlike traditional industrial applications that rely on fixed
workflows or centralized control systems, such an agent can
dynamically select and invoke different tools or services
based on the worker's task, location, and surrounding
conditions. As the worker moves across the factory floor or
connects through a different access point or edge node, the
agent's reachable services and communication properties may
also change.
4.2. Private 5G/6G Service Agent
In a private 5G/6G deployment, an enterprise or operator may
provide a controlled network domain to support localized and
latency-sensitive services.
An AI agent associated with user equipment (UE), such as a
field technician tablet, autonomous vehicle terminal, or
industrial handheld device, may need to accomplish a complex
Dunbar, et al. Expires Dec 1, 2026 [Page 7]
Internet-Draft Agent-Attachment
task by invoking multiple remote tools or services hosted
within the private network. For example, the agent may:
o retrieve equipment status from a monitoring service,
o invoke a diagnostic tool hosted on an edge MCP server,
o access a local policy or authorization service,
o query a nearby inference service for real-time analysis,
and
o obtain repair instructions or workflow data from an
enterprise application server.
To complete such tasks efficiently, the agent may need to
discover and interact with different services available at
the current site or within the serving 5G/6G domain. Which
services are reachable, and how they should be accessed, can
depend on the UE's current point of attachment, serving edge
node, network slice, or operator policy.
Unlike typical Internet-based applications that rely on
globally reachable endpoints, such agents operate within a
provider-managed domain where communication depends on the
current network attachment and locally available services. As
the UE moves, changes serving edge nodes, or is reassigned to
a different slice or policy domain, the agent's reachable
resources and communication properties may also change.
4.3. Industrial IoT Monitoring Agent
In industrial IoT deployments, sensors and devices are
connected through private access networks and edge gateways.
An AI agent associated with a device or gateway may monitor
local conditions and respond to operational events by
invoking multiple tools or services within the local domain.
For example, the agent may:
o collect telemetry from nearby sensors and controllers,
o invoke an anomaly-detection or correlation service hosted
on an edge server,
o query a local policy or safety system to determine
permitted actions, and
o trigger alerts, workflow updates, or local control
responses.
Dunbar, et al. Expires Dec 1, 2026 [Page 8]
Internet-Draft Agent-Attachment
Unlike traditional monitoring systems that periodically
export data to centralized cloud platforms for offline
analysis, such agents perform local analysis and decision-
making within the private network. Their ability to reach the
appropriate tools or services may depend on the device's
current attachment point, serving gateway, or local policy
domain.
4.4. Key Characteristics
The above examples share the following properties:
o Agents may need to query a Directory Service to discover
other agents, tools, or services needed to complete a
task.
o Agents may invoke remote services, such as tools hosted
on MCP servers or other service endpoints within the
local or remote domain.
o Agents may invoke or coordinate with other agents to
accomplish multi-step tasks.
o Agents are attached to edge nodes, gateways, or physical
devices.
o They operate within controlled administrative domains
rather than solely over the public Internet.
o Their behavior depends on local context, including device
state, locally available services, policy constraints,
and current network attachment.
o Their attachment may change over time, requiring dynamic
updates to communication properties and reachable
resources.
In such environments, an agent's identifier alone is
insufficient to determine how it can be reached or what
resources it can access. The agent's current attachment
context becomes an essential part of its operational state.
5. Architecture Overview
The Agent Attachment Protocol (AAP) defines the procedures by
which an agent establishes attachment to an edge node,
referred to as an Agent Gateway.
Dunbar, et al. Expires Dec 1, 2026 [Page 9]
Internet-Draft Agent-Attachment
An Agent Gateway is an edge node that serves as the
attachment anchor for agents. It provides functions for agent
authentication, registration, and maintenance of attachment
state. Gateway anchors the agent's current network presence
and maintains an association between the Agent Identifier
(AgentID) and its point of attachment.
In this architecture, agents are identified by stable,
location-independent AgentIDs, decoupled from underlying IP
addressing. Agent Gateway establishes and maintains the
attachment context for each agent, which includes information
such as the agent's current ingress point, associated domain
or policy context, and supported communication mechanisms.
The primary function of AAP is to create and maintain this
attachment context. The protocol defines how an agent:
o identifies and connects to a candidate Agent Gateway,
o performs mutual authentication,
o registers its AgentID, and
o establishes and maintains its attachment state.
As part of this process, the Agent Gateway may derive a set
of attachment-related communication properties associated
with the agent's current attachment. These properties can
include endpoint identifiers, supported protocols, attachment
point identifiers, and domain information.
The communication properties derived from attachment may be
exposed to external systems, such as discovery services, or
used by other mechanisms (e.g., routing or control-plane
protocols). However, the definition of those systems and
their use of the information is outside the scope of this
document.
While an Agent Gateway may participate in forwarding traffic
based on local policy or identifiers, forwarding behavior and
overlay control-plane mechanisms are not specified by AAP;
examples of how attachment state may be used by such
mechanisms are described in Section 7.
Dunbar, et al. Expires Dec 1, 2026 [Page 10]
Internet-Draft Agent-Attachment
+----------------------+ +----------------------+
| DIRECTORY SERVICE |<-------| AGENT GATEWAY (GW) |
| Capability -> AgentID| (F) | Attachment Context |
| Attachment Properties| Export | AgentID -> Attach Pt |
+----------+-----------+ +----------+-----------+
^ ^
| (A) Agent Inquiry | (C) GW-DISCOVER
| (B) Directory Returns | (D) GW-OFFER
| |
| |
+----------+-------------------------------+----------+
| AGENT A |
+-------------------------+---------------------------+
|
| (E) AAP ATTACH
| Authentication
| AgentID Registration
| Attachment Context Setup
v
+----------------------+
| ATTACHMENT STATE |
| AgentID |
| Attachment Point |
| Supported Protocols |
| Domain/Policy Info |
+----------------------+
Figure 1: Key Components of Agent Attachment
Legend:
(A) Agent queries: "Who has Skill X?"
(B) Directory returns: "Agent B (AgentID-456)"
(C) GW-DISCOVER: The Agent initiates discovery of a candidate
Agent Gateway using locally configured or bootstrap
mechanisms (e.g., anycast, DNS, or pre-configured address).
This step is part of attachment bootstrapping and is within
the scope of AAP.
(D) GW-OFFER: An Agent Gateway responds with information
needed for attachment, such as its identifier, reachable
endpoint, and supported attachment parameters. The Agent
selects a Gateway and proceeds with attachment.
(E) AAP ATTACH: The Agent establishes attachment to the
selected Agent Gateway by performing mutual authentication,
Dunbar, et al. Expires Dec 1, 2026 [Page 11]
Internet-Draft Agent-Attachment
registering its AgentID, and creating an attachment context.
The Gateway records the association between the AgentID and
the current attachment point, and derives attachment-related
communication properties (e.g., endpoint, supported
protocols, domain/policy context).
(F) Attachment Property Exposure: The Agent Gateway, or
another authorized attachment authority, may expose
attachment-derived properties to a Directory Service or
similar system. These properties enable discovery systems to
return information about how and where an entity is currently
attached. The mechanisms for publishing, distributing, or
querying this information are outside the scope of AAP.
The following steps illustrate the high level operation of
agent attachment to an Agent Gateway:
o Capability Discovery: An Agent may perform an out-of-band
inquiry to a Directory Service, for example, to find an
agent capable of JSON-to-XML translation. The Directory
Service may return one or more Target AgentIDs that
satisfy the request. At this stage, the Agent has
identified the target agent(s) but may not know where
those agents are currently attached in the network. The
capability discovery mechanism is outside the scope of
this document.
o Gateway Discovery: The Agent discovers a candidate local
Agent Gateway using a supported bootstrap mechanism, such
as anycast, DNS-based resolution, DHCP-based
provisioning, or pre-configuration. The Agent may send a
GW-DISCOVER message, and one or more reachable Agent
Gateways may respond with GW-OFFER messages containing
the Gateway identifier, attachment endpoint, supported
protocols, and other attachment parameters.
o Handshake and Registration: The Agent selects an Agent
Gateway and performs a mutual authentication handshake.
During this process, the Agent provides its AgentID and
cryptographic proof of identity. Upon successful
validation, the Agent Gateway establishes an attachment
context and records the association between the AgentID
and the current attachment point.
Dunbar, et al. Expires Dec 1, 2026 [Page 12]
Internet-Draft Agent-Attachment
o Attachment Property Derivation: After successful
attachment, the Agent Gateway derives and maintains
attachment related communication properties for the
Agent. These may include endpoint identifiers, supported
protocols, attachment point identifiers, domain
information, and policy context. These properties reflect
the Agent's current network attachment and may change as
the Agent moves, detaches, re-attaches, or changes
Gateway.
o Exposure to External Systems: The attachment-derived
properties may be made available to external systems,
such as Directory Services or future control-plane
mechanisms. This enables discovery systems to return
information about how and where an Agent is currently
attached. The mechanisms for publishing, querying,
distributing, or using these properties are outside the
scope of this document.
6. Agent Gateway Bootstrap and Attachment
In a dynamic environment, an Agent cannot assume a fixed
attachment point. An Agent's network attachment may change
over time due to mobility, multi-homing, scaling, policy
decisions, or deployment constraints. Therefore, the Agent
Attachment Protocol (AAP) defines bootstrap mechanisms that
allow an Agent to identify a candidate Agent Gateway and
establish an attachment context.
The mechanisms described in this section are limited to
identifying a candidate Agent Gateway for attachment and
establishing the attachment state. They are not part of
entity discovery and do not define how agents discover other
agents.
AAP supports multiple mechanisms for locating a candidate
Agent Gateway. These mechanisms are treated as bootstrap
options and do not alter the attachment, authentication, or
registration procedures defined in this document.
Dunbar, et al. Expires Dec 1, 2026 [Page 13]
Internet-Draft Agent-Attachment
6.1. Bootstrap Mechanisms
An Agent MAY use one or more of the following mechanisms to
identify a candidate Agent Gateway:
6.1.1. Anycast-Based Discovery
An Agent MAY identify a nearby Agent Gateway by sending a GW-
DISCOVER message to a well-known anycast address. The message
MAY include the AgentID and a nonce.
Any Agent Gateway reachable via the anycast address MAY
respond with a GW-OFFER message. Anycast-based bootstrap
enables topology-aware selection of a nearby Gateway without
requiring pre-configuration.
6.1.2. DHCP-Based Bootstrapping
In managed access networks, the Agent Gateway MAY be co-
located with, or designated by, the IP gateway for the
Agent's access network. In such environments, DHCP MAY be
used to provide the Agent with unicast bootstrap information
for an Agent Gateway, such as an IP address, FQDN, or service
endpoint.
DHCP-based information MUST be treated as advisory. The Agent
MUST still perform the authentication and registration
procedures defined in Section 5.3 before establishing an
attachment.
6.1.3. DNS-Based Bootstrap
A system external to AAP (e.g., a directory or configuration
service) MAY provide a stable Agent Gateway identifier, such
as a URL or FQDN. The Agent MAY use DNS resolution to obtain
a reachable address for the Gateway.
DNS-based bootstrap provides scalable reachability but does
not replace the explicit attachment and authentication
procedures defined by AAP..
Dunbar, et al. Expires Dec 1, 2026 [Page 14]
Internet-Draft Agent-Attachment
6.2. Gateway Offer and Selection
For bootstrap mechanisms that involve Gateway responses
(e.g., anycast-based bootstrap), an Agent Gateway MAY respond
with a GW-OFFER message containing:
o Gateway identifier
o Transport endpoint (e.g., URI or IP address)
o Supported attachment protocols and parameters
The Agent selects one Gateway based on local policy and
proceeds with the attachment procedure.
6.3. Handshake and Registration
The Agent initiates a mutual authentication handshake with
the selected Agent Gateway, providing its AgentID and
cryptographic proof of identity.
Upon successful validation, the Agent Gateway establishes an
attachment context and records the association between the
AgentID and the current attachment point. This attachment
context reflects the Agent's current network presence and may
include information such as attachment point identifier,
supported protocols, and domain or policy context.
The Agent Gateway maintains this attachment state for the
duration of the attachment.
6.4. Attachment Property Derivation
Following successful attachment, the Agent Gateway derives
and maintains a set of attachment-related communication
properties associated with the Agent's current attachment.
These properties MAY include:
o Endpoint identifiers
o Supported communication protocols
o Attachment point identifiers
o Domain or administrative context
o Policy-related attributes
Dunbar, et al. Expires Dec 1, 2026 [Page 15]
Internet-Draft Agent-Attachment
These properties reflect the Agent's current network
attachment and may change as the Agent moves, detaches, or
re-attaches.
6.5. Exposure of Attachment Properties
The attachment-related properties derived by the Agent
Gateway MAY be made available to external systems, such as
directory services or other control-plane mechanisms.
This enables discovery systems to include information about
how and where an Agent is currently attached. The mechanisms
for publishing, distributing, querying, or consuming these
properties are outside the scope of AAP.
7. Use of Attachment State (Informative)
This section describes how attachment state established by
AAP may be used by other mechanisms. The behavior described
here is illustrative only. AAP does not define forwarding
protocols, routing mechanisms, or transport architectures,
but provides the attachment-derived information required to
enable them.
7.1. Attachment State Representation
An Agent Gateway maintains attachment state for each attached
Agent. This state reflects the current binding between an
AgentID and its attachment context.
The attachment state MAY include:
o AgentID
o Attachment point identifier (e.g., local interface or
ingress context)
o Reachable endpoint identifier (e.g., URI, IP address,
or service endpoint)
o Supported communication protocols
o Domain or administrative context
o Policy-related attributes
Dunbar, et al. Expires Dec 1, 2026 [Page 16]
Internet-Draft Agent-Attachment
This information is derived during the attachment process and
updated as the Agent attaches, detaches, or changes its point
of attachment.
7.2. Use of Attachment State by External Systems
Attachment state may be consumed by systems external to AAP,
such as:
o discovery or directory services,
o routing or control-plane mechanisms,
o policy enforcement systems.
These systems may use attachment related properties to
determine how to reach an Agent, exchange reachability
information, or optimize communication paths.
For example, a control-plane mechanism may use attachment
point identifiers and domain information to select a
preferred path to an Agent when multiple attachment options
exist.
AAP does not define how such systems operate or how the
information is exchanged between them.
7.3. Forwarding Using Attachment State (Example)
In some deployments, attachment state may be used by edge
nodes to support message forwarding between Agents.
An Agent Gateway may act as a forwarding element within a
domain or overlay system. Each Gateway MAY maintain a data
structure (e.g., a Message Forwarding Table, MFT) that maps
AgentIDs (or AgentID prefixes) to local attachment points or
next-hop Agent Gateways.
The MFT is derived from attachment state and updated
dynamically as agents attach, detach, or change their point
of attachment.
When a message is sent toward a target AgentID:
o If the target Agent is attached locally, the message
may be delivered to the corresponding attachment
point.
Dunbar, et al. Expires Dec 1, 2026 [Page 17]
Internet-Draft Agent-Attachment
o If the target Agent is attached to a remote Gateway,
the message may be forwarded to a next-hop Gateway
based on locally available state or control-plane
information.
If no matching entry exists, the Gateway MAY invoke a
resolution or discovery procedure to determine the current
attachment point of the target Agent. Such procedures are
outside the scope of this document.
7.4. Transport Header (Example)
AAP facilitates forwarding by enabling the use of forwarding-
relevant identifiers derived from attachment state.
In an example deployment, messages MAY include a cleartext
transport header carrying information such as:
o Target AgentID (or prefix)
o Message Identifier
o Time-to-Live (TTL)
o End-to-End Security Context Identifier
This header enables forwarding decisions based on AgentID
while keeping application-layer semantics opaque to
intermediate nodes.
7.5. Role in Routing and Control Plane
Attachment-derived properties defined by AAP may also be used
by routing or control-plane mechanisms.
For example:
o control-plane systems may exchange AgentID-to-
attachment mappings across domains,
o routing mechanisms may use attachment point
identifiers and domain information to determine
optimal paths, and
o policy systems may use attachment context to enforce
domain-specific constraints.
Dunbar, et al. Expires Dec 1, 2026 [Page 18]
Internet-Draft Agent-Attachment
AAP does not define these routing or control-plane
mechanisms, but provides the necessary attachment information
to enable them.
7.6. Payload Confidentiality
Agent Gateways do not inspect, decrypt, or interpret
application-layer payloads. Forwarding decisions are made
solely based on transport header information and attachment-
derived state.
End-to-end confidentiality and integrity are preserved
between communicating agents.
8. Attachment State Maintenance and Teardown
The relationship between an Agent and an Agent Gateway is
represented by attachment state, which reflects the Agent's
current network presence. This attachment state is dynamic
and may change over time as the Agent attaches, detaches, or
changes its point of attachment.
Attachment state MAY be maintained using either a stateful
model or a soft-state (stateless) model, depending on
deployment requirements and implementation choices.
8.1. Stateful Attachment Model
In a stateful attachment model, the Agent Gateway maintains
explicit attachment state for each attached Agent.
Keep-Alives:
An attached Agent periodically sends keep-alive or heartbeat
messages to the Agent Gateway to indicate continued presence.
If these messages are not received within a configured
interval, the Agent Gateway MAY mark the corresponding
attachment state as stale and eventually remove it.
Explicit Release:
When an Agent intends to detach, it MAY send a termination
signal (e.g., Session-End) to the Agent Gateway. Upon
receipt, the Agent Gateway removes the attachment state
associated with the AgentID.
Dunbar, et al. Expires Dec 1, 2026 [Page 19]
Internet-Draft Agent-Attachment
This model provides explicit control over attachment
lifecycle and enables precise tracking of active attachments.
8.2. Stateless (Soft-State) Attachment Model
In a soft-state model, the Agent Gateway treats attachment
state as time-bounded and does not rely on explicit teardown
signaling.
o Attachment state entries are created with a lifetime and
expire automatically unless refreshed.
o Periodic refresh messages or ongoing communication MAY
implicitly renew the attachment state.
o Absence of refresh activity results in automatic removal
of stale attachment state.
This model reduces signaling overhead and is suitable for
large-scale or highly dynamic environments.
8.3. Interoperability Considerations
Regardless of whether a stateful or soft-state model is used,
the semantics of attachment state remain consistent.
Implementations MUST ensure that stale or invalid attachment
state is removed in a timely manner to avoid incorrect or
outdated representation of an Agent's network attachment.
Implementations MAY support one or both models, provided that
the resulting attachment state accurately reflects the
Agent's current attachment context.
9. Security Considerations
The Agent Attachment Protocol (AAP) defines procedures for
establishing attachment between an Agent and an Agent
Gateway. Security in AAP focuses on protecting the integrity
of the attachment process and the correctness of the
resulting attachment state.
9.1. Authentication and Identity Binding
AAP MUST support mutual authentication between the Agent and
the Agent Gateway during the attachment process.
Dunbar, et al. Expires Dec 1, 2026 [Page 20]
Internet-Draft Agent-Attachment
o The Agent MUST provide cryptographic proof of its
identity (e.g., possession of a private key associated
with its AgentID).
o The Agent Gateway MUST authenticate the Agent before
establishing attachment state.
o The Agent MUST validate the identity of the Agent
Gateway to prevent attachment to unauthorized or
malicious gateways.
The attachment context established by AAP SHOULD include a
cryptographic binding between the AgentID and the
authenticated session to prevent impersonation or replay.
9.2. Integrity of Attachment State
The Agent Gateway maintains attachment state that associates
an AgentID with a current attachment point and related
properties.
Implementations MUST ensure that:
o attachment state cannot be modified by unauthorized
entities,
o stale or invalid attachment state is removed in a timely
manner, and
o updates to attachment state are authenticated and
integrity protected.
Incorrect or compromised attachment state may result in
misrepresentation of an Agent's reachability or communication
properties.
9.3. Protection of Attachment Exchanges
Messages exchanged during bootstrap, authentication, and
attachment establishment SHOULD be protected against
eavesdropping, tampering, and replay.
This MAY be achieved using existing secure transport
mechanisms (e.g., TLS, DTLS, QUIC, or equivalent). The
selection of specific transport protocols is outside the
scope of this document.
Dunbar, et al. Expires Dec 1, 2026 [Page 21]
Internet-Draft Agent-Attachment
9.4. Exposure of Attachment Properties
Attachment-related communication properties derived by the
Agent Gateway may be exposed to external systems, such as
directory services.
Care MUST be taken to ensure that:
o only authorized systems can access attachment-related
information,
o sensitive information (e.g., internal topology or policy
context) is not exposed beyond intended scope, and
o integrity and authenticity of published properties are
preserved.
Mechanisms for access control, distribution, and validation
of such information are outside the scope of AAP.
9.5. Relationship to End-to-End Security
AAP does not define agent-to-agent communication or
application-layer messaging. Therefore:
o AAP does not mandate end-to-end encryption between
Agents.
o AAP does not participate in application-layer security
contexts.
End-to-end security between Agents (e.g., confidentiality,
integrity, and authentication of exchanged data) MUST be
provided by mechanisms external to AAP.
10. Manageability Considerations
TBD
11. IANA Considerations
TBD
Dunbar, et al. Expires Dec 1, 2026 [Page 22]
Internet-Draft Agent-Attachment
12. References
12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
12.2. Informative References
.
13. Acknowledgments
Acknowledgements to xxx for their extensive review and
suggestions.
This document was prepared using 2-Word-v2.0.template.dot.
Appendix A:
Authors' Addresses
Linda Dunbar
Futurewei
Email: ldunbar@futurewei.com
Kausik Majumdar
Oracle
Email: kausik.majumdar@oracle.com
Contributors' Addresses
Dunbar, et al. Expires Dec 1, 2026 [Page 23]