| |
|
| |
| | 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. |
| | 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. |
| | 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. |
| | Packed CBOR |
| |
| | draft-ietf-cbor-packed-18.txt |
| | Date: |
07/01/2026 |
| | Authors: |
Carsten Bormann, Mikolai Guetschow |
| | Working Group: |
Concise Binary Object Representation Maintenance and Extensions (cbor) |
|
The Concise Binary Object Representation (CBOR, RFC 8949 == STD 94) 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. CBOR does not provide any forms of data compression. CBOR data items, in particular when generated from legacy data models, often allow considerable gains in compactness when applying data compression. While traditional data compression techniques such as DEFLATE (RFC 1951) can work well for CBOR encoded data items, their disadvantage is that the recipient needs to decompress the compressed form before it can make use of the data. This specification describes Packed CBOR, a set of CBOR tags and simple values that enable a simple transformation of an original CBOR data item into a Packed CBOR data item that is almost as easy to consume as the original CBOR data item. A separate decompression step is therefore often not required at the recipient. // (This cref will be removed by the RFC editor:) The present // revision -18 is a work-in-progress release in preparation for // another cbor-packed side meeting. The wording of the present // revision continues to make use of the tunables A/B/C to be set to // specific numbers before completing the Packed CBOR specification; // not all the examples may fully align yet. Specifically, the new // text about using the reference data item allocations for other // mechanisms than the cbor-packed one defined here should enable us // to revert to A=16. |
| | 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. |
| | DNS IPv6 Transport Operational Guidelines |
| |
|
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 when both native and IPv4-embedded IPv6 addresses are available. This document obsoletes RFC 3901. |
| | 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). |
| | 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. |
| | Adding an Uncacheable File Data Attribute to NFSv4.2 |
| |
|
The Network File System version 4.2 (NFSv4.2) allows a client to cache data for file objects. Applications on some clients can control the caching of data, but there is no way to achieve this at a system level. This document introduces a new uncacheable file data attribute for NFSv4.2. Files marked as uncacheable file data SHOULD NOT have their data stored in client-side caches. This document extends NFSv4.2 (see RFC7862). |
| | 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]. |
| | MoQ qlog event definitions |
| |
|
This document defines a qlog event schema containing concrete events for MoQ. |
| | 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]. |
| | 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. |
| | 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 |
| | Fast Network Notifications Problem Statement |
| |
| | draft-dong-fantel-problem-statement-03.txt |
| | Date: |
07/01/2026 |
| | Authors: |
Jie Dong, Mike McBride, Francois Clad, Zhaohui Zhang, Yongqing Zhu, Xiaohu Xu, Rui Zhuang, Ran Pang, Hao Lu, Yadong Liu, Luis Contreras, DURMUS Mehmet, Reshad Rahman |
| | Working Group: |
Individual Submissions (none) |
|
Modern networks require adaptive traffic manipulation including Traffic Engineering (TE), load balancing, flow control, and protection, to support high-throughput, low-latency, and lossless applications such as Artificial Intelligence (AI) /Machine Learning (ML) training and real-time services. A good and timely understanding of network operational status, such as congestion and failures, can help to improve network utilization, enable the selection of paths with reduced latency, and enable faster response to critical events. This document describes the existing problems and why a new set of fast network notification solutions are needed. |
| | 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. |
| | Available Session Recovery Protocol |
| |
| | draft-cmcc-asrp-03.txt |
| | Date: |
07/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 aims to optimize high-availability network cluster architectures, providing a superior cluster high-availability solution for stateful network services such as load balancing and Network Address Translation (NAT). ASRP defines the procedures for session backup and recovery, along with the message formats used in interactions, enabling efficient and streamlined session state management. Unlike traditional high-availability technologies that back up session states within the cluster, the core innovation of ASRP lies in distributing state information to clients or servers. This approach offers multiple advantages, significantly enhancing the cluster's elastic scaling capability; supporting rapid recovery from single-point or even multi-point failures; reducing resource redundancy by eliminating centralized backup nodes; and substantially simplifying cluster implementation complexity. The ASRP protocol provides network clusters with ultimate elastic scalability, facilitating the implementation and deployment of large- scale elastic network clusters. |
| | 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. |
| | OAuth 2.0 RAR Metadata and Error Signaling |
| |
|
OAuth 2.0 Rich Authorization Requests (RAR), as defined in [RFC9396], enables clients to request fine-grained authorization 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 structure for advertising authorization details type documentation and JSON Schema [JSON.Schema] definitions via OAuth Authorization Server Metadata [RFC8414] and OAuth Resource Server Metadata [RFC9728]. In addition, this document defines a new OAuth error code, insufficient_authorization_details, enabling resource servers to return actionable authorization details objects to clients. |
| | 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. |
| | 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 hierarchical component 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. |
| | 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. |
| | 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. |
| | 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, so there is a benefit and little cost in documenting a file format to use for these key pairs, similar to how RFC 7468 defines other PEM file formats. |
| |
|
| |
| | 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. |
| | Media Access Control (MAC) Addresses in X.509 Certificates |
| |
| | draft-ietf-lamps-macaddress-on-02.txt |
| | Date: |
06/01/2026 |
| | Authors: |
Russ Housley, Corey Bonnell, Joe Mandel, Tomofumi Okubo |
| | Working Group: |
Limited Additional Mechanisms for PKIX and SMIME (lamps) |
|
This document defines a new otherName for inclusion in the X.509 Subject Alternative Name (SAN) and Issuer Alternative Name (IAN) extensions to carry an IEEE Media Access Control (MAC) address. The new name form makes it possible to bind a layer-2 interface identifier to a public key certificate. Additionally, this document defines how constraints on this name form can be encoded and processed in the X.509 Name Constraints extension. |
| | 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. |
| | 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. |
| | Transmission of IP Packets over Overlay Multilink Network (OMNI) Interfaces |
| |
|
Mobile nodes that operate in air/land/sea/space domains (e.g., aircraft of various configurations, terrestrial vehicles, seagoing vessels, space systems, enterprise wireless devices, pedestrians with cell phones, etc.) configure mobile routers to connect end user network peers with Internetwork correspondents over wireless and/or wired-line data links. This document presents a multilink virtual interface specification that supports mobile node coordination with a network-based mobility service, fixed node correspondents and/or other mobile node peers. The virtual interface provides an adaptation layer service that supports secure global mobile Internetworking. This document specifies the transmission of IP packets over Overlay Multilink Network (OMNI) Interfaces. |
| | 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. |
| | Using BMP over QUIC connection |
| |
|
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. |
| | 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. |
| | Secure Resource Layer (SRL) Core |
| |
|
This document defines the Secure Resource Layer (SRL), a global trust layer that verifies digital resources before they are accessed. SRL introduces governance, verification, and revocation mechanisms that complement existing URL and QR code systems. |
| | 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. |
| | TCP Provenance Identifier 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. |
| | 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 VC, CBOR Web Token, and ISO mdoc. It also defines an extension point and a registry for future status mechanisms. |
| | Post-Quantum Cryptography in OpenPGP |
| |
| | draft-ietf-openpgp-pqc-16.txt |
| | Date: |
06/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. |
| | Guidelines for Characterizing "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 future IETF work. This document updates RFC6291 by adding to the guidelines for the use of the term "OAM". It does not modify any other part of RFC6291. |
| | 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). |
| | PQ/T Hybrid Key Exchange with ML-KEM in SSH |
| |
|
This document defines Post-Quantum Traditional (PQ/T) Hybrid key exchange methods based on the quantum-resistant the Module-Lattice- Based Key-Encapsulation Mechanism (ML-KEM) standard and traditional Elliptic-curve Diffie–Hellman (ECDH) key exchange schemes. These methods are defined for use in the SSH Transport Layer Protocol. |
| |
|
| |
| | 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). |
| | LISP Traffic Engineering |
| |
| | draft-ietf-lisp-te-23.txt |
| | Date: |
05/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 RLOC 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. |
| | 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. |
| | Use of Composite ML-DSA in TLS 1.3 |
| |
|
Compositing the post-quantum ML-DSA signature with traditional signature algorithms provides protection against potential breaks or critical bugs in ML-DSA or the ML-DSA implementation. This document specifies how such a composite signature can be formed using ML-DSA with RSA-PKCS#1 v1.5, RSA-PSS, ECDSA, Ed25519, and Ed448 to provide authentication in TLS 1.3. |
| | 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. |
| | 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. |
| | HMTFTP: HMAC-Derived TFTP with Optional AEAD Protection (v0.2) |
| |
|
HMTFTP is a lightweight UDP file transfer protocol that preserves the simplicity of TFTP (block-and-ACK) while adding a structured TLV extension mechanism and an optional authenticated-encryption mode. When negotiated, DATA payloads are protected with AEAD AES-256-GCM and keys are derived with HKDF-SHA-256 from a pre-shared key (PSK). HMTFTP uses UDP port TBD by default (requested: 6369; configurable). |
| | 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. |
| | Adding an Atomic SWAP Operation to NFSv4.2 |
| |
|
The Network File System version 4.2 (NFSv4.2) does not provide support for the atomic update of data. This document introduces a new SWAP operation which provides for such atomic updates. This document extends NFSv4.2 (see RFC7862). |
| | 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. |
| | 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. |
| | 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. |
| | 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. |
| | 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. |
| | Consideration of Applying Zero Trust Philosophy in Network Infrastructure |
| |
| | draft-li-zt-consideration-01.txt |
| | Date: |
04/01/2026 |
| | Authors: |
Xueting Li, Aijun Wang, iqjie@mail.ustc.edu.cn, Wenhao Lin |
| | 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. |
| | 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. |
| | 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. |
| |
|
| |
| | 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. |
| |
|
| |
| | Weighted Multi-Path Procedures for EVPN Multi-Homing |
| |
| | draft-ietf-bess-evpn-unequal-lb-30.txt |
| | Date: |
02/01/2026 |
| | Authors: |
Neeraj Malhotra, Ali Sajassi, Jorge Rabadan, John Drake, Avinash Lingala, Samir Thoria |
| | Working Group: |
BGP Enabled ServiceS (bess) |
|
Ethernet VPN (EVPN) provides all-active multi-homing for Customer Equipment (CE) devices connected to multiple Provider Edge (PE) devices, enabling equal cost load balancing of both bridged and routed traffic across the set of multi-homing PEs. However, existing procedures implicitly assume equal access bandwidth distribution among the multi-homing PEs, which can constrain link additions or removals and may not handle unequal PE-CE link bandwidth following link failures. This document specifies extensions to EVPN procedures to support weighted multi-pathing in proportion to PE-CE link bandwidth or operator-defined weights, thereby providing greater flexibility and resilience in multi-homing deployments. The extensions include signaling mechanisms to distribute traffic across egress PEs based on relative bandwidth or weight, and enhancements to Broadcast, Unknown Unicast, and Multicast (BUM) designated forwarder (DF) election to achieve weighted DF distribution across the multi- homing PE set. The document updates RFC 8584 and related EVPN DF election extensions (i.e. draft-ietf-bess-evpn-per-mcast-flow-df- election and draft-ietf-bess-evpn-pref-df) to enable weighted load balancing across different DF election algorithms. |
| | 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. |
| | SCION Data Plane |
| |
|
This document describes the data plane of the path-aware, inter- domain network architecture SCION (Scalability, Control, and Isolation On Next-generation networks). A fundamental characteristic of SCION is that it gives path control to SCION-capable endpoints. The SCION Control Plane is responsible for discovering these paths and making them available as path segments to the endpoints. The role of the SCION Data Plane is to combine these path segments into end-to-end paths, and forward data between endpoints according to the specified path. It fundamentally differs from an IP-based data plane in that it is _path-aware_ and interdomain forwarding directives are embedded in the packet header. This document provides a detailed specification of the SCION data packet format as well as the structure of the SCION header, including extension headers. It also describes the life of a SCION packet while traversing a SCION network, followed by a specification of the SCION path authorization mechanisms and the packet processing at routers. 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. |
| | 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. |