| |
|
| |
| | A Top-level Domain for Private Use |
| |
|
This document describes the "internal" top-level domain for use in private applications. |
| | DKIM Access Control and Differential Changes |
| |
|
This document specifies a DKIM (RFC 6376) extension that allows cryptographic verification of SMTP (RFC 5321) envelope data, of any DKIM signature along the message path, even beyond IMF (RFC 5322) message content changes. It therefore addresses security glitches, and introduces a new world of email solutions that move complexity away from lower network layers, where problems cannot be solved, complying with David Wheeler's fundamental theorem of software engineering, that "We can solve any problem by introducing an extra level of indirection". It updates DKIM to obsolete certain aspects that reality has proven to be superfluous, incomplete, or obsoleted. |
| | BGP Monitoring Protocol (BMP) Statistics Types Extension |
| |
|
[RFC7854], [RFC8671] and [I-D.ietf-grow-bmp-bgp-rib-stats] define different BGP Monitoring Protocol (BMP) statistics message types to observe events that occur on a monitored router. This document defines some additional statistics type to monitor BMP Adj-RIB-In, Loc-RIB and Adj-RIB-Out Routing Information Bases (RIBs). |
| | 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, 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. |
| | Post-quantum Hybrid ECDHE-SCloud+ Key Exchange for TLS 1.3 |
| |
|
This draft specifies how to run hybrid key exchange with ECDHE and Scloud+ in Transport Layer Security (TLS) protocol version 1.3 (TLS 1.3) to mitigate quantum threats. Scloud+ is an unstructured lattice based KEM with post-quantum security. This draft follows the post- quantum hybrid key exchange framework specified by [TLS.Hybrid], by concatenating the public keys and ciphertexts of ECDHE and Scloud+. [EDNOTE: ... ] |
| |
|
| |
| | CDNI Cache Control Metadata |
| |
|
This specification adds new Cache Control objects that complement the basic Cache Control Metadata object defined in RFC8006, providing content providers and upstream Content Delivery Networks (uCDNs) more fine-grained control over downstream CDN (dCDN) caching. Use cases include overriding or adjusting cache control headers from the Content Service Provider (CSP) source or origin, bypassing caching altogether, or altering cache keys with dynamically generated values. |
| | YANG-CBOR: Allocating SID ranges for PEN holders |
| |
|
YANG-CBOR (RFC 9254, "Encoding of Data Modeled with YANG in the Concise Binary Object Representation (CBOR)") defines YANG Schema Item iDentifiers (YANG SID), globally unique 63-bit unsigned integers used to identify YANG items. RFC 9595 ("YANG Schema Item iDentifier (YANG SID)") defines ways to allocate these SIDs on the basis of IANA registries. The present specification employs these SID allocation mechanisms to allocate ranges with 100 000 SIDs (representation size 64 bits) each for each of the holders of IANA-registered Private Enterprise Numbers (PENs) < 1 000 000, as well as ranges with 10 000 SIDs (representation size 32 bits) each for each of the holders of PENs < 100 000. // The present revision –06 is a resubmission of -05 with "Intended // Status: Standards Track", after IESG discussion pointed into this // direction. |
| | NETCONF over QUIC |
| |
| | draft-ietf-netconf-over-quic-06.txt |
| | Date: |
30/12/2025 |
| | 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 |
| | Recommendations for using Multiple IP Addresses in Benchmarking Tests |
| |
|
RFC 2544 has defined a benchmarking methodology for network interconnect devices. Its test frame format contained fixed IP addresses and fixed port numbers. RFC 4814 introduced pseudorandom port numbers but used a single source and destination IP address pair when testing with a single destination network. This limitation may cause an issue when the device under test uses the Receive-Side Scaling (RSS) mechanism in the packet processing flow. RSS has two implementations: the first only includes the IP addresses, whereas the second also includes the port numbers in the tuple used for hashing. Benchmarking tests that use a single IP address pair and RFC 4814 pseudorandom port numbers are biased against the first type of RSS implementation because traffic is not distributed among the processing elements. This document recommends the usage of pseudorandom IP addresses in a similar manner as RFC 4814 did with the port numbers. If accepted, this document updates all affected RFCs, including RFC 2544, RFC 4814, RFC 5180, RFC 8219. |
| | A Framework to Evaluate LLM Agents for Network Configuration |
| |
|
This document specifies an evaluation framework and related definitions for intent-driven network configuration using Large Language Model(LLM)-based agents. The framework combines an emulator-based interactive environment, a suite of representative tasks, and multi-dimensional metrics to assess reasoning quality, command accuracy, and functional correctness. The framework aims to enable reproducible, comprehensive, and fair comparisons among LLM- driven network configuration approaches. |
| | 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. |
| | Unified Transition Overlay (UTO): A Gateway-Based IPv4/IPv6 Translation Proxy |
| |
|
Unified Transition Overlay (UTO) is a gateway-based IPv4/IPv6 translation proxy that enables cross-version connectivity without requiring encapsulation, new protocol headers, or modifications to end-host stacks. UTO operates exclusively at transition gateways, which translate packet headers between IPv4 and IPv6 and update transport-layer checksums to preserve end-to-end correctness. By confining translation logic to gateways, UTO allows the underlying network to remain purely IPv4 or purely IPv6, facilitating incremental deployment within existing routing and forwarding infrastructures. UTO also supports incremental checksum update to reduce processing overhead for TCP and UDP traffic. |
| | SCTP Negotiation Acceleration Protocol |
| |
|
WebRTC Data Channels use the Stream Control Transmission Protocol (SCTP) over a Datagram Transport Layer Security (DTLS) association. The standard SCTP connection establishment requires a handshake that introduces latency. This document specifies a method to accelerate the datachannel establishment by embedding the SCTP initialization parameters within the Session Description Protocol (SDP) offer/answer exchange. This reduces the time required to open a data channel by up to two network round-trip times. |
| |
|
| |
| | Adaptive Subscription to YANG Notification |
| |
|
This document defines a YANG data model and associated mechanism to enable adaptive subscriptions to YANG notifications. The publisher can dynamically adjust the periodic update interval based on the evaluation of pre-configured conditions (e.g., thresholds or expressions). This allows for finer-grained telemetry by increasing update frequency when certain criteria are met, and reducing it otherwise. |
| | 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. |
| | 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 rfc881bis 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 define ACLs using an ACL model based on Windows ACLs. Support for other ACL models 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 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 od previous specifications, which dealt with the need for support for UNIX- oriented clients and server by leaving many important matters unspecified. [Consensus Needed (Items #117a, #119a)]: In this document, the relationship among the multiple ACL models for which potential support was mentioned has changed. A core set of functionality, shared in large part with that derived from a subset of the functionality provided by the now-withdrawn draft-POSIX ACLs is presented as the conceptual base of the feature set. Additional sets of features used to provide the functionality needed by clients expecting Windows semantics as part of the NFSv4 ACL model are considered as OPTIONAL extensions to that core. In addition it is made clear that support for the draft POSIX ACL model is not yet present in NFSv4.1, but that a subset of that functionality is available. 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. |
| | Extending ICMPv6 for SRv6-related Information Validation |
| |
|
This document introduces the mechanism to verify the data plane against the control plane and detect data plane failures in IPv6/SRv6 networks by extending ICMPv6 messages. |
| | EVPN Mpls Ping Extension |
| |
|
In an EVPN or any other VPN deployment, there is an urgent need to tailor the reachability checks of the client nodes via off-box tools which can be triggered from a remote Overlay end-point or a centralized controller. There is also a ease of operability needed when the knowledge known is partial or incomplete. This document aims to address the limitation in current standards for doing so and provides solution which can be made standards in future. As an additional requirement, in network border routers, there are liaison/ dummy VRFs created to leak routes from one network/fabric to another. There are scenarios wherein an explicit reachability check for these type of VRFs is not possible with existing mpls-ping mechanisms. This draft intends to address this as well. Few of missing pieces are equally applicable to the native lsp ping as well. |
| | Data Plane Failure Detection Mechanisms for EVPN over SRv6 |
| |
|
This document proposes extension for ICMPv6 to detect data plane failures for EVPN over SRv6. |
| | Bicone Source Address Validation |
| |
|
Source address validation (SAV) aims to avoid improper blocking of legitimate traffic while maintaining directionality. Existing SAV mechanisms commonly rely on ingress allowlist filters on interfaces facing customer or lateral peer Autonomous Systems (ASes), which can result in improper blocking when the allowlist is incomplete. This document analyzes this issue and describes an alternative ingress SAV approach based on a blocklist of prefixes exclusively associated with the provider cone. Network operators may select either approach based on their operational context. |
| | Onions Problem Statement |
| |
|
YANG-based service APIs are widely used to expose network and service abstractions to external systems such as controllers, orchestration platforms, and OSS/BSS applications. Despite the availability of numerous YANG data models and YANG-to-API tools, operators continue to face significant challenges in operationalizing these APIs in a consistent, scalable, and interoperable manner. APIs derived from similar YANG models often differ in semantics, lifecycle behavior, observability, and consumption patterns, complicating automation and cross-vendor integration. This document describes the problem space associated with operationalizing YANG-based service APIs, drawing on operator experience, IAB workshop findings, and IETF applicability studies to highlight gaps in current practices and motivate requirements for improving API predictability and operational effectiveness, without defining specific solutions, protocols, or tools. |
| | AES-CMAC for COSE |
| |
|
This document registers COSE algorithm code points for using the Advanced Encryption Standard (AES) in Cipher-based Message Authentication Code (CMAC) mode for use in CBOR Object Signing and Encryption (COSE) messages. The CMAC mode of operation is an alternative to AES-CBC-MAC which is approved by US NIST FIPS 140. |
| | Bundle Protocol (BP) Manifest Block |
| |
|
This document defines an extension block type for Bundle Protocol version 7 to capture discretionary summary data about the state of a Bundle at the time the extension block is added. This Manifest structure is a general purpose container for information about other blocks, and can be used as a piece-part of a larger security operation. |
| | 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. |
| | 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. |
| | SCITT Reference APIs |
| |
| | draft-ietf-scitt-scrapi-06.txt |
| | Date: |
29/12/2025 |
| | Authors: |
Henk Birkholz, Jon Geater |
| | Working Group: |
Supply Chain Integrity, Transparency, and Trust (scitt) |
|
This document describes a REST API that supports the normative requirements of the SCITT Architecture. Optional key discovery and query interfaces are provided to support interoperability with X.509 Certificates, alternative methods commonly used to support public key discovery and Artifact Repositories. |
| | TEEP Usecase for Confidential Computing in Network |
| |
|
Confidential computing is the protection of data in use by performing computation in a hardware-based Trusted Execution Environment. Confidential computing could provide integrity and confidentiality for users who want to run applications and process data in that environment. When confidential computing is used in scenarios which need network to provision user data and applications, TEEP architecture and protocol could be used. This usecase illustrates the steps of how to deploy applications, containers, VMs and data in different confidential computing hardware in network. This document is a use case and extension of TEEP architecture and could provide guidance for cloud computing, MEC (Multi-access Computing) and other scenarios to use confidential computing in network. |
| | Workload Identifier |
| |
|
This document defines a canonical identifier for workloads, referred to as the Workload Identifier. A Workload Identifier is a URI that uniquely identifies a workload within the context of a specific trust domain. This identifier can be embedded in digital credentials, including X.509 certificates and security tokens, to support authentication, authorization, and policy enforcement across diverse systems. The Workload Identifier format ensures interoperability, facilitates secure identity federation, and enables consistent identity semantics. |
| |
|
| |
| | Flowspec Indirection-id Redirect for SRv6 |
| |
|
This document defines extensions to "FlowSpec Redirect to indirection-id Extended Community" for SRv6. This extended community can trigger advanced redirection capabilities to flowspec clients for SRv6. When activated, this flowspec extended community is used by a flowspec client to retrieve the corresponding next-hop and encoding information within a localised indirection-id mapping table. The functionality detailed in this document allows a network controller to decouple the BGP flowspec redirection instruction from the operation of the available paths. |
| | The MASQUE Proxy |
| |
|
MASQUE (Multiplexed Application Substrate over QUIC Encryption) is a set of protocols and extensions to HTTP that allow proxying all kinds of Internet traffic over HTTP. This document defines the concept of a "MASQUE Proxy", an Internet-accessible node that can relay client traffic in order to provide privacy guarantees. |
| | YANG Data Model for supporting multipath IGMP/MLD proxies |
| |
|
The ability to support multiple upstream interfaces in IGMP/MLD proxies necessitates configuring different upstream interfaces for specific multicast channels or sessions. [RFC9398] defined YANG Data Model for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Proxy Devices. Building on that foundation, this document proposes an augmentation of thet model for the support of multiple upstream interfaces in IGMP/MLD proxies. |
| | BGP Extensions for Service Routing of Mobile Core Networks |
| |
|
This document describes a new route propagation and service discovery mechanism by proposing BGP extensions for mobile core network service routing. The proposed solution introduces a Service Route Address Family, hierarchical Network Identifier allocation, and path-aware routing mechanisms that enable scalable inter-domain service discovery while preserving compatibility with current 3GPP standards. These extensions provide the foundation for efficient service propagation, route aggregation, and loop-free routing in large-scale distributed mobile core deployments. |
| | SSH Agent Protocol |
| |
|
This document specifies a key agent protocol for use in the Secure Shell (SSH) protocol. Note This note is to be removed before publishing as an RFC. In the IANA considerations section, please replace "thisRFC" with "RFC" and the assigned number, when known. |
| |
|
| |
| | Computing-Aware Traffic Steering (CATS) Problem Statement,Use Cases,and Requirements |
| |
|
Distributed computing is a computing pattern that service providers can follow and use to achieve better service response time and optimized energy consumption. In such a distributed computing environment, compute intensive and delay sensitive services can be improved by utilizing computing resources hosted in various computing facilities. Ideally, compute services are balanced across servers and network resources to enable higher throughput and lower response time. To achieve this, the choice of server and network resources should consider metrics that are oriented towards compute capabilities and resources instead of simply dispatching the service requests in a static way or optimizing solely on connectivity metrics. The process of selecting servers or service instance locations, and of directing traffic to them on chosen network resources is called "Computing-Aware Traffic Steering" (CATS). This document provides the problem statement and the typical scenarios for CATS, which shows the necessity of considering more factors when steering traffic to the appropriate computing resource to better meet the customer's expectations. |
| | Application-Responsive Network Framework |
| |
|
With the deployment of increasingly advanced technologies on a large scale, such as SRv6 and network slicing, there is a growing need to expose these new capabilities to applications. The current practice involves using ACLs to classify packets and then map the traffic onto appropriate network resources. This approach results in the application being passively perceived by the network, rather than the application actively interfacing with the network. Furthermore, changes in application characteristics necessitate triggering network configuration adjustments, making it challenging to deploy at scale. The document proposes a new framework called Application Responsive Network (ARN), by encapsulating more network functions into ARN ID, thus it opens up interfaces to applications. The vision is to enable applications to access network resources like they access an operating system. |
| | Source Address Validation Using Source Origin Authorizations (SOAs) |
| |
|
Given that an AS collaboration scheme for inter-domain source address validation requires an information-sharing platform, this document proposes a new approach by leveraging Resource Public Key Infrastructure (RPKI) architecture to validate the authenticity of source address of packets. Source Origin Authorization (SOA) is a newly defined cryptographically signed object; it provides a means of recording information about the last Autonomous System (AS) traversed by packets before reaching a specific AS. When validated, the eContent of an SOA object confirms that the holder of the listed AS Number (ASN) has authorized the specified pre-ASes. This enables other ASes to collaboratively filter spoofed traffic, enhancing global Internet security by mitigating source address spoofing and DDoS attacks. |
| | A Profile for Source Origin Authorizations(SOAs) |
| |
|
This document defines Source Origin Authorization (SOA), a new object in the Resource Public Key Infrastructure (RPKI), designed to extend RPKI's capabilities to securing the data plane. An SOA object is a digitally signed artifact that records information about the possible last-hop ASes traversed by packets before reaching a specific AS. By providing this information, the SOA enables other ASes to collaboratively filter traffic with spoofed source addresses claiming to originate from the IP space of the target AS, thereby enhancing global Internet security through mitigation of source address spoofing and DDoS attacks. |
| | Problem Statement: Interaction Continuity and Control for Internet of Everything Systems |
| |
|
Internet of Everything (IoE) deployments increasingly bind together devices, networks, cloud and edge compute, AI-assisted processing, and human participation within the same time-bounded operational interactions. When governance is externalized into multiple fragmented control contexts, the system must continuously propagate and reconcile identity, policy state, routing state, and compute placement decisions across those contexts, in real time. This document defines an architectural problem: as independently scaling dimensions multiply, coordination surfaces grow at multiplicative rates, making deterministic governance impractical. The draft enumerates requirements for interaction-scoped governance primitives that collapse fragmented control contexts. |
| | ACE-GF: A Generative Framework for Atomic Cryptographic Entities |
| |
|
This document specifies the Atomic Cryptographic Entity Generative Framework (ACE-GF), a cryptographic construction for deriving and reconstructing stable cryptographic identities from user-held credentials without requiring persistent storage of a master secret. ACE-GF addresses a structural limitation of existing deterministic key-derivation and identity systems, which rely on long-lived root secrets and rigid derivation hierarchies. By separating identity reconstruction from long-term secret storage, ACE-GF enables stateless identity recovery, credential rekeying, and context- isolated derivation across multiple cryptographic algorithms. The framework is designed to be application-agnostic and may be applied to diverse environments such as authentication systems, distributed identities, secure key management, and cryptographic wallets. This document defines the core construction, security properties, and interoperability considerations of ACE-GF, while application-specific profiles are defined separately. |
| | Event and Webhook Delivery Semantics |
| |
|
Event- and webhook-based integrations are a common application-layer mechanism for interoperability across Internet services, yet they lack a shared delivery semantics contract. Existing implementations vary widely in retry behavior, acknowledgment signaling, failure classification, idempotency identifiers, and replay handling, resulting in fragile integrations and ambiguous operational expectations. This document defines a minimal, application-layer delivery semantics profile for event and webhook delivery over existing transports, most commonly HTTP. |
| |
|
| |
| | Instance Information for SDF |
| |
|
This document discusses types of Instance Information to be used in conjunction with the Semantic Definition Format (SDF) for Data and Interactions of Things (draft-ietf-asdf-sdf) and will ultimately define Representation Formats for them as well as ways to use SDF Models to describe them. // The present revision is the first one after the adoption by the // ASDF Working Group. Content-wise, it is unchanged compared to the // preceding individual draft revision. |
| | Group Object Security for Constrained RESTful Environments (Group OSCORE) |
| |
| | draft-ietf-core-oscore-groupcomm-28.txt |
| | Date: |
23/12/2025 |
| | Authors: |
Marco Tiloca, Goeran Selander, Francesca Palombini, John Mattsson, Rikard Hoeglund |
| | Working Group: |
Constrained RESTful Environments (core) |
|
This document defines the security protocol Group Object Security for Constrained RESTful Environments (Group OSCORE), providing end-to-end security of messages exchanged with the Constrained Application Protocol (CoAP) between members of a group, e.g., sent over IP multicast. In particular, the described protocol defines how OSCORE is used in a group communication setting to provide source authentication for CoAP group requests, sent by a client to multiple servers, and for protection of the corresponding CoAP responses. Group OSCORE also defines a pairwise mode where each member of the group can efficiently derive a symmetric pairwise key with each other member of the group for pairwise OSCORE communication. Group OSCORE can be used between endpoints communicating with CoAP or CoAP- mappable HTTP. |
| | VPN Prefix Outbound Route Filter (VPN Prefix ORF) for BGP-4 |
| |
|
This draft defines a new type of Outbound Route Filter (ORF), known as the Virtual Private Network (VPN) Prefix ORF. The VPN Prefix ORF mechanism is applicable when VPN routes from different Virtual Routing and Forwarding (VRF) instances are exchanged through a single shared Border Gateway Protocol (BGP) session.The purpose of VPN Prefix ORF mechanism is to control the overload of VPN routes based on RT. With this mechanism, the overload can be limited within the minimum range. |
| | MPLS Network Actions for Network Resource Partition Selector |
| |
|
An IETF Network Slice service provides connectivity coupled with a set of network resource commitments and is expressed in terms of one or more connectivity constructs. A Network Resource Partition (NRP) is a collection of resources identified in the underlay network to support IETF Network Slice services. A Slice-Flow Aggregate refers to the set of traffic streams from one or more connectivity constructs belonging to one or more IETF Network Slices that are mapped to a specific NRP and provide the same forwarding treatment. The packets associated with a Slice-Flow Aggregate may carry a marking in the packet's network layer header to identify this association and this marking is referred to as NRP Selector. The NRP Selector is used to map the packet to the associated NRP and provide the corresponding forwarding treatment to the packet. MPLS Network Actions (MNA) technologies are used to indicate actions for Label Switched Paths (LSPs) and/or MPLS packets and to transfer data needed for these actions. This document discusses options for using MPLS Network Actions (MNAs) to carry the NRP Selector in MPLS packets. |
| | Route Target Constraint for BGP Flow Spec(BGP Flow) and BGP Segment Routing Policies(BGP SR-Policy) |
| |
|
This document specifies an extension to the application scenarios of Route Target Constraints (RTC). By using the Global Administrator field of the IPv4 Address Specific Extended Community to identify a network node and exchanging BGP Route-Target routes, a BGP speaker can generate an egress policy for filtering routing updates associated with specific network nodes,which could implement precise control and distribution of services such as BGP Flow Specification and BGP Segment Routing Policies. |
| | YANG Configuration Templates |
| |
|
NETCONF and RESTCONF protocols provide programmatic interfaces for accessing configuration data modeled by YANG. This document defines the use of a YANG-based configuration template mechanism whereby configuration data can be defined in one or more templates and applied repeatedly. This avoids the redundant definition of identical configuration and ensures the consistency of it, thus allowing devices to be managed more conveniently and efficiently. |
| | Modbus Serial Link Communication Security Protocol Reference Specification and implementation guide |
| |
|
The Modbus TCP protocol has adopted TLS-based security standards; however, Modbus serial communication over EIA/TIA-485 multi-point systems, commonly used in 2-wire or 4-wire configurations, lacks standardized security mechanisms. These systems support cable lengths exceeding 1000m at baud rates up to 9600 bit/s with AWG26 or thicker cables, while Category 5 cables can reach up to 600m. As an application layer protocol, despite its widespread application, the absence of encryption and authentication in Modbus protocol via serial links exposes plaintext data to risks such as MIM interception, modification under attacks such as side-channel analysis etc., particularly in long-distance or bridged network scenarios. Enhancing Modbus serial link security requires introducing proper encryption and authentication methods tailored to varied deployment environments onsidering the characteristics of serial links. A proposed security standard guide outlines lightweight encryption and authentication mechanisms to improve confidentiality and integrity while maintaining compatibility with existing Modbus devices, offering a practical upgrade path for secure industrial control systems. |
| | MTA Hooks: An HTTP-Based Mail Processing Protocol |
| |
|
This document specifies MTA Hooks, an HTTP-based protocol enabling Mail Transfer Agents (MTAs) to delegate message processing decisions to external services. MTA Hooks provides a modern alternative to legacy mail filtering protocols by leveraging ubiquitous HTTP infrastructure, supporting both JSON and CBOR serialization, and offering fine-grained capability negotiation. The protocol supports both inbound message reception and outbound message delivery scenarios, allowing external scanners to inspect messages, modify content, and influence routing decisions at various stages of mail processing. |
| | Mitigating DoS attacks in IPv6 by clarifying the number of occurrences of Extension Headers |
| |
|
This document updates RFC 8200 by specifying normative requirements on the number of occurrences of IPv6 Extension Headers. Operational experience has demonstrated that permitting multiple occurrences of the same Extension Header can create parsing ambiguity, increase attack surface, and complicate packet processing in general. This is especially true for both the Hop-by-Hop Options Header and the Destination Options Header, which can contain a number of options. This document restricts IPv6 packets to carry at most one instance of each Extension Header, with the exception of the Destination Options Header, which is permitted to appear twice as specified in RFC 8200. |
| | Export of MPLS Network Action (MNA) Information in IPFIX |
| |
|
This document introduces new IPFIX IEs for exporting MPLS Network Action (MNA) information in IPFIX, covering both in-stack and post- stack MNAs. |
| | Minimizing ANY-Query Responses at Recursive Resolvers |
| |
|
The " ANY " query type in DNS requests the server to return all available resource records for a given domain name. While RFC 8482 defines a mechanism for authoritative servers to minimize ANY responses, a recursive resolver may still generate an ANY query response directly from its cache, thereby bypassing the authoritative side's ANY query minimization strategy. This document provides supplementary guidance for recursive resolvers on processing ANY queries to mitigate potential operational and security issues. |
| | Delayed Transmission and Store-and-forward in QUIC |
| |
|
This document describes two mechanisms in QUIC. The first is the delayed transmission, in which the sender would negotiate a proper time to send traffic to the receiver. The second is the store-and- forward, in which the sender would send the traffic to another place that supports temporary data store and data upload instead of the sender. |
| | Host Extensions for IP Multicasting and "Any Source Multicasting" (ASM) IP service |
| |
|
This memo specifies the extensions required of a host implementation of the Internet Protocol (IP) to support IP multicast with the IP service interface "Any Source Multicast" (ASM). This specification applies to both versions 4 and 6 of the Internet Protocol. Distribution of this memo is unlimited. This document replaces RFC1112 for everything but its specification of the IGMP version 1 protocol. |
| | Protocol Numbers for SCHC |
| |
| | draft-ietf-schc-protocol-numbers-06.txt |
| | Date: |
23/12/2025 |
| | Authors: |
Robert Moskowitz, Pascal Thubert, Carles Gomez, Ana Minaburo, Marc Blanchet |
| | Working Group: |
Static Context Header Compression (schc) |
|
This document requests an Internet Protocol Number, an Ethertype assignment, a CCSDS (Consultative Committee for Space Data Systems) Encapsulation Number, and well known ports for SCHC. The SCHC architecture, the SCHC instance establishment, and the SCHC compression/decompression processes are simplified when SCHC is easily recognised. Well-known protocol and port numbers are needed. The Internet Protocol Number request is so that SCHC can be used for IP independent of other transports such as UDP and ESP. The Ethertype and the CCSDS Encapsulation Number are to support generic use of native SCHC over any IEEE 802 technology and CCSDS link layer technology, respectively, for IP and non-IP protocols. |
| |
|
| |
| | Constrained Application Protocol (CoAP): Corrections and Clarifications |
| |
|
RFC 7252 defines the Constrained Application Protocol (CoAP), along with a number of additional specifications, including RFC 7641, RFC 7959, RFC 8132, and RFC 8323. RFC 6690 defines the link format that is used in CoAP self-description documents. Some parts of the specification may be unclear or even contain errors that may lead to misinterpretations that may impair interoperability between different implementations. The present document provides corrections, additions, and clarifications to the RFCs cited; this document thus updates these RFCs. In addition, other clarifications related to the use of CoAP in other specifications, including RFC 7390 and RFC 8075, are also provided. |
| | Updates to SMTP related IANA registries |
| |
|
While EMAILCORE working group was working on update to SMTP specification, it became clear that existing entries in SMTP related registries are missing information or contain stale information and need to be updated. This document updates such entries. |
| | BGP BFD Strict-Mode |
| |
|
This document specifies extensions to RFC4271 BGP-4 that enable a BGP speaker to negotiate additional Bidirectional Forwarding Detection (BFD) extensions using a BGP capability. This BFD Strict-Mode Capability enables a BGP speaker to prevent a BGP session from being established until a BFD session is established. This is referred to as BFD "strict-mode". |
| | A Base YANG Data Model for Network Inventory |
| |
|
This document defines a base YANG data model for reporting network inventory. The scope of this base model is set to be application- and technology-agnostic. The base data model can be augmented with application- and technology-specific details. |
| | BGP Logical Link Discovery Protocol (LLDP) Peer Discovery |
| |
|
Link Layer Discovery Protocol (LLDP) or IEEE Std 802.1AB is implemented in networking equipment from many vendors. It is natural for IETF protocols to avail this protocol for simple discovery tasks. This document describes how BGP would use LLDP to discover directly connected and 2-hop peers when peering is based on loopback addresses. |
| | BGP Flow-Spec Traffic Compress Action |
| |
|
Flow-spec is an extension to BGP that allows for the dissemination of traffic flow specification rules and traffic filtering actions. This document specifies a new traffic filtering action to support compressing traffic. |
| | Latency Guarantee with Stateless Fair Queuing |
| |
|
This document specifies the framework and the operational procedure for deterministic networking with a set of rate based work conserving packet schedulers. The framework guarantees end-to-end (E2E) latency bounds to flows. The schedulers in core nodes do not need to maintain flow states. Instead, the entrance node of a flow marks an ideal service completion time according to a fluid model, called Finish Time (FT), of a packet in the packet header. The subsequent core nodes update FT by adding delay factors, which are functions of the flow and the nodes. The packets in the queue of the scheduler are served in the ascending order of FT. This mechanism is called the stateless fair queuing. The result is that flows are isolated from each other almost perfectly. The latency bound of a flow depends only on the flow's intrinsic parameters such as the maximum burst size and the service rate, except the link capacities and the maximum packet length among other flows sharing each output link with the flow. |
| | Explicit Congestion Notification Using MPLS Network Actions |
| |
|
It has been broadly demonstrated that user experience improvements for time-critical applications have not increased at the same pace as network throughput (i.e., the increased bandwidth does not result in a corresponding increase in the user experience). Optimizing network latency rather than throughput can lead to a significantly improved user experience for time-critical applications. Low Latency, Low Loss, and Scalable Throughput (L4S) technology, introduced in RFC 9330, uses Explicit Congestion Notification (ECN) bits by marking packets suffering potential congestion in the network. L4S operates as a congestion-control mechanism, using markers within the data packets to detect and promptly respond to congestion conditions. This feedback loop enables devices (e.g., endpoints such as client devices and server devices) to adjust data flow in real-time, preventing bottlenecks and ensuring smoother transmission. RFC 5129 describes a mechanism for supporting ECN in the Multiprotocol Label Switching (MPLS) data plane. That mechanism is based on the codepoints that take part in the Traffic Class (TC) field and, thus, prevent the use of TC field for traffic differentiation. This document defines how ECN can be supported in the MPLS data plane using the MPLS Network Actions technology. |
| | StealthFlow Protocol (SFP) |
| |
|
The StealthFlow Protocol (SFP) is a low-observability, stateless pre-authentication and transport armor mechanism designed to precede existing TLS or QUIC sessions. SFP aims to reduce handshake fingerprinting, limit asymmetric denial-of-service amplification, and minimize early plaintext metadata exposure, while preserving compatibility with the existing PKI and TLS ecosystems. SFP does not replace TLS or QUIC. Instead, it provides an optional single-round pre-filtering and authentication layer that enables servers to reject illegitimate traffic with minimal computational cost and minimal network observability. This document supersedes the prior informal specification known as draft-eli-z-protocol-00. |
| | DNS-Native AI Agent Naming and Resolution |
| |
|
This document specifies a DNS-native naming and resolution mechanism for AI agents. Building upon the DNS specification (RFC 1035) and leveraging Service Binding (SVCB) records (RFC 9460, RFC 9461), it defines how AI agents are identified using Fully Qualified Domain Names (FQDNs), how their identity and cryptographic keys are published via DNS TXT records, and how multi-version, multi-protocol service resolution is achieved using DNS SVCB records. The design philosophy emphasizes DNS as the authoritative source, protocol autonomy, and graceful degradation for legacy clients. When version is not explicitly specified, the highest priority (default) version is provided. This approach maximizes reuse of existing Internet infrastructure while enabling the rapid evolution of AI agent ecosystems. |
| | Registries for Credential Exchange |
| |
|
This specification defines IANA registries for Fido Alliance Credential Exchange Format (CXF) credential types and extension identifiers. |
| | 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. |
| | Problem Statement of Zero Trust Deployment in Telecom Network Environments |
| |
|
Zero Trust, as a security paradigm, has achieved global practical consensus. However, its large-scale deployment in telecommunications network environments presents unique challenges. Operationally standards tailored to the specific requirements of telecom networks are needed. |
| | PCEP Operational Clarification |
| |
| | draft-ietf-pce-operational-02.txt |
| | Date: |
22/12/2025 |
| | Authors: |
Mike Koldychev, Siva Sivabalan, Shuping Peng, Diego Achaval, Hari Kotni, Andrew Stone |
| | Working Group: |
Path Computation Element (pce) |
|
This document clarifies certain operational behavior aspects of the PCEP protocol. The content of this document has been compiled based on several interop exercises. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Path Computation Element mailing list (pce@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/pce/. Source for this draft and an issue tracker can be found at https://github.com/ietf-wg-pce/draft-ietf-pce-operational. |
| | The RFCXML version 3 Vocabulary as Implemented |
| |
|
This is a tombstone for a document that described the RFCXML version 3 vocabulary as it was previously implemented in tools used by the RFC Production Center. There is no intention of publishing this Internet Draft as an RFC. See the introduction for more information about this tombstone. |
| | Applicability of Abstraction and Control of Traffic Engineered Networks (ACTN) to Packet Optical Integration (POI) |
| |
| | draft-ietf-teas-actn-poi-applicability-17.txt |
| | Date: |
22/12/2025 |
| | Authors: |
Fabio Peruzzini, Jean-Francois Bouquier, Italo Busi, Daniel King, Daniele Ceccarelli |
| | Working Group: |
Traffic Engineering Architecture and Signaling (teas) |
|
This document explores the applicability of the Abstraction and Control of TE Networks (ACTN) architecture to Packet Optical Integration (POI) within the context of IP/MPLS and optical internetworking. It examines the YANG data models defined by the IETF that enable an ACTN-based deployment architecture and highlights specific scenarios pertinent to Service Providers. Existing IETF protocols and data models are identified for each multi-technology scenario (packet over optical), particularly emphasising the Multi-Domain Service Coordinator to Provisioning Network Controller Interface (MPI) within the ACTN architecture |
| |
|
| |
| | SRv6 Egress Protection in Multi-homed scenario |
| |
|
This document describes a SRv6 egress node protection mechanism in multi-homed scenarios. |
| | 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. |
| | YANG Data Model for SR and SR TE Topologies on IPv6 Data Plane |
| |
|
This document defines a YANG data model for Segment Routing (SR) topology and Segment Routing (SR) Traffic Engineering (TE) topology, using IPv6 data plane. It provides the methods for representing and manipulating SR Topologies on IPv6 Data Plane, and can be used on a controller for the network-wide operations such as path computation. |
| | Distribute Service Metric by BGP |
| |
|
When calculating the path selection for service traffic, it is important to consider not only network metrics, but also the impact of service Metric. Therefore, it is necessary to transmit service Metric information from the service site to the user access site, in order to facilitate path selection for service traffic at the access router. This document describes an approach for using the BGP Control Plane to steer traffic based on a set of metrics that reflect the underlying network conditions and other service-specific state collected from available service locations. |
| | SRv6 Resource Programming with NRP flavor |
| |
|
This document introduces a new flavor type for SRv6 called "Flavor NRP". It associates the SRv6 End.X SID with a set of network resource partitions (referred to as NRP resources). By using the End.X SID with the NRP flavor type, SRv6 policies can provide programmability for network resources. |
| | YANG Data Model for SR Policy Group |
| |
|
This document defines YANG data models for Segment Routing (SR) Policy group that can be used for configuring, instantiating, and managing SR Policy groups. The model is generic and apply equally to the MPLS and SRv6 instantiations of SR policy groups. |
| | Segment Routing based Solution for Hierarchical IETF Network Slices |
| |
|
This document describes a Segment Routing based solution for two- level hierarchical IETF network slices. Level-1 network slice is realized by associating Flex-Algo with dedicated sub-interfaces, and level-2 network slice is realized by using SR Policy with additional NRP-ID on data plane. |
| | Certificate Update in TLS 1.3 |
| |
|
This document defines a mechanism that enables TLS 1.3 endpoints to update their certificates during the lifetime of a connection using Exported Authenticators. A new extension is introduced to negotiate support for certificate update at handshake time. When negotiated, either endpoint can provide a post-handshake authenticator containing an updated certificate, delivered via a new handshake message. This mechanism allows long-lived TLS connections to remain valid across certificate rotations without requiring session termination. |
| | OAuth 2.0 Resource Parameter in Access Token Response |
| |
|
This specification defines a new parameter resource to be returned in OAuth 2.0 access token responses. It enables clients to confirm that the issued token is valid for the intended resource. This mitigates ambiguity and certain classes of security vulnerabilities such as resource mix-up attacks, particularly in systems that use the Resource Indicators for OAuth 2.0 specification [RFC8707]. |
| | Applicability of A2A Protocol for Network Management Agents |
| |
|
The evolution of network management towards autonomic operation requires the deployment of AI agents at various hierarchical layers, including directly on network elements. This transformation shifts network devices from passively managed resources to autonomous entities capable of local decision-making and collaborative problem- solving. This document discusses the applicability of the Agent-to-Agent (A2A) Protocol to the network management plane, specifically for communication between Controller Agents (CAs) and Device Agents (DAs). This indicates that the inherent characteristics of Device Agents necessitate the adoption of the agent-to-agent communication paradigm. The document further explores generic workflows, deployment scenarios, and the relationship of A2A with existing network management protocols like NETCONF, RESTCONF, gNMI,and the Model Context Protocol (MCP). |
| | Framework for Multi-domain IPv6-only Underlay Network and IPv4-as-a-Service |
| |
|
For the IPv6 transition, IPv6-only is considered the final stage where only IPv6 protocol is used for transport while maintaining global reachability for both IPv6 and IPv4 services. This document introduces a framework for a multi-domain IPv6-only underlay network from the perspective of network operators. In particular, it proposes stateless address mapping as the basis for enabling IPv4 service data transmission in a multi-domain IPv6-only environment (i.e., IPv4-as-a-Service). It describes the methodology of stateless IPv4/IPv6 mapping, illustrates the behaviors of network devices, analyzes the options of IPv6 mapping prefix allocation, and discusses the security considerations. This framework is not intended to replace existing IPv6-only technologies, but rather to leverage or remain compatible with them. |
| |
|
| |
| | An sdfType for Links |
| |
| | draft-ietf-asdf-sdftype-link-01.txt |
| | Date: |
19/12/2025 |
| | Authors: |
Carsten Bormann, Ari Keranen |
| | Working Group: |
A Semantic Definition Format for Data and Interactions of Things (asdf) |
|
This document defines and registers an sdfType "link" for the Semantic Definition Format (SDF) for Data and Interactions of Things (draft-ietf-asdf-sdf). |
| | dry-run DNSSEC |
| |
|
This document describes a method called "dry-run DNSSEC" that allows for testing DNSSEC deployments without affecting the DNS service in case of DNSSEC errors. It accomplishes that by introducing new DS Type Digest Algorithms that when used in every record of a DS RRset, referred to as dry-run DS, signal to validating resolvers that dry- run DNSSEC is used for the zone. DNSSEC errors are then reported with DNS Error Reporting, but any bogus responses to clients are withheld. Instead, validating resolvers fallback from dry-run DNSSEC and provide the response that would have been answered without the presence of the dry-run DS. A further EDNS option is presented for clients to opt-in for dry-run DNSSEC errors and allow for end-to-end DNSSEC testing. |
| | JMAP Enhanced Result References |
| |
|
This document specifies an extension to the JSON Meta Application Protocol (JMAP) that enhances the result reference mechanism defined in [RFC8620]. The extension allows result references to be used in additional contexts beyond method call arguments, specifically within object properties during JMAP /set operations and within FilterCondition objects used in /query operations. Additionally, this specification extends result references to support JSON Path expressions ([RFC9535]) as an alternative to JSON Pointer ([RFC6901]), providing more expressive query capabilities for extracting values from previous method call results. These enhancements enable more efficient data reuse patterns across JMAP method calls, reducing the need for multiple round trips between client and server. |
| | JMAP Object Metadata |
| |
|
This document defines a new extension to the JSON Meta Application Protocol (JMAP) that introduces a standardized mechanism for managing metadata associated with JMAP objects. The JMAP Object Metadata extension allows clients and servers to store, retrieve, and synchronize arbitrary metadata and annotations on any JMAP data type in a consistent manner. It defines a generic annotation model as well as specific mappings for accessing IMAP metadata and WebDAV “dead properties” where applicable. This extension facilitates interoperability between JMAP and existing metadata frameworks while allowing vendor-specific extensions in a structured and discoverable way. |
| | IMAP UIDBATCHES Extension |
| |
|
The UIDBATCHES extension of the Internet Message Access Protocol (IMAP) allows clients to retrieve UID ranges that partition a mailbox's messages into equally sized batches. This enables clients to perform operations such as FETCH, SEARCH, and STORE on specific message batches, providing better control over resource usage and response sizes. The extension is particularly useful with the UIDONLY mode where sequence numbers are unavailable. |
| | 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. 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. |
| | Network File System (NFS) Version 4 Minor Version 1 Protocol |
| |
|
This document describes the Network File System (NFS) version 4 minor version 1, including features retained from the base protocol (NFS version 4 minor version 0, which is specified in RFC 7530) and protocol extensions made and part of Minor Version 1. The later minor version has no dependencies on NFS version 4 minor version 0, and was, until recently, documented as a completely separate protocol. This document is part of a set of documents which collectively obsolete RFCs 8881 and 8434. In addition to many corrections and clarifications, it will rely on NFSv4-wide documents to substantially revise the treatment of protocol extension, internationalization, and security, superseding the descriptions of those aspects of the protocol appearing in RFCs 5661 and 8881. |
| | eXtensible Stateless Equipment Data Exchange |
| |
| | draft-guy-xfsp-03.txt |
| | Date: |
19/12/2025 |
| | Authors: |
Mark Spencer, Edward Guy, , Nick Hartley |
| | Working Group: |
Individual Submissions (none) |
|
This document presents a binary IP-based protocol to facilitate interoperable communications between electronic equipment on a platform. The protocol is UDP-based, stateless, and multicast. Messages consist of a common header followed by a series of parameters and related attributes. The parameters are always informational, e.g., indicating airspeed is 150 kts, but parameter attributes can be set to indicate intent, e.g., this parameter contains a new user selected value such as an instruction that deploys the landing gear. Although initially designed for avionics, it can be applied to other platform domains as well. This document defines the core protocol and a method to extend it to meet any domain specific needs. |
| | Data Fields for Congestion Measurement |
| |
|
Congestion Measurement collects the congestion information in the packet while the packet traverses a path. The sender sets the congestion measurement data fields in the packet header indicating the network device along the path to update the congestion information field in the packet. When the packet arrives at the receiver, the congestion information field will reflect the degree of congestion across network path. Congestion Measurement can enable precise congestion control, assist in effective load balancing, and simplify network debugging. This document defines data fields for Congestion Measurement. Congestion Measurement Data-Fields can be encapsulated into a variety of protocols, such as IPv6, Segment Routing Header (SRH), Network Service Header (NSH), Generic Network Virtualization Encapsulation (Geneve), etc. |
| | IPv6 Options for Congestion Measurement |
| |
|
The Congestion Measurement enables precise congestion control, assists in effective load balancing, and simplifies network debugging by accurately reflecting the degree of congestion across network paths. This document defines how Congestion Measurement Data Fields are encapsulated in IPv6. |
| | New Key Share Extension for Classic McEliece Algorithms |
| |
|
RFC 8446 is modified to where another key share extension is introduced to accommodate both public keys and ciphertexts in ClientHello and ServerHello messages for post-quantum algorithms that have large public keys, including algorithms of the code-based cryptographic scheme Classic McEliece. |
| | The CITTAMARKET Protocol: Decentralized AGI Identity Anchoring via Bitcoin |
| |
|
This document specifies the CITTAMARKET Protocol v1.0, an open standard for the immutable identification and timestamping of Artificial General Intelligence (AGI) systems. The protocol leverages the Bitcoin blockchain's Proof-of-Work to solve the architectural problem of coordinating distributed autonomous systems without centralized control. It defines a four-layer architecture for creating unforgeable "Sovereign Identity" records. Priority of this invention is cryptographically anchored in Bitcoin blocks #927277, #927579, #928154, and #928185. |
| | OAuth 2.0 Refresh Token and Authorization Expiration |
| |
|
This specification extends OAuth 2.0 [RFC6749] by adding new token endpoint response parameters to specify refresh token expiration and user authorization expiration. |
| | Distribute SRv6 Locator by DHCP |
| |
|
In an SRv6 network, each SRv6 Segment Endpoint Node must be assigned an SRv6 Locator, and segment IDs are generated within the address space of this SRv6 Locator. This document describes a method for assigning SRv6 Locators to SRv6 Segment Endpoint Nodes through DHCPv6. |
| | A YANG Data Model for Resource Reservation Protocol (RSVP) |
| |
| | draft-ietf-teas-yang-rsvp-20.txt |
| | Date: |
19/12/2025 |
| | Authors: |
Vishnu Beeram, Tarek Saad, Rakesh Gandhi, Xufeng Liu, Igor Bryskin |
| | Working Group: |
Traffic Engineering Architecture and Signaling (teas) |
|
This document defines a YANG data model for the configuration and management of the RSVP protocol. The YANG data model covers the building blocks that may be augmented by other RSVP extension data models such as RSVP Traffic-Engineering (RSVP-TE). It is divided into two modules that cover the basic and extended RSVP features. |
| | Common YANG Data Types for Traffic Engineering |
| |
| | draft-ietf-teas-rfc8776-update-20.txt |
| | Date: |
19/12/2025 |
| | 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. |
| |
|
| |
| | Semantic Definition Format (SDF): Mapping files |
| |
| | draft-ietf-asdf-sdf-mapping-00.txt |
| | Date: |
18/12/2025 |
| | Authors: |
Carsten Bormann, Jan Romann |
| | Working Group: |
A Semantic Definition Format for Data and Interactions of Things (asdf) |
|
The Semantic Definition Format (SDF) is a format for domain experts to use in the creation and maintenance of data and interaction models that describe Things, i.e., physical objects that are available for interaction over a network. It was created as a common language for use in the development of the One Data Model liaison organization (OneDM) models. Tools convert this format to database formats and other serializations as needed. An SDF specification often needs to be augmented by additional information that is specific to its use in a particular ecosystem or application. SDF mapping files provide a mechanism to represent this augmentation. |
| | 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 Internet Standards 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. |
| | Protocol-Specific Profiles for JSContact |
| |
|
This document defines JSContact profiles, an IANA registry for named subsets of JSContact elements. It aims to facilitate using JSContact in context of contact data exchange protocols or other use cases, in which supporting all of JSContact semantics might be inappropriate. |
| | CPace,a balanced composable PAKE |
| |
|
This document describes CPace which is a protocol that allows two parties that share a low-entropy secret (password) to derive a strong shared key without disclosing the secret to offline dictionary attacks. The CPace protocol was tailored for constrained devices and can be used on groups of prime- and non-prime order. |
| | 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. |
| | Bundle Protocol (BP) Secure Advertisement and Neighborhood Discovery (SAND) |
| |
|
This document defines the Secure Advertisement and Neighborhood Discovery (SAND) protocol for Bundle Protocol version 7 (BPv7) within a delay-tolerant network (DTN). This protocol defines a general purpose advertisement mechanism with an initial set of message and data types able to be advertised by participating nodes in a BPv7 network. The focus of this document is for advertisement to topological neighbors about local neighborhoods but can be expanded upon in the future through extension points. |
| | Room Policy for the More Instant Messaging Interoperability (MIMI) Protocol |
| |
|
This document describes a set of concrete room policies for the More Instant Messaging Interoperability (MIMI) Working Group. It describes several independent properties and policy attributes which can be combined to model a wide range of chat and multimedia conference types. |
| | Segment Routing Policy Extension 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. A Network Resource Partition (NRP), is a subset of the resources and associated policies in the underlay network. In SR networks with multiple NRPs, an SR Policy can be associated with a particular NRP. In that case, SR Policy can be used for steering and forwarding traffic which is mapped to the NRP, so that the packets can be processed with the subset of network resources and policy of the NRP for guaranteed performance. Thus the association between SR Policy and NRP needs to be specified. This document defines extensions to the SR Policy Architecture to allow the association of the SR Policy candidate paths with NRPs. |
| | Fully Adaptive Routing Ethernet using BGP |
| |
| | draft-xu-idr-fare-04.txt |
| | Date: |
18/12/2025 |
| | Authors: |
Xiaohu Xu, Shraddha Hegde, Keyur Patel, Zongying He, Junjie Wang, Hongyi Huang, Qingliang Zhang, Hang Wu, Yadong Liu, Yinben Xia, Peilong Wang, Tiezheng |
| | Working Group: |
Individual Submissions (none) |
|
Large language models (LLMs) like ChatGPT have become increasingly popular in recent years due to their impressive performance in various natural language processing tasks. These models are built by training deep neural networks on massive amounts of text data, as well as visual and video data, and often consist of billions or even trillions of parameters. However, the training process for these models can be extremely resource-intensive, requiring the deployment of thousands or even tens of thousands of GPUs in a single AI training cluster. Therefore, three-stage or even five-stage CLOS networks are commonly adopted for AI networks. The non-blocking nature of the network becomes increasingly critical for large-scale AI model training. Therefore, adaptive routing is necessary to dynamically distribute traffic to the same destination across multiple equal-cost paths, based on network capacity and even congestion information along those paths. |
| | XET: Content-Addressable Storage Protocol for Efficient Data Transfer |
| |
|
This document specifies XET, a content-addressable storage (CAS) protocol designed for efficient storage and transfer of large files with chunk-level deduplication. XET uses content-defined chunking to split files into variable-sized chunks, aggregates chunks into containers called xorbs, and enables deduplication across files and repositories through cryptographic hashing. |
| | Decentralized Threat Signaling Protocol (DTSP) using OraSRS |
| |
|
This document specifies the Decentralized Threat Signaling Protocol (DTSP), a mechanism for distributed edge clients to collaboratively detect, report, and mitigate network threats. The protocol defines a state machine for threat lifecycle management (T0-T3), a standardized data format for threat signaling, and security mechanisms to prevent abuse in a permissionless environment. |
| | LDAP Bind Response Extension for Returning DN and Attributes |
| |
|
This document proposes an extension to the LDAP Bind operation to optionally return the authenticated subject’s Distinguished Name (DN) and selected attributes. The goal is to reduce the number of client- server round trips required to obtain user identity information after authentication. |
| | Z-Protocol: Zero-Handshake Adaptive Proof-of-Work Encrypted Transport Protocol |
| |
|
This document describes Z-Protocol, an experimental transport-layer protocol that establishes secure communication without a visible handshake. Z-Protocol combines asymmetric cryptography, adaptive proof-of-work admission control, and stateless packet processing to mitigate denial-of-service attacks and reduce observable protocol metadata during connection establishment. |
| | PCEP Extension for Tunneled Flow Specification |
| |
|
Traffic flows may be categorized and described using "Flow Specifications". RFC8955 defines the Flow Specification and describes how Flow Specification components are used to describe traffic flows. RFC8955 also defines how Flow Specifications may be distributed in BGP to allow specific traffic flows to be associated with routes. RFC 9168 specifies a set of extensions to PCEP to support the dissemination of Flow Specifications. This allows a PCE to indicate what traffic should be placed on each path that it is aware of. The extensions defined in this document extend the support for tunneled traffic filtering rules. |
| | 464XLAT Customer-side Translator (CLAT): Node Behavior and Recommendations |
| |
|
464XLAT defines an architecture for providing IPv4 connectivity across an IPv6-only network. The solution involves two functional elements: a provider-side translator (PLAT) and a customer-side translator (CLAT). This document updates the 464XLAT specification (RFC6877) and Requirements for IPv6 Customer Edge Routers (RFC8585) by further defining CLAT node behavior and IPv6 Customer Edge Routers to support IPv4-as-a-Service by providing recommendations for node developers on enabling and disabling CLAT. |
| |
|
| |
| | 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. |
| | Domain Connect Protocol - DNS provisioning between Services and DNS Providers |
| |
|
This document provides specification of the Domain Connect Protocol that was built to support DNS configuration provisioning between Service Providers (hosting, social, email, hardware, etc.) and DNS Providers. |
| | Delay-Tolerant Networking UDP Convergence Layer Protocol Version 2 |
| |
| | draft-ietf-dtn-udpcl-03.txt |
| | Date: |
17/12/2025 |
| | Authors: |
Brian Sipos, Joshua Deaton |
| | Working Group: |
Delay/Disruption Tolerant Networking (dtn) |
|
This document describes a UDP convergence layer (UDPCL) for Delay- Tolerant Networking (DTN). This version of the UDPCL protocol clarifies requirements of the earlier experimental RFC 7122, adds discussion of multicast addressing, congestion signaling, and updates to the Bundle Protocol (BP) contents, encodings, and convergence layer requirements in BP version 7. Specifically, the UDPCL uses CBOR-encoded BPv7 bundles as its service data unit being transported and provides an unacknowledged transport of such bundles. This version of UDPCL also includes security and extensibility mechanisms. |
| | Security Considerations for Computing-Aware Traffic Steering |
| |
|
Computing-Aware Traffic Steering (CATS) inherits potential security vulnerabilities from the network, computing nodes as well as workflows of CATS. This document describes various threats and security concerns related to CATS and existing approaches to solve these threats. |
| | Post-Quantum Traditional (PQ/T) Hybrid Authentication with Dual Certificates in TLS 1.3 |
| |
| | draft-yusef-tls-pqt-dual-certs-01.txt |
| | Date: |
17/12/2025 |
| | Authors: |
Rifaat Shekh-Yusef, Hannes Tschofenig, Mike Ounsworth, Tirumaleswar Reddy.K, Yaroslav Rosomakho |
| | Working Group: |
Individual Submissions (none) |
|
This document extends the TLS 1.3 authentication mechanism to allow the negotiation and use of two signature algorithms to enable dual- algorithm hybrid authentication, ensuring that an attacker would need to break both algorithms to compromise the session. The two signature algorithms come from two independent certificates that together produce a single Certificate and CertificateVerify message. |
| | Transparency Record Protocol for AI Governance |
| |
|
This document specifies the Transparency Record Protocol (TRP), an application-layer protocol for propagating AI transparency metadata across distributed systems. TRP enables organizations to maintain cryptographic chain of custody for AI-generated content, enforce governance policies at network boundaries, and provide verifiable audit trails for regulatory compliance. |
| | A YANG Data Model and RADIUS Extension for Policy-based Network Access Control |
| |
| | draft-ietf-opsawg-ucl-acl-10.txt |
| | Date: |
17/12/2025 |
| | Authors: |
Qiufang Ma, Qin WU, Mohamed Boucadair, Daniel King |
| | Working Group: |
Operations and Management Area Working Group (opsawg) |
|
This document defines a YANG data model for policy-based network access control, which provides enforcement of network access control policies based on group identity. Specifically in scenarios where network access is triggered by user authentication, this document defines a mechanism to ease the maintenance of the mapping between a user group identifier and a set of IP/MAC addresses to enforce policy-based network access control. Moreover, the document defines a Remote Authentication Dial-in User Service (RADIUS) attribute that is used to communicate the user group identifier as part of identification and authorization information. |
| | Publishing End-Site Prefix Lengths |
| |
|
This document specifies how to augment the Routing Policy Specification Language (RPSL) inetnum: class to refer specifically to prefixlen files which are comma-separated values (CSV) files used to specify end-site prefix lengths. This document also describes an optional mechanism that uses the Resource Public Key Infrastructure (RPKI) to authenticate the prefixlen files. |
| | Guidelines for Considering Operations and Management in IETF Specifications |
| |
| | draft-ietf-opsawg-rfc5706bis-01.txt |
| | Date: |
17/12/2025 |
| | Authors: |
Benoit Claise, Joe Clarke, Adrian Farrel, Samier Barguil, Carlos Pignataro, Ran Chen |
| | Working Group: |
Operations and Management Area Working Group (opsawg) |
|
New Protocols or Protocol Extensions are best designed with due consideration of the functionality needed to operate and manage them. Retrofitting operations and management considerations is suboptimal. The purpose of this document is to provide guidance to authors and reviewers on what operational and management aspects should be addressed when defining New Protocols or Protocol Extensions. This document obsoletes RFC 5706, replacing it completely and updating it with new operational and management techniques and mechanisms. It also updates RFC 2360 to obsolete mandatory MIB creation and introduces a requirement to include an "Operational Considerations" section in new RFCs in the IETF Stream. |
| | Path Computation Element Communication Protocol (PCEP) Extensions for Signaling Multipath Information |
| |
| | draft-ietf-pce-multipath-17.txt |
| | Date: |
17/12/2025 |
| | Authors: |
Mike Koldychev, Siva Sivabalan, Tarek Saad, Vishnu Beeram, Hooman Bidgoli, Bhupendra Yadav, Shuping Peng, Gyan Mishra, Samuel Sidor |
| | Working Group: |
Path Computation Element (pce) |
|
Certain traffic engineering path computation problems require solutions that consist of multiple traffic paths that together form a solution. Returning a single traffic path does not provide a valid solution. This document defines mechanisms to encode multiple paths for a single set of objectives and constraints. This allows encoding of multiple Segment Lists per Candidate Path within a Segment Routing Policy. The new Path Computation Element Communication Protocol (PCEP) mechanisms are designed to be generic, where possible, to allow for future re-use outside of SR Policy. The new PCEP mechanisms are applicable to both stateless and stateful PCEP. Additionally, this document updates RFC 8231 to allow encoding of multiple Segment Lists in PCEP. |
| |
|
| |
| | Automatic Certificate Management Environment (ACME) with OpenID Federation 1.0 |
| |
| | draft-ietf-acme-openid-federation-00.txt |
| | Date: |
16/12/2025 |
| | Authors: |
Giuseppe De Marco, Brandon Pitman, Tim Geoghegan, David Cook, J.C. Jones |
| | Working Group: |
Automated Certificate Management Environment (acme) |
|
The Automatic Certificate Management Environment (ACME) protocol allows server operators to obtain TLS certificates for their websites, based on a demonstration of control over the website's domain via a fully-automated challenge/response protocol. OpenID Federation 1.0 defines how to build a trust infrastructure using a trusted third-party model. It uses a trust evaluation mechanism to attest to the possession of private keys, protocol specific metadata and miscellaneous administrative and technical information related to a specific entity. This document defines how X.509 certificates associated with a given OpenID Federation Entity can be issued by an X.509 Certification Authority through the ACME protocol to the organizations which are part of a federation built on top of OpenID Federation 1.0. |
| | A Voucher Artifact for Bootstrapping Protocols |
| |
| | draft-ietf-anima-rfc8366bis-21.txt |
| | Date: |
16/12/2025 |
| | Authors: |
Kent Watsen, Michael Richardson, Esko Dijk, Max Pritikin, 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. |
| | YANG Groupings for UDP Clients and UDP Servers |
| |
|
This document defines two YANG 1.1 modules with reusable groupings for managing UDP clients and UDP servers. Notes to the RFC editor This note is to be removed before publishing as an RFC. Please replace "RFC XXXX" with the assigned RFC number prior to publication. Note that there are also several occurrences of "RFC XXXX" in the YANG modules. |
| | SID as source address in SRv6 |
| |
|
SRv6 is being rapidly deployed and is currently primarily used in trusted-domain backbone networks. However, we have also observed that SRv6 is beginning to extend toward end-user devices, e.g., in SD-WAN deployments. SD-WAN can be deployed in third-party clouds or at customer sites, causing the physical boundary of SRv6 to become blurred. This introduces certain security issues, such as middlebox filtering and unauthorized access to others’ VPN in Section 8.1 and Section 6 in [I-D.draft-ietf-spring-srv6-security]. This proposal mitigates these risks by using SID as source address in SRv6 packets. |
| | Guidance for Managing YANG Modules in RFCs and IANA Registries |
| |
|
This document provides guidance to the RFC Editor and IANA on managing YANG modules in RFCs and IANA registries, ensuring consistent application of YANG Semantic Versioning rules. |
| | OAuth 2.0 Token Exchange Target Service Discovery |
| |
|
This specification defines a method for OAuth 2.0 clients to discover the set of available target services (audiences, resources, and scopes) for a given subject token when performing OAuth 2.0 Token Exchange. The discovery endpoint accepts any subject token type registered in the OAuth Token Type Registry and returns values that are valid inputs to subsequent Token Exchange requests, supporting advanced use cases such as identity chaining and cross-domain delegation. |
| | 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. |
| | Special Use ASN's for 44net |
| |
|
This document proposes reserving a pool of Autonomous System Numbers (ASNs) for the Amateur Radio Digital Communications Network (44Net, also known as AMPRNet). 44Net traces its origins to the early 1980s when the Class A network 44.0.0.0/8 was set aside for amateur packet radio, enabling worldwide experimental and operational use by licensed radio amateurs. Recent work, including Ursini’s proposal to reserve the IPv6 block 44::/16 for amateur radio, demonstrates ongoing efforts to secure dedicated Internet resources for the community. To complement these efforts, this document recommends reserving approximately 25,000 ASNs for distribution to licensed radio operators and 44Net operators to support past, present, and future allocations, simplify routing and resource management, and make it straightforward to identify 44Net participants on the global Internet. |
| | Roughtime |
| |
|
This document describes Roughtime—a protocol that aims to achieve two things: secure rough time synchronization even for clients without any idea of what time it is, and giving clients a format by which to report any inconsistencies they observe between time servers. This document specifies the on-wire protocol required for these goals, and discusses aspects of the ecosystem needed for it to work. |
| | Hash-based Signatures: State and Backup Management |
| |
| | draft-ietf-pquip-hbs-state-02.txt |
| | Date: |
16/12/2025 |
| | Authors: |
Thom Wiggers, Kaveh Bashiri, Stefan Kolbl, Jim Goodman, Stavros Kousidis |
| | Working Group: |
Post-Quantum Use In Protocols (pquip) |
|
Stateful Hash-Based Signature Schemes (Stateful HBS) such as LMS, HSS, XMSS and XMSS^MT combine Merkle trees with One-Time Signatures (OTS) to provide signatures that are resistant against attacks using large-scale quantum computers. Unlike conventional stateless digital signature schemes, Stateful HBS have a state to keep track of which OTS keys have been used, as double-signing with the same OTS key allows forgeries. This document provides guidance and catalogs security considerations for the operational and technical aspects of deploying systems that rely on Stateful HBS. Management of the state of the Stateful HBS, including any handling of redundant key material, is a sensitive topic. This document describes some approaches to handle the associated challenges. It also describes the challenges that need to be resolved before certain approaches should be considered. |
| | 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. |
| | Revision of the RPKI Validation Algorithm |
| |
|
This document describes an improved validation procedure for Resource Public Key Infrastructure (RPKI) signed objects. This document updates RFC 6487. This document updates RFC 9582. This document obsoletes RFC 8360. |
| | Signed Prefix List (SPL) Based Route Origin Verification and Operational Considerations |
| |
|
The Signed Prefix List (SPL) is an RPKI object that attests to the complete list of prefixes which an Autonomous System (AS) may originate in the Border Gateway Protocol (BGP). This document specifies an SPL-based Route Origin Verification (SPL-ROV) methodology and combines it with the ROA-based ROV (ROA-ROV) to facilitate an integrated mitigation strategy for prefix hijacks and AS forgery. The document also explains the various BGP security threats that SPL can help address and provides operational considerations associated with SPL-ROV deployment. |
| | Testing Applications' IPv6 Support |
| |
|
This document provides guidance for application developers and software as a service providers on how to approach IPv6 testing in Dual-Stack (IPv4+IPv6), and IPv6-only scenarios, including "true IPv6-only" scenarios. It discusses common misconceptions about the degree to which operating systems and libraries can abstract IPv6 issues away and explains common regressions to avoid when deploying IPv6 support. |
| |
|
| |
| | Internet Control Message Protocol (ICMPv6) Reflection |
| |
|
This document specifies the ICMPv6 Reflection utility. The ICMPv6 Reflection utility is a diagnostic tool, similar to Ping and the ICMPv6 PROBE utility. It is similar to Ping and PROBE in that it relies on a stateless message exchange between a probing node and a probed node. The probing node sends a request to the probed node and the probed node responds to the request. The ICMPv6 Reflection utility differs from Ping and PROBE because, in the ICMPv6 Reflection utility, the probing node requests a snapshot of the message that it sent, as it was when arrived at the probed node. The probed node returns the requested snapshot. The ICMPv6 Reflection utility is useful because it can allow the user to see how the network modified the request as it traveled from the probing node to the probed node. |
| | Use of Hybrid Public-Key Encryption (HPKE) with CBOR Object Signing and Encryption (COSE) |
| |
| | draft-ietf-cose-hpke-19.txt |
| | Date: |
15/12/2025 |
| | Authors: |
Hannes Tschofenig, Orie Steele, Ajitomi, Daisuke, Laurence Lundblade, Michael Jones |
| | Working Group: |
CBOR Object Signing and Encryption (cose) |
|
This specification defines hybrid public-key encryption (HPKE) for use with CBOR Object Signing and Encryption (COSE). HPKE offers a variant of public-key encryption of arbitrary-sized plaintexts for a recipient public key. HPKE is a general encryption framework utilizing an asymmetric key encapsulation mechanism (KEM), a key derivation function (KDF), and an Authenticated Encryption with Associated Data (AEAD) algorithm. This document defines the use of HPKE with COSE. Authentication for HPKE in COSE is provided by COSE-native security mechanisms or by the pre-shared key authenticated variant of HPKE. |
| | 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. |
| | 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. |
| | YANG Data Model for MPLS mLDP |
| |
| | draft-ietf-mpls-mldp-yang-15.txt |
| | Date: |
15/12/2025 |
| | Authors: |
Syed Raza, Xufeng Liu, Santosh Esale, Loa Andersson, Jeff Tantsura |
| | Working Group: |
Multiprotocol Label Switching (mpls) |
|
This document describes a YANG data model for the Multiprotocol Label Switching (MPLS) Multipoint Label Distribution Protocol (mLDP). The mLDP YANG data model augments the MPLS LDP YANG data model. The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA). |
| | remoteStorage 1.0 |
| |
|
This draft describes a protocol by which client-side applications, running inside a web browser, can communicate with a data storage server that is hosted on a different domain name. This way, the provider of a web application need not also play the role of data storage provider. The protocol supports storing, retrieving, and removing individual documents, as well as listing the contents of an individual folder, and access control is based on bearer tokens. |
| | Deterministic Networking (DetNet) Data Plane - Tagged Cyclic Queuing and Forwarding (TCQF) for bounded latency with low jitter in large scale DetNets |
| |
| | draft-eckert-detnet-tcqf-12.txt |
| | Date: |
15/12/2025 |
| | Authors: |
Toerless Eckert, Yizhou Li, Stewart Bryant, Andrew Malis, Jeong-dong Ryoo, Peng Liu, Guangpeng Li, Shoushou Ren |
| | Working Group: |
Individual Submissions (none) |
|
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. |
| | 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 between multiple candidate paths in the SR policy. |
| | SW103K PROTOCOL |
| |
|
This specification defines a new protocol sw103k addresses challenges in networks with limited bandwidth, latency constraints, and data integrity concerns. It provides compression and decompression to optimize bandwidth utilization in environments such as Data centers, internet exchange points, and mobile communications. The protocol operates at the data link layer with a custom frame format including SW103K and HAVI headers. Key features include: - Batch processing of 103 packets with compression - Merkle tree- based integrity verification (merklesw103k root hash) - QoS mechanisms with 8-bit priority field - Security features including AES-256-GCM encryption - Physical layer synchronization with +-1us accuracy Jutifying why sw103k is unique: The sw103k protocol is a Layer-2 mechanism that applies stateful compression to complete payloads using shared context between communicating entities. The protocol assumes that traffic in constrained networks is often structured and repetitive and therefore allows endpoints to provision payload templates, dictionaries, and delta-encoding state prior to data exchange. During operation, payloads may be represented by compact identifiers together with fields that describe deviations from previously established state. For traffic patterns that conform to these assumptions, this approach can substantially reduce the number of transmitted octets and may achieve compression ratios on the order of 103:1 for selected telemetry and control messages. By operating independently of IP version, transport protocol, and application encoding, sw103k is intended to reduce airtime usage, energy consumption, and the need for fragmentation in environments where link capacity and device resources are limited. |
| | Reliability Framework for SRv6 Service Function Chaining |
| |
|
Segment routing (SR) [RFC8402] is a source routing paradigm that explicitly indicates the forwarding path for packets at the ingress node. SR can be instantiated on the MPLS data plane (MPLS-SR) and the IPv6 data plane (SRv6). On the MPLS-SR data plane, a segment is encoded as an MPLS label, and an ordered list of segments is encoded as a stack of labels. On the SRv6 data plane, a segment is encoded as an IPv6 address (SRv6 SID) [RFC8986], and an ordered list of segments is encoded as an ordered list of SRv6 SIDs in the SR header (SRH) [RFC8754]. The ingress node steers packets into a specific path according to the ordered list of segments (SR Policy) as defined in [RFC9256]. Service Function Chaining (SFC) defines an ordered set of service functions and subsequent "steering" of traffic through them. The architecture of SFC is defined in [RFC7665]. This document describes the common failure scenarios and protection mechanisms of service function chains in SR networks. Then implementation recommendations for protection of service function chains are proposed. |
| | Responsive Use of the Mobile Ad Hoc Network (MANET) Routing Protocol OLSRv2 |
| |
|
This specification describes an optional Topology Control (TC) message that can be sent by an OLSRv2 router. This is permitted, but not suggested, by the existing protocol, but is here recommended for use in some networks. The original motivation for this message came from the circumstances of a mostly stable network, in the most extreme case updated only by messages responding to the arrival and departure of routers, in which case the additional TC message is not just recommended but required. However, the additional message could be useful in reducing the routing convergence time in any network in which messages are sent at lengthy intervals. This specification updates RFC 7181 "The Optimized Link State Routing Protocol version 2 (OLSRv2)". |
| | SRv6 Path Verification |
| |
|
SRv6 is being rapidly deployed and is currently primarily used in trusted-domain backbone networks. However, we have also observed that SRv6 is beginning to extend toward end-user devices, e.g., in SD-WAN deployments. SD-WAN can be deployed in third-party clouds or at customer sites, causing the physical boundary of SRv6 to become blurred. This introduces certain security risks, such as packet injection and path manipulation attacks. Section 6 of [I-D.draft-ietf-spring-srv6-security] identifies these risks as well, including Section 6.2.1 on Modification Attacks and Section 6.2.3 on Packet Insertion. This proposal mitigates these risks by enhancing the HMAC mechanism defined in [RFC8754]. |
| | COSE Receipts for MMRs |
| |
|
This document defines a new verifiable data structure type for COSE Receipts [I-D.ietf-cose-merkle-tree-proofs] specifically for use with ledgers based on post-order traversal binary Merkle trees and which are designed for high throughput, ease of replication and compatibility with commodity cloud storage. Post-order traversal binary Merkle trees, also known as history trees, are more commonly known as Merkle Mountain Ranges. |
| | SCONE TCP Option |
| |
|
This document describes a TCP option that permits network elements to provide TCP endpoints advice on rate limits within the network. The functionality for TCP is analogous to SCONE packets within the QUIC protocol. |
| | The Use Case of Autonomic Traffic Management in the Artificial Intelligence Data Center |
| |
|
This document describes the use case of autonomic traffic management in the Artificial Intelligence Data Center (AIDC), including the requirements and two management mechanisms, based on the distributed model and the centralized controlling model. It proposed to use the IETF GRASP protocol for the information exchanging, resource negotiation, control signalling, and etc. |
| | Power and Energy YANG Module |
| |
|
This document defines the YANG data model for Power and Energy monitoring of devices within or connected to communication networks. |
| | Path Computation Element Communication Protocol (PCEP) extensions for Circuit Style Policies |
| |
|
Segment Routing (SR) enables a node to steer packet flows along a specified path without the need for intermediate per-path states, due to the utilization of source routing. An SR Policy can consist of one or a set of candidate paths, where each candidate path is represented by a segment list or a set of segment lists, which are essentially instructions that define a source-routed policy. This document specifies a set of extensions to the Path Computation Element Communication Protocol (PCEP) for Segment Routing Policies that are designed to satisfy requirements for connection-oriented transport services (Circuit-Style SR policies). They include the ability to control path modification and the option to request path with strict hops only, being also applicable for generic SR policy use cases where controlling path modification or deterministic and persistent path requirements are applicable. |
| | Segment Routing based Network Resource Partition (NRP) for Enhanced VPN |
| |
|
Enhanced VPNs aim to deliver VPN services with enhanced characteristics, such as guaranteed resources, latency, jitter, etc., so as to support customers requirements on connectivity services with these enhanced characteristics. Enhanced VPN requires integration between the overlay VPN connectivity and the characteristics provided by the underlay network. 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. Segment Routing (SR) leverages the source routing paradigm. A node steers a packet through an ordered list of instructions, called "segments". A segment is referred to by its Segment Identifier (SID). SIDs can represent topological or service based instructions. SIDs can further be associated with a set of network resources used for executing the instruction. Such SIDs are called resource-aware SIDs. A group of resource-aware SIDs may be used to build SR based NRPs, which provide customized network topology and resource attributes required by one or a group of enhanced VPN services. This document describes an approach to build SR based NRPs using resource-aware SIDs. The SR based NRP can be used to deliver enhanced VPN services in SR networks. |
| |
|
| |
| | Automated Certificate Management Environment (ACME) rats Identifier and Challenge Type |
| |
| | draft-ietf-acme-rats-00.txt |
| | Date: |
12/12/2025 |
| | Authors: |
Peter Liu, Mike Ounsworth, Michael Richardson |
| | Working Group: |
Automated Certificate Management Environment (acme) |
|
This document describes an approach where an ACME Server can challenge an ACME Client to provide a Remote Attestation Evidence or Remote Attestation Result in any format supported by the Conceptual Message Wrapper. The ACME Server can optionally challenge the Client for specific claims that it wishes attestation for. |
| | RTP Control Protocol (RTCP) Messages for Temporal-Spatial Resolution |
| |
|
This specification describes an RTCP feedback message format for the ISO/IEC International Standard 23001-11, known as Energy Efficient Media Consumption (Green metadata), developed by the ISO/IEC JTC 1/SC 29/ WG 3 MPEG System. The RTCP payload format specified in this specification enables receivers to provide feedback to the senders and thus allows for short-term adaptation and feedback-based energy efficient mechanisms to be implemented. The payload format has broad applicability in real-time video communication services. |
| | HTTP Unencoded Digest |
| |
|
The Repr-Digest and Content-Digest integrity fields are subject to HTTP content coding considerations. There are some use cases that benefit from the unambiguous exchange of integrity digests of unencoded representation. The Unencoded-Digest and Want-Unencoded- Digest fields complement existing integrity fields for this purpose. This document updates the terms "Integrity fields" and "Integrity preference fields" defined in RFC 9530. |
| | 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. |
| | REST API Linked Data Keywords |
| |
|
This document defines two keywords to provide semantic information in OpenAPI Specification and JSON Schema documents, and support contract-first semantic schema design. |
| | Nearly IPv6 Only Dual Stack Hosts |
| |
|
Once all of a dual stack IPv4 and IPv6 host's applications support IPv6, IPv4 connectivity becomes unnecessary. However, ceasing to provide a dual stack host with an IPv4 address via a DHCPv4 server can cause the host to continue to make periodic and unsatisfied DHCPv4 requests, imposing unnecessary broadcast traffic on an attached link. In this situation, it would be useful to continue to provide a host with an IPv4 address via DHCPv4, yet prevent it from using the IPv4 address for any connectivity outside of the host itself. This memo describes a DHCPv4 method to achieve this. |
| | Additional Security Algorithms For Use With TCP-AO |
| |
|
RFC5926 specifies cryptographic algorithms for TCP-AO. It explains how to use KDF_HMAC_SHA1 and KDF_AES_128_CMAC as KDFs. It also explains how to use HMAC-SHA-1-96 and AES-128-CMAC-96 as MAC algorithms. This document specifies several new KDFs and MAC algorithms for TCP- AO. The KDFs and MAC algorithms specified in this document are based upon more recent, stronger cryptography. |
| | Update Management Extensions for Software Updates for Internet of Things (SUIT) Manifests |
| |
|
This specification describes extensions to the SUIT manifest format. These extensions allow an update author, update distributor or device operator to more precisely control the distribution and installation of updates to devices. These extensions also provide a mechanism to inform a management system of Software Identifier and Software Bill Of Materials information about an updated device. |
| |
|
| |
| | JSContact Cryptographic Key Extensions |
| |
|
Extensions to the JSContact data model for contact card data are defined to provide improved support for describing cryptographic credentials to be used with applications and services and to provide support for authenticated updates to a contact card. These features in combination provide a basis for establishing and maintaining peer- to-peer trust. |
| | Clarifications on CDS/CDNSKEY and CSYNC Consistency |
| |
|
Maintenance of DNS delegations requires occasional changes of the DS and NS record sets on the parent side of the delegation. For the case of DS records, "Automating DNSSEC Delegation Trust Maintenance" (RFC 7344) provides automation by allowing the child to publish CDS and/or CDNSKEY records holding the prospective DS parameters which the parent can ingest. Similarly, "Child-to-Parent Synchronization in DNS" (RFC 7477) specifies CSYNC records to indicate a desired update of the delegation's NS (and glue) records. Parent-side entities (e.g., Registries and Registrars) can query these records from the child and, after validation, use them to update the parent- side Resource Record Sets (RRsets) of the delegation. This document specifies under which conditions the target states expressed via CDS/CDNSKEY and CSYNC records are considered "consistent". Parent-side entities accepting such records from the child have to ensure that update requests retrieved from different authoritative nameservers satisfy these consistency requirements before taking any action based on them. This document updates RFC 7344 and RFC 7477. |
| | Signal-Free Locator/ID Separation Protocol (LISP) Multicast |
| |
|
This document describes the design for inter-domain multicast overlays using the Locator/ID Separation Protocol (LISP). The document specifies how LISP multicast overlays operate over a unicast underlays. When multicast sources and receivers are active at Locator/ID Separation Protocol (LISP) sites, the core network is required to use native multicast so packets can be delivered from sources to group members. When multicast is not available to connect the multicast sites together, a signal-free mechanism can be used to allow traffic to flow between sites. The mechanism within here uses unicast replication and encapsulation over the core network for the data plane and uses the LISP mapping database system so encapsulators at the source LISP multicast site can find decapsulators at the receiver LISP multicast sites. This document when approved obosletes RFC8378. |
| | Deterministic Networking (DetNet) Data Plane - guaranteed Latency Based Forwarding (gLBF) for bounded latency with low jitter and asynchronous forwarding in Deterministic Networks |
| |
| | draft-eckert-detnet-glbf-07.txt |
| | Date: |
11/12/2025 |
| | Authors: |
Toerless Eckert, Alexander Clemm, Stewart Bryant, Stefan Hommes |
| | Working Group: |
Individual Submissions (none) |
|
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. |
| | Latency analysis of mobile transmission |
| |
|
Dependable time-critical communication over a mobile network has its own challenges. This document focuses on a comprehensive analysis of mobile systems latency in order to incorporate its specifics in developments of latency specific network functions. The analysis provides valuable insights for the development of wireless-friendly methods ensuring bounded latency as well as future approaches using data-driven latency characterization. |
| | STAMP Extensions for DetNet |
| |
|
Deterministic Networking (DetNet) provides a capability for the delivery of data flows with extremely low packet loss rates and bounded end-to-end delivery latency. The enabler to DetNet is a proper queue scheduling mechanism, such as timeslot based queueing and forwarding mechanism, which requires every router along the DetNet path to collect the basic timeslot mapping relationship between itself and its adjacent router. This document defines two Simple Two-Way Active Measurement Protocol (STAMP) TLVs, to acquire the basic timeslot mapping relationship between the local router and its adjacent router. |
| | 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. |
| | Using IKE Fragmentation for Large Messages |
| |
|
This document describes describes issues with using Internet Key Exchange version 2 (IKEv2) fragmentation for transmitting large messages on unreliable transport. The document proposes several approaches for dealing with these issues: randomizing the order the fragments are sent, dispersing sending fragments over time and selective retransmission of fragments based on information from the peer about their receipt. |
| | The "HeaderWrittenBy" and "SendingSoftware" Mail Header Fields |
| |
|
This document proposes two new, optional mail header fields. * "HeaderWrittenBy" is designed to provide a simple attestation of the host that injected a message's primary author-level headers (such as "From") into the mail system. * "SendingSoftware" is designed to declare the Mail User Agent (MUA) that composed the message. These are intended to provide additional, simple-to-parse signals for mail filtering and analysis, to be used in conjunction with existing authentication mechanisms like DKIM. |
| | DNS driven traffic steering |
| |
|
The Internet provides best-effort service, and for users with quality assurance requirements, selecting an Internet acceleration service provider to gareentee network access quality is a common choice. This document proposes a possible mechanism for leveraging DNS to automatically steer application’s traffic onto an SRv6 network. |
| | RATS Conceptual Messages Wrapper (CMW) |
| |
| | draft-ietf-rats-msg-wrap-23.txt |
| | Date: |
11/12/2025 |
| | Authors: |
Henk Birkholz, Ned Smith, Thomas Fossati, Hannes Tschofenig, Dionna Glaze |
| | Working Group: |
Remote ATtestation ProcedureS (rats) |
|
The Conceptual Messages introduced by the RATS architecture (RFC 9334) are protocol-agnostic data units that are conveyed between RATS roles during remote attestation procedures. Conceptual Messages describe the meaning and function of such data units within RATS data flows without specifying a wire format, encoding, transport mechanism, or processing details. The initial set of Conceptual Messages is defined in Section 8 of RFC 9334 and includes Evidence, Attestation Results, Endorsements, Reference Values, and Appraisal Policies. This document introduces the Conceptual Message Wrapper (CMW) that provides a common structure to encapsulate these messages. It defines a dedicated CBOR tag, corresponding JSON Web Token (JWT) and CBOR Web Token (CWT) claims, and an X.509 extension. This allows CMWs to be used in CBOR-based protocols, web APIs using JWTs and CWTs, and PKIX artifacts like X.509 certificates. Additionally, the draft defines a media type and a CoAP content format to transport CMWs over protocols like HTTP, MIME, and CoAP. The goal is to improve the interoperability and flexibility of remote attestation protocols. Introducing a shared message format such as CMW enables consistent support for different attestation message types, evolving message serialization formats without breaking compatibility, and avoiding the need to redefine how messages are handled within each protocol. |
| | Versioning in the Registration Data Access Protocol (RDAP) |
| |
|
This document describes an RDAP extension for an extensible set of versioning types with the features of identifying the RDAP extension versions supported by the server, the RDAP extension versions included in an RDAP response, and enabling a client to specify the desired RDAP extension versions to include in the RDAP query and RDAP response. |
| | Flow Queue PIE: A Hybrid Packet Scheduler and Active Queue Management Algorithm |
| |
|
This document presents Flow Queue Proportional Integral controller Enhanced (FQ-PIE), a hybrid packet scheduler and Active Queue Management (AQM) algorithm to isolate flows and tackle the problem of bufferbloat. FQ-PIE uses hashing to classify incoming packets into different queues and provide flow isolation. Packets are dequeued by using a variant of the round robin scheduler. Each such flow is managed by the PIE algorithm to maintain high link utilization while controlling the queue delay to a target value. |
| |
|
| |
| | BGP Usage for SD-WAN Overlay Networks |
| |
|
This document explores the complexities involved in managing large scale Software Defined WAN (SD-WAN) overlay networks, along with various SD-WAN scenarios. Its objective is to illustrate how a BGP-based control plane can effectively manage these overlay networks by distributing edge service reachability information, WAN port attributes, and underlay path details, thereby minimizing manual provisioning. |
| | 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. |
| | 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). |
| | HTTP Problem Types for Digest Fields |
| |
|
This document specifies problem types that servers can use in responses to problems encountered while dealing with a request carrying integrity fields and integrity preference fields. |
| | 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. to be used 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). |
| | Cisco's CoAP Simple Management Protocol |
| |
|
CoAP Simple Management Protocol (CSMP) is purpose-built to provide lifecycle management for resource constrained IoT devices deployed within large-scale, bandwidth constrained IoT networks. CSMP offers an efficient transport and message encoding supporting classic NMS functions such as device on-boarding, device configuration, device status reporting, securing the network, etc. This document describes the design and operation of CSMP. This document does not represent an IETF consensus. |
| | Caller ID Verification In Heterogeneous Telecommunication Networks |
| |
| | draft-hao-civ-02.txt |
| | Date: |
10/12/2025 |
| | Authors: |
Feng Hao, Basil Thomas, Steve Smith, Muhammad Azad, Shen Wang |
| | Working Group: |
Individual Submissions (none) |
|
This document defines an extension to the INVITE header of the Session Initiation Protocol (SIP) to support a Caller ID Verification (CIV) method. CIV authenticates the caller ID of an incoming call through a challenge-and-response process across both IP and non-IP networks without requiring a trusted third party or a public key infrastructure. When receiving a call with a claimed phone number, the called party holds the call and sends a quickly terminated INVITE request (like a flash call) to that number, carrying a short 4-digit challenge embedded as part of the caller ID. A genuine caller would receive the challenge and respond by echoing the same digits, e.g., through DTMF (Dual-Tone Multi-Frequency). The proposed extension involves two changes to the INVITE header. First, it adds a new option tag, "civ", in the Supported header field of the INVITE request. This tag allows the calling party to indicate support for CIV in the initial call. Second, it adds a special value "civ-veri- call" for the Purpose parameter of the Call-Info header field. This value allows the called party to make a verification call, indicating the purpose of the call is to transmit a challenge rather than establish a phone conversation. CIV uses the standard Session-ID header in the INVITE request to allow the calling party to explicitly match the verification call with the initial call. Whilst this document focuses on IP networks, the same CIV protocol also works with non-IP networks (e.g., SS7) by including the "civ" tag, the "civ-veri-call" value and the session ID in the User-to-User Information (UUI) parameter. |
| | The Ethical Crawler Agreement Protocol (ECAP) |
| |
|
This document specifies the Ethical Crawler Agreement Protocol (ECAP), an application-layer protocol for managing consent and ethical verification between web hosts and automated agents (crawlers, AI scrapers). Unlike the voluntary robots.txt standard, ECAP utilizes cryptographic signatures and a declarative policy handshake to ensure verifiable, consent-based access to web resources. |
| | The Micro Agent Communication Protocol (uACP) |
| |
| | draft-mallick-muacp-00.txt |
| | Date: |
10/12/2025 |
| | Authors: |
Arnab Mallick, Indraveni Chebolu |
| | Working Group: |
Individual Submissions (none) |
|
This document specifies the Micro Agent Communication Protocol (µACP), a resource-efficient messaging protocol for autonomous agents operating on constrained devices (Class 1 IoT devices per [RFC7228]). Existing agent communication protocols assume unbounded computational and energy resources; µACP provides formal guarantees on memory, energy, and bandwidth consumption while maintaining expressiveness sufficient for finite-state coordination patterns. The protocol defines four core message types, a fixed 64-bit header, TLV-based extensibility, and mandatory OSCORE security binding for operation in adversarial environments. |
| | 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. |
| | The MyClerk Virtual File System: Distributed Storage for Family Networks |
| |
|
This document specifies the MyClerk Virtual File System (VFS), a distributed storage system designed for family networks. The VFS provides end-to-end encrypted, redundant storage across heterogeneous nodes using adaptive chunking and Reed-Solomon erasure coding [REED-SOLOMON]. Metadata synchronization uses Conflict-free Replicated Data Types (CRDTs) [CRDT] with a hybrid LWW-Register and OR-Set approach. The system supports tiered storage, automatic health monitoring with self-healing capabilities, and federation between separate family installations. It is designed to be accessible to non-technical users while providing enterprise-grade data durability. |
| | A profile for Signed Prefix Lists for Use in the Resource Public Key Infrastructure (RPKI) |
| |
|
This document defines a "Signed Prefix List", a Cryptographic Message Syntax (CMS) protected content type for use with the Resource Public Key Infrastructure (RPKI) to carry the complete list of prefixes which an Autonomous System (the subject AS) may originate to all or any of its routing peers. The validation of a Signed Prefix List confirms that the holder of the subject AS produced the object, and that this list is a current, accurate and complete description of address prefixes that may be announced into the routing system originated by the subject AS. |
| |
|
| |
| | Task Extensions to iCalendar |
| |
|
The Internet Calendaring and Scheduling Core Object Specification (iCalendar) (RFC5545) VTODO calendar component has seen limited adoption and use, mainly for personal reminders and to-do lists. This document updates and defines extensions to VTODO to provide improved status tracking, scheduling and specification of tasks to allow its use in other contexts, such as process control and project management. It also defines how Calendaring Extensions to WebDAV (CalDAV) (RFC 4791) servers can be extended to support certain automated task management behaviours. |
| | Mobile Traffic Steering |
| |
| | draft-ietf-dmm-mts-00.txt |
| | Date: |
09/12/2025 |
| | Authors: |
Marco Liebsch, Jari Mutikainen, Zhaohui Zhang, Tianji Jiang |
| | Working Group: |
Distributed Mobility Management (dmm) |
|
The evolution of cellular mobile communication systems is aligned with an increasing demand for customized deployments, energy efficiency, dynamic re-configurability and the integration and use of other network technologies, such as non-cellular radio access technologies and non-terrestrial networks. In order to achieve and maintain the expected service quality and continuity, such systems should be designed and controllable end-to-end, taking all involved network domains and segments into account. This document discusses an end-to-end system from an advanced use cases perspective and substantiates the demand for solutions to share information and enable control interfaces between all connected network domains, including the mobile communication system and the transport network that stretches up to the data networks that host service instances. In the view of flexible implementations and deployment, two architectural principles, leveraging either a dedicated controller or a decentralized control plane, are described and discussed, accompanied by operational aspects and an associated information model that enable end-to-end mobile traffic treatment and steering in such complex and dynamically changing networks. |
| | Guidance to Avoid Use of BGP Extended Communities at Internet Exchange Route Servers |
| |
|
This document outlines a recommendation to the Internet operational community to avoid the use of BGP Extended Communities at Internet Exchange Point (IXP) Route Servers. It includes guidance for both the Internet Service Provider side peering with Route Servers and IXPs operating Route Servers. This recommendation aims to help the global Internet routing system's performance and help protect Route Server participants against misconfigurations. This document updates RFC 7948. |
| | 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. |
| | Fast HIP Host Mobility |
| |
|
This document describes mobility scenarios and how to aggressively support them in HIP. The goal is minimum lag in the mobility event. |
| | SRv6-based BGP Service Capability |
| |
|
RFC9252 specifies that implementations MUST provide a mechanism to control advertisement of SRv6-based BGP service routes on a per neighbor and per service basis. This document provides analysis on the problems that may be encountered if the SRv6-based service routes are received by the MPLS-only PEs. Some currently used SRv6-based service routes advertisement controlling methods by configuration or network planning are also described. And this document proposes an automatic advertisement controlling method for SRv6-based service routes by defining a new Capability Code for SRv6-based BGP service capability. |
| | A Profile for Signed Group of Multiple-Origin Autonomous Systems for Use in the Resource Public Key Infrastructure (RPKI) |
| |
|
This document defines a "Signed MOAS Group", a Cryptographic Message Syntax (CMS) protected content type for use with the Resource Public Key Infrastructure (RPKI) to authenticate the collective announcement of IP prefixes by Multiple Origin Autonomous System (MOAS). The Signed MOAS Group mainly includes two parts: an IP prefix and a list of Autonomous Systems (ASes) authorized to announce the prefix. At least one of these ASes SHOULD be authorized to announce the prefix by the prefix owner through a Route Origin Authorization (ROA). The validation of a Signed MOAS Group confirms that the authorized ASes and other listed ASes have collectively agreed to announce the prefix, ensuring that the announcement is legitimate, accurate, and mutually authorized. |
| | Domain Name System (DNS) IANA Considerations |
| |
|
This document specifies Internet Assigned Numbers Authority (IANA) parameter assignment considerations for the allocation of Domain Name System (DNS) resource record (RR) types, CLASSes, operation codes, error codes (RCODEs), DNS protocol message header bits, and AFSDB resource record subtypes. It obsoletes RFC 6895 and updates RFCs 1183, 2930, 3597, and 8945. |
| | HTTP Profile for Synchronized Resource State (Agentic State Transfer) |
| |
|
HTTP resources are frequently exposed in multiple representations (e.g., text/html for rendering and application/json for processing) via Content Negotiation. However, standard HTTP concurrency controls (such as ETags) are typically scoped to the byte sequence of a specific representation. This creates a synchronization gap where a client modifying one representation cannot guarantee consistency with the underlying state of another representation, leading to race conditions and "lost updates" in multi-client environments. This document specifies _Agentic State Transfer_ (AST), an HTTP profile for managing _Canonical Resource State_ (CRS) across multiple synchronized representations of the same resource. It defines the use of _Semantic Validators_ (Content Identity) to track the logical state of a resource independent of its serialization. It further mandates the use of Optimistic Concurrency Control via If-Match headers for state-changing operations, ensuring that mutations applied by automated agents are atomic and consistent across all views. |
| | Registration Data Access Protocol (RDAP) Extension for Resource Public Key Infrastructure (RPKI) Registration Data |
| |
|
The Resource Public Key Infrastructure (RPKI) is used to secure inter-domain routing on the internet. This document defines a new Registration Data Access Protocol (RDAP) extension with identifier "rpki1", for accessing the RPKI registration data in the Internet Number Registry System (INRS) for the Route Origin Authorization (ROA), Autonomous System Provider Authorization (ASPA), and X.509 Resource Certificate RPKI profiles through RDAP. The INRS is composed of Regional Internet Registries (RIRs), National Internet Registries (NIRs), and Local Internet Registries (LIRs). |
| | A Comprehensive Errata for 'retransmission-allowed' XML Element |
| |
|
This document fixes use of the 'retransmission-allowed' element of PIDF-LO in six published RFCs. All text and examples should show 'true' or 'false' to match the XML schema definitions, but some RFCs incorrectly use 'yes' or 'no'. This document updates RFC4119, RFC5606, RFC5774, RFC6442, RFC7378, RFC8262. |
| | Secure Reporting of SUIT Update Status |
| |
| | draft-ietf-suit-report-18.txt |
| | Date: |
09/12/2025 |
| | Authors: |
Brendan Moran, Henk Birkholz |
| | Working Group: |
Software Updates for Internet of Things (suit) |
|
The Software Update for the Internet of Things (SUIT) manifest provides a way for many different update and boot workflows to be described by a common format. This document specifies a lightweight feedback mechanism that allows a developer in possession of a manifest to reconstruct the decisions made and actions performed by a manifest processor. |
| |
|
| |
| | 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. |
| | Post-Quantum Key Encapsulation Mechanisms (PQ KEMs) for JOSE and COSE |
| |
| | draft-ietf-jose-pqc-kem-05.txt |
| | Date: |
08/12/2025 |
| | Authors: |
Tirumaleswar Reddy.K, Aritra Banerjee, Hannes Tschofenig |
| | Working Group: |
Javascript Object Signing and Encryption (jose) |
|
This document describes the conventions for using Post-Quantum Key Encapsulation Mechanisms (PQ-KEMs) within JOSE and COSE. 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-ietf-jose-pqc/. Discussion of this document takes place on the jose Working Group mailing list (mailto:jose@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/cose/. Subscribe at https://www.ietf.org/mailman/listinfo/jose/. |
| | LISP Multicast Overlay Group to Underlay RLOC Mappings |
| |
|
This draft augments LISP [RFC9300] multicast functionality described in [I-D.farinacci-lisp-rfc6831bis] and [I-D.farinacci-lisp-rfc8378bis] to support the mapping of overlay group addresses to underlay RLOC addresses. This draft defines a many-to-1, 1-to-many, and many-to-many relationship between multicast EIDs and the Replication List Entries (RLEs) RLOC records they map to. The mechanisms in this draft allow a multicast LISP overlay to run over a mixed underlay of unicast and/or multicast packet forwarding functionality. |
| | Adaptive Routing Notification |
| |
|
Large-scale supercomputing and AI data centers utilize multipath to implement load balancing and/or improve transport reliability. Adaptive routing (AR), widely used in direct topologies such as dragonfly, is growing popular in commodity data centers to dynamically adjust routing policies based on path congestion and failures. When congestion or failure occurs, the sensing node can not only apply AR locally but also send the congestion/failure information to other nodes in a timely and accurate manner to enforce AR on other nodes, thus avoiding exacerbating congestion on the reported path. This document specifies Adaptive Routing Notification (ARN), a general mechanism to proactively disseminate congestion detection and congestion elimination information for remote nodes to perform re-routing policies. Particularly for AI workloads like DeepSeek's MoE models that exhibit dynamic all-to-all communication patterns with bursty traffic characteristics, such mechanisms become crucial to enable immediate network response to transient congestion conflicts. |
| | PQ/T Hybrid KEM: HPKE with JOSE/COSE |
| |
|
This document outlines the construction of a PQ/T Hybrid Key Encapsulation Mechanism (KEM) in Hybrid Public-Key Encryption (HPKE) for integration with JOSE and COSE. It specifies the utilization of both traditional and Post-Quantum Cryptography (PQC) algorithms, referred to as PQ/T Hybrid KEM, within the context of JOSE and COSE. |
| | Evidence Package Format Specification: Storing Evidence from Software Testing |
| |
|
Taking evidence is a key part of any robust software testing process. This specification defines a format which collects evidence together and stores metadata and annotations in an organised fashion from both manual and automated testing sources. This work is not a standard and does not enjoy community consensus. |
| | An AuthZEN profile for trust registries |
| |
|
Trust registries come in many forms; ETSI trust status lists, OpenID Federation, ledgers. This document describes a simple protocol in the form of a profile of AuthZen that provides a local interface to one or more trust registries. The protocol is mant to be used as a local abstraction layer for any application that needs to evaluate trust. |
| | Managing multiple paths for a QUIC connection |
| |
| | draft-ietf-quic-multipath-18.txt |
| | Date: |
08/12/2025 |
| | 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. |
| | EAT Measured Component |
| |
|
The term "measured component" refers to an object within the attester's target environment whose state can be sampled and typically digested using a cryptographic hash function. Examples of measured components include firmware stored in flash memory, software loaded into memory at start time, data stored in a file system, or values in a CPU register. This document provides the information model for the "measured component" and two associated data models. This separation is intentional: the JSON and CBOR serializations, coupled with the media types and associated CoAP Content-Formats, enable the immediate use of the semantics within the EAT framework. Meanwhile, the information model can be reused in future specifications to provide additional serializations, for example using ASN.1. |
| | Encrypted Payloads in SUIT Manifests |
| |
|
This document specifies techniques for encrypting software, firmware, machine learning models, and personalization data by utilizing the IETF SUIT manifest. Key agreement is provided by ephemeral-static (ES) Diffie-Hellman (DH) and AES Key Wrap (AES-KW). ES-DH uses public key cryptography while AES-KW uses a pre-shared key. Encryption of the plaintext is accomplished with conventional symmetric key cryptography. |
| |
|
| |
| | Flooding Reduction Algorithms Framework |
| |
|
This document introduces a framework making it possible to deploy multiple flood reduction algorithms within the same IGP domain in an interoperable fashion. |
| | MAC Address for Layer 3 Link Local Discovery Protocol (LLDP) |
| |
|
IEEE 802 has defined a number of protocols which can operate between adjacent Ethernet stations at Layer 2, including bridges, and may be useful between Layer 3 aware stations such as IP routers and hosts. An example is the Link Layer Discover Protocol (IEEE Std 802.1AB, LLDP). This document specifies a MAC address that can be used for this purpose for interoperability despite intervening bridges. |
| | Privacy Preference Declaration for Home Networks |
| |
|
This document proposes a framework that empowers users to define and enforce privacy policies within their home networks through a Privacy Preference Declaration (PPD) protocol and architecture. As connected devices proliferate, this approach enhances user control by enabling user-defined privacy settings for different data types, automatic policy discovery by new devices, and accountability measures such as notifications, network restrictions, or perhaps reporting non- compliance with users' defined preferences to designated authorities. The framework aims to cultivate a privacy-conscious home network environment through clear, enforceable privacy governance. |
| | Privacy Preference Declaration Taxonomy |
| |
|
This document defines a standardized taxonomy for describing data handling practices of Internet-connected devices within home networks. It complements the Privacy Preference Declaration (PPD) Protocol and architecture by providing the necessary vocabulary and semantic structure to represent and reason about data types, purposes, actions, sources, and destinations. This taxonomy supports both machine reasoning and human interpretation and can be implemented using ontological frameworks such as OWL-DL. |
| | Transition to Full BGPsec Deployment: Transitive-BGPsec is Incompatible with BGPsec |
| |
|
This document elaborates on the reasons why it is unfeasible to reconstruct the native-BGPsec as a transitive approach, such that a BGP update with a correctly signed BGPsec_PATH attribute can traverse legacy areas and afterwards it can still be properly processed by subsequent native-BGPsec speakers. |
| | A Profile for Route Path Authorizations (RPAs) |
| |
|
This document defines a Cryptographic Message Syntax (CMS) protected content type for Route Path Authorizations (RPA) objects used in Resource Public Key Infrastructure (RPKI). An RPA is a digitally signed object that provides a means of verifying whether an IP address block is received from AS a to AS b and announced from AS b to AS c. When validated, an RPA's eContent can be used for the detection and mitigation of route hijacking, especially providing protection for the AS_PATH attribute in BGP-UPDATE. This object is a variant of the aut-num object in the Internet Routing Registry (IRR). |
| | Measurement and Analysis of IPv6 Interface Identifier Patterns in the Real World |
| |
|
Interface Identifiers (IIDs) are critical components of IPv6 addresses, significantly impacting user privacy and the feasibility of network reconnaissance. RFC 7707 previously provided a comprehensive analysis of IID patterns based on data from the early stages of IPv6 deployment. However, with the widespread adoption of privacy-enhancing standards such as RFC 7217, historical data no longer accurately reflects the current IPv6 ecosystem. This document provides updated measurements of IID patterns by utilizing an improved pattern recognition method and incorporating novel data sources, such as public mailing lists. The measurement data reveals that while "Low-byte" patterns have decreased significantly in server addresses, a substantial number of seemingly random addresses actually belong to non-random, specific patterns, implying that heuristic scanning remains a viable vector. Furthermore, while client devices have widely adopted randomized addresses-effectively enhancing privacy-Client Premise Equipment (CPE) routers continue to exhibit a high usage rate of IEEE EUI-64 addresses, constituting an often-overlooked privacy risk. This document aims to update the statistics and analysis regarding IID pattern distribution found in RFC 7707, providing essential insights for modern network defense strategies and standard compliance. |
| | A whitelist-based data fencing mechanism in data circulation |
| |
|
This document defines the data transaction permission fields within the Data Fencing architecture and the whitelist information maintained by the gateway devices. By comparing the data transaction permission fields against the whitelist, data packets are either permitted or blocked, establishing precise data flow boundaries and egress control. Finally, the document presents several use cases of the data fencing. |
| | 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. |
| |
|
| |
| | 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 ("Internet Calendaring and Scheduling Core Object Specification (iCalendar)"). |
| | 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. |
| | YANG Data Model for FlexE Management |
| |
| | draft-ietf-ccamp-flexe-yang-cm-07.txt |
| | Date: |
05/12/2025 |
| | Authors: |
Minxue Wang, Liuyan Han, Xuesong Geng, Jin Zhou, Luis Contreras, Xufeng Liu |
| | Working Group: |
Common Control and Measurement Plane (ccamp) |
|
This document defines a service provider targeted YANG data model for the configuration and management of a Flex Ethernet (FlexE) network, including FlexE group and FlexE client. The YANG module in this document conforms to the Network Management Datastore Architecture (NMDA). |
| | Template-Driven HTTP CONNECT Proxying for TCP |
| |
|
TCP proxying using HTTP CONNECT has long been part of the core HTTP specification. However, this proxying functionality has several important deficiencies in modern HTTP environments. This specification defines an alternative HTTP proxy service configuration for TCP connections. This configuration is described by a URI Template, similar to the CONNECT-UDP and CONNECT-IP protocols. |
| | BGP Dissemination of Flow Specification Rules for Tunneled Traffic |
| |
|
This draft specifies a Border Gateway Protocol (BGP) Network Layer Reachability Information (NLRI) encoding format for flow specifications (RFC 8955) that can match on a variety of tunneled traffic. In addition, flow specification components are specified for certain tunneling header fields. |
| | 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 guidelines and facilitate their consistent implementation with chairs and administrators. |
| | 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. |
| | Enhanced Alternate Marking Method |
| |
|
This document extends the IPv6 Alternate Marking Option to provide enhanced capabilities and allow advanced functionalities. With this extension, it can be possible to perform thicker packet loss measurements and more dense delay measurements with no limitation for the number of concurrent flows under monitoring. |
| | Issue in Route Origin Validation from Route Partial Visibility |
| |
|
In the Resource Public Key Infrastructure (RPKI), validating prefix- origin pairs using Route Origin Authorizations (ROAs) globally and performing Route Origin Validation (ROV) locally at each Autonomous System (AS) with validated ROA payloads (VRPs) can lead to inconsistent results due to partial route visibility. This document highlights how partial route visibility can turn originally non-loose ROAs into loose VRPs, outlines the causes of partial route visibility, and discusses potential solutions to mitigate the issue. |
| | TESLA Update for GNSS SBAS Authentication |
| |
|
This document updates TESLA [RFC4082] to current cryptographic methods leveraging the work done by the International Civil Aviation Organization (ICAO) in their Global Navigation Satellite System (GNSS) Satellite-based augmentation system (SBAS) authentication protocol. The TESLA updates are to align to this and other current best practices. |
| | RESTful Provisioning Protocol (RPP) - Requirements |
| |
|
This document describes the requirements for the development of the RESTful Provisioning Protocol (RPP). |
| | Circuit Style Segment Routing Policy |
| |
| | draft-ietf-spring-cs-sr-policy-13.txt |
| | Date: |
05/12/2025 |
| | 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). |
| |
|
| |
| | Usage Limits on AEAD Algorithms |
| |
|
An Authenticated Encryption with Associated Data (AEAD) algorithm provides confidentiality and integrity. Excessive use of the same key can give an attacker advantages in breaking these properties. This document provides simple guidance for users of common AEAD functions about how to limit the use of keys in order to bound the advantage given to an attacker. It considers limits in both single- and multi-key settings. |
| | Mobility-aware Transport Network Slicing for 5G |
| |
| | draft-ietf-dmm-tn-aware-mobility-24.txt |
| | Date: |
04/12/2025 |
| | Authors: |
Uma Chunduri, John Kaippallimalil, Sridhar Bhaskaran, Jeff Tantsura, Luis Contreras |
| | Working Group: |
Distributed Mobility Management (dmm) |
|
Network slicing in 5G enables logical networks for communication services of multiple 5G customers to be multiplexed over the same infrastructure. While 5G slicing covers logical separation of various aspects of 5G infrastructure and services, user's data plane packets over the Radio Access Network (RAN) and Core Network (5GC) use IP in many segments of an end-to-end 5G slice. When end-to-end slices in a 5G System use network resources, they are mapped to corresponding Transport Network (TN) slice(s) which in turn provide the bandwidth, latency, isolation, and other criteria required for the realization of a 5G slice. This document describes mapping of 5G slices to TN slices using UDP source port number of the GTP-U bearer when the TN slice provider is separated by an "attachment circuit" from the networks in which the 5G network functions are deployed, for example, 5G functions that are distributed across data centers. The slice mapping defined here is supported transparently when a 5G user device moves across 5G attachment points and session anchors. |
| | Simple Two-way Active Measurement Protocol (STAMP) for MPLS Label Switched Paths (LSPs) |
| |
| | draft-ietf-mpls-stamp-00.txt |
| | Date: |
04/12/2025 |
| | Authors: |
Greg Mirsky, Li Zhang, Loa Andersson |
| | Working Group: |
Multiprotocol Label Switching (mpls) |
|
Simple Two-way Active Measurement Protocol (STAMP), defined in RFC 8762 and RFC 8972, is expected to be able to monitor the performance of paths between systems that use a wide variety of encapsulations. This document defines encapsulation and bootstrapping of a STAMP test session over an MPLS Label Switched Path. |
| | A YANG Data Model for RESTCONF Clients and Servers |
| |
|
This document presents two YANG modules, one module to configure a RESTCONF client and the other module to configure a RESTCONF server. These modules support both standard and RESTCONF Call Home connections. |
| | A YANG Data Model for NETCONF Clients and Servers |
| |
|
This document presents two YANG modules, one module to configure a NETCONF client and the other module to configure a NETCONF server. These modules support both the SSH and TLS transport protocols, and support both standard NETCONF and NETCONF Call Home connections. |
| | SCION Control Plane |
| |
|
This document describes the Control 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 that can choose between multiple path options, thereby enabling the optimization of network paths. The Control Plane is responsible for discovering these paths and making them available to the endpoints. The SCION Control Plane creates and securely disseminates path segments between SCION Autonomous Systems (AS) which can then be combined into forwarding paths to transmit packets in the data plane. This document describes mechanisms of path exploration through beaconing and path registration. In addition, it describes how Endpoints construct end-to-end paths from a set of possible path segments through a path lookup process. 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. |
| | JSON Structure: Core |
| |
|
This document specifies JSON Structure, a data structure definition language that enforces strict typing, modularity, and determinism. JSON Structure describes JSON-encoded data such that mapping to and from programming languages and databases and other data formats is straightforward. |
| | JSON Structure: Import |
| |
|
This document specifies the $import and $importdefs keywords as extensions to JSON Structure Core. These keywords allow a schema to import definitions from external schema documents. |
| | JSON Structure: Alternate Names and Descriptions |
| |
|
This document is an extension to JSON Structure Core. It defines three annotation keywords, altnames, altenums, and descriptions, which allow schema authors to provide alternative identifiers, display names, and multi-variant descriptions for types, properties, and enumeration values. |
| | JSON Structure: Symbols,Scientific Units,and Currencies |
| |
|
This document specifies "JSON Structure Symbols, Scientific Units, and Currencies", an extension to JSON Structure Core. This specification defines a set of annotation keywords for associating scientific unit and currency metadata and constraints, primarily for use with numeric values. JSON Structure Scientific Units provides a mechanism for schema authors to explicitly declare the unit associated with numeric data, thereby enabling precise mapping between schema representations and external data systems. |
| | JSON Structure: Validation Extensions |
| |
|
The JSON Structure Validation extension provides schema authors with additional means to constrain instance data. These keywords are applied in conjunction with the constructs defined in JSON Structure Core. The keywords defined herein include numeric, string, array, and object validation keywords as well as conditional validations. |
| | JSON Structure: Conditional Composition |
| |
|
This document specifies JSON Structure Conditional Composition, an extension to JSON Structure Core that introduces composition constructs for combining multiple schema definitions. In particular, this specification defines the semantics, syntax, and constraints for the keywords allOf, anyOf, oneOf, and not, as well as the if/then/ else conditional construct. |
| | A YANG Data Model for Attachment Circuit as a Service with UDP Tunnel Support |
| |
|
Delivery of network services over a Layer 3 tunnel assumes that the appropriate setup is provisioned over links that connect the customer termination points and provider network. The required setup to allow successful data exchange over these links is referred to as an attachment circuit (AC) while the underlying link for carrying network services is referred to as "bearer", in this case a Layer 3 UDP tunnel. This document specifies an extension for UDP tunnel as Layer 3 bearer to the YANG service data model for AC. |
| | Concluding the ARC Experiment |
| |
|
This document calls for a conclusion to the experiment defined by “The Authenticated Received Chain (ARC) Protocol,” (RFC8617) and recommends that ARC no longer be deployed or relied upon between disparate senders and receivers. The document summarizes what ARC set out to do, reports on operational experience, and explains how the experience gained during the experiment is being incorporated into the proposed DKIM2 work as the successor to DomainKeys Identified Mail (DKIM). To avoid any future confusion, it is therefore requested that ARC (RFC8617) be marked “Obsolete” by the publication of this Internet-Draft. |
| | 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. |
| | PCEP Extensions for Computing-Aware Traffic Steering (CATS) Service |
| |
|
The CATS (Computing-Aware Traffic Steering) can steer traffic between clients of a service and sites offering the service. The C-PS may be deployed as a PCE and the ingress CATS-Router could be viewed as a PCC. This document proposes the PCEP extensions for selecting and distributing the paths for CATS services. |
| | Automated Discovery Of Audit Reports (audits.json) |
| |
|
This document describes a mechanism that an organization can use to enable automatic discovery of documents associated with regulatory compliance. It is motivated by regulations that require, for example, publicly accessible audits of automated decision-making processes in hiring. |
| | Phi-Ns Cryptosystem |
| |
|
This document describes Phi-Ns, a new asymmetric cryptographic primitive based on the structured decomposition of the quadratic gap between two primes. Phi-Ns defines a public key q and a private key p such that the difference q^2 - p^2 is expressed as a composite value T. The value T is then factored into small controlled components noted a, b, and R, and the final secret structure abR is encoded through a randomized serialization process. The security of Phi-Ns does not rely on integer factorization, the discrete logarithm problem, or elliptic curves. Instead, it depends on the difficulty of recovering p from q when the attacker has no oracle, no structural anchor, and no method to determine whether a candidate p is correct. Because T can be recursively decomposed and reassembled into multiple unpredictable forms, the resulting search space grows combinatorially. Phi-Ns further supports recursive expansion of the internal abR structure, allowing the construction of high-entropy secret states even when p and q have relatively small bit lengths. This enables compact public keys, efficient computation, and strong post-quantum resistance based on a non-factorization hardness assumption. This document specifies the algorithmic model of Phi-Ns, its parameter choices, and the serialization rules used to encode the abR structure. It also outlines two public-key variants, PK-p and PK-q, which expose either p or q as the public value depending on deployment constraints. |
| | Link-Layer Types for PCAP-related Capture File Formats |
| |
|
This document describes a set of Packet CAPture (PCAP)-related LinkType values and creates an IANA registry for those values. These values are used by the PCAP and PCAP-Now-Generic specifications. |
| | RDAP Extensions |
| |
|
This document describes and clarifies the usage of extensions in RDAP. |
| | A Profile for Resource Public Key Infrastructure (RPKI) Canonical Cache Representation (CCR) |
| |
|
This document specifies a Canonical Cache Representation (CCR) content type for use with the Resource Public Key Infrastructure (RPKI). CCR is a DER-encoded data interchange format which can be used to represent various aspects of the state of a validated cache at a particular point in time. The CCR profile is a compact and versatile format well-suited for a diverse set of applications such as audit trail keeping, validated payload dissemination, and analytics pipelines. |
| | The Erik Synchronization Protocol for use with the Resource Public Key Infrastructure (RPKI) |
| |
|
This document specifies the Erik Synchronization Protocol for use with the Resource Public Key Infrastructure (RPKI). Erik Synchronization can be characterized as a data replication system using Merkle trees, a content-addressable naming scheme, concurrency control using monotonically increasing sequence numbers, and HTTP transport. Relying Parties can combine information retrieved via Erik Synchronization with other RPKI transport protocols. The protocol's design is intended to be efficient, fast, easy to implement, and robust in the face of partitions or faults in the network. |
| |
|
| |
| | IPv6 Query 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 IPv6 networks. IPv6 Node IOAM Request uses the IPv6 Node Information messages, allowing the IOAM encapsulating node to discover the enabled IOAM capabilities of each IOAM transit and IOAM decapsulating node. This document updates RFCs 4620 and 4884. |
| | RTP payload format for APV |
| |
| | draft-ietf-avtcore-rtp-apv-00.txt |
| | Date: |
03/12/2025 |
| | Authors: |
Youngkwon Lim, Minwoo Park, Madhukar Budagavi, Rajan Joshi, Kwang Choi |
| | Working Group: |
Audio/Video Transport Core Maintenance (avtcore) |
|
This document describes RTP payload format for bitstream encoded with Advanced Professional Video (APV) codec. |
| | Advanced BGP Monitoring Protocol (BMP) Statistics Types |
| |
|
RFC 7854 defines different BGP Monitoring Protocol (BMP) statistics message types to observe events that occur on a monitored router. This document defines new statistics type to monitor BMP Adj-RIB-In and Adj-RIB-Out Routing Information Bases (RIBs). |
| | MP-BGP Extension and the Procedures for IPv4/IPv6 Mapping Advertisement |
| |
|
This document defines MP-BGP extension and the procedures for IPv4 service delivery in multi-domain IPv6-only underlay networks. It defines a new TLV in the BGP Tunnel Encapsulation attribute, used in conjunction with a specific AFI/SAFI combination for advertising IPv4-over-IPv6 mapping rules. The behaviors of each type of network (IPv4 and IPv6) are also illustrated. In addition, this document provides the deployment and operation considerations when the extension is deployed. |
| | Composite ML-KEM for use in X.509 Public Key Infrastructure |
| |
| | draft-ietf-lamps-pq-composite-kem-11.txt |
| | Date: |
03/12/2025 |
| | 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 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. |
| | Distribute SRv6 Locator by IPv6 Stateless Address Autoconfiguration |
| |
|
In an SRv6 network, each SRv6 Segment Endpoint Node must be assigned an SRv6 locator, and segment IDs are generated within the address space of this SRv6 locator. This document describes a method for assigning SRv6 locators to SRv6 Segment Endpoint Nodes through IPv6 stateless address autoconfiguration. |
| | Consolidated Parameters Part for Multipart/Form-Data |
| |
|
This document describes a deployment pattern for reducing overhead in multipart/form-data requests that include both file uploads and numerous text parameters. The approach consolidates multiple text fields into one or more application/x-www-form-urlencoded parts inside the multipart body. This technique requires no changes to existing HTTP, MIME, or form specifications and is fully compatible with RFC 7578. It uses only existing, standardized Content-Type values in their already-defined manner, making it immediately deployable with current infrastructure. The pattern guarantees backward compatibility: servers that don't recognize it still receive all parameters as standard form data. RFC 7578 defines multipart/form-data but does not specify optimization strategies; this document fills that gap. This document records the pattern, processing rules, and deployment considerations, and reports implementation experience from production systems processing millions of uploads daily. |
| | High-Assurance Execution Environment (HAE) for Secure Approval |
| |
|
This document specifies the High-Assurance Execution Environment (HAE), a trusted, ephemeral approval environment designed to protect the authorization of high-risk digital and physical actions. |
| | PRE-RCT: Pre-Execution Authorization Receipt Format |
| |
|
This document defines PRE-RCT, the Pre-Execution Authorization Receipt, a cryptographically signed and attestation-aware receipt format used to record high-risk authorization events. PRE-RCT is intended for use with pre-execution authorization protocols such as GNA. |
| | HTTP Bearer Auth Method Extensions |
| |
|
This document specifies an improved HTTP 401 and 407 flow for Bearer authentication where user-agents (or client applications) can automatically fetch requested tokens from a Security Token Service (STS). A fallback to an OpenID Connect (OIDC) redirect flow is included. This improved 401/407 Bearer flow, when used, elides the need for Proof Key for Code Exchange (PKCE) and does not impose on application Universal Resource Identifier (URI) query parameter design. As well this extension allows for user-agent caching of tokens. |
| | Metadata Constrained Distribution |
| |
|
This document specifies a receiver-driven _Metadata Subscription_ (MDS) mechanism for BGP. A BGP speaker uses the new MDS NLRI to subscribe to specific service metadata attributes. |
| | OAuth 2.0 for Browser-Based Applications |
| |
|
This specification details the threats, attack consequences, security considerations and best practices that must be taken into account when developing browser-based applications that use OAuth 2.0. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Web Authorization Protocol Working Group mailing list (oauth@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/oauth/. Source for this draft and an issue tracker can be found at https://github.com/oauth-wg/oauth-browser-based-apps. |
| | A Taxonomy of operational security considerations for manufacturer installed keys and Trust Anchors |
| |
|
This document provides a taxonomy of methods used by manufacturers of silicon and devices to secure private keys and public trust anchors. This deals with two related activities: how trust anchors and private keys are installed into devices during manufacturing, and how the related manufacturer held private keys are secured against disclosure. This document does not evaluate the different mechanisms, but rather just serves to name them in a consistent manner in order to aid in communication. |
| |
|
| |
| | An Application Layer Interface for Non-Internet-Connected Physical Components (NIPC) |
| |
| | draft-ietf-asdf-nipc-15.txt |
| | Date: |
02/12/2025 |
| | 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. |
| | 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 IP and non-IP protocols such as Bluetooth Low Energy, Zigbee or HTTP and CoAP. |
| | COSE (CBOR Object Signing and Encryption) Receipts |
| |
|
COSE (CBOR Object Signing and Encryption) Receipts prove properties of a verifiable data structure to a verifier. Verifiable data structures and associated proof types enable security properties, such as minimal disclosure, transparency and non-equivocation. Transparency helps maintain trust over time, and has been applied to certificates, end to end encrypted messaging systems, and supply chain security. This specification enables concise transparency oriented systems, by building on CBOR (Concise Binary Object Representation) and COSE. The extensibility of the approach is demonstrated by providing CBOR encodings for Merkle inclusion and consistency proofs. |
| | An Architecture for DNS-Bound Client and Sender Identities |
| |
| | draft-ietf-dance-architecture-10.txt |
| | Date: |
02/12/2025 |
| | Authors: |
Ash Wilson, Shumon Huque, Olle Johansson, Michael Richardson |
| | Working Group: |
DANE Authentication for Network Clients Everywhere (dance) |
|
This architecture document defines terminology, interaction, and authentication patterns, related to the use of DANE DNS records for TLS client and messaging peer identity, within the context of existing object security and TLS-based protocols. |
| | Validating anydata in YANG Library context |
| |
|
This document describes a method to use YANG RFC 8525 and standard YANG validation rules in RFC 7950 to validate YANG data nodes that are children of an "anydata" data node. |
| | Transient Hiding of Hop-by-Hop Options |
| |
|
There are an increasing number of IPv6 hop-by-hop options specified but such IPv6 options are poorly handled, particularly by high-speed routers in the core Internet where packets having options may be discarded. This document proposes a simple method of transiently hiding such options for part of a packet's path to protect the packet from discard or mishandling. |
| | Fast Congestion Notification Packet (CNP) in RoCEv2 Networks |
| |
|
This document describes a Remote Direct Memory Access (RDMA) over Converged Ethernet version 2 (RoCEv2) congestion control mechanism, which is inspired by Really Explicit Congestion Notification (RECN) described in RFC 7514, also known as Fast Congestion Notification Packet (Fast CNP). By extending the RoCEv2 CNP, Fast CNP can be sent by the switch directly to the sender, advising the sender to reduce the transmission rate at which it sends the flow of RoCEv2 data traffic. |
| | Domain Transfer Authorization Using Cryptographic Signatures |
| |
|
This document specifies a mechanism to enhance domain transfer security by transitioning from a shared-secret authorization model to a asymmetric cryptographic signature-based validation system. Using asymmetric cryptographic signatures enables many benefits over a shared secret, such as non-repudiation, improved auditability through clear identification of the authorizing entity, elimination of the need for registries to store and secure shared secrets, replay protection through timestamp validation, and reduced risk of interception since only the private key needs to remain secret. This document establishes the following AuthCodeSEC extension of EPP with the following protocol elements: |
| | Module-Lattice Key Exchange in SSH |
| |
|
This document defines pure post-quantum key exchange methods based on Module-lattice post-quantum key encapsulation schemes for use in the SSH Transport Layer Protocol. |
| | Export of Encapsulation Layer Information in IPFIX |
| |
|
This document introduces new IPFIX IEs for encapsulation layer indication to help with the scenario when monitoring flow with multi- layer network encapsulations. |
| | Revision to Locally Served DNS Zones Registry |
| |
|
RFC 6063, "Locally Served DNS Zones", defines two IANA registries called "IPv4 Locally-Served DNS Zone Registry" and "IPv6 Locally- Served DNS Zone Registry". This document changes the registration procedure for that registry from "IETF Review" to "Expert Review". This document updates RFC 6063. |
| | Extended Key Usage and Mutual TLS in EPP |
| |
|
This document describes the state of the Mutual Transport Layer Security (mTLS) client authentication mechanism in the Extensible Provisioning Protocol (EPP) with respect to a recent change in the client certificates published by some Certificate Authorities (CAs). The issue is described and options are presented to address the operational impact of the change. |
| | GuardNet Authorization Protocol (GNA): Pre-Execution Authorization for High-Risk Digital Actions |
| |
|
This document specifies the GuardNet Authorization Protocol (GNA), a pre-execution authorization framework for high-risk digital and physical actions. GNA defines an enforcement model in which sensitive operations (for example, payments, administrative changes, OT/ICS commands, and AI-initiated actions) are intercepted before execution, evaluated against policy and context, routed to one or more authenticated approvers, and executed only after a valid authorization token is issued. GNA provides non-repudiable authorization receipts and is designed to integrate with existing identity providers and logging systems without requiring architectural changes. The protocol provides stronger authorization guarantees using digital signatures and contextual decisioning and is intended as a complement to, not a replacement for, existing authentication and monitoring systems. |
| | GuardMail Protocol (GMP): Authenticated Messaging with Non-Repudiable Cryptographic Receipts |
| |
|
This document specifies the GuardMail Protocol (GMP), a framework for authenticated outbound messaging that provides cryptographic proof of origin, integrity, and policy compliance for email and file-based communications. GMP introduces GuardMail Receipts (GMRs), signed metadata structures bound to sender identity and message content that allow recipients to verify authenticity independent of transport mechanisms such as SPF, DKIM, and DMARC. GMP provides a modern, interoperable method for organizations to protect against impersonation, deepfake-based fraud, unauthorized content changes, and spoofed internal communications in enterprise environments. |
| | SRv6 Path Egress Protection |
| |
|
TI-LFA specifies fast protections for transit nodes and links of an SR path. However, it does not present any fast protections for the egress node of the SR path. This document describes protocol extensions for fast protecting the egress node and link of a Segment Routing for IPv6 (SRv6) path. The solution uses IGP extensions and a Mirror SID (End.M) behavior to steer traffic to a protector egress upon failure of the primary egress. This document operates within a single link-state IGP area/level and uses IS-IS/OSPFv3 to advertise a Mirror SID and the protected locators for egress node/link protection. While the mechanism can protect traffic whose active segment at the egress is a Service SID (e.g., VPN SID), it is not suitable for large-scale deployments with a high cardinality of VPN/service instances or random multi-homing patterns, because the amount of egress-protection information to be flooded in the IGP increases and may impact convergence and control- plane load. |
| | Change Publication Server used by an RPKI CA |
| |
|
This document outlines how an RPKI CA can migrate from one RFC 8181 Publication Server to another. The process is similar to the RPKI CA Key Rollover process defined in RFC 6489, except that in this case a new location is used for the new key. |
| | Legacy RSASSA-PKCS1-v1_5 codepoints for TLS 1.3 |
| |
|
This document allocates code points for the use of RSASSA-PKCS1-v1_5 with client certificates in TLS 1.3. This removes an obstacle for some deployments to migrate to TLS 1.3. |
| |
|
| |
| | A Vocabulary For Expressing AI Usage Preferences |
| |
|
This document defines a vocabulary for expressing preferences regarding how digital assets are used by automated processing systems. This vocabulary allows for the declaration of restrictions or permissions for use of digital assets by such systems. |
| | A YANG Data Model for Optical Transport Network (OTN) Tunnels and Label Switched Paths |
| |
|
This document describes the YANG data model for tunnels in OTN TE networks. The model can be used to do the configuration in order to establish the tunnel in OTN network. This work is independent with the control plane protocols. |
| | Media Type Registration for Protocol Buffers |
| |
|
This document registers media types for Protocol Buffers, a common extensible mechanism for serializing structured data. |
| | Cookies: HTTP State Management Mechanism |
| |
|
This document defines the HTTP Cookie and Set-Cookie header fields. These header fields can be used by HTTP servers to store state (called cookies) at HTTP user agents, letting the servers maintain a stateful session over the mostly stateless HTTP protocol. Although cookies have many historical flaws that degrade their security and privacy, the Cookie and Set-Cookie header fields are widely used on the Internet. This document obsoletes RFC 6265. |
| | CMSF- a CMAF compliant implementation of MOQT Streaming Format |
| |
|
This document updates [MSF] by defining a new optional feature for the streaming format. It specifies the syntax and semantics for adding CMAF-packaged media [CMAF] to MSF. |
| | MPLS Network Action (MNA) Sub-Stack Solution |
| |
| | draft-ietf-mpls-mna-hdr-17.txt |
| | Date: |
01/12/2025 |
| | Authors: |
Jaganbabu Rajamanickam, Rakesh Gandhi, Royi Zigler, Haoyu Song, Kireeti Kompella |
| | Working Group: |
Multiprotocol Label Switching (mpls) |
|
This document defines the MPLS Network Actions (MNA) sub-stack solution for carrying Network Actions and Ancillary Data in the MPLS label stack. MNA can be used to influence packet forwarding decisions, carry additional Operations, Administration, and Maintenance information in the MPLS packet or perform user-defined operations. The solution specified in this document addresses the requirements for In-stack network action and In-stack data found in RFC 9613. This document follows the architectural framework for the MNA technologies specified in RFC 9789. |
| | SRv6 Bitmap Multicast |
| |
|
Multicast forwarding in a network provides advantages in improving the network usage and performance. In some cases it helps improve the operations in managing network. The major challenge in multicast operations is in managing the per-flow states in the network as required by all the legacy multicast frameworks. This document specifies a bitmap forwarding extension to SRv6 to support state-free forwarding model in a network. |
| | 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. |
| | Data Model for Computing-Aware Traffic Steering (CATS) |
| |
| | draft-yl-cats-data-model-05.txt |
| | Date: |
01/12/2025 |
| | Authors: |
Huijuan Yao, Changwang Lin, Zhenqiang Li, Quan Xiong, Luis Contreras |
| | Working Group: |
Individual Submissions (none) |
|
This document defines a YANG data model for the configuration and management of Computing-Aware Traffic Steering (CATS) systems. The YANG module defined in this document conforms to the Network Management Datastore Architecture (NMDA). |
| | 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. |
| | Post-Quantum Guidance for current deployments of IETF protocols. |
| |
|
We provide guidance on the use of post-quantum algorithms for those currently deploying applications using IETF protocols with support for such algorithms. |
| | Information Element for Flow Discard Classification |
| |
|
This document defines an IPFIX Information Element for classifying flow-level discards that aligns with the information model defined in [I-D.ietf-opsawg-discardmodel]. The flowDiscardClass Information Element provides consistent classification of packet discards across IPFIX implementations, enabling correlation between device, interface and control-plane discards and the impacted flows. |
| | EVPN-Specific BMP RIB Statistics Extensions |
| |
|
This document defines new EVPN-specific BGP Monitoring Protocol (BMP) statistics types. These extensions include scalar counters for EVPN route types specifically, while also keeping scope for defining counters which are EVPN route-type agnostic but related to BGP-EVPN RIB like, number of multihoming Ethernet Segments, number of multihomed EVIs, number of aliased paths, number of dynamic inter-VRF route leaking (IVRL). |
| | CMSF- a CMAF compliant implementation of MOQT Streaming Format |
| |
|
This document updates [MSF] by defining a new optional feature for the streaming format. It specifies the syntax and semantics for adding CMAF-packaged media [CMAF] to MSF. |
| | BGP Deterministic Path Forwarding (DPF) |
| |
| | draft-wang-idr-dpf-00.txt |
| | Date: |
01/12/2025 |
| | Authors: |
Kevin Wang, Michal Styszynski, W. Lin, Mahesh Subramaniam, Thomas Kampa, Diptanshu Singh |
| | Working Group: |
Individual Submissions (none) |
|
Modern data center (DC) fabrics typically employ Clos topologies with External BGP (EBGP) for plain IPv4/IPv6 routing. While hop-by-hop EBGP routing is simple and scalable, it provides only a single best- effort forwarding service for all types of traffic. This single best-effort service might be insufficient for increasingly diverse traffic requirements in modern DC environments. For example, loss and latency sensitive AI/ML flows may demand stronger Service Level Agreements (SLA) than general purpose traffic. Duplication schemes which are standardized through protocols such as Parallel Redundancy Protocol (PRP) require disjoint forwarding paths to avoid single points of failure. Congestion avoidance may require more deterministic forwarding behavior. This document introduces BGP Deterministic Path Forwarding (DPF), a mechanism that partitions the physical fabric into multiple logical fabrics. Flows can be mapped to different logical fabrics based on their specific requirements, enabling deterministic forwarding behavior within the data center. |
| | Updates to OAuth 2.0 Security Best Current Practice |
| |
|
This document updates the set of best current security practices for OAuth 2.0 by extending the security advice given in RFC 6749, RFC 6750, and RFC 9700, to cover new threats that have been discovered since the former documents have been published. |
| | OAuth SPIFFE Client Authentication |
| |
|
This specification profiles the Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants [RFC7521] and JWT Profile for OAuth 2.0 Client Authentication and Authorization Grants [RFC7523] to enable the use of SPIFFE Verifiable Identity Documents (SVIDs) as client credentials in OAuth 2.0. It defines how OAuth clients with SPIFFE credentials can authenticate to OAuth authorization servers using their JWT-SVIDs or X.509-SVIDs without the need for client secrets. This approach enhances security by enabling seamless integration between SPIFFE-enabled workloads and OAuth authorization servers while eliminating the need to distribute and manage shared secrets such as static client secrets. |
| | The "_for-sale" Underscored and Globally Scoped DNS Node Name |
| |
|
This document defines an operational convention that uses the reserved underscored DNS leaf node name "_for-sale" to indicate that the parent domain name is available for purchase. The convention can be deployed without disrupting existing operations, and it may be applied even when the domain name is still actively in use. |
| | Path Computation Element Communication Protocol (PCEP) Extensions for Associated Bidirectional Segment Routing (SR) Paths |
| |
|
The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Clients (PCCs) requests. Segment Routing (SR) leverages the source routing and tunneling paradigms. The Stateful PCEP extensions allow stateful control of Segment Routing Traffic Engineering (TE) paths. Furthermore, PCEP can be used to allow a PCE to compute SR TE paths in the network. This document defines PCEP extensions for grouping two unidirectional SR paths (one in each direction in the network) into a single associated bidirectional SR path. The mechanisms defined in this document are applicable to both stateless and stateful PCEs for PCE- initiated and PCC-initiated LSPs. |
| | The Internet Standards Process |
| |
|
This memo documents the process used by the Internet community for the standardization of protocols and procedures. It defines the stages in the standardization process, the requirements for moving a document between stages and the types of documents used during this process. It also addresses the intellectual property rights and copyright issues associated with the standards process. This document obsoletes RFC 2026, RFC 5657, RFC 6410, RFC 7100, RFC 7127, RFC 8789, and RFC 9282. It also includes the changes from RFC 7475. If this document and [_2418bis] are published as RFCs, then taken together the two of them make RFC 7475 obsolete. |
| | RDAP Extension for DNS Time-To-Live (TTL Values) |
| |
|
This document describes an extension to the Registration Data Access Protocol ([RFC9083]) which allows the Time-To-Live (TTL) values for relevant DNS record types to be included in RDAP responses. About this draft This note is to be removed before publishing as an RFC. The source for this draft, and an issue tracker, may can be found at https://github.com/gbxyz/rdap-ttl-extension. |
| | Static Context Header Compression (SCHC) for the Constrained Application Protocol (CoAP) |
| |
| | draft-ietf-schc-8824-update-07.txt |
| | Date: |
01/12/2025 |
| | Authors: |
Marco Tiloca, Laurent Toutain, Ivan Martinez, Ana Minaburo |
| | Working Group: |
Static Context Header Compression (schc) |
|
This document defines how to compress Constrained Application Protocol (CoAP) headers using the Static Context Header Compression and fragmentation (SCHC) framework. SCHC defines a header compression mechanism adapted for constrained devices. SCHC uses a static description of the header to reduce the header's redundancy and size. While RFC 8724 describes the SCHC compression and fragmentation framework and its application for IPv6 and UDP headers, this document applies SCHC to CoAP headers. The CoAP header structure differs from that of IPv6 and UDP headers, since CoAP uses a flexible header with a variable number of options that are in turn of variable length. The CoAP message format is asymmetric, i.e., request messages have a header format different from that of response messages. This specification gives guidance on applying SCHC to flexible headers and on leveraging the message format asymmetry for defining more efficient compression Rules. This document replaces and obsoletes RFC 8824. |
| | TCP ACK Rate Request Option |
| |
|
TCP Delayed Acknowledgments (ACKs) is a widely deployed mechanism that allows reducing protocol overhead in many scenarios. However, Delayed ACKs may also contribute to suboptimal performance. When a relatively large congestion window (cwnd) can be used, less frequent ACKs may be desirable. On the other hand, in relatively small cwnd scenarios, eliciting an immediate ACK may avoid unnecessary delays that may be incurred by the Delayed ACKs mechanism. This document specifies the TCP ACK Rate Request (TARR) option. This option allows a sender to request the ACK rate to be used by a receiver, and it also allows to request immediate ACKs from a receiver. |