| |
|
| |
| | ACME End User Client and Code Signing Certificates |
| |
|
Automated Certificate Management Environment (ACME) core protocol addresses the use case of web server certificates for TLS. This document extends the ACME protocol to support service account authentication credentials, micro-service accounts credentials, device client, code signing, document signing certificates and keys. |
| | Operations,Administration and Maintenance (OAM) Requirements for Bit Index Explicit Replication (BIER) Layer |
| |
|
This document describes a list of functional requirements toward Operations, Administration and Maintenance (OAM) toolset in Bit Index Explicit Replication (BIER) layer of a network. |
| | Post-Quantum and Post-Quantum/Traditional Hybrid Algorithms for HPKE |
| |
|
Updating key exchange and public-key encryption protocols to resist attack by quantum computers is a high priority given the possibility of "harvest now, decrypt later" attacks. Hybrid Public Key Encryption (HPKE) is a widely-used public key encryption scheme based on combining a Key Encapsulation Mechanism (KEM), a Key Derivation Function (KDF), and an Authenticated Encryption with Associated Data (AEAD) scheme. In this document, we define KEM algorithms for HPKE based on both post-quantum KEMs and hybrid constructions of post- quantum KEMs with traditional KEMs, as well as a KDF based on SHA-3 that is suitable for use with these KEMs. When used with these algorithms, HPKE is resilient with respect to attacks by a quantum computer. |
| | 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. |
| | Internet X.509 Public Key Infrastructure: Algorithm Identifiers for SLH-DSA |
| |
| | draft-ietf-lamps-x509-slhdsa-09.txt |
| | Date: |
30/06/2025 |
| | Authors: |
Kaveh Bashiri, Scott Fluhrer, Stefan-Lukas Gazdag, Daniel Van Geest, Stavros Kousidis |
| | Working Group: |
Limited Additional Mechanisms for PKIX and SMIME (lamps) |
|
Digital signatures are used within X.509 Public Key Infrastructure such as X.509 certificates, Certificate Revocation Lists (CRLs), and to sign messages. This document specifies the conventions for using the Stateless Hash-Based Digital Signature Algorithm (SLH-DSA) in X.509 Public Key Infrastructure. The conventions for the associated signatures, subject public keys, and private keys are also specified. |
| | LISP Canonical Address Format (LCAF) |
| |
| | draft-ietf-lisp-rfc8060bis-01.txt |
| | Date: |
30/06/2025 |
| | Authors: |
Alvaro Retana, Dino Farinacci, David Meyer, Job Snijders |
| | Working Group: |
Locator/ID Separation Protocol (lisp) |
|
This document defines a canonical address format encoding used in Locator/ID Separation Protocol (LISP) control messages and in the encoding of lookup keys for the LISP Mapping Database System. This document obsoletes RFC 8060. |
| | NETCONF Transport Port Numbers |
| |
|
This document releases NETCONF-related port number IANA assignments that have not stood the test of time (e.g., assignments for Historic NETCONF-related protocols). Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Network Configuration Working Group mailing list (netconf@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/netconf/. Source for this draft and an issue tracker can be found at https://github.com/boucadair/netconf-port-numbers. |
| | Flexible Candidate Path Selection of SR Policy |
| |
|
This document proposes a flexible SR policy candidate path selection method. Based on the real-time resource usage and forwarding quality of candidate paths, the head node can perform dynamic path switching among multiple candidate paths in the SR policy. |
| | Intra-domain SAV Support via BGP |
| |
|
This document describes a method for publishing source prefixes via the BGP protocol, iterating through the SAV table entries based on intra-domain next hop SAV rules. The generation of intra-domain next hop SAV rules is implemented by the intra-domain IGP protocol, and the BGP protocol inherits the source interface list from its next hop SAV rules to generate the SAV rule table for source prefixes. |
| | BGP Flowspec for Computing-Aware Traffic Steering |
| |
|
A BGP Flow Specification is an n-tuple consisting of several matching criteria that can be applied to IP traffic. Computing-Aware Traffic Steering (CATS) is a framework which optimizes traffic steering to a given service instance by taking into account the dynamic nature of both computing and network resources. This document specifies a new BGP Flow Spec Component Type in order to support CATS traffic forwarding. |
| | End-to-end Security for Media over QUIC |
| |
|
The Media over QUIC system allows relays to assist in the delivery of real-time media. While these relays are trusted to facilitate media delivery, they are not trusted to access the media content. The document describes an end-to-end security system that prevents relays from accessing media content. MLS is used to establish keys that are available only to legitimate participants in a session, which are then used to protect media data using SFrame. |
| | Segment Routing Policy Extension for Network Resource Partition |
| |
| | draft-jiang-spring-sr-policy-nrp-03.txt |
| | Date: |
30/06/2025 |
| | Authors: |
1211176911910469110103, Ran Chen, Jie Dong, Changwang Lin, Ran Pang, KaZhang, wei gao, Jiang Wenying |
| | Working Group: |
Individual Submissions (none) |
|
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 describes how the SR Policy extension for associated NRP and the operational mechanisms function together. |
| | Data Model for Computing-Aware Traffic Steering (CATS) |
| |
| | draft-yl-cats-data-model-03.txt |
| | Date: |
30/06/2025 |
| | Authors: |
Huijuan Yao, Changwang Lin, Zhenqiang Li, Quan Xiong |
| | Working Group: |
Individual Submissions (none) |
|
This document defines a YANG data model for the configuration and management of Computing-Aware Traffic Steering (CATS) framework. The YANG module defined in this document conforms to the Network Management Datastore Architecture (NMDA). |
| | PCEP over QUIC |
| |
|
This document specifies the use of QUIC streams to implement the PCEP protocol for efficient and secure data transmission. |
| | Distributed Aggregation Protocol (DAP) Extensions for Improved Application of Differential Privacy |
| |
|
The Distributed Aggregation Protocol (DAP) can be a key component of a system that provides differentially-private guarantees for participants. Extensions to DAP are defined to support these guarantees. This includes bindings of reports to specific options, so that the aggregation service can better implement privacy budgeting and replay protections. |
| | HTTP Version Translation of the Capsule Protocol |
| |
|
This draft specifies how HTTP intermediaries can translate the Capsule Protocol between HTTP versions. 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-kb-capsule-conversion/. Source for this draft and an issue tracker can be found at https://github.com/bemasc/capsule-conversion. |
| | Enhancing ICMPv6 Error Message Authentication Using Challenge-Confirm Mechanism |
| |
|
The Internet Control Message Protocol for IPv6 (ICMPv6) is essential for network diagnostics but is vulnerable to off-path spoofing attacks, especially when error messages relate to stateless transport protocols like UDP. An attacker can forge these messages to degrade performance or enable Man-in-the-Middle attacks. This document explores solutions to this problem by first presenting a straightforward but flawed stateful challenge-response mechanism. It explains how this "strawman" approach, while preventing simple spoofing, introduces a severe vulnerability to state-exhaustion Denial-of-Service (DoS) attacks. Building on this analysis, the document then proposes a robust, stateless challenge-response mechanism inspired by TCP SYN-Cookies. This proposal eliminates the need to store per-challenge state by computationally generating challenges. It limits state management to minimal flags on existing sockets or a bounded probabilistic data structure. This approach effectively authenticates ICMPv6 error messages while inherently resisting both off-path spoofing and state- exhaustion DoS attacks, thus improving the robustness of ICMPv6. |
| | Amendments to Stateful PCE Communication Protocol (PCEP) |
| |
| | draft-many-pce-stateful-amendment-02.txt |
| | Date: |
30/06/2025 |
| | Authors: |
Andrew Stone, Mike Koldychev, Siva Sivabalan, Diego Achaval, Shuping Peng, Hari Kotni, Samuel Sidor |
| | Working Group: |
Individual Submissions (none) |
|
This document updates RFC8231 and RFC8664 to reflect operationalized implementations and define optimizations in the PCEP protocol. |
| | Decentralized Messaging Layer Security |
| |
|
Messaging Layer Security (MLS) provides strong end-to-end security guarantees for group messaging including Forward Secrecy (FS) and Post-Compromise Security (PCS). MLS requires a Delivery Service (DS) component to facilitate agreement between group members on the order of Commit messages. In decentralized settings without an authoritative entity to enforce ordering, group members will likely have to retain key material so they can process commits out-of-order. Retaining key material, however, significantly reduces the FS of the protocol. This draft specifies Decentralized MLS (DMLS), based on the the Fork-Resilient Continuous Group Key Agreement protocol FREEK proposed by Alwen et al. [FRCGKA]. In essence, DMLS extends MLS such that key material can be retained to process Commits out-of- order with recuded impact to FS, thus allowing safer deployment in decentralized environments. |
| | OAuth 2.0 client extension claims |
| |
|
This specification defines new claims for JWT profiled access tokens [RFC9068] so that resource providers can benefit from more granular information about the client: its authentication methods as well as the grant flow and the grant flow extensions used as part of the issuance of the associated tokens. |
| | OAuth 2.0 step-up authorization challenge proto |
| |
|
It is not uncommon for resource servers to require additional information like details of delegation authorization, or assurance proof of the delegation of authorization mechanism used according to the characteristics of a request. This document introduces a mechanism that resource servers can use to signal to a client that the data and metadata associated with the access token of the current request does not meet its authorization requirements and, further, how to meet them. This document also codifies a taxonomy to guide the client into starting a new request towards the authorization server in order to get issued, if applicable, a new set of tokens matching the requirements. |
| | Hybird Fordwarding of Computing-Aware Traffic Steering (CATS) |
| |
| | draft-fu-cats-hybrid-fwd-00.txt |
| | Date: |
30/06/2025 |
| | Authors: |
FUHUAKAI, Xinxin Yi, Bo Pang, Dongyu Yuan, Wei Duan, Chuanyang Miao |
| | Working Group: |
Individual Submissions (none) |
|
This document proposes a hybrid forwarding mechanism for CATS (Computing-Aware Traffic Steering). The mechanism integrates the CATS forwarding table with the IP forwarding table, optimizing the utilization of forwarding table capacity. By customizing the forwarding model based on service identifiers, it can accommodate both experience-sensitive and non-experience-sensitive services. Additionally, it supports flow-granularity load balancing, enhancing the utilization of computing and networking resources while ensuring differentiated service requirements are satisfied. |
| | Attesting the Identities of Parties in OpenID Connect (OIDC) using the Resource Public Key Infrastructure (RPKI) |
| |
|
The Peering API currently under discussion in the GROW Working Group does not provide a standardised mechanism to authenticate parties engaged in the Peering API. This document specifies a method to attest as to the identities of parties in an OpenID Connect (OIDC) exchange, binding the authentication flow to agents of ASNs. Discussion This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.molgen.mpg.de/q/rpki-peering-api-discovery. |
| | 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. |
| | Problem Statement for Cross-Layer Vulnerabilities due to Forged ICMP Errors |
| |
|
ICMP error messages are vital for network reliability, providing feedback on issues such as unreachable hosts or fragmentation requirements. They help devices adapt dynamically, support troubleshooting, and enable essential functions like Path MTU Discovery. However, off-path attackers on the Internet may forge ICMP error messages to bypass legitimate validation mechanisms, causing the victim's TCP/IP stack to misinterpret network conditions and exposing critical vulnerabilities. This document analyzes how such forged ICMP errors can be exploited by off-path attackers to induce cross-layer interactions within the victim's TCP/IP stack, leading to four classes of vulnerabilities: information leakage, desynchronization of shared variables, semantic gaps, and identity deception. These ICMP-based attacks allow off-path attackers to manipulate network traffic, disrupt communication flows, and compromise both infrastructure and user privacy, without being on the direct communication path. The document concludes with proposed countermeasures and recommendations for protocol evolution. |
| | DKIM2 Message Examples |
| |
|
This memo provides examples of how DKIM2 would apply to common email usage scenarios. |
| | Multipath Traffic Engineering for Segment Routing |
| |
|
This document describes a mechanism to achieve Multipath Traffic Engineering for Segment Routing based networks. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Source Packet Routing in Networking Working Group mailing list (spring@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/spring/. Source for this draft and an issue tracker can be found at https://github.com/astone282/draft-stone-spring-mpte-sr. |
| | Using ECN when Proxying UDP in HTTP |
| |
|
This document describes how to proxy the ECN bits when proxying UDP in HTTP. |
| | DIEM Use Cases and Requirements |
| |
|
The Digital Emblems (DIEM) working group (WG) will define an architecture and discovery mechanism to present and validate digital emblems. This document lists use cases for the current and future scope of the DIEM WG and their associated requirements. |
| | Further considerations on AI Agent Authentication and Authorization Based on OAuth 2.0 Extension |
| |
|
Agent Communication Network(ACN) is becoming a promising and fundamental infrastructure for most vertical industries. To construct and build a scalable and trustable ACN, authentication and authorization of AI agents are some of the most important issues that need to be solved. This document extends the model of OAuth 2.0 and proposes new workflows for AI agent authentication and authorization. |
| | CATS Reference Model for AI-Agent Communication Network |
| |
|
This draft describes the AI-agents along with the network to provide the communication services among various types of AI-agents, i.e., AI-agent Communication Network or ACN. Thanks to the CATS-like information flow steering in ACN, we propose a CATS reference model that covers the definition of reference points, protocol stacks, service provisioning model, sigaling procedures, message paths, and implementation schemes. This reference model is generalized so as to accommodate both the existing CATS framework and the potential extension for the ACN. |
| | Use Cases and Requirements of AI Agent Communication from 6G Aspect |
| |
|
AI Agent can do some tasks as an assistant to human beings. During the task process, the Agent may need to connect to other Agents with different skills relative to the task. The Agent to Agent communication is a new kind of traffic for Internet, and some new requirements for networking are proposed. This document talks about the requirements and key issues of global AI agent communication towards 6G. Some 6G related use cases from 3GPP documents are introduced. After that, the related requirements for the AI Agent Communication Network (ACN) are proposed, and potential ACN frameworks and standardization works for the AI Agent Communication are also discussed. |
| | Distributed AI Accountability Protocol (DAAP) Version 2.0 |
| |
|
This document specifies the Distributed AI Accountability Protocol (DAAP) version 2.0, an enhanced framework for authentication, monitoring, and control of autonomous AI agents. DAAP provides cryptographic identity verification, periodic check-ins, remote shutdown capabilities, adaptive location reporting, and behavioral monitoring. The protocol addresses critical challenges in AI safety including accountability gaps, rogue AI risks, and regulatory compliance through a multi-layered approach combining hardware-backed security, real-time monitoring, and ethical governance frameworks. |
| | Information and Data Models for Packet Discard Reporting |
| |
| | draft-ietf-opsawg-discardmodel-08.txt |
| | Date: |
30/06/2025 |
| | Authors: |
John Evans, Oleksandr Pylypenko, Jeffrey Haas, Aviran Kadosh, Mohamed Boucadair |
| | Working Group: |
Operations and Management Area Working Group (opsawg) |
|
This document defines an information model and a corresponding YANG data model for packet discard reporting. The information model provides an implementation-independent framework for classifying packet loss to enable automated network mitigation of unintended packet loss. The YANG data model specifies an implementation of this framework for network elements. |
| | PCEP Operational Clarification |
| |
| | draft-ietf-pce-operational-01.txt |
| | Date: |
30/06/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. |
| | P2MP Policy Ping |
| |
|
SR Point-to-Multipoint (P2MP) Policies are used to define and manage explicit P2MP paths within a network. These policies are typically calculated via a controller-based mechanisms and installed via a Path Computation Element (PCE). In other cases these policies can be installed manually via YANG modles or CLI. They are used to steer multicast traffic along optimized paths from a Root to a set of Leaf routers. This document defines extensions to Ping and Traceroute mechanisms for Segment Routing (SR) P2MP Policy with MPLS encapsulation to provide OAM (Operations, Administration, and Maintenance) capabilities. The proposed extensions enable operators to verify connectivity, diagnose failures and troubleshoot forwarding issues within P2MP Policy multicast trees. By introducing new mechanisms for detecting failures and validating path integrity, this document enhances the operational robustness of P2MP multicast deployments. Additionally, it ensures that existing MPLS and SR-based OAM tools can be effectively applied to networks utilizing P2MP Policies. |
| | RESTful Provisioning Protocol (RPP) - Requirements |
| |
|
This document describes the requirement for the development of the RESTful Provisioning Protocol (RPP). |
| | 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. |
| | A Non-Queue-Building Per-Hop Behavior (NQB PHB) for Differentiated Services |
| |
| | draft-ietf-tsvwg-nqb-30.txt |
| | Date: |
30/06/2025 |
| | Authors: |
Greg White, Thomas Fossati, Ruediger Geib |
| | Working Group: |
Transport and Services Working Group (tsvwg) |
|
This document specifies characteristics of a Non-Queue-Building Per- Hop Behavior (NQB PHB). The NQB PHB provides a shallow-buffered, best-effort service as a complement to a Default deep-buffered best- effort service for Internet services. The purpose of this NQB PHB is to provide a separate queue that enables smooth (i.e. non-bursty), low-data-rate, application-limited traffic microflows, which would ordinarily share a queue with bursty and capacity-seeking traffic, to avoid the latency, latency variation and loss caused by such traffic. This PHB is implemented without prioritization and can be implemented without rate policing, making it suitable for environments where the use of these features is restricted. The NQB PHB has been developed primarily for use by access network segments, where queuing delays and queuing loss caused by Queue-Building protocols are manifested, but its use is not limited to such segments. In particular, the application of NQ PHB to cable broadband links, Wi-Fi links, and mobile network radio and core segments are discussed. This document recommends a specific Differentiated Services Code Point (DSCP) to identify Non-Queue-Building microflows, and updates the RFC8325 guidance on mapping Diffserv to IEEE 802.11 for this codepoint. [NOTE (to be removed by RFC-Editor): This document references an ISE submission draft (I-D.briscoe-docsis-q-protection) that is approved for publication as an RFC. This draft should be held for publication until the queue protection RFC can be referenced.] |
| | Framework of Multi-domain IPv6-only Underlay Network and IPv4-as-a-Service |
| |
|
For the IPv6 transition, IPv6-only is considered as the final stage, where only IPv6 protocol is used for transport while maintaining global reachability for both IPv6 and IPv4 services. This document illustrates a framework of multi-domain IPv6-only underlay network from an operator's perspective. In particular, it proposes stateless address mapping as the base for enabling IPv4 service data transmission in an multi-domain IPv6-only environment(i.e.,IPv4-as- a-Service). It describes the methodology of stateless IPv4/IPv6 mapping, illustrates the behaviors of network devices, analyzes the options of IPv6 mapping prefix allocation, examines the utilization of SRv6, and discusses the security considerations. |
| |
|
| |
| | Constrained GeneRic Autonomic Signaling Protocol |
| |
|
This document proposes the UDP-based Constrained GeneRic Autonomic Signaling Protocol (cGRASP), which is designed to be a constrained and lightweight version of the GeneRic Autonomic Signaling Protocol(GRASP, or the standard GRASP), with shortened messages and a built-in reliability mechanism. cGRASP can work reliably over UDP, making it suitable for IoT, where lightweight and resource- constrained devices dominate. Given the established ecosystem of CoAP and aiming to promote cGRASP adoption in IoT, this document also focuses on the cGRASP transition from UDP to a CoAP-based framework, i.e., CoAP-based cGRASP. Furthermore, this document also discusses the potential way to adapt the cGRASP to work on the network without IP connectivity. |
| | Matroska Media Container Codec Specifications |
| |
| | draft-ietf-cellar-codec-15.txt |
| | Date: |
29/06/2025 |
| | Authors: |
Steve Lhomme, Moritz Bunkus, Dave Rice |
| | Working Group: |
Codec Encoding for LossLess Archiving and Realtime transmission (cellar) |
|
This document defines the Matroska multimedia container codec mappings, including the codec ID, layout of data in a Block element and in an optional CodecPrivate element. |
| | 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". |
| | Deterministic Route Redistribution into BGP |
| |
|
In this document we present several examples of non-deterministic routing behavior involving route redistribution into BGP. To eliminate such non-deterministic behavior, we propose an enhancement to BGP route selection that would take into account the administrative distance under certain conditions. Additionally, We recommend lowering the LOCAL_PREF value in implementation for the redistributed backup route when appropriate. |
| | 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. |
| | 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. |
| | Terminology for Implementing Lossless Techniques in Wide Area Networks |
| |
|
This document compiles a glossary of terminology commonly used in discussions about enhancing lossless transmission capabilities and network performance in Wide Area Networks, especially those terms already in related IETF drafts without further explanation. To aid operators and implementers in reading contemporary drafts, this document attempts to provide an overview of terms and definitions for clarifying the current understanding, so as to facilitate the ongoing research. |
| | A Referee to Authenticate Servers in Local Domains |
| |
|
Obtaining and maintaining PKI certificates for devices in a local domain network is difficult for both technical and human factors reasons. This document describes an alternative approach to securely identify and authenticate servers in the local domain using a HTTPS- based trust anchor system, called a Referee. The Referee allows bootstrapping a network of devices by trusting only the Referee trust anchor in the local domain. |
| | RPP Architecture |
| |
|
Advancements in development, integration, deployment environments and operational paradigms have led to a desire for an alternative for the Extensible Provisioning Protocol (EPP). This document defines the architecture for the RESTful Provisioning Protocol (RPP) an HTTP based provisioning protocol leveraging the REST architectural style and JSON data-interchange format, aiming to standardize a RESTful protocol for provisioning database objects. The architecture includes support for extensibility, allowing for multiple possible use cases. RPP is intended to co-exist with EPP, offering an alternative protocol including data model compatibility with EPP core objects and the benefits associated with the REST architectural style and widely adopted HTTP-based technologies. |
| | OODA-HTTP: Adaptive Security Framework for HTTP Communications |
| |
|
This document defines OODA-HTTP, a protocol extension and adaptive security framework that applies the Observe-Orient-Decide-Act loop to HTTP/HTTPS communications. OODA-HTTP introduces dynamic behavior at the application layer, enabling real-time detection, decision, and mitigation based on evolving threat contexts. Each HTTP request becomes not just a message, but an observation signal, a decision vector, and a defensive act. This framework introduces headers such as X-OODA-Action to carry contextual scores or actions across clients, servers, and intermediaries. OODA-HTTP transforms passive transport into active self- defense, offering resilience against classic and quantum threats. It is designed as a native defender of the World Wide Web \[Gupta23]\[Martinez22]\[Wang21]\[Kim23]. |
| | Reliable Transparency and Revocation Mechanisms |
| |
|
This document describes reliable mechanisms for the publication and revocation of Transport Layer Security (TLS) certificates. This reliability takes several forms. First, it provides browsers a strong guarantee that all certificates they accept are truly published and unrevoked at the time they're accepted. Second, it allows operators to monitor for mis-issuances related to their websites in a highly efficient way without relying on third-party services. Third, it provides a high degree of operational redundancy to minimize the risk of cascading outages. |
| | CBOR: Generating Numeric Map Labels from Textual EDN |
| |
|
The Concise Binary Object Representation (CBOR, STD 94 == RFC 8949) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. CBOR diagnostic notation (EDN) is widely used to represent CBOR data items in a way that is accessible to humans, for instance for examples in a specification. Complex examples often use nested maps, the map keys (labels) for each of which are often sourced from different specifications. While the e'' application extension provides a way to import data items, particularly constant values, from a CDDL model, it does not help with automatically selecting the right kind of map depending on its position in the nested maps. // The present document is intended to capture ideas initially // discussed at the CBOR WG interim 2025-06-25 and demonstrate some // design alternatives. It is not ready for adoption yet in any way. |
| | Detecting Outdated Proxy Configuration |
| |
|
This document defines a lightweight mechanism that allows explicit HTTP proxies to inform clients when their proxy configuration, such as a Proxy Auto-Configuration (PAC) file or Provisioning Domain (PvD) proxy configuration, is outdated. Clients signal to the proxy the configuration URL and the timestamp of when it was last fetched. In response, the proxy may indicate that a newer version of the configuration is available. This enables clients to refresh their configuration without relying on frequent polling or short expiration intervals. The mechanism is designed to be compatible with existing proxy deployment models and supports both PAC-based and PvD-based configurations. |
| | Intelligent Routing Method of SR Policy |
| |
|
Segment routing (SR) [RFC8402] is a source routing paradigm that explicitly indicates the forwarding path for packets at the ingress node. An SR Policy is associated with one or more candidate paths, and each candidate path is either dynamic, explicit or composite. This document describes an intelligent routing method for SR Policy based on network quality in MPLS and IPv6 environments. |
| | GLobal Unique Enterprise (GLUE) Identifiers |
| |
| | draft-ietf-spice-glue-id-01.txt |
| | Date: |
29/06/2025 |
| | Authors: |
Brent Zundel, Pamela Dingle, Michael Jones |
| | Working Group: |
Secure Patterns for Internet CrEdentials (spice) |
|
This specification establishes an IETF URN namespace for GLobal Unique Enterprise (GLUE) Identifiers. It also establishes an IETF URN namespace for identifiers defined by the IETF Secure Patterns for Internet CrEdentials (SPICE) working group. The GLUE URN namespace is within the SPICE URN namespace. |
| | Segment Protection for SR-TE Paths |
| |
|
Segment routing supports the creation of explicit paths using Adj- Segment-ID (SID), Node-SIDs, and BSIDs. It is important to provide fast reroute (FRR) mechanisms to respond to failures of links and nodes in the Segment-Routed Traffic-Engineered(SR-TE) path. A point of local repair (PLR) can provide FRR protection against the failure of a link in an SR-TE path by examining only the first (top) label in the SR label stack. In order to protect against the failure of a node, a PLR may need to examine the second label in the stack as well, in order to determine SR-TE path beyond the failed node. This document specifies how a PLR can use the first and second label in the SR-MPLS label stack describing an SR-TE path to provide protection against node failures. |
| |
|
| |
| | Performance Measurement with Asymmetrical Traffic Using STAMP |
| |
|
This document describes an optional extension to a Simple Two-way Active Measurement Protocol (STAMP) that enables control of the length and/or number of reflected packets during a single STAMP test session. In some use cases, the use of asymmetrical test packets allow for the creation of more realistic flows of test packets and, thus, a closer approximation between active performance measurements and conditions experienced by the monitored application. Also, the document includes an analysis of challenges related to performance monitoring in a multicast network. It defines procedures and STAMP extensions to achieve more efficient measurements with a lesser impact on a network. |
| | Clarification and enhancement of RFC7030 CSR Attributes definition |
| |
| | draft-ietf-lamps-rfc7030-csrattrs-23.txt |
| | Date: |
28/06/2025 |
| | Authors: |
Michael Richardson, Owen Friel, David von Oheimb, Dan Harkins |
| | Working Group: |
Limited Additional Mechanisms for PKIX and SMIME (lamps) |
|
This document updates RFC7030, Enrollment over Secure Transport (EST), clarifying how the Certificate Signiing Request (CSR) Attributes Response can be used by an EST server to specify both CSR attribute Object IDs (OID) and also CSR attribute values, in particular X.509 extension values, that the server expects the client to include in subsequent CSR request. RFC9148 is derived from RFC7030, and it is also updated. RFC7030 (EST) is ambiguous in its specification of the CSR Attributes Response. This has resulted in implementation challenges and implementor confusion. As a result, there was not universal understanding of what was specified. This document clarifies the encoding rules. This document therefore also provides a new straightforward approach: using a template for CSR contents that may be partially filled in by the server. This also allows an EST server to specify a subject Distinguished Name (DN). |
| | SIMAP: Concept,Requirements,and Use Cases |
| |
|
This document defines the concept of Service & Infrastructure Maps (SIMAP) and identifies a set of SIMAP requirements and use cases. The SIMAP was previously known as Digital Map. The document intends to be used as a reference for the assessment of the various topology modules to meet SIMAP requirements. |
| | HTTP Availability Hints |
| |
|
This specification defines availability hints, a new class of HTTP responses headers that augment the information in the Vary header field. |
| | RSVP Cryptographic Authentication,Version 2 |
| |
|
This document provides an algorithm-independent description of the format and use of RSVP's INTEGRITY object. The RSVP INTEGRITY object is widely used to provide hop-by-hop integrity and authentication of RSVP messages, particularly in MPLS deployments using RSVP-TE. This document obsoletes both RFC2747 and RFC3097. |
| | PIM Join Attributes for Locator/ID Separation Protocol (LISP) Environments |
| |
|
This document defines two PIM Join/Prune attributes that support the construction of multicast distribution trees where the root and receivers are located in different Locator/ID Separation Protocol (LISP) sites. These attributes allow the receiver site to select between unicast and multicast underlying transport, to convey the RLOC (Routing Locator) address of the receiver ETR (Egress Tunnel Router) to the control plane of the root ITR (Ingress Tunnel Router) and to signal the underlay multicast group to the control plane of the root ITR. This document updates RFC 8059 and RFC 9798. |
| | Partial MLS |
| |
| | draft-kiefer-mls-partial-00.txt |
| | Date: |
28/06/2025 |
| | Authors: |
Franziskus Kiefer, Karthikeyan Bhargavan, Richard Barnes, Joel, Marta Mularczyk |
| | Working Group: |
Individual Submissions (none) |
|
The Messaging Layer Security (MLS) protocol provides efficient asynchronous group key establishment for large groups with up to thousands of clients. In MLS, any member can commit a change to the group, and consequently, all members must download, validate, and maintain the full group state, which can incur a significant communication and computational costs, especially when joining a group. This document defines an MLS extension to support "partial MLS clients" that don't undertake these costs. A partial client cannot commit changes to the group, and only has partial authentication information for the other members of the group, but is otherwise able to participate in the group. In exchange for these limitations, a partial MLS client can participate in an MLS group with significantly lower requirements in terms of download, memory, and processing. |
| | References in RFCs and IANA Registries |
| |
|
This document describes the use of references in RFCs and IANA registries. It also discusses situations where RFCs are currently required as references in IANA registries. This document does not define any new policies, but instead describes the many practices that have been used, particularly the practices that are considered best current practices today. This document is informative, and thus does not require changes to, or prohibit exceptions from, the current practices. |
| |
|
| |
| | Multicast and Ethernet VPN with Segment Routing P2MP and Ingress Replication |
| |
| | draft-ietf-bess-mvpn-evpn-sr-p2mp-13.txt |
| | Date: |
27/06/2025 |
| | Authors: |
Rishabh Parekh, Dan Voyer, Clarence Filsfils, Mankamana Mishra, Hooman Bidgoli, Zhaohui Zhang |
| | Working Group: |
BGP Enabled ServiceS (bess) |
|
A Point-to-Multipoint (P2MP) Tree in a Segment Routing domain carries traffic from a Root to a set of Leaves. This document describes extensions to BGP encodings and procedures for P2MP trees and Ingress Replication used in BGP/MPLS IP VPNs and Ethernet VPNs in a Segment Routing domain. |
| | Deterministic Networking (DetNet) Controller Plane Framework |
| |
|
This document provides a framework overview for the Deterministic Networking (DetNet) controller plane. It discusses concepts and requirements for DetNet controller plane which could be basis for future solution specification. |
| | DRIP Entity Tags in the Domain Name System |
| |
|
This document defines the Domain Name System (DNS) functionality of a Drone Remote Identification Protocol (DRIP) Identity Management Entity (DIME). It is built around DRIP Entity Tags (DETs) to standardize a hierarchical registry structure and associated processes to facilitate trustable and scalable registration and lookup of information related to Unmanned Aircraft Systems (UAS). The registry system supports issuance, discovery, and verification of DETs, enabling secure identification and association of UAS and their operators. It also defines the interactions between different classes of registries (root, organizational, and individual) and their respective roles in maintaining the integrity of the registration data. This architecture enables decentralized, federated operation while supporting privacy, traceability, and regulatory compliance requirements in the context of UAS Remote ID and other services. |
| | BGP UPDATE for SD-WAN Edge Discovery |
| |
|
The document describes the BGP mechanisms for SD-WAN (Software Defined Wide Area Network) edge node attribute discovery. These mechanisms include a new tunnel type and sub-TLVs for the BGP Tunnel- Encapsulation Attribute [RFC9012] and set of NLRI (network layer reachability information) for SD-WAN underlay information. In the context of this document, BGP Route Reflector (RR) is the component of the SD-WAN Controller that receives the BGP UPDATE from SD-WAN edges and in turn propagates the information to the intended peers that are authorized to communicate via the SD-WAN overlay network. |
| | Circuit Style Segment Routing Policies with Optimized SID List Depth |
| |
|
Service providers require delivery of circuit-style transport services in a segment routing based IP network. This document introduces a solution that supports circuit style segment routing policies that allows usage of optimized SID lists (i.e. SID List that may contain non-contiguous node SIDs as instructions) and describes mechanisms that would allow such encoding to still honor all the requirements of the circuit style policies notably traffic engineering and bandwidth requirements. |
| | An Update on Milestones |
| |
|
As mandated in RFC 2418, working group charters currently contain milestones. However, these milestones are often sufficiently out of date that they no longer provide value. This document makes milestones optional and allows more discretion on their dates. It updates RFC 2418. |
| | Traceability Claims |
| |
|
This document defines claims to support traceability of physical goods across supply chains, focusing on items such as bills of lading, transport modes, and container manifests. These claims standardize the encoding of essential logistics and transport metadata, facilitating enhanced transparency and accountability in global supply chains. These claims are registered for use in both CBOR Web Tokens (CWTs) and JSON Web Tokens (JWTs). |
| | Eligibility Concept in Segment Routing Policies |
| |
|
Segment Routing (SR) introduces new challenges for pinning candidate paths on their intended paths (the path the PCE computed based on provided intent and may have made bandwidth reservations on). The actual path through a network can change or no longer meet the required constraints if a SID list of an SR Policy candidate path is not fully expressed as a list of adjacency SIDs or when a change in the topology does happen. The introduction of the new candidate path eligibility concept permits a path to be signaled and established as operationally up, but controls whether the path is eligible to carry traffic, thus influencing its active state. The eligibility concept allows a system (operator, pce, headend, etc.) to set eligibility as false when path deviations may have occurred, or path constraints are no longer met for one or more SID lists of a candidate path and clear it when candidate path deviations are removed or constraints are met again. |
| | Deferred Key Binding for OAuth |
| |
|
Sometimes you want to get a token that's tied to a public key but you can't prove possession of that public key. That's when you need to trust me, bruh. |
| | Priority-based Flow Control SID in SRv6 |
| |
|
To address the issue of lossless transmission for cross-data center services, the PFC (Priority-based Flow Control) mechanism can be extended to wide-area networks (WANs) to solve packet loss caused by network congestion and the problem of backpressure signal transmission between WAN and RoCEv2 network in data centers. By leveraging SRv6 and slicing technologies, it is possible to effectively control the propagation range and path of PFC backpressure signals in wide-area networks, thereby avoiding issues such as deadlocks and the excessive propagation of congestion scope. PFC is a hop-by-hop mechanism. Given that most current WAN devices do not support PFC function, this document proposes defining a new type of SRv6 SID End.X.PFC to indicate the PFC-capable interface in the WAN network. |
| | OAuth 2.0 Refresh Token and Consent Expiration |
| |
|
This specification extends OAuth 2.0 [RFC6749] by adding new token endpoint response parameters to specify refresh token expiration and user consent expiration. |
| | A Data Manifest for Contextualized Telemetry Data |
| |
|
Network platforms use Network Telemetry, such as YANG-Push, to continuously stream information, including both counters and state information. This document describes the metadata that ensure that the collected data can be interpreted correctly. This document specifies the data manifest, composed of two YANG data models (the platform manifest and the non-normative data collection manifest). These YANG modules are specified at the network level (e.g., network controllers) to provide a model that encompasses several network platforms. The data manifest must be streamed and stored along with the data, up to the collection and analytics systems to keep the collected data fully exploitable by the data scientists and relevant tools. Additionally, this document specifies an augmentation of the YANG-Push model to include the actual collection period, in case it differs from the configured collection period. |
| | OpenID Connect Standard Claims Registration for CBOR Web Tokens |
| |
|
This document registers OpenID Connect standard claims already used in JSON Web Tokens for use in CBOR Web Tokens. |
| |
|
| |
| | Fixing the C-Flag in Extended Address Registration Option (EARO) |
| |
|
This document updates “Address-Protected Neighbor Discovery for Low- Power and Lossy Networks” (RFC 8928) by changing the position of the C-flag in the Extended Address Registration Option (EARO) and registering it with IANA. |
| | BRSKI Cloud Registrar |
| |
| | draft-ietf-anima-brski-cloud-15.txt |
| | Date: |
26/06/2025 |
| | Authors: |
Owen Friel, Rifaat Shekh-Yusef, Michael Richardson |
| | Working Group: |
Autonomic Networking Integrated Model and Approach (anima) |
|
Bootstrapping Remote Secure Key Infrastructures (BRSKI) defines how to onboard a device securely into an operator-maintained infrastructure. It assumes that there is local network infrastructure for the device to discover and help the device. This document extends BRSKI and defines new device behavior for deployments where no local infrastructure is available, such as in a home or remote office. This document defines how the device can use a well-defined "call-home" mechanism to find the operator-maintained infrastructure. This document defines how to contact a well-known Cloud Registrar, and two ways in which the new device may be redirected towards the operator-maintained infrastructure. The Cloud Registrar enables discovery of the operator-maintained infrastructure, and may enable establishment of trust with operator-maintained infrastructure that does not support BRSKI mechanisms. |
| | Integration of DNS Domain Names into Application Environments: Motivations and Considerations |
| |
|
This document reviews the motivations and considerations for integrating DNS domain names into an application environment and provides terminology to establish a shared understanding of what a DNS integration may entail. |
| | A YANG Data Model for BGP Communities |
| |
|
This document defines a YANG data model for the structured specification of BGP communities. The model provides operators with a way to publish their locally defined BGP communities in a standardized format. |
| | Communicating Proxy Configurations in Provisioning Domains |
| |
|
This document defines a mechanism for accessing provisioning domain information associated with a proxy, such as other proxy URIs that support different protocols and information about which destinations are accessible using a proxy. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/tfpauly/privacy-proxy. |
| | Responsiveness under Working Conditions |
| |
|
For many years, a lack of responsiveness, variously called lag, latency, or bufferbloat, has been recognized as an unfortunate, but common, symptom in today's networks. Even after a decade of work on standardizing technical solutions, it remains a common problem for the end users. Everyone "knows" that it is "normal" for a video conference to have problems when somebody else at home is watching a 4K movie or uploading photos from their phone. However, there is no technical reason for this to be the case. In fact, various queue management solutions have solved the problem. Our network connections continue to suffer from an unacceptable amount of delay, not for a lack of technical solutions, but rather a lack of awareness of the problem and deployment of its solutions. We believe that creating a tool that measures the problem and matches people's everyday experience will create the necessary awareness, and result in a demand for solutions. This document specifies the "Responsiveness Test" for measuring responsiveness. It uses common protocols and mechanisms to measure user experience specifically when the network is under working conditions. The measurement is expressed as "Round-trips Per Minute" (RPM) and should be included with goodput (up and down) and idle latency as critical indicators of network quality. |
| | Internet X.509 Public Key Infrastructure - Algorithm Identifiers for the Module-Lattice-Based Digital Signature Algorithm (ML-DSA) |
| |
|
Digital signatures are used within X.509 certificates, Certificate Revocation Lists (CRLs), and to sign messages. This document specifies the conventions for using FIPS 204, the Module-Lattice- Based Digital Signature Algorithm (ML-DSA) in Internet X.509 certificates and certificate revocation lists. The conventions for the associated signatures, subject public keys, and private key are also described. |
| | An Attribute for Statement of Possession of a Private Key |
| |
|
This document specifies an attribute for a statement of possession of a private key by a certificate subject. As part of X.509 certificate enrollment, a Certification Authority (CA) typically demands proof that the subject possesses the private key that corresponds to the to-be-certified public key. In some cases, a CA might accept a signed statement from the certificate subject. For example, when a certificate subject needs separate certificates for signature and key establishment, a statement that can be validated with the previously issued signature certificate for the same subject might be adequate for subsequent issuance of the key establishment certificate. |
| | EVPN First Hop Security |
| |
|
The Dynamic Host Configuration Protocol (DHCP) snoop database stores valid IPv4-to-MAC and IPv6-to-MAC bindings by snooping on DHCP messages. These bindings are used by security functions like Dynamic Address Resolution Protocol Inspection (DAI), Neighbor Discovery Inspection (NDI), IPv4 Source Guard, and IPv6 Source Guard to safeguard against traffic received with a spoofed address. These functions are collectively referred to as First Hop Security (FHS). This document proposes BGP extensions and new procedures for Ethernet VPN (EVPN) will distribute and synchronize the DHCP snoop database to support FHS. Such synchronization is needed to support EVPN host mobility and multi-homing. |
| | A Prio Instantiation for Vector Sums with an L1 Norm Bound on Contributions |
| |
|
A Prio Verifiable Distributed Aggregation Function is defined that supports vector or histogram addition, where the sum of the values in the contribution is less than a chosen value. |
| | Advertisement of SR Policy Administative Flags using BGP Link-State |
| |
|
This document defines the extension of BGP Link-State to advertise the administrative state of the candidate path or segment list, facilitating the operation and maintenance of the SR Policy. |
| | PQC Escape Message for Dynamic Migration |
| |
|
In this contribution, a design of escape message mechanism is proposed, where the service provider sends an escape message to the service consumer using existing non-PQC connection and then starts to re-establish the quantum-safe protocol. The proposed escape message can potentially be used in a variety of protocols, including IPsec, TLS, or between the air interface of a cellphone and a network device. We believe that for largely deployed networks and entities, escape messages can be provided as a plan B for always-live devices of service provider and consumer that cannot complete post-quantum migration in advance and mitigates negative impacts after potential Q-days occur. Different protocols and devices may be implemented escape mechanism in different sepcific ways. |
| | TE and Path & Placement Computation for Cloud Native Applications |
| |
|
Currently a path computation is the ability to find the path/s connecting two or more points of the network identified with addresses. The path selection can be driven requiring constraints and metric minimization in traversing the network. The computed paths may be used for realizing a network slice providing connectivity to applications that shall be able to reach addresses of the end-points. A cloud native application (CNA) becomes a network point only when an instance of it has been deployed in a site fulfilling the requirements for resources, scalability, reliability, security and costs... The process for identifying where to deploy a CNA is disjoined from path computation that is executed in a following step. If the path computation cannot satisfy the request not finding a connectivity solution, the chosen end-points shall be changed restarting the process from the selection of the deployment sites. The CNA problem can be generalized to all the cases where more end- points can be alternatives for terminating a path. For example, an enterprise site may be attached to the ISP backbone via more nodes in risk diversity belonging to different network segments. How computing the best connectivity in the ISP network including the selection of the best placement for the end-points in the enterprise sites? Where locating end-points of overlay network may be managed as well as an application. |
| | Best Practices for Secure ICAP Deployment with Credential-Based TLS |
| |
|
This document defines a Best Current Practice for deploying the Internet Content Adaptation Protocol (ICAP) in a secure manner. It introduces a mechanism for symmetric encryption using TLS, with client authentication based on user credentials. The aim is to provide confidentiality and integrity of ICAP traffic in modern zero- trust and content-sensitive environments. |
| | 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. |
| | Path Computation Element Communication Protocol (PCEP) extensions for Circuit Style Policies |
| |
|
Segment Routing (SR) enables a node to steer packet flows along a specified path without the need for intermediate per-path states, due to the utilization of source routing. An SR Policy comprises a sequence of segments, which are essentially instructions that define a source-routed policy This document proposes a set of extensions to the Path Computation Element Communication Protocol (PCEP) for Segment Routing Policies that are designed to satisfy requirements for connection-oriented transport services (Circuit-Style SR policies). They include the ability to control path recomputation and the option to request path with strict hops only and are also applicable for generic SR policy use cases where controlling path recomputation or distinct hop requirements are applicable. |
| | Return Routability Check for DTLS 1.2 and DTLS 1.3 |
| |
|
This document specifies a return routability check for use in context of the Connection ID (CID) construct for the Datagram Transport Layer Security (DTLS) protocol versions 1.2 and 1.3. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Transport Layer Security Working Group mailing list (tls@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/tls/. Source for this draft and an issue tracker can be found at https://github.com/tlswg/dtls-rrc. |
| |
|
| |
| | Operational Considerations for Voucher infrastructure for BRSKI MASA |
| |
|
This document describes a number of operational modes that a BRSKI Manufacturer Authorized Signing Authority (MASA) may take on. Each mode is defined, and then each mode is given a relevance within an over applicability of what kind of organization the MASA is deployed into. This document does not change any protocol mechanisms. |
| | Operational Considerations for BRSKI Registrar |
| |
|
This document describes a number of operational modes that a BRSKI Registration Authority (Registrar) may take on. Each mode is defined, and then each mode is given a relevance within an over applicability of what kind of organization the Registrar is deployed into. This document does not change any protocol mechanisms. This document includes operational advice about avoiding unwanted consequences. |
| | SRH Reduction for SRv6 End.M.GTP6.E Behavior |
| |
|
Segment Routing over IPv6 for the Mobile User Plane specifies interworking between SRv6 networks and GTP-U networks including required behaviors. This document specifies a new behavior named End.M.GTP6.E.Red which improves the End.M.GTP6.E behavior more hardware-friendly by indicating the behavior with one SID. |
| | Delegation Revalidation by DNS Resolvers |
| |
|
This document describes an optional algorithm for the processing of Name Server (NS) resource record (RR) sets (RRsets) during iterative resolution, and describes the benefits and considerations of using this approach. When following a referral response from an authoritative server to a child zone, DNS resolvers should explicitly query the authoritative NS RRset at the apex of the child zone and cache this in preference to the NS RRset on the parent side of the zone cut. The (A and AAAA) address RRsets in the additional section from referral responses and authoritative NS answers for the names of the NS RRset, should similarly be re-queried and used to replace the entries with the lower trustworthiness ranking in cache. Resolvers should also periodically revalidate the delegation by re-querying the parent zone at the expiration of the TTL of either the parent or child NS RRset, whichever comes first. |
| | API Keys and Privacy |
| |
|
Redirecting HTTP requests to HTTPS, a common pattern for human-facing web resources, can be an anti-pattern for authenticated API traffic. This document discusses the pitfalls and makes deployment recommendations for authenticated HTTP APIs. It does not specify a protocol. |
| | Network File System (NFS) Version 4 Minor Version 1 Protocol |
| |
|
This document describes the Network File System (NFS) version 4 minor version 1, including features retained from the base protocol (NFS version 4 minor version 0, which is specified in RFC 7530) and protocol extensions made as part of Minor Version 1. The later minor version has no dependencies on NFS version 4 minor version 0, and was, until recently, documented as a completely separate protocol. This document is part of a set of documents which collectively obsolete RFCs 8881 and 8434. In addition to many corrections and clarifications, it will rely on NFSv4-wide documents to substantially revise the treatment of protocol extension, internationalization, and security, superseding the descriptions of those aspects of the protocol appearing in RFCs 5661 and 8881. |
| | Adaptive IPv4 Address Space |
| |
|
This document describes a solution to the Internet address depletion issue through the use of an existing Option mechanism that is part of the original IPv4 protocol. This proposal, named EzIP (phonetic for Easy IPv4), outlines the IPv4 public address pool expansion and the Internet system architecture enhancement considerations. EzIP may expand an IPv4 address by a factor of 256M without affecting the existing IPv4 based Internet, or the current private networks. It is in full conformance with the IPv4 protocol, and supports not only both direct and private network connectivity, but also their interoperability. EzIP deployments may coexist with existing Internet traffic and IoTs (Internet of Things) operations without perturbing their setups, while offering end-users the freedom to independently choose which service. EzIP may be implemented as a software or firmware enhancement to Internet edge routers or private network routing gateways, wherever needed, or simply installed as an inline adjunct hardware module between the two, enabling a seamless introduction. The 256M case detailed here establishes a complete spherical layer of an overlay of routers for interfacing between the Internet fabric (core plus edge routers) and the end user premises or IoTs. Incorporating caching proxy technology in the gateway, a fairly large geographical region may enjoy address expansion based on as few as one ordinary IPv4 public address utilizing IP packets with degenerated EzIP header. If IPv4 public pool allocations were reorganized, the assignable pool could be multiplied 512M fold or even more. Enabling hierarchical address architecture which facilitates both hierarchical and mesh routing, EzIP can provide nearly the same order of magnitude of address pool resources as IPv6 while streamlining the administrative aspects of it. The basic EzIP will immediately resolve the local IPv4 address shortage, while being transparent to the rest of the Internet as a new parallel facility. Under the Dual-Stack environment, these proposed interim facilities will relieve the IPv4 address shortage issue, while affording IPv6 more time to reach maturity for providing the availability levels required for delivering a long-term general service. The basic EzIP may be deployed in two distinctive phases. First, the CG-NAT operation may be enhanced by enabling the use of 240/4 netblock in addition to the current 100.64/10 netblock of RFC6598. This makes end-to-end connectivity feasible within the service area of each 240/4 netblock. Second, this capability may extend to global coverage with the use of the Option Word mechanism in the IP header. |
| | Deadline Based Deterministic Forwarding |
| |
|
This document describes a deadline based deterministic forwarding mechanism for IP/MPLS network with the corresponding resource reservation, admission control, scheduling and policing processes to provide guaranteed latency bound. It employs a latency compensation technique with a stateless core, to replace reshaping, making it suitable for the Differentiated Services (Diffserv) architecture [RFC2475]. |
| | YANG Data Model for RPKI to Router Protocol |
| |
| | draft-liu-sidrops-rtr-yang-07.txt |
| | Date: |
25/06/2025 |
| | Authors: |
Yisong Liu, Changwang Lin, Haibo Wang, ROY Jishnu, Jeffrey Haas, Hongwei Liu, Di Ma |
| | Working Group: |
Individual Submissions (none) |
|
This document defines YANG data models for configuring and managing Resource Public Key Infrastructure (RPKI) to Router Protocol (RFC6810 and RFC8210). |
| | DKIM2 - signing the source and destination of every email |
| |
|
This memo provides a rationale for replacing the existing email security mechanisms with a new mechanism based around a more strongly authenticated email delivery pathway, including an asynchronous return channel. |
| | OAuth 2.0 App2App Browserless Flow |
| |
|
This document describes a protocol connecting 2 native apps via the OAuth [App2App] pattern, to achieve native user navigation (no web browser required), regardless of any number of OAuth brokers federating the request across trust domains. |
| | Unobtrusive End-to-End Email Signatures |
| |
|
This document deals with end-to-end cryptographically signed email. It introduces a novel structure for signed email that is designed to avoid creating any disturbance in legacy email clients. This "unobtrusive" signature structure removes disincentives for signing email. |
| | A Profile for Traffic Origin Authorizations (TOAs) |
| |
|
This document defines a standard profile for Traffic Origin Authorizations (TOAs), a Cryptographic Message Syntax (CMS) protected content type for use with the Resource Public Key Infrastructure (RPKI). A TOA is a digitally signed object that provides a means of verifying that an IP address block holder has authorized an Autonomous System (AS) to originate traffic using source IP addresses within the address block. |
| | SCHC Payload compression |
| |
|
This document describes several techniques to enable utilization of the same engine to compress and decompress headers from the existing SCHC framework [RFC8724], but used to compress payload of specific protocols. The first approach is to introduce new type of static rules that enable encoding application data. This extensions provides compact and generic variation on how data is organized. The second approach provides dynamic compression and decompression. Here, the system identifies parts of the payload that can be compressed, and enables a SCHC decompressor to restore the original packet. |
| | Service Binding Mapping for Background Requests |
| |
|
This document defines a new SvcParamKey for use in Service Binding (SVCB) and HTTPS DNS resource records which enables authoritative DNS servers to indicate that a client can use an alternative endpoint for "background" requests. By providing this information, clients can make informed decisions about which service endpoints to use based on their specific applications needs at the time of making connections. |
| | Prevention Downgrade Attacks on the Internet Key Exchange Protocol Version 2 (IKEv2) |
| |
|
This document describes an extension to the Internet Key Exchange protocol version 2 (IKEv2) that aims to prevent some kinds of downgrade attacks on this protocol. |
| | Carrying SR-Algorithm in Path Computation Element Communication Protocol (PCEP) |
| |
| | draft-ietf-pce-sid-algo-21.txt |
| | Date: |
25/06/2025 |
| | Authors: |
Samuel Sidor, Zoey Rose, Shaofu Peng, Shuping Peng, Andrew Stone |
| | Working Group: |
Path Computation Element (pce) |
|
This document specifies extensions to the Path Computation Element Communication Protocol (PCEP) to enhance support for Segment Routing (SR) with a focus on the use of Segment Identifiers (SIDs) and SR- Algorithms in Traffic Engineering (TE). The SR-Algorithm associated with a SID defines the path computation algorithm used by Interior Gateway Protocols (IGPs). This document introduces extensions in three main areas. Mechanisms for informing PCEP peers about the SR-Algorithm associated with SIDs by encoding this information in Explicit Route Object (ERO) and Record Route Object (RRO) subobjects. This document updates RFC 8664 and RFC 9603 to allow such extension. The document specifies SR-Algorithm constraint, enabling refined path computations that can leverage IGP algorithm logic, including Flexible Algorithms, and their associated constraints and optimization metrics. It defines new metric types for the METRIC object required to support SR-Algorithm based path computation, but also applicable to Label Switched Paths (LSPs) setup using different Path Setup Types. |
| |
|
| |
| | Prioritizing known-local IPv6 ULAs through address selection policy |
| |
|
This document updates the default address selection algorithm for Internet Protocol Version 6 (IPv6), originally specified in RFC 6724, based on accumulated operational experience. It introduces the concept of "known-local" Unique Local Address (ULA) prefixes within the fd00::/8 block and specifies that ULA-to-ULA communications using such prefixes should be preferred over both IPv4-to-IPv4 and GUA-to- GUA (Global Unicast Address) communications in local use scenarios. The document defines mechanisms for nodes to identify and incorporate known-local prefixes into their address selection policy tables. It further clarifies the unconditional requirement for implementing Rule 5.5 of RFC 6724 and reduces the default precedence for 6to4 addresses. These updates enhance the supportability of typical deployment environments, including automatic and unmanaged configurations, and promote consistent IPv6-over-IPv4 precedence behavior for both ULA and GUA within local networks. The document acknowledges that certain atypical deployment models may require explicit configuration to achieve intended operational outcomes. |
| | BGP MPLS-Based Ethernet VPN |
| |
|
This document describes procedures for Ethernet VPN (EVPN), a BGP MPLS-based solution which addresses the requirements specified in the corresponding RFC - "Requirements for Ethernet VPN (EVPN)". This document obsoletes RFC7432 (BGP MPLS-Based Ethernet VPN) and updates RFC8214 (Virtual Private Wire Service Support in Ethernet VPN). |
| | A Framework for Computing-Aware Traffic Steering (CATS) |
| |
| | draft-ietf-cats-framework-10.txt |
| | Date: |
24/06/2025 |
| | Authors: |
Cheng Li, Zongpeng Du, Mohamed Boucadair, Luis Contreras, John Drake |
| | Working Group: |
Computing-Aware Traffic Steering (cats) |
|
This document describes a framework for Computing-Aware Traffic Steering (CATS). Specifically, the document identifies a set of CATS components, describes their interactions, and provides illustrative workflows of the control and data planes. |
| | Attacks on the Constrained Application Protocol (CoAP) |
| |
| | draft-ietf-core-attacks-on-coap-06.txt |
| | Date: |
24/06/2025 |
| | Authors: |
John Mattsson, John Fornehed, Goeran Selander, Francesca Palombini, Christian Amsuess |
| | Working Group: |
Constrained RESTful Environments (core) |
|
Being able to securely retrieve information from sensors and control actuators while providing guards against distributed denial-of- service (DDoS) attacks are key requirements for CoAP deployments. To that aim, a security protocol (e.g., DTLS, TLS, or OSCORE) can be enabled to ensure secure CoAP operation, including protection against many attacks. This document identifies a set of known CoAP attacks and shows that simply using CoAP with a security protocol is not always enough for secure operation. Several of the identified attacks can be mitigated with a security protocol providing confidentiality and integrity combined with the solutions specified in RFC 9175. |
| | Hybrid Public Key Encryption |
| |
| | draft-ietf-hpke-hpke-01.txt |
| | Date: |
24/06/2025 |
| | Authors: |
Richard Barnes, Karthikeyan Bhargavan, Benjamin Lipp, Christopher Wood |
| | Working Group: |
HPKE Publication, Kept Efficient (hpke) |
|
This document describes a scheme for hybrid public key encryption (HPKE). This scheme provides a variant of public key encryption of arbitrary-sized plaintexts for a recipient public key. It also includes a variant that authenticates possession of a pre-shared key. HPKE works for any combination of an asymmetric KEM, key derivation function (KDF), and authenticated encryption with additional data (AEAD) encryption function. We provide instantiations of the scheme using widely used and efficient primitives, such as Elliptic Curve Diffie-Hellman (ECDH) key agreement, HMAC-based key derivation function (HKDF), and SHA2. |
| | IGP Flexible Algorithms Reverse Affinity Constraint |
| |
|
An IGP Flexible Algorithm (Flex-Algorithm) enables the computation of constraint-based paths within an IGP domain, allowing operators to influence path selection according to administrative policies. This document defines an extension to Flex-Algorithm that allows the inclusion or exclusion of links from path computation based on Administrative Groups (also known as link affinities) associated with the reverse direction of the path under computation. This extension enhances the path selection capabilities of Flex- Algorithm by enabling reverse-affinity-based constraints, which are particularly useful for scenarios where path symmetry or directional link attributes are operationally significant. |
| | Interconnecting domains with IBGP |
| |
|
This document relaxes the recommendations specified in BGP/MPLS IP Virtual Private Networks (VPNs) and BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP) allowing the building of Inter-domain L3VPN architecture with internal BGP. |
| | Timeslot Queueing and Forwarding Mechanism |
| |
|
IP/MPLS networks use packet switching (with the feature store-and- forward) and are based on statistical multiplexing. Statistical multiplexing is essentially a variant of time division multiplexing, which refers to the asynchronous and dynamic allocation of link timeslot resources. In this case, the service flow does not occupy a fixed timeslot, and the length of the timeslot is not fixed, but depends on the size of the packet. Statistical multiplexing has certain challenges and complexity in meeting deterministic QoS, and its delay performance is dependent on the used queueing mechanism. This document further describes a generic time division multiplexing scheme for layer-3 in an IP/MPLS networks, called timeslot queueing and forwarding (TQF) mechanism. TQF is an enhancement based on TSN TAS and allows the data plane to create a flexible timeslot mapping scheme based on available timeslot resources. It defines a cyclic period consisting of multiple timeslots where a flow is assigned to be transmited within one or more dedicated timeslots. The objective of TQF is to better handle large scaling requirements. |
| | Applications and Procedures for Unknown MAC Route in EVPN |
| |
|
The Interconnect Solution for Ethernet VPN defines Unknown MAC (Media Access Control) Route (UMR) utilization for Data Center Interconnect (DCI) when EVPN MPLS or EVPN VXLAN is an overlay network for such interconnects. This scenario impacts MAC mobility procedures and needs to be addressed. This document describes additional changes and enhancements required for MAC mobility procedures when using UMR.. |
| | Public Key Hash for Local Domains |
| |
|
This specification eliminates security warnings when connecting to local domains using TLS. Servers use a unique, long hostname which encodes their public key that the client validates against the public key presented in the TLS handshake. |
| | OAuth Client Registration on First Use with SPIFFE |
| |
|
The OAuth framework is a widely deployed authorization protocol standard that enables applications to obtain limited access to user resources. OAuth clients must be registered with the OAuth authorization server, which poses significant operational challenges in dynamically scaling environments. The Secure Production Identity Framework For Everyone (SPIFFE) is a graduated Cloud Native Compute Foundation project designed to dynamically attest and verify workload identity. This draft describes how workloads with SPIFFE credentials can be used with OAuth to lessen the operational burden of client registration through a "register on first use" principle. |
| | OAuth 2.0 Dynamic Client Registration with Trusted Issuer Credentials |
| |
|
An OAuth 2.0 client requires specific information to interact with an authorization server, including a client identifier registered with the authorization server. The OAuth 2.0 Dynamic Client Registration Protocol [RFC7591] defines a mechansim for dynamic client registration that removes the need for manual registration. This provides a more scalable mechanism that can be used by clients that do not have a pre-existing relationship with an authorization server, or where manually configuring such relationships is prohibitive from a cost and scale perspective. Examples of deployments that benefit from dynamic client registration includes modern cloud architectures where microservices are created on demand to meet scale requirements or for use with emerging protocols like the Model Context Protocol (MCP) [MCP] which requires clients to register with an authorization server even if they do not have a predefined relationship with the authorization server. Similar to modern cloud native workloads, MCP service integrations may be ephemeral in nature. The OAuth 2.0 Dynamic Client Registration Protocol [RFC7591] defines a software statement that includes metadata about the client and is signed by a developer or trusted third party. This specification describes the use of specific third party credentials issued to workloads and applications as software statements. The specification describes two types of credentials that may be used as software statements. The first is Secure Production Identity Framework For Everyone (SPIFFE) credentials. The second is the use of JWT representation of a Verifiable Credentials [VC-JWT] |
| | A recommendation for filtering address records in stub resolvers |
| |
|
Since IPv4 and IPv6 addresses are represented by different resource records in the DNS, operating systems capable of running both IPv4 and IPv6 need to make two queries when resolving a host name. This document discusses conditions, under which the stub resolver can optimize the process by not sending one of the queries if the host is connected to a single-stack network. |
| | Update of the Simple Two-way Active Measurement Protocol Class-of-Service Extension - ECN |
| |
|
The Simple Two-Way Active Measurement Protocol (STAMP) enables one- way and round-trip measurement of network metrics between IP hosts, and has a facility for defining optional extensions. This document updates the definition of the Class of Service TLV (originally defined in RFC 8972) to enable the measurement of manipulation of the value of the Explicit Congestion Notification (ECN) field of the IP header by middleboxes between two STAMP hosts, and to enable discovery and measurement of paths that provide differential treatment of packets depending on the value of their ECN field. |
| | DNS Resolver Information Key for DELEG |
| |
|
This document specifies a DNS Resolver Information Key to inform DNS clients of DELEG support. |
| | Standardising Protocol-Error |
| |
|
We extend and standardise the Protocol-Error packet Code, first defined in RFC 7930 for the Remote Authentication Dial In User Service (RADIUS) protocol. |
| | Application assistance based mobile network user-plane evolution |
| |
|
This document analyzes the problems and necessity for evolution of user-plane in mobile networks. In addition, the use cases and requirements are discussed. |
| | A YANG Data Model for Terminal Access Controller Access-Control System Plus (TACACS+) |
| |
|
This document defines a Terminal Access Controller Access-Control System Plus (TACACS+) client YANG module that augments the System Management data model, defined in RFC 7317, to allow devices to make use of TACACS+ servers for centralized Authentication, Authorization, and Accounting (AAA). Specifically, this document defines a YANG module for TACACS+ over TLS 1.3. This document obsoletes RFC 9105. |
| | General Source Address Validation Capabilities |
| |
|
The SAV rules of existing source address validation (SAV) mechanisms, are derived from other core data structures, e.g., FIB-based uRPF, which are not dedicatedly designed for source filtering. Therefore there are some limitations related to deployable scenarios and traffic handling policies. To overcome these limitations, this document introduces the general SAV capabilities from data plane perspective. How to implement the capabilities and how to generate SAV rules are not in the scope of this document. |
| | RPKI Publication Server Best Current Practices |
| |
|
This document describes best current practices for operating an RFC 8181 RPKI Publication Server and its rsync (RFC 5781) and RRDP (RFC 8182) public repositories. |
| | Circuit Style Segment Routing Policy |
| |
| | draft-ietf-spring-cs-sr-policy-10.txt |
| | Date: |
24/06/2025 |
| | Authors: |
Christian Schmutzer, Zafar Ali, Praveen Maheshwari, Reza Rokui, Andrew Stone |
| | Working Group: |
Source Packet Routing in Networking (spring) |
|
This document describes how Segment Routing (SR) policies can be used to satisfy the requirements for bandwidth, end-to-end recovery and persistent paths within a SR network. The association of two co- routed unidirectional SR Policies satisfying these requirements is called "circuit-style" SR Policy (CS-SR Policy). |
| | Applicability of IETF-Defined Service and Network Data Models for Network Slice Service Management |
| |
|
This document exemplifies how the various data models that are produced in the IETF can be combined in the context of Network Slice Services delivery. Specifically, this document describes the relationship between the Network Slice Service models for requesting Network Slice Services and both Service (e.g., the L3VPN Service Model, the L2VPN Service Model) and Network (e.g., the L3VPN Network Model, the L2VPN Network Model) models used during their realizations. In addition, this document describes the communication between a Network Slice Controller (NSC) and the network controllers for the realization of Network Slices. The Network Slice Service YANG model provides a customer-oriented view of the intended Network slice Service. Thus, once an NSC receives a request for a Slice Service request, the NSC has to map it to accomplish the specific objectives expected by the network controllers. Existing YANG network models are analyzed against Network Slice requirements, and the gaps in existing models are identified. |
| | Prefer use of RFC8781 for Discovery of IPv6 Prefix Used for IPv6 Address Synthesis |
| |
|
On networks providing IPv4-IPv6 translation (NAT64, RFC7915), hosts and other endpoints might need to know the IPv6 prefix used for translation (the NAT64 prefix). While RFC7050 defined a DNS64-based prefix discovery mechanism, more robust methods have since emerged. This document provides updated guidelines for NAT64 prefix discovery, deprecating the RFC7050 approach in favor of modern alternatives (e.g., RFC8781) whenever available. |
| |
|
| |
| | JSCalendar: Converting from and to iCalendar |
| |
|
This document defines how to convert calendaring information between the JSCalendar and iCalendar data formats. It considers every JSCalendar and iCalendar element registered at IANA at the time of publication. It defines conversion rules for all elements that are common to both formats, as well as how convert arbitrary or unknown JSCalendar and iCalendar elements. |
| | JSCalendar: A JSON Representation of Calendar Data |
| |
|
This specification defines a data model and JSON representation of calendar data that can be used for storage and data exchange in a calendaring and scheduling environment. It aims to be an alternative and, over time, successor to the widely deployed iCalendar data format. It also aims to be unambiguous, extendable, and simple to process. In contrast to the jCal format, which is also based on JSON, JSCalendar is not a direct mapping from iCalendar but defines the data model independently and expands semantics where appropriate. |
| | JSContact: Optional Unique Identifiers |
| |
|
This document redefines the mandatory "uid" property of a Card object to become optional. This is both for using JSContact in other protocols than CardDAV and JMAP for Contacts, as well as to align the semantics of the vCard UID property with JSContact. This is a breaking change, this document introduces version "2.0" to replace the current JSContact version "1.0". |
| | CBOR Encoded X.509 Certificates (C509 Certificates) |
| |
|
This document specifies a CBOR encoding of X.509 certificates. The resulting certificates are called C509 Certificates. The CBOR encoding supports a large subset of RFC 5280 and all certificates compatible with the RFC 7925, IEEE 802.1AR (DevID), CNSA 1.0, RPKI, GSMA eUICC, and CA/Browser Forum Baseline Requirements profiles. When used to re-encode DER encoded X.509 certificates, the CBOR encoding can in many cases reduce the size of RFC 7925 profiled certificates with over 50% while also significantly reducing memory and code size compared to ASN.1. The CBOR encoded structure can alternatively be signed directly ("natively signed"), which does not require re-encoding for the signature to be verified. The TLSA selectors registry defined in RFC 6698 is extended to include C509 certificates. The document also specifies C509 Certificate Requests, C509 COSE headers, a C509 TLS certificate type, and a C509 file format. |
| | Mobility-aware Transport Network Slicing for 5G |
| |
| | draft-ietf-dmm-tn-aware-mobility-20.txt |
| | Date: |
23/06/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 IP transport network 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 transport network slices using UDP source port number of the GTP-U bearer when the IP transport network (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. |
| | Multi-Part TLVs in IS-IS |
| |
| | draft-ietf-lsr-multi-tlv-19.txt |
| | Date: |
23/06/2025 |
| | Authors: |
Parag Kaneriya, Tony Li, Tony Przygienda, Shraddha Hegde, Les Ginsberg |
| | Working Group: |
Link State Routing (lsr) |
|
New technologies are adding new information into IS-IS while deployment scales are simultaneously increasing. This causes the contents of many critical TLVs to exceed the currently supported limit of 255 octets. This document codifies the common mechanism of extending the TLV content space through multiple TLVs. |
| | Media over QUIC Transport |
| |
|
This document defines the core behavior for Media over QUIC Transport (MOQT), a media transport protocol designed to operate over QUIC and WebTransport, which have similar functionality. MOQT allows a producer of media to publish data and have it consumed via subscription by a multiplicity of endpoints. It supports intermediate content distribution networks and is designed for high scale and low latency distribution. |
| | Common YANG Data Types |
| |
|
This document defines a collection of common data types to be used with the YANG data modeling language. This version of the document adds several new type definitions and obsoletes RFC 6991. |
| | Unicast Use of the Formerly Reserved 240/4 |
| |
|
This document redesignates 240/4, the region of the IPv4 address space historically known as "Experimental," "Future Use," or "Class E" address space, so that this space is no longer reserved. It asks implementers to make addresses in this range fully usable for unicast use on the Internet. |
| | Unicast Use of the Lowest Address in an IPv4 Subnet |
| |
|
With ever-increasing pressure to conserve IP address space on the Internet, it makes sense to consider where relatively minor changes can be made to fielded practice to improve numbering efficiency. One such change, proposed by this document, is to increase the number of unicast addresses in each existing subnet, by redefining the use of the lowest-numbered (zeroth) host address in each IPv4 subnet as an ordinary unicast host identifier, instead of as a duplicate segment- directed broadcast address. |
| | Unicast Use of the Formerly Reserved 0/8 |
| |
|
This document redesignates 0/8, the lowest block in the IPv4 address space, so that this space is no longer reserved. It asks implementers to make addresses in this range fully usable for unicast use on the Internet. |
| | Unicast Use of the Formerly Special-Cased 127/8 |
| |
|
This document redefines the IPv4 local loopback network as consisting only of the 65,536 addresses 127.0.0.0 to 127.0.255.255 (127.0.0.0/16). It asks implementers to make addresses in the prior loopback range 127.1.0.0 to 127.255.255.255 fully usable for unicast use on the Internet. |
| | EVPN L3-Optimized IRB |
| |
|
Ethernet VPN Integrated Routing and Bridging (EVPN-IRB) provides dynamic and efficient intra and inter-subnet connectivity among Tenant Systems and end devices while maintaining very flexible multihoming capabilities. This document describes how EVPN-IRB can be optimized for IP hosts and devices such that PE devices only maintain MAC addresses for locally-connected IP hosts, thus improving MAC scalability of customer bridges and PE devices significantly. This document describes how such optimization is acheived while still supporting host moblity which is one of the fundamental features in EVPN and EVPN-IRB. With such optimization PE devices perform routing for both intra and inter-subnet traffic which results in some some caveats that operators and service providers need to be fully aware of. |
| | EVPN Underlay Network Migration From IPv4 to IPv6 |
| |
|
EVPN [RFC7432] and [RFC8365] has become the standard defacto technology/solution used in Enterprise, Data Center, and Service Provider networks because of its multi-tenancy, flexible multi-homing capabilities, efficient utilization of network bandwidth, support of workload mobility, flexible workload placement, etc. across many different types of services/VPNs. Some operators have deployed IPv4 underlay network/fabric and now plan to migrate to IPv6. This document describes the procedures to achieve such migration seamlessly. |
| | PQ/T Hybrid Composite Signatures for JOSE and COSE |
| |
|
This document describes JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE) serializations for PQ/T hybrid composite signatures. The composite algorithms described combine ML-DSA as the post-quantum component and ECDSA as the traditional component. |
| | SRv6 Deployment Options |
| |
|
When deciding to migrate a network from MPLS/SR-MPLS to SRv6, common questions involve how to go about performing the migration, what's the least amount of impact to an existing network and what existing techniques are available. This document presents various migration options for networks being upgraded from MPLS/SR-MPLS to SRv6. |
| | Open Cloud Mesh |
| |
|
Open Cloud Mesh is a server federation protocol that is used to notify a Receiving Party that they have been granted access to some Resource. It has similarities with authorization flows such as OAuth, as well as with social internet protocols such as ActivityPub and email. Open Cloud Mesh only handles the necessary interactions up to the point where the Receiving Party is informed that they were granted access to the Resource. The actual resource access is then left to protocols such as WebDAV and others. |
| | MNA for Metadata in SR-MPLS Service Programming |
| |
|
This document defines MPLS Network Action(MNA) encoding to carry metadata in SR service programming with SR-MPLS data plane. |
| | ICMPv6 Prefix Redirect Messages |
| |
|
The existing IPv6 ICMPv6 Redirect Message informs a host of a better next hop for a single destination IPv6 address. There is a use case for informing a host of a better next hop for a prefix or range of IPv6 addresses that includes or covers the single destination address that triggered the ICMPv6 redirect message. This memo specifies an ICMPv6 Prefix Redirect Message for this purpose. |
| | Tunnel Extensible Authentication Protocol (TEAP) Version 2 |
| |
|
This document defines the Tunnel Extensible Authentication Protocol (TEAP) version 2. It addresses a number of security and interoperability issues in TEAPv1 which was defined in [I-D.ietf-emu-rfc7170bis]. |
| | Authoritative DNS Transport Signaling |
| |
|
This document proposes a mechanism for authoritative DNS servers to opportunistically signal their support for alternative transport protocols (e.g., DNS over TLS (DoT), DNS over HTTPS (DoH) and DNS over QUIC (DoQ)) directly within the Additional section of authoritative DNS responses. This "hint-based" approach aims to enable resolvers to discover and upgrade transport connections more efficiently, thereby improving privacy, security, and performance for subsequent interactions. The mechanism is designed to not require any protocol change. It is safe, backward-compatible, and effective even when DNSSEC validation of the hint is not possible or desired. This document proposes an improvement on the opportunistic (but blind) testing of alternative transports suggested in RFC9539 by providing a mechanism by which a responding authoritative server may signal what alternative transports it supports. TO BE REMOVED: This document is being collaborated on in Github at: https://github.com/johanix/draft-johani-dnsop-transport-signaling (https://github.com/johanix/draft-johani-dnsop-transport-signaling). The most recent working version of the document, open issues, etc, should all be available there. The authors (gratefully) accept pull requests. |
| | Admission Control with Gateway |
| |
|
This document proposes to enhance the congestion control with the admission control mechanism at the gateway to achieve fast feedback and per-flow control. |
| | Modernizing Workload Security: Verifiable Geofencing,Proof-of-Possession,and Protocol-Aware Residency Enforcement |
| |
|
Modern cloud and distributed environments face significant risks from stolen bearer tokens, protocol replay, and trust gaps in transit. This document presents a framework for modernizing workload security through cryptographically verifiable geofencing, proof-of-possession, and protocol-aware residency enforcement. By binding workload identity to both geographic and host attributes, and supplementing bearer tokens with verifiable, location- and host-bound claims, the framework addresses the challenges of bearer token theft, proof-of- possession, IPSEC, and trust-in-transit. Leveraging trusted hardware, attestation protocols, and geolocation services, this approach ensures that only authorized workloads in approved locations and environments can access sensitive data or services, even in the presence of advanced threats. |
| | 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. |
| | Extensible Provisioning Protocol (EPP) Transport over QUIC |
| |
| | draft-ietf-regext-epp-quic-01.txt |
| | Date: |
23/06/2025 |
| | Authors: |
Jiankang Yao, Hongtao Li, Man Zhang, Dan Keathley, James Gould |
| | Working Group: |
Registration Protocols Extensions (regext) |
|
This document describes how an Extensible Provisioning Protocol (EPP) session is mapped onto a QUIC connection. EPP over QUIC (EoQ) leverages the performance and security features of the QUIC protocol as an EPP transport. |
| | Deprecating Obsolete Key Exchange Methods in (D)TLS 1.2 |
| |
|
For (D)TLS 1.2, this document deprecates the use of two key exchanges, namely Diffie-Hellman over a finite field and RSA, and it discourages the use of static elliptic curve Diffie-Hellman cipher suites. These prescriptions apply only to (D)TLS 1.2 since (D)TLS 1.0 and TLS 1.1 are deprecated by RFC 8996 and (D)TLS 1.3 either does not use the affected algorithm or does not share the relevant configuration options. (There is no DTLS version 1.1.) This document updates RFCs 9325, 4346, 5246, 4162, 6347, 5932, 5288, 6209, 6367, 8422, 5289, 5469, 4785, 4279, 5487, 6655, and 7905. |
| |
|
| |
| | Automated Certificate Management Environment (ACME) Device Attestation Extension |
| |
|
This document specifies new identifiers and a challenge for the Automated Certificate Management Environment (ACME) protocol which allows validating the identity of a device using attestation. |
| | 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. |
| | Use of Hybrid Public Key Encryption (HPKE) with JSON Object Signing and Encryption (JOSE) |
| |
| | draft-ietf-jose-hpke-encrypt-10.txt |
| | Date: |
20/06/2025 |
| | Authors: |
Tirumaleswar Reddy.K, Hannes Tschofenig, Aritra Banerjee, Orie Steele, Michael Jones |
| | Working Group: |
Javascript Object Signing and Encryption (jose) |
|
This specification defines Hybrid Public Key Encryption (HPKE) for use with JSON Object Signing and Encryption (JOSE). HPKE offers a variant of public key encryption of arbitrary-sized plaintexts for a recipient public key. HPKE is a general encryption framework utilizing an asymmetric key encapsulation mechanism (KEM), a key derivation function (KDF), and an authenticated encryption with additional data (AEAD) algorithm. This document defines the use of HPKE with JOSE. The specification chooses a specific subset of the HPKE features to use with JOSE. |
| | CAA Security Tag for Cryptographically-Constrained Domain Validation |
| |
| | draft-ietf-lamps-caa-security-02.txt |
| | Date: |
20/06/2025 |
| | Authors: |
Henry Birge-Lee, Grace Cimaszewski, Cyrill Kraehenbuehl, Liang Wang, Aaron Gable, Prateek Mittal |
| | Working Group: |
Limited Additional Mechanisms for PKIX and SMIME (lamps) |
|
Cryptographic domain validation procedures leverage authenticated communication channels to ensure resilience against attacks by both on-path and off-path network adversaries which attempt to tamper with communications between the Certification Authority (CA) and the network resources related to the domain contained in the certificate. Domain owners can leverage "security" Property Tags specified in CAA records (defined in [RFC8659]) with the critical flag set, to ensure that CAs perform cryptographically-constrained domain validation during their issuance procedure, hence defending against global man- in-the-middle adversaries. This document defines the syntax of the CAA security Property as well as acceptable means for cryptographically-constrained domain validation procedures. |
| | User Discovery Requirements |
| |
|
This document defines requirements for the user discovery problem within the More Instant Messaging Interoperability (MIMI) working group. User discovery is essential for interoperability, allowing message senders to locate recipients across diverse platforms using globally unique, cross-service identifiers (e.g., email addresses, phone numbers). The core challenge involves reliably mapping these identifiers to messaging service providers and determining the reachability of a recipient's identifier across multiple providers. |
| | Ad Hoc On-demand Distance Vector Version 2 (AODVv2) Routing |
| |
| | draft-perkins-manet-aodvv2-06.txt |
| | Date: |
20/06/2025 |
| | Authors: |
Charles Perkins, John Dowdell, Lotte Steenbrink, Victoria Pritchard |
| | Working Group: |
Individual Submissions (none) |
|
The Ad Hoc On-demand Distance Vector Version 2 (AODVv2) routing protocol is intended for use by mobile routers in wireless, multihop networks. AODVv2 determines unicast routes among AODVv2 routers within the network in an on-demand fashion. |
| | Merkle Tree Certificates |
| |
|
This document describes Merkle Tree certificates, a new form of X.509 certificates which integrate public logging of the certificate, in the style of Certificate Transparency. The integrated design reduces logging overhead in the face of both shorter-lived certificates and large post-quantum signature algorithms, while still achieving comparable security properties to traditional X.509 and Certificate Transparency. Merkle Tree certificates additionally admit an optional signatureless optimization, which decreases the message size by avoiding signatures altogether, at the cost of only applying to up-to-date relying parties and older certificates. |
| | 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. |
| | 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. |
| | A YANG Data Model for CMIS Access and Control |
| |
|
This document provides a YANG data model to access to and control CMIS for controlling Digital Coherent Optics device equipped in a router or a switch from outside. CMIS has custom pages which enables to be defined by the module vendor for its own usage, and allows to extend the uses of the optics devices. |
| | BIMI on an Independent MUA |
| |
|
This document describes a method by which a receiving MTA may insert Brand Indicators for Message Identification (BIMI) headers into a message in such a way that a third party MUA can not only use the information in those headers but also validate that the headers were inserted by the MTA. |
| | 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. |
| | Hybrid signature spectrums |
| |
|
This document describes classification of design goals and security considerations for hybrid digital signature schemes, including proof composability, non-separability of the component signatures given a hybrid signature, backwards/forwards compatibility, hybrid generality, and simultaneous verification. |
| | Performance Measurement Using Simple Two-Way Active Measurement Protocol (STAMP) for Segment Routing Networks |
| |
| | draft-ietf-spring-stamp-srpm-19.txt |
| | Date: |
20/06/2025 |
| | Authors: |
Rakesh Gandhi, Clarence Filsfils, Bart Janssens, Mach Chen, Richard Foote |
| | Working Group: |
Source Packet Routing in Networking (spring) |
|
Segment Routing (SR) leverages the source routing paradigm and applies to both Multiprotocol Label Switching (SR-MPLS) and IPv6 (SRv6) data planes. This document describes the procedures for Performance Measurement in SR networks using the Simple Two-Way Active Measurement Protocol (STAMP), as defined in RFC 8762, along with its optional extensions defined in RFC 8972 and further augmented in RFC 9503. The described procedure is used for links and SR paths (including SR Policies, SR IGP best paths, and SR IGP Flexible Algorithm paths), as well as Layer-3 and Layer-2 services in SR networks, and is applicable to both SR-MPLS and SRv6 data planes. |
| |
|
| |
| | DNS over CoAP (DoC) |
| |
| | draft-ietf-core-dns-over-coap-15.txt |
| | Date: |
19/06/2025 |
| | Authors: |
Martine Lenders, Christian Amsuess, Cenk Gundogan, Thomas Schmidt, Matthias Waehlisch |
| | Working Group: |
Constrained RESTful Environments (core) |
|
This document defines a protocol for exchanging DNS messages over the Constrained Application Protocol (CoAP). These CoAP messages can be protected by DTLS-Secured CoAP (CoAPS) or Object Security for Constrained RESTful Environments (OSCORE) to provide encrypted DNS message exchange for constrained devices in the Internet of Things (IoT). |
| | Bundle Transfer Protocol - Unidirectional |
| |
|
This document defines a protocol for the unidirectional transfer of large binary objects, typically Bundle Protocol version 7 bundles, between two nodes connected by a unidirectional, unreliable, frame- based link-layer protocol, without requiring IP services. The protocol does not require a return path for acknowledgements, but instead supports data repetition as a mechanism to protect against data loss. It fully supports the disaggregation of flows of binary objects of different priority, preventing head-of-line blocking impacting performance. The wire format of the protocol is designed to enable performant implementation in hardware or software, with the aim of enabling protocol implementations to run at the line-rate of the underlying link-layer protocol. |
| | Forward Error Correction for the Bundle Transfer Protocol |
| |
|
This document defines an optional extension to the Bundle Transfer Protocol - Unidirectional, as described in [BTPU], to enable forward error correction (FEC) coding to be applied selectively to the transfer of individual bundles on a case by case basis. The definition and use of FEC follows the FECFRAME framework defined in [RFC6363], and this document introduces new Message types to BTPU in order to carry the FEC information as defined in the framework. |
| | JSON Meta Application Protocol (JMAP) for Calendars |
| |
|
This document specifies a data model for synchronizing calendar data with a server using JMAP. Clients can use this to efficiently read, write, and share calendars and events, receive push notifications for changes or event reminders, and keep track of changes made by others in a multi-user environment. |
| | NETCONF and RESTCONF Private Candidate Datastores |
| |
|
This document provides a mechanism to extend the Network Configuration Protocol (NETCONF) and RESTCONF protocol to support multiple clients making configuration changes simultaneously and ensuring that they commit only those changes that they defined. This document addresses two specific aspects: The interaction with a private candidate over the NETCONF and RESTCONF protocols and the methods to identify and resolve conflicts between clients. |
| | HTTP Message Signatures Directory |
| |
|
This document describes a method for clients using [HTTP-MESSAGE-SIGNATURES] to advertise their signing keys. It defines a key directory format based on JWKS as defined in Section 5 of [JWK], as well as new HTTP Method Context to allow for in-band key discovery. |
| | HTTP Message Signatures for automated traffic Architecture |
| |
|
This document describes an architecture for identifying automated traffic using [HTTP-MESSAGE-SIGNATURES]. The goal is to allow automated HTTP clients to cryptographically sign outbound requests, allowing HTTP servers to verify their identity with confidence. |
| | Web bot auth Glossary |
| |
|
Automated traffic authentication presents unique security challenges, constraints, and opportunities that impact all Internet users. This document seeks to collect terminology and examples within the space, with a specific focus on AI related technologies. |
| | Fragmentation Revisited: For What It's Worth |
| |
|
Internet Protocol (IP) fragmentation and reassembly have served as core elements of the architecture from the very earliest days but they have been subject to negative publicity by studies that have declared them "harmful" and "fragile". These warning labels have resonated deeply within the community in a way that fosters the enemies of sound engineering: fear, uncertainty and doubt. This document revisits IP fragmentation and shows that a properly engineered alternative IPv6 solution is both practical and necessary to provide a robust service for the future of Internetworking. |
| | Secure Reporting of Update Status |
| |
| | draft-ietf-suit-report-12.txt |
| | Date: |
19/06/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 specification describes 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. |
| | WIMSE Workload to Workload Authentication |
| |
| | draft-ietf-wimse-s2s-protocol-05.txt |
| | Date: |
19/06/2025 |
| | Authors: |
Brian Campbell, Joe Salowey, Arndt Schwenkschuster, Yaron Sheffer |
| | Working Group: |
Workload Identity in Multi System Environments (wimse) |
|
The WIMSE architecture defines authentication and authorization for software workloads in a variety of runtime environments, from the most basic ones up to complex multi-service, multi-cloud, multi- tenant deployments. This document defines the simplest, atomic unit of this architecture: the protocol between two workloads that need to verify each other's identity in order to communicate securely. The scope of this protocol is a single HTTP request-and-response pair. To address the needs of different setups, we propose two protocols, one at the application level and one that makes use of trusted TLS transport. These two protocols are compatible, in the sense that a single call chain can have some calls use one protocol and some use the other. Workload A can call Workload B with mutual TLS authentication, while the next call from Workload B to Workload C would be authenticated at the application level. |
| |
|
| |
| | A Vocabulary For Expressing AI Usage Preferences |
| |
|
This document proposes a standardized vocabulary for expressing preferences related to how digital assets are used by automated processing systems. This vocabulary allows for the creation of structured declarations about restrictions or permissions for use of digital assets by such systems. |
| | Indicating Preferences Regarding Content Usage |
| |
|
Content creators and other stakeholders might wish to signal their preferences about how their content might be consumed by automated systems. This document defines how preferences can be signaled as part of the acquisition of content in HTTP. This document updates RFC 9309 to allow for the inclusion of usage preferences. |
| | EVPN Interworking with IPVPN |
| |
|
Ethernet Virtual Private Network (EVPN) is used as a unified control plane for tenant network intra and inter-subnet forwarding. When a tenant network spans not only EVPN domains but also domains where BGP VPN-IP or IP families provide inter-subnet forwarding, there is a need to specify the interworking aspects between BGP domains of type EVPN, VPN-IP and IP, so that the end-to-end tenant connectivity can be accomplished. This document specifies how EVPN interworks with VPN-IPv4/VPN-IPv6 and IPv4/IPv6 BGP families for inter-subnet forwarding. The document also addresses the interconnect of EVPN domains for Inter-Subnet Forwarding routes. In addition, this specification defines a new BGP Path Attribute called D-PATH (Domain PATH) that protects gateways against control plane loops. D-PATH modifies the BGP best path selection for multiprotocol BGP routes of SAFI 128 and EVPN IP Prefix routes, and therefore this document updates the BGP best path selection specification, but only for IPVPN and EVPN families. |
| | ICMP Extension Header Length Field |
| |
|
The ICMP Extension Structure does not have a length field. Therefore, unless the length of the Extension Structure can be inferred from other data in the ICMP message, the Extension Structure must be the last item in the ICMP message. This document defines a length field for the ICMP Extension Structure. When length information is provided, receivers can use it to parse ICMP messages. Specifically, receivers can use length information to determine the offset at which the item after the ICMP Extension Structure begins. |
| | Simple Two-Way Active Measurement Protocol (STAMP) Extensions for Reflecting STAMP Packet IP Headers |
| |
|
The Simple Two-Way Active Measurement Protocol (STAMP) and its optional extensions can be used for Edge-To-Edge (E2E) active measurement. In Situ Operations, Administration, and Maintenance (IOAM) data fields can be used for recording and collecting Hop-By- Hop (HBH) and E2E operational and telemetry information. This document extends STAMP to reflect IP headers as well as IPv6 extension headers for HBH and E2E active measurements, for example, using IOAM data fields. |
| | Composite ML-DSA for use in X.509 Public Key Infrastructure |
| |
| | draft-ietf-lamps-pq-composite-sigs-06.txt |
| | Date: |
18/06/2025 |
| | Authors: |
Mike Ounsworth, John Gray, Massimiliano Pala, Jan Klaussner, Scott Fluhrer |
| | Working Group: |
Limited Additional Mechanisms for PKIX and SMIME (lamps) |
|
This document defines combinations of ML-DSA [FIPS.204] in hybrid with traditional algorithms RSASSA-PKCS1-v1_5, RSASSA-PSS, ECDSA, Ed25519, and Ed448. These combinations are tailored to meet security best practices and regulatory guidelines. Composite ML-DSA is applicable in any application that uses X.509 or PKIX data structures that accept ML-DSA, but where the operator wants extra protection against breaks or catastrophic bugs in ML-DSA. |
| | Proxying Ethernet in HTTP |
| |
|
This document describes how to proxy Ethernet frames in HTTP. This protocol is similar to IP proxying in HTTP, but for Layer 2 instead of Layer 3. More specifically, this document defines a protocol that allows an HTTP client to create Layer 2 Ethernet tunnel through an HTTP server to an attached physical or virtual Ethernet segment. |
| | Flexible Hybrid PQ MLS Combiner |
| |
|
This document describes a protocol for combining a traditional MLS session with a post-quantum (PQ) MLS session to achieve flexible and efficient hybrid PQ confidentiality and authenticity that amortizes the computational cost of PQ Key Encapsulation Mechanisms and Digital Signature Algorithms. Specifically, we describe how to use the exporter secret of a PQ MLS session, i.e., an MLS session using a PQ ciphersuite, to seed PQ guarantees into an MLS session using a traditional ciphersuite. By supporting on-demand traditional-only key updates (a.k.a. PARTIAL updates) or hybrid-PQ key updates (a.k.a. FULL updates), we can reduce the bandwidth and computational overhead associated with PQ operations while meeting the requirement of frequent key rotations. |
| | Some Key Terms for Network Fault and Problem Management |
| |
| | draft-ietf-nmop-terminology-19.txt |
| | Date: |
18/06/2025 |
| | Authors: |
Nigel Davis, Adrian Farrel, Thomas Graf, Qin WU, Chaode Yu |
| | Working Group: |
Network Management Operations (nmop) |
|
This document sets out some terms that are fundamental to a common understanding of network fault and problem management within the IETF. The purpose of this document is to bring clarity to discussions and other work related to network fault and problem management, in particular to YANG models and management protocols that report, make visible, or manage network faults and problems. |
| | Indicating Non-Availability of Dynamic Updates in the DNS |
| |
|
The Start of Authority Resource Record in the Domain Name System includes various parameters related to the handling of data in DNS zones. These parameters are variously used by authority-only servers, caching resolvers and DNS clients to guide them in the way that data contained within particular zones should be used. One particular field in the SOA RR is known as MNAME, which is used to specify the "Primary Master" server for a zone. This is the server to which clients use Dynamic Update to send DNS UPDATE messages. Many zones do not support the Dynamic Update, and any such DNS UPDATE messages which are received provide no usual purpose. For such zones it may be preferable not to receive updates from clients at all. This document proposes a convention by which a zone operator can signal to clients that a particular zone does not support Dynamic Update. |
| | BGP Next-next Hop Nodes |
| |
|
BGP speakers learn their next hop addresses for NLRI in RFC-4271 in the NEXT_HOP field and in RFC-4760 in the "Network Address of Next Hop" field. Under certain circumstances, it might be desirable for a BGP speaker to know both the next hops and the next-next hops of NLRI to make optimal forwarding decisions. One such example is global load balancing (GLB) in a Clos network. Draft-ietf-idr-entropy-label defines the "Next Hop Dependent Characteristics Attribute" (NHC) which allows a BGP speaker to signal the forwarding characteristics associated with a given next hop. This document defines a new NHC characteristic, the Next-next Hop Nodes (NNHN) characteristic, which can be used to advertise the next- next hop nodes associated with a given next hop. |
| | Definition for Aggregated BMP Route Monitoring Message |
| |
|
This document proposes an aggregated BMP route monitoring message. It can compress multiple BMP route monitoring messages into one aggregated BMP route monitoring message to reduce the amount of reported BMP route monitoring messages and reduce network overhead. This document updates RFC 7854 by adding new BMP Messages type. |
| | A method for describing changes made to an email |
| |
|
This memo describes a method for describing the changes made to an email during common email modifications, for example those caused by mailing lists and forwarders. While this is general enough to be used for any changes, it is anticipated that this method will normally be used for removing added data rather than large complex changes. |
| | IP in Deep Space: Key Characteristics,Use Cases and Requirements |
| |
|
Deep space communications involve long delays (e.g., Earth to Mars has one-way delays 4-24 minutes) and intermittent communications, mainly because of orbital dynamics. The IP protocol stack used on the Internet is based on the assumptions of shorter delays and mostly uninterrupted communications. This document describes the key characteristics, use cases, and requirements for deep space networking, intended to help when profiling IP protocols in such environment. |
| | 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. |
| | Semantic Definition Format (SDF) Extension for Non-Affordance Information |
| |
|
This document describes an extension to the Semantic Definition Format (SDF) for representing non-affordance information of Things, such as physical, contextual, and descriptive metadata. This extension introduces a new class, sdfNonAffordance, that enables comprehensive modeling of Things and improves semantic clarity. |
| | Post-Quantum Traditional (PQ/T) Hybrid Authentication with Dual Certificates in TLS 1.3 |
| |
| | draft-yusef-tls-pqt-dual-certs-00.txt |
| | Date: |
18/06/2025 |
| | Authors: |
Rifaat Shekh-Yusef, Hannes Tschofenig, Mike Ounsworth, Yaron Sheffer, 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. |
| | 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. |
| | An Architecture for Trustworthy and Transparent Digital Supply Chains |
| |
| | draft-ietf-scitt-architecture-13.txt |
| | Date: |
18/06/2025 |
| | Authors: |
Henk Birkholz, Antoine Delignat-Lavaud, Cedric Fournet, Yogesh Deshpande, Steve Lasker |
| | Working Group: |
Supply Chain Integrity, Transparency, and Trust (scitt) |
|
Traceability in supply chains is a growing security concern. While verifiable data structures have addressed specific issues, such as equivocation over digital certificates, they lack a universal architecture for all supply chains. This document proposes a scalable architecture for single-issuer signed statement transparency applicable to any supply chain. It ensures flexibility, interoperability between different transparency services, and compliance with various auditing procedures and regulatory requirements. |
| | Amplification Attacks Using the Constrained Application Protocol (CoAP) |
| |
|
Protecting Internet of Things (IoT) devices against attacks is not enough. IoT deployments need to make sure that they are not used for Distributed Denial-of-Service (DDoS) attacks. DDoS attacks are typically done with compromised devices or with amplification attacks using a spoofed source address. This document gives examples of different theoretical amplification attacks using the Constrained Application Protocol (CoAP). The goal with this document is to raise awareness and to motivate generic and protocol-specific recommendations on the usage of CoAP. Some of the discussed attacks can be mitigated by not using NoSec or by using the Echo option. |
| | Convergence of Congestion Control from Retained State |
| |
| | draft-ietf-tsvwg-careful-resume-19.txt |
| | Date: |
18/06/2025 |
| | Authors: |
Nicolas Kuhn, Emile Stephan, Gorry Fairhurst, Raffaello Secchi, Christian Huitema |
| | Working Group: |
Transport and Services Working Group (tsvwg) |
|
This document specifies a cautious method for IETF transports that enables fast startup of CC for a wide range of connections. It reuses a set of computed CC parameters that are based on previously observed path characteristics between the same pair of transport endpoints. These parameters are saved, allowing them to be later used to modify the CC behaviour of a subsequent connection. It describes assumptions and defines requirements for how a sender utilises these parameters to provide opportunities for a connection to more rapidly get up to speed and rapidly utilise available capacity. It discusses how use of Careful Resume impacts the capacity at a shared network bottleneck and the safe response that is needed after any indication that the new rate is inappropriate. |
| |
|
| |
| | Common YANG Data Types for Layer 0 Networks |
| |
| | draft-ietf-ccamp-rfc9093-bis-15.txt |
| | Date: |
17/06/2025 |
| | Authors: |
Sergio Belotti, Italo Busi, Dieter Beller, Esther Le Rouzic, Aihua Guo |
| | Working Group: |
Common Control and Measurement Plane (ccamp) |
|
This document defines a collection of common data types, identities, and groupings in the YANG data modeling language. These common types and groupings, derived from the built-in YANG data types, identities, and groupings are intended to be imported by modules that model Optical Layer 0 configuration and state capabilities, such as Wavelength Switched Optical Networks (WSONs) and flexi-grid Dense Wavelength Division Multiplexing (DWDM) networks. This document obsoletes RFC 9093 by replacing the YANG module it contained with a new revision that includes additional YANG data types, identities and groupings. |
| | Verifiable Distributed Aggregation Functions |
| |
| | draft-irtf-cfrg-vdaf-15.txt |
| | Date: |
17/06/2025 |
| | Authors: |
Richard Barnes, David Cook, Christopher Patton, Phillipp Schoppmann |
| | Working Group: |
Crypto Forum (cfrg) |
|
This document describes Verifiable Distributed Aggregation Functions (VDAFs), a family of multi-party protocols for computing aggregate statistics over user measurements. These protocols are designed to ensure that, as long as at least one aggregation server executes the protocol honestly, individual measurements are never seen by any server in the clear. At the same time, VDAFs allow the servers to detect if a malicious or misconfigured client submitted an invalid measurement. Two concrete VDAFs are specified, one for general- purpose aggregation (Prio3) and another for heavy hitters (Poplar1). |
| | LISP Geo-Coordinates |
| |
|
This document describes how Geo-Coordinates can be used in the Locator/ID Separation Protocol (LISP). The functionality proposes a new LISP Canonical Address Format (LCAF) encoding for such Geo- Coordinate. This document updates RFC8060. |
| | Media Type Specifications and Registration Procedures |
| |
|
This document defines procedures for the specification and registration of media types for use in HTTP, MIME, and other Internet protocols. |
| | Extensible YANG Model for YANG-Push Notifications |
| |
|
This document defines a new extensible notification structure, defined in YANG, for use in YANG-Push Notification messages enabling any YANG-compatible encodings such as XML, JSON, or CBOR. Additionally, it defines two essential extensions to this structure, the support of a hostname and a sequence number and the support of a timestamp characterizing the moment when the changed data was observed. |
| | Proxy MAC-IP Advertisement in EVPNs |
| |
|
This document specifies procedures for EVPN PEs connected to a common multihomed site to generate proxy EVPN MAC-IP advertisements on behalf of other PEs to facilitate preservation of ARP/ND state across link or node failures. |
| | 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. |
| | SR Policy Group |
| |
|
Segment Routing is a source routing paradigm that explicitly indicates the forwarding path for packets at the ingress node. An SR Policy is associated with one or more candidate paths, and each candidate path is either dynamic, explicit, or composite. This document describes SR Policy Group in MPLS and IPv6 environments and illustrates some use cases for parent SR Policy and SR Policy Group to provide best practice cases for operators. |
| | 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. |
| | RDAP Extension for DNS Time-To-Live (TTL Values) |
| |
|
This document describes an extension to the Registration Data Access Protocol ([RFC9083]) which allows the Time-To-Live (TTL) values for relevant DNS record types to be included in RDAP responses. About this draft This note is to be removed before publishing as an RFC. The source for this draft, and an issue tracker, may can be found at https://github.com/gbxyz/rdap-ttl-extension. |
| | 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. |
| | ASPA-based AS_PATH Verification for BGP Export |
| |
|
This document describes that a BGP speaker may perform AS_PATH verification on the routes it sends to BGP neighbors at external BGP (eBGP) egress based on Autonomous System Provider Authorization (ASPA) objects in the Resource Public Key Infrastructure (RPKI). Before BGP speakers advertise routes to external peers at eBGP egress, performing ASPA-based AS_PATH verification can prevent route leaks to external peers, check for local misconfigurations and detect ASPA registration errors, thus avoiding the advertisement of invalid routes. |
| | SRv6 Path Verification |
| |
|
This document proposes a path verification mechanism for SRv6, which adopts a hop-by-hop cryptographic computation on the destination segment identifier at each node, combined with an end-to-end verification at the last hop. Although the HMAC mechanism specified in RFC 8754 can verify the integrity of the entire SID List, if we want to force the SRv6 endpoints the packet must pass through during forwarding, it is necessary to retain some information each time the packet passes through an SRv6 endpoint. This draft proposes an enhancement to HMAC specificed by RFC 8754 that provides the capability to enforce the packet's forwarding path to go through all or certain SRv6 endpoints in the SID List. And this approach also significantly reduces the processing overhead associated with hop-by- hop path verification. |
| | Verifiable Voice Protocol |
| |
|
Verifiable Voice Protocol (VVP) authenticates and authorizes organizations and individuals making and/or receiving telephone calls. This eliminates trust gaps that malicious parties exploit. Like related technolgies such as SHAKEN, RCD, and BCID, VVP can bind cryptographic evidence to a SIP INVITE, and verify this evidence downstream. VVP can also let evidence flow the other way, proving things about the callee. VVP builds from different technical and governance assumptions than alternatives, and uses stronger, richer evidence. This allows VVP to cross jurisdictional boundaries easily and robustly. It also makes VVP simpler, more decentralized, cheaper to deploy and maintain, more private, more scalable, and higher assurance. Because it is easier to adopt, VVP can plug gaps or build bridges between other approaches, functioning as glue in hybrid ecosystems. For example, it may justify an A attestation in SHAKEN, or an RCD passport for branded calling, when a call originates outside SHAKEN or RCD ecosystems. VVP also works well as a standalone mechanism, independent of other solutions. An extra benefit is that VVP enables two-way evidence sharing with verifiable text and chat (e.g., RCS and vCon), as well as with other industry verticals that need verifiability in non-telco contexts. |
| | Simple Two-Way Active Measurement Protocol (STAMP) Extensions for Bit Error Rate Measurement |
| |
|
The Simple Two-Way Active Measurement Protocol (STAMP), as defined in RFC 8762, along with its optional extensions specified in RFC 8972, can be utilized for active measurement. This document further augments the STAMP extensions specified in RFC 8972 to enable the measurement of the bit error rate within the "Extra Padding" TLV of STAMP packets. |
| | The Reason for Abandoning the UPA Draft |
| |
|
[I-D.ietf-lsr-igp-ureach-prefix-announce] (UPA draft) proposes the solution to announce the prefix unreachable information within the IGP domain. It utilizes the LSInfinity concept that is introduced in [RFC2328], without analyzing the dormant and flawed design. The proposal doesn't work even in simple scenario, is based on one flawed feature, lacks the explicit withdrawn procedures. This document analyzes the above issues, suggests the IETF commuity abandon the UPA draft, replace it with other more comprehensive document [I-D.wang-lsr-prefix-unreachable-annoucement](Founder Draft), to provide the IETF community the more optimal solution. |
| | Signalling a Zone Cut to Nowhere in the DNS |
| |
|
This document defines a standard means to signal that a zone cut exists in the DNS without specifying a set of nameservers to which a child zone is delegated. This is useful in situations where it is important to make it clear to clients that a zone cut exists, but when the child zone is only provisioned in a private namespace. |
| | Extension Registry for the Extensible Provisioning Protocol |
| |
|
The Extensible Provisioning Protocol (EPP) includes features to add functionality by extending the protocol. It does not, however, describe how those extensions are managed. This document describes a procedure for the registration and management of extensions to EPP, and it specifies a format for an IANA registry to record those extensions. |
| | Cross-Device Flows: Security Best Current Practice |
| |
|
This document describes threats against cross-device flows along with practical mitigations, protocol selection guidance, and a summary of formal analysis results identified as relevant to the security of cross-device flows. It serves as a security guide to system designers, architects, product managers, security specialists, fraud analysts and engineers implementing cross-device flows. |
| | Post-Quantum Cryptography in OpenPGP |
| |
| | draft-ietf-openpgp-pqc-12.txt |
| | Date: |
17/06/2025 |
| | Authors: |
Stavros Kousidis, Johannes Roth, Falko Strenzke, Aron Wussler |
| | Working Group: |
Open Specification for Pretty Good Privacy (openpgp) |
|
This document defines a post-quantum public-key algorithm extension for the OpenPGP protocol. Given the generally assumed threat of a cryptographically relevant quantum computer, this extension provides a basis for long-term secure OpenPGP signatures and ciphertexts. Specifically, it defines composite public-key encryption based on ML- KEM (formerly CRYSTALS-Kyber), composite public-key signatures based on ML-DSA (formerly CRYSTALS-Dilithium), both in combination with elliptic curve cryptography, and SLH-DSA (formerly SPHINCS+) as a standalone public key signature scheme. |
| | Hash-based Signatures: State and Backup Management |
| |
| | draft-ietf-pquip-hbs-state-00.txt |
| | Date: |
17/06/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 (S-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, S-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 documents security considerations for the operational and technical aspects of deploying systems that rely on S-HBS. Management of the state of the S-HBS, including any handling of redundant key material, is a sensitive topic, and we discuss some approaches to handle the associated challenges. We also describe the challenges that need to be resolved before certain approaches should be considered. |
| | Device Schema Extensions to the SCIM model |
| |
|
The initial core schema for SCIM (System for Cross Identity Management) was designed for provisioning users. This memo specifies schema extensions that enables provisioning of devices, using various underlying bootstrapping systems, such as Wi-fi Easy Connect, FIDO device onboarding vouchers, BLE passcodes, and MAC authenticated bypass. |
| | Hybrid key exchange in TLS 1.3 |
| |
|
Hybrid key exchange refers to using multiple key exchange algorithms simultaneously and combining the result with the goal of providing security even if all but one of the component algorithms is broken. It is motivated by transition to post-quantum cryptography. This document provides a construction for hybrid key exchange in the Transport Layer Security (TLS) protocol version 1.3. Discussion of this work is encouraged to happen on the TLS IETF mailing list tls@ietf.org or on the GitHub repository which contains the draft: https://github.com/dstebila/draft-ietf-tls-hybrid-design. |
| |
|
| |
| | BGP based Multi-homing in Virtual Private LAN Service |
| |
|
Virtual Private LAN Service (VPLS) is a Layer 2 Virtual Private Network (VPN) that gives its customers the appearance that their sites are connected via a Local Area Network (LAN). It is often required for the Service Provider (SP) to give the customer redundant connectivity to some sites, often called "multi-homing". This memo shows how BGP-based multi-homing can be offered in the context of LDP and BGP VPLS solutions. This document updates RFC 4761 by defining new flags in the Control Flags field of the Layer2 Info Extended Community. |
| | Composite ML-KEM for use in X.509 Public Key Infrastructure |
| |
| | draft-ietf-lamps-pq-composite-kem-07.txt |
| | Date: |
16/06/2025 |
| | Authors: |
Mike Ounsworth, John Gray, Massimiliano Pala, Jan Klaussner, Scott Fluhrer |
| | Working Group: |
Limited Additional Mechanisms for PKIX and SMIME (lamps) |
|
This document defines combinations of ML-KEM [FIPS.203] in hybrid with traditional algorithms RSA-OAEP, ECDH, X25519, and X448. These combinations are tailored to meet security best practices and regulatory guidelines. Composite ML-KEM is applicable in any application that uses X.509 or PKIX data structures that accept ML- KEM, but where the operator wants extra protection against breaks or catastrophic bugs in ML-KEM. |
| | Proxying Bound UDP in HTTP |
| |
|
The mechanism to proxy UDP in HTTP only allows each UDP Proxying request to transmit to a specific host and port. This is well suited for UDP client-server protocols such as HTTP/3, but is not sufficient for some UDP peer-to-peer protocols like WebRTC. This document proposes an extension to UDP Proxying in HTTP that enables such use- cases. |
| | YANG Notification Transport Capabilities |
| |
|
This document specifies a YANG module for YANG notifications transport capabilities which augments the notification capabilities model. The module provides transport protocol, transport encoding, and transport encryption system capabilities for transport-specific notification. This YANG module can be used by the client to learn capability information from the server at runtime or at implementation time, by making use of the YANG instance data file format. |
| | Brand Indicators for Message Identification (BIMI) |
| |
|
Brand Indicators for Message Identification (BIMI) permits Domain Owners to coordinate with Mail User Agents (MUAs) to display brand- specific Indicators next to properly authenticated messages. There are two aspects of BIMI coordination: a scalable mechanism for Domain Owners to publish their desired Indicators, and a mechanism for Mail Transfer Agents (MTAs) to verify the authenticity of the Indicator. This document specifies how Domain Owners communicate their desired Indicators through the BIMI Assertion Record in DNS and how that record is to be interpreted by MTAs and MUAs. MUAs and mail- receiving organizations are free to define their own policies for making use of BIMI data and for Indicator display as they see fit. |
| | SID as source address in SRv6 |
| |
|
In SRv6 network, the SRv6 packets usually use loopback address as source address. However, when there is symmetric traffic requirement for bidirectional flow, or there is requirement for traffic source validation, using loopback address as source address is not sufficient. This document proposes using SID as source address for SRv6 traffic, also identifies solution for several use cases. |
| | eXtensible Stateless Equipment Data Exchange |
| |
| | draft-guy-xfsp-02.txt |
| | Date: |
16/06/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. |
| | Simple Local Web PKI Certificate Resource Preservation Management for Internet Browser |
| |
|
The management of Web PKI certificate resources presents a challenge when the misalignment of ownership and management rights over certificate resources of one organization creating a risk of unilateral suspension and revocation by another competing organizations. This situation undermines the stability of critical infrastructure and affects the integrity of authentication systems. To address these concerns, this document proposes a mechanism that allows Internet browsers to create a customized management view of certificate resources, enabling them to override the verification results from specific certification authorities as needed. This approach enhances security, facilitates stakeholder collaboration, and preserves the operational integrity of foundational industry systems. |
| | Export of Gigabit Passive Optical Network Encapsulation Mode in IP Flow Information Export (IPFIX) |
| |
|
This document introduces new IP Flow Information Export (IPFIX) Information Elements to identify a set of G-PON Encapsulation Method entities in the Passive Optical Transport of the Optical Distribution Network. |
| | The Fast Software Authenticated Encryption HiAE |
| |
| | draft-pham-cfrg-hiae-01.txt |
| | Date: |
16/06/2025 |
| | Authors: |
Frank Denis, Pham Phuong, Lucas Prabel, Sun Shuzhou |
| | Working Group: |
Individual Submissions (none) |
|
This document describes the high throughput authenticated encryption algorithm HiAE designed for new wireless generation 6G and data transmission applications. |
| | 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. |
| | Proxy for Congestion Notification |
| |
|
This document describes the necessity and feasibility to introduce a proxy network node between the congested network node and the traffic sender. The proxy network node is used to translate the congestion notification. The congested network node sends the congestion notification to the proxy network node in a format defined in this document, and the proxy network node translates the received congestion notification to a format known by the traffic sender and resends the translated congestion notification to the traffic sender. |
| | Allow using serverAuth certificates for mutual TLS (mTLS) authentication in server-to-server usages. |
| |
|
This document aims to standardize the validation of mutual TLS authentication between servers (server-to-server). It outlines recommended validation flows as well as provides practical design recommendations. Basically the EKU id-kp-clientAuth and id-kp- serverAuth get more precisely defined to represent their common understanding by issuing CAs and browsers. id-kp-clientAuth aka. "TLS WWW client authentication" SHOULD mean authentication of a natural or legal entity. id-kp-serverAuth aka. "TLS WWW server authetnication" SHOULD mean authentication of a device. When two id- kp-clientAuth certificates are used this means E2E authentication between two users. Where as two id-kp-serverAuth certificates being used means server-to-server authentication. And one user and one server certificate within one TLS connection means client-to-server (or technically also server-to-client). The term "TLS-Client" SHOULD no longer be used and mean the party sending the initial package while establishing a TLS connection. This helps to avoid design issues moving forward as currently some people thought TLS-Client auth was only ever used in "client-to-server" and never within "server-to-server" context. Which sparked the demand for this document to begin with to keep server-to-server auth with public trusted certificates working. |
| | RPKI Manifest Number Handling |
| |
|
The Resource Public Key Infrastructure (RPKI) makes use of signed objects called manifests. A manifest lists each file that a publisher intends to include within an RPKI repository, and can be used to detect certain forms of attack against a repository. Manifests include a "manifest number" (manifestNumber), which the publisher must increment whenever it issues a new manifest, and Relying Parties (RPs) are required to verify that a newly-retrieved manifest for a given Certification Authority (CA) has a higher manifestNumber than the previously-validated manifest. However, the manifestNumber field is 20 octets in length (i.e. not unbounded), and no behaviour is specified for when a manifestNumber reaches the largest possible value. This document specifies publisher and RP behaviour for this scenario. |
| | 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. |
| | IANA Registry Updates for TLS and DTLS |
| |
|
This document updates the changes to TLS and DTLS IANA registries made in RFC 8447. It adds a new value "D" for discouraged to the Recommended column of the selected TLS registries and adds a "Comment" column to all active registries that do not already have a "Comment" column. Finally, it updates the registration request instructions. This document updates RFC 8447. |
| | Bootstrapping TLS Encrypted ClientHello with DNS Service Bindings |
| |
|
To use TLS Encrypted ClientHello (ECH) the client needs to learn the ECH configuration for a server before it attempts a connection to the server. This specification provides a mechanism for conveying the ECH configuration information via DNS, using a SVCB or HTTPS resource record (RR). |
| |
|
| |
| | RTP Payload Format for sub-codestream latency JPEG 2000 streaming |
| |
|
This RTP payload format defines the streaming of a video signal encoded as a sequence of JPEG 2000 codestreams. The format allows sub-codestream latency, such that the first RTP packet for a given image can be emitted before the entire image is available to, or encoded by, the sender. |
| | TLS Client Authentication via DANE TLSA records |
| |
|
The DANE TLSA protocol describes how to publish Transport Layer Security (TLS) server certificates or public keys in the DNS. This document updates RFC 6698 and RFC 7671. It describes how to additionally use the TLSA record to publish client certificates or public keys, and also the rules and considerations for using them with TLS. |
| | TLS Extension for DANE Client Identity |
| |
|
This document specifies a TLS and DTLS extension to convey a DNS- Based Authentication of Named Entities (DANE) Client Identity to a TLS or DTLS server. This is useful for applications that perform TLS client authentication via DANE TLSA records. |
| | Applicability of Border Gateway Protocol - Link State (BGP-LS) with Multi-Topology (MT) for Segment Routing based Network Resource Partitions (NRPs) |
| |
|
An 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, which provide advanced features such as guaranteed resources, bounded latency or jitter to meet specific customer connectivity requirements. When Segment Routing (SR) is used for building NRPs, each NRP can be allocated with a group of Segment Identifiers (SIDs) to identify the topology and resource attributes of network segments in the NRP. In some network scenarios, each NRP can be associated with a unique logical network topology. When a centralized network controller is used for NRP-specific constraint-based path computation, especially when an NRP spans multiple IGP areas or multiple Autonomous Systems (ASes), BGP-LS is needed to advertise the NRP topology and associated resource information to the network controller. This document describes a mechanism to distribute the information of SR based NRPs using BGP-LS with MT. |
| | 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. |
| | 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. |
| | Testing async submission |
| |
|
This draft is submitted only to test the async api submission endpoint |
| | Transmission of IP Packets over Overlay Multilink Network (OMNI) Interfaces |
| |
|
Air/land/sea/space mobile nodes (e.g., aircraft of various configurations, terrestrial vehicles, seagoing vessels, space systems, enterprise wireless devices, pedestrians with cell phones, etc.) communicate with networked correspondents over wireless and/or wired-line data links and configure mobile routers to connect end user networks. This document presents a multilink virtual interface specification that enables mobile nodes to coordinate with a network- based mobility service, fixed node correspondents and/or other mobile node peers. The virtual interface provides an adaptation layer service suited for both mobile and more static environments such as enterprise and home networks. Both Provider-Aggregated (PA) and Provider-Independent (PI) addressing services are supported. This document specifies the transmission of IP packets over Overlay Multilink Network (OMNI) Interfaces. |
| | Automatic Extended Route Optimization (AERO) |
| |
|
This document specifies an Automatic Extended Route Optimization (AERO) service for IP internetworking over Overlay Multilink Network (OMNI) Interfaces. AERO/OMNI uses IPv6 Neighbor Discovery (IPv6 ND) for control plane messaging over the OMNI virtual link. Router discovery and neighbor coordination are employed for network admission and to manage the OMNI link forwarding and routing systems. Secure multilink path selection, multinet traversal, mobility management, multicast forwarding, multihop operation and route optimization are naturally supported through dynamic neighbor cache updates on a per flow basis. Both Provider-Aggregated (PA) and Provider-Independent (PI) addressing services are supported. AERO is a widely-applicable service especially well-suited for air/land/sea/ space mobility applications including aviation, intelligent transportation systems, mobile end user devices, space exploration and many others. |
| | Stateless MNA-based Egress Protection (SMEP) |
| |
|
The MPLS Egress Protection Framework specifies a fast reroute framework for protecting IP/MPLS services. To that end, bypass tunnels have to be signaled to the Point of Local Repair (PLR). Further, the PLR must maintain the bypass forwarding state on a per- transport-tunnel basis. This document presents the concept of Stateless MNA-based Egress Protection (SMEP). SMEP protects egress routers by providing alternative MPLS egress labels in-stack. This mechanism does not require a bypass forwarding state in PLRs. An example for the application of SMEP is given using a MPLS network action for stack management. |
| | Procedures for Handling Liaison Statements to and from the IETF |
| |
|
This document describes the procedures for generating and handling liaison statements between the IETF and other SDOs, so that the IETF can effectively collaborate with other organizations in the international standards community. |
| | JWTClaimConstraints profile of ACME Authority Token |
| |
|
This document defines an authority token profile for handling the validation of JWTClaimConstraints and EnhancedJWTClaimConstraints. This profile follows the model established in Authority Token for the validation of TNAuthList but is specifically tailored for the JWTClaimConstraints certificate extensions. The profile enables validation and challenge processes necessary to support certificates containing both TNAuthList and JWTClaimConstraints, particularly in the context of Secure Telephone Identity (STI). |
| | Guidelines for Considering Operations and Management in IETF Specifications |
| |
| | draft-opsarea-rfc5706bis-02.txt |
| | Date: |
13/06/2025 |
| | Authors: |
Benoit Claise, Joe Clarke, Adrian Farrel, Thomas Graf, Samier Barguil, Carlos Pignataro, Ran Chen |
| | Working Group: |
Individual Submissions (none) |
|
New Protocols or Protocol Extensions are best designed with due consideration of the functionality needed to operate and manage the protocols. Retrofitting operations and management is sub-optimal. The purpose of this document is to provide guidance to authors and reviewers of documents that define New Protocols or Protocol Extensions regarding aspects of operations and management that should be considered. This document obsoletes RFC 5706, replacing it completely and updating it with new operational and management techniques and mechanisms. It also introduces a requirement for an "Operational and Management Considerations" section in Internet-Drafts, before they are progressed for publication as RFCs. |
| | Framework for Energy Efficiency Management |
| |
| | draft-belmq-green-framework-03.txt |
| | Date: |
13/06/2025 |
| | Authors: |
Benoit Claise, Luis Contreras, Jan Lindblad, Marisol Amador, Emile Stephan, Qin WU |
| | Working Group: |
Individual Submissions (none) |
|
Recognizing the urgent need for energy efficiency, this document specifies a management framework focused on devices and device components within, or connected to, interconnected systems. The framework aims to enable energy usage optimization, based on the network condition while achieving the network's functional and performance requirements (e.g., improving overall network utilization) and also ensure interoperability across diverse systems. Leveraging data from existing use cases, it delivers actionable metrics to support effective energy management and informed decision- making. Furthermore, the framework proposes mechanisms for representing and organizing timestamped telemetry data using YANG models and metadata, enabling transparent and reliable monitoring. This structured approach facilitates improved energy efficiency through consistent energy management practices. |
| | MPLS Network Action for Stack Management |
| |
|
The MPLS Network Action (MNA) framework provides a general mechanism for the encoding and processing of network actions and their data. This document introduces a network action to the MPLS Network Action (MNA) framework for stack management operations including MOVE-N-LSE and POP-N-LSE. The MOVE-N-LSE operation elevates a specified number of LSEs within the stack and the POP-N-LSE operation removes a specified number of LSEs. The stack management operations can be used to facilitate various applications. As an example, a mechanism called HBH preservation which reduces the readable label depth (RLD) requirement in nodes is presented. |
| | Signaling MNA Capabilities Using IGP |
| |
|
This document defines capabilities of nodes supporting MPLS Network Actions (MNA) and how to signal them using IS-IS and OSPF. The capabilities include the Readable Label Depth (RLD), supported network action opcodes, and the maximum sizes of differently scoped Network Action Sub-stacks (NAS), called the NAS_MLD. For IS-IS and OSPF signaling, sub-TLV encodings based on existing mechanisms to signal node- and link-specific capabilities are leveraged. |
| | Capability Attestation Extensions for the Entity Attestation Token (EAT) in Agentic AI Systems |
| |
|
This document specifies extensions to the Entity Attestation Token (EAT) [RFC9248] to support robust, interoperable attestation of capabilities in agentic AI systems. These extensions introduce new claims and guidance for securely asserting agent functional, reasoning, and operational capabilities, as well as their compositional structure and policy constraints. The goal is to enable trustworthy, verifiable, and privacy-respecting capability attestation for autonomous agents in dynamic, decentralized environments. |
| | Extending Certificate Enrollment Protocols for Scalable Agentic AI Identity |
| |
|
Agentic AI systems require robust, verifiable identities to operate securely. While traditional certificate enrollment protocols like SCEP and EST can be extended to include remote attestation evidence, performing a full validation for every agent's certificate request presents significant scalability and privacy challenges. This document proposes two distinct, scalable models for integrating attestation into the enrollment lifecycle. The first model leverages Zero-Knowledge Proofs (ZKP) to provide private, efficient, and continuous attestation. The second model uses a one-time, high- assurance bootstrapping process to establish a trusted host environment, which is then authorized to endorse certificate requests for the agents it runs. Both models enable high-assurance identity for AI agents while addressing the performance bottlenecks of naive per-enrollment verification. |
| | Publishing End-Site Prefix Lengths |
| |
|
This document specifies how to augment the Routing Policy Specification Language (RPSL) inetnum: class to refer specifically to prefixlen comma-separated values (CSV) data files and describes an optional scheme that uses the Resource Public Key Infrastructure (RPKI) to authenticate the prefixlen data files. |
| | SVGs in RFCs |
| |
|
This document sets policy for the inclusion of SVGs in the definitive versions of RFCs and relevant publication formats. It contains policy requirements from RFC 7996 and removes all requirements related to using a specific SVG profile or specific implementation code. It also makes the RFC Publication Center (RPC) responsible for implementation decisions regarding SVGs. |
| | Static Context Header Compression (SCHC) for the Internet Control Message Protocol (ICMPv6) |
| |
|
This document describes how the ICMPv6 protocol can be integrated into the SCHC architecture. It extends the YANG Data Model with new field IDs specific to ICMPv6 headers. To enhance the compression of ICMPv6 error messages, the document also introduces two new Matching Operators and two new Compression Decompression Actions to manipulate the ICMPv6 payload. Finally, for constrained networks such as LPWAN, it introduces a proxy behavior, where a SCHC Core end-point may anticipate the device reaction to incorrect messages. |
| |
|
| |
| | ML-DSA for JOSE and COSE |
| |
| | draft-ietf-cose-dilithium-07.txt |
| | Date: |
12/06/2025 |
| | Authors: |
Michael Prorock, Orie Steele, Rafael Misoczki, Michael Osborne, Christine Cloostermans |
| | Working Group: |
CBOR Object Signing and Encryption (cose) |
|
This document describes JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE) serializations for Module- Lattice-Based Digital Signature Standard (ML-DSA), a Post-Quantum Cryptography (PQC) digital signature scheme defined in FIPS 204. |
| | COSE Header parameter for RFC 3161 Time-Stamp Tokens |
| |
|
This document defines two CBOR Signing And Encrypted (COSE) header parameters for incorporating RFC 3161-based timestamping into COSE message structures (COSE_Sign and COSE_Sign1). This enables the use of established RFC 3161 timestamping infrastructure in COSE-based protocols. |
| | BMP YANG Module |
| |
| | draft-ietf-grow-bmp-yang-05.txt |
| | Date: |
12/06/2025 |
| | Authors: |
Camilo Cardona, Paolo Lucente, Thomas Graf, Benoit Claise, Dhananjay Patki, Narasimha Prasad |
| | Working Group: |
Global Routing Operations (grow) |
|
This document proposes a YANG module for the configuration and monitoring of the BGP Monitoring Protocol (BMP). |
| | A Common YANG Data Model for Scheduling |
| |
|
This document defines common types and groupings that are meant to be used for scheduling purposes such as event, policy, services, or resources based on date and time. For the sake of better modularity, the YANG module includes a set of recurrence related groupings with varying levels of representation (i.e., from basic to advanced) to accommodate a variety of requirements. It also defines groupings for validating requested schedules and reporting scheduling status. |
| | Paired MLS - PCS in Limited Modes |
| |
|
This document describes the Paired Messaging Layer Security (MLS) extension that improves Post Compromise Security for devices that are unable to self-update using a trusted paired device. |
| | 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)". |
| | Adaptive Routing Notification for Load-balancing |
| |
|
In this document, adaptive routing is referred to as a technology that makes dynamic traffic forwarding decisions based on changes in traffic load and network topology, devices with adaptive routing capabilities can dynamically select the outport in the forwarding table based on the congestion condition of the outport or downstream link. This document focuses on the information carried in (Adaptive Routing Notification)ARN messages and how they are delivered and processed in the network. |
| | POSIX Draft ACL support for Network File System Version 4,Minor Version 2 |
| |
|
This document describes a potential protocol extension involving the addition of four new attributes to be used by servers to provide support for POSIX ACLs. The term POSIX ACLs refers to the ACL component of the Portable Operating System Interface (POSIX) 1003.1e draft 17 document for which sponsorship was withdrawn in January 1998. Although the draft POSIX standard that describes these ACLs was never ratified, several POSIX-based operating systems, such as Linux, Solaris and FreeBSD include support for them. The NFS Version 4 (NFSv4) ACLs described in Network File System (NFS) Version 4 Minor Version 1 henceforth referred to as NFSv4 ACLs, use a different model and attempts to map between the ACLs of these two models have not been completely successful. In order to adequately support POSIX ACLs, this document proposes four new attributes that may optionally be used by an NFS Version 4, minor version 2 (NFSv4.2) server to support ACLs that conform to the aforementioned POSIX 1003.1e draft 17. |
| | SSH Support of ML-DSA |
| |
|
This document describes the use of ML-DSA digital signatures in the Secure Shell (SSH) protocol. |
| | Concise Selector for Endorsements and Reference Values |
| |
|
In the Remote Attestation Procedures (RATS) architecture, Verifiers require Endorsements and Reference Values to assess the trustworthiness of Attesters. This document specifies the Concise Selector for Endorsements and Reference Values (CoSERV), a structured query/result format designed to facilitate the discovery and retrieval of these artifacts from various providers. CoSERV defines a query language and corresponding result structure using CDDL, which can be serialized in CBOR format, enabling efficient interoperability across diverse systems. |
| | Automatic Certificate Management Environment (ACME) with OpenID Federation 1.0 |
| |
|
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 the possession of public keys, protocol specific metadata and various 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. |
| | Announce Existence of Parent CDS/CSYNC Scanner |
| |
|
In DNS operations, automated scanners are commonly employed by the operator of a parent zone to detect the presence of specific records, such as CDS or CSYNC, in child zones, indicating a desire for delegation updates. However, the presence and periodicity of these scanners are typically implicit and undocumented, leading to inefficiencies and uncertainties.  This document proposes an extension to the semantics of the DSYNC resource record, as defined in [I-D.draft-ietf-dnsop-generalized-notify], allowing parent zones to explicitly signal the presence and scanning interval of such automated scanners. This enhancement aims to improve transparency and coordination between child and parent zones. TO BE REMOVED: This document is being collaborated on in Github at: https://github.com/johanix/draft-berra-dnsop-announce-scanner (https://github.com/johanix/draft-berra-dnsop-announce-scanner). The most recent working version of the document, open issues, etc, should all be available there. The authors (gratefully) accept pull requests. |
| | An EAT Profile for Device Attestation |
| |
|
In confidential computing, device assignment (DA) is the method by which a device (e.g., network adapter, GPU), whether on-chip or behind a PCIe Root Port, is assigned to a Trusted Virtual Machine (TVM). For the TVM to trust the device, the device must provide the TVM with attestation Evidence confirming its identity and the state of its firmware and configuration. Since Evidence claims can be consumed by 3rd party attestation services external to the TVM, there is a need to standardise the representation of Evidence to ensure interoperability. This document defines an attestation Evidence format for DA as an EAT (Entity Attestation Token) profile. |
| | The HPKE Elligator KEM |
| |
|
This document contains the GNUnet communicator specification. This document defines the normative wire format of communicator protocols, cryptographic routines and security considerations for use by implementers. This specification was developed outside the IETF and does not have IETF consensus. It is published here to inform readers about the function of GNUnet communicators, guide future communicator implementations, and ensure interoperability among implementations including with the pre-existing GNUnet implementation. |
| | A YANG Data Model for the Virtual Router Redundancy Protocol (VRRP) |
| |
|
This document describes a YANG data model for the Virtual Router Redundancy Protocol (VRRP). Both versions 2 and 3 of VRRP are covered. The VRRP terminology has been updated conform to inclusive language guidelines for IETF technologies. This document obsoletes RFC 8347. |
| | SSH Agent Protocol |
| |
|
This document describes 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. |
| |
|
| |
| | 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. |
| | An sdfType for Links |
| |
|
This document defines and registers an sdfType "link" for the Semantic Definition Format (SDF) for Data and Interactions of Things (draft-ietf-asdf-sdf). |
| | Computing-Aware Traffic Steering (CATS) Problem Statement,Use Cases,and Requirements |
| |
|
Distributed computing is a computing pattern that service providers can follow and use to achieve better service response time and optimized energy consumption. In such a distributed computing environment, compute intensive and delay sensitive services can be improved by utilizing computing resources hosted in various computing facilities. Ideally, compute services are balanced across servers and network resources to enable higher throughput and lower response time. To achieve this, the choice of server and network resources should consider metrics that are oriented towards compute capabilities and resources instead of simply dispatching the service requests in a static way or optimizing solely on connectivity metrics. The process of selecting servers or service instance locations, and of directing traffic to them on chosen network resources is called "Computing-Aware Traffic Steering" (CATS). This document provides the problem statement and the typical scenarios for CATS, which shows the necessity of considering more factors when steering traffic to the appropriate computing resource to better meet the customer's expectations. |
| | Reliable and Available Wireless Architecture |
| |
|
Reliable and Available Wireless (RAW) extends the reliability and availability of DetNet to networks composed of any combination of wired and wireless segments. The RAW Architecture leverages and extends RFC 8655, the Deterministic Networking Architecture, to adapt to challenges that affect prominently the wireless medium, notably intermittent transmission loss. This document defines a network control loop that optimizes the use of constrained bandwidth and energy while assuring the expected DetNet services. The loop involves a new Point of Local Repair (PLR) function in the DetNet service sublayer that dynamically selects the DetNet path(s) for packets to route around local connectivity degradation. |
| | A YANG Network Data Model of Network Inventory Software Extensions |
| |
|
The base Network Inventory YANG model defines the physical network elements (NEs) and hardware components of NEs. This document extends the base Network Inventory model for non-physical NEs (e.g., controllers, virtual routers, virtual firewalls) and software components (e.g., platform operating system (OS), software-patch). |
| | Transport Layer Protocol Requirement for LEO satellite |
| |
|
In recent years, high-bandwidth LEO (Low Earth Orbit) satellite networks, such as Starlink and OneWeb, have seen tremendous development and are gradually becoming an important part of the global Internet. However, due to the unique characteristics of satellite networks, using TCP for data transmission faces challenges in multiple aspects, such as high latency caused by long-distance propagation and high error rates due to signal attenuation. This proposal summarizes the basic requirements that need to be considered for designing transport layer protocols tailored to LEO satellites. |
| | RTP Payload Format for ISO/IEC 21122 (JPEG XS) |
| |
|
This document specifies a Real-Time Transport Protocol (RTP) payload format for transport of a video signal encoded with JPEG XS (ISO/IEC 21122). JPEG XS is a low-latency and low-complexity video coding system. Employing this format allows achieving encoding-decoding latencies confined to a fraction of a video frame. This document is a necessary revision of RFC 9134 to incorporate support for new features introduced in the third edition of JPEG XS. Most notably, it contains the necessary provisions to support the TDC coding mode. This document obsoletes RFC 9134; however, the revised payload format is designed to ensure that existing compliant implementations of RFC 9134 remain valid under the updated specification. Additionally, this document consolidates the errata of RFC 9134 and includes improvements and clarifications to its implementers and users. |
| | Forwarding Commitment BGP Testbed and Deployment Experience |
| |
|
Forwarding Commitment BGP (FC-BGP) enables the establishment of a secure inter-domain routing system by providing security for the path of Autonomous Systems (ASs) through which a BGP UPDATE message passes. In an effort to enhance the validation of FC-BGP, a prototype implementation of the FC-BGP was developed and an evaluation was conducted on the FITI high-performance IPv6 backbone network. This document reports on the prototype implementation and the results of the evaluation. |
| | Technical Considerations for Transport Layer Protocols Optimization for Satellite Networks (T4SAT) |
| |
|
This document analyses the gaps of the existing transport layer technologies and provides technical considerations for Transport Layer Protocols Optimization for Satellite Networks (T4SAT). |
| | LEO transport problem statement |
| |
|
LSN, Starlink and OneWeb, can provide global Internet connectivity with latency comparable to terrestrial networks, but their fast movement and frequent handovers result in highly dynamic connectivity changes. The fast movement of LSN will introduce frequent handover and varying link delays every few minutes. As the path over LSN varies, TCP cannot tell whether changes in packet loss or RTT are due to path changes or network congestion, thus it might not be able to make proper adjustment. This greatly impact the performance of TCP. |
| | 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". Segments can represent topological or service based instructions. Segments can further be associated with a set of network resources used for executing the instruction. Such segments are called resource-aware segments. 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. |
| |
|
| |
| | EVPN Fast Reroute |
| |
|
This document summarises EVPN convergence mechanisms and specifies procedures for EVPN networks to achieve fast and scale-independent convergence. |
| | Intent-Based Network Management Automation in 5G Networks |
| |
|
This document describes Network Management Automation (NMA) of cellular network services in 5G networks. For NMA, it proposes a framework empowered with Intent-Based Networking (IBN). The NMA in this document deals with a closed-loop network control, network intent translator, and network management audit. To support these three features in NMA, it specifies an architectural framework with system components and interfaces. Also, this framework can support the use cases of NMA in 5G networks such as the data aggregation of Internet of Things (IoT) devices, network slicing, and the Quality of Service (QoS) in Vehicle-to-Everything (V2X). |
| | The SDN-based MPTCP-aware and MPQUIC-aware Transmission Control Model |
| |
|
This document aims to study and implement Multipath Transmission Control Protocol (MPTCP) and Multipath QUIC (MPQUIC) using application layer traffic optimization (ALTO) or Link Layer Discovery Protocol (LLDP) in Software-Defined Networking (SDN). In a traditional Software-Defined Networking, ALTO server collects network cost indicators (including link delay, number of paths, availability, network traffic, bandwidth and packet loss rate etc.), and the controller extracts MPTCP or MPQUIC packet header to allocate MPTCP or MPQUIC packet to suitable transmission path according to the network cost indicators by ALTO and YANG topology modules, which can reduce the probability of transmission path congestion and improving path utilization in a multipath transmission network. |
| | An Intent-Based Management Framework for Software-Defined Vehicles in Intelligent Transportation Systems |
| |
|
Software-Defined Vehicle (SDV) is a new player towards autonomous vehicles in Intelligent Transportation Systems (ITS). An SDV is constructed by a software platform like a cloud-native system (e.g., Kubernetes) and has its internal network. To facilitate the easy and efficient configuration of networks in the SDV, an intent-based management is an appropriate direction. This document proposes a framework of intent-based management for networks, security, and applications in SDVs so that they can communicate with other SDVs and infrastructure nodes for safe driving and infotainment services in the road networks. |
| | 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. |
| | 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. |
| | Framework for High Performance Wide Area Network (HP-WAN) |
| |
|
This document defines a framework to enable the host-network collaboration for high-speed and high-throughput data transmission, coupled with fast completion time of High Performance Wide Area Networks (HP-WAN). It focuses on key congestion control functions to facilitate host-to-network collaboration and perform rate negotiation, such as QoS policy, admission control, and traffic scheduling. |
| | 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. 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 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. |
| | 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). |
| | BGP AS_PATH Verification Based on Route Path Authorizations (RPA) Objects |
| |
|
The Route Path Authorizations (RPA) is an RPKI object that attests to the complete routing paths description which an Autonomous System (AS) would obey in Border Gateway Protocol (BGP) route propagation. This document specifies an RPA-based AS Path Verification methodology to mitigate, even solve, AS Path forgery and route leaks. This document also explains the various BGP security threats that RPA can help address and provides operational considerations associated with RPA deployment. |
| | Benchmarking Methodology for Computing-aware Traffic Steering |
| |
|
Computing-aware traffic steering(CATS) is a traffic engineering approach based on the awareness of both computing and network information. This document proposes benchmarking methodologies for CATS. |
| | Enhancing Security in EAP-AKA' with Hybrid Post-Quantum Cryptography |
| |
|
Forward Secrecy for the Extensible Authentication Protocol Method for Authentication and Key Agreement (EAP-AKA' FS) is specified in [RFC9678], providing updates to [RFC9048] with an optional extension that offers ephemeral key exchange using the traditional Ephemeral Elliptic Curve Diffie-Hellman (ECDHE) key agreement algorithm for achieving perfect forward secrecy (PFS). However, it is susceptible to future threats from Cryptographically Relevant Quantum Computers, which could potentially compromise a traditional ephemeral public key. If the adversary has also obtained knowledge of the long-term key and ephemeral public key, it could compromise session keys generated as part of the authentication run in EAP-AKA'. This draft aims to enhance the security of EAP-AKA' FS protocol by leveraging PQ/T Hybrid [I-D.ietf-pquip-pqt-hybrid-terminology] algorithms to make it quantum-safe. |
| | BIER Payload Label |
| |
|
The BIER Encapsulation RFC8296 specifies that the "Proto" field in the BIER header is set to 1 if an MPLS label stack follows the BIER header and the top of the stack label is a downstream-assigned label, and is set to 2 if the top of stack label is an upstream-assigned label, which is looked up in the context-specific label forwarding table that can be derived from the BIER header. The terms upstream/downstream-assignment are inappropriate to describe the required forwarding for new MPLS label semantics such as SRGB and DCB labels as defined in RFC8402 and RFC9573 respectively. This can result in potentially inconsistent implementation choices causing potential interoperability issues. This document rectifies this situation by changing the IANA BIER Next Protocol Identifier semantic for MPLS code points from their label semantic to the required LFIB in the forwarding plane, hence covering those new type of labels without changing behavior for existing upstream/downstream-assigned labels. |
| | The SSLKEYLOGFILE Format for TLS |
| |
|
A format that supports logging information about the secrets used in a TLS connection is described. Recording secrets to a file in SSLKEYLOGFILE format allows diagnostic and logging tools that use this file to decrypt messages exchanged by TLS endpoints. This format is intended for use in systems where TLS only protects test data. |
| |
|
| |
| | Use of the ML-DSA Signature Algorithm in the Cryptographic Message Syntax (CMS) |
| |
|
The Module-Lattice-Based Digital Signature Algorithm (ML-DSA), as defined in FIPS 204, is a post-quantum digital signature scheme that aims to be secure against an adversary in possession of a Cryptographically Relevant Quantum Computer (CRQC). This document specifies the conventions for using the ML-DSA signature algorithm with the Cryptographic Message Syntax (CMS). In addition, the algorithm identifier and public key syntax are provided. |
| | Integration of Speech Codec Enhancement Methods into the Opus Codec |
| |
|
This document proposes a set of requirements for integrating a speech codec enhancement method into the Opus codec [RFC6716] |
| | Subscription to Notifications in a Distributed Architecture |
| |
|
This document describes extensions to the YANG notifications subscription to allow metrics being published directly from processors on line cards to target receivers, while subscription is still maintained at the route processor in a distributed forwarding system. |
| | 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. |
| | 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. |
| | RPKI to Router Protocol over QUIC |
| |
|
The Resource Public Key Infrastructure (RPKI) to Router Protocol provides a simple but reliable mechanism to receive cryptographically validated RPKI prefix origin data and router keys from a trusted cache. RPKI to Router (RTR) Protocol can be carried over various transports such as TCP, SSH or else. QUIC provides useful and secure semantics for RTR Protocol in particular as a single connection could carry multiple requests over streams, enabling much better efficiency and performance for both peers. This document describes how to use RTR Protocol over the QUIC transport protocol, named RTRoQUIC. |
| | Unified Network and Cloud Orchestration Framework |
| |
|
This draft introduces the Unified Network and Cloud Orchestration Framework (UNCO), which is designed to enable real-time and joint orchestration of network and computing resources in 5G and future- generation networks. UNCO framework addresses inefficiencies in current resource scheduling mechanisms, resolves objective conflicts across domains, and provides unified policy and security management. It is applicable in emerging scenarios such as ultra-reliable low- latency communications (URLLC), mobile edge computing (MEC), and network slicing, where service quality and operational efficiency are paramount. |
| | 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. |
| | Registration Protocol for Performance and Diagnostic Metrics |
| |
|
This document specifies a registration protocol for use with Performance and Diagnostic Metrics version 2 (PDMv2). This registration process enables endpoints to communicate supported policies and capabilities in advance of measurement sessions, simplifying setup and enhancing security. The protocol defines a set of commands, responses, and message formats, and proposes integration with the Diameter Base Protocol (RFC6733) as the transport and authentication mechanism. |
| | Gap Analysis of Fast Notification for Traffic Engineering and Load Balancing |
| |
|
Modern networks require fast, adaptive Traffic Engineering (TE) to support demanding applications like AI training and real-time services. Existing mechanisms for load balancing, protection, and flow control often lack responsiveness and scalability. This document analyzes key gaps in current TE solutions and proposes fast notification as a low-latency, event-driven enhancement. Fast notification enables real-time network awareness and quicker reactions to dynamic conditions, improving overall network efficiency and reliability. |
| |
|
| |
| | IPv6 Neighbor Discovery Prefix Registration |
| |
|
This document updates Subnet Neighbor Discovery (RFC 8505, RFC 8928) to enable a node that owns or is directly connected to a prefix to register that prefix to neighbor routers. The registration indicates that the registered prefix can be reached via the advertising node without a loop. The unicast prefix registration allows the node to request neighbor router(s) to redistribute the prefix in another routing domain regardless of the routing protocol used in that domain. This document extends Routing Protocol for Low-Power and Lossy Networks (RPL) (RFC 6550, RFC 9010) to enable a 6LoWPAN Router (6LR) to inject the registered prefix in RPL. |
| | Finding Tracking Tags |
| |
| | draft-ietf-dult-finding-01.txt |
| | Date: |
06/06/2025 |
| | Authors: |
Christine Fossaceca, Eric Rescorla |
| | Working Group: |
Detecting Unwanted Location Trackers (dult) |
|
Lightweight location tracking tags are in wide use to allow users to locate items. These tags function as a component of a crowdsourced tracking network in which devices belonging to other network users (e.g., phones) report which tags they see and their location, thus allowing the owner of the tag to determine where their tag was most recently seen. This document defines the protocol by which devices report tags they have seen and by which owners look up their location. |
| | 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. |
| | Advertising Unreachable Links in OSPF |
| |
|
In certain scenarios, it is necessary to advertise unreachable links in OSPF, which should be explicitly excluded from the related SPF calculation. This document specifies using LSLinkInfinity(0xffff) to advertise an OSPF link as unreachable. Stub Router Advertisement (RFC 6987) defines MaxLinkMetric (0xffff) to indicate a router-LSA link should not be used for transit traffic. This document updates RFC 6987 and RFC 8770. When an OSPFv2 router supports the Unreachable Link support capability defined in this document, the OSPFv2 stub router MaxLinkMetric(0xffff) MUST be updated to MaxReachableLinkMetric(0xfffe). |
| | Label Switched Path Ping for Segment Routing Path Segment Identifier with MPLS Data Plane |
| |
|
Segment Routing (SR) leverages source routing to steer packets through an ordered list of instructions, called segments. SR can be instantiated over the MPLS data plane. Path Segment Identifiers (PSIDs) are used to identify and correlate bidirectional or end-to- end paths in Segment Routing networks. This document defines procedures (i.e. six new Target forwarding Equivalence Class (FEC) Stack sub-TLVs) for the use of LSP Ping to support connectivity verification and fault isolation for SR paths that include Path Segment Identifiers. The mechanisms described enable the validation and tracing of SR paths with Path SIDs in MPLS networks, complementing existing SR-MPLS OAM capabilities. |
| | YANG Groupings for HTTP Clients and HTTP Servers |
| |
|
This document primarily presents two YANG modules: the first defines a minimal grouping for configuring an HTTP client, and the second defines a minimal grouping for configuring an HTTP server. It is intended that these groupings will be used to help define the configuration for simple HTTP-based protocols (not for complete web servers or browsers). This document additionally presents a third YANG module, to define a grouping for URIs. |
| | The FNV Non-Cryptographic Hash Algorithm |
| |
| | draft-eastlake-fnv-35.txt |
| | Date: |
06/06/2025 |
| | Authors: |
Glenn Fowler, Landon Noll, Kiem-Phong Vo, Donald Eastlake, Tony Hansen |
| | Working Group: |
Individual Submissions (none) |
|
FNV (Fowler/Noll/Vo) is a fast, non-cryptographic hash algorithm with good dispersion that has been widely used and is referenced in a number of standards documents. The purpose of this document is to make information on FNV and open-source code performing all specified sizes of FNV conveniently available to the Internet community. |
| | SRv6 Egress Protection in Multi-homed scenario |
| |
|
This document describes a SRv6 egress node protection mechanism in multi-homed scenarios. |
| | NRP ID in SRv6 segment |
| |
|
This document proposes a method to carry the NRP-ID with the packet in the SRv6 segment. |
| | IS-IS and OSPFv3 Extensions to Advertise SRv6 Service SID |
| |
|
The IPv6 backbone networks only deploying IGP may be required to interconnect IPv4 islands. SRv6 Service SIDs like End.DT4 may be used to realize such requirements. This document extends IS-IS and OSPFv3 to advertise SRv6 Service SIDs. |
| | Encapsulation of BFD for SRv6 Policy |
| |
|
Bidirectional Forwarding Detection (BFD) mechanisms can be used for fast detection of failures in the forwarding path of SR Policy. This document describes the encapsulation of BFD for SRv6 Policy. The BFD packets may be encapsulated in Insert-mode or Encaps-mode. |
| | Reliability in AI Networks Gap Analysis,Problem Statement,and Requirements |
| |
|
This document provides the gap analysis of existing reliability mechanism in AI networks, describes the fundamental problems, and defines the requirements for technical improvements. |
| | IGP Color-Aware Routing |
| |
| | draft-lin-lsr-igp-car-03.txt |
| | Date: |
06/06/2025 |
| | Authors: |
Changwang Lin, Mengxiao Chen, Liyan Gong |
| | Working Group: |
Individual Submissions (none) |
|
This document describes an IGP based routing solution to establish end-to-end intent-aware paths across a multi-domain service provider transport network. |
| | 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. |
| | Secure Asset Transfer Protocol (SATP) Core |
| |
| | draft-ietf-satp-core-09.txt |
| | Date: |
06/06/2025 |
| | Authors: |
Martin Hargreaves, Thomas Hardjono, Rafael Belchior, Venkatraman Ramakrishna, Alexandru Chiriac |
| | Working Group: |
Secure Asset Transfer Protocol (satp) |
|
This memo describes the Secure Asset Transfer (SAT) Protocol for digital assets. SAT is a protocol operating between two gateways that conducts the transfer of a digital asset from one gateway to another, each representing their corresponding digital asset networks. The protocol establishes a secure channel between the endpoints and implements a 2-phase commit (2PC) to ensure the properties of transfer atomicity, consistency, isolation and durability. |
| |
|
| |
| | Encapsulation of Simple Two-Way Active Measurement Protocol for Pseudowires and LSPs in MPLS Networks |
| |
| | draft-ietf-mpls-stamp-pw-01.txt |
| | Date: |
05/06/2025 |
| | Authors: |
Rakesh Gandhi, Patrice Brissette, Eddie Leyton, Xiao Min |
| | Working Group: |
Multiprotocol Label Switching (mpls) |
|
Pseudowires (PWs) and Label Switched Paths (LSPs) are used in MPLS networks for various services including carrying layer 2 and layer 3 data packets. This document describes the procedure for encapsulation of the Simple Two-Way Active Measurement Protocol (STAMP) defined in RFC 8762 and its optional extensions defined in RFC 8972 for PWs and LSPs in MPLS networks. The procedure uses Generic Associated Channel (G-ACh) to encapsulate the STAMP test packets with or without adding an IP/UDP header for PWs and LSPs. |
| | Guidelines for Authors and Reviewers of Documents Containing YANG Data Models |
| |
|
This document provides guidelines for authors and reviewers of specifications containing YANG data models, including IANA-maintained modules. Recommendations and procedures are defined, which are intended to increase interoperability and usability of Network Configuration Protocol (NETCONF) and RESTCONF Protocol implementations that utilize YANG modules. This document obsoletes RFC 8407. Also, this document updates RFC 8126 by providing additional guidelines for writing the IANA considerations for RFCs that specify IANA-maintained modules. |
| | Advertisement of Candidate Path Validity Control Parameters using BGP-LS |
| |
|
This document describes a mechanism to collect the configuration and states of SR policies carrying the validity control parameters of the candidate path by using BGP Link-State (BGP-LS) updates. Such information can be used by external components for path computation, re-optimization, service placement, etc. |
| | PCEP extension to support Candidate Paths validity |
| |
|
This document defines PCEP extensions for signaling the validity control parameters of a candidate path for an SR Policy. |
| | EVPN Group Policy |
| |
|
Group Based Policy can be used to achieve micro or macro segmentation of user traffic. For Group Based Policy, a Group Policy ID, also known as Group Policy Tag, is used to represent a logical group that shares the same policy and access privilege. This document defines a backward compatible extension to Virtual eXtensible Local Area Network (VXLAN) that allows a Group Policy ID to be carried for the purposes of policy enforcement at the egress Network Virtualization Edge (NVE). It also defines a new BGP Extended Community that can be used to propagate Group Policy ID through a BGP route advertisement in the control plane. This is to facilitate policy enforcement at the ingress NVE when feasible. |
| | Deadline Aware Streams in QUIC Multipath |
| |
|
This document proposes the Deadline-aware Multipath Transport Protocol (DMTP) concept as an extension to the Multipath Extension for QUIC (QUIC-MULTIPATH) as well as QUIC itself. This extension aims to support data streams with strict latency requirements by enabling the signaling of a stream's deadline and ideally by combining multipath scheduling, congestion control adaptations, and optional forward error correction (FEC). Moreover, DMTP leverages the path identifiers introduced by the Multipath Extension for QUIC to distinguish different end-to-end paths as they may be offered in a Path Aware Network (PAN) such as SCION. This allows an application to select its preferred paths while maintaining interoperability with standard endpoints using the Multipath Extension for QUIC. In combination, DMTP enables endpoints to exchange and schedule deadline-aware streams across multiple network paths. Additionally, this proposal also maintains compatibility with QUIC itself, in order to deliver its benefits - albeit with limited effectiveness - even in scenarios where only a single path can or should be used. |
| | Evidence Package Format Specification |
| |
|
Taking evidence is a key part of any 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. |
| | The DIMG (Dual-Image) File Format Specification |
| |
|
This document specifies the DIMG (Dual-Image) file format, which encapsulates two discrete image blocks within a single file container. The format addresses common inefficiencies in handling front/back documentation scenarios by eliminating redundant file management operations and simplifying data exchange workflows. Security considerations are discussed in Section 7. |
| | 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. |
| | Early IANA Registry Creation |
| |
|
This memo describes the requirements for publishing a registry on the IANA website before the IETF Stream document that creates the registry is approved for publication as an RFC. This process can be used when a Working Group needs to coordinate allocations among multiple documents or with an organization outside the IETF. |
| | Registration Data Access Protocol (RDAP) Extension for Geofeed Data |
| |
|
This document defines a new Registration Data Access Protocol (RDAP) extension, "geofeed1", for indicating that an RDAP server hosts geofeed URLs for its IP network objects. It also defines a new media type and a new link relation type for the associated link objects included in responses. |
| |
|
| |
| | Automated Certificate Management Environment (ACME) Delay-Tolerant Networking (DTN) Node ID Validation Extension |
| |
|
This document specifies an extension to the Automated Certificate Management Environment (ACME) protocol which allows an ACME server to validate the Delay-Tolerant Networking (DTN) Node ID for an ACME client. A DTN Node ID is an identifier used in the Bundle Protocol (BP) to name a "singleton endpoint", one which is registered on a single BP node. The DTN Node ID is encoded as a certificate Subject Alternative Name (SAN) of type otherName with a name form of BundleEID and as an ACME Identifier type "bundleEID". |
| | Optimizing BFD Authentication |
| |
|
This document describes an experimental optimization to BFD Authentication. It provides procedure where only important BFD state transitions require strong authentication and permits the majority of BFD Control Packets to use a less computationally intensive authentication mechanism. This enables BFD to scale better when there is a desire to use strong authentication. |
| | Protocol-Specific Profiles for JSContact |
| |
|
This document defines JSContact profiles, a named subsets of JSContact elements that are supported in context of a contact data exchange protocol or other use case. It aims to facilitate using JSContact in contexts where supporting all of JSContact semantics is not appropriate. |
| | 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. |
| | Use of Hybrid Public-Key Encryption (HPKE) with CBOR Object Signing and Encryption (COSE) |
| |
| | draft-ietf-cose-hpke-13.txt |
| | Date: |
04/06/2025 |
| | Authors: |
Hannes Tschofenig, Orie Steele, Ajitomi, Daisuke, Laurence Lundblade |
| | Working Group: |
CBOR Object Signing and Encryption (cose) |
|
This specification defines hybrid public-key encryption (HPKE) for use with CBOR Object Signing and Encryption (COSE). HPKE offers a variant of public-key encryption of arbitrary-sized plaintexts for a recipient public key. HPKE works for any combination of an asymmetric key encapsulation mechanism (KEM), key derivation function (KDF), and authenticated encryption with additional data (AEAD) function. Authentication for HPKE in COSE is provided by COSE-native security mechanisms or by the pre-shared key authenticated variant of HPKE. This document defines the use of the HPKE with COSE. |
| | Dynamic Host Configuration Protocol for IPv6 (DHCPv6) |
| |
| | draft-ietf-dhc-rfc8415bis-12.txt |
| | Date: |
04/06/2025 |
| | Authors: |
Tomek Mrugalski, Bernie Volz, Michael Richardson, Sheng Jiang, Timothy Winters |
| | Working Group: |
Dynamic Host Configuration (dhc) |
|
This document specifies the Dynamic Host Configuration Protocol for IPv6 (DHCPv6): an extensible mechanism for configuring nodes with network configuration parameters, IP addresses, and prefixes. Parameters can be provided statelessly, or in combination with stateful assignment of one or more IPv6 addresses and/or IPv6 prefixes. DHCPv6 can operate either in place of or in addition to stateless address autoconfiguration (SLAAC). This document obsoletes RFC8415 to incorporate reported errata and to obsolete the assignment of temporary addresses (the IA_TA option) and the server unicast capability (the Server Unicast option and UseMulticast status code). |
| | DNSSEC Cryptographic Algorithm Recommendation Update Process |
| |
|
The DNSSEC protocol makes use of various cryptographic algorithms to provide authentication of DNS data and proof of non-existence. To ensure interoperability between DNS resolvers and DNS authoritative servers, it is necessary to specify both a set of algorithm implementation requirements and usage guidelines to ensure that there is at least one algorithm that all implementations support. This document replaces and obsoletes RFC8624 and moves the canonical source of algorithm implementation requirements and usage guidance for DNSSEC from RFC8624 to an IANA registry. This is done both to allow the list of requirements to be more easily updated, and to allow the list to be more easily referenced. Future extensions to this registry can be made under new, incremental update RFCs. This document also incorporates the revised IANA DNSSEC considerations from RFC9157. The document does not change the status (MUST, MAY, RECOMMENDED, etc.) of the algorithms listed in RFC8624; that is the work of future documents. |
| | Using the Extensible Authentication Protocol (EAP) with Ephemeral Diffie-Hellman over COSE (EDHOC) |
| |
| | draft-ietf-emu-eap-edhoc-04.txt |
| | Date: |
04/06/2025 |
| | Authors: |
Dan Garcia-Carrillo, Rafael Marin-Lopez, Goeran Selander, John Mattsson, Francisco Lopez |
| | Working Group: |
EAP Method Update (emu) |
|
The Extensible Authentication Protocol (EAP), defined in RFC 3748, provides a standard mechanism for support of multiple authentication methods. This document specifies the EAP authentication method EAP- EDHOC, based on Ephemeral Diffie-Hellman Over COSE (EDHOC). EDHOC is a lightweight security handshake protocol, enabling authentication and establishment of shared secret keys suitable in constrained settings. This document also provides guidance on authentication and authorization for EAP-EDHOC. |
| | The eap.arpa domain and EAP provisioning |
| |
|
This document defines the eap.arpa domain for use only in Network Access Identifiers (NAIs) as a way for Extensible Authentication Protocol (EAP) peers to signal to EAP servers that they wish to obtain limited, and unauthenticated, network access. EAP peers signal which kind of access is required via certain predefined identifiers which use the Network Access Identifier (NAI) format of RFC 7542. A table of identifiers and meanings is defined, which includes entries for RFC 9140. |
| | Resumable Uploads for HTTP |
| |
|
Data transfer using the Hypertext Transfer Protocol (HTTP) is often interrupted by canceled requests or dropped connections. If the intended recipient can indicate how much of the data was received prior to interruption, a sender can resume data transfer at that point instead of attempting to transfer all of the data again. HTTP range requests support this concept of resumable downloads from server to client. This document describes a mechanism that supports resumable uploads from client to server using HTTP. |
| | VPN Prefix Outbound Route Filter (VPN Prefix ORF) for BGP-4 |
| |
|
This draft defines a new type of Outbound Route Filter (ORF), known as the VPN Prefix ORF. The VPN Prefix ORF mechanism is applicable when VPN routes from different VRFs are exchanged through a single shared BGP session. |
| | Comparison of CoAP Security Protocols |
| |
|
This document analyzes and compares the sizes of key exchange flights and the per-packet message size overheads when using different security protocols to secure CoAP. Small message sizes are very important for reducing energy consumption, latency, and time to completion in constrained radio network such as Low-Power Wide Area Networks (LPWANs). The analyzed security protocols are DTLS 1.2, DTLS 1.3, TLS 1.2, TLS 1.3, cTLS, EDHOC, OSCORE, and Group OSCORE. The DTLS and TLS record layers are analyzed with and without 6LoWPAN- GHC compression. DTLS is analyzed with and without Connection ID. |
| | Key Transparency Protocol |
| |
|
While there are several established protocols for end-to-end encryption, relatively little attention has been given to securely distributing the end-user public keys for such encryption. As a result, these protocols are often still vulnerable to eavesdropping by active attackers. Key Transparency is a protocol for distributing sensitive cryptographic information, such as public keys, in a way that reliably either prevents interference or detects that it occurred in a timely manner. |
| | Validity of SR Policy Candidate Path |
| |
|
This document defines extensions to BGP to distribute the validity control parameters of a candidate path for an SR Policy. |
| | Certificate Status Information Mechanism Description Updates to RFC 5280 |
| |
|
The updates to RFC 5280 described in this document provide alignment with the 2013 specification for the X.509 Internet Public Key Infrastructure Online Certificate Status Protocol-OCSP [RFC6960]. |
| | Technical guidelines of Web server certification path validation for Interent browser |
| |
|
In Web PKI, certificate path construction and validation are crucial security review processes. At present, there are many Internet browser manufacturers around the world. With the change of security practices and the development of technology, the certificate validation process in Internet browser industry is relatively messy, including various private implementations of manufacturers. It is a typical patching improvement method, and the implementation of process functions is relatively arbitrary. This document provides a technical guide for certification path validation of web server certificates during Internet SSL/TLS protocol communication for Web PKI, including the basic path verification process, as well as reference procedures, guidance and suggestions for input, initialization, and basic certificate processing in the verification process. This document is applicable to the development and application of Internet browsers, as well as other similar digital certificate authentication systems requiring SSL/TLS security protocol secure communication. |
| | Using TLS Client Authentication with DNS Handles |
| |
|
This is a discussion document prepared for the DANCE Working Group presenting possible convergence between the DNS Handles authentication approach based on OAUTH being used in the ATmosphere and the DANCE approach. User experience and architectural requirements for using TLS Client Authentication in a DNS Handles based environment are discussed. |
| | Bundle Protocol (BP) Security Associations with Few Exchanges (SAFE) |
| |
|
This document defines a protocol for negotiating scoped security associations between Bundle Protocol version 7 (BPv7) agents within a delay-tolerant network (DTN). Security associations are used to amortize the costs of asymmetric-keyed security operations and allow for efficient and high-throughput BPv7 security within a public key infrastructure. |
| | PCEP Extensions for Tree Engineering for Bit Index Explicit Replication (BIER-TE) |
| |
| | draft-ietf-pce-bier-te-02.txt |
| | Date: |
04/06/2025 |
| | Authors: |
Ran Chen, Zheng Zhang, Huaimo Chen, Senthil Dhanaraj, Fengwei Qin, Aijun Wang |
| | Working Group: |
Path Computation Element (pce) |
|
Tree Engineering for Bit Index Explicit Replication (BIER-TE) shares architecture and packet formats with BIER. BIER-TE forwards and replicates packets based on a BitString in the packet header, but every BitPosition of the BitString of a BIER-TE packet indicates one or more adjacencies. BIER-TE Path can be derived from a Path Computation Element (PCE). This document specifies extensions to the Path Computation Element Protocol (PCEP) that allow a PCE to compute and initiate the path for the Tree Engineering for Bit Index Explicit Replication (BIER-TE). |
| | Registration Data Access Protocol (RDAP) Regional Internet Registry (RIR) Search |
| |
|
The Registration Data Access Protocol (RDAP) is used by Regional Internet Registries (RIRs) and Domain Name Registries (DNRs) to provide access to their resource registration information. The core specifications for RDAP define basic search functionality, but there are various search options related to IP addresses, IP prefixes, and ASNs, which are provided by RIRs via their Whois services, but for which there is no corresponding RDAP functionality. This document extends RDAP to support those search options. |
| | Static Context Header Compression and Fragmentation over networks prone to disruptions |
| |
|
This document describes the use of SCHC over different network topologies and devices regardless of their capabilities and configurations. The use of SCHC will bring connectivity to devices with disruptive connections caused by restrained use of battery and connectionless setups with long delays and latency. |
| |
|
| |
| | BRSKI with Pledge in Responder Mode (BRSKI-PRM) |
| |
| | draft-ietf-anima-brski-prm-23.txt |
| | Date: |
03/06/2025 |
| | Authors: |
Steffen Fries, Thomas Werner, Eliot Lear, Michael Richardson |
| | Working Group: |
Autonomic Networking Integrated Model and Approach (anima) |
|
This document defines enhancements to Bootstrapping Remote Secure Key Infrastructure (BRSKI, RFC8995) as BRSKI with Pledge in Responder Mode (BRSKI-PRM). BRSKI-PRM supports the secure bootstrapping of devices, referred to as pledges, into a domain where direct communication with the registrar is either limited or not possible at all. To facilitate interaction between a pledge and a domain registrar the registrar-agent is introduced as new component. The registrar-agent supports the reversal of the interaction model from a pledge-initiated mode, to a pledge-responding mode, where the pledge is in a server role. To establish the trust relation between pledge and registrar, BRSKI-PRM relies on object security rather than transport security. This approach is agnostic to enrollment protocols that connect a domain registrar to a key infrastructure (e.g., domain Certification Authority). |
| | BGP Link-State extensions for BIER |
| |
| | draft-ietf-bier-bgp-ls-bier-ext-20.txt |
| | Date: |
03/06/2025 |
| | Authors: |
Ran Chen, Zheng Zhang, Vengada Govindan, IJsbrand Wijnands, Zhaohui Zhang |
| | Working Group: |
Bit Indexed Explicit Replication (bier) |
|
Bit Index Explicit Replication (BIER) is an architecture that provides optimal multicast forwarding through a "BIER domain" without requiring intermediate routers to maintain any multicast related per- flow state. BIER also does not require any explicit tree-building protocol for its operation. A multicast data packet enters a BIER domain at a "Bit-Forwarding Ingress Router" (BFIR), and leaves the BIER domain at one or more "Bit-Forwarding Egress Routers" (BFERs). The BFIR router adds a BIER header to the packet. The BIER header contains a bitstring in which each bit represents exactly one BFER to forward the packet to. The set of BFERs to which the multicast packet needs to be forwarded is expressed by setting the bits that correspond to those routers in the BIER header. BGP Link-State (BGP-LS) enables the collection of various topology informations from the network, and the topology informations are used by the controller to calculate the fowarding tables and then propagate them onto the BFRs(instead of having each node to calculate on its own) and that can be for both inter-as and intra-as situations. This document specifies extensions to the BGP Link-state address- family in order to advertise the BIER informations. |
| | Media Type Registration for Protocol Buffers |
| |
|
This document registers media types for Protocol Buffers, a common extensible mechanism for serializing structured data. |
| | Deprecate usage of ECC-GOST within DNSSEC |
| |
|
This document retires the use of GOST R 34.10-2001 (mnemonic "ECC- GOST") within DNSSEC. RFC5933 (now historic) defined the use of GOST R 34.10-2001 and GOST R 34.11-94 algorithms with DNS Security Extensions (DNSSEC). This document updates RFC5933 by deprecating the use of ECC-GOST. |
| | Deprecating the use of SHA-1 in DNSSEC signature algorithms |
| |
|
This document deprecates the use of the RSASHA1 and RSASHA1-NSEC3-SHA1 algorithms for the creation of DNS Public Key (DNSKEY) and Resource Record Signature (RRSIG) records. It updates RFC4034 and RFC5155 as it deprecates the use of these algorithms. |
| | Bundle Protocol Security (BPSec) COSE Context |
| |
|
This document defines a security context suitable for using CBOR Object Signing and Encryption (COSE) algorithms within Bundle Protocol Security (BPSec) integrity and confidentiality blocks. A profile for COSE, focused on asymmetric-keyed algorithms, and for PKIX certificates are also defined for BPSec interoperation. |
| | 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. |
| | The "_for-sale" Underscored and Globally Scoped DNS Node Name |
| |
|
This document defines an operational convention for using the reserved underscored DNS leaf node name "_for-sale" to indicate that the parent domain name is available for purchase. This approach offers the advantage of easy deployment without affecting ongoing operations. As such, the method can be applied to a domain name that is still in full use. Note to the RFC Editor This document contains several "Notes to the RFC Editor", including this section. These should be reviewed and resolved prior to publication. |
| | IPv6 Extended Fragment Header for IPv4 |
| |
|
The Internet Protocol, version 4 (IPv4) header includes a 16-bit Identification field in all packets, but this length is too small to ensure reassembly integrity even at moderate data rates in modern networks. Even for Internet Protocol, version 6 (IPv6), the 32-bit Identification field included when a Fragment Header is present may be smaller than desired for some applications. This specification addresses these limitations by adapting the IPv6 Extended Fragment Header for IPv4. |
| | COSE Receipts with CCF |
| |
|
This document defines a new verifiable data structure type for COSE Signed Merkle Tree Proofs specifically designed for transaction ledgers produced via Trusted Execution Environments (TEEs), such as the Confidential Consortium Framework ([CCF]) to provide stronger tamper-evidence guarantees. |
| | Requirements of Fast Notification for Traffic Engineering and Load Balancing |
| |
|
This document defines the requirements for Fast Notification for Traffic Engineering and Load Balancing (FaNTEL), a mechanism designed to deliver near real-time network status updates. FaNTEL enables fast failure and congestion notifications, supporting rapid protection switching and dynamic load balancing. By providing low- latency alerts, it helps networks respond quickly to link failures and congestion events, improving service reliability and performance. |
| | CATALOG Authorization Transparency And Log Overlay for Graph-based DNS |
| |
|
This document proposes an extension to the Certification Authority Authorization (CAA) DNS Resource Record (RR) that enables the mandatory or optional binding of Certificate Transparency (CT) Log URIs directly within DNS. By embedding CT-Log endpoints in CAA RR, Certification Authorities (CAs) gain a standardized, discoverable mechanism for retrieving preferred and permitted CT-Log endpoint information, thereby enhancing the security and auditability of X.509 TLS certificate issuance. The extension defines the syntax and semantics for a new CAA property tag, *"issuect"*, and introduces a parameter set consisting of _"desc"_, _"critical"_, _"validfrom"_, _"validtill"_, _"cturi"_, _"logid"_, and _"pubkey"_. It outlines validation and processing rules, discusses deployment considerations, privacy implications, and interoperability with existing DNS, CA, and CT infrastructures. Additionally, the draft proposes an MTA-STS-like hardening mechanism, called *CAA-CT-STS*, for the new property to further strengthen the PKI ecosystem. Finally, it introduces the recursive acronym CATALOG (CATALOG Authorization Transparency And Log Overlay for Graph-based DNS) as a mnemonic for the overall extension framework. |
| | Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks |
| |
| | draft-ietf-nvo3-rfc7348bis-00.txt |
| | Date: |
03/06/2025 |
| | Authors: |
Mallik Mahalingam, Dinesh Dutt, Larry Kreeger, T. Sridhar, Ali Sajassi |
| | Working Group: |
Network Virtualization Overlays (nvo3) |
|
This document is a resubmission of RFC7348 as an IETF document stream so that proper IETF code points can be assigned in the IANA section for future work based on this RFC. This document obsoletes RFC7348 (Virtual eXtensible Local Area Network - VXLAN), which is used to address the need for overlay networks within virtualized data centers accommodating multiple tenants. The scheme and the related protocols can be used in networks for cloud service providers and enterprise data centers. This memo documents the deployed VXLAN protocol for the benefit of the Internet community. |
| |
|
| |
| | iCalendar Format Extensions for JSCalendar |
| |
|
This document defines a set of new elements for iCalendar and extends the use of existing ones. Their main purpose is to extend the semantics of iCalendar with elements defined in JSCalendar, but the new definitions also aim to be useful within just the iCalendar format. This document updates RFC 5545 ("Internet Calendaring and Scheduling Core Object Specification (iCalendar)"). |
| | YANG Data Model for FlexE Management |
| |
| | draft-ietf-ccamp-flexe-yang-cm-06.txt |
| | Date: |
02/06/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). |
| | DHCPv4-over-DHCPv6 (DHCP 4o6) with Relay Agent Support |
| |
|
This document describes a mechanism for networks with legacy IPv4-only clients to use services provided by DHCPv6 using DHCPv4- over-DHCPv6 (DHCP 4o6) in a Relay Agent. RFC7341 specifies use of DHCPv4-over-DHCPv6 in the client only. This document specifies a RFC7341-based approach that allows DHCP 4o6 to be deployed as a Relay Agent (4o6RA) that implements the 4o6 DHCP encapsulation and decapsulation in an intermediate node rather than the client. |
| | Quality of Outcome |
| |
|
This document introduces the Quality of Outcome (QoO) framework, a novel approach to network quality assessment designed to align with the needs of application developers, users, and operators. By leveraging the Quality Attenuation metric, QoO provides a unified method for defining and evaluating application-specific network requirements while ensuring actionable insights for network optimization and simple quality scores for end-users. |
| | OSPF-GT (Generalized Transport) |
| |
|
OSPFv2 and OSPFv3 include a reliable flooding mechanism to disseminate routing topology and Traffic Engineering (TE) information within a routing domain. Given the effectiveness of these mechanisms, it is advantageous to use the same mechanism for dissemination of other types of information within the domain. However, burdening OSPF with this additional information will impact intra-domain routing convergence and possibly jeopardize the stability of the OSPF routing domain. This document presents mechanisms to advertise this non-routing information in separate OSPF Generalized Transport (OSPF-GT) instances. OSPF-GT is not constrained to the semantics as traditional OSPF. OSPF-GT neighbors are not required to be directly attached since they are never used to compute hop-by-hop routing. Consequently, independent sparse topologies can be defined to dissemenate non- routing information only to those OSPF-GT routers requiring it. |
| | Updates to Anycast Property advertisement for OSPFv2 |
| |
|
Both SR-MPLS prefix-SID and IPv4 prefix may be configured as anycast and as such the same value can be advertised by multiple routers. It is useful for other routers to know that the advertisement is for an anycast identifier. Each prefix is advertised along with an 8-bit field of capabilities,by using the flag flield in the OSPFv2 Extended Prefix TLV, but the definition of anycast flag to identify the prefix as anycast has not yet been defined. This document defines a new flag in the OSPFv2 Extended Prefix TLV Flags to advertise the anycast property. |
| | OpenPGP Web Key Directory |
| |
|
This specification describes a service to locate OpenPGP keys by mail address using a Web service and the HTTPS protocol. It also provides a method for secure communication between the key owner and the mail provider to publish and revoke the public key. |
| | PCEP Extensions for sid verification for SR-MPLS |
| |
|
This document defines a new flag for indicating the headend is explicitly requested to verify SID(s) by the PCE. |
| | lispers.net LISP NAT-Traversal Implementation Report |
| |
|
This memo documents the lispers.net implementation of LISP NAT traversal functionality. The document describes message formats and protocol semantics necessary to interoperate with the implementation. This memo is not a standard and does not reflect IETF consensus. |
| | Simple Two-Way Active Measurement Protocol (STAMP) Extensions for Reflecting STAMP Packet MPLS Sub-Stacks |
| |
|
The Simple Two-Way Active Measurement Protocol (STAMP) and its optional extensions can be used for Edge-To-Edge (E2E) active measurement. In Situ Operations, Administration, and Maintenance (IOAM) data fields can be used for recording and collecting Hop-By- Hop (HBH) and E2E operational and telemetry information. This document extends STAMP to reflect MPLS Network Action Sub-Stacks for HBH and E2E active measurements, for example, using IOAM data fields. |
| | SCIM Profile for Security Event Tokens |
| |
| | draft-ietf-scim-events-08.txt |
| | Date: |
02/06/2025 |
| | Authors: |
Phillip Hunt, Nancy Cam-Winget, Mike Kiser, Jen Schreiber |
| | Working Group: |
System for Cross-domain Identity Management (scim) |
|
This specification defines a set of SCIM Security Events using the Security Event Token Specification RFC8417 to enable the asynchronous exchange of messages between SCIM Service Providers and receivers. SCIM Security Events are typically used for: asynchronous request completion, resource replication, and provisioning co-ordination. |
| | TLS 1.3 Extension for Using Certificates with an External Pre-Shared Key |
| |
|
This document specifies a TLS 1.3 extension that allows TLS clients and servers to authenticate with certificates and provide confidentiality based on encryption with a symmetric key from the usual key agreement algorithm and an external pre-shared key (PSK). |