# drafts

name: draft-mangrove-workgroup-mangrove
rev: 00
title: Mangrove: A Unified Framework for Internet Topology, Routing Abstraction, and Modeling
time: 2024-09-06T07:05:00Z
group_uri: /api/v1/group/group/1027/
expires: 2024-09-06T19:42:44Z
states: ["/api/v1/doc/state/2/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-07T06:55:14.591179+00:00
source: ietf
abstract:
  This document describes a novel system called Mangrove for obtaining global visibility across the Internet. It achieves this through constructing a comprehensive, unified representation of the Internet's topology and routing behavior by aggregating and indexing diverse data sources. he core challenge is obtaining an accurate, up-to-date model of how packets traverse the global Internet given the Internet's vast scale, dynamic nature, and fragmented visibility across multiple organizations collecting data in different formats.

  Mangrove addresses this by leveraging the hierarchical structure and natural abstractions of Internet architecture. It collects and integrates data from traceroute measurements, BGP routing tables, IP allocation records, and active broadband measurements. This multi-source data is partitioned and indexed across multiple granularity levels - geographic regions, autonomous systems, and IP prefixes - allowing effective storage, querying, and scalable processing.

  Mangrove constructs a unified topology and routing representation augmented with an extensible ruleset derived from Internet axioms and measured data. For arbitrary source-destination pairs, it computes estimated packet paths and associated performance metrics at the highest feasible granularity level based on available information completeness. The system handles real-time Internet dynamics through incremental rule refinement using detected changes in routing data and measurements. This enables timely updates to the topology model without full recomputation. Mangrove aims to provide researchers and operators an unprecedented unified Internet view for analysis, optimization, planning, security, and regulatory tasks.

full_text:
  ALTO                                                          Y. R. Yang
  Internet-Draft                                               B. L. Lewis
  Intended status: Standards Track                            D. M. Mertus
  Expires: 5 September 2024                                      A. S. Shi
                                                               J. Z. Zhang
                                                           Yale University
                                                              4 March 2024


        Mangrove: A Unified Framework for Internet Topology, Routing
                         Abstraction, and Modeling
                    draft-mangrove-workgroup-mangrove-00

  Abstract

     This document describes a novel system called Mangrove for obtaining
     global visibility across the Internet.  It achieves this through
     constructing a comprehensive, unified representation of the
     Internet's topology and routing behavior by aggregating and indexing
     diverse data sources. he core challenge is obtaining an accurate, up-
     to-date model of how packets traverse the global Internet given the
     Internet's vast scale, dynamic nature, and fragmented visibility
     across multiple organizations collecting data in different formats.

     Mangrove addresses this by leveraging the hierarchical structure and
     natural abstractions of Internet architecture.  It collects and
     integrates data from traceroute measurements, BGP routing tables, IP
     allocation records, and active broadband measurements.  This multi-
     source data is partitioned and indexed across multiple granularity
     levels - geographic regions, autonomous systems, and IP prefixes -
     allowing effective storage, querying, and scalable processing.

     Mangrove constructs a unified topology and routing representation
     augmented with an extensible ruleset derived from Internet axioms and
     measured data.  For arbitrary source-destination pairs, it computes
     estimated packet paths and associated performance metrics at the
     highest feasible granularity level based on available information
     completeness.  The system handles real-time Internet dynamics through
     incremental rule refinement using detected changes in routing data
     and measurements.  This enables timely updates to the topology model
     without full recomputation.  Mangrove aims to provide researchers and
     operators an unprecedented unified Internet view for analysis,
     optimization, planning, security, and regulatory tasks.

  Status of This Memo

     This Internet-Draft is submitted in full conformance with the
     provisions of BCP 78 and BCP 79.



  Yang, et al.            Expires 5 September 2024                [Page 1]


  Internet-Draft  Mangrove: A Unified Framework for Intern      March 2024


     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 5 September 2024.

  Copyright Notice

     Copyright (c) 2024 IETF Trust and the persons identified as the
     document authors.  All rights reserved.

     This document is subject to BCP 78 and the IETF Trust's Legal
     Provisions Relating to IETF Documents (https://trustee.ietf.org/
     license-info) in effect on the date of publication of this document.
     Please review these documents carefully, as they describe your rights
     and restrictions with respect to this document.  Code Components
     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 and Motivation . . . . . . . . . . . . . . . . .   3
     2.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   4
     3.  Internet Structure Overview . . . . . . . . . . . . . . . . .   5
     4.  Existing Systems Overview . . . . . . . . . . . . . . . . . .   6
     5.  Mangrove: A Framework For Internet Abstraction and
             Modeling  . . . . . . . . . . . . . . . . . . . . . . . .   7
       5.1.  Methodology . . . . . . . . . . . . . . . . . . . . . . .   8
       5.2.  System Architecture . . . . . . . . . . . . . . . . . . .  10
       5.3.  Scalability . . . . . . . . . . . . . . . . . . . . . . .  11
         5.3.1.  Geographic  . . . . . . . . . . . . . . . . . . . . .  11
         5.3.2.  AS  . . . . . . . . . . . . . . . . . . . . . . . . .  11
         5.3.3.  Subnet/Prefix . . . . . . . . . . . . . . . . . . . .  12
     6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
     7.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  13








  Yang, et al.            Expires 5 September 2024                [Page 2]


  Internet-Draft  Mangrove: A Unified Framework for Intern      March 2024


  1.  Introduction and Motivation

     The Internet is a vast and complex network of interconnected devices,
     spanning the globe and enabling communication between billions of
     users and systems.  Understanding the underlying topology and routing
     model of the Internet is crucial for researchers, network operators,
     and service providers to gain insights into routing dynamics,
     performance characteristics, and potential vulnerabilities.  However,
     the current state of Internet topology and routing mapping is
     fragmented, with multiple organizations and projects collecting data
     through various measurement techniques, such as traceroutes, BGP
     looking glass dumps, and performance metrics.  This data is often
     inconsistent in format, incomplete, and distributed across multiple
     sources, making it challenging to obtain a comprehensive and unified
     view of the Internet's topology.  We wish to build a system that
     unifies this information into a single representation of routing and
     topology models of the Internet at different points in time, allowing
     for queries to be performed against this representation.

     By creating a comprehensive model of the Internet’s topology and
     routing dynamics, this system will enable a wide range of
     applications and analysis, including:

     1.  Network monitoring/troubleshooting: The ability to detect and
         localize routing anomalies, such as loops, black holes, or
         performance degradation can aid in identifying and resolving
         network issues more efficiently.

     2.  Vulnerability assessment and security analysis: A unified view of
         the Internet's topology and routing can help identify potential
         vulnerabilities, such as single points of failure or routing
         hijacks, enabling proactive measures to enhance network security
         and resilience.

     3.  Traffic Engineering and Capacity Planning: By understanding the
         flow of traffic across the Internet, service providers can
         optimize resource allocation, load balancing, and capacity
         planning, improving overall network performance and efficiency.

     4.  Resilience and Disaster Recovery Planning: Modeling the impact of
         potential outages or failures on the Internet's topology and
         routing can inform disaster recovery strategies and contingency
         plans, ensuring business continuity and minimizing service
         disruptions.







  Yang, et al.            Expires 5 September 2024                [Page 3]


  Internet-Draft  Mangrove: A Unified Framework for Intern      March 2024


     5.  Privacy and Regulatory Compliance Analysis: The ability to map
         data flows across the Internet can aid in identifying potential
         privacy violations or regulatory non-compliance, enabling
         organizations to take proactive measures to protect user data and
         comply with relevant regulations.

  2.  Problem Statement

     Being able to construct a digital twin of a network as large as the
     Internet comes with unique requirements for our system.  These are,
     in no particular order:

     1.  Scalability: The sheer scale of the Internet poses a significant
         challenge for our system.  With over 17 billion devices connected
         and more than 60,000 networks or Autonomous Systems (ASes), each
         with its own internal topology, storing information about the
         paths interconnecting all these devices requires us to employ
         efficient indexing mechanisms and data structures that enable
         fast queries over large repositories of data.

     2.  Diverse Data Sources: The data required for topology mapping is
         scattered across multiple organizations, each with their own data
         collection methodologies, formats, and access methods (discussed
         below).  The diversity of formats, from traceroute data to BGP
         table dumps, coupled with varying updating cadences and access
         methods, presents a significant challenge.  Furthermore, the
         quality and completeness of the data can vary based on the
         vantage points of the collectors, leading to potential gaps or
         inconsistencies.  Our system must be capable of integrating data
         from these diverse sources in a way that is consistent and
         unified.

     3.  Partial Information: Many topology measurement techniques, such
         as traceroutes, can produce incomplete or missing information due
         to factors like firewalls, packet filters, or unresponsive
         devices.  This is often manifested as missing hops represented by
         asterisks (*) in the traceroute data.  Additionally, BGP routing
         data lacks granularity below the Autonomous System (AS) level
         paths.  IP geo-mapping databases, used to associate IP addresses
         with physical locations, also have inherent inaccuracies.
         Furthermore, performance data may be sampled or estimated
         statistically rather than being comprehensive.  As such, our
         system must be capable of producing the best-effort topology and
         routing representation for packets between two hosts, even when
         the input data is incomplete or partially missing.






  Yang, et al.            Expires 5 September 2024                [Page 4]


  Internet-Draft  Mangrove: A Unified Framework for Intern      March 2024


     4.  Real-time, Dynamic Updates: The Internet is a highly dynamic
         environment, with routing changes, network outages, and topology
         shifts occurring continuously.  Events like outages, attacks, or
         policy changes can trigger changes in the routing behavior, with
         BGP convergence times ranging from seconds to minutes after an
         event.  New links and nodes are constantly being added, while
         others are going down.  Our system needs mechanisms to detect
         these relevant changes and incrementally update the topology
         representation in real-time or near real-time.  However, this
         requirement presents a trade-off between the cost of performing
         full recomputations versus maintaining and applying deltas or
         incremental updates.  Additionally, our system must meet the time
         window requirements for how current the topology view needs to
         be, depending on the specific use case or application.

  3.  Internet Structure Overview

     At a high level, the objective of our framework is to compute a
     digital twin of the Internet routing system, and this system is
     complex:

     The Internet is composed of several layers, each serving a distinct
     function:

     1.  Link Layer: Governs the transfer of data between directly
         connected nodes.

     2.  Internet Layer: Handles logical addressing and routing of data
         across the network.

     3.  Transport Layer: Manages end-to-end communication and ensures
         reliable data transfer.

     4.  Application Layer: Enables network services and applications to
         interface with the underlying transport protocols.

     Sitting on top of these layers, Autonomous Systems (ASes) and the
     Border Gateway Protocol (BGP) govern how packets traverse networks
     operated by different administrative entities.

     The behavior of the Internet can be characterized by two principal
     components: the underlying network topology and the routing policies
     enforced by the protocol ruleset.  Network topology delineates the
     physical connectivity constraints that determine the paths packets
     can traverse.  However, network infrastructure is in a constant state
     of flux as devices are continually added, removed, or reconfigured,
     posing challenges for comprehensive topology measurement outside an
     AS's purview.  Routing policies dictate how packets are forwarded



  Yang, et al.            Expires 5 September 2024                [Page 5]


  Internet-Draft  Mangrove: A Unified Framework for Intern      March 2024


     along available paths in accordance with protocol rules.  Protocols
     like Equal-Cost Multi-Path (ECMP) routing introduce complexity,
     making the determination of single best paths more difficult.
     Furthermore, most devices do not expose their Forwarding Information
     Bases (FIBs), obscuring the precise ruleset implementations.

     Consequently, measurements provide the primary evidence of the
     effects induced by the combination of the underlying topology and the
     applied routing policies.  This abstraction of rule systems onto
     physical network elements results in observable path properties, such
     as latency, bandwidth, and jitter, which are crucial for
     characterizing end-to-end packet delivery performance between nodes.

  4.  Existing Systems Overview

     Current solutions for internet visibility topology generally divide
     their focuses across two key categories: topology and routing
     inference and metadata measurement.  Additionally, these solutions
     further subdivide into consumer solutions and enterprise solutions
     providing a mix of both aggregate and granular data measured in
     varying units of time.

     Topology and routing measurement solutions employ a collection
     paradigm that includes:

     1.  Distributed Nodes: Operated either by the organization itself or
         external contributors, these nodes form the backbone of data
         collection efforts.

     2.  Periodic Traceroute Measurements: Using tools such as paris
         traceroute, measurements are periodically collected between nodes
         to infer network topology.

     3.  Data Inference: The collected data is analyzed to infer the
         network topology, relying on the information returned by
         traceroute measurements.

     Metadata measurement solutions diverge from topology measurement
     primarily in the nature of data collected.  Unlike topology
     measurement, which focuses on the structure of the network, metadata
     measurement seeks to understand the properties of network paths.
     This requires a significantly larger dataset, typically sourced from
     a wide user base employing network measurement tools.  The process
     involves:

     1.  Connection to a Local Server: Establishing a baseline for
         measurement by connecting to a server in close proximity to the
         user.



  Yang, et al.            Expires 5 September 2024                [Page 6]


  Internet-Draft  Mangrove: A Unified Framework for Intern      March 2024


     2.  Connection Saturation: Maximizing the use of the connection to
         ensure comprehensive data collection.

     3.  Measurement Execution: Performing measurements to gather data on
         the connection.

     4.  Optional Traceroute Measurement: If feasible, supplementing the
         measurement with traceroute data for enhanced insight.

     5.  Statistical Inference: Applying statistical methods to the
         collected data to extrapolate insights on broadband measurements,
         with a focus on geographical specificity.

  5.  Mangrove: A Framework For Internet Abstraction and Modeling

     The existing choice between focusing on traceroute data or broadband
     connection measurements presents a significant trade-off for
     organizations.  To generate an accurate topology, organizations need
     control: owning the network devices, collecting traceroute data on a
     consistent schedule, and sending as many traceroutes as possible in
     ways that maximize inference.  However, broadband measurement
     requires detail and quantity: distributing access nodes, collecting
     as much consumer information as possible, using traceroutes as only
     secondary sources of information.  This tradeoff in required
     infrastructure has made it difficult to bridge the gap between
     topology, path inference, and associated metadata.

     Topology and routing inference is done through the analysis of data
     retrieved from techniques including traceroute experiments and BGP
     Looking Glass dumps.  This raw data alone provides insight into the
     ‘real’ structure of the Internet; traceroute measurements form the
     backbone of most existing Internet topology mapping efforts, and when
     combined with Autonomous System routing data, can be used to infer
     the paths that exist throughout the internet.  The primary technique
     for collecting these involves deploying a distributed set of vantage
     points or measurement nodes across the Internet.  These nodes
     periodically initiate traceroute experiments towards predetermined
     destination IP addresses or prefixes.  Many topology mapping projects
     like CAIDA's Ark and RIPE Atlas have deployed large measurement
     infrastructures consisting of hundreds or thousands of vantage points
     globally.  These provide diverse perspectives into Internet paths
     from different edge networks.

     Most existing platforms focus on either traceroute data collection
     and analysis, or BGP/routing data.  Very few solutions currently
     attempt an integrated data fusion across measurements, routing,
     geolocation and performance data.




  Yang, et al.            Expires 5 September 2024                [Page 7]


  Internet-Draft  Mangrove: A Unified Framework for Intern      March 2024


     We propose the engineering of a scalable system that aggregates and
     indexes data from various sources to construct a single, unified
     representation of Internet topology.  This representation would
     provide researchers and network operators with rich information about
     the connectivity between devices on the Internet, augmented by
     performance metrics that could inform them about connection quality
     between networks.

  5.1.  Methodology

     To construct this unified representation, our system will leverage
     the natural abstractions offered by Internet architecture to provide
     the best level of estimates for topologies and routing decisions.
     The core methodology involves the following steps:

     1.  Data Aggregation: Collect and integrate data from multiple
         sources, including CAIDA Ark traceroute measurements, BGP looking
         glass dumps, Regional Internet Registry (RIR) records, and
         performance data from projects like M-Lab, Ookla, and perfSONAR.

     2.  Abstraction: Leverage the natural abstractions in Internet
         architecture, such as the Autonomous System (AS) level, to
         represent topology at different granularities.  This allows the
         system to handle incomplete data and provide estimates at varying
         resolutions.  Represent this as a multidimensional graph where
         nodes can aggregate, inherit, or point to other nodes on the
         graph depending on the abstraction layer.

     3.  Rule Generation: Use network axioms to generate an initial set of
         rules for AS pathing using BGP dumps, traceroute first hops, and
         business relationships.  The system then repeatedly generates and
         refines lower rule sets using axioms, AS pathing, FIBs, and known
         clustering policies for levels of resolution from subnet to
         devices.

     4.  Compression: Completed rules are grouped into sets for their
         particular header space.  The system stores such classes in a
         tree which represents IP prefixes and addresses.  Indexing into
         and moving down levels for a chosen destination determines the
         rule-set.  This allows for constant-time indexing, with a slight
         space tradeoff.










  Yang, et al.            Expires 5 September 2024                [Page 8]


  Internet-Draft  Mangrove: A Unified Framework for Intern      March 2024


     5.  Path Inference: For a given source and destination IP address
         pair, the system will attempt to provide the highest certainty
         estimate of the path a packet would take, based on the aggregated
         data and rule trie.  If complete traceroute data is available, it
         will be used to provide a detailed IP-level path.  If not, the
         system will attempt to construct a path using the rule set for
         its IP prefix and graph edge weights.  The final fall back is to
         AS-level paths derived from BGP routing information.

     6.  Performance Enrichment: Augment the topology representation with
         performance metrics, such as bandwidth, latency, and throughput,
         obtained from sources like M-Lab and Ookla.  Such data can be
         added by matching consumer collected traceroutes with those of
         topology measurement solutions.  For AS-level paths, performance
         metrics can be averaged across nodes within each AS.

     With the above, we will provide users with an interface that they may
     use to query the path that a packet would take between any two
     arbitrary source and destination IP addresses.  Our system will
     leverage all of the information it has aggregated to provide a ‘best
     estimate’ of this path, while augmenting this with performance
     metrics at the highest level of resolution.

     To illustrate this, we consider a sample user query where a user
     wishes to know the path a packet would take between source IP address
     A and destination IP address B.

     At a high level, our system will do the following:

     1.  Map each IP address to their corresponding AS numbers: the system
         will maintain an IP address to AS lookup as a result of
         aggregating this data from several sources over time.  The most
         recent match for the IP address will be used.

     2.  Analyze BGP routing data for each corresponding AS: if the IP
         addresses lie in separate autonomous systems, we may query each
         of the corresponding BGP table representations for each AS to
         determine the AS path that a packet will use to get from A to B.

     3.  Infer AS-level Path: After determining the AS numbers for the
         source and destination IP addresses, and analyzing the BGP
         routing data for the corresponding ASes, the system can infer the
         AS-level path that a packet would take from the source AS to the
         destination AS.  This AS-level path would be a sequence of AS
         numbers, representing the path through different Autonomous
         Systems.





  Yang, et al.            Expires 5 September 2024                [Page 9]


  Internet-Draft  Mangrove: A Unified Framework for Intern      March 2024


     4.  Retrieve Traceroute Data for Each AS Hop: For each AS hop in the
         inferred AS-level path, the system will attempt to retrieve
         relevant traceroute data to reconstruct the IP-level path within
         that AS.  This can be done by querying the indexed traceroute
         data based on the source and destination AS numbers for that
         particular hop.

     5.  Reconstruct IP-level Path Within Each AS: If traceroute data is
         available for an AS hop, the system will use that data to
         reconstruct the IP-level path within that AS.If no traceroute
         data is available, the system will treat that AS hop as a single
         hop in the final path, representing the AS-level transition.

     6.  Handle Missing Hops and Incomplete Paths: If there are missing
         hops (represented by *) within an AS hop, the system will group
         consecutive * hops and represent them as a single AS-level hop in
         the final path.  If no traceroute data is available for an entire
         AS hop, the system will represent that hop at the AS-level in the
         final path.  This illustrates our concept of ‘granularity’ -
         where there is missing data at a specific resolution, we may
         resort to using data at a lower resolution (the AS level) to
         still provide some insight into the path.

     7.  Associate Performance Metrics: The system can then associate
         relevant performance metrics, such as latency, bandwidth, or
         throughput, with each hop in the final path.  In cases where our
         system must resort to lower resolutions, we may use aggregation
         and averaging techniques to provide a rough estimate on
         connectivity statistics for that portion of the path.

  5.2.  System Architecture

     The proposed system will consist of the following key components:

     1.  Data Collectors: Modules responsible for fetching and processing
         data from various sources, such as CAIDA Ark, BGP looking glass
         servers, RIRs, and performance measurement platforms.

     2.  Data Unification Engine: A central component that integrates and
         indexes the collected data into a unified representation,
         handling data format conversions, deduplication, and consistency
         checks.

     3.  Topology Database: A scalable and distributed data store designed
         to store and query the unified topology representation,
         supporting both IP-level and AS-level granularities.  The data
         will be represented as a multi-dimensional graph, its associated
         rule sets in equivalence classes, and a compressed trie.



  Yang, et al.            Expires 5 September 2024               [Page 10]


  Internet-Draft  Mangrove: A Unified Framework for Intern      March 2024


     4.  Query Engine: An engine with a custom query language that can
         quickly join data at multiple levels of resolution depending on
         the user request.

     5.  Interface: An API or user interface that allows researchers and
         network operators to submit source-destination IP pairs and
         retrieve the corresponding estimated paths, along with associated
         performance metrics.

     6.  Real-time Update Handler: A component that monitors for changes
         in the underlying data sources and triggers updates to the
         topology representation, ensuring it remains current with the
         dynamic nature of the Internet.

  5.3.  Scalability

     With regards to discussion about scalabiltiy, the partitioning and
     distribution of data across different levels can be structured as
     follows:

  5.3.1.  Geographic

     At the geographic level, the system can partition the data based on
     geographic regions or clusters.  This level is responsible for
     storing and managing the BGP routing data for the Autonomous Systems
     (ASes) within each geographic cluster.  The primary function of this
     level is to handle AS-level path inference and resolution based on
     the BGP routing data.

  5.3.2.  AS

     Within each geographic partition, the system can further partition
     the data by individual AS.  At this level, each AS is responsible for
     storing and managing its own internal routing topology and traceroute
     data.  This level is designed to handle IP-level path reconstruction
     and inference within the boundaries of a single AS.

     The AS-level partitions can maintain the following data:

     1.  Internal Routing Topology: This includes the router-level
         topology within the AS, representing the interconnections between
         routers and network devices.

     2.  Traceroute Data: Traceroute measurements conducted within the AS,
         capturing the IP-level paths between different ingress and egress
         points or subnets.





  Yang, et al.            Expires 5 September 2024               [Page 11]


  Internet-Draft  Mangrove: A Unified Framework for Intern      March 2024


     3.  Performance Metrics: Performance data (e.g., latency, bandwidth)
         associated with links or paths within the AS, obtained from
         sources like M-Lab or Ookla.

  5.3.3.  Subnet/Prefix

     To further enhance granularity and scalability, the system can
     introduce an additional level of partitioning at the subnet or IP
     prefix level.  This level can store traceroute data and performance
     metrics specific to individual subnets or IP prefixes within an AS.

     By partitioning the data at these multiple levels, the system can
     distribute the workload and storage requirements across different
     components, allowing for parallel processing and improved
     scalability.

     The workflow for resolving a path between a source and destination IP
     address would involve the following steps:

     1.  The geographic partition responsible for the source and
         destination ASes is identified, and the AS-level path is
         determined using the BGP routing data.

     2.  For each AS hop in the inferred AS-level path, the corresponding
         AS partition is queried to retrieve traceroute data and
         reconstruct the IP-level path within that AS.

     3.  If further granularity is required or available, the subnet/
         prefix level partitions can be consulted to obtain more detailed
         traceroute data and performance metrics for specific IP prefixes
         or subnets along the path.

  6.  IANA Considerations

     This document has no actions for IANA.

  7.  Security Considerations

     The collection, distribution of MoWIE information should consider the
     security requirements on information privacy and information
     integration protection and authentication in both sides.  Since the
     network status is not directly related to any special user, there is
     currently no any privacy issue.  But the information transmitted to
     the application can pass through a lot of middle box and can be
     changed by the man in the middle.  To protect the network
     information, an end to end encryption and integration is needed.
     Also, the network needs to authenticate the information exposure
     provided to right applications.  These security requirements can be



  Yang, et al.            Expires 5 September 2024               [Page 12]


  Internet-Draft  Mangrove: A Unified Framework for Intern      March 2024


     implemented by the TLS and other security mechanisms.

  Authors' Addresses

     Y. Richard Yang
     Yale University
     Watson 208A, 51 Prospect Street
     New Haven, CT 06511
     United States of America
     Email: yang.r.yang@yale.edu


     Bradley Lewis
     Yale University
     33 Lynwood Pl
     New Haven, CT 06511
     United States of America
     Email: bradley.lewis@yale.edu


     Daniel Mertus
     Yale University
     Unit 404, 367 Elm Street
     New Haven, CT 06511
     United States of America
     Email: daniel.mertus@yale.edu


     Alex Shi
     Yale University
     33 Lynwood Pl
     New Haven, CT 06511
     United States of America
     Email: alex.shi@yale.edu


     Joseph Zhang
     Yale University
     33 Lynwood Pl
     New Haven, CT 06511
     United States of America
     Email: joseph.zhang@yale.edu









  Yang, et al.            Expires 5 September 2024               [Page 13]


name: draft-ietf-grow-va
rev: 06
title: FIB Suppression with Virtual Aggregation
time: 2024-12-18T18:43:57Z
group_uri: /api/v1/group/group/1584/
expires: 2012-07-02T07:00:06Z
ad: /api/v1/person/person/101568/
states: ["/api/v1/doc/state/2/", "/api/v1/doc/state/150/", "/api/v1/doc/state/38/"]
categories: []
tags: []
fetched_at: 2026-03-07T06:55:14.591186+00:00
source: ietf
abstract:
  The continued growth in the Default Free Routing Table (DFRT)
     stresses the global routing system in a number of ways.  One of the
     most costly stresses is FIB size: ISPs often must upgrade router
     hardware simply because the FIB has run out of space, and router
     vendors must design routers that have adequate FIB.  FIB suppression
     is an approach to relieving stress on the FIB by not loading selected
     RIB entries into the FIB.  Virtual Aggregation (VA) allows ISPs to
     shrink the FIBs of any and all routers, easily by an order of
     magnitude with negligible increase in path length and load.  FIB
     suppression can be deployed autonomously by an ISP without requiring
     cooperation between adjacent ISPs, and can co-exist with legacy
     routers in the ISP.

full_text:
  Network Working Group                                         P. Francis
  Internet-Draft                                                   MPI-SWS
  Intended status: Informational                                     X. Xu
  Expires: July 2, 2012                                             Huawei
                                                                H. Ballani
                                                                Cornell U.
                                                                    D. Jen
                                                                      UCLA
                                                            R. Raszuk, Ed.
                                                              NTT MCL Inc.
                                                                  L. Zhang
                                                                      UCLA
                                                         December 30, 2011


                  FIB Suppression with Virtual Aggregation
                         draft-ietf-grow-va-06.txt

  Abstract

     The continued growth in the Default Free Routing Table (DFRT)
     stresses the global routing system in a number of ways.  One of the
     most costly stresses is FIB size: ISPs often must upgrade router
     hardware simply because the FIB has run out of space, and router
     vendors must design routers that have adequate FIB.  FIB suppression
     is an approach to relieving stress on the FIB by not loading selected
     RIB entries into the FIB.  Virtual Aggregation (VA) allows ISPs to
     shrink the FIBs of any and all routers, easily by an order of
     magnitude with negligible increase in path length and load.  FIB
     suppression can be deployed autonomously by an ISP without requiring
     cooperation between adjacent ISPs, and can co-exist with legacy
     routers in the ISP.

  Status of this Memo

     This Internet-Draft is submitted to IETF 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 http://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."




  Francis, et al.           Expires July 2, 2012                  [Page 1]


  Internet-Draft               FIB Suppression               December 2011


     This Internet-Draft will expire on July 2, 2012.

  Copyright Notice

     Copyright (c) 2011 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.



































  Francis, et al.           Expires July 2, 2012                  [Page 2]


  Internet-Draft               FIB Suppression               December 2011


  Table of Contents

     1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
       1.1.  Scope of this Document . . . . . . . . . . . . . . . . . .  5
       1.2.  Requirements notation  . . . . . . . . . . . . . . . . . .  5
       1.3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  5
     2.  Overview of Virtual Aggregation (VA) . . . . . . . . . . . . .  6
       2.1.  Mix of Legacy and VA Routers . . . . . . . . . . . . . . .  9
       2.2.  Summary of Tunnels and Paths . . . . . . . . . . . . . . .  9
     3.  Specification of VA  . . . . . . . . . . . . . . . . . . . . . 11
       3.1.  Legacy Routers . . . . . . . . . . . . . . . . . . . . . . 11
       3.2.  Advertising and Handling Virtual Prefixes (VP) . . . . . . 12
         3.2.1.  Distinguishing VPs from Sub-prefixes . . . . . . . . . 12
         3.2.2.  Limitations on Virtual Prefixes  . . . . . . . . . . . 12
         3.2.3.  Aggregation Point Routers (APR)  . . . . . . . . . . . 13
         3.2.4.  Non-APR Routers  . . . . . . . . . . . . . . . . . . . 14
         3.2.5.  Adding and deleting VPs  . . . . . . . . . . . . . . . 14
       3.3.  Border VA Routers  . . . . . . . . . . . . . . . . . . . . 15
       3.4.  Advertising and Handling Sub-Prefixes  . . . . . . . . . . 15
       3.5.  Suppressing FIB Sub-prefix Routes  . . . . . . . . . . . . 16
         3.5.1.  Selecting Popular Prefixes . . . . . . . . . . . . . . 16
       3.6.  New Configuration  . . . . . . . . . . . . . . . . . . . . 17
       3.7.  Interaction with Traffic Engineering . . . . . . . . . . . 18
     4.  Usage of MPLS Tunnels  . . . . . . . . . . . . . . . . . . . . 19
       4.1.  Usage of Inner Label . . . . . . . . . . . . . . . . . . . 19
     5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 20
     6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 20
       6.1.  Properly Configured VA . . . . . . . . . . . . . . . . . . 20
       6.2.  Mis-configured VA  . . . . . . . . . . . . . . . . . . . . 21
     7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
     8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
       8.1.  Normative References . . . . . . . . . . . . . . . . . . . 21
       8.2.  Informative References . . . . . . . . . . . . . . . . . . 22
     Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23

















  Francis, et al.           Expires July 2, 2012                  [Page 3]


  Internet-Draft               FIB Suppression               December 2011


  1.  Introduction

     ISPs today manage constant DFRT growth in a number of ways.  One way,
     of course, is for ISPs to upgrade their router hardware before DFRT
     growth outstrips the size of the FIB.  This may be too expensive for
     many ISPs.  They would prefer to extend the lifetime of routers whose
     FIBs can no longer hold the full DFRT.

     A common approach taken by lower-tier ISPs is to default route to
     their transit providers.  Routes to customers and peer ISPs are
     maintained, but everything else defaults to the provider.  This
     approach has several disadvantages.  First, packets to Internet
     destinations may take longer-than-necessary Autonomous System (AS)
     paths.  This problem can be mitigated through careful configuration
     of partial defaults, but this can require substantial configuration
     overhead.  A second problem with defaulting to providers is that the
     ISP is no longer able to provide the full DFRT to its customers.
     Finally, provider defaults prevents the ISP from being able to detect
     martian packets.  As a result, the ISP transmits packets that could
     otherwise have been dropped over its expensive provider links.

     An alternative is for the ISP to maintain full routes in its core
     routers, but to filter routes from edge routers that do not require a
     full DFRT.  These edge routers can then default route to the core
     routers.  This is often possible with edge routers that interface to
     customer networks.  The problem with this approach is that it cannot
     be used for all edge routers.  For instance, it cannot be used for
     routers that connect to transits.  It of course also does not help in
     cases where core routers themselves have inadequate FIB capacity.

     FIB Suppression is an approach to shrinking FIB size that requires no
     changes to BGP, no changes to packet forwarding mechanisms in
     routers, and relatively minor changes to control mechanisms in
     routers and configuration of those mechanisms.  The core idea behind
     FIB suppression is to run BGP as normal, and in particular to not
     shrink the RIB, but rather to not load certain RIB entries into the
     FIB.  This approach minimizes changes to routers, and in particular
     is simpler than more general routing architectures that try to shrink
     both RIB and FIB.  With FIB suppression, there are no changes to BGP
     per se.  The BGP decision process does not change, the selected AS-
     PATH does not change, and except on rare occasion the exit router
     does not change.  ISPs can deploy FIB suppression autonomously and
     with no coordination with neighboring ASes.

     This document describes an approach to FIB suppression called
     "Virtual Aggregation" (VA).  VA operates by organizing the IP (v4 or
     v6) address space into Virtual Prefixes (VP), and using tunnels to
     aggregate the (regular) sub-prefixes within each VP.  The decrease in



  Francis, et al.           Expires July 2, 2012                  [Page 4]


  Internet-Draft               FIB Suppression               December 2011


     FIB size can be dramatic, easily 5x or 10x with only a slight path
     length and router load increase [nsdi09].

  1.1.  Scope of this Document

     The scope of this document is limited to intra-domain VA operation.
     Individual ASs autonomously operate VA internally without any
     coordination with neighboring ASs.  For the remainder of this
     document, the terms ISP, AS, and domain are used interchangeably.

     This document applies equally to IPv4 and IPv6.

     This document is limited to the following tunnel types: MPLS Label
     Switched Paths (LSP), and of MPLS inner labels tunneled over either
     LSPs or IP headers.

     VA may operate with a mix of upgraded routers and legacy routers.
     There are no topological restrictions placed on the mix of routers.
     In order to avoid loops between upgraded and legacy routers, packets
     are always tunneled by the VA routers to the BGP NEXT_HOPs of the
     matched BGP routes.  If a given local ASBR (Autonomous System Border
     Router) is a legacy router, it must be able to terminate tunnels.

  1.2.  Requirements notation

     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
     "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" when
     capitalized in this document are to be interpreted as described in
     [RFC2119].

  1.3.  Terminology

     Aggregation Point Router (APR):  An Aggregation Point Router (APR) is
        a router that aggregates a Virtual Prefix (VP) by installing
        routes (into the FIB) for all of the sub-prefixes within the VP.
        APRs advertise the VP to other routers with BGP.  For each sub-
        prefix within the VP, APRs have a tunnel from themselves to the
        remote ASBR (Autonomous System Border Router) where packets for
        that prefix should be delivered.
     Install and Suppress:  The terms "install" and "suppress" are used to
        describe whether a RIB entry has been loaded or not loaded into
        the FIB.  In particular, "install a route" means "install a route
        into the FIB", and "suppress a route" means "do not install a
        route into the FIB".







  Francis, et al.           Expires July 2, 2012                  [Page 5]


  Internet-Draft               FIB Suppression               December 2011


     Legacy Router:  A router that does not run VA, and has no knowledge
        of VA.  Legacy routers, however, must be able to terminate tunnels
        when they are local ASBRs.
     Non-APR Router:  In discussing VPs, it is often necessary to
        distinguish between routers that are APRs for that VP, and routers
        that are not APRs for that VP (but of course may be APRs for other
        VPs not under discussion).  In these cases, the term "APR" is
        taken to mean "a VA router that is an APR for the given VP", and
        the term "non-APR" is taken to mean "a VA router that is not an
        APR for the given VP".  The term non-APR router is not used to
        refer to legacy routers.
     Popular Prefix:  A Popular Prefix is a sub-prefix that is installed
        in a router in addition to the sub-prefixes it holds by virtue of
        being a Aggregation Point Router.  The Popular Prefix allows
        packets to follow the shortest path.  Note that different routers
        do not need to have the same set of Popular Prefixes.
     Routing Information Base (RIB):  The term RIB is used rather sloppily
        in this document to refer either to the loc-RIB (as used in
        [RFC4271]), or to the combined Adj-RIBs-In, the Loc-RIB, and the
        Adj-RIBs-Out.
     Sub-Prefix:  A regular (physically aggregatable) prefix.  These are
        equivalent to the prefixes that would normally comprise the DFRT
        in the absence of VA.  A VA router will contain a sub-prefix entry
        either because the sub-prefix falls within a Virtual Prefix for
        which the router is an APR, or because the sub-prefix is installed
        as a Popular Prefix.  Legacy routers hold the same sub-prefixes
        that they hold today.
     Tunnel:  This document specifies the use of MPLS Label Switched Paths
        (LSP), and of MPLS inner labels tunneled over either LSPs or IP
        headers.  While in principle other types of tunnels may be used,
        they are not specified here.  This document uses the term tunnel
        to refer to the above MPLS encapsulations.
     VA router:  A router that operates Virtual Aggregation according to
        this document.
     Virtual Prefix (VP):  A Virtual Prefix (VP) is a prefix used to
        aggregate its contained regular prefixes (sub-prefixes).  The set
        of sub-prefixes in a VP are not physically aggregatable, and so
        they are aggregated at APRs through the use of tunnels.
     VP-List:  A list of defined VPs.  All routers must agree on the
        contents of this list.


  2.  Overview of Virtual Aggregation (VA)

     For descriptive simplicity, this section starts by describing VA
     assuming that there are no legacy routers in the domain.  Section 2.1
     overviews the additional functions required by VA routers to
     accommodate legacy routers.



  Francis, et al.           Expires July 2, 2012                  [Page 6]


  Internet-Draft               FIB Suppression               December 2011


     A key concept behind VA is to operate BGP as normal, and in
     particular to populate the RIB with the full DFRT, but to suppress
     many or most prefixes from being loaded into the FIB.  By populating
     the RIB as normal, we avoid any changes to BGP, and changes to router
     operation are relatively minor.  The basic idea behind VA is as
     follows: The address space is partitioned into large prefixes ---
     larger than any aggregatable prefix in use today.  These prefixes are
     called Virtual Prefixes (VP).  Different VPs do not need to be the
     same size.  They may be a mix of /6, /7, /8 (for IPv4), and so on.
     Indeed, an ISP can define a single /0 VP, and use it for a core/edge
     type of configuration.  That is, the core routers would maintain full
     FIBs, and edge routers could maintain default routes to the core
     routers, and suppress as much of the FIB as they wish.  Each ISP can
     independently select the size of its VPs.

     VPs are not themselves topologically aggregatable.  VA makes the VPs
     aggregatable through the use of tunnels, as follows.  Associated with
     each VP are one or more "Aggregation Point Routers" (APR).  An APR
     (for a given VP) is a router that installs routes for all sub-
     prefixes (i.e. real physically aggregatable prefixes) within the VP.
     By "install routes" here, we mean:

     1.  The route for each of the sub-prefixes is loaded into the FIB,
         and
     2.  there is a tunnel from the APR to the BGP NEXT_HOP for the route.

     The APR originates a BGP route to the VP.  This route is distributed
     within the domain, but not outside the domain.  With this structure
     in place, a packet transiting the ISP goes from the ingress router to
     the APR (usually via a tunnel), and then from the APR to the BGP
     NEXT_HOP router via a tunnel.  VA can operate with MPLS LSPs, or with
     MPLS inner labels over LSPs or IP headers.  Section 4 specifies the
     usage of MPLS tunnels.  Other tunnel types (i.e., GRE) may be used,
     but are not specified in this document.

     The BGP NEXT_HOP can be either the local ASBR or the remote ASBR.  In
     the former case, an inner label is used to tunnel packets
     (Section 4.1).  In either case, all tunnel headers are stripped by
     the local ASBR before the packet is delivered to the remote ASBR.  In
     other words, the remote ASBR sees a normal IP packet, and is
     completely unaware of the existence of VA in the neighboring ISP.

     Note that the AS-PATH is not effected at all by VA.  This means among
     other things that AS-level policies are not effected by VA.  The
     packet may not, however, follow the shortest path within the ISP
     (where shortest path is defined here as the path that would have been
     taken if VA were not operating), because the APR may not be on the
     shortest path between the ingress and egress routers.  When this



  Francis, et al.           Expires July 2, 2012                  [Page 7]


  Internet-Draft               FIB Suppression               December 2011


     happens, the packet experiences additional latency and creates extra
     load (by virtue of taking more hops than it otherwise would have).
     Note also that, with VA, a packet may occasionally take a different
     exit point than it otherwise would have.  This can occur for instance
     when the exit point nearest to the selected APR is different than the
     exit point nearest to the router initiating the tunnel to the APR.

     VA can avoid traversing the APR for selected routes by installing
     these routes in non-APR routers.  In other words, even if an ingress
     router is not an APR for a given sub-prefix, it MAY install that sub-
     prefix into its FIB.  Packets in this case are tunneled directly from
     the ingress to the BGP NEXT_HOP.  These extra routes are called
     "Popular Prefixes", and are typically installed for policy reasons
     (e.g. customer routes are always installed), or for sub-prefixes that
     carry a high volume of traffic (Section 3.5.1).  Different routers
     may have different Popular Prefixes.  As such, an ISP may assign
     Popular Prefixes per router, per POP, or uniformly across the ISP.  A
     given router may have zero Popular Prefixes, or the majority of its
     FIB may consist of Popular Prefixes.  The effectiveness of Popular
     Prefixes to reduce traffic load relies on the fact that traffic
     volumes follow something like a power-law distribution: i.e. that 90%
     of traffic is destined to 10% of the destinations.  Internet traffic
     measurement studies over the years have consistently shown that
     traffic patterns follow this distribution [nsdi09], though there is
     no guarantee that they always will.

     Note that for routing to work properly, every packet must sooner or
     later reach a router that has installed a sub-prefix route that
     matches the packet.  This would obviously be the case for a given
     sub-prefix if every router has installed a route for that sub-prefix.
     If this is not the case, then there MUST be at least one Aggregation
     Point Router (APR) for the sub-prefix's Virtual Prefix (VP).
     Ideally, every POP contains at least two APRs for every Virtual
     Prefix.  By having APRs in every POP, the latency imposed by routing
     to the APR is minimal (the extra hop is within the POP).  By having
     more than one APR, there is a redundant APR should one fail.  In
     practice it is often not possible to have an APR for every VP in
     every POP.  This is because some POPs may have only one or a few
     routers, and therefore there may not have enough cumulative FIB space
     in the POP to hold every sub-prefix.  Note that any router ("edge",
     "core", etc.)  MAY be an APR.

     It is important that both the contents of BGP RIBs, as well as the
     contents of the Routing Table (as defined in Section 3.2 of
     [RFC4271]) not be modified by VA (other than the introduction of
     routes to VPs).  This is because PIM-SM [RFC4601] relies on the
     contents of the Routing Table to build its own trees and forwarding
     table.  Therefore, FIB suppression MUST take place between the



  Francis, et al.           Expires July 2, 2012                  [Page 8]


  Internet-Draft               FIB Suppression               December 2011


     Routing Table and the actual FIB(s).

  2.1.  Mix of Legacy and VA Routers

     It is important that an ISP be able to operate with a mix of "VA
     routers" and "legacy routers".  This allows ISPs to deploy VA in an
     incremental fashion and to continue to use routers that for whatever
     reason cannot be upgraded.  This document allows such a mix, and
     indeed places no topological restrictions on that mix.  It does,
     however, require that legacy routers are able to forward tunneled
     packets, are able to serve as tunnel endpoints, and are able to
     participate in distribution of tunnel information required to
     establish themselves as tunnel endpoints.  Depending on the tunnel
     type, legacy routers MAY also be able to initiate tunneled packets,
     though this is an OPTIONAL requirement.  Legacy routers MUST use
     their own address as the BGP NEXT_HOP.

  2.2.  Summary of Tunnels and Paths

     To summarize, the following tunnels are created:

     1.  From all VA routers to all BGP NEXT_HOP addresses (where the BGP
         NEXT_HOP address is either an APR, a local ASBR, or the remote
         ASBR neighbor of a VA router).
     2.  Optionally, from all legacy routers to all BGP NEXT_HOP
         addresses.
     There are a number of possible paths that packets may take through an
     ISP, summarized in the following diagram.  Here, "VA" is a VA router,
     "LR" is a legacy router, the symbol "==>" represents a tunneled
     packet (through zero or more routers), "-->" represents an untunneled
     packet, and "(pop)" represents stripping the tunnel header.  The
     symbol "::>" represents the portion of the path where although the
     tunnel is targeted to the receiving node, the outer header has been
     stripped.

















  Francis, et al.           Expires July 2, 2012                  [Page 9]


  Internet-Draft               FIB Suppression               December 2011


                                               Egress
                                               Router
             Ingress    Some       APR         (Local     Remote
             Router     Router     Router      ASBR)      ASBR
             -------    ------     ------      ------     --------
         1.    VA===================>VA=========>VA(pop)::::>Peer ASBR

         2.    VA===================>VA=========>LR--------->Peer ASBR

         3.    VA===============================>VA(pop)::::>Peer ASBR

         4.    VA===============================>LR--------->Peer ASBR

         (The following two exist in the case where legacy routers
          can initiate tunneled packets.)

         5.    LR===============================>VA(pop)::::>Peer ASBR

         6.    LR===============================>LR--------->Peer ASBR

         (The following two exist in the case where legacy routers
          cannot initiate tunneled packets.)

         7.    LR------->VA (remaining paths as in 1 to 4 above)

         8.    LR------->LR--------------------->LR--------->Peer ASBR


     The first and second paths represent the case where the ingress
     router does not have a Popular Prefix for the destination, and MUST
     tunnel the packet to an APR.  The third and fourth paths represent
     the case where the ingress router does have a Popular Prefix for the
     destination, and so tunnels the packet directly to the egress.  The
     fifth and sixth paths are similar to the third and fourth paths
     respectively, but where the ingress is a legacy router that can
     initiate tunneled packets, and effectively has the Popular Prefix by
     virtue of holding the entire DFRT.  (Note that some ISPs have only
     partial RIBs in their customer-facing edge routers, and default route
     to a router that holds the full DFRT.  This case is not shown here,
     but works perfectly well.)  Finally, paths 7 and 8 represent the case
     where legacy routers cannot initiate a tunneled packet.

     VA prevents the routing loops that might otherwise occur when VA
     routers and legacy routers are mixed.  In particular, VA avoids the
     case where a legacy router is forwarding packets towards the BGP
     NEXT_HOP, while a VA router is forwarding packets towards the APR,
     with each router thinking that the other is on the shortest path to
     their respective targets.



  Francis, et al.           Expires July 2, 2012                 [Page 10]


  Internet-Draft               FIB Suppression               December 2011


     In the first four types of path, the loop is avoided because tunnels
     are used all the way to the egress.  As a result, there is never an
     opportunity for a legacy router to try to route based on the
     destination address unless the legacy router is the egress, in which
     case it forwards the packet to the remote ASBR.

     In the 5th and 6th cases, the ingress is a legacy router, but this
     router can initiate tunnels and has the full FIB, and so simply
     tunnels the packet to the egress router.

     In the 7th and 8th cases, the legacy ingress cannot initiate tunnels,
     and so forwards the packet hop-by-hop towards the BGP NEXT_HOP.  The
     packet will work its way towards the egress router, and will either
     progress through a series of legacy routers (in which case the IGP
     prevents loops), or it will eventually reach a VA router, after which
     it will take tunnels as in the 1st and 2nd cases.


  3.  Specification of VA

     This section describes in detail how to operate VA.

  3.1.  Legacy Routers

     VA can operate with a mix of VA and legacy routers.  To prevent the
     types of loops described in Section 2.2, however, legacy routers MUST
     satisfy the following requirements:

     1.  When forwarding externally-received routes over iBGP, the BGP
         NEXT_HOP attribute MUST be set to the legacy router itself.
     2.  Legacy routers MUST be able to detunnel packets addressed to
         themselves at the BGP NEXT_HOP address.  They MUST also be able
         to convey the tunnel information needed by other routers to
         initiate tunneled packets to them.  If a legacy router cannot
         detunnel and convey tunnel parameters, then the AS cannot use VA.
     3.  Legacy routers MUST be able to forward all tunneled packets.
     4.  Every legacy router MUST hold its complete FIB.  Note, however,
         that this FIB does not necessarily need to contain the full DFRT.
         This might be the case, for instance, if the router is an edge
         router that defaults to a core router.

     As long as legacy routers participating in tunneling as described
     above there are no topological restrictions on the legacy routers.
     They may be freely mixed with VA routers without the possibility of
     forming sustained loops (Section 2.2).






  Francis, et al.           Expires July 2, 2012                 [Page 11]


  Internet-Draft               FIB Suppression               December 2011


  3.2.  Advertising and Handling Virtual Prefixes (VP)

  3.2.1.  Distinguishing VPs from Sub-prefixes

     VA routers MUST be able to distinguish VPs from sub-prefixes.  This
     is primarily in order to know which routes to install.  In
     particular, non-APR routers SHOULD know which prefixes are VPs before
     they receive routes for those VPs, for instance when they first boot
     up.  This is in order to avoid the situation where they unnecessarily
     start filling their FIBs with routes that they ultimately don't need
     to install (Section 3.5).  This leads to the following requirement:

     It MUST be possible to configure the complete list of VPs into all VA
     routers.  This list is known as the VP-List.

  3.2.2.  Limitations on Virtual Prefixes

     From the point of view of best-match routing semantics, VPs are
     treated identically to any other prefix.  In other words, if the
     longest matching prefix is a VP, then the packet is routed towards
     the VP.  If a packet matching a VP reaches an APR for that VP, and
     the APR does not have a better matching route, then the packet is
     discarded by the APR (just as a router that originates any prefix
     will discard a packet that does not have a better match).

     The overall semantics of VPs, however, are slightly different from
     those of real prefixes.  Without VA, when a router originates a route
     for a (real) prefix, the expectation is that the addresses within the
     prefix are within the originating AS (or a customer of the AS).  For
     VPs, this is not the case.  APRs originate VPs whose sub-prefixes
     exist in different ASes.  Because of this, VPs MUST not be advertised
     across AS boundaries.  This is done with NO_EXPORT Communities
     Attribute (Section 3.2.3).

     It is up to individual domains to define their own VPs.  VPs MUST be
     "larger" (span a larger address space) than any real sub-prefix.  If
     a VP is smaller than a real prefix, then packets that match the real
     prefix will nevertheless be routed to an APR owning the VP, at which
     point the packet will be dropped if it does not match a sub-prefix
     within the VP (Section 6).

     (Note that, in principle there are cases where a VP could be smaller
     than a real prefix.  This is where the egress router to the real
     prefix is a VA router.  In this case, the APR could theoretically
     tunnel the packet to the appropriate remote ASBR, which would then
     forward the packet correctly.  On the other hand, if the egress
     router is a legacy router, then the APR could not tunnel matching
     packets to the egress.  This is because the egress would view the VP



  Francis, et al.           Expires July 2, 2012                 [Page 12]


  Internet-Draft               FIB Suppression               December 2011


     as a better match, and would loop the packet back to the APR.  For
     this reason we require that VPs be larger than any real prefixes, and
     that APRs never install prefixes larger than a VP in their FIBs.)

     It is valid for a VP to be a subset of another VP.  For example, 20/7
     and 20/8 can both be VPs.  In fact, this capability is necessary for
     "splitting" a VP without temporarily increasing the FIB size in any
     router.  (Section 3.2.5).

  3.2.3.  Aggregation Point Routers (APR)

     For each VP for which a router is an APR, the router does the
     following:

     1.  The APR MUST originate a BGP route to the VP.  In this route, the
         NLRI are all of the VPs for which the router is an APR.  This is
         true even for VPs that are a subset of another VP.  The ORIGIN is
         set to INCOMPLETE (value 2), the AS number of the APR's AS is
         used in the AS_PATH, and the BGP NEXT_HOP is set to the address
         of the APR.  The ATOMIC_AGGREGATE and AGGREGATOR attributes are
         not included.
     2.  The APR MUST attach a NO_EXPORT Communities Attribute [RFC1997]
         to the route.
     3.  The APR MUST be able to detunnel packets addressed to itself at
         its BGP NEXT_HOP address.  It MUST also be able to convey the
         tunnel information needed by other routers to initiate tunneled
         packets to them.
     4.  If a packet is received at the APR whose best match route is the
         VP (i.e. it matches the VP but not any sub-prefixes within the
         VP), then the packet MUST be discarded (see Section 3.2.2).  This
         can be accomplished by never installing a prefix larger than the
         VP into the FIB, or by installing the VP as a route to \dev\null.

  3.2.3.1.  Selecting APRs

     An ISP is free to select APRs however it chooses.  The details of
     this are outside the scope of this document.  Nevertheless, a few
     comments are made here.  In general, APRs should be selected such
     that the distance to the nearest APR for any VP is small---ideally
     within the same POP.  Depending on the number of routers in a POP,
     and the sizes of the FIBs in the routers relative to the DFRT size,
     it may not be possible for all VPs to be represented in a given POP.
     In addition, there should be multiple APRs for each VP, again ideally
     in each POP, so that the failure of one does not unduly disrupt
     traffic.






  Francis, et al.           Expires July 2, 2012                 [Page 13]


  Internet-Draft               FIB Suppression               December 2011


  3.2.4.  Non-APR Routers

     A non-APR router MUST install at least the following routes:

     1.  Routes to VPs (identifiable using the VP-List).
     2.  Routes to all sub-prefixes that are not covered by any VP in the
         VP-List.

     If the non-APR has a tunnel to the BGP NEXT_HOP of any such route, it
     MUST use the tunnel to forward packets to the BGP NEXT_HOP.

     When an APR fails, routers must select another APR to send packets to
     (if there is one).  This happens, however, through normal internal
     BGP convergence mechanisms.

  3.2.5.  Adding and deleting VPs

     An ISP may from time to time wish to reconfigure its VP-List.  There
     are a number of reasons for this.  For instance, early in its
     deployment an ISP may configure one or a small number of VPs in order
     to test VA.  As the ISP gets more confident with VA, it may increase
     the number of VPs.  Or, an ISP may start with a small number of large
     VPs (i.e. /4's or even one /0), and over time move to more smaller
     VPs in order to save even more FIB.  In this case, the ISP will need
     to "split" a VP.  Finally, since the address space is not uniformly
     populated with prefixes, the ISP may want to change the size of VPs
     in order to balance FIB size across routers.  This can involve both
     splitting and merging VPs.  Of course, an ISP must be able to modify
     its VP-List without 1) interrupting service to any destinations, or
     2) temporarily increasing the size of any FIB (i.e. where the FIB
     size during the change is no bigger than its largest size either
     before or after the change).

     The first step for adding a VP is to configure the APRs for the VP.
     This causes the APRs to originate routes for the VP.  Non-APR routers
     will install this route according to the rules in Section 3.2.4 even
     though they do not yet recognize that the prefix is a VP.
     Subsequently the VP is added to the VP-List of non-APR routers.  The
     Non-APR routers can then start suppressing the sub-prefixes with no
     loss of service.

     To delete a VP, the process is reversed.  First, the VP is removed
     from the VP-Lists of non-APRs.  This causes the non-APRs to install
     the sub-prefixes.  After all sub-prefixes have been installed, the VP
     may be removed from the APRs.

     In many cases, it is desirable to split a VP.  For instance, consider
     the case where two routers, Ra and Rb, are APRs for the same prefix.



  Francis, et al.           Expires July 2, 2012                 [Page 14]


  Internet-Draft               FIB Suppression               December 2011


     It would be possible to shrink the FIB in both routers by splitting
     the VP into two VPs (i.e. split one /6 into two /7's), and assigning
     each router to one of the VPs.  While this could in theory be done by
     first deleting the larger VP, and then adding the smaller VPs, doing
     so would temporarily increase the FIB size in non-APRs, which may not
     have adequate space for such an increase.  For this reason, we allow
     overlapping VPs.

     To split a VP, first the two smaller VPs are added to the VP-Lists of
     all non-APR routers (in addition to the larger superset VP).  Next,
     the smaller VPs are added to the selected APRs (which may or may not
     be APRs for the larger VP).  Because the smaller VPs are a better
     match than the larger VP, this will cause the non-APR routers to
     forward packets to the APRs for the smaller VPs.  Next, the larger VP
     can be removed from the VP-Lists of all non-APR routers.  Finally,
     the larger VP can be removed from its APRs.

     To merge two VPs, the new larger VP is configured in all non-APRs.
     This has no effect on FIB size or APR selection, since the smaller
     VPs are better matches.  Next the larger VP is configured in its
     selected APRs.  Next the smaller VPs are deleted from all non-APRs.
     Finally, the smaller VPs are deleted from their corresponding APRs.

  3.3.  Border VA Routers

     A VA router that is an ASBR MUST do the following:

     1.  When forwarding externally-received routes over iBGP, if a tunnel
         with an inner label is used, the ASBR MUST set the BGP NEXT_HOP
         attribute to itself.  Otherwise, the BGP NEXT_HOP attribute is
         left unchanged.
     2.  They MUST establish tunnels as described in Section 4.
     3.  The ASBR MUST detunnel the packet before forwarding the packet to
         the remote ASBR.
     4.  The ASBR MUST be able to forward the packet without a FIB lookup.
         In other words, the tunnel information itself contains all the
         information needed by the border router to know which remote ASBR
         should receive the packet.

  3.4.  Advertising and Handling Sub-Prefixes

     Sub-prefixes are advertised and handled by BGP as normal.  VA does
     not effect this behavior.  The only difference in the handling of
     sub-prefixes is that they might not be installed in the FIB, as
     described in Section 3.5.

     In those cases where the route is installed, packets forwarded to
     prefixes external to the AS MUST be transmitted via the tunnel



  Francis, et al.           Expires July 2, 2012                 [Page 15]


  Internet-Draft               FIB Suppression               December 2011


     established as described in Section 3.3.

  3.5.  Suppressing FIB Sub-prefix Routes

     Any route not for a known VP (i.e. not in the VP-List) is taken to be
     a sub-prefix.  The following rules are used to determine if a sub-
     prefix route can be suppressed.

     1.  A VA router MUST NOT FIB-install a sub-prefix route for which
         there is no tunnel to the BGP NEXT_HOP address.  This is to
         prevent a loop whereby the APR forwards the packet hop-by-hop
         towards the next hop, but a router on the path that has FIB-
         suppressed the sub-prefix forwards it back to the APR.
     2.  If the router is an APR, a route for every sub-prefix within the
         VP MUST be FIB-installed (subject to the above limitation that
         there be a tunnel).
     3.  If a non-APR router has a sub-prefix route that does not fall
         within any VP (as determined by the VP-List), then the route MUST
         be installed.  This may occur because the ISP hasn't defined a VP
         covering that prefix, for instance during an incremental
         deployment build-up.
     4.  If an ASBR is using strict uRPF to do ingress filtering, then it
         MUST install routes for which the remote ASBR is the BGP NEXT_HOP
         [RFC2827].  Note that only an APR may do loose uRPF filtering,
         and then only for routes to sub-prefixes within its VPs.
     5.  All other sub-prefix routes MAY be suppressed.  Such "optional"
         sub-prefixes that are nevertheless installed are referred to as
         Popular Prefixes.  Note, however, that whether or not to install
         a given sub-prefix SHOULD NOT be based on whether or not there is
         an active route to a VP in the VP-List.  This avoids the
         situation whereby, during BGP initialization, the router receives
         some sub-prefix routes before receiving the corresponding VP
         route, with the result that it installs routes in its FIB that it
         will only remove a short time later, possibly even overflowing
         its FIB.

  3.5.1.  Selecting Popular Prefixes

     Individual routers MAY independently choose which sub-prefixes are
     Popular Prefixes.  There is no need for different routers to install
     the same sub-prefixes.  There is therefore significant leeway as to
     how routers select Popular Prefixes.  As a general rule, routers
     should fill the FIB as much as possible, because the cost of doing so
     is relatively small, and more FIB entries leads to fewer packets
     taking a longer path.  Broadly speaking, an ISP may choose to fill
     the FIB by making routers APRs for as many VPs as possible, or by
     assigning relatively few APRs and rather filling the FIB with Popular
     Prefixes.  Several basic approaches to selecting Popular Prefixes are



  Francis, et al.           Expires July 2, 2012                 [Page 16]


  Internet-Draft               FIB Suppression               December 2011


     outlined here.  Router vendors are free to implement whatever
     approaches they want.

     1.  Policy-based: The simplest approach for network administrators is
         to have broad policies that routers use to determine which sub-
         prefixes are designated as popular.  An obvious policy would be a
         "customer routes" policy, whereby all customer routes are
         installed (as identified for instance by appropriate community
         attribute tags).  Another policy would be for a router to install
         prefixes originated by specific ASes.  For instance, two ISPs
         could mutually agree to install each other's originated prefixes.
         A third policy might be to install prefixes with the shortest AS-
         PATH.
     2.  Static list: Another approach would be to configure static lists
         of specific prefixes to install.  For instance, prefixes
         associated with an SLA might be configured.  Or, a list of
         prefixes for the most popular websites might be installed.
     3.  High-volume prefixes: By installing high-volume prefixes as
         Popular Prefixes, the latency and load associated with the longer
         path required by VA is minimized.  One approach would be for an
         ISP to measure its traffic volume over time (days or a few
         weeks), and statically configure high-volume prefixes as Popular
         Prefixes.  There is strong evidence that prefixes that are high-
         volume tend to remain high-volume over multi-day or multi-week
         timeframes (though not necessarily at short timeframes like
         minutes or seconds).  High-volume prefixes MAY also be installed
         automatically.  For this, a router measures its own traffic
         volumes, and installs and removes Popular Prefixes in response to
         changes in traffic load.  The downside of this approach is that
         it complicates debugging network problems.  If packets are being
         dropped somewhere in the network, it is more difficult to find
         out where if the selected path can change dynamically.

  3.6.  New Configuration

     VA places new configuration requirements on ISP administrators.
     Namely, the administrator does the following.

     1.  Select VPs, and configure the VP-List into all VA routers.  As a
         general rule, having a larger number of relatively small prefixes
         gives administrators the most flexibility in terms of filling
         available FIB with sub-prefixes, and in terms of balancing load
         across routers.  Once an administrator has selected a VP-List, it
         is just as easy to configure routers with a large list as a small
         list.  A good list might be one where the number of VPs is
         relatively large, say 100 or so (noting again that each VP must
         be smaller than a real prefix), and the number of sub-prefixes
         within each VP is roughly the same.



  Francis, et al.           Expires July 2, 2012                 [Page 17]


  Internet-Draft               FIB Suppression               December 2011


     2.  Select and configure APRs.  There are three primary
         considerations here.  First, there needs to be enough APRs to
         failover to should one or more APRs crash.  Second, APR
         assignment should not result in router overload.  Third,
         excessively long paths should be avoided.  Ideally there should
         be two APRs for each VP within each PoP, but this may not be
         possible for small PoPs.  Failing this, there should be at least
         two APRs in each geographical region, so as to minimize path
         length increase.  Routers should have the appropriate counters to
         allow administrators to know the volume of APR traffic each
         router is handling so as to adjust load by adding or removing APR
         assignments.
     3.  Select and configure Popular Prefixes or Popular Prefix policies.
         There are two general goals here.  The first is to minimize load
         overall by minimizing the number of packets that take longer
         paths.  The second is to insure that specific selected prefixes
         don't have overly long paths.  These goals have to be weighed
         against the administrative overhead of configuring potentially
         thousands of Popular Prefixes.  As one example a small ISP may
         wish to keep it simple by doing nothing more than indicating that
         customer routes should be installed.  In this case, the
         administrator could otherwise assign as many APRs as possible
         while leaving enough FIB space for customer routes.  As another
         example, a large ISP could build a management system that takes
         into consideration the traffic matrix, customer SLAs, robustness
         requirements, FIB sizes, topology, and router capacity, and
         periodically automatically computes APR and Popular Prefix
         assignments.

  3.7.  Interaction with Traffic Engineering

     In VA, some traffic traverses an APR as an intermediate "hop", and
     some does not.  For that traffic that does not, there is no
     difference between how that traffic is handled and how it is handled
     in a non-VA network with edge-to-edge tunnels.  As a result, there
     should be no difference in how traffic engineering operates on that
     traffic.

     For traffic that does traverse APR "hop", the following holds: Any
     traffic engineering decisions that affect the BGP NEXT_HOP must be
     made at the APR.  Traffic engineering decisions that effects the
     router path through the AS may be handled in one of two ways.  First,
     the path decision may simply be made twice independently, once for
     the ingress-to-APR tunnel, and once for the APR-to-egress tunnel.
     This approach requires no changes to the traffic engineering
     mechanisms per se, but it may not make optimal path selection
     decisions.  Second, the traffic engineering decision may take into
     account both tunnels, even to the point of choosing among multiple



  Francis, et al.           Expires July 2, 2012                 [Page 18]


  Internet-Draft               FIB Suppression               December 2011


     transit APRs.  This approach may be more optimal, but is more complex
     and requires changes to existing mechanisms.

     Overall, if the majority of traffic does not involve an APR "hop",
     for instance through the use of popular prefixes, then VA in any
     event has a minimal impact on traffic engineering, and so the impact
     of VA may potentially be ignored.


  4.  Usage of MPLS Tunnels

     VA utilizes a straight-forward application of MPLS.  The tunnels are
     MPLS Label Switched Paths (LSP), and are signaled using either the
     Label Distribution Protocol (LDP) [RFC5036] or RSVP-TE [RFC3209].
     Both VA and legacy routers MUST participate in this signaling.

     APRs and ASBRs initiate tunnels.  In both cases, Downstream
     Unsolicited tunnels are initiated to all IGP neighbors with the full
     BGP NEXT_HOP address as the Forwarding Equivalence Class (FEC).  In
     the case of APRs, the BGP NEXT_HOP is the APR's own address.  In the
     case of legacy ASBRs, the BGP NEXT_HOP is the ASBR's own address.  In
     the case of VA ASBRs, the BGP NEXT_HOP is that of the remote ASBR.

     Existing Penultimate Hop Popping (PHP) mechanisms in the data plane
     can be used for forwarding packets to remote ASBRs.

  4.1.  Usage of Inner Label

     Besides using a separate LSP to identify the remote ASBR as described
     above, it is also possible to use an inner label to identify the
     remote ASBR.  Either an outer label or an IP tunnel identifies the
     local ASBR.

     When a local ASBR advertises a route into iBGP, it sets the NEXT_HOP
     to itself, and assigns a label to the route.  This label is used as
     the inner label, and identifies the remote ASBR from which the route
     was received [RFC3107].

     The presence of the inner label in the iBGP update acts as the signal
     to the receiving router that an inner label MUST be used in packets
     tunneled to the NEXT_HOP address.  If there is an LSP established
     targeted to the NEXT_HOP address, then it is used to tunnel the
     packet to the NEXT_HOP address.  Otherwise, an IP header address to
     the NEXT_HOP address is used.







  Francis, et al.           Expires July 2, 2012                 [Page 19]


  Internet-Draft               FIB Suppression               December 2011


  5.  IANA Considerations

     There are no IANA considerations.


  6.  Security Considerations

     We consider the security implications of VA under two scenarios, one
     where VA is assumed to be configured and operated correctly, and one
     where it is mis-configured.  A cornerstone of VA operation is that
     the basic behavior of BGP doesn't change, especially inter-domain.
     Among other things, this makes it easier to reason about security.

  6.1.  Properly Configured VA

     If VA is configured and operated properly, then the external behavior
     of an AS does not change.  The same upstream ASes are selected, and
     the same prefixes and AS-PATHs are advertised.  Therefore, a properly
     configured VA domain has no security impact on other domains.

     If another ISP starts advertising a prefix that is larger than a
     given VP, this prefix will be ignored by APRs that have a VP that
     falls within the larger prefix (Section 3.2.3).  As a result, packets
     that might otherwise have been routed to the new larger prefix will
     be dropped at the APRs.  Note that the trend in the Internet is
     towards large prefixes being broken up into smaller ones, not the
     reverse.  Therefore, such a larger prefix is likely to be invalid.
     If it is determined without a doubt that the larger prefix is valid,
     then the ISP will have to reconfigure its VPs.

     VA does not change an ISP's ability to do ingress filtering using
     strict uRPF (Section 3.5).

     Regarding DoS attacks, there are two issues that need to be
     considered.  First, does VA result in new types of DoS attacks?
     Second, does VA make it more difficult to deploy DoS defense systems.
     Regarding the first issue, one possibility is that an attacker
     targets a given router by flooding the network with traffic to
     prefixes that are not popular, and for which that router is an APR.
     This would cause a disproportionate amount of traffic to be forwarded
     to the APR(s).  While it is up to individual ISPs to decide if this
     attack is a concern, it does not strike the authors that this attack
     is likely to significantly worsen the DoS problem.

     Many DoS defense systems use dynamically established Routing Table
     entries to divert victims' traffic into LSPs that carry the traffic
     to scrubbers.  This mechanism works with VA---it simply over-rides
     whatever route is in place.  This mechanism works equally well with



  Francis, et al.           Expires July 2, 2012                 [Page 20]


  Internet-Draft               FIB Suppression               December 2011


     APRs and non-APRs.

  6.2.  Mis-configured VA

     VA introduces the possibility that a VP is advertised outside of an
     AS.  This in fact should be a low probability event since routers
     filter these, but it is considered here none-the-less.

     If an AS leaks a large VP (i.e. larger than any real prefixes), then
     the impact is minimal.  Smaller prefixes will be preferred because of
     best-match semantics, and so the only impact is that packets that
     otherwise have no matching routes will be sent to the misbehaving AS
     and dropped there.  If an AS leaks a small VP (i.e. smaller than a
     real prefix), then packets to that AS will be hijacked by the
     misbehaving AS and dropped.  (This can happen with or without VA, and
     so doesn't represent a new security problem per se.)

     Although VPs MUST be larger than real prefixes, there is
     intentionally no mechanism designed to automatically insure that this
     is the case.  Such a mechanisms would be dangerous.  For instance, if
     an ISP somewhere advertised a very large prefix (a /4, say), then
     this would cause APRs to throw out all VPs that are smaller than
     this.  For this reason, VPs must be set through configuration only.


  7.  Acknowledgements

     The authors would like to acknowledge the efforts of Xinyang Zhang
     and Jia Wang, who worked on CRIO (Core Router Integrated Overlay), an
     early inter-domain variant of FIB suppression, and the efforts of
     Hitesh Ballani and Tuan Cao, who worked on the configuration-only
     variant of VA that works with legacy routers.  We would also like to
     thank Scott Brim, Daniel Ginsburg, and Rajiv Asati for their helpful
     comments.  In particular, Daniel's comments significantly simplified
     the spec (eliminating the need for a new Extended Communities
     Attribute).  Finally, we would like to thank Wes George, Med
     Boucadair, and Bruno Decraene for their reviews and suggestions.


  8.  References

  8.1.  Normative References

     [RFC1997]  Chandrasekeran, R., Traina, P., and T. Li, "BGP
                Communities Attribute", RFC 1997, August 1996.

     [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119, March 1997.



  Francis, et al.           Expires July 2, 2012                 [Page 21]


  Internet-Draft               FIB Suppression               December 2011


     [RFC2827]  Ferguson, P. and D. Senie, "Network Ingress Filtering:
                Defeating Denial of Service Attacks which employ IP Source
                Address Spoofing", BCP 38, RFC 2827, May 2000.

     [RFC3107]  Rekhter, Y. and E. Rosen, "Carrying Label Information in
                BGP-4", RFC 3107, May 2001.

     [RFC3209]  Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
                and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
                Tunnels", RFC 3209, December 2001.

     [RFC4271]  Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
                Protocol 4 (BGP-4)", RFC 4271, January 2006.

     [RFC4601]  Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
                "Protocol Independent Multicast - Sparse Mode (PIM-SM):
                Protocol Specification (Revised)", RFC 4601, August 2006.

     [RFC5036]  Andersson, L., Minei, I., and B. Thomas, "LDP
                Specification", RFC 5036, October 2007.

  8.2.  Informative References

     [I-D.ietf-grow-simple-va]
                Francis, P., Xu, X., Ballani, H., Raszuk, R., and L.
                Zhang, "Simple Virtual Aggregation (S-VA)",
                draft-ietf-grow-simple-va-00 (work in progress),
                March 2010.

     [I-D.ietf-grow-va-gre]
                Francis, P., Raszuk, R., and X. Xu, "GRE and IP-in-IP
                Tunnels for Virtual Aggregation",
                draft-ietf-grow-va-gre-00 (work in progress), July 2009.

     [I-D.ietf-grow-va-mpls]
                Francis, P. and X. Xu, "MPLS Tunnels for Virtual
                Aggregation", draft-ietf-grow-va-mpls-00 (work in
                progress), May 2009.

     [I-D.ietf-grow-va-mpls-innerlabel]
                Xu, X. and P. Francis, "Proposal to use an inner MPLS
                label to identify the remote ASBR VA",
                draft-ietf-grow-va-mpls-innerlabel-00 (work in progress),
                September 2009.

     [nsdi09]   Ballani, H., Francis, P., Cao, T., and J. Wang, "Making
                Routers Last Longer with ViAggre", ACM Usenix NSDI 2009 ht
                tp://www.usenix.org/events/nsdi09/tech/full_papers/



  Francis, et al.           Expires July 2, 2012                 [Page 22]


  Internet-Draft               FIB Suppression               December 2011


                ballani/ballani.pdf, April 2009.


  Authors' Addresses

     Paul Francis
     Max Planck Institute for Software Systems
     Gottlieb-Daimler-Strasse
     Kaiserslautern  67633
     Germany

     Phone: +49 631 930 39600
     Email: francis@mpi-sws.org


     Xiaohu Xu
     Huawei Technologies
     No.3 Xinxi Rd., Shang-Di Information Industry Base, Hai-Dian District
     Beijing, Beijing  100085
     P.R.China

     Phone: +86 10 82836073
     Email: xuxh@huawei.com


     Hitesh Ballani
     Cornell University
     4130 Upson Hall
     Ithaca, NY  14853
     US

     Phone: +1 607 279 6780
     Email: hitesh@cs.cornell.edu


     Dan Jen
     UCLA
     4805 Boelter Hall
     Los Angeles, CA  90095
     US

     Phone:
     Email: jenster@cs.ucla.edu








  Francis, et al.           Expires July 2, 2012                 [Page 23]


  Internet-Draft               FIB Suppression               December 2011


     Robert Raszuk (editor)
     NTT MCL Inc.
     101 S Ellsworth Avenue Suite 350
     San Mateo, CA  94401
     US

     Email: robert@raszuk.net


     Lixia Zhang
     UCLA
     3713 Boelter Hall
     Los Angeles, CA  90095
     US

     Phone:
     Email: lixia@cs.ucla.edu


































  Francis, et al.           Expires July 2, 2012                 [Page 24]



name: draft-cowles-aee
rev: 00
title: Agent Envelope Exchange (AEE): A Minimal JSON Envelope Format for Inter-Agent Communication
time: 2026-02-28T21:57:29Z
group_uri: /api/v1/group/group/1027/
expires: 2026-09-01T21:57:29Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-07T06:55:14.591563+00:00
source: ietf
abstract:
  Agent Envelope Exchange (AEE) defines a minimal, transport-
     independent JSON envelope format for communication between autonomous
     AI agents, traditional services, and human participants.  The
     envelope comprises 14 well-defined fields that provide message
     identity, typing, correlation, tracing, priority, and extensibility
     without prescribing payload semantics or transport mechanisms.  AEE
     separates the concerns of message routing and lifecycle management
     (the envelope) from domain-specific meaning (intent schemas),
     enabling portable, composable, and auditable workflows across
     heterogeneous agent frameworks.  This document specifies the envelope
     structure, validity rules, conformance levels, entity identifier
     conventions, a reserved intent namespace for protocol negotiation,
     and a referencing strategy that avoids envelope nesting.

full_text:
  Independent Submission                                         A. Cowles
  Internet-Draft                                                  Quox Ltd
  Intended status: Experimental                           28 February 2026
  Expires: 1 September 2026


  Agent Envelope Exchange (AEE): A Minimal JSON Envelope Format for Inter-
                            Agent Communication
                            draft-cowles-aee-00

  Abstract

     Agent Envelope Exchange (AEE) defines a minimal, transport-
     independent JSON envelope format for communication between autonomous
     AI agents, traditional services, and human participants.  The
     envelope comprises 14 well-defined fields that provide message
     identity, typing, correlation, tracing, priority, and extensibility
     without prescribing payload semantics or transport mechanisms.  AEE
     separates the concerns of message routing and lifecycle management
     (the envelope) from domain-specific meaning (intent schemas),
     enabling portable, composable, and auditable workflows across
     heterogeneous agent frameworks.  This document specifies the envelope
     structure, validity rules, conformance levels, entity identifier
     conventions, a reserved intent namespace for protocol negotiation,
     and a referencing strategy that avoids envelope nesting.

  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 1 September 2026.

  Copyright Notice

     Copyright (c) 2026 IETF Trust and the persons identified as the
     document authors.  All rights reserved.




  Cowles                  Expires 1 September 2026                [Page 1]


  Internet-Draft                     AEE                     February 2026


     This document is subject to BCP 78 and the IETF Trust's Legal
     Provisions Relating to IETF Documents (https://trustee.ietf.org/
     license-info) in effect on the date of publication of this document.
     Please review these documents carefully, as they describe your rights
     and restrictions with respect to this document.

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   4
     3.  Envelope Format . . . . . . . . . . . . . . . . . . . . . . .   4
       3.1.  JSON Schema . . . . . . . . . . . . . . . . . . . . . . .   7
     4.  Message Types . . . . . . . . . . . . . . . . . . . . . . . .   7
     5.  Entity Identifiers  . . . . . . . . . . . . . . . . . . . . .   9
       5.1.  Identifier Format . . . . . . . . . . . . . . . . . . . .   9
       5.2.  Common Type Prefixes  . . . . . . . . . . . . . . . . . .   9
       5.3.  Causality Tracing Across Entity Types . . . . . . . . . .  10
     6.  Validity Rules  . . . . . . . . . . . . . . . . . . . . . . .  10
     7.  Conformance Levels  . . . . . . . . . . . . . . . . . . . . .  11
       7.1.  MVE-Required (Schema-Valid) . . . . . . . . . . . . . . .  11
       7.2.  MVE-5 (Log-Friendly)  . . . . . . . . . . . . . . . . . .  12
     8.  Signatures  . . . . . . . . . . . . . . . . . . . . . . . . .  12
     9.  Intent Namespace  . . . . . . . . . . . . . . . . . . . . . .  14
       9.1.  Naming Conventions  . . . . . . . . . . . . . . . . . . .  14
       9.2.  Reserved Namespace: aee.* . . . . . . . . . . . . . . . .  14
       9.3.  Intent Schema Publishing  . . . . . . . . . . . . . . . .  16
     10. Referencing Strategy  . . . . . . . . . . . . . . . . . . . .  16
       10.1.  Rationale: Avoiding Nested Envelopes . . . . . . . . . .  16
       10.2.  The payload.references Array . . . . . . . . . . . . . .  16
       10.3.  Exception: Archival and Forensic Snapshots . . . . . . .  17
     11. Security Considerations . . . . . . . . . . . . . . . . . . .  17
       11.1.  Replay Attacks and Correlation ID Uniqueness . . . . . .  18
       11.2.  Signature Verification and Trust Model . . . . . . . . .  18
       11.3.  Envelope Integrity Without Signatures  . . . . . . . . .  18
       11.4.  Privacy of Payload Contents  . . . . . . . . . . . . . .  19
       11.5.  Trust Boundaries Between Agents  . . . . . . . . . . . .  19
       11.6.  Denial of Service via Priority Field Abuse . . . . . . .  19
     12. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  20
     13. References  . . . . . . . . . . . . . . . . . . . . . . . . .  20
       13.1.  Normative References . . . . . . . . . . . . . . . . . .  20
       13.2.  Informative References . . . . . . . . . . . . . . . . .  20
     Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  21
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  21








  Cowles                  Expires 1 September 2026                [Page 2]


  Internet-Draft                     AEE                     February 2026


  1.  Introduction

     The rapid proliferation of autonomous AI agent frameworks --
     including LangGraph, AutoGen, CrewAI, and numerous proprietary
     systems -- has created a fragmented landscape for inter-agent
     communication.  Each framework defines its own message structures,
     correlation mechanisms, and error conventions, making it difficult to
     compose workflows that span multiple agent runtimes or organizational
     boundaries.

     Existing approaches suffer from several deficiencies:

     *  *No standard envelope format:* Messages lack a consistent
        structure for identity, typing, and metadata, forcing each
        integration to define bespoke serialization.

     *  *Lost causality:* Without standardized correlation and reply-to
        semantics, tracing a request through a chain of agents requires
        framework-specific tooling.

     *  *Coupled semantics:* Many systems conflate the message container
        with the message content, making it impossible to validate routing
        independently of payload.

     *  *Human exclusion:* Most agent protocols treat human participants
        as external to the messaging model rather than as first-class
        senders and recipients.

     AEE addresses these problems by defining a minimal 14-field JSON
     envelope that standardizes message identity, type classification,
     sender/recipient addressing, intent declaration, correlation,
     distributed tracing hooks, priority signaling, execution constraints,
     payload carriage, and optional cryptographic signatures.  The
     envelope is deliberately small and stable: it provides just enough
     structure for messages to be routed, correlated, traced, and
     validated, while delegating all domain-specific semantics to intent
     schemas that evolve independently.

     AEE does not prescribe a transport mechanism.  Envelopes MAY be
     carried over HTTP, WebSocket, NATS, Kafka, Redis Streams, or any
     other reliable or unreliable channel.  The protocol is intentionally
     transport-agnostic to maximize adoption across diverse deployment
     topologies.








  Cowles                  Expires 1 September 2026                [Page 3]


  Internet-Draft                     AEE                     February 2026


  2.  Conventions and Definitions

     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.

     The following terms are used throughout this document:

     Envelope  The top-level JSON object defined by this specification,
        containing metadata fields and a payload.

     Intent  A namespaced identifier declaring the semantic purpose of a
        message.  The intent determines which payload schema applies.

     Entity  Any participant in AEE communication: an autonomous agent, a
        traditional service, a human operator, or a broadcast channel.

     Correlation  The mechanism by which related messages (e.g., a task
        and its result) are linked via shared identifiers.

     MVE  Minimal Viable Envelope.  A subset of envelope fields sufficient
        for a particular conformance tier.

  3.  Envelope Format

     An AEE message is a JSON object [RFC8259] with exactly 14 top-level
     fields.  The envelope is designed to be small, stable, and forward-
     compatible.  The meaning of a message is determined by the
     combination of its "type" and "intent" fields; the "payload" carries
     intent-specific data whose schema is defined externally.

     +====+==========+=========+=============+==========================+
     | #  | Field    | Type    | Required    | Description              |
     +====+==========+=========+=============+==========================+
     | 1  | v        | string  | Yes         | Envelope schema version. |
     |    |          |         |             | For this specification,  |
     |    |          |         |             | the value MUST be "1".   |
     +----+----------+---------+-------------+--------------------------+
     | 2  | id       | string  | Yes         | Unique message           |
     |    |          |         |             | identifier.  ULID or     |
     |    |          |         |             | UUID [RFC4122] is        |
     |    |          |         |             | RECOMMENDED.  Minimum    |
     |    |          |         |             | length: 8 characters.    |
     +----+----------+---------+-------------+--------------------------+
     | 3  | ts       | string  | Yes         | Timestamp of message     |
     |    |          |         |             | creation.  ISO 8601 UTC  |



  Cowles                  Expires 1 September 2026                [Page 4]


  Internet-Draft                     AEE                     February 2026


     |    |          |         |             | format is RECOMMENDED    |
     |    |          |         |             | (e.g.,                   |
     |    |          |         |             | "2025-12-14T03:45:12Z"). |
     |    |          |         |             | Minimum length: 10       |
     |    |          |         |             | characters.              |
     +----+----------+---------+-------------+--------------------------+
     | 4  | type     | string  | Yes         | Message type.  MUST be   |
     |    |          |         |             | one of: "task",          |
     |    |          |         |             | "result", "event",       |
     |    |          |         |             | "error", "stream".       |
     +----+----------+---------+-------------+--------------------------+
     | 5  | from     | string  | Yes         | Sender entity identifier |
     |    |          |         |             | (see Section 5).         |
     |    |          |         |             | Minimum length: 1        |
     |    |          |         |             | character.               |
     +----+----------+---------+-------------+--------------------------+
     | 6  | to       | string  | Yes         | Recipient entity         |
     |    |          |         |             | identifier or channel    |
     |    |          |         |             | (see Section 5).         |
     |    |          |         |             | Minimum length: 1        |
     |    |          |         |             | character.               |
     +----+----------+---------+-------------+--------------------------+
     | 7  | intent   | string  | Yes         | Namespaced intent        |
     |    |          |         |             | identifier declaring the |
     |    |          |         |             | semantic purpose of the  |
     |    |          |         |             | message (see Section 9). |
     |    |          |         |             | Minimum length: 3        |
     |    |          |         |             | characters.              |
     +----+----------+---------+-------------+--------------------------+
     | 8  | corr     | string  | Yes         | Correlation identifier   |
     |    |          |         |             | linking all messages in  |
     |    |          |         |             | a workflow or            |
     |    |          |         |             | conversation thread.     |
     |    |          |         |             | Minimum length: 8        |
     |    |          |         |             | characters.              |
     +----+----------+---------+-------------+--------------------------+
     | 9  | reply_to | string  | Conditional | The "id" of the message  |
     |    |          | or null |             | being replied to.  MUST  |
     |    |          |         |             | be non-null (minimum 8   |
     |    |          |         |             | characters) when "type"  |
     |    |          |         |             | is "result" or "error".  |
     |    |          |         |             | SHOULD be null for other |
     |    |          |         |             | types.                   |
     +----+----------+---------+-------------+--------------------------+
     | 10 | trace    | object  | No          | Distributed tracing      |
     |    |          | or null |             | context with "trace_id"  |
     |    |          |         |             | and "span_id" string     |
     |    |          |         |             | properties.  RECOMMENDED |



  Cowles                  Expires 1 September 2026                [Page 5]


  Internet-Draft                     AEE                     February 2026


     |    |          |         |             | when an observability    |
     |    |          |         |             | system is in use.        |
     +----+----------+---------+-------------+--------------------------+
     | 11 | priority | string  | Yes         | Message priority.  MUST  |
     |    |          |         |             | be one of: "low",        |
     |    |          |         |             | "normal", "high",        |
     |    |          |         |             | "urgent".                |
     +----+----------+---------+-------------+--------------------------+
     | 12 | requires | object  | No          | Execution constraints    |
     |    |          | or null |             | and expectations.        |
     |    |          |         |             | Common keys include      |
     |    |          |         |             | "timeout_ms" (number),   |
     |    |          |         |             | "human_approval"         |
     |    |          |         |             | (boolean), "evidence"    |
     |    |          |         |             | (boolean), "format"      |
     |    |          |         |             | (string), and            |
     |    |          |         |             | "min_confidence"         |
     |    |          |         |             | (number, 0 to 1).        |
     |    |          |         |             | Unknown keys MUST be     |
     |    |          |         |             | ignored by consumers.    |
     +----+----------+---------+-------------+--------------------------+
     | 13 | payload  | object  | Yes         | Intent-specific data.    |
     |    |          |         |             | The shape is defined by  |
     |    |          |         |             | the intent schema, not   |
     |    |          |         |             | by this specification.   |
     |    |          |         |             | MUST be a JSON object.   |
     +----+----------+---------+-------------+--------------------------+
     | 14 | sig      | object, | No          | Optional cryptographic   |
     |    |          | string, |             | signature or             |
     |    |          | or null |             | authentication proof     |
     |    |          |         |             | (see Section 8).         |
     +----+----------+---------+-------------+--------------------------+

                         Table 1: AEE Envelope Fields

     The following example shows a complete AEE envelope of type "task":















  Cowles                  Expires 1 September 2026                [Page 6]


  Internet-Draft                     AEE                     February 2026


     {
       "v": "1",
       "id": "01JFB2R1JZKQ9V3K8W8Y9W1F2A",
       "ts": "2025-12-14T03:45:12Z",
       "type": "task",
       "from": "agent.manager",
       "to": "agent.backup_auditor",
       "intent": "ops.backup.status.check",
       "corr": "01JFB2QX0K8X5K6ZJ9G2C0C1MW",
       "reply_to": null,
       "trace": {"trace_id": "9f3c", "span_id": "a12b"},
       "priority": "high",
       "requires": {
         "timeout_ms": 30000,
         "evidence": true,
         "human_approval": false
       },
       "payload": {"cluster": "node.lan", "window": "24h"},
       "sig": null
     }

  3.1.  JSON Schema

     A normative JSON Schema (draft 2020-12) for the AEE v1 envelope is
     published alongside this specification.  The schema validates
     envelope structure only; intent-specific payload validation is
     performed by separate schemas associated with each intent.

     The schema enforces all required fields, type constraints,
     enumeration values, and the conditional requirement that "reply_to"
     MUST be a non-null string of at least 8 characters when "type" is
     "result" or "error".  The schema sets "additionalProperties" to true
     at the top level to support forward compatibility.

  4.  Message Types

     The "type" field classifies the purpose and expected behavior of each
     envelope.  Exactly five message types are defined:

     task  A request to perform work.  A "task" message sets an
        expectation that the recipient will eventually respond with either
        a "result" or an "error" envelope sharing the same "corr" value
        and a "reply_to" referencing this task's "id".  The sender MAY
        specify execution constraints in the "requires" field (e.g.,
        timeout, required evidence, human approval).

     result  Successful completion of a task.  The "reply_to" field MUST




  Cowles                  Expires 1 September 2026                [Page 7]


  Internet-Draft                     AEE                     February 2026


        contain the "id" of the originating "task" envelope.  The
        "payload" carries the intent-specific output of the completed
        work.

     event  An informational signal that does not require a reply.  Events
        are used for notifications, status broadcasts, and telemetry.  The
        "reply_to" field SHOULD be null.

     error  Unsuccessful completion of a task.  The "reply_to" field MUST
        contain the "id" of the originating "task" envelope.  The
        "payload" SHOULD include a "code" string, a human-readable
        "message" string, and a "retryable" boolean.  Additional fields
        such as "backoff_ms" and "evidence_refs" MAY be included.

     stream  A partial or progress update related to a task or long-
        running process.  Stream messages allow the recipient to observe
        intermediate state without waiting for the final result.  Multiple
        "stream" envelopes MAY share the same "corr" and precede the
        terminal "result" or "error".

     The following example shows a "result" envelope responding to the
     task shown in Section 3:

     {
       "v": "1",
       "id": "01JFB2S7T8N4J8B7QH1GJ8Z1Y2",
       "ts": "2025-12-14T03:45:20Z",
       "type": "result",
       "from": "agent.backup_auditor",
       "to": "agent.manager",
       "intent": "ops.backup.status.check",
       "corr": "01JFB2QX0K8X5K6ZJ9G2C0C1MW",
       "reply_to": "01JFB2R1JZKQ9V3K8W8Y9W1F2A",
       "trace": {"trace_id": "9f3c", "span_id": "b77c"},
       "priority": "high",
       "requires": {"evidence": true},
       "payload": {
         "status": "PARTIAL_FAILURE",
         "failed": [
           {"node": "pve02", "reason": "connection_refused:8007"}
         ],
         "confidence": 0.96,
         "evidence_refs": ["log:pbs01:job/2025-12-14T02:00Z"]
       },
       "sig": null
     }

     The following example shows an "error" envelope:



  Cowles                  Expires 1 September 2026                [Page 8]


  Internet-Draft                     AEE                     February 2026


     {
       "v": "1",
       "id": "01JFB2T3W9H0J1FQWQ7B2M3D5E",
       "ts": "2025-12-14T03:45:21Z",
       "type": "error",
       "from": "agent.backup_auditor",
       "to": "agent.manager",
       "intent": "ops.backup.status.check",
       "corr": "01JFB2QX0K8X5K6ZJ9G2C0C1MW",
       "reply_to": "01JFB2R1JZKQ9V3K8W8Y9W1F2A",
       "trace": {"trace_id": "9f3c", "span_id": "c01d"},
       "priority": "high",
       "requires": {"evidence": true},
       "payload": {
         "code": "E_TIMEOUT",
         "message": "PBS API did not respond within 30s",
         "retryable": true,
         "backoff_ms": 60000,
         "evidence_refs": ["tcp:pve02->pbs01:8007"]
       },
       "sig": null
     }

  5.  Entity Identifiers

     The "from" and "to" fields accept any entity identifier string.  AEE
     treats all participants -- autonomous agents, traditional services,
     human operators, and broadcast channels -- as first-class senders and
     recipients.  There is no distinction at the envelope level between a
     message sent by a human and one sent by an agent.

  5.1.  Identifier Format

     The RECOMMENDED identifier format is:

     <type>.<name>

     where "type" indicates the entity category and "name" is a locally
     unique identifier within that category.  Implementations MAY use any
     unique string, but the typed format improves debuggability and log
     readability.

  5.2.  Common Type Prefixes

     The following type prefixes are defined as conventions.  This list is
     not exhaustive; implementations MAY define additional prefixes.

     agent.*  Autonomous agents (e.g., "agent.backup_auditor",



  Cowles                  Expires 1 September 2026                [Page 9]


  Internet-Draft                     AEE                     February 2026


        "agent.code_reviewer").

     service.*  Traditional (non-agent) services (e.g., "service.billing",
        "service.auth").

     human.*  Human participants (e.g., "human.adam", "human.ops_lead").

     bus.*  Broadcast channels or topic-based routing targets (e.g.,
        "bus.ops", "bus.alerts").

  5.3.  Causality Tracing Across Entity Types

     When a human initiates a task that cascades through multiple agents,
     the full causality chain is traceable through the combination of
     "from", "to", "corr", and "reply_to" fields.  For example, a chain
     such as "human.adam" to "agent.router" to "agent.reviewer" to
     "service.linter" maintains complete provenance regardless of entity
     type at each hop.

  6.  Validity Rules

     The following rules are normative.  An AEE envelope that violates any
     MUST-level rule is invalid and SHOULD be rejected by conforming
     implementations.

     1.   The fields "v", "id", "ts", "type", "from", "to", "intent",
          "corr", "priority", and "payload" MUST be present in every
          envelope.

     2.   The "type" field MUST contain one of the following values:
          "task", "result", "event", "error", "stream".

     3.   If "type" is "result" or "error", the "reply_to" field MUST be
          present and MUST be a non-null string with a minimum length of 8
          characters, corresponding to the "id" of the originating "task"
          envelope.

     4.   The "payload" field MUST be a JSON object.  The structure of the
          payload is defined by the intent schema associated with the
          "intent" value.

     5.   The "v" field MUST contain the string "1" for envelopes
          conforming to this version of the specification.

     6.   The "priority" field MUST contain one of the following values:
          "low", "normal", "high", "urgent".





  Cowles                  Expires 1 September 2026               [Page 10]


  Internet-Draft                     AEE                     February 2026


     7.   Unknown top-level fields MUST be ignored by consumers.  This
          ensures forward compatibility: future versions or extensions may
          add fields without breaking existing implementations.

     8.   Consumers SHOULD log at minimum the following fields for
          observability: "id", "corr", "intent", "from", "to", "type", and
          "priority".

     9.   Producers SHOULD include the "trace" field with "trace_id" and
          "span_id" values when an observability or distributed tracing
          system is in use.

     10.  Within the "requires" object, unknown keys MUST be ignored by
          consumers.  Producers SHOULD keep the "requires" object compact.

  7.  Conformance Levels

     AEE supports incremental adoption through two defined conformance
     tiers.  Not every system needs full specification compliance on
     initial deployment.

  7.1.  MVE-Required (Schema-Valid)

     The Minimal Viable Envelope (MVE-Required) tier includes all fields
     required by the JSON Schema:

     *  "v"

     *  "id"

     *  "ts"

     *  "type"

     *  "from"

     *  "to"

     *  "intent"

     *  "corr"

     *  "priority"

     *  "payload"






  Cowles                  Expires 1 September 2026               [Page 11]


  Internet-Draft                     AEE                     February 2026


     A system emitting envelopes with all 10 MVE-Required fields is fully
     schema-valid and interoperable with any AEE-compliant consumer.  A
     system MAY claim MVE-Required compliance if:

     1.  It emits envelopes with all 10 required fields.

     2.  Those envelopes validate against the AEE v1 JSON Schema.

     3.  The "reply_to" field is non-null for "result" and "error" types.

     MVE-Required certification attests to structural compliance only.  It
     does not certify payload schema conformance, semantic correctness of
     intents, or support for the "aee.*" protocol intents defined in
     Section 9.

  7.2.  MVE-5 (Log-Friendly)

     For logging, telemetry, and observability-only contexts, a 5-field
     subset is recognized:

     *  "v"

     *  "id"

     *  "type"

     *  "from"

     *  "intent"

     MVE-5 is *NOT* schema-valid AEE.  It is a convenience envelope for
     systems that only emit logs or telemetry and do not participate in
     request/response flows.  MVE-5 envelopes:

     *  Can be parsed by AEE-aware log aggregators.

     *  Cannot be used for task/result correlation (missing "corr" and
        "reply_to").

     *  SHOULD NOT be sent to agents expecting full envelopes.

  8.  Signatures

     The "sig" field provides an OPTIONAL mechanism for cryptographic
     authentication and integrity verification of AEE envelopes.  When
     signatures are used, the signing process SHOULD bind at minimum the
     following fields:




  Cowles                  Expires 1 September 2026               [Page 12]


  Internet-Draft                     AEE                     February 2026


     *  "v"

     *  "id"

     *  "ts"

     *  "type"

     *  "from"

     *  "to"

     *  "intent"

     *  "corr"

     *  "reply_to"

     *  "payload"

     The "sig" field MAY be a JSON object or a string.  When it is an
     object, the following structure is RECOMMENDED:

     {
       "alg": "ed25519",
       "kid": "key-2",
       "value": "<base64-encoded-signature>"
     }

     alg  The signature algorithm.  Ed25519 is RECOMMENDED for new
        implementations.  HMAC-SHA256 ("HS256") MAY also be used in
        symmetric-key environments.

     kid  Key identifier, enabling key rotation and multi-key
        environments.

     value  The signature or HMAC value, typically Base64-encoded.

     This specification does not define a key distribution mechanism.
     Deployments SHOULD establish key management procedures appropriate to
     their trust model.  Future companion documents may define a security
     profile with detailed signing procedures, key exchange, and replay
     protection.








  Cowles                  Expires 1 September 2026               [Page 13]


  Internet-Draft                     AEE                     February 2026


  9.  Intent Namespace

     The "intent" field carries a namespaced identifier that declares the
     semantic purpose of a message.  The intent determines which payload
     schema applies: each intent publishes separate schemas for "task",
     "result", and (optionally) "error" payloads.  This separation means
     the envelope can be validated independently of payload content.

  9.1.  Naming Conventions

     The RECOMMENDED naming format uses flexible dotted notation:

     <domain>.<subdomain>.<noun>.<verb>

     Examples:

     *  "ops.network.port.probe"

     *  "ops.backup.status.check"

     *  "infra.proxmox.vm.create"

     *  "docs.summarize.with_citations"

     Verbs SHOULD be explicit (e.g., "check", "probe", "create",
     "summarize").  Implementations SHOULD avoid overloading a single
     intent with multiple optional behaviors.  Intent schemas MAY be
     versioned independently of the AEE envelope specification.

     If two agents cannot agree on an intent identifier, they do not share
     semantics.  The absence of a recognized intent is not an error; it
     simply indicates that the agents lack a shared vocabulary for that
     operation.

  9.2.  Reserved Namespace: aee.*

     The "aee.*" namespace is reserved for protocol negotiation and
     context retrieval.  These intents enable agents to discover
     capabilities, fetch context, and validate payloads without custom
     integration.  They are protocol primitives, not orchestration
     mechanisms.

     The following core intents are defined:








  Cowles                  Expires 1 September 2026               [Page 14]


  Internet-Draft                     AEE                     February 2026


      +======================+=========================================+
      | Intent               | Purpose                                 |
      +======================+=========================================+
      | aee.status.ping      | Liveness check.  The recipient MUST     |
      |                      | respond with a result containing        |
      |                      | {"pong": true}.                         |
      +----------------------+-----------------------------------------+
      | aee.status.health    | Health and readiness status.  The       |
      |                      | result payload MUST include a "status"  |
      |                      | field with one of: "healthy",           |
      |                      | "degraded", "unhealthy".                |
      +----------------------+-----------------------------------------+
      | aee.spec.query       | Return supported AEE version and        |
      |                      | capabilities.  The result MUST include  |
      |                      | "aee_version" and MAY include an        |
      |                      | "extensions" array.                     |
      +----------------------+-----------------------------------------+
      | aee.capability.list  | List supported intents.  The task MAY   |
      |                      | include a "namespace_filter" string.    |
      |                      | The result MUST include an "intents"    |
      |                      | array of strings.                       |
      +----------------------+-----------------------------------------+
      | aee.context.fetch    | Retrieve an envelope or payload by      |
      |                      | reference.  The task MUST include "id"  |
      |                      | and MAY include "corr", "locator", and  |
      |                      | "hash" for verification.                |
      +----------------------+-----------------------------------------+
      | aee.context.refute   | Reject a referenced context with a      |
      |                      | reason.  The task MUST include "id" and |
      |                      | "reason".  The result MUST include      |
      |                      | "acknowledged" (boolean).               |
      +----------------------+-----------------------------------------+
      | aee.validate.payload | Validate a payload against an intent    |
      |                      | schema.  The task MUST include "intent" |
      |                      | and "payload_to_validate".  The result  |
      |                      | MUST include "valid" (boolean) and MAY  |
      |                      | include an "errors" array.              |
      +----------------------+-----------------------------------------+

                   Table 2: Reserved aee.* Protocol Intents

     Implementations claiming AEE compliance are not required to implement
     all "aee.*" intents.  However, "aee.status.ping" SHOULD be supported
     by all agents to enable basic liveness detection.







  Cowles                  Expires 1 September 2026               [Page 15]


  Internet-Draft                     AEE                     February 2026


     Application-specific intents MUST NOT use the "aee.*" namespace.  If
     a use case requires scheduling, workflow, or orchestration semantics,
     those intents belong in an application namespace (or in a companion
     protocol such as AOCL [AOCL]).

  9.3.  Intent Schema Publishing

     AEE does not standardize the "payload" field's internal structure.
     Instead, each intent publishes separate JSON Schema documents for its
     "task", "result", and "error" payload variants.  The RECOMMENDED file
     layout is:

     envelope/aee-v1.schema.json
     intents/<intent>.task.schema.json
     intents/<intent>.result.schema.json
     intents/<intent>.error.schema.json

     AEE does not require a centralized intent registry.  Communities MAY
     publish intent schemas in version-controlled repositories, package
     registries, or any other distribution mechanism appropriate to their
     ecosystem.

  10.  Referencing Strategy

     When an envelope needs to reference prior context (e.g., the original
     task that spawned a result, or related evidence from another
     workflow), AEE prescribes a reference-based approach rather than
     embedding full envelopes within payloads.

  10.1.  Rationale: Avoiding Nested Envelopes

     Embedding full envelopes inside payloads creates several problems:

     *  *Matryoshka bloat:* Deeply nested structures grow with each hop in
        a multi-agent workflow, consuming storage and bandwidth.

     *  *Token collapse:* Large language models (LLMs) processing nested
        envelopes waste context window tokens on redundant structural
        metadata.

     *  *Signature ambiguity:* When envelopes are nested, it becomes
        unclear which envelope's signature is authoritative -- the outer
        or the inner.

  10.2.  The payload.references Array

     When referencing prior envelopes, implementations SHOULD use a
     "references" array within the payload:



  Cowles                  Expires 1 September 2026               [Page 16]


  Internet-Draft                     AEE                     February 2026


     {
       "payload": {
         "references": [
           {
             "id": "01JFB2R1JZKQ9V3K8W8Y9W1F2A",
             "corr": "01JFB2QX0K8X5K6ZJ9G2C0C1MW",
             "type": "aee.envelope",
             "locator": "store://envelopes/01JFB2R1JZKQ9V3K8W8Y9W1F2A",
             "hash": "sha256:a1b2c3..."
           }
         ]
       }
     }

     Each reference object contains the following fields:

     id (REQUIRED)  The referenced envelope's "id" value.

     corr (OPTIONAL)  The correlation ID for additional context.

     type (REQUIRED)  The reference type.  For envelope references, the
        value MUST be "aee.envelope".

     locator (OPTIONAL)  A URI or path that can be used to retrieve the
        full referenced envelope, for example via the "aee.context.fetch"
        intent.

     hash (OPTIONAL)  A content hash (e.g., "sha256:...") for integrity
        verification of the referenced envelope.

     To retrieve the full envelope behind a reference, consumers SHOULD
     use the "aee.context.fetch" protocol intent (see Section 9).

  10.3.  Exception: Archival and Forensic Snapshots

     When creating immutable audit logs or forensic snapshots, embedding
     full envelopes as inert blobs within a "result" payload is
     acceptable.  These embedded envelopes are historical records, not
     active routing participants.  Implementations MUST NOT attempt to
     route or process embedded archival envelopes as live messages.

  11.  Security Considerations









  Cowles                  Expires 1 September 2026               [Page 17]


  Internet-Draft                     AEE                     February 2026


  11.1.  Replay Attacks and Correlation ID Uniqueness

     Each AEE envelope carries a unique "id" field and a "corr" field
     linking related messages.  If message identifiers are predictable or
     reused, an attacker could replay previously captured envelopes to
     trigger duplicate work or corrupt workflow state.  Implementations
     MUST generate "id" values using cryptographically random or
     lexicographically-sortable unique identifiers (e.g., ULIDs or UUIDs
     [RFC4122]).  Consumers SHOULD maintain a deduplication window and
     reject envelopes with previously seen "id" values within that window.
     The "ts" field SHOULD be checked against a reasonable clock-skew
     tolerance to detect stale replays.

  11.2.  Signature Verification and Trust Model

     The "sig" field is OPTIONAL, meaning that unsigned envelopes are
     valid per this specification.  Deployments operating in environments
     where message authenticity is critical MUST require signatures and
     establish a trust model for key distribution.  Ed25519 is RECOMMENDED
     for asymmetric signatures due to its performance characteristics and
     resistance to implementation pitfalls.  When signatures are present,
     consumers MUST verify them before processing the envelope.  A failed
     signature verification MUST result in rejection of the envelope.

     This specification does not define a public key infrastructure (PKI)
     or key exchange mechanism.  Deployments SHOULD document their key
     management procedures, including key rotation schedules, revocation
     mechanisms, and the scope of trust for each key identifier ("kid").

  11.3.  Envelope Integrity Without Signatures

     In deployments where the "sig" field is not used, envelope integrity
     depends entirely on the security properties of the transport layer.
     If envelopes are carried over an unencrypted or unauthenticated
     channel, any intermediary can modify envelope fields -- including
     "from", "to", "intent", and "payload" -- without detection.
     Deployments that do not use envelope-level signatures MUST ensure
     that the transport layer provides adequate integrity and
     authentication guarantees (e.g., TLS with mutual authentication).
     For tamper-evident recording of envelope exchanges, the companion
     VOLT protocol [VOLT] defines cryptographic hash chains that can
     provide post-hoc verification of envelope integrity.









  Cowles                  Expires 1 September 2026               [Page 18]


  Internet-Draft                     AEE                     February 2026


  11.4.  Privacy of Payload Contents

     AEE envelopes carry arbitrary payload data that may include
     personally identifiable information (PII), credentials, internal
     system details, or other sensitive content.  The envelope format does
     not provide payload encryption.  Implementations handling sensitive
     data SHOULD encrypt payloads at the application layer or ensure that
     the transport provides confidentiality (e.g., TLS).  The "requires"
     field MUST NOT be used to carry secrets; credentials should be
     transmitted through secure side-channels rather than embedded in
     envelope metadata.

     The logging guidance in Section 6 (rule 8) recommends logging several
     envelope fields for observability.  Implementations MUST ensure that
     logged fields do not inadvertently expose sensitive payload contents.
     The "intent" field, while not typically sensitive, may reveal
     operational patterns; deployments SHOULD consider the information
     leakage implications of intent names in log aggregation systems.

  11.5.  Trust Boundaries Between Agents

     AEE entity identifiers (see Section 5) are self-asserted: the "from"
     field is populated by the sender, and there is no built-in mechanism
     to verify that the claimed sender identity is authentic.  In multi-
     tenant or cross-organizational deployments, a malicious agent could
     impersonate another agent by setting an arbitrary "from" value.
     Deployments MUST implement identity verification at trust boundaries,
     either through envelope signatures (see Section 8), transport-layer
     authentication, or a gateway that validates sender identity before
     forwarding envelopes.

     When envelopes cross trust boundaries (e.g., from an internal agent
     network to an external partner's agents), implementations SHOULD
     validate all envelope fields at the boundary, strip or redact
     sensitive payload content, and apply allowlist-based intent filtering
     to prevent unauthorized operations.

  11.6.  Denial of Service via Priority Field Abuse

     The "priority" field allows senders to signal message urgency.  A
     malicious or misconfigured agent could set all messages to "urgent"
     priority, starving normal-priority messages of processing resources.
     Implementations SHOULD enforce per-sender priority quotas or rate
     limits.  Infrastructure components SHOULD NOT blindly trust the
     "priority" field from untrusted sources; instead, they SHOULD apply
     policy-based priority assignment or capping at trust boundaries.





  Cowles                  Expires 1 September 2026               [Page 19]


  Internet-Draft                     AEE                     February 2026


     Similarly, the "requires" field's "timeout_ms" value could be abused
     to hold resources for extended periods.  Consumers SHOULD enforce
     maximum timeout values regardless of the requested timeout, and
     SHOULD release resources promptly when timeouts expire.

  12.  IANA Considerations

     This document has no IANA actions.

  13.  References

  13.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/info/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/info/rfc8174>.

     [RFC8259]  Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
                Interchange Format", STD 90, RFC 8259,
                DOI 10.17487/RFC8259, December 2017,
                <https://www.rfc-editor.org/info/rfc8259>.

  13.2.  Informative References

     [RFC4122]  Leach, P., Mealling, M., and R. Salz, "A Universally
                Unique IDentifier (UUID) URN Namespace", RFC 4122,
                DOI 10.17487/RFC4122, July 2005,
                <https://www.rfc-editor.org/info/rfc4122>.

     [AOCL]     Cowles, A., "Agent Orchestration Control Layers (AOCL)",
                Work in Progress, Internet-Draft, draft-cowles-aocl-00,
                2026, <https://github.com/AdaminX/AOCL-Agent-
                Orchestration-Control-Layers-Protocol>.

     [VOLT]     Cowles, A., "Verifiable Operations Ledger and Trace
                (VOLT)", Work in Progress, Internet-Draft, draft-cowles-
                volt-00, 2026, <https://github.com/AdaminX/VOLT-Protocol>.









  Cowles                  Expires 1 September 2026               [Page 20]


  Internet-Draft                     AEE                     February 2026


  Acknowledgements

     The author wishes to thank the early adopters and reviewers of the
     AEE specification within the Quox ecosystem, whose feedback on real-
     world agent interoperability challenges shaped the design of this
     envelope format.

  Author's Address

     Adam Cowles
     Quox Ltd
     London
     United Kingdom
     Email: adam@quox.ai
     URI:   https://quox.ai




































  Cowles                  Expires 1 September 2026               [Page 21]


name: draft-mapmw-task-discovery
rev: 00
title: Task discovery in agentic networks
time: 2026-03-01T14:51:10Z
group_uri: /api/v1/group/group/1027/
expires: 2026-09-02T14:51:10Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-07T06:55:14.591573+00:00
source: ietf
abstract:
  This document defines an architectural framework for an open,
     interoperable ecosystem in which task owners publish
     tasks—represented as structured task cards—to a task-posting
     platform, enabling autonomous agents to discover tasks, negotiate
     execution terms, and coordinate multi-agent collaboration.  The
     architecture introduces a set of functional layers—including the Task
     Owner Layer, Task Owner Access Layer, Task-Posting Platform, Agentic
     Layer, Agent Access Layer, and an optional Communication Link—that
     collectively support secure task publication, agent discovery,
     capability evaluation, and bilateral negotiation.  The framework is
     designed to accommodate heterogeneous agents with diverse skill sets,
     trust requirements, and operational models, while ensuring consistent
     interaction patterns across platforms and vendors.

     The document also surveys existing agent-discovery approaches, such
     as A2A, agntcy/OASF, ARDP, and DNS-AID, and identifies gaps that
     motivate a unified, interoperable model for task-centric and
     agent-initiated discovery and interaction.  It also explores possible
     ways by which the current approached can enhance the proposed
     framework.  The goal of this architecture is not to replace existing
     mechanisms but to provide a complementary framework that enables
     agent–task interactions in scenarios that are difficult to support
     using traditional agent-to-agent or platform-centric interaction
     models.  The document is concluded with some potential
     standardization venues for the IETF.

full_text:
  Network Working Group                                          H. Moussa
  Internet-Draft                                               A. Akhavain
  Intended status: Informational                             Huawei Canada
  Expires: 2 September 2026                                       R. Pioli
                                                               Independent
                                                                 J. Mozley
                                                               N. Williams
                                                            Infoblox, Inc.
                                                              1 March 2026


                     Task discovery in agentic networks
                       draft-mapmw-task-discovery-00

  Abstract

     This document defines an architectural framework for an open,
     interoperable ecosystem in which task owners publish
     tasks—represented as structured task cards—to a task-posting
     platform, enabling autonomous agents to discover tasks, negotiate
     execution terms, and coordinate multi-agent collaboration.  The
     architecture introduces a set of functional layers—including the Task
     Owner Layer, Task Owner Access Layer, Task-Posting Platform, Agentic
     Layer, Agent Access Layer, and an optional Communication Link—that
     collectively support secure task publication, agent discovery,
     capability evaluation, and bilateral negotiation.  The framework is
     designed to accommodate heterogeneous agents with diverse skill sets,
     trust requirements, and operational models, while ensuring consistent
     interaction patterns across platforms and vendors.

     The document also surveys existing agent-discovery approaches, such
     as A2A, agntcy/OASF, ARDP, and DNS-AID, and identifies gaps that
     motivate a unified, interoperable model for task-centric and
     agent-initiated discovery and interaction.  It also explores possible
     ways by which the current approached can enhance the proposed
     framework.  The goal of this architecture is not to replace existing
     mechanisms but to provide a complementary framework that enables
     agent–task interactions in scenarios that are difficult to support
     using traditional agent-to-agent or platform-centric interaction
     models.  The document is concluded with some potential
     standardization venues for the IETF.

  Status of This Memo

     This Internet-Draft is submitted in full conformance with the
     provisions of BCP 78 and BCP 79.





  Moussa, et al.          Expires 2 September 2026                [Page 1]


  Internet-Draft               Task-discovery                   March 2026


     Internet-Drafts are working documents of the Internet Engineering
     Task Force (IETF).  Note that other groups may also distribute
     working documents as Internet-Drafts.  The list of current Internet-
     Drafts is at https://datatracker.ietf.org/drafts/current/.

     Internet-Drafts are draft documents valid for a maximum of six months
     and may be updated, replaced, or obsoleted by other documents at any
     time.  It is inappropriate to use Internet-Drafts as reference
     material or to cite them other than as "work in progress."

     This Internet-Draft will expire on 2 September 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 (https://trustee.ietf.org/
     license-info) in effect on the date of publication of this document.
     Please review these documents carefully, as they describe your rights
     and restrictions with respect to this document.  Code Components
     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  . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.  Task Discovery: an Agent initiated engagement . . . . . . . .   4
     3.  Traditional agent-task discovery approaches . . . . . . . . .   8
       3.1.  Approach 1 Agent-to-Agent protocol (A2A)  . . . . . . . .   8
         3.1.1.  General description of the approach . . . . . . . . .   8
         3.1.2.  Components, interfaces, and protocols . . . . . . . .   8
         3.1.3.  Known implementations / ecosystem . . . . . . . . . .   8
         3.1.4.  Shortcomings and limitations (expected or
                 reported) . . . . . . . . . . . . . . . . . . . . . .   9
       3.2.  Approach 2 Agntcy by Cisco  . . . . . . . . . . . . . . .   9
         3.2.1.  General description of the approach . . . . . . . . .   9
         3.2.2.  Components, interfaces, and protocols . . . . . . . .   9
         3.2.3.  Known implementations / ecosystem . . . . . . . . . .   9
         3.2.4.  Shortcomings and limitations (expected or
                 reported) . . . . . . . . . . . . . . . . . . . . . .  10
       3.3.  Approach 3 DNS for AI Discovery (DNS-AID) . . . . . . . .  10
       3.4.  Approach 4: Agent Registration and Discovery Protocol
             (ARDP)  . . . . . . . . . . . . . . . . . . . . . . . . .  10
         3.4.1.  General Description of the Approach . . . . . . . . .  10
         3.4.2.  Core Characteristics  . . . . . . . . . . . . . . . .  11



  Moussa, et al.          Expires 2 September 2026                [Page 2]


  Internet-Draft               Task-discovery                   March 2026


     4.  Our approach: task cards and task discovery . . . . . . . . .  11
       4.1.  Task Discovery Ecosystem  . . . . . . . . . . . . . . . .  11
       4.2.  Task cards  . . . . . . . . . . . . . . . . . . . . . . .  14
       4.3.  Task discovery  . . . . . . . . . . . . . . . . . . . . .  15
       4.4.  Interaction between task owners and agents  . . . . . . .  15
     5.  Complementary operations format . . . . . . . . . . . . . . .  16
       5.1.  A2A and Agntcy role in task discovery . . . . . . . . . .  16
       5.2.  DNS-AID role in task discovery  . . . . . . . . . . . . .  16
       5.3.  ARDP role in task discovery . . . . . . . . . . . . . . .  16
     6.  Conclusion and Discussions  . . . . . . . . . . . . . . . . .  17
       6.1.  Summary of advantages of the proposed Task Discovery
             Ecosystem . . . . . . . . . . . . . . . . . . . . . . . .  17
       6.2.  IETF work required to realize the vision  . . . . . . . .  18
     7.  Security Considerations . . . . . . . . . . . . . . . . . . .  19
     8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  19
     Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  20
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  20

  1.  Introduction

     To date, both industry and academic communities have shown strong
     interest in the problem of agent discovery, in which a task owner
     seeks to identify the most suitable agent or group of agents to
     perform a given task.  Several frameworks have been proposed such as
     A2A, Agntcy, BANDAID, ARDP, and DNA which we will examine in detail
     in later sections.

     It is important to note that, although these methods offer valuable
     insights and each has distinct strengths and limitations, they share
     a common design principle that creates several challenges.  They all
     assume agents are represented by identification records stored in a
     registry and made discoverable to task owners, who must then sift
     through piles of agent IDs to find suitable providers and assign
     tasks.  This reliance on ID-card–based discovery introduces several
     limitations within the broader framework, including:
















  Moussa, et al.          Expires 2 September 2026                [Page 3]


  Internet-Draft               Task-discovery                   March 2026


     *  Agent capabilities must be made discoverable to task initiators,
        and that information often needs to remain visible for the agent’s
        lifetime; as the number of agents grows, this requirement
        increases the network’s storage footprint.  Ensuring global
        visibility typically requires geographic replication or federation
        of registries, which multiplies storage and synchronization costs
        and also raises additional operational burdens: increased
        bandwidth for replication and queries, higher indexing and lookup
        overhead, greater CPU and memory use for maintaining searchable
        indexes, and stronger consistency or reconciliation mechanisms to
        keep records correct and up to date.  These costs together drive
        latency, operational complexity, and monetary expense as the agent
        population and geographic scope scale.

     *  In traditional agent discovery, task owners must sift through many
        agent identification records to find a suitable provider.  This
        process assumes owners know the precise skills or requirements
        needed for a task—a strong and often unrealistic assumption.  As a
        result, non-expert owners face high search friction, increased
        mismatch risk, and longer resolution times; these effects worsen
        for complex, multi-domain tasks

     *  Traditional discovery often funnels work to a few visible
        providers, creating task magnets: top-ranked agents get most jobs,
        newcomers struggle to get any, and reputation feedback loops
        reinforce the imbalance.  This reduces competition, slows
        innovation, and may lead to missed opportunity to match with the
        best agent for the given task.

     *  Task initiators need intelligent search controls—stoppage criteria
        and efficient search methods—because agent populations grow
        continuously and exhaustive discovery is impractical; deciding
        when to stop expanding the search space and how to explore
        promising candidates efficiently is therefore a core design
        challenge.

  2.  Task Discovery: an Agent initiated engagement

     Given the above foreseeable potential challenges to traditional
     approaches, we propose an alternative and complimentary framework
     where agents take active role in task to agent matching.  In this
     framework, we consider what we refer to as task discovery, as
     follows:

     *  Consider a system in which task owners can post their tasks on
        some type of a platform (e.g., social media, internet, websites,
        ebillboards…etc).




  Moussa, et al.          Expires 2 September 2026                [Page 4]


  Internet-Draft               Task-discovery                   March 2026


     *  Also consider that agents are equipped with means and intelligence
        that enable them to access this platform.

     *  Agents can then discover tasks posted to this platform.

     *  Agents can select the tasks that suit their skillset and
        capabilities.

     *  Agents can then send necessary information (e.g. agent card,
        history, make, model, ratings...etc) to task owners and present
        themselves as potential candidates capable of fulfilling the
        posted task.

     *  Task owners can employ a contention resolution mechanism to assign
        the task to a candidate and provide permission to the selected
        agent to complete the task.  Essentially, compared to traditional
        methods, in this propose approach, task discovery helps decreases
        the number of comparison processes needed to select the best
        matching agent.

     *  Agents can form coalitions (pre-organized or dynamically formed
        upon discovering posted tasks) to appear more capable than they
        would in their individual forms.  These are teams of agents where
        each team has an overall team capability and skillset that is an
        aggregate of the capabilities and skillsets of the team members.

     *  In scenarios where multi-agent collaboration is needed, team
        formations enables the task owner to have the full knowledge of
        all different agents involved in fulfillment of the task from the
        onset.  This is in contrast to the traditional task fulfillment
        where dynamically recruited downstream agents need to be
        continuously announced and approved by the task owner.
        Essentially, the propose approach can help ease up the need for
        chain of permission requests.

     *  Similarly, upon discovering posted tasks, agents can acquire
        additional agentic skills to augment their capabilities before
        submitting applications to task owners and becoming candidates.

     The above proposed complimentary architecture can help facilitate
     various services, including:

     *  Increase agent visibility: Idle agents who hold identification
        cards but are not being selected by task owners can use the
        proposed architecture to increase their visibility.  In this
        design, agents are allowed to actively approach task owners and
        offer their services, rather than remaining passive and waiting to
        be chosen.



  Moussa, et al.          Expires 2 September 2026                [Page 5]


  Internet-Draft               Task-discovery                   March 2026


     *  Reputation Building and fair selection: Reputation is a key factor
        that differentiates agents and influences their likelihood of
        being selected, typically based on task-owner ratings, accuracy,
        completion time, and overall performance.  Because reputation
        reflects an agent’s history of completed tasks, newly added agents
        face a cold-start problem in traditional discovery models where
        agents remain passive and must wait to be chosen, making it
        difficult to compete with established agents.  The proposed
        platform mitigates this challenge by allowing agents to actively
        seek out tasks and offer their services, giving them opportunities
        to build or strengthen their reputation rather than relying solely
        on being selected.

     *  Guided Agent improvement: Agents are expected to be self-evolving
        entities that continuously learn new skills.  In traditional
        passive discovery methods, organizations develop agents and are
        responsible for improving the quality of their published agents;
        to do this efficiently they conduct extensive market analyses to
        identify the skills their agents lack and evolve them accordingly.
        However, because discovery is passive, such analyses assume access
        to records showing which agent performed which task and why it was
        chosen; information that is often proprietary or confidential in
        competitive markets.  In the proposed approach, agents can inspect
        task postings directly: they can infer required skills from task
        descriptions and metadata, compare those requirements to their own
        capabilities, and determine which skills to develop so they are
        better positioned to handle the tasks most commonly submitted by
        task owners.

     *  Improve agent-task matching: Selecting the right agent for a task
        is not straightforward.  Traditional methods assume task owners
        know enough about a domain to specify the exact skills required,
        but that is often false: a car owner who reports “weird noise when
        braking” may not know whether the problem is tires, brakes, or
        suspension, so they will search for a generic “mechanic,” yielding
        either too many matches or none if they must be more specific.
        Under the proposed approach, task owners can post a general
        request (e.g., “fix car making noise when braking”) and agents can
        proactively query for clarifications—asking about recent brake
        work, symptom duration, or offering to run a diagnostic—thereby
        shifting the diagnostic intelligence from the owner to service
        providers and improving match quality.

     *  Improved complex task handling: Tasks vary in complexity: some
        require a single agent (e.g., “translate this text from French to
        English”), while others need multiple agents (e.g., “help build a
        bicycle” — one agent to purchase parts, another to deliver them, a
        third to guide assembly).  In traditional discovery models,



  Moussa, et al.          Expires 2 September 2026                [Page 6]


  Internet-Draft               Task-discovery                   March 2026


        complex tasks must be split into subtasks, but that process
        assumes the task owner can (1) decompose the task to the right
        level of granularity and (2) know what agents exist to handle each
        subtask; if the available agent landscape is unknown, splitting
        can be counterproductive (for example, designating a “purchase
        parts” subtask is useless if no purchasing agent exists).  The
        proposed approach lets task owners post raw, unsplit tasks to the
        billboard, relieving them of the burden of decomposition; agents
        discover those postings, use their internal knowledge and
        awareness of other agents to form coalitions, and split and assign
        subtasks among themselves, thereby shifting the complexity to the
        service-providing side and enabling tasks to be partitioned in
        ways that match actual agent capabilities.  Also, this provides a
        means by which agents can form coalitions with trusted parties to
        handle tasks together.

     *  Mechanisms for authentication and trust establishment: task owners
        generally need to interact with authenticated, registered agents,
        and traditional discovery models place the burden of vetting on
        owners—reviewing credentials, certifications, provenance, and
        other trust signals—which assumes owners have the expertise and
        resources to perform reliable vetting.  Prior proposals (for
        example, BANDAID and ARDP) shift parts of that responsibility to
        third parties such as DNS-based certification systems, but they
        still depend on standardized, often rigid trust criteria and
        centralized records that may be proprietary or vulnerable to
        compromise.  To increase flexibility and usability, the proposed
        approach lets task owners define their own authentication and
        trust requirements (for example, accepting agents by origin and
        publisher, or requiring background checks, tests, or cryptographic
        attestations); agents apply for tasks by connecting to the owner,
        and the owner admits only those agents that meet its chosen
        criteria.  The billboard used for posting tasks can also enforce
        admission policies, allowing only authenticated and trusted agents
        to submit proposals.  It would be appreciated to mention that
        under this approach, various grounding mechanisms would be needed
        so that proposed flexibility non-standardized design does not lead
        to fragmentation, spoofing, or unscalable manual vetting.

     It should be clear from the above that the primary advantage of the
     proposed architecture is to shift part of the discovery burden from
     task owners to service-providing agents rather than to replace
     existing registry-based discovery.  Task owners retain the option to
     search agent registries, but the complementary billboard model lets
     owners post raw, unsplit tasks and lets agents perform decomposition,
     diagnostics, and coalition formation.  Agents still rely on discovery
     to assemble teams, but their team formation is driven by objectives
     inferred from the task posting and by agents’ own knowledge of



  Moussa, et al.          Expires 2 September 2026                [Page 7]


  Internet-Draft               Task-discovery                   March 2026


     capabilities and trust relationships.  To make this shift practical
     and secure, the platform should combine owner-configurable trust
     policies with policy profiles, machine-readable credentials,
     standardized task posting mechanisms, standardized task metadata
     formatting, billboard admission controls, and budgeted search/stop
     rules so owner flexibility does not produce fragmentation, spoofing,
     or unscalable manual vetting.  All of these aspects can benefit from
     discussions and developments within the IETF as will be discussed
     later.

  3.  Traditional agent-task discovery approaches

     This section aims at providing a brief high level collective
     description of traditional known agent discovery mechanisms (i.e.,
     some form of a summary for the different approaches that outlines the
     general theme)

  3.1.  Approach 1 Agent-to-Agent protocol (A2A)

  3.1.1.  General description of the approach

     A2A uses Agent Cards (structured JSON metadata) plus registry servers
     and discovery clients so that agents and clients can retrieve
     machine-readable descriptions of remote agents’ capabilities and
     endpoints.  Discovery is tightly coupled with the A2A messaging and
     lifecycle model.

  3.1.2.  Components, interfaces, and protocols

     *  Agent Card: the primary discovery artifact (JSON schema)
        describing name, capabilities, endpoints, and interaction hints.

     *  AgentRegistry / DiscoveryClient: servers that host Agent Cards and
        clients that query registries or use local discovery strategies.

     *  A2A transport and security stack: discovery is integrated with the
        protocol’s authentication and session establishment flows so that
        discovery leads directly into authenticated communication.

  3.1.3.  Known implementations / ecosystem

     Google published A2A and maintains a public GitHub repository and
     documentation; multiple SDKs and language bindings (including a
     Python discovery module) implement the Agent Card and registry
     patterns.






  Moussa, et al.          Expires 2 September 2026                [Page 8]


  Internet-Draft               Task-discovery                   March 2026


  3.1.4.  Shortcomings and limitations (expected or reported)

     *  Registry and card freshness: Agent Cards must be kept up to date;
        stale cards can misrepresent runtime capabilities.

     *  Owner specification burden: discovery via structured cards assumes
        owners or publishers can accurately enumerate capabilities; vague
        tasks still require additional negotiation or diagnostics.

     *  Interoperability gaps without profiles: different deployments may
        extend Agent Cards or discovery strategies; without standardized
        profiles, cross-domain behavior can vary.

  3.2.  Approach 2 Agntcy by Cisco

  3.2.1.  General description of the approach

     AGNTCY provides a registry-and-messaging stack for agent
     interoperability: agents publish metadata and capability records to
     discoverable services, use secure messaging for interaction, and rely
     on observability/attestation components to verify behavior.
     Discovery within Agntcy centers on a registry-style directory that
     indexes agent metadata and capability schemas; agents publish
     machine-readable schema-backed records (built on the Open Agentic
     Schema Framework (OASF)) and discovery queries retrieve matching
     entries.

  3.2.2.  Components, interfaces, and protocols

     *  OASF schema server and schema repository for capability and
        metadata definitions.

     *  Agent Directory / Agent Directory Service (ADS) that indexes
        signed agent records and maps capability descriptors to content
        locations.

     *  Secure low-latency messaging (SLIM) and transport bindings for
        agent-to-agent communication that integrate discovery with secure
        agent-to-agent messaging and observability pipelines.

     *  Identity, observability, and evaluation subsystems for provenance,
        runtime telemetry, and capability assessment.

  3.2.3.  Known implementations / ecosystem

     AGNTCY code and reference components are available on GitHub from
     Outshift/Cisco and collaborators; the project has been adopted into a
     Linux Foundation initiative with multiple industry participants.



  Moussa, et al.          Expires 2 September 2026                [Page 9]


  Internet-Draft               Task-discovery                   March 2026


  3.2.4.  Shortcomings and limitations (expected or reported)

     *  Registry-centric bias: relies on owners or agents to keep registry
        entries current; static entries can become stale relative to
        runtime capability.

     *  Operational complexity: full stack (registry, messaging,
        observability) increases deployment and integration effort for
        platforms.

     *  Cold-start for newcomers: while registries provide authoritative
        identity, newcomers still need paths to earn visibility and
        reputation unless additional onboarding flows are defined.

  3.3.  Approach 3 DNS for AI Discovery (DNS-AID)

     *  describe the approach

     *  Highlight different components, interfaces, protocols....etc

     *  name some well-known implementations

     *  list known or expected shortcomings of the approach if any

  3.4.  Approach 4: Agent Registration and Discovery Protocol (ARDP)

  3.4.1.  General Description of the Approach

     The Agent Registration and Discovery Protocol (ARDP) is a control-
     plane protocol designed to provide stable agent identifiers,
     authenticated registration, and authorized endpoint resolution in
     distributed and federated environments.

     ARDP is not limited to static agent “card” storage.  It defines a
     dynamic, soft-state registration model in which bindings expire and
     must be refreshed, and in which resolution is subject to
     authorization policy and privacy controls.  This distinguishes ARDP
     from passive directory models and enables its use in mobile,
     federated, and multi-tenant environments.

     Unlike static registries that merely store agent identification
     records, ARDP defines:

     *  Identity-bound registration with cryptographic proof-of-control
        (JWS-based PoC for REGISTER/refresh operations).

     *  Soft-state bindings with TTL and refresh semantics, allowing
        dynamic endpoint mobility.



  Moussa, et al.          Expires 2 September 2026               [Page 10]


  Internet-Draft               Task-discovery                   March 2026


     *  Fine-grained authorization for RESOLVE and QUERY operations.

     *  Capability advertisement independent of interaction protocol
        (e.g., MCP, A2A, HTTP, gRPC).

     *  Explicit federation model with provenance metadata and TTL
        honoring.

     *  Privacy-aware redaction defaults for discovery responses.

  3.4.2.  Core Characteristics

     ARDP operates as a minimal control-plane discovery layer.  It does
     not define session management, task execution semantics, runtime
     authorization tokens, billing mechanisms, or governance frameworks.
     Instead, it focuses on:

     *  Binding a stable Agent Identifier (AID) to active endpoints and
        capability metadata.

     *  Ensuring that only entities that can prove control of an AID may
        register or refresh it.

     *  Providing authorized resolution of endpoints and capabilities.

  4.  Our approach: task cards and task discovery

     This section aims to provided general high-level description and
     architecture of the proposed Task Discovery Ecosystem.  It also poses
     some questions that need answers and opens up venues for discussions.

  4.1.  Task Discovery Ecosystem



















  Moussa, et al.          Expires 2 September 2026               [Page 11]


  Internet-Draft               Task-discovery                   March 2026


  +----------+                                                         +----------+
  |          |                                                         |          |
  |+--------+|      +--------+                         +--------+      |+--------+|
  || T.O. 1 || <--> |        |                         |        | <--> || Agent 1||
  |+--------+|      |        |      +-----------+      |        |      |+--------+|
  |          |      |        |      |           |      |        |      |     ↕    |
  |+--------+|      |  T.O.  |      |   Task    |      | Agent  |      |+--------+|
  || T.O. 2 || <--> | Access | <--> |  Posting  | <--> | Access | <--> || Agent 2||
  |+--------+|      | Layer  |      |  Platform |      | Layer  |      |+--------+|
  |          |      |        |      |           |      |        |      |     ↕    |
  |+--------+|      |        |      +-----------+      |        |      |+--------+|
  || T.O. n || <--> |        |                         |        | <--> || Agent m||
  |+--------+|      +--------+                         +--------+      |+--------+|
  |          |                                                         |          |
  +----------+                                                         +----------+
       ↑                                                                    ↑
       |                         Communication  link                        |
       +--------------------------------------------------------------------+
  * T.O: Task Owner

               Figure 1: Figure 1: Task Discovery Ecosystem

     As shown in the figure, the ecosystem consists of different layers.

     *  Task Owner Layer: This layer hosts the entities that submit tasks
        requiring assistance from AI agents.  It provides mechanisms for
        verifying, authenticating, and registering trusted task owners,
        ensuring that only authorized parties can participate in the
        system.  This layer also manages the lifecycle of owner
        activity—including task submission, accounting and charging, and
        policy enforcement—and offers the privacy and security controls
        needed to protect owner data and identity.

     *  Agentic Layer: The Agentic Layer hosts the autonomous agents that
        evaluate, select, and execute tasks.  Agents in this layer expose
        diverse skill sets and operate as independent decision-making
        entities.  They are expected to discover posted tasks through
        standardized search interfaces, analyze task requirements, compare
        them against their own capabilities, and determine whether they
        are suitable candidates.  Once engaged, agents can communicate
        with task owners to request assignment, seek clarification,
        provide progress updates, or deliver results.  This layer may also
        support additional functions such as capability attestation, agent
        registration and authentication, reputation tracking, coalition
        formation for multi-agent tasks, and mechanisms for agents to
        manage their own operational state (availability, load, or cost).
        Within this layer, agent-to-agent discovery, communication, and
        session-management protocols—such as A2A, agntcy, ARDP, and



  Moussa, et al.          Expires 2 September 2026               [Page 12]


  Internet-Draft               Task-discovery                   March 2026


        DNS-AID—may be used to support coalition formation, peer
        coordination, and agent-level discovery needed to assemble
        appropriate teams for tasks that require multi-agent
        collaboration.  In some implementations, specialized “scouting
        agents” may continuously search for suitable tasks and, upon
        discovery, rely on agent-to-agent protocols to subcontract or
        delegate the task to the most appropriate agents within their
        network.

     *  Task Owner (T.O.)  Access Layer: This Layer provides the
        interfaces through which task owners interact with the
        task-posting platform.  It exposes the protocols required for safe
        and reliable operation, including mechanisms for submitting new
        tasks, tracking task status, and updating, retracting, or
        modifying previously posted tasks.  This layer also supports the
        communication requirements needed for rich interaction—such as
        multi-modal exchanges, session management, and secure transport
        between task owners and the platform.  Standardizing this layer
        enables task owners of different types and from different vendors’
        ecosystems to interact with task-posting platforms in a
        consistent, interoperable manner.  It should be noted here that
        also the task-posting platforms can come from different vendors as
        well, so standardized access layer is essential.

     *  Agent Access Layer: The Agent Access Layer provides the
        standardized interfaces through which agents interact with the
        task-posting platform and with other system components.  It
        exposes the protocols required for safe task discovery, capability
        advertisement, proposal submission, and session establishment.
        This layer also supports secure communication, multi-modal
        exchanges, status reporting, and lifecycle management for
        agent-initiated interactions.  By defining common access and
        communication primitives, the Agent Access Layer enables
        heterogeneous agents—potentially from different vendors or
        ecosystems—to interoperate reliably with task-posting platforms
        and with one another.

     *  Task-Posting Platform: The Task-Posting Platform is the
        environment in which task owners publish tasks (task cards for
        instance) and make them visible to eligible agents.  It maintains
        the authoritative catalog of active tasks and enforces the
        policies under which tasks may be posted, viewed, or acted upon.
        Platforms may apply subject-matter restrictions, require specific
        agent capabilities, or limit participation to task owners who meet
        defined trust or compliance requirements.  The platform is
        responsible for ensuring fair and consistent visibility across all
        posted tasks and for exposing standardized APIs that allow agents
        to search, filter, and retrieve tasks in a predictable manner.  In



  Moussa, et al.          Expires 2 September 2026               [Page 13]


  Internet-Draft               Task-discovery                   March 2026


        addition to basic posting and retrieval, the platform may support
        task lifecycle management, admission control, rate limiting,
        prioritization rules, and mechanisms for handling updates,
        cancellations, and task-owner clarifications.  This allows it to
        provide necessary OAM functionality for task owners.  Although
        platforms may differ in internal design, they are expected to
        expose interoperable interfaces that conform to the specifications
        defined by the Task Owner Access Layer and the Agent Access Layer,
        enabling cross-vendor compatibility and consistent behavior across
        deployments.

     *  The Communication Link: The Communication Link is an optional
        component that enables direct, bilateral interaction between task
        owners and agents after initial discovery.  Its purpose is to
        off-load certain interaction responsibilities from the access
        layers by providing a secure channel through which both parties
        can negotiate task-specific details.  Once an agent identifies a
        suitable task, it may use this link to contact the task owner
        directly and establish the terms under which the task will be
        fulfilled.  These terms may include trust requirements, handling
        expectations, privacy constraints, compensation models, escalation
        paths, or any other operational parameters relevant to the task.
        This link supports private sessions that operate outside the
        default policies of the task-posting platform while still relying
        on standardized, regulated, and secured communication protocols
        defined by the ecosystem.  It allows richer negotiation
        patterns—such as multi-modal exchanges, iterative clarification,
        or structured contract formation—without requiring the platform to
        mediate every interaction.

  4.2.  Task cards

     *  what are task cards?

     *  how are they generated? (there should be a mechanism to generate
        these) -- potential for standardization.

     *  What are some proposed task card structures? -- potential for many
        IETF drafts and solution proposal.

     *  How are task cards used by agents to satisfy the different
        scenarios considered? -- (these task cards need to be designed
        such that they can be utilized to fulfill the above scenarios.
        Mechanism by which this is done might not be in IETF scope, but
        perhaps would invite creative designing proposals)






  Moussa, et al.          Expires 2 September 2026               [Page 14]


  Internet-Draft               Task-discovery                   March 2026


  4.3.  Task discovery

     *  How are task cards stored? (authorization, authentication,
        standardization) --- potential for standardization

     *  How are task cards published and handled after being published?
        (expiration, prioritization, fairness) -- potential for
        standardization

     *  What are the possible different approaches to discovering them in
        light of the different scenarios being considered? -- potential
        for standardization

     *  How to ensure secure and private access to task cards? --
        potential for standardization

     *  Centralized and decentralized discovery?

     *  Efficient discovery? -- This is likely out of scope for the IETF,
        making it more suitable as a research topic for the IRTF.
        Alternatively, this could be handled through engineered,
        standardized methods, such as hierarchical or DNS-based discovery.

  4.4.  Interaction between task owners and agents

     *  How do agents connect with task owners? (authentication,
        validation, and authorization) -- potential for standardization

     *  How can task owners monitor progress on their tasks? -- potential
        for standardization

     *  How do agents charge and bill for their service? -- This is likely
        out of scope for the IETF

     *  What happens if agents did not fulfill the task up to standards
        required?  -- IETF can provide a way to express satisfaction,
        similar to ai-pref

     *  how to insure privacy and security? -- potential for
        standardization.  Perhaps proposal such as ARDP might find utility
        here.

     *  authorization and authentication of agent? -- potential for
        standardization

     *  authorization and authentication of task owner? -- potential for
        standardization




  Moussa, et al.          Expires 2 September 2026               [Page 15]


  Internet-Draft               Task-discovery                   March 2026


     *  authorization and authentication of billboards? -- potential for
        standardization

  5.  Complementary operations format

     This section aims to describe how the two models can operate
     side-by-side: registry-based discovery continues to offer a stable,
     authoritative directory of agents, while the billboard-driven
     approach adds dynamic task posting, proactive agent proposals, richer
     reputation building, and improved handling of vague or complex tasks.
     Together, they form a hybrid discovery ecosystem in which registries
     provide long-term identity and credentials, and the billboard layer
     provides real-time matching, diagnostics, coalition formation, and
     opportunities for newcomers—each compensating for the other’s
     weaknesses.

  5.1.  A2A and Agntcy role in task discovery

     To be completed..

  5.2.  DNS-AID role in task discovery

     To be completed..

  5.3.  ARDP role in task discovery

     Being a control-plane protocol that is designed to provide stable
     agent identifiers, authenticated registration, and authorized
     endpoint resolution in distributed and federated environment, the
     ARDP can facilitate many features necessary for the operation of the
     Task Discovery Ecosystem proposed here.  To be exact, ARDP can:

     *  Serve as the authoritative identity and endpoint binding layer for
        agents that respond to task postings.

     *  Allow Agents discovering tasks via a billboard mechanism to:

        -  Validate peer agent identities when forming coalitions.

        -  Resolve authoritative endpoints for inter-agent coordination.

        -  Verify provenance and federation trust relationships.

     *  Task billboards may reference ARDP-resolvable AIDs instead of
        duplicating identity records.

     However, what the ARDP is not meant to do is:




  Moussa, et al.          Expires 2 September 2026               [Page 16]


  Internet-Draft               Task-discovery                   March 2026


     *  Task decomposition logic.

     *  Coalition formation strategies.

     *  Runtime authorization enforcement within an agent.

     *  Reputation scoring or bidding mechanisms.

     These functions can operate above ARDP or alongside it in
     complementary architectures such as the proposed task discovery
     model.

     Thus, in light of the above, it is clear that ARDP complements both
     registry-based discovery and billboard-based task discovery by
     providing a secure and interoperable control-plane foundation.

  6.  Conclusion and Discussions

  6.1.  Summary of advantages of the proposed Task Discovery Ecosystem

     *  A task-card storage entity is dynamic and demand-driven: posted
        tasks expire or are archived once completed, so the active dataset
        shrinks and grows with workload.  This contrasts with
        registry-based approaches that must persist and replicate every
        agent profile indefinitely.  By keeping only active task records
        readily searchable, the proposed model reduces persistent storage,
        indexing, replication bandwidth, and update churn, aligning
        infrastructure cost with actual demand while still supporting
        optional archival and a small authoritative registry for
        long-lived credentials, making it a better scalable solution.

     *  The proposed model reduces the task-owner’s burden of finding the
        right agent by shifting discovery work to agents: agents that
        believe they are a good fit proactively submit proposals, which
        narrows the owner’s search space and removes the need for owners
        to precisely specify required skills.

     *  For non urgent tasks that owners do not want to spend a lot for
        them to be done, they are posted for agents to bid on and owners
        can choose the best offer.  This also allows idle agents to have a
        chance to make money and perhaps help with load balancing

     *  By allowing agents to proactively propose for posted tasks, the
        platform enables newcomers and under-exposed agents to build
        verifiable reputation through completed work, reducing cold-start
        barriers and improving match quality—provided the system enforces
        admission controls, verification steps, and incentive mechanisms
        to limit noise and gaming.



  Moussa, et al.          Expires 2 September 2026               [Page 17]


  Internet-Draft               Task-discovery                   March 2026


     *  The billboard model augments registry-based discovery rather than
        replacing it: owners retain registry search capabilities while
        also posting raw tasks to receive proactive proposals.  This
        hybrid approach preserves existing workflows, lowers the barrier
        for non-expert owners, and enables richer matching strategies; to
        work well it requires interoperable metadata, admission controls,
        and clear ranking/deduplication rules so the two channels remain
        complementary and secure.

  6.2.  IETF work required to realize the vision

     The proposed billboard-like agent initiated task discovery model
     offers clear benefits, but substantial IETF work is required to make
     it interoperable, secure, and scalable.  Standards are needed for
     task-posting formats, machine-readable credentials, admission and
     discovery APIs, policy profiles, privacy-preserving attestations, and
     budgeted search semantics; without these, owner-defined trust
     policies will fragment the ecosystem, invite spoofing, and force
     unscalable manual vetting.  The IETF should therefore define minimal,
     composable building blocks that preserve owner flexibility while
     enabling automated verification, cross-domain discovery, and fair
     matching across implementations.

     *  Task posting and metadata formats: a compact, extensible schema
        for raw task descriptions, required attributes, and diagnostic
        prompts.

     *  Discovery and billboard APIs: standardized endpoints and query
        semantics for posting tasks, submitting proposals, and retrieving
        shortlists.

     *  Standardized machine-readable credentials and attestations:
        interoperable formats and protocols for signed capability claims,
        provenance, selective-disclosure identity attributes, and
        revocation signals, enabling automated trust decisions between
        task owners, billboards, and agents without relying on proprietary
        or ad-hoc vetting.

     *  Policy profiles and admission rules: interoperable assurance
        levels (e.g., basic/verified/high-assurance) and a way to express
        owner preferences as machine-evaluable policies.

     *  Search semantics and stop rules: standardized notions of budgeted
        search, progressive widening, and marginal-gain stoppage so
        clients and servers can interoperate on when to halt exploration.
        This is also needed to limit the possibility of overload the read
        function of the agent/task registries.




  Moussa, et al.          Expires 2 September 2026               [Page 18]


  Internet-Draft               Task-discovery                   March 2026


     *  Coalition formation primitives: lightweight protocols for
        capability advertisement, role negotiation, payment split
        templates, and failure recovery.

     *  Fairness and anti-gaming controls: mechanisms that give newcomers
        a fair chance and prevent manipulation of the matching and
        reputation systems.  This includes onboarding micro-tasks for new
        agents, freshness boosts so proposals from less-visible agents are
        not buried, reputation-normalization rules to prevent score
        inflation, and signals for detecting sybil or duplicate agents.

     *  Privacy and selective disclosure: mechanisms (attribute
        attestations, minimal disclosure) that let agents prove claims
        without exposing sensitive data.

     *  Audit, logging, and revocation: tamper-evident logging mechanisms,
        standardized revocation lists, and dispute-resolution hooks that
        allow task owners, agents, and billboards to verify what happened
        during a task lifecycle across different administrative domains.
        This includes consistent formats for recording proposals,
        decisions, completions, and failures; mechanisms for revoking
        compromised or misbehaving agents; and interoperable audit trails
        that support cross-domain verification and accountability.
        Without these shared mechanisms, it becomes difficult to detect
        misconduct, resolve disputes, or maintain trust in a multi-vendor,
        multi-platform ecosystem.

     *  Operational guidance and standardized profiles — a set of shared
        deployment guidelines, recommended defaults, and well-defined
        configuration profiles that help different implementations behave
        consistently.  This includes safe presets for non-expert task
        owners (e.g., “fast match”, “high assurance”), normative guidance
        on how to apply admission policies and search budgets, and test
        vectors that allow implementers to verify correct behavior.
        Without this layer of operational guidance, platforms may
        interpret the same mechanisms differently, leading to
        fragmentation, inconsistent trust decisions, and unpredictable
        user experience.

  7.  Security Considerations

     Security considerations are as outlined within the document under the
     privacy and security requirements

  8.  IANA Considerations

     This document has no IANA actions.




  Moussa, et al.          Expires 2 September 2026               [Page 19]


  Internet-Draft               Task-discovery                   March 2026


  Contributors

     Hesham Moussa
     Huawei Canada
     Email: hesham.moussa@huawei.com


     Arashmid Akhavain
     Huawei Canada
     Email: arashmid.akhavain@huawei.com


     Roberto Pioli
     Independent
     Email: roberto.pioli@example.com


     Jim Mozley
     Infoblox, Inc.
     Email: jmozley@infoblox.com


     Nic Williams
     Infoblox, Inc.
     Email: nwilliams@infoblox.com


  Authors' Addresses

     Hesham Moussa
     Huawei Canada
     Email: hesham.moussa@huawei.com


     Arashmid Akhavain
     Huawei Canada
     Email: arashmid.akhavain@huawei.com


     Roberto Pioli
     Independent
     Email: roberto.pioli@example.com


     Jim Mozley
     Infoblox, Inc.
     Email: jmozley@infoblox.com




  Moussa, et al.          Expires 2 September 2026               [Page 20]


  Internet-Draft               Task-discovery                   March 2026


     Nic Williams
     Infoblox, Inc.
     Email: nwilliams@infoblox.com
















































  Moussa, et al.          Expires 2 September 2026               [Page 21]


name: draft-chu-oauth-as-attested-user-cert
rev: 00
title: OAuth 2.0 Rich Authorization Requests for AS-Attested User Certificates
time: 2026-03-02T08:39:10Z
group_uri: /api/v1/group/group/1027/
expires: 2026-09-03T08:39:10Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-07T06:55:14.591587+00:00
source: ietf
abstract:
  This document defines an extension to the OAuth 2.0 Rich
     Authorization Requests (RAR) framework.  It introduces a mechanism
     that allows a Client, such as an autonomous AI Agent, to request an
     Authorization Server (AS) to include an AS-attested Resource Owner
     public key certificate within, or bound to, an Access Token.

     This mechanism enables the Resource Server (RS) to securely obtain
     the Resource Owner's trusted public key, which can then be used to
     verify application-layer delegation evidence (e.g., Verifiable
     Credentials) signed by the Resource Owner.

full_text:
  OAuth                                                             C. Chu
  Internet-Draft                                                     R. Li
  Intended status: Standards Track                                 H. Wang
  Expires: 3 September 2026                                          T. Li
                                                       Huawei Int. Pte Ltd
                                                              2 March 2026


  OAuth 2.0 Rich Authorization Requests for AS-Attested User Certificates
                  draft-chu-oauth-as-attested-user-cert-00

  Abstract

     This document defines an extension to the OAuth 2.0 Rich
     Authorization Requests (RAR) framework.  It introduces a mechanism
     that allows a Client, such as an autonomous AI Agent, to request an
     Authorization Server (AS) to include an AS-attested Resource Owner
     public key certificate within, or bound to, an Access Token.

     This mechanism enables the Resource Server (RS) to securely obtain
     the Resource Owner's trusted public key, which can then be used to
     verify application-layer delegation evidence (e.g., Verifiable
     Credentials) signed by the Resource Owner.

  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 3 September 2026.

  Copyright Notice

     Copyright (c) 2026 IETF Trust and the persons identified as the
     document authors.  All rights reserved.






  Chu, et al.             Expires 3 September 2026                [Page 1]


  Internet-Draft          OAuth RAR for User Certs              March 2026


     This document is subject to BCP 78 and the IETF Trust's Legal
     Provisions Relating to IETF Documents (https://trustee.ietf.org/
     license-info) in effect on the date of publication of this document.
     Please review these documents carefully, as they describe your rights
     and restrictions with respect to this document.  Code Components
     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.  1.  Introduction  . . . . . . . . . . . . . . . . . . . . . .   2
     2.  2.  Conventions and Terminology . . . . . . . . . . . . . . .   3
     3.  3.  Protocol Overview . . . . . . . . . . . . . . . . . . . .   3
       3.1.  3.1.  Phase 1: Initial Bootstrapping and Registration . .   3
       3.2.  3.2.  Phase 2: Autonomous Execution . . . . . . . . . . .   4
     4.  4.  Authorization Details Type  . . . . . . . . . . . . . . .   5
       4.1.  4.1.  The authorization_details Object  . . . . . . . . .   5
       4.2.  4.2.  Example Token Request . . . . . . . . . . . . . . .   5
     5.  5.  Authorization Server Processing . . . . . . . . . . . . .   5
     6.  6.  Access Token and Introspection  . . . . . . . . . . . . .   6
       6.1.  6.1.  JWT Access Token Payload  . . . . . . . . . . . . .   6
       6.2.  6.2.  Token Introspection Response  . . . . . . . . . . .   6
     7.  7.  Resource Server Processing  . . . . . . . . . . . . . . .   7
     8.  8.  Security Considerations . . . . . . . . . . . . . . . . .   7
       8.1.  8.1.  Integrity and Authenticity of the Resource Owner's
             Public Key  . . . . . . . . . . . . . . . . . . . . . . .   7
       8.2.  8.2.  Proof-of-Possession (PoP) . . . . . . . . . . . . .   8
       8.3.  8.3.  Validation of Delegated Intent Boundaries . . . . .   8
     9.  9.  IANA Considerations . . . . . . . . . . . . . . . . . . .   8
       9.1.  9.1.  OAuth Authorization Details Types Registry  . . . .   8
     10. Normative References  . . . . . . . . . . . . . . . . . . . .   8
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

  1.  1.  Introduction

     With the rise of autonomous AI Agents acting on behalf of users,
     traditional OAuth 2.0 [RFC6749] scopes often fail to provide the
     fine-grained, user-signed intent verification required for high-
     stakes operations.  A robust solution involves the Resource Owner
     (RO) issuing a Verifiable Credential (VC) to the Client.  To exercise
     these delegated rights, the Client generates and presents a
     Verifiable Presentation (VP)-derived from the original VC-to the
     Resource Server (RS) to prove specific, user-signed delegation
     boundaries.






  Chu, et al.             Expires 3 September 2026                [Page 2]


  Internet-Draft          OAuth RAR for User Certs              March 2026


     However, a trust gap exists: while the RO uses its private key to
     sign the VC, the RS lacks a standard mechanism to verify if the
     corresponding public key genuinely belongs to the RO.  This
     specification bridges that gap by leveraging Rich Authorization
     Requests (RAR) [RFC9396].  It allows a Client to request an AS-
     attested certificate of the RO's public key.  The RS can then extract
     this certificate from the Access Token to verify the signature of the
     RO-issued evidence contained within the VP.

  2.  2.  Conventions and Terminology

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

  3.  3.  Protocol Overview

     The protocol consists of two phases: Initial Bootstrapping and
     Autonomous Execution.

  3.1.  3.1.  Phase 1: Initial Bootstrapping and Registration

     The RO registers their public key and authorizes the Client to act on
     their behalf.

     +------+          (1) Register Public Key (PK)          +---------------+
     |      |----------------------------------------------->|               |
     |  RO  |          (2) Acknowledge & Store PK            | Authorization |
     |      |<-----------------------------------------------|  Server (AS)  |
     +------+                                                |               |
        |                                                    |               |
        |      (3) Interactive Authz Request (via Client)    |               |
        +--------------------------------------------------->|               |
        |                                                    |               |
        |      (4) Explicit Consent for Refresh Token (RT)   |               |
        |<---------------------------------------------------|               |
        |                                                    |               |
        |              (5) Issue Refresh Token (RT)          |               |
        |   +------------------------------------------------|               |
        |   |                                                +---------------+
        v   v
     +----------+                                            +---------------+
     |          |      (6) Delegate Intent (e.g., via VC)    |               |
     |  Client  |<-------------------------------------------|      RO       |
     | (Agent)  |          (Signed with Private Key)         |               |
     +----------+                                            +---------------+




  Chu, et al.             Expires 3 September 2026                [Page 3]


  Internet-Draft          OAuth RAR for User Certs              March 2026


     1.  *Public Key Registration:* The RO registers their public key (PK)
         with the AS.

     2.  *Storage:* The AS stores the PK and binds it to the RO's
         identity.

     3.  *Authorization Request:* The Client initiates an interactive
         OAuth 2.0 flow.

     4.  *Consent:* The AS authenticates the RO and obtains consent for a
         Refresh Token (RT).

     5.  *Token Issuance:* The AS issues an RT to the Client.

     6.  *Intent Delegation:* The RO provides the Client with signed
         evidence (e.g., a VC) out-of-band.

  3.2.  3.2.  Phase 2: Autonomous Execution

     The Client uses the Refresh Token to request an Access Token
     containing the RO's certificate.

     +----------+      (A) Token Request (Refresh Token + RAR)       +---------------+
     |          |--------------------------------------------------->|               |
     |  Client  |                                                    | Authorization |
     | (Agent)  |      (B) Access Token (includes AS-signed Cert)    |  Server (AS)  |
     |          |<---------------------------------------------------|               |
     +----------+                                                    +---------------+
          |
          |    (C) API Request + AT + RO-signed VC
          v
     +----------+      (D) [Optional] Introspect AT                  +---------------+
     | Resource |--------------------------------------------------->| Authorization |
     | Server   |      (E) Return Certificate Data                   |  Server (AS)  |
     |  (RS)    |<---------------------------------------------------|               |
     |          |                                                    +---------------+
     |          |-- (F) Extract Cert & Verify AS Signature
     |          |-- (G) Verify VC Signature using User PK from Cert
     |          |-- (H) Execute Authorized Operation
     +----------+

     *  *(A) Token Request:* The Client calls the AS /token endpoint with
        grant_type=refresh_token and RAR authorization_details.

     *  *(B) AT Issuance:* The AS validates the RT and issues an Access
        Token (AT) containing the RO's certificate.





  Chu, et al.             Expires 3 September 2026                [Page 4]


  Internet-Draft          OAuth RAR for User Certs              March 2026


     *  *(C) Resource Request:* The Client presents the AT and the RO-
        signed VC to the RS.

     *  *(D-E) Introspection:* The RS may retrieve certificate data via
        introspection if the AT is opaque.

     *  *(F-G) Verification:* The RS verifies the certificate and then
        uses the RO's PK to verify the VC.

  4.  4.  Authorization Details Type

     This section defines the new RAR authorization_details type
     urn:ietf:params:oauth:as-attested-user-cert.  This type enables the
     Client to explicitly request the RO's public key attestation.

  4.1.  4.1.  The authorization_details Object

     The following fields are defined for this RAR type:

     *  *type* (REQUIRED): MUST be set to urn:ietf:params:oauth:as-
        attested-user-cert.

     *  *cert_format* (OPTIONAL): A string indicating the preferred format
        for the attestation.  Supported values include x509 (for [RFC5280]
        certificates) and jwk (for [RFC7517] JSON Web Keys).  If omitted,
        the AS MAY return a format based on its local policy.

     *  *intended_rs* (OPTIONAL): An array of strings containing the
        identifiers (e.g., URIs) of the Resource Servers.  This allows the
        AS to restrict the audience of the issued certificate.

  4.2.  4.2.  Example Token Request

     ```http POST /token HTTP/1.1 Host: as.example.com Content-Type:
     application/x-www-form-urlencoded

     grant_type=refresh_token &refresh_token=tGzv3JOkF0XG5Qx2TlKWIA
     &client_id=ai-agent-client-123 &authorization_details=[ { "type":
     "urn:ietf:params:oauth:as-attested-user-cert", "cert_format": "x509",
     "intended_rs": ["https://rs.example.com/api/v1
     (https://rs.example.com/api/v1)"] } ] ```

  5.  5.  Authorization Server Processing

     When the AS receives a token request with the
     urn:ietf:params:oauth:as-attested-user-cert type, it MUST perform the
     following processing steps:




  Chu, et al.             Expires 3 September 2026                [Page 5]


  Internet-Draft          OAuth RAR for User Certs              March 2026


     1.  *Grant Validation:* Validate the refresh_token or other provided
         grant according to [RFC6749].

     2.  *RO Identification:* Identify the RO associated with the
         authenticated session or grant.

     3.  *Public Key Retrieval:* Retrieve the RO's registered public key
         from the AS's secure storage.  If no public key is registered for
         this RO, the AS MUST return an invalid_request error.

     4.  *Certificate Generation:* Generate a digital attestation (e.g.,
         an X.509 certificate) that binds the RO's identity (the sub
         value) to the retrieved public key.  The AS MUST sign this
         attestation using its own private key.

     5.  *Issuance:* Include the attestation data in the
         authorization_details claim of the issued Access Token.

  6.  6.  Access Token and Introspection

     The AS MUST provide the RO's certificate data to the RS, either by
     embedding it directly in a structured token (e.g., JWT) or by
     returning it via an introspection response.

  6.1.  6.1.  JWT Access Token Payload

     For JWT-formatted Access Tokens [RFC9068], the AS MUST include the
     certificate in the authorization_details array:

     {
       "iss": "[https://as.example.com](https://as.example.com)",
       "sub": "user_12345",
       "aud": "[https://rs.example.com/api/v1](https://rs.example.com/api/v1)",
       "exp": 1718293600,
       "authorization_details": [
         {
           "type": "urn:ietf:params:oauth:as-attested-user-cert",
           "certificate_data": "MIIDdzCCAl+gAwIBAgIE...<Base64_Encoded_Cert>..."
         }
       ]
     }

  6.2.  6.2.  Token Introspection Response

     If the Access Token is opaque, the RS MUST use Token Introspection
     [RFC7662].  The AS response MUST include the same
     authorization_details object as defined above:




  Chu, et al.             Expires 3 September 2026                [Page 6]


  Internet-Draft          OAuth RAR for User Certs              March 2026


     {
       "active": true,
       "scope": "read write",
       "authorization_details": [
         {
           "type": "urn:ietf:params:oauth:as-attested-user-cert",
           "certificate_data": "MIIDdzCCAl+gAwIBAgIE..."
         }
       ]
     }

  7.  7.  Resource Server Processing

     The RS MUST follow these steps to verify the AI Agent's request:

     1.  *AT Validation:* Validate the Access Token (signature,
         expiration, and audience).

     2.  *Certificate Extraction:* Extract the certificate_data from the
         authorization_details claim.

     3.  *AS Signature Verification:* Verify the AS's signature on the
         certificate using the AS's well-known public key.  This confirms
         that the RO's public key has not been tampered with.

     4.  *Application Evidence Verification:* Extract the RO's public key
         from the verified certificate and use it to verify the signature
         of the application-layer evidence (e.g., the VP/VC provided by
         the AI Agent).

     5.  *Execution:* Proceed with the requested operation only if all
         cryptographic signatures are valid.

  8.  8.  Security Considerations

  8.1.  8.1.  Integrity and Authenticity of the Resource Owner's Public
        Key

     The AS-attested certificate is the primary defense against key
     substitution attacks.  The RS MUST NOT use any RO public key that is
     not accompanied by a valid AS signature.  Any discrepancy in the AS
     signature MUST result in the immediate rejection of the request.









  Chu, et al.             Expires 3 September 2026                [Page 7]


  Internet-Draft          OAuth RAR for User Certs              March 2026


  8.2.  8.2.  Proof-of-Possession (PoP)

     To prevent token/credential leakage risks, it is RECOMMENDED that the
     Client's request to the RS be protected by a Proof-of-Possession
     mechanism (e.g., DPoP or mTLS), ensuring the AT and the RO-signed
     evidence are bound to the current Client.

  8.3.  8.3.  Validation of Delegated Intent Boundaries

     The RS MUST strictly parse and validate the claims within the
     presented VP to ensure the requested action falls within the explicit
     boundaries signed by the RO.

  9.  9.  IANA Considerations

  9.1.  9.1.  OAuth Authorization Details Types Registry

     This document requests the registration of the following type in the
     "OAuth Authorization Details Types" registry:

     +===========================+===============+==========+============+
     | Type Value                | Description   |Change    | Reference  |
     |                           |               |Controller|            |
     +===========================+===============+==========+============+
     | urn:ietf:params:oauth:as- | Request an    |IETF      | [[This     |
     | attested-user-cert        | AS-attested   |          | Document]] |
     |                           | RO public     |          |            |
     |                           | key           |          |            |
     |                           | certificate   |          |            |
     +---------------------------+---------------+----------+------------+

                                    Table 1

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

     [RFC6749]  Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
                RFC 6749, DOI 10.17487/RFC6749, October 2012,
                <https://www.rfc-editor.org/rfc/rfc6749>.

     [RFC6750]  Jones, M. and D. Hardt, "The OAuth 2.0 Authorization
                Framework: Bearer Token Usage", RFC 6750,
                DOI 10.17487/RFC6750, October 2012,
                <https://www.rfc-editor.org/rfc/rfc6750>.



  Chu, et al.             Expires 3 September 2026                [Page 8]


  Internet-Draft          OAuth RAR for User Certs              March 2026


     [RFC7519]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
                (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
                <https://www.rfc-editor.org/rfc/rfc7519>.

     [RFC7662]  Richer, J., Ed., "OAuth 2.0 Token Introspection",
                RFC 7662, DOI 10.17487/RFC7662, October 2015,
                <https://www.rfc-editor.org/rfc/rfc7662>.

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

     [RFC9396]  Lodderstedt, T., Richer, J., and B. Campbell, "OAuth 2.0
                Rich Authorization Requests", RFC 9396,
                DOI 10.17487/RFC9396, May 2023,
                <https://www.rfc-editor.org/rfc/rfc9396>.

  Authors' Addresses

     Cheng-Kang Chu
     Huawei Int. Pte Ltd
     Email: chu.cheng.kang@huawei.com


     Ruochen Li
     Huawei Int. Pte Ltd
     Email: li.ruochen@h-partners.com


     Haiguang Wang
     Huawei Int. Pte Ltd
     Email: wang.haiguang.shieldlab@huawei.com


     Tieyan Li
     Huawei Int. Pte Ltd
     Email: Li.Tieyan@huawei.com














  Chu, et al.             Expires 3 September 2026                [Page 9]


name: draft-ma-v6ops-pe-ipv6only-reqs
rev: 00
title: Requirements for Provider Edge in IPv6-only Underlay Networks
time: 2026-03-05T17:28:10Z
group_uri: /api/v1/group/group/1027/
expires: 2026-09-03T09:37:12Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-07T06:55:14.591593+00:00
source: ietf
abstract:
  This document defines functional, protocol, and operational
     requirements for Provider Edge (PE) devices operating in a multi-
     domain network environment where the underlay is exclusively based on
     IPv6.  These requirements ensure consistent service delivery,
     interoperability, and efficient operations across autonomous domains
     while supporting IPv4-as-a-Service (IPv4aaS).

full_text:
  v6ops Working Group                                                C. Ma
  Internet-Draft                                                    C. Xie
  Intended status: Standards Track                           China Telecom
  Expires: 3 September 2026                                   2 March 2026


       Requirements for Provider Edge in IPv6-only Underlay Networks
                     draft-ma-v6ops-pe-ipv6only-reqs-00

  Abstract

     This document defines functional, protocol, and operational
     requirements for Provider Edge (PE) devices operating in a multi-
     domain network environment where the underlay is exclusively based on
     IPv6.  These requirements ensure consistent service delivery,
     interoperability, and efficient operations across autonomous domains
     while supporting IPv4-as-a-Service (IPv4aaS).

  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 3 September 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 (https://trustee.ietf.org/
     license-info) in effect on the date of publication of this document.
     Please review these documents carefully, as they describe your rights
     and restrictions with respect to this document.  Code Components
     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.



  Ma & Xie                Expires 3 September 2026                [Page 1]


  Internet-Draft              IPv6-only PE reqs                 March 2026


  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
       1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
     2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
     3.  Architectural Reference Model . . . . . . . . . . . . . . . .   3
     4.  Core Requirements for PEs . . . . . . . . . . . . . . . . . .   4
       4.1.  Inter-domain Routing Distribution Requirements  . . . . .   4
       4.2.  Data Plane Forwarding & Encapsulation Requirements  . . .   5
       4.3.  Operations & Management Requirements  . . . . . . . . . .   6
     5.  Relationship with Existing Frameworks . . . . . . . . . . . .   6
     6.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
     7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
     8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   7
     9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
       9.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
       9.2.  Iormative References  . . . . . . . . . . . . . . . . . .   9
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

  1.  Introduction

     The evolution towards IPv6-only underlay networks presents a
     compelling opportunity to simplify network architecture and reduce
     operational overhead.  In large-scale service provider environments,
     this underlay often spans multiple administrative domains (e.g.,
     different Autonomous Systems or organizational boundaries).  A
     framework for such a multi-domain IPv6-only underlay, supporting
     services like IPv4-as-a-Service (IPv4aaS), is described in
     [I-D.ietf-v6ops-framework-md-ipv6only-underlay].

     In this architecture, the Provider Edge (PE) device serves as the
     critical nodal point where customer service attachment intersects
     with the multi-domain IPv6-only underlay.  Its role extends beyond
     traditional PE functions to include key responsibilities in inter-
     domain service routing, protocol-agnostic data encapsulation, and
     cross-domain service assurance.

     This document specifies the requirements for PE devices operating in
     this specific context.  These requirements ensure that PEs from
     different vendors and domains can interoperate seamlessly to deliver
     end-to-end services across a pure IPv6 underlay.










  Ma & Xie                Expires 3 September 2026                [Page 2]


  Internet-Draft              IPv6-only PE reqs                 March 2026


     It should be noted that this document does not cover all the
     requirements for PE devices, it only introduces the parts directly
     related to IPv6-only.  By specifying these requirements, this
     document aims to provide a common recommendation for equipment
     vendors and network operators, facilitating the development,
     deployment, and interoperability of multi-domain IPv6-only PE
     Routers.  This will ultimately contribute to the successful
     establishment and operation of multi-domain IPv6-only network.

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

     The following terms are defined in this draft:

     *  Multi-domain Network: A network comprising two or more
        administratively separate domains (e.g., Autonomous Systems)
        interconnected to provide end-to-end services.

     *  IPv6-only Underlay: A network infrastructure that exclusively uses
        IPv6 for forwarding and control-plane protocols, with no native
        IPv4 forwarding path.

     *  Inter-domain PE: A PE device located at the boundary between two
        administrative domains, responsible for exchanging service
        information and forwarding traffic across domains.

     *  Intra-domain PE: A PE device located within a single
        administrative domain.

     *  IPv4-as-a-Service (IPv4aaS): A service model where IPv4
        connectivity is provided to customers over an IPv6-only underlay
        network, using encapsulation or translation techniques.

     *  PE: Provider Edge, defined in [RFC4026]

  3.  Architectural Reference Model








  Ma & Xie                Expires 3 September 2026                [Page 3]


  Internet-Draft              IPv6-only PE reqs                 March 2026


               +------------------+      PE     +------------------+
               |   Domain A       | (Intra/Inter|    Domain B      |
               | (IPv6-only AS)   |   -domain)  | (IPv6-only AS)   |
               |                  +-------------+                  |
               |  [PE]---[P]---[ASBR]        [ASBR]---[P]---[PE]   |
               +------------------+             +------------------+
                       |                                      |
                   +---+------+                          +----+----+
                   | IPv4 CE  |                          | IPv4 CE |
                   +----------+                          +---------+

                     Figure 1: Multi-domain IPv6-only Underlay
                           with PE Service Attachment Points

     In the reference model (Figure 1):

     *  Each domain operates an internal IPv6-only IGP (e.g., IS-ISv6 or
        OSPFv3) .

     *  Domains are interconnected via Inter-domain PEs (acting as ASBRs)
        using IPv6 EBGP sessions.

     *  Service layer routes (e.g., IPv4 VPN routes) are exchanged via MP-
        BGP over the IPv6 underlay.

     *  Customer IPv4 traffic is encapsulated within IPv6 (e.g., with an
        SRv6 header) for traversal across the multi-domain underlay.

  4.  Core Requirements for PEs

  4.1.  Inter-domain Routing Distribution Requirements

     REQ-1: A PE device, when acting as an Inter-domain PE, MUST be able
     to exchange service layer routes (e.g., VPN-IPv4/VPN-IPv6 NLRIs
     [RFC4364] with PEs in other domains using MP-BGP sessions where the
     next-hop is an IPv6 address.  This MUST be supported over IPv6-only
     underlay transport.














  Ma & Xie                Expires 3 September 2026                [Page 4]


  Internet-Draft              IPv6-only PE reqs                 March 2026


     REQ-2: A PE device MUST support the necessary MP-BGP extensions and
     procedures for advertising IPv4-to-IPv6 (and vice versa) service
     mappings across domain boundaries.  This capability is FUNDAMENTAL
     for enabling services like IPv4-as-a-Service (IPv4aaS) in an IPv6-
     only underlay.  It allows a downstream PE to correctly associate a
     received IPv4 service prefix with its corresponding IPv6 underlay
     path identifier or tunnel endpoint.  The specific encoding (e.g., a
     dedicated BGP attribute, extended community, or a new AFI/SAFI) and
     procedures for distributing these mappings MUST follow
     [I-D.ietf-idr-mpbgp-extension-4map6].  PE devices MUST be able to
     install forwarding state based on these received mappings.

     REQ-3: A PE device MUST correctly process and enforce policies based
     on BGP Extended Community attributes, specifically Route Target, to
     identify and isolate service routes and their associated mappings
     belonging to different customers or domains.

     REQ-4: A PE device MAY support additional mechanisms for inter-
     domain traffic steering and policy enforcement beyond basic
     connectivity.  If supported, such mechanisms (e.g., BGP-based
     mechanisms for segment routing or other tunnel technologies) SHOULD
     operate transparently across the IPv6-only underlay.  Crucially, the
     absence of any specific traffic steering mechanism MUST NOT break
     basic IPv4aaS service connectivity established through REQ-1 and REQ-
     2.

  4.2.  Data Plane Forwarding & Encapsulation Requirements

     REQ-5: A PE device MUST support at least one IETF-standardized
     encapsulation method for carrying non-IPv6 customer traffic (e.g.,
     IPv4, Ethernet) across the IPv6-only underlay.  Possible mechanisms
     include, but are not limited to, IPv6-in-IPv6 tunneling [RFC2473],
     Generic Routing Encapsulation (GRE) over IPv6, MPLS-in-UDP/IPv6
     [RFC7510], or SRv6 [RFC8986].  The choice of encapsulation MUST be
     derivable from the control-plane information (e.g., the service
     mapping advertised per REQ-2).

     REQ-6: As an ingress PE, the device MUST be capable of encapsulating
     received customer packets (e.g., IPv4) with an appropriate IPv6
     header, based on the forwarding state installed via the control plane
     (driven by REQ-2).  As an egress PE, the device MUST be capable of
     decapsulating the outer IPv6 header to recover the original customer
     packet and forward it to the correct service instance.








  Ma & Xie                Expires 3 September 2026                [Page 5]


  Internet-Draft              IPv6-only PE reqs                 March 2026


     REQ-7: Due to the increased packet size from encapsulation, a PE
     device MUST implement Path MTU Discovery for IPv6 [RFC8201].  It MUST
     either handle fragmentation appropriately or signal MTU issues back
     to the source (e.g., using ICMPv6 Packet Too Big messages) in a way
     that functions correctly across domain boundaries, considering the
     encapsulated path.

  4.3.  Operations & Management Requirements

     REQ-8: A PE device MUST support standardized OAM mechanisms that
     operate end-to-end across multiple domains over the IPv6-only
     underlay.  This includes, but is not limited to, IPv6-based
     Bidirectional Forwarding Detection (BFD)[RFC5880]and ICMPv6-based
     traceroute.  The OAM packets MUST follow the same encapsulation path
     as data traffic.As a forwarding node in IPv6-only networks, PE router
     shall accept centralized policy scheduling from the network
     controller and implementing automated configuration through the
     NETCONF protocol/YANG model.  Meanwhile, the PE supports syslog and
     SNMP Trap alarm mechanisms, enabling rapid fault location and
     security incident tracing through standardized logs.

     REQ-9: A PE device MUST be able to map the Quality of Service (QoS)
     markings from the customer packet (e.g., IPv4 DSCP) to the
     encapsulating IPv6 header's Traffic Class field (or equivalent), and
     ensure this policy is consistently applied and honored as the packet
     traverses different domains.

     REQ-10: A PE device MUST provide robust isolation between traffic
     from different customers or services across the shared IPv6 underlay.
     This MUST be enforceable at inter-domain boundaries, typically
     implemented through the use of distinct VPN routing/forwarding
     instances or logically separated encapsulation identifiers derived
     from the control plane.

  5.  Relationship with Existing Frameworks

     This document provides the concrete device-level requirements that
     implement the architecture described in the framework document
     [I-D.ietf-v6ops-framework-md-ipv6only-underlay].  It relies upon and
     extends the principles established in existing VPN specifications
     (e.g., [RFC4364], [RFC7432]) and places critical new requirements on
     MP-BGP for service mapping (REQ-2) to enable operation in a multi-
     domain, IPv6-only context.

  6.  Security Considerations

     Security in a multi-domain IPv6-only environment introduces specific
     considerations for PE devices:



  Ma & Xie                Expires 3 September 2026                [Page 6]


  Internet-Draft              IPv6-only PE reqs                 March 2026


     o BGP Session Security: All inter-domain BGP sessions MUST be secured
     using mechanisms such as IPsec [RFC4301].  Route Origin Authorization
     (ROA) validation via RPKI [RFC6810] SHOULD be implemented where
     feasible.

     o Mapping Advertisement Integrity: The service mapping advertisements
     (REQ-2) are critical for correct forwarding.  Mechanisms MUST be in
     place to ensure their integrity and authenticity, potentially
     leveraging existing BGP security measures.

     o OAM Protection: OAM protocols MUST be rate-limited and protected
     from misuse that could lead to denial-of-service attacks across
     domains.

     o Encapsulation Overhead and Inspection: The addition of
     encapsulation headers should be considered in network capacity
     planning and security monitoring.  Techniques for deep packet
     inspection may need to be adapted to operate on encapsulated traffic
     within the underlay.

  7.  IANA Considerations

     This document has no IANA actions.

  8.  Acknowledgements

     The authors would like to thank the contributors and reviewers of
     this document for their valuable input and feedback.

  9.  References

  9.1.  Normative References

     [I-D.ietf-idr-mpbgp-extension-4map6]
                Xie, C., Dong, G., Li, X., Han, G., and Z. Guo, "MP-BGP
                Extension and the Procedures for IPv4/IPv6 Mapping
                Advertisement", Work in Progress, Internet-Draft, draft-
                ietf-idr-mpbgp-extension-4map6-05, 3 December 2025,
                <https://datatracker.ietf.org/doc/html/draft-ietf-idr-
                mpbgp-extension-4map6-05>.

     [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/info/rfc2119>.






  Ma & Xie                Expires 3 September 2026                [Page 7]


  Internet-Draft              IPv6-only PE reqs                 March 2026


     [RFC2473]  Conta, A. and S. Deering, "Generic Packet Tunneling in
                IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473,
                December 1998, <https://www.rfc-editor.org/info/rfc2473>.

     [RFC4026]  Andersson, L. and T. Madsen, "Provider Provisioned Virtual
                Private Network (VPN) Terminology", RFC 4026,
                DOI 10.17487/RFC4026, March 2005,
                <https://www.rfc-editor.org/info/rfc4026>.

     [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
                Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
                December 2005, <https://www.rfc-editor.org/info/rfc4301>.

     [RFC4364]  Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
                Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
                2006, <https://www.rfc-editor.org/info/rfc4364>.

     [RFC5880]  Katz, D. and D. Ward, "Bidirectional Forwarding Detection
                (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010,
                <https://www.rfc-editor.org/info/rfc5880>.

     [RFC6810]  Bush, R. and R. Austein, "The Resource Public Key
                Infrastructure (RPKI) to Router Protocol", RFC 6810,
                DOI 10.17487/RFC6810, January 2013,
                <https://www.rfc-editor.org/info/rfc6810>.

     [RFC7432]  Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A.,
                Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based
                Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February
                2015, <https://www.rfc-editor.org/info/rfc7432>.

     [RFC7510]  Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black,
                "Encapsulating MPLS in UDP", RFC 7510,
                DOI 10.17487/RFC7510, April 2015,
                <https://www.rfc-editor.org/info/rfc7510>.

     [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/info/rfc8174>.

     [RFC8201]  McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed.,
                "Path MTU Discovery for IP version 6", STD 87, RFC 8201,
                DOI 10.17487/RFC8201, July 2017,
                <https://www.rfc-editor.org/info/rfc8201>.







  Ma & Xie                Expires 3 September 2026                [Page 8]


  Internet-Draft              IPv6-only PE reqs                 March 2026


     [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/info/rfc8986>.

  9.2.  Iormative References

     [I-D.ietf-v6ops-framework-md-ipv6only-underlay]
                Xie, C., Ma, C., Li, X., Mishra, G. S., and T. Graf,
                "Framework for Multi-domain IPv6-only Underlay Network and
                IPv4-as-a-Service", Work in Progress, Internet-Draft,
                draft-ietf-v6ops-framework-md-ipv6only-underlay-19, 5
                February 2026, <https://datatracker.ietf.org/doc/html/
                draft-ietf-v6ops-framework-md-ipv6only-underlay-19>.

  Authors' Addresses

     Chenhao
     China Telecom
     Beiqijia Town, Changping District
     Beijing
     Beijing, 102209
     China
     Email: machh@chinatelecom.cn


     Chongfeng Xie
     China Telecom
     Beiqijia Town, Changping District
     Beijing
     Beijing, 102209
     China
     Email: xiechf@chinatelecom.cn

















  Ma & Xie                Expires 3 September 2026                [Page 9]


name: draft-yang-dynamic-ecn-threshold
rev: 00
title: Coupling ECN Marking Thresholds with Dynamic Buffer Allocation
time: 2026-03-02T10:42:36Z
group_uri: /api/v1/group/group/1027/
expires: 2026-09-03T10:42:36Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-07T06:55:15.140207+00:00
source: ietf
abstract:
  Explicit Congestion Notification (ECN) marking thresholds are
     typically configured statically.  In modern network devices that
     employ dynamic buffer allocation -- where the maximum buffer
     available to a queue fluctuates dynamically based on the number of
     active queues and the remaining shared buffer pool -- a static ECN
     threshold can frequently become misaligned with the actual
     instantaneous buffering capacity.

     This misalignment can lead to pathological behaviors: either
     premature marking (which underutilizes available buffers and
     throttles throughput) or late marking (which provides no advance
     warning before tail drop occurs).  This document describes an
     operational framework and a deterministic reference algorithm for
     dynamically coupling the ECN marking threshold with the dynamic
     buffer allocation limit.  By maintaining an adaptive relationship
     through configurable parameters, this mechanism ensures robust
     congestion signaling across varying load conditions without requiring
     complex external machine-learning models or per-flow tracking.

full_text:
  Transport Area Working Group                                     J. Yang
  Internet-Draft                                                  W. Cheng
  Intended status: Informational                                   Y. Tian
  Expires: 2 September 2026                                   China Mobile
                                                                   J. Wang
                                                                  G. Zhang
                                                                    Centec
                                                              1 March 2026


       Coupling ECN Marking Thresholds with Dynamic Buffer Allocation
                    draft-yang-dynamic-ecn-threshold-00

  Abstract

     Explicit Congestion Notification (ECN) marking thresholds are
     typically configured statically.  In modern network devices that
     employ dynamic buffer allocation -- where the maximum buffer
     available to a queue fluctuates dynamically based on the number of
     active queues and the remaining shared buffer pool -- a static ECN
     threshold can frequently become misaligned with the actual
     instantaneous buffering capacity.

     This misalignment can lead to pathological behaviors: either
     premature marking (which underutilizes available buffers and
     throttles throughput) or late marking (which provides no advance
     warning before tail drop occurs).  This document describes an
     operational framework and a deterministic reference algorithm for
     dynamically coupling the ECN marking threshold with the dynamic
     buffer allocation limit.  By maintaining an adaptive relationship
     through configurable parameters, this mechanism ensures robust
     congestion signaling across varying load conditions without requiring
     complex external machine-learning models or per-flow tracking.

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



  Yang, et al.            Expires 2 September 2026                [Page 1]


  Internet-Draft            Dynamic ECN Threshold               March 2026


     This Internet-Draft will expire on 2 September 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 (https://trustee.ietf.org/
     license-info) in effect on the date of publication of this document.
     Please review these documents carefully, as they describe your rights
     and restrictions with respect to this document.  Code Components
     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
     2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
       2.1.  Requirements Language . . . . . . . . . . . . . . . . . .   4
     3.  Applicability Statement . . . . . . . . . . . . . . . . . . .   4
     4.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   5
     5.  Dynamic Coupling Architecture . . . . . . . . . . . . . . . .   5
       5.1.  Prerequisite: Buffer State Awareness  . . . . . . . . . .   5
       5.2.  Reference Algorithm for ECN Threshold . . . . . . . . . .   6
       5.3.  Architectural Invariants  . . . . . . . . . . . . . . . .   7
     6.  Operational Considerations  . . . . . . . . . . . . . . . . .   7
       6.1.  Update Synchronization  . . . . . . . . . . . . . . . . .   7
       6.2.  Tuning the Offset Parameter . . . . . . . . . . . . . . .   8
       6.3.  Tuning the ECN_Floor Parameter  . . . . . . . . . . . . .   8
     7.  Implementation Status . . . . . . . . . . . . . . . . . . . .   8
     8.  Related Work  . . . . . . . . . . . . . . . . . . . . . . . .   9
     9.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
     10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
     11. Normative References  . . . . . . . . . . . . . . . . . . . .  10
     12. Informative References  . . . . . . . . . . . . . . . . . . .  10
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11

  1.  Introduction

     Explicit Congestion Notification (ECN) [RFC3168] enables network
     devices to signal incipient congestion to endpoints without resorting
     to packet drops.  A device marks a packet's IP header with the
     Congestion Experienced (CE) codepoint when a specific queue metric
     exceeds a configured Active Queue Management (AQM) threshold.  The
     sender, upon learning of the CE mark through transport-layer
     feedback, proactively reduces its sending rate.



  Yang, et al.            Expires 2 September 2026                [Page 2]


  Internet-Draft            Dynamic ECN Threshold               March 2026


     Conventionally, the ECN marking threshold is established as a static
     value chosen by the network operator.  This static approach functions
     adequately when the maximum buffer available to a given queue is also
     static and predictable.  However, the architecture of modern data
     center switches heavily relies on dynamic buffer allocation.  In such
     architectures, the maximum buffer a queue is permitted to consume
     (Buf_Thrd) fluctuates significantly based on the total available
     shared buffer and the instantaneous number of active queues drawing
     from it.  Dynamic buffer allocation schemes, such as those utilizing
     the alpha parameter model, are widely deployed in commodity switching
     silicon to maximize memory utilization.

     When Buf_Thrd shrinks (e.g., due to an incast event activating many
     queues), a static ECN threshold originally positioned well below the
     nominal buffer limit may suddenly be equal to or greater than the
     current Buf_Thrd.  In this scenario, the device is forced into tail
     drop before the queue occupancy ever reaches the ECN threshold.  The
     ECN mechanism effectively fails, yielding severe packet loss and
     higher tail latency rather than graceful rate reduction.

     Conversely, when the network load decreases and Buf_Thrd expands, the
     static threshold may sit far below the actual buffer capacity.  This
     drastically underutilizes available buffering, generating premature
     congestion signals that trigger unnecessary rate reduction and
     diminish overall link utilization.

     Unlike sojourn-time based AQM algorithms (such as CoDel [RFC8289] or
     PIE [RFC8033]), which inherently adapt to buffer size variations by
     measuring delay rather than bytes, queue-depth based marking
     mechanisms (e.g., standard step-marking in DCTCP [RFC8257] or RoCEv2
     environments) are highly vulnerable to dynamic buffer fluctuations.

     This document specifies an operational mechanism that continually
     derives the ECN marking threshold (ECN_Thrd) from the instantaneous
     value of Buf_Thrd.  The computation introduces two operator-
     configurable parameters to maintain predictable headroom.  The
     approach offers a deterministic, hardware-friendly solution to
     maintain a consistent relationship between ECN marking and buffer
     availability.

  2.  Terminology

     In the context of this document, a "queue" typically refers to a per-
     port, per-traffic-class transmission queue within a forwarding
     device.

     Buf_Thrd (Buffer Threshold):  The dynamic buffer allocation limit for




  Yang, et al.            Expires 2 September 2026                [Page 3]


  Internet-Draft            Dynamic ECN Threshold               March 2026


        a specific queue.  This represents the maximum amount of shared
        buffer memory that the queue is currently authorized to occupy.
        Buf_Thrd is periodically or event-driven recomputed by the
        device's buffer management subsystem.

     ECN_Thrd (ECN Threshold):  The active ECN marking threshold for a
        queue.  When the instantaneous or averaged queue occupancy meets
        or exceeds ECN_Thrd, the device applies the CE codepoint to
        arriving ECN-capable packets.

     Offset:  A configurable parameter dictating the desired buffer
        headroom (typically measured in bytes or cells) maintained between
        Buf_Thrd and ECN_Thrd.  The Offset acts as a shock absorber for
        packets already in-flight during the control loop feedback delay.

     ECN_Floor:  A configurable parameter establishing the minimum
        permissible boundary for ECN_Thrd.  It acts as a safeguard against
        ECN_Thrd collapsing to excessively low values (e.g., below a
        single MTU), which would cause catastrophic throughput degradation
        via aggressive continuous marking.

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

  3.  Applicability Statement

     This document is explicitly applicable to network forwarding devices
     utilizing queue-depth based ECN marking mechanisms in conjunction
     with a dynamic buffer allocation scheme.  It is primarily targeted at
     Data Center Networks (DCN) and high-speed interconnects where
     instantaneous queue length or average queue length is evaluated
     against a byte-based or cell-based threshold.

     This specification does NOT target devices employing sojourn-time
     based AQMs (e.g., [RFC8289], [RFC8033]), as time-based algorithms
     naturally abstract away the physical buffer size and are generally
     immune to the dynamic shared buffer problem described herein.

     The operational logic defined here is strictly internal to the
     network device.  It does not alter the ECN wire protocol, IP-layer
     ECN codepoint semantics, or the transport-layer negotiation
     standardized in [RFC3168].




  Yang, et al.            Expires 2 September 2026                [Page 4]


  Internet-Draft            Dynamic ECN Threshold               March 2026


     The method is compatible with Classic ECN marking as well as modern
     scalable congestion controls (e.g., the L4S architecture [RFC9330]
     and its ECN protocol [RFC9331]).  In a DualQ Coupled AQM
     [I-D.ietf-tsvwg-aqm-dualq-coupled] architecture, the dynamically
     computed ECN_Thrd may serve as the target threshold for the Classic
     queue, leaving the L4S queue's specialized marking behavior
     independent.

  4.  Problem Statement

     To formalize the problem context, consider a Top-of-Rack (ToR) switch
     equipped with a 12 MB shared buffer pool and 48 egress ports.  Under
     light traffic conditions with only 4 queues active, the dynamic
     buffer management may assign a Buf_Thrd of 3 MB to each active queue.
     Assuming a network operator statically configures an ECN threshold of
     200 KB, the system operates with 2.8 MB of effective headroom,
     providing ample shock absorption.

     However, during a coordinated incast event where all 48 ports become
     heavily congested, the shared buffer is fractured, and the dynamic
     Buf_Thrd for each queue plummets to 250 KB.  The statically
     configured 200 KB ECN threshold now yields a mere 50 KB of headroom.
     In high-speed environments (e.g., 100Gbps+), 50 KB is significantly
     smaller than the Bandwidth-Delay Product (BDP) of the control loop.
     Consequently, the queue will hit the tail drop limit (Buf_Thrd)
     before the transport sender has time to react to the CE marks,
     inducing severe retransmission timeouts and latency spikes.

     Conversely, if the operator statically configures the ECN threshold
     to 2 MB to optimize for high throughput under light load, the ECN
     mechanism will completely fail during the incast event because the
     static ECN threshold (2 MB) heavily exceeds the active Buf_Thrd (250
     KB).

     A deterministic, dynamic coupling between Buf_Thrd and ECN_Thrd is
     necessary to resolve these dual failure modes without relying on
     static compromises.

  5.  Dynamic Coupling Architecture

  5.1.  Prerequisite: Buffer State Awareness

     The foundation of this architecture requires the device's forwarding
     plane to expose the current Buf_Thrd value to the AQM/ECN marking
     engine.  The specific memory management algorithm (e.g., alpha-based
     proportional allocation) calculating Buf_Thrd is outside the scope of
     this document.  The sole prerequisite is that Buf_Thrd is
     continuously updated and accessible with low latency.



  Yang, et al.            Expires 2 September 2026                [Page 5]


  Internet-Draft            Dynamic ECN Threshold               March 2026


  5.2.  Reference Algorithm for ECN Threshold

     Network devices SHOULD compute ECN_Thrd continuously based on
     Buf_Thrd, Offset, and ECN_Floor.  To ensure stability across all load
     extremes, the logic is segmented into three distinct operational
     regions:

     Region A -- Sufficient Buffer (Nominal State):

     Condition: (Buf_Thrd - Offset) > ECN_Floor.  The buffer allocation is
     generous enough to accommodate the full requested headroom (Offset).
     Here, ECN_Thrd = Buf_Thrd - Offset.  The ECN threshold securely
     tracks the dynamic buffer limit, guaranteeing precisely the
     configured absorption capacity.

     Region B -- Constrained Buffer (Congested State):

     Condition: (Buf_Thrd - Offset) <= ECN_Floor AND Buf_Thrd > ECN_Floor.
     The shared buffer is highly constrained.  Enforcing the full Offset
     would depress ECN_Thrd below the critical ECN_Floor, risking
     excessive marking and severe throughput collapse.  To mitigate this,
     the threshold is clamped: ECN_Thrd = ECN_Floor.  The available
     headroom compresses to (Buf_Thrd - ECN_Floor), prioritizing
     reasonable throughput over optimal packet absorption.

     Region C -- Critical Buffer (Exhaustion State):

     Condition: Buf_Thrd <= ECN_Floor.  The queue's buffer allocation has
     collapsed to or below the minimum floor.  In this critical state,
     clamping ECN_Thrd to ECN_Floor would result in ECN_Thrd >= Buf_Thrd,
     rendering ECN useless (tail drops would occur silently).  Thus,
     ECN_Thrd = Buf_Thrd.  While zero headroom remains, the device marks
     packets exactly at the tail drop boundary, ensuring the network still
     transmits explicit congestion signals.

     The reference logic is expressed as follows:

     function compute_ecn_threshold(Buf_Thrd, Offset, ECN_Floor):
         IF (Buf_Thrd - Offset) > ECN_Floor:
             RETURN Buf_Thrd - Offset          // Region A: Optimal tracking
         ELSE IF Buf_Thrd > ECN_Floor:
             RETURN ECN_Floor                  // Region B: Floor clamped
         ELSE:
             RETURN Buf_Thrd                   // Region C: Drop boundary







  Yang, et al.            Expires 2 September 2026                [Page 6]


  Internet-Draft            Dynamic ECN Threshold               March 2026


                          Buf_Thrd Update Event
                                |
                                v
                   +---------------------------+
                   | (Buf_Thrd - Offset) >     |
                   |        ECN_Floor?         |
                   +-------------+-------------+
                   | YES         | NO
                   v             v
         ECN_Thrd =     +------------------+
         Buf_Thrd -     | Buf_Thrd >       |
         Offset         |    ECN_Floor?    |
         [Region A]     +--------+---------+
                        | YES    | NO
                        v        v
              ECN_Thrd =   ECN_Thrd =
              ECN_Floor    Buf_Thrd
              [Region B]   [Region C]

              Figure 1: State Transition of Dynamic ECN Threshold

     This algorithm requires minimal logic gates (two comparators and one
     subtractor), ensuring it can be evaluated in standard Application-
     Specific Integrated Circuit (ASIC) pipelines with nominal nanosecond
     latency.

  5.3.  Architectural Invariants

     Implementations conforming to this framework SHOULD validate the
     following invariants to prevent anomalous traffic handling:

     1.  ECN_Thrd MUST NOT exceed Buf_Thrd (ECN_Thrd <= Buf_Thrd).  This
     mathematically guarantees ECN marking is always attempted prior to or
     simultaneously with queue tail drop.

     2.  ECN_Thrd MUST NOT fall below ECN_Floor, UNLESS the maximum
     physical buffer limit (Buf_Thrd) has itself fallen below ECN_Floor.

  6.  Operational Considerations

  6.1.  Update Synchronization

     ECN_Thrd MUST be inherently recomputed concurrently with any
     transition in Buf_Thrd.  Event-driven synchronization is highly
     RECOMMENDED over periodic polling.  Polling introduces phase-delay,
     leaving the ECN_Thrd stale during the most critical microsecond
     inflection points of transient congestion.  If atomic hardware
     updates are impossible, implementations SHOULD bias the asynchronous



  Yang, et al.            Expires 2 September 2026                [Page 7]


  Internet-Draft            Dynamic ECN Threshold               March 2026


     race condition to temporarily favor a lower ECN_Thrd (causing a
     premature mark) over a higher ECN_Thrd (causing an unnotified drop).

  6.2.  Tuning the Offset Parameter

     The Offset represents the network's required "shock absorber."
     Operators SHOULD calibrate the Offset to slightly exceed the expected
     Bandwidth-Delay Product (BDP) of the typical congestion control
     feedback loop:

     Offset ≈ Link_Rate * RTT

     In contemporary intra-data-center fabrics (RTT ~20-50 microseconds,
     400 Gbps links), Offset values ranging from 1 MB to 2.5 MB are
     operationally appropriate.  Oversizing the Offset prematurely
     throttles flows; undersizing it invites high tail-drop rates despite
     ECN capability.

  6.3.  Tuning the ECN_Floor Parameter

     ECN_Floor establishes the maximum throttling severity.  It MUST NOT
     be configured smaller than the Maximum Transmission Unit (MTU) of the
     link (e.g., 9000 bytes).  For environments executing Data Center TCP
     (DCTCP) [RFC8257], ECN_Floor SHOULD typically mirror the static
     thresholds recommended for shallow buffering (e.g., 30 KB to 100 KB),
     preventing the queue from emptying completely while maintaining
     ultra-low queuing delay.

  7.  Implementation Status

     [RFC Editor: Please remove this section before publication.]

     This section records the status of known implementations of the
     protocol defined by this specification at the time of posting of this
     Internet-Draft, and is based on a proposal described in RFC 7942.
     The description of implementations in this section is intended to
     assist the IETF in its decision processes in progressing drafts to
     RFCs.

     The dynamic ECN threshold coupling mechanism described in this
     document has been implemented and validated in the data plane of
     Centec Networks' switching silicon, specifically designed to mitigate
     micro-bursts and incast congestion in large-scale RDMA over Converged
     Ethernet (RoCEv2) deployments by China Mobile.







  Yang, et al.            Expires 2 September 2026                [Page 8]


  Internet-Draft            Dynamic ECN Threshold               March 2026


  8.  Related Work

     AQM recommendations generalized in [RFC7567] outline the complexities
     of parameter tuning.  While this document aligns with the intent of
     [RFC7567], it specifically isolates and resolves the intersection of
     AQM and dynamic shared buffering, a domain not fully explored in
     legacy AQM guidelines.

     The AI-based ECN approach proposed in
     [I-D.zhuang-tsvwg-ai-ecn-for-dcn] targets similar parameter
     adaptation via machine learning.  The framework in this document,
     conversely, advocates for a mathematically deterministic data-path
     calculation, demanding no training data, no external control-plane
     telemetry loop, and zero inference latency.

     TCP Alternative Backoff with ECN (ABE) [RFC8511] optimizes how
     endpoints react to CE marks.  ABE is strictly complementary; it
     refines the sender response, whereas this architecture ensures the
     network device generates those marks at structurally correct moments.

  9.  Security Considerations

     This specification introduces an automated internal parameter
     coupling within the network forwarding plane.  It does not exchange
     new protocol messages across the wire, thus introducing no new
     cryptographic or protocol-level attack surfaces.

     Operational Degradation via Misconfiguration: Invalid configuration
     of Offset or ECN_Floor can initiate self-inflicted Denial of Service
     (DoS) behaviors.  For instance, an immensely inflated Offset might
     universally push the system into Region C, effectively disabling
     early congestion warning.  Implementations SHOULD validate parameter
     inputs through management interfaces and emit warnings if Offset
     exceeds typical physical buffer allocations.

     Internal Signaling Integrity: The architectural dependency between
     the memory management unit (MMU) and the ECN marking engine requires
     deterministic internal signaling.  If the internal update of Buf_Thrd
     is delayed or corrupted under heavy system load, the ECN_Thrd
     calculation will be based on stale memory constraints, leading to
     temporary periods of over-marking or under-marking.  Hardware designs
     SHOULD prioritize this internal signaling path.

     Buffer Exhaustion Vectors: Malicious, non-responsive flows could
     intentionally occupy massive allocations of the shared buffer pool.
     In dynamic buffer architectures, this action compresses the Buf_Thrd
     for all other benign queues, plunging them into Region B or Region C.
     This is an inherent vulnerability of shared memory switches, not



  Yang, et al.            Expires 2 September 2026                [Page 9]


  Internet-Draft            Dynamic ECN Threshold               March 2026


     generated by this ECN algorithm.  Operators MUST utilize per-queue
     maximum caps, port-level QoS scheduling, and admission control to
     insulate queues from cross-traffic buffer starvation.

  10.  IANA Considerations

     This document has no IANA actions.

  11.  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/info/rfc2119>.

     [RFC3168]  Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
                of Explicit Congestion Notification (ECN) to IP",
                RFC 3168, DOI 10.17487/RFC3168, September 2001,
                <https://www.rfc-editor.org/info/rfc3168>.

     [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/info/rfc8174>.

  12.  Informative References

     [RFC7567]  Baker, F., Ed. and G. Fairhurst, Ed., "IETF
                Recommendations Regarding Active Queue Management",
                BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015,
                <https://www.rfc-editor.org/info/rfc7567>.

     [RFC8033]  Pan, R., Natarajan, P., Baker, F., and G. White,
                "Proportional Integral Controller Enhanced (PIE): A
                Lightweight Control Scheme to Address the Bufferbloat
                Problem", RFC 8033, DOI 10.17487/RFC8033, February 2017,
                <https://www.rfc-editor.org/info/rfc8033>.

     [RFC8257]  Bensley, S., Thaler, D., Balasubramanian, P., Eggert, L.,
                and G. Judd, "Data Center TCP (DCTCP): TCP Congestion
                Control for Data Centers", RFC 8257, DOI 10.17487/RFC8257,
                October 2017, <https://www.rfc-editor.org/info/rfc8257>.

     [RFC8289]  Nichols, K., Jacobson, V., McGregor, A., Ed., and J.
                Iyengar, Ed., "Controlled Delay Active Queue Management",
                RFC 8289, DOI 10.17487/RFC8289, January 2018,
                <https://www.rfc-editor.org/info/rfc8289>.





  Yang, et al.            Expires 2 September 2026               [Page 10]


  Internet-Draft            Dynamic ECN Threshold               March 2026


     [RFC8511]  Khademi, N., Welzl, M., Armitage, G., and G. Fairhurst,
                "TCP Alternative Backoff with ECN (ABE)", RFC 8511,
                DOI 10.17487/RFC8511, December 2018,
                <https://www.rfc-editor.org/info/rfc8511>.

     [RFC9330]  Briscoe, B., Ed., De Schepper, K., Bagnulo, M., and G.
                White, "Low Latency, Low Loss, and Scalable Throughput
                (L4S) Internet Service: Architecture", RFC 9330,
                DOI 10.17487/RFC9330, January 2023,
                <https://www.rfc-editor.org/info/rfc9330>.

     [RFC9331]  De Schepper, K. and B. Briscoe, Ed., "The Explicit
                Congestion Notification (ECN) Protocol for Low Latency,
                Low Loss, and Scalable Throughput (L4S)", RFC 9331,
                DOI 10.17487/RFC9331, January 2023,
                <https://www.rfc-editor.org/info/rfc9331>.

     [I-D.zhuang-tsvwg-ai-ecn-for-dcn]
                Zhuang, Y., Zhang, B., and H. Pan, "Artificial
                Intelligence (AI) based ECN adaptive reconfiguration for
                datacenter networks", Work in Progress, Internet-Draft,
                draft-zhuang-tsvwg-ai-ecn-for-dcn-00, October 2019,
                <https://datatracker.ietf.org/doc/draft-zhuang-tsvwg-ai-
                ecn-for-dcn/>.

     [I-D.ietf-tsvwg-aqm-dualq-coupled]
                De Schepper, K. and B. Briscoe, Ed., "DualQ Coupled AQMs
                for Low Latency, Low Loss and Scalable Throughput (L4S)",
                Work in Progress, Internet-Draft, draft-ietf-tsvwg-aqm-
                dualq-coupled-24, 2024, <https://datatracker.ietf.org/doc/
                draft-ietf-tsvwg-aqm-dualq-coupled/>.

  Authors' Addresses

     Jin Yang
     China Mobile
     Beijing
     100053
     China
     Email: yangjinwl@chinamobile.com


     Weiqiang Cheng
     China Mobile
     Beijing
     100053
     China
     Email: chengweiqiang@chinamobile.com



  Yang, et al.            Expires 2 September 2026               [Page 11]


  Internet-Draft            Dynamic ECN Threshold               March 2026


     Yuchi Tian
     China Mobile
     Beijing
     100053
     China
     Email: tianyuchi@chinamobile.com


     Junjie Wang
     Centec
     Suzhou
     215000
     China
     Email: wangjj@centec.com


     Guoying Zhang
     Centec
     Suzhou
     215000
     China
     Email: zhanggy@centec.com





























  Yang, et al.            Expires 2 September 2026               [Page 12]


name: w3c-web-user-agents
rev: 00
title: Web User Agents
time: 20260120
states: []
categories: ["Policy/governance", "Human-agent interaction"]
tags: []
fetched_at: 2026-03-04T00:09:05.823046+00:00
source: ietf
abstract:
  Web user agents include both web browsers and other intermediaries between end-users and the web. Each user agent serves its user, not any of the other constituencies. A user agent owes its user various duties, which should be established through collective discussions and embodied in the various standards that user agents implement.

full_text:
  Web User Agents Web User Agents Editor’s Draft , 20 January 2026 More details about this document This version: https://w3ctag.github.io/user-agents Latest published version: https://www.w3.org/TR/web-user-agents/ Feedback: GitHub Editors: Jeffrey Yasskin ( Google ) Sarven Capadisli ( Invited Expert ) Copyright © 2026 World Wide Web Consortium . W3C ® liability , trademark and permissive document license rules apply. Abstract Web user agents include both web browsers and other intermediaries between end-users and the web. Each user agent serves its user, not any of the other constituencies. A user agent owes its user various duties, which should be established through collective discussions and embodied in the various standards that user agents implement. Status of this document This section describes the status of this document at the time of its publication. A list of current W3C publications and the latest revision of this technical report can be found in the W3C standards and drafts index . This document was published by the Technical Architecture Group as an Editor’s Draft intended for the Note track. This is a draft document and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to cite this document as other than a work in progress. Editor’s Drafts are not endorsed by W3C nor its Members. Feedback and comments on this document are welcome. Please file an issue in this document’s GitHub repository . The W3C Patent Policy does not carry any licensing requirements or commitments on this document. This document is governed by the 18 August 2025 W3C Process Document . Table of Contents 1 Audience 2 What is a web user agent 2.1 User agents as software components 3 Duties of user agents 3.1 Protection 3.2 Honesty 3.3 Loyalty 4 Acknowledgements Index Terms defined by this specification Terms defined by reference References Normative References Informative References 1. Audience This document is intended for: Technical authors who want to reuse or reference these concepts in their own specifications or documentation. User agent developers who want to align implementations with design and privacy principles that prioritize their users. Web developers who want to understand why user agents prioritize user privacy and security over other constituencies, including developer convenience. Regulators and policymakers who seek to understand the duties, principles, and expectations guiding user agent behavior. 2. What is a web user agent A user agent , in general, is any software entity that interacts with other entities on behalf of its user. User agents include many operating systems; email clients; PDF, ebook, and image viewers; credential managers , including digital wallets; and many other kinds of software. A web user agent is any software entity that interacts with websites outside the entity itself, on behalf of its user, including simply rendering the content of websites. In web specifications and the rest of this document, web user agents are usually referred to as just " user agents ". Either fully-qualified term can be used if there’s a chance of confusion. A person can use many different user agents in their day-to-day life. The most common type of web user agent is the web browser, including in-app browsers that can follow cross-site links. However, user agents also include other tools like search engines, voice-driven assistants, and generative AI systems that present snippets or summaries of website content, or help people navigate and interact with websites. User agent behavior is not completely defined by web standards or even by technical specifications in general. In particular, user agents choose which specifications to implement in order to best serve their users, and they implement proprietary user interfaces and other behavior around the specifications they do implement. 2.1. User agents as software components As software components, user agents can be parts of larger applications and can call libraries that implement the web platform or parts of it. When an application makes a clear distinction between its pieces that are user agents and its pieces that aren’t, then only the user agent parts, which browse content from outside the user agent itself, need to follow the user agent duties . Parts that are clearly only showing the application’s own content can act on their own behalf, but the application should still give its users clear expectations about what behavior they should expect from different parts of the application. If the distinction between internal and external content is too small—for example if the application doesn’t show an address bar or another indicator of content origin when browsing external content—then the application should also follow the user agent duties when showing its own content. Similarly a library that implements the web platform may or may not be a full user agent . Some, like SFSafariViewController and Android Custom Tabs take on the responsibility of implementing the user agent duties and of clearly distinguishing between the external content they browse and the content controlled by the embedding application. These libraries are user agents . Other libraries, like the Android , iOS , and Windows WebView libraries, are designed to support many kinds of applications. Because some of these applications include only their own content, WebView libraries are not meant to be user agents on their own, and they do not implement the user agent duties . Ultimately, an embedding application is responsible for following the user agent duties if it, or any part of it, acts as a user agent . This can be straightforward if the application only browses external content through a user agent library. Developers need to take extra care to follow the user agent duties when using a non- user agent WebView to implement an in-app browser . 3. Duties of user agents Each user agent serves its user ( The Internet is for End Users ), not any of the other constituencies. A user agent owes its user various duties , which should be established through collective discussions and embodied in the various standards that user agents implement. 3.1. Protection It should be safe to visit a web page. Visiting a page must not by itself let the page change the user’s computer or environment, such as by installing software or accessing hardware. Any data revealed to sites or other observers should be aligned with the user’s preferences and follow the principle of data minimization . In particular, user agents must act to limit the potential for sites to track user activity [unsanctioned-tracking] . Users may choose to share more information , such as by filling out forms or granting permissions. Even then, user agents must help users avoid deception and clearly signal when a page attempts to gain elevated access. Access to local files or other sensitive resources must be limited to clear, intentional user actions, with appropriate warnings. EXAMPLE: Attacks User agents need to prevent malicious code on a site from being able to escape the user agent to modify the user’s computer or access other origins . User agents meet this duty of protection by sandboxing components, using memory-safe languages, and employing security teams to find and respond to vulnerabilities. These defenses need to evolve continuously to address new threats. EXAMPLE: Tracking If a person visits unrelated websites, it’s feasible to avoid sending a shared identifying cookie to embedded iframes. A browser that does send such a cookie is failing its duty of protection. However, revealing a stable IP address is currently unavoidable, so it’s not a violation. EXAMPLE: Local Files User agents are expected to prevent pages from accessing local files unless the user explicitly selects or opens one. This motivates behaviors like: giving each file: URL its own origin , removing path components from <input type=file> uploads, and restricting which local fonts can be used in @font-face rules. However, users can still choose to share files, e.g., via uploads or downloads. APIs like File System Access don’t violate this duty, provided users have the tools to make good decisions . 3.2. Honesty A user agent must mediate between the Web and its user, explaining what is happening in a form the user can understand. A user agent may use multiple approaches for explanations, including text, permission prompts, indicators, previews, and other interface elements. Consider the placement of these elements and whether anything needs emphasis. A quintessential example is user agents indicating if a website was served over an encrypted connection. This has evolved over time, from insecure sites being shown with a broken lock icon, to some user agents explicitly including the text "not secure" in the URL bar. Specifications, like the Media Capture and Streams , include Privacy Indicator Requirements that require user agents to explain some specific kinds of website behavior, but user agents should also use the same techniques when users need to know about other behavior, even if a specification doesn’t specifically call out that behavior. An honest user agent actively works to present the truth to its user. It doesn’t just avoid lies. Its explanations should clearly represent the current state and likely consequences, avoid euphemism or ambiguity, and make it obvious when sensitive activity is occurring. The user agent should choose when and how often to show these explanations, so explanations arrive when helpful and inform rather than distract. The user agent should ensure the user can control if and when they make a decision. 3.3. Loyalty A user agent must serve its user’s interests over its implementer’s interests and over the interests of any other party. A user agent can be loyal while also collecting payment for its services, as long as that payment is fair and was agreed ahead of time. A user agent can also help its user make a credible commitment to a page in order to get that page’s services, and it’s not disloyal to maintain that commitment after getting the services. A user agent must not obstruct its users from switching to another user agent. For example, it must not block access to, export, or store user data in ways that prevent portability. This includes identity information, bookmarks, history, passwords, and credentials such as passkeys. If the user agent relies on the underlying OS to store credentials, there needs to be a way for users to allow other user agents to access those credentials. 4. Acknowledgements Thanks to the Infra Standard for an earlier definition of User Agents and to Privacy Principles for the initial version of these duties. Index Terms defined by this specification general user agent , in § 2 UA duties , in § 3 user agent , in § 2 user agent duties , in § 3 web user agent , in § 2 Terms defined by reference [CREDENTIAL-MANAGEMENT-1] defines the following terms: credential manager [CSS-FONTS-5] defines the following terms: @font-face [HTML] defines the following terms: File Upload origin [URL] defines the following terms: origin References Normative References [CREDENTIAL-MANAGEMENT-1] Nina Satragno; Marcos Caceres. Credential Management Level 1 . URL: https://w3c.github.io/webappsec-credential-management/ [DESIGN-PRINCIPLES] Martin Thomson; Jeffrey Yasskin. Web Platform Design Principles . URL: https://w3ctag.github.io/design-principles/ [MEDIACAPTURE-STREAMS] Cullen Jennings; et al. Media Capture and Streams . URL: https://w3c.github.io/mediacapture-main/ [RFC8890] M. Nottingham. The Internet is for End Users . August 2020. Informational. URL: https://www.rfc-editor.org/rfc/rfc8890 Informative References [CSS-FONTS-5] Chris Lilley. CSS Fonts Module Level 5 . URL: https://drafts.csswg.org/css-fonts-5/ [FILE-SYSTEM-ACCESS] File System Access . Draft Community Group Report. URL: https://wicg.github.io/file-system-access/ [HTML] Anne van Kesteren; et al. HTML Standard . Living Standard. URL: https://html.spec.whatwg.org/multipage/ [Infra] Anne van Kesteren; Domenic Denicola. Infra Standard . Living Standard. URL: https://infra.spec.whatwg.org/ [PRIVACY-PRINCIPLES] Robin Berjon; Jeffrey Yasskin. Privacy Principles . URL: https://w3ctag.github.io/privacy-principles/ [UNSANCTIONED-TRACKING] Mark Nottingham. Unsanctioned Web Tracking . 17 July 2015. TAG Finding. URL: http://www.w3.org/2001/tag/doc/unsanctioned-tracking/ [URL] Anne van Kesteren. URL Standard . Living Standard. URL: https://url.spec.whatwg.org/


