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]

