| |
|
| |
| | CDDL Module Structure |
| |
| | draft-ietf-cbor-cddl-modules-05.txt |
| | Date: |
30/08/2025 |
| | Authors: |
Carsten Bormann, Brendan Moran |
| | Working Group: |
Concise Binary Object Representation Maintenance and Extensions (cbor) |
|
At the time of writing, the Concise Data Definition Language (CDDL) is defined by RFC 8610 and RFC 9682 as well as RFC 9165 and RFC 9741. The latter two have used the extension point provided in RFC 8610, the _control operator_. As CDDL is being used in larger projects, the need for features has become known that cannot be easily mapped into this single extension point. The present document defines a backward- and forward-compatible way to add a module structure to CDDL. |
| | A feature freezer for the Concise Data Definition Language (CDDL) |
| |
|
In defining the Concise Data Definition Language (CDDL), some features have turned up that would be nice to have. In the interest of completing this specification in a timely manner, the present document was started to collect nice-to-have features that did not make it into the first RFC for CDDL, RFC 8610, or the specifications exercising its extension points, such as RFC 9165. Significant parts of this draft have now moved over to the CDDL 2.0 project, described in draft-bormann-cbor-cddl-2-draft. The remaining items in this draft are not directly related to the CDDL 2.0 effort. |
| | Modern Network Unicode |
| |
|
BCP18 (RFC 2277) has been the basis for the handling of character- shaped data in IETF specifications for more than a quarter of a century now. It singles out UTF-8 (STD63, RFC 3629) as the “charset” that MUST be supported, and pulls in the Unicode standard with that. Based on this, RFC 5198 both defines common conventions for the use of Unicode in network protocols and caters for the specific requirements of the legacy protocol Telnet. In applications that do not need Telnet compatibility, some of the decisions of RFC 5198 can be cumbersome. The present specification defines “Modern Network Unicode” (MNU), which is a form of RFC 5198 Network Unicode that can be used in specifications that require the exchange of plain text over networks and where just mandating UTF-8 may not be sufficient, but there is also no desire to import all of the baggage of RFC 5198. As characters are used in different environments, MNU is defined in a one-dimensional (1D) variant that is useful for identifiers and labels, but does not use a structure of text lines. A 2D variant is defined for text that is a sequence of text lines, such as plain text documents or markdown format. Additional variances of these two base formats can be used to tailor MNU to specific areas of application. |
| | Using CDDL for CSVs |
| |
|
The Concise Data Definition Language (CDDL), standardized in RFC 8610, is defined to provide data models for data shaped like JSON or CBOR. Another representation format that is quote popular is the CSV (Comma-Separated Values) file as defined by RFC 4180. The present document shows a way how to use CDDL to provide a data model for CSV files. |
| | CDDL 2.0 and beyond -- a draft plan |
| |
|
The Concise Data Definition Language (CDDL) today is defined by RFC 8610, RFC 9165, RFC 9682, and RFC\ 9741). RFC 9165 and the latter (as well as some more application specific specifications such as RFC 9090) have used the extension point provided in RFC 8610, the control operator. As CDDL is used in larger projects, feature requirements become known that cannot be easily mapped into this single extension point. Hence, there is a need for evolution of the base CDDL specification itself. The present document provides a roadmap towards a "CDDL 2.0"; it is intended to serve as a basis for implementations that evolve with the concept of CDDL 2.0. It is based on draft-bormann-cbor-cddl-freezer, but is more selective in what potential features it takes up and more detailed in their discussion. This document is intended to evolve over time; it might spawn specific documents and then retire, or it might eventually be published as a roadmap document. |
| | The "dereferenceable identifier" pattern |
| |
|
In a protocol or an application environment, it is often important to be able to create unambiguous identifiers for some meaning (concept or some entity). Due to the simplicity of creating URIs, these have become popular for this purpose. Beyond the purpose of identifiers to be uniquely associated with a meaning, some of these URIs are in principle _dereferenceable_, so something can be placed that can be retrieved when encountering such a URI. |
| | Stand-in Tags for YANG-CBOR |
| |
|
YANG (RFC 7950) is a data modeling language used to model configuration data, state data, parameters and results of Remote Procedure Call (RPC) operations or actions, and notifications. YANG-CBOR (RFC 9254) defines encoding rules for YANG in the Concise Binary Object Representation (CBOR) (RFC 8949). While the overall structure of YANG-CBOR is encoded in an efficient, binary format, YANG itself has its roots in XML and therefore traditionally encodes some information such as date/times and IP addresses/prefixes in a verbose text form. This document defines how to use existing CBOR tags for this kind of information in YANG-CBOR as a "stand-in" for the text-based information that would be found in the original form of YANG-CBOR. |
| | Representing metadata annotations in YANG-CBOR |
| |
|
This specification defines the representation of metadata annotations (RFC 7952) in YANG-CBOR (RFC 9254). |
| | PCAP Now Generic (pcapng) Capture File Format |
| |
| | draft-ietf-opsawg-pcapng-04.txt |
| | Date: |
30/08/2025 |
| | Authors: |
Michael Tuexen, Fulvio Risso, Jasper Bongertz, Gerald Combs, Guy Harris, Eelco Chaudron, Michael Richardson |
| | Working Group: |
Operations and Management Area Working Group (opsawg) |
|
This document describes a format to record captured packets to a file. This format is extensible; Wireshark can currently read and write it, and libpcap can currently read some pcapng files. |
| |
|
| |
| | YANG Data Models for requesting Path Computation in WDM Optical Networks |
| |
|
This document provides a mechanism to request path computation in Wavelength-Division Multiplexing (WDM) optical networks composed of Wavelength Switched Optical Networks (WSON) and Flexi-Grid Dense Wavelength Division Multiplexing (DWDM) switched technologies. This model augments the Remote Procedure Calls (RPCs) defined in RFC YYYY. [RFC EDITOR NOTE: Please replace RFC YYYY with the RFC number of draft-ietf-teas-yang-path-computation once it has been published. |
| | COSE Header parameter for RFC 3161 Time-Stamp Tokens |
| |
|
This document defines two CBOR Signing And Encrypted (COSE) header parameters for incorporating RFC 3161-based timestamping into COSE message structures (COSE_Sign and COSE_Sign1). This enables the use of established RFC 3161 timestamping infrastructure in COSE-based protocols. |
| | Report from the IAB Workshop on the Next Era of Network Management Operations (NEMOPS) |
| |
|
The "Next Era of Network Management Operations (NEMOPS)" workshop was convened by the Internet Architecture Board (IAB) from December 3-5, 2024, as a three-day online meeting. It builds on a previous 2002 workshop, the outcome of which was documented in RFC 3535, identifying 14 operator requirements for consideration in future network management protocol design and related data models, along with some recommendations for the IETF. Much has changed in the Internet’s operation and technological foundations since then. The NEMOPS workshop reviewed the past outcomes and discussed any operational barriers that prevented these technologies from being widely implemented. With the industry, network operators and protocol engineers working in collaboration, the workshop developed a suggested plan of action and network management recommendations for the IETF and IRTF. Building on RFC 3535, this document provides the report of the follow-up IAB workshop on Network Management. Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect IAB views and positions. |
| | Alternate Marking Deployment Framework |
| |
|
This document provides a framework for Alternate Marking deployment and includes considerations and guidance for the deployment of the methodology. |
| | A YANG Data Model for Client Signal Performance Monitoring |
| |
|
A transport network is a server-layer network to provide connectivity services to its client. Given the client signal is configured, the followup function for performance monitoring, such as latency and bit error rate, would be needed for network operation. This document describes the data model to support the performance monitoring functionalities. |
| | CDDL models for some existing RFCs |
| |
|
A number of CBOR- and JSON-based protocols have been defined before CDDL was standardized or widely used. This short draft records some CDDL definitions for such protocols, which could become part of a library of CDDL definitions available for use in CDDL2 processors. It focuses on CDDL in (almost) published IETF RFCs. |
| | Current Process for Handling RFC Errata Reports |
| |
|
This document describes the current web-based process for handling the submission, verification, and posting of errata for the RFC Series. The main concepts behind this process are (1) distributing the responsibility for verification to the appropriate organization or person for each RFC stream, and (2) using a Web portal to automate the processing of erratum reports. This system was launched in November 2007. This draft documents the existing system as a means to facilitate discussion to revamp how errata are reported, reviewed, and publicized. |
| | Commercial National Security Algorithm Suite Certificate and Certificate Revocation List Profile |
| |
|
This document specifies a profile of X.509 v3 Certificates and X.509 v2 Certificate Revocation Lists for applications that use Commercial National Security Algorithm Suite published by the United States Government. The profile applies to the capabilities, configuration, and operation of all components of US National Security Systems that employ such X.509 certificates. US National Security Systems are described in NIST Special Publication 800-59. It is also appropriate for all other US Government systems that process high-value information. This memo is not an IETF standard, and does not represent IETF community consensus. The profile is made publicly available for use by developers and operators of these and any other system deployments. |
| | Commercial National Security Algorithm (CNSA) Suite Profile for TLS 1.3 |
| |
|
This document defines a base profile of TLS 1.3 for use with the US Commercial National Security Algorithm (CNSA) 2.0 Suite, a cybersecurity advisory published by the United States Government which outlines quantum-resistant cryptographic algorithm policy for US national security applications. This profile applies to the capabilities, configuration, and operation of all components of US National Security Systems that employ TLS 1.3. It is also appropriate for all other US Government systems that process high-value information. This memo is not an IETF standard, and has not been shown to have IETF community consensus. This profile is made publicly available for use by developers and operators of these and any other system deployments. |
| | The IMAP WEBPUSH extension |
| |
|
This document defines a WEBPUSH extension of the Internet Message Access Protocol (IMAP) that permits IMAP servers to send WebPush notifications. |
| | Considerations of Gradual IPv6-only Deployment in 5G Mobile Networks |
| |
|
This document describes the approach of gradually deploying 464XLAT based IPv6-only technology on user plane in 3GPP 5G networks. It also discusses the challenges and potential solutions. |
| | Commercial National Security Algorithm (CNSA) Suite 2.0 Profile for IPsec |
| |
|
This document defines a base profile for IPsec for use with the US Commercial National Security Algorithm (CNSA) 2.0 Suite, a cybersecurity advisory that outlines quantum-resistant cryptographic algorithm policy for national security applications. This profile applies to the capabilities, configuration, and operation of all components of US National Security Systems that employ IPsec. It is also appropriate for all other US Government systems that process high-value information. This memo is not an IETF standard, and has not been shown to have IETF community consensus. This profile is made publicly available for use by developers and operators of these and any other system deployments. |
| | Commercial National Security Algorithm (CNSA) Suite Profile for SSH |
| |
|
This document defines a base profile of SSH for use with the US Commercial National Security Algorithm (CNSA) 2.0 Suite, a cybersecurity advisory published by the United States Government which outlines quantum-resistant cryptographic algorithm policy for US national security applications. This profile applies to the capabilities, configuration, and operation of all components of US National Security Systems that employ SSH. It is also appropriate for all other U.S. Government systems that process high-value information. This memo is not an IETF standard, and has not been shown to have IETF community consensus. This profile is made publicly available for use by developers and operators of these and any other system deployments. |
| | Commercial National Security Algorithm (CNSA) Suite Profile for Secure/Multipurpose Internet Mail Extensions (S/MIME) |
| |
|
This document defines a base profile of S/MIME for use with the US Commercial National Security Algorithm (CNSA) 2.0 Suite, a cybersecurity advisory published by the United States Government which outlines quantum-resistant cryptographic algorithm policy for US national security applications. This profile applies to the capabilities, configuration, and operation of all components of US National Security Systems that employ S/MIME. It is also appropriate for all other US Government systems that process high-value information. This memo is not an IETF standard, and has not been shown to have IETF community consensus. This profile is made publicly available for use by developers and operators of these and any other system deployments. |
| | Commercial National Security Algorithm (CNSA) Suite Profile of Certificate Management over CMS |
| |
|
This document specifies a profile of the Certificate Management over CMS (CMC) protocol for managing X.509 public key certificates in applications that use the Commercial National Security Algorithm (CNSA) Suite published by the United States Government. The profile applies to the capabilities, configuration, and operation of all components of US National Security Systems that manage X.509 public key certificates over CMS. It is also appropriate for all other US Government systems that process high-value information. This memo is not an IETF standard, and does not represent IETF community consensus. The profile is made publicly available here for use by developers and operators of these and any other system deployments. |
| | Updates to DNS64 Functionality Advertisement for DNS RA Option |
| |
|
This document defines a new flag in the DNS RA Option to advertise the DNS64 functionality. This extension enables automatic configuration of DNS64 resolution, improving deployability in IPv6 transition scenarios. |
| | TLS Key Share Prediction |
| |
|
This document defines a mechanism for servers to communicate key share preferences in DNS. Clients may use this information to reduce TLS handshake round-trips. |
| |
|
| |
| | Key Management for Group Object Security for Constrained RESTful Environments (Group OSCORE) Using Authentication and Authorization for Constrained Environments (ACE) |
| |
|
This document defines an application profile of the Authentication and Authorization for Constrained Environments (ACE) framework, to request and provision keying material in group communication scenarios that are based on the Constrained Application Protocol (CoAP) and are secured with Group Object Security for Constrained RESTful Environments (Group OSCORE). This application profile delegates the authentication and authorization of Clients, which join an OSCORE group through a Resource Server acting as Group Manager for that group. This application profile leverages protocol-specific transport profiles of ACE to achieve communication security, server authentication, and proof of possession for a key owned by the Client and bound to an OAuth 2.0 access token. |
| | IPv4 routes with an IPv6 next hop |
| |
|
This document proposes "v4-via-v6" routing, a technique that uses IPv6 next-hop addresses for routing IPv4 packets, thus making it possible to route IPv4 packets across a network where routers have not been assigned IPv4 addresses. The document both describes the technique, as well as discussing its operational implications. |
| | Updated Use of the Expires Message Header Field |
| |
|
This document allows broader use of the Expires message header field for mail messages. Message creators can then indicate when a message expires, while recipients would use this information to handle an expired message differently. |
| | Enhancing Route Origin Validation by Aggregating Validated ROA Payloads |
| |
|
Resource Public Key Infrastructure (RPKI) enables address space holders to issue Route Origin Authorization (ROA) objects to authorize one or more Autonomous Systems (ASes) to originate BGP routes for specific IP address prefixes. Individual BGP speakers can utilize Validated ROA Payloads (VRPs) to validate the legitimacy of BGP announcements. This document highlights potential validation errors, and recommends extension of VRPs from reasonable aggregation to enhance Route Origin Validation (ROV) and prevent validation errors that may occur due to traffic engineering or route aggregation policies. |
| | IOAM Trace Option Extensions for Incorporating the Alternate-Marking Method |
| |
|
In situ Operation, Administration, and Maintenance (IOAM) is used for recording and collecting operational and telemetry information. Specifically, passport-based IOAM allows telemetry data generated by each node along the path to be pushed into data packets when they traverse the network, while postcard-based IOAM allows IOAM data generated by each node to be directly exported without being pushed into in-flight data packets. This document extends IOAM Trace Option for incorporating the Alternate-Marking Method. |
| | RPKI Repository Problem Statement and Analysis |
| |
|
With the increasing deployment of Route Origin Authorizations (ROAs) and Route Origin Validation (ROV), the Resource Public Key Infrastructure (RPKI) has become a critical component for securing inter-domain routing. RPKI leverages cryptographic certificates to validate the authenticity and authorization of IP address and AS number allocations. All RPKI objects are stored in distributed repositories and periodically retrieved by relying parties (RPs). This document presents a data-driven analysis of the current RPKI repository system, including a global survey of AS administrators and an empirical evaluation of repository operations. The analysis reveals that the existing repository architecture suffers from limited scalability and suboptimal efficiency, and is highly sensitive to failures. As the number of ROAs and RPs increases, the growing number of point-to-point connections between repositories and RPs, coupled with the pull-based data synchronization model, significantly degrades the system's scalability and performance. Moreover, a failure or attack on any Publication Point (PP) can prevent RPs from obtaining a complete and up-to-date view of RPKI data. This document further outlines the fundamental requirements for building a scalable, resilient,and efficient RPKI repository architecture to address these limitations. |
| | IOAM Direct Exporting (DEX) Option Extensions for Incorporating the Alternate-Marking Method |
| |
|
In situ Operations, Administration, and Maintenance (IOAM) is used for recording and collecting operational and telemetry information. Specifically, passport-based IOAM allows telemetry data generated by each node along the path to be pushed into data packets when they traverse the network, while postcard-based IOAM allows IOAM data generated by each node to be directly exported without being pushed into in-flight data packets. This document extends IOAM Direct Export (DEX) Option-Type to integrate the Alternate-Marking Method into IOAM. |
| | A Generic Framework for Building Dynamic Decentralized Systems (GFDS) |
| |
| | draft-jesus-gfds-01.txt |
| | Date: |
28/08/2025 |
| | Authors: |
Diogo Jesus, Joao Leitao |
| | Working Group: |
Individual Submissions (none) |
|
Building and managing highly dynamic and heterogeneous decentralized systems can prove to be quite challenging due to the great complexity and scale of such environments. This document specifies a Generic Framework for Building Dynamic Decentralized Systems (GFDS), which composes a reference architecture and execution model for developing and managing these systems, while providing high-level abstractions to users. |
| | Host key update mechanism for SSH |
| |
|
This document describes an extension to allow a Secure Shell (SSH) server to inform a client of the full set of host keys it supports. This may be used for graceful host key rotation and to provide keys for additional signature algorithms to the client, supporting algorithm agility. |
| |
|
| |
| | Application of the Alternate Marking Method to the Segment Routing Header |
| |
| | draft-fz-spring-srv6-alt-mark-17.txt |
| | Date: |
27/08/2025 |
| | Authors: |
Giuseppe Fioccola, Tianran Zhou, Gyan Mishra, xuewei wang, Geng Zhang, Mauro Cociglio |
| | Working Group: |
Individual Submissions (none) |
|
This document describes an alternative experimental approach for the application of the Alternate-Marking Method to SRv6. It uses an experimental TLV in the Segment Routing Header, and thus participation in this experiment should be between coordinating parties in a controlled domain. This approach has potential scaling and simplification benefits over the technique described in RFC 9343 and the scope of the experiment is to determine whether those are significant and attractive to the community. This protocol extension has been developed outside the IETF as an alternative to the IETF's standards track specification RFC 9343 and it does not have IETF consensus. It is published here to guide experimental implementation, ensure interoperability among implementations to better determine the value of this approach. Researchers are invited to submit their evaluations of this work to the RFC Editor for consideration as independent submissions or to the IETF SPRING working group as Internet-Drafts. |
| | Mutually Authenticating TLS in the context of Federations |
| |
| | draft-halen-fedae-03.txt |
| | Date: |
27/08/2025 |
| | Authors: |
Stefan Halen, Jakob Schlyter |
| | Working Group: |
Individual Submissions (none) |
|
This informational independent submission to the RFC series describes a means to use TLS 1.3 to perform machine-to-machine mutual authentication within federations. This memo is not a standard. It does not modify the TLS protocol in any way, nor does it require changes to common TLS libraries. TLS is specified and standardized by the IETF's TLS working group. The framework enables interoperable trust management for federated machine-to-machine communication. It introduces a centrally managed trust anchor and a controlled metadata publication process, ensuring that only authorized members are identifiable within the federation. These mechanisms support unambiguous entity identification and reduce the risk of impersonation, promoting secure and policy-aligned interaction across organizational boundaries. |
| | MANET Internetworking: Problem Statement and Gap Analysis |
| |
|
[RFC2501] defines a MANET as "an autonomous system of mobile nodes. The system may operate in isolation, or may have gateways to and interface with a fixed network" (such as the global public Internet). This document presents a MANET Internetworking problem statement and gap analysis. |
| | Path Computation Element Communication Protocol (PCEP) Extensions for Associated Bidirectional Segment Routing (SR) Paths |
| |
|
The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Clients (PCCs) requests. Segment routing (SR) leverages the source routing and tunneling paradigms. The Stateful PCEP extensions allow stateful control of Segment Routing Traffic Engineering (TE) Paths. Furthermore, PCEP can be used for computing SR TE paths in the network. This document defines PCEP extensions for grouping two unidirectional SR Paths (one in each direction in the network) into a single associated bidirectional SR Path. The mechanisms defined in this document can also be applied using a stateful PCE for both PCE- initiated and PCC-initiated LSPs or when using a stateless PCE. |
| | QUIC-LB: Generating Routable QUIC Connection IDs |
| |
|
QUIC address migration allows clients to change their IP address while maintaining connection state. To reduce the ability of an observer to link two IP addresses, clients and servers use new connection IDs when they communicate via different client addresses. This poses a problem for traditional "layer-4" load balancers that route packets via the IP address and port 4-tuple. This specification provides a standardized means of securely encoding routing information in the server's connection IDs so that a properly configured load balancer can route packets with migrated addresses correctly. As it proposes a structured connection ID format, it also provides a means of connection IDs self-encoding their length to aid some hardware offloads. |
| | Deprecating Insecure Practices in RADIUS |
| |
|
RADIUS crypto-agility was first mandated as future work by RFC 6421. The outcome of that work was the publication of RADIUS over TLS (RFC 6614) and RADIUS over DTLS (RFC 7360) as experimental documents. Those transport protocols have been in wide-spread use for many years in a wide range of networks. They have proven their utility as replacements for the previous UDP (RFC 2865) and TCP (RFC 6613) transports. With that knowledge, the continued use of insecure transports for RADIUS has serious and negative implications for privacy and security. The publication of the "BlastRADIUS" exploit has also shown that RADIUS security needs to be updated. It is no longer acceptable for RADIUS to rely on MD5 for security. It is no longer acceptable to send device or location information in clear text across the wider Internet. This document therefore deprecates many insecure practices in RADIUS, and mandates support for secure TLS-based transport layers. We also discuss related security issues with RADIUS, and give recommendations for practices which increase both security and privacy. |
| | Reverse Change-of-Authorization (CoA) in RADIUS/(D)TLS |
| |
|
This document defines a "reverse Change-of-Authorization (CoA)" path for RADIUS packets. A TLS connection is normally used to forward request packets from a client to a server and to send responses from the server to the client. This specification allows a server to send CoA request packets to the client in "reverse" down that connection, and for the client to send responses to the server. Without this capability, it is in general impossible for a server to send CoA packets to a Network Access Server (NAS) that is located behind a firewall or NAT. This reverse CoA functionality extends the available transport methods for CoA packets, but it does not change anything else about how CoA packets are handled. This document updates RFC8559. |
| |
|
| |
| | BIER BFD |
| |
| | draft-ietf-bier-bfd-09.txt |
| | Date: |
25/08/2025 |
| | Authors: |
Quan Xiong, Greg Mirsky, fangwei hu, Chang Liu, Gyan Mishra |
| | Working Group: |
Bit Indexed Explicit Replication (bier) |
|
Point to multipoint (P2MP) BFD is designed to verify multipoint connectivity. This document specifies the application of P2MP BFD in BIER network. |
| | Supporting BIER in IPv6 Networks (BIERin6) |
| |
| | draft-ietf-bier-bierin6-12.txt |
| | Date: |
25/08/2025 |
| | Authors: |
Zheng Zhang, Zhaohui Zhang, IJsbrand Wijnands, Mankamana Mishra, Hooman Bidgoli, Gyan Mishra |
| | Working Group: |
Bit Indexed Explicit Replication (bier) |
|
BIER is a multicast forwarding architecture that does not require per-flow state inside the network yet still provides optimal replication. This document describes how the existing BIER encapsulation specified in RFC 8296 works in a non-MPLS IPv6 network, which is referred to as BIERin6. Specifically, like in an IPv4 network, BIER can work over L2 links directly or over tunnels. In case of IPv6 tunneling, a new IP "Next Header" type is to be assigned for BIER. |
| | CDNI Protected Secrets Metadata |
| |
|
This document defines a simple mechanism for protected secret data (such as salt values or encryption keys) that may be embedded in configuration metadata or capabilities advertisements. |
| | CDNI Client Access Control Metadata |
| |
|
This specification adds to the basic client access control metadata in RFC8006, providing content providers and upstream content delivery networks (uCDNs) extended capabilities in defining location and time window restrictions. Support is also provided to define required Transport Layer Security (TLS) certificates and encryption levels. The specification also defines configuration metadata for the Common Access Token (CAT), developed jointly by the Streaming Video Technology Alliance (SVTA) and Consumer Technology Association Web Application Video Ecosystem (CTA-WAVE). |
| | BMP Extension for Path Status TLV |
| |
|
The BGP Monitoring Protocol (BMP) provides an interface for obtaining BGP path information, which is is conveyed through BMP Route Monitoring (RM) messages. This document specifies a BMP extension to convey the status of a path after being processed by the BGP process. |
| | A Connectivity Monitoring Metric for IPPM |
| |
|
Within a Segment Routing domain, segment routed measurement packets can be sent along pre-determined paths. This enables new kinds of measurements. Connectivity monitoring allows to supervise the state and performance of a connection or a (sub)path from one or a few central monitoring systems. This document specifies a suitable type-P connectivity monitoring metric. |
| | CDNI Metadata Expression Language |
| |
|
This document specifies the syntax and provides usage examples for an expression language to be used within Content Delivery Network Interconnection (CDNI) Metadata Interface (MI) objects. The purpose of this expression language is to enable metadata to be applied conditionally (based on aspects of an HTTP request), and to enable Hypertext Transfer Protocol (HTTP) responses to be generated or altered dynamically. |
| | CDNI Processing Stages Metadata |
| |
|
This document specifies a set of objects extending the Content Delivery Network Interconnection (CDNI) metadata model to allow for metadata to be applied conditionally and at various points in a dCDNs processing of requests. The concept of Processing Stages are introduced, where each stage in a CDN's processing pipeline presents an opportunity to examine requests and responses and make alterations as needed. Metadata, such as caching rules, can be applied conditionally (based on aspects of an HTTP request header), and HTTP responses from a source can be altered dynamically (such as adding or dropping an HTTP header). This standard leverages the expression language documented in the Metadata Expression Language (MEL) Specification. |
| | CDNI Source Access Control Metadata |
| |
|
This specification provides an alternative to the MI.SourceMetadata objects defined in RFC8006, providing greatly extended capabilities with regards to defining multiple sources, load balancing, and failover rules across those sources, as well as a mechanism for a content delivery network (CDN) to monitor source health and pull unhealthy sources out of rotation. Additionally, new methods are defined for authentication access to an upstream source/origin. |
| | Asset Profiles for Asset Exchange |
| |
|
A definition of asset schema and profiles is needed to provide a semantic definition of tokenized assets. The Asset schema is an abstract construct at the root hierarchy of more specific "asset profiles". Asset profiles describe the structure (type) of assets that are specific to a given domain or industry. An asset instance that is instantiated in a specific network and is exchanged via the SATP protocol has an instance-class relationship (in an ontological sense) with a given profile. Asset profiles are essential to the SATP protocol as they define the semantics of asset instances to be transferred. Gateways may negotiate asset transfers based on the nature and abilities of the assets as defined according to their profile. The current document discusses the definition of the asset schema and profile. |
| | SATP Setup Stage |
| |
|
SATP Core defines an unidirectional transfer of assets in three stages, namely the Transfer Initiation stage (Stage-1), the Lock- Assertion stage (Stage-2) and the Commitment Establishment stage (Stage-3). This document defines the Setup Phase, often called "Stage-0", prior to the execution of SATP Core. During Setup, the two Gateways that would participate in the asset transfer are bound together via a "transfer context". The transfer context conveys information regarding the assets to be exchanged. Gateway can perform any kind of negotiation based on that transfer context, before entering into SATP Core. |
| | An Analysis of ASPA-based AS_PATH Verification |
| |
|
Autonomous System Provider Authorization (ASPA) is very helpful in detecting and mitigating route leaks (valley-free violations) and a majority of forged-origin hijacks. This document does an analysis on ASPA-based AS_PATH verification to help people understand its strengths and deficiencies, and some potential directions of enhancing ASPA are provided. |
| | EVN6: Mapping of Ethernet Virtual Network to IPv6 Underlay for Transmission |
| |
| | draft-xls-intarea-evn6-04.txt |
| | Date: |
25/08/2025 |
| | Authors: |
Chongfeng Xie, Jibin Sun, Xing Li, Congxiao Bao, Mark Smith |
| | Working Group: |
Individual Submissions (none) |
|
This document describes the mechanism of mapping of Ethernet Virtual Network to IPv6 Underlay for transmission. Unlike the existing methods, this approach places the Ethernet frames to be transmitted directly in the payload of IPv6 packets, i.e., L2 over IPv6, and uses stateless mapping to generate IPv6 source and destination addresses from the host's MAC addresses, Ethernet Virtual Network identifier and site prefixes. The IPv6 packets generated in this way carry Ethernet frames and are routed to the destination site across public IPv6 network. |
| | A YANG Data Model for In Situ Operations,Administration,and Maintenance (IOAM) Integrity Protected Options |
| |
|
In Situ Operations, Administration, and Maintenance (IOAM) is an example of an on-path hybrid measurement method. IOAM defines a method for producing operational and telemetry information that may be exported using the in-band or out-of-band method. I-D.ietf-ippm- ioam-data-integrity (RFC Ed.: to be replaced by RFC YYYY) defines IOAM Options with integrity protection, also called Integrity Protected Options. This document defines a YANG module for the configuration of these Integirty Protected Options. |
| | A profile for FC path attribute |
| |
|
This document specifies a mechanism for embedding a new path attribute, known as the FC path attribute, into BGP UPDATE messages. The FC (Forwarding Commitment) is a cryptographically signed object to certify an AS's routing intent on its directly connected hops. By incorporating the FC path attribute into BGP UPDATE messages. This mechanism provides enhanced route authenticity and lays the groundwork for improved data-plane forwarding verification. This mechanism is backward compatible, which means a router that supports the attribute can interoperate with a router that doesn't, allowing partial deployment across the Internet. |
| | Synchronizing BMP Monitoring Options and State |
| |
|
This document proposes methods to facilitate correction of BGP Routing Information Base inconsistencies in a non-disruptive manner from the BMP Sender to the BMP Collector. |
| | OAuth 2.0 Extension: On-Behalf-Of User Authorization for AI Agents |
| |
|
This specification extends the OAuth 2.0 Authorization Framework [RFC6749] to enable AI agents to securely obtain access tokens for acting on behalf of users. It introduces the *requested_actor* parameter in authorization requests to identify the specific agent requiring delegation and the *actor_token* parameter in token requests to authenticate the agent during the exchange of an authorization code for an access token. The flow can be initiated by a resource server challenge, ensuring that user consent is obtained dynamically when access is attempted. This extension ensures secure delegation with explicit user consent, streamlines the authorization flow, and enhances auditability through access token claims that document the delegation chain from the user to the agent via a client application. |
| | Currently Used Terminology Related to Source Address Validation |
| |
|
This document provides an overview of terms and abbreviations related to Source Address Validation (SAV). Its purpose is to establish a common and consistent set of terminology for use across SAV-related discussions and documents. This document explicitly does not serve as an authoritative source of correct terminology. |
| | Updates to Dynamic IPv6 Multicast Address Group IDs |
| |
|
Describes limitations of the existing range of dynamic IPv6 multicast addresses specified in RFC3307. Recommends replacing these allocations with a new registry in the IPv6 Multicast Address Space Registry registry group. Suggests initial contents of the new registry: a reduced allocation for MADCAP (RFC2730), a Private Use range, and Solicited-Node multicast addresses (which were not previously noted in RFC3307). |
| | Post-Quantum Cryptography for Engineers |
| |
| | draft-ietf-pquip-pqc-engineers-14.txt |
| | Date: |
25/08/2025 |
| | Authors: |
Aritra Banerjee, Tirumaleswar Reddy.K, Dimitrios Schoinianakis, Tim Hollebeek, Mike Ounsworth |
| | Working Group: |
Post-Quantum Use In Protocols (pquip) |
|
The advent of a cryptographically relevant quantum computer (CRQC) would render state-of-the-art, traditional public key algorithms deployed today obsolete, as the mathematical assumptions underpinning their security would no longer hold. To address this, protocols and infrastructure must transition to post-quantum algorithms, which are designed to resist both traditional and quantum attacks. This document explains why engineers need to be aware of and understand post-quantum cryptography (PQC), detailing the impact of CRQCs on existing systems and the challenges involved in transitioning to post-quantum algorithms. Unlike previous cryptographic updates, this shift may require significant protocol redesign due to the unique properties of post-quantum algorithms. |
| | RATS Endorsements |
| |
|
In the IETF Remote Attestation Procedures (RATS) architecture, a Verifier accepts Evidence and, using Appraisal Policy typically with additional input from Endorsements and Reference Values, generates Attestation Results in formats that are useful for Relying Parties. This document illustrates the purpose and role of Endorsements and discusses some considerations in the choice of message format for Endorsements in the scope of the RATS architecture. This document does not aim to define a conceptual message format for Endorsements and Reference Values. Instead, it extends RFC9334 to provide further details on Reference Values and Endorsements, as these topics were outside the scope of the RATS charter when RFC9334 was developed. |
| |
|
| |
| | BIER Prefix Redistribute |
| |
|
This document defines a BIER proxy function to support one single BIER sub-domain over multiple underlay routing protocol regions (Autonomous Systems or IGP areas). A new BIER proxy range sub-TLV is defined to redistribute BIER BFR-id information across the routing regions. |
| | Media Type Registration for Protocol Buffers |
| |
|
This document registers media types for Protocol Buffers, a common extensible mechanism for serializing structured data. |
| | Internet Key Exchange version 2 (IKEv2) extension for Header Compression Profile (HCP) |
| |
| | draft-ietf-ipsecme-ikev2-diet-esp-extension-06.txt |
| | Date: |
21/08/2025 |
| | Authors: |
Daniel Migault, Maryam Hatami, Daiying Liu, Stere Preda, J. Atwood, Sandra Cespedes, Tobias Guggemos, David Schinazi |
| | Working Group: |
IP Security Maintenance and Extensions (ipsecme) |
|
This document describes an IKEv2 extension for Header Compression to agree on Attributes for Rule Derivation. This extension defines the necessary registries for the ESP Header Compression Profile (EHCP) Diet-ESP. |
| | Media Type Specifications and Registration Procedures |
| |
|
This document defines procedures for the specification and registration of media types for use in HTTP, MIME, and other Internet protocols. |
| | BGP Signaled MPLS Namespaces |
| |
|
The MPLS forwarding layer in a core network is a shared resource. The MPLS FIB at nodes in this layer contains labels that are dynamically allocated and locally significant at that node. These labels are scoped in context of the global loopback address. Let us call this the global MPLS namespace. For some usecases like upstream label allocation, it is useful to create private MPLS namespaces (virtual MPLS FIB) over this shared MPLS forwarding layer. This allows installing deterministic label values in the private FIBs created at nodes participating in the private MPLS namespace, while preserving the "locally significant" nature of the underlying shared global MPLS FIB. This document defines new address families (AFI: 16399, SAFI: 128, or 1) and associated signaling mechanisms to create and use MPLS forwarding contexts in a network. Some example use cases are also described. |
| | Distributed Remote Attestation |
| |
|
In the RATS architecture, remote attestation typically involves multiple roles: verifier, attester, endorser, reference value provider, and relying party. However, in complex networks, the large number of entities in each role can significantly increase the cost of communication and computational resources. This document proposes a simplified remote attestation method based on distributed ledger(DL) technology, which aims to reduce the overhead for participants in multi-party networks. |
| | Yang Data Model for EVPN multicast |
| |
|
This document describes a YANG data model for EVPN multicast services. The model is agnostic of the underlay as well as RFC 9251. This document mainly focuses on EVPN instance framework. |
| |
|
| |
| | IPv6 Neighbor Discovery Prefix Registration |
| |
|
This document updates IPv6 Neighbor Discovery (RFC 4861) and IPv6 Subnet Neighbor Discovery (RFC 8505, RFC 8928) to enable a node that owns or is directly connected to a prefix to register that prefix to neighbor routers. The registration indicates that the registered prefix can be reached via the advertising node without a loop. The unicast prefix registration allows the node to request neighbor router(s) to redistribute the prefix in another routing domain regardless of the routing protocol used in that domain. This document updates Routing Protocol for Low-Power and Lossy Networks (RPL) (RFC 6550, RFC 9010) to enable a 6LoWPAN Router (6LR) to inject the registered prefix in RPL. |
| | Protocol-Specific Profiles for JSContact |
| |
|
This document defines JSContact profiles, an IANA registry for named subsets of JSContact elements. It aims to facilitate using JSContact in context of contact data exchange protocols or other use cases, in which supporting all of JSContact semantics might be inappropriate. |
| | JSContact Version 2.0: A JSON Representation of Contact Data |
| |
|
This document defines version "2.0" of JSContact. It defines the "uid" property of a Card object to be optional, rather than mandatory as defined in previous version "1.0". Other than changing the "uid" property, all other definitions of JSContact version "1.0" remain as defined in RFC 9553. This document updates RFC 9555 by redefining how to convert the now optional "uid" property from and to vCard. |
| | Link-Local Next Hop Capability for BGP |
| |
|
To support IPv6 reachability, BGP [RFC4271] relies on the Multiprotocol Extensions as defined in [RFC4760]. [RFC2545] defines the structure of IPv6 next hops. These IPv6 next hops may contain a Global IPv6 address, and optionally can contain an IPv6 Link-Local address when the BGP peer is directly attached and shares a common subnet with the IPv6 Global address. This document updates [RFC2545] to clarify the encoding of the BGP next hop when the advertising system is directly attached and only an IPv6 Link-Local address is available. A new BGP Capbility [RFC5492] is defined to signal support for this updated encoding. This clarification applies specifically to IPv6 Link-Local addresses and does not pertain to IPv4 Link-Local addresses as defined in [RFC3927]. |
| | ICMP Extension Structure Length Field |
| |
|
The ICMP Extension Structure (RFC4884) does not have a length field. Therefore, unless the length of the Extension Structure can be inferred from other data in the ICMP message, the Extension Structure must be the last item in the ICMP message. This document updates RFC 4884 to define a length field for the ICMP Extension Structure. When length information is provided, receivers can use it to parse ICMP messages. Specifically, receivers can use length information to determine the offset at which the item after the ICMP Extension Structure begins. |
| | HTTP Live Streaming 2nd Edition |
| |
|
This document obsoletes RFC 8216. It describes a protocol for transferring unbounded streams of multimedia data. It specifies the data format of the files and the actions to be taken by the server (sender) and the clients (receivers) of the streams. It describes version 13 of this protocol. |
| | The IPv6 Segment Routing (SRv6) Domain Name System (DNS) Resource Record |
| |
|
A Domain Name System (DNS) Resource Record (RR) Type is specified for storing IPv6 Segment Routing (SRv6) Information in the DNS. |
| | Intra-domain Source Address Validation (SAVNET) OAM |
| |
|
This document is a framework for how Source Address Validation (SAVNET) can be applied to operations and maintenance procedures for Intra-domain network. The document is structured to outline how Operations and Management (OAM) functionality can be used to assist in fault, configuration, accounting, performance, and security management, commonly known by the acronym FCAPS. |
| | Signaling SAVNET Capability Using IGP |
| |
|
Existing intra-domain SAV solutions (e.g., BCP38 [RFC2827] and BCP84 [RFC3704]) have problems of high operational overhead or inaccurate validation (see [I-D.ietf-savnet-intra-domain-problem-statement]). To address these problems and guide the design of new intra-domain SAV solutions,[I-D.ietf-savnet-intra-domain-architecture] proposes the architecture of intra-domain SAVNET and introduces the use of SAV-specific information in intra-domain networks. This document defines a mechanism to signal the SAVNET capablity and the source prefix using IGP and BGP-LS. |
| | Content Steering |
| |
|
This document describes a mechanism for servers to communicate their preferences to clients about utilizing alternate servers for streaming content. These alternate servers are typically distinct Content Delivery Networks or any other servers that offer similar distribution services. The mechanism described in this document is designed to be universally applicable and independent of any specific Content Delivery Protocol. |
| | Bitwise IP Filters for BGP FlowSpec |
| |
|
This draft introduces the bitwise matching filters for source or destination IPv4/IPv6 address fields. These filters enhance the functionalities of the BGP Flow Specification framework and aid scenarios involving symmetric traffic load balancing. |
| | BGP-4 Path Attribute Filtering Capability |
| |
|
Path Attributes in the BGP-4 protocol (RFC 4271) carry data associated with BGP routes. Many of the Path Attributes carried in BGP are intended for limited scope deployment. However, the extension mechanism defined by BGP that carries these attributes often carries them farther than necessary, sometimes with unfortunate results. This document defines a mechanism using BGP Capabilities (RFC 5492) that permits eBGP speakers to determine what Path Attributes should be permitted to cross external BGP routing boundaries. |
| | Identification,Sequence Number and Payload Option for IPv6 NDP and IPv4 ARP Ping |
| |
|
IPv6 Neighbor Discovery Protocol (NDP) and IPv4 Address Resolution Protocol (ARP) can be used to perform "ping" tests that overcome nodes' refusal to respond to IPv6 and IPv4 ICMP Echo Requests. A drawback is that NDP and ARP do not carry an Identification, Sequence Number and Payload for these ping tests. This memo proposes an IPv6 Neighbor Discovery Option that adds these fields to the NDP and ARP packets used to perform ping tests. |
| | LISP-Based Network for AI Infrastructure |
| |
|
The LISP control plane provides the mechanisms to support both Scale- Up and Scale-Out backend networks within AI infrastructure. This document outlines how LISP can enable a unified control plane architecture that accommodates both scaling technologies, offering flexibility in deployment. This approach allows AI/ML applications—whether focused on training or inference—to operate workloads efficiently with resiliency on a converged infrastructure, supporting diverse deployment scenarios using the same underlying network fabric. |
| | Contextual Authentication Presentation Protocol (CAPP) |
| |
| | draft-shim-capp-00.txt |
| | Date: |
20/08/2025 |
| | Authors: |
Ace Shim, Lukas.J Han |
| | Working Group: |
Individual Submissions (none) |
|
CAPP is a decentralized presentation protocol for Verifiable Credentials that enables frictionless, context-triggered, pre- consented credential sharing without requiring interactive challenge- response cycles. It is optimized for physical access, transit, event entry, and other passive authentication scenarios. |
| | PCEP Extensions to support BFD parameters |
| |
|
This document proposes extension to PCEP to configure LSP parameters. Some of LSP parameters are needed to configure S-BFD for candidate paths. Each candidate path is identified in PCEP by its uniquely assigned PLSP-ID. The mechanism proposed in this document is applicable to to all path setup types. This extension can work with ifferent PCEP Path Setup Types but especially suitable for Segment Routing (SR-MPLS, SRv6).. |
| |
|
| |
| | LSR Extensions for BIER non-MPLS Encapsulation |
| |
|
Bit Index Explicit Replication (BIER) is an architecture that provides multicast forwarding through a "BIER domain" without requiring intermediate routers to maintain multicast related per-flow state. BIER can be supported in MPLS and non-MPLS networks. This document updates RFC8296 and specifies the required extensions to the IS-IS, OSPFv2 and OSPFv3 protocols for supporting BIER in non- MPLS networks using BIER non-MPLS encapsulation. |
| | DRIP Entity Tags in the Domain Name System |
| |
|
This document defines the Domain Name System (DNS) functionality of a Drone Remote Identification Protocol (DRIP) Identity Management Entity (DIME). It is built around DRIP Entity Tags (DETs) to standardize a hierarchical registry structure and associated processes to facilitate trustable and scalable registration and lookup of information related to Unmanned Aircraft Systems (UAS). The registry system supports issuance, discovery, and verification of DETs, enabling secure identification and association of UAS and their operators. It also defines the interactions between different classes of registries (root, organizational, and individual) and their respective roles in maintaining the integrity of the registration data. This architecture enables decentralized, federated operation while supporting privacy, traceability, and regulatory compliance requirements in the context of UAS Remote ID and other services. |
| | Adding Extensions to ICMP Errors for Originating Node Identification |
| |
|
RFC5837 describes a mechanism for Extending ICMP for Interface and Next-Hop Identification, which allows providing additional information in an ICMP error that helps identify interfaces participating in the path. This is especially useful in environments where a given interface may not have a unique IP address to respond to, e.g., a traceroute. This document introduces a similar ICMP extension for Node Identification. It allows providing a unique IP address and/or a textual name for the node, in the case where each node may not have a unique IP address (e.g., a deployment in which all interfaces have IPv6 addresses and all nexthops are IPv6 nexthops, even for IPv4 routes). |
| | Signal-Free Locator/ID Separation Protocol (LISP) Multicast |
| |
|
This document describes the design for inter-domain multicast overlays using the Locator/ID Separation Protocol (LISP). The document specifies how LISP multicast overlays operate over a unicast underlays. When multicast sources and receivers are active at Locator/ID Separation Protocol (LISP) sites, the core network is required to use native multicast so packets can be delivered from sources to group members. When multicast is not available to connect the multicast sites together, a signal-free mechanism can be used to allow traffic to flow between sites. The mechanism within here uses unicast replication and encapsulation over the core network for the data plane and uses the LISP mapping database system so encapsulators at the source LISP multicast site can find decapsulators at the receiver LISP multicast sites. |
| | Analysis for Multiple Data Plane Solutions of Computing-Aware Traffic Steering |
| |
| | draft-fu-cats-muti-dp-solution-03.txt |
| | Date: |
19/08/2025 |
| | Authors: |
FUHUAKAI, Bo Liu, Zhenqiang Li, Daniel Huang, Dongyu Yuan, Liwei Ma, Wei Duan |
| | Working Group: |
Individual Submissions (none) |
|
This document proposes a data plane framework for Computing-Aware Traffic Steering (CATS), detailing multiple optional solutions, comparing their key characteristics and distinctions, and analyzing applicable scenarios to provide a reference for implementation. |
| | Flow-Level Load Balancing of Computing-Aware Traffic Steering (CATS) |
| |
| | draft-fu-cats-flow-lb-02.txt |
| | Date: |
19/08/2025 |
| | Authors: |
FUHUAKAI, Daniel Huang, Liwei Ma, Wei Duan, Bin Tan |
| | Working Group: |
Individual Submissions (none) |
|
This document proposes a flow-level load balancing solution for CATS, and is designed to effectively manage CS-ID traffic by addressing issues like frequent control plane operations and uneven use of computing resources. The approach entails concurrently identifying multiple next-hop choices, factoring in both network pathways and service instances. Traffic is then distributed among these service instances using flow-based load balancing, which relies on the five- tuple characteristics of packets. |
| |
|
| |
| | CBOR Encoded X.509 Certificates (C509 Certificates) |
| |
|
This document specifies a CBOR encoding of X.509 certificates. The resulting certificates are called C509 Certificates. The CBOR encoding supports a large subset of RFC 5280 and all certificates compatible with the RFC 7925, IEEE 802.1AR (DevID), CNSA 1.0, RPKI, GSMA eUICC, and CA/Browser Forum Baseline Requirements profiles. C509 is deployed in different settings including, in-vehicle and vehicle-to-cloud communication, Unmanned Aircraft Systems (UAS), and Global Navigation Satellite System (GNSS). When used to re-encode DER encoded X.509 certificates, the CBOR encoding can in many cases reduce the size of RFC 7925 profiled certificates by over 50% while also significantly reducing memory and code size compared to ASN.1. The CBOR encoded structure can alternatively be signed directly ("natively signed"), which does not require re-encoding for the signature to be verified. The TLSA selectors registry defined in RFC 6698 is extended to include C509 certificates. The document also specifies C509 Certificate Requests, C509 COSE headers, a C509 TLS certificate type, and a C509 file format. |
| | Some Key Terms for Network Fault and Problem Management |
| |
| | draft-ietf-nmop-terminology-23.txt |
| | Date: |
18/08/2025 |
| | Authors: |
Nigel Davis, Adrian Farrel, Thomas Graf, Qin WU, Chaode Yu |
| | Working Group: |
Network Management Operations (nmop) |
|
This document sets out some terms that are fundamental to a common understanding of network fault and problem management within the IETF. The purpose of this document is to bring clarity to discussions and other work related to network fault and problem management, in particular to YANG data models and management protocols that report, make visible, or manage network faults and problems. |
| | Supporting IOAM in IPv6 |
| |
|
IOAM pre-allocated trace option data fields can be encapsulated in IPv6 HbH options header as described in RFC9486. However, due to the potential large size of the trace data and the HbH extension header location in the IPv6 packets, the scheme creates practical challenges for implementation, especially when other extension headers, such as a routing header, also exist and require on-path processing. We propose two alternative approaches to address this challenge in addition to IOAM DEX: separating the IOAM incremental trace data from the IOAM instruction header, or applying the segment IOAM trace data export scheme, based on the network scenario and application requirements. We discuss the pros and cons of each approach in this document. |
| | The Architecture of Network-Aware Domain Name System (DNS) |
| |
|
This document describes a framework which extends the Domain Name System (DNS) to provide network awareness to applications. The framework enables DNS system responses that are dependent on communication service requirements such as QoS or path without changes in the format of DNS protocol messages or application program interfaces (APIs). The different enhancement methods and use cases are discussed. |
| | Using ShangMi in the Internet Key Exchange Protocol Version 2 (IKEv2) |
| |
|
This document defines a set of cryptographic transforms for use in the Internet Key Exchange Protocol version 2 (IKEv2). The transforms are based on ISO and Chinese cryptographic standard algorithms (called "ShangMi" or “SM” algorithms). The use of these algorithms with IKEv2 is not endorsed by the IETF. The SM algorithms is ISO standardization and are mandatory for some scenario in China, so this document provides a description of how to use the SM algorithms with IKEv2 and specifies a set of cryptographic transforms so that implementers can produce interworking implementations. |
| | SRv6 for Deterministic Path Placement in AI Backends |
| |
| | draft-filsfils-srv6ops-srv6-ai-backend-02.txt |
| | Date: |
18/08/2025 |
| | Authors: |
Clarence Filsfils, Chris Martin, Kiran Pillai, Pablo Camarillo, Ahmed Abdelsalam, Jeff Tantsura, Keyur Patel |
| | Working Group: |
Individual Submissions (none) |
|
This document describes the use of SRv6 to enable deterministic path placement in AI backends, optimizing load balancing and congestion control for predictable GPU workloads. |
| | Anonymous Credit Tokens |
| |
|
This document specifies Anonymous Credit Tokens (ACT), a privacy- preserving authentication protocol that enables numerical credit systems without tracking individual clients. Based on keyed- verification anonymous credentials and privately verifiable BBS-style signatures, the protocol allows issuers to grant tokens containing credits that clients can later spend anonymously with that issuer. The protocol's key features include: (1) unlinkable transactions - the issuer cannot correlate credit issuance with spending, or link multiple spends by the same client, (2) partial spending - clients can spend a portion of their credits and receive anonymous change, and (3) double-spend prevention through cryptographic nullifiers that preserve privacy while ensuring each token is used only once. Anonymous Credit Tokens are designed for modern web services requiring rate limiting, usage-based billing, or resource allocation while respecting user privacy. Example applications include rate limiting and API credits. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. |
| | System for Cross-domain Identity Management: Agentic Identity Schema |
| |
|
The System for Cross-domain Identity Management (SCIM) specifications are designed to make identity management in cloud-based applications and services easier. This document provides a platform-neutral schema for representing AI agents' identities in JSON format, enabling them to be transferred in the SCIM protocol to the service. This establishes an agentic identity so that an agent can subsequently be authenticated and authorized to interact with the service. |
| | A Profile for Autonomous System Provider Authorization |
| |
| | draft-ietf-sidrops-aspa-profile-20.txt |
| | Date: |
18/08/2025 |
| | Authors: |
Alexander Azimov, Eugene Uskov, Randy Bush, Job Snijders, Russ Housley, Ben Maddison |
| | Working Group: |
SIDR Operations (sidrops) |
|
This document defines a Cryptographic Message Syntax (CMS) protected content type for Autonomous System Provider Authorization (ASPA) objects for use with the Resource Public Key Infrastructure (RPKI). An ASPA is a digitally signed object through which the issuer (the holder of an Autonomous System identifier), can authorize one or more other Autonomous Systems (ASes) as its upstream providers. When validated, an ASPA's eContent can be used for detection and mitigation of route leaks. |
| | Resource Public Key Infrastructure (RPKI) Manifest Number Handling |
| |
|
The Resource Public Key Infrastructure (RPKI) makes use of signed objects called manifests, each of which includes a "manifest number". This document updates RFC9286 by specifying issuer and RP behaviour when a manifest number reaches the largest possible value, a situation not considered in RFC9286. |
| | WebRTC-HTTP Egress Protocol (WHEP) |
| |
| | draft-ietf-wish-whep-03.txt |
| | Date: |
18/08/2025 |
| | Authors: |
Sergio Murillo, Cheng Chen, Dan Jenkins |
| | Working Group: |
WebRTC Ingest Signaling over HTTPS (wish) |
|
This document describes a simple HTTP-based protocol that will allow WebRTC-based viewers to watch content from streaming services and/or Content Delivery Networks (CDNs) or WebRTC Transmission Network (WTNs). |
| |
|
| |
| | ESP Header Compression with Diet-ESP |
| |
| | draft-ietf-ipsecme-diet-esp-09.txt |
| | Date: |
17/08/2025 |
| | Authors: |
Daniel Migault, Maryam Hatami, Sandra Cespedes, J. Atwood, Daiying Liu, Tobias Guggemos, Carsten Bormann, David Schinazi |
| | Working Group: |
IP Security Maintenance and Extensions (ipsecme) |
|
This document specifies Diet-ESP, a compression mechanism for control information in IPsec/ESP communications. The compression uses Static Context Header Compression rules. |
| | Multicast Redundant Ingress Router Failover |
| |
|
This document analyzes the problem of failover between redundant ingress routers in multicast domains. It describes cold, warm, and hot standby modes, detailing their advantages, limitations, and deployment considerations to help operators select appropriate mechanisms. |
| | TLS 1.2 Update for Long-term Support (LTS) |
| |
|
This document specifies an update of TLS 1.2 for long-term support (LTS) on systems that can have multi-year or even decade-long update cycles, one that incoporates as far as possible what's already deployed for TLS 1.2 but with the security holes and bugs fixed. This document also recognises the fact that there is a huge amount of TLS use outside the web content-delivery environment with its resource-rich hardware and software that can be updated whenever required and provides a long-term stable, known-good version that can be deployed to systems that can't roll out ongoing changes on a continuous basis. |
| | A Pre-Authentication Mechanism for SSH |
| |
|
Devices running SSH are frequently exposed on the Internet, either because of operational considerations or through misconfiguration, making them vulnerable to the constant 3-degree background radiation of scanning and probing attacks that pervade the Internet. This document describes a simple pre-authentication mechanism that limits these attacks with minimal changes to SSH implementations and no changes to the SSH protocol itself. |
| | PKCS #15 Updates |
| |
|
This document describes updates to the PKCS #15 standard made since the original publication of the standard. |
| | Hierarchical Topology for Language Model Coordination |
| |
|
This document defines a YANG data model and reference architecture for a hierarchical topology of language models (LMs), where tiny, small, and large LMs cooperate to perform distributed inference, summarization, and decision-making. The model supports secure inter-node messaging, request escalation, token-based authorization, and decentralized validation using pluggable trust models. This architecture is designed for deployments where computational capabilities vary across nodes, such as edge-to-cloud environments or multi-tier AI systems. The goal is to provide a standards-based mechanism for orchestrating scalable, secure LM interactions across heterogeneous systems. |
| | Support for Path MTU (PMTU) in the Path Computation Element (PCE) Communication Protocol (PCEP) |
| |
| | draft-ietf-pce-pcep-pmtu-08.txt |
| | Date: |
17/08/2025 |
| | Authors: |
Shuping Peng, Cheng Li, Liuyan Han, Luc-Fabrice Ndifor, Samuel Sidor |
| | Working Group: |
Path Computation Element (pce) |
|
The Path Computation Element (PCE) provides path computation functions in support of traffic engineering in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. The Source Packet Routing in Networking (SPRING) architecture describes how Segment Routing (SR) can be used to steer packets through an IPv6 or MPLS network using the source routing paradigm. A Segment Routed Path can be derived from a variety of mechanisms, including an IGP Shortest Path Tree (SPT), explicit configuration, or a Path Computation Element (PCE). Since the SR does not require signaling, the path maximum transmission unit (MTU) information for the SR path is unavailable at the headend. This document specifies the extension to PCE Communication Protocol (PCEP) to carry path MTU as a new metric type in the PCEP messages for SR, but not limited to it. This document also updates RFC 5440 to allow metric bounds to be minimum as needed in the case of path MTU. |
| |
|
| |
| | A YANG data model for Tree Engineering for Bit Index Explicit Replication (BIER-TE) |
| |
| | draft-ietf-bier-te-yang-09.txt |
| | Date: |
15/08/2025 |
| | Authors: |
Zheng Zhang, Cui(Linda) Wang, Ran Chen, fangwei hu, Mahesh Sivakumar, chenhuanan |
| | Working Group: |
Bit Indexed Explicit Replication (bier) |
|
This document defines a YANG data module for Tree Engineering for Bit Index Explicit Replication (BIER-TE) configuration and operation. |
| | Internationalization for the NFSv4 Protocols |
| |
|
This document describes the handling of internationalization for all NFSv4 protocols, including NFSv4.0, NFSv4.1, NFSv4.2 and extensions thereof, and future minor versions. It updates RFC7530 and RFC8881. |
| | NTS4PTP - Network Time Security for the Precision Time Protocol |
| |
|
This document specifies an automatic key management service for the integrated security mechanism (prong A) of IEEE Std 1588™-2019 (PTPv2.1) described there in Annex P. This key management follows the immediate security processing approach of prong A and extends the NTS Key Establishment protocol defined in IETF RFC 8915 for securing NTPv4. The resulting NTS for PTP (NTS4PTP) protocol provides a security solution for all PTP modes and operates completely independent of NTPv4. It also provides measures against known attack vectors targeting PTP. |
| | Protocol Independent Multicast - Sparse Mode (PIM-SM) Designated Router (DR) Improvement |
| |
|
Protocol Independent Multicast - Sparse Mode (PIM-SM) is a widely deployed multicast protocol. As deployment for the PIM protocol is growing day by day, a user expects lower packet loss and faster convergence regardless of the cause of the network failure. This document defines an extension to the existing protocol, which improves the PIM's stability with respect to packet loss and convergence time when the PIM Designated Router (DR) role changes. |
| | Attestation Results for Secure Interactions |
| |
| | draft-ietf-rats-ar4si-09.txt |
| | Date: |
15/08/2025 |
| | Authors: |
Eric Voit, Henk Birkholz, Thomas Hardjono, Thomas Fossati, Vincent Scarlata |
| | Working Group: |
Remote ATtestation ProcedureS (rats) |
|
This document defines reusable Attestation Result information elements. When these elements are offered to Relying Parties as Evidence, different aspects of Attester trustworthiness can be evaluated. Additionally, where the Relying Party is interfacing with a heterogeneous mix of Attesting Environment and Verifier types, consistent policies can be applied to subsequent information exchange between each Attester and the Relying Party. This document also defines two serialisations of the proposed information model, utilising CBOR and JSON. |
| |
|
| |
| | Prioritizing known-local IPv6 ULAs through address selection policy |
| |
|
This document updates the default address selection algorithm for Internet Protocol Version 6 (IPv6), originally specified in RFC 6724, based on accumulated operational experience. It introduces the concept of "known-local" Unique Local Address (ULA) prefixes within the fd00::/8 block and specifies that ULA-to-ULA communications using such prefixes should be preferred over both IPv4-to-IPv4 and GUA-to- GUA (Global Unicast Address) communications in local use scenarios. The document defines mechanisms for nodes to identify and incorporate known-local prefixes into their address selection policy tables. It introduces a requirement to implement Rule 5.5 of RFC 6724 and reduces the default precedence for 6to4 addresses. These updates enhance the supportability of typical deployment environments, including automatic and unmanaged configurations, and promote consistent IPv6-over-IPv4 precedence behavior for both ULA and GUA within local networks. The document acknowledges that certain atypical deployment models may require explicit configuration to achieve intended operational outcomes. |
| | ACME End User Client and Code Signing Certificates |
| |
|
Automated Certificate Management Environment (ACME) core protocol addresses the use case of web server certificates for TLS. This document extends the ACME protocol to add 3 challenge types that may support service account authentication credentials, micro-service accounts credentials, device client, code signing, document signing certificates and keys. |
| | ALPN ID Specification for CoAP over DTLS |
| |
| | draft-ietf-core-coap-dtls-alpn-05.txt |
| | Date: |
11/08/2025 |
| | Authors: |
Martine Lenders, Christian Amsuess, Thomas Schmidt, Matthias Waehlisch |
| | Working Group: |
Constrained RESTful Environments (core) |
|
This document specifies an Application-Layer Protocol Negotiation (ALPN) ID for transport-layer-secured Constrained Application Protocol (CoAP) services. |
| | DNS IPv6 Transport Operational Guidelines |
| |
|
This memo provides guidelines and documents Best Current Practice for operating authoritative DNS servers as well as recursive and stub DNS resolvers, given that queries and responses are carried in a mixed environment of IPv4 and IPv6 networks. This document expands on RFC 3901 by recommending that authoritative DNS servers as well as recursive DNS resolvers support both IPv4 and IPv6. It furthermore provides guidance for how recursive DNS resolver should select upstream DNS servers, if synthesized and non-synthesized IPv6 addresses are available. This document obsoletes RFC3901. (if approved) |
| | DNS to Web3 Wallet Mapping |
| |
|
This document proposes an implementation standard for mapping wallets to domain names using the new WALLET RRType, allowing for TXT record fallback while the WALLET RRType propagates through DNS providers. The goal is to provide a secure and scalable and unbiased way to associate wallets with domain names, enabling seamless lookup as well as suggesting required authentication mechanism. The proposal relies on DNSSEC or security successors to ensure trust and security. |
| | Verifiable STI Persona (VESPER) Use Cases and Requirements |
| |
|
This document discusses a set of use cases and requirements for an extension to Secure Telephone Identity Revisited (STIR) called Verifiable STI PERsona (VESPER). VESPER fundamentally enhances STIR by establishing an authoritative and cryptographically verifiable Right-to-Use (RTU) relationship between telephone numbers and their assigned entities, business organizations or individuals, through digital signatures that bind an entity to a set of asserted claims, delegate certificates that govern the assertion of those claims to a responsible party, and Authority Tokens that prove the validation of those claims by authoritative parties. This cryptographic binding ensures explicit non-repudiation, removing ambiguity around who is accountable for calls or messages originating from specific telephone numbers, significantly deterring spoofing and fraud. |
| | SSH Support of ML-DSA |
| |
|
This document describes the use of ML-DSA digital signatures in the Secure Shell (SSH) protocol. |
| | A YANG Data Model for requesting path computation |
| |
|
There are scenarios, typically in a hierarchical Software-Defined Networking (SDN) context, where the topology information provided by a Traffic Engineering (TE) network provider may be insufficient for its client to perform multi-domain path computation. In these cases the client would need to request the TE network provider to compute some intra-domain paths to be used by the client to choose the optimal multi-domain paths. This document provides a mechanism to request path computation by augmenting the Remote Procedure Calls (RPCs) defined in RFC YYYY. [RFC EDITOR NOTE: Please replace RFC YYYY with the RFC number of draft-ietf-teas-yang-te once it has been published. Moreover, this document describes some use cases where the path computation request, via YANG-based protocols (e.g., NETCONF or RESTCONF), can be needed. |
| |
|
| |
| | OpenPGP HTTP Keyserver Protocol |
| |
|
This document specifies a series of conventions to implement an OpenPGP keyserver using the Hypertext Transfer Protocol (HTTP). As this document is a codification and extension of a protocol that is already in wide use, strict attention is paid to backward compatibility with these existing implementations. |
| | GREASE Code Points in OpenPGP |
| |
|
This document reserves code points in various OpenPGP registries for use in interoperability testing, by analogy with GREASE in TLS. |
| | BMPS: Transport Layer Security for BGP Monitoring Protocol |
| |
|
The BGP Monitoring Protocol (BMP) defines the communication between a BMP station and multiple routers, referred to as network elements (NEs). This document describes BMP over TLS, which uses Transport Layer Security (TLS) to ensure secure transport between the NE and the BMP monitoring station. It updates [RFC7854] regarding BMP session establishment and termination. |
| | OpenID Connect Email Account Linking Extension |
| |
|
This document extends OpenID Connect's standard email functionality to support secure linking between multiple email accounts. It enables users to associate secondary email addresses with their primary account while maintaining backward compatibility with existing implementations. The extension provides methods for establishing, managing, and utilizing these relationships within the OpenID Connect email scope. |
| | Media Types for OpenPGP |
| |
|
This document updates the specification of existing media types, and specifies additional media types, for the identification of OpenPGP data in non-MIME contexts. |
| | Age Verification: Age vs. Youth -- One is not Like the Other |
| |
|
Solely technical measures advertised to allow for the age verification of minors online face fundamental challenges on a conceptual and implementation level. Organizational measures, on the other hand, have been established as best practices by peer groups who are both high risk and digitally savvy, which exists to protect minors. These approaches can be strengthened via technical measures, and two such candidates are the Qualified Website Authentication Certificates (QWACS), introduced by the EU as part of eIDAS 2.0 [QWACS] and potentially the work of IETF's digital emblems working group [DIEM]. Based on early analysis of the use and abuse cases as well as privacy and security considerations, we provide arguments why non-scaling organizational measures are a necessity and strengthening these with technical measures is a way to enable the security for minors online. |
| |
|
| |
| | A Common YANG Data Model for Scheduling |
| |
|
This document defines common types and groupings that are meant to be used for scheduling purposes such as event, policy, services, or resources based on date and time. For the sake of better modularity, the YANG module includes a set of recurrence-related groupings with varying levels of representation (i.e., from basic to advanced) to accommodate a variety of requirements. It also defines groupings for validating requested schedules and reporting scheduling status. |
| | DNS Filtering Details for Applications |
| |
|
[I-D.ietf-dnsop-structured-dns-error] introduces structured error data for DNS responses that have been filtered. This specification allows more specific details of filtering incidents to be conveyed. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/mnot/public-resolver-errors. |
| | The IETF is for Everyone: Toward Inclusive and Equitable Participation in Internet Governance |
| |
|
This document aims to foster a deeper reflection within the IETF community on inclusive participation, equitable access, and the implications of global meeting venue selections on diverse contributors. It seeks to complement existing RFCs by proposing additional dialogue, tools, and evaluation mechanisms. |
| | A Best Current Practice for Agentic Interactions over HTTP |
| |
|
This document describes a set of best practices for facilitating interactions between automated software agents (AI agents) using the Hypertext Transfer Protocol (HTTP). As agentic systems proliferate, they frequently utilize HTTP in ad-hoc ways, leading to interoperability challenges and the rise of proprietary, "walled garden" ecosystems. This document proposes a minimalist, standardized framework based on existing HTTP semantics to promote a more cohesive, efficient, and open ecosystem. The primary recommendations codify the principles of the Agentic Hypercall Protocol (AHP), including tool invocation via GET requests, a stateless authentication scheme, and the formalization of the 402 (Payment Required) status code to enable a native economic layer for the machine economy. |
| | PCE Communication Protocol (PCEP) Extensions for Using the PCE as a Central Controller (PCECC) of point-to-multipoint (P2MP) LSPs |
| |
|
The PCE is a core component of Software-Defined Networking (SDN) systems. The PCE has been identified as an appropriate technology for the determination of the paths of point-to-multipoint (P2MP) TE Label Switched Paths (LSPs). A PCE-based Central Controller (PCECC) can simplify the processing of a distributed control plane by blending it with elements of SDN and without necessarily completely replacing it. Thus, the P2MP LSP can be calculated/set up/initiated, and the label-forwarding entries can also be downloaded through a centralized PCE server to each network device along the P2MP path while leveraging the existing PCE technologies as much as possible. This document specifies the procedures and PCE Communication Protocol (PCEP) extensions for using the PCE as the central controller for provisioning labels along the path of the static P2MP LSP. |
| | RDAP Extension for DNS Time-To-Live (TTL Values) |
| |
|
This document describes an extension to the Registration Data Access Protocol ([RFC9083]) which allows the Time-To-Live (TTL) values for relevant DNS record types to be included in RDAP responses. About this draft This note is to be removed before publishing as an RFC. The source for this draft, and an issue tracker, may can be found at https://github.com/gbxyz/rdap-ttl-extension. |
| | Secure Asset Transfer Protocol (SATP) Core |
| |
| | draft-ietf-satp-core-11.txt |
| | Date: |
07/08/2025 |
| | Authors: |
Martin Hargreaves, Thomas Hardjono, Rafael Belchior, Venkatraman Ramakrishna, Alexandru Chiriac |
| | Working Group: |
Secure Asset Transfer Protocol (satp) |
|
This memo describes the Secure Asset Transfer (SAT) Protocol for digital assets. SAT is a protocol operating between two gateways that conducts the transfer of a digital asset from one gateway to another, each representing their corresponding digital asset networks. The protocol establishes a secure channel between the endpoints and implements a 2-phase commit (2PC) to ensure the properties of transfer atomicity, consistency, isolation and durability. |
| |
|
| |
| | Traffic Steering using BGP FlowSpec with SR Policy |
| |
|
BGP Flow Specification (FlowSpec) [RFC8955] and [RFC8956] has been proposed to distribute BGP [RFC4271] FlowSpec NLRI to FlowSpec clients to mitigate (distributed) denial-of-service attacks, and to provide traffic filtering in the context of a BGP/MPLS VPN service. Recently, traffic steering applications in the context of SR-MPLS and SRv6 using FlowSpec are being used in networks. This document introduces the usage of BGP FlowSpec to steer packets into an SR Policy. |
| | BGP Extension for SR-MPLS Entropy Label Position |
| |
|
This document proposes extensions for BGP to indicate the entropy label position in the SR-MPLS label stack when delivering SR Policy via BGP. |
| | Advertising SID Algorithm Information in BGP |
| |
|
This document defines new Segment Types and proposes extensions for BGP to provide algorithm information for SR-MPLS Adjacency-SIDs when delivering SR Policy via BGP. |
| | LISP Control-Plane ECDSA Authentication and Authorization |
| |
|
This draft describes how LISP control-plane messages can be individually authenticated and authorized without a a priori shared- key configuration. Public-key cryptography is used with no new PKI infrastructure required. |
| | IS-IS Extension to Advertise SRv6 SIDs using SID Block |
| |
|
This document proposes a simplified method to advertise SRv6 SIDs in IS-IS. The SRv6 SID Block is composed of a number of continuous SIDs within the address range of a Locator. When a SID is assigned from the SID Block, it is described by an index based on the SID Block, instead of the whole 128-bit IPv6 address. |
| | Service Interworking between SRv6 |
| |
|
When operators provide services through SRv6, such as L3VPN and L2VPN, there may be cross-domain scenarios of multiple ASs, or multiple admin domain scenarios within the same AS. This document describes how to implement interworking of services for such scenarios. |
| | Ping Path Consistency over SRv6 |
| |
|
In the SRv6 network, the headend node could use Ping (ICMPv6 Echo) to detect the connectivity of the SRv6 path to implement path switching. When a headend use Ping to detect the segment list/CPath of SRv6 Policy, the forward path of ICMPv6 Echo Request message is indicated by segment list, the reverse path of ICMPv6 Echo Reply message is via the shortest path from the destination node to the source as determined by routing. The forward path and reverse path of ICMPv6 message are likely inconsistent going through different intermediate nodes or links. This document describes how to ensure the consistency of the forward path and the reverse path when using ICMPv6 Echo messages to detect SRv6 Policy. |
| | Path-aware Remote Protection Framework |
| |
|
This document describes the framework of path-aware remote protection. |
| | SRv6 SFC Architecture with SR-aware Functions |
| |
|
This document describes the architecture of Segment Routing over IPv6 (SRv6) Service Function Chaining (SFC) with SR-aware functions. This architecture provides the following benefits: * Comprehensive Management: a centralized controller for SFC, handling SR Policy, link-state, and network metrics. * Simplicity: no SFC proxies, which reduces the number of nodes and address resource consumption. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Source Packet Routing in Networking Working Group mailing list (spring@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/spring/. Source for this draft and an issue tracker can be found at https://https/github.com/watal. |
| | Considerations for Integrating Merkle Tree Ladder (MTL) Mode Signatures into Applications |
| |
|
This document provides design considerations for application designers on how to add Merkle Tree Ladder (MTL) Mode signatures into their applications. It provides general considerations relevant to any signature algorithm in addition to specific considerations for MTL mode such as for grouping and ordering messages to be signed, computing and signing ladders, and forming signatures exchanged between application components, including handling caching between the signer and the verifier. |
| | IPFIX Protocol over QUIC |
| |
|
The IP Flow Information Export (IPFIX) Protocol provides a means for transmitting Traffic Flow information over the network. IPFIX Data and Template Records can be carried over a number of transport protocols from an IPFIX Exporting Process to an IPFIX Collecting Process. The supported transport protocols are SCTP, UDP and TCP. QUIC could provide useful, reliable and secure semantics for IPFIX Protocol in particular as a single connection could carry multiple traffic flows over streams, enabling much better efficiency and performance for Exporter and Collector. This document describes how to use IPFIX Protocol over the QUIC transport protocol, named IPFIXoQUIC. |
| | Task-Oriented Multi-Agent Recovery Framework for High-Reliability in Converged Mobile Networks |
| |
|
This document defines a task-oriented, agent-based method for fault recovery in converged public-private mobile networks. The proposed method introduces a multi-agent collaboration framework that enables autonomous failure detection, scoped diagnosis, inter-domain coordination, and intent-driven policy reconfiguration. It is particularly applicable in complex 5G/6G network deployments, such as Multi-Operator Core Networks (MOCN) and Standalone Non-Public Networks (SNPN), where traditional centralized management is insufficient for ensuring high service reliability and dynamic recovery. The document also specifies protocol requirements for inter-agent communication, state consistency, and secure coordination, aiming to support interoperability and resilience across heterogeneous network domains. |
| | Architectural Considerations of Age Restriction |
| |
|
Around the world, policymakers are considering (and in some cases implementing) age restriction systems for Internet content. This document explores the unwanted impacts on the Internet that these systems are likely to have, and makes recommendations to increase their chances of becoming a successful part of the Internet infrastructure. |
| | YANG Data Model for RPKI to Router Protocol |
| |
| | draft-ietf-sidrops-rtr-yang-00.txt |
| | Date: |
04/08/2025 |
| | Authors: |
Yisong Liu, Changwang Lin, Haibo Wang, ROY Jishnu, Jeffrey Haas, Hongwei Liu, Di Ma |
| | Working Group: |
SIDR Operations (sidrops) |
|
This document defines YANG data models for configuring and managing Resource Public Key Infrastructure (RPKI) to Router Protocol (RFC6810 and RFC8210). |