| |
|
| |
| | 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. |
| | 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. |
| | 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. |
| | 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. |
| | 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. |
| | 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. |
| | 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. |
| |
|
| |
| | 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. |
| |
|
| |
| | 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. |
| | 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". |
| | 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. |
| | 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. |
| | 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). |
| |
|
| |
| | 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. |
| | 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. |
| |
|
| |
| | 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. |
| | 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. |
| |
|
| |
| | 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. |
| | 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. |
| |
|
| |
| | 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. |
| | 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. |
| | 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. |
| | 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. |
| | 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. |
| | 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. |
| | 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. |
| |
|
| |
| | Problems and Requirements of Addressing in Integrated Space-Terrestrial Network |
| |
|
This document presents a detailed analysis of the problems and requirements of network addressing in "Internet in space" for terrestrial users. It introduces the basics of satellite mega- constellations, terrestrial terminals/ground stations, and their inter-networking. Then it explicitly analyzes how space-terrestrial mobility yeilds challenges for the logical topology, addressing, and their impact on routing. The requirements of addressing in the space-terrestrial network are discussed in detail, including uniqueness, stability, locality, scalability, efficiency and backward compatibility with terrestrial Internet. The problems and requirements of network addressing in space-terrestrial networks are finally outlined. |
| | LISP-Based Network for AI Infrastructure |
| |
|
The Locator/Identifier Separation Protocol (LISP) control plane provides the mechanisms to support Scale-Up, Scale-Out and Scale- Across backend networks within AI infrastructure. This document describes how LISP enables a unified control plane architecture that accommodates different scaling technologies, offering flexibility in deployment. By leveraging lisp mechanisms including EID-to-RLOC- mapping/pxTR registrations, publication-subscription and VPN instance-based segmentation ([RFC9300][RFC9301][RFC9437][I-D.ietf- lisp-site-external-connectivity][I-D.ietf-lisp-vpn]), the architecture delivers scalable high bandwidth for large training workloads, ultra-low-latency collective operations, and a simplified control framework that seamlessly spans heterogeneous accelerator fabrics. This approach allows AI/ML applications (whether focused on training or inference) to run workloads efficiently with resiliency on a converged infrastructure, supporting diverse deployment scenarios using the same underlying network fabric. |
| | Export of Energy Consumption Information in IPFIX |
| |
|
This document introduces new IPFIX IEs for exporting energy consumption information of physical entities in a network device. New Information Elements are defined to report instantaneous and average energy consumption information at device, line-card, and port granularity. |
| |
|
| |
| | 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. |
| | 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. |
| | 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. |
| | 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. |
| | 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. |
| | 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 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. |
| | 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. |
| |
|
| |
| | 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. |
| | 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. |
| |
|
| |
| | 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. |
| | 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). |
| |
|
| |
| | 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. |
| | 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. |
| | 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. |
| | 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. |
| | 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. |
| |
|
| |
| | 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. |
| | 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. |
| | 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). |
| | 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). |
| | 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. |
| | 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. |