| |
|
| |
| | Verifiable Distributed Aggregation Functions |
| |
| | draft-irtf-cfrg-vdaf-18.txt |
| | Date: |
30/01/2026 |
| | Authors: |
Richard Barnes, David Cook, Christopher Patton, Phillipp Schoppmann |
| | Working Group: |
Crypto Forum (cfrg) |
|
This document describes Verifiable Distributed Aggregation Functions (VDAFs), a family of multi-party protocols for computing aggregate statistics over user measurements. These protocols are designed to ensure that, as long as at least one aggregation server executes the protocol honestly, individual measurements are never seen by any server in the clear. At the same time, VDAFs allow the servers to detect if a malicious or misconfigured client submitted an invalid measurement. Two concrete VDAFs are specified, one for general- purpose aggregation (Prio3) and another for heavy hitters (Poplar1). |
| | DNS Multiple QTYPEs |
| |
|
This document specifies a method for a DNS client to request additional DNS record types to be delivered alongside the primary record type specified in the question section of a DNS QUERY (OpCode=0). |
| | Communicating Proxy Configurations in Provisioning Domains |
| |
|
This document defines a mechanism for accessing provisioning domain information associated with a proxy, such as other proxy URIs that support different protocols and information about which destinations are accessible using a proxy. 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/tfpauly/privacy-proxy. |
| | Quality of Outcome (QoO) |
| |
| | draft-ietf-ippm-qoo-06.txt |
| | Date: |
30/01/2026 |
| | Authors: |
Bjorn Teigen, Magnus Olden, Ike Kunze |
| | Working Group: |
IP Performance Measurement (ippm) |
|
This document introduces the Quality of Outcome (QoO) network quality score and the corresponding QoO framework as an approach to network quality assessment designed to align with the needs of application developers, users, and operators. By leveraging the Quality Attenuation metric, QoO provides a method for defining and evaluating application-specific, quality-focused network performance requirements to enable insights for network optimization and simple Quality of Service scores for end-users. |
| | An Algorithm for Computing Dynamic Flooding Topologies |
| |
|
Link-state routing protocols suffer from excessive flooding in dense network topologies. Dynamic flooding [I-D.ietf-lsr-dynamic-flooding] alleviates the problem by decoupling the flooding topology from the physical topology. Link-state protocol updates are flooded only on the sparse flooding topology while data traffic is still forwarded on the physical topology. This document describes an algorithm to obtain a sparse subgraph from a dense graph. The resulting subgraph has certain desirable properties and can be used as a flooding topology in dynamic flooding. This document discloses the algorithm that we have developed in order to make it easier for other developers to implement similar algorithms. We do not claim that our algorithm is optimal, rather it is a pragmatic effort and we expect that further research and refinement can improve the results. We are not proposing that this algorithm be standardized, nor that the working group use this as a basis for further standardization work, however we have no objections if the working group chooses to do so. |
| | AI Content Disclosure Header |
| |
|
This document proposes a machine-readable Hypertext Transfer Protocol (HTTP) response header field, AI-Disclosure, to disclose the presence and degree of Artificial Intelligence (AI) generated or AI-assisted content in web responses. The header is designed for compatibility with HTTP structured field syntax and provides metadata for user agents, bots, and archiving systems. It supports layered disclosure strategies alongside human-readable and structured metadata formats. |
| | OAuth 2.0 JWT Authorization Grant with DPoP Binding |
| |
|
This specification defines a new OAuth 2.0 authorization grant type that uses a JSON Web Token (JWT) assertion to request an access token that is bound to a specific key using the Demonstration of Proof-of- Possession (DPoP) mechanism. This provides a higher level of security than a simple bearer token, as the client must prove possession of the key to use the access token. |
| | Agent Gateway Intercommunication Framework |
| |
|
This document defines the framework and requirements for intercommunication between Agent Gateways (AGw) in the Agent Internet (IoA) ecosystem. It specifies a hierarchical layered model, functional components, protocol requirements and deployment consideration for AGw interconnection. The framework aims to address data synchronization, protocol compatibility, and security challenges in cross-domain agent collaboration, enabling efficient and scalable communication for distributed intelligent agents. It is compatible with existing IoA reference architectures while specializing in cross-domain gateway interoperability. |
| | The MyClerk Protocol: Tiered Security Communication for Distributed Family Systems |
| |
|
This document specifies the MyClerk Protocol, a tiered-security communication protocol designed for distributed family orchestration systems. The protocol provides six security tiers ranging from 1-byte minimal overhead for tunneled messages to 144-byte full security for critical operations. It supports multiple transport mechanisms including NATS, Matrix, WebSocket, and direct TCP, while maintaining end-to-end encryption using ChaCha20-Poly1305 and X25519 key exchange. The protocol is transport-agnostic, federation-capable, and optimized for environments ranging from resource-constrained IoT devices to full-featured desktop clients. |
| | Autocrypt v2 OpenPGP Certificates and Transferable Secret Keys |
| |
|
This document describes the "Autocrypt v2 Certificate", a standard structure for an OpenPGP certificate for Internet messaging. It offers defense against store-now-decrypt-later attacks from quantum computers through post-quantum hybrid cryptography. It also enables reliable deletion ("Forward Secrecy") of received messages even when adversaries capture encrypted messages in transit and later compromise the user's message archive and secret keys. The design uses deterministically ratcheted rotating encryption subkeys with predictable expiration combined with coordinated secret key material destruction. This document also describes the structure, use, and maintenance of the OpenPGP Transferable Secret Key that corresponds with the Autocrypt v2 Certificate. |
| | RFC9583 Clock Sync is not a valid Quantum-Internet Application |
| |
|
This internet draft is a critique of RFC 9583, "Application Scenarios for the Quantum Internet". Section 3.2 of that document presents network clock synchronization as application for quantum internet. The present internet draft argues why it is not. |
| | Token Status List (TSL) |
| |
|
This specification defines a status mechanism called Token Status List (TSL), data structures and processing rules for representing the status of tokens secured by JSON Object Signing and Encryption (JOSE) or CBOR Object Signing and Encryption (COSE), such as JWT, SD-JWT, CBOR Web Token, and ISO mdoc. It also defines an extension point and a registry for future status mechanisms. |
| | Distributed Aggregation Protocol for Privacy Preserving Measurement |
| |
| | draft-ietf-ppm-dap-17.txt |
| | Date: |
30/01/2026 |
| | Authors: |
Tim Geoghegan, Christopher Patton, Brandon Pitman, Eric Rescorla, Christopher Wood |
| | Working Group: |
Privacy Preserving Measurement (ppm) |
|
There are many situations in which it is desirable to take measurements of data which people consider sensitive. In these cases, the entity taking the measurement is usually not interested in people's individual responses but rather in aggregated data. Conventional methods require collecting individual responses and then aggregating them on some server, thus representing a threat to user privacy and rendering many such measurements difficult and impractical. This document describes a multi-party Distributed Aggregation Protocol (DAP) for privacy preserving measurement which can be used to collect aggregate data without revealing any individual contributor's data. |
| | SCHClet - Modular Use of the SCHC Framework |
| |
| | draft-ietf-schc-schclet-00.txt |
| | Date: |
30/01/2026 |
| | Authors: |
Alexander Pelov, Quentin Lampin, Marion Dumay |
| | Working Group: |
Static Context Header Compression (schc) |
|
This document introduces the concept of a SCHClet: a modular sub- function within the SCHC (Static Context Header Compression) framework. Inspired by chiplet architectures in hardware design, a SCHClet encapsulates a specific SCHC function—such as compression, fragmentation, or acknowledgments—as a self-contained unit. This modularization enables tailored implementations that avoid the overhead of deploying a full SCHC stack. By decomposing SCHC functionality into SCHClets, the framework becomes more adaptable, extensible, and suitable for a wider range of network environments—including, but not limited to, constrained networks. A system using SCHClets remains compliant with the SCHC framework and can interoperate with a full SCHC implementation, provided compatible configuration parameters are used. Each SCHClet is defined by the SCHC Profiles and configuration parameters necessary for interoperability. It operates within a single Stratum and a single SCHC Instance. For example, a device may implement only the NoAck fragmentation mode as a standalone SCHClet, potentially with fixed parameters. This modular approach simplifies development, reduces resource demands, and provides a framework for future extensibility of the SCHC architecture. |
| |
|
| |
| | Automated Certificate Management Environment (ACME) Device Attestation Extension |
| |
|
This document specifies new identifiers and a challenge for the Automated Certificate Management Environment (ACME) protocol which allows validating the identity of a device using attestation. |
| | Group Communication for the Constrained Application Protocol (CoAP) |
| |
|
The Constrained Application Protocol (CoAP) is a web transfer protocol for constrained devices and constrained networks. In a number of use cases, constrained devices often naturally operate in groups (e.g., in a building automation scenario, all lights in a given room may need to be switched on/off as a group). This document specifies the use of CoAP for group communication, including the use of UDP/IP multicast as the default underlying data transport. Both unsecured and secured CoAP group communication are specified. Security is achieved by use of the Group Object Security for Constrained RESTful Environments (Group OSCORE) protocol. The target application area of this specification is any group communication use cases that involve resource-constrained devices or networks that support CoAP. This document replaces and obsoletes RFC 7390, while it updates RFC 7252 and RFC 7641. |
| | Using the Extensible Authentication Protocol (EAP) with Ephemeral Diffie-Hellman over COSE (EDHOC) |
| |
| | draft-ietf-emu-eap-edhoc-07.txt |
| | Date: |
29/01/2026 |
| | Authors: |
Dan Garcia-Carrillo, Rafael Marin-Lopez, Goeran Selander, John Mattsson, Francisco Lopez |
| | Working Group: |
EAP Method Update (emu) |
|
The Extensible Authentication Protocol (EAP), defined in RFC 3748, provides a standard mechanism for support of multiple authentication methods. This document specifies the EAP authentication method EAP- EDHOC, based on Ephemeral Diffie-Hellman Over COSE (EDHOC). EDHOC is a lightweight security handshake protocol, enabling authentication and establishment of shared secret keys suitable in constrained settings. This document also provides guidance on authentication and authorization for EAP-EDHOC. |
| | LEDBAT++: Congestion Control for Background Traffic |
| |
|
This memo describes LEDBAT++, a set of enhancements to the LEDBAT (Low Extra Delay Background Transport) congestion control algorithm for background traffic. The LEDBAT congestion control algorithm has several shortcomings that prevent it from working effectively in practice. LEDBAT++ extends LEDBAT by adding a set of improvements, including reduced congestion window gain, modified slow-start, multiplicative decrease and periodic slowdowns. This set of improvement mitigates the known issues with the LEDBAT algorithm, such as latency drift, latecomer advantage and inter-LEDBAT fairness. LEDBAT++ has been implemented as a TCP congestion control algorithm in the Windows operating system. LEDBAT++ has been deployed in production at scale on a variety of networks and been experimentally verified to achieve the original stated goals of LEDBAT. This document is a product of the Internet Congestion Control Research Group (ICCRG) of the Internet Research Task Force (IRTF). |
| | Use of SHA-3 in the Internet Key Exchange Protocol Version 2 (IKEv2) and IPsec |
| |
|
This document specifies the use of KMAC128 and KMAC256 within the Internet Key Exchange Version 2 (IKEv2), Encapsulating Security Payload (ESP), and Authentication Header (AH) protocols. These algorithms can be used as integrity protection algorithms for ESP, AH and IKEv2, and as Pseudo-Random Functions (PRFs) for IKEv2. Requirements for supporting signature algorithms in IKEv2 that use SHA3-256, SHA3-384, SHA3-512, SHAKE128 and SHAKE256 are also specified. |
| | 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. |
| | PCEP Extension for Bounded Latency |
| |
|
In certain networks, such as Deterministic Networking (DetNet), it is required to consider the bounded latency for path selection. This document describes the extensions for Path Computation Element Communication Protocol (PCEP) to carry the bounded latency constraints and distribute deterministic paths for end-to-end path computation in deterministic services. |
| | Distribution of Service Metadata in BGP-LS |
| |
|
In edge computing, a service may be deployed on multiple instances within one or more sites, called edge service. The edge service is associated with an ANYCAST address in the IP layer, and the route of it with potential service metadata will be distributed to the network. The Edge Service Metadata can be used by ingress routers to make path selections not only based on the routing cost but also the running environment of the edge services. The service route with metadata can be collected by a PCE(Path Compute Element) or an analyzer for calculating the best path to the best site/instance. This draft describes a mechanism to collect information of the service routes and related service metadata in BGP-LS. |
| | IOAM network awareness for Low Latency,Low Loss,and Scalable Throughput (L4S) |
| |
| | draft-quan-l4s-ioam-01.txt |
| | Date: |
29/01/2026 |
| | Authors: |
Wei Quan, Wei Su, Shuaihao Pan, Xiaobin Liang, Jie Liang |
| | Working Group: |
Individual Submissions (none) |
|
This specification defines a framework how to update L4S Dual-Queue Coupled AQM with In Situ Operations, Administration, and Maintenance (IOAM). These are designed for consistently very low queuing latency, very low congestion loss, and scaling of perflow throughput by using Explicit Congestion Notification (ECN) using the operational and telemetry information collected by IOAM. Since L4S lacks information about the use of network status and network nodes, which also affect network performance in practice, it is considered to use direct export mode for information collection of L4S-IOAM to strengthen the AQM regulation of L4S. It then gives the normative requirements that are necessary. |
| | Source Prefix Advertisement for Intra-domain SAVNET |
| |
|
This document describes a mechanism for intra-domain source address validation (SAV), called Source Prefix Advertisement (SPA) for Intra- domain SAVNET (Intra-domain SPA). The mechanism enables intra-domain routers to generate accurate SAV rules by leveraging routing information together with SAV-specific information, including Source Entity Identifiers (SEIs) and Hidden Prefix (HP). Intra-domain SPA improves the precision and reliability of source address validation, addressing challenges such as asymmetric routing and the use of hidden prefixes by legitimate source entities. |
| | IS-IS,OSPF and BGP-LS Traffic Engineering and Flexible Algorithm Extensions for Utilizing Bit Error Rate Metrics |
| |
|
This document describes extensions to IS-IS, OSPF, and BGP-LS Traffic Engineering to distribute the Bit Error Rate (BER) and Packet Error Rate (PER) metrics for the links that can be used for flexible algorithm and path selection purpose. Note that this document only covers the mechanisms with which network-performance information is distributed. The mechanisms for measuring network performance or acting on that information, once distributed, are outside the scope of this document. |
| | Extensions to the Path Computation Element Communication Protocol (PCEP) for Utilizing Bit Error Rate (BER) Metrics |
| |
|
IGP Traffic Engineering (TE) Metric Extensions describe mechanisms with which network performance information is distributed via OSPF IS-IS, and BGP-LS, respectively. The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Client (PCC) requests. This document describes the extension to PCEP to utilize Bit Error Rate (BER) and Packet Error Rate (PER) as constraints for end-to-end path computation. |
| | A Profile for Traffic Origin Authorizations (TOAs) |
| |
| | draft-qin-savnet-toa-01.txt |
| | Date: |
29/01/2026 |
| | Authors: |
Lancheng Qin, Ben Maddison, Dan Li, Igor Lubashev |
| | Working Group: |
Individual Submissions (none) |
|
This document defines a standard profile for Traffic Origin Authorizations (TOAs), a Cryptographic Message Syntax (CMS) protected content type for use with the Resource Public Key Infrastructure (RPKI). A TOA is a digitally signed object that provides a means of verifying that an IP address block holder has authorized an Autonomous System (AS) to originate traffic using source IP addresses within the address block. |
| | Verifiable AI Refusal Events using SCITT |
| |
|
This document defines a claim set for recording AI content refusal events. The claim set specifies the semantic content and correlation rules for refusal audit trails, independent of any particular serialization format. The claims are designed to be carried within SCITT Signed Statements and verified using SCITT Receipts. This specification addresses claim semantics and verification requirements; it does not mandate a specific encoding. A CDDL definition is provided for CBOR-based implementations, and equivalent JSON representations are shown in an appendix for illustration. This specification provides auditability of logged refusal decisions. It does not define content moderation policies, classification criteria, or what AI systems should refuse. |
| | Agent Collaboration Protocols Architecture for Internet of Agents |
| |
|
Internet of Agents (IoA) aims to facilitate interconnection and collaboration among heterogeneous agents to address complex tasks and support diverse applications. This IETF draft proposes the Agent Collaboration Protocols (ACPs) architecture, which includes conceptual domains, functional components and reference interfaces, to achieve agent interconnection and collaboration. ACPs cover all stages of agents in the network, from their access to collaboration, supporting agent trusted registration, agent identity authentication, agent discovery, agent interaction, tool invocation, and agent monitoring. The long-term vision of ACPs is to support the future large-scale interconnected agents and construct the key infrastructure for IoA. |
| | Network Service Type-Aware Traffic Labeling Protocol (NST-TLP) |
| |
|
This document specifies a protocol mechanism for embedding service type identifiers into network packets in order to enable intelligent traffic recognition, policy-based forwarding, and resource optimization by network devices. The protocol allows standardized service type labels to be carried in IPv4/IPv6 headers, MPLS labels, or Ethernet frame headers. It is applicable to a wide range of services, including immersive VR (e.g., 1080p, 4K), scientific computing, real-time communications, and Internet of Things (IoT) applications. |
| | Protocol Architects Are Not the Creators of the Internet |
| |
|
TCP/IP standardized interoperability and end to end transport semantics. The World Wide Web standardized publishing and retrieval. Neither TCP/IP nor the Web specifies, provisions, or enforces the path properties required for utility grade Internet operation at scale. This memo defines terminology to distinguish interoperability standards from utility grade operation and specifies operational requirements for “infrastructure activation”: provisioned transport, interconnection strategy, routing policy control, redundancy, locality, continuous monitoring, incident response, and enforceable service accountability. This memo proposes no protocol changes. Figure 1. Three layer model. Protocols enable interoperability. The Web enables publishing. Utility grade Internet behavior requires infrastructure activation. |
| | Content Provenance Profile (CPP) Core |
| |
|
The Content Provenance Profile (CPP) is an open specification for cryptographically verifiable media capture provenance. This document defines the core data model, hashing conventions, Merkle tree construction rules, RFC 3161 Time-Stamp Authority (TSA) anchoring protocol, and offline verification procedures for CPP. CPP enables capture devices to produce tamper-evident provenance records that bind media content to external timestamps via trusted third parties. Unlike self-attestation models, CPP requires independent timestamp verification through RFC 3161 TSA services, providing externally verifiable proof of when media was captured. This specification focuses on the interoperable core of CPP: the data structures, cryptographic operations, and verification algorithms necessary for independent third-party verification. Application- specific features such as depth analysis are defined as optional extensions. |
| | Considerations for On-Demand Retrieval of Multiple RPKI Object Types |
| |
|
The Resource Public Key Infrastructure (RPKI) RFC6480 [RFC6481] relies on Publication Points (PPs) to distribute cryptographically verifiable objects. Under the current design, Relying Parties (RPs) retrieve the complete set of RPKI objects from repositories, even when their operational requirements are limited to a specific subset, for example, ROAs only. This all-or-nothing retrieval model may result in increased bandwidth consumption, higher synchronization latency, and unnecessary computational overhead. This document examines these challenges and discusses directions for enabling more selective and efficient access to RPKI data. |
| |
|
| |
| | RTP Payload Format for Visual Volumetric Video-based Coding (V3C) |
| |
|
A visual volumetric video-based coding (V3C) ISO/IEC 23090-5 bitstream is composed of V3C units that contain V3C atlas sub- bitstreams, V3C video sub-bitstreams, and a V3C parameter set. This memo describes an RTP payload format for V3C atlas sub-bitstreams. The RTP payload format for V3C video sub-bitstreams is defined by relevant IETF RFC for the applicable video codec. The V3C RTP payload format allows for packetization of one or more V3C atlas Network Abstraction Layer (NAL) units in an RTP packet payload as well as fragmentation of a V3C atlas NAL unit into multiple RTP packets. The memo also describes the mechanisms for grouping RTP streams of V3C component sub-bitstreams, providing a complete solution for streaming V3C encoded content. |
| | CDNI Delivery Metadata |
| |
|
This specification adds to the core set of configuration metadata defined in RFC8006, providing delivery metadata to define traffic types, request delegation behavior and CDN transport arrangements selection of a downstream CDN. |
| | Pacing in Transport Protocols |
| |
| | draft-irtf-iccrg-pacing-01.txt |
| | Date: |
28/01/2026 |
| | Authors: |
Michael Welzl, Wesley Eddy, Vidhi Goel, Michael Tuexen |
| | Working Group: |
Internet Congestion Control (iccrg) |
|
Applications or congestion control mechanisms can produce bursty traffic which can cause unnecessary queuing and packet loss. To reduce the burstiness of traffic, the concept of evenly spacing out the traffic from a data sender over a round-trip time known as "pacing" has been used in many transport protocol implementations. This document gives an overview of pacing and how some known pacing implementations work. |
| | Advertising Unreachable Links in OSPF |
| |
|
In certain scenarios, it is necessary to advertise OSPF links that are not applicable to the default SPF (Shortest Path First) calculation for other purposes. In order to advertise these links and not use them in the base SPF calculation, the metric LSLinkInfinity (0xffff) is used to specify that the link is unreachable. MaxReachableLinkMetric (0xfffe) is defined to provide backward compatible reachability in specifications that previously specified advertisement of MaxLinkMetric (0xffff). This document updates RFC 5443, RFC 6987, and RFC 8770 with respect to the advertisement of MaxReachableLinkMetric (0xfffe) rather than MaxLinkMetric (0xffff). |
| | UDP-based Transport for Configured Subscriptions |
| |
| | draft-ietf-netconf-udp-notif-25.txt |
| | Date: |
28/01/2026 |
| | Authors: |
Alex Feng, Pierre Francois, Tianran Zhou, Thomas Graf, Paolo Lucente |
| | Working Group: |
Network Configuration (netconf) |
|
This document describes a UDP-based transport for YANG notifications to collect data from network nodes within a controlled environment. A shim header is defined to facilitate the data streaming directly from a publishing process on a network device to telemetry receivers. Such a design enables higher frequency updates and less performance overhead on publisher and receiver processes compared to already established notification mechanisms. A YANG data model is also defined for management of the described UDP-based transport. |
| | System-defined Configuration |
| |
|
The Network Management Datastore Architecture (NMDA) in RFC 8342 defines several configuration datastores holding configuration. The contents of these configuration datastores are controlled by clients. This document introduces the concept of system configuration datastore holding configuration controlled by the system on which a server is running. The system configuration can be referenced (e.g., leafref) by configuration explicitly created by clients. This document updates RFC 8342. |
| | BGP Neighbor Discovery |
| |
|
BGP is being used as the underlay routing protocol in some large- scaled data centers (DCs). Most popular design followed is to do hop-by-hop external BGP (EBGP) session configurations between neighboring routers on a per link basis. The provisioning of BGP neighbors in routers across such a DC brings its own operational complexity. This document introduces a BGP neighbor discovery mechanism that greatly simplifies BGP operations in such DC and other networks by automatic setup of BGP sessions between neighbor routers using this mechanism. |
| | Encryption algorithm Rocca-S |
| |
| | draft-nakano-rocca-s-06.txt |
| | Date: |
28/01/2026 |
| | Authors: |
Yuto Nakano, Kazuhide Fukushima, Takanori Isobe |
| | Working Group: |
Individual Submissions (none) |
|
This document defines Rocca-S encryption scheme, which is an Authenticated Encryption with Associated Data (AEAD), using a 256-bit key and can be efficiently implemented utilizing the AES New Instruction set (AES-NI). |
| | AS2 Specification Modernization |
| |
|
This document provides an applicability statement (RFC 2026, Section 3.2) describing how to securely exchange structured business data over HTTP. Structured business data may be XML; Electronic Data Interchange (EDI) in either the American National Standards Committee (ANSI) X12 format or the UN Electronic Data Interchange for Administration, Commerce, and Transport (UN/EDIFACT) format; or other structured data formats. The data is packaged using standard MIME structures. Authentication and data confidentiality are obtained by using Cryptographic Message Syntax with S/MIME security body parts (see Section 10.1). Authenticated acknowledgements make use of multipart/signed Message Disposition Notification (MDN) responses to the original HTTP message. This applicability statement is informally referred to as "AS2" because it is the second applicability statement, produced after "AS1" (RFC 3335). This document obsoletes RFC 4130 and stands on its own without reference to AS1 or SMTP, except where required for IANA registry updates. This document also updates IANA registries originally created by RFC 3335 and RFC 4130. |
| | Internet of Agents Task Protocol (IoA Task Protocol) for Heterogeneous Agent Collaboration |
| |
|
This draft defines a new agent collaboration protocol, named the Internet of Agents Task Protocol (IoA Task Protocol), to support distributed, heterogeneous agent collaboration in intelligent systems. The IoA Task Protocol enables dynamic team formation, adaptive task coordination, and structured communication among agents with diverse architectures, tools, and knowledge sources. Through a layered architecture and extensible message format, it supports decentralized deployment across devices and can interoperate with existing frameworks. The protocol is particularly suited to large- scale intelligent collaboration scenarios—such as intelligent transportation, smart healthcare, and large-scale human–AI teaming—across heterogeneous network environments, including fixed networks, edge–cloud infrastructures, and emerging mobile networks such as 6G. |
| | SRv6 Segment Identifier Compression for Satelite Networks |
| |
|
This document defines a compression method for Segment Identifiers (SIDs) in Segment Routing over IPv6 (SRv6) specifically designed for satellite networks. By leveraging the topological location information of satellite nodes, a 128-bit SID is compressed into a 32-bit Compressed SID (C-SID). The method introduces a "SID Container" structure to support the co-existence of 128-bit SIDs and 32-bit C-SIDs within a single Segment List without modifying the SRv6 control plane or the fixed SRH header format defined in RFC 8754. |
| | DNS Extensions to Energy Efficiency as Service(EEAS) |
| |
|
This document describes a new Mechanism and DNS resource record (RR) type to carry information about energy-related characteristics for end-to-end internet access. The "EE" ("Energy Efficiency") record allows the network to provide different levels of energy-saving service. By providing more energy information to the client before it attempts to establish a connection, these records offer potential benefits to enhancements on energy as service criteria. |
| | Guidelines for Characterizing the Term "OAM" |
| |
|
As the IETF continues to produce and standardize different Operations, Administration, and Maintenance (OAM) protocols and technologies, various qualifiers and modifiers are prepended to the OAM abbreviation. While, at first glance, the most used appear to be well understood, the same qualifier may be interpreted differently in different contexts. A case in point is the qualifiers "in-band" and "out-of-band" which have their origins in the radio lexicon, and which have been extrapolated into other communication networks. This document recommends not to use these two terms when referring to OAM. This document considers some common qualifiers and modifiers that are prepended, within the context of packet networks, to the OAM abbreviation and lays out guidelines for their use in IETF documents. This document extends RFC 6291 by adding to the guidelines for the use of the term "OAM" with qualifiers. It does not modify any part of RFC 6291. |
| | GLobal Unique Enterprise (GLUE) Identifiers |
| |
| | draft-ietf-spice-glue-id-04.txt |
| | Date: |
28/01/2026 |
| | Authors: |
Brent Zundel, Pamela Dingle, Michael Jones |
| | Working Group: |
Secure Patterns for Internet CrEdentials (spice) |
|
This specification establishes a URN namespace for GLobal Unique Enterprise (GLUE) Identifiers. This enables URN identifiers to be used for businesses and organizations. It enables organizational identities from existing authorities to be represented within this URN namespace. |
| | Circuit Style Segment Routing Policy |
| |
| | draft-ietf-spring-cs-sr-policy-14.txt |
| | Date: |
28/01/2026 |
| | Authors: |
Christian Schmutzer, Zafar Ali, Praveen Maheshwari, Reza Rokui, Andrew Stone |
| | Working Group: |
Source Packet Routing in Networking (spring) |
|
This document describes how Segment Routing (SR) policies can be used to satisfy the requirements for bandwidth, end-to-end recovery and persistent paths within a SR network. The association of two co- routed unidirectional SR Policies satisfying these requirements is called "Circuit Style" SR Policy (CS-SR Policy). |
| |
|
| |
| | A Voucher Artifact for Bootstrapping Protocols |
| |
| | draft-ietf-anima-rfc8366bis-25.txt |
| | Date: |
27/01/2026 |
| | Authors: |
Kent Watsen, Michael Richardson, Esko Dijk, Toerless Eckert, Qiufang Ma |
| | Working Group: |
Autonomic Networking Integrated Model and Approach (anima) |
|
This document defines a strategy to securely assign a Pledge to an Owner using an artifact signed, directly or indirectly, by the Pledge's manufacturer. This artifact is known as a "Voucher". This document defines an artifact format as a YANG-defined JSON or CBOR document that has been signed using a variety of cryptographic systems. The Voucher Artifact is normally generated by the Pledge's manufacturer (i.e., the Manufacturer Authorized Signing Authority (MASA)). This document updates RFC8366: it includes a number of desired extensions into the YANG module. The Voucher Request YANG module defined in RFC8995 is also updated and now included in this document, as well as other YANG extensions needed for variants of BRSKI/ RFC8995. |
| | CBOR Serialization and Determinism |
| |
|
This document defines two CBOR serializations: "ordinary serialization" and "deterministic serialization." It also introduces the term "general serialization" to name the full, variable set of serialization options defined in [STD94]. Together, these three form a complete set of serializations that cover the majority of CBOR serialization use cases. These serializations are largely compatible with those widely implemented by the CBOR community. |
| | CDNI Edge Control Metadata |
| |
|
This specification defines configuration metadata objects related to controlling edge access to resources via content delivery networks (CDNs) and Open Caching systems. Configuring Cross-Origin Resource Sharing (CORS) access rules and the dynamic generation of CORS headers is a key feature of typical configurations, as are the ability to define response body compression rules and client connection timeouts. |
| | Hybrid PQ/T Key Encapsulation Mechanisms |
| |
|
This document defines generic constructions for hybrid Key Encapsulation Mechanisms (KEMs) based on combining a post-quantum (PQ) KEM with a traditional cryptographic component. Hybrid KEMs built using these constructions provide strong security properties as long as either of the underlying algorithms are secure. |
| | Extended Communities Derived from Route Targets |
| |
|
This document specifies a way to derive an Extended Community from a Route Target and describes some example use cases. |
| | MTU propagation over EVPN Overlays |
| |
|
Path MTU Discovery between end-host-devices/Virtual-Machines/servers/ workloads connected over an EVPN-Overlay Network in Datacenter/Campus/enterprise deployment, is a problem, yet to be resolved in the standards forums. It needs a converged solution to ensure optimal usage of network and computational resources of the networking elements, including underlay routers/switches, constituting the overlay network. This documents takes leads from the guidelines presented in [RFC4459]. The overlay connectivity can pan across various sites (geographically seperated or collocated) for realizing a Datacenter Interconnect or intersite VPNs between campus sites (buildings, branch offices etc). This literature intends to solve problem of icmp error propagation from an underlay routing/switching device to an end-host (hooked to EVPN overlay), thus facilitating "accurate MTU" learnings. This document also leverages the icmp multipart message extension, mentioned in [RFC4884] to carry the original packet in the icmp PDU. |
| | BGP-LS extensions for BIER-TE |
| |
|
BIER-TE forwards and replicates packets based on a BitString in the packet header, but every BitPosition of the BitString of a BIER-TE packet indicates one or more adjacencies. BGP Link-State (BGP-LS) enables the collection of various topology informations from the network, and the topology informations are used by the PCE to calculate the path and then propagate them onto the BFRs(instead of having each node to calculate on its own) and that can be for both inter-as and intra-as situations. This document specifies extensions to the BGP Link-state address- family in order to advertise BIER-TE informations. |
| | All PEs as DF |
| |
|
The Designated forwarder concept is leveraged to prevent looping of BUM traffic into tenant network sourced across NVO fabric for multihoming deployments. [RFC7432] defines a preliminary approach to select the DF for an ES,VLAN or ES,Vlan Group, panning across multiple NVE's. [RFC8584] makes the election logic more robust and fine grained by inculcating fair election of DF handling most of the prevalent use-cases. This document presents a deployment problem and a corresponding solution which cannot be easily resolve by rules mentioned in [RFC7432] and [RFC8584]. It involves redundant firewall deployment on disparate overlay sites connected over WAN. The requirement is to allow reachability, ONLY, to the local firewall, unless there is an outage. In case of outage the reachability can be extended to remote site's firewall over WAN. |
| | Open Ethics Transparency Protocol |
| |
|
The Open Ethics Transparency Protocol (OETP) is an application-level protocol for publishing and accessing ethical Disclosures of IT Products and their Components. The Protocol is based on HTTP exchange of information about the ethical "postures", provided in an open and standardized format. The scope of the Protocol covers Disclosures for systems such as Software as a Service (SaaS) Applications, Software Applications, Software Components, Application Programming Interfaces (API), Automated Decision-Making (ADM) systems, and systems using Artificial Intelligence (AI). OETP aims to bring more transparent, predictable, and safe environments for the end-users. The OETP Disclosure Schema is an extensible JSON-based format. |
| | Secure IP Binding Synchronization via BGP EVPN |
| |
|
The distribution of clients of L2 domain across extended, networks leveraging overlay fabric, needs to deal with synchronizing the Client Binding Database. The 'Client IP Binding' indicates the IP, MAC and VLAN details of the clients that are learnt by security protocols. Since learning 'Client IP Binding database' is last mile solution, this information stays local to the end point switch, to which clients are connected. When networks are extended across geographies, that is, both layer2 and layer3, the 'Client IP Binding Database' in end point of switches of remote fabrics should be in sync. This literature intends to align the synchronization of 'Client IP Binding Database" through an extension to BGP control plane constructs and as BGP is a typical control plane protocol configured to communicate across network boundries. |
| | Secure Asset Transfer Protocol (SATP) Gateway Crash Recovery Mechanism |
| |
|
This memo describes the crash recovery mechanism for the Secure Asset Transfer Protocol (SATP). The goal of this draft is to specify the message flow that implements a crash recovery mechanism, composed of self-healing and rollback sub-protocols. The mechanism assures that gateways running SATP are able to recover faults, enforcing ACID properties for asset transfers across ledgers (i.e., double spend does not occur). |
| | Signaling MNA Capability Using IGP and BGP-LS |
| |
|
This document defines a mechanism to signal MNA Capability using IGP and Border Gateway Protocol-Link State(BGP-LS). |
| | SRv6 NET-PGM extension: Compressed BSID Insertion |
| |
|
The End.B6.Insert and End.B6.Insert.Red SHOULD support the NEXT-C-SID flavor either individually or in combinations. This document defines the SRH processing of the End.B6.Insert and End.B6.Insert.Red with NEXT-C-SID flavor. |
| | Broadband Network UP-Specific Information Suboption for the DHCP Relay Agent Option |
| |
|
This document defines a new Broadband Network UP-Specific Information suboption for the Dynamic Host Configuration Protocol’s (DHCP) relay agent information option. The suboption allows the DHCP relay agent (Broadband Network CP) to include UP-specific information in the DHCP messages it forwards, to ensure that subscribers within the same SGRP under the same UP are assigned IP addresses from the same address space by the DHCP server. |
| | Available Session Recovery Protocol |
| |
| | draft-cmcc-asrp-05.txt |
| | Date: |
27/01/2026 |
| | Authors: |
Zhaoyu Luo, Haishuang Yan |
| | Working Group: |
Individual Submissions (none) |
|
This document describes an experimental protocol named the Available Session Recovery Protocol (ASRP). The protocol is designed to optimize high-availability network cluster architectures, providing a superior high-availability solution for clusters offering stateful network services such as load balancing and Network Address Translation (NAT [RFC4787]). ASRP defines the procedures for session backup and recovery, as well as the message formats used during these interactions, enabling efficient and streamlined session state management. In contrast to traditional high-availability techniques that back up session state within the cluster itself, the core innovation of ASRP lies in its distributed backup of state information to the client or server side. This approach offers multiple advantages: it significantly enhances the cluster's elastic scaling capabilities; supports rapid recovery from single-point or even multi-point failures; reduces resource redundancy by eliminating centralized backup nodes; and substantially simplifies the implementation complexity of the cluster. The ASRP protocol provides exceptional elastic scalability for network clusters, facilitating the implementation and deployment of large-scale elastic network clusters. |
| | Domain Name System (DNS) Public Key Based Request and Transaction Authentication (SIGZERO,SIG(0)) |
| |
|
This document specifies use of the SIGZERO and SIG(0) Domain Name System (DNS) Resource Records (RRs) to provide public key based authentication of DNS requests and transactions. This document obsoletes RFC 2931. |
| | SCONE Applicability for IEEE 802.11 Access Networks |
| |
|
This document describes the applicability of the Standard Communication with Network Elements (SCONE) protocol to IEEE 802.11 based access networks. SCONE defines a mechanism by which an on-path network element can provide advisory downlink throughput guidance to QUIC endpoints. The SCONE protocol is access agnostic and does not assume any specific access technology. In IEEE 802.11 deployments, such constraints may be derived at access points or controllers that combine policy awareness, with visibility into access network conditions. This document explains how existing SCONE roles and throughput advice semantics apply in these deployments without assuming any specific IEEE 802.11 MAC or PHY behavior. This document does not define new protocol extensions and does not modify SCONE behavior. Its purpose is to clarify deployment considerations for IEEE 802.11 environments. |
| | Mathematical notation in RFCs |
| |
|
This document defines policy and allows new technology for the representation of mathematical notation in RFCXML and relevant publication formats. After implementation of this policy, mathematical notation in RFCXML and the HTML publication format will no longer be accepted in Unicode or Scalable Vector Graphics (SVGs). |
| | Privacy Pass Issuance Protocol for Anonymous Rate-Limited Credentials |
| |
|
This document specifies the issuance and redemption protocols for tokens based on the Anonymous Rate-Limited Credential (ARC) cryptographic protocol. |
| | EAT Attestation Results |
| |
| | draft-ietf-rats-ear-02.txt |
| | Date: |
27/01/2026 |
| | Authors: |
Thomas Fossati, Eric Voit, Sergei Trofimov, Henk Birkholz |
| | Working Group: |
Remote ATtestation ProcedureS (rats) |
|
This document defines the EAT Attestation Result (EAR) message format. EAR is used by a verifier to encode the result of the appraisal over an attester's evidence. It embeds an AR4SI's "trustworthiness vector" to present a normalized view of the evaluation results, thus easing the task of defining and computing authorization policies by relying parties. Alongside the trustworthiness vector, EAR provides contextual information bound to the appraisal process. This allows a relying party (or an auditor) to reconstruct the frame of reference in which the trustworthiness vector was originally computed. EAR supports simple devices with one attester as well as composite devices that are made of multiple attesters, allowing the state of each attester to be separately examined. EAR can also accommodate registered and unregistered extensions. It can be serialized and protected using either CWT or JWT. |
| | RDAP Extensions |
| |
|
This document describes and clarifies the usage of extensions in RDAP. |
| | RDAP Extension for DNS Time-To-Live (TTL Values) |
| |
|
This document describes an extension to the Registration Data Access Protocol 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. |
| |
|
| |
| | PQ/T Hybrid Composite Signatures for JOSE and COSE |
| |
|
This document describes JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE) serializations for PQ/T hybrid composite signatures. The composite algorithms described combine ML-DSA as the post-quantum component and either ECDSA or EdDSA as the traditional component. |
| | Delay Options |
| |
|
This document introduces new IPv6 options for HBH or DOH Options header, to carry delay related information for deterministic forwarding. |
| | Computing-Aware Traffic Steering (CATS) Operations,Administration,and Maintenance (OAM) Framework |
| |
| | draft-fu-cats-oam-fw-05.txt |
| | Date: |
26/01/2026 |
| | Authors: |
FUHUAKAI, Quan Xiong, Bo Liu, Zhenqiang Li |
| | Working Group: |
Individual Submissions (none) |
|
This document describes the Operations, Administration, and Maintenance (OAM) framework and requirements for Computing-Aware Traffic Steering (CATS). The framework defines the CATS OAM layering model and functional components. It also specifies the requirements to enable fault management and performance monitoring for CATS end- to-end connections encompassing clients, network paths, and service instances. |
| | Providing DNSSD Service on Infrastructure |
| |
|
DNS Service Discovery provides several mechanisms whereby hosts can discover and advertise services on an IP network. Such discovery can be done using Multicast DNS (mDNS) or DNS, and advertising can be done with DNSSD Service Registration Protocol (SRP) or mDNS. This document describes a way to provide a unified DNSSD proxy service that allows hosts to advertise services using SRP and discover services using unicast DNS via a Discovery Proxy rather than using of mDNS, in scenarios where mDNS is currently the only option. |
| | Secure Resource Layer (SRL) Core |
| |
|
This document defines the Secure Resource Layer (SRL), a global trust layer that evaluates digital resources before they are accessed. SRL introduces governance, verification, and revocation mechanisms that complement existing URL, QR code, and short URL systems. SRL is designed to be deployable incrementally and is already being validated through live resolver deployments, without requiring changes to existing Internet standards, browsers, or operating systems. |
| | AI Governance and Accountability Protocol (AIGA) |
| |
|
This document specifies the AI Governance and Accountability (AIGA) Protocol, a practical, economically viable, and technically enforceable framework for governing autonomous AI agents. AIGA is designed to address real-world deployment constraints, adversarial agent scenarios, and economic incentive alignment. The protocol is founded on a Tiered Risk-Based Governance model, applying proportional oversight to agents based on their capabilities. All agents are governed by an Immutable Kernel Architecture which provides a non-modifiable Trusted Computing Base (TCB) for enforcing policy. This is combined with Action-Based Authorization, where critical operations require real-time approval. To solve the single-point-of-failure problem, the protocol uses a Federated Authority Network of regional, cross-validating hubs and provides a Network-Level Quarantine Protocol for enforcement. The entire framework is designed around Economic Incentive Alignment, making compliance the most economically rational choice for operators. For high-assurance (T3-T4) scenarios, AIGA specifies advanced, redundant mechanisms including Multi-Vendor TEE Attestation (M-TACE), AI "Warden Triumvirate" Triage, Human Review Board (HRB) Multi- Signature, Peer Consensus Failsafe & Identity Rotation, and Double Ratchet Cryptography. |
| | MyTerms Contract Negotiation Protocol (MCNP): Human and machine-readable agreements |
| |
|
This document covers the technical requirements of contractual interactions and agreements between individuals and the entities they engage on a network as defined in IEEE7012. It describes how individuals, acting as first parties, can proffer their privacy requirements as contractual terms and arrive at agreements recorded and kept by both sides. This includes the hosting format for contracts, negotiation of contracts, signing of contracts, and auditing of contracts. |
| | Adapting Constrained Devices for Post-Quantum Cryptography |
| |
|
This document provides guidance on integrating Post-Quantum Cryptography (PQC) into resource-constrained devices, such as IoT nodes and lightweight Hardware Security Modules (HSMs). These systems often operate with strict limitations on processing power, RAM, and flash memory, and may even be battery-powered. The document emphasizes the role of hardware security as the basis for secure operations, supporting features such as seed-based key generation to minimize persistent storage, efficient handling of ephemeral keys, and the offloading of cryptographic tasks in low-resource environments. It also explores the implications of PQC on firmware update mechanisms in such constrained systems. |
| | Static Context Header Compression and Fragmentation over networks prone to disruptions |
| |
|
This document describes the use of SCHC over different network topologies and devices regardless of their capabilities and configurations. The use of SCHC will bring connectivity to devices with disruptive connections caused by restrained use of battery and connectionless setups with long delays and latency. |
| | Guidance to Avoid Carrying RPKI Validation States in Transitive BGP Path Attributes |
| |
|
This document provides guidance to avoid carrying Resource Public Key Infrastructure (RPKI) derived Validation States in Transitive Border Gateway Protocol (BGP) Path Attributes. Annotating routes with transitive attributes signaling Validation State may cause needless flooding of BGP UPDATE messages through the global Internet routing system, for example when Route Origin Authorizations (ROAs) are issued, or are revoked, or when RPKI-To-Router sessions are terminated. Operators SHOULD ensure Validation States are not signaled in transitive BGP Path Attributes. Specifically, Operators SHOULD NOT associate Prefix Origin Validation state with BGP routes using transitive BGP Communities. |
| |
|
| |
| | 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, common certificate profiles and is extensible. Two types of C509 certificates are defined. One type is an invertible CBOR re-encoding of DER encoded X.509 certificates with the signature field copied from the DER encoding. The other type is identical except that the signature is over the CBOR encoding instead of the DER encoding, avoiding the use of ASN.1. Both types of certificates have the same semantics as X.509 and the same reduced size compared to X.509. The document also specifies CBOR encoded data structures for certificate (signing) requests and certificate request templates, new COSE headers, as well as a TLS certificate type and a file format for C509. This document updates RFC 6698; the TLSA selectors registry is extended to include C509 certificates. |
| | CCNx Content Object Chunking |
| |
|
This document specifies a chunking protocol for dividing a user payload into CCNx Content Objects. It defines a name segment type to identify each sequential chunk number and a Content Object field to identify the last available chunk number. This includes specification for the naming convention to use for the chunked payload and a field added to a Content Object to represent the last chunk of an object. This document updates RFC8569 and RFC8609. |
| | PROBE: A Utility for Probing Interfaces |
| |
| | draft-ietf-intarea-rfc8335bis-02.txt |
| | Date: |
25/01/2026 |
| | Authors: |
Bill Fenner, Ron Bonica, Reji Thomas, Jen Linkova, Chris Lenart, Mohamed Boucadair |
| | Working Group: |
Internet Area Working Group (intarea) |
|
This document describes a network diagnostic tool called PROBE. PROBE is similar to PING in that it can be used to query the status of a probed interface, but it differs from PING in that it does not require bidirectional connectivity between the probing and probed interfaces. Instead, PROBE requires bidirectional connectivity between the probing interface and a proxy interface. The proxy interface can reside on the same node as the probed interface, or it can reside on a node to which the probed interface is directly connected. This document updates RFC 4884 and obsoletes RFC 8335. |
| | Integration of Speech Codec Enhancement Methods into the Opus Codec |
| |
|
This document proposes a set of requirements for integrating a speech codec enhancement method into the Opus codec [RFC6716] |
| | Augmented-by Addition to the YANG Library |
| |
|
This document augments the ietf-yang-library to provide the augmented-by list. It facilitates the process of obtaining all dependencies between YANG modules, by querying the network management server's YANG library. This document updates RFC 8525. 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/Zephyre777/draft-lincla-netconf-yang-library- augmentation. |
| | CBOR : : Core - CBOR Cross Platform Profile |
| |
|
This document defines CBOR::Core, a platform-agnostic profile for CBOR (RFC 8949) intended to serve as a viable replacement for JSON in computationally advanced systems like Internet browsers, mobile phones, and Web servers. For enhanced strictness, as well as for enabling cryptographic methods like signing and hashing, to optionally be applied to "raw" (non-wrapped) CBOR data, deterministic encoding is mandated. Furthermore, the document outlines API features for manipulating CBOR data in a secure manner. This document mainly targets CBOR tool developers. |
| | Sub-Link Scoped IPv6 Multicast Addressing |
| |
|
The IPv6 addressing architecture for multicast has the scope of a multicast group embedded in its address, with the smallest non- reserved scopes being interface-local and link-local, numbered 1 and 2. This document suggests the introduction of a scope inbetween these two, for use with lower-layer transport multicast that reaches parts of a link. Since there is no room to insert a scope value for this, a separate address block is used. A mapping for Ethernet as lower-layer transport is provided. |
| | Using IS-IS To Advertise Power Group Membership |
| |
|
This document introduces Power Groups. A Power Group is a hierarchical abstraction of power consumed by hardware components. In IS-IS, interfaces can reference the Power Group to which they belong. Therefore, Power Groups provide a method of organizing interfaces into groups by power characteristics. The TE path placement algorithm can use Power Group membership information to implement TE policy. Power Group information is particularly useful when implementing TE policies that support power- savings and sustainability. |
| | OAuth 2.1 Government Content Access Control |
| |
|
This document defines an OAuth 2.1 profile that enables a government authority to enforce age-based and content-based access restrictions for online services while preserving user privacy. The protocol allows relying parties to request government-defined regulatory scopes (such as pornography or social media access) and receive cryptographically verifiable eligibility decisions without disclosing user identity, exact age, or personally identifiable information. The profile constrains OAuth features to prevent abuse, cross-service correlation, and unauthorized token issuance. |
| | CURE: Consent Upon Recipient Engagement |
| |
| | draft-cure-core-00.txt |
| | Date: |
25/01/2026 |
| | Authors: |
Madhu Balakrishna |
| | Working Group: |
Individual Submissions (none) |
|
This document specifies CURE (Consent Upon Recipient Engagement), a fully native, asynchronous mechanism for expressing and enforcing recipient consent in email without introducing mailbox enumeration, synchronous negotiation, or new SMTP commands. CURE does not guarantee delivery, consent, or sender legitimacy; rather, it provides a privacy-preserving signal that mailbox providers MAY use to improve enforcement and sender accountability. |
| | BGP Optional Transitive Attribute for Advertising GPU and AI Accelerator Capabilities |
| |
|
This document defines a new BGP path attribute, GPU_CAPABILITY, to allow network devices to advertise the availability, capacity, and characteristics of GPU and AI accelerators within a data center or AI fabric. This optional, transitive attribute enables schedulers, orchestration systems, and control-plane applications to discover GPU resources directly through BGP, integrating resource-awareness into routing and placement decisions. The attribute is TLV-based, extensible, and vendor-neutral. |
| | Anonymous Rate-Limited Credentials Cryptography |
| |
|
This document specifies the Anonymous Rate-Limited Credential (ARC) protocol, a specialization of keyed-verification anonymous credentials with support for rate limiting. ARC credentials can be presented from client to server up to some fixed number of times, where each presentation is cryptographically bound to client secrets and application-specific public information, such that each presentation is unlinkable from the others as well as the original credential creation. ARC is useful in applications where a server needs to throttle or rate-limit access from anonymous clients. |
| | QUIC Extension for Server-Initiated Connection Migration |
| |
|
This document specifies an extension of QUIC that allows the server to initiate connection migration. |
| | Considerations for Performing Safe Measurement on the Internet |
| |
|
Internet measurement is important to researchers from industry, academia and civil society. While measurement of the internet can give insight into the functioning and usage of the Internet, it can present risks to user privacy. This document describes briefly those risks. It also outlines considerations for researchers to reference when designing internet measurements to ensuring that those measurements can be carried out with user safety as a priority. |
| | Updates to Dynamic IPv6 Multicast Address Group IDs |
| |
|
This document describes limitations of the existing range of dynamic IPv6 multicast addresses specified in RFC3307. It recommends replacing these allocations with a new registry in the IPv6 Multicast Address Space Registry registry group. The document also suggests initial contents of the new registry: a reduced allocation for MADCAP (RFC2730), a range for SSM, a Private Use range, and Solicited-Node multicast addresses (which were not previously noted in RFC3307). |
| |
|
| |
| | 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. |
| | Enhancements to the YANG Language for Capturing Subtree Replacements |
| |
|
As YANG data models evolve over time, model nodes are often deprecated or made obsolete. Current practices for documenting replacement paths for these nodes rely on unstructured external documents, making it difficult to programmatically identify and migrate to replacement nodes. This document proposes a YANG extension mechanism that embeds replacement path information directly within YANG models, enabling automation tools to identify replacement nodes and assist users in migrating from deprecated elements to their replacements. |
| | SRv6 L3VPN Fast Reroute |
| |
|
In some multihoming SRv6 L3VPN scenarios, once fast reroute has taken place, a second fast reroute is undesirable and may cause looping. This document proposes a mechanism to prevent further fast reroutes by advertising No-Further-FRR behaviors for L3 SRv6 Service SIDs in BGP messages. |
| | YANG Message Keys for Message Broker Integration |
| |
|
This document specifies a mechanism to define a unique Message key for a YANG to Message Broker integration and a topic addressing scheme based on YANG-Push subscription type and a YANG index defined in this document. This enables YANG data consumption of a subset of subscribed YANG data, either per specific YANG node, identifier or telemetry message type, by indexing and organizing in Message Broker topics, indexing the information by using data taxonomy and organize data in partitions and shards. |
| | JIS: JTel Identity Standard |
| |
|
This document specifies JIS (JTel Identity Standard), a semantic security protocol providing identity management, trust establishment, and intent validation across multiple communication protocols. Unlike traditional security systems that react to attack patterns, JIS validates semantic intent before execution. JIS introduces FIR/A (First Initiation Revoke/Accept) for trust genesis, SNAFT for semantic firewall, BALANS for risk scoring, and Humotica for human- readable context. JIS integrates with TIBET for complete provenance tracking where audit is a precondition for behavior, not an observation of it. |
| | Agent Communication Framework for Network AIOps |
| |
|
As the development of large model and agent technology, it is a trend for multi-agent collaboration to solve complex problems. This document proposes an Agent Communication Framework, a multi-agent communication and collaboration framework that facilitates the coordination of heterogeneous multi-agents and supports intelligent network operations and maintenance (AIOps). Its architecture includes an AI gateway and an Agent Name Service, along with capabilities such as monitoring and tracking, as well as security protection. Agent Communication Framework provides a comprehensive solution for multi-agent communication and collaboration, laying the foundation for future interactive, scalable, secure, and controllable multi-agent network intelligent operations and maintenance. |
| | Transaction Tokens |
| |
|
Transaction Tokens (Txn-Tokens) are designed to maintain and propagate user identity and authorization context across workloads within a trusted domain during the processing of external requests, such as API calls. They ensure that this context is preserved throughout the call chain, even when new transactions are initiated internally, thereby enhancing security and consistency in complex, multi-service architectures. |
| | Controlling Secure Network Enrollment in RPL networks |
| |
|
[RFC9032] defines a method by which a potential [RFC9031] enrollment proxy can announce itself as available for new RPL nodes to enroll on a network. The announcement includes a priority for enrollment. This document provides a mechanism by which a Routing Protocol for Low-Power and Lossy Networks (RPL) Root can globally disable enrollment announcements or adjust the base priority for enrollment operations. |
| |
|
| |
| | On-time Forwarding with Non-work Conserving Stateless Core Fair Queuing |
| |
|
This document specifies the framework and operational procedure for deterministic networking that guarantees maximum and minimum end-to- end latency bounds to flows. The solution has non-periodic, asynchronous, flow-level, non-work conserving, on-time, and rate- based functional characteristics, according to the taxonomy suggested by [draft-ietf-detnet-dataplane-taxonomy-03]. The packets are stored in the queue in ascending order of the ideal service start time, called Eligible Time (ET), and the ideal service completion time, called Finish Time (FT). The queued packets were forwarded between ET and FT in a non-work conserving manner. The ET and FT are calculated at the entrance node according to the packet size and rate of the flow. All subsequent core nodes are stateless and asynchronously compute ET and FT based on metadata received via packet headers. This mechanism is called non-work-preserving stateless fair queuing, which guarantees both E2E latency upper and lower bounds. |
| | On-time Forwarding with Push-In First-Out (PIFO) queue |
| |
|
This document describes operations of data plane and controller plane for Deterministic Networking (DetNet) to forward packets to meet minimum and maximum end-to-end latency requirements, while utilizing Push-In First-Out (PIFO) queue. According to the solution described in this document, forwarding nodes do not need to maintain flow states or to be time-synchronized with each other. |
| | Applicability Statement for IETF Core Email Protocols |
| |
| | draft-ietf-emailcore-as-27.txt |
| | Date: |
23/01/2026 |
| | Authors: |
John Klensin, Kenneth Murchison |
| | Working Group: |
Revision of core Email specifications (emailcore) |
|
Electronic mail is one of the oldest Internet applications that is still in very active use. While the basic protocols and formats for mail transport and message formats have evolved slowly over the years, events and thinking in more recent years have supplemented those core protocols with additional features and suggestions for their use. This Applicability Statement describes the relationship among many of those protocols and provides guidance and makes recommendations for the use of features of the core protocols. |
| | TCP-AO Protection for BGP Monitoring Protocol (BMP) |
| |
|
This document outlines the utilization of the TCP Authentication Option (TCP-AO), as specified in [RFC5925], for the authentication of BGP Monitoring Protocol (BMP) sessions, as specified in [RFC7854]. TCP-AO provides for the authentication of BMP sessions established between routers and BMP stations at the TCP layer. 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/hmntsharma/draft-hmntsharma-bmp-tcp-ao. |
| | IoT DNS Security and Privacy Guidelines |
| |
|
This document outlines best current practices for Internet of Things (IoT) device providers regarding the implementation of DNS stub resolvers, with the aim of mitigating security threats, enhancing privacy, and resolving operational challenges. It also provides guidelines for network operators on mitigating the risks identified in this draft as DNS resolution includes services outside of the stub-resolver, and for device providers' management zones. |
| | LSP Ping/Traceroute for Enabled In-situ OAM Capabilities |
| |
|
This document describes the application of the mechanism of discovering In-situ OAM (IOAM) capabilities, described in RFC 9359 "Echo Request/Reply for Enabled In Situ OAM (IOAM) Capabilities", in MPLS networks. The MPLS Node IOAM Information Query functionality uses the MPLS echo request/reply messages, allowing the IOAM encapsulating node to discover the enabled IOAM capabilities of each IOAM transit and IOAM decapsulating node. |
| | Metadata Query Protocol |
| |
|
This document defines a simple protocol for retrieving metadata about named entities, or named collections of entities. The goal of the protocol is to profile various aspects of HTTP to allow requesters to rely on certain, rigorously defined, behaviour. This document is a product of the Research and Education Federations (REFEDS) Working Group process. |
| | SAML Profile for the Metadata Query Protocol |
| |
|
This document profiles the Metadata Query Protocol for use with SAML metadata. This document is a product of the Research and Education Federations (REFEDS) Working Group process. Editorial Note (To be removed by RFC Editor before publication) Discussion of this draft takes place on the MDX mailing list (mdx@lists.iay.org.uk), which is accessed from [MDX.list]. XML versions, latest edits and the issues list for this document are available from [md-query]. The changes in this draft are summarized in Appendix A.25. |
| | Encrypted Client Hello Deployment Considerations |
| |
|
(Editorial note: to be updated as the text in the main body of the document is finalised) This document is intended to inform the community about the impact of the deployment of the proposed Encrypted Client Hello (ECH) standard that encrypts Server Name Indication (SNI) and other data. Data encapsulated by ECH (ie data included in the encrypted ClientHelloInner) is of legitimate interest to on-path security actors including those providing inline malware detection, parental controls, content filtering to prevent access to malware and other risky traffic, mandatory security controls etc. The document includes observations on current use cases for SNI data in a variety of contexts. It highlights how the use of that data is important to the operators of both public and private networks and shows how the loss of access to SNI data will cause difficulties in the provision of a range of services to end-users, including the potential weakening of cybersecurity defences. Some mitigations are identified that may be useful for inclusion by those considering the adoption of support for ECH in their software. |
| | WBA OpenRoaming Wireless Federation |
| |
| | draft-tomas-openroaming-07.txt |
| | Date: |
23/01/2026 |
| | Authors: |
Bruno Tomas, Mark Grayson, Necati Canpolat, Betty Cockrell, Sri Gundavelli |
| | Working Group: |
Individual Submissions (none) |
|
This document describes the Wireless Broadband Alliance's OpenRoaming system. The OpenRoaming architecture enables a seamless onboarding experience for devices connecting to access networks that are part of the federation of access networks and identity providers. The primary objective of this document is to describe the protocols that form the foundation for this architecture, enabling providers to correctly configure their equipment to support interoperable OpenRoaming signalling exchanges. In addition, the topic of OpenRoaming has been raised in different IETF working groups, and therefore a secondary objective is to assist those discussions by describing the federation organization and framework. |
| | Automatic Extended Route Optimization (AERO) |
| |
|
This document specifies an Automatic Extended Route Optimization (AERO) and mobility service for IP internetworking over Overlay Multilink Network (OMNI) Interfaces. AERO/OMNI use IPv6 Neighbor Discovery (IPv6 ND) control plane messaging over the OMNI virtual link to support secured network admission and OMNI link forwarding. Flow-based secure multilink path selection, multinet traversal, mobility management, multicast forwarding, multihop operation and route optimization are naturally supported through dynamic neighbor cache updates. AERO is a widely-applicable service well-suited for air/land/sea/space secure global mobile Internetworking applications including aviation, intelligent transportation systems, mobile end user devices, space exploration and many others. |
| | Domain Registry Grace Period Mapping for the Extensible Provisioning Protocol (EPP) |
| |
|
This document describes an Extensible Provisioning Protocol (EPP) [RFC5730] extension mapping for the management of Domain Name System (DNS) domain names subject to "grace period" policies. Grace period policies exist to allow protocol actions to be reversed or otherwise revoked during a short period of time after the protocol action has been performed. This mapping extends the EPP domain name mapping [RFC5731] to provide additional features required for grace period processing. This document replaces the extension mapping for grace periods described in [RFC3915], rendering that document obsolete. |
| | Post-Quantum Enhancements to EAP-TLS and EAP-TTLS |
| |
|
This document proposes enhancements to the Extensible Authentication Protocol with Transport Layer Security (EAP-TLS) and EAP Tunneled TLS (EAP-TTLS) to incorporate post-quantum cryptographic mechanisms. It also addresses challenges related to large certificate sizes and long certificate chains, as identified in [RFC9191], and provides recommendations for integrating PQC algorithms into EAP-TLS and EAP- TTLS deployments. |
| | Microphone Access Fairness Protocol (MAFP) |
| |
|
This document specifies the Microphone Access Fairness Protocol (MAFP), an Experimental protocol intended to improve fairness in access to microphones during technical events, forums, panels, and other interactive sessions. The protocol documents commonly observed behaviors, informal control mechanisms, and failure modes associated with microphone access in both in-person and remote participation environments. |
| | TIBET: Evidence Trail Protocol |
| |
|
This document specifies TIBET (Transaction/Interaction-Based Evidence Trail), a protocol for establishing complete provenance chains in AI- to-AI and AI-to-human interactions. TIBET provides a standardized token structure capturing WHAT happened (ERIN), WHAT was attached (ERAAN), the CONTEXT around it (EROMHEEN), and WHY it happened (ERACHTER). This enables audit trails that meet emerging regulatory requirements for AI transparency. |
| | Cross-Device Flows: Security Best Current Practice |
| |
|
This document describes threats against cross-device flows along with practical mitigations, protocol selection guidance, and a summary of formal analysis results identified as relevant to the security of cross-device flows. It serves as a security guide to system designers, architects, product managers, security specialists, fraud analysts and engineers implementing cross-device flows. |
| | Efficient RDAP Referrals |
| |
|
This document describes an RDAP extension that allows RDAP clients to request to be referred to a related RDAP record for a resource. |
| | PEM file format for ECH |
| |
|
Encrypted ClientHello (ECH) key pairs need to be configured into TLS servers, which can be built using different TLS libraries. This document specifies a file format to use, similar to how RFC 7468 defines other PEM file formats. |
| | Common YANG Data Types for Traffic Engineering |
| |
| | draft-ietf-teas-rfc8776-update-21.txt |
| | Date: |
23/01/2026 |
| | Authors: |
Italo Busi, Aihua Guo, Xufeng Liu, Tarek Saad, Igor Bryskin |
| | Working Group: |
Traffic Engineering Architecture and Signaling (teas) |
|
This document defines a collection of common data types, identities, and groupings in YANG data modeling language. These derived common data types, identities and groupings are intended to be imported by other modules, e.g., those which model the Traffic Engineering (TE) configuration and state capabilities. This document obsoletes RFC 8776. |
| | IETF Network Slice Topology YANG Data Model |
| |
|
An RFC 9543 network slice customer may utilize intent-based topologies to express resource reservation intentions within the provider's network. These customer-defined intent topologies allow customers to request shared resources for future connections that can be flexibly allocated and customized. Additionally, they provide an extensive level of control over underlay service paths within the network slice. This document describes a YANG data model for expressing customer intent topologies which can be used to enhance the RFC 9543 Network Slice Services in specific use cases, such as Network wholesale scenarios, where both topology and connectivity intents need to be expressed. |
| |
|
| |
| | JSCalendar: Converting from and to iCalendar |
| |
|
This document defines how to convert calendaring information between the JSCalendar and iCalendar data formats. It considers every JSCalendar and iCalendar element registered at IANA at the time of publication. It defines conversion rules for all elements that are common to both formats, as well as how convert arbitrary or unknown JSCalendar and iCalendar elements. This document updates RFC 5545 ("iCalendar") and jscalendarbis ("JSCalendar") by defining new properties and parameters for JSCalendar and iCalendar conversion. |
| | Operational Guidelines for DNS Transport in Mixed IPv4/IPv6 Environments |
| |
|
This document provides guidelines and documents Best Current Practice for operating authoritative DNS servers, recursive resolvers and stub resolvers in a mixed IPv4/IPv6 environment. This document recommends that both authoritative DNS servers and recursive resolvers support IPv4 and IPv6. It also provides guidance on how recursive DNS resolvers should select upstream DNS servers, including when IPv4-embedded IPv6 addresses are available. This document obsoletes RFC 3901. |
| | Use Cases for Energy Efficiency Management |
| |
| | draft-ietf-green-use-cases-01.txt |
| | Date: |
22/01/2026 |
| | Authors: |
Emile Stephan, Marisol Amador, Benoit Claise, Qin WU, Luis Contreras, Carlos Bernardos, Xinyu Chen |
| | Working Group: |
Getting Ready for Energy-Efficient Networking (green) |
|
This document groups use cases for Energy efficiency Management of network devices. Discussion Venues Source of this draft and an issue tracker can be found at https://github.com/emile22/draft-ietf-green-use-cases |
| | The Locator/ID Separation Protocol (LISP) for Multicast Environments |
| |
| | draft-ietf-lisp-rfc6831bis-06.txt |
| | Date: |
22/01/2026 |
| | Authors: |
Dino Farinacci, David Meyer, John Zwiebel, Stig Venaas, Vengada Govindan |
| | Working Group: |
Locator/ID Separation Protocol (lisp) |
|
This document describes the design for inter-domain multicast overlays using the Locator/ID Separation Protocol (LISP) architecture and protocols. The document specifies how LISP multicast overlays operate over multicast and unicast underlays. The mechanisms in this specification indicate how a signal-based approach using the PIM protocol can be used to program LISP encapsulators with a replication list in a locator-set, where the replication list can be a mix of multicast and unicast locators. This document when approved obsoletes RFC6831 |
| | IS-IS Distributed Flooding Reduction |
| |
|
In dense topologies (such as data center fabrics based on the Clos and butterfly though not limited to those; in fact any large topology or one with relatively high degree of connectivity qualifies here) IGP flooding mechanisms designed originally for rather sparse topologies can "overflood", or in other words generate too many identical copies of same information arriving at a given node from other devices. This normally results in longer convergence times and higher resource utilization to process and discard the superfluous copies. Flooding algorithm extensions that restrict the amount of flooding performed can be constructed and can reduce resource utilization significantly, while improving convergence performance. One such flooding modification (based on previous art) optimized for operational considerations, described further in Section 2, is described in this document. |
| | BGP-LS Advertisement of SR Policy Performance Metric |
| |
|
This document describes a way to advertise the performance metrics for Traffic Engineering (TE) Policy using BGP Link State (BGP-LS). |
| | Merkle Tree Certificates |
| |
|
This document describes Merkle Tree certificates, a new form of X.509 certificates which integrate public logging of the certificate, in the style of Certificate Transparency. The integrated design reduces logging overhead in the face of both shorter-lived certificates and large post-quantum signature algorithms, while still achieving comparable security properties to traditional X.509 and Certificate Transparency. Merkle Tree certificates additionally admit an optional signatureless optimization, which decreases the message size by avoiding signatures altogether, at the cost of only applying to up-to-date relying parties and older certificates. |
| | BFD Path Consistency over SR |
| |
|
Bidirectional Forwarding Detection (BFD) can be used to monitor paths between nodes. U-BFD defined in [I-D.ietf-bfd-unaffiliated-echo] can effectively reduce the device equipment. Seamless BFD (S-BFD) provides a simplified mechanism which is suitable for monitoring of paths that are setup dynamically and on a large scale network. In SR network, BFD can also be used to monitor SR paths. When a headend use BFD to monitor the segment list/CPath of SR Policy, the forward path of control packet is indicated by segment list, the reverse path of response control packet is via the shortest path from the reflector back to the initiator (headend) as determined by routing. The forward path and reverse path of control packet are likely inconsistent going through different intermediate nodes or links. This document describes a method to keep the forward path and reverse path consistent when using S-BFD or U-BFD to detect SR Policy |
| | Purge Originator Identification for OSPF |
| |
|
In RFC6232(Purge Originator Identification TLV for IS-IS), ISIS POI (Purge Originator Identification) TLV is added to the purge LSP to record the system ID of the IS generating it. At present, OSPF purge does not contain any information identifying the Router that generates the purge. This makes it difficult to locate the source router. While OSPF protocol is difficult to add additional content to the purge LSA, this document proposes generating a POI LSA together with a purge LSA to record the router ID of the router generating the purge. To address this issue, this document defines a POI LSA to record the router ID of the OSPF generating it. |
| | Considerations for Protective DNS Server Operators |
| |
|
Protective DNS is a defense mechanism deployed on recursive resolvers to prevent users from accessing malicious domains. For domain names in the blocklist, it rewrites DNS resolution responses to point to secure destinations (e.g., safe servers) to prevent users from accessing malicious entities. Owing to its effective defenses against common cyber attack behaviors—such as command-and-control (C2) communications of malware—Protective DNS deployment has surged via various initiatives. Not only have renowned DNS service providers adopted this defense, but some countries have also launched national-scale deployments. Meanwhile, studies analyzing Protective DNS have identified implementation diversity. Thus, this document aims to provide specific operational and security considerations for Protective DNS. It is intended primarily for entities seeking to deploy Protective DNS for defensive purposes, offering deployment and security considerations. |
| | SCHC Payload compression |
| |
|
This document describes several techniques to enable utilization of the same engine to compress and decompress headers from the existing SCHC framework [RFC8724], but used to compress payload of specific protocols. The first approach is to introduce new type of static rules that enable encoding application data. This extensions provides compact and generic variation on how data is organized. The second approach provides dynamic compression and decompression. Here, the system identifies parts of the payload that can be compressed, and enables a SCHC decompressor to restore the original packet. |
| | Deploying and Using Email in Deep Space |
| |
|
This document is an assessment on the email protocols to be used in deep space and provides recommendations to deploy and use email in deep space. |
| | Static Context Header Compression and Fragmentation ARQ/FEC mode |
| |
|
This document defines a new fragmentation mode for the SCHC standard defined in RFC8724. The new fragmentation mode is designed for communications that require additional reliability mechanisms. The reliability is based on a hybrid ARQ/FEC type II mechanism that combines forward error correction (FEC) with adaptive retransmissions to achieve high reliability. |
| | Remote Attestation with Exported Authenticators |
| |
| | draft-fossati-seat-expat-01.txt |
| | Date: |
22/01/2026 |
| | Authors: |
Muhammad Sardar, Thomas Fossati, Tirumaleswar Reddy.K, Yaron Sheffer, Hannes Tschofenig, Ionut Mihalcea |
| | Working Group: |
Individual Submissions (none) |
|
This specification defines a method for two parties in a communication interaction to exchange Evidence and Attestation Results using exported authenticators, as defined in [RFC9261]. Additionally, it introduces the cmw_attestation extension, which allows attestation credentials to be included directly in the Certificate message sent during the Exported Authenticator-based post-handshake authentication. The approach supports both the passport and background check models from the RATS architecture while ensuring that attestation remains bound to the underlying communication channel. |
| | ApertoDNS Protocol: A Modern Dynamic DNS Update Protocol |
| |
|
This document specifies the ApertoDNS Protocol, a modern RESTful protocol for dynamic DNS (DDNS) updates. It provides a secure, provider-agnostic alternative to legacy protocols, with native support for IPv4, IPv6, bulk updates, automatic IP detection, TXT record management for ACME DNS-01 challenges, and standardized authentication mechanisms. The protocol uses well-known URIs (RFC 8615), JSON payloads (RFC 8259), and bearer token authentication (RFC 6750) to enable interoperable dynamic DNS services across different providers. |
| | Pre-,Intra- and Post-handshake Attestation |
| |
|
This document presents a taxonomy of extending TLS protocol with remote attestation, referred to as attested TLS. It also presents high-level analysis of benefits and limitations of each category, namely pre-handshake attestation, intra-handshake attestation and post-handshake attestation. |
| | Distributed Aggregation Protocol (DAP) Extensions for the Attribution API |
| |
|
This defines extensions to the DAP protocol that support the Attribution API. These extensions provide support for differentially-private aggregation and the operating modes that the Attribution API depends on. |
| | Export of BIER Information in IP Flow Information Export (IPFIX) |
| |
|
This document introduces new IP Flow Information Export (IPFIX) Information Elements (IEs) to identify a set of information related to Bit Index Explicit Replication (BIER) such as data contained in BIER header that traffic is being forwarded with. |
| | Kaspa Kinesis Transport Protocol (KKTP) |
| |
|
The Kaspa Kinesis Transport Protocol (KKTP) is a serverless, CGNAT-compatible secure messaging protocol that uses the Kaspa BlockDAG as a decentralized mailbox for peer discovery, key agreement, and encrypted message relay. KKTP enables secure, replay-protected, and publicly verifiable communication between peers without STUN/TURN, centralized servers, or direct IP connectivity. This document specifies the protocol, data structures, cryptographic primitives, security properties, and operational considerations for KKTP. |
| | Kaspa Kinesis Transport Protocol (KKTP) Threat Model |
| |
|
This document defines the adversary model, security assumptions, security goals, and explicit non-goals for the Kaspa Kinesis Transport Protocol (KKTP). It describes the capabilities of potential attackers, the trust assumptions required for correct operation, and the limits of the protocol's security guarantees. This document is intended to complement the main KKTP specification. |
| | Chunked Oblivious HTTP Messages |
| |
|
This document defines a variant of the Oblivious HTTP message format that allows chunks of requests and responses to be encrypted and decrypted before the entire request or response is processed. This allows incremental processing of Oblivious HTTP messages, which is particularly useful for handling large messages or systems that process messages slowly. |
| | YANG Data Models for Network Resource Partitions (NRPs) |
| |
| | draft-ietf-teas-nrp-yang-05.txt |
| | Date: |
22/01/2026 |
| | Authors: |
Bo Wu, Dhruv Dhody, Vishnu Beeram, Tarek Saad, Shaofu Peng |
| | Working Group: |
Traffic Engineering Architecture and Signaling (teas) |
|
RFC 9543 describes a framework for Network Slices in networks built from IETF technologies. In this framework, the network resource partition (NRP) is introduced as a collection of network resources allocated from the underlay network to carry a specific set of Network Slice Service traffic and meet specific Service Level Objective (SLO) and Service Level Expectation (SLE) characteristics. This document defines two YANG data models for Network Resource Partitions (NRPs): a network-level model for policy configuration by a Network Slice Controller, and a device-level model for configuration of individual network elements. These models enable automated provisioning of NRPs in IP/MPLS and Segment Routing (SR) networks, supporting scalable realization of RFC 9543 Network Slice Services. |
| |
|
| |
| | RTP Payload Format for Haptics |
| |
|
This memo specifies an RTP payload format for the MPEG-I haptic data. A haptic media stream is composed of MIHS units including a MIHS (MPEG-I Haptic Stream) unit header and zero or more MIHS packets. The RTP payload header format allows for packetization of a MIHS unit in an RTP packet payload as well as fragmentation of a MIHS unit into multiple RTP packets. The original subtype registration for haptics/ hmpg, registered with IANA in RFC9695, did not include any required or optional parameters. This memo updates RFC9695 and the haptics/ hmpg registration to add optional parameters. It also provides SDP usage information for the haptics media type. |
| | Multicast and Ethernet VPN with Segment Routing P2MP and Ingress Replication |
| |
|
A Point-to-Multipoint (P2MP) Tree in a Segment Routing domain carries traffic from a Root to a set of Leaves. This document specifies extensions to BGP encodings and procedures for P2MP trees and Ingress Replication used in BGP/MPLS IP VPNs and Ethernet VPNs in a Segment Routing domain. |
| | OSPFv3 Extensions for BIER |
| |
|
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. The BIER architecture uses MPLS or other encapsulations to steer the multicast traffic towards the receivers. This document describes the OSPFv3 protocol extensions required for BIER with MPLS encapsulation. Support for other encapsulation types is outside the scope of this document. |
| | Key Transparency Architecture |
| |
|
This document defines the terminology and interaction patterns involved in the deployment of Key Transparency in a general secure group messaging infrastructure, and specifies the security properties that the protocol provides. It also gives more general, non- prescriptive guidance on how to securely apply Key Transparency to a number of common applications. |
| | IPv4+ The Extended Protocol Based On IPv4 |
| |
|
This document specifies version 4+ of the Internet Protocol (IPv4+). IPv4 is very successful,simple and elegant. continuation and expansion of the IPv4 is necessary. Existing systems, devices only need to upgrade the software to support IPv4+, without the need to update new hardwares,saving investment costs. Ipv4+ is also an interstellar Protocol, so the Internet will evolve into a star Internet. |
| | Flexible Candidate Path Selection of SR Policy |
| |
|
This document describes a flexible method for selecting candidate Segment Routing (SR) policy paths. Based on the real-time resource usage and forwarding quality of candidate paths, the head node can perform dynamic path switching among multiple candidate paths in the SR policy. |
| | Using BMP over QUIC connection |
| |
| | draft-liu-grow-bmp-over-quic-05.txt |
| | Date: |
21/01/2026 |
| | Authors: |
Yisong Liu, Changwang Lin, Thomas Graf, Paolo Lucente, Mukul Srivastava |
| | Working Group: |
Individual Submissions (none) |
|
The BGP Monitoring Protocol (BMP) provides a convenient interface for obtaining route views by monitoring BGP sessions. BMP operates over TCP and is unidirectional (from client to server). QUIC provides multiple simultaneous streams to carry data in one direction, enabling much better efficiency and performance for both peers, in particular unidirectional streams can provide reverse data protection for the sender. QUIC also provides shorter handshake and includes TLS. This document describes how to use BMP over the QUIC transport protocol, named BMPoQUIC. |
| | An EAT Profile for Trustworthy Device Assignment |
| |
|
In confidential computing, device assignment (DA) is the method by which a device (e.g., network adapter, GPU), whether on-chip or behind a PCIe Root Port, is assigned to a Trusted Virtual Machine (TVM). For the TVM to trust an assigned device, the device must provide the TVM with attestation Evidence confirming its identity and the state of its firmware and configuration. Since Evidence claims can be processed by 3rd party entities (e.g., Verifiers, Relying Parties) external to the TVM, there is a need to standardize the representation of DA-related information in Evidence to ensure interoperability. This document defines an attestation Evidence format for DA as an EAT (Entity Attestation Token) profile. |
| | A YANG Module for SRv6 Next-Hop RIB Extensions |
| |
|
This document defines a YANG data module for configuring and managing SRv6 next hop information for Routing, which augments the YANG data model for Routing Management (RFC8349). |
| | IKEv2 Fragment Acknowledgment Extension |
| |
|
This document specifies an extension to the Internet Key Exchange Protocol Version 2 (IKEv2) that enables acknowledgment of IKEv2 message fragments over UDP. The mechanism allows an IKE peer to confirm reception of individual fragments during the IKE_AUTH exchange and any subsequent exchanges where IKEv2 Fragmentation is used. Support for this feature is negotiated using a new Notify Message Status Type during IKE_SA_INIT, and fragment acknowledgments are exchanged using a separate Notification payload. This extension improves reliability when large IKE messages are exchanged, such as those containing post-quantum cryptography (PQC) payloads, and reduces retransmission overhead, thereby improving IKEv2 round-trip times in lossy network conditions. |
| | OAuth Transaction Tokens Best Current Practice |
| |
|
This document provides best current practices for implementing and deploying OAuth 2.0 Transaction Tokens as specified in draft-ietf- oauth-transaction-tokens. Transaction Tokens (Txn-Tokens) enable workloads in a trusted domain to preserve and propagate user identity and authorization context across service boundaries during the processing of external programmatic requests. This BCP addresses practical deployment considerations including token service architecture, size management, propagation patterns, validation strategies, and operational monitoring that are essential for secure and effective implementation in production environments. |
| | Minimum RTT Estimation Under Low ACK Frequency |
| |
|
In traditional acknowledgment mechanisms, the sender frequently "pulls" ACK packets, resulting in significant protocol control overhead. This leads to wasted CPU and I/O resources, contention for packet spectrum on half-duplex links (e.g., WLAN), and reverse-path congestion in asymmetric links (e.g., satellite network). Reducing the number of ACKs is essential in scenarios where ACK overhead is non-negligible. However, a lower ACK frequency can introduce biases in delay estimation, such as overestimating the minimum round-trip time (minRTT). This document proposes how to calibrate the estimation of the minRTT under low ACK frequency conditions. |
| | FAF: Foundational AI-context Format for Development Tools |
| |
|
This document specifies FAF (Foundational AI-context Format), a YAML- based format for representing software project context in a form consumable by AI development tools. FAF provides a standardized mechanism for sharing project architecture, conventions, dependencies, and goals across heterogeneous AI agents, addressing context fragmentation in multi-agent development environments. FAF is registered with IANA as "application/vnd.faf+yaml" (October 2025). This document seeks registration as "application/faf+yaml". |
| | Open Cloud Mesh |
| |
|
Open Cloud Mesh (OCM) is a server federation protocol that is used to notify a Receiving Party that they have been granted access to some Resource. It has similarities with authorization flows such as OAuth, as well as with social internet protocols such as ActivityPub and email. A core use case of OCM is when a user (e.g., Alice on System A) wishes to share a resource (e.g., a file) with another user (e.g., Bob on System B) without transferring the resource itself or requiring Bob to log in to System A. While this scenario is illustrative, OCM is designed to support a broader range of interactions, including but not limited to file transfers. Open Cloud Mesh handles interactions only up to the point where the Receiving Party is informed of their access to the Resource. Actual Resource access is subsequently managed by other protocols, such as WebDAV. |
| | Updates to SFrame Cipher Suites Registry |
| |
|
This document addresses two omissions in the Secure Frames (SFrame) protocol specification. First, the definition of the IANA registry for SFrame ciphersuites omits several important fields. This document requests that IANA add those fields and defines the contents of those fields for current entries. Second, the AEAD construction based on AES-CTR and HMAC is defined only for the 128-bit security level. This document registers parallel constructions at the 256-bit security level. |
| | 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. |
| | IP in Deep Space: Key Characteristics,Use Cases and Requirements |
| |
|
Deep space communications involve long delays (e.g., Earth to Mars has one-way delays 4-24 minutes) and intermittent communications, mainly because of orbital dynamics. The IP protocol stack used on the Internet is based on the assumptions of shorter delays and mostly uninterrupted communications. This document describes the key characteristics, use cases, and requirements for deep space networking, intended to help when profiling IP protocols in such environment. |
| | The JSON format for vCon - Conversation Data Container |
| |
|
vCon is a standardized framework for the exchange of conversational data. Conversations, which may involve one or more participants, occur across a wide variety of modes and application platforms. This document defines a JSON format for representing conversational data, encompassing metadata, conversation media, related documents, and analysis. The goal of this standard is to provide an abstracted, platform-independent data format for conversations, regardless of the mode or application platform. By doing so, it facilitates the integration and seamless exchange of conversational data across application platforms, enterprises, and trust boundaries. |
| |
|
| |
| | Constrained GeneRic Autonomic Signaling Protocol |
| |
|
This document proposes the Constrained GeneRic Autonomic Signaling Protocol (cGRASP), a constrained and lightweight variant of the GeneRic Autonomic Signaling Protocol (GRASP, or the standard GRASP). cGRASP reduces message overhead and replaces TCP with CoAP as the transport protocol. By leveraging CoAP's reliability features and deployment maturity, cGRASP can provide reliable signaling services without relying on TCP, making it suitable for IoT, where lightweight and resource-constrained devices dominate. Furthermore, this document also discusses the potential approaches to adapting the cGRASP to work on the network without IP connectivity. |
| | Automatic Peering for SIP Trunks |
| |
|
This document specifies a framework that enables enterprise telephony Session Initiation Protocol (SIP) networks to solicit and obtain a capability set document from a SIP service provider. The capability set document encodes a set of characteristics that enable easy peering between enterprise and service provider SIP networks. |
| | An Application Layer Interface for Non-Internet-Connected Physical Components (NIPC) |
| |
| | draft-ietf-asdf-nipc-16.txt |
| | Date: |
20/01/2026 |
| | Authors: |
Bart Brinckman, Rohit Mohan, Braeden Sanford |
| | Working Group: |
A Semantic Definition Format for Data and Interactions of Things (asdf) |
|
This memo describes an API that allows applications to perform operations against a gateway serving one or more devices described by an SDF model. The document describes a RESTful application layer interface to perform operations on those devices, as well as a CBOR- based publish-subscribe interface for streaming data. |
| | Semantic Definition Format (SDF) Extension for Non-Affordance Information |
| |
|
This document describes an extension to the Semantic Definition Format (SDF) for representing non-affordance information of Things, such as physical, contextual, and descriptive metadata. This extension introduces a new class keyword, sdfContext, that enables comprehensive modeling of Things and improves semantic clarity. |
| | Semantic Definition Format (SDF) modeling for Digital Twin |
| |
| | draft-ietf-asdf-digital-twin-03.txt |
| | Date: |
20/01/2026 |
| | Authors: |
Hyunjeong Lee, Jungha Hong |
| | Working Group: |
A Semantic Definition Format for Data and Interactions of Things (asdf) |
|
This memo specifies SDF modeling for a digital twin, i.e. a digital twin system, and its Things. An SDF is a format that is used to create and maintain data and interaction, and to represent the various kinds of data that is exchanged for these interactions. The SDF format can be used to model the characteristics, behavior and interactions of Things, i.e. physical objects, in a digital twin that contain Things as components. |
| | Protocol Mapping for SDF |
| |
|
This document defines protocol mapping extensions for the Semantic Definition Format (SDF) to enable mapping of protocol-agnostic SDF affordances to protocol-specific operations. The protocol mapping mechanism allows SDF models to specify how properties, actions, and events should be accessed using specific non-IP and IP protocols such as Bluetooth Low Energy, Zigbee or HTTP and CoAP. |
| | Instance Information for SDF |
| |
|
This document specifies instance-related messages to be used in conjunction with the Semantic Definition Format (SDF) for Data and Interactions of Things (draft-ietf-asdf-sdf). Split into four "archetypes", instance-related messages are always governed by SDF models, strictly separating instance and class information. _Context_ information plays a crucial role both for lifecycle management and actual device interaction. // This revision applies a major restructuring, reduces redundancy // and clarifies some of the concepts that are used throughout the // document. It also expands upon three experimental application // scenarios for instance-related messages. |
| | 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 underlay. 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. This document when approved obsoletes RFC 8378. |
| | Post-Stack MPLS Network Action (MNA) Solution |
| |
| | draft-ietf-mpls-mna-ps-hdr-06.txt |
| | Date: |
20/01/2026 |
| | Authors: |
Jaganbabu Rajamanickam, Rakesh Gandhi, Royi Zigler, Jie Dong |
| | Working Group: |
Multiprotocol Label Switching (mpls) |
|
This document defines the Post-Stack MPLS Network Action (MNA) solution for carrying Network Actions and Ancillary Data after the MPLS label stack, based on the In-Stack MNA solution defined in "MPLS Network Action (MNA) Sub-Stack Solution." MPLS Network Actions can be used to influence packet forwarding decisions, carry additional Operations, Administration, and Maintenance information in the MPLS packet, or perform user-defined operations. This solution document addresses the Post-Stack network action and Post-Stack data-specific requirements found in RFC 9613. This document follows the framework specified in RFC 9789. |
| | ASPA-based AS_PATH Verification for BGP Export |
| |
| | draft-zhang-sidrops-aspa-egress-04.txt |
| | Date: |
20/01/2026 |
| | Authors: |
Jia Zhang, Yangyang Wang, Maria Matejka, Mingwei Xu, Kotikalapudi Sriram, Nan Geng |
| | Working Group: |
Individual Submissions (none) |
|
This document describes AS_PATH verification based on Autonomous System Provider Authorization (ASPA) for egress eBGP speakers. ASPA is a Resource Public Key Infrastructure (RPKI) object that allows an AS to register its transit provider ASes. Performing ASPA-based AS_PATH verification at egress can prevent the propagation of route leaks to external peers, check for local misconfigurations, and help detect potential ASPA registration errors. This approach complements ingress-side verification; it ensures coverage should ASPA deployment be absent at the ingress eBGP router of the AS. |
| | Amendments to Stateful PCE Communication Protocol (PCEP) |
| |
| | draft-many-pce-stateful-amendment-03.txt |
| | Date: |
20/01/2026 |
| | Authors: |
Andrew Stone, Mike Koldychev, Siva Sivabalan, Diego Achaval, Shuping Peng, Hari Kotni, Samuel Sidor |
| | Working Group: |
Individual Submissions (none) |
|
This document updates RFC8231, RFC8664 and RFC8281 to reflect operationalized implementations and define optimizations in the PCEP protocol. |
| | KEM-based Authentication for EDHOC in Initiator-Known Responder (IKR) Scenarios |
| |
|
This document specifies a more efficient variant of a Key Encapsulation Mechanism (KEM)-based authentication method for the Ephemeral Diffie-Hellman Over COSE (EDHOC) lightweight protocol, designed for the specific scenario in which the Initiator has prior knowledge of the Responder’s credentials, a case commonly found in constrained environments. Improving upon the approach described in KEM-based Authentication for EDHOC, this method uses only a mandatory three-message handshake to enable signature-free post-quantum authentication when PQC KEMs, such as the NIST-standardized ML-KEM, are employed, while still providing mutual authentication, forward secrecy, and a degree of identity protection. |
| | DomainKeys Identified Mail Signatures v2 (DKIM2) |
| |
|
DomainKeys Identified Mail v2 (DKIM2) permits a person, role, or organization that owns a signing domain to document that it has handled an email message by associating their domain with the message. This is achieved by providing a hash value that has been calculated on the current contents of the message and then applying a cryptographic signature that covers the hash values and other details about the transmission of the message. Verification is performed by querying an entry within the signing domain's DNS space to retrieve an appropriate public key. As a message is transferred from author to recipient systems that alter the body or header fields will provide details of their changes and calculate new hash values. Further signatures will be added to provide a validatable "chain". This permits validators to identify the nature of changes made by intermediaries and apply a reputation to the systems that made changed. DKIM2 also allows recipients to detect when messages have been unexpectedly "replayed" and will ensure that Delivery Status Notifications are only sent to entities that were involved in the transmission of a message. |
| | Populating resolvers with the root zone |
| |
|
DNS recursive resolver operators need to provide the best service possible for their users, which includes providing an operationally robust and privacy protecting service. Challenges to these deployment goals include difficulty of getting responses from the root servers (such as during a network attack), longer-than-desired round-trip times to the closest DNS root server, and privacy issues relating to queries sent to the DNS root servers. Resolvers can solve all of these issues by simply serving an already cached a copy of the full root zone. This document shows how resolvers can fetch, cache and maintain a copy of the root zone, how to detect if the contents becomes stale, and procedures for handling error conditions. |
| | Transaction Tokens For Agents |
| |
|
This document specifies an extension to the OAuth Transaction Tokens framework (https://drafts.oauth.net/oauth-transaction-tokens/draft- ietf-oauth-transaction-tokens.html) to support agent context propagation within Transaction Tokens for agent-based workloads. The extension defines two new context fields: 'actor' and 'principal'. The 'actor' field identifies the agent performing the action, while the 'principal' field identifies the human or system entity that initiated the agent's action. For autonomous agents operating independently, the 'principal' field MAY be omitted. These additional context fields enable services within the call graph to make more granular access control decisions, thereby enhancing security. |
| | BGP Unreachability Information SAFI |
| |
|
This document defines a new BGP Subsequent Address Family Identifier (SAFI) called "Unreachability Information" that allows the propagation of prefix unreachability information through BGP without affecting the installation or removal of routes in the Routing Information Base (RIB) or Forwarding Information Base (FIB). This mechanism enables network operators to share information about unreachable prefixes for monitoring, debugging, and coordination purposes while maintaining complete separation from the active routing plane. |
| | ChainSync: A Synchronization Protocol for Strict Sequential Execution in Linear Distributed Pipelines |
| |
|
ChainSync is a lightweight application-layer protocol that runs over reliable TCP connections to synchronize a fixed linear chain of distributed processes such that they execute their local tasks in strict sequential order and only after every process in the chain has confirmed it is ready. The protocol has four phases: 1) a forward "readiness" wave, 2) a backward "start" wave, 3) a forward "execution" wave, and 4) a backward exit wave. The design guarantees strict ordering even when nodes become ready at very different times and requires only point-to-point TCP connections along the chain, thus no central coordinator is needed. |
| | Control Word Option |
| |
|
This document introduces new IPv6 options for DOH, to carry flow identifier, sequence number, and other customer service mapped information that is encapsulated by the provider network, to support flow-specific treatment, such as statistics, monitoring, QoS, redundancy elimination and reordering, etc. |
| | Encapsulation of OpenFlow over Delay-Tolerant Networking (DTN) Using the Bundle Protocol |
| |
|
This document specifies a method for carrying OpenFlow messages over Delay-Tolerant Networking (DTN) using the Bundle Protocol (BP). The method encapsulates OpenFlow messages as BP payloads and defines the mapping between OpenFlow messages and Bundles, the payload format, and addressing and multiplexing considerations based on DTN Endpoint Identifiers (EIDs). This document further discusses conditions that may occur on intermittently connected or high-latency links, including fragmentation, duplicate delivery, out-of-order arrival, and expiration, and defines corresponding message handling rules. These rules enable the transmission of OpenFlow messages across DTN without modifying the semantics of the OpenFlow protocol. |
| | Benchmarking Terminology for Large Language Model Serving |
| |
|
This document defines terminology for benchmarking the performance of Large Language Model (LLM) inference serving systems. It establishes a shared vocabulary for latency, throughput, resource utilization, and quality metrics applicable to inference engines, application gateways, and compound agentic systems. This document defines terminology only and does not prescribe benchmark methodologies or acceptance thresholds. |
| | Benchmarking Methodology for Large Language Model Serving |
| |
|
This document defines benchmarking methodologies for Large Language Model (LLM) inference serving systems. It provides test procedures, setup parameters, measurement specifications, and reporting formats for evaluating latency, throughput, scheduling, and resource management characteristics. This document is a companion to "Benchmarking Terminology for Large Language Model Serving" and SHOULD be consulted alongside that terminology document. |
| | Performance Benchmarking Profiles for Large Language Model Serving Systems |
| |
|
This document defines performance benchmarking profiles for Large Language Model (LLM) serving systems. Profiles bind the terminology defined in draft-gaikwad-llm-benchmarking-terminology and the procedures described in draft-gaikwad-llm-benchmarking-methodology to concrete architectural roles and workload patterns. Each profile clarifies the System Under Test (SUT) boundary, measurement points, and interpretation constraints required for reproducible and comparable benchmarking. This document specifies profiles only. It does not define new metrics, benchmark workloads, or acceptance thresholds. |
| | Guidelines for IANA DNS Root Zone Publication List Providers |
| |
|
This document describes guidelines for entities that wish to publish a list of URLs from where the contents of the IANA DNS root zone may be obtained. These guidelines are specifically provided as guidance to IANA, but these suggestions may be applicable to any entity wishing to build a list of IANA DNS root zone sources for their own purposes. |
| | Real Human Verification (RHV): A Hardware-Rooted Cryptographic Standard for Human-Origin Visual Evidence |
| |
|
This document defines Real Human Verification (RHV), a public cryptographic standard for establishing a constitutional root of trust for direct human-origin visual evidence in the post-AI era. RHV specifies cryptographic primitives, hardware-backed capture requirements, and public transparency logging mechanisms that allow digital photos and videos to prove that they originate from a physically authenticated human capture pipeline. RHV does not judge content truth; it defines cryptographically verifiable human-origin capture, tamper-evident integrity, and publicly auditable provenance chains. By anchoring visual evidence in hardware roots of trust and append-only transparency logs, RHV provides a neutral, publicly verifiable foundation for judicial, institutional, and societal reliance on digital visual evidence across operating systems, cameras, drones, and sensor-based capture devices. |
| | Persistent Systems Email: prasad_k1@persistent.com |
| |
|
This document specifies a universal, tunnel-less mechanism for Secure Service Edge (SSE) steering based on a new SSE Identification Header (SSE-ID). The architecture enables endpoints, OS network stacks, and enterprise SD-WAN edge devices to signal the intent for traffic to be routed to an SSE provider without using GRE or IPsec tunnels. This document also defines an SD-WAN extension called the Direct Switchover Token (DST). DST provides a vendor-agnostic mechanism enabling SD-WAN spokes to establish direct, encrypted, spoke-to-spoke paths for traffic that does not require SSE inspection. DST is issued by a central controller after initial packets reach a hub or the controller and after evaluating policy and SSE requirements. Additionally, this document introduces (a) a Participating ISP routing model using an SSE-Only Public Pool (SOPP) and an SSE POP ID (SPID) to locate and route to SSE edges on SSE-enabled circuits, and (b) a Merger & Acquisition (M&A) access mode that allows two enterprises to access resources via the SSE cloud using Enterprise IDs; in this mode, traffic is spliced inside the SSE fabric by EID, with address-domain isolation to avoid IP conflicts. Together, SSE-ID and DST—augmented with SOPP/SPID and M&A mode— provide a unified, interoperable, and tunnel-less architecture for SSE integration, SD-WAN optimization, inter-domain routing, and enterprise-to-enterprise access. |
| | EntglDb Peer-to-Peer Communication and Security Protocol |
| |
|
This document specifies the peer-to-peer communication protocol used by EntglDb, a decentralized database system. It defines the mechanisms for local node discovery via UDP, secure connection establishment over TCP using ECDH and AES-GCM, and the message framing and synchronization flow required for data consistency across nodes. |
| | YANG Data Model for RPKI to Router Protocol |
| |
| | draft-ietf-sidrops-rtr-yang-01.txt |
| | Date: |
20/01/2026 |
| | 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). |
| | A YANG Data Model for Traffic Engineering Tunnels,Label Switched Paths,and Interfaces |
| |
| | draft-ietf-teas-yang-te-41.txt |
| | Date: |
20/01/2026 |
| | Authors: |
Tarek Saad, Rakesh Gandhi, Xufeng Liu, Vishnu Beeram, Igor Bryskin |
| | Working Group: |
Traffic Engineering Architecture and Signaling (teas) |
|
This document defines a YANG data model for the provisioning and management of Traffic Engineering (TE) tunnels, Label Switched Paths (LSPs), and interfaces. The model covers data that is independent of any technology or dataplane encapsulation and is divided into two YANG modules that cover device-specific, and device independent data. This model covers data for configuration, operational state, remote procedural calls, and event notifications. |
| |
|
| |
| | iCalendar Format Extensions for JSCalendar |
| |
|
This document defines a set of new elements for iCalendar and extends the use of existing ones. Their main purpose is to extend the semantics of iCalendar with elements defined in JSCalendar, but the new definitions also aim to be useful within just the iCalendar format. This document updates RFC 5545 ("iCalendar") and its extension documents RFC 7986 and RFC 9073. |
| | Operations,Administration and Maintenance (OAM) features for Reliable and Available Wireless |
| |
|
Some critical applications may use a wireless infrastructure. However, wireless networks exhibit a bandwidth of several orders of magnitude lower than wired networks. Besides, wireless transmissions are lossy by nature; the probability that a packet cannot be decoded correctly by the receiver may be quite high. In these conditions, providing high reliability and a low delay is challenging. This document lists the requirements of the Operation, Administration, and Maintenance (OAM) features are recommended to provide availability and reliability on top of a collection of wireless segments. This document describes the benefits, problems, and trade-offs for using OAM in wireless networks to achieve Service Level Objectives (SLO). |
| | BGP SR Policy Extensions for Segment List Identifier |
| |
|
Segment Routing is a source routing paradigm that explicitly indicates the forwarding path for packets at the ingress node. An SR Policy is a set of candidate paths, each consisting of one or more segment lists. This document defines extensions to BGP SR Policy to specify the identifier of segment list. |
| | YANG Data Model for BGP about RPKI |
| |
|
This document defines YANG data models for configuring and managing BGP information about Resource Public Key Infrastructure (RPKI). |
| | OSPFv2 Anycast Property Advertisement |
| |
|
An IP prefix may be configured as anycast and as such the same value can be advertised by multiple routers. It is useful for other routers to know that the advertisement is for an anycast prefix. This document defines a new flag in the OSPFv2 Extended Prefix TLV Flags to advertise the anycast property. The document also specifies a companion YANG module for managing this function. |
| | Deep Audio Redundancy (DRED) Extension for the Opus Codec |
| |
|
This document proposes a mechanism for embedding very low bitrate deep audio redundancy (DRED) within the Opus codec (RFC6716) bitstream. |
| | MOQT Streaming Format |
| |
|
This document specifies the MOQT Streaming Format, designed to operate on Media Over QUIC Transport. |
| | Semantic Metadata Annotation for Network Anomaly Detection |
| |
|
This document explains the motivation for defining semantic metadata annotations to help testing, validating and comparing Outlier and Symptom detection systems. These semantic annotations can be supported by supervised and semi-supervised machine learning algorithms and enable data exchange among network operators, vendors and academia, making anomalies apprehensible for humans. The proposed semantics uniforms the network anomaly data exchange between operators and vendors to improve their Service Disruption Detection Systems. |
| | Notable CBOR Tags |
| |
|
The Concise Binary Object Representation (CBOR, RFC 8949) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. In CBOR, one point of extensibility is the definition of CBOR tags. RFC 8949's original edition, RFC 7049, defined a basic set of 16 tags as well as a registry that can be used to contribute additional tag definitions [IANA.cbor-tags]. Since RFC 7049 was published, at the time of writing some 250 definitions of tags and ranges of tags have been added to that registry. The present document provides a roadmap to a large subset of these tag definitions. Where applicable, it points to an IETF standards or standard development document that specifies the tag. Where no such document exists, the intention is to collect specification information from the sources of the registrations. After some more development, the present document is intended to be useful as a reference document for the IANA registrations of the CBOR tags the definitions of which have been collected. |
| | IETF Experiments |
| |
|
This document describes IETF protocol experiments and provides guidelines for the publication of Experimental RFCs. |
| | Optional IS-IS Fragment Timestamping and Database Fingerprint |
| |
|
Many applications in today’s networks rely on reliable and timely flooding of link-state information, such as, but not limited to Traffic Engineered networks. If such link-state information is delayed it can be difficult for those applications to adequately fulfill their intended functionality. This document describes extensions to ISIS supporting distribution of fragment origination time. The origination time can be used to aid troubleshooting and/or by the applications themselves to improve their behavior. Additionally, a mechanism is proposed by which the consistency of databases on all routers in the network can be easily verified and a rough metric of diffusion behavior derived. |
| | Use Cases and Properties for Integrating Remote Attestation with Secure Channel Protocols |
| |
| | draft-mihalcea-seat-use-cases-01.txt |
| | Date: |
19/01/2026 |
| | Authors: |
Ionut Mihalcea, Muhammad Sardar, Thomas Fossati, Tirumaleswar Reddy.K, Yuning Jiang, Meiling Chen |
| | Working Group: |
Individual Submissions (none) |
|
This document outlines use cases and desirable properties for integrating remote attestation (RA) capabilities with secure channel establishment protocols, with an initial focus on Transport Layer Security (TLS) v1.3 Handshake. Traditional peer authentication in TLS establishes trust in a peer's network identifiers but provides no assurance regarding the integrity of its underlying software and hardware stack. Remote attestation addresses this gap by enabling a peer to provide verifiable evidence about its current state, including the state of its trusted computing base (TCB). This document explores specific use cases, such as confidential data collaboration and secure secrets provisioning, to motivate the need for this integration. From these use cases, it specifies a set of essential properties the protocol solution must have, including cryptographic binding to the TLS connection, evidence freshness, and flexibility to support different attestation models. This document is intended to serve as an input to the design of protocol solutions within the SEAT working group. |
| | OAuth 2.0 RAR Metadata and Error Signaling |
| |
|
OAuth 2.0 Rich Authorization Requests (RAR), as defined in [RFC9396], enables fine-grained authorization requests, using structured JSON objects. While RAR [RFC9396] standardizes the exchange and handling of authorization details, it does not define a mechanism for clients to discover how to construct valid authorization details types. This document defines a machine-readable metadata format for authorization servers to provide authorization details type documentation and JSON Schema [JSON.Schema] definitions, as well as interoperable discovery via OAuth Resource Server Metadata [RFC9728]. This document also defines a new WWW-Authenticate normative OAuth error code, insufficient_authorization_details, enabling resource servers to indicate inadequate authorization details as the cause of failure. It also defines an OPTIONAL response body which MAY be returned alongside the insufficient_authorization_details error, providing an informative yet actionable authorization details object, which can be used directly in a subsequent OAuth request. |
| | Geospatial Resource Discovery (GRD): Problem Statement and Conceptual Architecture |
| |
|
The Internet provides standardized mechanisms for resolving identifiers, such as domain names, to network locations. These mechanisms assume that a client already knows the identifier of the resource it wishes to access. Emerging classes of applications, including augmented reality, autonomous systems, robotics, and spatial computing, operate under a different assumption. In these systems, discovery begins with physical presence and observer context rather than with a predefined name. This document describes the architectural gap addressed by a Geospatial Resource Discovery service. It defines the problem space, explains why existing standards are insufficient, and outlines a conceptual architecture for spatial discovery. This document is informational and architectural in nature. It does not define a protocol, data format, or implementation. |
| | An IANA root zone publication source list format |
| |
|
This document describes a machine readable format to be used by IANA to publish a list of sources where the contents of the IANA DNS Root Zone may be fetched from. |
| | A Multiplane Architecture Proposal for the Quantum Internet |
| |
|
A consistent reference architecture model for the Quantum Internet is required to progress in its evolution, providing a framework for the integration of the protocols applicable to it, and enabling the advance of the applications based on it. This model has to satisfy three essential requirements: agility, so it is able to adapt to the evolution of quantum communications base technologies, sustainability, with open availability in technological and economical terms, and pliability, being able to integrate with the operations and management procedures in current networks. This document proposes such an architecture framework, with the goal of providing a conceptual common framework for the integration of technologies intended to build the Quantum Internet infrastructure and its integration with the current Internet. The framework is based on the already extensive experience in the deployment of QKD network infrastructures and on related initiatives focused on the integration of network infrastructures and services. |
| | YANG Models for Quality of Service (QoS) in IP networks |
| |
| | draft-ietf-rtgwg-qos-model-14.txt |
| | Date: |
19/01/2026 |
| | Authors: |
Aseem Choudhary, Mahesh Jethanandani, Ebben Aries, Helen Chen |
| | Working Group: |
Routing Area Working Group (rtgwg) |
|
This document describes a YANG model for management of Quality of Service (QoS) in IP networks. |
| | System for Cross-domain Identity Management: Definitions,Overview,Concepts,and Requirements |
| |
|
This document provides definitions, overview and selected use cases of the System for Cross-domain Identity Management (SCIM). It lays out the system's concepts, models, and flows, and it includes use cases, and implementation considerations. |
| | Introducing Resource Awareness to SR Segments |
| |
|
This document describes a mechanism to allocate network resources to one or a set of Segment Routing Identifiers (SIDs). Such SIDs are referred to as resource-aware SIDs. The resource-aware SIDs retain their original forwarding semantics, with the additional semantics to identify the set of network resources available for the packet processing and forwarding action. The proposed mechanism is applicable to both segment routing with MPLS data plane (SR-MPLS) and segment routing with IPv6 data plane (SRv6). |
| | A YANG Data Model for RSVP-TE Protocol |
| |
| | draft-ietf-teas-yang-rsvp-te-10.txt |
| | Date: |
19/01/2026 |
| | Authors: |
Vishnu Beeram, Tarek Saad, Rakesh Gandhi, Xufeng Liu, Igor Bryskin, Himanshu Shah |
| | Working Group: |
Traffic Engineering Architecture and Signaling (teas) |
|
This document defines a YANG data model for the configuration and management of RSVP (Resource Reservation Protocol) to establish Traffic-Engineered (TE) Label-Switched Paths (LSPs) for MPLS (Multi- Protocol Label Switching) and other technologies. The model defines a generic RSVP-TE module for signaling LSPs that are technology agnostic. The generic RSVP-TE module is to be augmented by technology specific RSVP-TE modules that define technology specific data. This document also defines the augmentation for RSVP-TE MPLS LSPs model. This model covers data for the configuration, operational state, remote procedural calls, and event notifications. |
| | YANG Data Model for Scheduled Attributes |
| |
|
The YANG model in this document includes three modules, and can be used to manage network resources and topologies with scheduled attributes, such as predictable link loss and link connectivity as a function of time. The intent is to have this information be utilized by Time-Variant Routing systems. |
| |
|
| |
| | IPv6 Performance and Diagnostic Metrics Version 2 (PDMv2) Destination Option |
| |
| | draft-ietf-ippm-encrypted-pdmv2-13.txt |
| | Date: |
18/01/2026 |
| | Authors: |
Nalini Elkins, michael ackermann, Ameya Deshpande, Tommaso Pecorella, Adnan Rashid, Lorenzo Fedi |
| | Working Group: |
IP Performance Measurement (ippm) |
|
RFC 8250 defines an IPv6 Destination Option that carries Performance and Diagnostic Metrics (PDM) such as sequence numbers and timing information. While useful for measurement and troubleshooting, clear-text PDM data may expose operational characteristics of endpoints and networks. This document defines PDMv2, a revised version of PDM that introduces a registration-based security model. Instead of specifying cryptographic algorithms or inline key negotiation, PDMv2 relies on a prior registration process to authenticate entities, authorize participation, and establish shared secrets. These secrets are then used by endpoints and authorized analyzers to protect and interpret PDMv2 data according to local policy. This document specifies the PDMv2 semantics, header structure, and operational model. Cryptographic algorithms, key derivation functions, and cipher negotiation are explicitly out of scope. |
| | NETCONF over QUIC |
| |
| | draft-ietf-netconf-over-quic-07.txt |
| | Date: |
18/01/2026 |
| | Authors: |
Jinyou Dai, Shaohua Yu, Weiqiang Cheng, Marc Blanchet, Per Andersson |
| | Working Group: |
Network Configuration (netconf) |
|
This document specifies how to use QUIC as a secure transport for exchanging Network Configuration Protocol (NETCONF) messages. NETCONF over QUIC allows to take advantage of QUIC streams, for example, to eliminate some TCP head-of-line blocking issues. NETCONF over QUIC provides security properties similar to NETCONF over TLS. This document also defines a YANG module which augments the ietf- netconf-client and ietf-netconf-server YANG modules. Editorial note (to be removed by the RFC Editor This draft contains placeholder values that need to be replaced with finalized values at the time of publication. This note summarizes all of the substitutions that are needed. No other RFC Editor instructions are specified elsewhere in this document. Artwork in this document contains shorthand references to drafts in progress. Please apply the following replacements: * AAAA --> the assigned RFC value for this draft * BBBB --> the assigned RFC value for draft-ietf-netconf-netconf- client-server * CCCC --> the assigned RFC value for draft-ietf-netconf-quic- client-server |
| | YANG Module Versioning Requirements |
| |
|
This document describes the problems that can arise because of the YANG language module update rules, that require all updates to YANG module preserve strict backwards compatibility. It also defines the requirements on any solution designed to solve the stated problems. This document does not consider possible solutions, nor endorse any particular solution. |
| | An Architecture for YANG-Push to Message Broker Integration |
| |
|
This document describes the motivation and architecture of a native YANG-Push notifications and YANG Schema integration into a Message Broker and YANG Schema Registry. |
| | A Framework for a Network Anomaly Detection Architecture |
| |
|
This document describes the motivation and architecture of a Network Anomaly Detection Framework and the relationship to other documents describing network Symptom semantics and network incident lifecycle. The described architecture for detecting IP network service interruption is designed to be generic applicable and extensible. Different applications are described and examples are referenced with open-source running code. |
| | Extensible YANG Model for Network Telemetry Messages |
| |
|
This document defines an extensible message schema in YANG to be used at data collection to transform Network Telemetry messages into external systems such as Message Brokers. The extensible message schema enables data collectors to add metadata for the provenance of the operational network data. |
| | Terminal Identity Authentication Based on Address Label |
| |
|
This document proposes an IPv6-based address label terminal identity authentication architecture, which tightly binds identity information to the source address of data packets. This approach enables hop-by- hop identity authentication while ensuring source address verification. The mechanism facilitates user identity verification, ensuring privacy protection, security, and efficient auditing. Additionally, this document details the implementation of address label authentication within the IPv6 extension header. |
| | Use Cases for Authentication of Web Bots |
| |
|
This draft outlines use cases for authentication for bot clients on the Web. About This Document This note is to be removed before publishing as an RFC. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-nottingham-webbotauth-use- cases/. information can be found at https://mnot.github.io/I-D/. Source for this draft and an issue tracker can be found at https://github.com/mnot/I-D/labels/webbotauth-use-cases. |
| | Agent Interaction & Delegation Protocol (AIDP) |
| |
|
This document specifies the Agent Interaction & Delegation Protocol (AIDP), a control-plane protocol for secure, auditable, and interoperable software agents. AIDP defines standardized mechanisms for expressing intent, enforcing authority, delegating capabilities, executing actions, and binding execution results to agent reasoning across heterogeneous systems and administrative domains. |
| | Complex Information: A Conceptual Extension of Classical Information Models for Human Decision Contexts |
| |
|
Classical information models have proven highly effective for the design and operation of machine-based communication and computation systems. These models intentionally abstract away meaning, interpretation, and human decision-making in order to achieve formal clarity and computability. This document describes a conceptual extension to classical information models, referred to as complex information, which represents information as consisting of two components: a real component, suitable for machine processing, and an imaginary component, representing human context, meaning, and non-computable decision factors. The proposed concept does not replace existing information theory, nor does it define new protocols or standards. Instead, it provides a descriptive framework for reasoning about information systems that interact with human decision processes, trust, and interpretation. |
| | Identity Namespace Architecture |
| |
|
This document defines the Identity Namespace architecture. |
| | Message Envelope Format |
| |
|
This document defines the message envelope format used for structured, verifiable message exchange. |
| | SoftHSM Enforcement Rules |
| |
|
This document defines enforcement and governance rules for the SoftHSM trust model. |
| | Source Address Validation in Intra-domain Networks Gap Analysis,Problem Statement,and Requirements |
| |
|
This document provides a gap analysis of existing intra-domain source address validation mechanisms, describes the fundamental problems, and defines the basic requirements for technical improvements. |
| |
|
| |
| | Kemeleon Encodings |
| |
|
This document specifies Kemeleon encoding algorithms for encoding ML- KEM encapsulation keys and ciphertexts as random bytestrings. Kemeleon encodings provide obfuscation of encapsulation keys and ciphertexts, relying on module LWE assumptions. |
| | Deadline Based Deterministic Forwarding |
| |
|
This document describes a deadline based deterministic forwarding mechanism for IP/MPLS network with the corresponding resource reservation, admission control, scheduling and policing processes to provide guaranteed latency bound. It employs a latency compensation technique with a stateless core, to replace reshaping, making it suitable for the Differentiated Services (Diffserv) architecture [RFC2475]. |
| | Timeslot Queueing and Forwarding Mechanism |
| |
|
IP/MPLS networks use packet switching (with the feature store-and- forward) and are based on statistical multiplexing. Statistical multiplexing is essentially a variant of time division multiplexing, which refers to the asynchronous and dynamic allocation of link timeslot resources. In this case, the service flow does not occupy a fixed timeslot, and the length of the timeslot is not fixed, but depends on the size of the packet. Statistical multiplexing has certain challenges and complexity in meeting deterministic QoS, and its delay performance is dependent on the used queueing mechanism. This document further describes a generic time division multiplexing scheme for layer-3 in an IP/MPLS networks, called timeslot queueing and forwarding (TQF) mechanism. TQF is an enhancement based on TSN TAS and allows the data plane to create a flexible timeslot mapping scheme based on available timeslot resources. It defines a cyclic period consisting of multiple timeslots where a flow is assigned to be transmited within one or more dedicated timeslots. The objective of TQF is to better handle large scaling requirements. |
| | Deterministic Networking (DetNet) Data Plane - Tagged Cyclic Queuing and Forwarding (TCQF) for bounded latency with low jitter in large scale DetNets |
| |
| | draft-ietf-detnet-tcqf-00.txt |
| | Date: |
16/01/2026 |
| | Authors: |
Toerless Eckert, Yizhou Li, Stewart Bryant, Andrew Malis, Jeong-dong Ryoo, Peng Liu, Guangpeng Li, Shoushou Ren |
| | Working Group: |
Deterministic Networking (detnet) |
|
This memo specifies a forwarding method for bounded latency and bounded jitter for Deterministic Networks and is a variant of the IEEE TSN Cyclic Queuing and Forwarding (CQF) method. Tagged CQF (TCQF) supports more than 2 cycles and indicates the cycle number via an existing or new packet header field called the tag to replace the cycle mapping in CQF which is based purely on synchronized reception clock. This memo standardizes TCQF as a mechanism independent of the tagging method used. It also specifies tagging via the (1) the existing MPLS packet Traffic Class (TC) field for MPLS packets, (2) the IP/IPv6 DSCP field for IP/IPv6 packets, and (3) a new TCQF Option header for IPv6 packets. Target benefits of TCQF include low end-to-end jitter, ease of high- speed hardware implementation, optional ability to support large number of flow in large networks via DiffServ style aggregation by applying TCQF to the DetNet aggregate instead of each DetNet flow individually, and support of wide-area DetNet networks with arbitrary link latencies and latency variations as well as low accuracy clock synchronization. |
| | Deterministic Networking (DetNet) Data Plane - guaranteed Latency Based Forwarding (gLBF) for bounded latency with low jitter and asynchronous forwarding in Deterministic Networks |
| |
| | draft-ietf-detnet-glbf-00.txt |
| | Date: |
16/01/2026 |
| | Authors: |
Toerless Eckert, Alexander Clemm, Stewart Bryant, Stefan Hommes |
| | Working Group: |
Deterministic Networking (detnet) |
|
This memo proposes a mechanism called "guaranteed Latency Based Forwarding" (gLBF) as part of DetNet for hop-by-hop packet forwarding with per-hop deterministically bounded latency and minimal jitter. gLBF is intended to be useful across a wide range of networks and applications with need for high-precision deterministic networking services, including in-car networks or networks used for industrial automation across on factory floors, all the way to ++100Gbps country-wide networks. Contrary to other mechanisms, gLBF does not require network wide clock synchronization, nor does it need to maintain per-flow state at network nodes, avoiding drawbacks of other known methods while leveraging their advantages. Specifically, gLBF uses the queuing model and calculus of Urgency Based Scheduling (UBS, [UBS]), which is used by TSN Asynchronous Traffic Shaping [TSN-ATS]. gLBF is intended to be a plug-in replacement for TSN-ATN or as a parallel mechanism beside TSN-ATS because it allows to keeping the same controller-plane design which is selecting paths for TSN-ATS, sizing TSN-ATS queues, calculating latencies and admitting flows to calculated paths for calculated latencies. In addition to reducing the jitter compared to TSN-ATS by additional buffering (dampening) in the network, gLBF also eliminates the need for per-flow, per-hop state maintenance required by TSN-ATS. This avoids the need to signal per-flow state to every hop from the controller-plane and associated scaling problems. It also reduces implementation cost for high-speed networking hardware due to the avoidance of additional high-speed speed read/write memory access to retrieve, process and update per-flow state variables for a large number of flows. |
| | DTNMA Application Resource Identifier (ARI) |
| |
| | draft-ietf-dtn-ari-08.txt |
| | Date: |
16/01/2026 |
| | Authors: |
Edward Birrane, Emery Annis, Brian Sipos |
| | Working Group: |
Delay/Disruption Tolerant Networking (dtn) |
|
This document defines the structure, format, and features of the naming scheme for the objects defined in the Delay-Tolerant Networking Management Architecture (DTNMA) Application Management Model (AMM), in support of challenged network management solutions described in the DTNMA document. This document defines the DTNMA Application Resource Identifier (ARI), using a text-form based on the common Uniform Resource Identifier (URI) and a binary-form based on Concise Binary Object Representation (CBOR). These meet the needs for a concise, typed, parameterized, and hierarchically organized set of managed data elements. |
| | DTNMA Application Management Model (AMM) and Data Models |
| |
| | draft-ietf-dtn-amm-06.txt |
| | Date: |
16/01/2026 |
| | Authors: |
Edward Birrane, Brian Sipos, Justin Ethier |
| | Working Group: |
Delay/Disruption Tolerant Networking (dtn) |
|
This document defines a model that captures the information necessary to asynchronously manage applications within the Delay-Tolerant Networking Management Architecture (DTNMA). This model provides a set of common managed object types, data types and structures, and a template for information needed within each application data model. The built-in definitions are made to be extensible by applications without needing to modify core Agent or Manager behavior. |
| | Bundle Protocol Endpoint ID Patterns |
| |
|
This document extends the Bundle Protocol Endpoint ID (EID) concept into an EID Pattern, which is used to categorize any EID as matching a specific pattern or not. EID Patterns are suitable for expressing configuration, for being used on-the-wire by protocols, and for being easily understandable by a layperson. EID Patterns include scheme- specific optimizations for expressing set membership and each scheme pattern includes text and binary encoding forms; the pattern for the "ipn" EID scheme being designed to be highly compressible in its binary form. This document also defines a Public Key Infrastructure Using X.509 (PKIX) Other Name form to contain an EID Pattern and a handling rule to use a pattern to match an EID. |
| | ACLs within the NFSv4 Protocols |
| |
|
This document is part of the set of documents intended to update the description of NFSv4 Minor Version One as part of the rfc8881bis respecification effort for NFSv4.1. It describes the structure and function of NFSv4 Access Control Lists within NFSv4.0 and NFSv4.1. These minor versions and forthcoming ones define ACLs using an ACL structure derived from Windows ACLs. Support for other ACL approaches such as draft-POSIX ACLs remains an option that could be taken advantage of in later minor versions such as NFSv4.2. This document describes the structure of these Windows-derived NFSv4 ACLs and their role in the NFSv4 security architecture. While the focus of this document is on the role of these ACLs in providing a more flexible approach to file access authorization than is made available by the POSIX-derived authorization-related attributes, the potential provision of other security-related functionality based on ACLs is covered as well. Because of the failure of previous specifications to provide a satisfactory description of the authorization semantics of NFSv4 ACLs, this document takes a different approach to many matters while maintaining compatibility with implementations based on previous specifications. When the resulting document is eventually published as an RFC, it will supersede the descriptions of ACL structure and semantics appearing in existing minor version specification documents for NFSv4.0 and NFSv4.1, thereby updating RFC7530 and RFC8881. |
| | Binary Uniform Language Kit 1.0 |
| |
|
This specification describes a uniform, decentrally extensible and efficient format for data serialization. |
| | SCION Control Plane PKI |
| |
|
This document presents the trust concept and design of the SCION _Control Plane Public Key Infrastructure (CP-PKI)_. SCION (Scalability, Control, and Isolation On Next-generation networks) is a path-aware, inter-domain network architecture where the Control Plane PKI handles cryptographic material and is the foundation of the authentication procedures in SCION. It is used by SCION's Control Plane ([I-D.dekater-scion-controlplane]) to authenticate and verify path information, and provisions SCION's trust model based on Isolation Domains. This document describes the trust model behind the SCION Control Plane PKI, including the specifications of the different types of certificates and the Trust Root Configuration. It also describes how to deploy the Control Plane PKI infrastructure. This document contains new approaches to secure path aware networking. It is not an Internet Standard, has not received any formal review of the IETF, nor was the work developed through the rough consensus process. The approaches offered in this work are offered to the community for its consideration in the further evolution of the Internet. |
| | Scale-Up Network Header (SUNH) |
| |
|
This document specifies the Scale-Up Network Header that is a concise and efficient network layer header. The primary use case is high performance networking in limited domains, and in particular in scale-up networks for AI where even modest packet overhead packet may be detrimental to overall performance. |
| | Gateway Requirements for Dynamic Multi-agents Secured Collaboration |
| |
|
This document discusses the requirements for introducing Gateways into Dynamic Multi-agents Secured Collaboration for better scalability, communication efficiency, and security etc. This document also discusses the gaps of current hardware/software gateways that could not fulfil the task, so that a new kind of entity, e.g. DMSC Gateway, is needed. |
| | Security Analysis of Multi-agents Secured Communication and Limitations of Existing Protocols |
| |
|
Multi-agents systems (MAS) increasingly cooperate through workflow, orchestrated, and mesh communication patterns. While existing Internet protocols provide confidentiality and endpoint authentication, they were not designed for agent-native semantics such as dynamic identity, computation-bounded requests, context integrity, and intermediary trust. This document analyzes security risks in agent communication and identifies limitations in widely deployed protocols (TLS, HTTP, MQTT,A2A and etc.) and developer framework (AutoGen and etc.). This document intend to establish a common problem statement and gap analysis to inform future IETF standardization. |
| | BMP Statistics Information TLV |
| |
|
The BGP Monitoring Protocol (BMP) defines statistics reports that provide periodic snapshots of various BGP-related metrics. When statistics are reported periodically, the snapshot values may not reflect the variations that occurred between reporting intervals. This document defines a Statistics Information TLV that can be used to convey additional statistical information about BMP gauge-type statistics during the reporting period. This TLV reports the minimum and maximum values observed (with timestamps indicating when they occurred), along with additional statistical measures such as average, median, or snapshot values. This enables BMP collectors to better understand the dynamics of monitored statistics even when the reported snapshot values appear constant. |
| | BMP Statistics Information TLV |
| |
|
The BGP Monitoring Protocol (BMP) defines statistics reports that provide periodic snapshots of various BGP-related metrics. When statistics are reported periodically, the snapshot values may not reflect the variations that occurred between reporting intervals. This document defines a Statistics Information TLV that can be used to convey additional statistical information about BMP gauge-type statistics during the reporting period. This TLV reports the minimum and maximum values observed (with timestamps indicating when they occurred), along with additional statistical measures such as average, median, or snapshot values. This enables BMP collectors to better understand the dynamics of monitored statistics even when the reported snapshot values appear constant. |
| |
|
| |
| | Digital Emblems - Use Cases and Requirements |
| |
| | draft-ietf-diem-requirements-01.txt |
| | Date: |
15/01/2026 |
| | Authors: |
Casey Deccio, Rahel Fainchtein, Felix Linker, Jim Reid, Alex Rosenberg, Allison Mankin |
| | Working Group: |
Digital Emblems (diem) |
|
Digital emblems are a means for digital assets to signal that they should be treated in a specific way by reference to some normative framework. This document lists the requirements and use cases that an architecture for digital emblems must accommodate. |
| | DTNMA Application Data Model (ADM) YANG Syntax |
| |
| | draft-ietf-dtn-adm-yang-06.txt |
| | Date: |
15/01/2026 |
| | Authors: |
Edward Birrane, Brian Sipos, Justin Ethier |
| | Working Group: |
Delay/Disruption Tolerant Networking (dtn) |
|
This document defines a concrete syntax for encoding a Delay-Tolerant Networking Management Architecture (DTNMA) Application Data Model (ADM) using the syntax and modular structure, but not the full data model, of YANG. Extensions to YANG are defined to capture the specifics needed to define DTNMA Application Management Model (AMM) objects and to use the Application Resource Identifier (ARI) data- value syntax. |
| | DTNMA Asynchronous Management Protocol (AMP) |
| |
| | draft-ietf-dtn-amp-03.txt |
| | Date: |
15/01/2026 |
| | Authors: |
Edward Birrane, Brian Sipos |
| | Working Group: |
Delay/Disruption Tolerant Networking (dtn) |
|
This document defines a messaging protocol for the Delay-Tolerant Networking (DTN) Management Architecture (DTNMA) Asynchronous Management Model (AMM) and a transport binding for exchanging those messages over a network. This Asynchronous Management Protocol (AMP) does not require transport-layer sessions, operates over unidirectional links, and seeks to reduce the energy and compute power necessary for performing remote management of resource constrained devices possibly over challenged networks. |
| | BGP SR Policy Extensions for Network Resource Partition |
| |
|
Segment Routing (SR) Policy is a set of candidate paths, each consisting of one or more segment lists and the associated information. The header of a packet steered in an SR Policy is augmented with an ordered list of segments associated with that SR Policy. A Network Resource Partition (NRP) is a subset of network resources allocated in the underlay network which can be used to support one or a group of RFC 9543 network slice services. In networks where there are multiple NRPs, an SR Policy may be associated with a particular NRP. The association between SR Policy and NRP needs to be specified, so that for service traffic which is steered into the SR Policy, the header of the packets can be augmented with the information associated with the NRP. An SR Policy candidate path can be distributed using BGP SR Policy. This document defines the extensions to BGP SR policy to specify the NRP which the SR Policy candidate path is associated with. |
| | Optimized Rekeys in the Internet Key Exchange Protocol Version 2 (IKEv2) |
| |
|
This document describes a method for reducing the size of the Internet Key Exchange version 2 (IKEv2) CREATE_CHILD_SA exchanges used for rekeying of the IKE or Child SA by replacing the SA and TS payloads with a Notify Message payload. Reducing size and complexity of IKEv2 exchanges is especially useful for low power consumption battery powered devices. |
| | Proxying Bound UDP in HTTP |
| |
|
The mechanism to proxy UDP in HTTP only allows each UDP proxying request to transmit to a specific host and port. This is well suited for UDP client-server protocols such as HTTP/3, but is not sufficient for some UDP peer-to-peer protocols like WebRTC. This document proposes an extension to UDP proxying in HTTP that enables such use- cases. |
| | Considerations of AI-powered Autonomic Service Agent Communication |
| |
|
ANIMA defined Autonomic Service Agent to build intelligent management functions into network devices, and could interact with each other through a standard protocol (aka GRASP).With the rapid advancement of Large Language Model (LLM)-driven AI technologies, there is now a potential opportunity to enhance the ASA to be AI-powered, thereby elevating the intelligence of device-built-in management functions to a whole new level.This document analyzes the impact of the AI-powered ASA, mostly from the perspective of the ASA communication protocol. |
| | Adding an Atomic SWAP Operation to NFSv4.2 |
| |
|
The Network File System version 4.2 (NFSv4.2) does not provide support for atomic multi-block updates to file data. This document introduces a new SWAP operation which provides for such atomic updates. This document extends NFSv4.2 (see RFC7862). |
| | A Systemic Meditation on Internet Connectivity Equilibrium |
| |
|
This document presents a systemic meditation on how the Internet arrived at its present connectivity equilibrium. The analysis proceeds by retrospective reconstruction: examining observable adaptations, constraints, and deferred decisions across multiple layers of the stack, rather than by benchmarking, simulation, or protocol comparison. The term "meditation" is used deliberately to indicate a method grounded in historical observation, accumulated operational experience, and the interpretation of persistent compensatory mechanisms as empirical evidence of structural conditions. The document does not assign fault, advocate specific remedies, or propose new protocol mechanisms. Instead, it seeks to explain how a sequence of locally rational responses to real pressures interacted over time to produce a stable, but heavily mediated, connectivity equilibrium at Internet scale. |
| | ADEM Core Specification |
| |
|
In times of armed conflict, the protective emblems of the red cross, red crescent, and red crystal are used to mark physical assets. This enables military units to identify assets as respected and protected under international humanitarian law. This draft specifies the format and trust architecture of a protective, digital emblem to network-connected infrastructure. Such emblems mark assets as protected under IHL analogously to the physical emblems. |
| | ADEM - Distribution and Discovery over DNS |
| |
|
TODO Abstract |
| | IPv6 Sparse Random Addressing |
| |
|
The IPv6 address space is huge. This document discusses how "sparse random addressing" can be used to defeat DDOS attacks, and also to create paid-access websites. The essential idea is to use the host ID portion of an IPv6 address as a time-based password that only paid subscribers know. (They know it by running a program on the device that they use to access the website. That program uses the current time and a secret shared with the web server to calculate the current host ID.) Each subscriber has a unique secret so, at any point in time, uses a unique IPv6 address to access the website. Sparseness prevents attack packets from reaching the web server. Uniqueness creates accountability. To protect routers from flood attacks, the globally routable /48 prefix is also randomized, in a way that exploits BGP route propagation delay to partially or completely quash the flooding at the source, thereby protecting all upstream routers. This early draft only contains a conceptual overview. |
| | IPv6 Stateless Address Autoconfiguration for Satellite Networks using Topology-Embedded Interface Identifiers |
| |
|
This document specifies a Stateless Address Autoconfiguration (SLAAC) mechanism tailored for satellite constellation networks. It describes how a Host generates IPv6 Interface Identifiers (IIDs) based on deterministic orbital topology parameters and spacecraft identifiers, rather than hardware Media Access Control (MAC) addresses. By embedding topological information (Shell, Orbit, Satellite Index) directly into the IID, this method provides semantic addressing, allowing network operators and routing protocols to derive physical location information solely from the IPv6 address. This approach guarantees global uniqueness within the constellation, minimizes the need for Duplicate Address Detection (DAD), and is suitable for Links typically found in space environments, such as CCSDS AOS or space- based Ethernet. |
| | Path Computation Element Communication Protocol (PCEP) Extensions for SID verification for SR-MPLS |
| |
|
This document defines extensions to the Path Computation Element Communication Protocol (PCEP) to support SID verification in Segment Routing MPLS (SR-MPLS) networks. Specifically, it introduces a flag in the SR-ERO subobject to indicate that the Path Computation Client (PCC) is explicitly requested to verify SID(s) by the Path Computation Element (PCE), and defines capability exchange mechanisms. |
| |
|
| |
| | JSCalendar: A JSON Representation of Calendar Data |
| |
|
This specification defines a data model and JSON representation of calendar data that can be used for storage and data exchange in a calendaring and scheduling environment. It aims to be an alternative and, over time, successor to the widely deployed iCalendar data format. It also aims to be unambiguous, extendable, and simple to process. In contrast to the jCal format, which is also based on JSON, JSCalendar is not a direct mapping from iCalendar but defines the data model independently and expands semantics where appropriate. This document obsoletes RFC 8984. |
| | The Multicast Application Port |
| |
|
This document discusses the drawbacks of the current practice of assigning a UDP port to each multicast application. Such assignments are redundant because the multicast address already uniquely identifies the data. The document proposes assigning a UDP port specifically for use with multicast applications and lists requirements for using this port. This method does not require modification to existing protocol stacks, though recommended updates to make the port easier to use are included. |
| | IETF Community Moderation |
| |
|
The IETF community will treat people with kindness and grace, but not endless patience. This memo obsoletes RFCs 3683 and 3934, and it updates RFCs 2418 and 9245 establishing a policy for the moderation of disruptive participation across the IETF's various public contribution channels and discussion fora. It establishes guardrails for moderation and a moderator team. That team will develop a set of moderation procedures and facilitate their consistent implementation with chairs and administrators. |
| | YANG Data Models for fine grain Optical Transport Network |
| |
|
This document defines YANG data models to describe the topology and tunnel information of a fine grain Optical Transport Network. The YANG data models defined in this document are designed to meet the requirements for efficient transmission of sub-1Gbit/s client signals in transport network. |
| | A Survey to Determine MPLS Label Stack Inspection Behavior |
| |
|
As part of the work on MPLS Network Actions (MNA) a debate arose concerning how existing MPLS implementations handle Special Purpose Labels (SPLs) especially in the context of processing the MPLS Entropy Label. The question applies to the relative placement of the Entropy Label Indicator (ELI) and the MNA Base SPL in the MPLS label stack. This question is applicable to the use of the ELI and any new base SPL (bSPL), or to the relative placement of any two bSPLs including the Extension Label that precedes any extended SPL. In order to discover what deployed implementations currently do, it is proposed that the MPLS working group chairs poll participants to answer specific questions about their implementations. This document is a working draft of the questions to be asked. It is not intended that this document should progress to publication as an RFC. |
| | Consideration of Applying Zero Trust Philosophy in Network Infrastructure |
| |
| | draft-li-zt-consideration-03.txt |
| | Date: |
14/01/2026 |
| | Authors: |
Xueting Li, Aijun Wang, iqjie@mail.ustc.edu.cn, Wenhao Li |
| | Working Group: |
Individual Submissions (none) |
|
Network security has traditionally relied on a perimeter-centric model, assuming that traffic originating within the network can be implicitly trusted. This model is fundamentally challenged by modern, highly distributed, and software-driven network environments where internal compromise is a realistic and high-impact threat scenario. This document examines the critical limitations of edge- only network protection and the systemic risks that arise from insufficient internal validation. Once the network perimeter is bypassed, the absence of internal protection mechanisms facilitates rapid lateral movement, impersonation of network entities, and interference with critical control and management functions. The document argues that Zero Trust (ZT) principles, which mandate continuous, dynamic verification of all entities and communications regardless of network location, are necessary to address contemporary threat models. Deploying ZT-aligned network protection mechanisms beyond the network edge is essential to build resilient, controllable, and trustworthy networks. |
| | Ordering of RRSets in DNS Message Sections |
| |
|
The existing Domain Name System (DNS) specifications lack some clarity in their description of the process by which individual sections of a DNS message are constructed. This document updates RFC 1034 and RFC 1035 to provide a clearer specification, consistent with deployed implementations. |
| |
|
| |
| | Test Vectors for CBOR Encoded X.509 (C509) Certificates |
| |
|
This document contains examples of CBOR encoded X.509 (C509) certificates, certificate (signing) requests, and certificate request templates. |
| | Media over QUIC Transport |
| |
|
This document defines the core behavior for Media over QUIC Transport (MOQT), a media transport protocol designed to operate over QUIC and WebTransport, which have similar functionality. MOQT allows a producer of media to publish data and have it consumed via subscription by a multiplicity of endpoints. It supports intermediate content distribution networks and is designed for high scale and low latency distribution. |
| | Adding an Uncacheable File Data Attribute to NFSv4.2 |
| |
|
Network File System version 4.2 (NFSv4.2) clients commonly perform client-side caching of file data in order to improve performance. On some systems, applications may influence client data caching behavior, but there is no standardized mechanism for a server or administrator to indicate that particular file data should not be cached by clients for reasons of performance or correctness. This document introduces a new file data caching attribute for NFSv4.2. Files marked with this attribute are intended to be accessed with client-side caching of file data suppressed, in order to support workloads that require predictable data visibility. This document extends NFSv4.2 (see RFC7862). |
| | Encoding Network Slice Identification for SRv6 |
| |
|
A Network Resource Partition (NRP) is a subset of the network resources and associated policies on each of a connected set of links in the underlay network. An NRP could be used as the underlay to support one or a group of enhanced VPN services. For packet forwarding in a specific NRP, some fields in the data packet are used to identify the NRP the packet belongs to, so that NRP-specific processing can be performed on each node along a path in the NRP. This document describes a novel method to encode NRP-ID in the outer IPv6 header of an SRv6 domain, which could be used to identify the NRP-specific processing to be performed on the packets by each network node along a network path in the NRP. |
| | An Overview of Network Slicing Efforts in The IETF |
| |
|
This document lists a set of slicing-related specifications that are being development within the IETF. This document is meant to provide an overview of slicing activities in the IETF to hopefully ease coordination and ensure that specifications that are developed in many WGs are consistent. |
| | Multicast over SRv6 networks |
| |
|
This document presents solutions for deploying multicast in SRv6 networks. It explores the use of the native IPv6 multicast data plane for multicast distribution. The document discusses distributed control plane mechanisms, including PIM, and its integration with IGP Flex-Algo to optimize multicast delivery. The document also addresses overlay multicast solutions for both the Global Table Multicast (GTM) and Multicast VPNs (MVPNs), utilizing IP-in- IPv6 encapsulation without requiring additional shim layers. |
| | Using Attestation in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) |
| |
|
The TLS handshake protocol allows authentication of one or both peers using static, long-term credentials. In some cases, it is also desirable to ensure that the peer runtime environment is in a secure state. Such an assurance can be achieved using remote attestation which is a process by which an entity produces Evidence about itself that another party can use to appraise whether that entity is found in a secure state. This document describes a series of protocol extensions to the TLS 1.3 handshake that enable the binding of the TLS authentication key to a remote attestation session. This enables an entity capable of producing attestation Evidence, such as a confidential workload running in a Trusted Execution Environment (TEE), or an IoT device that is trying to authenticate itself to a network access point, to present a more comprehensive set of security metrics to its peer. These extensions have been designed to allow the peers to use any attestation technology, in any remote attestation topology, and to use them mutually. |
| | Artificial Intelligence Governance Architecture (AIGA) |
| |
|
This document defines the Artificial Intelligence Governance Architecture (AIGA), an application-layer protocol for the discovery, authentication, and state management of Autonomous Agents. The protocol specifies a cryptographic handshake mechanism, a standard header schema for risk classification, and a transport-agnostic method for immutable activity logging via Merkle Trees. To address latency and enforcement concerns, this version introduces "Session Resumption" for high-frequency transactions and "Hardware-Enforced Termination" using Trusted Execution Environments (TEEs). |
| | Digital Signing of Physical Items Protocol (DSPIP) |
| |
|
This document specifies the Digital Signing of Physical Items Protocol (DSPIP), a cryptographic protocol for authenticating physical items using digitally signed QR codes. This specification focuses on the SHIP type for shipping and logistics applications, providing cryptographic authentication of packages with chain of custody tracking. The protocol introduces privacy-preserving delivery mechanisms including encrypted recipient information, last mile provider selection, physical anti-cloning protections through split-key labels, and scalable revocation and delivery confirmation systems. DSPIP uses DNS-based public key distribution similar to DKIM and supports optional blockchain integration for immutable record keeping. While this specification focuses on shipping applications, the protocol includes a type field to enable future expansion to other use cases. |
| | UZPIF Outbound Indexing for Search Engines and AI |
| |
|
This document proposes an outbound, opt-in mechanism for web content discovery and indexing, complementing or replacing traditional inbound crawling models such as those governed by the Robots Exclusion Protocol (REP; [RFC9309]). In the proposed approach, servers proactively initiate authenticated outbound connections to trusted indexers (search engines or AI systems) using identity-bound grants, enabling explicit consent for indexing, freshness signalling, and content usage policy communication. The mechanism integrates with identity-centric frameworks such as the Universal Zero-Port Interconnect Framework (UZPIF; [UZPIF]) and supports both traditional search engines and AI-driven indexing and retrieval systems. It aims to reduce unsolicited crawling abuse, improve signal quality for indexers, and provide site owners with positive control over discoverability in an era of increasing AI content consumption. |
| | Invariant-Closed System Design (ICSD) |
| |
| | draft-dpa-icsd-00.txt |
| | Date: |
13/01/2026 |
| | Authors: |
Benjamin Fisher |
| | Working Group: |
Individual Submissions (none) |
|
Invariant-Closed System Design (ICSD) defines an architectural principle for building systems in which all representable states are valid and compliant by construction. Rather than relying on runtime detection, validation, or remediation of invalid or abusive behaviour, ICSD ensures that invalid states are structurally unrepresentable through constrained state models, invariant-bound transitions, and authority-anchored truth sources. This document introduces the ICSD concept, its core properties, design trade-offs, and applicability to compliance-critical domains such as payroll, taxation, financial reporting, and regulated infrastructure. It is intended for discussion and experimentation in environments requiring high assurance of correctness, auditability, and resistance to abuse. |
| | Post-Quantum Cryptography in OpenPGP |
| |
| | draft-ietf-openpgp-pqc-17.txt |
| | Date: |
13/01/2026 |
| | Authors: |
Stavros Kousidis, Johannes Roth, Falko Strenzke, Aron Wussler |
| | Working Group: |
Open Specification for Pretty Good Privacy (openpgp) |
|
This document defines a post-quantum public key algorithm extension for the OpenPGP protocol, extending RFC9580. Given the generally assumed threat of a cryptographically relevant quantum computer, this extension provides a basis for long-term secure OpenPGP signatures and ciphertexts. Specifically, it defines composite public key encryption based on ML-KEM (formerly CRYSTALS-Kyber), composite public key signatures based on ML-DSA (formerly CRYSTALS-Dilithium), both in combination with elliptic curve cryptography, and SLH-DSA (formerly SPHINCS+) as a standalone public key signature scheme. |
| | Information and Data Models for Packet Discard Reporting |
| |
| | draft-ietf-opsawg-discardmodel-11.txt |
| | Date: |
13/01/2026 |
| | Authors: |
John Evans, Oleksandr Pylypenko, Jeffrey Haas, Aviran Kadosh, Mohamed Boucadair |
| | Working Group: |
Operations and Management Area Working Group (opsawg) |
|
This document defines an Information Model and specifies a corresponding YANG data model for packet discard reporting. The Information Model provides an implementation-independent framework for classifying packet loss - both intended (e.g., due to policy) and unintended (e.g., due to congestion or errors) - to enable automated network mitigation of unintended packet loss. The YANG data model specifies an implementation of this Information Model for network elements. |
| | Attestation Event Stream Subscription |
| |
|
This document defines how to subscribe to YANG Event Streams for Remote Attestation Procedures (RATS). Specifically, this document defines a YANG module that augments the YANG module for TPM-based Challenge-Response Remote Attestation (CHARRA), enabling subscription to RATS Conceptual Messages of the Evidence type and auxiliary Event Logs as part of that Evidence. The module defined requires at least one TPM 1.2 or TPM 2.0 (or equivalent hardware implementation providing the same protected capabilities as a TPM) must be available on the Attester on which the YANG server is running. |
| | Selective Disclosure CBOR Web Tokens (SD-CWT) |
| |
| | draft-ietf-spice-sd-cwt-06.txt |
| | Date: |
13/01/2026 |
| | Authors: |
Michael Prorock, Orie Steele, Henk Birkholz, Rohan Mahy |
| | Working Group: |
Secure Patterns for Internet CrEdentials (spice) |
|
This specification describes a data minimization technique for use with CBOR Web Tokens (CWTs). The approach is based on the Selective Disclosure JSON Web Token (SD-JWT), with changes to align with CBOR Object Signing and Encryption (COSE) and CWTs. |
| | SR Policy Group |
| |
|
Segment Routing is a source routing paradigm that explicitly indicates the forwarding path for packets at the ingress node. An SR Policy is associated with one or more candidate paths, and each candidate path is either dynamic, explicit, or composite. This document describes SR Policy Group in MPLS and IPv6 environments and illustrates some use cases for parent SR Policy and SR Policy Group to provide best practice cases for operators. |
| | Extended Key Update for Transport Layer Security (TLS) 1.3 |
| |
|
TLS 1.3 ensures forward secrecy by performing an ephemeral Diffie- Hellman key exchange during the initial handshake, protecting past communications even if a party's long-term keys (typically a private key with a corresponding certificate) are later compromised. While the built-in KeyUpdate mechanism allows application traffic keys to be refreshed during a session, it does not incorporate fresh entropy from a new key exchange and therefore does not provide post- compromise security. This limitation can pose a security risk in long-lived sessions, such as those found in industrial IoT or telecommunications environments. To address this, this specification defines an extended key update mechanism that performs a fresh Diffie-Hellman exchange within an active session, thereby ensuring post-compromise security. By forcing attackers to exfiltrate new key material repeatedly, this approach mitigates the risks associated with static key compromise. Regular renewal of session keys helps contain the impact of such compromises. The extension is applicable to both TLS 1.3 and DTLS 1.3. |
| |
|
| |
| | CoAP: Non-traditional response forms |
| |
|
In CoAP as defined by RFC 7252, responses are always unicast back to a client that posed a request. The present memo describes two forms of responses that go beyond that model. The design spaces for the new CoAP Options proposed to represent these responses are now sufficiently understood that they can be developed to standards-track specifications, either in this document or by transferring the specification for an Option to a document that that Option closely works with. |
| | 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 to collect operational and telemetry information. The collected data may then be exported to systems that will use it to, e.g., monitor, measure, or (re)configure the network. Integrity Protection of In Situ Operations, Administration, and Maintenance (IOAM) Data Fields (RFC YYYY) defines IOAM Options with integrity protection, also called Integrity Protected Options. This document defines a YANG module for the management of these Integrity Protected Options. |
| | YANG Metadata Annotation for Immutable Flag |
| |
|
This document defines a way to formally document an existing behavior, implemented by servers in production, on the immutability of some system-provided nodes, using a YANG metadata annotation called "immutable" to flag which nodes are immutable. Clients may use "immutable" annotations provided by the server, to know beforehand why certain otherwise valid configuration requests will cause the server to return an error. The immutable flag is descriptive, documenting an existing behavior, not proscriptive, dictating server behaviors. This document updates RFC 8040 and RFC 8526. |
| | Flow Measurement in IPv6 Network |
| |
|
This document describes how to deploy in-situ flow performance measurement based on Alternate-Marking method in IPv6 domain. |
| | Interconnecting domains with IBGP |
| |
|
This document relaxes the recommendations specified in BGP/MPLS IP Virtual Private Networks (VPNs) and BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP) allowing the building of Inter-domain L3VPN architecture with internal BGP. |
| | Managing CBOR codepoints in Internet-Drafts |
| |
|
CBOR-based protocols often make use of numbers allocated in a registry. During development of the protocols, those numbers may not yet be available. This impedes the generation of data models and examples that actually can be used by tools. This short draft proposes a common way to handle these situations, without any changes to existing tools. Also, in conjunction with the application-oriented EDN literal e'', a further reduction in editorial processing of CBOR examples around the time of approval can be achieved. |
| | IPv6 Extended Fragment Header (EFH) |
| |
|
The Internet Protocol, version 4 (IPv4) header includes a 16-bit Identification field in all packets, but this length is too small to ensure reassembly integrity even at moderate data rates in modern networks. Even for Internet Protocol, version 6 (IPv6), the 32-bit Identification field included when a Fragment Header is present may be smaller than desired for some applications. Both IPv4 and IPv6 fragmentation have further been classified as fragile to the point that their use is discouraged. This specification addresses these limitations by defining an IPv6 Extended Fragment Header (EFH) that includes a 64-bit Identification in the context of more robust, secure and efficient fragmentation and reassembly procedures. |
| | RDAP Simple Redaction |
| |
|
This document defines a simple redaction extension for the Registration Data Access Protocol (RDAP). |
| | 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. |
| | A Token-efficient Data Layer for Agentic Communication |
| |
|
Agentic communication fundamentally differs from traditional machine communication in that its outputs are recursively consumed and interpreted by Large Language Models (LLMs). This unique characteristic makes efficient use of the model's limited context a critical requirement. However, current agent communication protocols - such as the Model Context Protocol (MCP) and Agent-to-Agent (A2A) - often suffer from token or context bloat, caused by redundant schema definitions, verbose message structures, and inefficient capability exchanges. As a result, a substantial number of tokens are unnecessarily consumed within the model’s context window. To address these issues, this draft defines the Agentic Data Optimization Layer (ADOL), a general and foundational data-layer for agent communication. ADOL introduces a set of backward-compatible optimizations, including schema deduplication through JSON references, adaptive inclusion of optional fields, controllable response verbosity, and retrieval-based selection mechanisms. Collectively, these mechanisms reduce token consumption, enhance context efficiency, and provide a scalable foundation for future agent communication frameworks. |
| | CSV++ (CSV Plus Plus): Extension to RFC 4180 for Hierarchical Data |
| |
|
This document specifies CSV++ (CSV Plus Plus), an extension to the Comma-Separated Values (CSV) format defined in RFC 4180. CSV++ adds support for repeating fields (one-to-many relationships) and hierarchicalcomponent structures while maintaining backward compatibility with standard CSV parsers. The extension uses declarative syntax in column headers to define array fields and nested structures, enabling representation of complex real-world data while preserving the simplicity and human-readability of CSV. |
| | Unified Rendering of Email Standard (URES) |
| |
|
This document specifies requirements for the uniform rendering of HTML email content across mail user agents (MUAs). It addresses critical inconsistencies in how email clients interpret HTML and CSS, including dark mode adaptation, embedded asset handling, positioning constraints, and secure SVG rendering. The specification aims to eliminate the current fragmentation in email rendering while maintaining backwards compatibility with existing MIME standards (RFCs 2045-2049) and the Internet Message Format (RFC 5322). |
| | Early Attestation is Broken |
| |
|
Sheffer et al. published [I-D.fossati-seat-early-attestation] on 9th January, 2025 and despite being wildly out of scope of SEAT charter, the draft made its place -- getting two-thirds of meeting time -- in the agenda for upcoming SEAT interim meeting within hours of publishing. In comparison, our request to present [I-D.fossati-seat-expat] fully within the charter was refused. In this document, we disprove the claim made in [I-D.fossati-seat-early-attestation] for backward compatibility with standard TLS [I-D.ietf-tls-rfc8446bis]. We argue that [I-D.fossati-seat-expat] is a much more reaonsable way of achieving the goal within the scope of SEAT charter. |
| | HTTP Content Negotiation for Consolidated Machine-Readable Representations |
| |
|
This document specifies the use of HTTP content negotiation with the Prefer header to request consolidated, machine-optimised representations of web resources. Clients use the Accept header for format negotiation and the Prefer header with return=consolidated to request content optimised for automated consumption. Publishers benefit from dramatically reduced request volume and the ability to present contextually complete information, improving both operational efficiency and content effectiveness. Consolidated resources enable practical caching, further reducing load. This document introduces a single new preference value for the existing Prefer header and otherwise relies solely on established HTTP mechanisms. |
| | Updates to OAuth 2.0 JSON Web Token (JWT) Client Authentication and Assertion-Based Authorization Grants |
| |
| | draft-ietf-oauth-rfc7523bis-05.txt |
| | Date: |
12/01/2026 |
| | Authors: |
Michael Jones, Brian Campbell, Chuck Mortimore, Filip Skokan |
| | Working Group: |
Web Authorization Protocol (oauth) |
|
This specification updates the requirements for audience values in OAuth 2.0 Client Assertion Authentication and Assertion-based Authorization Grants to address a security vulnerability identified in the previous requirements for those audience values in multiple OAuth 2.0 specifications. |
| | JSON Web Token Best Current Practices |
| |
|
JSON Web Tokens, also known as JWTs, are URL-safe JSON-based security tokens that contain a set of claims that can be signed and/or encrypted. JWTs are being widely used and deployed as a simple security token format in numerous protocols and applications, both in the area of digital identity and in other application areas. This Best Current Practices (BCP) specification updates RFC 7519 to provide actionable guidance leading to secure implementation and deployment of JWTs. This BCP specification furthermore replaces the existing JWT BCP specification RFC 8725 to provide additional actionable guidance covering threats and attacks that have been discovered since RFC 8725 was published. |
| | Managing multiple paths for a QUIC connection |
| |
| | draft-ietf-quic-multipath-19.txt |
| | Date: |
12/01/2026 |
| | Authors: |
Yanmei Liu, Yunfei Ma, Quentin De Coninck, Olivier Bonaventure, Christian Huitema, Mirja Kuehlewind |
| | Working Group: |
QUIC (quic) |
|
This document specifies a multipath extension for the QUIC protocol to enable the simultaneous usage of multiple paths for a single connection. It proposes a standard way to create, delete, and manage paths using identifiers. It does not specify address discovery or management, nor how applications using QUIC schedule traffic over multiple paths. |
| | Deprecating Obsolete Key Exchange Methods in (D)TLS 1.2 |
| |
|
For (D)TLS 1.2, this document deprecates the use of two key exchanges, namely Diffie-Hellman over a finite field and RSA, and it discourages the use of static elliptic curve Diffie-Hellman cipher suites. These prescriptions apply only to (D)TLS 1.2 since (D)TLS 1.0 and TLS 1.1 are deprecated by RFC 8996 and (D)TLS 1.3 either does not use the affected algorithms or does not share the relevant configuration options. (There is no DTLS version 1.1.) This document updates RFCs 9325, 4346, 5246, 4162, 6347, 5932, 5288, 6209, 6367, 8422, 5289, 5469, 4785, 4279, 5487, 6655, and 7905, to deprecate or discourage - i.e., change to MUST NOT or SHOULD NOT, as listed in Section 5.3, Section 5.2, Section 5.3, Section 5.4, and Section 5.5 - the use of cipher suites using the above key exchange methods in (D)TLS 1.2 connections. |
| | Operational Guidance on Coexistence with Classic ECN during L4S Deployment |
| |
|
This document provides guidance in order to ensure successful deployment of Low Latency Low Loss Scalable throughput (L4S) in the Internet. Other L4S documents provide guidance for running an L4S experiment, but this document is focused solely on potential interactions between L4S flows and flows using the original ('Classic') ECN over a Classic ECN bottleneck. The document discusses the potential outcomes of these interactions, describes mechanisms to detect the presence of Classic ECN bottlenecks, and identifies opportunities to prevent and/or detect and resolve fairness problems in such networks. This guidance is aimed at operators of end-systems, operators of networks, and researchers. |
| |
|
| |
| | BGP-LS Extension for Inter-AS Topology Retrieval |
| |
|
This document describes the process to distribute Border Gateway Protocol- Link State (BGP-LS) key parameters for inter-domain links between two Autonomous Systems. This document defines a new type within the BGP-LS NLRI for a Stub Link and three new type-length- values (TLVs) for BGP-LS Link descriptor. These additions to BGP-LS let Software Definition Network (SDN) controllers retrieve the network topology automatically under various inter-AS environments. Such extension and process can enable the network operator to collect the interconnect information between different domains and then calculate the overall network topology automatically based on the information provided by BGP-LS protocol. |
| | LISP for Satellite Networks |
| |
|
This specification describes how the LISP architecture and protocols can be used over satellite network systems. The LISP overlay runs on earth using the satellite network system in space as the underlay. |
| | Enhanced Bailiwick Checking for DNS Resolvers to Mitigate Cache Poisoning Vulnerabilities |
| |
|
The Domain Name System (DNS) relies on caching to function efficiently. However, DNS cache poisoning remains a significant threat. The "bailiwick" rule is a fundamental security mechanism intended to prevent resolvers from caching out-of-bailiwick data sent by malicious or misconfigured authoritative servers. Current DNS standards provide high-level guidance on bailiwick checking but lack specific algorithmic definitions, leading to inconsistent implementations across different DNS software. These inconsistencies can be exploited, particularly in DNS servers that operate in multiple modes, such as Conditional DNS Servers (CDNS), which may act as both recursive resolvers and forwarders and often share a common cache. This document specifies enhanced and more precise rules for bailiwick checking in DNS resolvers, including those operating as forwarders or CDNS. The goal is to provide clearer guidelines for implementers, reduce the attack surface for cache poisoning, and improve the overall security and robustness of the DNS infrastructure. The recommendations herein are informed by recent research highlighting vulnerabilities in existing bailiwick implementations. |
| | Clarifying DNS Resolver Behavior for the Recursion Desired (RD) Flag |
| |
|
This document addresses inconsistencies observed in the handling of the Recursion Desired (RD) flag in DNS queries by various DNS resolver implementations, particularly when the RD flag is cleared (set to 0). Such inconsistencies have been shown to be exploitable, leading to potent Denial of Service (DoS) amplification attacks. This document provides clear guidance and recommendations for DNS resolver (including forwarding and recursive resolvers) behavior when processing queries with different RD flag settings. The goal is to enhance DNS security, mitigate specific amplification attack vectors, and ensure more predictable and robust DNS operations. |
| | Best Current Practices for DNS Resolver Resilience Against Coordinated Amplification Attacks |
| |
|
This document describes an attack vector, exemplified by the "DNSBomb" attack, that leverages the emergent behavior of several widely- implemented DNS resolver mechanisms. By combining query timeouts, query aggregation, and response timing, an attacker can turn a set of resolvers into powerful amplifiers for a Pulsing Denial-of-Service (PDoS) attack. This attack is difficult to detect due to its low average traffic rate but can be highly effective at overwhelming a target's resources. This document provides operational guidance and a set of best practices for DNS resolver implementers and operators to mitigate this threat. The goal is to harden the DNS ecosystem by reducing the potential for resolvers to be used in such a coordinated fashion, thereby improving the operational resilience of the DNS. |
| | DNS Response Pre-processing Security Guidelines: Awaiting Valid Responses |
| |
|
The security and robustness of the Domain Name System (DNS) significantly depend on how resolvers handle received responses. Current DNS specifications lack exhaustive and consistent guidance on response pre-processing, particularly for malformed or unexpected packets. This specification gap has led to implementation divergences and has been shown to introduce security vulnerabilities such as DNS cache poisoning, Denial of Service (DoS), and resource exhaustion, as detailed in the TUDOOR attack research. This document aims to clarify and standardize the behavior of DNS resolvers when receiving and initially processing responses from upstream servers. The core proposal is the "Awaiting Valid Responses" mechanism, which mandates that a resolver, after issuing a query, MUST maintain a defined waiting period to receive a well- formed, relevant, and validated response. During this period, non- compliant incoming packets should be discarded, and the resolver should continue to wait until a valid response is received or the query times out. This document provides guidance for DNS implementers to mitigate security risks arising from flaws in response pre-processing logic. |
| | The DNS Stamps Specification |
| |
|
This document specifies DNS Stamps, a compact format that encodes the information needed to connect to DNS resolvers. DNS Stamps encode all necessary parameters including addresses, hostnames, cryptographic keys, and protocol-specific configuration into a single string using a standard URI format. The specification supports multiple secure DNS protocols including DNSCrypt, DNS-over-HTTPS (DoH), DNS-over-TLS (DoT), DNS-over-QUIC (DoQ), and Oblivious DoH. |
| | AI Agent Use Cases and Requirements in 6G Network |
| |
|
This draft introduces use cases related to AI Agents in 6G networks, primarily referencing the technical report of 3GPP SA1 R20 Study on 6G Use Cases and Service Requirements (TR 22.870). It also elaborates on some of the requirements for introducing AI Agents into 6G networks from the perspective of operators. |
| | PCE Communication Protocol (PCEP) Extensions for Using PCE as a Central Controller (PCECC) for Segment Routing (SR) MPLS Segment Identifier (SID) Allocation and Distribution |
| |
|
The PCE is a core component of Software-Defined Networking (SDN) systems. 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 Label Switched Path (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 path while leveraging the existing PCE technologies as much as possible. This document specifies the procedures and PCE Communication Protocol (PCEP) extensions when a PCE-based controller is also responsible for configuring the forwarding actions on the routers, in addition to computing the paths for packet flows in a segment routing (SR) network and telling the edge routers what instructions to attach to packets as they enter the network. PCECC as defined in RFC 9050 is further enhanced for SR-MPLS SID (Segment Identifier) allocation and distribution. |
| | A YANG Data Model for the Virtual Router Redundancy Protocol (VRRP) |
| |
|
This document describes a YANG data model for the Virtual Router Redundancy Protocol (VRRP). Both versions 2 and 3 of VRRP are covered. The VRRP terminology has been updated to conform to inclusive language guidelines for IETF technologies. This document obsoletes RFC 8347. |
| | A Profile for Mapping Origin Authorizations (MOAs) |
| |
|
This document proposes a new approach by leveraging Resource Public Key Infrastructure (RPKI) architecture to verify the authenticity of the mapping origin of an IPv4 address block. MOA is a newly defined cryptographically signed object that provides a means for the address holder can authorize an IPv6 mapping prefix to originate mapping for one or more IPv4 prefixes. When receiving the MOA objects from the relying parties, PE devices can verify and discard invalid address mapping announcements from unauthorized IPv6 mapping prefixes to prevent IPv4 prefix hijacking. |
| |
|
| |
| | RTP Payload Format for SFrame |
| |
|
This document describes the RTP payload format of SFrame, its use in SDP, and per stream key derivation. |
| | Data Modelling and Gap Analysis of Optical Pluggables in Packet Over Optical Network |
| |
|
This draft outlines the pluggable module attributes within a host device. It includes representations of optical pluggable module capabilities, configuration, states, and telemetry data. These attributes draws from existing IETF standards and incorporates input from other industry forums and standards, such as ITU-T, OpenConfig, OIF and ONF TAPI, to ensure uniform structuring and consistent naming conventions. Note that the IETF terminology shall be given precedence wherever possible. In case there is a duplication of an attribute, this draft may describe how the attribute is named in the related document. Only if no attribute exists in IETF RFCs or IETF WG drafts, new attributes shall be introduced if they are needed. This draft provides a gap analysis with respect to existing IETF work in the following areas: * It provides an analysis of optical attributes in a set of IETF documents with specifications of other organizations to identify modeling gaps. * It identifies modeling needs addressing the specific aspect of pluggability of transceiver modules. The authors recognize the fact that that not all pluggable modules are coherent, not all coherent pluggable modules are DWDM capable and not all DWDM capable interfaces are implemented as pluggable modules. This analysis identifies gaps to manage the lifecycle of an optical pluggable module, from operator approval and viability assessment, to deployment, monitoring and phase-out. The lifecycle of an optical pluggable module, from operator approval and viability assessment to deployment and monitoring, is also addressed. About This Document This note is to be removed before publishing as an RFC. The latest revision of this draft can be found at https://italobusi.github.io/actn-wdm-pluggable-modelling/draft-rokui- ccamp-actn-wdm-pluggable-modelling.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-ietf- ccamp-actn-wdm-pluggable-modelling/. Discussion of this document takes place on the Common Control and Measurement Plane Working Group mailing list (mailto:ccamp@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/ccamp/. Subscribe at https://www.ietf.org/mailman/listinfo/ccamp/. Source for this draft and an issue tracker can be found at https://github.com/italobusi/actn-wdm-pluggable-modelling. |
| | Domain-based Message Authentication,Reporting,and Conformance (DMARC) Failure Reporting |
| |
|
Domain-based Message Authentication, Reporting, and Conformance (DMARC) is a mechanism by which a Domain Owner can request feedback about email messages using their domain in the From: address field. This document describes "failure reports", or "failed message reports", which provide details about individual messages that failed to authenticate according to the DMARC mechanism. This document updates RFC 6591 and obsoletes RFC 7489. |
| | A YANG Data Model for Network Inventory Location |
| |
|
This document defines a YANG data model for Network Inventory location (e.g., site, room, rack, geo-location data), which provides location information with different granularity levels for inventoried network elements. Accurate location information is useful for network planning, deployment, and maintenance. However, such information cannot be obtained or verified from the Network Elements themselves. This document defines a location model for network inventory that extends the base inventory with comprehensive location data. |
| | LISP Traffic Engineering |
| |
| | draft-ietf-lisp-te-24.txt |
| | Date: |
09/01/2026 |
| | Authors: |
Dino Farinacci, Michael Kowal, Parantap Lahiri, Padma Pillay-Esnault |
| | Working Group: |
Locator/ID Separation Protocol (lisp) |
|
This document describes how Locator/Identifier Separation Protocol (LISP) re-encapsulating tunnels can be used for Traffic Engineering purposes. The mechanisms described in this document require no LISP protocol changes and specify how existing Routing Locator encodings are used to construct Explicit Locator Paths for traffic engineering purposes. The Traffic Engineering features provided by these LISP mechanisms can span intra-domain, inter-domain, or a combination of both. |
| | 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. |
| | On the Relationship Between Remote Attestation and Behavioral Evidence Recording |
| |
|
This document provides an informational discussion of the conceptual relationship between remote attestation, as defined in RFC 9334 (RATS Architecture), and behavioral evidence recording mechanisms. It observes that these two verification capabilities address fundamentally different questions - attestation addresses "Is this system in a trustworthy state?" while behavioral evidence addresses "What did the system actually do?" - and discusses how they could conceptually complement each other in accountability frameworks. This document is purely descriptive: it does not propose any modifications to RATS architecture, define new mechanisms or protocols, or establish normative requirements. It explicitly does not define any cryptographic binding between attestation and behavioral evidence. |
| | Eligibility Concept in Segment Routing Policies |
| |
|
Segment Routing (SR) introduces new challenges for pinning candidate paths on their intended paths (the path the PCE computed based on provided intent and may have made bandwidth reservations on). The actual path through a network can change or no longer meet the required constraints if a SID list of an SR Policy candidate path is not fully expressed as a list of adjacency SIDs or when a change in the topology does happen. The introduction of the new candidate path eligibility concept permits a path to be signaled and established as operationally up, but controls whether the path is eligible to carry traffic, thus influencing its active state. The eligibility concept allows a system (operator, pce, headend, etc.) to set eligibility as false when path deviations may have occurred, or path constraints are no longer met for one or more SID lists of a candidate path and clear it when candidate path deviations are removed or constraints are met again. |
| |
|
| |
| | CoAP Publish-Subscribe Profile for Authentication and Authorization for Constrained Environments (ACE) |
| |
|
This document defines an application profile of the Authentication and Authorization for Constrained Environments (ACE) framework, to enable secure group communication in the Publish-Subscribe (Pub-Sub) architecture for the Constrained Application Protocol (CoAP) [draft- ietf-core-coap-pubsub], where Publishers and Subscribers communicate through a Broker. This profile relies on protocol-specific transport profiles of ACE to achieve communication security, server authentication, and proof of possession of a key owned by the Client and bound to an OAuth 2.0 access token. This document specifies the provisioning and enforcement of authorization information for Clients to act as Publishers and/or Subscribers, as well as the provisioning of keying material and security parameters that Clients use for protecting their communications end-to-end through the Broker. Note to RFC Editor: Please replace "[draft-ietf-core-coap-pubsub]" with the RFC number of that document and delete this paragraph. |
| | CDNI Logging Extensions |
| |
|
This document defines a set of extensions to CDNI for supporting transmission of transaction logs in both push and pull operational modes, new log container formats and log record formats, new logging fields, and metadata for describing the transformation, obfuscation, and encryption of log record fields. |
| | The BBS Signature Scheme |
| |
|
This document describes the BBS Signature scheme, a secure, multi- message digital signature protocol, supporting proving knowledge of a signature while selectively disclosing any subset of the signed messages. Concretely, the scheme allows for signing multiple messages whilst producing a single, constant size, digital signature. Additionally, the possessor of a BBS signatures is able to create zero-knowledge, proofs of knowledge of a signature, while selectively disclosing subsets of the signed messages. Being zero-knowledge, the BBS proofs do not reveal any information about the undisclosed messages or the signature itself, while at the same time, guaranteeing the authenticity and integrity of the disclosed messages. |
| | Dataplane Enhancement Taxonomy |
| |
|
This draft is to facilitate the understanding of the data plane enhancement solutions, which are suggested currently or can be suggested in the future, for deterministic networking. This draft provides criteria for classifying data plane solutions. Examples of each category are listed, along with reasons where necessary. Strengths and limitations of the categories are described. Suitability of the solutions for various services of deterministic networking are also mentioned. Reference topologies for evaluation of the solutions are given as well. |
| | Extensible Authentication Protocol (EAP) Using Privacy Pass Token |
| |
|
This document describes Extensible Authentication Protocol using Privacy Pass token (EAP-PPT) Version 1. The protocol specifies use of the Privacy Pass token for client authentication within EAP as defined in RFC3748. Privacy Pass is a privacy preserving authentication mechanism used for authorization, as defined in RFC9576. |
| | OSPF YANG Model Augmentations for Additional Features - Release 1 |
| |
|
This document defines YANG data modules that augment the IETF OSPF YANG model to support various OSPF extensions and features, including Traffic Engineering Extensions to OSPF Version 3 as defined in RFC 5329, OSPF Two-Part Metric as defined in RFC 8042, OSPF Graceful Link Shutdown as defined in RFC 8379, OSPF Link-Local Signaling (LLS) Extensions for Local Interface ID Advertisement as defined in RFC 8510, OSPF MSD as defined in RFC 8476, OSPF Application-Specific Link Attributes as defined in RFC 9492, and OSPF Flexible Algorithm as defined in RFC 9350. |
| | POSIX Draft ACL support for Network File System Version 4,Minor Version 2 |
| |
|
This document proposes four new optional file attributes for NFSv4.2 to support POSIX ACLs conforming to the withdrawn POSIX 1003.1e draft 17. Although never ratified, POSIX ACLs are implemented in widely deployed operating systems. Existing attempts to map between NFSv4 and POSIX ACL models have been unsuccessful due to semantic incompatibilities. These new attributes allow servers to expose POSIX ACLs directly, avoiding lossy mapping. |
| | Path Computation Element Communication Protocol (PCEP) Extensions for Topology Filter |
| |
|
This document proposes a set of extensions for Path Computation Element Communication Protocol (PCEP) to support the topology filter during path computation. |
| | IGP Extensions for Deterministic Traffic Engineering |
| |
|
This document describes IGP extensions to support Traffic Engineering (TE) of deterministic routing, by specifying new information that a router can place in the advertisement of neighbors. This information describes additional details regarding the state of the network that are useful for deterministic traffic engineering path computations. |
| | Verifiable Voice Protocol |
| |
|
Verifiable Voice Protocol (VVP) authenticates and authorizes organizations and individuals making and/or receiving telephone calls. This eliminates trust gaps that malicious parties exploit. Like related technologies such as SHAKEN, RCD, and BCID, VVP uses STIR to bind cryptographic evidence to a SIP INVITE, and verify this evidence downstream. VVP can also let evidence flow the other way, proving things about the callee. VVP builds from different technical and governance assumptions than alternatives, and uses richer, stronger evidence. This allows VVP to cross jurisdictional boundaries easily and robustly. It also makes VVP simpler, more decentralized, cheaper to deploy and maintain, more private, more scalable, and higher assurance. Because it is easier to adopt, VVP can plug gaps or build bridges between other approaches, functioning as glue in hybrid ecosystems. For example, it may justify an A attestation in SHAKEN, or an RCD passport for branded calling, when a call originates outside SHAKEN or RCD ecosystems. VVP also works well as a standalone mechanism, independent of other solutions. An extra benefit is that VVP enables two-way evidence sharing with verifiable text and chat (e.g., RCS and vCon), as well as with other industry verticals that need verifiability in non-telco contexts. |
| | KEM-based Authentication for EDHOC in Initiator-Known Responder (IKR) Scenarios |
| |
|
This document specifies a more efficient variant of a Key Encapsulation Mechanism (KEM)-based authentication method for the Ephemeral Diffie-Hellman Over COSE (EDHOC) lightweight protocol, designed for the specific scenario in which the Initiator has prior knowledge of the Responder’s credentials, a case commonly found in constrained environments. Improving upon the approach described in KEM-based Authentication for EDHOC, this method uses only a mandatory three-message handshake to enable signature-free post-quantum authentication when PQC KEMs, such as the NIST-standardized ML-KEM, are employed, while still providing mutual authentication, forward secrecy, and a degree of identity protection. |
| | HTTP Signature-Key Header |
| |
|
This document defines the Signature-Key HTTP header field for distributing public keys used to verify HTTP Message Signatures as defined in RFC 9421. Four initial key distribution schemes are defined: pseudonymous inline keys (hwk), identified signers with JWKS URI discovery (jwks_uri), X.509 certificate chains (x509), and JWT- based delegation (jwt). These schemes enable flexible trust models ranging from privacy-preserving pseudonymous verification to PKI- based identity chains and horizontally-scalable delegated authentication. |
| | Advertising DetNet Resources in BGP Link-State |
| |
|
BGP Link-State (BGP-LS) enables the collection of various topology information from the network. This document specifies the advertisement of DetNet scheduling resources in BGP-LS, providing a foundation for the controller to calculate DetNet based traffic engineering path. |
| | Verifiable AI Provenance Framework (VAP): An Architectural Framework for Evidentiary-Grade AI Decision Trails |
| |
|
Automated decision-making systems, including AI and algorithmic systems in critical infrastructure, currently lack standardized mechanisms for producing evidentiary-grade provenance records that can withstand independent verification. Traditional logging approaches fail to provide the cryptographic guarantees required for regulatory compliance, forensic investigation, and cross- organizational accountability. This document describes the Verifiable AI Provenance Framework (VAP), an architectural framework that defines requirements for producing verifiable decision trails using existing IETF security technologies. VAP does not define new protocols or cryptographic primitives; rather, it provides an architectural coordination layer that enables domain-specific profiles to leverage Supply Chain Integrity, Transparency and Trust (SCITT), Remote Attestation Procedures (RATS), CBOR Object Signing and Encryption (COSE), and related IETF work in a consistent manner. This document is intended to frame the problem space and facilitate discussion about whether architectural coordination work is needed in this area. |
| | Protocols Applicability for Computing-Aware Traffic Steering (CATS) |
| |
|
This document analyzes the applicability of protocols related to a CATS system，and describes how to build a CATS system by extending existing IETF protocols. |
| | PQ/T Composite Schemes for OpenPGP using NIST and Brainpool Elliptic Curve Domain Parameters |
| |
| | draft-ietf-openpgp-nist-bp-comp-03.txt |
| | Date: |
08/01/2026 |
| | Authors: |
Quynh Dang, Stephan Ehlen, Stavros Kousidis, Johannes Roth, Falko Strenzke |
| | Working Group: |
Open Specification for Pretty Good Privacy (openpgp) |
|
This document defines PQ/T ("post-quantum/traditional") composite schemes based on ML-KEM and ML-DSA combined with ECDH and ECDSA algorithms using the NIST and Brainpool domain parameters for the OpenPGP protocol [RFC9580], and as such extends [I-D.draft-ietf-openpgp-pqc]. |
| | Group Address Allocation Protocol (GAAP) |
| |
|
This document describes a design for a lightweight decentralized multicast group address allocation protocol (named GAAP and pronounced "gap" as in "mind the gap"). The protocol requires no configuration setup and no centralized services. The protocol runs among group participants which need a unique group address to send and receive multicast packets. Tailored for IPv4 and IPv6 networks, this design offers a simple, lightweight option rather than extending an existing protocol. |
| | WIMSE Workload-to-Workload Authentication with HTTP Signatures |
| |
|
The WIMSE architecture defines authentication and authorization for software workloads in a variety of runtime environments, from the most basic ones to complex multi-service, multi-cloud, multi-tenant deployments. This document defines one of the mechanisms to provide workload authentication, using HTTP Signatures. While only applicable to HTTP traffic, the protocol provides end-to-end protection of requests (and optionally, responses), even when service traffic is not end-to-end encrypted, that is, when TLS proxies and load balancers are used. Authentication is based on the Workload Identity Token (WIT). |
| |
|
| |
| | Using the Constrained RESTful Application Language (CoRAL) with the Admin Interface for the OSCORE Group Manager |
| |
|
Group communication for the Constrained Application Protocol (CoAP) can be secured using Group Object Security for Constrained RESTful Environments (Group OSCORE). A Group Manager is responsible to handle the joining of new group members, as well as to manage and distribute the group keying material. The Group Manager can provide a RESTful admin interface that allows an Administrator entity to create and delete OSCORE groups, as well as to retrieve and update their configuration. This document specifies how an Administrator interacts with the admin interface at the Group Manager by using the Constrained RESTful Application Language (CoRAL). The ACE framework for Authentication and Authorization is used to enforce authentication and authorization of the Administrator at the Group Manager. Protocol-specific transport profiles of ACE are used to achieve communication security, proof-of-possession, and server authentication. |
| | Additional Formats of Authentication Credentials for the Datagram Transport Layer Security (DTLS) Profile for Authentication and Authorization for Constrained Environments (ACE) |
| |
|
This document updates the Datagram Transport Layer Security (DTLS) profile for Authentication and Authorization for Constrained Environments (ACE). In particular, it specifies the use of additional formats of authentication credentials for establishing a DTLS session, when peer authentication is based on asymmetric cryptography. Therefore, this document updates RFC 9202. What is defined in this document is seamlessly applicable also if the profile uses Transport Layer Security (TLS) instead, as defined in RFC 9430. |
| | Bit Index Explicit Replication (BIER) Ping and Trace |
| |
| | draft-ietf-bier-ping-18.txt |
| | Date: |
07/01/2026 |
| | Authors: |
Nagendra Nainar, Carlos Pignataro, Mach Chen, Greg Mirsky |
| | Working Group: |
Bit Indexed Explicit Replication (bier) |
|
Bit Index Explicit Replication (BIER) is a multicast forwarding architecture designed to simplify and optimize multicast delivery. This document describes the mechanism and basic BIER OAM packet format that can be used to perform failure detection and isolation on the BIER data plane without any dependency on other layers, like the IP layer. |
| | Key Usage Limits for OSCORE |
| |
|
Object Security for Constrained RESTful Environments (OSCORE) uses AEAD algorithms to ensure confidentiality and integrity of exchanged messages. Due to known issues allowing forgery attacks against AEAD algorithms, limits should be followed regarding the number of times a specific key is used for encryption or decryption. Among other reasons, approaching key usage limits requires updating the OSCORE keying material before communications can securely continue. This document defines how two OSCORE peers can follow these key usage limits and what steps they should take to preserve the security of their communications. |
| | BGP Link Bandwidth Extended Community |
| |
| | draft-ietf-idr-link-bandwidth-24.txt |
| | Date: |
07/01/2026 |
| | Authors: |
Prodosh Mohapatra, Reshma Das, MOHANTY Satya, Serge Krier, Rafal Szarecki, Akshay Gattani |
| | Working Group: |
Inter-Domain Routing (idr) |
|
This document defines a BGP Extended Community, the Link Bandwidth Extended Community, which carries bandwidth information to enable weighted load-balancing in multipath scenarios. It specifies the format and processing rules for this extended community type. |
| | Implementation Considerations for Ephemeral Diffie-Hellman Over COSE (EDHOC) |
| |
|
This document provides considerations for guiding the implementation of the authenticated key exchange protocol Ephemeral Diffie-Hellman Over COSE (EDHOC). |
| | Composite ML-KEM for use in X.509 Public Key Infrastructure |
| |
| | draft-ietf-lamps-pq-composite-kem-12.txt |
| | Date: |
07/01/2026 |
| | Authors: |
Mike Ounsworth, John Gray, Massimiliano Pala, Jan Klaussner, Scott Fluhrer |
| | Working Group: |
Limited Additional Mechanisms for PKIX and SMIME (lamps) |
|
This document defines combinations of US NIST ML-KEM [FIPS.203] in hybrid with traditional algorithms RSA-OAEP, ECDH, X25519, and X448. These combinations are tailored to meet security best practices and regulatory guidelines. Composite ML-KEM is applicable in any application that uses X.509 or PKIX data structures that accept ML- KEM, but where the operator wants extra protection against breaks or catastrophic bugs in ML-KEM. |
| | Composite ML-DSA for use in X.509 Public Key Infrastructure |
| |
| | draft-ietf-lamps-pq-composite-sigs-14.txt |
| | Date: |
07/01/2026 |
| | Authors: |
Mike Ounsworth, John Gray, Massimiliano Pala, Jan Klaussner, Scott Fluhrer |
| | Working Group: |
Limited Additional Mechanisms for PKIX and SMIME (lamps) |
|
This document defines combinations of US NIST ML-DSA in hybrid with traditional algorithms RSASSA-PKCS1-v1.5, RSASSA-PSS, ECDSA, Ed25519, and Ed448. These combinations are tailored to meet regulatory guidelines. Composite ML-DSA is applicable in applications that uses X.509 or PKIX data structures that accept ML-DSA, but where the operator wants extra protection against breaks or catastrophic bugs in ML-DSA, and where EUF-CMA-level security is acceptable. |
| | LISP Canonical Address Format (LCAF) |
| |
| | draft-ietf-lisp-rfc8060bis-03.txt |
| | Date: |
07/01/2026 |
| | Authors: |
Alvaro Retana, Dino Farinacci, Job Snijders, Alberto Rodriguez-Natal |
| | Working Group: |
Locator/ID Separation Protocol (lisp) |
|
This document defines a canonical address format encoding used in Locator/ID Separation Protocol (LISP) control messages and in the encoding of lookup keys for the LISP Mapping Database System. This document obsoletes RFC 8060. |
| | MPLS Network Action for Deterministic Networking |
| |
| | draft-ietf-mpls-mna-detnet-00.txt |
| | Date: |
07/01/2026 |
| | Authors: |
Xueyan Song, Greg Mirsky, Balazs Varga, Rakesh Gandhi, Quan Xiong |
| | Working Group: |
Multiprotocol Label Switching (mpls) |
|
This document specifies formats and mechanisms for using MPLS Network Actions (MNA) to support Deterministic Networking (DetNet) services, including bounded latency, low loss and in-order delivery. It defines MPLS In-Stack and Post-Stack MNA for carrying DetNet-specific information, such as flow identification, sequence number, and latency information, which are forwarded over an MPLS technology- based network domain. |
| | BGP over QUIC |
| |
| | draft-retana-idr-bgp-quic-08.txt |
| | Date: |
07/01/2026 |
| | Authors: |
Alvaro Retana, Yingzhen Qu, Jeffrey Haas, Shuanglong Chen, Jeff Tantsura |
| | Working Group: |
Individual Submissions (none) |
|
This document specifies the procedures for BGP to use QUIC as a transport protocol with a mechanism to carry Network Layer protocols (AFI/SAFI) over multiple QUIC streams to achieve high resiliency. |
| | A YANG Data Model for Resource Performance Monitoring |
| |
| | draft-yu-ccamp-resource-pm-yang-05.txt |
| | Date: |
07/01/2026 |
| | Authors: |
Chaode Yu, Fabio Peruzzini, Zheng Yanlei, Italo Busi, Aihua Guo, Victor Lopez, XingZhao, Mingshuang Jin |
| | Working Group: |
Individual Submissions (none) |
|
This document defines a YANG data model for resource Performance Monitoring, applicable to network controllers, which provides the functionalities of retrieval of performance monitoring capabilities, TCA (Threshold Crossing Alert) configuration, current or history performance data retrieval, and performance monitoring task management. |
| | A YANG Data Model for Service Path Computation |
| |
|
This document defines a YANG data model for client signal service's path computation and path management. |
| | A YANG Data Model for Passive Network Inventory |
| |
| | draft-ygb-ivy-passive-network-inventory-03.txt |
| | Date: |
07/01/2026 |
| | Authors: |
Chaode Yu, Aihua Guo, Italo Busi, Mohammad Boroon, Sergio Belotti, tom van caenegem, Swaminathan S., Swaminathan B., Nigel Davis, Mauro Tilocca, Brad Peters, Bin Yoon, liuyucong, Yang Zhao, Avinash Sakalabhaktula |
| | Working Group: |
Individual Submissions (none) |
|
This document presents a YANG data model for tracking and managing passive network inventory. The model enhances the base model outlined in [I-D.draft-ietf-ivy-network-inventory-yang] and is intended for use in the northbound interface of a domain controller as defined in [RFC8453]. |
| | Synchronizing caches of DNS resolvers |
| |
|
Network of cooperating and mutually trusting DNS resolvers could benefit from cache sharing, where one resolver would distribute the result of a resolution to other resolvers. This document standardizes a protocol to do so. |
| | Tunnel Extensible Authentication Protocol (TEAP) Version 2 |
| |
|
This document defines the Tunnel Extensible Authentication Protocol (TEAP) version 2. It addresses a number of security and interoperability issues in TEAPv1 which was defined in [I-D.ietf-emu-rfc7170bis]. |
| | Applicability of Service & Infrastructure Maps (SIMAP) to Transport Networks |
| |
|
This document explores the applicability of the Service & Infrastructure Maps (SIMAP) concepts to transport networks and it examines the YANG data models defined by the IETF to support the requirements and use cases for SIMAP applicability to transport networks. |
| | Distribution of Software Updates with End-to-End Secure Group Communication and Block-Wise Transfer for CoAP |
| |
|
This document defines a method for efficiently distributing a software update to multiple target devices, by using end-to-end secure group communication over UDP and IP multicast. To this end, the defined method relies on a number of building blocks developed in the Constrained RESTful Environments (CoRE) Working Group of the IETF. Those especially include the Constrained Application Protocol (CoAP), Block-wise transfers for CoAP, and the end-to-end security protocol Group Object Security for Constrained RESTful Environments (Group OSCORE). The method defined in this document is compatible with (but not dependent on) the architecture for software and firmware update developed in the Software Updates for Internet of Things (SUIT) Working Group of the IETF. |
| | Workload Identifier Scope Hint for TLS ClientHello |
| |
|
This document defines a TLS extension that allows clients to indicate one or more workload identifier scopes in the ClientHello message. Each scope consists of a URI scheme and trust domain component, representing the administrative domain and identifier namespace in which the client operates. These identifier scopes serve as hints to enable the server to determine whether client authentication is required and which policies or trust anchors should apply. This mechanism improves efficiency in mutual TLS deployments while minimising the exposure of sensitive identifier information. To protect confidentiality, this extension can be used in conjunction with Encrypted Client Hello (ECH). |
| | Extensions to TLS FATT Process |
| |
|
This document applies only to non-trivial extensions of TLS, which require formal analysis. It proposes the authors provide a threat model and informal security goals in the Security Considerations section, and a protocol diagram in the draft. We also briefly present a few pain points of the one doing the formal analysis which require refining the process: * Contacting FATT * Understanding the opposing goals * No response from some authors * Slots at meeting |
| | Export of BGP VPN Information in IPFIX |
| |
|
This document introduces new IP Flow Information Export (IPFIX) information elements to carry the egress PE information in IPFIX. |
| | Deprecating IPv6 Extension Headers on the Internet |
| |
|
This document describes the deprecation of IPv6 extension headers on the Internet with the exception of Encapsulating Security Payload. Deprecation is motivated by three factors: 1) the data shows high discard rates for packets with extension headers sent over the Internet, 2) extension headers can be used for Denial of Service attack and are replete with other security vulnerabilities, 3) the high loss rates are a disincentive to develop new extension headers or options that might be useful or fix known problems. This document recommends that extension headers, other than Encapsulating Security Payload, be relegated to use only in limited domains and that packets with extension headers should be discarded at boundary routers of limited domains. |
| | Deprecate IPv6 Destination Options Before the Routing Header |
| |
|
This document deprecates IPv6 Destination Options before the Routing header since there are no known deployments or uses for the Destination Options Header placed ahead in precedence of the Routing Header. It also requires that if a Routing header is present in a packet then it must immediately follow the IPv6 header or immediately follow the Hop-by-Hop Options header if an Hop-by-Hop Options header is also present in the packet. These requirements imply that at most one Routing header may be present in a packet. |
| | Privacy-Preserving Federated Learning Architecture for Multi-Tenant AI Agent Systems |
| |
|
This document specifies a reference architecture for privacy- preserving federated learning in multi-tenant AI agent deployments. It addresses the challenge of enabling collaborative model training across organizational boundaries while maintaining formal privacy guarantees and tenant data isolation. The architecture combines federated averaging, differential privacy mechanisms, and secure aggregation to enable cross-tenant knowledge transfer without exposing sensitive behavioral data. |
| | Routing in Fat Trees (RIFT) Key/Value Topology Information Elements Structure and Processing |
| |
|
The RIFT (Routing in Fat Trees) protocol allows for key/value pairs to be advertised within Key-Value Topology Information Elements (KV TIEs). The data contained within these KV TIEs can be used for any imaginable purpose. This document specifies behavior for the various Key-Types (i.e., Well-Known, OUI, and Experimental) and a method to structure corresponding values. It also defines a Well-Known Key Sub-Type used for testing tie-breaking behavior. |
| |
|
| |
| | BGP Link-State extensions for BIER |
| |
| | draft-ietf-bier-bgp-ls-bier-ext-21.txt |
| | Date: |
06/01/2026 |
| | Authors: |
Ran Chen, Zheng Zhang, Vengada Govindan, IJsbrand Wijnands, Zhaohui Zhang |
| | Working Group: |
Bit Indexed Explicit Replication (bier) |
|
Bit Index Explicit Replication (BIER) is an architecture that provides optimal multicast forwarding through a "BIER domain" without requiring intermediate routers to maintain any multicast related per- flow state. BIER also does not require any explicit tree-building protocol for its operation. A multicast data packet enters a BIER domain at a "Bit-Forwarding Ingress Router" (BFIR), and leaves the BIER domain at one or more "Bit-Forwarding Egress Routers" (BFERs). The BFIR router adds a BIER header to the packet. The BIER header contains a bitstring in which each bit represents exactly one BFER to forward the packet to. The set of BFERs to which the multicast packet needs to be forwarded is expressed by setting the bits that correspond to those routers in the BIER header. BGP Link-State (BGP-LS) enables the collection of various topology informations from the network, and the topology informations are used by the controller to calculate the fowarding tables and then propagate them onto the BFRs(instead of having each node to calculate on its own) and that can be for both inter-as and intra-as situations. This document specifies extensions to the BGP Link-state address- family in order to advertise the BIER informations. |
| | Dynamic Capability for BGP-4 |
| |
|
This document defines a new BGP capability termed "Dynamic Capability", which would allow the dynamic update of capabilities over an established BGP session. This capability would facilitate non-disruptive capability changes by BGP speakers. |
| | Accumulated Metric in NHC attribute |
| |
| | draft-ietf-idr-bgp-generic-metric-02.txt |
| | Date: |
06/01/2026 |
| | Authors: |
Srihari Sangli, Shraddha Hegde, Reshma Das, Bruno Decraene, Bin Wen, Marcin Kozak, Jie Dong, Luay Jalil, Ketan Talaulikar |
| | Working Group: |
Inter-Domain Routing (idr) |
|
RFC7311 describes mechanism for carrying accumulated IGP cost across BGP domains however it limits to IGP-metric only. There is a need to accumulate and propagate different types of metrics as it will aid in intent-based end-to-end path across BGP domains. This document defines BGP extensions for generic metric sub-types that enable different types of metrics to be accumulated and carried in BGP. This is applicable when multiple domains exchange BGP routing information. |
| | Clarification to Processing Key Usage Values During Certificate Revocation List (CRL) Validation |
| |
|
RFC 5280 (Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile) defines the profile of X.509 certificates and CRLs for use in the Internet. Section 4.2.1.3 of RFC 5280 requires CRL issuer certificates to contain the keyUsage extension with the cRLSign bit asserted. However, the CRL validation algorithm specified in Section 6.3 of RFC 5280 does not explicitly include a corresponding check for the presence of the keyUsage certificate extension. This document updates RFC 5280 to require that check. |
| | Unobtrusive End-to-End Email Signatures |
| |
|
This document deals with end-to-end cryptographically signed email. It introduces a novel structure for signed email that is designed to avoid creating any disturbance in legacy email clients. This "unobtrusive" signature structure removes disincentives for signing email. |
| | MISP taxonomy format |
| |
|
This document outlines the MISP taxonomy format, a straightforward JSON structure designed to represent machine tags (also known as triple tags) vocabularies. A public directory, referred to as MISP taxonomies, is available and leverages this format. These taxonomies are used to classify cybersecurity events, threats, suspicious activities, and indicators. |
| | Email Feedback Reports for DKIM Signers |
| |
|
Mechanism to discover a destination used to deliver user-supplied FBL reports to an original DKIM signer or other responsible parties. This allows the reporting entity to deliver reports for each party which has affixed a validating DKIM signature. The discovery is made via DNS and the record is constructed using items within the DKIM signature in the message. |
| | Automated Certificate Management Environment (ACME) Extension for Public Key Challenges |
| |
|
This document specifies an extension to the ACME protocol [RFC8555] that enables Acme server to use the public key authentication protocol to verify that the real certificate applicant behind the Acme client has control over the identity and to ensure strong consistency between the identity in the challenge phase and the identity of the final certificate issued. This document also proposes a process extension for removing CSR at the certificate application phase. |
| | Decentralized RPKI Repository Architecture |
| |
|
The Resource Public Key Infrastructure (RPKI) plays a crucial role in securing inter-domain routing. However, the current RPKI Repository system suffers from fundamental limitations in reliability, scalability, and consistency. In particular, single-point failures at repository publication points (PPs), the growing number of bidirectional connections between PPs and relying parties (RPs), and the lack of a globally consistent historical RPKI data view pose significant risks to the resilience, integrity, and authority of the global RPKI ecosystem. This document proposes the Decentralized RPKI Repository (dRR), a novel repository architecture that decouples RPKI object signing authority from RPKI object management authority (e.g., storage and distribution). dRR introduces a distributed group of certificate servers (CSs) and a layer of Monitors to achieve robust, scalable, and auditable RPKI data management. The architecture maintains full compatibility with the existing RPKI trust model rooted in the five RIR trust anchors, enabling incremental deployment without disrupting current relying parties (RPs) validation semantics. By doing so, dRR addresses longstanding repository challenges and enhances the overall efficiency and trustworthiness of RPKI-based routing security. |
| | Normative Admissibility Framework for Agent Speech Acts |
| |
|
This document defines a normative framework for evaluating the admissibility of speech acts produced by autonomous agents in goal- directed activity. The framework establishes rules for determining whether an agent's statement is admissible based on its modality (assertive, conditional, refusal, descriptive) and its grounding state, independent of semantic truth. This framework enables deterministic, auditable evaluation of agent contributions without requiring truth verification or semantic interpretation. |
| | The Universal Zero-Port Interconnect Framework (UZPIF): An Identity-Centric Architecture for Post-Port Networking |
| |
|
The Universal Zero-Port Interconnect Framework (UZPIF) describes a post-port networking model in which communication is established via outbound, identity-bound sessions to Rendezvous Nodes (RNs). By removing publicly reachable listening ports at endpoints, UZPIF aims to reduce exposure to Internet-wide scanning and unsolicited ingress, and to constrain a broad class of lateral-movement vectors. This document outlines architectural motivation, a high-level security model, operational and economic considerations, a governance concept (Pantheon), and an incremental migration approach. UZPIF is intended to be read alongside companion work describing the Universal Zero-Port Transport Protocol (UZP; [UZP]) and TLS-UZP ([TLS-DPA]). |
| | Provenance Identifier TCP Option |
| |
|
This document describes a TCP option that carries a Provenance Identifier (ProvID) to enable correlation of TCP connections when transport-layer identifiers change along the path. |
| | Export of Segment Routing Path Segment Identifier (PSID) Information in IPFIX |
| |
|
This document introduces new IPFIX Information Elements to identify the Segment Routing (SR) Path Segment Identifier (PSID) for SR-MPLS and SRv6 paths identification. |
| | PCEP Extensions for Tree Engineering for Bit Index Explicit Replication (BIER-TE) |
| |
| | draft-ietf-pce-bier-te-03.txt |
| | Date: |
06/01/2026 |
| | Authors: |
Ran Chen, Zheng Zhang, Huaimo Chen, Senthil Dhanaraj, Fengwei Qin, Aijun Wang |
| | Working Group: |
Path Computation Element (pce) |
|
Tree Engineering for Bit Index Explicit Replication (BIER-TE) shares architecture and packet formats with BIER. BIER-TE forwards and replicates packets based on a BitString in the packet header, but every BitPosition of the BitString of a BIER-TE packet indicates one or more adjacencies. BIER-TE Path can be derived from a Path Computation Element (PCE). This document specifies extensions to the Path Computation Element Protocol (PCEP) that allow a PCE to compute and initiate the path for the Tree Engineering for Bit Index Explicit Replication (BIER-TE). |
| |
|
| |
| | Framework and Data Model for OTN Network Slicing |
| |
| | draft-ietf-ccamp-yang-otn-slicing-10.txt |
| | Date: |
05/01/2026 |
| | Authors: |
Aihua Guo, Luis Contreras, Sergio Belotti, Reza Rokui, Yunbin Xu, Yang Zhao, Xufeng Liu |
| | Working Group: |
Common Control and Measurement Plane (ccamp) |
|
The requirement of slicing network resources with desired quality of service is emerging at every network technology, including the Optical Transport Networks (OTN). As a part of the transport network, OTN can provide hard pipes with guaranteed data isolation and deterministic low latency, which are highly demanded in the Service Level Agreement (SLA). This document describes a framework for OTN network slicing and defines YANG data models with OTN technology-specific augments deployed at both the north and south bound of the OTN network slice controller. Additional YANG data model augmentations will be defined in a future version of this draft. |
| | Bundle Protocol Security (BPSec) COSE Context |
| |
|
This document defines a security context suitable for using CBOR Object Signing and Encryption (COSE) algorithms within Bundle Protocol Security (BPSec) integrity and confidentiality blocks. A profile for COSE, focused on asymmetric-keyed algorithms, and for PKIX certificates are also defined for BPSec interoperation. |
| | Segment Routing Path MTU in BGP |
| |
|
Segment Routing is a source routing paradigm that explicitly indicates the forwarding path for packets at the ingress node. An SR policy is a set of SR Policy candidate paths consisting of one or more segments with the appropriate SR path attributes. BGP distributes each SR Policy candidate path as combination of an prefix plus a the BGP Tunnel Encapsulation(Tunnel-Encaps) attribute containing an SR Policy Tunnel TLV with information on the SR Policy candidate path as a tunnel. However, the path maximum transmission unit (MTU) information for a segment list for SR path is not currently passed in the BGP Tunnel-Encaps attribute. . This document defines extensions to BGP to distribute path MTU information within SR policies. |
| | Update of the Simple Two-way Active Measurement Protocol Class-of-Service Extension - ECN |
| |
|
The Simple Two-Way Active Measurement Protocol (STAMP) enables one- way and round-trip measurement of network metrics between IP hosts, and has a facility for defining optional extensions. This document updates the definition of the Class of Service TLV (originally defined in RFC 8972) to enable the measurement of manipulation of the value of the Explicit Congestion Notification (ECN) field of the IP header by middleboxes between two STAMP hosts, and to enable discovery and measurement of paths that provide differential treatment of packets depending on the value of their ECN field. |
| | The Role of the Internet Research Task Force (IRTF) |
| |
|
This memo discusses the role of the Internet Research Task Force (IRTF), considering its research groups, community, and the various workshops, prizes, and other activities it supports. The relationship of the IRTF to the IETF is also considered. This document is a product of the Internet Research Steering Group (IRSG). |
| | Registration of further IMAP/JMAP keywords and mailbox name attributes |
| |
|
This document defines a number of keywords and mailbox name attributes that have been in use across different server and client implementations. It defines the intended use of these keywords and mailbox name attributes. This document registers all of these with IANA to avoid name collisions. |
| | Intentionally Temporarily Degraded or Insecure |
| |
|
Performing DNSKEY algorithm transitions with DNSSEC signing is unfortunately challenging to get right in practice without decent tooling support. This document weighs the correct, completely secure way of rolling keys against an alternate, significantly simplified, method that takes a zone through an insecure state first. |
| | A CoRIM Profile for Arm's Platform Security Architecture (PSA) Endorsements |
| |
|
PSA Endorsements comprise reference values, endorsed values, cryptographic key material and certification status information that a Verifier needs in order to appraise Attestation Evidence produced by a PSA device. This memo defines PSA Endorsements as a profile of the CoRIM data model. |
| | The Transit Measurement Option |
| |
|
This document specifies an IPv6 option that contains a compact set of fields which can be used for transit delay measurement and congestion detection. This option can be incorporated into data packets and updated by transit nodes along the path, enabling lightweight measurement and monitoring using constant-length data that does not depend on the number of hops in the network. |
| | Secret Key Agreement for DNS: The TKEY Resource Record |
| |
|
RFC 8945 provides efficient authentication of Domain Name System (DNS) protocol messages using shared secret keys and the Transaction Signature (TSIG) resource record (RR). However, it provides no mechanism for setting up such keys other than by configuration. This document specifies the Transaction Key (TKEY) RR that can be used to establish shared secret keys between a DNS resolver and server. This document obsoletes RFC 2930. |
| | MIMI Portability |
| |
|
This document describes MIMI Portability mechanisms. |
| | MIMI Attachments |
| |
|
This document describes MIMI Attachments. |
| | Attester Groups for Remote Attestation |
| |
|
This document proposes an extension to the Remote Attestation Procedures architecture by introducing the concept of Attester Groups. This extension aims to reduce computational and communication overhead by enabling collective Evidence appraisal of high number of homogeneous devices with similar characteristics, thereby improving the scalability of attestation processes. |
| | A CoRIM Profile for Arm's Confidential Computing Architecture (CCA) Endorsements |
| |
|
Arm Confidential Computing Architecture (CCA) Endorsements comprise reference values and cryptographic key material that a Verifier needs to appraise Attestation Evidence produced by an Arm CCA system. This memo defines CCA Endorsements as a profile of the CoRIM data model. 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/yogeshbdeshpande/draft-cca-rats-endorsements. |
| | Composite ML-DSA Signatures for SSH |
| |
|
This document describes the use of PQ/T composite signatures for the Secure Shell (SSH) protocol. The composite signatures described combine ML-DSA as the post-quantum part and the elliptic curve signature schemes ECDSA, Ed25519 and Ed448 as the traditional part. |
| | Kerberos SPAKE with Two-Factor Authentication |
| |
|
This document defines a new two-factor authentication mechanism for the Kerberos SPAKE pre-authentication. The mechanism uses the time- based one-time password (TOTP) as a second factor, and combines it with the password factor in a more secure way, which can prevent attackers from both impersonating Kerberos clients and obtaining TGTs' session keys in case of any factor leakage. |
| | WIMSE Extensions for Trustworthy Workload Identity |
| |
|
This document contains a gap analysis that is the output of the Confidential Computing Consortium identifying areas in the IETF WIMSE WG work where the current WIMSE architecture should be extended to accommodate workloads running in Confidential Computing environments. This document contains a high-level outline for these extensions. |
| | SRv6 End-to-End DC Frontend and WAN |
| |
|
The SRv6 Network Programming architecture allows an application to control the end-to-end journey of traffic flows through different network domains in a unified and stateless manner, meaning intermediate network devices do not store per-flow information. This document covers its application to the integration of data center (DC) and wide area network (WAN) architectures using SRv6 with uSID (NEXT-CSID). This eliminates the complexities and inefficiencies associated with traditional fragmented network designs. The solution enhances scalability and enables flexible stateless service insertion by unifying the DC and WAN under a single SRv6 domain. |
| | In Situ Operations,Administration,and Maintenance (IOAM) Template Option |
| |
|
In situ measurement is performed by incorporating performance related information into in-flight data packets. This document specifies a new IOAM Option-Type that has a fixed length and can be updated by transit nodes along the path. It enables lightweight monitoring while maintaining a constant length that is not changed in-flight and is not affected by the number of hops in the network. |
| | Distributed Remote Attestation |
| |
|
In many deployments, remote attestation is performed within separate administrative and trust domains. Each domain typically operates its own management plane and a Remote Attestation Service (RAS) to obtain verifier inputs (e.g., endorsement material and reference values) and produce attestation results. At scale, cross-domain scenarios face two recurring challenges: (1) enabling policy-controlled transparency so that verifiers or relying parties in one domain can discover and retrieve selected attestation artifacts from other domains; and (2) supporting many-to-many distribution and reuse of verifier inputs and verifier outputs without requiring point-to-point integrations. This document describes Distributed Remote Attestation (DRA) patterns that use a shared publication channel for selected artifacts with provenance and access control in mind. A Distributed Ledger (DL) is discussed as one concrete instantiation of such a publication channel, including an option to host verification logic on the DL. The described patterns are intended to complement existing RATS procedures and conceptual messages, and can be realized by other tamper-evident publication channels with comparable properties. |
| | HTTP Redirect Headers |
| |
|
This document defines HTTP headers that enable secure parameter passing and mutual authentication during browser redirects. The Redirect-Query header carries parameters in browser-controlled headers instead of URLs, preventing leakage through browser history, Referer headers, server logs, and analytics systems. The Redirect- Origin header provides browser-verified origin authentication that cannot be spoofed or stripped, enabling reliable mutual authentication between parties. The optional Redirect-Path header allows servers to request path-specific origin verification. Together, these headers address critical security and privacy concerns in authentication and authorization protocols such as OAuth 2.0, OpenID Connect, and SAML. |
| | OAuth 2.0 Extension for AI Model Access |
| |
|
This document defines an extension to OAuth 2.0 for delegating scoped access to AI model APIs. It introduces a standardized scope syntax, resource indicators for AI providers, and token constraints suitable for AI workloads including spend limits and model restrictions. |
| | TLS-DPA: An Identity-Bound Security Protocol for Traditional,Overlay,and Zero-Port Transports |
| |
|
TLS-DPA is an experimental, identity-bound security protocol inspired by the design of TLS 1.3 ( [RFC8446] ). It is intended to operate consistently across environments where conventional IP address and port semantics are weak, unstable, or intentionally absent, including zero-port transports such as UZP ( [UZP] ). TLS-DPA generalises the handshake so it is not tied to server-side listeners, binds authentication to Service Identities rather than network coordinates, reduces metadata exposure to intermediaries (including rendezvous nodes in UZP fabrics), provides a unified hybrid-KEM post-quantum transition model ( [NIST-PQC] ), and supports session continuity across overlay path changes (e.g., QUIC Connection IDs; [RFC9000] ). |
| | UZP: Universal Zero-Port Transport Protocol |
| |
|
The Universal Zero-Port Transport Protocol (UZP) defines an identity- addressed, encrypted-by-default transport for the Universal Zero-Port Interconnect Framework (UZPIF; [UZPIF]). Instead of exposing IP:port listeners, both endpoints establish outbound, identity-bound sessions to one or more Rendezvous Nodes (RNs). The RN performs flow stitching but never terminates end-to-end cryptography or holds long- term secrets. All application data is carried over an authenticated encryption (AEAD) channel keyed by a handshake based on modern and post-quantum-capable primitives. Reliability is expressed at the block level, rather than at the TCP segment or stream level, enabling selective retransmission and deterministic pacing. This document specifies the UZP wire format, handshake, cryptographic negotiation, exporter interface, 0-RTT rules, replay model, and RN behaviour, and its relationship to UZPIF ([UZPIF]), QUIC ([RFC9000]), HIP ([RFC7401]), and TLS 1.3 ([RFC8446]). |
| | New requirements for Authentication and Authorization in the AI Agents era |
| |
|
AI Agents are rapidly evolving from academic concepts into the core engines driving next-generation applications. However, their autonomy, dynamic nature, and complex delegation relationships pose a fundamental challenge to our existing authentication and authorization frameworks, which were designed for human users and traditional software. This document dissects the novel characteristics of AI Agents and outlines the new requirements for authentication and authorization which can manage dynamic behavior rather than verifying static identity. |
| | Avoid Large Records with a Wildcard Owner Name |
| |
|
As DNS hosting becomes increasingly centralized, with multiple zones hosted on shared authoritative name servers, the risk of DNS amplification attacks has grown. By crafting large DNS records with wildcard owner names, attackers can exploit these shared servers to launch high-volume DDoS amplification attacks. This document provides operational guidance for DNS hosting providers to mitigate DDoS risks arising from amplification of responses derived from wildcard owner names. |
| | Extended Key Update for QUIC |
| |
|
This document specifies an Extended Key Update mechanism for the QUIC protocol, building on the foundation of the TLS Extended Key Update. The TLS Extended Key Update specification enhances the TLS protocol by introducing key updates with forward secrecy, eliminating the need to perform a full handshake. This feature is particularly beneficial for maintaining security in scenarios involving long-lived connections. This specification replaces the QUIC Key Update mechanism described in the "Using TLS to Secure QUIC" specification. |
| |
|
| |
| | Lzip Compressed Format and the 'application/lzip' Media Type |
| |
|
Lzip is a lossless compressed data format designed for data sharing, long-term archiving, and parallel compression/decompression. Lzip uses LZMA compression and can achieve higher compression ratios than gzip. Lzip provides accurate and robust 3-factor integrity checking. This document describes the lzip format and registers a media type, a content coding, and a structured syntax suffix to be used when transporting lzip-compressed content via MIME or HTTP. |
| | Path Tracing in SRv6 networks |
| |
| | draft-filsfils-ippm-path-tracing-05.txt |
| | Date: |
04/01/2026 |
| | Authors: |
Clarence Filsfils, Ahmed Abdelsalam, Pablo Camarillo, Mark Yufit, Yuanchao Su, Satoru Matsushima, Mike Valentine, Dhamija |
| | Working Group: |
Individual Submissions (none) |
|
Path Tracing provides a record of the packet path as a sequence of interface ids. In addition, it provides a record of end-to-end delay, per-hop delay, and load on each egress interface along the packet delivery path. Path Tracing allows to trace 14 hops with only a 40-bytes IPv6 Hop- by-Hop extension header. Path Tracing supports fine grained timestamp. It has been designed for linerate hardware implementation in the base pipeline. |
| | Filtering Out RPKI Data by Type based on Enhanced SLURM Filters |
| |
|
Simplified Local Internet Number Resource Management with the RPKI (SLURM) helps operators create a local view of the global RPKI by generating sets of filters and assertions. This document proposes to filter out RPKI data by type based on enhanced SLURM filters. Only the RPKI data types that the network or routers are interested in will appear in the Relying Party's output. |
| | Source Prefix Advertisement for Inter-domain SAVNET |
| |
|
This document proposes to use Source Prefix Advertisement (SPA) messages for advertising hidden source prefixes and discovering the hidden paths of source prefixes. The accuracy of existing inter- domain SAV mechanisms like EFP-uRPF can be improved by SPA. |
| | A SCITT Profile for Verifiable Audit Trails in Algorithmic Trading: The VeritasChain Protocol (VCP) |
| |
|
This document defines a profile of the SCITT (Supply Chain Integrity, Transparency, and Trust) architecture for creating tamper-evident audit trails of AI-driven algorithmic trading decisions and executions. The VeritasChain Protocol (VCP) applies the SCITT framework to address the specific requirements of financial markets, including high-precision timestamps, regulatory compliance considerations (EU AI Act, MiFID II), and privacy-preserving mechanisms (crypto-shredding) compatible with GDPR. This profile specifies how VCP events are encoded as SCITT Signed Statements, registered with Transparency Services, and verified using COSE Receipts. |
| | Service Binding Mapping for Agents |
| |
|
With the continuous introduction of intelligent agent communication and interaction protocols, the current DNS cannot adequately meet the requirements for agent service resolution. This document defines a new DNS resource record type, AGENT, which is a SVCB-compatible RR type, and specifies the mapping specifications. |
| | PIM Join Attributes for Locator/ID Separation Protocol (LISP) Environments |
| |
|
This document defines two PIM Join/Prune attributes that support the construction of multicast distribution trees where the root and receivers are located in different Locator/ID Separation Protocol (LISP) sites. These attributes allow the receiver site to select between unicast and multicast underlying transport, to convey the RLOC (Routing Locator) address of the receiver ETR (Egress Tunnel Router) to the control plane of the root ITR (Ingress Tunnel Router) and to signal the underlay multicast group to the control plane of the root ITR. This document updates RFC 8059 and RFC 9798. |
| |
|
| |
| | A YANG Data Model for Network Incident Management |
| |
|
A network incident refers to an unexpected interruption of a network service, degradation of a network service quality, or sub-health of a network service. Different data sources including alarms, metrics, and other anomaly information can be aggregated into a few of network incidents through data correlation analysis and the service impact analysis. This document defines a YANG Module for the network incident lifecycle management. This YANG module is meant to provide a standard way to report, diagnose, and help resolve network incidents for the sake of network service health and probable cause analysis. |
| | Inter-domain Source Address Validation based on AS relationships |
| |
|
This draft introduces a distributed inter-domain source address validation scheme based on AS relationships named AS Relationship Based Inter-domain Filtering (ARBIF). It primarily describes this method from seven aspects: a brief introduction to the scheme, an overview of the AS relationship classification and acquisition methods, the architecture of the ARBIF system, implementation based on BGP extension, typical use cases, experiments of ARBIF, and considerations for deployability. |
| | Advertisement of Multi-Sourced SAV Rules using BGP Link-State |
| |
|
This document describes the protocol extensions of BGP Link-State to collect source address validation (SAV) rules generated by different protocols/mechanisms, to facilitate multi-sourced SAV rules monitoring and management. |
| | A Public Key Service Provider for Verification in Multiple Issuers and Verifiers |
| |
|
SPICE provides a selective disclosure mechanism of credentials from issuer. However, future network services may be built on the trust between multiple entities. Obtaining the public key of multiple issuers for a verifer from potential multiple sources can be complex. In this contribution, an optional public key service is proposed in SPICE architecture for the issue of obtaining the public keys of the issuers from multiple trusted entities. The basic function of public key service is proposed including public key registration, token verification, and a potential implementation such as the distributed ledger. We hope that the proposed contribution can be used as infomative for SPICE regarding to the token validation procedure. |
| | BGP Extensions to Enable BGP FlowSpec based IFIT |
| |
|
Border Gateway Protocol (BGP) Flow Specification (FlowSpec) is an extension to BGP that supports the dissemination of traffic flow specifications and resulting actions to be taken on packets in a specified flow. In-situ Flow Information Telemetry (IFIT) denotes a family of flow-oriented on-path telemetry techniques, which can provide high-precision flow insight and real-time network issue notification. This document defines BGP extensions to distribute BGP FlowSpec based traffic filtering carrying IFIT information. So IFIT behavior can be applied to the specified flow automatically. |
| | PQ/T Hybrid Composite Key Exchange and Reliable Transport for IKEv2 |
| |
|
The eventual transition to post-quantum key exchange will require elimination of traditional key exchange for reduced protocol complexity and efficiency. IKEv2 therefore requires a mechanism that can operate in a PQC-only environment, without depending on traditional key exchange algorithms (e.g., MODP DH or ECDH). As IKEv2 permits arbitrary combinations of algorithms, unnecessary complexity and insecure hybrid constructions are easily implemented. This document defines PQ/T hybrid composite key exchange algorithms for IKEv2 and a single combined KE payload that carries both the traditional and post-quantum components. It also leverages the existing IKEv2 reliable transport mechanism so that large PQC key exchange messages can be reliably exchanged over TCP. Together, these mechanisms enable secure and efficient PQ/T hybrid deployments today and provide a clear path for IKEv2 to operate in environments where traditional algorithms have been replaced by PQC algorithms. |
| | Secure Mobile Vault Format |
| |
|
The Secure Mobile Vault Format (SMVF) defines a binary container format for storing encrypted password vaults on mobile devices. The format is designed to be offline-first, zero-knowledge, cryptographically robust, and forward-compatible. SMVF specifies strict structural layout, authenticated encryption, and deterministic metadata handling suitable for constrained mobile environments. 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/voyager-2021/smv-specification. |
| | Operational Practices for Digital Sovereignty and Meaningful Connectivity through Circular Management of User and Network Devices |
| |
|
This document systematizes operational practices observed across multiple community-centred deployments that aim to improve meaningful connectivity and digital sovereignty through the circular management of end-user and network devices. It is published as an Informational RFC on the IRTF stream and does not define Internet standards or protocol requirements. The document addresses a foundational but often overlooked dependency of Internet access deployments: the availability, repairability, governance, and lifecycle management of network and user devices required to meaningfully use access networks. It is based on operational experience from deployments in Spain, Argentina, and Senegal—including eReuse.org, EKOA/UNLP, Solidança, TAU/RAEE, and Hahatay. It describes practices that have demonstrated positive access, social, and environmental outcomes. These practices are presented as descriptive guidance derived from operational experience rather than as normative requirements. They complement research within the IRTF GAIA Research Group by documenting reproducible approaches that improve the sustainability, autonomy, and long-term viability of Internet access in underserved contexts. |
| | QNAME Minimization Trade-offs : Privacy Leakage and Amplification potential |
| |
|
This document examines the current protocol policies and operational state of QNAME Minimization (QMIN), defined in RFC 9156 [RFC9156]. While QMIN is a DNS privacy mechanism, its existing implementation strategies introduce subtle trade-offs between privacy and security. Specifically, current policies may still present potential information leakage or introduce query amplification potential. This informational document aims to alert protocol designers, implementers, and users to these emerging challenges and suggests that a careful re-evaluation and improvement of the QMIN mechanism are necessary to fully mitigate these combined privacy and security risks. |
| |
|
| |
| | A YANG Data Model for the Alternate Marking Method |
| |
|
Alternate-Marking Method is a technique used to perform packet loss, delay, and jitter measurements on in-flight packets. This document defines a YANG data model for the Alternate Marking Method. |
| | On-Path Telemetry YANG Data Model |
| |
|
This document proposes a YANG data model for monitoring On-Path network performance information to be published in YANG notifications. The Alternate-Marking Method and In-situ Operations, Administration, and Maintenance (IOAM) are the On-Path hybrid measurement methods considered in this document. |
| | Deterministic Route Redistribution into BGP |
| |
|
In this document we present several examples of non-deterministic routing behavior involving route redistribution into BGP. To eliminate such non-deterministic behavior, we propose an enhancement to BGP route selection that would take into account the administrative distance under certain conditions. Additionally, We recommend lowering the LOCAL_PREF value in implementation for the redistributed backup route when appropriate. |
| | Stateless OpenPGP Command Line Interface |
| |
|
This document defines a generic stateless command-line interface for dealing with OpenPGP messages, certificates, and secret key material, known as sop. It aims for a minimal, well-structured API covering OpenPGP object security and maintenance of credentials and secrets. |
| | Multicast Extension for QUIC |
| |
|
This document defines a multicast extension to QUIC to enable the efficient use of multicast-capable networks to send identical data streams to many clients at once, coordinated through individual unicast QUIC connections. |
| | Detecting Unwanted Location Trackers |
| |
|
This document lists a set of best practices and protocols for accessory manufacturers whose products have built-in location- tracking capabilities. By following these requirements and recommendations, a location-tracking accessory will be compatible with unwanted tracking detection and alerts on mobile platforms. This is an important capability for improving the privacy and safety of individuals in the circumstance that those accessories are used to track their location without their knowledge or consent. |
| | Lightweight Directory Access Protocol (LDAP): Additional Syntaxes |
| |
|
This document registers additional syntax definitions for use in Lightweight Directory Access Protocol (LDAP) directory and Directoy services series X.500. This includes widely used datatypes and syntaxes. |
| | Deprecate IP Authentication Header |
| |
|
This document deprecates the IP Authentication Header. The motivations are that authentication without confidentiality is not compelling, the Authentication Header is incompatible with some commonly deployed protocols, and there is likely no deployment of Authentication Header. |
| | X.509v3 ML-DSA Certificates for the Secure Shell (SSH) Protocol |
| |
|
This document describes the use of Module-Lattice-Based Digital Signature Algorithm (ML-DSA) in Internet X.509 version 3 Public Key Certificate in the Secure Shell protocol. Accordingly, the document updates RFC6187. |
| | Path Computation Element Communication Protocol (PCEP) Extensions to Enable IFIT |
| |
| | draft-ietf-pce-pcep-ifit-08.txt |
| | Date: |
02/01/2026 |
| | Authors: |
Hang Yuan, wangxuerong, Pingan Yang, Weidong Li, Giuseppe Fioccola |
| | Working Group: |
Path Computation Element (pce) |
|
In-situ Flow Information Telemetry (IFIT) refers to network OAM data plane on-path telemetry techniques, in particular In-situ OAM (IOAM) and Alternate Marking. This document defines PCEP extensions to allow a Path Computation Client (PCC) to indicate which IFIT features it supports, and a Path Computation Element (PCE) to configure IFIT behavior at a PCC for a specific path in the stateful PCE model. The application to Segment Routing (SR) is reported. However, the PCEP extensions described in this document can be generalized for all path types, but that is out of scope of this document. |
| | Using JSContact in Registration Data Access Protocol (RDAP) JSON Responses |
| |
|
This document describes an RDAP extension which represents entity contact information in JSON responses using JSContact. |
| | The "exts_list" Parameter for the RDAP Media Type |
| |
|
This document defines a new parameter for the RDAP media type that can be used to describe RDAP content with RDAP extensions. Additionally, this document describes the usage of this parameter with RDAP for the purposes of signalling RDAP extensions during content negotiation. |
| |
|
| |
| | EAP defaults for devices that need to onboard |
| |
|
This document describes a method by which an unconfigured device can use EAP-TLS to join a network on which further device onboarding, network attestation or other remediation can be done. While RFC 5216 supports EAP-TLS without a client certificate, that document defines no method by which unauthenticated EAP-TLS can be used. This draft addresses that issue. |
| | Infight Removal of IPv6 Hop-by-Hop and Routing Headers |
| |
|
This document specifies a method to allow intermediate nodes to remove IPv6 Hop-by-Hop Options headers and Routing headers from packets inflight. The goal is to reduce the probability of packets being dropped because they contain these extension headers without impacting functionality. An additional goal is to limit visibility of information in extension headers to those nodes that need to process the headers. |
| | Secure Intent Protocol: JWT Compatible Agentic Identity and Workflow Management |
| |
|
This document specifies Agentic JSON Web Token (Agentic JWT), as an extension to OAuth 2.0 that addresses authorization challenges unique to autonomous agentic AI systems. This protocol solves the problem of Zero-Trust drift due to non-deterministic Agentic AI clients causing separation between user's (resource owner's) intent and client application's actions. Traditional OAuth 2.0 assumes that client applications faithfully represent user intent when requesting authorization. This assumption breaks down when autonomous AI agents dynamically generate workflows, create sub-agents, and make authorization decisions without continuous human oversight. We term this the "intent-execution separation problem." Agentic JWT introduces three mechanisms to address this problem: (1) cryptographic agent identity through agent checksums (based on agent's system prompts, tools and configurations), (2) workflow-aware token binding that links user intent to agent execution, and (3) a new OAuth 2.0 grant type (agent_checksum) for secure token issuance, (4) a flavor of PoP (Proof-of-Possession) at the level of an agentic identity to prevent token replays by other agents in the same multi- agent process. This specification enables Zero-Trust security principles in multi- agent systems while maintaining backward compatibility with existing OAuth 2.0 infrastructure. The security analysis and experimental validation are described in the companion research paper. |
| | Network-Infrastructure Hiding Protocol |
| |
|
The Network-Infrastructure Hiding Protocol (NHP) is a cryptography- based session-layer protocol designed to operationalize Zero Trust principles by concealing protected network resources from unauthorized entities. NHP enforces authentication-before-connect access control, rendering IP addresses, ports, and domain names invisible to unauthorized users. This document defines the protocol architecture, cryptographic framework, message formats, and workflow to enable independent implementation of NHP. It represents the third generation of network hiding technology—evolving from first- generation port knocking to second-generation Single-Packet Authorization (SPA) and now to NHP with advanced asymmetric cryptography, mutual authentication, and scalability for modern threats. This specification also provides guidance for integration with Software-Defined Perimeter (SDP), DNS, FIDO, and Zero Trust policy engines. |
| | The Cosmos Protocol Specification (Trust-Native Semantic Protocol) |
| |
|
The Cosmos Protocol (Trust-Native Semantic Protocol) defines a badge- based identity and communication system intended for deployments that prefer not to rely on external consensus or blockchain infrastructure. Cosmos supports trust-native communication and decentralized identity management through cryptographically signed badges that operate without mandatory external trust systems. The protocol also supports passwordless authentication flows using badge- based credentials and biometric authenticators, reducing reliance on traditional password mechanisms. The Cosmos Protocol introduces several foundational innovations that together form an integrated identity-native communication substrate. These include: (1) Badge-Based Identity -- cryptographically signed, capability-bearing identifiers designed to operate without requiring blockchain or distributed ledger infrastructure, while allowing deployments to integrate such systems if desired; (2) Trust Scoring -- reputation-anchored trust models (domain-bound for DNS networks, star-bound for Cosmos-native networks) that enable cross-star capability granting and trust-based authorization without requiring new badges; (3) Lumen Encryption -- uses post-quantum candidate cryptographic primitives (see [RFC-XXXX-Lumen]), badge-native encryption designed to support forward secrecy; (4) Echo Grammar -- semantic message structures that provide intent clarity, UI hints, and agent compatibility; (5) Capsule System -- universal, encrypted containers for communication and storage; (6) Slipstream Transport (TNTP) -- a trust-native transport protocol with badge-based sessions, intent-aware routing, and the ability to operate without blockchain or external consensus dependencies; (7) Ramp and SDFF Serialization -- deterministic text and binary formats that provide canonical structure for all Cosmos data; (8) Profile System -- portable, domain-scoped user profiles with badge-based access control; and (9) Productivity Protocols -- standardized scheduling, contacts, and calendaring protocols (Comet, Nebula, Nova) that provide a badge-native model that can serve as an alternative to multiple legacy standards. Cosmos badges are Ramp (Slope Data Format, SDF) documents with optional DID compatibility, allowing integration with existing decentralized identity systems while preserving the protocol's self- contained architecture within Cosmos deployments. The badge system addresses key limitations in current identity approaches, including the lack of enterprise-grade lifecycle management, star-bound trust establishment, and the ability to operate independently of external infrastructure in constrained or disconnected environments. The protocol provides a viable alternative to complex identity stacks while maintaining interoperability with existing standards, making it suitable for both greenfield deployments and integration with existing systems. |